교차 검토 2,481건: Claude Code와 Codex가 서로의 작업을 확인하다

Claude Code가 작업을 마치면 공개 전에 Codex가 읽습니다. Codex가 작성하면 Claude가 읽습니다.

은행도 비슷하게 일합니다. 자기 대출을 자기가 승인하지는 않죠. 한 사람이 서류를 작성하고 다른 사람이 서명합니다. 누구도 모욕이라고 생각하지 않습니다. 우리는 두 AI 에이전트가 짝을 이뤄 같은 일을 맡고, 하나는 수행하고 다른 하나는 검토하는 방식을 Dual Brain이라고 부릅니다. Sno Station에 내장돼 있으며, 우리는 칠월 중순부터 이렇게 일해 왔습니다.

검토할 때마다 빌드 머신의 로그 파일에 한 줄이 남습니다. 얼마 전 궁금해져서 그 줄을 세어 봤습니다.

건수

칠월 19일부터 구월 21일까지 두 AI 에이전트는 서로의 작업을 2,481건 검토했습니다. 그 기간 중 실제로 일한 날은 63일로, 하루에 약 39건입니다. 9,452개 파일에서 3.2백만 줄을 읽었습니다.

검토 한 건에는 약 두 분이 걸립니다. 중앙값은 141초이고 열 건 중 아홉 건은 여섯 분 안에 끝납니다. 이 숫자는 보기보다 중요합니다. 사람이 하는 검토에는 하루가 걸리고, 대부분은 사람을 기다리는 시간입니다. 두 분이면 검토할 가치가 있는지 따지지 않게 됩니다. 모든 작업을 검토합니다.

저는 대부분의 작업이 통과할 거라고 생각했습니다.

판정이 나온 검토 중 431건은 승인됐습니다. 1,953건은 수정이 필요하다는 판정을 받았습니다. 즉 다섯 건 중 네 건에서 두 번째 AI 에이전트가 작업을 돌려보냈습니다.

다섯 건 중 네 건입니다. 피곤한 인턴이 대충 쓴 초안이 아닙니다. 모델은 이미 테스트를 실행했고 작업이 끝났다고 했습니다.

코드와 계획

그다음 코드 검토와 계획 검토를 따로 세어 봤습니다.

코드는 27% 통과했습니다. 1,475건 중 398건이 승인됐습니다. 좋지는 않지만 감당할 만합니다.

계획은 3.6% 통과했습니다. 907건 중 33건입니다.

두 번 확인해야 했습니다. 계획은 문서입니다. 무엇을 왜 만들지 설명합니다. 컴파일할 필요가 없으니 코드보다 문서를 제대로 쓰기가 쉬울 것 같습니다. 하지만 반대입니다. 코드는 실행할 때마다 현실의 검증을 받습니다. 계획에는 실제로 없는 데이터베이스 열이 있다고 적을 수 있습니다. 누군가 그 문장을 바탕으로 만들기 전까지는 아주 그럴듯해 보입니다.

그래서 이제는 계획과 함께 사실도 검토자에게 줍니다. 계획 검토 전에 작성한 AI 에이전트가 명령을 실행하고, 행을 세고, 스키마를 출력해 원본 결과를 첨부합니다. 그러면 검토자는 계획의 주장과 대조할 근거가 생깁니다. 이것이 없으면 자료를 볼 수 없는 시험과 같습니다. 검토자는 문서 안의 모순은 찾을 수 있지만 문서와 현실이 다른지는 알 수 없습니다.

가장 심각한 지적은 대부분 바로 이 간극에서 나옵니다. 같은 기간 검토자들은 1,395건의 검토에서 심각한 문제 4,277건을 표시했습니다. 제가 전부 확인하지는 않았고, 모두 실제 문제인 것도 아닙니다. 하지만 실제였던 문제는 대체로 같은 종류였습니다. 누구도 직접 확인하지 않은 내용을 확신에 차서 적어 놓은 것이죠.

잘못된 부분

여기서 끝내면 좋은 이야기입니다. 이 모든 검토가 작업을 개선했다고 믿고 싶습니다.

하지만 그렇게 단순하지 않습니다. 검토자는 언제나 무언가를 찾아냅니다.

