[책 리뷰] 개발자 원칙

읽게 된 계기

개발자 커뮤니티를 운영하시는 분과 대화를 나누던 중, 이 책을 추천받게 되었다. 평소에도 혼자 공부하면서 ‘어떻게 성장해야 할까’라는 막연한 고민을 자주 하던 터라, 선배 개발자들의 실제 경험과 조언이 담긴 책이라는 점에서 흥미가 생겼다. 단순한 기술서가 아니라, 각자가 겪은 현실과 그 속에서 길어 올린 원칙들을 이야기하는 책이라는 점이 마음에 들었다. 가볍게 펼쳤던 책이었지만, 예상보다 훨씬 많은 생각과 공감을 남겨주었다.
이 책은 총 9명의 개발자들이 자신만의 철학과 경험을 바탕으로 써 내려간 글을 모은 형태다. 글을 읽으며 적어둔 메모들을 바탕으로, 기억에 남았던 내용과 개인적인 생각들을 정리해보고자 한다.

1. 박성철 - 덕업일치, 쓸모 있는 소프트웨어를 만들자

프로그래머는 단순히 코드만 잘 짜는 사람으로 머무를 수 없다. 프로젝트를 하다 보면 코드뿐 아니라, 그것이 왜 필요한지 설명해야 하고, 이해관계자를 설득해야 하며, 때로는 협상하고 갈등을 조율해야 하는 경우도 많다. 결국, 소프트웨어 개발은 혼자만의 일이 아닌 팀플레이라는 점을 늘 염두에 둬야 한다. 또한 개발 동기에 대해 흥미로운 비유를 사용했다. 동기를 스칼라(Scalar)로 생각하지 말고 벡터(Vector)로 생각하자. 단순히 '열정'이라는 크기만으로는 부족하고, 명확한 방향성을 가진 동기만이 지속가능한 에너지가 된다는 것이다.

요즘은 AI가 코드 작성에서 점점 더 많은 비중을 차지하면서, 개발자의 역할도 단순히 코드를 잘 짜는 수준을 넘어서는 방향으로 변화하고 있다고 느낀다. 이제는 ‘어떤 문제를 해결할 것인가’, ‘어떤 방식으로 접근할 것인가’처럼 더 큰 맥락에서의 판단과 방향 설정이 훨씬 더 중요해졌다고 느낀다. 협업 과정에서도 설득력 있는 커뮤니케이션 능력, 빠른 의사결정, 자기 주도적인 자세가 필수라는 걸 몸소 체감하고 있다.
그런 점에서 저자가 말한 “동기를 스칼라가 아니라 벡터로 생각하라”는 비유는 특히 인상 깊었다. 단순히 열정을 쏟는 것만으로는 부족하고, 분명한 방향이 있을 때 그 에너지가 비로소 의미를 가진다는 말에 깊이 공감했다. 이 글은 내가 개발자로서 어디로 가고 있는지, 그리고 어떤 방향으로 성장해 나가고 싶은지를 다시 한 번 고민해보는 좋은 계기가 되었다.

 

2. 강대명 - 오류를 만날 때가 가장 성장할 수 있을 때

에러는 피할 수 없는 것이며, 오히려 가장 빠르게 성장할 수 있는 기회가 된다. 첫 번째 원칙은 에러가 발생했을 때 반드시 소스 코드 레벨에서 그 원인을 파악하는 것이다. 단순히 에러 메시지를 보고 넘어가지 말고, 내부 동작을 들여다보며 왜 그런 결과가 나왔는지 구조적으로 이해해야 한다. 두 번째 원칙은 그 경험을 글로 남겨 공유하는 것이다. '부끄러워하지 말고, 오히려 기록을 통해 스스로도 성장할 수 있다'는 점을 강조했다.

에러가 나면 예전에는 당황하거나, 급하게 GPT를 통해 해결하는 데만 집중하곤 했다. 하지만 요즘은 에러가 발생하면 그 원인을 이해하려고 노력하는 편이다. 코드 레벨에서 원인을 파악하는 습관이 쌓이다 보니, 이제는 “어디쯤에서 문제가 생겼겠구나” 하고 대략적으로 짐작할 수 있게 된 것 같다. 또 내용을 글로 정리하고 공유하는 과정에서 한 번 더 머릿속에 넣게 되니, 기억에도 더 오래 남고 학습 효과도 훨씬 크다고 느낀다. 그래서 요즘은 사소한 내용이라도 틈틈이 노션이나 블로그에 정리해두려고 한다.

 

