설계도는 깔끔했다. 운용은 별개의 문제였다

3개월 전, 저는 의기양양했습니다.

코드 리뷰를 6단계로 나누어, AI와 인간의 분업을 설계했기 때문입니다. 그 설계도는 '코드 리뷰를 6단계로 나누면 AI와 인간의 분업이 보인다'로 정리했습니다. 덕분에 많은 분이 읽어주셨습니다.

하지만, 자신의 팀에서 3개월간 운영해 보고 저는 얼굴이 창백해졌습니다.

6단계 중 인간이 진지하게 보고 있었던 것은 단 1단계뿐이었습니다. 나머지 5단계는 어느샌가 AI에게 통째로 맡기고 있었습니다. 설계도에서는 6단계 모두에 역할을 부여했는데, 현실의 저는 대부분의 단계를 그냥 지나치고 있었습니다.

이를 깨달은 것은 제가 작성한 리뷰 코멘트를 월말에 다시 살펴보았을 때였습니다. 단계 4~5에 남은 저의 코멘트는 거의 「좋아요」 리액션뿐이었습니다. 문장으로 고민한 흔적이 단계 6에만 남아 있었던 것입니다.

설계한 것은 저입니다. 그 설계를 가장 게을리한 것도 저였습니다. 독자들에게는 「6단계로 분업합시다」라고 권하면서, 정작 자신은 5단계를 지나치고 있었습니다. 죄책감이 한동안 가시지 않았습니다.

이것은 저의 태만함에 대한 고백입니다. 동시에, 아마 당신의 팀에서도 일어나고 있는 일에 대한 기록이기도 합니다. 그리고 결론부터 말씀드리자면, 이 '그냥 지나침'은 절반은 옳고, 절반은 위험했습니다. 그 선을 어디에 긋느냐가 이 기사의 본론입니다.

우선, 6단계를 빠르게 복습하겠습니다

책으로 낸 3층 모델을, 운용에서는 6개의 단계로 나누었습니다. 3층을 실제 파이프라인에 적용하면 다음과 같습니다.

정형 게이트 (Formatting Gate): 포맷·import 순서. hook과 CI가 기계적으로 걸러냄 -
정적 게이트 (Static Gate): 타입 에러·lint 위반. 이 또한 CI가 걸러냄 -
테스트 게이트 (Test Gate): 유닛 테스트·커버리지 임계값 -
AI 기계 리뷰 (AI Machine Review): CodeRabbit이 N+1이나 미사용 변수를 지적 -
AI 의미 리뷰 (AI Semantic Review): Claude가 명명(Naming)·보안·설계의 낌새를 지적 -
인간 리뷰 (Human Review): 설계 판단·비즈니스 로직·방향성 편집

단계 13은 기계, 45는 AI, 6은 인간. 책의 Layer 1/2/3을 운용의 해상도까지 나눈 것뿐입니다. 설계로서는 지금도 옳다고 생각합니다.

문제는, 올바른 설계를 3개월간 운영하면 무엇이 일어나는가였습니다.

5단계가 「실질적 AI 통째로 맡기기」가 되었다

솔직하게 쓰겠습니다.

첫 2주 동안은 6단계 모두를 정성스럽게 살펴보았습니다. AI의 지적을 하나씩 검토하고, 기각할 것은 기각하고, 채택할 것은 채택했습니다. 기각의 판단 기준은 'AI의 지적을 기각하는 기술'에 쓴 대로입니다.

3주 차부터 저는 변했습니다.

단계 1~3의 CI 게이트는 원래 보는 것이 아닙니다. 초록색이면 통과, 빨간색이면 개발자가 수정합니다. 여기에 인간의 역할은 제로입니다. 설계대로이므로 문제없습니다.

무너진 것은 단계 4~5였습니다.

AI의 지적이 안정적이고 정확하다는 것을 깨닫자, 저는 그것을 「읽지 않고 신뢰하게」 되었습니다. CodeRabbit이 「여기는 N+1입니다」라고 하면, 확인하지 않고 「수정해 주세요」라고 코멘트를 남깁니다. Claude가 「이 명명은 오해를 불러일으킬 수 있습니다」라고 하면, 스스로 생각하기 전에 동의합니다.

3개월 후, 저의 단계 4~5에서의 소요 시간은 거의 제로가 되어 있었습니다. AI의 지적에 이모지로 리액션을 누르는 작업으로 변해 있었던 것입니다.

월별로 되돌아보면 타락의 속도가 잘 보입니다.

1개월 차, 저는 단계 4~5의 AI 지적을 평균 7할 정도 스스로 재확인했습니다. 2개월 차, 그것이 3할로 떨어졌습니다. 3개월 차, 거의 제로입니다. AI가 배신하지 않는 기간이 계속될수록 저의 확인은 옅어집니다. 신뢰는 확인을 게을리하는 핑계로 조용히 변해갔습니다.

