2026년 6월 현재, 코딩 에이전트의 성능이 급격히 끌어올려지면서 엔지니어링의 어려운 지점은 "코드 작성"에서 "그 코드를 신뢰할지 판단하는 일"로 이동하고 있습니다. 작성은 거의 공짜가 됐지만, 이해와 검증은 여전히 비싸기 때문입니다. GeekNews가 Addy Osmani의 서브스택 글을 인용해 정리한 이번 화두는, AI 산출량은 폭증했지만 실제 가치는 그에 훨씬 못 미친다는 일관된 측정 결과입니다.

1. 2026년 데이터가 실제로 보여주는 것
수년간 일화·논쟁이던 주장이 이제 이해관계가 다른(일부는 경쟁 관계인) 조직들에 의해 대규모로 측정됐고, 동일한 결론이 도출됩니다. AI는 산출량은 급증시키되 품질과 리뷰 가능성은 떨어뜨린다는 것입니다.
Faros AI가 4,000개 팀·22,000명 개발자를 추적한 결과(2026년 3월 데이터)에 따르면, 저(낮은) AI 도입에서 고(높은) AI 도입으로 전환할 때 긍정적으로는 엔지니어당 처리량이 상승했지만, 부정적으로는 코드 churn이 861% 증가, 인시던트 대 PR 비율이 242.7% 증가, 개발자당 결함률이 9%에서 54%로 뛰었고, 중앙값 리뷰 소요 시간은 441.5% 증가(첫 리뷰까지 시간·평균 리뷰 시간 모두 약 2배)했습니다. 무리뷰 머지 PR도 31.3% 늘었는데, 이는 누구도 의도적으로 선택한 게 아니라 리뷰어가 물량을 따라가지 못해 읽히지 않은 코드가 그냥 머지되는 일상이 됐기 때문입니다. 성숙하고 규율 잡힌 엔지니어링 관행을 가진 팀도 동일하게 타격받았고, 좋은 프로세스도 물량이 설계 속도보다 빨리 도착하는 상황은 막지 못했습니다.
CodeRabbit 연구(2025년 12월)는 오픈소스 PR 470개(AI 공동 작성 320, 사람만 150)를 분석해 AI 변경이 약 1.7배 많은 이슈를 동반한다고 보고했습니다. 로직·정확성 문제는 약 75% 증가, 보안 이슈는 1.5~2배 증가, 가독성 문제는 3배 이상 증가했습니다. GitClear 생산성 데이터(2025년까지)는 매일 AI를 쓰는 사용자가 비사용자 대비 약 4배 원시 산출량을 내지만, 1년 전 자신 대비 실제 생산성 향상은 약 12%에 불과하다고 측정했습니다. 4배의 코드를 사람이 전부 리뷰해야 하는 구조입니다. GitHub 보고에 따르면 Copilot 리뷰는 누적 6천만 건 이상 실행됐고 1년 만에 10배 증가, 플랫폼 리뷰 5건 중 1건 이상이 에이전트 관여입니다. 더 이상 틈새 관행이 아니라 코드가 만들어지는 방식 자체가 달라지고 있습니다.
2. 모두가 서로 다른 문제를 풀고 있음
위 경고성 데이터 대부분은 엔터프라이즈 텔레메트리와 압도된 오픈소스 메인테이너에게서 나온 것이므로, 소수만 쓰는 것을 만드는 1인 개발자에게는 상당 부분 그대로 적용되지 않습니다. 위치를 결정하는 세 변수는 blast radius(망가졌을 때 일어나는 일 — 아무 일도 없거나, 분노한 사용자·금전·PII 노출), 코드의 수명(다음 주 다시 쓸 일회성 프로토타입인지, 수년간 유지할 코드베이스인지), 이해해야 하는 사람 수(머릿속에 전부 담은 본인뿐인지, 시간에 걸쳐 소유권을 공유하는 팀인지)입니다.
솔로·그린필드·사용자 없음인 경우, 리뷰의 두 번째 역할인 팀 내 지식 분배 자체가 존재하지 않습니다(본인이 곧 팀). 합리적 선택은 테스트와 자동화에 강하게 의존하고 정말 중요한 부분만 리뷰하며 나머지는 가벼운 터치로 두는 것입니다. 단, 테스트가 진짜일 때만 작동하고, 안전망 없이 리뷰를 건너뛰면 일이 사라지는 게 아니라 더 비싼 값으로 이연될 뿐입니다. 위험한 중간 지점은 프로젝트에 사용자가 생기는 순간인데, 버그 잡기 역할이 갑자기 중요해지고 지식 공유 역할도 동시에 켜집니다. 대규모 조직·오래된 코드베이스·다수 사용자 환경에서는 모든 경고성 수치가 최대 강도로 적용되며, 아무도 이해 못한 변경은 comprehension debt(이해 부채)가 되어 누군가의 온콜 인시던트로 돌아옵니다. 핵심은 "기업은 신중, 솔로는 여유"가 아니라 위치에 따라 리뷰의 목적이 달라지므로 규칙도 달라져야 한다는 점입니다.
3. 사라진 의도, 그리고 Loop engineering의 관점

