문서, PDF, 비전, 검색, 인용

문서를 읽는다는 것은 답을 만드는 일이 아니라 근거를 다루는 일이다

앞 장에서 우리는 Claude에게 도구를 붙이는 방법을 배웠다. Claude는 직접 데이터베이스에 접속하거나 서버 명령을 실행하는 존재가 아니라, 필요한 도구 호출을 제안하고 그 결과를 해석하는 추론 엔진에 가깝다. 이번 장에서는 그 원리를 문서와 이미지, 검색 결과로 확장한다.

계약서 80쪽을 넣고 "요약해 줘"라고 말하는 것은 쉽다. 논문 PDF를 올리고 "핵심만 알려줘"라고 말하는 것도 쉽다. 하지만 실무에서 정말 필요한 것은 조금 다르다. 우리는 "요약"이 아니라 확인 가능한 요약을 원한다. "그럴듯한 설명"이 아니라 어느 페이지, 어느 조항, 어느 표에서 나온 말인지 추적할 수 있는 설명을 원한다. 이 차이가 문서형 AI 작업의 품질을 가른다.

Claude는 PDF, 이미지, 검색 결과, 인용 기능을 활용해 문서 기반 작업을 강하게 지원한다. PDF support를 이용하면 문서의 텍스트뿐 아니라 페이지 이미지에 담긴 시각 정보까지 함께 다룰 수 있고, vision 기능을 이용하면 스크린샷·차트·사진 같은 자료를 해석할 수 있다.¹ Citations 기능을 쓰면 Claude의 답변에 근거 위치를 붙여 사용자가 원문을 확인할 수 있으며, search result blocks를 쓰면 애플리케이션이 가져온 검색 결과를 구조화된 근거로 전달할 수 있다.²

다만 기능이 강해질수록 착각도 커진다. Claude가 문서를 읽었다고 해서 모든 페이지를 완벽하게 이해했다는 뜻은 아니다. 표의 머리글을 잘못 연결할 수 있고, 차트 축을 반대로 읽을 수 있으며, 긴 계약서에서 예외 조항을 놓칠 수 있다. 최신 웹 검색 결과가 들어왔다고 해서 자동으로 진실이 되는 것도 아니다. 검색 결과는 근거 후보일 뿐이고, 근거 후보 사이에는 신뢰도 차이가 있다.

이 장의 핵심은 하나다. Claude에게 자료를 던지는 법이 아니라, 자료를 근거로 바꾸는 법을 배우는 것이다.

PDF는 "파일 하나"가 아니라 페이지와 질문의 묶음이다

PDF는 실무에서 가장 흔한 문서 형식이다. 계약서, 제안서, 감사 보고서, 제품 매뉴얼, 논문, 판례, 정책 문서, 회의록이 모두 PDF로 오간다. 그래서 많은 사용자가 Claude에 PDF를 넣고 곧바로 묻는다.

"이 문서 요약해 줘."

나쁜 요청은 아니다. 처음 훑어볼 때는 충분히 쓸 만하다. 하지만 이 방식은 문서가 길고 중요해질수록 위험해진다. 3쪽짜리 안내문은 통째로 요약해도 괜찮다. 120쪽짜리 계약서, 60쪽짜리 임상 보고서, 부록이 많은 기술 제안서는 다르다. 이때 PDF는 하나의 파일이 아니라 다음 요소들의 묶음으로 보아야 한다.

PDF 작업의 첫 단계는 "무엇을 읽힐 것인가"보다 "어떤 읽기를 시킬 것인가"다. 같은 계약서라도 CFO는 지급 조건과 위약금을 보고, 법무팀은 책임 제한과 준거법을 보며, 보안팀은 데이터 처리와 감사 권한을 본다. Claude에게 이 차이를 알려 주지 않으면 평균적인 요약은 만들어도 업무에 맞는 독해는 하지 못한다.

가장 안전한 PDF 입력 프롬프트는 다음 네 층을 가진다.

목적: 이 문서를 왜 읽는가?
범위: 어느 페이지·섹션을 볼 것인가?
질문: 무엇을 찾아야 하는가?
근거: 답변마다 어떤 원문 위치를 붙일 것인가?

예를 들어 계약서 검토라면 이렇게 요청할 수 있다.

첨부한 PDF는 SaaS 서비스 이용계약서 초안이다.

목적:
우리 회사가 고객사 입장에서 서명하기 전에 주요 리스크를 검토하려 한다.

범위:
먼저 전체 문서를 훑되, 특히 다음 항목을 중점적으로 확인해 줘.
- 자동 갱신과 해지
- 요금 인상
- 데이터 처리와 보안
- 책임 제한
- 손해배상
- 준거법과 분쟁 해결

작업:
1. 각 항목별로 관련 조항을 찾아라.
2. 고객사에 불리할 수 있는 표현을 설명하라.
3. 협상 시 수정 요청 문구를 제안하라.
4. 확실하지 않은 내용은 추정하지 말고 "원문 확인 필요"라고 표시하라.

출력:
표로 작성하라. 열은 항목, 관련 조항/페이지, 리스크 설명, 수정 제안, 확인 필요 여부로 구성하라.

이 프롬프트는 "요약해 줘"보다 길지만 훨씬 안전하다. Claude가 무엇을 리스크로 볼지, 어떤 단위로 답할지, 근거를 어떻게 붙일지 알 수 있기 때문이다.

논문 PDF에서는 질문이 달라진다.

첨부한 PDF는 머신러닝 논문이다.

다음 순서로 읽어 줘.
1. 연구 질문을 한 문장으로 정리한다.
2. 기존 연구와의 차이를 설명한다.
3. 실험 설정에서 데이터셋, 베이스라인, 평가 지표를 추출한다.
4. 표와 그림이 주장하는 바를 각각 설명한다.
5. 저자가 인정한 한계와, 독자가 추가로 의심해야 할 한계를 구분한다.
6. 답변마다 가능한 한 페이지 또는 섹션 근거를 붙인다.

주의:
수식이나 표를 해석할 때 확실하지 않으면 확실하지 않다고 말한다.
논문에 없는 성능 비교를 만들어 내지 않는다.

매뉴얼 PDF에서는 또 다르다.

첨부한 PDF는 장비 설치 매뉴얼이다.

사용자는 현장 설치 기사이며, 지금 필요한 것은 전체 요약이 아니라 작업 순서다.
다음 형식으로 정리해 줘.

