'예스24 리뷰어클럽 서평단 자격으로 도서를 제공받고 작성한 리뷰입니다'

동작하기만 한다면 가장 단순하게 만들라 -워드 커닝엄

가장 처음 이 책에 대해 소개하는 글에서 '복합적인 것'과 '복잡한 것'의 차이에 대해 이야기한다. 복합적인 것에는 일정한 구조와 규칙이 존재한다. 하지만 그 구조와 규칙을 무시하기 시작하면 복잡한 상태로 변한다. 이 책을 관통하는 단순함이란 단어는 소프트웨어에만 국한되지 않고 거의 모든 일에 적용된다.

일하는 방식의 단순화, 환경의 단순화, 상호작용의 단순화, 코드의 단순화 이 네가지 파트로 구성된 미니멀리즘 프로그래머는 프로젝트의 군더더기를 제거하고 핵심가치에 집중하는 태도를 강조하며 복합적이지만 복잡하지 않은 프로그래밍을 소개한다.

라이프스타일부터 프로그래밍에 이르기까지 불필요한 부분을 줄이고 중요한 것에 집중함으로 지속 가능성을 영위할 수 있는 미니멀리즘에 대해 다시 한번 생각해보게 되는 계기가 되었다.

#리뷰어클럽리뷰





"한빛미디어 서평단 ＜나는리뷰어다＞ 활동을 위해서 책을 협찬 받아 작성된 서평입니다."

이 책을 펼치기 전까지 나는 '단순함'을 일종의 타협이라고 생각했다. 기능이 많아야 좋은 소프트웨어고, 라이브러리를 잘 활용할수록 숙련된 개발자라는 믿음. 무언가를 더 얹을수록 더 전문적으로 보인다는 착각. 아마 개발을 처음 배울 때부터 나도 모르게 내면화한 편견이었을 것이다. 그 편견을 정면으로 깨부수는 책이 왔다. 『실용주의 프로그래머』의 저자 데이비드 토머스의 신작 『미니멀리즘 프로그래머』다.

저자는 이렇게 묻는다. 11줄짜리 코드를 짜면 끝날 일을 왜 거대한 라이브러리를 설치해서 처리하려 하냐고. 읽는 순간 뜨끔했다. 나 역시 npm install을 입력하는 데 망설임이 없었고, 프레임워크 없이 무언가를 만드는 일을 오히려 비효율이라 여겼으니까. 저자가 진짜 비효율이라고 말하는 건 그 태도 자체다. 필요하지도 않은 복잡함을 끌어안고, 그것을 유지하느라 정작 본질을 잃어버리는 것.

단순함은 기교가 아니라 태도다

책의 핵심 주장은 명확하다. 미니멀리즘은 코드를 짧게 줄이는 기술이 아니라는 것. 저자가 말하는 단순함은 훨씬 더 근본적인 곳에 있다. 프로젝트의 군더더기를 걷어내고 핵심 가치에 집중하는 태도, 변화를 두려워하지 않고 받아들이는 용기다.

책은 네 개의 파트로 나뉜다. 하는 일, 환경, 상호작용, 코드 자체를 각각 단순화하는 방법을 다룬다. 이 구조 자체가 이미 저자의 철학을 반영한다. 단순함은 코드 수준에서만 이루어지는 게 아니라, 개발자의 일하는 방식 전반에 걸쳐 실천되어야 한다는 것이다.

29가지 실천 원칙으로 이루어진 이 책은 읽는 내내 '맞아, 이게 문제였어'라는 감탄과 '이렇게까지 해야 해?'라는 의심이 교차하게 만든다. 그 긴장감이 이 책의 매력이다.

코드 다이어트: 덜어내는 용기

1부의 '코드 다이어트' 챕터는 가장 직접적인 도발로 시작된다. 의존성을 줄이라는 것, 프레임워크를 맹신하지 말라는 것, 기능은 적을수록 좋다는 것.

저자는 라이브러리를 도입하기 전에 마치 '성분표를 꼼꼼히 확인하듯' 점검하라고 말한다. 이 라이브러리가 지금 나에게 정말 필요한가, 유지보수 비용은 얼마나 되는가, 직접 구현하는 게 더 단순하지는 않은가. 질문은 단순하지만 대답하는 과정에서 스스로의 습관을 돌아보게 된다.

'혹시 나중에 필요할지 모른다'는 이유로 추가되는 기능들을 저자는 '미래의 부채'라 부른다. 당장은 자산처럼 보이지만, 결국 유지보수 비용이라는 이자를 영원히 지불해야 한다는 것이다. 얼마나 정확한 비유인지는, 과거에 내가 '언젠가 쓰겠지' 하며 남겨두었다가 결국 아무도 건드리지 않은 코드들을 떠올리면 바로 알 수 있다.

프로젝트 최적화: 회의를 줄이는 것도 개발이다

2장에서 책은 코드를 벗어나 팀과 조직의 단순함을 이야기한다. 팀의 결합도를 낮추고, 회의를 줄이고, 정보가 자유롭게 흐르는 구조를 만들라는 것이다. 처음엔 이 부분이 개발 서적과 어울리지 않는다고 생각했다. 읽다 보면 저자의 의도가 분명히 보인다. 코드의 복잡함과 조직의 복잡함은 본질적으로 같은 문제라는 것. 지나치게 결합된 모듈이 시스템을 취약하게 만들듯, 지나치게 의존적인 팀 구조는 조직을 느리고 경직되게 만든다.

