From 5191191af9ce4e6109a63699aa25f67a87db8c9f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=EC=9D=B4=EA=B7=BC=EC=A3=BC?= Date: Fri, 12 Jun 2026 20:27:18 +0900 Subject: [PATCH 1/2] Create Chapter_6_to_9.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 목차 작성 --- .../geunju-lee/Chapter_6_to_9.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 2026/Developer_Principles/geunju-lee/Chapter_6_to_9.md diff --git a/2026/Developer_Principles/geunju-lee/Chapter_6_to_9.md b/2026/Developer_Principles/geunju-lee/Chapter_6_to_9.md new file mode 100644 index 00000000..290dce19 --- /dev/null +++ b/2026/Developer_Principles/geunju-lee/Chapter_6_to_9.md @@ -0,0 +1,13 @@ +# 개발자 원칙 독후감 + +## 6 ~ 9장 + +--- + +# chapter 6 - 목표를 달성하는 나만의 기준, GPAM + +# chapter 7 - 프로덕트 중심주의 + +# chapter 8 - 제어할 수 없는 것에 의존하지 않기 + +# chapter 9 - 달리는 기차의 바퀴 갈아 끼우기 From f37eaff9be0542c77178b00dbe6eb3d43789b335 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=EC=9D=B4=EA=B7=BC=EC=A3=BC?= Date: Fri, 12 Jun 2026 21:09:29 +0900 Subject: [PATCH 2/2] =?UTF-8?q?=EB=8F=85=ED=9B=84=EA=B0=90=20=EC=9E=91?= =?UTF-8?q?=EC=84=B1?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 독후감 작성 --- .../geunju-lee/Chapter_6_to_9.md | 42 +++++++++++++++++-- 1 file changed, 38 insertions(+), 4 deletions(-) diff --git a/2026/Developer_Principles/geunju-lee/Chapter_6_to_9.md b/2026/Developer_Principles/geunju-lee/Chapter_6_to_9.md index 290dce19..abcff23e 100644 --- a/2026/Developer_Principles/geunju-lee/Chapter_6_to_9.md +++ b/2026/Developer_Principles/geunju-lee/Chapter_6_to_9.md @@ -4,10 +4,44 @@ --- -# chapter 6 - 목표를 달성하는 나만의 기준, GPAM +# Chapter 6 - 목표를 달성하는 나만의 기준, GPAM -# chapter 7 - 프로덕트 중심주의 +이 장에서는 GPAM(Goal, Plan, Action, Measure)이라는 목표 달성 원칙을 소개한다. 목표를 세우는 것에서 끝나는 것이 아니라, 계획을 세우고 실행한 뒤 결과를 측정하는 과정까지 포함한다는 점이 인상 깊었다. -# chapter 8 - 제어할 수 없는 것에 의존하지 않기 +특히 소프트웨어 개발 사이클과 비교한 설명이 이해하기 쉬웠다. 개발에서도 요구사항을 정의하고, 설계와 구현을 거쳐 테스트와 검증을 수행하듯이 개인의 목표 역시 체계적으로 관리할 수 있다는 점이 공감되었다. -# chapter 9 - 달리는 기차의 바퀴 갈아 끼우기 +책에서 제시한 실천 사례들을 보면서 나 역시 GPAM을 활용할 수 있는 목표를 찾아 적용해 보고 싶다는 생각이 들었다. 예를 들어 새로운 기술을 학습하거나 새로운 사람을 만나는 것처럼 막연하게 생각하던 일들도 GPAM 방식으로 구체화하면 더 꾸준히 실천할 수 있을 것 같다. + +다만 생각해보니 올해 딱히 목표를 세우지 않아서 일단 목표를 세우기로 했다. + +# Chapter 7 - 프로덕트 중심주의 + +이 장에서는 목표를 추상적으로 세우기보다 실제로 만들어낼 결과물(프로덕트) 중심으로 생각해야 한다고 이야기한다. + +예를 들어 "스프링 프레임워크를 공부해야지."라는 목표보다 "스프링으로 간단한 API 서버를 만들어 보겠다."라는 목표가 훨씬 구체적이고 실행 가능하다. 실제 결과물을 만드는 과정에서 자연스럽게 필요한 지식을 익히게 되기 때문이다. + +회사에서 사용하는 프로덕트 중심 사고방식을 개인 생활에도 적용할 수 있다는 점이 흥미로웠다. 나 또한 최근에는 EDA(Event-Driven Architecture)에서 아이디어를 얻어 행동을 연결하는 습관을 만들려고 노력하고 있다. 예를 들어 "밥을 먹으면 바로 식기를 치운다.", "집에 들어오면 바로 씻는다."처럼 특정 행동이 다음 행동의 트리거가 되도록 만들어 미루는 습관을 줄이고 있다. + +### 논의사항 - 이러한 개발 프로세스를 생활에서 사용한 경험이 있으신가요? + +# Chapter 8 - 제어할 수 없는 것에 의존하지 않기 + +이 장에서는 내가 제어할 수 없는 것에 지나치게 의존하면 언젠가 문제가 발생할 수 있다는 점을 강조한다. + +책에서 예시로 든 주민등록번호를 PK로 사용하는 사례가 특히 인상 깊었다. 현재는 문제가 없어 보여도 법이나 정책이 변경되면 시스템 전체에 큰 영향을 줄 수 있기 때문이다. 결국 외부 환경에 의해 변경될 수 있는 값을 핵심 식별자로 사용하는 것은 위험한 설계라는 점을 다시 한번 느꼈다. + +이러한 원칙은 개발뿐 아니라 일상에서도 적용할 수 있다고 생각한다. 내가 통제할 수 없는 요소보다는 직접 관리하고 개선할 수 있는 요소에 집중하는 것이 장기적으로 더 안정적인 선택이라는 점을 배웠다. + +하지만 제어할 수 없는 것에 의존하지 않는 것은 좋지만, 또 너무 의존하지 않기 위해 모든 것을 다 만들려고 하면 일처리가 늦어진다. 예를 들어 다른 스타트업은 외부 tool을 많이 사용하여 더 빠른 서비스 오픈을 할 수 있는 반면, 네이버는 모든 것을 내부적으로 만들어서 사용하려다보니 서비스 오픈 속도가 그만큼 떨어진다. 무엇이 정답인지 정말 모르겠다. + +# Chapter 9 - 달리는 기차의 바퀴 갈아 끼우기 + +이 장은 현실적인 개발 업무와 가장 맞닿아 있는 내용이었다. + +완벽한 시스템을 한 번에 만드는 것보다 우선 동작하게 만들고, 이후 지속적으로 개선하는 접근 방식에 공감했다. 실제 업무에서도 마감 기한이 존재하기 때문에 처음부터 모든 것을 이상적으로 구현하기는 어렵다. + +개인적으로는 코드 리팩터링보다 데이터베이스 변경이 훨씬 어렵다고 느낀다. 코드 수정은 비교적 빠르게 진행할 수 있지만, 데이터베이스 스키마 변경은 기존 데이터 마이그레이션과 운영 환경까지 고려해야 하므로 부담이 크다. + +또한 기술 부채는 시간이 지나면 자연스럽게 해결되는 문제가 아니라, 누군가 의식적으로 관리해야 하는 문제라는 점에도 공감했다. 현재 우리 팀에서는 내가 이러한 개선 작업을 주도하는 편인데, 이를 방치하면 결국 팀 전체의 생산성이 떨어지고 그 영향은 나에게도 돌아온다. 그래서 기능 개발뿐 아니라 지속적인 리팩터링과 구조 개선에도 시간을 투자하려고 노력하고 있다. + +### 논의사항 - 기술 부채에 대해서 다들 어떻게 해결하고 있나요?