3. 공용준 - 소프트웨어 디자인 법칙

소프트웨어를 개발하는 데 있어 디자인, 즉 설계는 단순한 문서 작업이 아니라 문제 해결의 첫걸음이다. 그 시작점은 ‘요구사항’을 정확히 이해하고 정리하는 데 있다. 사용자의 니즈를 파악하는 것뿐 아니라, 요구사항에서 암묵적으로 기대하고 있는 기능이나 제약조건까지 포착하는 능력이 중요하다. 이러한 세세한 요구사항을 구조화하고, 이를 바탕으로 설계하는 습관은 실전에서 강력한 기반이 되어준다.

읽으면서 내용이 다소 어렵고 쉽게 와닿지 않았다. ‘이건 내가 아직 실무 경험이 부족해서 더 어렵게 느껴지는구나’라는 생각이 들었다. 요구사항을 문서로 구체화해본 경험이 많지 않다 보니, 저자의 조언이 낯설게 다가왔다. 특히 암묵적인 요구사항을 인지하는 능력은 단기간에 생기는 게 아니라, 실제 협업을 통해 계속 훈련하고 쌓아가야 할 역량이라는 점을 새삼 느꼈다.

 

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

개발자는 평생 학습이 기본인 직업이다. 단순히 무작정 공부하는 것이 아니라, 자신의 성장 방향을 설정하고, 현재 속도를 파악하며, 그 속도를 적절히 유지하는 것이 중요하다. 자신의 한계 속도를 넘기면 오히려 실수가 잦아지고 회복력이 떨어질 수 있다. 또 중요한 원칙 중 하나는 ‘의도적으로 낯선 방식’을 선택하는 것이다. 익숙한 방식은 안전하지만, 진짜 성장은 낯선 환경 속에서 나온다. 이미 만들어진 구조나 코드를 분해하고 분석해보는 것도 매우 효과적인 학습 방법이다.

‘의도적으로 낯선 방식을 선택하라’는 조언이 특히 기억에 남았다. 나도 모르게 익숙한 프레임워크나 기술에만 의존하고 있었던 건 아닐까 하는 생각이 들었다. 새로운 것을 시도하면 시행착오가 생기기 마련인데, 요즘은 AI를 활용하면서 그런 시행착오조차 피하려 했던 것 같아 스스로를 돌아보게 됐다. 학습한 내용을 기록하고, 공유하며, 피드백을 주고받는 문화를 만들자는 말에도 깊이 공감했다. 개발은 혼자서만 하는 작업이 아니라, 다양한 사람들과 의견을 나누고 함께 공부할 때 훨씬 더 빠르게 성장할 수 있다는 걸 느꼈다.

 

5. 박미정 - 이직, 분명한 이유가 필요해

이직은 단순한 탈출구가 되어선 안 된다. 오히려 자신이 어떤 방향으로 성장하고 싶은지, 어떤 환경에서 일하고 싶은지를 명확히 하는 계기가 되어야 한다. 특히 개발자에게는 ‘조직 문화’가 매우 중요한데, 협업 방식이나 피드백 구조, 학습을 장려하는 분위기 등이 모두 성장에 직결된다. 환경이 바뀌면 학습 곡선도 달라지고, 자신이 몰랐던 능력을 발견할 수도 있다.

아직 취업을 하지 못한 상태라 이직을 고민할 단계는 아니지만, 이 글을 읽으면서 언젠가는 그런 상황을 마주할 수도 있겠다는 생각이 들었다. 단순히 ‘지금 일이 힘들다’는 이유만으로 회사를 옮기기보다는, 성장의 관점에서 어떤 환경이 나에게 더 도움이 될지를 고민하는 자세가 필요하다는 점이 인상 깊었다. 조직 문화를 중요하게 바라보는 기준도 생긴 것 같아 의미 있었고, 앞으로 어떤 조직이 나에게 잘 맞을지 스스로 탐색해보는 과정도 중요하다는 걸 느꼈다. 그동안은 막연히 “연봉을 올리기 위해 이직한다”는 생각이 강했는데, 이 글을 통해 그 시선을 다시 생각해보게 됐다.

 

6. 박종천 - GPAM: 목표를 달성하는 나만의 기준