한 가지 구체적인 예를 들겠습니다. 어떤 인증 관련 PR에서 CodeRabbit이 「여기는 토큰의 유효 기간 체크가 빠져 있습니다」라고 지적했습니다. 3개월 차의 저는 코드를 열지 않고 「수정해 주세요」라고 답했습니다. 지적은 옳았습니다. 하지만 저는 그것이 옳다는 것을 스스로 확인하지 않았습니다. 맞았으니까 다행이라는 것뿐인 이야기입니다.

데이터도 「인간은 읽지 않게 된다」고 말하고 있다

이것은 저만의 타락이 아닌 듯합니다.

Sonar의 State of Code Developer Survey 2026에 따르면, 개발자의 96%가 「AI 생성 코드가 기능적으로 옳다고 완전히 신뢰하지 않는다」고 답했습니다. 반면, 95%가 「리뷰에 어떠한 노력을 기울이고 있다」고도 답했습니다.

모순되는 것 같지만, 그렇지 않습니다.

사람들은 「완전히 신뢰하지는 않는다」고 말하면서도, 현장에서는 신뢰하고 있습니다. Stack Overflow의 AI 트러스트 갭 (AI Trust Gap) 기사 역시, 개발자들이 AI를 「판단의 대체가 아닌 보조」라고 겉으로는 말하면서도, 실무에서는 보조를 판단의 근거로 삼고 있는 구도를 그리고 있습니다.

제가 단계 4~5에서 타락한 것은 업계의 평균치였던 셈입니다. 조금 안심이 되면서도, 한편으로는 조금 무서워졌습니다.

그럼, 형해화된 단계는 무의미했던 것인가

여기서 역설이 발생합니다.

형해화되었다고 해서 단계 4~5가 무의미했던 것은 아닙니다. 오히려 그 반대였습니다.

AI의 지적 정확도가 제가 확인 작업을 게을리할 수 있을 정도로 높았다는 뜻입니다. CodeRabbit의 오탐율(False Positive Rate)은 Graphite의 조사 결과 2.3%로 보고되었습니다. 일반적인 AI 리뷰 도구에서도 오탐은 5~15% 수준에 머뭅니다. 100건의 지적 중 틀린 것은 몇 건뿐입니다.

몇 건의 오류를 위해 제가 95건을 재확인한다.

그것은 분업이 아닙니다. AI의 숙제를 채점하는 작업입니다. 제가 단계 4~5를 「읽지 않게 된」 것은 타락인 동시에, 올바른 최적화이기도 했습니다. 기계가 9할의 정확한 일을 하는데, 인간이 두 번 다시 훑어보는 것은 의미가 희박합니다.

다만, 몇 건의 오탐을 방치해도 된다는 뜻은 아닙니다. 이 내용은 나중에 다시 다루겠습니다.

운영 측면에서 효과를 본 또 다른 점은 단계 4와 5를 서로 다른 AI로 분리한 것이었습니다.

단계 4의 CodeRabbit과 단계 5의 Claude는 특기가 다릅니다. 전자는 정적 분석 (Static Analysis)에 가까워 N+1 문제나 미사용 변수를 찾아내는 데 강합니다. 후자는 긴 코드의 문맥이나 설계의 뉘앙스를 파악하는 데 강합니다. 본문의 AI 리뷰 추가 장에서 썼듯이, 두 개의 필터를 겹치면 지적이 가끔 중복됩니다.

冗長해 보일 수 있습니다. 하지만 항공 업계의 더블 체크 (Double Check)와 마찬가지로, 이중 필터를 통과한 문제는 정말로 인간이 봐야 할 것들만 남게 됩니다. 단계를 분리함으로써 제 단계 6에 도달하는 노이즈가 확실히 줄어들었습니다.

6段階レビューの勾配テーブル。AI比率と人間関与度が段階を追って反転する

이 경사 테이블 (Gradient Table)이 3개월간의 운영을 통해 제가 목격한 풍경입니다.

단계를 내려갈수록 AI 비중은 낮아지고 인간의 관여도는 높아집니다. 보기에는 아름다운 그라데이션처럼 보입니다. 하지만 실제로 운영해 보니, 단계 4~5의 「인간 관여도·중」은 3개월 만에 「거의 제로」로 가라앉았습니다. 설계상의 중간값은 실제 운영에서는 유지되지 않았던 것입니다.

인간이 정말로 필요했던 것은 단계 6뿐이었다

3개월 치의 PR을 되돌아보며, 제가 내린 「AI는 할 수 없었던 판단」을 세어보았습니다.

모두 단계 6에 집중되어 있었습니다.