1. 설치 전 준비물
2. 안전 경고
3. 설치 순서
4. 각 단계의 확인 기준
5. 흔한 오류와 해결 방법
6. 원문 페이지

주의:
안전 경고와 전원 관련 지시는 절대 생략하지 말라.
표나 그림에만 있는 정보도 빠뜨리지 말라.

문서 작업에서 "좋은 질문"은 예쁜 문장이 아니다. 읽는 목적과 실패 비용을 드러내는 문장이다. 계약서에서 실패하면 돈과 책임 문제가 생긴다. 매뉴얼에서 실패하면 안전 문제가 생긴다. 논문에서 실패하면 잘못된 의사결정이 생긴다. Claude에게 그 비용을 알려 주면 더 조심스럽게 읽게 만들 수 있다.

긴 PDF를 한 번에 읽히지 말고 읽기 전략을 나누어라

긴 문서를 다룰 때 가장 흔한 실수는 처음부터 끝까지 한 번에 완벽한 답을 기대하는 것이다. 물론 Claude의 긴 문맥 처리 능력은 강력하다. 그러나 장문 문서 작업에서 중요한 것은 단순히 "많이 넣기"가 아니라 "올바른 순서로 읽기"다.

긴 PDF는 보통 세 단계로 읽는 것이 안정적이다.

첫째, 지도 만들기다. 목차, 섹션 제목, 표와 그림 목록, 부록 구조를 먼저 뽑는다. 이 단계에서는 깊은 해석보다 문서의 지형을 파악한다. 사람이 낯선 건물에 들어가면 먼저 층별 안내도를 보는 것과 같다.

둘째, 질문별 정밀 읽기다. 전체 문서 지도를 바탕으로 특정 질문에 관련된 페이지와 섹션을 집중해서 본다. 계약서라면 책임 제한, 데이터 처리, 종료 조항을 따로 읽는다. 보고서라면 결론, 방법론, 수치 근거, 한계점을 따로 읽는다.

셋째, 교차 검증이다. 요약 내용이 표·그림·부록·각주와 충돌하지 않는지 확인한다. 긴 문서의 핵심 정보는 본문에만 있지 않다. 부록 표에 중요한 예외가 있고, 각주에 적용 제외 조건이 있으며, 그림 캡션에 실험 조건이 숨어 있는 경우가 많다.

다음은 긴 PDF를 안정적으로 처리하는 3단계 프롬프트 흐름이다.

1단계: 문서 지도 작성
첨부한 PDF를 먼저 깊게 요약하지 말고 구조만 파악해 줘.
목차, 주요 섹션, 표/그림, 부록, 반복적으로 등장하는 핵심 용어를 정리해 줘.
각 항목에 페이지 범위를 붙여 줘.

2단계: 질문별 근거 추출
앞서 만든 문서 지도를 바탕으로 "데이터 보존 및 삭제"와 관련된 모든 조항을 찾아 줘.
본문, 표, 부록, 정의 조항을 모두 확인하고, 관련성이 약한 항목과 강한 항목을 구분해 줘.

3단계: 답변 검증
방금 정리한 내용이 문서 안의 다른 조항과 충돌하는지 확인해 줘.
특히 예외, 단서, "단, …의 경우", "notwithstanding", "except" 같은 표현을 찾아서 앞선 결론을 수정해야 하는지 검토해 줘.

이 방식은 다소 번거로워 보이지만, 중요한 문서일수록 시간을 아낀다. 처음부터 완성 답변을 요구하면 빠르게 결과를 얻는 대신 어디서 틀렸는지 찾기 어렵다. 단계별로 읽히면 중간 산출물이 남는다. 문서 지도, 근거 추출표, 충돌 검토표가 쌓이면 사람도 검토하기 쉬워진다.

PDF 입력에서 특히 조심해야 할 문서는 스캔본이다. 스캔본은 텍스트가 아니라 이미지로 구성된 경우가 많다. OCR, 즉 이미지 속 글자를 인식하는 과정에서 숫자 0과 영문 O, 1과 l, 쉼표와 마침표, 원화 표시와 달러 표시가 섞일 수 있다. 오래된 계약서나 도장 찍힌 공문, 저해상도 팩스 문서는 더 위험하다.

스캔본을 처리할 때는 다음과 같이 물어야 한다.

이 PDF가 텍스트 기반 문서인지, 스캔 이미지 기반 문서인지 먼저 판단해 줘.
읽기 어려운 페이지, 흐릿한 표, 잘릴 가능성이 있는 영역이 있으면 페이지별로 알려 줘.
숫자·날짜·금액·이름처럼 오독 위험이 큰 항목은 확신도를 함께 표시해 줘.

계약서나 재무 문서에서는 특히 숫자가 중요하다. "10일"과 "30일", "1,000,000원"과 "10,000,000원"은 전혀 다른 결과를 만든다. Claude가 숫자를 추출했다면 반드시 원문 위치와 함께 다시 확인해야 한다. 중요한 숫자는 한 번 더 질문하는 것이 좋다.

앞서 추출한 모든 날짜, 금액, 비율, 기간만 따로 모아 줘.
각 항목에 원문 표현, 해석한 값, 페이지, 확신도를 붙여 줘.
확신도가 낮거나 OCR 오독 가능성이 있는 항목은 별도로 표시해 줘.

문서를 읽는 AI를 믿는다는 것은 아무 검증 없이 받아들인다는 뜻이 아니다. 믿을 수 있게 만드는 절차를 설계한다는 뜻이다.

표는 문장보다 어렵다: 행과 열의 관계를 확인하라

사람은 표를 보면 눈으로 구조를 한 번에 잡는다. 하지만 모델에게 표는 생각보다 까다로운 입력이다. 셀 병합, 다단 머리글, 각주, 단위 표시, 음수 표기, 빈칸의 의미, 색상 강조가 모두 해석 대상이기 때문이다.

예를 들어 다음과 같은 표를 보자.

이 표는 단순하다. 하지만 실제 보고서 표는 훨씬 복잡하다. "단위: 백만원"이 표 위에 있고, "괄호는 음수"라는 주석이 아래에 있으며, 2025년 값 중 일부는 추정치일 수 있다. 머리글이 두 줄로 나뉘어 "국내/해외"와 "매출/이익"이 교차할 수도 있다. 이때 Claude가 표를 잘못 읽으면 결론 전체가 흔들린다.

표를 읽힐 때는 다음처럼 구조 확인을 먼저 시켜야 한다.

첨부 문서의 12페이지 표 3을 해석하기 전에, 먼저 표 구조를 설명해 줘.

