In English.

AI로 위키를 만들어 본 사람들이 자주 하는 말이 있습니다. 만들기는 쉬운데 품질을 지키기가 어렵다는 겁니다. 페이지가 수천 개로 늘어나면 아무도 전부 다시 읽지 않습니다. 그 사이 남의 말을 엉뚱한 사람에게 붙였거나 원문의 단서 조항이 슬그머니 빠진 페이지들이, 멀쩡한 페이지와 똑같은 얼굴로 섞여 듭니다.

2026년 9월, 타입세이프(TypeSafe AI)가 Jev를 내놓았습니다. Jev는 글을 쓰지 않는 판정 모델(judge model)입니다. 예/아니오 같은 정해진 형식으로 질문하면 확률로만 답합니다. 우리는 이걸로 위키의 모든 페이지에 점수를 매기고, 점수가 낮은 페이지부터 다시 읽으면 품질 관리를 운에 맡기지 않아도 되겠다고 기대했습니다.

우리는 같은 프레임워크로 위키 두 개를 운영합니다. 하나는 약 2,400페이지 규모의 비공개 한국어 위키이고, 다른 하나는 누구나 볼 수 있는 이 공개 영어 위키입니다. 두 곳 모두에서 Jev를 시험했고, 공개 위키에서는 결과가 나오기 전에 규칙부터 문서로 적어 두었습니다. 공개 위키에서 나온 답은 ‘효과 없음’이었습니다. Jev의 순위는 결함 페이지를 무작위보다 잘 골라내지 못했습니다(다만 신뢰구간은 넓습니다). 그런데 정말 쓸모 있는 건 이 결론보다 왜 그렇게 나왔는지입니다. 그 이유는 Jev에만 있지 않습니다. AI가 쓴 문서 더미에 어떤 선별 도구를 붙여도 같습니다.

제목의 조리질은 이 기대를 옮긴 비유입니다. 예전에는 시장에서 산 쌀에 잔돌이 섞여 있어서, 밥을 짓기 전에 쌀을 물에 담그고 조리(대오리로 엮은 작은 국자 모양의 도구)로 휘휘 저어 떠냈습니다. 가벼운 쌀알은 물에 떠올라 조리에 담기고, 무거운 돌은 바가지 바닥에 가라앉아 남습니다. 쌀알을 하나하나 들여다보는 사람은 없습니다. 조리가 무게 차이로 한 번에 돌을 가려 줍니다.

품질이 천차만별인 위키에서 Jev로 불량 페이지를 골라내는 일이 바로 이 조리질입니다. 물론 돌을 가장 확실하게 찾으려면 쌀알을 하나하나 봐야 합니다. LLM 검수자가 모든 페이지를 원문과 대조해 읽고 결함을 적어 내는 방식입니다. 이번 실험에서 이 검수는 페이지당 약 39,000토큰이 들었습니다. 검수자가 불러오는 지침과 페이지, 원문, 그리고 써 내는 보고서까지 합친 값입니다(세션 기록에서 계산한 값이라, 공개 위키 숫자 가운데 유일하게 저장소 자료로 다시 계산할 수 없습니다). Jev도 페이지와 원문을 읽지만, 예/아니오 질문 최대 세 개에 확률로만 답하고 글은 한 줄도 쓰지 않습니다. 페이지당 입력 약 13,000토큰이었습니다. Jev의 낮은 점수가 불량 페이지를 제대로 짚어 준다면, 비싼 검수자는 그 페이지만 읽으면 됩니다.

다만 조리질에는 전제가 있습니다. 조리가 돌을 실제로 남겨야 하고, 돌이 어느 쪽을 떠도 나올 만큼 많지도, 거의 없지도 않아야 합니다. 한 번 뜰 때마다 돌이 나오면 조리로 가를 게 아니라 결국 한 알 한 알 다 봐야 합니다. 돌이 거의 없으면 조리가 제대로 듣는지 확인하는 데만도 쌀이 아주 많이 필요합니다. 우리 두 위키가 각각 어떤 쌀이었는지가 이 글의 줄거리입니다.

