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

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

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

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

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

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

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

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

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

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

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

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

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

• 비용: 입력 토큰 단가 × 토큰 수 (선형)
• Latency: 토큰 수에 거의 비례 (선형)
• Attention 연산: 토큰 수 제곱 (KV cache 적용해도 인상)

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

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

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

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

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

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

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

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

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

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

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

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

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

import anthropic

client = anthropic.Anthropic()

SYSTEM = """당신은 마케팅 데이터 분석 어시스턴트.
출력은 항상 한국어 자유 산문 1-2단락."""

def build_context(query, brand_guide, campaigns_data, examples):
    return f"""<brand_guide>
{brand_guide}
</brand_guide>

<campaigns_data>
{campaigns_data}
</campaigns_data>

<examples>
{examples}
</examples>

<question>
{query}
</question>"""

resp = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=600,
    system=SYSTEM,
    messages=[{"role": "user",
               "content": build_context(query, brand_guide,
                                        campaigns_data, examples)}],
)

XML 태그로 컨텍스트 영역을 명시적으로 구분. 모델이 <question> 태그 안의 핵심 질문에 attention을 집중하고, 다른 태그들은 참조용으로 활용합니다. 같은 정보라도 태그 없는 자유 산문보다 회수 정확도가 한 단계 높습니다.

8. 컨텍스트가 너무 길어졌을 때

위 5가지 원칙을 다 적용해도 컨텍스트가 100k+로 커질 수밖에 없는 자리가 있습니다(예: 100쪽 보고서 분석). 그때의 옵션.

8-1. 청크 단위 처리 + 합치기

100쪽을 10페이지씩 청크로 나눠 각 청크별 요약을 LLM에 시킨 뒤, 그 요약들을 다시 모아 최종 답변. 단계가 많아지지만 각 단계의 컨텍스트는 짧음.

8-2. 1시간 캐시 활용

같은 base 컨텍스트(100쪽 보고서)에 여러 질문을 던질 때 Prompt caching 1시간 캐시 적용. 첫 호출만 비싸고 그 이후는 1/10 가격.

8-3. 큰 컨텍스트 모델 vs RAG 결정

대부분의 마케팅 자동화는 RAG가 적합. 큰 컨텍스트 모델은 특수한 자리(법률 문서, 긴 회의록)에 한정.

9. 마치며 — 긴 컨텍스트의 운영 책임

긴 컨텍스트는 새로운 가능성이지만 새로운 책임도 따라옵니다. 단순히 “다 넣자”는 비용·정확도·latency 모두에 손해. 5가지 원칙(처음·끝 배치, 다이어트, RAG, 구조화 형식, 위치별 역할 분담)을 분기에 한 번씩 점검하면 LLM 자동화의 운영 안정성이 한 단계 올라갑니다.

다음 분기에 한 번만 시도해 볼 만한 것은 가장 컨텍스트가 긴 자동화 한 자리에 5가지 원칙 적용 ON/OFF 비교를 돌려 답변 품질·비용 차이를 정량화하는 흐름입니다.

다음에 읽을 글

• Prompt caching — 긴 컨텍스트의 비용 90% 절감
• 트랜스포머 직관 — lost-in-the-middle의 attention 근거
• RAG 평가 — 긴 컨텍스트 vs RAG 비교

참고

• Liu et al. (2023), “Lost in the Middle”: https://arxiv.org/abs/2307.03172
• Anthropic, “Long context tips”: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/long-context-tips
• “Needle in a haystack” benchmark: https://github.com/gkamradt/LLMTest_NeedleInAHaystack
• Anthropic, “Use XML tags for prompts”: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/use-xml-tags
• “RULER: What’s the Real Context Size of Your Long-Context Language Models” (Hsieh et al., 2024): https://arxiv.org/abs/2404.06654