• 이 기능, 애초에 이 계층(Layer)에 두는 것이 맞는가 (설계 판단)
• 이 조건 분기, 사양(Specification)의 의도와 일치하는가 (비즈니스 로직)
• 이 패턴, 앞으로 코드베이스에서 늘려야 하는가 줄여야 하는가 (방향성 편집)

AI는 「이 코드가 무엇을 하는지」는 정확하게 읽어냅니다. 하지만 「이 코드가 왜, 여기에, 이런 형태로 있어야 하는가」는 읽지 못합니다.

Addy Osmani의 Code Review in the Age of AI 역시 같은 선을 긋고 있습니다. 추상화가 요구사항의 변화를 견딜 수 있는지, 에러 처리가 현실의 실패 모드 (Failure Mode)를 포괄하고 있는지와 같은 것들은 현행 모델이 갖지 못한 판단이라는 것입니다.

저의 3개월간의 로그는 이 주장에 대한 실측 데이터가 되었습니다. 단계 6에서만 저는 정말로 고민하고 있었습니다.

업계의 수치도 같은 방향을 가리키고 있습니다. AI는 로직의 오류가 인간보다 75% 더 많다는 보고도 있으며, 초안(Draft)은 빠르지만 판단은 위태롭습니다. 빠르게 쓰는 능력과 올바르게 판단하는 능력은 별개입니다. 전자는 AI에게 치우치고, 후자는 인간에게 남습니다. 3개월간의 로그는 그 분수령을 단계 6에 그었습니다.

단계를 늘릴수록 인간의 업무는 한 점에 집중되었다

여기서 가장 큰 발견입니다.

6단계로 늘린 것이 인간의 차례를 줄인 것이 아닙니다. 단계를 늘렸기에 인간의 차례를 한 점으로 압축할 수 있었던 것입니다.

만약 단계를 나누지 않았다면, 저는 하나의 PR에서 「포맷·타입·테스트·N+1·네이밍·설계」를 동시에 보고 있었을 것입니다. 뇌의 리소스는 사소한 지적들에 잡아먹힙니다. 설계 판단에 도달하기도 전에 지쳐버립니다.

6단계로 나눈 덕분에 단계 1~5가 사소한 것들을 흡수해 주었습니다. 제 앞에 도달하는 PR은 기계적인 문제들이 전부 걷어내진 상태입니다. 그렇기에 저는 단계 6의 판단에만 온전히 집중할 수 있습니다.

단계를 늘릴수록 인간의 일은 줄어들고, 깊어집니다. 이것이 3개월 만에 얻은 가장 큰 수확이었습니다.

이는 인지 부하 (Cognitive Load)의 문제이기도 합니다.

Sonar의 조사에 따르면, 개발자의 95%가 리뷰에 노력을 기울이고 있지만, 그 노력이 「절약했을 것이라 믿었던 시간」을 갉아먹고 있다는 구도가 나타났습니다. AI로 빠르게 쓰고 리뷰에서 느려지는 것. 결과적으로 편해지지 않은 것입니다.

왜일까요. 리뷰하는 인간이 사소한 것과 중요한 것을 같은 뇌로 보고 있기 때문입니다. 하나의 PR (Pull Request)에서 타입 에러 (Type Error)도 설계 판단도 동시에 요구받으면, 뇌는 눈앞의 사소한 것부터 처리합니다. 설계에 도달하기도 전에 주의력이 소진됩니다.

6단계는 이러한 소모를 구조적으로 방지합니다. 사소한 것들은 단계 1~5에서 기계와 AI가 흡수합니다. 인간의 뇌가 가동되는 것은 단계 6뿐입니다. 똑같은 1시간이라도, 사소한 것에 깎이지 않는 1시간은 판단의 질이 전혀 다릅니다. 빨라진 것이 아니라, 깊어진 것입니다. 이것이 분업의 진정한 보상이었습니다.

「필요한 단계」와 「의식적인 단계」를 구분하기

3개월 동안, 저는 단계에 두 가지 종류가 있다는 것을 깨달았습니다.

필요한 단계는 거치지 않으면 품질이 떨어지는 단계입니다. 단계 1~5가 이에 해당합니다. 인간이 보지 않아도 기계와 AI가 묵묵히 품질을 지켜줍니다. 형식화(形骸化)되어 있더라도 기능은 하고 있습니다.

의식적인 단계는 거쳐도 아무것도 변하지 않는 단계입니다. 제 팀에는 처음에 이것이 하나 있었습니다. "리뷰 요청을 보내기 전에 Slack으로 미리 말하기"라는, 인간 사이의 확인 단계입니다.

3개월 만에 이 의식은 사라졌습니다.

아무도 곤란해하지 않았기 때문입니다. 단계 1~5가 품질을 담보하고 있는 이상, 인간의 사전 메시지에는 의미가 없습니다. 형태만 남아 있던 단계는 운영 과정에서 자연스럽게 깎여 나갔습니다. 설계도에 적은 단계 중 기능하는 단계는 남고, 의식은 사라집니다. 운영이란, 바로 이러한 선별 과정이었을지도 모릅니다.

