ThinkAboutSoftware · jongfeel · May 27, 2026 · May 27, 2026 · May 27, 2026 · May 27, 2026
diff --git a/2026/Developer_Principles/jongfeel/Chapter03_소프트웨어_디자인_원칙.md b/2026/Developer_Principles/jongfeel/Chapter03_소프트웨어_디자인_원칙.md
@@ -0,0 +1,38 @@
+## Summary
+
+- https://github.com/jongfeel/BookReview/issues/1735
+
+## Review
+
+- https://github.com/jongfeel/BookReview/issues/1735#issuecomment-4544781478
+
+## 리뷰
+
+소프트웨어 디자인 원칙이라면 우선 내가 구현 담당인지 리더인지 부터 파악하는 게 좋다고 본다.
+
+구현 담당이면 소프트웨어 디자인에 대해 알아볼 필요가 있고, 왜 해야 하는지 그리고 왜 좋은지를 경험해 볼 수 있으면 좋다.
+구현이라면 설계해 둔 내용을 파악해 코드 작성이나 이미 구현된 내용에 대한 버그 수정일텐데
+그런 작업을 하고 있으면 설계에 대한 내용을 이해하기 어렵기 떄문이다.
-그런 작업을 하고 있으면 설계에 대한 내용을 이해하기 어렵기 떄문이다.
+그런 작업을 하고 있으면 설계에 대한 내용을 이해하기 어렵기 때문이다.
-그런 작업을 하고 있으면 설계에 대한 내용을 이해하기 어렵기 떄문이다.
+그런 작업을 하고 있으면 설계에 대한 내용을 이해하기 어렵기 때문이다.
+그래서 AI가 있기 전에도 구현 전에 설계를 할 수 있도록 나도 팀에 원칙을 세운 적이 있고 하고 나서야 알게 되는 것들이 있다고 피드백을 받았던 적도 있다.
+
+리더라면 소프트웨어 디자인에 대해 많이 공부하고 내가 속한 도메인, 내가 속한 팀의 특성을 파악해 최적의 방법으로 적용하도록 노력해야 한다. 
+그렇지 못한 리더라면 리더의 자질이 부족하다고 볼 수 있다.
+리더는 설계 능력과 더불어 우리 팀에 필요한 설계 요소, 책에서 얘기하는 17개의 항목에서도 뭐가 더 중요성이 있는지 파악하고 실천할 수 있도록 리딩해야 하는 책임이 있다.
+
+AI가 설계 검증은 잘 해줄 수 있어도, 실제 설계 능력까지 발휘해야 하는 건 아직 개발자의 몫일 수 있다.
+어쩌면 AI가 설계도 해줄 수 있다고 하더라도, 왜 이런 설계가 필요한지에 대한 이유는 사람이 설명할 수 있어야 한다고 보는게 2026년 5월 기준으로는 아직 유효하다고 본다.
+
+## 논의주제 
+
+사실 제가 리뷰에도 적었지만 저는 구현인지 리더인지 구분하고 디자인 원칙에 대해 접근하는 방법에 대해 얘기했습니다.
+설계 원칙을 만들어야 하는 건 리더의 몫이고, 설계를 하고 구현을 담당하는 개발자는 설계에 대한 경험을 쌓을 수 있는 좋은 기회라는 걸 얘기한 것입니다.
+
+저자의 17가지 설계 원칙은 이미 기존에 있던 원칙을 자신만의 기준으로 다시 정리해서 설명해 주고 있는데 여태까지 읽었던 다른 저자와 달리 경험담 보다는 기술 서적의 내용의 요약 정리에 가깝다는 느낌이 들었습니다.
+
+그래서 논의 주제는 이 분의 17가지 원칙에서 받아들이기 어려운 원칙이나 이해가 안됐던 원칙을 얘기해 보면 어떨까 합니다.
+
+저는 미적 설계 부분이 이전에 읽었던 수많은 책들 중에는 없었던 내용이었는데 특이하게도 ISO 9241-12 로 등록되어 있는 표준이더군요.
+그런데도 그 표에 나와 있는 수치화 점수가 얼마나 의미가 있나 싶을 정도로 미심적인 부분이 많았습니다.
-그런데도 그 표에 나와 있는 수치화 점수가 얼마나 의미가 있나 싶을 정도로 미심적인 부분이 많았습니다.
+그런데도 그 표에 나와 있는 수치화 점수가 얼마나 의미가 있나 싶을 정도로 미심쩍은 부분이 많았습니다.
-그런데도 그 표에 나와 있는 수치화 점수가 얼마나 의미가 있나 싶을 정도로 미심적인 부분이 많았습니다.
+그런데도 그 표에 나와 있는 수치화 점수가 얼마나 의미가 있나 싶을 정도로 미심쩍은 부분이 많았습니다.
+그게 직관의 영역이 맞지 않나 싶은데 표에는 객관적 지표인 - 정보 체계는 80점, 코드화는 60점 이상 달성한다 라는 말이 이상하게 들릴 정도였습니다.
+ISO 9241-12를 검색해 보면 바로 알 수 있는데 그 기준이 1998년에 만들어진 표준입니다.
+무려 28년전 기준으로 소프트웨어 원칙을 논하기에는 너무 무리수를 두지 않았나 하는 아쉬움이 많이 드네요.
diff --git a/2026/Developer_Principles/jongfeel/Chapter04_나의_메이저_버전을_업그레이드하는_마이너_원칙들.md b/2026/Developer_Principles/jongfeel/Chapter04_나의_메이저_버전을_업그레이드하는_마이너_원칙들.md
@@ -0,0 +1,16 @@
+## Summary
+
+- https://github.com/jongfeel/BookReview/issues/1744
+
+## Review
+
+- https://github.com/jongfeel/BookReview/issues/1744#issuecomment-4550580432
+
+## 리뷰
+
+기록하기, 돌아보기, 실수하기 등 좋은 얘기들이 많다.
+이 책이 2022년 출판, 즉 2021년 까지의 저자들의 경험을 담고 있다고 했을 때
+중요한 요소는 코드가 아니라 그 코드를 작성하면서 겪는 과정이 중요하다는 2026년에는 더 크게 와 닿는 말이라고 본다.
+
+특히 내가 AI가 있기 전에도 중요하게 생각했던 설계 리뷰에 대한 내용이 언급되서 반가웠다.
-특히 내가 AI가 있기 전에도 중요하게 생각했던 설계 리뷰에 대한 내용이 언급되서 반가웠다.
+특히 내가 AI가 있기 전에도 중요하게 생각했던 설계 리뷰에 대한 내용이 언급돼서 반가웠다.
-특히 내가 AI가 있기 전에도 중요하게 생각했던 설계 리뷰에 대한 내용이 언급되서 반가웠다.
+특히 내가 AI가 있기 전에도 중요하게 생각했던 설계 리뷰에 대한 내용이 언급돼서 반가웠다.
+설계 리뷰를 통해 의견을 공유하고 요구사항에 맞는 설계에 있어서 리뷰가 가능하다는 점은 시스템을 개발하는데 있어서 중요한 능력이라고 보기 때문이다.
diff --git a/2026/Developer_Principles/jongfeel/Chapter05_이직_분명한_이유가_필요해.md b/2026/Developer_Principles/jongfeel/Chapter05_이직_분명한_이유가_필요해.md
@@ -0,0 +1,12 @@
+## Summary
+
+- https://github.com/jongfeel/BookReview/issues/1745
+
+## Review
+
+- https://github.com/jongfeel/BookReview/issues/1745#issuecomment-4550727469
+
+## 리뷰
+
+예전에 읽었을 때도 느꼈는지 모르겠는데 이직의 이유는 내가 무엇을 하고 싶은가가 중요한 것이라고 본다.
+그리고 여러 다양한 경험을 해보는 건 좋다는 것에 동의한다. 그게 특히 즐겁게 일하면서 삶을 살 수 있는 방법이라면 더 그래야 한다.