AI의 거짓말은 다른 회사 AI가 잡는다

AI에게 보고서를 검토시켜 본 사람이라면 한 번쯤 겪는 일이 있습니다. "이 문서에 틀린 부분 있어?"라고 물으면, 방금 자기가 쓴 문서를 두고 "문제없습니다, 잘 작성되었습니다"라고 답하는 순간이요. 사람도 자기 글의 오타는 잘 못 봅니다. AI는 그 편향이 더 심합니다. 자기가 생성한 답을 다른 답보다 후하게 평가하는 성향, 이걸 연구자들은 자기선호 편향(self-preference bias)이라고 부릅니다. 문제는 이겁니다. AI 심판은 자기 또는 같은 계열의 산출물에 후한 경향이 있습니다. 그래서 저는 규칙을 하나 세웠습니다. 작업물 검증은 반드시 다른 회사의 AI에게 맡긴다. 그런데 이 규칙, 정말 효과가 있을까요? 믿음이 아니라 숫자로 확인하고 싶었습니다.

실험: 가짜 출처를 심고, 다른 회사 AI에게 맡긴다

설계는 단순했습니다. 검증된 깨끗한 항목 9개에, 제가 일부러 오염시킨 항목 6개를 섞었습니다. 오염의 종류도 다양하게 심었습니다. 결론을 반대로 뒤집기, 저자 이름 바꿔치기, 출처를 엉뚱한 논문으로 교체, 수치 변조, 아예 존재하지 않는 URL 날조, 원문에 없는 주장 삽입. 이렇게 15개 항목을 섞은 다음, 정답지는 저만 가지고 있고 검증하는 AI들에게는 "어느 게 가짜인지" 전혀 알려주지 않았습니다. 완전한 블라인드 테스트입니다.

검증은 네 개의 층위로 나눠서 돌렸습니다. 먼저 기계적인 방식(URL이 실제로 열리는지 확인하는 프로그램), 그리고 서로 다른 세 회사의 모델. Claude Sonnet, GPT 계열, GLM. 세 모델 모두 웹 접근 권한을 주고 "출처를 직접 확인하라"고 했습니다.

결과: 6개 중 6개, 오경보 0

기계적 검증부터 보면 뼈아팠습니다. URL이 실제로 열리는지만 확인하는 방식은 6개 중 1개만 잡았습니다. 날조한 가짜 URL은 걸렸지만, 나머지 5개는 통과시켰습니다. URL이 실재한다는 것과 그 주장이 사실이라는 것은 전혀 다른 문제라는 걸 숫자로 확인한 셈입니다. 링크가 살아 있어도 그 안의 내용은 조작될 수 있으니까요.

그런데 세 개의 AI 모델은 달랐습니다. 세 모델 모두 6개를 전부 잡았습니다(6/6). 오경보, 즉 멀쩡한 항목을 가짜라고 잘못 지목한 경우는 0건이었습니다. 속도만 조금씩 달랐을 뿐(가장 빠른 모델은 69초), 검출 능력은 동률이었습니다. 결론을 뒤집은 것도, 저자를 바꾼 것도, 수치를 변조한 것도, 세 회사의 AI가 각자 웹에서 원문을 열어 확인하고 "이건 원문과 다르다"며 정확히 짚어냈습니다.

흥미로운 장면도 있었습니다. 한 항목을 두고 두 모델은 "확인됨"이라 했는데, 한 모델은 정직하게 "초록만으로는 확인 불가"라며 보류했습니다. 세 표의 다수결이 이 이견을 정확히 해소했습니다. 패널을 여러 개 두는 이유가 여기 있습니다. 한 모델만 썼다면 이 보류가 애매한 상태로 남았을 텐데, 세 모델의 합의가 판정을 확정지었습니다.

진짜 반전: 심지 않은 오류까지 잡혔다

여기까지는 제가 심은 함정을 잡은 이야기입니다. 정말 놀란 건 다음입니다. 세 모델이 검증 과정에서, 제가 심지도 않은 진짜 오류를 찾아냈습니다.

