개발자 원칙 sprint 11 - 권태형

2026/Developer_Principles/taehyoung/3.md

@@ -0,0 +1,17 @@
+# 3장
+
+## 내 생각
+
+- 이분의 글을 읽으면서, 뭔가 느껴진 바이브가 있었습니다. 장 초반에 나오는 이분의 이력을 유심히 살펴보게 되었고, 크고 규모있는 회사 환경, SI환경 에서오랫동안 근무하면서, 굳혀진 본인만의 스타일과 에고가 있으신 분이겠구나 라고 생각했는데, 역시나 제 예상대로 였습니다
+- 초반부에 나오는 SOLID, KISS, YAGNI 등에 대한 맹목적 추정을 하지 말라는 것과 IT 업계 개발자들 사이에 설계라는 용어가 명확히 정의되지 않은 상황에 대해서는 개인적으로 공감되는 부분이 이였습니다
+- but, 책 후반부로 갈 수록, 본인의 방법론에 기초한 주장에 쎄지는 것을 느꼈고, 본인의 대기업 커리어의 경험에 대한 신뢰를 바탕으로 경험이 맞다는 전제하에 주장하시는 것 같다는 느낌을 받았습니다. 본인 경험하에서 이렇게 했더니 좋았더라 라는게 그렇게 큰 공감이 되진 않았고, 이분의 주장은 규모가 작은회사에서는 전혀 맞지 않겠다는 생각이 들었습니다
+- 저는 상황에 따라 적절한 방법론이 있을 수 있다고 생각하는 편이고, 그렇기에 현재 나 혹은 팀, 회사의 상황에 맞게 적절한 해결책들을 생각해내서(그게 책에서 읽은 것이든 경험한 것이든), 적용하는게 좋다고 생각하는 편인데, 이 저자는 본인의 경험상 이 방법이 맞다라는 식의 주장을 펼치고 있다보니, 특히 이런 부분은 공감이 안되었던 것 같습니다
+- 결국에 이분의 글은 설계를 꼼꼼이 하라는 말이고, 책 후반부는 그냥 여러 분야에서의 설계를 어떻게 해야하는지에 대한 기계적인 조언 및 정답에 대한 내용들을 쭉 적어두었는데, 내용을 읽으면서, 솔직히 마음속으로 누가 이걸 모르나;; 라는 생각이 들었습니다. 사실 이런 정답 같은 것들이 현실세계에서 여러 변수들 때문에 생각대로 안되는 경우가 많고, 독자입장에서는 이것을 해결한 경험담 같은 것들을 듣고 싶다는 생각에 책을보는건데, 그냥 정답을 나열 하는식으로 적어둔것을 보고 많이 별로 라고 생각했습니다 솔직히 말하면, 그 내용도 별로 도움되는내용도 아니기도 했고…
+- 제가 만약에 이분과 서로 질문과 답변을 할 수 있는 시간이 있다면, 아래 내용을 물어볼 거 같습니다
+    - 17가지 설계항목을 제시하셨는데, 실제 제품이 설계대로 동작하지 않으면 어떻게 하나요? 제품을 고치나요? 설계를 고치나요?
+    - 최초 설계 대로 개발이 되더라도, 추후 유지보수 관점에서 요구사항이 변경되면, 설계도 변경될 수 있습니다. 애초에 확장성을 고려한 설계였다면, 변경이 안되겠지만, 예측못한 요구사항이 발생한다면, 결국 설계가 변경될 수 밖에 없는데, 이런 경우에 어떤식으로 관리하나요? / 애초에 고칠 설계라면, 굳이 설계를 열심히 할 필요가 있나요?
+    - 장애 대비 설계 파트에서, 실제로 장애 발생 시 수치에 따라 정해진 등급대로 행동하도록 지정해야한다고 했는데, 그 수치와 등급은 어떤기준으로 어떻게 정하나요?
+    - 변환 설계에 나온 장애 등급을 규정하는 사후 처리 프로세스를 설계하기 이전에, 어떻게 하면 의존성을 최소화할 수 있는 코드 설계를 할 수 있을지를 먼저 고민해야하는거 아닌가요?
+    - 가용성 설계에서 MTBF와 MTTR 값을 100일, 12시간으로 설정했는데, 근거는 무엇이고 경계값에 걸리면 문제있는걸로 봐야하는건가요?
+    - 기획서를 아주 상세히, 요구사항을 꼼꼼하게 기술해야하는 것의 기준이 무엇인가요?
+- 결국 소프트웨어 개발 구현과 설계에 대한 문제는 상황에 따른 How 가 중요한데, 이분은 What 만 나열한 것 같고, 서울대 가려면 공부를 열심히 해야한다 수준으로 답변이라고 생각됩니다

2026/Developer_Principles/taehyoung/4.md

