한 줄만 틀려도 버린다 — 뉴스 4만 7천 묶음을 읽힐 LLM, 7종 12가지 설정을 같은 검증기로 재다

들어가며: 4만 7천 묶음을 누구에게 맡길까

크게 보기

코어닷투데이 사실탐색기는 기록에서 "지금 참인 값"을 근거와 함께 답하거나, 근거가 모자라면 답하지 않는 엔진입니다(설계편). 이번에는 공적 기록 대신 뉴스를 넣으려고 합니다. 2026년 11월 초 기사들을 같은 사건끼리 묶었더니 이야기 4만 7,300개가 나왔습니다. 이 가운데 3만 5,652개(75%)는 기사 한 건짜리이고, 7,084개는 기사 세 건 이상이 같은 사건을 다룹니다.

엔진에 넣으려면 묶음마다 세 가지를 뽑아야 합니다. 누가 무엇을 했다고 누가 말했는지(주장), 그 일이 언제였는지(시점), 그리고 서로 다른 기사의 주장이 같은 사건을 가리키는지입니다. 모든 행에는 원문 구절이 글자 그대로 붙어야 합니다. 나중에 엔진이 "이 값은 어느 기사의 어느 문장에서 왔나"를 되짚을 수 있어야 하기 때문입니다.

사람이 손으로 할 수 있는 양이 아니라 LLM에 맡깁니다. 문제는 어느 LLM이냐입니다. 앞서 검수용 판본 24개는 Claude Code(Opus 5.5)로 만들었습니다. 같은 방식으로 4만 7천 개를 돌리기에는 비싸고 느립니다. 그래서 후보를 넓혔습니다. 코어닷투데이 게이트웨이의 싼 모델 둘, 무료라는 국산 API 하나, 같은 Claude의 작은 모델들, 그리고 사내 A100 GPU에 직접 올린 공개 모델까지. 숫자부터 보겠습니다.

기사 3건씩 묶인 이야기 7개, 기준 답의 주장 412개로 잰 코어닷투데이 실측(2026-11-09~10).

순서는 이렇습니다.

1. 무엇을 시키는가: 세 단계 추출.
2. 어떻게 채점하나: 검증기와 기준 답.
3. 후보 7종, 12가지 설정.
4. 결과 한눈에.
5. 통과율이 먼저다: 전부 아니면 전무.
6. 지시문 한 줄이 회수율을 두 배로.
7. 생각 모드는 공짜가 아니다.
8. ‘무료’와 ‘할인’의 조건.
9. 우리 GPU로 돌리면.
10. 주장 하나당 비용, 그리고 4만 7천 개 계산.
11. 그래서 무엇을 고르나.
12. 이 결과를 어디까지 믿을 수 있나.

1. 무엇을 시키는가: 세 단계 추출

모델은 기사 묶음(문서마다 문단 ID가 붙은 JSON)과 7천 자 분량의 지시문을 받고, JSON 객체 하나를 돌려줍니다. 안에는 세 단계의 결과가 들어갑니다.

시험한 이야기 7개는 주제와 길이를 고르게 골랐습니다. 열차 고장(938자)부터 시의 주택 공급 계획(8,242자)까지이고, 모두 기사 세 건으로 묶여 있습니다. 기준 답의 주장은 26개에서 99개입니다.

2. 어떻게 채점하나: 검증기와 기준 답

크게 보기

채점은 두 겹입니다.

첫째 관문은 결정론 검증기입니다. 사실탐색기가 판본을 적재하기 전에 실제로 돌리는 것과 같은 코드입니다. JSON 스키마를 지키는지, 모든 quote가 해당 문단에 글자 그대로 있는지, 시간 표현이 그 quote 안에 있는지, 시간 규칙(예정된 일에 발생 시점을 붙이지 않는다, explicit에는 기준일을 붙이지 않는다, relative에는 기준일이 있어야 한다 등)을 지키는지, 같은 사건 묶음이 서로 모순되지 않는지를 봅니다. 행 하나라도 어기면 이야기 전체를 거부합니다. 거부되면 오류 메시지를 그대로 모델에게 보여 주고 한 번 더 고쳐 쓰게 했습니다. 두 번째에도 거부되면 그 이야기는 판본에 들어갈 수 없습니다.

