DEV Community

Cover image for Context engineering — 200k 토큰 컨텍스트의 설계 원칙 5가지
HyunSeok Jeong
HyunSeok Jeong

Posted on • Originally published at blog.trysitely.com

Context engineering — 200k 토큰 컨텍스트의 설계 원칙 5가지

Claude Sonnet은 200k 토큰, GPT-5는 1M 토큰까지 컨텍스트를 받습니다. 보고서 한 권을 통째로 넣고 질문할 수 있다는 뜻입니다. 그런데 실제 운영해보면 함정이 보입니다 — 중간 부분의 정보를 모델이 자주 놓치고, 비용은 길이 제곱으로 늘고, 정작 답변 정확도가 컨텍스트 짧을 때보다 떨어집니다. 긴 컨텍스트를 잘 쓰는 건 따로 설계 원칙이 필요합니다.

마케터가 이 글을 읽어야 하는 이유: RAG 챗봇·보고서 자동화·캠페인 분석 등 LLM 자동화의 거의 모든 자리에서 컨텍스트가 길어지는 압력이 있습니다. 단순히 "다 넣자"가 아니라 어떤 정보를 어디에 배치할지의 설계 한 줄이 답변 품질·비용 둘 다 결정합니다.

200k 토큰 컨텍스트 안에서 처음·끝의 정보가 강하게 attention 받고 중간이 흐려지는 lost-in-the-middle 현상 다이어그램
긴 컨텍스트는 새 차원의 문제를 만든다. 처음·끝·중간의 attention 분포가 다르다.

1. Lost-in-the-middle — 가장 큰 함정

긴 컨텍스트를 처음 써보면 가장 빨리 마주치는 현상입니다.

모델이 컨텍스트 처음·끝의 정보를 잘 보고, 중간 정보는 약하게 본다.

트랜스포머 직관에서 다룬 것처럼 attention이 모든 토큰을 같은 강도로 보지 않습니다. 학습 데이터에서 처음·끝 토큰이 정답에 자주 등장한 패턴이 모델에 박혀 있어, 100k 토큰의 중간에 핵심 정보를 두면 잘 못 찾습니다.

정보 위치 회수 정확도 (평균)
처음 10% 90%+
처음 30% 70-80%
중간 50% 50-60%
끝 30% 70-80%
끝 10% 85%+

NIAH (Needle In A Haystack) 벤치마크에서 일관되게 관찰되는 패턴. 모델·버전마다 차이가 있지만 큰 흐름은 비슷.

📌 이 글의 전제

독자가 LLM·RAG·프롬프트라는 단어를 일상으로 쓰고, 트랜스포머의 attention 직관 정도는 받아들인다고 가정합니다. 코드를 직접 짠 적 없어도 됩니다.

2. 원칙 1 — 핵심 정보는 처음과 끝에

가장 단순하고 강력한 원칙. 사용자 질문·핵심 지시는 시스템 프롬프트의 시작 또는 사용자 메시지의 끝에 배치합니다.

좋은 구조 나쁜 구조
[시스템 핵심 지시] [컨텍스트 문서들] [사용자 질문] [컨텍스트 문서들] [시스템 지시 중간] [사용자 질문]

배경 컨텍스트(few-shot 예시·참고 문서)는 중간으로. 핵심 정보가 처음과 끝에 자리잡으면 lost-in-the-middle 영향을 줄입니다.

3. 원칙 2 — 컨텍스트 다이어트

200k가 가능하다고 200k를 다 쓸 이유는 없습니다. 컨텍스트 길이는 비용·latency·정확도 셋 다에 영향을 줍니다.

CostTin,LatencyTin,Attention computeTin2 \text{Cost} \propto T_{\text{in}}, \quad \text{Latency} \propto T_{\text{in}}, \quad \text{Attention compute} \propto T_{\text{in}}^2
  • 비용: 입력 토큰 단가 × 토큰 수 (선형)
  • Latency: 토큰 수에 거의 비례 (선형)
  • Attention 연산: 토큰 수 제곱 (KV cache 적용해도 인상)

8k → 4k 절반으로 줄이면 비용 절반, latency 절반, attention 연산 1/4. 동시에 lost-in-the-middle 감소. 모든 차원에서 이득.

💡 다이어트 첫 시도

현재 컨텍스트의 절반을 제거해도 답변 품질이 큰 차이가 없는 자리가 80% 이상입니다. 골든셋 50개로 절반 다이어트 ON/OFF 비교를 한 번 돌려보면 자리에 따라 어떻게 다른지 명확해집니다.

4. 원칙 3 — RAG로 동적 선택

코퍼스가 크면 벡터 검색으로 관련 문서를 동적 선택해 컨텍스트에 넣는 RAG가 표준 패턴입니다.

사용자 질문
    │
    ▼
벡터 검색 → Top 5 문서 선택
    │
    ▼
선택된 5개만 컨텍스트로 LLM에 전달
Enter fullscreen mode Exit fullscreen mode

전체 코퍼스를 통째로 넣지 않고 관련 5개만 동적 선택. 컨텍스트 다이어트가 자동으로 일어남. RAG 품질 개선은 RAG 평가RAG 재순위에서 다룹니다.

5. 원칙 4 — 구조화된 형식 활용

긴 컨텍스트라도 구조화된 형식이면 모델이 정보를 더 잘 회수합니다.

형식 효과
자유 산문 가장 약함
Markdown 헤딩 중간
YAML/JSON 구조 강함
XML 태그 가장 강함 (Anthropic 권장)

XML 태그로 컨텍스트의 각 영역을 명시적으로 구분하면 모델이 "이 부분은 회사 정책, 저 부분은 사용자 데이터"를 분명히 인식합니다. Claude는 XML 형식에 특히 강하게 학습되어 있어 컨텍스트 회수 정확도가 한 단계 올라갑니다.

6. 원칙 5 — 위치별 역할 분담

긴 컨텍스트의 위치별 역할을 명확히 잡으면 효율이 올라갑니다.

위치 역할
시스템 프롬프트 시작 핵심 지시·역할·톤
시스템 프롬프트 중간 제약·스타일 가이드
시스템 프롬프트 끝 출력 형식 명시
사용자 메시지 시작 컨텍스트 문서
사용자 메시지 중간 Few-shot 예시
사용자 메시지 끝 핵심 질문·요청

이 구조를 표준 템플릿으로 박아두면 새 자동화에 적용할 때 헷갈리지 않습니다. 각 자리의 역할이 분명하니 lost-in-the-middle도 줄어듭니다.

7. 코드 한 묶음 — 컨텍스트 구조 템플릿

이게 글에 박는 유일한 코드입니다. Anthropic XML 태그 활용 패턴.


python
Enter fullscreen mode Exit fullscreen mode

Top comments (0)