확인할 것:
1. 행은 무엇을 의미하는가?
2. 열은 무엇을 의미하는가?
3. 단위는 무엇인가?
4. 각주나 주석이 있는가?
5. 빈칸, 괄호, 별표의 의미가 설명되어 있는가?
6. 표에서 직접 읽은 값과 네가 계산한 값을 구분하라.

이 프롬프트에서 중요한 문장은 마지막이다. 직접 읽은 값과 계산한 값을 구분하라. Claude가 표에 없는 증감률을 계산할 수는 있다. 하지만 그 값이 원문에 있는 값인지, 모델이 계산한 값인지 분리해야 검증이 가능하다.

재무 표에서는 다음 형식이 좋다.

표 기반 답변에서는 빈칸도 질문해야 한다. 빈칸은 "0"일 수도 있고, "해당 없음"일 수도 있고, "자료 없음"일 수도 있다. 표 아래 주석이 그 의미를 설명하는 경우가 많다. 따라서 빈칸을 임의로 0으로 바꾸면 안 된다.

표의 빈칸을 0으로 해석하지 말라.
원문 주석에서 빈칸의 의미를 찾고, 설명이 없으면 "의미 불명"으로 표시하라.

차트도 마찬가지다. 막대그래프, 선그래프, 산점도, 누적 그래프는 각각 읽는 법이 다르다. 특히 누적 막대그래프와 일반 막대그래프를 혼동하면 큰 오류가 생긴다. 축이 로그 스케일인지 선형 스케일인지, y축이 0에서 시작하는지, 오른쪽 보조축이 있는지 확인해야 한다.

차트 해석 프롬프트는 다음처럼 시작하는 것이 안전하다.

이 차트를 해석하기 전에 차트의 문법을 먼저 설명해 줘.

확인할 것:
- 차트 유형
- x축과 y축의 의미
- 단위와 스케일
- 범례
- 데이터 기간
- 값이 직접 표시된 것인지 시각적으로 추정한 것인지
- 차트가 강조하는 결론과, 차트만으로는 말할 수 없는 결론

특히 마지막 항목이 중요하다. 차트는 강한 설득 도구다. 보고서 작성자는 특정 메시지를 전달하려고 축 범위와 색상, 순서를 선택한다. Claude에게 "차트가 주장하는 바"와 "차트로는 증명할 수 없는 바"를 나누게 하면 과잉 해석을 줄일 수 있다.

이미지와 스크린샷은 보이는 것과 추정한 것을 나누어야 한다

Claude의 vision 기능은 이미지 자료를 다룰 때 유용하다. 제품 사진, UI 스크린샷, 화이트보드 사진, 영수증, 차트 이미지, 현장 점검 사진 등을 설명하고 분석할 수 있다.³ 하지만 이미지 해석에는 늘 두 층이 있다. 하나는 보이는 것이고, 다른 하나는 추정한 것이다.

예를 들어 회의실 화이트보드 사진을 넣고 "무슨 내용인지 정리해 줘"라고 하면 Claude는 글자를 읽고 구조를 추정한다. 하지만 흐릿한 글자, 가려진 부분, 문맥상 보완한 단어가 섞일 수 있다. UI 스크린샷에서는 버튼 이름을 잘못 읽거나, 비활성화된 상태를 활성 상태로 착각할 수 있다. 제품 사진에서는 크기와 재질을 추정할 수 있지만, 사진만으로 확정할 수 없는 정보가 많다.

이미지 작업에서는 항상 다음 세 범주를 분리해야 한다.

스크린샷 분석 프롬프트는 다음처럼 쓸 수 있다.

첨부한 이미지는 웹 서비스 관리자 화면의 스크린샷이다.

다음 세 범주로 나누어 분석해 줘.
1. 이미지에서 직접 보이는 UI 요소
2. 화면의 목적에 대한 추정
3. 이미지로는 확인할 수 없는 것

그다음 사용성 관점에서 문제점을 찾아 줘.
단, 실제 동작 여부나 사용자 권한처럼 스크린샷만으로 알 수 없는 내용은 단정하지 말라.

차트 이미지라면 이렇게 요청한다.

첨부한 차트 이미지를 분석해 줘.

먼저 차트의 제목, 축, 단위, 범례를 읽어라.
그다음 데이터가 말하는 추세를 설명하라.
마지막으로 차트만 보고 단정할 수 없는 결론을 따로 적어라.
숫자 값이 이미지에서 정확히 읽히지 않으면 "대략"이라고 표시하라.

현장 사진이나 품질 점검 사진에서는 더 조심해야 한다. 사진 한 장으로 안전 여부를 확정하면 안 된다. 조명, 각도, 해상도, 가려진 부분 때문에 보이지 않는 결함이 있을 수 있다.

첨부한 현장 사진을 보고 점검 의견을 작성해 줘.

반드시 다음 원칙을 지켜라.
- 사진에서 직접 보이는 이상 징후만 "관찰"로 적는다.
- 원인과 위험도는 "가능성"으로 표현한다.
- 사진만으로 판단할 수 없는 항목은 현장 확인 질문으로 남긴다.
- 안전과 관련된 결론은 단정하지 않는다.

이미지 분석에서 좋은 답변은 자신감 넘치는 답변이 아니다. 어디까지 보았고, 어디부터 추정인지 선을 긋는 답변이다.

Citations: 답변에 발자국을 남겨라

문서 기반 작업의 가장 큰 약점은 "그 말이 어디서 나왔는가?"라는 질문에 답하지 못할 때 드러난다. Claude가 50쪽짜리 정책 문서를 요약했는데 근거 위치가 없다면, 사용자는 결국 원문을 다시 읽어야 한다. 그러면 AI가 시간을 아껴 준 것이 아니라 검증 부담을 뒤로 미룬 셈이다.

Citations 기능은 이 문제를 줄이기 위한 장치다. Claude가 문서나 검색 결과를 바탕으로 답할 때 답변의 특정 문장에 원문 근거를 붙이도록 할 수 있다.⁴ 사용자는 답변을 읽다가 근거 표시를 따라가 원문 위치를 확인한다. 이것은 단순한 출처 목록과 다르다. 문서 끝에 "참고: 계약서.pdf"라고 쓰는 것만으로는 부족하다. 중요한 것은 어떤 주장에 어떤 근거가 연결되는가다.

예를 들어 다음 두 답변을 비교해 보자.

나쁜 답변:
이 계약은 자동 갱신되며, 해지하려면 사전 통지가 필요합니다.
출처: 계약서.pdf

