컨텍스트 윈도우: AI가 한 번에 들고 다니는 작업 기억

컨텍스트 윈도우 뜻: 한 줄 정의#

모델이 참조할 수 있는 작업 맥락은 학습 데이터나 영구 기억과 다릅니다. 아래는 Anthropic의 컨텍스트 윈도우 설명과 Mirr Code의 컨텍스트 안내를 바탕으로 정리했습니다. 확인일: 2026-11-02.

1. 수정할 기능과 관련 파일, 오류 메시지 중 필요한 부분을 먼저 지정합니다.
2. 비밀번호와 개인정보를 제외하고, 긴 로그는 문제를 재현하는 부분만 선택합니다.
3. 긴 대화에서는 중요한 결정과 제약을 확인해 요약하고, 누락된 조건과 결과를 다시 검토합니다.

왜 중요한가: 한국 개발자 기준#

큰 저장소 전체를 무작정 넣으면 관련 없는 내용이 중요한 단서를 가릴 수 있습니다. 큰 윈도우는 더 많은 자료를 담을 수 있게 하지만, 자료를 잘 선택하거나 정확하게 해석한다는 보장은 아닙니다.

예제: 코드나 터미널로 보기#

로그인 오류라면 전체 저장소 대신 오류 메시지의 민감하지 않은 부분과 해당 화면·인증 처리 파일, 관련 테스트를 지정해 보세요. Mirr Code 문서는 입력창에서 파일을 @로 선택하고 긴 대화를 /compact로 요약하는 방법을 안내합니다. 이는 사용 안내이며 실행 기록이 아닙니다.

관련 용어#

앞서 링크한 컨텍스트·토큰 계산 문서를 적용한 진단표이며 실측 결과는 아닙니다. 모델별 스펙 비교와 한도 도달 로그는 아직 필요합니다.

토큰과 비용은 사용량 단위와 과금을, 에이전트 하네스는 모델에 파일과 도구를 연결하는 환경을 설명합니다.

저장소 질문을 위한 맥락 묶음 만들기#

로그인 오류를 조사한다면 오류 문장만으로는 부족할 수 있습니다. 어느 화면에서 어떤 순서로 발생하는지, 기대한 결과는 무엇인지, 관련 파일과 테스트는 어디에 있는지 함께 전달합니다. 그렇다고 로그인과 관계없는 문서와 과거 대화까지 모두 붙일 필요는 없습니다. 질문을 이해하는 데 필요한 자료와 단지 가까이 있는 자료를 구분하세요. 모델이 읽을 수 있는 최대량과 이번 과제에 필요한 양은 다릅니다.

자료마다 역할을 붙이면 충돌을 발견하기 쉽습니다. 현재 코드, 과거 설계, 수정 요청, 관찰한 오류를 구분해 적으세요. 예전 문서가 현재 코드와 다른데 어느 쪽이 실제 기준인지 알 수 없으면 모델이 오래된 계약을 따라갈 수 있습니다. 파일 경로와 기준 버전도 같이 남기면 나중에 결과가 바뀐 이유를 조사할 수 있습니다. 긴 설명보다 출처와 시점이 분명한 짧은 근거가 먼저 필요할 때가 있습니다.

긴 문맥에서는 위치가 답을 바꾼다#

"Lost in the Middle" 연구는 긴 입력에서 관련 정보의 위치만 바꿔도 언어 모델의 성능이 크게 떨어질 수 있다고 보고했습니다. 여러 문서에서 답을 찾는 질문과 키-값 검색 과제에서, 관련 정보가 입력의 처음이나 끝에 있을 때 성능이 흔히 가장 높았고, 긴 문맥의 중간에 있을 때는 크게 떨어졌습니다. 연구는 이 현상이 긴 문맥을 명시적으로 지원하는 모델에서도 나타난다고 밝혔습니다.