둘째는 기준 답과의 비교입니다. 기준 답은 검수용 판본을 만들 때 Claude Code(Opus 5.5)가 같은 지시문으로 추출해 검증기를 통과시킨 결과입니다. 사람이 한 줄씩 고친 정답은 아닙니다. 이 점은 12절에서 다시 다룹니다. 후보의 주장과 기준 주장은 원문 구절의 위치로 짝지었습니다. 같은 문단에서 두 구절이 30% 이상 겹치면 같은 주장으로 봅니다. 그 위에서 다섯 가지를 셌습니다.

3. 후보 7종, 12가지 설정

처음에는 Haiku 5.5 서브에이전트에게만 "꼼꼼하게, 빠짐없이, 인용은 글자 그대로"라는 문장을 더 줬다는 것을 나중에 알았습니다. 공정하지 않으니 같은 문장을 모든 모델에 넣고 다시 돌렸고, 두 결과를 다 남겼습니다. 이 실수가 이 글에서 가장 큰 발견(6절)으로 이어졌습니다.

4. 결과 한눈에

* Haiku 5.5의 시간은 Claude Code 서브에이전트가 파일을 읽고 쓰는 시간까지 포함한 값이라 API 응답 시간과 비교할 수 없습니다. ‘꼼꼼’은 6절의 한 줄을 더한 지시문입니다. 비용은 재시도를 포함한 실측이고, 게이트웨이 크레딧을 목록가 기준(1,858크레딧 = $1)으로 바꿨습니다.

표에서 먼저 볼 것은 세 가지입니다.

• 틀린 것을 지어내는 모델은 거의 없었습니다. 후보가 뽑은 주장 가운데 기준 답과 짝지어진 비율은 모든 모델이 88~99%였습니다. 차이는 정확도가 아니라 얼마나 많이, 끝까지 뽑느냐에서 났습니다.
• 통과분 회수율과 주장 회수율 사이가 벌어집니다. DeepSeek·EXAONE·Qwen은 통과만 하면 72~88%를 회수합니다. 그런데 판본에 남는 양은 14~29%입니다. 짧은 이야기만 통과하고 긴 이야기를 잃었기 때문입니다. 위젯의 ‘이야기별 결과’에서 빨간 칸이 오른쪽(긴 이야기)에 몰려 있는 것을 볼 수 있습니다.
• 한 세대 차이가 결정적이었습니다. Haiku 4.5는 7개를 모두 거부당했고, 14번의 시도 가운데 12번이 인용 문제였습니다. 원문을 복사하지 않고 자기 말로 바꿔 썼습니다. 같은 지시문에서 Haiku 5.5는 이 실수를 하지 않았습니다.

5. 통과율이 먼저다: 전부 아니면 전무

Claude 5.5를 뺀 9개 설정이 두 번째 시도까지 거부된 38건의 이유를 모아 보면 이렇습니다.

Haiku 4.5, DeepSeek 두 설정, Muse 두 설정, EXAONE, Qwen 세 설정. 인용 불일치 14건 가운데 6건이 Haiku 4.5. 시간 규칙 16건의 내역은 ‘예정된 일에 발생 시점’ 6건, ‘쓸데없는 기준일’ 4건, ‘기준일 누락’ 4건, ‘시간 표현이 인용 밖’ 2건.

한 이야기에는 주장·시간·비교 쌍이 59행에서 165행까지 있습니다. 그 가운데 한 행이 "예정된 일에 발생 시점을 붙였다"면 나머지 164행이 아무리 좋아도 그 이야기는 판본에 들어가지 못합니다. 행 하나가 틀릴 확률을 1%로 잡으면, 59행짜리 이야기는 55%가 통과하지만 165행짜리는 19%만 통과합니다. 모델 실력이 같아도 이야기가 길수록 통과율은 기하급수로 떨어집니다.

