생성형 AI (GenAI) 개발의 오류 #4: 인간의 검토를 생략하면 병목 현상이 제거된다는 착각

이 글은 생성형 AI (Generative AI)를 사용하여 구축할 때 팀들이 범하는 잘못된 가정에 관한 8개의 포스트 시리즈 중 네 번째 글입니다. 오류 #1에서는 왜 더 빠른 생성 속도가 더 빠른 엔지니어링을 의미하지 않는지를 다루었습니다. 오류 #2에서는 왜 그럴듯해 보이는 것이 정답이 아닌지를 다루었습니다. 오류 #3에서는 왜 AI가 AI를 신뢰성 있게 검증할 수 없는지를 다루었습니다. 이 포스트에서는 검토 단계(Review gate)를 완전히 제거했을 때 어떤 일이 발생하는지를 다룹니다.

오류

"인간의 코드 리뷰 (Code review)가 병목 현상이다. 리뷰를 없애면 파이프라인이 AI의 속도로 움직일 것이다."

유혹적인 이유

계산은 간단하며 좌절감은 실재합니다. AI는 3분 만에 PR (Pull Request)을 생성합니다. 인간의 검토는 3시간이 걸립니다. 인간은 기계보다 60배 느립니다. 만약 AI의 도움을 받아 PR을 생성하는 개발자가 5명이라면, 이들을 검토하는 한 명의 테크 리드 (Tech lead)가 팀 전체 산출물의 제약 사항이 됩니다. 파이프라인은 검토 단계에서 멈춰버립니다.

유행하는 해결책은 리뷰를 없애는 것입니다. AI가 코드의 100%를 작성하게 하세요. 테스트를 믿으세요. 더 빠르게 배포하세요. 업계의 저명한 목소리들은 이를 명시적으로 옹호합니다. 만약 리뷰가 병목 현상이라면, 그것을 제거하라는 것입니다. 리뷰어의 시간은 더 높은 수준의 업무에 쓰이는 것이 낫다는 논리입니다.

이 논리는 단 한 가지 질문을 던지기 전까지는 매우 설득력이 있습니다: 리뷰를 대체한 것은 무엇인가?

연구 결과가 이러한 우려를 뒷받침합니다. Perry 등의 2023년 Stanford 연구("Do Users Write More Insecure Code with AI Assistants?")에 따르면, AI 어시스턴트 (AI Assistants)를 사용하는 개발자들은 더 많은 보안 취약 코드를 작성했지만, 그 코드가 안전하다고 믿을 가능성은 더 높았습니다. 인간의 "리뷰 병목 현상 (reviewer bottleneck)"은 단순히 속도의 문제가 아닙니다. 이는 잘못된 보안 의식 (false sense of security)으로 인해 발생하는 인지적 실패 (cognitive failure)입니다. AI가 더 빠르게 생성할수록 개발자는 더 자신감을 갖게 되고, 검토 (scrutinize)는 덜 하게 됩니다.

이것이 잘못된 이유

게이트 (gate)가 존재하는 데에는 이유가 있습니다. 그것은 무언가를 잡아내기 위해서입니다. 게이트를 제거하면, 게이트가 잡아내던 것들이 프로덕션 (production)에 도달하기 시작합니다. 질문은 "리뷰가 느린가?"가 아닙니다. 질문은 "다른 어떤 것도 잡아내지 못하는 것을 리뷰가 무엇을 잡아내고 있었는가?"가 되어야 합니다.

인간의 코드 리뷰 (code review)는 파이프라인 (pipeline)의 다른 어떤 부분도 다루지 않는 최소 세 가지 범주의 문제를 잡아냅니다:

1. 아무도 테스트를 작성하지 않은 속성들. 테스트는 누군가가 검증하려고 '생각한' 것을 검증합니다. 리뷰는 아무도 테스트할 생각을 하지 못한 것들을 잡아냅니다. 즉, 아키텍처 위반 (architectural violation), 보안 가정 (security assumption), 성능 영향 (performance implication), 또는 아무도 예상하지 못해 테스트 케이스가 없는 비즈니스 로직 오류 (business logic error) 등이 이에 해당합니다.

2. 구성적 정확성 (Compositional correctness). 테스트는 개별 컴포넌트 (components)를 검증합니다. 리뷰는 종종 컴포넌트들이 어떻게 상호작용하는지를 살펴보는 유일한 단계입니다. 이 변경 사항이 모듈 A와 모듈 B 사이의 암묵적 계약 (implicit contract)을 깨뜨리는가? 이 새로운 엔드포인트 (endpoint)가 의존성 사이클 (dependency cycle)을 유발하는가? 이 데이터베이스 마이그레이션 (database migration)이 다른 팀의 동시 마이그레이션과 나쁜 상호작용을 하는가? 등을 확인합니다.