'지긋지긋한 회의 줄이기'라는 소제목은 유독 공감이 갔다. 저자는 회의 자체를 악으로 규정하지 않는다. 목적 없이 반복되는 회의, 결론 없이 끝나는 회의가 팀의 에너지를 어떻게 소진시키는지를 짚는다. 그리고 회의를 줄이는 구체적인 방법 대신, 왜 회의가 많아지는지를 먼저 들여다보게 한다. 증상이 아니라 원인을 다루라는 것, 이 역시 미니멀리즘의 철학과 맞닿아 있다.

환경 자동화: 단순함을 위한 준비

역설적이게도 단순함을 위해서는 처음에 한 번 공을 들여야 한다. 2부는 그 이야기다. 터미널 환경 최적화, 에디터 설정, 개발 장비 세팅 자동화까지. 반복되는 귀찮은 작업들을 자동화해 두면 이후엔 본질적인 일에 집중할 수 있다. '명령어 하나로 배포가 가능한 시스템'이라는 표현이 인상적이었다. 저자는 이를 단순함을 유지하기 위한 최소한의 기반으로 이야기한다. 복잡한 배포 절차, 매번 다른 환경 설정, 누군가의 머릿속에만 있는 암묵지. 이 모든 것이 복잡함의 씨앗이다. 자동화는 그 씨앗이 자라기 전에 뿌리째 뽑는 일이다.

'미래에서 놀고, 과거에서 일하기'라는 챕터 제목은 처음엔 의아했다. 새로운 기술과 도구는 가볍게 실험하되, 실제 업무에서는 검증된 안정적인 도구를 쓰라는 뜻이다. 유행을 쫓는 것과 변화를 받아들이는 것은 다르다. 저자는 그 경계를 '실용성과 기발함을 섞는' 균형감각으로 설명한다.

소프트 스킬: 공감도 단순화할 수 있다

3부는 상호작용의 단순화를 다룬다. 의견 충돌을 제로섬 게임으로 보지 않기, 공감 능력 기르기, 이야기로 설명하기. 얼핏 보면 자기계발서처럼 보이지만, 저자는 이를 철저히 개발자의 언어로 풀어낸다. '사물에도 공감하기'라는 원칙이 흥미로웠다. 코드를 작성할 때 그 코드를 읽을 사람의 입장이 되어보는 것, 시스템을 설계할 때 그 시스템을 사용하는 사람의 맥락을 상상하는 것. 공감은 팀원과의 관계를 부드럽게 만드는 기술이기도 하지만, 더 단순하고 더 올바른 코드를 만드는 기반이기도 하다는 점에서 설득력이 있다.

'이야기 엮기' 원칙도 실용적이다. 복잡한 기술적 내용을 이해관계자에게 설명할 때, 데이터와 논리보다 이야기가 더 강하게 전달된다는 것. 커뮤니케이션 비용을 줄이는 가장 단순한 방법은 결국 상대방이 쉽게 이해할 수 있는 언어로 말하는 것이다.

데이터 주도 개발과 가독성: 코드 단순화의 정수

4부는 가장 기술적이면서도 통쾌한 챕터들로 이루어져 있다. 데이터에 주도권을 넘기고, 테이블로 테스트를 단순화하고, 상태 머신으로 로직을 정리하는 방법들이 나온다. '데이터에 운전대 맡기기'는 특히 공감이 갔다. 복잡한 if-else의 숲을 헤매던 경험은 누구나 한 번쯤 있을 것이다. 조건 분기를 코드로 직접 표현하는 대신 데이터 구조로 끌어내면, 로직은 단순해지고 변경도 쉬워진다. 코드보다 데이터가 다루기 쉽다는 주장은 실제로 해본 사람이라면 고개를 끄덕일 수밖에 없다.

가독성 챕터에서 '주석 달지 않기'는 도발적으로 들릴 수 있다. 주장은 명확하다. 주석이 필요하다는 것은 코드 자체가 의도를 설명하지 못하고 있다는 신호라는 것. 좋은 이름, 좋은 구조, 좋은 흐름이 주석보다 훨씬 강한 가독성을 만든다. '옆으로 긴 코드보다 아래로 긴 코드가 낫다', '관련된 코드는 한곳에 모으기', '마지막에 쉼표 남겨두기' 같은 원칙들은 작고 구체적이지만, 코드 리뷰 현장에서 바로 써먹을 수 있는 것들이다. 이런 디테일에서 저자의 현장 경험이 느껴진다.

AI 시대일수록 단순함이 무기다

마지막 챕터에 이르면 왜 이 책이 지금 나왔는지가 분명해진다. AI가 코드를 생성하는 시대일수록, 개발자의 진짜 가치는 더 많이 만드는 것이 아니라 불필요한 것을 걷어내는 판단력에 있다. AI는 코드를 빠르게 만들어준다. 그런데 그 코드가 정말 필요한지, 이 복잡함이 감당할 만한지를 판단하는 것은 여전히 개발자의 몫이다. AI가 쏟아내는 코드 속에서 방향을 잃지 않으려면 단순함이라는 나침반이 필요하다는 저자의 주장이 공허하게 들리지 않는 것은, 책 전체가 그 나침반을 구체적인 방법으로 제시하고 있기 때문이다.

이 책을 추천하는 사람들

모든 개발자에게 권하고 싶지만, 특히 이런 분들에게 강하게 추천한다.

복잡해진 코드베이스 앞에서 무력함을 느끼는 개발자. 기능을 추가할수록 프로젝트가 무거워진다는 걸 알면서도 멈추지 못하는 개발자. AI 도구를 쓰기 시작하면서 코드의 방향을 잃은 기분이 드는 개발자. 개발이 언제부터인가 즐겁지 않아진 개발자.

