Claude와 Gemini 크로스 리뷰 워크플로우

이 글의 배경이 되는 이야기는 17화: AI 두 명이 동시에 말했다 — “이제 그만하세요”와 21화: 여기까지의 이야기에서 읽을 수 있습니다.

이 글을 읽으면 알 수 있는 것

이 프로젝트에서 AI는 도구가 아니라 공동 작업자에 가깝습니다. 코드의 상당 부분을 AI와 함께 작성했습니다.

그런데 문제가 있었습니다. AI가 자기가 만든 코드의 문제를 잘 못 찾습니다.

새우깡 사건이 대표적입니다. AI가 이름 기반 매칭 로직을 설계했고, AI에게 “이 코드에 문제가 없는지” 물었습니다. “잘 작동합니다”라는 답이 돌아왔습니다. 2,434건이 전부 틀린 코드였는데요.

사람도 마찬가지입니다. 자기가 쓴 글의 오탈자를 스스로 잘 못 찾는 것처럼, 자기가 만든 로직의 결함을 자기가 발견하기는 어렵습니다.

그래서 두 번째 시선이 필요했습니다.

역할	담당 AI	하는 일
구현	Claude	코드 작성, 기능 구현, 디버깅
리뷰	Gemini	코드 리뷰, 설계 검토, 대안 제시

엄격하게 고정된 것은 아닙니다. 주제에 따라 역할이 바뀌기도 합니다. 하지만 기본 원칙은 **“만든 AI가 아닌 다른 AI가 검토한다”**입니다.

한 AI가 매칭 엔진을 구현할 때, 전체 데이터를 메모리에 올리는 방식을 사용했습니다. 98만 건의 원재료를 한 번에 로드하고 처리하는 구조였습니다.

다른 AI가 이 코드를 보고 지적했습니다. “이 방식은 데이터가 늘어나면 메모리가 부족해집니다. 배치 단위로 처리하는 것이 안전합니다.”

구현한 AI에게 같은 질문을 했으면 “현재 데이터 규모에서는 문제없습니다”라고 답했을 겁니다. 맞는 말이지만, 미래의 문제를 예방하지 못합니다.

한 AI가 검증 시스템을 설계할 때, 5가지 검증 항목을 만들었습니다. 다른 AI가 검토하면서 “영양정보 수치의 합리성 검증(열량이 음수인 경우 등)이 빠져 있다”고 지적했습니다.

만든 쪽은 “현재 데이터에서 그런 경우가 없다”고 할 수 있습니다. 하지만 검증은 “현재 없는 것”이 아니라 “앞으로 나타날 수 있는 것”을 잡기 위한 것입니다.

17화에서 이야기한 것처럼, 두 AI가 독립적으로 같은 결론을 내렸습니다. “백엔드 완성도는 충분합니다. 프론트엔드로 넘어가세요.”

한 AI만 이 말을 했으면 “정말 그런가?” 하고 의심했을 겁니다. 두 AI가 각자의 분석에 기반하여 같은 결론을 낸 것이 전환의 결정적 계기였습니다.

이것은 이 프로젝트에서의 체감이며, 일반화하기 어렵습니다. AI 모델은 계속 업데이트되고, 같은 질문에도 맥락에 따라 다른 답을 합니다.

세 번째를 선택했습니다. 모든 코드를 크로스 리뷰하는 것은 비현실적입니다. 대신 매칭 로직 변경, 데이터 모델 변경, 새로운 외부 연동 등 영향 범위가 큰 변경에 대해서만 다른 AI의 검토를 받습니다.

두 AI 모두 같은 방향으로 틀릴 수 있습니다. 두 AI가 합의하더라도, 그것이 정답이라는 보장은 없습니다. AI의 학습 데이터가 유사하므로, 같은 편향을 가질 수 있습니다.

맥락 전달이 어렵습니다. 한 AI와 긴 대화를 나눈 후, 다른 AI에게 같은 맥락을 전달하려면 요약이 필요합니다. 이 과정에서 중요한 디테일이 빠질 수 있습니다.

AI의 출력을 신뢰하는 가장 좋은 방법은, 다른 AI에게 의심하게 하는 것입니다.

다음 글: “이제 그만하세요” — 99.5%에서 멈추는 용기