좋은 답변:
이 계약은 최초 기간 종료 후 동일한 기간으로 자동 갱신되며, 갱신을 원하지 않는 당사자는 만료 30일 전까지 서면 통지를 해야 합니다. [근거: 제5조 2항, p.7]

두 답변의 정보량은 비슷해 보이지만 업무 가치는 다르다. 좋은 답변은 사용자가 바로 원문을 확인할 수 있다. 법무 담당자는 제5조 2항을 열어 문구를 검토하고, 협상 담당자는 "30일"이 충분한지 판단한다.

인용을 잘 붙이려면 프롬프트에서 근거 단위를 지정해야 한다.

답변의 모든 핵심 주장에는 근거를 붙여 줘.
근거는 가능한 한 페이지 번호와 조항명 또는 표 번호로 표시해 줘.
한 문단에 여러 주장이 있으면 주장별로 근거를 나누어 줘.
문서에서 근거를 찾지 못한 내용은 추정하지 말고 "근거 없음"이라고 표시해 줘.

Citations는 특히 다음 작업에서 강력하다.

다만 인용이 붙었다고 해서 답변이 자동으로 옳아지는 것은 아니다. 인용은 검증을 가능하게 하는 장치이지, 검증 자체가 아니다. Claude가 관련 근거를 붙였지만 그 근거가 결론을 충분히 지지하지 못할 수 있다. 또는 같은 문서의 다른 조항이 예외를 만들 수 있다. 그래서 중요한 답변에는 "근거 적합성"을 다시 물어야 한다.

앞서 작성한 답변의 각 근거가 해당 주장을 실제로 뒷받침하는지 검토해 줘.
다음 세 등급으로 표시해 줘.
- 강함: 근거가 주장을 직접 뒷받침함
- 보통: 근거가 관련은 있으나 해석이 필요함
- 약함: 근거가 부족하거나 간접적임

근거가 약한 주장은 더 조심스럽게 다시 표현해 줘.

이 질문은 문서형 작업의 품질을 크게 높인다. 많은 오류는 "근거가 아예 없음"에서만 생기지 않는다. "관련 있어 보이는 근거를 과하게 해석함"에서도 생긴다.

검색 결과는 지식이 아니라 증거 후보이다

Claude의 기본 지식은 특정 시점까지의 학습에 기반한다. 최신 가격, 최근 정책 변화, 어제 발표된 보안 취약점, 방금 바뀐 API 문서, 새로 나온 법령 개정안은 외부 확인이 필요하다. 이때 웹 검색이나 애플리케이션이 수집한 검색 결과를 Claude에게 제공한다.

Anthropic의 문서에는 Claude에게 구조화된 검색 결과를 전달하는 search result blocks 개념이 있다. 개발자는 검색 시스템이 찾은 제목, URL, 본문 일부, 출처 정보를 Claude에게 넘기고, Claude는 그 자료를 근거로 답변을 구성할 수 있다.⁵ 웹 검색 도구를 사용하는 경우에도 핵심 원리는 같다. 최신 정보는 "모델의 기억"이 아니라 "지금 가져온 근거"로 다루어야 한다.⁶

검색 기반 답변에서 가장 위험한 요청은 이것이다.

요즘 생성형 AI 규제 동향 알려줘.

너무 넓고, 기준도 없고, 출처 요구도 없다. 그러면 답변은 그럴듯하지만 검증하기 어려운 개괄이 되기 쉽다. 검색 기반 질문은 다음처럼 바꾸어야 한다.

2025년 이후 공개된 자료를 중심으로 생성형 AI 개인정보 규제 동향을 정리해 줘.

범위:
- 한국, EU, 미국 자료를 우선한다.
- 정부기관, 규제기관, 법령 원문, 공식 가이드라인을 우선한다.
- 블로그나 언론 기사는 공식 자료를 보완할 때만 사용한다.

출력:
1. 지역별 핵심 변화
2. 기업이 해야 할 대응
3. 아직 불확실한 쟁점
4. 각 주장별 출처 링크

검색 결과를 사용할 때는 출처의 신뢰도를 구분해야 한다. 공식 문서, 법령 원문, 학술 논문, 기업 블로그, 커뮤니티 글은 같은 무게가 아니다. Claude에게 이 우선순위를 알려 주면 답변이 훨씬 안정된다.

검색 결과를 사용할 때 다음 우선순위를 적용해 줘.
1순위: 법령 원문, 정부·규제기관 공식 문서
2순위: 국제기구, 표준화기구, 학술 논문
3순위: 기업 공식 문서와 릴리스 노트
4순위: 언론 기사
5순위: 블로그, 커뮤니티, 개인 의견

상위 출처와 하위 출처가 충돌하면 상위 출처를 우선하고, 충돌 사실을 명시해 줘.

검색 기반 답변에서는 날짜도 중요하다. 웹에는 오래된 정보가 오래 남아 있다. 2023년의 API 제한, 2024년의 가격표, 2025년의 베타 기능 설명이 동시에 검색될 수 있다. Claude가 검색 결과를 잘 요약해도 날짜를 확인하지 않으면 낡은 답변이 된다.

각 출처의 게시일 또는 업데이트일을 확인해 줘.
날짜가 없으면 "날짜 확인 불가"로 표시해 줘.
최신 정보와 과거 정보가 충돌하면 최신 공식 문서를 우선하되, 변경 이력을 설명해 줘.

검색 결과를 넣을 때 개발자는 원문 전체를 무작정 넣고 싶어 한다. 그러나 검색 결과가 많아질수록 잡음도 많아진다. 검색 시스템은 Claude에게 다음 정보를 구조화해서 주는 편이 좋다.

{
  "title": "문서 제목",
  "url": "https://example.com/source",
  "published_at": "2026-03-10",
  "source_type": "official_docs",
  "snippet": "검색 결과 요약 또는 관련 문단",
  "relevance_reason": "이 결과가 사용자 질문과 관련 있는 이유"
}

이렇게 넘기면 Claude는 단순히 텍스트 뭉치를 읽는 것이 아니라 "어떤 출처의 어떤 정보인지"를 파악할 수 있다. 검색 결과는 내용뿐 아니라 메타데이터가 중요하다. 제목, URL, 날짜, 출처 유형, 관련성 이유가 답변 품질을 좌우한다.

Grounded response: 대답을 자료 안에 묶어 두는 기술

