MS Copilot은 왜 긴 문서의 중간 내용을 놓칠까? (Lost in the Middle)

8월 06, 2025

Lost in the Middle 현상과 실무 대응 방법

Microsoft Copilot이나 GitHub Copilot을 사용하다 보면 긴 문서를 다룰 때 이상한 현상을 경험할 수 있습니다. 문서의 앞부분과 끝부분은 비교적 잘 반영하는데, 정작 중간에 있는 중요한 내용은 빠뜨리거나 약하게 반영하는 경우입니다.

이 현상은 흔히 Lost in the Middle이라고 불립니다. 특정 제품만의 오류라기보다는, 긴 입력을 처리하는 대규모 언어모델(LLM) 전반에서 관찰되는 한계에 가깝습니다.

Lost in the Middle이란?

Lost in the Middle은 언어모델이 긴 입력을 처리할 때, 관련 정보가 어디에 위치하는지에 따라 성능이 달라지는 현상을 말합니다.

대표적인 연구에서는 다중 문서 질의응답과 키-값 검색 과제를 통해 다음과 같은 경향을 확인했습니다.

  • 관련 정보가 입력의 앞부분에 있을 때 성능이 높다.
  • 관련 정보가 입력의 끝부분에 있을 때도 성능이 비교적 높다.
  • 관련 정보가 입력의 중간에 있을 때 성능이 떨어지는 경향이 있다.
  • 긴 컨텍스트 처리를 목적으로 설계된 모델에서도 이 문제가 완전히 사라지지는 않는다.

즉, 컨텍스트 창이 길다고 해서 모델이 문서 전체를 균등하게 이해한다고 볼 수는 없습니다. 긴 문서를 넣을 수 있는 능력과, 그 안의 모든 정보를 안정적으로 찾아 쓰는 능력은 별개의 문제입니다.

사람의 기억과 비슷한가?

이 현상은 인간의 기억 연구에서 말하는 Serial Position Effect와 비슷하게 설명되기도 합니다.

Serial Position Effect는 크게 두 가지로 나뉩니다.

  • Primacy Effect, 초두 효과: 처음 제시된 정보를 더 잘 기억하는 경향
  • Recency Effect, 최신 효과: 마지막에 제시된 정보를 더 잘 기억하는 경향

LLM에서도 입력의 앞부분이나 끝부분에 있는 정보가 더 강하게 반영되는 경향이 관찰됩니다. 다만 사람의 기억과 완전히 같은 원리라고 단정해서는 안 됩니다. LLM은 사람처럼 기억하는 것이 아니라, 입력 토큰 간의 관계와 패턴을 계산해 다음 출력을 생성하기 때문입니다.

따라서 블로그나 업무 문서에서는 “인간의 기억과 동일하다”보다는 “비슷한 위치 편향이 관찰된다” 정도로 표현하는 것이 더 안전합니다.

Microsoft Copilot에서도 왜 문제가 되는가?

Microsoft Copilot은 Word, PowerPoint, Excel, Teams, Outlook, SharePoint, OneDrive 등 Microsoft 365 데이터와 연결되어 업무 문서를 요약하거나 질의응답을 수행합니다.

하지만 긴 문서를 다룰 때는 다음과 같은 문제가 생길 수 있습니다.

  1. 문서 전체 요약에서 중간 장의 핵심 내용이 빠질 수 있다.
  2. 질문에 필요한 근거가 문서 중간에 있으면 답변이 부정확해질 수 있다.
  3. 여러 문서를 한 번에 참조할 때 일부 문서나 일부 구간이 과소 반영될 수 있다.
  4. Copilot이 답변은 그럴듯하게 하지만, 실제 근거 문서의 특정 내용을 놓칠 수 있다.

Microsoft 역시 긴 문서를 사용할 때는 문서를 나누거나, 구간별로 요약하거나, 참조할 범위를 명확히 하라고 안내합니다. 또한 LLM이 파일의 시작과 끝에 있는 내용을 더 우선시할 수 있어, 중간 내용이 덜 반영될 수 있다는 점도 언급하고 있습니다.

긴 문서를 Copilot에 맡길 때의 실무 전략