사람이 코드를 쓰면 의도가 거의 공짜로 따라오고, 저울질하고 버린 대안이 작성자 머릿속에 남아 리뷰는 그 추론을 점검하는 일이었습니다. 현대 에이전트도 추론하며 종종 사고 과정을 가시적으로 보여주지만, 그 추론은 diff가 만들어지는 순간 버려지고 PR에 첨부되지 않습니다. 게다가 그것은 "어떻게 구현할지"에 대한 에이전트의 추론이지 "애초에 맞는 작업인지"에 대한 사람의 판단이 아닙니다. 결과적으로 리뷰는 눈앞의 추론 점검에서 기록되지 않은 의도의 재구성으로 바뀌어 더 어렵고 느려졌습니다(441% 더 걸리는 이유). 한 개발자의 표현처럼, 에이전트 PR 리뷰는 자신을 "이 코드를 처음으로 본 인간"으로 만듭니다.
루프의 전제는 에이전트에 프롬프트를 넣는 사람에서 벗어나 에이전트에 프롬프트를 넣는 시스템을 구축하는 것이고, 그 중심에는 작업 완료 여부를 판정하는 judge 에이전트가 있습니다. 리뷰어는 의도적으로 내부 루프에서 설계상 제거되는 다음 역할이며, 작성 자동화 1년 뒤 검증도 자동화되며 사람은 한 단계 위로 밀려납니다. 닫힌 루프의 위험은 에이전트가 쓰고 다른 에이전트가 리뷰하고 세 번째가 판정하면 상관된 맹점을 가진 모델들의 합의가 빌려온 확신이 되는 것입니다. 그래서 사람은 떠나지 않고 한 단계 위로 이동해야 합니다 — 모든 diff를 읽는 것에서 모델로 전이되지 않는 부분을 소유하는 것으로 전환하는 것입니다. 책임이 중요하고, 사람이 지켜야 할 영역은 이게 만들 가 옳은 변경인지의 판단, 틀리면 비싼 고blast-radius 게이트, 그리고 아무도 명세하지 않은 행동입니다. human in the loop에서 human on the loop으로 — 모든 PR을 읽는 대신 시스템을 샘플링·스폿체크·감사하고 틀리면 실제로 아픈 곳에 제한된 주의를 집중하는 흐름입니다.
4. 실무 지침 — 도구 선택과 조직 원칙
전용 AI 리뷰 도구는 이제 충분히 좋으며, 사이드 프로젝트 포함 모든 것에 최소한 메인 코딩 에이전트(가능하면 전용 리뷰 에이전트)를 돌릴 것을 권장할 정도입니다. CodeRabbit은 가장 널리 배포된 독립형으로 Martian 벤치마크(2026년 1~2월)에서 F1 1위, 정밀도 약 49%에 업계 최고 recall을 기록했습니다. Greptile은 정밀도를 내주고 recall을 확보해 한 벤치마크에서 버그 검출률 약 82%(CodeRabbit 44% 대비)를 보였고, Anthropic Code Review는 자사 엔지니어가 오류로 표시한 결과가 1% 미만, 실질적 리뷰를 받는 PR 비율을 16%에서 54%로 끌어올렸습니다. 한 엔지니어가 CodeRabbit·Sentry Seer·Greptile·Cursor BugBot를 3주 반 동안 실제 PR 146개, 발견 679건에 병렬 적용한 벤더 외부 실험(4개 리뷰어 병렬 실험)에서는 617개의 고유 플래그 위치 중 93.4%가 정확히 하나의 도구에서만 검출됐고, 네 도구가 같은 줄을 단 한 번도 함께 플래그하지 않았습니다. 이질성이 핵심입니다 — 한 모델 4벌은 청구서만 커진 단일 리뷰어이고, 진짜 다른 4개 리뷰어는 누구도 단독으로 못 찾는 버그를 드러냅니다.
조직 원칙 측면에서는 리뷰 노력을 "틀렸을 때의 비용"에 맞추고, 저렴한 결정론적 작업은 최대한 앞으로 당기며, 사람의 주의는 사람만 할 수 있는 일에 예약해야 합니다. 작성자가 아닌 위험으로 계층화(Tier by risk, not by author)하는 접근이 핵심인데, 설정 변경은 린터와 한 번 훑기로 충분하고 핵심 비즈니스 로직 경로 수정은 풀 스택 — 타입, 테스트, 서로 다른 두 AI 리뷰어, 해당 시스템 소유자인 사람, 보안 패스 — 가 필요합니다. 보일러플레이트에 무거운 리뷰를 쓰지 말고, 테스트가 초록이라고 큰 변경을 통과시키지 말아야 합니다. Early-Stage Prediction of Review Effort(2026년 1월, 에이전트 작성 PR 33,707개 연구)에서는 파일 유형·패치 크기 같은 저렴한 신호로 고유지비 PR을 사람이 보기 전에 예측하는 회로 차단기 구축이 잘 작동한다고 보고했고, 리뷰어 이탈이 거부된 에이전트 PR의 38%를 차지한다는 2026년 연구도 같은 결론을 향합니다.
5. 정리 — 무엇이 달라졌고 무엇을 해야 하는가
요약하면, AI 시대의 병목은 작성에서 검증으로 이동했고, 검증 단계는 두 가지 압력을 동시에 받습니다 — 사람이 따라가지 못하는 물량, 그리고 사라진 의도를 처음부터 재구성해야 하는 비용. 솔로·사용자 없음은 AI에 거의 전부를 맡기는 것이 방어 가능한 2026년 현재의 입장이고, 대규모·다수 사용자는 첫·두 번째 패스와 지루한 90%는 기계가, 부하를 견디는 경로(load-bearing paths)에는 실제 사람이 유지하는 형태입니다. 사람을 얼마나 둘지는 죄책감이 아니라 blast radius로 설정하는 다이얼이고, 도구는 단일 최고가 없으므로 고위험 영역에서는 의격이 다른 둘을 병행하고 모든 결과는 자신의 코드에서 측정해야 합니다. 2026년 6월 기준으로 코드를 더 빨리 쓰는 팀이 이기는 게 아니라, 사라진 의도를 복구하는 시스템을 의도적으로 만든 팀이 이깁니다.
이미지 출처: Unsplash / Picsum
'AI 뉴스' 카테고리의 다른 글
| Claude Code 수석 디자이너의 AI 빌드 워크플로우 — worktree·auto mode·prototype skill 실전 정리 (0) | 2026.06.18 |
|---|---|
| OpenRouter Fusion API — 멀티 모델 심의로 프론티어 성능을 넘는 새로운 호출 방식 (0) | 2026.06.18 |
| Show GN: Anf — Claude로 만든 새로운 macOS Finder 가이드 (0) | 2026.06.17 |
| 연구자들 "Fable 5 논란은 탈옥이 아니라 'fix this code'에서 시작됐다" — 2026년 6월 (0) | 2026.06.17 |
| Apple이 Hide My Email을 쓸모없게 만들려 하고 있음 — 2026년 6월 현재 사용자 대응 가이드 (0) | 2026.06.17 |