한빛미디어

안녕하세요, 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 한 번 다시 열게 될 겁니다.