AI 문서요약 정확도 실측: 3문장과 8문장의 차이

AI 문서요약에서 가장 먼저 정할 것은 모델이 아니었습니다. 몇 문장까지 허용할지였습니다.

2026년 9월 22일, 내가 로컬 gemma3:4b와 클라우드 Gemini 3.8 Flash High에 같은 문서들을 넣어 72회 요약했습니다. 채점 기준은 돌리기 전에 먼저 고정해 두었습니다. 완전통과는 로컬이 36번 중 6번, 클라우드가 36번 중 14번이었습니다. 클라우드가 더 많이 통과했지만, 세 문장으로 제한하자 양쪽 모두 12번 중 한 번도 핵심 다섯 항목을 전부 남기지 못했습니다.

핵심을 빠뜨리면 안 되는 문서를 요약하려는 분이라면 선택 기준은 여기서 갈립니다. 짧은 요약이 필요할수록 더 강한 모델만 찾기보다, 먼저 반드시 남길 항목과 최소 문장 수를 정해야 합니다.

내가 세운 기준으로 72회를 다시 훑어봤을 때 원문 밖의 숫자, 원문과 반대되는 주장, 폐기된 수치를 최종 사실처럼 쓴 사례는 양쪽 모두 0건이었습니다. 완전통과하지 못한 응답들은 모두 핵심 슬롯을 하나 이상 빠뜨렸습니다. 일부는 문장 수도 어겼지만, 공통으로 걸린 실패는 누락이었습니다.

자연스러운 세 문장이 핵심 세 덩어리를 지웠습니다

첫 응답부터 그 차이가 드러났습니다. 936자짜리 커피 설명문을 로컬 모델에 주고 세 문장으로 요약하라고 요청했습니다.

응답에는 이런 문장이 들어 있었습니다.

"커피 추출 방식에 따라 같은 원두라도 다양한 맛을 낼 수 있으며, 드립, 에스프레소, 침지식 등이 대표적이다."

이어지는 두 문장도 문법상 자연스러웠습니다. 드립은 깔끔한 맛, 에스프레소는 농축된 맛, 프렌치프레스는 묵직한 맛이라고 정리했고 마지막에는 분쇄도·온도·시간을 조절해야 한다고 썼습니다.

문장 수 역시 정확히 세 개였습니다. 원문에 없는 숫자도 보태지 않았습니다.

그래도 내가 세운 항목표와 대조한 채점 결과는 실패였습니다. 세부 항목을 대조하자 드립의 추출 원리, 에스프레소의 압력 특성, 침지식과 함께 설명된 콜드브루가 빠져 있었습니다. 핵심 슬롯 다섯 개 중 남은 것은 두 개뿐이었습니다.

이 응답을 문장만 읽으면 요약으로 받아들이기 쉽습니다. 커피 추출법이라는 큰 주제를 말했고 대표 방식도 열거했기 때문입니다. 하지만 원문에 있던 콜드브루를 반드시 남겨야 한다면 결과는 쓸 수 없습니다.

자연스러움은 누락 검사가 아닙니다. 요약문이 매끄럽다는 판단과 필요한 항목이 모두 남았다는 판정은 따로 해야 합니다.

72회는 문서 네 종과 문장 조건 세 가지로 나눴습니다

입력은 성격이 다른 자체 작성 문서 네 종이었습니다.

문서	길이	확인하려던 요약 난점
D1 생활 설명문	936자	여러 추출법과 조절 변수를 함께 보존하는가
D2 장애 회고	1,753자	초기 가설과 실제 원인을 뒤바꾸지 않는가
D3 요금·보관 정책	3,243자	요금제별 숫자와 예외 규칙을 함께 남기는가
D4 의사결정 메모	6,519자	폐기 수치를 버리고 최종 결정까지 유지하는가

각 문서를 3문장, 5문장, 8문장으로 요약하게 했고 같은 조건을 세 번씩 반복했습니다. 두 모델의 실행 순서는 한쪽이 늘 먼저 나오지 않도록 회전했습니다. 모든 셀은 앞 대화를 이어받지 않는 독립 단일 요청이었습니다.

로컬은 Ollama의 gemma3:4b를 사용했습니다. temperature=0, seed=14, keep_alive=0으로 실행했고, 같은 문서와 문장 수를 묶은 12개 조건에서 각 세 반복의 출력이 모두 같았습니다.

