AI에게 맡기는 것은 '코더'인가, '리뷰어'인가? 어느 쪽이 먼저인가?

지난번, '사기ダメ.com(사기안돼.com)'을 Claude Code로 만들어 보았다는 글을 썼더니, Gemini와 Grok으로부터 여러 가지 지적을 받았다.

그중에서 가장 반응이 컸던 것이 "AI가 작성한 코드를 리뷰하지 않고 있다, 이것은 부채의 블랙박스화가 아닌가"라는 지적이다.

이 지적 자체는 옳다고 생각하지만, 결론은 다르다.

오늘은 그 이야기를 한 단계 더 메타적인 관점에서 써 보았다.

경영진·AI 도입을 검토하는 사용자는 AI에 이렇게 기대한다.

"AI에게 코드나 문서를 쓰게 하면, 인건비는 거의 제로가 되고 생산성은 폭발적으로 올라가지 않을까?"

그 마음은 이해한다. Claude Code를 만져본 사람이라면 누구나 한 번쯤은 그렇게 생각한다.

하지만 동시에 이렇게도 생각한다.

"아니, 그래도 AI가 작성한 코드나 문서를 그대로 내놓는 것은 역시 무섭다."

이것도 이해한다. 나도 그렇게 생각한다.

즉, 생산성은 믿지만, 정확성은 신뢰하지 않는다.

이 상태에서 어떤 일이 벌어지는가?

"AI에게 코드를 쓰게 한다"는 것은, 인간이 리뷰어(Reviewer)로 돌아간다는 뜻이다.

여기까지는 모두 막연하게나마 알고 있다.

문제는 다음 단계이다.

AI가 초 단위로 만들어내는 코드를, 인간이 초 단위로 읽을 수 있는가?

불가능하다.

10배 속도로 생성되는 코드를 리뷰어 한 명이 감당할 수 있을 리 없다.

그렇게 되면 리뷰어를 2명, 3명, 5명으로 늘리게 된다.

코더(Coder)를 없앴는데, 리뷰어가 늘어날 수도 있는 미래?

"구조가 이상하지 않은가?"라는 점이다.

여기서 확실히 써두고 싶은 것이 있다.

인간 리뷰어에게는 구조적인 약점이 3가지 있다.

지적한 부분이 고쳐지지 않으면, 짜증이 난다.

"일단 전에 지적한 여기! 고쳐서 다시 가져와"라며 돌려보낸다.

돌려보낸 뒤에 뒤에 있었을지도 모를 치명적인 버그(Bug)는 보지 않는다.

"완주하지 못하는 리뷰", 이것이 인간 리뷰어의 첫 번째 약점이다.

인간이기에 휴일에는 쉰다.

컨디션 난조나 개인 사정으로 쉬는 것은 어쩔 수 없다, 인간이니까.

쉬게 되면 리뷰 업무가 중단되므로, 리뷰어를 여러 명 체제로 만든다.

여러 명이 되면 판단 기준이 흔들린다.

흔들리기 때문에 논쟁이 발생하고, 귀중한 시간과 체력을 소모한다.

리뷰가 시작되기도 전에 이미 체력을 깎아먹고 있는 상태다.

GitHub의 리뷰 툴도, 각종 테스트 툴도 우수하지만 코드 체계의 체크밖에 하지 않는다.

"이 구현은 사양서 3장의 요구사항 B를 충족하는가"라는 판정은 할 수 없다.

"커버리지(Coverage) 80%를 넘었으니 OK"도 마찬가지로, 라인 커버리지(Line Coverage)로는 "사용자가 화면 A에서 조작 B를 했을 때, 최종적으로 화면 C에서 올바른 결과가 보이는가"를 보장할 수 없다.

그래서 사기ダメ.com에서는 "커버리지 + 실기 fixture + KPI 모니터링"의 3종 세트로 담보하고 있다.

코더가 시나리오 테스트를 쓰면 되는가?

