균등하게 나눈 줄 알았는데, 중간만 타오르고 있었다

나는 코드 리뷰(Code Review)를 6단계로 나누었습니다. Lint, 타입(Type), AI 설계 리뷰, 인간의 설계 판단, 통합 테스트, 릴리스 판정입니다. 책임을 나누면 각 단계가 가벼워질 것이라고 믿었습니다.

90일 후, 실측치를 보고 아연실색했습니다. 지적 사항 전체의 62%가 Stage 3(AI 리뷰) 한 곳에 쌓여 있었던 것입니다.

균등하게 나누면 균등하게 분산될 것이라고 생각했습니다. 실제로는 반대로, 나눔으로써 어디에 편중되어 있는지가 가시화되었을 뿐이었습니다.

게다가 곤란하게도, 나는 3개월 동안 그 편중을 깨닫지 못한 채 "6단계로 깔끔하게 돌아가고 있다"고 느끼고 있었습니다. 감각은 거짓말을 합니다. 숫자를 얻기 전까지는.

숫자로 본 편중

먼저 실측치를 하나의 테이블로 정리합니다. 90일 동안, 리뷰 코멘트 총수 1,247건, 6단계 내역입니다.

Stage 3 に指摘の62%が集中していた6段階レビューの90日集計

내역을 말로 다시 풀어서 설명하겠습니다. Stage 1과 Stage 2(기계적인 체크)는 합계 13%. Stage 4 이후(인간 판단·통합·릴리스)는 합계 25%. 중앙의 Stage 3만으로 62%입니다.

나는 3단계로 나눈 것처럼 운영하고 있었습니다. "기계가 잡는다 / AI가 잡는다 / 인간이 잡는다"의 3개 블록입니다. 숫자를 나열하고 나서야 깨달았지만, 이것은 실질적으로 AI 단일 구성에 가까운 운영이었습니다.

「기계 → AI → 인간」은 이상론이었다

분업 설계의 바탕은 서적으로 먼저 정리한 6층 모델입니다.

• Stage 1: Lint / Format
• Stage 2: 타입 / 빌드 (Build)
• Stage 3: AI 설계 리뷰
• Stage 4: 인간의 설계 판단
• Stage 5: 통합 테스트
• Stage 6: 릴리스 판정

설계 당시의 나는 이렇게 생각했습니다. Stage 1과 2에서 기계적인 문제를 없앤다. Stage 3에서 AI에게 패턴 인식(Pattern Recognition)을 시킨다. Stage 4는 인간이 방향성을 결정한다. Stage 5와 6은 게이트(Gate)다.

듣기에는 깔끔합니다. 실제로는 달랐습니다.

Stage 1과 Stage 2는 입구의 그물이 너무 촘촘해서, 애초에 도달하는 지적 사항이 적습니다. 포맷이나 타입은 commit 전의 hook에서 걸러지기 때문입니다. "사전에 제거된 것은 리뷰 단계에서 지적 사항으로 계산되지 않는다". 단순한 사실이지만, 설계 시에는 간과하고 있었습니다.

반면 Stage 4(인간의 설계 판단)는 반대 방향으로 위축되었습니다. AI가 Stage 3에서 모두 잡아버리면, 인간이 발견하는 신규 지적 사항은 격감하는 것입니다. 인간의 역할은 "AI가 제기한 지적 사항의 채택 여부 판단"으로 치우치게 되었고, 신규 지적 사항의 발안은 한 달에 손에 꼽을 정도였습니다.

결과적으로 중간의 Stage 3에 책임이 쏠립니다. 1,247건 중 772건이 Stage 3. 이것이 하네스(Harness) 운영 90일의 실측입니다.

참고로 덧붙이자면, 이 1,247건은 "AI 도구가 제기한 지적 사항"과 "내가 인간으로서 작성한 코멘트"를 모두 포함합니다. CodeRabbit과 Claude Code의 PR 리뷰 액션, 그리고 나의 수동 코멘트를 PR별로 집계하여 어느 Stage의 지적인지를 사후에 라벨링(Labeling)했습니다. 라벨링 자체는 Claude의 도움을 받았습니다. 사람의 힘만으로는 감당할 수 없는 양이었습니다.

