Skip to main content

긴 문서를 Claude에 맡기면, 생각보다 자주 '그럴듯한데 틀린 말'이 섞입니다. 이유는 단순해요. 문서가 길수록 (1) 필요한 부분을 놓치기 쉽고, (2) 질문이 넓으면 빈틈을 "추측"으로 메우기 쉽고, (3) 표·수치·조항처럼 정밀도가 중요한 정보는 한 번 삐끗하면 전체 결론이 흔들리기 때문입니다.

이 장에서는 claude.ai에서 파일·PDF·대용량 문서를 다룰 때, 문서를 안전하게 읽히고(컨텍스트) 필요한 정보만 요약→추출→검증으로 안정적으로 뽑아내는 작업 루틴을 만듭니다.

앞서 '출력 제어 마스터: 길이·톤·형식(표/JSON/XML)·불확실성 처리 규칙'에서 다룬 것처럼, 긴 문서 작업은 특히 "대화"보다 "규격"이 중요합니다. 이 장은 그 규격을 문서 작업에 맞게 재구성한 실전편입니다.

긴 문서에서 Claude가 흔히 틀리는 이유

긴 문서를 다룰 때 실패 패턴은 대체로 세 가지로 모입니다.

첫째, 요약과 추출을 섞어서 합니다. 요약은 "핵심을 간단히" 만드는 일이고, 추출은 "원문에 있는 항목을 빠짐없이 뽑는" 일입니다. 요약은 어느 정도 편집이 허용되지만, 추출은 편집이 아니라 데이터화에 가깝습니다.

둘째, 질문이 "전반적으로 정리해줘"처럼 넓으면 Claude가 문서 전체를 다 읽은 것처럼 말하려고 합니다. 그 순간 환각(Hallucination) 위험이 커집니다.

셋째, 검증 단계가 없습니다. 긴 문서는 사람이 읽어도 실수합니다. AI도 마찬가지예요. 그래서 "한 번에 끝내기" 대신, 검증(Verification)이 포함된 루프가 기본값이어야 합니다.

이 장의 핵심은 간단합니다.

  • 요약은 요약답게

  • 추출은 추출답게(스키마/템플릿으로)

  • 마지막은 검증으로(근거 우선)

업로드 전에 5분 준비: 문서를 '읽히기 좋은 형태'로 바꾸기

claude.ai에 파일을 올리기 전에, 딱 5분만 투자하면 결과가 확 달라집니다.

먼저 파일 이름을 바꿉니다. 예를 들어 2026-계약서_최종.pdf, 요구사항정의서_v3.docx처럼 "무슨 문서인지"가 제목만 봐도 드러나게요. 긴 대화에서 Claude가 파일을 헷갈리면, 그 다음은 전부 꼬입니다.

다음으로 질문을 "업무 목적"으로 바꿉니다. 예를 들어

  • 나쁜 질문: "이 PDF 요약해줘."

  • 좋은 질문: "이 계약서에서 우리에게 불리한 조항만 뽑아서, 조항번호/요지/리스크/대응안을 표로 정리해줘."

마지막으로 민감정보를 잠깐 점검하세요. 업로드 파일에는 종종 주민번호, 계좌번호, 고객명단 같은 내용이 섞입니다. 보안과 운영은 '안전·신뢰·운영: 프롬프트 인젝션, 권한, 데이터 프라이버시, 평가(Evals)와 개선 루프'에서 크게 다루겠지만, 문서 작업은 업로드 순간부터 위험이 시작되니 "마스킹/익명화" 습관이 특히 중요합니다.

claude.ai에서 파일을 '컨텍스트'로 쓰는 법

앞서 'claude.ai 화면 완전 해부: 채팅, 파일 업로드, 스타일(Styles), 프로젝트(Projects)'에서 UI 자체는 봤습니다. 여기서는 파일을 올린 뒤 "어떻게 읽게 만들지"에만 집중합니다.

핵심은 파일을 올리는 순간, Claude가 문서를 자동으로 "잘 읽어줄 것"이라 기대하지 않는 겁니다. 대신 당신이 읽는 순서를 설계해야 합니다.

이 장에서 쓸 기본 작업 단위는 두 가지입니다.

문서 지도(Document map): 문서의 목차·구성·용어·중요 표/부록 위치를 요약한 '찾아보기'입니다. 긴 문서를 바로 요약시키지 말고, 먼저 문서 지도를 만들면 이후 질문이 훨씬 정확해집니다.

