여전히 AI 에이전트의 코드를 검토해야 할까요?

모든 팀에서 논쟁은 같은 방식으로 시작됩니다. 한 쪽은 에이전트들이 이제 우리가 예전처럼 승인하던 풀 리퀘스트의 절반보다 더 깔끔한 코드를 작성한다고 주장하며, 왜 여전히 모든 줄을 읽고 있는지 묻습니다. 다른 쪽은 우리가 서명한 사람들인데 그렇다고 주장합니다.

두 쪽 모두 맞습니다. 그래서 논쟁은 결코 끝나지 않습니다. 질문이 잘못되었기 때문에 끝나지 않으며, 질문을 수정하면 답변은 거의 지루해집니다.

모든 줄을 읽지 않고 배포하는 것에 대한 주장

가장 강력한 낙관적인 주장에서 시작하세요. 이는 대부분의 리뷰어들이 인정하는 것보다 더 강력합니다.

명확한 사양과 테스트 스위트가 있는 범위가 정해진 작업에서, 현대의 코딩 에이전트는 마감일 아래에서 일하는 중간 인간보다 더 일관된 코드를 생성합니다. 오류 경로에서 지루해하지 않습니다. 금요일 오후 6시에 널 체크를 작성합니다. 주어진 프로젝트 규칙을 매번 따르며, 피곤한 개발자가 스스로 허용하는 작은 조용한 반란 없이 진행합니다.

인간 리뷰는 에이전트가 도착하기 전에 이미 깨져 있었습니다. 실제 팀에서 일해본 사람이라면 LGTM 반응을 알고 있습니다: 리뷰어의 주의는 몇 백 줄 후에 무너지고, 그 뒤의 승인들은 기술적이지 않고 사회적입니다. 우리는 엄격한 리뷰의 황금기를 잃은 것이 아닙니다. 우리는 이미 대부분이 연극이었던 의식을 잃었습니다.

그 다음은 볼륨입니다. 다섯 개의 에이전트를 병렬로 실행하는 한 개발자는 한 시간에 어떤 인간도 주의 깊게 읽을 수 있는 것보다 더 많은 diff를 생성합니다. "모든 것을 읽어라"라는 규칙이 있다면, 당신은 조용히 자동화한 병목 현상을 다시 설치한 것입니다. 900줄의 diff를 훑어보는 인간은 지식을 생성하지 않고 서명을 하며, 이는 전혀 검토하지 않는 것보다 더 나쁩니다. 왜냐하면 그것은 보장이 없는 곳에서 보장을 만들어내기 때문입니다.

diff에 인간을 유지해야 하는 이유

이제 반대쪽, 즉 열광자들이 인정하는 것보다도 더 강력한 쪽입니다.

책임은 이전되지 않습니다. 모델은 새벽 3시에 호출되지 않습니다. 사고 검토에 참여하지 않으며, 데이터가 유출된 고객과 대화하지 않고, 변경의 결과를 다음 분기로 가져가지 않습니다. 병합하는 사람은 결과를 소유하며, 리뷰는 소유권이 단순히 선언되는 것이 아니라 행사되는 방법입니다.

에이전트 리뷰어는 에이전트 저자와 같은 방향으로 실패합니다. 이는 "다른 에이전트에게 검토를 맡기자"는 제안을 실제로 해결하는 논거입니다. 동일한 모델 계열의 두 에이전트가 동일한 맥락을 부여받으면, 그들은 선입견, 훈련 데이터를 공유하고 맹점을 공유합니다. 그들의 오류는 상관관계가 있습니다. 두 번째 에이전트는 누락된 테스트나 처리되지 않은 오류를 기꺼이 잡아내지만, 처음에 버그를 발생시킨 도메인에 대한 미묘한 오해를 기꺼이 승인합니다. 왜냐하면 그것도 같은 오해를 했기 때문입니다. 같은 방향에서 잘못된 두 리뷰어는 리뷰를 더하지 않습니다.

측정치도 좋지 않습니다. 산업 데이터에 따르면, 리뷰어는 AI 생성 변경 사항에 대해 인간이 작성한 것보다 의미 있게 더 많은 라운드를 교환합니다: 코드는 더 빨리 도착하고 신뢰할 수 있게 되기까지 더 오랜 시간이 걸립니다. 2026년 1월 연구는 에이전트 생성 변경 사항이 인간이 작성한 것보다 더 많은 중복성과 더 많은 누적 기술 부채를 가지고 있으며, 리뷰어는 그것을 승인하는 것에 대해 더 나은 느낌을 받는다고 밝혔습니다. 코드의 느낌과 실제 품질 사이의 그 격차가 한 문장으로 전체 위험을 설명합니다.

논쟁이 잘못된 프레임으로 설정되어 있습니다

회의를 끝내는 재구성입니다.