Anthropic의 맥락 엔지니어링 글은 같은 문제를 주의 예산이라는 말로 설명합니다. 컨텍스트 토큰이 늘수록 그 안의 정보를 정확히 떠올리는 능력이 떨어지는 현상을 컨텍스트 부패(context rot)라고 부르고, 컨텍스트는 한계 효용이 점점 줄어드는 한정된 자원이라고 봅니다. 같은 글은 새 토큰이 들어올 때마다 그 주의 예산이 조금씩 줄어든다고도 설명합니다. 그래서 목표는 결과에 필요한 고신호 토큰을 가장 적게 고르는 것이며, 한도가 크다는 사실이 이 선택을 대신해 주지는 않습니다.

긴 자료는 앞에 두고 질문은 뒤에 두기#

Anthropic의 긴 문맥 프롬프트 안내는 2만 토큰 이상의 큰 문서나 데이터를 다룰 때, 긴 자료를 프롬프트 위쪽에 두고 질문과 지시는 그 아래에 두라고 권합니다. 이 배치가 모든 모델에서 성능을 높인다고 설명하며, 여러 문서가 섞인 복잡한 입력에서는 질문을 끝에 둘 때 시험에서 응답 품질이 최대 30퍼센트 나아졌다고 소개합니다.

같은 안내는 긴 문서를 다룰 때 먼저 관련 구절을 인용하게 한 뒤 답하도록 요청하는 방법도 제시합니다. 인용을 먼저 고르면 모델이 관련 내용에 집중하고 나머지 문서를 무시하기 쉬워진다고 설명합니다. 저장소 질문이라면 "관련 함수 세 곳을 먼저 인용하고, 그다음 원인을 설명해 줘"처럼 단계를 나눠 요청할 수 있습니다. 여러 문서를 넣을 때는 문서마다 태그로 감싸고 출처 같은 메타데이터를 하위 태그로 붙이라는 권고도 같은 안내에 있습니다. 출처가 함께 있으면 서로 충돌하는 자료를 찾기도 쉬워집니다.

윈도우를 차지하는 것과 요금에 잡히는 것#

Anthropic의 컨텍스트 윈도우 문서는 요청에 들어간 모든 것이 윈도우에 계산된다고 설명합니다. 시스템 프롬프트, 메시지 안의 도구 결과와 이미지와 문서, 도구 정의가 여기에 포함됩니다. 프롬프트 캐싱을 쓰면 입력이 input_tokens, cache_read_input_tokens, cache_creation_input_tokens로 나뉘는데, 세 값 모두 윈도우에 계산됩니다. 같은 문서는 캐시된 접두사가 여전히 윈도우를 차지하며, 캐싱은 비용을 바꿀 뿐 토큰이 계산되는지를 바꾸지 않는다고 명시합니다. 이전 턴의 사고 블록이 윈도우에 남는지도 모델에 따라 다릅니다. 어떤 모델은 이전 사고 블록을 API가 자동으로 제거하고, 어떤 모델은 기본으로 유지해 윈도우에 계산합니다.

이 차이는 설계에 직접 영향을 줍니다. 같은 자료를 캐시로 싸게 반복 전달하더라도 그 자료가 모델의 주의 예산을 계속 차지한다는 사실은 그대로입니다. 관련 없는 긴 자료를 캐시에 넣는 것은 요금 문제이면서 동시에 맥락 품질의 문제입니다.

도구 정의가 차지하는 공간 줄이기#

Anthropic의 컨텍스트 윈도우 문서는 도구 정의도 입력으로 계산된다는 점을 짚고, 정의 자체가 쓰는 공간을 줄이는 방법을 따로 안내합니다. 도구 목록을 관리해 필요한 도구만 노출하거나, 도구 검색 도구로 정의를 미뤄 두고 필요할 때 불러오는 방식이 그 예입니다. 도구를 많이 붙인 설정이라면 대화 내용보다 먼저 도구 정의가 윈도우를 채우고 있는지 확인해 보세요.

한계를 넘으면 API가 보이는 신호#

Anthropic 문서는 한계 도달을 두 경우로 나눠 설명합니다. 입력 자체가 컨텍스트 윈도우를 넘으면 모든 모델에서 400 invalid_request_error와 "prompt is too long" 오류가 반환됩니다. 4.5 세대 이후 모델에서는 입력과 max_tokens의 합이 윈도우를 넘어도 요청이 받아들여지고, 생성 도중 한계에 닿으면 stop_reason이 model_context_window_exceeded로 끝납니다. 그 이전 모델은 검증 오류를 반환합니다.

