문서 요약 파이프라인, 사람 판단은 어디까지 뺄 수 있나

문서 요약 파이프라인은 모든 문서에 똑같이 적용되는 만능 구조가 아니다. 긴 문서·다중 문서·도메인 특화 환경에서는 검색과 요약을 결합한 구조가 검증됐지만, 짧고 사실 밀도가 높은 문서에는 오히려 불리하게 작용한 사례도 보고됐다. 자동화와 사람 검토를 나누는 기준은 "요약 품질 점수"가 아니라 "어떤 오류를 자동으로 걸러내고, 어떤 오류를 사람에게 넘기는가"에 있다.

문서 요약 파이프라인, 사람 검토를 어디까지 줄일 수 있나?

결론부터 말하면, 완전 자동화가 가능한 구간은 "커버리지 확인·형식 준수·초안 생성"이고, 사람이 남아야 하는 구간은 "최종 승인·예외 처리·품질 샘플링"이다. 이 분리는 2025년 MediaEval MultiSumm 계열 실험에서 이미 실제로 쓰인 구조다. 점수 하나로 자동화 여부를 정하는 대신, 단계별로 역할을 나누는 편이 실험적으로 더 안정적이었다.

• 긴 문서·다중 문서·도메인 특화 환경에서는 "요약 인덱스 + 검색" 구조가 강했다.
• 짧고 사실 밀도가 높은 문서(SciFact류)에서는 같은 구조가 해가 될 수 있다.
• 평가는 ROUGE 같은 어휘 유사도만으로는 부족하고, 사실성·일관성 지표가 같이 필요하다.
• 자동화 대상과 사람 검토 대상을 나누는 실제 기준은 커버리지, 형식, 최종 승인의 3단 분리였다.
• 근거 문장 추적(traceability)이 없으면 사람 검토 비중을 줄이기 어렵다.

이번 실험에서 검증하려던 것은 단순하다. "문서 요약을 자동화 파이프라인에 넣을 때, 어느 단계까지 사람 판단 없이 돌려도 되는가"였다. 실무에서 이 질문이 중요한 이유는, 요약 자동화를 도입할 때 흔히 "전체를 자동화하거나, 전체를 사람이 본다"는 이분법으로 접근하기 때문이다. 그 사이에 어떤 단계 구분이 실제로 검증됐는지를 공개 자료로 확인하는 게 이 글의 목적이다.

전체 문서를 통째로 넣을까, 요약 인덱스부터 만들까?

문서 길이와 도메인 특성에 따라 답이 갈린다. 2026년 연구 "Summary RAG"는 "전체 문서 → 요약 → 검색/생성"의 다단계 구조를 제시했고, NFCorpus에서 NDCG@100 기준 +16.5%, TREC-COVID에서 +12.2% 개선을 보였다. 반대로 SciFact처럼 문서가 짧고 사실 밀도가 높은 과제에서는 같은 구조가 오히려 해가 될 수 있다고 보고했다.

이 결과가 자동화 설계에 주는 실질적인 의미는, "요약 인덱스를 먼저 만드는 방식"을 기본값으로 깔아두면 안 된다는 것이다. 문서 길이 임계값과 도메인 특성을 먼저 판단하는 단계가 파이프라인 앞단에 있어야 한다. 실제로 2025년에 나온 장문 문서 요약 관련 systematic review도 문서 길이, 장르, 검색/압축/생성 조합에 따라 성능이 달라진다고 정리했다. 즉 "이 구조를 쓸지 말지"를 판단하는 규칙 자체가 자동화 설계의 첫 단계이고, 이 판단은 사람이 초기에 한 번 정해두는 편이 실험적으로 안전했다.

압축 단계를 따로 두면 요약 품질이 달라지나?

멀티문서·이벤트 요약에서는 원문 전체를 살려두는 쪽이 여전히 강했다. 2025 NAACL short paper "Scaling Multi-Document Event Summarization"은 full-text 방식과 검색 기반 방식이 대부분의 설정에서 가장 좋은 성능을 냈다고 결론냈다. 다만 중간 단계에서 압축 기반 방식(compression-based methods)이 강하게 작동해, 일부 설정에서는 full-context 방식을 앞선 경우도 있었다.

이 결과를 자동화 파이프라인 관점에서 다시 읽으면, "원문 전체 저장 → 검색/압축 후보 생성 → 최종 요약"의 3단 구조가 기본형으로 안정적이라는 뜻이다. 여기서 압축 단계는 완전히 최종 요약을 대체하는 역할이 아니라, 검색 결과를 좁혀주는 보조 단계로 넣는 편이 리스크가 적었다. 원문을 아예 버리고 압축본만 남기는 설계는, 검증된 사례 기준으로는 아직 권장하기 어렵다. 이 부분이 이번 실험에서 가장 확실하게 갈린 지점이었다.

요약이 "잘 됐다"는 건 무엇으로 판정하나?

ROUGE 단일 지표로는 판정 기준이 부족하다는 게 2025~2026 자료에서 반복 확인된다. 2025 MediaEval MultiSumm 논문은 ROUGE(어휘 유사도)와 BERTScore(의미 유사도)를 함께 쓰고, 여기에 LLM-as-judge로 factual accuracy, coherence, multimodal alignment를 따로 평가했다. 같은 MultiSumm 계열의 다른 팀은 data acquisition, preprocessing, classification and labeling, multimodal summarization, evaluation의 5단계로 파이프라인을 나누고, 자동 평가와 사람 평가를 병행했다.

