요즘 코드를 쓰는 속도가 부쩍 빨라졌다는 생각을 자주 합니다.
AI 도구와 자동화 덕분인데요.
이렇게 빠르게 만들어지는 코드들 중에서, 과연 어떤 코드가 오랫동안 이해되고 수정될 수 있을지 궁금해졌습니다.
이런 질문을 품고 집어든 책이 바로 존 아우스터하우트의 입니다.
이 책은 복잡한 아키텍처 선언보다는, 매일매일 마주하는 소프트웨어 복잡성을 어떻게 관리할 것인가에 대한 이야기를
담고 있습니다.
책을 읽기 전에는 모듈을 나누는 '분리 원칙'과 예상치 못한 상황을 처리하는 '예외 처리'가 서로 다른 주제라고
생각했습니다.
하지만 이 책의 특정 챕터들을 읽으면서, 이 두 가지가 결국은 '인터페이스를 사용하는 사람이 알아야 할 경우의 수를
줄이는 문제'라는 하나의 관점으로 연결될 수 있겠다는 가설을 세웠습니다.
이 책의 핵심 주장은 바로 이것입니다.
모듈의 경계와 예외 처리는 모두, 그 코드를 사용하는 사람이 알아야 할 경우의 수를 줄이는 방향으로 설계되어야
한다는 것이죠.
저자는 이런 관점에서 '함께 두는 것이 더 나은 경우'와 '오류를 아예 존재하지 않도록 설계하는 방식'을
이야기합니다.
가장 인상 깊었던 부분은 '오류를 아예 없애도록 설계한다'는 개념이었습니다.
단순히 예외 상황을 잘 잡아서 처리하는 코드를 늘리기보다는, 애초에 그런 오류 상태가 발생할 수 없도록 설계
단계에서부터 고민해야 한다는 것이죠.
이는 마치 병이 생기면 약을 먹는 것보다, 병에 걸리지 않도록 건강한 생활 습관을 만드는 것과 비슷하게
느껴졌습니다.
또, '특별한 경우'를 줄이는 설계가 호출자의 머릿속 분기를 줄인다는 인사이트도 크게 와닿았습니다.
특수한 사례가 자꾸 생겨나 인터페이스를 복잡하게 만든다면, 그 특수 사례를 일반적인 규칙으로 흡수하거나 아예
설계에서 제거할 수 없는지 먼저 고민해야 한다는 거죠.
무조건적으로 코드를 쪼개는 것이 아니라, 공유하는 정보가 많거나 인터페이스가 단순해질 수 있다면 오히려 함께 두는
것이 더 나을 수 있다는 점도 제 기존 생각을 흔들었습니다.
결국, 이 책은 제게 '설계'라는 것이 거창한 선언이 아니라, 매일매일 작성하는 코드의 이름, 경계, 예외 처리,
주석, 그리고 계층을 선택하는 순간순간에 스며들어 있다는 것을 일깨워 주었습니다.
이 책을 읽고 나서 제 코드 리뷰 방식에도 변화를 주려고 합니다.
이제부터는 단순히 '이 코드가 잘 작동하는가?'를 넘어, '이 코드를 다음으로 수정할 개발자가 무엇을 알아야
하는가?'라는 질문을 던지게 될 것 같습니다.
인터페이스가 노출하는 정보의 양, 즉 '표면적'을 줄이는 것이 좋은 설계의 핵심이라는 관점에서 코드를 보게 된
거죠.
이 책은 복잡한 소프트웨어 시스템을 다루는 개발자, 아키텍트, 그리고 AI가 생성하는 코드의 품질과 유지보수성에
대해 고민하는 모든 분들에게 깊은 울림을 줄 것입니다.
결론적으로 이 책이 제게 남긴 한 문장은 이렇습니다.
좋은 경계는 코드를 예쁘게 나누는 선이 아니라, 그 코드를 사용하는 사람의 경우의 수를 줄이는 장치입니다.
앞으로 AI 에이전트가 코드를 작성할 때, 이런 '경우의 수를 줄이는 설계 원칙'을 어떻게 검증 루프에 넣을 수
있을지, 계속해서 고민해 봐야겠습니다.