긴 문서 3분에 파악 — 요약·핵심추출·질문하기

회의록을 잡았으면, 문서 차례입니다

2장에서 회의를 통째로 붙잡았습니다. 이번엔 문서입니다. 20페이지 보고서, 30장짜리 계약서, 읽어야 할 논문. 다 읽을 시간은 없는데 내용은 알아야 하는 상황 말입니다.

AI에 문서를 그대로 올리면 3분이면 뼈대가 잡힙니다. 읽는 방식이 "처음부터 끝까지"에서 "필요한 것만 골라"로 바뀝니다.

이 장에서 다룰 네 가지

목적별 요약, 문서에 질문하기, 여러 문서 교차질문, 요약 검증. 앞 세 개가 속도를, 마지막 하나가 신뢰를 담당합니다.

문서를 어디에 올릴까

도구부터 정하고 갑니다. ChatGPT나 Claude에 파일을 올려 대화하는 게 가장 간단합니다. 문서가 한두 개고 그 자리에서 묻고 답할 거라면 이걸로 충분합니다.

여러 자료를 묶어 다뤄야 하거나 출처를 정확히 짚어야 하면 NotebookLM이 낫습니다. 구글이 만든 도구인데, 올린 자료 안에서만 답하고 어느 문서에서 나왔는지 인용을 붙여 줍니다.

얼마나 긴 문서까지 되나

길이 한계를 알아두면 낭패를 덜 봅니다. Claude는 한 번에 약 20만 토큰(대략 15만 단어)까지, 최신 Sonnet·Opus는 100만 토큰까지 읽습니다(Tygart Media, 2026). NotebookLM은 소스 하나당 최대 50만 단어, 무료 기준 노트북 하나에 소스 50개까지 담깁니다(Elephas, 2026).

파일 크기보다 길이가 진짜 벽

실무에서 걸리는 건 용량보다 길이입니다. Claude 유료 플랜은 파일당 30MB, 대화당 5개까지 올라가지만, 용량이 남아도 페이지가 길면 컨텍스트 한도에 먼저 닿습니다(Tygart Media, 2026). 긴 PDF 여러 개를 한꺼번에 올리면 앞쪽 문서를 조용히 놓치니, 아주 길면 나눠 올리는 편이 안전합니다.

같은 문서, 다른 요약

요약은 한 종류가 아닙니다. 누가 왜 읽느냐에 따라 달라야 합니다. AI에는 "무엇을 위한 요약인지"를 말해주면 됩니다. 목적을 안 정하고 "요약해줘"만 던지면 애매한 중간 길이가 나옵니다.

핵심만 빠르게 — 경영진용 요약

전체 그림만 잡으면 되는 상황이 있습니다. 이럴 땐 결론과 숫자 위주로 짧게 시킵니다.

이 보고서를 경영진용 3문장으로 요약해줘. 결론, 핵심 숫자, 다음 결정 사항 순서로. 배경 설명은 빼줘.

신제품 출시 보고서라면 "출시일 3주 지연, 예산 10% 초과, 매출 목표 유지"처럼 압축돼 나옵니다. 회의 직전 남이 쓴 문서를 훑을 때 제일 자주 씁니다.

실행 관점 — "내가 뭘 하면 되나"

같은 문서를 실무자 시선으로 다시 요약하게 하면 결론이 아니라 할 일이 나옵니다. "QA 일정 재조정, 마케팅 소재 마감 앞당기기"처럼요. 분량과 형식을 지정할수록 좋아집니다. "불릿 5개로", "표로 정리해서"를 붙이면 그대로 맞춰 줍니다.

반론 찾기 — 약한 데를 짚게

문서를 비판적으로 읽힐 수도 있습니다. 제안서나 기획안 검토에 특히 쓸모가 있습니다. "이 주장의 근거 중 약한 것", "빠진 반론", "경쟁사 대비 취약한 부분"을 뽑게 하면 사람이 놓치기 쉬운 구멍을 먼저 훑어 줍니다.

계약서라면 리스크 조항부터

계약서·제안서는 "위험 신호"를 먼저 찾게 하는 게 효율적입니다.

이 계약서에서 우리에게 불리할 수 있는 조항 3개를 찾아, 왜 불리한지 한 줄씩 설명해줘. 애매하게 해석될 표현도 짚어줘.

독소조항이나 빠진 항목을 먼저 걸러 줍니다. 최종 판단은 사람 몫이지만, 어디를 집중해 봐야 할지 길잡이가 생깁니다.

문서에 직접 물어보기

요약을 받는 것보다 한 발 더 나가면, 문서를 열어놓고 대화하듯 묻는 방식입니다. 전체를 훑지 않고 필요한 답만 콕 집어 꺼냅니다.

요약이 나은 때, 질문이 나은 때

둘은 쓰임이 다릅니다. 처음 보는 문서의 전체 그림이 필요하면 요약이 빠릅니다. 이미 대충 아는데 특정 정보만 확인하고 싶으면 질문이 낫습니다. 보통은 요약으로 뼈대를 잡고, 걸리는 부분을 질문으로 파고드는 순서가 잘 맞습니다.

특정 정보 콕 집어 묻기