목표는 그 자체로는 의미가 없다. 그것이 실현 가능한 계획으로 이어지고, 실행되고, 나중에 평가될 수 있어야 비로소 가치가 생긴다. 그래서 그는 GPAM이라는 목표관리 원칙을 제시했다: Goal(목표) - Plan(계획) - Action(실행) - Measure(평가). 이 네 단계를 모두 충족하는 목표가 진짜 ‘쓸모 있는’ 목표다. 또한 SMART 방법론(구체적이고, 측정 가능하며, 실행 가능하고, 현실적이고, 기한이 있는 목표 설정법)을 활용하면 목표를 더 명확하게 만들 수 있다.

“취업을 하자”처럼 막연한 목표를 나도 자주 세우곤 했다. 그런데 이 글을 읽고 나니 왜 그런 목표들이 구체적인 성과로 이어지지 못했는지 이해가 됐다. GPAM과 SMART 방법론은 단지 개발 공부에만 적용할 수 있는 게 아니라, 삶 전반의 목표 설정에도 활용할 수 있는 실용적인 프레임워크라는 점에서 인상 깊었다. 앞으로는 계획 없이 세운 목표는 의미 없다는 생각으로, 작더라도 실행 가능한 목표를 네 가지 관점에서 더 구체적으로 설계해보려 한다.

 

7. 이동욱 - 프로덕트 중심주의

요즘 개발자들은 넘쳐나는 기술 속에서 길을 잃기 쉽다. 이럴 때 가장 중요한 건 ‘무엇을 공부할까’가 아니라 ‘무엇을 만들고 싶은가’라는 질문이다. 프로덕트를 목표로 잡으면 자연스럽게 필요한 기술과 도구가 선별된다. 그리고 기능 구현에만 집착하지 말고, 디테일한 사용자 경험과 완성도를 고민해야 한다. 또한 협업에 대한 자세 역시 중요하다. 혼자 작업하더라도 미래의 나와 협업한다고 생각하고, 기록과 문서화 습관을 들이는 것이 필요하다.

개발을 하면서 고민했던 부분들과 공감되는 이야기들이 많았다. 프론트엔드에서는 스타일링 방식이나 상태 관리 라이브러리처럼 선택지가 워낙 많다 보니, 가능한 한 다양한 기술을 프로젝트에 적용해보려 노력해왔다. 그런데 작업을 하다가도 “기술 스택을 늘리기 위해 쓰고는 있는데, 이게 정말 맞는 걸까?”라는 질문이 계속 떠올랐던 기억이 있다. 이 글을 읽고 나니 기술을 습득할 때 단순히 ‘배운다’에 그치지 않고, ‘어떤 프로덕트를 만들기 위해 필요한가’를 기준으로 접근해야겠다는 생각이 들었다. 또 혼자 공부할 때도 주석을 잘 남기고, 미래의 나를 위해 흐름을 정리하고 기록하는 습관을 들이려는 노력이 필요하겠다고 느꼈다.

 

8. 이동욱 - 제어할 수 없는 것에 의존하지 않기

현실적인 소프트웨어 개발의 목표는 100% 완벽한 품질이 아니라, 정해진 기한 내에 일정 수준의 품질을 안정적으로 구현하는 것이다. 이를 위해서는 자신만의 기준을 정하고, 그 기준에 따라 일관성 있게 코드를 작성하는 태도가 중요하다.
저자는 그중 하나의 기준으로 ‘제어할 수 없는 것에 의존하지 않는 코드’를 제시했다. 예를 들어, 시스템 시간이나 외부 API, 요일 같은 외부 환경 요소에 직접 의존하는 코드는 테스트가 어렵고 예측 가능성도 떨어진다. 따라서 이런 요소들은 함수의 인자로 분리하거나, 모의 객체로 대체하는 방식으로 관리해야 한다고 조언한다.
이 원칙은 단순한 구현 전략을 넘어 개발자의 사고 방식에도 적용된다. 제어할 수 없는 조건에 집착하기보다는, 내가 통제할 수 있는 부분에 집중할 때 비로소 현실적인 해결책을 찾을 수 있다. 빠르게 대안을 선택하고 실행하는 능력 역시, 제어 가능한 요소에 기반해 얼마나 효과적으로 의사결정을 내리느냐에 달려 있다.

