"오늘 빨리 끝내는 코드와 내일도 계속 이해되는 코드는, 과연 어디서 갈라지는 걸까요?" 이 질문은 제가 최근 존
오스터하우트의 이라는 책을 읽으며, 계속해서 곱씹었던 화두입니다.
요즘처럼 AI 도구와 자동화가 코드를 뚝딱 만들어내는 시대에, 단순히 '작동하는' 코드를 넘어, 오랫동안 이해되고
수정될 수 있는 코드란 무엇일까 하는 고민이 깊어졌거든요.
솔직히 책을 집어 들기 전에는, 개발 현장에서는 결국 '일단 작동하는 것'이 설계 판단을 압도하기 쉽다고
생각했어요.
빠르게 기능을 구현하고, 일단 배포하는 것이 중요하다고 말이죠.
하지만 이 책은 그런 저의 가설에 정면으로 질문을 던집니다.
작동 여부를 최소한의 조건으로 낮추고, 오히려 '깊은 모듈'이라는 개념을 장기적인 투자의 단위로 보라고 말이죠.
이 책은 설계를 거창한 아키텍처 선언이 아니라, 우리가 매일 마주하는 일상적인 복잡성을 관리하는 행위로 읽게
만듭니다.
특히 3장 '작동하는 코드만으로는 부족하다'와 4장 '모듈은 깊어야 한다'는 저에게 큰 울림을 주었어요.
저자는 눈앞의 문제 해결에만 급급한 프로그래밍을 '전술적 프로그래밍'이라 부르며 경계합니다.
반대로 '전략적 프로그래밍'은 미래의 변경 가능성을 비용으로 계산하고, 작은 설계 투자를 꾸준히 넣는 태도를
의미해요.
그리고 이 '전략적 프로그래밍'의 핵심 도구 중 하나로 '깊은 모듈'을 제시합니다.
깊은 모듈이란, 단순한 인터페이스 뒤에 아주 큰 기능을 숨기는 모듈을 뜻해요.
사용자가 알아야 할 표면은 최소화하면서도, 내부의 복잡성을 효과적으로 흡수하는 거죠.
반대로 '얕은 모듈'은 기능을 분리하긴 했지만, 사용자가 여전히 많은 것을 알아야 하거나, 내부 복잡성을 제대로
감추지 못해 오히려 부담을 늘리는 모듈을 말합니다.
이 책의 내용을 읽으며, 제 경험이 여실히 떠올랐습니다.
'빠른 해결이 반복되면 구조가 느려진다'는 문구에 고개를 끄덕일 수밖에 없었죠.
당장 눈앞의 버그를 잡고, 기능을 추가하는 데만 집중하다
보면, 어느새 코드베이스는 엉망진창이 되고, 작은 변경에도 예상치 못한 문제가 터지는 악순환을 겪게 되거든요.
저는 그동안 클래스 개수를 줄이는 것이 좋은 설계라고 막연히 생각했던 적도 있었어요.
하지만 이 책은 '클래스 수보다
인터페이스 대비 기능 밀도를 봐야 한다'고 말합니다.
이 관점은 저에게 신선한 충격이었습니다.
단순히 덩치만 줄이는 것이 아니라, 얼마나 '적게 알게 해도 많이 해주는가'가 중요하다는 것을 깨달았죠.
가장 인상 깊었던 부분은, 설계가 별도의 거창한 의식이 아니라, '매일의 이름, 경계, 예외, 주석, 그리고 계층
선택 속에 들어 있다'는 저자의 통찰이었습니다.
이 문장을 읽고 나니, 코드 리뷰의 질문이 '작동하는가'에서 '다음
변경자가 무엇을 알아야 하는가'로 바뀌어야 한다는 저자의 주장에 깊이 공감하게 됐습니다.
이 질문 하나만으로도 코드의 품질과 미래 확장성에 대한 고민이 얼마나 깊어질 수 있는지 생각해보게 되었어요.
이 책을 읽고 나서, 저는 당장 제 작업 방식에 한 가지 변화를 주려고 합니다.
바로, 최근에 제가 수정한 모듈 하나를 다시 살펴보는 거예요.
과연 이 모듈이 '깊은 모듈'의 특성을 가지고 있는지, 사용자가 알아야 할 인터페이스는 최소화하면서도, 내부
복잡성을 잘 감추고 있는지를요.
그리고 앞으로 코드 리뷰를 할 때, 단순히 기능의 작동 여부뿐만 아니라, "이 코드를 다음
사람이 변경하려면 무엇을 알아야 할까?"라는 질문을 던져볼 생각입니다.
이 작은 습관이 쌓여서, 더 나은 코드를 만들고, 미래의 변경 비용을 줄이는 '전략적 프로그래밍'으로 나아갈 수
있다고 믿어요.
나아가, AI 에이전트가 코드를 작성하는 시대에, 이 '깊은 모듈' 원칙을 어떻게 검증 루프에 넣을 수 있을지
고민하는 것도 저의 새로운 과제가 될 것 같습니다.
이 책은 단순히 작동하는 코드를 넘어, 지속 가능한 소프트웨어를 만들고 싶은 모든 개발자에게 큰 영감을 줄 것이라고
생각합니다.
특히 빠른 개발 속도에만 매몰되어, 나중에 감당하기 힘든 기술 부채를 겪어본 경험이 있는 분이라면, 이 책이
제시하는 '전략적 프로그래밍'의 가치에 깊이 공감할 거예요.
또한, 팀의 코드 리뷰 문화를 개선하고 싶거나, 설계의 본질에 대해 다시 한번 생각해보고 싶은 분들에게도 적극
추천하고 싶습니다.
결론적으로 은 저에게 '깊은 모듈은 많이 감춘 모듈이 아니라, 적게 알게 해도 많이 해주는 모듈이다'라는 진리를
알려주었습니다.
이 책을 덮으면서, 저는 다시 한번 제 자신에게 질문을 던져봅니다.
"지금 내가 작성한 코드베이스에서, 이 책이 경고하는 '레드플래그'는 과연 어디에 가장 뚜렷하게 보일까?" 여러분도
이 질문을 한번 던져보시길 바랍니다.
오늘 저의 이야기는 여기까지입니다.
다음
독서에서도 더 깊은 인사이트를 가지고 돌아오겠습니다.