둘을 서로 못 보게 했다

“AI 하나만 믿지 말고 두 개로 교차검증해라.” 흔한 말이 됐다. “Claude한테 짜게 시키고 Codex한테 까게 시킨다”는 레시피도 커뮤니티에 흔하다. 그런데 대부분은 한 방향이다. Claude가 짠 걸 Codex가 리뷰한다. 여기 함정이 있다. 두 번째 모델이 첫 번째 답을 이미 본 채로 검토를 시작한다는 것. 사람도 그렇듯, 남이 내린 결론을 먼저 보면 거기 끌려간다.

그래서 내가 만든 crosscheck는 반대에서 출발했다. 두 AI가 서로의 답을 아예 못 보게 갈라놓는 것부터.

네 가지 차이

흔한 “AI 리뷰”와 다른 지점은 네 개다.

첫째, 블라인드. 외부 엔진(Codex)과 메인(Claude)에게 같은 질문을 던지되, 서로의 답을 보기 전에 각자 독립으로 조사하게 한다. 앵커링을 원천에서 끊는다.

둘째, 상호 반박. 그 다음에야 서로의 결론을 까 보여주고 반박하게 한다. 동의·반박·내가 틀린 부분을 각각 근거와 함께.

셋째, 근거를 파일·라인까지 되짚기. “여기가 원인”이라고 하면 그 파일과 라인을 실제로 다시 열어 확인한다. 판정은 다수결이 아니라 근거의 질로만 가린다.

넷째, 확인과 추측을 분리. 모든 인과 주장에 “근거로 확인됨” / “추측” 라벨을 강제한다. 그럴듯한 추측이 확인된 사실인 척 넘어가는 걸 막는다.

공개된 도구들을 조사해보니, 특히 셋째, 상대가 인용한 근거를 직접 열어 재확인하고 확인/추측을 라벨링하는 단계는 어디에도 명시적으로 없었다. 가장 가까운 도구도 블라인드까지였다.

실제로 뭘 잡았나

말로는 다 그럴듯하다. 실제로 뭘 잡았는지가 중요하다.

음악 추천 사이드에서 아티스트 이름 매칭을 손보다, 표기 차이를 흡수하려고 공백 제거 로직을 넣었다. 빌드 통과, 테스트 초록불. 마지막에 Codex가 짚었다. will.i.am을 공백 제거하면 william이 돼서 전혀 다른 William과 매칭된다고. 한 글자 토큰이 있으면 붙이지 않는 가드를 추가하고서야 배포했다. 한 모델한테만 물었으면 그대로 나갔을 것이다.

반대 방향도 있었다. 언젠가 Codex가 “이건 데이터가 오염된다”고 단정했는데, 근거를 열어보니 다른 가드 때문에 실제로는 영향 없는 코드였다. 그때는 내가 반박했고 Codex가 물러섰다. 한 번은 내가 틀렸다. 배치 결과에서 어떤 지표를 “1에서 3으로 늘었다”고 읽었는데, Codex가 DB를 다시 세서 “0에서 3”이라 정정했다. 그쪽이 맞았다.

그래서 다수결이 아니라 근거로 가린다. 어느 쪽도 그냥 안 믿는다. 나까지 포함해서.

도구가 한 것과 내가 한 것

여기서 선을 하나 그어야 한다.

이 도구의 세부, 즉 왜 하필 다른 벤더라야 하는지, 블라인드를 어떻게 구현하는지, read-only를 OS 레벨에서 어떻게 강제하는지는 상당 부분 내가 원래 알던 게 아니다. 만들면서 AI들과 같이 조사하며 정리했다. “다수결이 아니라 근거의 질로 판정한다”는 원칙조차 솔직히 도구가 짜준 쪽에 가깝다. 그러니 “내가 이 정교한 검증 구조를 설계했다”고 말하면 과장이다.

내가 우긴 건 하나였다. 어려운 판단일수록 한 모델한테 몰아주지 말자. 둘을 따로 굴리고, 붙여서 싸우게 하고, 근거로 가리자. 그리고 실제 작업마다 그걸 고집스럽게 돌렸다. 딱 거기까지가 내 몫이다. 나머지 정교함은 그 고집 위에 도구가 얹은 것이고, 그 합작이 위 버그들을 잡았다.

이 구분을 흐리지 않는 게 나한테는 중요하다. AI가 많은 걸 해주는 시대에 내가 한 것과 도구가 한 걸 섞어 “다 내가 했다”고 말하기 시작하면, 막상 내가 뭘 할 줄 아는지를 나부터 모르게 되니까.

언제 꺼내나

crosscheck는 의도적으로 발동하는 도구다. Codex 호출 한 번이 맥락을 통째로 넘기느라 보통 몇 분씩 걸려서, 가벼운 이슈엔 과하다. 단독 진단으로 확신이 안 서는 난제, “왜 이렇게 됐나”처럼 단정 위험이 큰 인과 추론, 보안·업그레이드 리스크, 설계가 갈릴 때. 그럴 때만 꺼낸다.

바꿔 말하면, AI에게 답을 빨리 받는 게 목적이 아닐 때 쓰는 도구다. 그 답이 통과해야 할 절차를 세우는 게 목적일 때. 요즘 내가 재미를 느끼는 지점도 거기다. 더 똑똑한 답을 받아내는 것보다, 그 답이 통과해야 할 절차를 짜는 것.