devholi***
2026-03-29

개발의 무게를 덜어내고 본질만 남기다. 실용주의 프로그래머 데이비드 토머스가 제안하는 지속 가능한 코딩을 위한 미니멀리즘
한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다.

책의 제목 (미니멀리즘)처럼, 제품에 여러 기능들이 추가되면 좋을 것 같은 현상은 결국 미래의 기술 부채가 된다는 사실을 명확히 알려주고 있습니다.
1인 개발자라면 MVP 를 만드는 과정에서 AI 챗봇, OAuth 로그인 등이 그 예가 될 수 있을 것이고, 회사에서도 실제 고객이 사용할 기능에 비해 과다하게 기능을 적용해보자고 논의가 나올 수도 있겠죠.
그러지 않는 것이 가장 좋겠지만, 꼭 이 기능을 만들고자 한다면 적어도 "고객에게 어떤 가치를 주기 위해" 필요한 기능이었다는 사실을 반드시 기억하는 게 맞겠다라는 생각이 들었습니다.
일례로, 회사에서 특정 기능을 리팩터링하려고 했을 때 이 함수를 어떠한 요구사항이 있어 만들게 되었는지 기억하는 데 오래 걸렸던 부분이 있었습니다. 요구사항을 제대로 기억하지 못하니 어떤 부분을 제거해도 괜찮을 지 파악하기 어려웠고, 그에 따른 시간적 비용을 치르게 된 적이 있었습니다.
비단 개발자로서 리팩터링 비용을 최적화하기 위해서 뿐만 아니라, 고객이 겪고 있는 핵심 문제를 풀기 위해서라도 가치 전달 중심의 사고법 (책에서의 "필요 주도 개발")을 훈련해야겠다는 생각이 들었습니다. 100가지 기능이 존재하는 제품을 만들더라도 고객이 겪고 있는 핵심 문제 하나를 풀지 못한다면 고객이 우리의 제품을 사용할 이유가 없을테니까요.

회사에서 간혹 회의가 매우 많이 몰려 있는 날에는 정규 시간 (퇴근 시간 전까지)에 회의만 하고, 그 후에야 본연의 업무를 할 수 있었던 적도 있었습니다. 그래서 그런지 팀 내에서도 회의에 대한 의견 공유가 많이 있었고, 여러 합의를 했던 적이 있었습니다.
책을 읽으면서 팀에서 한 합의와 비슷한 실천법이 많이 나와서 신기하기도 하고, 한편으로는 여느 회사/팀이나 모두 비슷한 문제를 겪고 있구나라는 생각도 들었습니다.
대표적으로는 회의의 주제에 따라 반드시 참석해야 할 사람이 아니면 회의에는 참석하지 않되, 반드시 "공유"를 통해 팀의 전체적인 방향성을 맞추는 게 효율성과 회의를 함께 챙길 수 있는 방법이라고 생각합니다.

저는 만 1년차 주니어 개발자이기도 하고 요즘 회사 차원의 단체 집중 프로젝트를 하면서 불편함을 느꼈을 때 그걸 숨기지 못하고 가끔씩 드러내는 편이었는데, 아무리 "기분이 태도가 되지 말자" 고 스스로 되뇌어도 잘 고쳐지지 않았습니다.
이 책에서는 다른 사람들과 갈등이 있을 때 원만하게 해결할 수 있는 방법과 미리 갈등을 차단할 수 있는 방법에 대해 알려주고 있습니다.
그 중 가장 적용하기 쉬웠던 건 상대방의 입장에서 대화를 할 수 있도록 미리 생각해 두는 것인데, 대표적으로 비개발 직군들과 진행 상황에 대해 짧게 공유할 때 (또는 문제 상황 공유) 기술적인 내용보다는 비유를 통해 쉽게 알려주어야겠다고 연습하는 것 입니다.
회사에 입사한 지 얼마 되지 않았을 때는 그동안 개발자들끼리만 사이드 프로젝트를 했어서 비유의 중요성을 몰랐는데, 실전에서 매우 효과가 좋은 방법을 알게 되어 유익했습니다.

생각보다 너무 좋은 내용에 앉은 자리에서 한번에 바로 끝까지 읽었습니다. 그동안 한빛미디어의 책을 읽으면서 여러 날에 걸쳐 책들을 읽곤 했는데, 이 책은 내용이 그리 길지 않기도 하고 글의 구성도 실전 적용법 형태로 간략하게 여러 개가 묶여있는 구조라 읽기 쉬웠습니다.
끊임없는 회의의 연속으로 업무를 진행하는 데 어려움을 겪고 있거나, 회사 동료를 대하는 데 어려움이 있어 소프트 스킬을 늘리고 싶으신 분들에게 본 책을 추천합니다. 또한, 책을 읽고 나서 두고 두고 시간이 날 때 마다 이 책의 내용을 잘 실천하고 있는 것이 맞는지 꼭 회고해보는 시간을 가지면 좋겠습니다.