3. 설계 일관성 (Design coherence). 테스트는 동작 (behavior)을 검증합니다. 리뷰는 의도 (intent)를 검증합니다. 이것이 올바른 접근 방식인가? 이 변경 사항이 아키텍처 (architecture)와 일치하는가? 우리는 올바른 것을 만들고 있는가, 아니면 단지 테스트를 통과하는 무언가를 만들고 있는가? 이것은 검증 (verification)이 아니라 판단 (judgment)의 영역입니다. 하지만 이 판단이야야 수백 번의 변경 사항을 거치며 코드베이스 (codebase)가 일관성을 잃고 표류하는 것을 방지합니다.

리뷰를 생략하면 세 가지 카테고리 모두 검토되지 않은 채 운영 환경 (production)에 도달합니다. 즉각적으로 발생하는 일은 아닙니다. 테스트가 여전히 쉬운 버그들은 잡아낼 것이기 때문입니다. 하지만 어려운 문제들 — 아키텍처 표류 (architectural drift), 구성 오류 (composition errors), 테스트되지 않은 보안 가정 (untested security assumptions) — 은 보이지 않게 축적됩니다.

Manny Lehman은 1980년에 이를 증명했습니다. 그의 소프트웨어 진화 제2법칙 (Second Law of Software Evolution)은 다음과 같이 명시합니다: "진화하는 프로그램이 지속적으로 변경됨에 따라, 구조적 악화를 반영하는 복잡성은 이를 유지하거나 줄이기 위한 노력이 수행되지 않는 한 증가한다."

코드 리뷰 (Code review)는 그러한 능동적인 작업을 위한 핵심 메커니즘입니다. 리뷰를 제거하는 것은 엔트로피 (entropy)를 멈추는 것이 아니라, 시스템을 관리 불가능한 상태가 될 때까지 엔트로피가 축적될 것임을 확정 짓는 것입니다. 리뷰를 생략하는 것은 아키텍처의 붕괴를 위험이 아닌 수학적 확실성으로 만듭니다.

Microsoft와 오픈 소스 프로젝트의 수천 건의 코드 리뷰를 대상으로 한 Rigby와 Bird의 2013년 실증 연구 ("Convergent Software Peer Review Practices")에 따르면, 리뷰의 주요 가치는 버그를 찾는 것이 아닙니다. 그것은 지식 전수 (knowledge transfer), 설계 개선 (design improvement), 그리고 팀 전체의 표준 유지입니다. 리뷰를 생략하면 단순히 버그를 놓치는 것에 그치지 않고, 시스템의 이론 구축 (Theory Building, Naur, 1985)과 개념적 무결성 (Conceptual Integrity, Brooks, 1975)을 파괴하게 됩니다.

급증기 (The boom)

1~3개월 차: 속도의 급증. 리뷰어를 기다리지 않고 PR (Pull Request)이 병합됩니다. 기능 전달 (feature delivery) 속도가 눈에 띄게 가속화됩니다. 팀은 이전 6개월 동안보다 3개월 동안 더 많은 것을 출시합니다. 경영진은 축하하고, 지표 (metrics)는 훌륭해 보입니다.

4~6개월 차: 조용한 축적. 리뷰를 건너뛴 각각의 AI 생성 PR에는 아무도 검토하지 않은 소수의 결정들이 담겨 있었습니다. 변수 명명 규칙 (variable naming convention)이 표류했습니다. 에러 처리 전략 (error handling strategy)이 서비스 간에 갈라졌습니다. 재시도 정책 (retry policy)이 세 개의 모듈에서 서로 다르게 구현되었습니다. 그 어떤 것도 테스트 실패를 유발하지는 않습니다. 각각은 아키텍처의 미세한 균열 (micro-crack)입니다.

7-9개월 차: 아무도 진단할 수 없는 첫 번째 장애 발생. 아무도 이해하지 못하는 코드 경로에서 운영 환경의 장애가 발생합니다. 당직 개발자가 파일을 엽니다. 그것은 AI가 생성한 것이었습니다. 한 번도 검토된 적이 없었습니다. 그것이 어떻게 작동하는지에 대한 멘탈 모델 (mental model)을 구축한 사람이 아무도 없었습니다. 개발자가 코드를 읽어보니 — 올바르게 보입니다. 버그는 이 함수와, 역시 AI가 생성하고 검토된 적 없는 다른 서비스의 또 다른 함수 사이의 상호작용에 있었습니다. 디버깅(Debugging)에 3일이 걸렸습니다. 코드를 작성하는 데는 3분이 걸렸습니다.

