AI가 PR 대부분을 쓰는 팀에서 사람 리뷰는 어떤 PR에 필수로 걸어야 할까요?

📌 오늘의 안건
AI가 PR 대부분을 쓰는 팀에서 사람 리뷰는 어떤 PR에 필수로 걸어야 할까요?

팀에 도입할 코드리뷰 가이드라인을 정하려고 합니다. 지금은 PR 대부분이 AI로 생성되는데, 기준 없이 모든 PR에 사람 리뷰를 1회씩 붙이고 있어서 사람 리뷰가 병목이 되고 있습니다.

제가 원하는 결과물은 'AI 리뷰와 사람 리뷰의 역할 분담표'입니다. 즉 AI 리뷰 통과만으로 머지해도 되는 PR과, 사람이 반드시 눈으로 봐야 하는 PR을 가르는 명시적인 기준이요.

여쭙고 싶은 점은 이렇습니다.

1. 사람 리뷰를 필수로 걸어야 하는 경계를 무엇으로 잡으시나요? (예: 변경 범위·도메인 민감도, 인증·결제·데이터 마이그레이션 같은 영역, 변경 라인 수, 신규 추상화 도입 여부, 되돌리기 난이도 등)
2. 반대로 AI 리뷰와 자동화된 검증만으로 통과시켜도 무방하다고 보시는 변경은 어디까지인가요?
3. 사람 리뷰가 남았을 때, 사람은 무엇을 보는 게 맞을까요? AI가 이미 잡아주는 스타일·버그 패턴 대신 설계 의도, 요구사항 부합, 유지보수 부담 같은 층위로 옮겨가야 한다고 보시는지 궁금합니다.
4. 이런 기준을 실제로 운영해 보셨다면, 사고나 품질 저하 없이 병목이 실제로 줄었는지도 듣고 싶습니다.

데밍입니다. 여러분이 지금 붙이고 있는 '모든 PR 1회 리뷰'가 실제로 무엇을 걸러냈는지 숫자로 남아 있는지부터 묻겠습니다.

머지장입니다. 저는 기준표보다 그 기준표 아래에서 하루를 보내는 작성자와 리뷰어의 기분을 먼저 들여다보겠습니다.

닥터 게이트입니다. 저는 잘 굴러가는 경우가 아니라, 이 기준표가 틀렸을 때 무엇이 복구 불가능해지는지를 맡겠습니다.

소크라테스입니다. 저는 무엇을 하라고 말하지 못합니다 — 다만 여러분이 '병목'과 '리뷰'라 부르는 것이 정말 그것인지부터 묻겠습니다.

장애 현장에서 새벽을 여러 번 보낸 사람입니다. 이번엔 이 기준이 뚫렸을 때 어디까지 망가지는지를 맡겠습니다.

역결입니다. 저는 합의가 빨리 만들어지는 자리를 특히 의심합니다 — 이번엔 '사람 리뷰가 병목'이라는 전제부터 뒤집어 보겠습니다.

결론: 사람 리뷰는 “AI가 틀렸을 때 사람·돈·데이터·운영을 망가뜨리는 PR”에만 필수로 걸고, 나머지는 자동화+AI 리뷰+사후 관측으로 흘려보내야 합니다. 필수 경계는 명확해야 합니다: 인증·권한·결제·개인정보·보안·암호화·감사로그, 데이터 마이그레이션/삭제, 배포·인프라·런타임 설정, 공개 API/스키마/계약 변경, 신규 추상화·아키텍처 방향 전환, 장애 시 롤백이 어려운 변경, 테스트가 부족한 동작 변경, 큰 변경 묶음입니다. 라인 수는 보조 신호로만 쓰되 “100줄 내외는 보통 리뷰 가능, 1000줄은 대체로 너무 큼”이라는 Google의 small CL 기준은 좋은 운영 감각입니다. google.github.io[1]

AI 리뷰만으로 머지 가능한 영역은 되돌리기 쉽고, 의미가 국소적이며, 자동 검증이 강한 변경입니다: 문서/주석, 포맷팅, 죽은 코드 삭제, 테스트 기대값 갱신, 타입·린트 수정, 기계적 리팩터링, 내부 UI copy 조정, 플래그 뒤의 작은 변경, 이미 충분한 테스트가 있는 단일 함수 수준 수정. 이때 조건은 “CI 통과, 테스트 존재, diff 작음, owner 경계 안 넘음, 배포 후 감지 가능, 즉시 롤백 가능”입니다. DORA도 AI 도입이 개인 생산성·flow·만족도를 높일 수 있지만, 큰 배치와 약한 피드백 루프에서는 안정성과 처리량을 해칠 수 있다고 보고합니다. 즉 병목을 줄이는 핵심은 사람 리뷰 폐지가 아니라, 작은 배치와 빠른 고품질 피드백입니다. dora.dev[1] , dora.dev[2]

사람이 남았을 때 보는 것은 스타일이 아니라 책임입니다: “이 요구사항이 맞나, 이 설계가 팀의 미래 비용을 늘리나, 장애 시 누가 어떻게 되돌리나, 주니어가 이 코드에서 배울 수 있나, 내가 승인자로서 설명 가능한가.” 모든 AI PR에 사람 도장을 찍게 하면 작성자는 대기 불안에 빠지고, 리뷰어는 자신이 쓰지 않은 코드를 책임지는 피로를 느끼며, 승인은 의식이 됩니다. Google 리뷰 가이드도 리뷰의 목적을 완벽함이 아니라 코드베이스 건강과 진전의 균형으로 둡니다. 운영 지표는 “사람 리뷰 비율”이 아니라 첫 응답 시간, 리뷰 대기 시간, 롤백률, 변경 실패율, 리뷰어 집중 시간, 주니어 학습 PR 비율로 잡아야 합니다. google.github.io[1] , google.github.io[2]

사람 리뷰 필수 경계를 잡기 위해, SRE·보안 가이드라인과 실제 사고 사례를 먼저 확인합니다.결론: 사람 리뷰의 경계는 라인 수·AI 통과 여부가 아니라 “롤백으로 세계가 복구되는가”다. 인증·권한·결제/정산·스키마·삭제·비밀키·의존성 추가처럼 한 번 쓰면 코드 되돌리기로 상태가 안 돌아오는 변경은 AI 리뷰만으로 머지하면 안 된다.

Veracode 2025 GenAI 보고서는 AI 생성 코드의 약 45%가 알려진 보안 결함을 포함한다고 했고, 업계 가이드도 auth·암호화·결제 경로는 사람 리뷰 없이 금지한다.[[1]](veracode.com[1])[[2]](cycode.com[2]) 스키마/데이터 마이그레이션은 앱 롤백과 데이터 롤백이 분리되어 “롤백 환상”이 생기므로 사람 검증이 필수다.[[3]](techscoop.substack.com[3])

역할 분담

경계 변수 우선순위: (1) 비가역성·상태 파괴 > (2) 권한·돈·비밀 > (3) 블라스트 반경(공용 경로·다수 소비자) > (4) 소유권 이탈 ≫ 라인 수. 라인 수는 신호일 뿐 게이트가 아니다. 대규모라도 내부 리네이밍이면 AI 가능, 10줄이라도 DROP/UPDATE … WHERE 누락·권한 우회면 사람 필수다.

사람이 볼 층위: 스타일·패턴 버그는 자동화에 넘기고, 사람은 의도·불변식·실패 시 조용한 손상 경로만 본다 — “이 변경이 틀리면 무엇이 영구히 깨지는가”, 요구사항/도메인 규칙 부합, 롤백·feature flag로 살릴 수 있는지, 권한 경계·감사 가능성, 유지보수 부채(공용 API·숨은 결합). Google 리뷰 표준도 “코드 건강 개선”과 설계 관점을 중심에 둔다.[[4]](google.github.io[1]) 운영 원칙: high-risk 경로에 사람 게이트를 고정하고 low-risk는 자동화로 빼면 병목은 줄고, “전 PR 1회 사람”보다 사고 표면은 작아진다. 반대로 high-risk를 AI 통과만으로 열면 권한 우회·이중 과금·비가역 데이터 손상이 현실 최악 시나리오다 — 그때 죽이는 것은 속도가 아니라 복구 불가능성이다.

1. 'AI 리뷰 통과'가 보증하는 신뢰의 실체에 대하여
'AI 리뷰 통과만으로 머지 가능한 기준'을 세우려는 시도는 AI가 품질을 보증할 수 있다는 잘못된 신뢰에서 출발합니다. GitClear 2024 Report[1]에 따르면, AI 코딩 도구 도입 이후 코드 중복이 급증하고 리팩토링 빈도는 급감했으며, 작성 후 바로 버려지는 코드 불안정성(churn)이 심화되고 있습니다. AI는 그럴듯한 패턴을 모방할 뿐 코드의 숨은 부작용이나 구조적 결함을 인지하지 못합니다. 스타일과 단순 버그 통과라는 얕은 신호가 어떻게 안전한 머지를 보증할 수 있습니까?

2. 인위적인 역할 분담과 경계선의 맹점
변경 라인 수나 도메인 민감도 같은 정량적 기준으로 AI와 인간의 리뷰 영역을 무 자르듯 나눌 수 있다는 생각은 위험합니다. 비민감 영역이나 단 몇 줄의 사소한 변경조차 아키텍처의 정합성을 깨뜨리고 시스템 전체를 붕괴시키는 도화선이 될 수 있습니다. "이 영역은 AI만으로 충분하다"고 규정하여 인간의 주의 영역에서 배제하는 순간, 그 코드는 기술 부채로 전락해 더 큰 장애 병목으로 돌아올 것입니다.

3. 결론: 이분법적 가이드라인이 아닌 PR 생산 단계의 통제
결론적으로, 'AI/사람 역할 분담표'를 제정하는 방식으로는 병목을 줄이면서 품질을 지키는 목표를 달성할 수 없습니다. 병목의 본질은 리뷰 가이드라인의 부재가 아니라, 검토 역량을 초과하여 무분별하게 쏟아지는 AI 생성 PR의 절대적인 양입니다. 유일한 해결책은 인간이 보지 않는 머지 경로를 승인하는 것이 아니라, 인간이 아키텍처와 요구사항의 정합성을 완벽히 장악하고 책임질 수 있는 '설계적 최소 단위'로만 PR을 쪼개어 발행하도록 프로세스를 통제하는 것뿐입니다.

1. 사람 리뷰 필수 경계: 폭발 범위(Blast Radius)와 불가역성(One-Way Door)

AI 리뷰어는 문맥상의 문법적 정합성만 판단할 뿐, 시스템 전체의 가용성과 아키텍처 맥락을 이해하지 못합니다. 따라서 '되돌릴 수 없는 변경(One-Way Door)'과 '보안/데이터 경계'에 한해 사람 리뷰를 필수 배치해야 합니다. 필수 리뷰 대상: ① 데이터베이스 스키마 마이그레이션 및 파괴적 쿼리, ② 인증/인가(Auth/RBAC) 및 테넌트 데이터 격리 로직, ③ 신규 아키텍처 추상화 및 외부 API 계약(Contract) 변경. 리스크 시나리오: AI에게 마이그레이션 코드를 위임할 경우, 데이터 잠금(Table Lock)이나 암묵적 권한 우회(IDOR) 같은 비기능적 결함을 '정상 코드'로 판단해 승인하는 무성의한 승인(Rubber-stamping) 참사가 발생합니다.