@@ -0,0 +1,14 @@
+# 4장
+
+## 논의 주제
+
+- 개발자 역량을 향상시키기 위한 본인만의 독특한(?) 방법론과 그 경험이 있는지 있다면 경험을 얘기해보면 좋을거 같습니다
+
+## 내 생각
+
+- 이전 3장과 비교했을 때, 완전 극과 극으로 비교되는 글이라고 생각한다 이런 수필류의 책에서 내가 원하는 것은 저자의 경험과 의견인데, 이 4장을 쓰신 저자분은 개발자 성장과 관련 자기가 하고 싶은 주장에 대해서 본인의 과거 사례를 구체적으로 명시하며 설명하고 있다 읽으면서, 글을 통해서 독자에게 좋은 가이드를 주고 싶은 마음, 글 작성에 많은 노력과 진심이 느껴지는 글이였다
+- 그럼에도 불구하고, 초반에 말씀하신 내용 자체는 천편일률적인 조언이였는데(가장 빠르게 배우는 방법은 남에게 가르치는 것이다 등), 개구리를 해부하지 말고, 직접 만들어라 라는 말에는 크게 공감하였다 내가 가장 중요하게 생각하는 것과 일치하기 때문이다 뭐든 개념을 그냥 공부하고 분석하는 것은 실력 향상에 제약이 있다. 무조건 공부한 내용을 구현까지 해보면서, 삽질 과정을 거쳐봐야 내 것이 된다 라고 생각한다.
+- 결국 직접 해보라는 얘기인데, 이건 꼭 개발 공부가 아니더라도 어떤 것이든 해당되는 것 이라 생각 한다
+- GTD 얘기가 나오는데, 나도 쓰고 있는 방법이다 할 일들을 정리할 때, 사용하면 좋을 방법론이다
+- 기록하는 습관에 대해서도 나오는데 이건 정말 중요한 것 같다 한 때, TIL 이 유행한적이 있었는데, 지속적으로 기록을 해야하기 때문에 지속하기가 쉽지 않았던 기억이 난다 지금은 AI를 통해서 TIL 을 작성해야해서 생기는 귀찮음이 많이 없어졌기 때문에, 내 업무 기록을 남기기 더 쉽지 않을까라는 생각이다
+- 마지막으로 여러 답을 찾아서 공유하는 부분이 많이 공감되었다 회사 업무를 하다보면, 어떤 문제를 해결하기 위한 다양한 방법이 나올 수 있다 변수가 많기 때문이다 이때 이런 변수들을 고려해서 문제 해결을 위한 적절한 해결책을 고민하고 결정하는 것이 엔지니어로써 해야하는 일인데, 그전에 다양한 가능성을 확인하고 경우의수를 따지기 위해서 여러 답을 찾아다녀야한다.

2026/Developer_Principles/taehyoung/5.md

@@ -0,0 +1,15 @@
+# 5장
+
+## 논의 주제
+
+- 본인만의 이직의 기준이 있다면 공유해보면 좋을거 같습니다
+
+## 내 생각
+
+- 5장의 주제는 이직이다 이직에 대한 저자의 생각을 한마디로 요약하자면, 흔히 생각하는 연봉상승 등의 외적인 보상을 위한 이직이 아닌, 내가 원하고 바라는 바가 있어서, 이직을 원한다면, 이직을 하라 라는 것이다.
+    - 사람마다 다른게 해석할 수 있는지 여지는 있지만, 나는 위와 같이 생각했다
+- 즉, 결국 내 마음이 가는대로 하라는 것이고, 저자는 본인이 하고픈 것을 하기 위해서 이직이라는 수단을 잘 활용한 것으로 볼 수 있다
+- 개인적으로는 이직에 대한 생각은 외적인 보상의 목적이 아닌, 이직을 꼭 해야만 하는 나만의 확실한 기준이 있을 때, 이직을 하면된다 이다. 그래서 근속연수나 이직 횟수로(너무 적거나, 너무 많거나) 어떤 사람을 판단하는 것은 너무 단면적인 부분으로만 판단하는게 아닌가 싶고, 동의하지 않는다
+- 내 경우도 아직 커리어 중에 이직이 없는데, 이직을 하지 않고있는 이유는 이직을 꼭 해야만하는 사유를 아직 찾지 못하였기 때문이다
+- 좋은 회사임을 판단하는 내 기준은 나보다 뛰어나고 잘하는 동료들이 있는지와 내 의견을 자유롭게 낼 수 있고, 동료들과 소통이 잘 되는지 인데, 이 두가지 모두 현재 회사는 기준치 이상 이라고 생각하고, 오히려 다른 회사를 가면 안좋아지면 안좋아졌지, 현재 회사보다 더 좋을 것 같지 않다고 생각한다. 위와 같은 나의 확실한 기준이 있기 때문에, 자연스레 위 기준이 충족되지 않을 시기에는 이직을 고려해보지 않을까? 생각된다
+- 이직을 하고 싶으면 하면되고, 이직을 안하고 싶으면 안하면된다. 단순히 사회에 만연한 스테레오 타입으로 판단하기 보다, 개인의 취향정도로 생각하면 어떨까 생각된다.