숫자의 생성 과정까지 적는 이유는, 이 기사의 주장이 "Stage 3에 모인 건수 비율"에 의존하고 있기 때문입니다. 지적의 유래가 편향된 방식으로 측정했다면 결론도 왜곡됩니다. 나의 운영에서는 Stage 3 지적의 대부분은 AI 발(發), Stage 4 지적의 대부분은 인간 발(發)이었습니다. 단순한 비율이지만, 집계 시 이곳이 섞이면 의미가 달라집니다.

Stage 3의 정체는 "의도된 저수조"였다

여기서 판단이 두 갈래로 나뉩니다.

첫 번째, Stage 3가 막혀 있으니 분산시키자는 판단. 다른 하나, Stage 3에 모으는 것이 올바른 설계였다고 다시 받아들이는 판단.

나는 후자를 택했습니다. 이유는 다음 세 가지입니다.

첫째, Stage 1과 Stage 2는 자동화율 100%입니다. 인간의 시간을 1초도 쓰지 않습니다. 지적 건수가 적은 이유는 hook이 commit 전에 조용히 대량의 문제를 막고 있기 때문입니다. 숫자로 나타나지 않을 뿐, 나의 시간은 가장 절약되고 있는 단계입니다.

둘째, Stage 4(인간 판단)를 두텁게 만드는 방향은 나의 운영 체력을 망가뜨립니다. Iris(나의 AI 하네스)는 1명 + AI로 운영하고 있습니다. Stage 4에 15% 이상의 지적을 쌓은 달은 나의 가용 시간이 명확하게 줄어들었습니다. 인간의 설계 판단은 "양"이 아니라 "무게"로 운영하고 싶은 계층입니다.

셋째로, Stage 3는 AI 리뷰 계층입니다. AI에게 지적 사항을 모으는 것은, 나의 시간을 소비하지 않고 지적 사항을 쌓을 수 있다는 것을 의미했습니다. 60%의 자동화율로 운영되고 있기 때문에, 실제로 제가 읽는 것은 Stage 3의 지적 사항 772건 중 약 300건입니다.

즉, Stage 3는 '막힌 배수구'가 아니라, 의도적으로 그곳으로 흘려보내는 '저수조'였습니다.

비유하자면, 6단계 리뷰는 6명의 경비원이 각자의 위치를 분담하는 체제가 아닙니다. 5명이 입구와 출구를 봉쇄하고, 가운데 1명(AI)에게만 "수상해 보이는 것은 전부 넘겨라"라고 지시하고 있는 체제입니다. 가운데로 짐이 모이는 것은 당연합니다. 오히려 다른 5명에게 짐을 돌려버리면, 그쪽의 비용이 급격히 상승하게 됩니다.

제 운영 방식에서 가장 비용이 많이 드는 단계는 Stage 4(인간의 설계 판단)입니다. 1건당 평균 25분. Stage 3(AI 리뷰)는 1건당 실질적으로 4분입니다. 같은 100건을 처리한다면, Stage 3가 Stage 4의 6분의 1 수준으로 해결됩니다. 총 소요 시간으로 보면, 6단계 중에서 Stage 3는 "저렴하게 대량으로 처리할 수 있는 단계"였습니다.

그럼에도 「62%」는 너무 많았기에, 내역을 다시 배분하다

그렇다 하더라도 62%는 너무 많습니다. 여기서부터 운영 개선에 들어갑니다.

Stage 3의 772건을 저는 다음 4가지 카테고리로 재분류했습니다.

하고 있는 일은 단순합니다. Stage 3에 모인 지적 사항을 "애초에 원래 어느 단계의 이야기인가"를 기준으로 다시 분류하는 작업입니다.

Naming이나 nil 체크는 정적 분석 (Static Analysis) 규칙으로 구현할 수 있는 문제였습니다. 이것을 Stage 1과 2로 내리면, Stage 3의 부하는 약 41%(509 → 302건)까지 낮아집니다.

반대로 "프로덕트 의도 판단" 108건은 AI에게 채택 여부를 맡겨서는 안 되는 계층이었습니다. 이곳은 Stage 4로 올립니다.