뒤이은 차례를 보죠. 작성자가 지적된 문제를 고치고 다시 검토를 요청한 뒤에는 21%가 통과했습니다. 첫 차례에는 17%였습니다. 모든 지적을 고쳐도 통과 확률은 거의 달라지지 않았습니다. 어떤 작업은 열다섯 차례까지 갔습니다.

작성자가 열다섯 번 실패했다는 뜻은 아닙니다. 검토자가 검토자다운 일을 한 것입니다. 유능한 모델에 문제를 찾으라고 하면 찾아냅니다. 일반적인 사용 경로가 깨끗하면 구석을 뒤집니다. 같은 밀리초에 도착한 두 요청. 쓰기 작업 중간에 들어온 취소. 가능은 합니다. 운석에 맞는 일도 가능한 것처럼요.

작성자는 순순히 문제를 하나씩 고치면서 무언가를 추가합니다.

이번 달 초에 작은 버그가 있었습니다. 수정안은 여섯 차례 검토를 거쳤습니다. 매번 검토자가 새로운 우려를 내놓고, 매번 작성자가 방어 장치를 추가했습니다. 토큰 수의 상한. 세션별 잠금. 이미 제공한 내용을 추적하는 별도의 테이블. 별칭 매핑. 결국 패치는 작은 요새가 됐습니다.

그 장치들은 실제 서비스에서 한 번도 작동하지 않았습니다. 그 밑에 가려진 수정안 자체에는 여전히 한 줄짜리 식별 오류가 있었지만, 방어 장치에 묻혀 아무도 보지 못했습니다. 조용한 악기 소리를 들으려고 증폭을 올렸더니 잡음만 주로 들리는 것과 같았습니다.

우리가 추가한 규칙

그래서 규칙을 하나 적었습니다. 이 실험 전체에서 얻은 가장 유용한 결과입니다.

문제를 찾았다고 해서 코드를 추가하라는 뜻은 아닙니다.

이제 검토 결과는 두 부류로 나뉩니다. 첫째는 실제 사용자가 평범한 날에 겪을 문제이면서, 가장 작은 수정으로 새로운 것을 추가할 필요가 없는 경우입니다. 이런 문제는 고칩니다. 둘째는 나머지 전부입니다. 드문 상황이나 새로운 잠금, 재시도, 테이블이 있어야 처리할 수 있는 것들입니다. 이를 기록하고 보고합니다. 사람이 필요하다고 결정하지 않는 한 코드로 만들지 않습니다.

또 검토자에게 빠진 것을 찾기 전에 불필요한 것을 찾게 했습니다. 아무도 필요로 하지 않은 잠금. 사용하는 곳이 한 군데뿐인 설정. 코드를 다시 말할 뿐인 테스트. 이제 삭제도 검토 지적으로 셉니다.

횟수에도 상한이 있습니다. 코드는 세 차례, 테스트는 한 차례입니다. 그 뒤에는 사람이 판단합니다. 아마 애초부터 사람이 할 일이었을 겁니다.

얼마나 가치가 있나

가치를 깔끔한 숫자로 말할 수는 없습니다. 그러고 싶습니다. 하지만 비교할 대조군이 없습니다. 같은 작업을 검토 없이 공개한 두 번째 회사가 없으니까요.

제가 가진 사실은 이렇습니다. 다섯 건 중 네 건에서 한 모델이 끝났다고 한 작업에 다른 모델은 고칠 부분이 있다고 봤습니다. 그중 일부는 잡음입니다. 하지만 AI 에이전트 하나가 자기 작업을 검토하면 거의 돌려보내지 않습니다. 자기가 쓴 내용을 이미 믿기 때문입니다. 두 번째 의견은 다른 곳에서 와야 합니다. 다른 사람들이 훈련했고 첫 모델이 모든 게 괜찮다고 판단할 때 그 자리에 없었던 다른 모델에서요.

머리 둘이 하나보다 낫습니다. 둘 다 사람의 머리가 아니어도 그렇다는 사실을 알게 됐습니다.

Sno Station은 오픈 소스이며 교차 검토도 그 일부입니다. sno.ai에서 볼 수 있습니다.