1. 문서를 작게 나누기

가장 현실적인 해결책은 긴 문서를 작은 단위로 나누는 것입니다.

예를 들어 100페이지짜리 보고서를 한 번에 요약시키기보다 다음처럼 나누는 것이 좋습니다.

  • 1장: 배경과 문제 정의
  • 2장: 시장 분석
  • 3장: 고객 요구사항
  • 4장: 실행 전략
  • 5장: 리스크와 대응 방안

그다음 각 장을 따로 요약하고, 마지막에 “각 장 요약을 통합해 전체 요약을 만들어줘”라고 요청하는 방식이 더 안정적입니다.

2. 중요한 정보를 앞이나 끝에 재배치하기

Copilot에게 반드시 반영시켜야 하는 조건, 기준, 결론은 문서 중간에만 두지 않는 것이 좋습니다.

특히 다음 정보는 문서 앞부분이나 요청 프롬프트에 다시 적어주는 편이 안전합니다.

  • 핵심 결론
  • 판단 기준
  • 반드시 지켜야 할 제약 조건
  • 제외해야 할 범위
  • 중요한 숫자나 일정
  • 의사결정에 필요한 근거

예를 들어 다음처럼 요청할 수 있습니다.

아래 문서에서 특히 3장 ‘고객 요구사항’과 5장 ‘리스크 대응 방안’을 중심으로 요약해줘.
중간 장의 내용이 빠지지 않도록 각 장별 핵심 근거를 따로 정리해줘.

3. “전체 요약”보다 “구간별 요약”을 먼저 요청하기

긴 문서를 한 번에 요약하면 모델이 중요한 중간 내용을 생략할 가능성이 커집니다.

더 좋은 방식은 다음 순서입니다.

  1. 각 장 또는 섹션별 요약을 요청한다.
  2. 각 섹션에서 핵심 주장과 근거를 뽑게 한다.
  3. 누락된 부분이 없는지 확인한다.
  4. 마지막에 전체 요약본을 만든다.

예시 프롬프트는 다음과 같습니다.

이 문서를 바로 전체 요약하지 말고, 먼저 목차 기준으로 섹션을 나눠줘.
각 섹션마다 핵심 주장, 근거, 숫자 데이터, 리스크를 표로 정리해줘.
그다음 전체 내용을 500자 요약으로 다시 압축해줘.

4. 질문 범위를 명확히 지정하기

Copilot에게 “이 문서 요약해줘”라고만 요청하면 범위가 너무 넓습니다. 대신 무엇을 기준으로 읽어야 하는지 알려주는 것이 좋습니다.

좋은 프롬프트에는 보통 다음 요소가 들어갑니다.

  • 목표: 무엇을 만들 것인가?
  • 맥락: 왜 필요한가?
  • 출처: 어떤 문서나 범위를 볼 것인가?
  • 기대 형식: 표, 목록, 요약문, 보고서 등 어떤 형태로 받을 것인가?

예시는 다음과 같습니다.

이 문서를 임원 보고용으로 요약해줘.
목표는 의사결정에 필요한 쟁점만 빠르게 파악하는 것이야.
특히 2장 시장 분석, 4장 실행 전략, 5장 리스크를 중심으로 봐줘.
출력은 ‘핵심 결론 / 근거 / 리스크 / 다음 액션’ 표로 정리해줘.

5. GitHub Copilot에서는 컨텍스트를 명시하기

VS Code에서 GitHub Copilot Chat을 사용할 때는 # 멘션을 활용해 참조할 파일, 폴더, 심볼, 코드베이스를 명확히 지정할 수 있습니다.

예를 들어 다음처럼 요청할 수 있습니다.

#codebase 이 프로젝트에서 사용자 인증 흐름을 설명해줘.
#authService.ts #loginController.ts 로그인 실패 시 예외 처리가 일관적인지 검토해줘.
#selection 선택한 코드만 리팩터링해줘. 외부 동작은 바꾸지 말고 가독성만 개선해줘.

이렇게 하면 Copilot이 막연히 전체 프로젝트를 추측하는 대신, 사용자가 지정한 범위를 중심으로 응답할 가능성이 높아집니다.