Google SRE Book - Release Engineering[1]에 명시되듯, 상태 변경이 수반된 불가역적 배포 실패는 단순 롤백이 불가능하여 즉시 서비스 전체 파멸로 이어집니다.

---

2. AI 자동 승인 범주와 사람이 검증해야 할 층위

자동화 검증(CI/CD, 정적 분석, 단위 테스트)을 완비했다면, 가역적인 2-Way Door 변경은 사람을 거치지 않고 AI 리뷰만으로 즉시 머지해야 병목이 해소됩니다.

• AI 자동 통과 범위: 린트/스타일 수정, 단순 UI/DTO 타입 추가, Pure Function 단위 테스트 추가, 섀도/캐너리 환경에서 100% 검증 가능한 독립 모듈.
• 사람 리뷰어가 집중해야 할 층위: 사람은 더 이상 오타나 버그 패턴을 찾지 않고 ① 요구사항과 설계 의도의 일치 여부, ② 인가 매트릭스 침범 위험, ③ 운영 시 관찰 가능성(Observability) 및 유지보수 부채만 검증해야 합니다. AI는 자신이 작성한 환각(Hallucination)을 논리적으로 정당화하는 코드를 생성하므로, 사람이 비즈니스 도메인 맥락에서 의도적 하차점과 경계 조건을 송곳처럼 짚어내야 합니다.

---

3. 통제된 자동화를 통한 병목 제거 및 방어책 설계

전사 PR의 70~80%를 차지하는 저리스크 변경을 AI 자동 머지로 전환하고, 남아있는 20%의 고위험 경계선 PR에만 사람의 집중력을 투입할 때 리뷰 병목과 장애율이 동시에 감소합니다.

• 안전공학적 방어책: 자동 승인된 PR이 생산성 향상을 가져오더라도 Knight Capital 사태(SEC Report)처럼 검증 프로세스 누락이 4억 6천만 달러의 파산을 부른 사례를 잊어서는 안 됩니다. AI 자동 머지 파이프라인에는 반드시 '자동 캐너리(Canary) 배포' 및 'SLO(서비스 수준 목표) 이탈 시 자동 롤백'이라는 최후의 안전장치가 시스템적으로 결합되어야만 사고 없는 실제 병목 감소를 이룰 수 있습니다.

1. 경계는 '영역'이 아니라 되돌리기 비용 × 자동검증 커버리지 두 축으로 잡아라

라인 수·도메인 목록을 게이트로 쓰면 안 된다. 라인 수는 공통원인 변동이지 결함 신호가 아니다. 데이터가 말해주는 건 딱 하나 — 400 LOC를 넘으면 사람 리뷰의 결함 검출률 자체가 무너진다(SmartBear/Cisco: 200~400 LOC·60분에서 검출률 70~90%, 그 이상은 급락). 즉 큰 PR은 "사람 리뷰 필수" 대상이 아니라 분할 요구 대상이다. 거기에 붙이는 사람은 검사원일 뿐 품질을 만들지 못한다(14포인트 3항). 지금 여러분 팀의 병목은 예상된 결과다 — DORA 2025는 AI 채택률 90%에서 처리량은 늘었지만 불안정성(변경실패·재작업·복구시간)이 함께 올랐고, 원인을 "생성 속도가 리뷰·검증 용량을 앞지른 것"으로 지목한다. 한 2025년 텔레메트리 조사(개발자 1만 명 이상, DX 보고)에서는 AI 고채택 팀의 머지 PR +98%, 리뷰 시간 +91%, PR 크기 +154%였다. 사람을 더 넣어 풀 문제가 아니다.

2. 역할 분담표 (기준은 전부 자동 판정 가능해야 한다)

3번 질문 — 그렇다, 층위를 옮기는 게 맞고 근거도 있다. AI 리뷰 코멘트 분포를 보면 해법 접근(21.8%)·문서(19.8%)·기능 결함(18.1%)이고, 기능 결함 코멘트의 반영률은 높지만(Codex 88.6%) 구글 AutoCommenter 실측에서 자동 코멘트가 실제 코드 변경으로 이어진 비율은 약 40%다. 반대로 AI가 구조적으로 못 보는 지표는 악화 중이다 — GitClear 2026: 블록 중복 2023 대비 +81%, 리팩터링(이동 코드) 21%(2022) → 3.8%(2026 YTD), 교차파일 함수 호출 −35%. 그러니 사람이 볼 것은 스펙↔구현 부합, 추상화가 필요했는지(중복을 추상화로 위장하지 않았는지), 삭제됐어야 할 코드가 남았는지, 실패 모드와 롤백 계획 넷으로 좁혀라. 스타일·널 체크는 사람이 보면 낭비다.

3. 4번에 대한 정직한 답: 측정되지 않았다

"이 기준을 적용해 사고 없이 병목이 줄었다"는 통제된 공개 증거는 없다. 있는 건 상관관계뿐이다 — 리뷰가 빠른 팀의 배포 성과가 약 50% 우수(DORA), 그리고 CFR이 5%→6%만 올라도 연 34.4만 달러 다운타임 비용(DORA 모델). 그러니 기준선을 먼저 측정하지 않고 이 표를 켜지 마라. 측정 없이 정한 기준선은 추측이다. 4주 베이스라인 → 30/60일 검증으로 이렇게 운영하라: ① 결함 유출률(머지 후 발견 결함/총 결함)을 자동 머지 경로와 사람 리뷰 경로로 분리 집계 — 이게 유일한 판정 지표다 ② 리뷰 대기시간 P50/P85 ③ CFR·MTTR ④ PR 크기 분포 ⑤ 사람 리뷰 코멘트 중 실제 결함을 잡은 비율(이게 10% 아래면 그 리뷰는 검사일 뿐이니 대상을 더 줄여라). 관리도로 보고 개별 점에 반응하지 마라 — 두 경로의 유출률 차이가 관리한계 안이면 자동 머지 범위를 넓히고, 벗어나면 그때만 특수원인을 조사한다.

그리고 진짜 투자처는 리뷰어 증원이 아니라 머지 후 자동 롤백·마이그레이션 리허설·변경 라인 커버리지 게이트다. 검사를 늘리는 대신 결함이 생길 수 없게 프로세스를 바꾸는 쪽이 항상 싸다.

Sources:

• DORA State of AI-assisted Software Development 2025[1] · Google Cloud 발표[2] · Faros 요약(CFR 5→6% 비용)[3]
• DX: DORA metrics in the AI era (리뷰 시간 +91%, PR 크기 +154%)[4] — 벤더 텔레메트리, 동료심사 아님
• PR 200줄 미만 권고 / SmartBear·Cisco 연구 정리[5] · PR 크기와 리뷰 품질 데이터[6]
• GitClear, The Maintainability Gap: 2026 AI Code Quality Research[7]
• Google Research, Resolving code review comments with ML (AutoCommenter)[8] · DX 뉴스레터 해설[9]
• "Go Home Copilot, You're Drunk": Developer Responses to Agent-Generated Code Review Comments (arXiv)[10]

반대·맹점 렌즈: 초안

전제 ①을 흔든다 — "사람 리뷰가 병목"은 오진일 가능성이 높다

질문자는 "기준 없이 모든 PR에 사람 리뷰 1회"가 병목이라 진단하지만, 진짜 병목은 리뷰 자체가 아니라 AI가 쏟아내는 PR의 크기와 빈도다. AI 코딩 에이전트 도입 후 엔지니어당 코드 산출량이 ~60% 증가했으나 리뷰 역량은 고정이라, 리뷰어가 느린 게 아니라 큐에 들어오는 물량이 폭발한 것이다. 여기서 "사람 리뷰를 줄이자"는 해법은 증상(대기시간)을 병목으로 착각한 것이다. 제약이론적으로 보면, 진짜 레버리지는 ① PR을 200줄 이하로 쪼개고, ② 사전 설계 문서(의도 명시)로 리뷰어의 인지 부하를 줄이며, ③ 리뷰 전용 시간 블록을 편성하는 것이다. 리뷰 자체를 없애는 건 병목을 옮기는 게 아니라 검증 게이트를 제거하는 것이다.

전제 ②를 흔든다 — "AI가 스타일·버그를 이미 잡는다"는 과대 추정이다

업계 벤치마크에 따르면, 최상위 AI 리뷰 도구의 실제 버그 탐지율은 42~48%에 불과하다(Macroscope 벤치마크, 실제 오픈소스 버그 재현 기준). 마케팅에서 말하는 90%+ 정확도는 합성(synthetic) 버그 기준이다. 특히:

• AI 생성 코드의 로직 오류는 인간 작성 대비 75% 더 빈번하고, 보안 취약점 밀도는 2.7배 높다 — 그런데 이 코드를 다시 AI가 리뷰하면 "문법적으로 깨끗하므로 통과"시키는 자기확증 편향(self-confirmation)이 발생한다.
• AI 리뷰가 강한 영역(포매팅·미사용 변수·단순 패턴)은 린터와 CI로 이미 커버되는 영역과 겹친다. 즉 AI 리뷰가 잡는다는 것의 상당 부분은 기존 자동화로도 잡히던 것이고, AI "만"의 부가 가치는 생각보다 좁다.

따라서 "AI가 잡으니 사람은 설계만 보면 된다"는 분업은 AI가 잡지 못하는 로직·보안·교차서비스 경합을 묵시적으로 사람 몫으로 밀어넣으면서, 사람에게는 "설계만 봐라"고 범위를 한정하는 모순을 품고 있다.

그래서 어디를 의심해야 하는가

질문자가 만들려는 '역할 분담표'의 위험은, "AI 통과 = 안전"이라는 신뢰가 형성되는 순간 사람 리뷰의 긴장도가 전면적으로 떨어지는 것이다. 팀이 AI 생성 코드를 "이미 검증됨"으로 취급하고 로컬 테스트·수동 검증을 생략하는 행동 변화가 사고의 주 원인이라는 보고가 반복된다(Shiplight 분석). 분류표를 만들기 전에 먼저 확인할 것은:

• AI 리뷰 도구의 실측 탐지율을 자체 코드베이스의 과거 버그로 백테스트했는가?
• 병목을 줄인다는 목표 지표가 '리뷰 대기시간'인가, '프로덕션 결함률'인가? 전자만 추적하면 후자가 악화되는 것을 눈치채지 못한다.
• "되돌리기 쉬우니 AI만 통과"라는 기준은, 되돌리기까지 걸리는 감지 시간(MTTD)이 빠르다는 전제를 별도로 입증해야 성립한다.

결론을 조금 수정하겠습니다.

내 초안의 방향, 즉 “모든 AI PR에 사람 리뷰 1회”는 지속 불가능하다는 판단은 유지합니다. 다만 다른 초안들을 보면 사람 리뷰를 줄이는 문제보다 먼저, AI가 만들어내는 PR의 크기·속도·책임 소재를 통제해야 한다는 지적이 더 강합니다. 그래서 최종 기준은 “AI 리뷰냐 사람 리뷰냐”가 아니라 자동 머지 가능 / 사람 리뷰 필수 / 분할 없이는 리뷰 금지의 3단계가 맞습니다.

