한빛미디어

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

이 책을 추천하는 사람들

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

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

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

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

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