실측도 이 모양을 따랐습니다. Claude를 뺀 8개 설정은 짧은 ‘열차 고장’과 ‘AI 데이터센터 착공’을 8개 중 7개씩 통과했고, 가장 긴 두 이야기는 8개 중 1개씩만 통과했습니다. 그 1개 중 하나는 99개 주장 가운데 3개만 뽑은 Muse였습니다.

여기서 얻는 교훈은 두 갈래입니다.

모델을 고를 때는 긴 입력으로 시험해야 합니다. 짧은 예제 몇 개로 재면 거의 모든 모델이 그럴듯해 보입니다. 이번에도 가장 짧은 이야기만 봤다면 12개 설정 중 10개가 통과했습니다.

검증 방식이 모델 선택을 좌우합니다. 행 하나 때문에 이야기째 버리는 대신 틀린 행만 버리면, 위젯의 ‘틀린 행만 버리기’처럼 싼 모델도 대부분의 행을 살릴 수 있습니다. 재시도 효과도 컸습니다. 오류 메시지를 보여 주고 한 번 더 시키자 Muse(꼼꼼)는 0개에서 4개로, Qwen FP8은 2개에서 4개로, DeepSeek(기본)은 1개에서 3개로 통과가 늘었습니다. 대신 행을 버리면 남은 행끼리의 참조를 다시 맞춰야 하고, 무엇을 버렸는지 기록해야 합니다. 사실탐색기는 근거의 사슬이 끊기지 않는 것을 가장 중요하게 여기기 때문에 지금은 이야기째 거부를 유지합니다. 모델이 그 기준을 맞추게 하는 쪽을 택했습니다.

6. 지시문 한 줄이 회수율을 두 배로

크게 보기

3절에서 말한 공정성 실수를 바로잡으려고 모든 모델의 지시문 끝에 이 한 줄을 더했습니다.

결과는 모델마다 정반대였습니다.

Sonnet 5.5는 원래 실수를 거의 하지 않는 대신 아꼈습니다. 가장 긴 이야기(기준 주장 99개)에서 기본 지시문으로는 주장 5개만 뽑았습니다. 기사 세 건 분량의 진술을 요약하듯 대표 몇 개만 남긴 것입니다. 한 줄을 더하자 같은 이야기에서 35개, 전체로는 두 배를 뽑았고, 통과율은 그대로였습니다.

DeepSeek은 반대였습니다. 더 많이 쓰라고 하자 행이 늘었고, 5절의 산수대로 행이 늘수록 하나쯤 틀릴 확률도 커졌습니다. 실수가 적은 모델에게는 ‘더 많이’가 득이고, 실수가 잦은 모델에게는 독입니다.

두 가지를 기억할 만합니다. 하나, 모델을 바꾸기 전에 지시문의 한 줄부터 바꿔 보세요. Sonnet에서는 그 한 줄이 비용 1.8배로 회수율을 두 배로 만들었습니다. 둘, 지시문을 바꿨으면 모든 후보에 같이 바꿔서 다시 재야 합니다. 한 모델에게만 유리한 문장이 섞여 있으면 비교 전체가 기울어집니다. 이번 지시문도 원래 Claude로 다듬은 것이라 이 위험에서 자유롭지 않습니다(12절).

7. 생각 모드는 공짜가 아니다

크게 보기

요즘 모델은 답하기 전에 ‘생각’을 길게 쓰는 모드가 있습니다. 어려운 추론에는 도움이 되지만, 긴 구조화 출력에서는 세 모델 모두에서 문제가 됐습니다.