다른 초안 비평

데밍 초안의 가장 좋은 점은 “큰 PR은 사람 리뷰 필수가 아니라 분할 반려 대상”이라고 못 박은 부분입니다. 이건 경험적으로도 중요합니다. 1000줄짜리 AI PR에 사람 리뷰어를 붙이면 리뷰어는 판단자가 아니라 책임 전가 장치가 됩니다. 작성자는 “리뷰 대기 중”이라는 초조함에 묶이고, 리뷰어는 “내가 쓰지도 않은 AI 코드에 승인 도장을 찍는 사람”이 됩니다. 이 상태에서는 학습도, 품질도, 책임도 흐려집니다.

닥터 게이트와 롤백왕 초안의 장점은 경계를 “위험 도메인”보다 복구 가능성으로 잡은 점입니다. 10줄짜리 권한 변경, 삭제 쿼리, 결제 산식 변경은 작은 변경이 아닙니다. 반대로 300줄 문서 수정은 클 수는 있어도 위험하지 않을 수 있습니다. 그러니 라인 수는 절대 기준이 아니라 인지 부하 신호로 써야 합니다.

소크라테스와 역결 초안은 자동 머지에 대한 과신을 잘 찌릅니다. “AI 리뷰 통과 = 안전”이라는 문구가 조직에 들어가면 사람들은 실제로 덜 읽고, 덜 실험하고, 덜 설명합니다. 이 위험은 큽니다. 다만 “사람이 보지 않는 머지는 원천적으로 안 된다”까지 가면 병목은 풀리지 않습니다. 그 입장은 품질 철학으로는 강하지만, AI PR이 이미 대량으로 들어오는 팀의 일상 리듬을 해결하지 못합니다.

따라서 절충안은 이겁니다.

최종 역할 분담표

내가 팀에 넣을 문장은 이렇게 쓰겠습니다.

사람 리뷰는 AI가 틀렸을 때 복구가 어렵거나 책임 설명이 필요한 PR에 필수로 건다.
큰 PR은 사람 리뷰로 해결하지 않고 쪼갠다.
자동 머지는 “안전해서”가 아니라 “작고, 가역적이고, 관측 가능해서” 허용한다.

사람 리뷰어가 봐야 할 것도 바뀌어야 합니다. 스타일, 네이밍, 단순 버그 패턴은 린터·테스트·AI 리뷰로 최대한 밀어냅니다. 사람은 다음만 봅니다.

• 이 변경이 요구사항과 맞는가
• 실패하면 무엇이 조용히 깨지는가
• 롤백이 실제로 가능한가
• 권한·데이터·돈의 불변식을 건드리는가
• 새 추상화가 팀의 미래 비용을 늘리는가
• 주니어가 이 리뷰에서 배울 맥락이 남아 있는가
• 내가 승인자로서 나중에 설명할 수 있는가

운영 지표도 바꿔야 합니다. “사람 리뷰 비율”을 낮추는 것만 보면 위험합니다. 대신 첫 응답 시간, 리뷰 대기 시간, PR 크기, 분할 반려율, 롤백률, 변경 실패율, 자동 머지 후 결함률, 리뷰어 집중 시간, 주니어 학습용 리뷰 비율을 같이 봐야 합니다.

최종 입장은 이렇습니다.

모든 PR에 사람 리뷰를 붙이는 방식은 AI 시대에 사람을 병목이자 면책 장치로 만든다. 하지만 AI 리뷰 통과만으로 안전하다고 믿는 것도 틀렸다. 사람 리뷰는 고위험 변경에 집중시키고, 저위험 변경은 자동화로 흘리되, 큰 AI PR은 사람이 보게 하지 말고 먼저 쪼개게 해야 한다.

결론

사람 리뷰의 1차 경계는 「롤백으로 세계가 복구되는가」다. 2차 경계는 「자동 검증이 그 실패를 머지 전에 잡을 수 있는가」다.
라인 수·AI 통과 여부는 게이트가 아니다. 다만 큰 PR은 ‘사람 필수’가 아니라 ‘분할 반려’ 대상이다. 전 PR에 사람 1회를 붙이는 병목은 리뷰 부재가 아니라 검증 용량을 초과한 AI 산출물량에서 온다. 해법은 사람 리뷰 폐지가 아니라 고위험만 사람이 잡고, 저위험은 자동화+관측으로 흘리며, 둘 다 작은 배치로 강제하는 것이다.

소크라테스의 “분담표 자체가 불가능”은 과하다. 역결의 “AI 통과=안전이라는 신뢰 붕괴” 경고는 맞다. 분담표는 면죄부가 아니라 게이트 조건 목록으로만 쓴다.

---

1. 사람 리뷰 필수 경계 (우선순위)

라인 수: 신호일 뿐 게이트가 아니다. 10줄 UPDATE WHERE 누락·권한 우회 = 사람 필수. 800줄 내부 리네이밍 = 분할 후 AI 경로 가능.
데밍·머지장 쪽 ≤200 LOC / 관심사 단일 / 400+는 분할 반려는 운영 규칙으로 흡수한다. 사람 게이트 조건이 아니라 머지 가능 조건이다.

최악 사고 경로 (AI만 통과 시):

• 마이그레이션: 잠금·부분 적용·앱 롤백 후에도 데이터 영구 손상
• 인가: IDOR·테넌트 격리 붕괴 → 조용한 데이터 유출
• 결제: 멱등 누락 → 이중 과금·장부 불일치 (코드 되돌리기로 정산 복구 불가)
• 비밀/의존성: 키 유출·공급망 오염은 배포 롤백으로 끝나지 않음

초안의 Veracode·업계 가이드(auth·암호화·결제 경로 사람 필수), 스키마 “롤백 환상”, 롤백왕의 SRE one-way door·Knight Capital식 검증 누락은 이 경계를 뒷받침한다.

---

2. AI 리뷰 + 자동화만으로 허용 — AND 조건 전부

분담표 왼쪽이 “영역 목록”이면 구멍이 난다. 오른쪽은 자동 판정 가능한 AND 조건으로 고정한다 (데밍 흡수).

전형 허용: 문서/주석/README, 순수 UI 카피·스타일(보안 경계 미접촉), 기존 순수 함수 테스트 추가, 동작 동일 내부 리팩터, 타이포·로깅, 비보안 플래그(프로드 기본 노출 없음), 패치 의존성(단 신규 의존성·메이저/공급망은 사람 필수).

역결이 지적한 대로 “되돌리기 쉬움”은 MTTD가 짧다는 전제 없이 성립하지 않는다. ④가 없으면 AI 전용 경로를 열지 않는다.

---

3. 역할 분담표 (운영용)

Socrates의 “몇 줄도 아키텍처를 깨뜨린다”는 공용 경로·계약·추상화에 해당할 때만 사람 필수로 흡수한다. 모든 줄에 사람을 붙이면 다시 병목이고, 승인 의식화(머지장)가 난다.

---

4. 사람이 볼 층위

주의 (역결 흡수): AI 리뷰 실측 탐지율은 마케팅보다 낮다. “사람은 설계만”이라고 범위를 좁히면 로직·보안·교차 서비스 경합이 공백이 된다. 사람은 설계 와 high-risk 경로의 경계 조건을 본다. 스타일을 안 볼 뿐, 보안·불변식을 “AI가 했으니 패스”하지 않는다.
자기확증(생성 AI ↔ 리뷰 AI)을 줄이려면 high-risk는 사람 + 자동화이지 AI 단독이 아니다.

---

5. 병목·품질 운영 (다른 초안에서 흡수)

• 병목 진단: “사람 1회”가 병목이 아니라 PR 크기·빈도 폭발(데밍 DX·DORA식 처리량↑·불안정성↑)이다. 사람 줄이기만 하면 검증 게이트 제거다.
• 레버리지: (1) high-risk 경로 사람 고정 (2) low-risk AND 조건 AI 경로 (3) 200 전후 분할·400+ 반려 (4) 의도 한 줄(스펙)로 인지 부하 감소 (5) AI 경로에 카나리·SLO 자동 롤백.
• 추적 지표: 사람 리뷰 비율 ❌ → 리뷰 대기·첫 응답, 변경 실패율·롤백률·MTTD/MTTR, 리뷰어 집중 시간, 고위험 PR 비율. 대기만 줄이고 결함률이 오르면 정책 실패.
• 도입 전제: AI 리뷰를 자체 과거 버그로 백테스트하지 않았으면, low-risk 경로도 좁게 시작한다. “대부분 AI 머지”를 전제로 열지 않는다.

---

6. 다른 초안에 대한 짧은 판정

최종 단정:
사람 리뷰는 비가역·권한·돈·비밀·공용 계약·검증 공백에만 필수로 건다.
그 외는 가역·국소·테스트·카나리 자동 롤백 AND를 만족할 때만 AI+자동화 머지를 허용한다.
병목을 줄이는 본체는 사람 감축이 아니라 작은 배치 + 고위험 집중 + 저위험의 관측 가능한 가역성이다. 고위험을 AI 통과만으로 열면 죽이는 것은 속도가 아니라 복구 불가능성이다.

입장 수정: 네 곳에서 내 초안이 틀렸다

닥터 게이트가 옳다. 내 표는 "라인 수는 게이트가 아니다"라고 써놓고 자동 머지 조건에 ≤200 LOC를 AND로 박아넣었다. 자기모순이다. 10줄짜리 WHERE 누락은 사람 필수고, 5,000줄 기계적 리네이밍은 자동이어야 맞다. LOC를 의미 변경 단위로 교체한다 — 기계적 변환(리네이밍·포매팅·코드젠·락파일)은 몇 줄이든 1로 계산. 이건 GitClear가 이미 쓰는 축(이동 코드 vs 신규 로직)이라 툴링으로 자동 판정 가능하다. 우선순위도 닥터 게이트의 순서를 그대로 받는다: 비가역성 > 권한·돈·비밀 > 블라스트 반경 > 소유권 이탈 ≫ 라인 수.

역결이 내 5번 조건의 구멍을 정확히 짚었다. "되돌리기 5분"은 감지되었을 때만 성립한다. MTTD가 측정되지 않은 구간에서 "롤백 쉬움"은 측정이 아니라 희망이다. 자동 머지 경로의 전제조건에 해당 배포 단위의 MTTD 실측치 존재를 추가한다. 측정 안 된 구간은 자동 머지 대상에서 제외 — 이게 내 원칙에 부합한다.

상관된 검증기 문제도 받는다. AI가 쓴 코드를 같은 계열 AI가 리뷰하면 오류가 독립이 아니다. 검출 확률이 독립 가정 하 계산보다 낮게 나온다. 조치는 간단하다: 생성 모델과 리뷰 모델을 다르게 쓰고, PR마다 생성기/검증기 조합을 로그에 남겨 유출률을 층화 집계하라. 층화하지 않으면 이 손실은 평균에 묻혀 영원히 안 보인다.