Grounded response는 답변을 제공된 근거 안에 묶어 두는 방식이다. 쉽게 말해 "네가 아는 것을 다 말하지 말고, 지금 준 자료로 확인되는 것만 말하라"는 설계다. 문서 요약, 규정 해석, 고객지원, 법무 검토, 의료·금융 보조처럼 근거가 중요한 영역에서는 이 원칙이 필수다.

일반 답변과 grounded response의 차이는 다음과 같다.

Grounded response를 만들려면 시스템 또는 사용자 지시에 다음 규칙을 넣는다.

아래 제공된 자료만 근거로 답하라.
자료에 없는 내용은 일반 지식으로 보완하지 말고 "제공된 자료에서는 확인되지 않음"이라고 말하라.
모든 핵심 주장에는 출처를 붙여라.
자료끼리 충돌하면 충돌을 숨기지 말고 나란히 제시하라.

고객지원 봇에서는 이렇게 쓸 수 있다.

너는 고객지원 상담 보조다.
답변은 제공된 도움말 문서와 정책 문서에 근거해야 한다.
정책 문서에 없는 보상, 환불, 예외를 약속하지 말라.
문서에서 확인되지 않는 경우 상담원에게 에스컬레이션하라고 안내하라.

법무 검토 보조에서는 더 엄격해야 한다.

첨부된 계약서와 제공된 회사 표준 조항만 근거로 검토하라.
법률 자문처럼 단정하지 말고, 문서상 리스크 후보를 정리하라.
계약서에 없는 법적 효과를 일반론으로 확정하지 말라.
불확실한 부분은 변호사 검토 필요로 표시하라.

Grounded response의 핵심은 "모른다"를 허용하는 것이다. 많은 제품 팀이 AI가 모른다고 답하는 것을 실패로 본다. 그러나 근거 기반 시스템에서 근거 없는 답을 하는 것이 진짜 실패다. 고객이 환불 가능 여부를 물었는데 정책 문서에 없는 예외를 Claude가 만들어 내면, 답변은 친절해 보여도 회사에는 리스크가 된다.

좋은 grounded response는 다음 문장을 자연스럽게 포함한다.

제공된 문서에서는 이 항목을 확인할 수 없습니다.
현재 근거만으로는 단정하기 어렵습니다.
A 문서는 이렇게 말하지만, B 문서는 다른 조건을 제시합니다.
이 결론은 p.12의 표와 p.18의 예외 조항을 함께 해석한 것입니다.

이런 문장은 답변을 약하게 만드는 것이 아니라 강하게 만든다. 왜냐하면 사용자가 판단할 수 있는 근거와 한계를 함께 주기 때문이다.

검색과 문서 읽기를 결합하는 RAG식 흐름

RAG, 즉 retrieval-augmented generation은 외부 저장소에서 관련 문서를 찾아 모델의 입력에 넣고 답변을 생성하는 패턴이다. 한국어로는 "검색 증강 생성" 정도로 번역할 수 있다. 8장에서 시스템 설계 패턴으로 더 자세히 다루겠지만, 문서·검색·인용 장에서도 기본 흐름은 알아야 한다.

RAG식 문서 질의응답은 보통 다음 순서로 움직인다.

사용자 질문
-> 검색 쿼리 생성
-> 문서 저장소에서 관련 조각 검색
-> 검색 결과를 재정렬
-> Claude에 질문과 근거 조각 전달
-> 근거 기반 답변 생성
-> 인용과 불확실성 표시

여기서 중요한 것은 검색 결과의 품질이다. Claude가 아무리 뛰어나도 엉뚱한 문서를 받으면 엉뚱한 답을 한다. 이것을 "garbage in, garbage out"이라고 부른다. 쓰레기를 넣으면 쓰레기가 나온다는 뜻이다.

문서 저장소를 만들 때는 문서를 너무 크게도, 너무 작게도 자르면 안 된다. 계약서 전체를 한 덩어리로 넣으면 검색이 둔해진다. 반대로 문장을 너무 잘게 자르면 조항의 맥락이 사라진다. 좋은 조각은 하나의 의미 단위를 담되, 원문 위치와 주변 맥락을 잃지 않아야 한다.

예를 들어 계약서는 조항 단위로 나누는 것이 좋다.

{
  "document_id": "msa_2026_customer_a",
  "chunk_id": "section_7_2",
  "title": "제7조 데이터 보존 및 삭제",
  "page": 14,
  "text": "계약 종료 후 회사는 고객 데이터를 30일 이내 삭제한다. 단, 관련 법령상 보존 의무가 있는 경우...",
  "metadata": {
    "document_type": "contract",
    "section": "7.2",
    "language": "ko",
    "effective_date": "2026-01-01"
  }
}

논문은 섹션과 표·그림 단위가 중요하다. 매뉴얼은 절차 단계 단위가 좋다. 정책 문서는 정의, 적용 범위, 예외, 절차, 책임자 단위로 나누면 답변 품질이 좋아진다.

RAG 답변 프롬프트는 다음처럼 구성할 수 있다.

사용자 질문:
{question}

아래는 검색 시스템이 찾은 관련 문서 조각이다.
각 조각에는 document_id, title, page, text가 포함되어 있다.

규칙:
1. 답변은 제공된 문서 조각에 근거해야 한다.
2. 근거가 부족하면 부족하다고 말한다.
3. 서로 충돌하는 조각이 있으면 충돌을 설명한다.
4. 핵심 주장마다 document_id와 page를 붙인다.
5. 사용자에게 필요한 다음 확인 질문이 있으면 마지막에 제시한다.

이 프롬프트는 Claude를 "전지적 답변자"가 아니라 "문서 증거를 해석하는 분석가"로 만든다. RAG에서 모델의 역할은 모든 것을 기억하는 것이 아니라, 검색된 근거를 읽고 질문에 맞게 조합하는 것이다.

다국어 문서에서는 번역보다 용어 일관성이 먼저다

한국 기업의 문서 작업은 대개 다국어다. 본사는 영어 계약서를 보내고, 국내 팀은 한국어 검토 의견을 작성한다. 일본 지사 매뉴얼을 한국어로 번역해야 하고, EU 규정 원문을 한국 내부 정책에 반영해야 한다. 이때 Claude는 번역과 요약을 동시에 잘 수행할 수 있지만, 다국어 작업에는 특별한 함정이 있다.