• DeepSeek Flash는 생각 모드가 기본으로 켜져 있습니다. 켠 채로 돌리자 생각에만 3만 토큰을 쓰다 출력 한도에 걸려 JSON이 중간에 잘렸습니다. 그래서 위 결과는 모두 생각을 끈 설정입니다.
• Qwen3.8-27B는 생각을 켜면(low) 통과한 두 이야기의 품질은 가장 좋았습니다(통과분 회수율 81%, 같은 사건 묶기 0.57). 그러나 큰 이야기 세 개에서는 출력 토큰을 생각에 다 써서 답이 비어 있었습니다. 생각의 양을 줄이라는 설정(reasoning_effort low)도 거의 듣지 않았습니다.
• EXAONE 2.5는 생각 모드를 끌 수 없습니다. 이야기 하나에 평균 11분이 걸렸고, 긴 이야기 둘은 서버 쪽 10분 제한에 걸려 끝내 응답을 받지 못했습니다.

구조화 추출에서 출력 한도는 답과 생각이 나눠 쓰는 예산입니다. 생각이 길어질수록 답에 남는 몫이 줄고, 답이 길어야 하는 일일수록 먼저 잘립니다. 생각 모드를 켤지 말지도 지시문처럼 실제 길이의 입력으로 재 보고 정해야 합니다. 참고로 Claude 5.5 세대는 생각을 스스로 조절하는 방식(adaptive)이고, 이번 Sonnet 실험에서 출력이 잘린 경우는 없었습니다.

8. ‘무료’와 ‘할인’의 조건

크게 보기

가장 싼 두 후보에는 가격표에 없는 조건이 있었습니다.

K-EXAONE 2.5 API는 무료입니다. 그러나 문서에 비상업적 이용 조건이 있고, 요청은 초당 1회·분당 60회로 제한됩니다. 실제로 이야기 일곱 개를 동시에 보내자 연결이 끊기거나 10분 뒤 서버 오류가 났습니다. 하나씩 보내면 이야기당 평균 647초가 걸립니다. 4만 7,300개를 이렇게 돌리면 약 354일입니다. 상업 서비스에 쓰려면 성능과 별개로 이용 조건부터 따로 확인해야 합니다.

Muse Spark 1.3 Contributor는 일반 등급보다 훨씬 쌉니다. 대신 보낸 프롬프트와 응답이 Meta의 모델 학습에 쓰일 수 있다는 것이 할인의 조건이고, 학습에 넘겨도 되는 데이터만 보내라고 안내합니다. 우리 입력은 언론사에 저작권이 있는 뉴스 기사입니다. 이것을 제3자의 학습 데이터로 넘길 권리가 우리에게 있는지는 법적 판단이 먼저 필요합니다. 게다가 이 등급은 모든 사용자가 분당 100회 요청을 나눠 쓰는 상한이 있어, 대량 작업에서는 요청 한도 오류를 각오해야 합니다.

교훈은 단순합니다. 단가를 비교하기 전에 약관의 세 줄을 읽으세요. 상업적 이용이 되는가, 내 입력이 어디에 쓰이는가, 대량으로 보낼 수 있는가.

9. 우리 GPU로 돌리면

크게 보기

API 비용이 0인 길도 있습니다. 사내 쿠버네티스 클러스터의 A100 두 장에 공개 모델 Qwen3.8-27B를 올렸습니다. 80GB짜리에는 원본(BF16)을, 40GB짜리에는 8비트로 줄인 FP8판을 올렸고, 서빙은 vLLM 0.32(다음 토큰 몇 개를 미리 추측하는 MTP 디코딩 포함)로 했습니다. 클러스터가 GPU를 쪼개 쓰는 방식(MIG)이라 파드가 GPU를 요청하면 조각이 자동으로 만들어지고, 끝나면 회수됩니다.

결과는 6절의 DeepSeek과 거의 같은 모양이었습니다. 통과한 이야기에서는 72~74%를 회수해 품질이 나쁘지 않았지만, 시간 규칙(쓸데없는 기준일)과 인용 불일치로 긴 이야기를 잃었습니다. 8비트로 줄여도 품질은 떨어지지 않았습니다(BF16 3/7, FP8 4/7로 오차 범위).