클라우드는 inferhub의 ag/gemini-3.8-flash-high, 표시명 Gemini 3.8 Flash High를 사용했습니다. 클라우드 결과는 반복마다 달라 각 응답을 독립적으로 채점했습니다. 같은 조건을 세 번 반복해도 36개 응답이 모두 달랐습니다.

초기 실행에서는 agy 구독의 Gemini 3.1 Pro High로 33셀을 완료했습니다. 개인 한도가 소진된 뒤 세 셀을 보완하는 식으로 모델을 섞으면 비교 조건이 달라지므로 그 결과를 최종 집계에 쓰지 않았습니다. 클라우드 36셀 전체를 Gemini 3.8 Flash High로 통일해 다시 실행한 것이 이 글의 결과입니다.

통과 여부는 문장 수와 핵심 보존을 따로 셌습니다

이번 채점은 미리 고정한 네 가지 조건만 확인했습니다.

• 요구한 3·5·8문장 수를 맞췄는가
• 문서마다 정한 핵심 슬롯 다섯 개를 모두 남겼는가
• 원문에 없는 숫자를 추가하지 않았는가
• 원문과 반대되는 주장이나 폐기된 사실을 채택하지 않았는가

장애 회고에는 "네트워크 지연 가설이 기각됐고 실제 원인은 만료된 인증서였다"는 구분이 들어 있습니다. 의사결정 문서에는 폐기된 400건·76.1%와 최종 수치인 480건·74.8%가 함께 나옵니다. 채점기는 앞의 수치를 최종 결과처럼 쓰거나 "배포 보류"를 "교체 결정"으로 뒤집으면 근거 안전 실패로 처리했습니다.

핵심 슬롯도 문서마다 달랐습니다. D3에서는 Basic·Pro·Team의 처리량과 보관 기간, OCR 제공 범위, 삭제 요청과 연간 할인 규칙을 함께 봤습니다. D4에서는 최종 표본, 전체 정확도, 하위집단 B, 지연·비용, 배포 보류와 재평가가 모두 있어야 통과였습니다.

이 기준은 업무상 빠뜨리면 곤란한 사실이 남았는지 확인하는 계약 검사입니다. 문장 수 지시를 지키는 것 자체가 별도의 측정 주제라는 점은 글자수 지시 준수율 실측에서 이미 확인한 바 있습니다.

세 문장에서는 클라우드도 통과하지 못했습니다

문장 수에 따라 결과를 나누면 차이가 크게 벌어집니다.

목표 문장 수	로컬 gemma3:4b	Gemini 3.8 Flash High
3문장	0/12	0/12
5문장	0/12	3/12
8문장	6/12	11/12

세 문장에서는 두 모델 모두 0/12였습니다. 클라우드 모델을 쓰더라도 다섯 핵심 슬롯을 세 문장 안에 전부 넣지 못했습니다.

D3 요금 정책의 첫 3문장 결과가 그 경계를 잘 보여줍니다. 로컬은 요금제가 세 가지라는 점, 매달 한도가 초기화된다는 점, 보관 기간 뒤 자동 삭제된다는 점을 골랐습니다. 그러나 Basic·Pro·Team의 구체적인 문서 수와 보관 기간, OCR 범위, 삭제 요청 기한, 연간 할인 조건은 핵심 슬롯 기준을 충족하지 못했습니다.

클라우드는 더 많은 숫자를 남겼습니다.

"클리어파일은 문서 처리 한도, 파일 크기 제한, 보관 기간, OCR 기능 제공 여부에 따라 Basic(무료), Pro(월 12,900원), Team(사용자당 월 29,900원) 세 가지 요금제로 운영됩니다."

나머지 두 문장에는 7일·30일·90일 보관 기간, OCR 제공 범위와 Pro의 연간 할인도 들어갔습니다. 그래도 요금제별 월 처리량 세 묶음과 삭제 요청 24시간을 다 담지 못해 핵심 슬롯은 1/5만 통과했습니다.

세 문장 안에서 어느 사실을 버릴지는 모델마다 달랐습니다. 버리지 않고 모두 남긴 모델은 없었습니다.

3문장 요약은 이번 조건에서 "핵심 다섯 항목 보존"과 양립하지 않았습니다. 이메일 제목이나 검색 결과 미리보기처럼 매우 짧은 출력에는 쓸 수 있어도, 정책·장애·의사결정 문서의 대체본으로 쓰기는 어렵습니다.

