컨텍스트는 '모델이 지금 보는 것' 전체다
LLM에게 컨텍스트란 대화의 분위기나 배경지식만을 뜻하지 않는다. 추론 시점에 모델 입력으로 들어가는 전체 토큰 집합이다. 여기에는 시스템 메시지, 개발자 지시, 사용자 질문, 이전 대화 기록, 검색된 문서, 예시, 도구 설명, 도구 호출 결과, 출력 형식 제약까지 모두 포함된다. Anthropic은 컨텍스트 엔지니어링을 "추론 중 LLM에 제공되는 토큰 집합을 관리하는 전략"으로 설명한다.1
중요한 점은 사용자의 질문이 전체 컨텍스트에서 아주 작은 비중만 차지하는 경우가 많다는 것이다. 예를 들어 사용자가 "환불 규정 알려줘"라고 묻는 순간, 실제 모델이 받는 입력은 다음처럼 훨씬 클 수 있다.
시스템 지시: "너는 사내 정책 어시스턴트다."
안전 규칙: "문서에 없는 내용은 추측하지 말라."
대화 기록: 사용자의 부서, 이전 요청, 이미 확인한 조건
검색 결과: 환불 정책 문서 일부
도구 설명: 문서 검색 도구, 고객 조회 도구의 사용법
도구 결과: 실제 검색된 문단
사용자 질문: "환불 규정 알려줘."
모델은 이 전체를 하나의 입력으로 보고 다음 토큰을 생성한다. 그래서 컨텍스트 설계의 핵심 질문은 "프롬프트를 어떻게 예쁘게 쓸까?"가 아니라 "이번 답변을 만들기 전에 모델이 무엇을 보아야 하는가?"다.
토큰: LLM이 읽는 최소 단위
LLM은 글자를 사람처럼 읽지 않는다. 입력 문장을 토큰이라는 단위로 쪼개 읽는다. 토큰은 단어일 수도 있고, 단어의 일부일 수도 있고, 기호일 수도 있다. 영어에서는 대략 한 토큰이 0.75단어 정도로 설명되지만, 언어와 토크나이저에 따라 달라진다. 한국어, 일본어, 중국어처럼 공백 기준 단어 구분이 영어와 다른 언어는 같은 의미를 표현해도 토큰 수가 다르게 나올 수 있다.
토큰은 세 가지 측면에서 중요하다.
첫째, 비용의 단위다. 대부분의 LLM API는 입력 토큰과 출력 토큰을 기준으로 과금한다. 둘째, 용량의 단위다. 컨텍스트 윈도우는 모델이 한 번에 처리할 수 있는 최대 토큰 수로 표시된다. 셋째, 주의의 단위다. 모델은 각 토큰이 다른 토큰과 어떤 관계를 갖는지 계산하면서 다음 토큰을 만든다.
따라서 "문서 세 개만 넣었다"는 말은 충분하지 않다. 실제로는 "몇 토큰을 넣었고, 그중 중요한 정보가 어디에 배치되었는가"가 더 중요하다.
컨텍스트 윈도우는 작업대이지 창고가 아니다
컨텍스트 윈도우는 모델이 한 번의 호출에서 볼 수 있는 토큰의 최대 범위다. 과거에는 수천 토큰이 일반적이었지만, 지금은 수십만 토큰이나 백만 토큰 이상을 지원하는 모델도 있다. 이 때문에 많은 사람이 "그냥 모든 문서를 넣으면 되지 않을까?"라고 생각한다.
하지만 컨텍스트 윈도우가 커진다고 성능이 자동으로 좋아지지는 않는다. 긴 입력에서는 두 가지 문제가 생긴다.
첫째, 관련 정보가 묻힌다. 모델은 긴 입력 전체를 완벽하게 균등하게 활용하지 못한다. Lost in the Middle 연구는 다중 문서 질의응답과 키-값 검색 과제에서, 관련 정보가 입력의 앞이나 끝에 있을 때보다 중간에 있을 때 성능이 크게 떨어질 수 있음을 보였다.2 이를 흔히 lost in the middle이라고 부른다.
둘째, 컨텍스트 로트(context rot)가 생긴다. 이 말은 긴 입력이 쌓일수록 모델의 출력 품질이 떨어지거나 일관성이 약해지는 현상을 가리키는 실무적 표현에 가깝다. 원인은 단순히 "모델이 멍청해진다"가 아니다. 불필요한 정보, 비슷하지만 관련 없는 정보, 오래된 대화, 중복된 문서가 모두 같은 창 안에서 경쟁하기 때문이다. Chroma의 long-context 평가도 단순한 needle-in-a-haystack 테스트를 넘어 실제적인 장기 컨텍스트 상황에서는 입력 길이와 방해 정보가 성능에 비균일한 영향을 줄 수 있음을 보여준다.6
그래서 긴 컨텍스트는 창고가 아니라 작업대에 가깝다. 작업대가 넓으면 큰 일을 할 수 있지만, 관련 없는 서류를 잔뜩 쌓아두면 오히려 필요한 문서를 찾기 어려워진다.
어텐션은 모든 토큰 관계를 계산하려 한다
현대 LLM의 핵심 구조는 트랜스포머이고, 트랜스포머의 중심에는 어텐션(attention)이 있다. 어텐션은 각 토큰이 다른 토큰을 얼마나 참고해야 하는지 계산하는 메커니즘이다. 원 논문인 Attention Is All You Need는 이 구조가 긴 시퀀스 안의 관계를 병렬적으로 학습할 수 있음을 보여주었다.3
쉽게 말해, 모델이 "그 회사의 환불 정책은…"이라는 답변을 만들 때 "그 회사"가 무엇을 가리키는지, "환불 정책"이 어떤 문서와 연결되는지, 앞에서 사용자가 말한 조건이 무엇인지 토큰 간 관계를 통해 계산한다.
문제는 이 계산이 공짜가 아니라는 점이다. 입력 토큰 수가 늘어나면 토큰 사이의 가능한 관계도 빠르게 늘어난다. 단순화하면 토큰 수가 두 배가 될 때 어텐션 계산량은 네 배에 가까워질 수 있다. 실제 시스템에서는 다양한 최적화가 들어가지만, 긴 컨텍스트가 더 비싸고 느려지는 기본 이유는 여기에 있다.
이때 유용한 개념이 어텐션 예산이다. 모델이 볼 수 있는 토큰 수가 많아도, 모든 토큰에 같은 품질의 주의를 기울일 수 있는 것은 아니다. 중요한 정보와 중요하지 않은 정보가 같은 입력 안에 있으면, 불필요한 토큰도 모델의 계산과 판단에 영향을 준다. 즉 토큰을 많이 넣는 것은 단지 비용을 늘리는 일이 아니다. 모델의 주의를 분산시키는 일이기도 하다.
긴 컨텍스트의 실제 비용: 돈, 시간, 품질
컨텍스트가 길어질수록 세 가지 비용이 함께 증가한다.
첫째, 금전 비용이다. 입력 토큰이 많으면 호출당 비용이 증가한다. 대화형 에이전트에서는 더 심각하다. 이전 대화와 도구 결과가 매 턴 다시 들어가면, 오래된 정보에도 매번 비용을 지불하게 된다.
둘째, 지연시간이다. 긴 입력은 첫 토큰이 나오기 전까지의 시간, 즉 TTFT(time to first token)를 늘린다. 모델은 답변을 시작하기 전에 입력을 처리하고 내부 상태를 준비해야 한다.
셋째, 품질 비용이다. 관련 없는 문서가 많으면 모델은 답변의 근거를 잘못 고르거나, 서로 충돌하는 정보를 섞거나, 핵심 조건을 놓칠 수 있다. 특히 "혹시 필요할지도 모르니 넣자"는 습관은 RAG 시스템과 에이전트에서 자주 실패를 만든다.
좋은 컨텍스트는 짧기만 한 컨텍스트가 아니다. 현재 작업에 필요한 고신호 토큰만 남긴 컨텍스트다. 어떤 작업은 긴 원문 전체가 필요하다. 법률 계약서 전체의 조항 간 충돌을 보려면 긴 컨텍스트가 유리할 수 있다. 반대로 사내 규정 하나를 찾는 질의응답에서는 관련 문단 몇 개만 넣는 편이 더 정확하고 싸다.
KV 캐시: 모델이 이미 읽은 토큰을 다시 계산하지 않게 하는 장치
LLM은 응답을 한 번에 통째로 쓰지 않는다. 토큰을 하나씩 생성한다. 이때 매번 이전 모든 토큰의 정보를 다시 계산하면 너무 느리다. 그래서 추론 시스템은 보통 KV 캐시(Key-Value cache)를 사용한다.
어텐션에서 각 토큰은 Query, Key, Value라는 벡터로 변환된다. 새 토큰을 생성할 때 이전 토큰들의 Key와 Value는 변하지 않는다. KV 캐시는 이 값을 저장해 두었다가 다음 생성 단계에서 재사용한다. 즉, 이미 읽은 토큰의 일부 계산 결과를 메모리에 보관하는 방식이다.4
KV 캐시는 속도를 크게 높인다. 하지만 대가가 있다. 메모리를 많이 쓴다. 컨텍스트가 길어질수록 캐시에 저장해야 할 Key와 Value도 늘어난다. 특히 긴 컨텍스트를 여러 사용자가 동시에 요청하면, GPU 메모리의 큰 부분이 모델 가중치가 아니라 KV 캐시에 묶인다. 그래서 긴 컨텍스트 모델을 운영할 때는 "모델이 몇 토큰까지 지원하는가"뿐 아니라 "그 길이에서 몇 명을 동시에 처리할 수 있는가"를 봐야 한다.
이 구조는 컨텍스트 설계에 직접적인 영향을 준다. 불필요한 토큰은 입력 비용만 늘리는 것이 아니라, KV 캐시 메모리도 차지한다. 따라서 프로덕션 시스템에서는 토큰 절약이 곧 처리량, 응답 속도, 인프라 비용의 문제로 이어진다.
안정적인 접두사와 프롬프트 캐싱
LLM 호출의 앞부분에는 자주 반복되는 정보가 들어간다. 예를 들어 시스템 지시, 출력 형식, 안전 규칙, 도구 설명, 제품 정책 요약 같은 것들이다. 이런 고정된 앞부분을 안정적인 접두사(stable prefix)로 설계하면 운영상 큰 이점이 생긴다.
많은 추론 시스템과 API 제공자는 프롬프트 캐싱 또는 prefix caching을 지원한다. 같은 접두사가 반복되면 그 부분의 처리 결과를 재사용해 비용과 지연시간을 줄이는 방식이다. KV 캐시 관점에서 보면, 공통 접두사의 Key와 Value를 매번 새로 계산하지 않고 공유하거나 재활용하는 최적화에 가깝다.5
이 때문에 컨텍스트 배치 순서가 중요해진다.
자주 바뀌지 않는 시스템 지시와 공통 규칙은 앞쪽에 둔다.
요청마다 달라지는 사용자 질문과 검색 결과는 뒤쪽에 둔다.
캐시 가능한 접두사 중간에 매번 바뀌는 값을 끼워 넣지 않는다.
도구 설명도 모든 도구를 항상 넣기보다, 필요한 도구만 선택적으로 넣는다.
예를 들어 다음 구조는 캐시에 불리하다.
[시스템 지시]
[사용자별 동적 정보]
[공통 도구 설명]
[공통 출력 규칙]
[질문]사용자별 정보가 중간에 들어가면 그 뒤의 공통 내용도 매번 다른 접두사가 된다. 반면 다음 구조는 더 낫다.
[시스템 지시]
[공통 출력 규칙]
[공통 도구 설명]
[사용자별 동적 정보]
[검색 결과]
[질문]앞부분이 안정적으로 유지되기 때문이다. 이는 단순한 정리 습관이 아니라 비용 최적화 전략이다.
모델이 놓치기 쉬운 것을 기준으로 설계하라
컨텍스트 엔지니어링은 모델의 강점보다 약점을 먼저 이해해야 잘할 수 있다. LLM은 많은 토큰을 처리할 수 있지만, 모든 정보를 같은 안정성으로 사용하지 못한다. 긴 입력의 중간을 놓칠 수 있고, 불필요한 정보에 주의가 분산될 수 있으며, 오래된 대화나 도구 결과를 계속 들고 가면 비용과 오류가 함께 늘어난다.
따라서 실무의 기본 원칙은 단순하다.
모델이 반드시 따라야 할 규칙은 명확하고 안정적인 위치에 둔다.
질문에 필요한 정보만 선택해 넣는다.
긴 기록은 요약하거나 단계별로 나눈다.
중요한 정보가 긴 입력의 한가운데 묻히지 않게 한다.
반복되는 접두사는 캐시 가능하도록 고정한다.
컨텍스트 길이는 "최대치"가 아니라 "업무에 필요한 적정치"로 잡는다.
컨텍스트 윈도우는 LLM의 작업 기억이다. 작업 기억은 클수록 좋을 때도 있지만, 잘 정리되어 있을 때 더 강력하다. 다음 장부터 살펴볼 컨텍스트의 구성 요소와 설계 원칙은 모두 이 사실에서 출발한다. 모델이 무엇을 볼 수 있고, 무엇을 놓치기 쉬운지 알아야 비로소 좋은 컨텍스트를 만들 수 있다.
참고
1Effective context engineering for AI agents
2Lost in the Middle: How Language Models Use Long Contexts
5The KV Cache: The Hidden Bottleneck of Long-Context LLMs
6Context Rot: How Increasing Input Tokens Impacts LLM Performance
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.