따라서 한계 가까이에서 작업할 때는 응답의 stop_reason과 오류 원문을 먼저 보세요. 같은 문서는 요청을 보내기 전에 토큰 계산 API로 사용량을 추정하라고 권합니다. 이것은 API 요청의 처리 결과에 관한 설명이며, 한계에 닿았을 때 파일이 지워지는지와는 다른 문제입니다.

같은 문서는 Claude Sonnet 계열과 Claude Haiku 4.5 등에 컨텍스트 인식이라는 기능이 있다고 설명합니다. 이 모델들은 대화 중에 남은 토큰 예산을 추적하며, 요청의 시스템 프롬프트에 전체 윈도우 크기가 주어집니다. 남은 공간을 추측하지 않고 실제 예산에 맞춰 긴 작업을 나누게 하려는 기능입니다.

앞선 제약이 사라지는 이유#

같은 문서는 claude.ai 같은 채팅 인터페이스가 윈도우를 먼저 들어온 메시지부터 밀어내는 방식(first in, first out)으로 관리할 수 있다고 주석으로 밝힙니다. 이 방식에서는 대화 초반에 정한 제약이 오래된 메시지로 밀려날 수 있습니다. 그러므로 중요한 제약은 한 번 말하고 끝내지 말고, 작업 단계가 바뀔 때마다 다시 적어 두는 것이 안전합니다.

맥락 압축이 잃기 쉬운 것#

Anthropic의 맥락 엔지니어링 글은 압축을 긴 대화를 요약해 새 윈도우로 옮기는 기법으로 설명하면서, 무엇을 남기고 버릴지 고르는 것이 핵심이라고 말합니다. 너무 공격적으로 요약하면 나중에야 중요해지는 미묘한 맥락이 사라질 수 있으므로, 먼저 재현율을 최대로 높이고 그다음 불필요한 내용을 걷어내 정밀도를 올리라고 권합니다. 같은 글은 도구를 메시지 기록 깊숙이에서 호출했다면 에이전트가 원본 결과를 다시 볼 필요가 있는지 묻고, 도구 결과를 비우는 것을 가장 안전한 가벼운 압축 형태로 꼽습니다.

API에는 서버가 요약을 만드는 압축 기능도 있습니다. Anthropic의 압축 문서는 오래된 턴을 서버에서 작성한 요약으로 바꾸고, 최근 턴을 원문 그대로 남기는 옵션도 소개합니다. 다만 2026-11-03 확인 시점의 문서에서 이 기능들은 베타로 표시되어 있어, 실제 사용 전에 지원 모델과 플랫폼을 확인하세요.

같은 압축 문서는 응답 품질이 대화가 길어질수록 떨어지기 때문에 압축으로 활성 컨텍스트를 작게 유지한다고 설명합니다. 압축을 실행하는 시점도 정할 수 있습니다. 사용자가 요청을 보내서 직접 실행하는 방식이 있고, 입력 토큰이 설정한 임계값에 닿을 때 API가 일반 요청 안에서 실행하는 방식도 있습니다. 온디맨드 압축에는 요약이 도착할 때까지 작업을 계속하게 하는 백그라운드 옵션도 있습니다. 도구 결과나 사고 블록을 요약하지 않고 규칙으로 지우는 방식은 문서에서 컨텍스트 편집(context editing)으로 따로 다룹니다.

메모와 하위 에이전트로 문맥 밖에 두기#

같은 글은 구조화된 메모도 소개합니다. 에이전트가 주기적으로 윈도우 밖의 메모리에 노트를 남기고, 필요할 때 그 노트를 다시 윈도우로 가져오는 방식입니다. 하위 에이전트를 쓰면 메인 에이전트는 고수준 계획을 들고 있고, 각 하위 에이전트가 깨끗한 윈도우에서 세부 작업을 맡고, 탐색에 수만 토큰을 쓰더라도 상위 에이전트에게는 보통 1,000~2,000토큰 정도의 압축된 요약만 돌려준다고 설명합니다. 상위 대화가 탐색 과정의 잡음으로 채워지지 않는 구조입니다. 같은 글은 이 패턴이 복잡한 리서치 과제에서 단일 에이전트 시스템보다 뚜렷이 나은 결과를 보였다고 소개합니다.

