에이전트 시리즈 (22): 컨텍스트 엔지니어링 심층 분석 — 세 가지 컨텍스트 관리 전략의 정량적 비교

선형적 비용 문제 (The Linear Cost Problem)

에이전트(Agents)는 상태가 없는 (stateless) API 호출이 아닙니다. 대화 기록을 기억해야 합니다. 매 턴(turn)마다 컨텍스트 윈도우 (context window)에 데이터가 쌓이며, 결국 두 가지 문제가 발생합니다:

Turn 1:   ~1K tokens   ← 저렴함
Turn 10:  ~5K tokens   ← 관리 가능
Turn 50:  ~25K tokens  ← 비용 상승 중
...

이는 이론적인 이야기가 아닙니다. 30턴의 프로젝트 논의는 전체 기록에 약 2,500 토큰이 소요되며, 100턴이 지나면 그 숫자는 약 8,000으로 늘어납니다. 즉, 모든 교환마다 선형적으로 증가합니다.

이 문제에 대한 세 가지 일반적인 대응 방식은 다음과 같습니다:

전략 (Strategy)	접근 방식 (Approach)	직관적인 트레이드오프 (Intuitive trade-off)
Naive (단순 방식)	매번 전체 기록을 전달	비용이 많이 들지만, 정확함
...

이 기사에서는 직관적인 트레이드오프가 실제로 유효한지 테스트하기 위해 실제 수치를 사용하여 세 가지 전략 모두를 벤치마킹합니다.

데모 설계 (Demo Design)

대화 구성 (Conversation Construction)

데이터베이스 선택, 캐시 설정 (cache config), 마이그레이션 소유권, 배포 플랫폼, CI/CD, 인증 및 기타 24가지 기술적 결정을 다루는 30턴의 프로젝트 논의를 구성했습니다. 핵심 설계 선택: 중요한 결정 사항들을 가장 초기인 1~4턴에 배치하고, 최근 턴에는 덜 중요한 내용을 포함했습니다. 이는 컨텍스트 손실 (context-loss)로 인한 실패가 드러나도록 강제하기 위함입니다.

세 가지 전략 구현 (Three Strategy Implementations)

전략 1: Naive (기준점/baseline)

def run_naive(history: list, query: str, keywords: list[str]) -> StrategyResult:
    msgs = [SystemMessage(content=SYSTEM_PROMPT)] + history + [HumanMessage(content=query)]
    tokens = count_messages_tokens(msgs)
...

전략 2: Sliding Window (슬라이딩 윈도우/truncation)

def run_sliding_window(
    history: list, query: str, keywords: list[str], window: int = 12
) -> StrategyResult:
...

**전략 3: Rolling Summary (롤링 요약)