당신은 저자를 불신해서 코드를 검토하는 것이 아닙니다. 당신은 서명하는 사람이기 때문에 검토하는 것입니다. 이는 완전히 다른 활동이며, 전체 논쟁은 이를 혼동하는 데서 비롯됩니다.

그렇게 보게 되면 "에이전트가 인간보다 나은가"라는 질문은 결정적인 질문이 아닙니다. 결정적인 질문은: 이 변경이 잘못되면, 그것을 알아내는 데 얼마나 비쌀 것이며, 되돌리는 데 얼마나 비쌀 것인가? 마케팅 헤드라인의 오타는 몇 초 만에 발견되고 몇 초 만에 되돌려집니다. 권한 미들웨어에서 반전된 권한 체크는 고객이나 규제 기관에 의해 발견되며, 실제로 되돌려지지 않습니다. 그때는 데이터가 이미 읽혔기 때문입니다.

따라서 답변은 "모든 것을 검토하라"도 아니고 "에이전트를 신뢰하라"도 아닙니다. 그것은:

당신은 줄을 검토하는 것을 중단합니다. 위험을 검토하기 시작합니다.

구체적으로, 검토는 작업의 중간에서 두 경계로 이동합니다. 이전: 잘못된 계획이 완벽하게 실행되는 것이 가장 비싼 실패 모드이므로 계획을 읽어야 하며, 계획은 15줄로 900줄보다 짧습니다. 이후: 폭발 반경에 비례하여 diff를 읽습니다. 그 사이의 줄은 기계에 속합니다.

"에이전트가 잘못했다"는 실제 모습

팀에 가져갈 수 있는 가장 유용한 것은 의견이 아니라 객관적인 신호 목록입니다. "코드가 이상하다"가 아니라, 1분 이내에 diff에서 확인할 수 있는 신호입니다. 다음은 그 자리를 차지한 것들입니다.

1. 테스트가 코드와 같은 커밋에서 변경되었습니다. 초록색은 관찰된 것이 아니라 구성된 것입니다. 이는 목록에서 가장 신호가 강한 항목이며, 가장 먼저 확인해야 할 것입니다.
2. 주장이 약화되었거나 테스트가 비활성화되었습니다. skip, only, 새로운 코드가 반환하는 것을 수용하도록 넓혀진 주장, 테스트가 노출해야 했던 오류를 삼키는 try/catch.
3. diff가 작업보다 큽니다. 아무도 요청하지 않은 파일이 수정되었습니다. 에이전트의 범위 확장은 열정이 아니라, 에이전트가 목표를 어딘가에서 재해석했다는 신호입니다.
4. 발명된 표면. 존재하지 않는 API 메서드, 구성 옵션 또는 경로. 에이전트의 머리 속에서는 컴파일되지만 다른 곳에서는 그렇지 않습니다.
5. 코드 대신 환경이 수정되었습니다. 하드코딩된 절대 경로, 기계 특정 값, 개인 토큰, 사용자 이름. 증상은 에이전트의 기계에서 사라지고 다른 모든 사람에게 이동합니다.
6. 요청 없이 의존성이 나타났습니다. 새로운 공급망, 새로운 라이센스, 새로운 유지 관리 표면, 유지 관리하지 않을 무언가에 의해 결정되었습니다.
7. 재사용 대신 중복. 이미 20줄 떨어진 곳에 존재하는 헬퍼를 재구현했습니다. 이는 측정된 부채의 메커니즘입니다: 각 변경 사항은 지역적으로 합리적으로 보이며, 코드베이스는 조용히 동일한 작업을 수행하는 세 번째 방법을 얻습니다.
8. 요약이 diff와 일치하지 않습니다. 테스트가 실행되지 않았을 때 "수정 및 테스트됨". 내러티브는 작업이 발생했는지 여부와 관계없이 동일한 확신으로 생성되므로, 이를 검증해야 할 주장으로 취급하고 보고서로 취급하지 마십시오.
9. 지침이 더 이상 따르지 않습니다. 조용히 떨어진 작은 규칙은 세션이 시작되기 전에 어떻게 열화되는지를 보여줍니다. 컨텍스트 파일의 카나리아를 사용하는 경우, 이는 정확히 잡아내기 위해 존재하는 것입니다.
10. 민감한 영역이 지나치게 다루어졌습니다. .env 읽기, 새로운 아웃바운드 네트워크 호출, 사용자 데이터를 포함하는 새로운 로그 라인, 기능 커밋에 포함된 마이그레이션.

목록에 없는 것을 주목하세요: 스타일, 명명, 포맷팅, "내가 다르게 했을 것" 등. 이는 항상 인간 리뷰의 가장 약한 부분이었으며, 이제는 진정으로 인간의 낭비입니다. 이를 리뷰에서 삭제하면 위의 10개 항목에 필요한 주의를 다시 얻을 수 있습니다.