10-12개월 차: 실행할 수 없는 아키텍처 변경. 팀은 핵심 모듈을 리팩터링 (refactor)해야 합니다. 해당 모듈은 누군가 마지막으로 검토한 이후 AI 에이전트 (AI agents)에 의해 수십 번 수정되었습니다. 테스트는 통과합니다. 코드는 읽기 좋습니다. 하지만 왜 이런 구조로 되어 있는지 아는 사람이 아무도 없습니다. 어떤 동작이 의도된 것이고, 어떤 것이 AI 생성의 우연한 부산물 (accidental artifacts)인지 아는 사람이 없습니다. 팀은 코드를 변경하기를 두려워합니다. 몇 달에 걸쳐 구축된 코드를 몇 달 안에 안전하게 수정할 수 없게 된 것입니다.

더 깊은 피해: 소유권 상실. 인간이 코드를 검토하지 않을 때, 코드를 소유하는 인간도 없습니다. 팀은 자신들이 더 이상 소프트웨어 엔지니어가 아니라

이것은 오류 #1에서 시작되어 이제 코드 수준에 도달한 인지 부채 (cognitive debt)의 궤적입니다. 검토 (review)는 AI가 생성한 변경 사항에 대해 인간의 이해를 구축하는 유일한 메커니즘이었습니다. 검토가 없다면 이해는 결코 형성되지 않습니다. 이 부채는 호출될 때까지 조용히 복리로 쌓이며, 호출되는 시점은 항상 장애 (incident) 발생 시이며, 항상 최악의 타이밍입니다.

검토의 세 가지 모델

업계는 두 가지 모델 사이에서 논쟁하고 있습니다. 하지만 실제로는 세 가지가 존재합니다.

모델 1 — 인간이 모든 것을 검토함:
    AI가 코드를 생성함 → 인간이 모든 줄을 읽음 → 배포 (Ship)

...

모델 2는 모델 1의 업그레이드처럼 보입니다. 하지만 실제로는 다운그레이드입니다. 안전 메커니즘을 대체하지 않은 채 제거해 버렸기 때문입니다. 팀은 정확도 (accuracy)를 속도 (speed)와 맞바꾸었으며, 이를 최적화 (optimization)라고 불렀습니다.

모델 3이 진정한 해결책입니다. 이는 타협하지 않습니다. 두 가지 요구 사항을 분리합니다:

• **정확도 (ACCURACY)**는 명세 (specifications)를 기반으로 작동합니다 (작고, 안정적이며, 인간이 작성하고, 신중하게 검토된 것).
• **속도 (SPEED)**는 코드 검증 (code verification)을 기반으로 작동합니다 (빠르고, 철저하며, 기계적이며, 모든 변경 사항에 적용되는 것).

명세 (Specification)가 100페이지짜리 요구사항 문서라는 뜻은 아닙니다. 이는 이미 코드베이스에 존재하는, 의도를 기계가 검증할 수 있는 모든 산출물을 의미합니다: TypeScript 인터페이스, OpenAPI 정의, Protocol Buffer 스키마, SQL 마이그레이션, Semgrep 규칙, 데이터베이스 제약 조건 (constraint) 등이 이에 해당합니다. 작고, 안정적이며, 인간이 작성하고, 기계에 의해 강제되는 것들입니다.

인간은 게임의 규칙을 검토합니다. 기계는 규칙이 깨지지 않았는지 확인하기 위해 모든 움직임을 검토합니다.

모든 안전 필수 (safety-critical) 도메인이 이곳에 도달한 방식

안전 필수 (safety-critical) 도메인 중 모델 1이나 모델 2를 사용하는 곳은 없습니다. 모든 곳이 모델 3을 사용합니다. 그들은 자신들이 정의한 "AI 속도의 생성"이 인간의 검토 역량을 초과했을 때, 독립적으로 모델 3에 도달했습니다.

항공 (Aviation): 제트 엔진이 조종사가 모든 상황에 반응할 수 없을 정도로 빨라졌습니다. 모델 1 (조종사가 모든 것을 모니터링)은 너무 느렸습니다. 모델 2 (조종사를 제거)는 너무 위험했습니다. 모델 3: 플라이 바이 와이어 (fly-by-wire) 엔벨로프 보호 (envelope protection). 조종사는 비행 계획 (FLIGHT PLAN, 사양)을 검토합니다. 컴퓨터는 비행 엔벨로프 (FLIGHT ENVELOPE, 기계적 게이트)를 강제합니다. 조종사가 시도하더라도 항공기를 실속 (stall) 시킬 수 없습니다. 즉, 사양 게이트 (specification gate)가 입력을 무시합니다. 이는 임시방편이 아닙니다. DO-178C (비행 소프트웨어 인증 표준)는 요구사항 (requirements, 사양)이 의도에 맞는지 인간이 검토할 것을 요구하는 반면, 코드 (code)는 구조적 커버리지 분석 (structural coverage analysis), 데이터 결합 분석 (data coupling analysis), 형식 기법 (formal methods)과 같은 결정론적 도구 (deterministic tools)를 사용하여 해당 요구사항에 따라 검증합니다. 인간은 비행 코드의 모든 줄을 검토하지 않습니다. 인간은 코드가 수행해야 하는 사항에 대한 사양을 검토하며, 기계는 그 사양에 따라 모든 줄을 검증합니다.