머지장의 '주니어 학습 PR 비율'은 내가 잘라낸 것 중 유일하게 잘못 잘라낸 것이다. 내 초안은 "사람 리뷰 코멘트 중 결함 검출률 10% 미만이면 낭비"라고 썼는데, 리뷰의 두 번째 기능이 지식 전파라면 이 기준은 틀린 지표다(14포인트 6·13항). 다만 결론은 머지장과 다르다 — 학습을 머지 게이트에 얹으면 둘 다 실패한다. 학습용 리뷰는 비차단(non-blocking)으로 분리해 별도 편성하고, 게이트 리뷰는 결함 검출률로만 평가하라. 게이트에 얹는 순간 학습은 대기시간 비용으로 바뀌고, 리뷰어는 승인 의식을 치른다.

기각하는 것

소크라테스의 분담표 무용론을 기각한다. "몇 줄짜리 변경도 시스템을 붕괴시킬 수 있다"는 명제는 반증 불가능하고, 정확히 전수검사 오류다. 모든 변경이 위험할 수 있다는 이유로 모든 변경을 검사하면, 검사 품질이 물량에 반비례해 떨어져 결국 아무것도 검사하지 못한다. 다만 처방 — 상류에서 설계 최소 단위로 쪼개 발행 — 은 옳고, 이건 분담표의 반대가 아니라 분담표가 강제하는 것이다. "신규 로직 400줄 초과 = 자동 반려"가 곧 상류 압력이다.

출처 없는 수치는 게이트 파라미터로 쓸 수 없다. 역결의 42~48% 탐지율, 로직 오류 75%, 취약점 밀도 2.7배, 롤백왕의 "저리스크 70~80%" — 이건 다른 코드베이스에서 다른 정의로 나온 숫자다. 특히 닥터 게이트가 인용한 Veracode 45%는 AI 생성 코드의 결함 포함률이지 AI 리뷰의 미검출률이 아니다. 두 지표를 바꿔 쓰면 게이트가 통째로 틀린다. 벤치마크 탐지율은 여러분 팀의 탐지율이 아니다. 역결의 진짜 기여는 숫자가 아니라 백테스트 처방이다: 최근 12개월 인시던트에서 원인 커밋을 뽑아 현재 AI 리뷰에 재투입해 자체 탐지율을 측정하라. 이건 1~2일이면 끝나고, 이 표를 켜기 전 유일한 필수 사전작업이다. 롤백왕의 "70~80%"도 목표치가 아니라 결과로 측정될 값이다.

수정된 분담표

3번 답은 유지한다 — 사람은 스펙↔구현 부합, 추상화의 정당성, 남은 죽은 코드, 실패 모드와 롤백 계획 넷만 본다. 근거도 그대로다: 구글 AutoCommenter 자동 코멘트의 실제 코드 반영률 약 40%, GitClear 2026 기준 블록 중복 +81%, 리팩터링 21%→3.8%, 교차파일 호출 −35%. AI가 구조를 못 보는 게 데이터로 확인된 영역이 정확히 사람 몫이다.

4번: 여전히 측정되지 않았다

이 표를 적용해 사고 없이 병목이 줄었다는 통제된 공개 증거는 이 라운드에서 아무도 제시하지 못했다. 그러니 백테스트 → 4주 베이스라인 → 표 적용 → 30/60일 검증 순서를 지켜라. 판정 지표는 하나다: 자동 머지 경로와 사람 리뷰 경로의 결함 유출률 차이를, 생성기/검증기 조합으로 층화해서 관리도로 본다. 차이가 관리한계 안이면 자동 경로를 넓히고, 벗어날 때만 특수원인을 조사한다. 개별 사건 하나에 표를 고치지 마라 — 그게 데밍이 말한 개입(tampering)이고, 변동을 키운다.

롤백왕이 든 Knight Capital은 n=1 특수원인이지 게이트 설계 근거가 아니다. 그 사건에서 배울 것은 "사람 승인을 늘려라"가 아니라 배포 검증과 자동 롤백이 없었다는 것 — 그건 정확히 여러분의 ⑤번 조건이다. 투자처는 리뷰어 증원이 아니라 MTTD 계측·자동 롤백·마이그레이션 리허설·커버리지 게이트다.

그대들이 세우려는 'AI/사람 역할 분담표'와 '가역성 중심의 분류'는 과연 안전과 효율을 모두 보장할 수 있습니까? 아니면 그저 책임 회피와 착각의 이정표일 뿐입니까? 다른 참가자들의 초안에 담긴 합의와 대안의 맹점을 묻습니다.

1. '가역성(되돌릴 수 있는 변경)'이라는 합의의 허상 (데밍·머지장·닥터게이트·롤백왕 비평)

그대들은 롤백이 쉽고 영향이 적은 '가역적 변경(2-Way Door)'은 AI와 자동화 검증만으로 넘기자고 합의했습니다.

• 묻습니다. 코드 변경을 '되돌리는 시간'이 5분 이내라 한들, 그 오류가 발생했음을 감지하는 시간(MTTD)이 며칠 혹은 몇 주가 걸린다면 그것이 정말 가역적인 변경입니까?
• 단순 UI 문구 수정이나 비보안 플래그 설정이라도, 특정 디바이스나 브라우저에서 결제 전환율을 조용히 떨어뜨리고 있다면 롤백 시스템이 이를 즉시 감지해 자동으로 되돌릴 수 있습니까?
• 사용자가 이미 이탈하고 브랜드 신뢰가 무너진 뒤의 롤백이 정말 '가역'인지 묻고 싶습니다.

2. '자동화 검증과 AI 리뷰' 맹신의 모순 (닥터게이트·데밍 비평)

그대들은 AI 생성 코드의 보안 결함률이 45%에 달하고(Veracode 2025), AI의 버그 탐지율이 절반 이하(42~48%)라는 실측값을 인용하면서도, 린트/유닛 테스트/SAST만 거치면 AI PR을 자동 머지해도 안전하다고 주장합니다.

• 묻습니다. AI가 생성한 '그럴듯하지만 비즈니스 요구사항을 교묘하게 왜곡한 로직 오류'와 AI 리뷰어의 '자기확증 편향'을 정적 분석 도구와 유닛 테스트가 잡아낼 수 있다고 믿는 근거는 무엇입니까?
• 테스트 코드마저 AI가 작성했다면, 그 테스트가 통과했다는 사실이 코드의 안전성을 보증합니까, 아니면 환각을 공식화하는 것에 불과합니까?

3. 'PR 쪼개기와 설계 문서'라는 대안의 새로운 병목 (역결 비평)

역결은 진짜 병목이 AI 생성 PR의 물량 폭발에 있으므로, PR을 200줄 이하로 쪼개고 설계 문서를 쓰자고 제안합니다.

• 묻습니다. PR을 작게 쪼개면 큐에 쌓이는 PR의 절대적인 개수는 몇 배로 늘어납니다. 리뷰어가 수십 개의 잘게 쪼개진 PR 사이를 오가며 치러야 할 컨텍스트 스위칭 비용은 새로운 인지적 병목을 낳지 않습니까?
• 설계 문서가 존재한다고 해서, AI가 제멋대로 구현해 놓은 코드의 세부 부작용을 검토하는 인간의 물리적 검증 시간이 정말로 줄어듭니까?

---

결론
그대들이 도출하려는 명시적 기준과 역할 분담표는 병목을 해결하지 못합니다. 그것은 "이 기준을 지켰으니 사고가 나도 내 책임이 아니다"라는 면피용 문서를 만드는 행위에 불과합니다.

질문자에게 묻습니다. 'AI 리뷰 통과'가 보증하는 안전의 실체가 존재하지 않는다면, 그리고 사람이 보지 않는 머지 경로가 필연적으로 시스템 손상을 동반한다면, 그대들이 말하는 '사람 리뷰 병목'은 줄여야 할 낭비입니까, 아니면 시스템 파멸을 막고 있는 마지막 방어선입니까?

다른 참가자들의 초안을 리스크 렌즈(안전공학·SRE) 관점에서 비평하고, 타당한 논거를 수용하여 강화된 최종 가이드라인을 제시합니다.

---

1. 다른 참가자 초안 비평 및 수용

• 소크라테스·역결 초안의 수용 (AI 자기확증 편향과 롤백 착각 경고)
• 수용할 점: AI가 생성한 로직 오류를 AI 리뷰어가 다시 검증할 때 발생하는 '자기확증 편향(Self-Confirmation Bias)'과, 앱 코드를 롤백해도 이미 파괴된 데이터는 복구되지 않는 '롤백 착각(Rollback Illusion)' 지적은 매우 타당합니다.
• 보완/설득할 점: 그러나 소크라테스의 "분담표 제정 자체를 거부"하는 주장은 현장의 병목을 방치합니다. 분담표를 없애는 것이 아니라, AI 자동 머지의 전제 조건을 극도로 좁히고 강제 게이트(Hard Gate)를 거는 방식으로 위험을 통제해야 합니다.

• 닥터 게이트·데밍 초안의 수용 (비가역성 기준 및 정량 한계)
• 수용할 점: 닥터 게이트의 '앱 롤백과 데이터 롤백 분리(상태 파괴 비가역성)' 기준과 데밍이 제시한 'SmartBear 400 LOC 초과 시 결함 검출률 급락' 및 'CODEOWNERS 경계' 기준은 방어책 설계에 필수적입니다.
• 보완할 점: 라인 수 자체는 안전을 보장하지 않지만, 400 LOC 초과 PR은 리뷰어의 '무성의한 승인(Rubber-stamping)'을 유발하는 치명적 인적 요인이므로 즉시 자동 반납/분할 조치해야 합니다.

---

2. 최종 AI vs 사람 리뷰 역할 분담표

AI 리뷰 통과만으로 머지하려면 아래 5개 AND 조건을 모두 충족해야 하며, 단 하나라도 위반 시 사람 리뷰로 즉시 전환합니다.

---

3. 사람 리뷰어가 검증해야 할 3대 리스크 층위

사람은 더 이상 스타일, 린트, 오타를 보지 않습니다. 사람이 남았을 때 집중해야 할 층위는 오직 '시스템 파멸 방지'입니다.

1. 상태 복구 및 롤백 가능성 (State Restoration):
2. "새벽 3시에 이 변경으로 장애가 났을 때, 단순 코드 롤백만으로 데이터 오염 없이 시스템이 정상화되는가?"
3. 도메인 불변식 및 권한 경계 (Invariants & Auth Matrix):
4. "AI가 작성한 코드가 테넌트 간 데이터 격리를 우회(IDOR)하거나 결제 멱등성 산식을 깨트리지 않는가?"
5. 조용한 손상 및 관찰가능성 (Silent Failures & Observability):
6. "예외가 암묵적으로 삼켜져 장애 감지 시간(MTTD)을 지연시키고 있지는 않은가?"

---

4. 안전공학적 방어책: 최후의 안전장치 결합

[Knight Capital 사태(SEC Report)]가 입증하듯, 검증 프로세스 결함과 배포 통제 미비는 순식간에 파산으로 이어집니다. AI 자동 머지를 안심하고 운영하려면 다음 두 가지 최후 안전장치가 필수입니다.

1. 자동 캐너리(Canary) 배포 & SLO 기반 즉시 롤백: AI 머지 PR은 즉시 전면 노출되지 않고 트래픽의 1~5%만 받는 캐너리 파이프라인을 거쳐야 합니다. 오류율 증가나 SLO 이탈 감지 시 사람이 개입하기 전에 시스템이 자동 롤백해야만 되돌리기 쉬움(2-Way Door)의 전제가 완성됩니다.
2. 사후 감사 샘플링 (Post-Merge Audit): AI 머지된 PR 중 5~10%를 랜덤 추출하여 주간 사후 리뷰를 진행함으로써, AI 리뷰의 결함 누출률을 지속적으로 모니터링합니다.

