개발자 원칙(확장판) - 박성철 , 강대명 , 공용준 , 김정 , 박미정 , 박종천 , 장동수 , 이동욱(향로) , 이동욱(네피림)

개발자 원칙(확장판) - 박성철 , 강대명 , 공용준 , 김정 , 박미정 , 박종천 , 장동수 , 이동욱(향로) , 이동욱(네피림)

 

이 책은 "좋은 개발자란 누구인가"라는 질문에 기술 스택이 아니라 업(業)의 원칙으로 답하는 책입니다.

 

컬리·카카오·무신사·몰로코·인프런 등에서 일해온 국내 테크 리더 9인이 각자 한 가지 원칙을 에세이로 풀어냈고, 확장판은 여기에 0장 「선배와의 인터뷰」와 각 장 말미의 「출간 후 2년, 그다음 이야기」를 더했습니다.

그래서 이 책은 "무엇을 코딩할까"보다 "어떻게 개발자로 살아갈까"에 가까운, 일종의 직업 정체성 안내서입니다.

---

0장. 선배와의 인터뷰

• 핵심 개념: 확장판에 새로 들어간 부분으로, 9인 저자 전원에게 같은 질문 세 가지를 던집니다. "좋은 개발자(좋은 개발 조직)란 무엇인가", "언제 가장 즐거웠나", "이 일을 계속하게 하는 원동력은 어디서 오는가"입니다.
• 주요 사례/에피소드: 각자의 답이 본문 9개 원칙의 출발점이 됩니다. 박성철은 개발자를 "현실의 문제를 해결하는 사람"으로 규정하고, 강대명은 "더 깊고 자세히, 더 많이 공부하라"는 한 문장으로 자기 태도를 압축합니다.
• 기억할 점: 본문보다 인터뷰가 더 흥미로운 대목이 있을 만큼, 저자들의 사람됨과 현재 직무 변화 자체가 책의 중요한 맥락입니다.

1장. 덕업일치를 넘어서

• 핵심 개념: 박성철(컬리 본부장)은 "좋아함(덕업일치)"은 출발점일 뿐이며, 직업으로서의 정체성을 의식적으로 탐구해야 지속 가능하다고 말합니다. 급여·복지 같은 위생 요인(Hygiene Factors: 부족하면 불만이 되지만 충족돼도 동기가 되지 않는 환경 요소)은 커트라인일 뿐, 진짜 만족은 성장을 자극하는 내재 동기(Intrinsic Motivation: 행동 자체에서 오는 즐거움)에서 나옵니다.
• 주요 사례/에피소드: SK플래닛 → 우아한형제들 → 컬리로 이어진 이직마다 '북극성'처럼 삼은 가치를 점검한 회고가 인상적입니다.
• 기억할 점: 번아웃은 에너지를 무조건 아끼기보다, 회복 탄력성을 키워 총량을 넓히는 방식으로 다스립니다. AI가 코드를 쏟아내는 시대일수록 "어떤 개발자가 될 것인가"라는 질문을 멈추지 말라고 당부합니다.

2장. 오류를 만날 때가 가장 성장하기 좋을 때다

• 핵심 개념: 강대명(레몬트리 기술책임자)은 장애와 오류를 방해물이 아니라 시스템 내부를 깊이 들여다볼 최고의 학습 자원으로 봅니다. AI가 준 정답 코드를 그대로 복사·붙여 넣는 습관은 장기적으로 자생력을 갉아먹는다고 경고합니다.
• 주요 사례/에피소드: 네이버·카카오·위버스의 데이터 플랫폼을 거치며 만난 난해한 오류들을, 짐작이 아니라 프레임워크의 소스 코드(Source Code: 프로그램의 원본 텍스트)를 한 줄씩 읽어 해결한 과정을 보여줍니다.
• 기억할 점: 오류를 고친 뒤에는 반드시 글로 정리해 지식을 내재화해야 합니다. 문제를 만나면 AI에 의존하기 전에 내부 동작을 먼저 추론해보는 훈련이 권장됩니다.

3장. 소프트웨어 디자인 원칙

• 핵심 개념: 공용준(카카오 클라우드 디렉터)은 거창한 패턴 카탈로그가 아니라, 실무에서 반복적으로 통하는 최소한의 설계 원칙(추상화·결합도 관리·확장성)을 정리합니다. 디자인을 곧 '의사소통'으로 보는 관점이 핵심입니다.
• 주요 사례/에피소드: 카카오톡 규모의 트래픽을 운영한 경험을 바탕으로, 비즈니스 요구와 시스템 설계가 충돌하는 전형적 딜레마와 그 조율 과정을 다룹니다.
• 기억할 점: 생성형 AI가 늘수록 사전 설계는 오히려 더 중요해집니다. 다만 거시적 설계를 다루는 만큼, 주니어가 한 번에 소화하기엔 진입 장벽이 느껴질 수 있는 장입니다.