핵심 요약

무엇을 하려 했고, 그 전에 무슨 일이 있었나

LLM Wiki Newsroom은 문서 폴더를 서로 링크된 마크다운 위키로 바꿔 주는 오픈소스 프레임워크입니다. Claude Code 에이전트 여럿이 페이지를 쓰고, 데스크(Desk)라는 별도 검수 역할이 각 페이지를 원문과 나란히 놓고 읽으며 결함을 찾습니다(전체 구조는 지식 팩토리에 정리해 두었습니다). 데스크 검수는 비용이 큽니다. 한 번 검수할 때마다 페이지와 원문을 통째로 읽어야 합니다. 그래서 공개 위키에는 계산이 거의 필요 없는 선별 기준이 하나 있습니다. 사실(fact)로 분류된 주장이 7개 이상이고 인용이 3개 이상이면, 그 소스 페이지에만 데스크 검수가 자동으로 돌아갑니다.

이 기준도 일종의 조리입니다. 다만 페이지를 읽지 않고 주장과 인용 개수만 세서 가르는 거친 조리입니다. Jev가 이보다 나은 조리가 될 수 있느냐가 질문이었습니다. 그래서 소스 페이지마다 페이지와 원문을 함께 주고 Jev에게 최대 세 가지를 물었습니다.

  1. 각 주장의 맥락이 살아 있는가, 아니면 단서 조항·조건·범위가 빠졌는가?
  2. 원문이 논쟁의 양쪽을 다 담고 있을 때 페이지도 양쪽을 다 담았는가?
  3. 주장마다 이름이 붙은 발화자가 원문에서 실제로 그 말을 한 사람이나 기관인가?

세 번째 질문은 위키에 따로 페이지가 있는 사람이나 기관을 발화자로 내세운 주장에만 했습니다.

답은 확률로 나옵니다. 다만 이번에는 그 값을 확률로 쓰지 않았습니다. 비공개 위키에서 먼저 겪은 일 때문입니다.

비공개 위키에서 먼저 Jev를 재 봤더니, 한국어에서는 확률값 자체를 믿을 수 없었습니다. 기대 보정 오차(모델이 말한 확률과 실제로 맞은 비율의 차이)가 두 질문에서 0.17~0.20이었고, 점수가 높다고 실제로 더 자주 맞는 것도 아니었습니다. 같은 요청을 다시 보내면 점수가 평균 0.013, 많게는 0.10까지 달라졌습니다(반복 요청 598쌍 기준). 기준선 근처 페이지의 순서를 뒤바꿀 만한 크기입니다. 그래서 점수를 확률로 읽지 않고 페이지를 줄 세우는 순위로만 썼습니다. 순위로서는 꽤 강했습니다. 위 질문 가운데 하나에서 AUC 0.80이 나왔고, 기존 선별 기준은 0.37로 무작위보다도 못했습니다.

그런데 같은 측정에서 나온 다른 숫자 때문에, Jev로 새 페이지를 거르겠다는 구상은 접었습니다. 그 질문 하나로만 봐도 페이지의 약 44%가 불합격으로 추정됐습니다(60페이지 층화 표본 기준). 절반 가까이가 결함 페이지면, 조리가 제쳐 둔 페이지도 둘 중 하나는 결함이라 결국 거의 전부를 다시 봐야 합니다. 그래서 우리는 비공개 위키에서 새 페이지 중 무엇을 검수할지 고르는 일을 그만두고, 새로 들어오는 소스 페이지를 전부 데스크에 넘기기로 했습니다. 나중에 새로 쓴 15페이지를 따로 봤더니 9페이지에 critical이나 high 결함이 있었습니다. 이 판단이 맞았다는 뜻입니다. 같은 15페이지에서 Jev의 순위는 결함의 심각도와 상관이 없었습니다(순위상관 +0.05, n=15).