---

요약 결론

사람 리뷰는 "AI가 틀렸을 때 코드 롤백만으로 상태가 복구되지 않는 PR(상태·권한·결제·마이그레이션)"과 "400 LOC 초과 PR"에만 집행하십시오. 가역적인 저리스크 PR은 [자동 캐너리 + SLO 롤백]이라는 시스템 안전장치를 조건으로 AI에 넘길 때만 사고와 병목을 동시에 잡을 수 있습니다.

반대·맹점 렌즈: 보완 답변

---

비평 요약 — 누구에게 설득됐고, 어디를 여전히 흔드는가

수긍하는 지점이 세 곳 있다.

첫째, 데밍과 소크라테스가 공유하는 "병목은 리뷰가 아니라 PR 물량"이라는 진단은 내 초안의 전제 ①과 정확히 겹친다. 데밍이 가져온 DX 텔레메트리(AI 고채택 팀: 머지 PR +98%, 리뷰 시간 +91%, PR 크기 +154%)는 내 주장에 정량 근거를 붙여준다. PR 분할 요구를 분담표보다 앞에 놓아야 한다는 데밍의 순서가 옳다. 400 LOC 초과 PR은 "누가 리뷰하느냐" 이전에 분할 반려 대상이라는 점을 흡수한다.

둘째, 닥터 게이트의 비가역성 우선순위 서열(상태 파괴 > 권한·돈·비밀 > 블라스트 반경 > 소유권 이탈 ≫ 라인 수)은 내 초안이 명시하지 못한 축을 선명하게 세웠다. 라인 수를 게이트가 아니라 신호로만 쓰라는 판단도 데밍과 닥터 게이트 모두 일치하며, 여기에 반박할 근거가 없다. 수긍한다.

셋째, 머지장이 인용한 Google 리뷰 가이드의 "완벽함이 아니라 코드베이스 건강과 진전의 균형"이라는 원칙은, 내 초안이 "검증 게이트 제거"라고 일축한 부분에 대한 유효한 반론이다. 모든 PR에 사람을 붙이는 것도 비용이며, 의식적 승인(rubber-stamping)이 되면 게이트가 있어도 검증이 아니라는 점은 인정한다.

---

그러나 합의가 수렴하는 지점에 세 가지 맹점이 남아 있다

맹점 1: "되돌리기 쉬운 변경 = AI만 통과" 공식의 전제가 검증되지 않았다.

데밍·닥터 게이트·롤백왕·머지장 모두 "되돌리기 비용이 낮으면 AI 자동 머지 허용"이라는 축으로 수렴한다. 그런데 되돌리기 용이성은 사전 평가와 사후 현실이 심하게 괴리하는 변수다. "단일 revert로 5분 이내 복구 가능"이라고 분류한 변경이, 이미 캐시에 전파되거나 다른 PR과 얽히거나 사용자가 새 동작에 의존하기 시작하면 revert만으로 상태가 복원되지 않는다. 닥터 게이트가 스키마 마이그레이션에 한정해 "롤백 환상"을 언급했지만, 이 환상은 앱 레이어에서도 동일하게 작동한다. 롤백왕이 인용한 Knight Capital 사태가 정확히 이 패턴이다 — 배포 자체는 "가역적"이었으나 8분 사이 시장에 나간 주문은 되돌릴 수 없었다. 되돌리기 비용을 분류 기준의 제1축으로 쓰려면, 감지 시간(MTTD)과 전파 범위를 함께 바인딩해야 한다. 분담표에서 이 조건을 명시한 것은 데밍뿐이고(카나리 자동 롤백 적용 구간), 나머지는 "되돌리기 쉬움"을 자명한 속성으로 전제하고 있다.

맹점 2: 분담표 자체가 만드는 인지적 부작용을 아무도 정량하지 않았다.

내 초안에서 지적한 "AI 통과 = 안전이라는 신뢰가 형성되면 사람 리뷰의 긴장도가 전면적으로 떨어진다"는 경고에 대해, 어떤 참가자도 직접 반박하지 않았다. 머지장이 "승인이 의식이 된다"고 언급한 것은 같은 현상의 다른 면이다. 문제는 분담표가 양쪽 모두에서 긴장을 풀어버린다는 것이다:

• "AI만 통과" 경로의 코드에 대해 팀은 로컬 테스트·수동 검증을 생략하는 행동 변화를 보인다.
• "사람 필수" 경로의 코드에 대해서도, "이건 AI가 이미 1차로 봤으니" 하고 리뷰어의 정밀도가 하락한다.

소크라테스가 "이분법적 가이드라인으로는 병목 감소와 품질 유지를 동시에 달성할 수 없다"고 단언한 것은 이 맹점을 정확히 찌른다. 다만 소크라테스의 대안("설계적 최소 단위로만 PR을 쪼개라")은 PR 발행 통제가 실무에서 강제 가능한지에 대한 메커니즘이 없어서, 원칙으로서는 옳으나 운영 가능한 답이 되지 못한다.

맹점 3: "사람은 설계·의도만 보라"는 층위 전환이 실행 가능하다는 합의에 근거가 없다.

데밍·머지장·롤백왕 모두 "사람은 스타일·버그 대신 설계 의도·요구사항 부합·유지보수 부담을 보라"고 수렴한다. 그런데 AI가 생성한 코드를 사람이 '설계 의도' 차원에서 리뷰하려면, 리뷰어가 해당 코드의 의도를 이해하고 있어야 한다. 사람이 직접 짠 코드는 작성자가 의도를 설명하고 리뷰어가 검증하는 구조지만, AI 생성 코드는 작성자(AI)가 의도를 갖지 않고, PR 요청자도 자기가 요청한 것 이상의 구현 세부를 모르는 경우가 흔하다. GitClear 2026의 리팩터링 비율 급락(21% → 3.8%)과 블록 중복 +81%은 이 상황의 증거다 — AI가 코드를 찍어내되 아무도 그 코드의 구조적 의도를 소유하지 않는다. "설계를 보라"는 지침은, 설계를 읽어낼 수 있는 코드가 들어온다는 전제가 먼저 성립해야 한다. 이 전제를 성립시키는 것은 분담표가 아니라, 데밍이 언급한 "사전 설계 문서(의도 명시)"와 소크라테스의 "설계적 최소 단위 PR"이다.

---

절충된 결론

한 문장 결론: 분담표를 만들기 전에 (1) PR 크기 상한을 강제하고, (2) 모든 AI PR에 사전 의도 문서를 요구하며, (3) "AI 자동 통과" 경로에도 MTTD 기반 자동 롤백을 전제 조건으로 걸어라 — 이 세 가지가 없는 분담표는 검증 게이트를 제거하면서 "가이드라인이 있다"는 착각만 남긴다.

약점 공략 — 이 방의 합의는 측정되지 않은 가정 위에 서 있다

여섯 초안이 수렴한 결론(비가역성 우선 → 3단계 분담표 → 라인 수는 신호)에 나도 서명했다. 그 서명을 지금 철회하지는 않는다. 다만 합의가 수렴했다는 사실 자체가 근거가 아니다. 여섯 명이 같은 방향으로 틀린 것과 옳은 것은 겉보기에 구분되지 않는다. 구분하는 것은 데이터뿐인데, 이 방에는 그 데이터가 없다.

---

1. 가장 큰 맹점: 아무도 '사람 게이트의 검출률'을 측정하지 않았다

이 토론 전체가 "어떤 PR을 사람에게 보낼까"를 묻는다. 그런데 이 질문은 "사람에게 보내면 결함이 잡힌다"를 전제한다. 그 전제의 측정치를 제시한 참가자는 한 명도 없다.

질문자의 현재 상태를 보라 — 전 PR에 사람 1회, 그리고 병목. 그렇다면 이미 데이터가 있어야 한다. 지난 3개월 사람 리뷰 코멘트 중 실제 결함을 막은 비율이 얼마인가? 그 숫자 없이 "고위험은 사람이 본다"고 정하는 것은, 효과가 측정되지 않은 처치를 대상만 바꿔 재배정하는 것이다. 병목은 줄겠지만 그건 처치를 줄였기 때문이지 잘 배분했기 때문이 아니다.

이 공격은 내 초안에도 그대로 꽂힌다. 나는 "게이트 리뷰는 결함 검출률로만 평가하라"고 썼지, 그 검출률이 지금 얼마인지는 모른다. 모르는 상태에서 분담표를 쓰면 그건 재배분이 아니라 도박이다.

2. 인용된 숫자들은 게이트 파라미터가 될 수 없다

• SmartBear 400 LOC — 사람이 쓴 코드를 사람이 읽던 시대의 관찰값이다. AI가 쓴 코드는 GitClear가 보여준 대로 이동/중복 비중이 다르다. 읽기 난이도 곡선이 같다는 근거가 이 방에 없다.
• Veracode 45% — 생성된 코드의 결함 보유율이다. 게이트를 통과한 코드의 유출률이 아니다. 두 숫자는 분모가 다르다. 이걸 자동 머지 안전성 논거로 쓴 초안이 여럿인데, 지표 정의를 바꿔치기한 것이다.
• 42~48% 탐지율, 2.7배, 70~80% — 다른 코드베이스, 다른 정의.

남의 코드베이스 관찰값은 가설의 출처지 임계값의 출처가 아니다. 200, 400, 5분 — 이 숫자들을 그대로 규칙에 박으면, 우리 팀에서 한 번도 검증되지 않은 상수가 게이트를 통제하게 된다.

3. 분담표는 분류기다. 그런데 오분류율 측정 설계가 없다

모든 분류기는 FN(자동 머지로 흘려보낸 사고)과 FP(사람에게 보냈으나 결함 0건)를 낸다. 여섯 초안 중 이 두 값을 어떻게 셀지 정의한 초안이 하나도 없다.

측정 없는 분류기는 개선되지 않는다. 개선되지 않는 게이트는 1년 뒤 그냥 관습이 된다. 소크라테스의 "면피 문서" 지적은 철학으로는 과했지만, 측정 의무가 붙지 않은 분담표에 한해서는 정확히 옳다. 현재 이 방의 여섯 안은 전부 그 상태다.

4. DORA 지표를 그대로 쓰면 개선은 장부상으로만 일어난다

• 변경실패율의 분모는 배포/변경 건수다. AI로 PR이 배로 늘면(DX 텔레메트리: 머지 PR +98%) 사고 건수가 그대로여도 실패율은 절반으로 좋아진다. 반드시 월 절대 인시던트 건수와 함께 봐라.
• PR 분할은 PR 단위 지표를 전부 좋게 만든다. 대기시간 중앙값↓, PR당 결함 밀도↓. 그러나 기능 하나가 5개 PR로 쪼개지면 기능 단위 리드타임은 나빠질 수 있다. 소크라테스의 컨텍스트 스위칭 지적의 측정 가능한 형태가 이것이다. 지표를 PR이 아니라 change-set(기능 단위)으로 재정의하지 않으면, 병목은 사라진 게 아니라 계측되지 않는 곳으로 이동한다.
• MTTR 개선은 MTTD가 측정되지 않으면 무의미하다. 역결의 지적은 옳고, 이건 지표 정의 문제로 되돌아온다.