Naming의 218건을 lint로 내린다고 말하기는 쉽지만, 실제로는 ESLint/Ruff의 커스텀 규칙 (custom rule)을 작성해야 합니다. 저의 경우에는 "함수명의 주동사는 영어 동사 하나"라는 느슨한 규칙과, "boolean 변수는 is_／has_／can_으로 시작한다"라는 규칙을 추가했습니다. 이를 통해 Naming 계열의 218건 중 약 160건이 Stage 1에서 자동으로 차단되게 되었습니다.

nil 체크 195건의 경우에는 TypeScript의 strict 옵션을 ON으로 설정하고, 타입 주석 (type annotation)을 인간 측에도 의무화했습니다. 이 또한 설정 변경만으로 이루어졌으며, 실질적으로 새로운 코드를 작성하지는 않았습니다. "AI에게 지적하게 만들었지만, 사실은 타입 시스템 (type system)이 원래부터 잡아낼 수 있었던 문제였다"라는 케이스가 제 예상보다 많았습니다.

「Stage 3에 무엇을 모을지를 처음에 결정하라」

90일을 운영하며 깨달은 점은, 6단계 리뷰를 기능하게 하는 핵심은 중앙의 Stage 3에 무엇을 의도적으로 모을지를 처음에 결정하는 것이라는 점이었습니다.

외부 단계(Lint／타입／통합／릴리스)는 목적이 명확하여 기계적으로 선을 그을 수 있습니다. 인간의 단계(Stage 4)도 시간이 유한하기 때문에 자연스럽게 취사선택됩니다.

가장 설계 판단이 많이 필요한 곳은 AI에게 맡기는 Stage 3입니다. 이곳을 "AI가 찾아낸 지적 사항의 수용처"로 취급하면, 다른 단계의 설계는 자동으로 결정됩니다. 반대로 이곳을 "어쩌다 보니 AI에게 부탁하는 계층"으로 방치하면, 6단계로 나눈 의미가 사라집니다. 저의 90일 전 설계가 바로 그러했습니다.

외부의 움직임도 참고로 언급해 두겠습니다. CodeRabbit은 2026년 업데이트에서 context engine과 code graph analysis를 결합한 3단 파이프라인화를 추진하고 있습니다 (theaiengineer.substack.com, 2026년 보도). Google의 readability 제도 또한 코드 전체가 아니라 "언어별 가독성"만을 인간이 집중해서 보는 단일 단계 특화 메커니즘을 사용하며, 사내 엔지니어의 약 20%가 상시 리뷰 담당자 혹은 리뷰 대상이 되는 운영 방식을 취하고 있습니다. 다단계 리뷰를 설계하는 타사들도 "AI와 인간의 주전장을 1단계로 좁히는" 방향으로 공통된 흐름을 보이고 있다는 인상을 받았습니다.

이것은 실감할 수 있는 큰 지지대였습니다. 저 혼자만의 90일 운영이라면 "어쩌다 편중된 것일지도 모른다"며 망설였을 것입니다. 타사의 설계 사상도 같은 방향을 향하고 있다는 것을 알게 된 시점에서, Stage 3에 모으겠다는 판단은 상당히 안심하고 굳힐 수 있었습니다.

부작용: Stage 4가 "떠올리는 층"에서 "발안하는 층"으로 돌아갔다

또 다른 예상치 못한 부작용이 있었습니다. Stage 3의 내역을 다시 나눈 이후, Stage 4의 성격 자체가 변한 것입니다.

재분류 전의 Stage 4는 실질적으로 "AI가 제기한 지적 사항 중 인간으로서 동의할지 결정하는 층"이었습니다. 저는 리뷰 코멘트 옆에 "Ack", "Skip", "Discuss"와 같은 라벨을 붙이고 있을 뿐, 새로운 문제를 발안하지는 않았습니다.

재분류 후, Stage 3가 "모듈 설계만"으로 좁혀진 결과, Stage 4에 "AI로는 보이지 않는 전제"를 가져올 여지가 생겼습니다. 프로덕트의 의도, 과거 고객 요구사항과의 정합성, 다음 달 출시 예정인 다른 기능과의 충돌. 이런 지적은 AI가 포착할 수 없습니다. 그저 가져올 장소가 없었을 뿐입니다.

