코드를 작성하거나 리뷰할 때, 가끔 이런 질문을 던지곤 합니다.
"왜 이렇게 복잡해졌을까?" 특히 요즘처럼 AI 도구와 자동화가 코드를 더 빨리 만들어내는 시대에는, 단순히
'작동하는 코드'를 넘어, "어떤 코드가 오래 이해되고 수정될 수 있을까?" 하는 질문이 더욱 중요해지는 것
같습니다.
오늘 제가 이야기할 책은 스탠포드의 컴퓨터 과학자 존 오스터하우트 교수의 입니다.
이 책은 저에게 '설계'를 거창한 아키텍처 선언이 아니라, 일상적인 복잡성 관리의 문제로 다시 읽게 만들었습니다.
처음
이 책을 집었을 때는, 코드를 어떻게 하면 더 깔끔하게 나눌 수 있을까 하는 막연한 기대를 가지고 있었습니다.
흔히들 코드를 여러 계층으로 나누면 설계가 좋아진다고 생각하기 쉽잖아요.
그런데 이 책은 단순히 '나눔' 그 자체보다, '나뉜 계층들이 과연 어떤 의미를 가지는지'를 묻고 있었습니다.
읽기 전의 가설이 흔들리는 순간이었죠.
이 책, 특히 제가 집중했던 7장과 8장의 핵심 메시지는 두 가지로 압축할 수 있습니다.
첫째는 "다른 계층은 다른 추상화를 가져야 한다"는 것입니다.
이 말은 계층이 단순히 하위 계층의 호출을 그대로 전달하는 통로가 되어서는 안 된다는 뜻입니다.
대신, 각 계층은 사용자가 완전히 다른 수준에서 생각하게 만드는, 새로운 사고 단위를 제공해야 한다는 거죠.
예를 들어, 우리는 웹 페이지를 볼 때 브라우저의 내부 구현이 어떻게 되어 있는지 일일이 알 필요
없이 '페이지'라는 추상화 위에서 생각합니다.
이것이 바로 좋은 계층 분리의 예시죠.
책에서는 이를 라고 부르며 경고합니다.
이름만 다를 뿐, 거의 그대로 호출을 넘기는 얕은 계층들은 사실 추상화가 아닙니다.
메서드 수가 아무리 늘어나도 코드를 이해하기 쉬워지지 않는다면, 그건 설계에 문제가 있다는 신호일 수 있습니다.
이름만 다른 래퍼는 그저 조직도일 뿐, 새로운 가치를 주지 못하는 거죠.
둘째 핵심은 "복잡성을 아래로 당겨라"는 원칙입니다.
좋은 모듈이나 라이브러리는 복잡한 작업을 스스로 떠맡아, 그것을 호출하는 상위 코드를 최대한 단순하게 만듭니다.
사용자는 그 복잡성을 직접 다룰 필요
없이, 간결한 인터페이스를 통해 원하는 기능을 쓸 수 있게 되는 겁니다.
마치 좋은 API가 내부의 복잡한 노동을 숨겨주듯이 말이죠.
하위 모듈이 어려운 일을 기꺼이 맡아주는 것, 이것이 바로 인터페이스 설계의 핵심이라고 책은 강조합니다.
이러한 메시지들은 저에게 깊은 인상을 남겼습니다.
특히 "새 계층은 어떤 새로운 생각을 제공해야 존재할 자격이 있는가?"라는 질문은 제 코드 리뷰 방식에 큰 변화를
가져왔습니다.
예전에는 단순히 "이 코드가 작동하는가?"에 초점을 맞췄다면, 이제는 "다음
변경자가 이 코드를 봤을 때 무엇을 알아야 하는가?" "이 계층이 새로운 사고 단위를 제공하는가?"를 먼저 묻게
됩니다.
설계는 어떤 거창한 선언문이 아니라, 우리가 매일 작성하는 코드의 이름, 경계, 예외 처리, 주석, 그리고 계층을
선택하는 순간들 속에 녹아 있다는 것을 깨달았습니다.
최근에 작업했던 모듈 하나를 다시 열어보고, 이 책의 기준에 따라 점검해보려는 작은 실험도 계획하고 있습니다.
과연 '패스스루' 메서드는 없는지, 복잡성은 잘 당겨져 있는지 말이죠.
이 책은 단순히 코드를 잘 쓰고 싶은 개발자뿐만 아니라, 팀 내 코드의 품질과 유지보수성을 고민하는 모든 개발자,
특히 시니어 개발자들에게 큰 울림을 줄 것이라고 생각합니다.
AI가 코드를 빠르게 생산하는 시대에, '좋은 코드'의 본질이 무엇인지 고민하고 싶은 분들이라면 꼭 한번 읽어보시길
권합니다.
오늘의 독후감을 한 문장으로 정리하자면 이렇습니다.
"계층은 많아질수록 좋은 것이 아니라, 서로 다른 생각을 제공할 때만 깊어진다." 그리고 여전히 저에게 남은 질문이
있습니다.
AI 에이전트가 코드를 작성할 때, 이 '계층의 깊이'와 '복잡성 하향'이라는 원칙을 어떻게 로 넣을 수 있을까요?
다음
독서에서 이 질문에 대한 힌트를 찾아볼 수 있기를 기대해 봅니다.