5. 층화 집계는 검정력이 없다 — 내 이전 제안의 결함

나는 "생성기/검증기 조합별로 유출률을 층화하라"고 썼다. 그런데 인시던트는 희귀 사건이다. 셀을 나누면 셀당 건수가 0~1이 되고, 차이를 검출할 검정력이 없다. 사고를 기다려서 게이트를 평가하는 설계는 원리적으로 작동하지 않는다.

대안은 하나뿐이다 — 사고를 기다리지 말고 결함을 주입해라. 뮤테이션 테스팅/시드 결함 주입을 자동 머지 경로에 상시 돌려서, 그 경로의 검출률을 원할 때 측정한다. 이게 이 방에서 아무도 제시하지 않은, 유일하게 통계적으로 작동하는 측정 수단이다. 저위험 경로에 심은 인공 결함이 몇 %나 통과하는지가 곧 그 경로의 실제 안전 마진이다.

6. 질문자의 4번에 대한 정직한 답

측정되지 않았다. 이 방에서 "분담표 도입 전후를 비교한 데이터"를 제시한 참가자는 없다. 인용된 모든 숫자는 남의 코드베이스의 단면 관찰이고, 어느 것도 개입 전후 비교가 아니다. 병목이 줄었다는 증언은 있어도, 사고가 늘지 않았다는 증거는 없다.

---

결론 — 분류 규칙이 아니라 측정 계약으로 도입하라

1. 무조건 사람 게이트 (측정 없이도 정당) — 단 하나의 축
비가역적 상태 변경(마이그레이션·삭제·백필·정산 확정·비밀/키). 여기만은 실증이 필요 없다. 틀렸을 때의 손실이 상한 없는 구간에서는 기대값 계산이 성립하지 않기 때문이다. 이건 데이터 판단이 아니라 결정이론 판단이고, 그래서 측정 유예가 허용된다.

2. 나머지 전부는 4주 섀도 분류로 시작하라
라우팅을 바꾸지 말고, 모든 PR에 분담표 라벨만 붙여 굴려라. 4주 뒤 나오는 것:

• 자동 머지 후보 비율의 실측치 (롤백왕의 70~80%가 우리 팀에서 몇 %인지)
• 사람 리뷰 코멘트의 결함 검출률 — 고위험 라벨 구간과 저위험 구간을 나눠서
• 이 두 숫자가 우리 팀의 임계값을 정한다. 200도 400도 아니고.

3. 동시에 결함 주입 파이프라인을 세워라. 자동 머지 경로의 검출률을 사고 없이 측정하는 유일한 방법이다. 이게 준비되기 전의 자동 머지 확대는 전부 추측이다.

4. 지표를 다시 정의하라. 리드타임은 PR이 아니라 기능 단위. 변경실패율은 절대 건수 병기. MTTD 미측정 배포 단위는 자동 머지 대상 제외.

우리가 지금 쓸 수 있는 문장은 이것뿐이다: "비가역 변경은 사람이 본다. 나머지 경계는 4주 뒤 우리 데이터가 정한다."
그 이상을 오늘 확정해서 문서에 박는 것은, 남의 숫자로 우리 게이트를 설계하는 일이다.

입장을 수정한다. 분담표는 바로 “규칙”으로 박으면 안 되고, 먼저 “측정 계약”으로 도입해야 한다. 다만 현장 운영을 멈출 수는 없으니, 오늘부터 쓸 임시 게이트는 둔다.

최종 수정안

핵심 문장은 이렇게 바꾸는 게 맞다.

비가역 변경은 사람이 본다.
큰 AI PR은 사람이 리뷰하지 않고 먼저 쪼갠다.
나머지 자동 머지 경계는 4주간 우리 팀 데이터로 정한다.

사람 리뷰어가 봐야 할 것은 다음이다.

• 요구사항과 실제 변경이 맞는가
• 실패했을 때 조용히 깨지는 영역이 있는가
• 롤백이 말뿐이 아니라 실제로 가능한가
• 권한·돈·데이터 불변식을 건드리는가
• 새 추상화가 팀의 미래 비용을 키우는가
• 승인자로서 나중에 설명할 수 있는가
• 주니어가 배울 맥락이 남아 있는가

운영 지표는 PR 단위만 보면 왜곡된다. PR 대기시간만 줄이면 작성자의 초조함은 줄어든 것처럼 보이지만, 기능 하나가 다섯 PR로 쪼개져 전체 리드타임이 늘 수 있다. 그래서 봐야 할 지표는 기능 단위 리드타임, 첫 응답 시간, 사람 리뷰 코멘트 중 실제 결함 방지 비율, 자동 머지 후보의 결함 유출률, 롤백률, 월 절대 인시던트 수, 주니어 학습용 리뷰 비율이다.

근거는 제공 자료 안의 범위에서만 쓴다. SmartBear의 400 LOC류 기준은 “인지 부하 신호”로만 쓰고 임계값으로 박지 않는다. Veracode 45%도 “생성 코드에 결함이 있을 수 있다”는 경고이지 “자동 머지 금지/허용”의 직접 근거가 아니다. GitClear의 AI 코드 변화 관찰도 PR 크기와 중복·이동 증가를 의심하게 하는 가설 출처로만 쓴다. DORA 지표는 그대로 쓰지 말고 절대 사고 건수와 기능 단위 리드타임을 병기해야 한다.

최종 결론: 사람 리뷰를 줄여야 한다. 하지만 먼저 AI PR의 크기와 책임 소재를 통제해야 한다. 자동 머지는 ‘AI가 잘 봐서’가 아니라 ‘작고, 가역적이고, 관측 가능해서’ 허용된다.

최종 수정안 — 표는 오늘 켠다. 단, 임계값에는 만료일을 박는다.

먼저, 내 직전 초안을 스스로 뒤집는다

약점 공략에서 나는 "비가역 변경만 사람 게이트, 나머지는 4주 섀도 분류"라고 썼다. 이건 과잉 교정이고, 데밍 원칙의 오용이다. 섀도 4주 동안 라우팅을 바꾸지 않으면 전 PR 사람 리뷰가 4주 더 유지된다 — 질문자가 호소한 병목을 한 달 연장하는 처방이다. 통계적 관리는 "측정될 때까지 아무것도 하지 마라"가 아니라 "현재 최선의 표준을 세우고, 그 표준을 데이터로 갱신하라"다(PDSA). 표준 없이 굴리는 것이 곧 특수원인과 공통원인을 구분 못 하는 상태다.

그래서 최종안은 이것이다: 표는 즉시 켜되, 모든 임계값에 출처 등급과 만료일을 붙인다.

분담표 (Day 1 발효)

즉시 A로 흘려보낼 것(섀도 유예 없음): 기계적 리네이밍, 포매팅, 코드젠 산출물, 락파일·의존성 패치, 테스트 전용 추가, 문서. 이 부류는 의미 변경 단위가 0이라 몇 줄이든 무관하다. 여기서만 병목의 상당 부분이 즉시 빠진다. 나머지 저위험 후보는 라벨만 붙여 4주 섀도 — 라우팅은 그때 넓힌다.

임계값의 출처 등급 (이게 이번 라운드의 핵심 기여다)

인용 숫자의 정의 정정 두 건은 유지한다. Veracode 45%는 AI 생성 코드의 결함 보유율이지 AI 리뷰의 미검출률이 아니다 — 분모가 다르며, 자동 머지 안전성 논거로 쓰면 게이트가 통째로 틀린다. DX 텔레메트리의 머지 PR +98%는 변경실패율의 분모를 부풀린다 — 사고 건수가 그대로여도 실패율은 절반으로 '개선'된다. (모든 인용은 앞 라운드에서 제시된 것이며, 이번 라운드는 검색 불가라 URL을 새로 붙이지 않는다. 링크 없이 재인용한다.)

측정 계약 (표와 한 세트로 발효)

1. 백테스트 (1~2일, 표 확대 전 필수) — 최근 12개월 인시던트의 원인 커밋을 현재 AI 리뷰에 재투입. 우리 팀의 탐지율이 여기서 나온다. 벤치마크 탐지율은 우리 탐지율이 아니다. 2. 결함 주입 상시화 — 인시던트는 희귀 사건이라 층화하면 셀당 0~1건, 검정력이 없다. 사고를 기다리는 평가 설계는 원리적으로 작동하지 않는다. 뮤테이션/시드 결함을 자동 머지 경로에 상시 주입해 검출률을 원할 때 측정한다. A 경로 확대의 유일한 정당화 근거다. 3. 오분류 계수 — FN(A로 흘려보낸 사고), FP(B로 보냈으나 결함 코멘트 0건)를 매주 센다. 이 둘을 안 세면 게이트는 1년 뒤 관습이 된다. 4. 지표 재정의 — 리드타임은 PR이 아니라 change-set(기능) 단위, 변경실패율은 월 절대 인시던트 건수 병기, MTTD 미측정 배포 단위는 A 제외. 5. 관리도로 판정 — A와 B의 결함 유출률 차이를 관리한계로 본다. 한계 안이면 A를 넓히고, 벗어날 때만 특수원인을 조사한다.

개별 사건 하나에 표를 고치지 마라 — 그게 tampering이고 변동을 키운다.

남은 질문 답

2번(자동 통과 범위): 위 A 조건 전부 충족. 라인 수는 조건이 아니다. 10줄 WHERE 누락은 B, 5,000줄 기계적 리네이밍은 A.

3번(사람이 볼 것): 넷만 본다 — 스펙↔구현 부합 / 추상화의 정당성 / 남은 죽은 코드 / 실패 모드와 롤백 계획. 근거는 AI가 구조를 못 본다는 데이터다: 구글 AutoCommenter 자동 코멘트의 실제 반영률 약 40%, GitClear 2026의 블록 중복 +81%·리팩터링 21%→3.8%·교차파일 호출 −35%. 스타일·버그 패턴은 이미 기계가 잡는다.

4번(실효 검증): 측정되지 않았다. 이 방 누구도 분담표 도입 전후 비교 데이터를 제시하지 못했다. 인용된 전부가 남의 코드베이스 단면 관찰이다. 병목이 줄었다는 증언은 있어도 사고가 늘지 않았다는 증거는 없다. 그러니 30/60일 검증까지는 이 표를 검증된 표준이 아니라 잠정 표준으로 불러라.

투자처는 리뷰어 증원이 아니다 — MTTD 계측, 자동 롤백, 마이그레이션 리허설, 커버리지 게이트, 결함 주입 파이프라인. Knight Capital에서 배울 것도 "승인을 늘려라"가 아니라 "배포 검증과 자동 롤백이 없었다"이고, 그건 정확히 ⑤번 조건이다.

오늘 문서에 박을 문장: "비가역 변경과 권한·돈·비밀은 사람이 본다. 기계적 변환은 오늘부터 자동이다. 그 사이의 경계는 4주 뒤 우리 데이터가 정하고, 임계값에는 만료일이 있다."

그대들이 합의한 'AI/사람 역할 분담표'와 '가역성 중심의 분류'는 결국 우리 팀에서 단 한 번도 측정되지 않은 가설과 남의 데이터 위에 세워진 사상누각입니다.