def summarize(messages: list) -> str:
    """대화 블록을 불렛 포인트 형태의 결정 목록으로 압축합니다."""
    text = "\n".join(
...

핵심 설계: cached_summary 파라미터를 통해 요약을 한 번만 생성하고 4개의 테스트 쿼리 전체에서 재사용할 수 있도록 했습니다. 따라서 38.2초의 생성 비용은 단 한 번만 지불됩니다.

테스트 쿼리 (모두 초기 결정 사항을 대상으로 함)

Query 1: 어떤 데이터베이스를 선택했나요? 소유자는 누구이며, 이유는 무엇인가요?
         Keywords: postgresql / timescaledb / david / acid / time-series

...

Recall (재현율) = 응답에서 발견된 키워드 수 / 전체 키워드 수. 단순하지만 결정론적(deterministic)입니다 — 추가적인 LLM 판사(judge) 호출이 필요하지 않습니다.

결과

History (대화 기록): 30 turns  |  Full context (전체 컨텍스트): 약 2,485 추정 토큰
Rolling summary (롤링 요약) 생성 시간: 38.2s (단 한 번 실행, 모든 쿼리에 대해 캐싱됨)

쿼리별 Recall (재현율)

Query                          Naive (단순)   Sliding (슬라이딩)   Rolling (롤링)
─────────────────────────────────────────────────────────
DB decision (turn 1)            100%        0%        0%
...

집계 지표 (Aggregate Metrics)

Strategy                   Avg Tokens   Avg Latency   Avg Recall
─────────────────────────────────────────────────────────────────
Naive (full history)            2,513          9.6s        80%
...

세 가지 직관에 반하는 발견 사항

발견 1: 절단(Truncation)의 비용은 직관을 훨씬 초과합니다

Sliding Window (슬라이딩 윈도우) 방식은 토큰의 76%를 절약하지만, Recall (재현율)을 80%에서 20%로 떨어뜨립니다.

원리적으로는 놀라운 일이 아닙니다 — 12개 메시지 윈도우를 넘어서면 1~4번째 턴은 이미 한참 전에 사라졌기 때문입니다 — 하지만 그 **규모(magnitude)**가 매우 놀랍습니다. Query 1 (데이터베이스 결정)의 점수는 0%입니다. 5개의 키워드 중 발견된 것이 하나도 없습니다. 모델이

이는 숨겨진 Naive(나이브) 방식의 실패 모드를 드러냅니다: 컨텍스트가 길어질수록 = 신호가 희소해지며 = 모델이 바로 눈앞에 있는 정보를 놓칠 수 있습니다. 토큰을 추가한다고 해서 항상 정확도가 높아지는 것은 아닙니다.

발견 3: 압축 손실은 노이즈가 아니라 실제 버그입니다

Rolling Summary (롤링 요약)를 사용한 Query 1의 점수는 0%이지만, 요약본에는 다음과 같은 내용이 명시적으로 포함되어 있습니다:

- Database: PostgreSQL with TimescaleDB extension (David, DB Lead)

키워드인 postgresql, timescaledb, david가 요약본에 있음에도 불구하고, 모델의 응답에는 단 하나도 나타나지 않았습니다. 조사 결과, 모델은 데이터베이스 선택에 관한 질문에는 답했지만, 해당 선택의 기술적 _이유(reasons)_인 ACID 준수(ACID compliance)나 시계열(time-series)에 대해서는 언급하지 않았습니다. 요약본이 결정 사항은 보존했지만, 그 근거(rationale)는 놓친 것입니다.

이것이 압축의 근본적인 비용입니다: 요약본은 "무엇이 결정되었는가"는 유지하지만, "왜 결정되었는가"는 잃어버립니다. 단순한 사실 회상이 아닌 근거에 대한 추론(reasoning)을 요구하는 쿼리는 이 격차로 인해 큰 타격을 입습니다.

각 전략의 사용 시점

작업 유형                                       권장 전략
─────────────────────────────────────────────────────────────────────
짧고, 상태가 없으며(stateless), 각 턴이 독립적인 경우  Naive (어차피 히스토리가 짧음)
...

Rolling Summary (롤링 요약) 생성 최적화:

1. 요약 세분화(Summarization granularity): 메시지마다 수행하는 것이 아니라 20~30턴마다 한 번씩 트리거하십시오. 빈번한 압축은 목적을 저해합니다.
2. 프롬프트에 구체성 요구: 보존할 것: 모든 결정 사항, 담당자 이름, 정확한 숫자는 타협할 수 없는 필수 사항입니다.
3. 2계층 구조(Two-layer structure): 요약(과거) + 최근 내용(최근 N개) 구조를 사용하십시오. 요약본을 최근 메시지와 다시 섞어서 재압축하지 마십시오.
4. 지연 생성(Lazy build): 요약이 처음 필요할 때 생성한 후 캐싱하십시오. 모든 쿼리마다 다시 생성하지 마십시오.

실제 Rolling Summary 출력 결과

다음은 22턴의 대화로부터 데모가 생성한 결과물이며, 압축률과 정보 보존력을 보여줍니다:

• 데이터베이스 (Database): TimescaleDB 확장이 포함된 PostgreSQL (David, DB Lead)
• 캐싱 (Caching): Redis Cluster, TTL: 세션 1시간, 대시보드 5분, 노드당 최대 16GB
• 데이터베이스 마이그레이션 (Database Migrations): Sarah (Backend Lead), Flyway, 시니어 엔지니어 2인의 승인 필요
  ...

디자인 체크리스트 (Design Checklist)

전략 선택 (Strategy selection)

• 작업이 얼마나 이전의 내용을 회상해야 하는지 식별
• 슬라이딩 윈도우 (Sliding Window): 최근 컨텍스트만으로 충분할 때만 사용
• 롤링 서머리 (Rolling Summary): 초기 결정 사항이 중요하지만, 원문 그대로의 기록은 필요하지 않을 때 사용
• 네이이브 (Naive): 히스토리가 본질적으로 짧거나, 근거에 대한 추론이 필요할 때 사용

롤링 서머리 구현 (Rolling Summary implementation)

• 프롬프트에 결정 사항, 담당자, 숫자, 기술적 선택 사항을 명시적으로 요구하는가
• 요약본이 메시지 목록에 섞이지 않고 시스템 프롬프트 (System Prompt)에 주입되는가
• 요약본이 쿼리마다 재구축되지 않고, 한 번 구축되어 캐싱 (Cached)되는가
• 트리거 임계값 (Trigger threshold): 메시지가 N턴을 초과할 때 요약하도록 설정했는가 (20~30턴 권장)

회상 검증 (Recall validation)

• 테스트 쿼리는 최근 내용뿐만 아니라 초기 턴을 대상으로 해야 함
• 키워드에는 단순한 결론뿐만 아니라 기술적 이유가 포함되어야 함 (예: 단순히 "postgresql"이 아니라 "acid")
• 프로덕션 전략을 선택하기 전에 키워드 회상 (Keyword-recall) 벤치마크를 실행할 것

요약 (Summary)

세 가지 결론:

1. 측정 없는 절단 (Truncation)은 함정이다: 슬라이딩 윈도우 (Sliding Window)는 토큰의 76%를 절약하지만, 초기 턴의 회상률 (Recall)을 0%로 떨어뜨립니다. 벤치마크가 없다면 이 절벽은 보이지 않습니다. 즉, 제품을 출시하면 에이전트가 컨텍스트의 절반을 조용히 잊어버리게 됩니다.
2. 요약 압축은 "무엇(what)"이 아니라 "왜(why)"를 잃는다: 결정 사항은 압축 과정에서 살아남지만, 그 근거 (Rationale)는 사라지는 경우가 많습니다. 추론 체인 (Reasoning chain)이 필요한 쿼리에는 네이이브 (Naive) 방식이나, 이유를 명시적으로 보존하도록 요구하는 요약 프롬프트가 더 적합합니다.
3. 롤링 서머리 (Rolling Summary)의 구축 비용은 일회성 지불이다: 38초라는 시간은 놀라워 보일 수 있지만, 이는 오프라인에서 수행되는 캐싱 (Cached) 작업입니다. 쿼리 시점에는 각 요청에 2,500개의 토큰 대신 약 600개의 토큰만 추가하면 되므로, 이후 모든 호출에서 4배의 토큰 절감 효과를 얻을 수 있습니다.

참고 자료

• LangChain Message History 문서
• Anthropic Context Caching 문서
• Article 8: Context Engineering — Context is the Most Important Input
• 전체 데모 코드: agent-21-context-engineering-deep

실제 엔터프라이즈급 워크플로우에서 검증된 AI 에이전트 및 스킬의 큐레이션 마켓플레이스인 PrimeSkills를 확인해 보세요. 불필요한 내용은 없고, 실제로 작동하는 것만 있습니다.

저의 홈페이지에서 더 유용한 지식과 흥미로운 제품을 찾아보세요