"3분기 매출이 얼마였지?", "이 조건은 몇 페이지에 나와?" 처럼 구체적으로 물으면 됩니다.

이 문서에서 3분기 매출 수치를 찾아줘. 몇 페이지 몇 번째 표에 나오는지 위치도 같이 알려줘.

위치를 같이 물어두면 나중에 원문에서 직접 확인하기 편합니다.

근거를 강제하는 한 줄

문서에 없는 걸 지어내는 걸 막으려면, 답의 범위를 못 박는 문장을 붙입니다. 이 한 줄이 질문의 신뢰도를 가장 크게 좌우합니다.

본문에 근거해서만 답하고, 본문에 없는 내용이면 "문서에 없음"이라고 해. 추측하지 마.

grounding(올린 자료에 근거해 답하기)이라 부르는 방식입니다. 근거를 대라고 명시하면 그럴듯하게 지어내는 빈도가 눈에 띄게 줍니다.

답 위치를 되묻기

한 발 더 나가면, 받은 답을 다시 검증용으로 씁니다. "그 근거가 몇 페이지 어느 문장인지" 되물으면 원문 확인이 빨라지고, 위치를 못 대는 답은 걸러집니다.

여러 문서를 한꺼번에 다루기

문서 하나가 아니라 여러 개를 놓고 비교하거나 종합해야 할 때가 있습니다. 여기서 도구 선택이 갈립니다.

흩어진 자료를 하나로 묶기

자료가 여러 개면 NotebookLM이 편합니다. 보고서·회의록·논문을 한 노트북에 묶어 올리면, 그 안에서만 답하고 어느 문서 몇 페이지에서 나왔는지 인용을 붙여 줍니다. 흩어진 자료를 하나의 "물어볼 수 있는 자료집"으로 만드는 셈입니다.

문서끼리 교차질문하기

여러 자료를 함께 올리면 문서 사이를 넘나드는 질문이 됩니다. "A 보고서와 B 제안서의 예산 숫자가 어디서 어떻게 다르지?" 같은 걸 물으면 두 문서를 오가며 대조하던 일을 한 번에 처리합니다.

올린 세 문서에서 '출시 일정'을 각각 찾아 표로 비교해줘. 서로 어긋나는 부분이 있으면 표시하고, 어느 문서에서 나왔는지 함께 적어줘.

종합 요약 만들기

비교를 넘어 여러 자료를 하나로 엮을 수도 있습니다. "이 자료들을 종합해 한 페이지 브리핑으로"라고 시키면 흩어진 내용을 한 장으로 묶어 줍니다. 다만 이때가 환각이 끼기 쉬운 지점이라, 다음 절의 검증이 특히 중요합니다.

출처 인용이 왜 중요한가

여러 문서를 섞으면 "이 답이 어느 문서에서 나왔는지"가 흐려집니다. 인용을 붙여 주는 도구가 유리한 이유입니다. 출처가 표시되면 의심스러운 답을 원문에서 바로 확인할 수 있고, 없는 걸 끌어다 붙였는지도 티가 납니다.

요약을 믿기 전에

한 가지 조심할 게 있습니다. AI는 문서에 없는 내용을 그럴듯하게 지어내기도 합니다. 특히 숫자와 날짜에서요.

두 종류의 환각

환각은 크게 두 갈래입니다. 준 문서와 어긋나는 경우(계약서에 없는 조항을 있는 듯 요약), 어디에도 없는 사실을 지어내는 경우(가짜 통계·인용). GPT-4o에 의료 기록 50건을 500단어로 요약시킨 실험에서 21건에 잘못된 정보가, 50건에 원문에 없던 일반화가 섞였습니다(Nature Scientific Reports, 2025).

숫자·날짜·고유명사부터 대조

그래서 중요한 요약일수록 원문과 대조하는 습관이 필요합니다. 전부 확인할 수 없으면 숫자·날짜·사람 이름부터 봅니다. 여기가 환각이 가장 잘 끼는 자리입니다.

방금 요약에서 나온 숫자·날짜·고유명사를 원문 어디에 나오는지 하나씩 짚어줘. 원문에서 못 찾은 항목이 있으면 따로 표시해.

근거를 못 대면 의심하기

근거를 대라고 했는데 "본문에 없음"이라고 답하거나 위치를 못 짚으면, 그 문장은 지어냈을 확률이 높습니다. 요약을 그대로 공유하기 전에 이 한 번의 대조가 큰 사고를 막습니다.

공유 전 마지막 한 줄

내보내기 직전엔 요약 자체를 원문과 다시 맞춰 보게 합니다. 이 검증 습관은 8장에서 자주 틀리는 유형과 함께 따로 정리합니다.

이 요약이 원문의 뜻을 왜곡하거나 없는 내용을 더한 곳이 있는지 확인해줘. 있으면 어느 문장인지 표시하고 원문 근거를 붙여줘.

이 장에서는 긴 문서를 목적별로 요약하고, 직접 질문하고, 여러 문서를 교차로 다루고, 그 결과를 검증하는 흐름을 봤습니다. 여기까지가 "읽기"의 자동화입니다. 다음 챕터에서는 읽는 것을 넘어 보고서·기획서 초안을 AI로 만들고 스스로 다듬게 하는 "쓰기"를 다루겠습니다.