문서 청킹도 중요하다

RAG나 벡터 검색을 사용하는 시스템에서는 긴 문서를 적절한 단위로 나누는 청킹(chunking) 전략이 중요합니다.

일반적인 방식은 다음과 같습니다.

방식 설명 장점
고정 크기 청크 일정한 글자 수나 단어 수로 문서를 나눔 구현이 쉽고 일관적
중첩 청크 청크 사이에 일부 내용을 겹치게 나눔 문맥 단절을 줄일 수 있음
구조 기반 청크 제목, 장, 절, 문단 기준으로 나눔 문서의 의미 구조를 보존하기 좋음
의미 기반 청크 내용의 의미 단위에 따라 나눔 검색과 요약 품질을 높이기 좋음

업무 문서에서는 단순히 글자 수 기준으로 자르기보다, 제목과 문단 구조를 기준으로 나누는 것이 더 효과적입니다. 특히 정책 문서, 제안서, 보고서처럼 구조가 중요한 문서는 “장·절 단위 청킹”이 유리합니다.

Copilot 사용 시 권장 프롬프트 패턴

긴 문서를 다룰 때는 다음과 같은 패턴을 활용할 수 있습니다.

문서 검토용

이 문서를 섹션별로 검토해줘.
각 섹션마다 핵심 주장, 근거, 누락된 정보, 모호한 표현을 표로 정리해줘.
문서 중간 부분의 내용도 빠뜨리지 말고 확인해줘.

요약용

전체 요약을 바로 만들지 말고, 먼저 목차 기준으로 장별 요약을 작성해줘.
그다음 장별 요약을 바탕으로 전체 요약을 5개 bullet로 압축해줘.

리스크 분석용

이 문서에서 의사결정에 영향을 줄 수 있는 리스크를 찾아줘.
특히 중간 섹션에 있는 조건, 예외, 제한사항을 우선적으로 확인해줘.
출력은 리스크 / 근거 위치 / 영향도 / 대응 방안 형식의 표로 정리해줘.

코드 검토용

#selection 이 코드의 오류 가능성, 예외 처리, 성능 문제를 검토해줘.
수정 코드를 바로 작성하기 전에 먼저 문제 목록과 수정 방향을 설명해줘.

결론

Lost in the Middle은 Microsoft Copilot만의 문제가 아니라, 긴 컨텍스트를 다루는 LLM 전반에서 나타나는 위치 편향 문제입니다.

Copilot을 더 안정적으로 사용하려면 다음 원칙을 지키는 것이 좋습니다.

  1. 긴 문서는 한 번에 처리하지 말고 나눈다.
  2. 중요한 정보는 프롬프트나 문서 앞부분에 다시 명시한다.
  3. 전체 요약 전에 구간별 요약을 먼저 만든다.
  4. 질문 범위와 출력 형식을 구체적으로 지정한다.
  5. GitHub Copilot에서는 파일, 폴더, 선택 영역, 코드베이스 등 컨텍스트를 명시한다.
  6. 결과를 그대로 믿지 말고 원문 근거와 대조한다.

AI가 긴 문서를 “읽을 수 있다”는 말은 문서 전체를 사람처럼 균등하게 이해한다는 뜻이 아닙니다. 긴 문서일수록 사용자가 범위와 맥락을 잘 설계해야 Copilot의 답변 품질도 높아집니다.

참고자료

  • Liu et al., “Lost in the Middle: How Language Models Use Long Contexts,” TACL, 2024. (https://arxiv.org/abs/2307.03172)
  • Guo and Vosoughi, “Serial Position Effects of Large Language Models,” 2024/2025.
  • Hämäläinen, “On Psychology of AI – Does Primacy Effect Affect ChatGPT and Other LLMs?”, NLP4DH, 2025.
  • Microsoft Support, “How reference and document lengths affect Copilot responses.”
  • Visual Studio Code Docs, “Manage context for AI.”
  • GitHub Docs, “Best practices for using GitHub Copilot.”
  • Microsoft Learn, “Chunk large documents for RAG and vector search in Azure AI Search.”

댓글 쓰기 · 수정

0 댓글