요즘 코드를 작성하는 속도는 그 어느 때보다
빠릅니다.
AI 도구들이 순식간에 수많은 코드를 만들어내죠.
그런데 이렇게 빠르게 생산된 코드 중, 얼마나 많은 코드가 오랫동안 이해되고, 또 수정될 수 있을까요?
저는 이 질문을 가지고 존 오스터하우트의 '소프트웨어 설계 철학'을 다시 펼쳐 들었습니다.
스탠퍼드 대학교 컴퓨터 과학자이자 Tcl/Tk 개발자로 잘 알려진 존 오스터하우트는, 설계를 거창한 아키텍처 선언이
아니라 매일 마주하는 복잡성을 관리하는 일로 바라봅니다.
특히 이번 독서에서는 '명백한 코드가 유행보다
강하다'는 9번째 회차에 집중했습니다.
책을 읽기 전, 제 안에는 이런 가설이 있었습니다.
아무리 좋은 방법론이나 최신 도구라 해도, 그것만으로는 설계의 품질을 자동으로 보장하지 못할 것이다.
오히려 유행하는 방법론들이 언제 설계를 돕고, 또 언제 설계를 가리는지, 그 기준이 궁금했습니다.
이 책의 핵심 주장은 명확합니다.
좋은 코드는 '명백해야' 한다는 것이죠.
읽는 사람이 적은 추론으로도 코드의 정확한 동작과 의도를 예측할 수 있어야 한다는 겁니다.
그리고 유행하는 모든 방법론과 패러다임은 이 '명백성'이라는 기준을 통과할 때에만 비로소 진정한 도움이 된다고
말합니다.
결국, 설계는 복잡성을 줄이는 일이고, 명백성은 그 복잡성을 측정하는 가장 중요한 척도가 되는 셈입니다.
이 책은 단순히 '무엇이 좋다, 나쁘다'고 단정하지 않습니다.
대신, 우리가 당연하게 여기던 많은 것들을 '명백성'이라는 렌즈로 다시 보게 만듭니다.
예를 들어, 객체 지향 프로그래밍, OOP는 강력한 도구임에 틀림없습니다.
하지만 상속이 깊은 계층을 만들고 분산된 상태가 암묵적인 규칙을 늘릴 때, 오히려 복잡성을 키울 수 있다는 저자의
지적에 깊이 공감했습니다.
패러다임은 원칙이 아니라 도구일 뿐이라는 깨달음이죠.
유닛 테스트나 TDD도 마찬가지입니다.
품질을 높이고 회귀를 막는 데 필수적이지만, 테스트 자체가 좋은 설계를 자동으로 만들어주지는 않습니다.
테스트 가능성은 좋은 설계의 신호일 수는 있어도, 충분조건은 아니라는 점을 다시 한번 상기시켜 주었습니다.
디자인 패턴 역시 공통의 언어를 제공하지만, 문제보다
패턴이 앞서면 단순히 장식에 불과할 수 있다는 경고도 인상 깊었습니다.
이 책을 읽고 나서, 제 머릿속에 가장 크게 남은 질문은 이것입니다.
'다음
변경자가 이 코드를 봤을 때, 무엇을 얼마나 알아야 할까?' 이제 코드 리뷰를 할 때 '이 코드가 작동하는가?'를
넘어, '이 코드가 얼마나 명백한가?', '이 코드를 이해하기 위해 얼마나 많은 추론이 필요한가?'를 묻게 될 것
같습니다.
설계는 거창한 회의나 문서가 아니라, 우리가 매일 선택하는 이름, 경계, 예외 처리, 주석, 그리고 코드의 계층
속에 녹아 있다는 것을 다시 한번 깨닫게 됩니다.
이 책은 최신 기술 스택이나 방법론을 맹목적으로 쫓기보다, 본질적인 설계의 가치에 대해 깊이 고민하고 싶은
개발자에게 강력히 추천합니다.
특히 애자일, TDD, 디자인 패턴 등 다양한 방법론을 접하면서도, '과연 이게 최선일까?'라는 의문을 품었던
분들에게 명쾌한 기준을 제시해 줄 것입니다.
결국, 유행은 설계를 대신하지 못합니다.
오직 읽는 사람이 덜 추론해도 되는, 즉 '명백한 코드'만이 오래 살아남는다는 메시지를 가슴에 새깁니다.
저는 이제 제가 작성하는 코드베이스에서 이 '명백성'의 레드 플래그가 어디에 가장 뚜렷하게 보이는지 찾아보려
합니다.