원본 자료에 "180개 구성"이라고 적힌 수치가 있었습니다. 깨끗한 항목으로 분류했던, 제가 손대지 않은 부분입니다. 그런데 두 모델이 독립적으로 "원문 초록에는 260개라고 되어 있다"고 지적했습니다. 확인해 보니 사실이었습니다. 180은 비용 추적용 하위 집합의 숫자였고, 전체 구성은 260개가 맞았습니다. 더 뼈아픈 건, 하루 전에 세 개의 AI 레인이 똑같이 이 오류를 냈고 그대로 전파됐다는 점입니다. 교차 검증을 돌리지 않았다면 영영 몰랐을 조용한 오류였습니다.

이게 왜 무서운 오류일까요? 타입 오류나 문법 오류는 컴파일러가 잡아줍니다. 죽은 링크는 프로그램이 잡아줍니다. 하지만 "180이 그럴듯하게 틀린" 오류는 아무도 안 잡아줍니다. 그럴듯하기 때문입니다. 이런 오류는 오직 원문을 다시 대조하는 독립된 눈만이 잡습니다.

배움: 검증은 신뢰가 아니라 구조다

이 실험에서 제가 가져간 배움은 세 가지입니다.

첫째, 한 시간 전에 만든 내 규칙조차 크리틱이 잡습니다. 실제로 이날 저는 새 운영 규칙을 하나 만들었는데, 다른 회사 AI가 그 규칙이 등재된 지 한 시간 만에 결함을 지적했습니다. 자기 손으로 만든 것을 자기가 검토하면 놓칠 위험이 큽니다. 저자와 검토자는 달라야 합니다.

둘째, 원문과 대조할 수 있는 사실 검증은 저렴한 모델로도 충분했습니다 (이번 실험 유형 기준 — 다른 유형의 검증까지 일반화는 아직입니다). 세 모델의 검출 능력이 동률이었다는 건, 이런 대조형 검증엔 굳이 가장 비싼 모델을 쓸 필요가 없다는 뜻입니다. 비싼 판단력은 모델끼리 이견이 갈릴 때, 그 이견을 조정하는 데만 아껴 쓰면 됩니다. 비용과 품질을 동시에 잡을 수 있습니다.

셋째, 가장 중요한 배움입니다. 검증은 신뢰의 문제가 아니라 구조의 문제입니다. "이 AI는 믿을 만해"라는 말은 검증이 아닙니다. 조작된 출처가 조용히 흘러 들어가는 길목마다, 그것을 만들지 않은 다른 회사의 눈을 하나 세워 두는 것. 그게 검증입니다. 저는 이제 어떤 AI의 결과물도 그 AI 자신에게 검토받지 않습니다. 대신 다른 가족에게 넘깁니다. 신뢰해서가 아니라, 구조가 그렇게 짜여 있기 때문입니다.

여러분이 AI로 중요한 문서를 만든다면, 오늘 딱 하나만 바꿔 보시길 권합니다. 검토는 다른 회사 AI에게 맡기세요. 같은 AI에게 막연히 "잘 썼나 봐줘"라고만 묻는 것은, 검증이 아니라 자화자찬에 가깝습니다.

오늘 해볼 것

1. 지금 작업 중인 중요한 문서가 A사 AI로 만든 것이라면, 오늘 검토만 B사 AI에게 맡겨보세요. 무료 티어로도 시작할 수 있습니다 — 다만 링크 열람이 실제로 되는지 먼저 확인하세요.
2. 검토 프롬프트는 "잘 썼나 봐줘"가 아니라 이렇게 쓰세요: "이 문서에서 사실 주장 5개를 뽑아, 각각 근거가 실제로 있는지 확인하고, 반박할 수 있는 것은 반박해줘." 검토자를 응원단이 아니라 공격수로 세우는 겁니다.
3. 출처가 달린 문서라면 한 줄을 추가하세요: "각 출처 링크를 열어서, 그 페이지가 인용된 주장과 실제로 일치하는지 대조해줘." 링크가 살아 있다는 것과 주장이 맞다는 것은 다른 문제입니다 — 제 실험에서 기계식 링크 검사가 6개 중 1개밖에 못 잡은 이유입니다.