그렇다고 Jev를 버린 건 아닙니다. 비공개 위키에는 이 규칙이 생기기 전에 발행한 페이지가 약 2,400개 쌓여 있고, 이걸 한꺼번에 다시 검수할 수는 없습니다. 그래서 이 묵은 페이지들을 어떤 순서로 다시 읽을지는 Jev 순위로 정합니다. 이 일에서는 제 몫을 합니다. 확인한 표본에서 Jev가 짚은 페이지의 약 94%가 결함 페이지였습니다. 다만 짚지 않은 페이지도 약 67%가 결함 페이지였습니다. 묵은 쌀 가운데 어느 쪽부터 고를지 알려 줄 뿐, 나머지에 돌이 없다고 말해 주지는 않습니다.

이 이야기는 외부에서 검증할 수 없습니다. 비공개 위키이고, 우리가 직접 잰 결과를 우리가 보고하는 것입니다. 누구나 확인할 수 있는 공개 위키에서 실험을 다시 한 이유가 바로 이겁니다.

스스로를 속이지 않도록 설계하기

공개 위키에는 소스가 4개뿐이어서 34개로 늘렸습니다. 소스 후보는 리포터(Reporter) 에이전트가 찾았고, 주제는 AI에서 ‘오픈소스’가 무엇을 뜻하느냐를 둘러싼 논쟁입니다. 그리고 평소라면 건너뛰고 싶었을 다섯 가지를 했습니다.

검수를 일부러 멈췄습니다. 새 소스 페이지가 기준을 넘으면 원래 데스크 검수가 돌아갑니다. 34페이지 전부에서 이걸 껐습니다. 리포터가 쓴 상태 그대로를 모집단으로 삼기 위해서입니다. 인물·개념 같은 다른 페이지는 평소대로 검수를 받았습니다.

규칙부터 적었습니다. 페이지에 라벨을 하나라도 붙이거나 점수를 매기기 전에 사전등록 문서를 파일로 남겼습니다. 이 문서에는 주 평가지표를 적었습니다. critical이나 high 결함이 하나라도 있으면 결함 페이지입니다. 비교 대상과 결정 규칙도 미리 정했습니다. 결함 페이지가 12개 이상이고 Jev AUC의 95% 신뢰구간 하한이 0.5를 넘으면 신호가 있다고 보고합니다. 아니면 소스를 25개쯤 더 넣고 다시 잽니다. 이 파일은 이 글과 함께 공개하기 전까지 git 밖에 있었습니다. 그래서 작성 순서는 우리 말을 믿어 주셔야 합니다.

페이지마다 두 번씩 블라인드로 라벨을 붙였습니다. 여기서 라벨러는 사람이 아니라 데스크 검수 절차를 따르는 AI 에이전트입니다. 서로 다른 데스크 에이전트 둘(라벨러 A·B)이 각 페이지를 원문과 대조해 검수했습니다. 한 번 호출에 4페이지씩(1차 마지막 호출만 2페이지), 매번 같은 프롬프트로 맡겼습니다. A와 B가 4페이지씩 묶어 받은 조합은 서로 달랐습니다. 주 평가지표에서 두 판정이 갈리면 세 번째 라벨러가 정했습니다. 라벨러에게는 Jev도, 실험 자체도, 우리가 이미 알던 문제도 알리지 않았습니다. 그런 정보가 들어 있는 작업 로그와 git 이력, tools 폴더는 읽지 말라고도 했습니다.

질문 문안을 라벨러 눈에서 치웠습니다. Jev에게 던진 세 질문은 통과 조건 형태로 적혀 있습니다. 이게 데스크가 읽는 파일에 들어 있었다면, 라벨러는 Jev가 묻는 바로 그것만 찾게 됐을 겁니다. 그래서 라벨링이 끝날 때까지 별도 폴더에 두었습니다.

점수는 맨 마지막에 매겼습니다. 라벨이 전부 모이기 전까지 Jev에게는 아무것도 보내지 않았습니다. 1차에서는 요청 90건, 입력 약 49만 토큰이었고, 페이지와 질문마다 한 번씩만 물었습니다. 라벨 파일에는 타임스탬프가 없어서 이 순서도 우리 말을 믿어 주셔야 합니다. 외부에서 확인할 수 있는 시각은 Jev 점수 파일의 타임스탬프뿐입니다.

