AI가 자신있게 틀리는 게 제일 무섭다 — 그래서 AI 넷한테 서로 채점을 시켰다

나는 개발자가 아니다. 자료 조사를 해서 글을 쓸 때 AI를 쓰는데, 언젠가부터 무서워졌다. AI는 틀린 답도 아주 당당하게 말한다. 그래서 AI 하나를 믿는 대신, AI 넷을 한 화면에 앉혀 놓고 서로의 답을 채점하게 만들었다. 개발은 전부 내 AI 비서한테 시켰다. 잘된 부분과, 이틀은 잡아먹은 버그 이야기까지 솔직하게 적는다.

1. 문제 — AI마다 말이 다르다

리서치 기반으로 글을 쓸 때 내 습관은 이랬다. 같은 질문을 AI 여러 개한테 각각 던지고, 답을 눈으로 비교한다. 창을 옮겨 다니며 복붙하고, 어디가 다른지 손으로 찾는다.

목적은 "어느 AI가 틀렸나"를 잡아내는 건데, 방식이 너무 원시적이었다. 탭 네 개를 왔다 갔다 하다 보면 빠뜨리고, 무엇보다 시간이 오래 걸렸다. 그러다 문득 이런 생각이 들었다. 이 비교 자체를, 그냥 AI들끼리 하게 만들면 안 되나?

2. 해법 — AI 넷을 한 회의실에 앉혔다

내가 AI 비서한테 부탁한 건 이거였다. "질문 하나를 넣으면 AI 넷한테 동시에 물어봐. 각자 답이 오는 대로 화면에 카드로 띄우고, 마지막에 넷이 합의한 것과 갈린 것을 정리해줘."

비서는 이렇게 만들었다. 각 AI는 그냥 줄글로 답하는 게 아니라 정해진 양식으로 답한다 — 판정(사실 / 부분 사실 / 반박 / 검증 불가), 확신 정도, 핵심 근거, 정정할 점, 출처. 답이 도착하는 대로 카드가 하나씩 뜨고, 다 모이면 요약 카드가 붙는다. 마음에 든 결과는 버튼 하나로 메모함에 저장돼서, 글 쓸 때 바로 인용한다.

넷은 성격이 일부러 다르다. 하나는 웹을 뒤져 출처를 다는 데 강하고, 둘은 지식과 추론이 강하되 학습된 시점이 서로 다르고, 나머지 하나는 또 다른 계열의 대형 AI다. 나는 여기서 하나 배웠다. 같은 AI 넷보다, 성격 다른 AI 넷이 서로의 사각지대를 덮는다.

3. 핵심 설계 — '대답 못 한 AI'를 찬성으로 세지 않기

여기서 비서가 강하게 주장한 원칙이 하나 있다. AI 중 하나가 양식을 어기거나 제대로 답을 못 하면, 그걸 '중립 찬성'으로 세면 안 된다는 것이다. 그러면 합의가 가짜로 부풀려진다. 대답 못 한 AI는 표가 아니라 기권으로 빠져야 한다.

또 하나. 넷의 의견이 반반으로 갈리면, 최종 판정을 억지로 하나로 몰지 않고 '의견 갈림'이라고 정직하게 표시하고 확신 수치도 확 낮춘다. "AI가 자신있게 틀리는 것"보다 "이건 갈린다"가 백 배 낫다. 사실 이 두 원칙이 이 도구의 전부라고 해도 된다.

4. 하이라이트 — AI들이 갈렸는데, 그게 정답이었다

테스트로 이런 주장을 넣어봤다. "테슬라는 2024년에 전 세계에서 전기차를 가장 많이 판 회사다."

결과가 흥미로웠다. 웹을 뒤지는 AI는 '사실'이라며 출처를 잔뜩 달았다. 추론이 강한 AI는 '부분적으로만 사실'이라며, 집계 기준(연간이냐 분기냐, 순수 전기차만이냐 아니냐)에 따라 1위 회사가 달라지는 유명한 논쟁을 짚었다. 그래서 최종 판정은 '의견 갈림'이 됐다.