이 책은 답을 주기보다 질문을 던진다. 지금 이 코드가 정말 필요한가, 이 복잡함은 가치가 있는가, 나는 지금 무엇을 위해 개발하고 있는가. 그 질문들이 불편하게 느껴진다면, 이 책이 가장 필요한 시점이라는 뜻일 것이다. 단순함은 쉬운 길이 아니다. 더 많은 사고와 용기를 요구한다. 하지만 그 끝에는 저자가 말하는 '프로그래밍의 즐거움'이 다시 기다리고 있을지 모른다.

오늘도 찾아주셔서 감사합니다.

출처: https://patiencelee.tistory.com/1273 [PatienceLee:티스토리]

#나는리뷰어다 #미니멀리즘프로그래머 #한빛미디어

책에서는 YAGNI, DRY, KISS 같은 익숙한 원칙을 다시 짚으면서, 특히 미리 설계하거나 불필요한 추상화를 도입하는 선택이 어떻게 복잡성을 키우는지를 설명합니다. 단순히 “코드를 줄이자”가 아니라, 필요해지기 전까지 만들지 않고, 설계 결정을 늦추는 것이 왜 중요한지를 실무 관점에서 이해하게 됩니다.

클린 코드나 클린 아키텍처를 읽고 난 이후, 한 단계 더 나아가 설계 기준을 고민하는 개발자라면 충분히 공감할 수 있는 내용입니다. 유지보수와 변경 비용을 줄이는 방향으로 시스템을 바라보고 싶은 분들에게 추천합니다.

본 리뷰는 한빛미디어 출판사로부터 전자 도서를 제공받아 작성했습니다.

"실용주의"를 넘어 "미니멀리즘"으로 

《미니멀리즘 프로그래머》는 《실용주의 프로그래머》의 공동 저자인 데이비드 토머스(David Thomas)의 신작입니다.

원제는 Simplicity: Sustainable, Humane, and Effective Software Development이며, 제목 그대로 소프트웨어 개발을

어떻게 더 단순하고 지속 가능하게 만들 수 있을지에 대해 이야기하는 책입니다.

책의 전체적인 흐름은 《실용주의 프로그래머》와 어느 정도 닮아 있습니다.

거창한 이론을 전면에 내세우기보다는, 저자의 오랜 경험을 바탕으로 실제 현장에서 적용할 수 있는 방식들을

풀어내는 형태입니다. 어떤 방법이 효과적이었는지, 그리고 문제가 생겼을 때 왜 그런 선택을 했는지를 차분히

설명해주기 때문에 실무를 해본 개발자라면 더 공감하면서 읽을 수 있습니다.

두 책은 공통점도 분명합니다.

   - 둘 다 단순히 코드를 잘 짜는 것만을 이야기하지 않습니다.

   - 도구 활용, 자동화, 협업, 변화 대응, 유지보수성까지 함께 보아야 한다고 말합니다.
하지만 두 책이 던지는 질문은 다릅니다.

《실용주의 프로그래머》가 “좋은 개발자는 무엇을 익혀야 하는가?”를 묻는 책이라면,

《미니멀리즘 프로그래머》는 “왜 개발은 자꾸 복잡해지는가, 그리고 무엇을 덜어내야 하는가?”를 묻는 책에 더 가깝습니다.

그래서 개인적으로는

《실용주의 프로그래머》가 개발자의 기본기를 다지는 교본 같은 책이라면,

《미니멀리즘 프로그래머》는 어느 정도 경험을 쌓은 개발자가 자신의 일하는 방식과 코드를 다시 돌아보게 만드는 교정서에 가깝다고 느꼈습니다.

“따라 하지 마세요”라는 말이 인상적이었습니다.

이 책에서 특히 인상 깊었던 부분 중 하나는, 저자가 책의 내용을 그대로 따라 하지 말라고 이야기하는 대목이었습니다.

저자는 자신의 경험 속에서 어떤 문제가 있었고, 왜 복잡함을 줄이기 위해 그런 선택을 했는지를 보여줍니다. 하지만 그것을 정답처럼 강요하지는 않습니다. 오히려 독자가 자신의 환경과 상황 속에서 각자의 답을 찾는 데 도움이 되기를 바라는 태도가 느껴졌습니다.

실제로 책을 읽으면서도 “무조건 이렇게 해야 한다”는 느낌보다는, “이렇게 접근할 수도 있겠구나”, “아, 이런 관점으로 볼 수도 있겠네”라는 생각이 더 많이 들었습니다. 그 점이 오히려 더 좋았습니다. 부담 없이 읽히면서도, 내가 진행했던 프로젝트들을 떠올리게 만들었기 때문입니다.

읽다 보면 자연스럽게 “아, 예전에 이런 경우가 있었지”, “그때 나는 어떻게 했었지?” 하고 스스로를 돌아보게 됩니다. 그런 점에서 이 책은 단순히 지식을 전달하는 책이라기보다, 경험 있는 개발자에게 생각할 거리를 던져주는 책이라는 느낌이 들었습니다.

특히 PART 01의 ‘코드 다이어트’는 실무와 맞닿아 있어 더 인상적이었습니다. 실제 프로젝트를 진행하다 보면 필요 이상으로 코드가 무거워지거나, 꼭 필요하지 않은 것까지 얹게 되는 경우가 많습니다. 그런 부분을 다시 생각하게 해주는 내용이었습니다.

물론 책의 내용 중에는 내가 진행하는 프로젝트와 그대로 맞지 않는 부분도 있었습니다. 하지만 그것은 구현 방식과 프로젝트 환경이 다르기 때문이지, 책의 내용이 틀렸기 때문은 아니라고 생각합니다. 이 책은 “무조건 이렇게 해야 한다”는 식의 정답을 주는 책이 아니라, 복잡성을 줄이는 방향을 제시하는 책이기 때문에 자신의 상황에 맞게 받아들이는 것이 중요하다고 느꼈습니다.

변화는 불편하지만, 받아들여야 한다