AI 라벨러는 일관성이 있고 모든 페이지에 돌릴 만큼 싸지만, 사람이 확인한 정답은 아닙니다. 비공개 위키의 측정도 같은 방식이었습니다. 그 한계는 아래에서 다시 짚습니다.

1차 측정: 그럴듯한 숫자, 그리고 함정

아래에서 AUC가 0.5를 넘으면 그 신호가 결함 페이지 쪽을 제대로 가리킨다는 뜻입니다. 순위는 결함이 가장 의심스러운 페이지부터 셉니다.

34페이지 중 결함 페이지는 6개였습니다. 이 시점에서 이미 ‘12개 이상’ 조건을 채우지 못했습니다. Jev의 AUC는 0.685였지만 신뢰구간 하한은 0.38까지 내려갔습니다. 기존 선별 기준의 AUC는 0.345, 페이지 길이의 AUC는 0.25였습니다. 둘 다 방향이 거꾸로였다는 뜻입니다. 짧은 페이지가 오히려 결함 페이지였습니다.

이 마지막 숫자 때문에 결함 페이지가 어떤 페이지인지 들여다봤습니다. 6개 중 3개가 처음부터 있던 4페이지에 속했습니다. 몇 달 전 예전 버전 파이프라인으로 쓴 페이지였고, 셋 다 짧았습니다. Jev는 이 셋을 1위, 4위, 6위에 올려 두었습니다. 확장으로 들어온 30페이지만 떼어 보면 AUC는 0.43이었습니다.

이 분석은 사전등록에 없었습니다. 데이터를 본 뒤에 한 사후 탐색이라 결론으로 쓰지 않고 가설로만 남겼습니다. Jev가 ‘틀린 페이지’가 아니라 ‘오래되고 얇은 페이지’를 잡고 있는 것 아니냐는 가설입니다. 같은 시기에 같은 방식으로 쓴 페이지 묶음(코호트)의 차이를 우리가 결함 신호로 잘못 읽었을 수 있다는 뜻입니다.

2차 측정: 방금 세운 가설을 검증하기

규칙대로 확장했습니다. 다만 새 소스를 하나라도 고르기 전에 사전등록 문서에 수정안을 먼저 붙였습니다. 주 분석은 현재 파이프라인이 쓴 페이지만 대상으로 하고, 초기 4페이지는 따로 보고합니다. 1차가 이 방향을 암시했으니 미리 문서로 적어 둔 겁니다. 2차 결과를 본 다음에 정했다면 답을 골라잡은 셈이 됩니다. 길이별로 나눈 분석도 추가했습니다. 페이지 길이나 코호트가 결함 신호인 척하지 못하게 하려는 장치입니다.

새 소스는 주제와 유형만 보고 골랐습니다. 여러 당사자를 인용하는 보도를 우선했는데, 그런 소스에서 발화자가 잘 뒤바뀌기 때문입니다. 리포터에게는 왜 이런 소스를 고르는지 알리지 않았습니다. 1차 채점은 9월 27일 17시 26분(한국 시각)에 끝났고, 새 소스는 9분 뒤인 17시 35분에 수집됐습니다. 수정안은 그 9분 사이에 썼는데, 이것도 사전등록과 마찬가지로 우리 말을 믿어 주셔야 합니다. 타임스탬프로 확인할 수 있는 건, 소스를 고를 때 새 소스가 아직 수집 전이라 참고할 점수가 아예 없었다는 사실입니다.

소스 32개를 더 넣고, 인물·개념 페이지 6개를 새로 쓰고 검수했습니다. 새 인물·개념 페이지는 새 소스 페이지에서만 링크했습니다. 이미 라벨을 붙인 34페이지를 건드리지 않기 위해서입니다. 이 34페이지의 해시는 매 단계 전후로 대조했고, 한 번도 바뀌지 않았습니다. 그다음 새 32페이지에도 똑같은 A·B 블라인드 라벨링을 돌리고, 판정이 갈린 두 페이지는 세 번째 라벨러에게 맡긴 뒤 점수를 매겼습니다(요청 84건, 입력 약 38만 토큰).