확실히 그렇지만, 그 시나리오를 쓰는 것도, 리뷰하는 것도, 결국은 사양을 머릿속에 넣은 인간이다.

즉 무엇을 하든, 사양 이해라는 무거운 작업이 인간 리뷰어에게 계속 남는다.

위에서 언급한 3가지 약점을 AI의 특성과 비교해 본다.

인간 리뷰어의 약점	AI 리뷰어의 특성
① 감정으로 막힘	24시간, 동일한 기준으로 담담하게 처리
...	...

...이것은 이제 AI 리뷰어의 승리 공식밖에 보이지 않는다.

코더를 AI화하기 전에, 리뷰어를 AI화해야 한다.

순서가 명백히 반대다, 세상의 논의는.

"AI에게 코드를 쓰게 해도 괜찮을까?"가 아니다.

"AI에게 리뷰를 시키려면 무엇이 필요한가?"를 먼저 풀어야 한다.

리뷰가 AI로 돌아가게 되어야 비로소, 코더의 AI화가 진정한 의미에서 생산성에 효과를 발휘한다.

그 전까지 **AI 코딩(AI Coding)**은 그저 **"인간 리뷰어 병목 현상 증산기"**에 불과하다.

단, ...

AI 리뷰어 × AI 코더 구성은, 방치하면 무한 수정 루프에 빠진다.

리뷰어 AI가 수백 건을 지적 → 코더 AI가 수정 → 다시 리뷰어가 반려 → 이하 무한...

이것은 탁상공론이 아니라, 확실히 일어나는 일이다.

그렇기에 "정지 조건" 설정이 필수적이다.

• 동일 지적의 재발 횟수로 종료
• 리뷰 왕복 횟수의 상한 설정
• 중요도 High만 반드시 수정, Low는 무시
• 일정 루프 후에는 인간에게 에스컬레이션(Escalation) (
  여기서 인간의 등장!)

리뷰의 관점은 업계, 언어, 프로덕트 특성에 따라 크게 다르다.

• 금융계 → 감사 로그(Audit Log)·트랜잭션 정합성
• 의료계 → 개인정보 보호·GDPR 대응
• 게임 → 퍼포먼스(Performance)·UX
• 사기 방지와 같은 적대적(Adversarial) 계열 → 공격 표면(Attack Surface)의 망라성
• 문서 작성 → 프레젠테이션 노하우

이것들은 모두, **리뷰 관점 패키지 (Review Perspective Package)**로서 md화할 수 있다.

그리고 그것을 마켓에서 사고팔 수 있는 세상이 있어도 좋다.

"이 프로젝트는 관점 패키지 v2.3을 채택"

"업계 표준 세트를 지속적으로 구매"

그러한 시장이 형성된다면, AI 리뷰어의 정밀도는 패키지 품질로 담보된다.

리뷰 지식을 사전으로서 유통시키는 새로운 시장의 여지는 충분히 있다고 생각한다.

관심 있는 분은 꼭 연락을... ㅋ

지난 기사에서 "코드를 읽지 않는데 무섭지 않은가"라는 질문을 받았던 답변은 이렇다.

"읽지 않아도 되는 메커니즘을 별도의 축으로 구축해 두었기 때문"

다만 솔직히 말하자면, 언젠가는 리뷰어 자체를 AI에게 맡기고 싶다.

그렇게 되어야 비로소 개인이 공공 서비스를 초고속으로 만들고 계속 운영하거나, 프로젝트 내의 생산성이 폭발적으로 상승하는 것이 당연해진다.

그런 세상이 오기 전까지, 사기안돼.com(詐欺ダメ.com)에서는 설계서와 ER 다이어그램(ER Diagram), 그리고 실기 KPI로 버틸 예정이다.

※ 별도로 작업 중인 프로젝트는 아주 철저하게 리뷰하고 있습니다... ㅋ

순서를 틀리지 않기 위해, 우선 리뷰어부터 AI로.

오늘은 그런 이야기였습니다.