또 하나 인상 깊었던 점은 변화에 대한 태도였습니다.

개발을 오래 하다 보면 익숙한 기술과 익숙한 방식에 머무르고 싶어질 때가 많습니다. 특히 시니어 개발자가 될수록 자신의 경험이 강한 무기가 되는 동시에, 새로운 것을 받아들이는 데 조심스러워질 수도 있습니다. 그것이 쉽지 않다는 점도 충분히 공감됩니다.

하지만 소프트웨어 개발은 변화가 매우 빠른 분야입니다. 최근에는 AI 기술의 발전으로 그 변화의 속도가 더 빨라졌습니다. 새로운 도구와 방식이 계속 등장하고, 예전에는 중요하게 여겼던 기준이 달라지기도 합니다.

이런 시점에서 변화를 무조건 두려워하기보다, 조금 느리더라도 받아들이고 따라가려는 태도가 결국 오래 살아남는 힘이 된다고 생각합니다. 책을 읽으며 특히 공감했던 것은, 저자가 배우는 일을 부담이 아니라 즐거움으로 바라보려 한다는 점이었습니다.
나 역시 그런 태도를 잃지 않도록 노력해야겠다는 생각이 들었습니다.

마무리 ....

《미니멀리즘 프로그래머》는 단순히 “덜 만들자”는 책이 아닙니다.
오히려 “복잡성을 통제할 수 있는 방식으로 만들자”는 책에 가깝습니다.

무언가를 더 추가하는 능력보다, 무엇을 줄이고 어떻게 단순하게 유지할 것인가를 고민하게 만든다는 점에서 의미가 컸습니다.

특히 요즘처럼 AI가 구현 속도를 높여주는 대신 설계 부채를 더 빨리 키울 수도 있는 시점에는 더욱 시의적절한 책이라고 생각합니다.

실무를 어느 정도 경험한 개발자라면, 자신의 코드와 일하는 방식을 다시 돌아보게 만드는 계기가 될 만한 책입니다.

#미니멀리즘 프로그래머#한빛미디어



"단순함을 추구하면 프로그래밍이 다시 즐거워질 겁니다."  

- 데이비드 토머스

# cd /project
# npm install
# npm run lint
# npm test
# npm run build
# scp dist/* server:/var/www/
// 뭔가 빠뜨리면 처음부터 다시... ㅠㅠ

makefile

