요약을 먼저 하면 약한 신호가 사라진다: LLM 요약-후-추출 함정
원문 텍스트를 LLM에 바로 넣지 않고 **“원문 → 요약 → 요약에서 추출”**로 파이프라인을 짜면, 지금은 사소해 보여도 나중에 결정적인 약한 신호가 요약 단계에서 사라진다. 특히 “무엇을 안 하기로 했다”는 부정·예외·번복 결정이 가장 먼저 버려진다. 따라서 의사결정 추적이나 신호 탐지가 목적이라면, 추적에 필요한 정보를 요약 단계가 강제로 보존하게 만들거나 원문을 직접 분석하는 경로를 따로 두어야 한다. 이 글은 그 분기점을 실제 사례로 설명한다.
요약-후-추출 함정이란 무엇인가
**요약-후-추출 함정(summarize-then-extract pitfall)**이란, 분석의 입력으로 원문 대신 AI 요약을 사용했을 때, 요약이 압축 과정에서 버린 정보를 다운스트림 추출 단계가 영영 복구할 수 없게 되는 정보 손실 구조를 말한다.
핵심은 요약의 목적함수와 추출의 목적함수가 다르다는 데 있다. 요약기는 “이 글의 주된 줄거리(gist)를 짧게”라는 목표로 학습·튜닝된다. 그런데 우리가 정작 추출하려는 것은 주된 줄거리가 아니라, 지금은 안 중요해 보이지만 나중에 결정적인 한 줄짜리 신호인 경우가 많다. 목적함수가 어긋난 두 단계를 직렬로 연결하면, 앞 단계가 뒤 단계에 필요한 정보를 미리 폐기해 버린다.
실제 사례: 스레드 중간의 한 줄짜리 번복 결정
샘플 출하 관련 이메일 스레드가 있었다. 제작 일정, 재고 상황, 담당자 변경, 현황 공유가 열 번 넘게 오가는 길고 지배적인 서사였다. 그 한가운데, 누군가 한 줄을 남겼다.
“특정 물량은 이번에 출하하지 않기로 함.”
AI 요약은 이 한 줄을 누락했다. 요약문에는 “샘플 제작 및 출하가 일정대로 진행 중”이라는 지배적 서사만 남았다. 몇 달 뒤 “그때 그 물량 왜 안 나갔지?”라는 질문이 들어왔을 때, 요약만 보던 시스템은 답할 수 없었다. 결정의 흔적이 저장 단계에서 이미 파괴되었기 때문이다.
이 사례의 교훈은 명확하다. 요약이 깔끔해질수록, 내가 찾던 한 줄이 사라진다.
왜 요약기는 하필 그 한 줄을 버리는가
요약기가 이 한 줄을 버린 데는 두 가지 메커니즘이 겹친다.
- 저현저성(low salience): 열 번 넘게 반복된 “진행 중” 서사에 비해, “안 하기로 함”은 분량이 미미하다. 요약기는 빈도·반복으로 중요도를 추정하므로, 한 번만 등장한 짧은 줄은 노이즈로 처리되기 쉽다.
- 부정·번복 편향: 요약기는 “무엇을 한다”는 긍정 행위는 잘 남기고, “무엇을 안 하기로 했다”는 부정·예외·번복을 가장 먼저 버린다. 그런데 의사결정 추적에서는 바로 그 부정·예외·번복이 최고 정보량을 가진다. 계획대로 된 일보다, 계획에서 벗어난 일이 추적의 핵심이기 때문이다.
정리하면 이렇다.
요약의 목적함수(주된 줄거리 압축) ≠ 의사결정 추적의 목적함수(예외·번복 보존).
이 한 줄이 함정의 본질이다.
그러면 언제 원문을, 언제 요약을 분석하나
요약을 무조건 피하라는 뜻은 아니다. 요약에는 토큰 한계 완화, 검색(임베딩) 효율, 비용·지연 분산, 수신자별 중복의 단일 서사화, 그리고 보안 정책상 파생물만 클라우드에 둘 수 있는 컴플라이언스 같은 명백한 이유가 있다. 분기 기준은 **“목적이 gist인가, 예외인가”**다.
| 분석 목적 | 입력으로 적합한 것 | 이유 |
|---|---|---|
| 주제 분류, 전체 동향 파악 | 요약 | gist가 곧 답이라 손실이 무해 |
| 의사결정 추적, 번복·예외 추적 | 원문 | 답이 요약이 버리는 곳에 있음 |
| 약한 선행 신호 탐지(수요·재고·capex) | 원문 | 신호는 빈도 낮은 미세 표현에 있음 |
| 빠른 훑어보기, UI 미리보기 | 요약 | 사람이 읽기용, 정확성 요구 낮음 |
규칙은 단순하다. 답이 “주된 줄거리”에 있으면 요약을 분석해도 되고, 답이 “예외·번복·약한 신호”에 있으면 원문을 직접 분석해야 한다.
설계 처방: 2-트랙 저장 + 결정-인지 요약
운영에서 이 함정을 막는 처방은 두 가지를 함께 쓰는 것이다.
첫째, 2-트랙 저장. 요약은 “훑기용”으로, 원문은 “추적용”으로 둘 다 보존한다. 원문을 통제된 사적 저장소(예: 온프레미스 DB)에 남겨두면, 요약이 버린 결정 한 줄도 추적 질의가 원문까지 내려가 복구할 수 있다. 요약을 단일 진실 원천(single source of truth)으로 삼지 않는 것이 핵심이다.
둘째, 결정-인지 요약(decision-aware summarization). 요약 프롬프트에 보존 대상을 계약처럼 명시한다.
다음 항목은 분량이 짧더라도 반드시 원문 표현 그대로 보존하라:
- 결정/확정 (예: "~하기로 함")
- 번복/취소 (예: "~안 하기로 함", "이전 결정 철회")
- 상태 변경 (예: 일정·담당·범위 변경)
- 부정·예외 (예: "단, ~는 제외")
이 항목들은 전체 서사에서 비중이 작아도 절대 생략하지 않는다.
이렇게 목적함수를 명시적으로 교정하면, 요약기가 기본값으로 버리던 저현저성 신호를 의도적으로 붙잡게 만들 수 있다.
한 줄 요약
요약은 “무엇을 했는가”는 남기고 “무엇을 안 하기로 했는가”는 버린다. 추적이 목적이라면 원문을 버리지 마라.
현실 주석: 위 처방은 손실을 줄이지 제거하지는 못한다. 결정-인지 프롬프트도 모델·문서에 따라 누락이 남고, 2-트랙 저장은 원문 조회 비용·지연을 떠안는다. 그래도 방향은 같다 — 약한 신호를 다루는 시스템에서 요약은 최적화일 뿐 진실 원천이 아니며, 진실 원천은 끝까지 원문이어야 한다.