4장. 나의 메이저 버전을 업그레이드하는 마이너 원칙들

• 핵심 개념: 김정(코드스쿼드 대표)은 자신을 소프트웨어에 비유해, 작은 마이너 패치를 꾸준히 쌓으면 메이저 버전이 올라간다고 봅니다. 시맨틱 버저닝(Semantic Versioning: 메이저·마이너·패치로 버전을 체계화하는 규칙)을 성장에 투영한 것입니다.
• 주요 사례/에피소드: "업무 관련 50% / 약하게 관련 30% / 관심사 20%"라는 학습 시간 가계부, 그리고 "개구리를 해부하지 말고 직접 만들어라"는 학습관이 구체적입니다.
• 기억할 점: 결과에 함몰되지 말고 과정을 기록하라(v0.5.0), 정답보다 해답을 찾으라는 조언은 직장인 누구나 바로 적용할 수 있는 자기계발 팁입니다.

5장. 이직, 분명한 이유가 필요해

• 핵심 개념: 박미정(무신사 개발실장)은 이직이 좋은 도구이지만, 분명한 이유와 방향이 없으면 '도망'이 된다고 말합니다. 성장 단계별로 적합한 이직 이유가 다르다는 4단계 프레임을 제시합니다.
• 주요 사례/에피소드: LG CNS → 네이버 → 쿠팡 → 코빗 → 배달의민족 베트남 → 무신사로 이어진 본인의 경로를 단계별 이유와 함께 솔직하게 공유합니다.
• 기억할 점: "왜 떠나는가"보다 "무엇을 얻는가"를 먼저 쓰고, 같은 이유로 두 번 이직하지 말 것. 주인의식을 발휘할 수 없거나 개발 문화에 기여하기 어려울 때가 이직의 적기입니다.

6장. 목표를 달성하는 나만의 기준, GPAM

• 핵심 개념: 박종천(몰로코 헤드 아키텍트)은 막연한 목표가 부르는 실행 지연을 깨기 위해, 개발 사이클을 일상에 접목한 GPAM(Goal·Plan·Action·Measure: 목표·계획·실행·측정) 프레임워크를 제안합니다. S.M.A.R.T.로 목표를 쪼개고 GPAM으로 돌립니다.
• 주요 사례/에피소드: 한컴 → 블리자드 → 넥슨 → 삼성전자 → 몰로코로 이어진 30여 년 경력, 그리고 '개발자의 7가지 고민'을 GPAM으로 분해하는 워크북식 적용이 실용적입니다.
• 기억할 점: 측정(Measure)이 빠진 목표 관리는 결국 추측이 됩니다. 분기마다 한 사이클을 돌리는 것만으로도 정체를 깰 수 있습니다.

7장. 프로덕트 중심주의

• 핵심 개념: 이동욱(네피림, 당근 엔지니어)은 개발자의 장기 성장 단위가 '기술 스택'이 아니라 '내가 끝까지 만든 프로덕트(Product: 완성된 제품)'라고 강조합니다. 그 프로덕트가 꼭 회사 업무일 필요도 없습니다.
• 주요 사례/에피소드: 플러터(Flutter) 학습을 예로, "문법책을 완독한다"는 추상적 계획과 "내 여행 기록 앱을 시장에 배포한다"는 제품 중심 계획이 만들어내는 결과물의 밀도 차이를 대조합니다.
• 기억할 점: 포트폴리오를 '기능'이 아니라 '완성된 프로덕트' 단위로 정리하세요. 완벽한 준비로 망설이기보다 빠르게 출시하고 반복 개선하는 감각이 필요합니다.

8장. 제어할 수 없는 것에 의존하지 않기