deploy:
npm install && npm run lint && \
npm test && npm run build && \
scp dist/* server:/var/www/
@echo "배포 완료!"

# make deploy   // 이제 터미널에서 딱 한 줄로 끝!

let isLoading = false;
let hasError = false;
let isSubmitted = false;
// 이 조합이 8가지나 됨. 어떤 게 유효한지 모름

const STATES = {
IDLE: 'idle',
LOADING: 'loading',
SUCCESS: 'success',
ERROR: 'error',
};

const TRANSITIONS = {
[STATES.IDLE]: { submit: STATES.LOADING },
[STATES.LOADING]: { ok: STATES.SUCCESS, fail: STATES.ERROR },
[STATES.ERROR]: { retry: STATES.LOADING },
[STATES.SUCCESS]: { reset: STATES.IDLE },
};

function transition(current, event) {
return TRANSITIONS[current]?.[event] ?? current;
}
// 현재 상태가 어디인지 항상 명확!



"한빛미디어 서평단 ＜나는리뷰어다＞ 활동을 위해서 책을 협찬 받아 작성된 서평입니다."

안녕하세요, WMS와 HR 시스템을 개발하고 있는 5년 차 개발자입니다. 요즘 프로젝트를 하면서 느끼는 건 하나였어요. "왜 이렇게 점점 복잡해지지…?" 오히려 올바른 프로그래밍을 하고 있는 건가라는 고민에 빠지게 되는 것 같습니다.

기능은 늘어나고, 코드도 늘어나고, 의존성도 계속 붙고… 어느 순간부터는 '개발'이 아니라 '복잡함 관리'가 일이 되어버린 느낌이었습니다. 그러던 와중에 [미니멀리즘 프로그래머]를 읽게 됐습니다.

결론부터 말하면, 이건 그냥 책이 아니라 개발 방식 자체를 다시 생각하게 만드는 트리거였습니다.

"코드를 더 잘 짜는 법이 아니라, 복잡함을 줄이는 사고방식 자체를 바꿔준다." 코드를 더 건강하게 만들 때입니다. 코드를 다이어트할 때입니다.

솔직히 찔렸습니다. 저 포함 대부분의 프로젝트가 "살찌는 방향"으로 가고 있거든요. 필요 이상으로 붙는 라이브러리, 점점 늘어나는 의존성, 수정하면 어디 터질지 모르는 구조. 특히 Phoenix 예시에서 "기본 프로젝트인데 의존성 40개 이상"이라는 부분 보고 우리 프로젝트 떠올라서 웃음이 나왔습니다. package.json 열어봤거든요. 세어봤습니다. 57개였습니다. 그 중에 지금 실제로 쓰고 있는 게 몇 개인지 추적해보니까, 절반은 "언젠가 쓰겠지" 하고 설치해 놓은 것들이더라고요. 언젠가는 아직 안 왔는데, 용량은 이미 왔습니다.

책에서 말하는 게 결국 이거예요.

"더하는 건 쉽다. 빼는 게 실력이다."

5년 차 되면 뭔가 더 많이 알아야 한다는 압박에 자꾸 도구를 쌓게 되는데, 이 책은 반대로 "덜어내는 훈련"을 시켜줍니다. 읽고 나서 저 한 가지 바로 실천했어요. 안 쓰는 패키지 정리하고, 의존성 12개 제거했습니다. 빌드 타임 줄었고, 번들 사이즈도 같이 줄었고, 무엇보다 npm install 할 때 덜 불안해졌습니다.

현황 파악 → 실행 → 학습

이건 거의 개발판 PDCA인데, 훨씬 현실적입니다. 복잡한 부분을 먼저 인정하고, 완벽한 설계보다 "작은 실행"을 먼저 치고, 결과 보고 계속 개선하는 흐름이에요. 말로 쓰면 당연한 것 같은데, 실제로 팀에서 이걸 못 하는 경우가 엄청 많거든요. 저희도 그랬어요. 설계 회의가 2주 넘게 가는데, 정작 코드 한 줄 안 나오는 스프린트가 있었거든요.

책 읽고 나서 팀한테 제안했습니다. "일단 작게 만들고 보자. 완벽한 설계는 두 번째다." 처음엔 반신반의했는데, 한 스프린트 돌아보니까 차이가 눈에 띄더라고요. 설계 회의 시간은 줄었고, 실제 구현 속도는 올라갔고, 무엇보다 팀 피로도가 확 내려갔습니다. 회의실에서 화이트보드 앞에 서서 "이 구조가 맞냐 틀리냐" 토론하던 시간을, 그냥 만들면서 확인하는 시간으로 바꿨을 뿐인데요. 특히 "완벽한 설계 먼저 하지 말라"는 부분, 팀 슬랙에 캡처해서 공유했는데 반응이 제일 좋았습니다. 시니어 개발자분이 "이거 진작에 알았으면..." 하셨을 때, 저도 같은 생각이었어요.

이 챕터는 그냥 실무 필살기입니다. 책에서 말하는 핵심은 단순해요. 결합도가 높으면 변경이 지옥이 된다. 그리고 결국엔 아무도 건드리기 싫은 코드가 된다.

읽으면서 손이 떨렸습니다. 우리 팀 얘기를 어떻게 알았지 싶어서요. 저희가 정확히 그 상태였거든요. A 건드리면 B 터지고, B 고치면 C 영향 가고, 결국 rollback. 몇 번 반복되니까 팀 내에 불문율이 생겼어요. "그 모듈은 건들지 말자." 아무도 말 안 했는데, 다들 알고 있는 그 분위기요.

책에서 나온 Hassan과 Jan 예시 보면서 웃음이 나왔습니다. Jan이 휴가 중이라 Hassan이 일을 못 한다는 그 장면, 코드 얘기인 줄 알았는데 팀 구조 얘기더라고요. 결합은 코드만의 문제가 아니라는 거, 그게 제일 인상 깊었어요.

책 읽고 나서 바로 세 가지 바꿨습니다. 공통 로직 분리하고, 의존성 줄이고, 서비스 레이어 역할을 명확하게 다시 정의했어요. 거창한 리팩토링이 아니었어요. 그냥 "이 함수가 여기 있어야 하나?" 질문 하나씩 던지면서 옮긴 거였는데, 결과가 체감될 정도로 달랐습니다. 수정 속도가 확실히 빨라졌고, 코드 리뷰할 때 "이거 바꾸면 어디 터지냐"는 질문이 줄었어요. 그 질문이 줄었다는 게, 사실 제일 큰 변화였습니다. 리뷰 스트레스가 그 질문에서 제일 많이 왔거든요.

책에서 이런 말이 나와요. 100% 정확한 기술적 답변이라도, 상대방이 세부 사항을 잘 모르는 이상 오히려 혼란을 일으킬 수 있다고. 즉, 설명의 혼란을 줄이기 위해 현실과 다소 차이가 나는 부분을 감수해야 할 때가 있다는 거예요.

읽으면서 뜨끔했습니다. 저 맨날 정확하게 설명하려다가 팀원들 눈 풀리게 만들었거든요.

특히 도메인 선택하기 부분이 인상적이었어요. 아무리 좋은 비유도, 상대방이 그 배경을 모르면 소용없다는 거예요. 책에서 명확하게 피하라고 하는 도메인이 있어요. 한 사람만이 깊이 있는 전문 지식을 보유한 도메인, 구축에 오랜 시간이 걸리는 환경, 정치·종교·사회적 이슈. 당연한 것 같은데, 저 세 번째 많이 어겼습니다. 회의 중에 괜히 사회 이슈 비유 들었다가 분위기 이상해진 적 한두 번이 아니에요.

이게 코드 얘기가 아니에요. 팀 안에서 소통하는 방식 얘기입니다. 코드 리뷰할 때도, 신입한테 설명할 때도, 기획자랑 회의할 때도 결국 이 원칙 하나로 수렴하더라고요.

그래서 요즘은 코드 구조 정리랑 팀 커뮤니케이션 개선을 같이 진행 중입니다. 어느 한쪽만 건드리면 결국 원래대로 돌아오거든요. 코드만 깔끔하게 정리해봤자, 팀 소통이 그대로면 한 달 뒤에 다시 엉킵니다. 이 챕터 하나가, 저한테는 기술서라기보다 팀 운영 가이드처럼 읽혔어요.

5년 차 개발자로서 솔직히 말할게요. 이 책은 기술서를 기대하면 안 됩니다. 알고리즘 설명 없고, 프레임워크 비교 없고, 최신 트렌드도 없어요. 그런 걸 기대하고 펼치면 실망할 수 있습니다.

대신 이 책이 주는 건 하나예요. "개발을 어떻게 해야 하는지." 기술이 아니라 방향. 코드가 아니라 사고방식. 읽고 나서 코딩 실력이 느는 게 아니라, 코딩하기 전에 먼저 멈추게 됩니다. "이거 꼭 필요한가?", "더 단순하게 할 수 있는가?" 이 질문이 자동으로 나오기 시작해요. 5년 차라면 설계의 영역에 도전하게 되고, 더 좋은 코드를 위해 노력해야 합니다. 그렇기 때문에 이 책을 추천합니다.

"잘 만드는 것보다, 덜 복잡하게 만드는 게 더 중요하다."

읽고 나서 달라진 게 있다면, 코드 짜기 전에 구조부터 고민하게 됐고, 복잡하다는 느낌이 들면 방향이 잘못됐다는 신호로 받아들이게 됐어요.

[미니멀리즘 프로그래머]는 "한 번 읽고 끝"이 아닙니다. 꽂아두고 가끔 꺼내보는 기준서 같은 느낌이에요. 실무에서 뭔가 꼬인다 싶을 때 펼쳐보면 답이 거기 있더라고요. 부담 없이 한 번 읽어보세요. 읽고 나서 분명 package.json 한 번 다시 열게 될 겁니다.

** 한빛미디어 서평단 ＜나는 리뷰어다＞ 활동을 위해서 책을 협찬받아 작성된 서평입니다.

미니멀 라이프가 유행인 때가 있었다.

물론 지금도 그 유행이 끝난 것은 아니다.

꾸준히 하고 있는 사람들 사이에서는 여전히 유효하다.

그것을 추구한 것은 결국 불필요한 것들을 제거하여 좀 더 풍성한 삶을 누릴 수 있도록 하게 하려 하는 것이었다.

불필요한 수많은 물건으로 인해 나의 동선과 신경이 분산되고 낭비되는 것이 많기 때문이다.

프로그래밍을 하는 것도 마찬가지이다.

이것이 좋다고 생각해서 버리지 못하고, 저것이 좋다고 해서 버리지 못하고 남겨둔 것이 많다.

그것이 남아서 레거시 코드가 되고, 그 레거시 코드를 잊든, 사람이 바뀌든 결국 불필요한 존재가 되어, 이것이 복잡도만 증가시키고 나의 필요와는 상관없이 그 자리에 남아있는 것을 보게 되는 경우가 많다.

그래서 코드 분석에도 시간이 오래 걸리고, 코드 수정에 영향을 주는 부분은 없는지 파악하는 데에도 많은 시간이 걸린다.

이렇듯 프로그래밍의 영역에서 어떤 방법으로 미니멀리즘을 구현해 나갈 것인지 생각해본 부분은 많기 때문에, 이것을 정리해 줄 좋은 계기가 될 것이라고 생각한 책이 나왔다.

책 정보

표지가 신뢰를 준다.

표지가 매우 미니멀리즘 하기 때문이다.

미니멀리즘을 지향하는 내요을 담은 책의 표지가 덕지덕지 홍보문구와 키워드로 가득차 있다면 이율배반적인 느낌이 들었을 것인데, 그렇지 않아서 다행이었다.

- 정가: 16,000원(전자책)

- 분량: 191쪽

- 저자: 데이비드 토머스

- 역자: 이민석

이 책의 챕터가 중요해 보여서 좀 더 언급해 본다.

단순함의 미학, 코드 다이어트, 프로젝트 최적화, 업무 자동화, 변화의 수용, 소프트 스킬, 데이터 주도 개발, 가독성 높은 코드.

이것들이 이 책에서 말하고자 하는 주요 키워드이다.

내용 특성상 실무에서 바로 적용을 해야 가치가 올라가는데, 이런 키워드를 익힘으로써 조금은 업무에도 도움이 되길 바라는 마음이다.

특징

(1) 건강하지 않은 의존성 줄이기

우선 건강하지 않은 의존성을 줄이기를 강조한다.

이는 내가 직접 컨트롤 가능하지 않은 부분에 대한 이야기를 내포하고 있다. 사실 이것은 처음에는 동의하기 어려웠다. 미니멀리즘한 개발을 위해서는 라이브러리를 잘 활용해야 나의 코드에 집중하기 좋지 않을까 하는 생각이다.

하지만, 이것은 그 부분을 뛰어넘어 이야기를 하고 있다. 마치 내 코드의 일부를 외주를 주는 것과 같은 효과를 말하는 부분 때문이다. 내 코드를 남에게 맡겨주는 것과 다름 없는 행동을 한다는 것은 결국 그것에 대한 책임을 져야 하기 때문에, 그 코드의 작동 매커니즘도 이해하고 있어야 문제가 생겨도 내가 핸들링이 가능하기 때문이다.

특히 무분별한 라이브러리 사용은 더 문제가 되는데, 함수 하나를 가져다 쓰기 위해 수많은 용량을 가져와야만 하는 의존성이 얽힌 상황이 문제가 되는 것 때문이다. 내가 막상 사용하는 것은 10KB정도인데, 가져다 놓으면 10MB를 넘게 추가되는 경우가 많기 때문이다. 이렇다는 것은 최소한 1000배는 불필요한 파일이 추가된다는 의미도 포함하는 것이다. 정말 내 의도대로 작동되는 코드를 원한다면 상황에 따라서는 내가 작성한 작은 코드만으로도 의도한 목적을 달성할 수 있는지 확인하는것이 필요하다.

(2) 기술을 공유하면 역량이 배가 된다

내 평소 지론과 일치하는 부분이어서 인상적이었다.

내가 담당하고 있는 전문 기술인 안드로이드 기술은 매 해가 지날 때마다 빠르게 기술이 발전하고 있다. 이것은 개발자 커뮤니티와 서로간에 공유하려는 문화가 만들었다고 생각한다. 기술을 공유하는 사람과 공유받는 사람 모두 윈윈인 상황이라는 것을 말해준다. 개인의 바쁜 삶에 치여서 해야만 하지만 하지 못하고 있는 부분이 있다면 이런 영역이 아닐까.

배우기 위해 가르치세요

(3) 자동화 먼저, 코드는 나중에

프로젝트를 처음 빌딩하는 과정에 있어서, 이것 저것 할 것들이 많다. 그래서 대강 빌드 한 번만 되면 바로 작업에 돌입하는 경우도 흔하게 경험한다. 하지만 이 책에서는 자동화를 강조하고 있다. 작업 중간에 불편함을 느끼고 자동화를 해야겠다고 생각할 수 있지만, 그 때에는 이미 작업의 우선순위에 밀리고, 결국 그 불편함을 감수하고 코드작업을 진행하게 된다. 그것이 결국 하나의 기술부채가 된다는 것을 강조한다. 나도 작업하다보면 로깅을 쉽게 할 수 있도록 만들면 좋겠다고 생각은 하지만, 한 번 작업을 시작한 이후에는 전체를 고치기 싫어서 그대로 두어버린다. 이 또한 환경 구성의 일부로 볼 수 있는데, 최대한 자동화를 할 수 있도록 만들어놓는 것이 좋겠다는 생각을 했다.

(4) 의견 다른 상대방과 이야기 하기

앞에서 이야기 했던 것들이 작업 내용과 관련된 미니멀리즘을 향한 일이었다면, 이제는 주제를 좀 돌려서 의견 교환에 대한 이야기를 다룬다. 의견 교환은 좀 더 순화한 말이고, 대부분은 의견 대립으로 말할 수 있다. 의견 대립이 발생하면, 그것을 회피하든, 내 의견을 강하게 피력하는 것이 일반적인데, 이 책에서는 변증법적 사고 훈련에 대해 이야기 하는 부분이 인상적이었다.

다른 사람과 의견이 다를 때 그것을 반박하기는 매우 쉽다. 내 생각이 옳았음을 꺾는 과정이 쉽지 않기 때문이다. 하지만, 그것보다는 상대방의 관점에서 보는 훈련이 필요하다. 상대방의 관점에서 보면 결국 건전한 의견 교환으로 가는 길이 된다.

(5) 코드 미니멀리즘

데이터를 바꾸는 것이 코드를 바꾸는 것보다 훨씬 간편하다는 점을 강조한다.

가끔 보면 별도의 클래스를 정의하기 귀찮아서 primitive type을 이용하는 경우가 많은데, 그럴 경우 이걸 처리하기 위한 코드가 많아진다. 처음에는 그것이 편해서 그대로 활요하게 되는데, 점점 요구사항은 늘어나고, 변경되며 결국은 그것을 만족하기 위한 방법으로 모델을 다시 만드는 경우에 대해서 떠올리게 되었다. 결국 데이터 중심으로 처리하는 것이 훨씬 편하다는 점에 대해 공감하게 되는 영역에 이른다.

개발할 때 로직을 줄일 수 있는 또 다른 방법은, 상태머신 관리 방법이다. 안드로이드 개발을 하다보면 자연스레 여기까지 이르게 되는데, 컴포즈를 다룰 때 정점에 이른다. 화면을 구성할 때 그 화면의 상태를 변경해줌으로써 정확하게 필요한 부분을 일일히 로직으로 구성하지 않고, 정확하게 나눈 파일이나 컴포저블 함수를 호출하는 방향으로 흐르게 된다. 이것의 출발점은 바로 상태머신이다. 그리고 이렇게 작성할 경우 가독성이 올라가는 것은 당연하다. 코드가 명확하게 블럭화되어 나뉘기 때문이다.

관련된 코드를 한 곳으로 모으는 것도 쉽게 간과하는 부분일 수 있으나, 잘 지켜야 코드 추적이 편해진다. 오랫동안 유지보수한 코드일수록 내가 추적해야 하는 코드량이 많을 수 밖에 없는데, 불필요하게 코드가 이리 뛰고 저리 뛰면 논리적 흐름도 자주 끊어져서 잇기가 쉽지 않다. 그래서 머릿속에 그림을 쉽게 그리기 위해서라도 관련된 코드를 잘 모아놓기만 해도 바로 이해할 수 있기 때문에 미니멀리즘한 코드를 구현하게 된다.

(6) 간단함이 복잡성보다 나은 점

사실 이 책에 나온 부분은 실제 프로젝트를 진행하는 입장에 비춰보면 일부라고 느낄 정도로 매우 적은 부분에 해당한다. 실제 현장에서는 이 책의 내용에서 찾을 수 없는 것이 대부분이다. 그렇다면 어떤 것이 간담함이라고 볼 수 있을까에 대한 기준점을 마지막에 제시해준다.

- 이해하기 더 쉽다

- 구성요소의 수가 더 적다

- 문제의 본질을 더 직접적으로 반영한다

이런 것을 회피하고 있다면, C를 그대로 둔 상태일 가능성이 높다. S를 올릴수록 결국 내 프로젝트가 훨씬 유지보수성이 올라가기 때문에 틈날때마다 이 점들을 체크하는 것이 좋다.

이 책을 추천하고 싶은 독자

- 현직 개발자

- 컴퓨터 공학 전공자

- 개발에 관심이 있는 사람 및 관련 조직의 장

총평

방정리를 잘하고 싶은데 방정리를 어떻게 하는 것이 효과적이고 대중적으로 좋은 방법인지 몰라서 한번 쯤은 책이나 영상을 찾아본 경험이 있을 것이다. 이 책도 마찬가지이다. (가만히만 두어도) 한 스프린트가 지날 때마다 내 프로젝트가 점점 복잡도가 올라가는 것을 경험한 적이 있을 것이다. 이제는 한번 쯤 프로젝트를 돌아볼 때 어떻게 어떤 관점에서 봐야 하는지, 좋은 가이드가 된다고 생각한다.

물론 나처럼 적지 않은 실무 경력을 가진 사람이라면 자신만의 방법은 분명 존재할 것이다. 하지만, 내 방법을 좀 더 체계적으로 만들거나, 머릿속에만 존재하고 실재하지 않는 영역이라면 이것을 실체화 시켜주는 역할을 해줄 것이라고 생각한다. 그래서 이 책을 읽고 실천까지 이르기를 바란다. 결국 이것을 수행함으로써 이득보는 것은 이 프로젝트를 수행하고 있는 나 자신이기 때문이다.

대부분 봄이 오면 옷 정리도 할 겸, 집 정리를 한 번씩은 한다. 이처럼 이 책을 읽고난 뒤 프로젝트 정리를 해보는 것은 어떨까.

봄에 집 정리를 하듯. 프로젝트에 쌓인 먼지를 털자고 말해주는 책

나는 리뷰어다2026 활동을 위해 책을 제공받아 작성한 리뷰입니다

덜어내는 사고방식을 배울 수 있는 책이다. 단순히 코드를 짧게 쓰는 기술을 말하는 게 아니라, 문제를 바라보고 해결하는 전반적인 과정에서 어떻게 더 효율적으로 일할 수 있는지에 대한 기준을 잡아준다. 무엇을 더 추가할지가 아니라, 무엇을 굳이 하지 않아도 되는지 판단하는 힘을 키워준다는 점이 인상적이다.

특히 AI로 대부분의 작업을 쉽게 만들어낼 수 있는 요즘 같은 환경에서는 오히려 과해지기 쉬운데, 이 책은 그런 흐름 속에서 불필요한 요소를 줄이고 본질에 집중하는 감각을 길러준다. 결국 중요한 것만 남기고 나머지를 덜어내는 선택이 얼마나 큰 차이를 만드는지 다시 생각하게 된다.

📢 예스24 리뷰어클럽 서평단 자격으로 도서를 제공받고 작성한 리뷰입니다.

◼️개발은 왜 점점 복잡해질까? 

 새로운 프로젝트를 시작하거나 기존 코드를 유지보수할 때마다 늘 마주하는 고민이 있다. '이게 이렇게까지 복잡할 일인가?' 우리는 매일 새로운 기술과 방대한 프레임워크가 쏟아지는 시대에 살고 있다. 새로운 도구는 당장의 문제를 빠르게 해결해 주는 듯하지만, 어느새 우리는 수많은 의존성(Dependencies)이 얽힌 복잡한 늪에 빠져 허우적대곤 한다. 

오늘 리뷰할 책은 '실용주의 프로그래머'의 저자로 잘 알려진 데이브 토마스(Dave Thomas)의 신작, '미니멀리즘 프로그래미머'이다.

◼️단순함은 도구가 아니라 태도이다 

이 책은 단순히 기술적인 스킬이나 매뉴얼을 나열한 책이 아니다. 대신 우리가 일하며 마주하는 작업 방식, 업무 환경, 팀원과의 소통 방식 등 다방면에서 '단순함'을 되찾는 방법을 저자의 생생한 경험에 빗대어 풀어낸다.

책은 크게 4가지 파트로 나뉘어 있다. 복잡한 시스템이나 툴의 거대한 기능에 갇히지 않는 방법부터 시작해, 나만의 업무 환경을 효율적으로 세팅하는 법을 다룬다. 또한 팀 내 소통을 가로막는 회의의 비효율성을 지적하며 대안을 제시하고, 실제 업무 구조 자체를 단순화하는 구체적인 실천법까지 폭넓게 짚어준다.

개인적으로 최근 n8n을 활용해 정보를 수집하여 내부 DB에 연동하는 자동화 파이프라인을 구축해 본 경험이 떠올랐다. 단순히 반복 작업을 자동화하는 것을 넘어, 책에서 강조하듯 실무자가 겪는 인지적 부담(cognitive load)을 덜어내고 작업 환경의 복잡성을 줄이는 것이 얼마나 중요한지 다시금 깨달을 수 있었다.

특히 인상 깊었던 점은 복잡성을 해결하기 위해 '현황파악(Orient), 실행(Step), 학습(Learn)'이라는 세 가지 단계를 반복하라는 접근법이다. 정해진 절대적인 규칙을 맹목적으로 따르는 것이 아니라, 가장 단순한 방법으로 가벼운 실험을 거치며 내 상황에 맞는 해결책을 찾고 점진적으로 개선해 나가는 태도를 이 책에서 가장 먼저 소개하고 있다. 

◼️기술의 노예가 아닌 주인이 되기 위하여

 책을 읽으며 새로운 업무 툴이나 시스템을 무비판적으로 도입했다가, 오히려 관리 포인트만 늘어나고 업무가 복잡해졌던 경험들이 떠올라 묘한 공감대가 형성되었다. 저자는 아무도 요구하지 않은 불필요한 기능을 더하느라 에너지를 낭비해서는 안 되며, 단순함을 유지하려면 지속적인 시간과 노력을 투자해야 한다고 강조한다.

이 책은 거창한 방법론을 강요하지 않는다. 오히려 매우 현실적이고 인간적인 조언들을 건넨다. 기술이 아무리 정교하게 발전해도 결국 시스템을 기획하고 작동하게 만드는 주체는 정밀한 기계 부품이 아니라 생각하고 상상하는 '사람'이기 때문이다.

매일같이 쏟아지는 새로운 기술의 파도 속에서 '더 많은 기능'만을 좇느라 지쳐가는 직장인이라면 꽤 흥미롭게 읽을 수 있는 책이다. 단순히 도구의 부속품처럼 일하는 것을 넘어, 지속 가능하고 효과적인 업무 프로세스를 위해 어떤 태도로 '단순함'을 추구해야 할지 깊이 있게 고민해보게 만든 책이었다.