수치로 나타내면, Stage 4의 신규 지적 발안율(건수 중 AI와 독립적으로 발생한 것)은 재분류 전후로 12% → 47%로 상승했습니다. 총 건수는 줄어들었지만, 인간이 인간답게 지적하는 비율이 높아졌다는 뜻입니다.

"AI에게 무엇을 맡길 것인가"를 결정하는 것은, 부작용으로서 "인간이 무엇을 할 것인가"를 결정하는 것이기도 하다는 것을 몸소 이해한 순간이었습니다.

90일 후에 내가 바꾼 설정

구체적으로 바꾼 설정을 남겨둡니다.

• AI 리뷰 단계(Stage 3)에 명시적인 "보고 싶지 않은 카테고리"를 추가했다. Naming과 nil 체크는 lint로 내렸으므로, Stage 3에서는 다루지 않는다.
• Stage 4(인간의 설계 판단)의 입력을, Stage 3가 "AI로는 판단할 수 없다"고 명시적으로 라벨링한 지적사항으로만 좁혔다.
• Stage 1과 2의 자동 규칙을, Stage 3에서 내려온 카테고리만큼 늘렸다. lint 규칙으로 19개, 타입 계열로 8개.
• 주 단위로 "Stage 3의 지적 비율"만 모니터링하도록 했다. 60%를 넘으면 Stage 1/2로 내릴 수 있는 지적이 쌓여가고 있다는 신호로 간주한다.

90일 후의 운영 비율은 Stage 3가 41%, Stage 1/2가 26%, Stage 4가 22%, Stage 5/6가 11%가 되었습니다.

균등하게 분산되었다고는 말하지 않겠습니다. Stage 3는 지금도 가장 두터운 단계입니다. 하지만 "막혀 있다"는 느낌은 사라졌고, Stage 4가 의미를 갖는 층으로 돌아왔습니다.

여담이지만, 이 4가지 설정 변경 중 구현에 가장 시간이 걸린 것은 네 번째 항목인 "주간 모니터링"이었습니다. GitHub API에서 PR 코멘트를 가져와 Stage 라벨을 붙이는 집계 스크립트가 필요하여 꼬박 하루가 걸렸습니다. 반대로 말하면, 그 외의 3개 항목은 설정 파일의 수정만 하면 됩니다. Stage 3의 내역 재검토부터 운영 개선까지의 구현 공수는 합계로 영업일 기준 2일 정도였습니다.

만약 다른 분이 모방한다면, 집계 스크립트부터 만들 것을 권합니다. 숫자가 먼저 보이지 않으면 설정 변경의 효과도 측정할 수 없습니다. 저도 90일 전으로 돌아갈 수 있다면, 우선 집계부터 시작하고 싶습니다.

요약

제가 90일간 운영하며 배운 것은 다음 3가지입니다.

• 6단계로 나누어도 지적 사항은 균등하게 분산되지 않습니다. 나누었기 때문에 편중됨이 가시화될 뿐입니다.
• 중앙의 AI 리뷰 단계(Stage 3)에 지적이 모이는 것은 설계로서 옳은 면이 있습니다. 인간의 시간을 소비하지 않고 지적을 쌓을 수 있는 단계이기 때문입니다.
• 다만 비율이 60%를 초과하면 "본래 Stage 1/2로 내릴 수 있어야 할 지적"이 섞여 있다는 신호이므로, 분기마다 Stage 3의 내역을 재검토합니다.
• 재검토는 Stage 3만 보면 됩니다. Stage 3가 움직이면 주변의 Stage 1/2/4의 역할도 자동으로 결정됩니다.

균등 분산을 목표로 하는 설계는 제 운영에서는 역효과였습니다. "어느 단계에 무엇을 의도하여 모을 것인가"를 처음에 결정하는 것이 6단계 리뷰를 기능하게 만듭니다.

관련 연재 기사도 있습니다. 이 글에서 다룬 "AI와 인간의 역할 분담"에 대한 보다 일반론을 알고 싶은 분은 다음 엔트리를 참조해 주세요.

Discussion