• 핵심 개념: 이동욱(향로, 인프랩 CTO)은 코드 설계든 이직이든 조직 매니징이든, 내 힘으로 제어할 수 없는 외부 변수에 의존하면 시스템이 깨지기 쉽다고 말합니다. 외부 의존을 줄일수록 견고해집니다.
• 주요 사례/에피소드: 많은 기업이 주민등록번호를 데이터베이스의 기본 키(Primary Key: 레코드를 고유하게 식별하는 키)로 삼았다가, 수집 금지법 개정으로 시스템 전체를 갈아엎어야 했던 사례가 대표적입니다.
• 기억할 점: 도메인 핵심 로직은 두텁게, 외부 통신·UI는 모킹(Mocking: 테스트용 가짜 객체로 격리하는 기법) 등으로 얇게 격리하세요. 커리어 결정도 "내가 제어할 수 없는 것"을 먼저 적어보고 시작하면 좋습니다.

9장. 달리는 기차의 바퀴를 갈아 끼우기

• 핵심 개념: 장동수(수수한기술 대표)는 운영 중인 서비스를 멈추지 않으면서 기술 부채를 점진적으로 갚는 현실적 리팩토링 철학을 다룹니다. "은탄환은 없다"는 인정에서 출발합니다.
• 주요 사례/에피소드: 세계 최초의 웹 기반 오피스 'Thinkfree Office Live' 개발, 그리고 패스트캠퍼스에서 60여 명 개발 조직을 맨땅에서 구축한 경험이 비유에 무게를 더합니다.
• 기억할 점: 처음부터 100점을 노리느라 일정을 어기기보다, 기한 내 80~90점으로 확실히 동작시키고 점진 개선하세요. 발견했을 때보다 한 단계 깨끗하게 두고 떠나는 보이스카우트 규칙이 핵심 습관입니다.

---

이 책을 관통하는 메시지는 분명합니다.

개발자의 수명을 결정하는 것은 계속 바뀌는 기술 스택이 아니라, 시대를 관통하는 단단한 원칙이라는 것입니다.

9인의 원칙은 코딩을 넘어 목표 관리와 조직 운영으로까지 확장됩니다.

특히 확장판의 추가분은 AI를 핑계로 기존 원칙을 폐기하지 않고, 오히려 설계·학습·문제 정의의 중요성을 더 강하게 만든다는 점에서 책의 신뢰도를 높입니다.

 

바로 적용해볼 만한 행동 포인트

• 장애를 겪으면 24시간 안에 원인 기록(RCA)을 남기고, 소스 코드 레벨까지 직접 확인한다.
• 구현 전 1페이지짜리 설계 문서를 먼저 쓴다.
• 분기마다 GPAM으로 개인 목표를 재설정하고 '측정' 항목을 반드시 넣는다.
• 이직을 검토할 때 "왜 떠나는가"보다 "무엇을 얻는가"를 먼저 적는다.
• 의사결정마다 통제 가능한 것과 불가능한 것을 분리해 적어본다.

---

추천 독자

• 연차에 비해 성장이 정체돼 돌파구를 찾는 3~7년 차 주니어·미들 개발자
• 생성형 AI로 직업 정체성에 혼란을 느끼는 소프트웨어 직군
• 팀장 승진을 앞둔 시니어, 혹은 조직을 갓 꾸리는 스타트업 초기 CTO

마무리 평

강점

• 한 권에서 컬리·카카오·무신사·몰로코의 의사결정 스타일을 비교할 수 있는 다관점 자극.
• GPAM, "제어할 수 없는 것에 의존하지 않기", "프로덕트 중심주의", "밥값 개발자"처럼 한 줄로 외울 수 있는 프레임이 많아, 회고나 1:1 면담에서 바로 인용하기 좋습니다.
• 같은 저자가 직접 쓴 '출간 후 2년' 후기로 원칙을 시간 검증한 구성.

아쉬운 점

• 저자 대부분이 국내 IT 대기업·유니콘 출신이라, SI·금융 같은 도메인과는 거리감이 있습니다.
• 챕터당 25~30쪽의 분량 제약 탓에 사례가 단편적으로 끝나는 장이 있고, 챕터 간 문체·깊이 편차도 느껴집니다.
• AI 시대 대응이 주로 인터뷰와 후기 코너에 분산돼 있어, 본문 9개 원칙 자체가 AI를 정면으로 다루지는 않습니다.
• 시니어에게는 새로운 기술 지식이라기보다 "이미 알지만 정리하지 못한 원칙의 재문장화"에 가깝습니다.

최종 평가 ★★★★☆

 

한국 개발 조직의 실제 언어로 쓰인 드문 커리어 원칙집입니다.

 

성장 방향을 정리하려는 3~7년 차나 예비 리드라면 강하게 추천하고, 깊은 아키텍처·테스트 전략을 찾는 시니어라면 보조 텍스트로 곁들이길 권합니다.