코드를 작성하는 일이 점점 더 빨라지는 요즘, 우리는 어떤 질문을 던져야 할까요?
단순히 빨리 만드는 것을 넘어, '잘 만드는 것'의 기준은 무엇일까요?
저는 최근 존 오스터하우트 교수의 "A Philosophy of Software Design"이라는 책을 읽으며 이
질문에 대한 답을 찾아봤습니다.
AI 도구가 코드를 뚝딱 만들어내는 시대에, 과연 어떤 코드가 오랫동안 살아남고, 다음
사람이 쉽게 이해하고 수정할 수 있을지 궁금했습니다.
솔직히 저는 늘 소프트웨어 설계가 멋진 아키텍처 다이어그램이나 정교한 디자인 패턴 선택의 문제라고 생각했죠.
하지만 이 책은 그보다
훨씬 근본적인 질문을 던지며, 제 가설을 흔들어 놓았습니다.
저자 오스터하우트 교수는 소프트웨어 설계의 핵심을 '복잡성'과의 싸움으로 정의합니다.
즉, 좋은 설계란 무엇인가를 더 많이 추가하는 기술이 아니라, 오히려 무엇을 줄이는 기술이라는 거죠.
책은 복잡성을 단순히 코드의 양이나 기능의 많음으로 보지 않습니다.
대신 개발자의 '인지 부하', 즉 코드를 이해하고 수정할 때 드는 '머릿속 부담'으로 측정해야 한다고 말합니다.
이 인지 부하가 곧 설계의 부채가 된다는 것이죠.
이 책을 읽기 전까지 저는 복잡성을 그저 '어렵다'는 감각적인 문제로만 생각했습니다.
하지만 책은 복잡성을 '장기적인 비용'으로 명확히 인지하게 했습니다.
마치 재무적인 부채처럼, 복잡성이 쌓이면 미래의 생산성을 갉아먹는다는 사실을요.
특히 '변경 증폭'이라는 개념이 와닿았습니다.
작은 수정 하나가 예상치 못하게 많은 곳에서 추가적인 변경을 요구하며 작업 시간을 잡아먹는 경험, 다들 한 번쯤
있으실 겁니다.
제 코드에서도 이런 증상이 어디까지 번지는지, 그리고 왜 번지는지 먼저 파악해야 한다는 깨달음을 얻었습니다.
그리고 '인지 부하'는 단순히 개인의 능력 문제가 아니라, 시스템 설계의 문제라는 통찰은 저에게 큰 충격이었습니다.
좋은 코드는 그저 실행만 되는 코드가 아니라, 다음
사람이 이해하고 수정하는 데 드는 비용이 낮은 코드여야 한다는 거죠.
이건 단순히 개인의 숙련도를 넘어, 팀 전체의 생산성과 직결되는 문제였습니다.
저는 이 책을 읽고 나서, 코드 리뷰 질문을 바꿔보기로 했습니다.
"이 코드가 잘 작동하는가?"에서 "다음
변경자가 이 코드를 수정하려면 무엇을 알아야 하는가?"로요.
설계는 거창한 아키텍처 문서에만 존재하는 것이 아니라, 매일 우리가 선택하는 변수 이름, 함수 경계, 주석
하나하나에 스며들어 있다는 것을 깨달았습니다.
최근 작업했던 모듈 하나를 다시 보면서, '변경 증폭'이나 '인지 부하'의 관점에서 얼마나 개선할 수 있을지
실험해볼 생각입니다.
숨겨진 의존성은 없는지, 모호한 부분은 없는지 꼼꼼히 살펴보려고 합니다.
이 책은 특히 실무에서 코드를 작성하고 유지보수하는 개발자분들, 그리고 코드 리뷰를 통해 동료들과 함께 더 나은
설계를 고민하는 팀 리더분들에게 큰 울림을 줄 것 같습니다.
단순히 기능 구현을 넘어, '오래가는 코드'를 만들고 싶은 분이라면 꼭 한번 읽어보시길 권합니다.
마치 좋은 건축가가 건물의 아름다움뿐 아니라 사용자의 편의와 유지보수 용이성을 고민하듯이, 이 책은 소프트웨어
건축가의 기본적인 철학을 제시합니다.
결국, 소프트웨어 설계는 코드를 멋지게 꾸미는 일이 아니라, 다음
사람이 덜 헤매게 만들어서 우리 모두의 장기적인 생산성을 높이는 일이라는 한 문장으로 정리할 수 있겠습니다.
저는 이제 또 다른 질문을 안고 다음
책으로 향합니다.
AI 에이전트가 코드를 작성할 때, 이 '복잡성 관리' 원칙을 어떻게 검증 루프에 넣을 수 있을까요?
아니면 AI 자체가 복잡성을 줄이는 새로운 설계 방식을 제시할 수 있을까요?
여러분의 생각은 어떠신가요?