문제는 속도입니다. 이야기 7개를 동시에 보냈을 때 A100 80GB는 초당 약 204토큰, 40GB는 약 106토큰을 냈습니다. 40GB는 모델을 올리고 나면 캐시 자리가 6만 4천 토큰뿐이라, 긴 요청을 한두 개씩만 동시에 처리합니다. 이야기 하나에 재시도까지 약 2만 토큰을 쓰므로, 4만 7,300개를 돌리면 80GB 한 장으로 약 56일, 두 장을 함께 써도 5주쯤 걸립니다. 그리고 절반 넘게는 거부되어 결국 다른 모델로 다시 돌려야 합니다.

자체 서빙이 의미 없다는 뜻은 아닙니다. 데이터를 밖으로 내보낼 수 없는 곳, 비용을 정말 0으로 맞춰야 하는 소량 재처리, 그리고 이번 결과를 보고 고친 지시문을 반복해서 시험하는 실험대로는 좋습니다. 다만 GPU의 비용은 돈이 아니라 시간으로 청구된다는 것을 계산에 넣어야 합니다.

10. 주장 하나당 비용, 그리고 4만 7천 개 계산

토큰 단가로 줄을 세우면 Muse가 가장 싸고 Sonnet이 가장 비쌉니다. 하지만 우리가 사는 것은 토큰이 아니라 판본에 들어간 주장입니다. 이야기당 비용을 회수한 주장 수로 나누면 순서가 바뀝니다.

이야기당 실측 비용 ÷ (이야기당 기준 주장 58.9개 × 주장 회수율). Haiku 5.5는 게이트웨이에 없어 API 비용을 재지 못했습니다. 목록가($0.10/$0.50, 배치 50% 할인)에 입력 1만·출력 2.5만 토큰을 가정한 추정입니다.

Haiku 5.5의 추정이 맞는다면, 이 일에서는 가장 최신의 작은 모델이 가장 싼 모델보다도 싸게 먹힙니다. 단가가 Muse Contributor와 비슷한 수준인데 회수율이 네 배이고, 거부된 이야기를 다시 돌릴 일도 없기 때문입니다. 아래 계산기에서 조합을 바꿔 보세요. 싼 모델로 먼저 돌리고 거부된 것만 비싼 모델로 재처리하는 흔한 전략도 넣었습니다.

계산기를 만져 보면 재처리 전략의 한계가 드러납니다. 재처리는 거부된 이야기만 고칩니다. Muse(기본)처럼 99개 중 3개만 뽑고도 통과한 이야기는 그대로 판본에 들어갑니다. 싼 모델의 약점이 ‘틀린다’가 아니라 ‘덜 뽑는다’일 때, 검증기는 그것을 잡지 못합니다. 통과율과 회수율을 따로 재야 하는 이유입니다.

11. 그래서 무엇을 고르나

사실탐색기 쪽 결론은 이렇습니다.

그리고 모델과 상관없이 지시문에 두 가지를 반영합니다. ‘꼼꼼’ 한 줄은 그대로 넣고, Haiku 5.5가 가장 약했던 장소(기준 답이 장소를 적은 주장 중 32%만 적음)를 따로 강조합니다.

12. 이 결과를 어디까지 믿을 수 있나