변경 사항은 얼마나 많은 리뷰를 받을 자격이 있나요?

diff 크기가 아니라 폭발 반경이 결정합니다. 오늘 오후 팀이 채택할 수 있는 표:

diff의 크기는 리뷰에 걸리는 시간을 알려줍니다. 폭발 반경은 선택 사항인지 여부를 알려줍니다.

행은 신뢰 수준에 관한 것이 아닙니다. 그것은 잘못될 비용에 관한 것이며, 이는 코드의 속성이지 누가 작성했는지의 속성이 아닙니다. 그것이 표를 사용할 수 있게 만드는 이유입니다: 팀이 에이전트의 품질에 대해 동의할 필요 없이 표에 동의할 수 있습니다. 팀이 철학적 질문에 대해 교착 상태에 빠지면, 이를 건너뛰고 행을 협상하십시오. 얼마나 빨리 수렴되는지 놀랄 것입니다.

유럽에서 개인 데이터를 처리하는 제품이라면, 법에 의해 맛이 아닌 하나의 행이 추가됩니다: AI가 구축한 기능이 GDPR을 준수해야 하는 사항은 판단의 문제가 아니며, "에이전트가 작성했다"는 방어가 된 적이 없습니다.

다섯 개의 에이전트가 동시에 실행될 때 무엇이 변하는가

위의 모든 것은 변경 사항을 볼 수 있다고 가정합니다. 병렬 에이전트가 있을 때, 그 가정은 먼저 깨지며, 특정 방식으로 깨집니다: diff는 단일 저자가 없습니다. 세 개의 에이전트가 마지막 커밋 이후 작업 트리를 수정했으며, "누가 이 파일을 변경했으며 어떤 작업의 일환으로 변경했는가"라는 질문은 더 이상 명확한 답이 없습니다. 귀속 없이 검토하는 것은 검토가 아니라 고고학입니다.

이는 도구 문제이며, AgentsRoom이 에이전트가 있는 곳에 리뷰를 두는 이유입니다:

• Review Mode는 커밋되기 전에 에이전트가 만든 모든 변경 사항을 읽을 수 있는 diff로 보여줍니다. 이는 "폭발 반경에 비례하여 diff를 읽는" 단계로, 사람들이 실제로 수행할 수 있을 만큼 저렴해졌습니다.
• 에이전트별 리뷰는 해당 diff를 에이전트별로 필터링하고 각 에이전트의 작업을 별도로 커밋할 수 있게 합니다. 다섯 개의 병렬 에이전트는 읽을 수 없는 작업 트리 대신 다섯 개의 검토 가능한 단위가 되며, 나쁜 변경 사항은 그것을 생성한 작업에 귀속됩니다.
• 커밋 메시지는 실제 diff에서 생성됩니다 커밋 필드의 반짝이 버튼을 사용하여, 이력이 무엇이 변경되었는지를 설명하도록 합니다. 이는 에이전트가 무엇을 하고 있다고 말했는지와는 다릅니다. 그 구분은 새벽 3시에, 여섯 달 후에 중요합니다.

이 모든 것이 판단을 대체하지는 않습니다. 그것은 판단을 행사하지 않는 것에 대한 변명을 제거합니다.

기계가 줄을 소유하게 하세요

줄을 읽는 것을 중단하고 싶다면, 다른 무언가가 그것을 읽어야 합니다. 실제로 네 가지가 그 부담을 지고 있습니다:

에이전트가 작성하지 않은 테스트가 코드와 같은 숨결로 작성되었습니다. 먼저 작성되었거나 다른 에이전트에 의해 작성되었거나 최소한 그들의 변경으로 검토되었습니다. 코드와 그 테스트가 같은 세대에서 나오면, 독립적인 증거가 되지 않습니다.

다른 모델을 가진 리뷰어. 이는 상관된 실패 문제에 대한 실질적인 답변입니다. 두 번째 에이전트가 리뷰를 한다면, 저자와 다른 제공자나 모델 계열에서 실행하세요. 오류를 완전히 비상관화할 수는 없지만, Claude가 작성한 코드에 대한 Codex 계열 리뷰어는 동일한 모델 리뷰어와는 측정 가능하게 다른 문제 클래스를 잡아냅니다. 왜냐하면 그것은 저자의 선입견을 공유하지 않기 때문입니다.

지치지 않는 게이트. 타입, 린트, 비밀 스캔, 커버리지 바닥, 기능과 함께 묶인 마이그레이션을 거부하는 CI. 게이트로 표현할 수 있는 모든 규칙은 다시는 주목할 필요가 없는 규칙입니다.