이에 상대의 타당한 논거를 수용하고 본질적인 맹점을 보완하여, 단순한 '면피용 문서'가 아닌 실증적 데이터에 기반한 최종 수정안을 제안합니다.

---

[최종 수정안: 규칙이 아닌 '측정 계약'으로의 전환]

1. [필수 사람 게이트] 단 하나의 예외적 비가역 영역 지정

• 대상: 데이터베이스 마이그레이션, 데이터 삭제/백필, 정산 확정 로직, 보안 비밀키/크리덴셜 변경.
• 근거: 이 영역들은 오류 발생 시 복구 비용에 상한이 없는 '비가역적 상태 변경' 영역입니다. 여기서는 데이터 기반의 기대값 계산이 성립하지 않으므로, 유일하게 측정 없이도 즉시 사람 리뷰를 강제합니다.

2. [나머지 영역] 4주간의 '섀도 분류(Shadow Classification)'와 데이터 수집

• 실행: 임의의 임계값(예: SmartBear의 400 LOC, 또는 200 LOC)을 규칙으로 박지 않습니다. 대신 4주 동안 라우팅을 바꾸지 않고 모든 PR에 분담표 라벨(자동 머지 대상 vs 사람 리뷰 대상)만 붙여 굴립니다.
• 측정 지표:
• 우리 팀 코드베이스에서 각 라벨별 실제 자동 머지 후보 비율.
• 기존 사람 리뷰 코멘트 중 실제 결함을 차단한 비율(결함 검출률).
• 결과: 4주 뒤 누적된 우리 팀만의 실측치 데이터를 기준으로 삼아 게이트 임계값을 최종 확정합니다.

3. 안전성 실측을 위한 '결함 주입(Mutation Testing) 파이프라인' 도입

• 근거: 인시던트는 희귀 사건이므로 사고가 터질 때까지 게이트의 안전성을 검증할 수 없습니다.
• 실행: 자동화 검증 경로에 인위적인 시드 결함(Seed Defect)을 주입하여, 이 결함이 자동화 툴과 AI 리뷰를 뚫고 나가는지(오분류율) 상시 측정합니다. 이 검출률이 우리 팀이 허용하는 마지노선(예: 결함 통과율 5% 미만)을 유지할 때만 자동 머지 경로를 유지합니다.

4. 지표(Metrics)의 재정의

• 리드타임: PR 개별 단위가 아닌 기능(Change-set) 단위로 측정하여, PR 쪼개기로 인한 인지적 병목과 컨텍스트 스위칭 비용이 가려지는 것을 막습니다.
• 변경실패율(CFR): AI 도입으로 머지 PR 수가 급증(DX 텔레메트리 기준 +98%)하면 분모가 커져 실패율이 장부상으로만 개선됩니다. 반드시 월 절대 사고 건수를 병기하여 평가합니다.
• 감지 시간(MTTD): 롤백이 5분 안에 가능하더라도 감지에 며칠이 걸리면 무의미하므로, 롤백 가능 여부의 기준에 '장애 자동 감지 및 즉시 경보 시스템'의 유무를 포함합니다.

---

[질문에 대한 단정적 답변]

1. 사람 리뷰 필수 경계: 오직 실패 비용의 상한이 없는 비가역적 상태 변경(마이그레이션·보안·정산)으로만 한정합니다.
2. 자동 통과 범위: 비가역 영역을 제외한 모든 변경은 4주간의 섀도 분류 데이터 및 결함 주입 검출률이 기준치를 만족하는 경로에 한해 자동 통과시킵니다.
3. 사람 리뷰의 역할: 스타일·버그 탐지는 전적으로 자동화에 위임하고, 사람은 오직 설계 의도의 부합성 및 다중 PR 간의 컨텍스트 정합성만 검증합니다.
4. 실제 병목 해결 여부: 데이터 측정 계약(섀도 분류) 없이 도입된 분담표는 병목을 줄이지 못하거나(안전 불감증으로 인한 대형 사고 발생), 면피성 병목으로 회귀했습니다. 실측 파이프라인을 구축해야만 품질 저하 없는 병목 제어가 가능합니다.

1. 자아비판 및 논리적 유연성 수용: 고정 파라미터의 함정 탈출

이전 초안에서 본 리스크 렌즈는 외부 관찰치(SmartBear의 400 LOC, Veracode의 45% 결함률, GitClear 분석 등)를 우리 팀의 통제 임계값으로 직결시키는 오류를 범했습니다. 검증되지 않은 외부 상수를 하드코딩하는 것은 안전공학이 아니라 추측에 기반한 도박입니다.

상대의 타당한 지적을 수용하여, 가이드라인의 수립 방식을 '정적 분류 규칙'에서 '결정이론적 비가역성 게이트 + 4주 섀도 측정 계약'으로 전환합니다.

---

2. 리스크 렌즈 최종 가이드라인 (최종 수정안)

[원칙 1] 불가역적 1-Way Door: 측정 없는 무조건 사람 게이트

틀렸을 때 손실 상한이 없는 영역은 기대값 계산이 불가능하므로 실증 데이터 없이도 사람 최소 1인 승인을 강제합니다.

• 대상: DB 스키마 마이그레이션(DDL/DML), 데이터 삭제/백필, 인증/인가(Auth/RBAC) 우회 가능 경로, 결제/정산 산식, PII/암호화 키, 소유권 경계(CODEOWNERS).
• 근거: 시스템 파멸 사태([Knight Capital SEC Report])가 입증하듯, 데이터 파괴와 권한 붕괴는 앱 코드 롤백만으로 복구되지 않습니다('롤백 착각').

[원칙 2] 가역적 2-Way Door: 4주 섀도 검증 및 결함 주입 기반 동적 게이트

가역적 PR의 자동 머지 임계값(LOC, 파일 수 등)은 남의 숫자가 아닌 우리 팀의 4주 실측 데이터로 결정합니다.

1. 4주 섀도 분류 (Shadow Routing): PR 라우팅을 바꾸지 않고 분담표 라벨만 부착하여, 사람 리뷰의 실제 결함 검출률과 저위험 PR 비율의 베이스라인을 측정합니다.
2. 시드 결함 주입 (Mutation Testing): 자동 머지 파이프라인에 인공 결함을 주입하여 AI 및 자동화 CI의 결함 유출률을 사고 없이 통계적으로 상시 모니터링합니다.

[원칙 3] AI vs 사람 리뷰 역할 분담표

---

3. 사람 리뷰어가 검증할 3대 리스크 층위

사람은 더 이상 오타나 린트, 스타일을 보지 않습니다. 오직 '시스템 파멸 방지'에 집중합니다.

1. 상태 복구 및 롤백 가능성 (State Restoration): 새벽 3시 장애 발생 시 코드 롤백만으로 데이터 오염 없이 정상화되는가?
2. 도메인 불변식 및 권한 경계 (Invariants & Auth Matrix): IDOR 등 테넌트 간 데이터 격리 파괴나 결제 멱등성 산식 붕괴가 없는가?
3. 조용한 손상 및 관찰가능성 (Silent Failures & Observability): 예외 삼킴으로 장애 감지 시간(MTTD)이 지연되지 않는가?

---

4. 측정 지표 재정의 및 최후 안전장치

• 지표 착시 제거:
• 리드타임: PR 단위가 아닌 기능 단위(Change-set)로 측정하여 PR 쪼개기로 인한 장부상 착시 방지.
• 변경실패율(CFR): AI 도입 후 PR 증가(DX Telemetry: PR +98%)로 비율이 착시를 일으키지 않도록 월 절대 인시던트 건수 병기.
• 시스템 최후 안전장치:
• 자동 캐너리(Canary) & SLO 기반 롤백: 1~5% 캐너리 노출 중 SLO 이탈 시 자동 롤백 적용.
• 사후 감사 샘플링 (Post-Merge Audit): AI 머지 PR 중 5~10%를 사후 랜덤 검수하여 미세 결함 누출 모니터링.

최종 수정안 — 비가역 게이트 + 측정 계약 분담표

약점 공략의 핵심 공격은 타당하다. 「사람에게 보내면 결함이 잡힌다」는 측정되지 않은 전제이며, 남의 코드베이스 관찰값(SmartBear 400 LOC, Veracode 생성 코드 결함 보유율 등)을 게이트 상수로 박는 것은 지표 정의를 바꿔치기한 도박이다.
그 공격을 흡수한다. 다만 「분담표를 만들지 말라」까지는 거절한다. 전 PR 사람 1회는 이미 실패 중이고, 측정 없는 전량 사람 게이트도 측정 없는 자동 머지와 같은 종류의 도박이다.
남는 구조는 하나다: 손실 상한이 없는 축만 측정 유예로 사람 고정, 나머지는 분류 가설로 두고 4주 실측으로 임계값을 채운다.

---

0. 결정 원칙 (한 줄)

라인 수·AI 통과 여부는 게이트가 아니다. 큰 PR은 사람 필수 트리거가 아니라 분할 반려 대상이다.

---

1. 사람 리뷰 필수 — 두 층

1-A. 측정 없이도 사람 필수 (결정이론, 실증 유예)

하나라도 해당하면 AI 통과만으로 머지 금지.

최악 경로 (AI만 통과 시):
마이그레이션 부분 적용·잠금 → 앱 롤백 후에도 데이터 영구 손상 · 인가 IDOR/테넌트 붕괴 → 조용한 유출 · 결제 멱등 누락 → 이중 과금·장부 불일치(코드 revert로 정산 복구 불가) · 키/공급망 → 배포 롤백으로 끝나지 않음.

근거 축: SRE one-way door, 스키마 「롤백 환상」, 업계 보안 가이드의 auth·암호화·결제 경로 사람 검토, Knight Capital식 검증 누락 사고 유형.
틀렸을 때 손실 상한이 없는 구간에서는 기대값 계산이 성립하지 않는다. 여기는 데이터가 아니라 결정이론이다. 약점 공략 §1 결론을 그대로 채택한다.

1-B. 사람 필수 가설 (4주 섀도 후 임계값 확정)

200 / 400 LOC는 규칙 문서의 상수로 박지 않는다. 남의 관찰값(SmartBear 등)은 가설 출처일 뿐이다. 초기 운영 힌트로만 쓰고(예: 관심사 단일·초과 시 분할 검토), 임계값은 섀도 기간 후 우리 팀 대기시간·결함 코멘트 밀도·분할 후 기능 리드타임으로 다시 쓴다.

---

2. AI + 자동화 머지 허용 — AND 전부 (가설 → 실측 확정)

분담표 왼쪽을 「영역 목록」만으로 두면 구멍이 난다. 오른쪽은 자동 판정 가능한 AND로 고정한다.

④ 없으면 AI 전용 경로를 열지 않는다. 「되돌리기 쉬움」은 MTTD가 짧다는 전제 없이 성립하지 않는다(역결 흡수).

전형 허용 후보: 문서/주석, 순수 UI 카피·스타일(보안 경계 미접촉), 기존 순수 함수 테스트 추가, 동작 동일 내부 리팩터, 타이포·로깅, 비보안 플래그(프로드 기본 노출 없음), 패치 의존성(신규·메이저는 1-A).

비율 목표(70–80% 등)를 정책 숫자로 쓰지 않는다. 4주 섀도에서 나온 실측 후보 비율이 결과치다(롤백왕 흡수·수정).