직접 적용하려면 저장소 작업마다 현재 목표, 결정한 사항, 아직 열린 질문을 메모 파일에 남기고 새 대화를 시작할 때 그 파일을 먼저 읽히는 방법이 가능합니다. 메모가 오래되었거나 틀리면 모델은 틀린 기준을 따를 수 있으므로, 각 메모에 작성 날짜와 근거 파일을 함께 적어 두세요.

필요한 자료를 단계적으로 드러내기#

Anthropic의 맥락 엔지니어링 글은 에이전트가 자료를 스스로 찾아가게 하면 점진적 노출(progressive disclosure)이 가능하다고 설명합니다. 에이전트는 탐색하면서 맥락을 조금씩 얻고, 다음 결정에 필요한 만큼만 작업 기억에 남깁니다. 같은 글은 파일 크기가 복잡도를, 이름 규칙이 목적을, 타임스탬프가 관련성을 어느 정도 드러낼 수 있다고 말합니다.

저장소 질문에서도 모든 파일을 미리 붙이기보다 어떤 파일을 열지 단서를 주고 단계적으로 읽게 하는 편이 맞을 때가 있습니다. 예를 들어 오류 문구와 화면 이름을 먼저 주고, 그 단서에 맞는 파일 두세 개를 고르게 한 뒤, 그 결과를 보고 다음 파일을 읽게 하는 방식입니다. 첫 단계에서 고른 파일과 이유를 기록하면 나중에 빠진 자료를 찾기도 쉽습니다.

Mirr에서 파일과 변경 사실 알리기#

Mirr Code 문서는 파일을 지정하면 비슷한 이름의 다른 화면을 고치는 일을 줄일 수 있다고 설명합니다. 한글 파일명도 입력해 검색할 수 있다고 안내합니다. 작업 방향이 바뀌었을 때는 "디자인은 그대로 두고 로그인 오류만 고쳐 줘"처럼 바뀐 조건을 설명하라고 권합니다.

같은 문서는 다른 프로그램에서 파일을 수정했다면 그 사실도 함께 알려 주라고 안내합니다. 대화 중에 읽은 파일 내용과 실제 파일이 달라질 수 있으므로, 외부 수정을 알리지 않으면 오래된 내용을 근거로 판단할 수 있습니다. 이 점을 작업 시작 메시지에 한 줄로 적어 두세요.

컨텍스트에 얼마나 많이 넣을지는 과제의 성격보다, 그 과제가 어떤 정보를 계속 참고해야 하는가에 따라 달라집니다. 같은 저장소에서 여러 파일을 계속 대조하는 작업은 입력이 커지고, 한 번에 끝나는 짧은 수정은 적게 쓰집니다. 이 차이를 '창이 클수록 좋다'로 읽지는 않습니다. 참고해야 할 정보를 좁히면 모델이 실제로 다루는 입력의 크기도 함께 줄어듭니다.

다음에 읽을 것#

한국어와 영어의 같은 뜻 문장에 대한 토큰 수는 여기서 아직 측정하지 않았습니다. 모델과 토크나이저마다 결과가 달라질 수 있으므로 실제 비교에는 대상 모델에 맞는 토크나이저와 비교할 문장을 사용해야 합니다. Anthropic의 토큰 계산 안내 확인일: 2026-11-02.

실제 계산 방법은 대상 모델의 토크나이저로 토큰 세기를 참고하세요. 단순 문자열의 계산값과 대화·도구를 포함한 입력, 실제 청구를 구분하는 절차이며 한·영 토큰 수를 측정한 결과는 아닙니다.

관련#

• 컨텍스트와 파일

편집 메모 (2026-11-02): 용량·기억·과금의 차이와 진단 질문을 보충했습니다. 한·영 토큰 수나 한계 도달 동작을 측정한 것으로 해석하지 마세요.