파일 입력과 긴 문서 처리

긴 문서를 그대로 넣지 않는 이유

짧은 질문은 그대로 모델에 보내도 됩니다. 하지만 PDF 보고서, 회의록, 책 원고처럼 긴 문서는 다릅니다. 긴 글을 한 번에 넣으면 네 가지 문제가 생깁니다.

첫째, 모델이 받을 수 있는 입력 길이에는 한도가 있습니다. 이를 보통 컨텍스트 윈도우라고 부릅니다. 문서가 이 한도를 넘으면 일부 내용을 잘라야 합니다.

둘째, 비용이 커집니다. AI API는 대체로 입력 토큰과 출력 토큰을 기준으로 비용이 계산됩니다. 읽을 필요 없는 부록, 반복 문장, 목차까지 모두 보내면 그만큼 돈을 더 씁니다.

셋째, 핵심 정보가 묻힙니다. 긴 문서를 넣었다고 해서 모델이 모든 문장을 같은 비중으로 기억하는 것은 아닙니다. 질문과 관련 없는 내용이 많으면 중요한 근거를 놓칠 수 있습니다.

넷째, 응답이 느려집니다. 입력이 길수록 처리 시간이 늘어나고, 사용자는 결과를 기다리다 이탈할 수 있습니다. 긴 문서 AI 기능의 핵심은 "많이 넣기"가 아니라 "나누고, 추적하고, 다시 합치기"입니다.

파일 업로드의 기본 흐름

서비스에서는 보통 PDF, Markdown, 텍스트 파일을 업로드받습니다. 흐름은 단순합니다.

1. 클라이언트에서 파일을 선택합니다.

2. 서버 API로 multipart/form-data 형식으로 보냅니다.

3. 서버에서 파일 크기와 확장자를 검사합니다.

4. 텍스트를 추출합니다.

5. 원본 파일은 저장하거나, 처리 후 삭제합니다.

6. 추출한 텍스트를 조각으로 나눕니다.

중요한 점은 파일 처리를 서버에서 통제해야 한다는 것입니다. API Key를 보호해야 하고, 파일 크기 제한, 악성 파일 검사, 사용자별 권한 확인도 서버에서 처리해야 합니다. 클라이언트에서 미리보기나 간단한 사전 검사를 할 수는 있지만, 최종 검증과 모델 호출은 서버가 담당해야 안전합니다.

작은 서비스라면 업로드 파일을 임시 디렉터리에 저장한 뒤 처리해도 됩니다. 운영 서비스라면 S3 같은 객체 저장소에 원본을 저장하고, DB에는 파일명, 사용자 ID, 상태, 생성 시간을 기록하는 방식이 안전합니다.

const fileRecord = {
  id: "file_123",
  userId: "user_1",
  name: "report.pdf",
  status: "processing",
  createdAt: new Date()
};

문서는 조각으로 나누어야 한다

텍스트를 추출한 뒤에는 문서를 분할합니다. 이때 아무 기준 없이 3,000자씩 자르면 문장이 끊기고 의미가 흐려질 수 있습니다. 가능하면 제목, 문단, 목록, 장 구분 같은 의미 단위를 먼저 사용합니다. 그래도 너무 길면 일정 길이 기준으로 다시 나눕니다.

각 조각에는 반드시 추적 정보를 붙입니다.

const chunk = {
  documentId: "file_123",
  chunkIndex: 4,
  title: "시장 분석",
  text: "...",
  source: {
    page: 12,
    startOffset: 5300,
    endOffset: 6900
  }
};

이 정보가 있어야 나중에 "이 요약은 원문 어디에서 나온 것인가?"를 확인할 수 있습니다. AI 결과를 신뢰하게 만드는 것은 멋진 문장이 아니라 추적 가능한 근거입니다.

Map-Reduce 요약 전략

긴 문서를 요약할 때 자주 쓰는 방식이 Map-Reduce입니다. 이름은 어렵지만 원리는 간단합니다.

Map 단계에서는 각 조각을 따로 요약합니다. 조각마다 핵심 주장, 중요한 수치, 등장 인물, 실행 항목을 뽑습니다.

Reduce 단계에서는 조각별 요약을 다시 모아 전체 요약을 만듭니다. 이때 단순히 이어 붙이면 안 됩니다. 반복 내용은 합치고, 서로 충돌하는 내용은 표시하고, 전체 구조에 맞게 재배열해야 합니다.

예를 들어 보고서 요약 기능이라면 결과를 다음처럼 설계할 수 있습니다.

{
  "summary": "전체 요약",
  "keyQuestions": ["검토해야 할 질문"],
  "actionItems": ["실행할 일"],
  "tags": ["시장", "비용", "전략"]
}

이 구조는 Structured Outputs와 JSON 응답 설계에서 다룬 JSON 응답 설계와 연결됩니다. 긴 문서 처리에서도 최종 결과는 사람이 읽기 좋은 문장과 프로그램이 저장하기 좋은 구조를 함께 가져야 합니다.

긴 책을 요약 노트로 바꾸기

실습으로 긴 책이나 보고서를 요약 노트로 바꾸는 기능을 생각해 봅시다.

먼저 파일을 업로드받고 텍스트를 추출합니다. 다음으로 장 제목을 기준으로 문서를 나눕니다. 장 구분이 없다면 일정 길이로 나누되, 문단 중간에서 끊지 않도록 조정합니다.

각 조각에 대해 모델에게 다음 작업을 맡깁니다.

• 핵심 내용 5줄 요약

• 중요한 개념 목록

• 독자가 던질 만한 질문 3개

• 실행 항목 또는 적용 아이디어

• 태그 3~5개

마지막으로 장별 결과를 모아 전체 노트를 생성합니다. 전체 노트에는 책의 한 줄 요약, 전체 목차, 핵심 주제, 반복해서 등장하는 개념, 독서 후 실천할 일을 포함합니다.

이 방식의 장점은 실패 범위가 작다는 것입니다. 한 조각 요약이 실패해도 전체 작업을 처음부터 다시 할 필요가 없습니다. 해당 조각만 재시도하면 됩니다. 또한 조각별 결과를 DB에 저장하면 사용자가 나중에 특정 장만 다시 요약하거나 질문할 수도 있습니다.

긴 문서 AI 기능은 결국 파이프라인입니다. 업로드하고, 추출하고, 나누고, 요약하고, 다시 합칩니다. 이 흐름을 만들 수 있으면 단순 챗봇을 넘어 문서 기반 AI 서비스를 만들 수 있습니다.