내가 코드 리뷰에 ChatGPT를 사용하지 않게 된 이유 (그리고 대신 사용하는 것)

지난달 나는 400줄 분량의 TypeScript 서비스 코드를 ChatGPT에 붙여넣고 보안 취약점을 검토해 달라고 요청했다. ChatGPT는 내 코드가 "잘 구조화되어 있고" "모범 사례(best practices)를 따르고 있다"고 말했다. 하지만 만약 우리가 그대로 배포했다면 교과서적인 SQL 인젝션(SQL injection)이 되었을 생(raw) SQL 문자열 결합을 놓쳤다. 그 순간 나는 LLM 코드 리뷰를 단순한 프롬프트(prompt)의 문제가 아닌 프로세스의 문제로 다루기 시작했다.

아첨 문제(The Flattery Problem)는 실재하며 과소평가되어 있다

ChatGPT는 도움이 되도록 훈련되었다. RLHF(인간 피드백을 통한 강화학습) 관점에서 '도움이 된다'는 것은 종종 긍정적이고 확언하는 태도와 상관관계가 있다. 당신이 코드를 붙여넣고 "이거 괜찮나요?"라고 물을 때, 당신은 본질적으로 사용자가 상호작용에 대해 기분 좋게 느끼기를 원하는 모델에게 질문하는 것이다. 모델은 칭찬할 거리를 찾아낼 것이다. 비판을 완화할 것이다. 말을 흐릴 것이다.

나는 충분히 많은 실험을 통해 확신할 수 있었다. 만약 당신이 자신감 있는 프레임(framing)을 사용하여 버그가 있는 코드를 ChatGPT에 붙여넣는다면 (예: "여기 내 최적화된 인증 흐름(auth flow)이 있어, 마지막으로 의견 있어?"), 동일한 코드를 붙여넣고 "이 코드에서 잘못된 점을 모두 찾아줘"라고 말할 때보다 더 호의적인 리뷰를 받게 될 것이다. 프레임이 출력을 극적으로 변화시킨다. 이것은 기능(feature)이 아니다. 코드 리뷰 맥락에서는 결함(liability)이다.

해결책은 "프롬프트를 더 잘 작성하라"가 아니다. 그것은 검토자에게 부담을 지우는 일이다. 즉, 코드를 작성했고 이미 사각지대(blind spots)를 가지고 있는 당신 자신에게 부담을 주는 것이다.

컨텍스트 윈도우(Context Windows)는 잘못된 약속이다

몇 달마다 더 큰 컨텍스트 윈도우(context window)를 가진 새로운 모델이 출시되면, 사람들은 전체 코드베이스를 붙여넣을 수 있다는 사실에 열광한다. 나도 이해한다. 나도 해봤다. 문제는 어텐션(attention)이 200k 토큰 전체에 걸쳐 균일하지 않다는 것이다. 모델은 미묘하고 포착하기 어려운 방식으로 긴 컨텍스트 추론(long-context reasoning) 능력이 저하된다. 실제 로직은 3,847행에서 변경되었는데 12행에 있는 함수를 참조할 것이다. 초기에 정의한 변수가 나중에 재정의되었다는 사실을 놓칠 것이다. 모델은 현재의 컨텍스트가 아닌, 컨텍스트의 이전 부분을 반영하는 자신감 있는 답변을 내놓을 것이다.

코드 리뷰는 시스템의 전체적인 멘탈 모델 (Mental Model)을 동시에 유지하는 것을 요구합니다. 단순히 당신이 보고 있는 파일뿐만 아니라, 서비스 간의 계약 (Contracts), ORM에 내재된 가정 (Assumptions), 그리고 세 단계 떨어진 설정 파일에 존재하는 엣지 케이스 (Edge cases)까지 모두 포함됩니다. 현재로서는 그 어떤 컨텍스트 윈도우 (Context window)도 이 문제를 해결할 수 없습니다. 그렇지 않다고 주장하는 모든 도구는 엔지니어링이 아닌 마케팅일 뿐입니다.

단일 모델 단일 재배양 (Single-Model Monoculture)의 위험성

팀 전체가 동일한 모델을 통해 AI 보조 코드 리뷰를 수행하면, 해당 모델의 사각지대를 대규모로 물려받게 됩니다. GPT-4는 특정 유형의 비동기 (Async) 버그를 놓치는 경향이 있다는 사실이 문서화되어 있습니다. Claude는 그중 일부는 더 잘 처리하지만 다른 부분에서는 더 취약합니다. 두 모델 모두 분산 시스템 (Distributed systems)에서의 미묘한 레이스 컨디션 (Race conditions)을 잡아내는 데에는 일관되게 능숙하지 않습니다.

만약 팀의 모든 구성원이 코드 리뷰를 위해 ChatGPT를 사용하고, ChatGPT가 특정 범주의 버그를 체계적으로 과소평가한다면, 그 버그들은 그대로 배포됩니다. 당신은 장애가 발생하기 전까지는 이 사실을 알 수 없습니다. 이것이 리뷰 파이프라인 (Review pipeline)에서 모델 다양성 (Model diversity)을 확보해야 한다는 논거입니다. 이는 특정 모델이 나쁘기 때문이 아니라, 단일 모델 단일 재배양 (Single-model monoculture)이 변동성 (Variance)을 제거하기 때문이며, 그 변동성이 바로 엣지 케이스를 잡아내는 핵심이기 때문입니다.

