장문 보고서: 검색·서술 분리 워크플로우

110k 토큰을 “한 번에” 넣을 수 있어도, 수백 쪽 정책보고서를 통째로 넣으면 모델이 근거와 주장 사이의 연결을 놓치는 경우가 있다. ChatGPT Enterprise 공식 문서에는 업로드 문서에서 컨텍스트 창으로 최대 110k 토큰을 처리할 수 있다고 적혀 있다. Claude.ai 공식 문서에는 업로드 파일이 파일당 30MB까지라고 적혀 있다. 이 두 제한은 장문 보고서 자동화에서 작업 단위를 어떻게 잡을지에 영향을 준다. “더 큰 창”만으로 해결하려 하기보다, **검색(근거 수집)**과 **논리/서술(초안 작성)**을 분리하는 워크플로우가 필요하다.

세 줄 요약

핵심 이슈는 ‘장문 정책보고서’를 LLM에 통째로 넣는 방식이 아니라, 검색(근거)과 서술(논리)을 분리해 운영하는 설계다.
컨텍스트 적재 한도(예: 110k 토큰)와 업로드 제약(예: 30MB/파일)은 작업 단위를 제한한다. 이 단위 설계가 품질, 감사 가능성, 재작업 비용에 영향을 준다.
‘근거 묶음→요약→아웃라인→본문→검증’ 루프를 장·절 단위로 반복한다. 검색용 세션과 서술용 세션을 분리한다. 최종 문서와 함께 인용 근거 묶음을 남긴다.

현황

정책보고서 자동화에서 자주 나오는 문제는 “문장은 길게 쓰는데, 근거 연결이 흔들린다”는 점이다. 원인이 모델 자체에만 있는 경우도 있지만, 투입 방식의 영향이 크다. 공식 문서 기준으로도 장문 작업에는 컨텍스트 한도와 파일 업로드 한도 같은 제약이 있다. 그래서 수백 쪽 보고서는 ‘단일 대화’로 처리하기보다 ‘분할된 공정’으로 다루는 편이 낫다.

ChatGPT Enterprise 관련 공식 문서에는 업로드 문서에서 컨텍스트 창으로 최대 110k 토큰을 처리할 수 있다고 명시돼 있다. 이 수치는 “처리할 수 있는 상한”을 말해 주지만, “항상 안정적으로 통제된다”는 뜻은 아니다. 정책보고서는 표, 각주, 인용, 법령 문구 같은 고정밀 요소가 많다. 이 요소들이 장 전체의 주장과 느슨하게 연결되면 오류가 생긴다. 컨텍스트가 크더라도, 한 번에 몰아넣는 방식은 검증 부담을 키운다.

Anthropic의 Claude.ai 공식 문서에는 파일 업로드가 파일당 30MB라고 적혀 있다. 여기서 중요한 것은 숫자 자체보다 작업 방식의 변화다. 문서가 클수록 업로드 가능한 단위로 쪼개야 한다. 그 순간부터 사용자는 분할 기준과 관리 규칙을 정해야 한다. 장문 작업의 출발점은 모델 선택만이 아니라, **분할 기준(장/절/표/근거 묶음)**을 먼저 정하는 일이다.

분석

이 이슈가 (특히 공공기관의 장문 문서 생산에서) 중요한 이유는, LLM 도입의 쟁점이 작성 속도만이 아니라 감사 가능성으로 이어지기 때문이다. 정책보고서에서 문제가 되는 지점은 문장 표현보다, 왜 그 결론이 나왔는지를 추적할 수 없는 경우다. 그래서 실무에서는 (1) 검색/RAG로 근거를 수집·정리하는 역할과 (2) 그 근거를 바탕으로 논리를 구성하고 장문을 쓰는 역할이 분리되는 경우가 많다. 둘을 같은 대화, 같은 입력 뭉치로 처리하면 출처 관리가 흐려질 수 있다.

한계도 있다. 첫째, 공식 문서에 나온 수치(예: 110k 토큰, 30MB/파일)는 도구가 허용하는 상한에 가깝다. 문서 구조, 표 형태, 스캔 품질, 추출 결과에 따라 사용 경험이 달라질 수 있다. 둘째, “서술” 단계에서 연결 문장이 자연스럽게 만들어져도, 근거 묶음이 빈약하면 보고서가 근거가 약한 글이 된다. 셋째, 공공기관 현장에는 법령 원문 접근, 특정 포맷 편집 같은 운영 제약이 있다. 이 제약은 모델 성능과 별개로 도입 과정에 영향을 준다. 그래서 워크플로우 자체가 품질 관리 체계가 된다.