근거 레지스트리(Evidence registry): 결론을 내리기 전에 "원문 근거(인용 가능한 문장)"를 모아둔 목록입니다. 이때 쓰는 대표 패턴이 근거우선(Quote-first) 패턴입니다.

문서 읽기 3단계: 지도 만들기 → 요약 → 추출

긴 문서 작업을 한 번에 끝내려 하면 실패합니다. 대신 아래 순서로 "좁혀 들어가면" 안전합니다.

문서 지도 만들기(첫 3~5분)

아래 프롬프트로 시작하세요.

역할: 너는 문서 분석가야.

자료: 첨부한 파일(들)

목표: 내가 이 문서를 빠르게 탐색할 수 있도록 '문서 지도(Document map)'를 만들어.

출력 형식(스키마/템플릿):
1) 문서 개요: 문서 종류/대상/작성 시점(문서에 있는 경우만)
2) 구조: 큰 섹션 제목과 페이지/위치(알 수 없으면 '미확정')
3) 반복 용어: 핵심 용어 10개와 문서 내 의미(정의가 없으면 '문서에 정의 없음')
4) 위험 신호: 숫자/기한/예외/면책/벌칙처럼 실수하면 큰 항목이 등장하는 구간 힌트

불확실성 처리 규칙:
- 문서에 없는 내용은 추측하지 말고 '문서에 없음'으로 써.
- 스캔 품질 등으로 확신이 없으면 '추가 확인 필요'로 표시해.

문서 지도가 있으면, 다음 단계(요약/추출)에서 질문을 "정확한 구간"으로 내릴 수 있어요.

요약은 '목적 맞춤 요약'으로

요약을 요청할 때는 반드시 누구를 위한 요약인지(읽는 사람)와 어디에 쓸 건지(용도)를 줘야 합니다. 같은 문서라도 법무팀 요약과 영업팀 요약은 다르니까요.

이 문서를 다음 조건으로 요약해줘.

독자: 팀장(5분만 읽음)
용도: 의사결정(승인/보류)
길이 제약 조건(Constraints): 총 12문장, 각 문장 25자~45자

포함해야 할 것:
- 결론 2문장(승인/보류 관점)
- 근거 6문장(문서 내용 기반)
- 리스크 4문장(리스크는 반드시 '왜'를 포함)

불확실성 처리 규칙:
- 근거가 약하면 '추가 확인 필요'로 표시

앞서 '출력 제어 마스터…'에서 말한 것처럼, "짧게"가 아니라 문장 수 같은 측정 가능한 단위로 고정하는 게 요약 품질을 올립니다.

추출은 '스키마'로 강제하기

추출은 문서 내용을 업무 데이터로 바꾸는 단계입니다. 이 단계에서 가장 잘 먹히는 방법이 스키마/템플릿(Output format) 강제입니다.

예를 들어 계약서에서 일정·금액·해지·위약금을 뽑고 싶다면 이렇게 갑니다.

첨부한 계약서에서 아래 항목을 '빠짐없이' 추출해줘.

출력은 반드시 JSON 하나로만.
스키마:
{
  "dates": [
    {"label": "", "date": "", "source_quote": "", "confidence": "high|medium|low"}
  ],
  "money": [
    {"label": "", "amount": "", "currency": "", "source_quote": "", "confidence": "high|medium|low"}
  ],
  "termination": [
    {"type": "해지|갱신|중도해지", "condition": "", "notice_period": "", "source_quote": "", "confidence": "high|medium|low"}
  ],
  "penalties": [
    {"label": "", "condition": "", "amount_or_formula": "", "source_quote": "", "confidence": "high|medium|low"}
  ]
}

불확실성 처리 규칙:
- 원문에서 그대로 옮겨 적을 수 없는 항목은 null로 두고 confidence=low.
- source_quote는 원문 문장을 가능한 그대로 넣되, 없으면 빈 문자열.

여기서 포인트는 두 가지입니다.

하나는 source_quote를 강제로 넣는 것. 추출 품질이 확 좋아집니다.

다른 하나는 confidence. "모르면 모른다"를 시스템으로 만들어, 그럴듯한 추측을 줄입니다(불확실성 처리 규칙).

Quote-first로 '근거 있는 답' 만들기

문서 기반 Q&A에서 가장 위험한 순간은, Claude가 결론을 먼저 쓰고 그럴듯한 근거를 뒤로 붙일 때입니다. 그래서 순서를 바꿉니다. 근거 먼저, 결론은 나중에.