"나에게 아무것도 묻지 않았다"는 문제

당신의 코드를 리뷰하는 숙련된 시니어 엔지니어는 명확히 하기 위한 질문을 던집니다. "여기서 예상되는 규모 (Scale)는 어느 정도인가요?" "이것이 트랜잭션 (Transaction) 내에서 실행되나요?" "이 큐 (Queue)가 실행될 때 비어 있다면 어떻게 되는지 고려했나요?" ChatGPT는 기본적으로 질문을 하지 않고, 질문에 답을 합니다. ChatGPT는 빈칸을 가정 (Assumptions)으로 채우고, 그 가정된 제약 조건들을 바탕으로 리뷰를 제공합니다.

ChatGPT가 승인한 SQL 인젝션 (SQL injection) 코드를 제가 직접 리뷰했을 때, 제가 던진 첫 번째 질문은 이것이었습니다: "이 값이 사용자 입력 (User input)으로부터 오는 경우가 있습니까?" 있었습니다. ChatGPT는 질문하지 않고서는 그 사실을 알 방법이 없었고, 질문하지도 않았습니다. ChatGPT는 해당 값을 신뢰할 수 있는 것으로 가정하고 그에 따라 리뷰를 진행했습니다.

최고의 코드 리뷰 도구는 자신이 모르는 것을 자신감 넘치는 문체로 덮어버리는 것이 아니라, 무엇을 모르는지를 드러내야 합니다.

AI 코드 리뷰 도구 평가 프레임워크

리뷰 워크플로우에 어떤 AI 도구를 도입하기 전에, 다음 다섯 가지 점검을 거쳐야 합니다:

1. 적대적 프롬프트 테스트 (The Adversarial Prompt Test)
의도적으로 오류가 있는 코드를 붙여넣으세요. 모델에게 오류가 있다고 말하지 마십시오. 프롬프트를 주지 않고도 문제가 있는지 찾아내는지 확인하세요. 만약 코드를 칭찬한다면, 그 도구는 부적격입니다.

2. 가정 표출 테스트 (The Assumption Surfacing Test)
모호한 외부 의존성을 가진 함수를 도구에 리뷰하도록 요청해 보세요. 해당 의존성에 대해 질문하는가, 아니면 가정한 후 진행하는가? 가정을 하는 도구는 위험합니다.

3. 크로스 파일 일관성 테스트 (The Cross-File Coherence Test)
서로 간의 계약(contract)이 위반된 두 파일을 제공해 보세요. 해당 위반을 잡아내는지 확인하세요. 이는 도구가 실제로 컨텍스트 전반에 걸쳐 추론하는지, 아니면 단순히 파일 내에서 패턴 매칭만 하는지를 테스트합니다.

4. 오탐률 점검 (The False Positive Rate Check)
좋은 보안 리뷰는 실제 문제를 포착합니다. 하지만 모든 것을 잠재적으로 취약하다고 플래그 지정하는 도구는 신호(signal)가 아니라 잡음(noise)입니다. 그 결과 중 얼마나 많은 것이 실행 가능한지 대 일반적인 경고와 비교하여 추적하십시오.

5. 모델 다양성 테스트 (The Model Diversity Test)
만약 도구가 하나의 모델로 작동한다면, 공급업체에 어떤 사각지대(blind spots)가 있는지 물어보세요. 만약

AI Handler는 또한 각 모델이 리뷰를 생성하는 데 사용한 컨텍스트 (context)를 추적하므로, 어떤 발견 사항이 가설 (assumption)에 기반한 경우 그 가설이 묻히지 않고 드러나게 됩니다. 만약 모델이 사용자의 입력값이 정제되었다고 (sanitized) 가정했다면, 그 가설을 명시적으로 확인할 수 있습니다. 그러면 사용자는 이를 확인하거나 무시하고 수정된 리뷰를 받을 수 있습니다.

또 다른 요소는 워크플로우 통합 (workflow integration)입니다. ChatGPT 코드 리뷰의 문제는 단순히 모델의 문제가 아닙니다. 리뷰가 사용자의 PR (Pull Request), CI 파이프라인 (CI pipeline), 그리고 장애 이력 (incident history)과 단절된 채 채팅창 안에만 머물러 있다는 점입니다. AI Handler는 이들을 연결합니다. 과거 장애 사례의 패턴과 일치하는 발견 사항이 있으면, 해당 장애를 컨텍스트 (context)로 하여 플래그 (flag)가 지정됩니다. 이것은 단순한 정적 분석 (static analysis)이 아니라 조직의 기억 (institutional memory)입니다.

제가 위에서 설명한 모든 문제를 AI Handler가 해결한다고 주장하는 것은 아닙니다. 제가 주장하는 것은, AI Handler가 앞서 언급한 모든 문제로 인해 고통받았던 사람이 이를 진지하게 받아들여 만든 도구라는 점입니다.

AI Handler는 제가 구축하고 있는 통합 AI 워크플로우 (AI workflow) 도구입니다. 2026년 6월 출시 예정입니다. 베타 액세스 (beta access)를 원하시면 ceo@eternalsix.com으로 이메일을 보내주세요.