개발자 원칙 (sprint 11) - 최지윤

2026/Developer_Principles/chichoon/chapter00_01_02.md

@@ -0,0 +1,50 @@
+## Chapter 00: 선배와의 인터뷰
+
+### 개요
+
+- 지식적인 측면의 글은 아니고 선배 개발자들의 인터뷰 형식의 글이라 술술 읽었다
+- 최근에 폭풍같은 바쁨을 겪고 .. 당장 오늘 낮에 팀장님과 면담을 했는데 그러고 나서 글을 읽으니 여러가지 생각이 들었음
+  - 내가 처음에 왜 이 일을 시작했었는지
+  - 지금 나는 이 일이 재밌다고 느끼고 있는지
+  - 힘들다면 어떤 부분이 힘든지
+- 사실 AI의 도입 및 미칠 듯한 발전으로 인해 점점 입사 초기에 막연히 생각했던 업무랑 달라지고 있어서 어색하긴 한데, 이것도 다 과도기일지니..
+  - 단순히 코드짜는 일만이 개발자의 업무가 아닌데 나는 아직도 거기에 얽매여 있는 건 아닌가? 라는 생각도 들었다
+- 인터뷰를 종합적으로 읽어봤을 때, 팀 동료들과 제품에 대한 애정이 생겨야 현재 업무에서 롱런할 수 있는 것 같음
+
+## Chapter 01: 덕업일치를 넘어서
+
+### 개요
+
+- 작성자가 매우 이과같다. 자전적인 글임에도 불구하고 온갖 차트와 물리용어가 등장한다
+- 업무를 시작한 계기를 보면 운이 좋았던 것으로 보이는데, 또 그 속에서도 자신의 자리를 보전하고 끊임없이 발전하고 즐거움을 찾으려고 노력한 걸 보면 롱런하는 이유가 있는 것 같다는 생각도 듦
+
+### 동기 관리
+
+- 내가 제일 못한다고 생각하는 부분 중 하나
+- 출퇴근길이 멀고 일이 바쁘다 보니 주어진 업무만 하느라 정신없고, 일을 하는 이유나 원동력은 없어진 것 같음
+- 당장에 빨리 해야하는 일만 쳐내기 급급해진 것 같음
+- 스스로의 에너지를 관리하고 업무를 하는 원동력을 적극적으로 찾는 부분에서 프로와 아마추어가 갈리는 것 같음
+  - 나는 아마추어다
+
+```
+논의 주제: 각자 일을 하면서 어디에서 힘을 가장 많이 얻는지? 보통 바쁘면 이런 걸 생각할 틈도 없지 않나요.. 제가 이상한건지 궁금
+```
+
+- 해당 챕터의 저자는 바쁜 상황 속에서도 커뮤니티를 열고 개발자들과 연대하며 끊임없이 서로를 돕는 것을 원동력으로 삼는 것 같은데, 정말 대단하다는 말 말고는 표현할 길이 없다
+  - 멘토님 생각도 났습니다.
+- 내 한 몸 보전하기 힘들어서 주변 사람들이랑 연락도 하나둘씩 끊어가는 내 자신에 한 5분정도 반성했다
+- 개발자를 양성하는 교육 과정이 흑마법과 같다는 사실은 공감
+  - 개발 방법(Java나 JavaScript 등)에만 치중하여 가르칠 게 아니라, 급변해가는 생태계에서 살아남고 주체적으로 끊임없이 지식을 습득하는 방법을 가르쳐야 한다고 생각
+  - 특히 지금처럼 AI로 하루가 다르게 급변하는 세상 속에서는 말이다
+- AI는 개발자를 완전히 대체하기보단, AI 기술을 잘 다루는 사람들이 개발자로 롱런할 것이라는 생각에도 공감
+  - 애초에 개발자가 단순 코딩만 하는 직업이 아님에도 불구하고, 근래의 교육 과정이나 부트캠프 등등은 다 이러한 부분에 초점을 맞춰서 당장 기업에서 제품을 짜내기만 하는 코더를 양성했던 것 같음 => 진짜 흑마법
+
+## Chapter 02: 오류를 만날 때가 가장 성장하기 좋을 때다
+
+### 개요
+
+- 사실 오류도 AI와 비슷한 것이라고 생각
+  - AI가 개발자를 대체할 것이라고 막연히 생각하고 외면하기보단, 정면돌파하고 내 것으로 습득하는 것이 중요
+  - 오류도 마찬가지 (오류를 두려워하기보단, 오류를 통해 발전해나가는 것이 중요하다고 생각한다)
+- 요즘은 오류 해결을 온라인까지 공개하지 않아도, 온갖 지식을 정돈하고 다듬어서 전달하는 AI가 있다 보니 정보 분별 능력(이게 맞는 정보인지, 틀린 정보인지)만 잘 기른다면 더더욱이나 오류로 성장할 수 있는 기회가 많은 것 같다
+- 이 챕터의 저자는 버그를 해결하는 데에만 중점을 두지 않고, 그 원인까지 소스코드 레벨에서 분석하는 열정이 대단하다...