API의 Citations(인용) 기능은 이런 요구를 시스템화한 접근입니다. Anthropic은 Citations가 활성화되면, 제공된 문서를 문장 단위로 나눠 모델이 답변에 "정확한 문장/구절" 참조를 붙이도록 설계했다고 합니다.1

claude 에서 당신이 할 일은 같은 원리를 프롬프트로 구현하는 겁니다.

질문: (예: "해지 조항에서 우리에게 불리한 부분은?")

답변 규칙(Quote-first):
1) 먼저 '근거 후보' 섹션에 원문 인용(짧은 문장)을 3~8개 모아.
2) 각 인용마다 '이 인용이 무엇을 의미하는지'를 1문장으로만 설명해.
3) 그 다음에만 '결론'을 5문장 이내로 써.

불확실성 처리 규칙:
- 근거 후보가 없으면 결론을 쓰지 말고 "문서에서 근거를 찾지 못함"이라고 말해.

이렇게 하면 Claude가 "아는 척"하기가 훨씬 어려워집니다.

요약-추출-검증 파이프라인: 실전 템플릿

이 장의 목표는 긴 문서를 안전하게 처리하는 겁니다. 그래서 마지막에 '검증'을 붙입니다.

검증은 거창하지 않아도 됩니다. 핵심은 "내가 지금 만들고 있는 결과가 원문과 맞는지"를 체크리스트로 확인하는 거예요.

아래는 범용 파이프라인 템플릿입니다. 한 채팅에서 그대로 복사해 시작해도 좋습니다.

너는 문서 처리 파이프라인을 수행해.

[입력]
- 첨부 파일: (여러 개 가능)
- 내 목표: (예: "이사회 보고용 리스크 요약 + 액션 아이템")

[단계 A: 문서 지도(Document map)]
- 문서 구조, 핵심 섹션 힌트, 위험 신호 구간을 만든다.

[단계 B: 요약(Summary)]
- 독자/용도에 맞춰 10~15문장 요약을 만든다.
- 불확실한 부분은 '추가 확인 필요'로 표시한다.

[단계 C: 추출(Extraction)]
- 아래 JSON 스키마로 필요한 항목만 빠짐없이 뽑는다.
- 각 항목에 source_quote와 confidence를 포함한다.

[단계 D: 검증(Verification)]
- 체크리스트로 스스로 검사한다:
  1) source_quote 없는 핵심 주장(특히 숫자/기한/의무)이 있는가?
  2) 문서에 없는 내용을 일반 상식으로 보충했는가?
  3) 스키마 필수 필드가 누락됐는가?
- 문제가 있으면, 문제 항목만 재추출/수정한다(부분 수정).

[출력]
A, B, C, D 순서로 출력.

여기서 "문제 항목만 재추출"이 중요합니다. 앞서 '아티팩트(Artifacts)로 보이는 결과 만들기…'에서 배운 부분 수정(좁혀서 수정) 루프를 문서 작업에도 그대로 적용하세요.

컨텍스트 한도를 넘는 초대용량 문서 다루기

문서가 너무 길면(책 한 권, 수백 페이지, 여러 PDF 묶음) 한 번에 정확히 처리하기 어렵습니다. 이때는 "나눠 먹기"가 정답입니다.

분할 업로드 + 누적 요약(Progressive summary)

방법은 단순합니다.

  1. 문서를 큰 덩어리로 나눕니다(예: 1~3장, 4~6장…).

  2. 각 덩어리마다 같은 스키마로 요약/추출을 수행합니다.

  3. 마지막에 '누적 요약'을 하나로 합칩니다.

중요한 건 누적 요약을 만들 때 정보를 줄이되, 근거 힌트는 남기는 것입니다. 예를 들어 "해지: 30일 전 통지" 같은 핵심 사실 옆에 "해지 조항 근처"처럼 위치 힌트를 남겨 두면, 나중에 재검증이 쉬워집니다.

질의도 분할한다: "전반"이 아니라 "구간"

대용량 문서에서 Q&A를 잘하려면 질문도 쪼개야 합니다.

  • "이 문서에서 문제점이 뭐야?" 대신

  • "요금/과금 섹션에서 고객 불만이 생길만한 표현만 찾아줘"처럼

범위를 문서의 일부로 제한하세요. 이건 사실상 가장 강력한 제약 조건(Constraints)입니다.

