주석의 근본적인 문제점
소프트웨어 공학 분야의 선구자들은 오랫동안 “스스로를 설명하는 코드(self-documenting code)”를 꿈꿔왔습니다. 브라이언 커니핸과 필립 제임스 플라우거는 “컴퓨터 프로그램의 유일하게 신뢰할 수 있는 문서는 코드 그 자체”라고 했으며, 로버트 마틴은 “언어가 충분히 표현력이 있다면 주석이 거의 필요 없을 것”이라고 주장했습니다. 그러나 이들에게는 이를 강제할 도구가 부족했습니다.
주석은 두 가지 주요 방식으로 실패합니다.
-
불분명함: 작성자에게 명확해 보이는 주석도 시간이 지나면 유지보수하는 개발자에게는 모호하게 느껴질 수 있습니다. 데이비드 파나스는 “작성자에게 명확하고 적절해 보이는 문서는 6개월 또는 6년 후에 코드를 유지보수해야 하는 프로그래머에게는 진흙처럼 모호하다”고 지적했습니다.
-
부패: 주석은 코드와 함께 자동으로 진화하지 않는 정적 메타데이터입니다. 구현이 변경되었음에도 주석이 업데이트되지 않으면, 이는 잘못된 정보를 제공하고 버그를 유발하며 디버깅 시간을 낭비하게 만듭니다. 앤드류 헌트와 데이브 토마스는 “신뢰할 수 없는 주석은 아예 없는 것보다 나쁘다”고 경고했습니다.
LLM을 활용한 주석 문제 해결
이제 LLM이라는 강력한 도구가 이 두 가지 문제를 해결할 수 있습니다.
-
온디맨드 문서 생성: 개발자가 수동으로 Javadoc 블록을 작성하는 대신, IDE는 LLM을 통해 필요할 때마다 코드의 의도를 요약한 문서를 생성할 수 있습니다. 이 문서는 항상 최신 코드 기반으로 생성되므로 부패할 염려가 없으며, 현대 LLM은 대부분의 인간보다 이 작업을 더 잘 수행합니다.
-
코드 해석 가능성 점수(CIS) 도입: LLM을 빌드 파이프라인에 통합하여 모든 함수의 코드 해석 가능성 점수(CIS)를 평가할 수 있습니다.
- LLM이 코드 로직을 설명하는 데 낮은 신뢰도를 보인다면, 이는 코드가 너무 영리하거나 복잡하다는 신호입니다.
- 컴파일러는 이 점수에 임계값을 설정하여, CIS가 너무 낮으면 빌드를 실패시킬 수 있습니다.
- 이는 코드의 가독성을 주관적인 선호도에서 객관적이고 측정 가능한 품질 게이트로 전환시킵니다.
주석의 완전한 금지
CIS 게이트가 도입되면 수동 주석은 불필요할 뿐만 아니라 해롭게 됩니다. 주석은 코드와 모순될 수 있는 ‘두 번째 진실의 원천’을 도입하기 때문입니다. 따라서 주석을 완전히 금지하는 것이 논리적인 결론입니다. 이는 개발자들이 본질적으로 기계가 해석할 수 있는 깨끗하고 구조화된 로직을 작성하도록 강제합니다. 로버트 마틴이 더 표현력 있는 언어를 원했지만, 이제는 어떤 언어든 해석할 수 있는 LLM이 있다면 더 나은 언어보다는 LLM의 해석 능력이 중요합니다. LLM이 코드를 설명할 수 없다면, 우리는 프로그래머를 비난하고 빌드를 중단해야 합니다.