2026/Developer_Principles/chichoon/chapter03_04_05.md

@@ -0,0 +1,110 @@
+## Chapter 03: 소프트웨어 디자인 원칙
+
+### 개요
+
+- 첫 문장 읽자마자 든 생각. 직전에 소프트웨어 아키텍처 책을 읽어서 그런진 모르겠지만, 설계에 절대라는 게 있나? 잘못 배웠다고 단정지을 수 있나?
+- 읽다 보니, 왜 저자가 단정짓는 표현을 사용했는지 알았음. 용어와 특성에 매몰되기만 해서는 좋은 제품이 나올 수 없다는 뜻임을 알았다. 이 부분은 공감이 간다.
+- 저자는 소프트웨어 디자인을 설계 관점으로 생각하고, 기능 / 성능 / 유지 보수 / 미적 설계의 네 부분으로 나눈 뒤, 소프트웨어가 코드적으로 깔끔한지 여부를 넘어서 요구 사항을 만족하는지에 초점을 맞추고 있다
+- 소프트웨어 설계는 정해진 포맷이나 표준화된 모델이 없다
+  - 하지만 클라우드와 컨테이너, 라이브러리 등이 등장하면서, 사용성이 개선되었다
+  - 그러한 시스템을 소재로 분류하고, 각 소재를 사용할 때의 매뉴얼 등은 취급할 수 있게 됨
+  - 많은 디자인 도구나 노코드 도구들이 나오면서, 이것들이 설계 표준이 될 지도 모른다는 판단이 떠오르게 됨
+
+### 설계 종류
+
+- 기능 설계
+  - 가장 중요한, 토대가 되는 설계
+  - 추가 및 개선할 기능을 기반으로 명세서를 작성하며 설계를 수행
+  - 요구사항을 전부 맞출 수 있는지가 중요
+- 성능 설계
+  - 몇 명이, 어느 빈도로 소프트웨어를 사용하는지에 따라, 구조를 설계한다
+  - 또는, 어떤 라이브러리나 프레임워크를 쓸 건지, 어느 클라우드 시스템에 올릴 것인지도 이를 판가름한다
+- 유지보수 설계
+  - 한번 배포된 뒤 계속 기능이 추가될 것을 고려하여, 패치 때마다 문제 없이 안정적으로 시스템이 유지되도록 한다
+- 미적 설계
+  - 디자이너가 관여하는 영역
+  - 사용자가 제품을 편안하고 즐겁게 이용할 수 있게끔 하는 분야
+  - UI / UX
+- 사용성 검증
+  - 인간공학 기반의, GUI 를 검증하는 수치적 방식
+
+### 암묵적 설계
+
+- 직접적으로 명시되진 않지만, 실제 개발 과정에서 수행되는 설계들
+- 설계할 때 명시적으로 이건 명시적 설계고 이건 암시적 설계라고 구분짓진 않는다
+- 하지만 소프트웨어 개발에 깊이 관여한다
+- 서비스 지속성 설계
+  - 가용성 설계 (무고장 유지되는 시간 및 수리에 걸리는 시간)
+  - 용량 설계 (처리해야 할 트래픽)
+  - 연속성 설계 (소프트웨어가 중단되지 않고 계속 실행되어야 함)
+  - 보안 설계 (데이터의 기밀성)
+- 서비스 전환 설계
+  - 변환 설계 (기능의 추가 및 폐기 시 다른 기능에 영향 최소화)
+  - 릴리즈 설계 (업그레이드 크기, 및 릴리즈 가능 여부 판단)
+  - 설정 관리 설계 (설정값으로 인한 부작용 최소화)
+- 서비스 운영 설계
+  - 장애 대비 설계 (예상치 못한 장애 발생 시, 처치)
+  - 요구 수행 설계 (사용자 문의 응대 등)
+  - 문제 대응 설계 (예상 가능한 범위에서의 문제점 인지 및 대응방안 제시)
+- 서비스 개선 설계
+  - 서비스 리포팅 설계
+  - 서비스 측정 설계
+  - 서비스 레벨 설계
+
+## Chapter 04: 나의 메이저 버전을 업그레이드하는 마이너 원칙들
+
+### v0.1.0 두리번거리면서 속력과 방향을 자주 확인하기
+
+- 인생에 목표는 있을 수 있지만, 목표에 도달하기까지의 길은 아무도 알 수 없다
+  - 내비게이션처럼 최단 거리를 향해 갈 수 있는 게 아니다
+  - 한 번에 도착하리라는 기대를 버려야 함
+- 같은 방향으로 가고자 하는 사람들은 많을 수 있다
+  - 그 사람들의 속도를 신경 쓰지 말아야 한다
+  - 다들 자신만의 속도가 있기 마련이다. 남들의 속도에 맞출 필요가 전혀 없다.
+  - 내가 할 수 있는 일의 한계치, 속도가 제각각이라는 뜻
+- 또한, 방향을 잃지 않도록, 항상 새로운 도구와 지식에 열린 마음으로 다가가야 한다
+- 속력과 방향이 합쳐져 속도를 구성한다
+  - 빠르기도 중요하지만, 방향도 중요하다
+  - 목적지로의 방향을 계속 생각하며 움직이자
+
+### v0.2.0 낯선 방식으로 해결하기
+
+- 나만의 속도를 인지하는 데에 좋은 방법
+- 낯선 정보, 언어, 라이브러리, 지식 등을 의도적으로 공부해 본다
+- 이미 알고 있는 것과, 전혀 모르는 것은 명확히 다르다
+  - 전혀 모르는 내용은, 알고 있는 내용으로 설명하지 않으면 이해할 수 없다
+- 자신이 이 정보를 명확하게 알고 있는지 판단하는 방법
+  - 이 정보에 대해 모르는 사람에게 설명해보기
+  - 알고 있다면, 설명이 조금 돌아가더라도 다시 시도가 가능
+  - 모르는 개념이라면, 설명이 막힐 것
+- 낯선 방식으로 소프트웨어를 직접 만들면서 해결하는 습관을 들여야 한다
+- 아는 문제를 모르는 언어로 풀어보는 것도 좋다
+- 제약사항을 추가하는 것이, 성장에 밑거름이 된다
+
+### v0.3.0 개구리를 해부하지 말고 직접 만들기
+
+- 개구리와 똑같다고 생각될 정도의 무언가를 만들어 보라는 뜻
+  - 개구리와 정말 비슷한 무언가를 만들려면, 그 개구리의 특성과 정보를 깊이 이해하고 분석하고 있어야 한다
+- 이 이론을 컴퓨터 과학에 접목시켜서, 운영체제나 데이터베이스, 인공지능, 컴파일러 등을 직접 구현해본다 가정하고 설계해 보자
+  - 쉽지 않은 일이고, 포기할 확률도 높지만, 즐거운 도전이 될 수 있다
+  - 함수 하나부터 시작할 것
+
+### v0.4.0 남을 향한 자존심을 버리고, 나를 향한 자존감 채우기
+
+- 상대방과 비교하면 끝이 없다
+  - 부러움, 질투만 유발한다
+  - 자존심이 상하고, 기분만 나빠진다. 오히려 성장에 도움이 되지 않을 수도 있다.
+- 나 자신과 비교하고 노력해 나가야 한다
+  - 나에게 맞는 방법으로 발전하면, 성취감과 함께 천천히 성장할 수 있다
+- 각자 서로 다른 속도로 발전하는 것과 일맥상통
+
+### v0.5.0 결과를 향하면서 과정을 기록하기
+
+- 결과 지향적인 생각은, 코드를 작성하면 그걸로 끝낸다
+- 과정을 꾸준히 기록해야 한다
+  - 같은 주제를 학습해도 방향이 다를 수 있고, 과정이 다를 수 있다
+  - 같은 알고리즘 문제를 풀어도, 해결 과정이 제각각일 것이다
+  - 알고리즘 문제를 풀고 점수로 판결낼 것이 아니라, 대화와 의사결정 과정을 파악하는 것이 인재 채용에 큰 도움이 될 것
+- 개발 과정에서는 보통 이 부분을 놓치기 쉽기 때문에, 짝 프로그래밍 등을 이용해서 역할을 분담하고 수행하다 보면 과정에 신경을 더 쓸 수 있게 된다
+
+### v0.6.1 의도한 실수를 반복하면서 작은 부분을 개선하기