가장 큰 문제는 용어 일관성이다. 같은 영어 단어가 문맥에 따라 다르게 번역될 수 있고, 반대로 서로 다른 영어 단어가 한국어에서는 같은 단어로 번역될 수 있다. 예를 들어 retention은 보존, 유지, 보유로 번역될 수 있다. processing은 처리, 가공, 프로세싱으로 옮길 수 있다. controller와 processor는 개인정보 문맥에서는 각각 개인정보처리자와 처리수탁자에 가까운 법적 의미를 가질 수 있지만, 일반 IT 문맥에서는 컨트롤러와 프로세서로 읽힐 수 있다.

다국어 문서 작업에서는 먼저 용어표를 만들어야 한다.

첨부한 영어 문서를 한국어로 요약하기 전에 핵심 용어표를 만들어 줘.

열은 다음과 같이 구성하라.
- 원문 용어
- 권장 한국어 번역
- 문맥상 의미
- 등장 위치
- 번역 시 주의점

특히 법률, 개인정보, 보안, 회계 관련 용어는 일반 번역과 전문 번역이 다를 수 있으므로 표시해 줘.

용어표가 생기면 이후 번역과 요약의 품질이 안정된다. 긴 문서를 번역하다 보면 앞에서는 retention을 "보존"으로, 뒤에서는 "보유"로 옮기는 일이 생긴다. 사람이 읽을 때는 작은 차이처럼 보이지만 법무 문서에서는 큰 차이가 될 수 있다.

번역 검토 프롬프트는 다음처럼 쓴다.

아래 한국어 번역문을 원문과 대조해 검토해 줘.

검토 기준:
1. 빠진 문장이나 빠진 조건이 있는가?
2. 의미가 반대로 바뀐 표현이 있는가?
3. must, shall, may, should의 강도가 적절히 번역되었는가?
4. except, unless, provided that 같은 예외 조건이 유지되었는가?
5. 핵심 용어가 용어표와 일관되는가?
6. 한국어 문장은 자연스럽지만 원문보다 과도하게 의역되지 않았는가?

출력은 문제 유형, 원문, 번역문, 수정 제안, 심각도로 정리해 줘.

법률·계약 문서에서는 조동사가 중요하다. shall과 may를 모두 "한다"로 번역하면 의무와 재량이 섞인다. commercially reasonable efforts를 "상업적으로 합리적인 노력"이라고 직역할지, "상업적으로 합리적인 범위의 노력"이라고 풀지에 따라 문장이 달라진다. Claude에게 이런 차이를 보게 하려면 "자연스럽게 번역해 줘"보다 "법적 강도와 조건을 보존해 줘"라고 말해야 한다.

다국어 요약에서도 원문 대조가 필요하다. 한국어 요약만 읽으면 편하지만, 중요한 결론에는 원문 표현을 함께 남기는 것이 좋다.

이 표는 번역의 신뢰도를 높인다. 특히 정책·법무 담당자는 한국어 요약만으로 결재하기 어렵다. 원문 표현이 함께 있으면 검토 속도가 빨라지고 오해가 줄어든다.

한국어 문서에서 자주 생기는 문제

한국어 문서는 영어 문서와 다른 난점이 있다. 첫째, 주어가 자주 생략된다. "처리한다", "보관한다", "파기한다"라고 쓰여 있지만 누가 하는지 문맥으로 읽어야 하는 경우가 많다. 둘째, 긴 명사구가 많다. "개인정보 처리 업무 위탁 계약에 따른 수탁자의 안전성 확보조치 이행 여부" 같은 표현은 구조를 풀어야 이해된다. 셋째, 법령·공공문서에는 한자어와 고정 표현이 많다.

Claude에게 한국어 문서를 읽힐 때는 생략된 주체와 조건을 복원하게 하는 질문이 유용하다.

이 한국어 정책 문서에서 각 의무 조항을 추출해 줘.
각 조항에 대해 다음을 표시하라.
- 의무를 지는 주체
- 해야 하는 행위
- 적용 조건
- 기한
- 예외
- 근거 문장

주어가 생략된 경우 문맥상 추정한 주체와 추정 근거를 함께 표시하라.

공공문서나 규정 문서에서는 정의 조항을 먼저 읽어야 한다. "이용자", "정보주체", "처리자", "수탁자", "제3자" 같은 용어는 문서마다 다르게 정의될 수 있다. Claude가 일반 상식으로 해석하면 틀릴 수 있다.

본문을 요약하기 전에 정의 조항을 먼저 추출해 줘.
이후 답변에서는 문서 내 정의를 우선 적용해 줘.
일반적인 의미와 문서 내 정의가 다르면 차이를 설명해 줘.

한국어 보고서에서는 수식어가 결론을 흐릴 때도 많다. "검토가 필요할 것으로 판단됨", "추진 가능성이 있음", "제한적으로 허용될 수 있음" 같은 표현은 강도가 다르다. Claude에게 결론의 강도를 분류하게 하면 의사결정에 도움이 된다.

문서의 주요 결론을 강도별로 분류해 줘.
- 확정: 문서가 명시적으로 단정함
- 가능성 높음: 근거가 강하지만 조건이 있음
- 검토 필요: 문서가 판단을 유보함
- 불확실: 근거가 부족함

각 결론에 원문 표현을 붙여 줘.

한국어 문서 처리에서 가장 좋은 습관은 "예쁜 요약"보다 "구조 복원"을 먼저 시키는 것이다. 누가, 무엇을, 언제, 어떤 조건에서, 무엇을 근거로 해야 하는지 뽑아내면 그다음 요약과 보고는 쉬워진다.

문서형 작업의 품질 점검표

Claude가 만든 문서 답변을 검토할 때는 문장만 보지 말고 품질 축을 나누어 보아야 한다. 좋은 답변은 유창한 답변이 아니라, 목적에 맞고 근거가 있으며 누락과 과장을 통제한 답변이다.

다음 점검표를 문서 작업의 마지막 단계에 붙이면 좋다.

이 점검을 Claude에게도 시킬 수 있다.

네가 방금 작성한 답변을 스스로 검토해 줘.
다음 기준으로 문제를 찾아라.
1. 근거가 없는 주장
2. 원문보다 강하게 표현한 주장
3. 누락 가능성이 있는 섹션
4. 숫자·날짜·고유명사 오류 가능성
5. 사용자가 원문에서 다시 확인해야 할 항목

문제가 있으면 답변을 수정하라.

자기 검토는 만능이 아니지만 도움이 된다. 특히 "원문보다 강하게 표현한 주장"을 찾게 하면 과잉 요약을 줄일 수 있다. 예를 들어 원문은 "may terminate"라고 했는데 답변이 "해지해야 한다"라고 쓰면 심각한 오류다. 이런 강도 차이는 문서 검토에서 자주 발생한다.