모집단 페이지 결함 페이지 Jev AUC 95% 신뢰구간 선별 기준 AUC 길이 AUC
현재 파이프라인(주 분석) 62 4 0.491 0.20~0.79 0.547 0.358
전체 66 7 0.692 0.41~0.92 0.392 0.215
초기 4페이지 4 3 1.000 — 0.500 0.667

신뢰구간 하한은 사전등록대로 두 방법(Hanley–McNeil, 2,000회 부트스트랩) 중 작은 값이고, 상한은 Hanley–McNeil 값입니다. 스크립트는 둘 다 출력합니다. 초기 4페이지 행은 표본이 4개뿐이라 참고용입니다.

페이지 길이로 층을 나눠 봐도 Jev는 살아나지 않았습니다(길이 3분위로 층화한 AUC 0.556). 현재 파이프라인의 결함 페이지 4개는 62개 중 14위, 16위, 41위, 57위였습니다. ‘점수가 가장 낮은 10개부터 다시 읽기’ 같은 대기열을 만들었다면 하나도 걸리지 않았을 겁니다. 새 페이지 32개를 더한 뒤에도 가설은 맞았습니다. 1차의 신호는 옛 코호트에서 왔고, 옛 코호트를 떼어 내면 사라집니다. 다만 새 증거가 얼마나 되는지는 솔직히 밝혀 둡니다. 결함 페이지 4개 중 새 페이지에서 나온 건 1개뿐이고, 나머지 3개는 1차 때 이미 본 페이지였습니다.

결정 규칙대로라면 한 번 더 확장해야 했습니다. 하지만 하지 않았습니다. 결함 비율이 6.5%면 결함 페이지 12개를 모으는 데 약 185페이지가 필요하고, 소스 25개를 더 넣어서는 답이 바뀌지 않습니다.

이 쌀에는 왜 큰 돌이 이렇게 적을까

‘결함 페이지 6.5%’라고 하면 파이프라인이 좋다는 소식처럼 들리고, 어느 정도는 맞습니다. 라벨을 전부 세어 보면 결함이 실제로 어디에 몰려 있는지 보입니다.

  결함 보고 수(critical / high / medium / low) 결함이 하나라도 있는 페이지 medium 이상 결함이 있는 페이지
1차 34페이지 1 / 21 / 88 / 284 34/34 32/34
2차 32페이지 0 / 2 / 66 / 262 32/32 25/32

라벨러 A·B의 보고를 더한 값이라, 두 라벨러가 모두 찾은 결함은 두 번 셉니다. 세 번째 라벨러의 보고는 넣지 않았습니다.

결함 없는 페이지는 하나도 없습니다. 대부분에 medium 결함이 있습니다. 단서 조항이 약해지거나, 기자의 서술을 발화자의 말로 옮기거나, 본문이 뒷받침하지 않는 연결(Connections) 항목이 페이지 끝에 붙어 있는 식입니다. 드문 건 읽는 사람이 틀린 사실을 믿게 만드는 종류의 결함입니다. 비공개 위키에는 이런 결함이 많은데 공개 위키에는 왜 적을까요? 후보 설명 셋을 근거가 강한 순서로 적고, 주의할 점을 하나 덧붙입니다.

  1. 파이프라인이 나아졌습니다. 공개 위키 안에 직접 증거가 있습니다. 예전 파이프라인이 쓴 4페이지에서는 결함 페이지가 3개였고, 현재 파이프라인이 쓴 62페이지에서는 4개였습니다. 우리는 비공개 위키에서 최악의 결함 유형 대부분을 겪으며 규칙을 만들었고, 그 규칙을 나중에 공개 위키로 옮겼습니다. 반면 비공개 위키 페이지 대부분은 그 규칙이 생기기 전에 쓰였습니다.
  2. 언어가 다릅니다. 비공개 위키에서 가장 심각했던 결함 유형은 ‘알려졌다’ 같은 전언 표현이 단정문으로 바뀌는 경우, 칼럼 필자의 의견이 기관 발표로 둔갑하는 경우, 옮겨 적다가 숫자를 잘못 적는 경우였습니다. 한국어 페이지는 원문이 영어면 번역을 한 번 거치고, 원문이 한국어여도 이런 전언 표현은 요약 과정에서 쉽게 떨어져 나갑니다. 공개 위키는 영어 원문을 영어 페이지로 씁니다. 측정한 건 아니고 가설입니다.
  3. 소스 성격이 다릅니다. 비공개 위키는 보도자료를 바탕으로 한 기술 뉴스가 대부분이라 수치가 많고, 수치가 틀리면 곧바로 critical입니다. 공개 위키는 리포터가 고른 분석·논평·보도라 수치가 적고, 결함도 뉘앙스 쪽으로 몰립니다.