원자력 운영 (Nuclear operations): 원자로 역학은 운영자가 모든 매개변수 (parameter)를 추적할 수 있는 속도보다 빠르게 일어납니다. 모델 1 (운영자가 모든 매개변수를 모니터링)은 너무 느렸습니다. 모델 2 (운영자의 감독을 제거)는 너무 위험했습니다. 모델 3: 자동 보호 시스템 (automated protection systems). 운영자는 절차 (PROCEDURES, 사양)를 검토합니다. 인터록 (interlocks)이 매개변수 제한 (PARAMETER LIMITS, 기계적 게이트)을 강제합니다. 매개변수가 엔벨로프 (envelope)를 초과하면 운영자의 입력과 관계없이 원자로가 자동으로 급정지 (scram) 합니다.

금융 거래 (Financial trading): 알고리즘 실행 (Algorithmic execution)은 마이크로초 단위로 이루어집니다. 모델 1 (인간이 모든 거래를 검토)은 너무 느렸습니다. 모델 2 (검토 없음)는 플래시 크래시 (flash crashes)를 유발했습니다. 모델 3: 사전 거래 리스크 체크 (pre-trade risk checks). 리스크 관리자는 리스크 한도 (RISK LIMITS, 사양)를 검토합니다. 시스템은 모든 거래 (EVERY TRADE, 기계적 게이트)에 대해 이를 강제합니다. 알고리즘이 무엇을 생성했는지와 관계없이, 한도를 위반하는 주문은 거래소에 도달할 수 없습니다.

Google monorepo: 20억 줄의 코드. 모델 1(모든 의존성의 모든 변경 사항을 인간이 검토)은 너무 느렸습니다. 모델 2(검토 없이 병합)는 monorepo를 망가뜨릴 것입니다. 모델 3: 자동화된 테스트(automated testing) + API 계약 강제(API contract enforcement). 팀은 인터페이스 계약(INTERFACE CONTRACTS, 명세/specification)을 검토합니다. CI는 모든 변경 사항(EVERY CHANGE)에 대해 이를 강제합니다(mechanical gate). 수백만 줄에 달하는 대규모 변경 사항이 병합될 수 있는 이유는, 영향을 받는 모든 테스트가 기계적으로 통과하기 때문입니다. Winters, Manshreck, 그리고 Wright가 Software Engineering at Google (2020)에서 기록했듯이, 코드 리뷰 장에서는 이를 명시적으로 다룹니다: "기계적 체크(mechanical checks)"(린터(linters), 테스트)는 자동화되지만, "설계 및 의도(design and intent)" 리뷰는 시스템의 일관성을 유지하는 게이트 역할을 합니다. 세계 최대 규모의 코드베이스조차 리뷰를 생략하지 않습니다. 대신 리뷰를 가장 높은 수준의 추상화 단계로 이동시킵니다.

이 패턴은 반복됩니다: 생성 속도가 인간의 검토 역량을 초과할 때, 검토가 사라지는 것이 아닙니다. 검토는 두 가지 속도를 가진 두 가지 활동으로 분리됩니다. 인간은 느리지만 높은 판단력이 필요한 작업(명세 검토)을 수행합니다. 기계는 빠르고 철저한 작업(명세에 따른 코드 검증)을 수행합니다.

모델 3을 강제하는 TRIZ 모순

이것은 선호의 문제가 아닙니다. 물리적 모순(physical contradiction)의 해결입니다.

검토는 정확해야(ACCURATE) 합니다 — 코드가 올바른지, 아키텍처가 견고한지, 보안 속성이 유지되는지를 판단하기 위해서는 인간의 도메인 전문 지식(domain expertise)이 필요합니다.

검토는 빨라야(FAST) 합니다 — 인간의 검토 속도는 팀이 AI의 생산성 이득을 포착하는 것을 방해하는 병목 현상(bottleneck)입니다.

동일한 시스템. 상반된 요구사항. TRIZ의 분리 원칙(separation principle): 만약 시스템이 동시에 A이면서 동시에 A가 아니어야 한다면, 그 모순을 서로 다른 산출물(artifacts)로 분리하십시오.

정확함 (인간의 속도):
    인간이 명세 작성    → 작고, 느리며, 전문 지식 필요
    인간이 명세 검토    → 드물게 수행, 높은 판단력 필요
...