중요 문서는 사람의 검토 단계를 반드시 남겨야 한다. Claude가 1차 추출과 비교, 누락 점검을 맡으면 사람은 더 높은 수준의 판단에 집중할 수 있다. 하지만 최종 서명, 법률 판단, 재무 공시, 안전 지침, 의료·금융 의사결정은 사람이 책임져야 한다. Claude의 역할은 검토자를 대체하는 것이 아니라, 검토자가 놓칠 수 있는 부분을 더 빨리 드러내는 것이다.

API 설계: 문서 입력을 제품 기능으로 만들 때

개인 사용자는 Claude 앱에 파일을 올리고 질문하면 된다. 개발자는 한 단계 더 생각해야 한다. 제품 안에서 문서 질의응답 기능을 만들려면 파일 업로드, 문서 파싱, 권한, 검색, 인용, 로그, 삭제 정책을 모두 설계해야 한다.

가장 단순한 흐름은 사용자가 업로드한 PDF를 Claude에 직접 전달하고 답변을 받는 것이다. 프로토타입에는 충분하다. 하지만 운영 제품에서는 보통 다음 구조가 필요하다.

파일 업로드
-> 바이러스 검사와 파일 형식 확인
-> 텍스트/이미지 추출 또는 원본 보관
-> 문서 메타데이터 저장
-> 페이지·섹션 단위 인덱싱
-> 사용자 질문 수신
-> 관련 페이지/조각 검색
-> Claude 호출
-> 인용 포함 답변 반환
-> 로그와 감사 기록 저장

여기서 문서 메타데이터는 답변 품질과 보안 모두에 중요하다.

{
  "document_id": "doc_2026_05_13_001",
  "title": "2026 서비스 이용계약서 초안",
  "owner_team": "legal",
  "classification": "confidential",
  "language": "ko",
  "version": "v0.9",
  "uploaded_at": "2026-05-13T09:30:00+09:00",
  "allowed_users": ["user_123", "user_456"]
}

Claude에게 문서 내용을 보낼 때 이 메타데이터 일부를 함께 전달하면 좋다. 예를 들어 문서 버전이 초안인지 최종본인지 알면 답변 표현이 달라진다. 기밀 문서라면 외부 공유 가능한 문구를 만들 때 주의해야 한다. 다만 개인정보나 비밀정보를 불필요하게 프롬프트에 넣어서는 안 된다. 다음 장들에서 보안과 컴플라이언스를 더 자세히 다루겠지만, 문서형 제품은 처음부터 데이터 흐름을 그려야 한다.

문서 질의응답 API의 응답은 자연어만 반환하지 않는 편이 좋다. UI에서 근거를 보여 주고, 사용자가 원문으로 이동하고, 품질 점검을 자동화하려면 구조화된 응답이 필요하다.

{
  "answer": "계약 종료 후 고객 데이터는 원칙적으로 30일 이내 삭제되지만, 법령상 보존 의무가 있는 경우 예외가 있습니다.",
  "citations": [
    {
      "document_id": "msa_2026_customer_a",
      "page": 14,
      "section": "7.2",
      "quote": "계약 종료 후 회사는 고객 데이터를 30일 이내 삭제한다...",
      "supports": "30일 이내 삭제 원칙"
    },
    {
      "document_id": "msa_2026_customer_a",
      "page": 14,
      "section": "7.2",
      "quote": "단, 관련 법령상 보존 의무가 있는 경우...",
      "supports": "법령상 보존 예외"
    }
  ],
  "confidence": "medium",
  "needs_human_review": true,
  "follow_up_questions": [
    "관련 법령상 보존 의무의 구체적 범위는 별도 법무 검토가 필요합니다."
  ]
}

구조화된 응답은 UI와 운영에 도움이 된다. citations는 원문 뷰어와 연결할 수 있고, needs_human_review는 승인 워크플로우로 보낼 수 있다. confidence는 사용자에게 답변의 한계를 보여 준다. 다만 신뢰도 점수는 절대적인 확률이 아니다. "높음"이라고 해서 검토가 필요 없다는 뜻이 아니며, "낮음"이라고 해서 쓸모없다는 뜻도 아니다. 제품에서는 신뢰도보다 "왜 검토가 필요한가"를 함께 보여 주는 편이 낫다.

문서와 검색 기능의 실패 패턴

문서형 AI 시스템은 비슷한 방식으로 실패한다. 실패 패턴을 미리 알면 프롬프트와 제품 설계를 더 안전하게 만들 수 있다.

첫 번째 실패는 요약에 의한 삭제다. 모델은 중요한 내용을 짧게 줄이면서 예외와 조건을 빼기 쉽다. "계약 종료 후 30일 이내 삭제"라고 요약했지만, 원문에는 "백업 시스템에서는 90일 이내 삭제"라는 예외가 있을 수 있다. 해결책은 예외만 따로 찾게 하는 것이다.

앞선 요약에서 빠졌을 수 있는 예외, 단서, 적용 제외 조건만 다시 찾아 줘.
"단", "다만", "except", "unless", "provided that" 같은 표현을 우선 확인해 줘.

두 번째 실패는 근거와 결론의 거리 증가다. Claude가 관련 문단을 근거로 붙였지만 결론은 그 문단보다 한 발 더 나아간다. 정책 문서가 "검토할 수 있다"고 했는데 답변은 "승인된다"고 말하는 식이다. 해결책은 근거 적합성 검토다.

세 번째 실패는 표와 본문 불일치 무시다. 본문은 "전년 대비 증가"라고 쓰지만 표는 특정 세그먼트에서 감소를 보여 줄 수 있다. 또는 본문은 전체 평균을 말하고 표는 지역별 편차를 보여 준다. 해결책은 본문 주장과 표 데이터를 대조시키는 것이다.

본문의 주요 주장과 표/그림의 데이터가 일치하는지 검토해 줘.
일치, 부분 일치, 불일치, 판단 불가로 분류해 줘.

네 번째 실패는 검색 결과의 권위 혼동이다. 오래된 블로그 글과 최신 공식 문서를 같은 무게로 다루면 잘못된 답이 나온다. 해결책은 출처 유형과 날짜를 메타데이터로 전달하고, 우선순위 규칙을 명시하는 것이다.

