요즘 AI 도구들이 코드를 정말 빠르게 만들어내죠.
그럴 때마다
저는 이런 질문을 던지곤 합니다.
'과연 어떤 코드가 오래 이해되고, 또 수정될 수 있을까?' 빠르게 작동하는 것만큼이나, 시간이 흘러도 그 본질을
잃지 않는 코드를 만드는 것이 중요하다고 생각했거든요.
그래서 저는 존 아우스터하우트의 『A Philosophy of Software Design』, 이 책을 다시
펼쳤습니다.
특히 마지막 장들, 성능 설계와 설계 원칙, 그리고 피해야 할 '레드 플래그'들을 다루는 부분이었죠.
책을 읽기 전에는 이런 가설을 가지고 있었습니다.
'성능 최적화는 결국 설계 원칙과 충돌할 수밖에 없지 않을까?' 빨리 만들려면, 어딘가 복잡해지거나 설계의
아름다움을 포기해야 할 때가 있다고 생각했거든요.
하지만 이 책의 저자, 스탠퍼드 대학교의 존 아우스터하우트 교수는 저의 이런 고정관념을 흔들어 놓았습니다.
그는 성능 역시 '복잡성'의 문제로 봐야 한다고 말합니다.
즉, 성능을 개선하는 과정도 결국 복잡성을 줄이는 방식이어야 한다는 거죠.
이 책에서 제가 가장 깊이 공감했던 문장 중 하나는 "측정하기 전에는 수정하지 마라"는 것이었습니다.
우리는 흔히 '여기가 느릴 거야'라는 추측만으로 코드를 뜯어고치곤 하죠.
하지만 저자는 정확한 측정을 통해 진짜 병목을 찾아야 한다고 강조합니다.
근거 없는 최적화는 오히려 불필요한 복잡성만 남길 수 있다는 거죠.
그리고 '핵심 경로'의 중요성도 다시 한번 깨달았습니다.
시스템 전체의 속도를 지배하는 그 핵심적인 흐름을 먼저 파악하고, 그곳을 중심으로 설계를 해야 한다는 겁니다.
중요하지 않은 부분을 아무리 최적화해봤자, 전체 성능에는 큰 영향을 주지 못하고 오히려 코드를 더 알아보기 어렵게
만들 뿐이라는 지적에 고개를 끄덕였습니다.
가장 인상 깊었던 건, 설계 원칙에 대한 저자의 관점이었습니다.
그는 설계 원칙이 단순히 외우는 '표어'나 '체크리스트'가 아니라고 말합니다.
대신, '복잡성의 냄새를 반복해서 감지하는 루프'가 되어야 한다고 강조하죠.
마치 좋은 의사가 환자의 증상을 끊임없이 살피듯, 개발자도 자신의 코드에서 복잡성의 신호를 지속적으로 포착하고
개선하는 과정을 반복해야 한다는 겁니다.
이 책을 읽고 나니, 제 코드 리뷰 질문이 달라졌습니다.
이전에는 '이 코드가 잘 작동하는가?'에 집중했다면, 이제는 '이 코드를 다음
변경자가 얼마나 쉽게 이해하고 수정할 수 있을까?'를 먼저 묻게 됩니다.
설계는 특별한 의식이나 거창한 선언이 아니라, 우리가 매일 작성하는 이름, 경계, 예외 처리, 주석, 그리고 계층
선택 속에 녹아 있다는 것을 깨달았어요.
그래서 저는 최근에 제가 수정한 모듈 하나를 다시 열어보려 합니다.
이 모듈의 '핵심 경로'는 무엇이었는지, 그리고 불필요한 복잡성을 유발하는 성능 최적화 시도는 없었는지, 책에서
배운 관점으로 다시 한번 꼼꼼하게 들여다볼 생각입니다.
이 책은 단순히 성능 좋은 코드를 만드는 방법을 알려주는 기술서가 아닙니다.
소프트웨어 설계의 본질에 대해 깊이 고민하고 싶은 분들, 특히 성능 개선과 설계 사이에서 균형을 잡는 데 어려움을
느끼는 개발자들에게 큰 울림을 줄 것이라고 생각합니다.
AI 시대에 좋은 코드가 무엇인지 성찰하고 싶은 분들에게도 강력하게 추천하고 싶어요.
결국 이 책이 저에게 남긴 한 문장은 이것입니다.
"특정 패턴을 따르기보다, 복잡성을 감지하고 줄이는 루프를 끊임없이 돌려라." 그렇다면 이제 새로운 질문이
남습니다.
AI 에이전트가 코드를 작성할 때, 이 복잡성 감지 루프를 어떻게 검증 과정에 포함시킬 수 있을까요?