그런데 이게 실제로 정확한 상태다. 2024년 전기차 판매 1위는 집계 기준에 따라 갈리는, 원래 논쟁적인 주제다. 만약 내가 AI 하나한테만 물었으면, 그 AI가 어느 한쪽을 자신있게 말했을 것이고 나는 그대로 믿었을 것이다. 넷이 갈렸다는 사실 자체가 "여긴 조심해"라는 신호였다.

반대로 "2024년 노벨 물리학상은 홉필드와 힌턴이다" 같은 확실한 사실은 넷이 만장일치로 '사실'이라 했다. 확실한 건 확실하게, 애매한 건 애매하게 — 딱 내가 원하던 거였다.

5. 이틀을 잡아먹은 버그 — "터미널에선 되는데요"

기능은 됐는데, AI 넷 중 하나만 계속 대답을 안 하고 기권 처리됐다. 240초를 꽉 채우고 빈 답이 왔다. 이상한 건, 똑같은 걸 내가 직접 명령어로 실행하면 4초 만에 답한다는 거였다.

이건 정말 사람을 미치게 하는 종류의 버그다. "내 손으로 하면 되는데, 프로그램이 하면 안 된다." 비서가 기록을 파보니 단서가 딱 한 줄 있었다. 그 AI 도구가 "추가 입력을 기다리는 중"이라며 멈춰 있었다.

원인을 내 말로 옮기면 이렇다. 그 도구는 "혹시 더 할 말 있어?" 하고 입력 창을 열어두는 습관이 있다. 내가 직접 실행하면, 사람이 쓰는 창이라 시스템이 알아서 "없어, 끝"이라고 넘어간다. 그런데 프로그램이 대신 실행하면, 그 '끝'이라는 신호를 아무도 안 보내줘서 도구가 영원히 기다린다.

해결은 허무하게도 한 줄이었다. 프로그램이 그 도구를 부른 직후에 "입력 끝"이라고 문을 닫아주는 것. 더 웃긴 건, 이 부품이 내가 평소 쓰는 다른 AI 비서의 예비 경로에서도 똑같이 쓰이고 있었다는 거다. 즉 몇 달 동안 "가끔 그 AI가 조용히 죽던" 잠복 버그를, 이번 작업이 우연히 수면 위로 끌어올린 셈이다.

교훈은 이거다. "내 터미널에선 되는데요"는 대개 환경이 다른 것이고, 그 차이는 눈에 안 보이는 곳에 숨어 있다. 비개발자인 나도 이건 확실히 배웠다 — 되는 것과 안 되는 것 사이엔, 내가 못 보던 조건이 항상 하나 더 있다.

6. 숫자로 남기면

  • 실측 응답 속도: 웹검색형 약 9초, 추론형 약 16초, 문제였던 AI 16.8초(수정 후 — 수정 전엔 240초 멈춤), 나머지 하나 약 6초
  • 고친 버그: 몇 달 묵은 잠복 버그 1개, 수정은 딱 한 줄
  • 안전장치: 새로 짠 자동 테스트 21개(전부 가짜 응답으로, 진짜 AI 호출 없이 검증)
  • 작업 기간: 기획부터 실서버 검증까지 하루

7. 그래서 남은 것

이제 리서치 문서를 쓸 때, 나는 AI 하나의 답을 곧이곧대로 믿지 않는다. 질문을 넣고, 넷이 뭐라 하는지 보고, 갈리면 바로 그 지점을 의심한다. AI가 똑똑해서 좋은 게 아니라, 서로 안 맞을 때 그걸 숨기지 않아서 쓸 만한 도구가 됐다.

나는 여전히 코드를 못 읽는다. 하지만 "AI를 한 개 믿지 말고, 여러 개를 서로 채점시켜라"는 원칙 하나는, 개발을 몰라도 오래 남을 것 같다.