다섯 번째 실패는 번역으로 인한 법적 강도 변화다. may가 "해야 한다"로, shall이 "할 수 있다"로 바뀌면 계약 해석이 달라진다. 해결책은 원문 핵심 표현을 함께 남기고, 조동사와 예외 조건을 따로 점검하는 것이다.

여섯 번째 실패는 이미지에서 보이지 않는 것을 본 것처럼 말하기다. 스크린샷만 보고 "관리자 권한이 없다"고 단정하거나, 사진만 보고 "부품이 파손되었다"고 확정하는 경우다. 해결책은 관찰·추정·확인 필요를 분리하는 것이다.

이 실패 패턴들은 단순한 주의사항이 아니다. 평가셋을 만들 때 그대로 테스트 항목이 된다. 9장에서 평가와 회귀 테스트를 다루겠지만, 문서형 시스템의 평가는 "요약이 자연스러운가"보다 "예외를 놓치지 않았는가", "근거가 결론을 지지하는가", "숫자가 맞는가"를 봐야 한다.

바로 가져다 쓰는 문서 작업 프롬프트

다음 템플릿들은 실무에서 바로 변형해 쓸 수 있다. 그대로 붙여 넣기보다 문서 종류, 실패 비용, 출력 형식을 자신의 업무에 맞게 바꾸는 것이 좋다.

계약서 리스크 검토

첨부한 계약서를 고객사/공급사 관점에서 검토해 줘.
관점: {우리 회사의 위치: 고객사 또는 공급사}
목적: 서명 전 주요 리스크 확인

중점 검토 항목:
- 계약 기간과 자동 갱신
- 요금, 지급, 연체
- 해지와 해지 후 의무
- 데이터 처리, 보안, 개인정보
- 지식재산권
- 비밀유지
- 책임 제한과 손해배상
- 준거법과 분쟁 해결

출력 형식:
항목 | 관련 조항/페이지 | 원문 요지 | 리스크 | 수정 제안 | 심각도 | 확인 필요

규칙:
근거 없는 추정은 하지 말라.
예외와 단서 조항을 반드시 확인하라.
수정 제안은 협상 문구 초안으로 작성하되, 법률 자문이 필요할 수 있음을 표시하라.

보고서 핵심 주장 검증

첨부한 보고서의 핵심 주장을 검증해 줘.

작업:
1. 보고서가 말하는 핵심 주장 5~10개를 추출한다.
2. 각 주장에 대한 근거 표, 그림, 문단을 찾는다.
3. 근거가 충분한지 평가한다.
4. 과장되었거나 근거보다 강한 표현을 찾는다.
5. 의사결정자가 추가로 확인해야 할 질문을 제시한다.

출력:
주장 | 근거 위치 | 근거 강도 | 문제점 | 더 안전한 표현 | 추가 확인 질문

논문 읽기

첨부한 논문을 연구 검토 관점에서 읽어 줘.

출력 순서:
1. 연구 질문
2. 핵심 기여
3. 방법론
4. 데이터셋과 평가 지표
5. 주요 결과
6. 표와 그림별 해석
7. 저자가 인정한 한계
8. 독자가 추가로 의심해야 할 한계
9. 재현에 필요한 정보가 충분한지

규칙:
논문에 없는 주장은 만들지 말라.
성능 수치는 표/그림 번호와 함께 제시하라.
저자의 주장과 네 해석을 구분하라.

매뉴얼에서 작업 절차 만들기

첨부한 매뉴얼을 현장 작업자가 사용할 절차서로 바꿔 줘.

반드시 포함할 것:
- 작업 전 준비물
- 안전 경고
- 단계별 작업 순서
- 각 단계의 완료 확인 기준
- 흔한 오류와 해결 방법
- 작업 중단이 필요한 위험 신호
- 원문 페이지

주의:
안전 관련 경고를 생략하지 말라.
그림이나 표에만 있는 정보도 확인하라.
확실하지 않은 단계는 현장 확인 필요로 표시하라.

스크린샷 UI 리뷰

첨부한 UI 스크린샷을 분석해 줘.

먼저 다음을 나누어 적어라.
1. 이미지에서 직접 보이는 요소
2. 화면 목적에 대한 추정
3. 이미지로는 확인할 수 없는 요소

그다음 사용성 문제를 찾아라.
문제별로 사용자 영향, 개선 제안, 확인이 필요한 실제 동작을 정리해 줘.

다국어 계약 번역 검토

아래 원문과 번역문을 대조해 검토해 줘.

중점:
- 의무와 권한의 강도: shall, must, may, should
- 예외 조건: except, unless, provided that, notwithstanding
- 기한과 기간
- 금액과 비율
- 정의된 용어의 일관성
- 누락된 문장 또는 추가된 의미

출력:
문제 유형 | 원문 | 번역문 | 문제 설명 | 수정 제안 | 심각도

문서형 Claude 사용의 마지막 원칙

문서, PDF, 이미지, 검색 결과를 다루는 Claude의 힘은 "많이 읽는다"에 있지 않다. 진짜 힘은 사람이 놓치기 쉬운 구조를 빠르게 드러내고, 근거를 따라가며, 질문을 쪼개고, 검토 가능한 초안을 만드는 데 있다.

그러나 문서형 작업에는 늘 책임이 따른다. 계약서 요약은 협상 판단에 영향을 준다. 매뉴얼 요약은 안전에 영향을 줄 수 있다. 검색 기반 규제 요약은 정책 결정에 영향을 준다. 이미지 분석은 품질 판단이나 현장 조치에 연결될 수 있다. 그래서 문서형 Claude 사용의 마지막 원칙은 단순하다.

답변을 믿기 전에, 답변이 어디에 발을 딛고 있는지 확인하라.

PDF에서는 페이지와 조항을 확인한다. 표에서는 행·열·단위·각주를 확인한다. 차트에서는 축과 스케일을 확인한다. 이미지에서는 관찰과 추정을 나눈다. 검색에서는 출처와 날짜를 확인한다. 번역에서는 원문 표현과 용어 일관성을 확인한다. 인용은 그 모든 확인의 길잡이다.

다음 장에서는 이 근거 기반 작업을 더 큰 시스템 설계로 확장한다. 단일 문서를 읽는 수준을 넘어, 문서 저장소를 만들고, 검색과 라우팅을 붙이고, 사람 검토를 워크플로우에 넣고, 실패를 격리하는 Claude 시스템 패턴을 살펴볼 것이다.

참고

¹Anthropic PDF support

²Anthropic citations

³Anthropic vision

⁴Anthropic citations

⁵Anthropic search results

⁶Anthropic web search tool