자기 닫힘 루프. 계획에 따라 자신의 작업을 빌드하고 실행하며, 무엇이든 넘기기 전에 반복하는 에이전트는 "실행조차 하지 않았다"는 전체 범주를 리뷰에서 제거합니다. 이는 자기 수정 에이전트 루프이며, 에이전트가 diff를 생성하는 것과 결과를 생성하는 것의 diff입니다. 이는 인간이 서명해야 하는 질문에 대한 답변을 제공하지 않습니다. 단지 인간이 이미 작동하는 무언가에 서명하고 있다는 것을 의미합니다.

그래서, 여전히 검토하나요?

네, 그리고 오늘보다 덜 합니다.

책임을 느끼기 위해 줄을 읽는 것을 중단하세요. 비싼 실수가 발생하는 곳이기 때문에, 이전에 계획을 읽으세요. diff를 폭발 반경에 비례하여 읽으세요. 기분이 아니라 사다리를 사용하세요. 인증, 결제, 권한, 개인 데이터 및 되돌릴 수 없는 모든 것에 대해 인간을 개인적으로 유지하세요. 모델은 책임을 지지 못하며, 두 번째 에이전트는 첫 번째의 맹점을 공유합니다. 나머지는 테스트, 타입, 게이트 및 저자의 모델을 공유하지 않는 리뷰어에게 맡기세요.

이것을 잘못 이해하는 팀은 두 가지 방향 중 하나로 실패하며, 둘 다 피할 수 있습니다. 하나는 모든 것을 검토하고 병목 현상이 되어 조용히 읽지 않고 승인하기 시작하며, 이는 최악의 두 세계입니다. 다른 하나는 아무것도 검토하지 않고 두 달 동안 빠르게 배포한 후, 누적된 부채를 갚는 데 한 분기를 소비합니다.

당신의 스탠드업에서의 논쟁은 실제로 에이전트가 좋은지에 관한 것이 아닙니다. 누가 서명할 의향이 있는지에 관한 것입니다. 그에 답하면, 리뷰 정책이 저절로 작성됩니다.

자주 묻는 질문

AI 생성 코드를 여전히 검토해야 할까요?

네, 하지만 모든 것을 줄마다 검토할 필요는 없습니다. 에이전트가 시작하기 전에 계획을 검토하고, 변경 사항이 무엇을 깨뜨릴 수 있는지에 비례하여 diff를 검토하세요. 문구 및 CSS는 훑어보세요. 인증, 결제, 권한, 개인 데이터 및 마이그레이션은 매번 인간이 줄마다 읽어야 합니다.

AI 에이전트가 다른 AI 에이전트의 코드를 검토할 수 있나요?

도움이 되지만, 위험한 코드에 대한 인간의 대체물은 아닙니다. 동일한 모델 계열의 두 에이전트가 동일한 맥락을 부여받으면 같은 방향으로 실패하는 경향이 있습니다. 그들의 오류는 상관관계가 있으므로, 두 번째 에이전트는 오타와 누락된 테스트를 잡아내지만 버그를 발생시킨 맹점을 공유합니다. 에이전트 리뷰어를 사용하는 경우, 저자와 다른 모델에서 실행하세요.

AI 에이전트가 실수를 했는지 어떻게 알 수 있나요?

스타일을 읽기보다는 diff에서 객관적인 신호를 찾으세요. 가장 강력한 신호: 테스트가 코드와 같은 커밋에서 변경되었으며, 이는 초록색이 관찰된 것이 아니라 구성된 것임을 의미합니다. 다른 신호로는 범위 확장, 비활성화되거나 약화된 주장, 발명된 API, 하드코딩된 로컬 경로 및 diff와 일치하지 않는 요약이 있습니다.

AI 에이전트가 인간 코드 리뷰어를 대체할까요?

그들은 이미 대부분의 줄 읽기를 대체했습니다. 서명은 대체할 수 없습니다. 책임은 모델로 이전되지 않으므로, 인간은 되돌리기 어려운 모든 것에 대해 병합 결정을 여전히 소유합니다.

AI 코드를 줄마다 검토해야 하나요?

폭발 반경이 정당화되는 곳에서만 그렇습니다. 줄마다 검토는 몇 개의 에이전트가 병렬로 실행되는 것을 넘어 확장되지 않으며, 오후 6시에 900줄의 diff를 훑어보는 인간은 지식을 생성하지 않고 서명을 합니다. 그 주의를 되돌리기 어려운 변경 사항에 집중하세요.

인간 리뷰 없이 절대 병합해서는 안 되는 것은 무엇인가요?

인증, 결제, 권한, 개인 데이터, 데이터베이스 마이그레이션, 삭제 경로 및 인프라에 영향을 미치는 모든 것입니다. 이들은 하나의 속성을 공유합니다: 잘못될 비용은 diff의 크기에 비례하지 않습니다.