프롬프트 엔지니어링 - 컨텍스트 엔지니어링

 

https://bits-bytes-nn.github.io/insights/agentic-ai/2026/04/05/evolution-of-ai-agentic-patterns.html

 

Anthropic의 가이드는 컨텍스트 큐레이션을 네 가지 전략으로 분류했습니다. 고객 지원 에이전트를 만든다고 해봅시다. 이 네 전략이 어떻게 작동하는지 따라가 봅시다.

• Write (작성): 시스템 프롬프트를 "고객 지원 에이전트입니다. 환불 정책은 30일입니다. 기술 문제는 티켓을 생성하세요"처럼 명확하고 구조화된 형태로 작성합니다. "무엇을 말할 것인가"가 아니라 "어떻게 구조화할 것인가"가 핵심입니다.
• Select (선택): 고객이 "주문 취소"라고 하면, 전체 FAQ가 아니라 취소/환불 관련 문서만 골라 컨텍스트에 넣습니다. "Lost-in-the-Middle" 현상 — 긴 책의 중간 부분을 기억 못 하는 것처럼, 컨텍스트가 길어지면 중간에 있는 정보의 정확도가 급격히 떨어지는 문제 — 을 방지하기 위해, 양보다 신호 대 잡음비(Signal-to-Noise Ratio)를 최적화해야 합니다.
• Compress (압축): 고객과 20턴 대화를 나눴다면, 초반 15턴을 "고객이 제품 X의 환불을 요청, 영수증 확인 완료, 배송비 문의 중"으로 요약합니다. Anthropic에 따르면 잘 설계된 압축은 정보 보존율 80% 이상을 유지하면서 토큰 사용량을 크게 줄일 수 있습니다.
• Isolate (격리): 고객이 기술 문제를 보고하면, 진단 서브에이전트에게 별도로 위임합니다. 메인 대화 컨텍스트에 로그 분석 데이터가 넘치지 않도록 격리하는 겁니다.

Google ADK의 컨텍스트 스택 아키텍처

Google ADK는 이 원칙을 구체적인 아키텍처로 구현했습니다. 세 가지 핵심 설계 원칙:

1. 저장과 표현의 분리. 데이터베이스에 비유하면, 원본 데이터(테이블)와 화면에 보여주는 뷰(view)를 구분하는 것입니다. 에이전트의 전체 대화 히스토리, 사용자 정보, 과거 도구 결과 등은 세션(Session)에 원본 그대로 보관합니다. 하지만 매 턴마다 모델 API에 실제로 보내는 토큰은 이 원본에서 필요한 부분만 골라 조립한 "작업 컨텍스트(Working Context)"입니다. 원본은 건드리지 않고, 읽을 때마다 그 시점에 최적화된 뷰를 새로 만드는 것이죠.
2. 명시적 변환 파이프라인. 이 "뷰 만들기"가 즉흥적이면 안 됩니다. "시스템 프롬프트 삽입 → 관련 히스토리 선별 → 도구 결과 요약 → 토큰 예산 확인"처럼 이름이 붙은 단계들이 정해진 순서로 실행됩니다. 문자열을 임의로 이어붙이는 게 아니라, 재현 가능한 파이프라인으로 컨텍스트를 조립하는 것입니다.
3. 기본 스코핑. 에이전트가 서브에이전트에게 작업을 위임할 때, 전체 대화를 통째로 넘기지 않습니다. "이 파일을 수정해줘"라는 서브에이전트에게는 해당 파일과 관련 컨텍스트만 전달합니다. 최소 권한 원칙(least privilege)의 컨텍스트 버전입니다.

이 원칙들을 바탕으로, Google ADK는 컨텍스트 윈도우를 구체적으로 두 영역으로 나눕니다.

• 안정 접두어 (Stable Prefix): 시스템 프롬프트, 에이전트 정체성, 도구 정의, 장기 요약 — 자주 변하지 않는 것을 앞쪽에 배치
• 동적 접미어 (Variable Suffix): 최신 사용자 입력, 새로운 도구 출력 — 자주 변하는 것을 뒤쪽에 배치

왜 이 순서가 중요한가? KV-cache 때문입니다.

KV-cache: 프로덕션의 핵심 메트릭

Manus 팀의 이야기를 들어보십시오. 이 팀은 에이전트 프레임워크를 네 번 갈아엎었습니다. 네 번. 첫 번째 버전은 프롬프트 최적화에 집중했고, 두 번째는 에이전트 아키텍처를 바꿨고, 세 번째는 도구 체계를 재설계했습니다. 네 번째에서야 깨달았습니다 — 진짜 병목은 프롬프트도, 아키텍처도, 도구도 아니라 컨텍스트 관리였다는 것을.

이 팀이 프로덕션 에이전트의 "가장 중요한 단일 메트릭"이라고 부른 건 KV-cache hit rate였습니다.

KV-cache(Key-Value Cache)의 작동 원리를 설명하겠습니다. LLM API에 프롬프트를 보내면, 모델은 각 토큰의 어텐션 키(Key)와 값(Value)을 계산합니다. 이 계산은 비용이 큽니다. 그런데 이전 요청의 프롬프트 접두어가 현재 요청과 동일하면, 그 부분은 재계산할 필요 없이 캐시된 결과를 사용할 수 있습니다. Claude Sonnet 기준 캐시 히트 시 비용이 10분의 1로 줄어듭니다. 에이전트가 30번의 턴을 거치면서 매번 시스템 프롬프트를 재계산하는 것과, 캐시를 활용하는 것의 차이는 어마어마합니다.

핵심은 이겁니다. 컨텍스트 접두어의 토큰 하나만 바뀌어도 이후 전체 캐시가 무효화됩니다. 그래서 Google ADK가 "안정 접두어"를 앞에 놓으라고 한 겁니다. 프롬프트의 "품질"보다 프롬프트의 "안정성"이 프로덕션에서는 훨씬 중요합니다. 아이러니합니다 — 2년 동안 프롬프트를 다듬었는데, 정작 프로덕션에서 중요한 건 프롬프트를 건드리지 않는 것이었습니다.