코드를 작성하다
보면 문득 이런 질문이 들 때가 있습니다.
인공지능 도구와 자동화가 코드를 더 빨리 만들어내는 시대에, 과연 어떤 코드가 오래 이해되고 수정될 수 있을까?
그리고 그 코드를 만드는 과정, 즉 '설계'란 무엇일까?
이 질문을 안고 존 오스터하우트의 이라는 책을 다시 펼쳤습니다.
특히 이번 여섯 번째 독서 회차에서는 '두 번 설계하고, 이유를 남겨라'는 메시지가 깊이 다가왔습니다.
책을 읽기 전 저는 '주석'이라는 것을 코드를 설명하는 부수적인 것으로 여기는 경향이 있었습니다.
하지만 이 책은 주석의 역할을 단순히 코드 뒤에 붙는 설명이 아니라, '설계 이유를 보존하는 도구'로 끌어올릴
것이라는 기대를 했습니다.
또, '설계'라는 것이 거창한 아키텍처 선언이 아니라, 매일의 코드 작성 속에서 일상적으로 이루어지는 복잡성
관리라는 점을 더 깊이 이해하고 싶었죠.
이 책은 제가 가졌던 막연한 생각들을 명확하게 정리해주었습니다.
핵심은 '보이지 않는 이유'를 드러내는 장치로서의 설계입니다.
저자는 두 가지 중요한 원칙을 제시하는데, 하나는 '두 번 설계하라 Design it Twice'는 것이고, 다른
하나는 '왜 주석을 남겨야 하는가 Why Write Comments?'입니다.
'두 번 설계하라'는 말은 첫 번째 설계안을 정답이 아니라, 그저 비교를 시작하기 위한 하나의 '후보'로 취급하라는
의미입니다.
우리는 대개 처음
떠오른 아이디어를 너무 쉽게 받아들이곤 하죠.
하지만 이 책은 최소한 두 가지 설계안을 비교할 때 비로소 숨어있던 가정이 드러나고, 각 대안의 장단점이
명확해진다고 말합니다.
저 역시 여러 대안을 고민할 때야 비로소 제가 놓쳤던 부분들이 보였던 경험이 많기에, 이 부분에 깊이 공감했습니다.
설계는 무언가를 '생성'하는 행위라기보다, 여러 가능성 중에서 가장 나은 것을 '비교하고 선택하는' 과정이라는
깨달음이었습니다.
그리고 '주석'에 대한 제 생각도 크게 바뀌었습니다.
흔히 '좋은 코드는 스스로를 설명한다
self-documenting'는 말을 듣곤 합니다.
저 역시 이 말에 현혹되어 주석을 소홀히 한 적이 많습니다.
하지만 책은 명확한 코드가 '무엇'을 하는지는 보여줄 수 있지만, '왜' 그렇게 했는지, '어떤 대안을 고려하다가
지금의 방식을 선택했는지'와 같은 의도와 맥락까지는 말해주지 못한다고 지적합니다.
좋은 주석은 코드의 내용을 중복해서 설명하는 것이 아니라, 설계 판단의 '장기 기억'이라는 것이죠.
미래의 내가, 혹은 동료가 코드를 이해하고 수정해야 할 때, 가장 필요한 정보는 바로 이 '이유'와 '맥락'이라는
겁니다.
이 책을 읽고 난 뒤, 제 작업 방식에 한 가지 중요한 변화를 주려고 합니다.
바로 '코드 리뷰'의 질문을 바꾸는 것입니다.
단순히 "이 코드가 잘 작동하는가?"에서 멈추는 것이 아니라, "이 코드를 다음
변경자가 이해하고 수정하려면 무엇을 알아야 하는가?"라는 질문을 던져보기로 했습니다.
그리고 그 답을 주석이나 짧은 문서 형태로 남기는 연습을 해보려고 합니다.
이는 마치 '아키텍처 결정 기록 Architecture Decision Record'를 코드 가까이에 남기는 것과
연결된다는 생각도 들었습니다.
새로운 모듈을 설계하거나 기존 코드를 수정할 때, 최소한 하나의 다른 설계안을 고민하고, 그 비교 과정을 짧게라도
기록하는 습관을 들이는 것이죠.
이 책은 매일 코드를 작성하고 수정하는 개발자들에게 특히 의미 있는 책이라고 생각합니다.
또, 코드 리뷰를 통해 동료의 성장을 돕고 싶은 리더들, 그리고 인공지능 자동화 시대에 인간 개발자의 역할과 가치에
대해 고민하는 모든 분께 권하고 싶습니다.
결론적으로, 이 책이 저에게 남긴 한 문장은 이렇습니다.
"설계의 품질은 첫 아이디어의 반짝임보다, 대안을 비교하고 그 이유를 남기는 습관에서 나온다." 이 문장을
곱씹으며, 다음
독서 질문을 던져봅니다.
"인공지능 에이전트가 코드를 작성할 때, 과연 이런 '이유'와 '대안'의 흔적을 어떻게 효과적으로 남길 수
있을까?" 그리고 그 흔적이 미래의 나에게 어떤 질문을 던지게 될까요?