“제어할 수 없는 것에 의존하지 말라”는 원칙은 단순히 테스트 가능한 코드를 작성하라는 기술적인 조언을 넘어, 현실에도 적용할 수 있는 개발자의 마인드셋처럼 느껴졌다.
개발을 하다 보면 팀원의 스케줄 변화나 의사 결정 지연처럼, 내가 통제할 수 없는 변수들로 인해 계획이 틀어지는 일이 자주 발생한다. 그럴 때마다 스트레스를 받기보다는, 지금 내가 할 수 있는 일부터 정리하거나, 구조를 먼저 설계해두는 방식으로 대응하는 습관이 훨씬 더 효과적이라는 걸 느끼게 되었다.
이 원칙은 결국 불확실성을 줄이고, 일관성을 유지하며, 내가 제어할 수 있는 부분에 집중하는 태도와 연결되어 있다. 앞으로도 어떤 문제를 마주할 때, ‘제어 가능한 것부터 먼저 움직이자’는 관점은 현실적인 해결책을 찾는 데 있어 큰 도움이 될 것 같다.

 

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

좋은 코드는 읽기 쉬워야 하며, 설명 없이도 의도가 자연스럽게 드러나야 한다. 이를 위해 설계와 변수명, 함수명에 신경 써야 하고, 불필요한 주석보다는 잘 작성된 테스트 코드가 더 효과적인 설명서가 될 수 있다.
많은 개발자들이 성능 최적화에 집착하는 경향이 있는데, 저자는 먼저 ‘잘 동작하는 코드’를 만드는 것이 가장 중요하다고 말한다. 실제로 실행되지도 않을 코드를 지나치게 최적화하려는 것보다, 안정적인 구현 이후에 점진적으로 개선하는 편이 더 현명하다.
또한 추상화는 유연성을 높이기 위한 수단이지, 그 자체가 목적이 되어선 안 된다. SOLID 원칙이나 클린 코드를 맹목적으로 따르기보다는, 단순하고 이해하기 쉬운 코드가 더 좋은 코드일 수 있다는 점을 강조한다.
코딩은 글쓰기와 같기 때문에 좋은 코드를 많이 읽고 코드 리뷰를 경험하는 것이 중요하다. 특히 AI가 코드를 작성해주는 시대에는, AI가 생성한 코드를 이해하고 판단할 수 있는 기준을 갖추는 것이 개발자의 핵심 역량이 될 수 있다.

개발자들이 추상화의 함정에 빠진다는 이야기에서 특히 공감이 많이 됐다. 나 역시 객체지향 개념을 깊이 이해해보려 하던 시기에, 더 유연한 구조를 만들겠다는 욕심으로 무리하게 추상화를 시도했던 경험이 있었다. 그런데 오히려 중요한 기능 구현보다 구조에만 매달리게 되면서, 본질을 놓치고 있었다는 걸 뒤늦게 깨달았다. 이 글을 통해 추상화는 어디까지나 ‘목표에 도달하기 위한 도구’이지, 그것 자체가 목적이 되어선 안 된다는 점을 다시 새기게 됐다.
또한 ‘잘 동작하는 코드’를 먼저 만들고, 이후에 리팩토링을 통해 개선해나가는 방식이 훨씬 실용적이라는 조언도 실제 경험과 맞닿아 있었다. 완벽함을 추구하다 보면 정작 중요한 걸 놓치기 쉽다는 걸 몸소 느껴왔기 때문에, 더욱 와닿았다.
그리고 요즘처럼 AI가 코드 작성을 도와주는 시대에는, 단순히 코드를 작성하는 능력보다도 좋은 코드를 식별하고 판단할 수 있는 기준을 갖추는 것이 더 중요하다는 말에도 크게 공감했다. 결국 그런 기준은 좋은 코드를 많이 읽고, 다양한 실전 경험을 통해 축적된 감각에서 비롯된다는 점을 다시 확인하게 되었다.

 

마무리

이 책은 개발자로서 가져야 할 자세, 마인드셋, 그리고 앞으로 나아갈 방향에 대해 다시 한번 생각해보게 해주었다. 각 챕터마다 전해지는 조언들은 단순한 팁을 넘어, 오랜 시간 쌓인 고민과 경험에서 우러나온 이야기들이라 더 깊게 다가왔다.
개발자로서 기술을 어떻게 익혀야 할지, 어떤 태도로 일과 커리어를 대해야 할지 막연했던 부분들이 이 책을 통해 조금씩 정리되는 느낌이었다. 무엇보다 ‘어떻게 성장할 것인가’라는 질문에 대해 각자 다른 방식으로 답을 제시해주는 점이 인상 깊었다.
프레임워크나 언어처럼 빠르게 바뀌는 기술보다, 개발자로서 오래 살아남기 위해 필요한 생각과 태도에 대해 고민하고 있다면 이 책이 좋은 방향을 잡아줄거라 생각된다.
특히나 개발을 시작한지 얼마안된 나같은 주니어 개발자들에게는 큰 도움이 되는 것 같아 추천한다.