실전 적용

실무 전략은 단순하다. **검색(근거 수집)**과 **논리/서술(초안·리라이팅)**을 역할로 분리한다. 그리고 “분할된 단위”마다 같은 절차를 반복한다. 예를 들어 ‘제도 현황’ 장을 쓰려면, 먼저 검색 세션에서 근거를 모아 “근거 묶음(출처별 요약+핵심 문장)”을 만든다. 다음으로 서술 세션에서는 근거 묶음만 넣는다. 장의 주장-근거-반론-정책대안 순서로 아웃라인을 만든 뒤 본문을 작성한다. 마지막으로 검증 세션(또는 동일 세션)에서 “각 문단이 어느 근거 묶음에 기대는지”를 점검한다.

예: 한 장(章)을 절 단위로 쪼개고, 절마다 “근거 5개 묶음” 같은 내부 규칙을 두면 업로드 한도(컨텍스트/파일 크기)가 주는 제약을 작업 규칙으로 흡수할 수 있다. 보고서는 길어질수록 ‘검색→서술’ 경계가 흐려지기 쉽다. 경계를 고정하면 (1) 근거 누락 (2) 문단 간 모순 (3) 인용 정리 부담을 줄이는 데 도움이 된다.

오늘 바로 할 일 체크리스트:

“검색용 대화(근거 수집)”와 “서술용 대화(장문 작성)”를 분리한다. 서술용에는 근거 묶음만 공급한다.
장·절·표 중 하나를 기준으로 분할 단위를 고정한다. 각 단위마다 요약 → 아웃라인 → 본문 → 근거-문단 매핑 검증 루프를 반복한다.
최종 산출물과 함께 “근거 묶음(출처별 요약/인용 후보/키워드)”을 같은 폴더(또는 같은 프로젝트) 단위로 보관한다.

FAQ

Q1. 컨텍스트가 크면(예: 110k 토큰) 수백 쪽을 그냥 넣고 요약·작성하면 되지 않나요?
A1. 가능은 합니다. 다만 안정적으로 관리된다고 보장하기는 어렵습니다. 공식 문서의 110k 토큰은 처리 상한에 가깝습니다. 정책보고서처럼 표·인용·법령 문구가 많은 문서는 근거와 주장 연결이 흐트러질 수 있습니다. 분할 단위로 근거를 묶고, 그 묶음만으로 서술을 생성하는 방식이 검증에 유리합니다.

Q2. 파일 업로드 제한(예: 30MB/파일)은 실무에 어떤 설계를 강제하나요?
A2. 문서를 업로드 가능한 단위로 쪼개는 설계를 요구합니다. 장·절·표 중 무엇을 기준으로 분할할지 정해야 합니다. 분할본에 어떤 메타데이터(장/절 번호, 출처, 버전)를 붙일지도 정해야 합니다. 규칙이 없으면 같은 자료를 반복 업로드하거나 인용 출처가 섞일 수 있습니다.

Q3. ‘검색’과 ‘서술’을 분리하면 무엇이 좋아지나요?
A3. 근거 품질 관리가 쉬워집니다. 검색 단계는 “근거가 충분한가/중복은 없는가/핵심 문장 추출이 정확한가”로 평가할 수 있습니다. 서술 단계는 “주장-근거-반론-대안이 논리적으로 연결되는가”로 평가할 수 있습니다. 역할을 나누면 재작업 시 문제 구간을 찾기 쉬워집니다.

결론

장문 정책보고서에서 LLM은 “한 번에 끝내는 자동작성기”라기보다, 근거 수집과 장문 서술을 분업시키는 공정에 가깝다. 다음으로 볼 지점은 모델 스펙 경쟁만이 아니다. 업로드·컨텍스트 같은 하드 리밋을 전제로, 분할 규칙과 검증 루프를 조직이 표준화했는지 점검해야 한다.

Aionda

장문 보고서: 검색·서술 분리 워크플로우

세 줄 요약

현황

분석

실전 적용

FAQ

결론

다음으로 읽기

참고 자료

업데이트 받기