형식화를 「방치」와 「최적화」로 분류하기

단, 형식화에는 두 종류가 있습니다.

좋은 형식화는 AI가 안정적으로 올바르기 때문에 인간이 손을 떼는 케이스입니다. 단계 4~5의 대부분이 이것이었습니다. 손을 떼도 좋습니다.

나쁜 형식화는 오검출(False Positive) 몇 건을 아무도 잡아내지 않게 되는 케이스입니다. AI 리뷰 도구 조사에 따르면, 알람 피로 (Alert Fatigue)가 발생하면 지적 사항의 40%가 무시된다고 보고되어 있습니다. 좋은 지적도 나쁜 지적도 통째로 넘어가 버립니다.

이 두 가지를 분류하는 메커니즘이 필요합니다.

제가 도입한 것은 월간 집계입니다. '피드백 루프 (Feedback Loop)' 장에 쓴 것처럼, 거절한 AI 지적을 JSONL로 쌓아두고 월말에 다시 검토합니다. 오검출이 편중되어 나타나는 부분을 알 수 있다면, AGENTS.md의 규칙을 수정합니다. 인간이 매번 읽는 대신, 한 달에 한 번 구조적으로 재검토합니다.

어떤 지적이 몇 번 나왔고 얼마나 거절되었는지는, 'GitHub API로 리뷰 메트릭스 (Review Metrics)를 가져오는 방법'에서 쓴 방식으로 계산했습니다. 감각이 아니라 숫자로 형식화의 좋고 나쁨을 판단합니다.

구체적인 기준은 다음과 같습니다. 어떤 단계의 AI 지적에서 거절률이 달이 지날수록 낮아지고 있다면 좋은 형식화입니다. AI가 학습하고 규칙이 성장하고 있다는 증거이므로, 인간은 손을 떼도 좋습니다. 반대로 거절률이 높게 유지되고 있다면 나쁜 형식화입니다. 오검출이 방치되어 결국 좋은 지적까지 무시됩니다. 이 부분만큼은 인간이 다시 고삐를 잡아야 합니다.

이 숫자를 한 달에 한 번 보는 것만으로, 저는 "어디를 게을리해도 괜찮고, 어디를 게을리하면 안 되는지"를 판단할 수 있게 되었습니다. 매번 PR마다 모든 단계를 감시할 필요는 없습니다. 구조를 월 단위로 점검하면 됩니다. 인간의 노동력은 PR 단위에서 월 단위로 옮겨갔습니다. 이것 또한 분업의 진화된 형태였습니다.

설계도와 운영 로그는 별도로 필요했다

3개월을 운영하며, 저는 처음에 느꼈던 불안감을 철회했습니다.

"5단계를 통째로 맡겨버린 것"은 태만이 아니었습니다. 설계가 제대로 작동했다는 증거였습니다. 인간이 단계 6에만 집중할 수 있었던 것은 단계 1~5가 묵묵히 일해주었기 때문입니다. 설계도는 운영 과정에서 형식화되는 것까지 포함하여 옳았습니다.

다만, 설계도만 읽어서는 이 안심에 도달할 수 없습니다. "6단계 모두에 인간이 관여해야 한다"고 오독한 채 계속 자신을 책망했을 것입니다.

설계도는 "어떻게 나눌 것인가"를 가르쳐줍니다. 운영 로그는 "나눈 뒤에 어떤 일이 일어나는가"를 가르쳐줍니다. 둘 다 없으면 현장은 돌아가지 않습니다.

당신의 팀에서도 단계 중 일부는 형식화될 것입니다. 그때 그것이 좋은 형식화인지 나쁜 형식화인지를 숫자로 분류하십시오. 인간의 차례가 1단계로 모였다면, 그것은 패배가 아니라 설계의 승리입니다.

3개월 전의 저는 6단계 모두에 인간이 관여하는 모습이 이상적이라고 생각했습니다. 지금은 그 반대가 이상적이라고 생각합니다. 인간이 관여하는 단계가 적을수록, 그 1단계의 밀도는 높아집니다. 잘 만들어진 시스템은 인간을 일하게 하지 않습니다. 인간만이 할 수 있는 단 한 점만을 인간에게 남깁니다.

리뷰를 6단계로 나누며 제가 마지막으로 얻은 것은, 5단계를 안심하고 놓아줄 수 있는 기술이었습니다. 놓아줄 수 있는 단계가 늘어날수록, 저는 정말로 생각해야 할 단 한 점에 가까워집니다. 시스템화란, 게을리해도 되는 곳을 올바르게 늘려가는 것이었습니다.

Discussion