주의할 점도 하나 있습니다. 심각도 경계가 흔들립니다. 두 차례 측정에서 A와 B의 판정이 갈린 페이지는 5개였고, 다섯 모두 두 라벨러가 같은 결함을 짚고 심각도만 달리 본 경우였습니다. 세 번은 high와 medium, 두 번은 high와 low로 갈렸습니다. 심각도 판단 하나에 뒤집히는 지표는 잡음이 커서, 6.5%라는 숫자 자체도 단단하지 않습니다.

여기서 배운 것

앞에서 조리질의 전제로 말한 그대로입니다. 결함이 아주 흔하면 선별 도구가 제쳐 둔 페이지도 결함일 가능성이 커서 검수를 덜어 주지 못하고, 결함이 드물면 도구가 제대로 듣는지 확인하는 데만도 큰 표본이 필요합니다. 이번 같은 작은 실험으로는 결론을 낼 힘이 모자랍니다. 우리는 “Jev가 페이지 순위를 잘 매기나?”라는 질문으로 시작했는데, 첫 질문이 틀렸습니다. 먼저 물어야 할 건 쌀에 돌이 얼마나 섞였느냐이고, 이건 표본에 직접 라벨을 붙여야만 답할 수 있습니다. 이번에는 블라인드 검수 137회가 들었습니다.

두 위키에서 같은 실험을 해 보니 양쪽 끝을 다 만났습니다.

그래서 바꾸는 내용은 별것 없습니다. 비공개 위키가 새 소스 페이지를 전부 검수하듯, 공개 위키도 모든 소스 페이지에 데스크 검수를 돌립니다. 실험 때문에 미뤄 둔 검수부터 합니다. 공개 위키에는 묵은 페이지가 순서를 정해야 할 만큼 쌓여 있지 않습니다. Jev를 호출하는 채점 도구는 커밋하지 않은 로컬 폴더에 그대로 둡니다.

이 결과를 두고 Jev가 나쁜 모델이라고 보지는 않습니다. 비공개 위키에서는 Jev의 순위가 지금까지 잰 신호 가운데 가장 좋았고, 지금도 묵은 페이지의 순서를 정하는 데 씁니다. 선별 도구는 결함이 흔하지도 드물지도 않아 골라낼 것이 있는 곳에서만 붙일 가치가 있습니다. 그곳이 어딘지는 기저율을 재 봐야 압니다.

한계

직접 확인하기

실험 폴더에는 다음이 들어 있습니다.

python docs/experiments/judge-model-2026-09/analyze.py 1        # 1차 측정
python docs/experiments/judge-model-2026-09/analyze.py 2        # 2차 측정
python docs/experiments/judge-model-2026-09/analyze.py labels   # 심각도 표, 검수 횟수, 요청 수

네트워크 호출도, API 키도 필요 없습니다. 스크립트가 읽는 건 그 폴더뿐입니다. 이제 페이지를 고치기 시작하므로, 각 페이지가 선별 기준을 넘었는지와 페이지 길이를 동결 시점에 스냅샷으로 따로 저장해 두었습니다. 라벨링 당시 페이지를 그대로 보고 싶다면 이 폴더를 추가한 커밋을 체크아웃하면 되고, 해시는 동결 파일에 있습니다. 다른 숫자가 나오면 이슈로 알려 주세요.