표·수치·조항처럼 '실수하면 큰' 정보 다루기

PDF에서 표나 수치는 특히 사고가 납니다. 사람도 PDF 표를 복사하면 줄이 틀어지잖아요. Claude도 비슷합니다.

그래서 표/수치 작업은 규칙을 추가합니다.

  • 숫자(금액/비율/기한)가 들어가면, 반드시 원문 인용(source_quote)을 함께 출력하게 합니다.

  • 계산이 필요하면, "계산 과정"을 분리합니다. (계산은 실수하기 쉬우니, 입력값과 계산식을 따로 보여주게 하면 검증이 쉬워요.)

  • 조항은 가능하면 "조항 제목/번호/요지/리스크/대응"처럼 필드로 나눕니다. 문장으로 풀어 쓰게 두면 누락이 늘어납니다.

미니 실습: 80페이지 PDF를 20분 만에 업무용 데이터로

상황을 하나 잡아볼게요. 80페이지짜리 제안요청서(RFP) PDF를 받았고, 오늘 안에 "요구사항 체크리스트"가 필요합니다.

1단계: 문서 지도

PDF 업로드 후, 문서 지도를 만들게 합니다. 여기서 "평가 기준", "납기/일정", "필수 제출 서류"가 어디에 있는지 찾는 게 목표예요.

2단계: 추출 스키마(체크리스트로 바로 쓰기)

이 RFP에서 '우리가 제출/준수해야 하는 요구사항'을 빠짐없이 추출해줘.

출력: Markdown 표
열: ID | 카테고리(기술/보안/일정/문서/가격/기타) | 요구사항 | 필수여부(Must/Should) | 증빙자료(무엇을 내야 하는지) | source_quote | 질문거리(불명확하면)

불확실성 처리 규칙:
- Must/Should가 문서에 명시되지 않으면 '미확정'으로 쓰고 질문거리를 적어.
- source_quote 없는 행은 만들지 마.

3단계: 검증(누락 탐지)

마지막으로 이렇게 시킵니다.

방금 만든 표를 검증해.

체크:
- 일정/제출/형식/보안 요구사항이 각각 최소 3개 이상 포함되었는지(문서에 실제로 있다면)
- 숫자(날짜/금액/비율) 항목은 모두 source_quote가 있는지
- '기타' 카테고리에 몰린 항목이 있으면 더 구체 카테고리로 재분류할지 제안

수정은 전체 재작성 금지. 문제가 있는 행만 교체해.

이렇게 하면 "그럴듯한 요약"이 아니라, 실제로 바로 붙여 넣어 쓸 수 있는 결과물이 나옵니다.

자주 겪는 문제와 고치는 법

문서 작업에서 자주 터지는 문제는 아래 셋입니다.

  • 문서에 없는 말을 단정한다: 근거 우선 프롬프트를 넣고, 불확실성 처리 규칙을 강하게(없으면 '문서에 없음') 두세요.

  • 형식을 자꾸 어긴다(표/JSON 망가짐): 앞서 '출력 제어 마스터…'의 방식대로 스키마를 더 단단하게 하고, "출력은 오직 JSON 하나"처럼 출구를 하나로 줄이세요.

  • 누락이 많다: "요약"을 먼저 해서 중요한 부분만 보고 추출하려고 하면 누락이 늘어납니다. 추출은 처음부터 "빠짐없이"가 목적이므로, 범위를 좁히거나(섹션 단위) 스키마를 단순화해서 단계적으로 늘리세요.

긴 문서는 결국 "잘 읽히는 질문"이 절반이고, "검증 루프"가 나머지 절반입니다. 그 두 가지를 갖추면, claude.ai는 단순 요약기가 아니라 '문서 처리 파이프라인'이 됩니다.

참고

1Introducing Citations on the Anthropic API

2Citations API and PDF support for Claude models now in Amazon Bedrock

책 목록

클로드(Claude) 완전 정복: claude.ai부터 Desktop·Cowork 자동화, MCP 연동, 보안 운영까지

전체 목차 보기

이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.

틸노트는 사용자가 AI를 활용해 노트를 쉽게 작성하거나 편집할 수 있는 서비스입니다.

AI 스퀘어 단톡방에 함께해요

AI 활용과 틸노트 사용 팁을 나누는 오픈채팅방입니다. 입장 비밀번호는 tilnote입니다.

참여하기