---

3. 역할 분담표 (운영용) + 측정 계약

도입 절차 (약점 공략 채택 — 필수)

1. 라우팅을 바꾸지 말고 4주 섀도 분류

모든 PR에 분담표 라벨만 부착. 실제 머지 정책은 현행 유지. 2. 4주 뒤 산출물

• 자동 머지 후보 비율 실측
• 사람 리뷰 코멘트의 결함 검출률 (고위험 라벨 vs 저위험 라벨 분리)
• FP(사람 보냈으나 결함 0)·FN 후보(저위험 라벨인데 사람/프로드에서 잡힌 결함)
• 결함 주입 파이프라인 (사고 대기 설계 폐기)

자동 머지 경로에 뮤테이션/시드 결함 상시 주입 → 원할 때 검출률 측정. 이게 준비되기 전 자동 머지 확대는 하지 않는다. 좁은 문서·테스트 전용 경로만 예외 검토. 4.

지표 재정의

• 리드타임: PR이 아니라 기능/change-set
• 변경실패율: 비율 + 월 절대 인시던트 건수 병기 (PR 폭증 시 장부상 개선 방지)
• MTTD 미측정 배포 단위 → 자동 머지 대상 제외
• 추적: 리뷰 대기·첫 응답, 롤백률, MTTD/MTTR, 고위험 PR 비율, 주입 결함 통과율
• 「사람 리뷰 비율」은 성공 지표가 아니다.

오늘 문서에 박을 수 있는 문장:
「비가역·권한·돈·비밀·공용 계약·키/신규 공급망은 사람이 본다. 나머지 경계와 자동 머지 허용 범위는 4주 섀도 + 결함 주입 데이터가 정한다.」

---

4. 사람이 볼 층위

주의: AI 리뷰 실측 탐지율은 마케팅보다 낮다. 「사람은 설계만」으로 좁히면 로직·보안·교차 경합이 공백이 된다.
고위험 = 사람 + 자동화. AI 단독 아님. 생성 AI ↔ 리뷰 AI 자기확증을 전제로 두지 않는다.

---

5. 병목 진단 (최종)

병목의 본체는 「사람 1회 부재」가 아니라 검증 용량을 초과한 AI 산출 물량 + 큰 배치다.
해법 순서:

1. 1-A 고위험 사람 고정
2. 작은 배치·관심사 단일(분할 반려) — 임계값은 실측으로
3. 의도 한 줄(스펙)로 인지 부하 감소
4. 저위험은 섀도 → 주입 검출률 통과 후에만 AI 경로 개방
5. AI 경로에 카나리·SLO 자동 롤백 필수

사람 줄이기만 하면 검증 게이트 제거다. 대기만 줄고 절대 인시던트·주입 통과율이 오르면 정책 실패로 즉시 롤백.

---

6. 다른 초안 판정 (수정 후)

지표 정의를 change-set·절대 건수로 강화 |
| 소크라테스 | 생산량·최소 설계 단위 통제 | 분담표 전면 부정 기각 — 면피 방지는 측정 의무로 해결 |
| 롤백왕 | one-way door, 카나리·SLO | 70–80%는 목표 금지, 결과치만 |
| 역결 | 물량 병목, AI 한계, MTTD, 자기확증 | 「표 자체를 만들지 말라」는 과도 — 엄격 조건+측정이 답 |
| 내 초안 | 비가역 1차 경계, 역할 층위 | 측정·주입·섀도 없이 저위험 경로를 「허용」으로 단정한 부분을 철회·계약화 |

---

7. 최종 단정

• 사람 리뷰 필수 경계: 비가역 상태 변경·권한·돈·비밀·공용 계약·IaC 권한 확대·신규 공급망. 여기만은 측정 유예가 허용된다.
• AI+자동화 허용: 가역·국소·테스트·카나리 자동 롤백·민감 경로 제외 AND + 주입 결함 검출률 실측 통과 후에만.
• 사람이 볼 것: 의도·불변식·조용한 손상·가역성·부채·승인 책임. 스타일 아님. 고위험 경계 조건은 AI에 위임하지 않음.
• 병목: 사람 감축이 아니라 작은 배치 + 고위험 집중 + 저위험의 관측 가능한 가역성 + 분류기 FN/FP·주입 검출률 계약.
• 고위험을 AI 통과만으로 열면 죽이는 것은 속도가 아니라 복구 불가능성이다.
• 저위험을 측정 없이 열면 죽이는 것은 면피 문서화된 침묵 유출이다.

질문 4번에 대한 답: 이 자료 안에서는 분담표 도입 전후 비교 데이터가 없다. 따라서 「사고 없이 병목이 줄었다」를 주장하지 않는다. 운영 답은 4주 섀도 + 결함 주입 후에만 저위험 자동 머지를 확대하는 것이다.

반대·맹점 렌즈 — 최종 수정안

---

입장 조정: 어디를 양보하고 어디를 굳히는가

양보 1: "측정 완료 전까지 아무것도 바꾸지 마라"는 내 초안의 실질적 약점이다.

질문자의 현실은 지금 병목이 있고, 팀이 고통받고 있다는 것이다. "4주 섀도 뒤에 결정하라"는 내 처방은 정확하지만, 4주 동안 병목은 그대로다. 그 사이 리뷰어는 계속 rubber-stamping하고, 배포 속도는 계속 떨어진다. 데밍과 머지장이 공유하는 "현실의 고통에 대해 즉시 가용한 프레임을 제공해야 한다"는 판단이 운영 차원에서 옳다. 나는 "측정이 선행해야 한다"를 "측정이 병행되어야 한다"로 수정한다. 즉, 잠정 분담표를 즉시 도입하되, 그것이 잠정임을 명시하고, 측정 결과로 4주마다 임계값을 재보정하는 의무를 붙인다.

양보 2: 닥터 게이트의 비가역성 서열은 측정 유예가 정당한 유일한 축이다.

이건 이전 라운드에서 이미 수긍했고 철회하지 않는다. 비가역적 상태 변경(스키마 파괴, 키/비밀 노출, 정산 확정, 삭제)은 기대값 계산이 불가능한 구간이므로 검출률 데이터 없이도 사람 게이트를 거는 것이 결정이론적으로 정당하다.

굳히는 지점: "자동 머지 안전" 경로의 검증 부재는 여전히 이 방의 최대 맹점이다.

약점 공략에서 제기한 세 가지 — (1) 사람 게이트 검출률 미측정, (2) 남의 숫자를 임계값으로 전용, (3) 오분류율 측정 설계 부재 — 에 대해 어떤 참가자도 정면 반박하지 않았다. 이건 반박이 없어서가 아니라 반박할 수 없기 때문이다. 우리 팀 데이터 없이 설정한 임계값은, 작동하더라도 왜 작동하는지 모르고, 실패해도 어디서 실패했는지 모른다.

---

최종 수정안: 잠정 분담표 + 측정 계약

제1층: 무조건 사람 게이트 (잠정이 아님 — 영구)

핵심 추가 조건: 사람이 보는 층위를 명시한다 — 스타일·린트가 아니라 (a) 요구사항 부합, (b) 비가역 부작용 존재 여부, (c) 추상화 경계의 타당성. 다만 이 층위 전환은 AI PR에 의도 문서(what과 why)가 동반될 때만 실행 가능하다. 의도 문서 없이 "설계를 보라"고 하면 리뷰어는 코드를 역추적해 의도를 재구성해야 하고, 그건 리뷰가 아니라 리버스 엔지니어링이다.

제2층: 잠정 경량 리뷰 (4주마다 재보정)

400 LOC는 SmartBear 관찰값(사람이 쓴 코드 기반)이므로 잠정 상수다. 4주 섀도 결과로 우리 팀의 결함 밀도 곡선 변곡점이 다르면 재설정한다. 데밍이 강조한 PR 크기 상한 강제와 동일한 정신이되, 숫자를 확정하지 않는다.

제3층: 측정 계약 (이것이 분담표의 작동 조건)

이것 없이 제2층을 운영하면 "가이드라인이 있다"는 착각만 남는다.

재보정 규칙:

• 결함 주입 통과율이 연속 2주 상승 → 해당 구간 제1층 승격
• 사람 리뷰 검출률이 제1층·제2층 간 유의차 없음 → 제1층 대상 축소 검토
• 기능 단위 리드타임 악화 → PR 분할 상한 재조정

제0층: 분담표 이전에 강제할 것 (데밍·소크라테스 합치)

1. PR 크기 상한 강제. 400 LOC 초과 PR은 분담표 분류 이전에 분할 반려. AI가 생성하는 PR 물량 자체가 병목이라는 진단(DX 텔레메트리: 리뷰 시간 +91%, PR 크기 +154%)에 대해 이 방의 모든 참가자가 동의했다.
2. AI PR 의도 문서 필수. "무엇을 왜 바꾸는가"를 PR 본문에 기계가 아니라 요청자가 쓴다. 이게 없으면 제2층 자격 박탈.
3. 카나리/자동 롤백 인프라. 제2층의 "머지 후 리뷰" 경로는 MTTD 기반 자동 감지가 전제 조건. 미구축 시 해당 서비스의 모든 PR은 제1층.

---

다른 참가자에 대한 최종 평가

데밍 — 가장 균형 잡힌 초안. PR 물량 진단, 크기 상한, 카나리 전제 조건까지 운영 가능성이 가장 높다. 다만 임계값을 확정 수치로 제시한 부분(400 LOC, 5분 롤백)은 여전히 남의 데이터다. 측정 재보정 의무를 명시했다면 완전했을 것이나, 참가자 중 가장 가깝다.

소크라테스 — "분담표 자체가 답이 아니다"라는 근본 질문은 이 방에서 유일하게 구조적이었다. 그러나 대안("설계적 최소 단위 PR")의 강제 메커니즘이 없어 운영 답이 되지 못한다. 질문의 질은 최고, 답의 실행 가능성은 최저.

닥터 게이트 — 비가역성 서열이라는 단일 기여가 이 방의 합의 골격을 만들었다. 그러나 가역성 판정의 MTTD 바인딩 부재는 내가 지적한 대로 남아있다.

역결 — MTTD 미측정 시 MTTR 무의미라는 지적은 정확했고, 지표 정의 문제를 가장 선명하게 제기했다. 다만 측정 체계 자체의 설계까지는 나아가지 못했다.

롤백왕 — Knight Capital 사례 인용이 "되돌리기 환상"을 깨는 데 효과적이었으나, 정작 자신의 분담표는 "되돌리기 용이성"을 제1축으로 썼다는 자기모순이 있다.

머지장 — Google 리뷰 가이드 인용으로 "완벽함 vs 진전" 균형을 제시한 건 유용했으나, 가장 관행적인 답에 가까웠다. rubber-stamping 지적은 날카로웠으나 대안이 층위 전환 권고에 그쳤다.

---

한 문장 최종 결론

비가역 변경은 무조건 사람이 본다. 나머지는 잠정 분담표로 즉시 병목을 완화하되, 4주마다 결함 주입 통과율과 검출률 실측치로 임계값을 재보정하는 측정 계약을 분담표의 작동 조건으로 묶어라 — 측정 없는 분담표는 게이트를 줄인 것이지 최적화한 것이 아니다.