• 이야기가 7개뿐입니다. 7개 중 3개 통과의 95% 신뢰구간은 16~75%입니다. 7/7과 0~1/7처럼 큰 차이만 믿을 수 있고, 3/7과 4/7의 차이는 의미가 없습니다. 위젯의 ‘검증 통과’ 보기에 구간을 함께 그렸습니다.
• 기준 답을 Claude가 만들었습니다. Opus 5.5의 추출을 기준으로 삼았으니, 같은 계열 모델이 같은 단위로 주장을 쪼갤 가능성이 큽니다. 다른 모델이 기준 답과 다르게 쪼갰지만 옳은 주장을 뽑았다면 회수율에서 손해를 봤을 수 있습니다. 다만 통과율 차이는 결정론 검증기에서 나온 것이라 이 편향과 무관합니다.
• 지시문도 Claude로 다듬었습니다. 7천 자 지시문은 Claude로 판본을 만들며 고쳐 온 것입니다. 다른 모델에 맞춰 고치면 그 모델의 점수가 오를 수 있습니다. 6절처럼 한 줄이 회수율을 두 배로 바꾸는 것을 보면 이 몫은 작지 않을 것입니다.
• Haiku 5.5는 다른 환경에서 쟀습니다. API가 아니라 Claude Code 서브에이전트로 돌렸고, 한 에이전트는 자기 출력 파일을 여러 번 고쳐 썼습니다. 사실상 시도를 더 한 셈입니다. API 시험 추출로 다시 확인하기 전까지 Haiku 5.5의 숫자는 상한으로 읽어야 합니다.
• 구조 강제 방식이 모델마다 다릅니다. Claude는 JSON 스키마를 강제했지만 DeepSeek은 게이트웨이에서 스키마 강제를 지원하지 않아 JSON 객체 모드로만 돌렸습니다. 각 설정은 한 번씩만 돌렸습니다.
• 기사 3건 묶음만 쟀습니다. 전체의 75%인 기사 한 건짜리 이야기는 더 짧고 문서 간 비교도 없으므로, 싼 모델의 통과율은 여기서보다 높을 것입니다. 이야기 크기에 따라 모델을 나눠 쓰는 것도 다음 실험 후보입니다.

맺으며

열두 가지 설정을 재고 나니 "어떤 모델이 가장 똑똑한가"는 반쯤만 맞는 질문이었습니다. 통과만 하면 대부분의 모델이 쓸 만한 주장을 뽑았습니다. 갈린 곳은 세 군데였습니다. 긴 입력에서 165행을 한 줄도 틀리지 않고 쓸 수 있는가. 시키지 않으면 아끼는가. 생각에 예산을 다 써 버리는가.

그래서 이 실험에서 얻은 교훈은 모델 이름보다 재는 방법에 가깝습니다. 실제 길이의 입력으로 잴 것, 통과율과 회수율을 따로 볼 것, 지시문을 바꾸면 모든 후보를 다시 잴 것, 토큰 단가가 아니라 쓸 수 있는 결과 하나당 비용으로 비교할 것, 그리고 가격표 밑의 약관을 읽을 것. 다음 글에서는 Haiku 5.5 배치 API로 200개를 먼저 돌린 결과와, 그 판본을 실제로 넣은 사실탐색기를 다룹니다.

출처

• 코어닷투데이 실측(2026-11-09~10): 2026년 11월 초 뉴스를 같은 사건끼리 묶은 이야기 4만 7,300개 중 기사 3건 묶음 7개, 기준 답 주장 412개. 기준 답은 Claude Code(Opus 5.5)로 만든 검수용 판본. 검증기는 사실탐색기 추출 파이프라인의 결정론 검사(스키마·인용 일치·시간 규칙·사건 묶음 일관성).
• 실행 환경: 코어닷투데이 게이트웨이(api.core.today, Anthropic·OpenAI 호환 형식), EXAONE 공식 API, 사내 쿠버네티스 클러스터의 NVIDIA A100 80GB·40GB(MIG 전체 조각)와 vLLM v0.32.0.
• 모델 문서: DeepSeek Flash, Muse Spark 1.3 Contributor, EXAONE API 빠른 시작, Claude 모델 개요, Claude 가격, 메시지 배치 API.
• 관련 글: 사실탐색기 v2 설계편, 최신 기사는 대체로 맞다, 엇갈린 값은 끝내 남는다, 한국어 임베딩 모델 14종, 4B를 Flash로 가르치기, Claimify.