그 결과 Coverage는 약 95%, Coherence Score는 평균 0.82로 보고됐다. 도시별로는 Dublin이 96.4%/0.84로 가장 높았고, Barcelona가 90.6%/0.78로 가장 낮았다. 이 편차는 "요약 품질이 문서 세트에 따라 흔들린다"는 것을 실측으로 보여준다. 그래서 최근에는 평가 축을 Faithfulness(정확성), Completeness(포괄성), Conciseness(간결성)로 구체화하는 흐름이 나타난다. 2026 ICNC 논문은 이 세 축을 기준으로 BBC News Summary Dataset(총 2,225개 기사, Business 510·Entertainment 386·Politics 417·Sport 511·Tech 401)을 평가에 썼고, 온디바이스 요약 모델 17개(3B 미만)를 비교하면서 ChatGPT-4o-latest와 LLaMA3.3-70B 두 개의 judge 모델을 함께 써서 편향을 줄이려 했다. 단일 점수 대신 두 개 이상의 judge를 쓰는 이 방식은, 요약기 선택을 자동화할 때 참고할 수 있는 실질적인 기준이다.

공개 벤치마크는 이 분리 구조를 어떻게 검증했나?

가장 구체적으로 확인된 건 "추적 가능성(traceability)"이 사람 검토를 줄이는 핵심 조건이라는 점이다. 2025년 의료 도메인 벤치마크 TracSum은 sentence-level citations가 붙은 traceable, aspect-based summarization을 제안했다. 요약 문장마다 원문 문장까지 되짚어갈 수 있게 설계한 것이 핵심이고, 이 구조가 있어야 나중에 감사나 수정이 가능하다고 봤다.

학습·개선 단계에서도 생성과 평가를 분리한 설계가 확인된다. 2025 arXiv 논문은 문서 출처를 7개 다양한 소스에서 모으고, 13개의 비-LLM/오픈소스 LLM/상용 LLM으로 요약을 생성한 뒤, LLM 기반 피드백을 품질(low/high), 차원(single/multi-dimensional), 세부도(coarse/fine-grained)의 4가지 구성으로 나눠 수집했다. 이는 "요약을 만드는 프롬프트"와 "요약을 평가하는 프롬프트"를 분리해야 개선 루프가 돈다는 것을 실측으로 보여준 사례다. 종합하면 2025년 흐름은 전통 지표(ROUGE/BERTScore) + LLM-as-judge + 사람 검토를 혼합하는 방향으로 자리 잡고 있고, 이 혼합 구조 자체가 "사람 판단과 자동화의 분리 기준"이 되고 있다.

이 구조가 막히는 지점은 어디인가?

가장 먼저 막힌 지점은 문서 유형 판단이다. Summary RAG 계열 결과가 보여주듯, 짧고 사실 밀도가 높은 문서에서는 요약 인덱스 구조가 오히려 손해였다. 이 판단을 자동으로 내리는 규칙은 아직 표준화돼 있지 않아서, 문서 길이·장르 임계값을 사람이 초기에 정의해야 했다.

두 번째는 평가 지표 편차다. MediaEval MultiSumm의 도시별 Coherence 점수가 0.78~0.84로 흔들린 것처럼, 같은 파이프라인이라도 문서 세트에 따라 품질이 달라졌다. 이 편차를 자동으로 감지해 사람에게 넘기는 규칙(예: 특정 임계값 이하면 사람 검토로 라우팅)은 실험 자료 안에서 구체적으로 확인되지 않았고, 이번 검증에서 남은 과제로 남았다. 세 번째는 traceability 구현 비용이다. sentence-level citation을 붙이는 구조는 감사에는 유리하지만, 파이프라인 구현 단계에서 추가 매핑 작업이 필요해 초기 구축 비용이 늘어난다.

이번 실험에서 남은 질문은 무엇인가?

이번 검증에서 확인된 건 "완전 자동화 vs 완전 수동"이라는 이분법이 아니라, 단계별로 역할을 쪼갤 수 있다는 것이었다. 커버리지·형식 준수·초안 생성은 자동화 쪽에 붙일 근거가 있었고, 최종 승인·예외 처리·품질 샘플링은 사람 쪽에 남을 근거가 있었다. 다만 이 분리 기준을 문서 종류마다 어떻게 미세 조정할지는 이번 자료만으로는 완전히 답이 나오지 않는다. 특히 판정 임계값(어느 Coherence 점수 아래면 사람에게 넘기는지)은 조직마다 다르게 정할 수밖에 없어 보이고, 다음 실험에서는 이 임계값을 직접 정의해보고 실제 오류율과 대조해보는 작업이 필요하다고 판단했다.

핵심 정리

• 문서 요약 파이프라인은 긴 문서·다중 문서·도메인 특화 환경에서 강점이 확인됐지만, 짧고 사실 밀도 높은 문서에는 불리할 수 있다.
• 원문 전체 저장 → 검색/압축 후보 생성 → 최종 요약의 3단 구조가 안정적이며, 압축은 보조 단계로 두는 편이 안전했다.
• 평가는 ROUGE 단일 지표 대신 BERTScore, LLM-as-judge(2개 이상), Faithfulness/Completeness/Conciseness 축을 함께 써야 한다.
• 사람 검토를 줄이려면 sentence-level traceability(근거 문장 매핑)가 필요하고, 이게 없으면 감사·수정이 어렵다.
• 자동화는 커버리지·형식·초안 생성에, 사람 판단은 최종 승인·예외 처리·샘플링에 남기는 분리가 공개 사례에서 작동했다.