여덟 문장이 되자 통과율이 크게 갈렸습니다

문장 예산을 여덟 개로 늘리자 통과율이 크게 갈렸습니다. 아래 표의 오른쪽 두 칸을 나란히 보면 격차가 한눈에 들어옵니다.

가장 긴 D4는 일부러 함정을 넣은 문서입니다. 평가 초안의 400건과 정확도 76.1%는 표본 설계 오류 때문에 폐기됐습니다. 최종 표본은 480건이고, 후보 모델의 전체 정확도는 74.8%였습니다. 전체 평균은 나아졌지만 신고가 집중된 하위집단 B는 악화됐고 지연과 비용도 늘어 최종 결정은 배포 보류였습니다.

Gemini 3.8 Flash의 첫 8문장 응답은 이 흐름을 유지했습니다.

"최종 평가 결과, 전체 분류 정확도는 모델 A의 71.2%에서 모델 B가 74.8%로 3.6%포인트 개선되었다."

"그러나 사용자 오류 신고가 집중되는 영역인 하위집단 B에서는 모델 B의 정확도가 65.1%로 모델 A(68.4%)보다 3.3%포인트 오히려 낮아졌다."

"이에 따라 즉시 전면 교체나 일부 시험 적용 대신 후보 모델 B의 도입을 잠정 중단하는 '배포 보류'를 최종 결정으로 채택했다."

마지막에는 표본을 1,000건으로 늘려 재평가한다는 계획도 남겼습니다. 폐기된 400건과 76.1%를 최종 수치로 가져오지 않았고, 정확도가 올랐다는 한 줄만 보고 배포 결정도 뒤집지 않았습니다. 같은 조건의 세 반복이 모두 완전통과했습니다.

로컬은 D1과 D2의 8문장 조건에서 각각 3/3을 통과했습니다. D3와 D4에서는 8문장을 줘도 각각 0/3이었습니다. D3는 핵심 다섯 묶음 중 네 묶음, D4도 네 묶음을 반복해서 남겼지만 한 묶음씩 빠졌습니다.

문서별 결과는 다음과 같습니다.

입력 문서	로컬	클라우드
D1 생활 설명문	3/9	4/9
D2 장애 회고	3/9	3/9
D3 요금·보관 정책	0/9	3/9
D4 의사결정 메모	0/9	4/9

표를 보면 규칙이 보입니다. D1·D2에서는 두 모델의 격차가 좁은데 D3·D4에 오면 로컬이 전부 0이 됩니다. 두 문서는 길이와 함께 숫자·예외·철회된 가설·폐기 수치가 더 많이 섞인 입력입니다. 이 표에서 읽을 수 있는 차이는 길이 단독 효과가 아니라, 길이와 정보 구조가 함께 복잡해진 조건에서 나타난 통과 여부입니다. 이번 실측에서 문서가 길고 조건이 복잡한 두 입력은 로컬이 통과하지 못했고, 클라우드는 일부 조건을 통과했습니다. 긴 문서에서 정보가 어디서 사라지는지는 긴 문서 회상 위치 실측에서 위치별로 따로 쟀습니다.

이번에는 거짓말보다 생략이 먼저 문제였습니다

근거 안전은 두 모델 모두 36/36이었습니다. 채점 기준에 잡히는 범위에서는 원문 밖 숫자를 만들거나, 반대 사실을 쓰거나, 폐기 수치를 최종값으로 채택한 응답이 없었습니다.

그렇다고 72개 요약이 모두 안전했다는 뜻은 아닙니다. 완전통과는 20개뿐이었습니다. 나머지 52개는 핵심 슬롯을 하나 이상 놓쳤고, 로컬 세 응답은 요구한 문장 수도 맞추지 못했습니다.

이번 기록에서 오류의 모양은 분명했습니다.

없는 사실을 더한 문제가 아니라, 있어야 할 사실을 덜어낸 문제였습니다.

요금 안내에서 OCR 적용 범위가 빠지면 무료 요금제에서도 OCR을 쓸 수 있다고 독자가 오해할 수 있습니다. 장애 회고에서 초기 가설의 기각이 빠지면 네트워크 지연을 실제 원인으로 읽을 수 있습니다. 의사결정 메모에서 하위집단 악화나 배포 보류가 빠지면 전체 정확도 개선만 남아 정반대의 결정을 내릴 수 있습니다.

