Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
본 기사는 코딩 에이전트가 코드 리뷰의 여러 기능을 수행할 수 있다는 주장에 대해 비판적인 시각을 제시합니다. 저자는 LLM 기반 에이전트가 결함 감지, 스타일 강제 등은 가능하지만, 인간만이 제공할 수 있는 '혼란', '변경 필요성 의문 제기', 그리고 '누락된 것 인식'과 같은 고차원적 검토 능력을 대체할 수 없다고 주장합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 HN OpenAI Codex의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기‘The End of Code Review: Coding Agents Supersede Human Inspection’이라는 기사의 초록은 독자들에게 다음과 같은 그림을 제시합니다…
초록– 코드 리뷰는 1976년 Fagan이 코드 검사(code inspection)를 공식화한 이래 소프트웨어 개발의 주요 품질 게이트였습니다. 지난 오십 년 동안, 동료가 병합(merge)하기 전에 변경 사항을 사람이 검토하고 의견을 제시하는 것은 모든 규모의 조직에서 핵심적인 관행이었습니다. 코딩 에이전트(coding agents)는 읽고, 쓰고, 테스트하고, 소프트웨어를 수리할 수 있는 대규모 언어 모델(LLM) 기반 자율 시스템입니다. 우리는 코딩 에이전트가 전통적인 인간 코드 리뷰가 더 이상 소프트웨어 품질 파이프라인의 필수 구성 요소가 아닌 역량 임계점을 넘었다고 주장합니다. 우리의 주장은 두 가지 주장에 근거합니다: 코드 리뷰의 모든 명시된 목표는 에이전트에 의해 더 낮은 비용과 더 높은 처리량을로 제공될 수 있으며; 에이전트가 코드를 작성하고 인간이 필수적인 검토자로 남는 순진한 통합은 의미 있는 보증을 제공하지도 않고 AI 지원 처리량에 맞춰 확장되지도 못하는 막다른 길입니다.
이 기사는 구조가 잘 짜여 있고, 연구 논문을 자주 읽지 않는 엔지니어들에게는 상당히 직관적입니다. 하지만 저는 이 주장이 **'대체 신화(substitution myth)'**라는 문제적인 틀에 비판적으로 의존한다고 생각합니다.
저자는 동료 코드 리뷰를 네 가지 명시된 기능으로 분해합니다: 결함 감지(defect detection), 스타일 강제(style enforcement), 지식 전수(knowledge transfer), 그리고 인식(awareness). 그리고 에이전트가 이 모든 것을 수행할 수 있다고 주장합니다. 물론 결론은, 만약 에이전트가 이러한 각 기능을 실행할 수 있다면, 그 에이전트는 인간 검토자를 대체할 능력을 갖추었다는 것입니다.
저는 이것이 기능으로 환원될 수 없는 동료 코드 리뷰의 몇 가지 중요한 측면을 간과하고 있다고 생각합니다:
동료 검토자의 혼란(A peer reviewer’s confusion)
경험 많은 엔지니어가 diff를 읽고 “이게 무슨 말인지 모르겠어요.”라고 말할 때, 그 혼란 자체가 발견(finding)입니다. 이는 코드가 너무 복잡하거나, 추상화가 잘못되었거나, 의도가 명확하지 않다는 것을 의미합니다. LLM은 항상 코드를 처리할 수 있다는 의미에서 ‘이해’할 것입니다. 인간의 합법적인 이해 불가 신호는 줄 수 없습니다. 이 글은 가독성(comprehensibility)을 다른 어떤 것보다 스타일과 관련된 것으로 다룹니다. 그렇지 않습니다. 그것은 창발적 속성(emergent property)이며, 사람(artifact를 이해하려는 시도)과 그 아티팩트 자체의 상호작용에서 나타납니다.
변경 자체가 필요한지에 대한 자격 있는 회의론
예를 들어 다음과 같은 질문을 던지는 것입니다:
“이게 정말 두 개의 PR로 되어야 할까요?”
또는
“이건 증상만 해결할 뿐, 근본적인 문제는 아닙니다.”
이것들은 변경의 의도(intent), 범위(scope), 그리고 적절성(appropriateness)에 대한 질문입니다. 이 모든 것은 코드가 “올바른지” 여부보다 먼저 발생합니다. 이 글의 틀은 a) 검토 중인 코드 변경이 필요하며, b) 검토의 주된 목적이 검증이라고 가정합니다.
하지만 프로덕션 환경과 접촉해 본 사람이라면 누구나 코드 리뷰가 때로는 변화 자체가 필요한지 여부를 의문을 제기할 수 있는 마지막 (혹은 유일한) 순간이라는 것을 이해합니다.
존재하지 않는 것을 볼 수 있는 능력
인간 검토자는 API 계약이 변경되었지만 에러 처리는 바뀌지 않았다는 것을 알아차릴 수 있습니다. 그들은 무엇이 누락되었는지를 알아차릴 수 있습니다. 다시 말해, 존재할 것으로 기대되는 것이 있지만 그렇지 않은 것을 인식하는 것입니다. 이 글은 이를 전혀 인정하지 않는데, 이는 특히 흥미롭습니다. 왜냐하면 부재성 맹점(absence blindness)은 LLM이 상당히 취약한 실패 유형이기 때문입니다.
에이전트는 존재하는 것(what is there)을 검토하고; 전문 지식을 가진 엔지니어는 누락된 것(what’s missing)을 쉽게 알아차릴 수 있습니다.
누가 코드를 작성했는지가 리뷰의 심층도를 좌우합니다.
동료 코드 리뷰어는 종종 동료인 해당 코드 작성자와의 과거 경험에서 비롯되는 일종의 *조정된 주의(calibrated attention)*를 가지고 있습니다. 예를 들어, 경력이 적은 엔지니어가 결제 모듈에 처음 커밋하는 것은 숙련되고 '회색 수염'을 가진 엔지니어의 루틴 리팩토링과는 다른 주목을 받을 가능성이 높습니다.
리뷰어들은 일반적으로 상황의 누가(who), 무엇(what), 언제(when), 어디서(where)를 자신들의 위험이 존재하는 경험과 일치시킵니다.
해당 논문은 모든 diff를 동등한 입력으로 취급하는 것 같습니다.
코드 리뷰는 양방향적이며 건설적이다
제 생각에 이 논문은 지식 전수를 단순히 정보 전달로 축소합니다. 에이전트는 그저 '설명을 생성'할 뿐입니다. 하지만 코드 리뷰에서의 토론은 공동의(joint) 인지 활동입니다. 동료 리뷰어는 작성자의 접근 방식에 대해 배우고, 작성자는 리뷰어들의 질문을 통해 배우며, 결과적으로 어느 당사자도 논의 이전에 가지고 있지 않았던 공유된 이해가 형성됩니다.
이것은 단순한 전송이 아닌 공동적(coactive) 작업입니다. 에이전트의 요약은 두 참여자의 정신 모델(mental models)을 변화시키는 대화의 대체재가 될 수 없습니다.
리포지토리 외부에서 존재하는 운영적 맥락
“지난 화요일에 이 서비스에서 문제가 발생했습니다.”
“이 다운스트림 소비자(downstream consumer)를 소유한 팀이 해당 인터페이스를 곧 폐기할 예정입니다.”
“법무팀에서 더 이상 이 필드를 로깅하지 말라고 했습니다.”
인간 리뷰어는 자신이 인식하는 것보다 훨씬 많은 맥락적 지식(contextual knowledge)을 가지고 있으며, 심지어 야생 상태에서 연결 고리를 인식할 수 있습니다. 사람들은 테스트, 문서, 버전 관리 시스템에 포착되지 않은 조직의 현재 상태, 최근 사건들, 비공식적인 합의를 이해하며, 이것들이 검토 중인 코드에 어떻게 영향을 미칠 수 있는지 인식할 수 있습니다. 이는 너무 자주 일어나서 거의 눈에 보이지 않습니다.
해당 논문은 코드베이스가 완전한 맥락이라고 가정합니다. 하지만 결코 그렇지 않습니다.
코드에 대한 책임(Accountability)은 단순한 관료적 형식주의가 아니다
이 논문은 인간의 책임을 규정 준수(compliance) 아티팩트로 다루며, 법적 또는 기타 규칙 관련 목적으로 ‘명시된 인간(named human)’으로 간주합니다. 하지만 자신이 변경 사항을 승인하는 데 개인적인 책임이 있다는 것을 인지하는 것은 검토 방식 자체를 형성합니다. 이것이 바로 ‘직접 이해관계가 걸린 상황(skin in the game)’입니다. 풀 리퀘스트(pull request)에 ‘서명’하는 에이전트는 아무런 결과도 지지 않으며, 진지한 평가를 촉진할 만한 인센티브 구조 또한 없습니다. 비록 이 논문이 토론 섹션에서 윤리적 우려 사항을 포함하고는 있지만, 결국 이를 ‘요구사항 공학(requirements engineering) 및 배포 후 모니터링’으로 돌리는 것은 저에게 있어 시간을 끄는 방식(hand-waving way of kicking the can down the road)처럼 느껴집니다.
제가 이 논문에서 가장 근본적인 문제라고 생각하는 부분은, 코드 리뷰가 무엇보다도 탐지(detection) 과정이라고 가정한다는 점입니다. 즉, 결함, 스타일 위반, 보안 문제 등을 찾아내고, 이러한 탐지를 더 빠르고 저렴하게 하는 것이 보편적으로 더 낫다고 전제합니다.
하지만 코드 리뷰는 또한 조정(coordination) 과정이자, 의미 구성(sensemaking) 과정이며, 거버넌스(governance) 과정이기도 합니다.
대체 신화(substitution myth) 역시 종종 같은 방식으로 진행됩니다:
이러한 접근 방식은 종종 같은 지점에서 무너집니다. 가장 중요했던 인간의 기여는 바로 기능 간의 *통합(integration)*이었기 때문입니다. 사람들은 계획에 없던 상황과 맥락에 적응하고, 기대되는 사회적 책임(social accountability)을 수행하는 능력이 있습니다.
이러한 상황에서 적응하는 능력은 위에서 언급된 초기 분해 단계 #1에서는 고려되지 않았습니다.
저 역시 이 부분이 원래 논문에서 다루어졌다고 생각하지 않습니다.