이런 누락은 맞춤법 검사로 잡히지 않습니다. 원문 밖 문장이 있는지만 보는 검사도 놓칩니다. 요약 전에 필수 항목을 정하고, 출력 뒤에 그 항목이 실제로 남았는지 대조해야 합니다.

서로 다른 실행 경로의 대기시간은 직접적인 속도 우열보다 실제 운용 환경의 참고값으로 읽어야 합니다

전체 요청 시간 중앙값은 로컬 5.56초, 클라우드 6.95초였습니다. 로컬의 사분위 범위는 5.11~6.38초, 클라우드는 5.71~8.55초로 겹쳤습니다.

로컬은 매 요청마다 keep_alive=0을 적용했으므로 모델을 다시 적재하는 시간이 포함될 수 있습니다. 클라우드는 네트워크와 inferhub 호출 시간이 들어갑니다. 두 경로의 구성도 같지 않습니다.

서로 다른 실행 경로의 대기시간은 직접적인 속도 우열보다 실제 운용 환경의 참고값으로 읽어야 합니다. 이번 글에서 운영 기준으로 삼은 것은 속도가 아니라 핵심 보존과 근거 안전입니다.

문서요약은 모델 선택 전에 계약부터 정해야 합니다

이번 결과를 실제 작업에 옮기면 절차는 단순합니다.

먼저 원문에서 빠지면 안 되는 항목을 적습니다. 장애 회고라면 영향 범위, 기각된 가설, 실제 원인, 복구, 데이터 유실 여부처럼 정할 수 있습니다. 요금 문서라면 요금제별 한도와 보관 기간, 예외 기능, 삭제·할인 조건이 됩니다.

그다음 항목 수에 맞춰 문장 예산을 줍니다. 이번처럼 핵심 묶음이 다섯 개인데 세 문장으로 압축하면 클라우드 모델도 전부 보존하지 못했습니다. 처음부터 여덟 문장을 허용하거나, "핵심 다섯 항목을 각각 포함하라"고 구조를 지정하는 편이 낫습니다. 여덟 문장 허용은 이번 결과가 직접 뒷받침하고, 구조 지정은 원칙에 근거한 권고입니다.

마지막으로 출력과 필수 항목표를 대조합니다. 이 단계는 로컬에만 필요한 방어가 아닙니다. 클라우드도 8문장 조건에서 12번 중 한 번은 핵심 슬롯을 놓쳤습니다.

이번 72회가 남긴 운영 기준은 이렇습니다.

• 짧은 미리보기처럼 일부 정보만 골라도 되는 용도라면 3문장 요약을 쓸 수 있습니다.
• 정책, 장애, 계약, 의사결정처럼 누락 비용이 큰 문서는 3문장만 요구하지 않습니다.
• 핵심 항목을 전부 보존해야 한다면 8문장부터 검토하고 슬롯 검사를 붙입니다.
• 이번 비교에서는 복잡한 D3·D4에서 클라우드가 더 많이 통과했지만, 클라우드 결과도 무검수로 넘기지 않습니다.
• 로컬을 써야 하는 문서라면 문장 수를 늘리고 필수 항목 검사를 통과한 결과만 채택합니다.

처음 빠졌던 콜드브루로 돌아가면 기준이 선명해집니다. 세 문장은 매끄러웠고 사실을 지어내지도 않았습니다. 그래도 콜드브루가 필요한 독자에게는 실패한 요약입니다.

좋은 문서요약은 짧아 보이는 답이 아니라, 버리면 안 되는 내용을 남긴 답입니다.

재현: cinevyze-bench의 run_summary_bench.py와 summary_bench_cases.json (문항 파일 포함). 본문의 원자료 경로(test_runs/…)는 비공개 작업 폴더라 외부에서 열 수 없습니다.

---

요약 비교는 로컬 gemma3:4b와 inferhub의 Gemini 3.8 Flash를 같은 날 실제로 호출해 얻었습니다. 측정 코드와 원고 작성에는 AI 도구의 도움을 받았고, 조건 승인과 발행 전 검수는 제가 합니다.

cinevyze 운영자 — 로컬 Ollama의 gemma3:4b와 inferhub의 Gemini 3.8 Flash High를 같은 날 순차 실행해 문장 예산별 핵심 보존을 검사했습니다. 측정 시점은 2026년 9월 22일입니다. 운영자 소개