컨텍스트 엔지니어링(Context Engineering)은 AI 에이전트의 컨텍스트 창에 무엇을 넣을지, 무엇을 압축할지, 무엇을 온디맨드로 검색할지, 무엇을 완전히 제외할지를 체계적으로 결정하는 방법론이다. 프로덕션에서 에이전트가 실패할 때 원인은 대부분 모델이 아니라 컨텍스트 창의 잘못된 관리다. 낡은 이력이 창을 채우고, 중복 검색 결과가 신호를 묻어버리며, 원시 도구 출력이 모델에게 필요한 정보를 가린다.
컨텍스트 창을 RAM처럼 다루기
컨텍스트 창을 단순한 기술적 제한이 아닌 주요 설계 파라미터로 다뤄야 한다. 토큰의 비용은 두 종류다:
- 금전적 비용: 모델은 입력 토큰당 과금되며, 멀티 스텝 에이전트 루프에서 빠르게 누적된다.
- 인지적 비용: 모델은 모든 토큰에 동등한 주의를 기울이지 않는다. 어텐션은 앞과 뒤 위치에 편향되고, 중간 컨텍스트 내용은 덜 영향을 준다. 토큰 한도 안에 들어오더라도 길고 구조 없는 입력은 추론 품질을 저하시킨다.
가장 유용한 멘탈 모델: 컨텍스트 창은 RAM, 외부 메모리·데이터베이스·파일시스템은 디스크. RAM이 빠르고 강력하지만 세션 간 초기화되듯이, 외부 스토어는 느리지만 크고 저렴하다. 좋은 컨텍스트 엔지니어링은 “지금 이 단계에서 RAM에 무엇을 올릴 것인가”를 매 스텝 결정한다.
컨텍스트를 채우는 4가지 레이어
프로덕션 에이전트의 컨텍스트는 보통 다음 레이어로 구성된다:
| 레이어 | 내용 | 특성 |
|---|---|---|
| 시스템 지시사항 | 에이전트 역할, 행동 규칙, 도구 스키마, 출력 형식, Few-shot 예시 | 주로 정적, 프리픽스 캐싱 적합 |
| 대화 이력 | 사용자 턴, 에이전트 응답, 도구 호출·결과 | 가장 빠르게 증가, 가장 관리 부족 |
| 검색된 지식 | 외부 스토어에서 가져온 문서, DB 레코드, 메모리 아이템 | 중복·관련성 제어 필요 |
| 작업 상태 | 중간 결과, 스크래치패드 추론, 태스크 진행 상황 | 멀티 스텝 일관성에 필수, 비쌈 |
컨텍스트 품질 문제는 보통 두 가지 실패로 귀결된다: 현재 스텝에 관련 없는 내용 포함, 또는 중요한 내용 제외. 둘 다 모델 문제가 아닌 아키텍처 결정이다.
정적 vs. 동적 컨텍스트 분리
컨텍스트 엔지니어링에서 가장 높은 가치를 가진 구조적 결정은 요청 간 고정되는 컨텐츠(정적)와 매 턴마다 바뀌는 컨텐츠(동적)의 분리다.
- 정적 컨텍스트: 시스템 프롬프트, 에이전트 아이덴티티, 도구 스키마, 고정 규칙. 프롬프트 앞에 위치해 프리픽스 캐싱(prefix caching)으로 반복 계산을 절감한다.
- 동적 컨텍스트: 현재 사용자 입력, 최근 도구 출력, 검색 문서. 가변 서픽스에 위치하며 현재 추론 스텝에 필요한 최소한으로 유지한다.
이 분리로 2패스 컨텍스트 조립 파이프라인을 만들 수 있다:
- 1패스: 정적 컨텍스트 로드 (시스템 프롬프트, 캐시된 지시사항, 장기 요약)
- 2패스: 동적 컨텍스트 주입 (현재 태스크 상태, 신선한 검색 결과, 최근 이력)
대화 이력 관리
이력은 대부분의 프레임워크가 가장 빈약하게 처리하는 부분이다. 흔한 패턴—새 턴을 덧붙이고 전체 이력을 재전송—은 짧은 세션에서는 작동하지만 장기 에이전트에서 두 가지 문제를 만든다:
- 컨텍스트 팽창(Context Bloat): 해결된 오류, 낡은 도구 출력, 무효화된 결정이 토큰을 소비
- 컨텍스트 오염(Context Poisoning): 모델의 초기 실수가 보존되어 이후 추론이 잘못된 전제 위에서 이루어짐
대화 이력 관리 전략:
| 전략 | 방법 | 적합한 상황 |
|---|---|---|
| 최근성 트런케이션 | 마지막 N 턴만 유지 | 비용 최적화, 단기 상태 충분 |
| 롤링 요약 | 오래된 교환을 압축 요약으로 대체 | 중기 세션 |
| 앵커된 반복 요약 | 의도·결정·행동·다음 단계를 구조화된 세션 상태 문서로 지속 업데이트 | 장기 에이전트, 가장 강력 |
검색을 예산 결정으로 설계
흔한 실수: 검색을 단순한 업스트림 단계로 취급하고 청크를 주입한 뒤 넘어가는 것. 실제로는 검색이 컨텍스트 예산에서 얼마를 소비할지, 언제 실행할지를 명시적으로 결정해야 한다.
검색 설계 원칙:
- 후처리 필터링: 주입 전 관련성을 점수화해 필요한 청크만 선택
- 시맨틱 청킹: 고정 크기 분할이 아닌 자연스러운 토픽 경계로 분할해 의미와 일관성 보존
- 하이브리드 검색: 시맨틱 검색 + 키워드/메타데이터 필터 조합. “최근 30일 청구 문제”처럼 임베딩만으로는 부족한 쿼리에 대응
- 에이전트 제어 검색: 에이전트가 언제 검색이 필요한지 판단하고 직접 호출. 자동 검색보다 더 타겟된 쿼리와 적시 실행을 보장
전체 에이전트 루프에서 토큰 예산 관리
개별 컨텍스트 결정만으로는 부족하다. 멀티 스텝 루프에서 토큰은 턴마다 누적되므로 전체 실행을 비용 단위로 관리해야 한다:
- 도구 출력(특히 검색·API 결과)이 가장 큰 비용 요인. 수집 시점에 필터·트리밍, 나중에 압축하지 말 것
- 컨텍스트 활용률 60~80% 유지를 목표로. 한도 꽉 채우면 갑작스러운 품질 저하가 발생
- 단순 태스크에는 최소 컨텍스트, 복잡한 멀티 스텝 태스크에는 더 많이 배분하는 동적 할당
프로덕션 컨텍스트 품질 평가
컨텍스트 엔지니어링 실패는 표준 평가에서 보이지 않는 경우가 많다. 짧은 테스트 세션에서 잘 작동하다가 긴 실행에서 저하되며, 실패가 컨텍스트 관리가 아닌 추론 문제로 오귀인된다.
프로브 기반 평가: 압축·검색 후 저장된 정보를 요구하는 타겟 질문을 던진다.
- 회상 프로브: 에이전트가 특정 사실을 기억하는가?
- 아티팩트 프로브: 에이전트가 수정한 파일을 알고 있는가?
- 연속성 프로브: 에이전트가 멀티 스텝 태스크를 이어서 계속할 수 있는가?
추적할 핵심 지표:
- 컨텍스트 활용률 — 예산 중 실제 사용 비율
- 압축 비율 — 요약으로 인한 토큰 감소
- 검색 정밀도 — 검색된 청크가 실제로 모델에 의해 사용되는가?
컨텍스트 드리프트 신호: 에이전트가 이미 처리한 파일을 다시 읽거나, 이미 내린 결정을 재서술하거나, 원래 사용자 의도에서 점차 멀어지는 태스크 재프레이밍.
관련 문서
- agent-harness — 컨텍스트 로트 대응, Ralph 루프, 훅 설계를 포함한 하네스 엔지니어링 전반
- long-running-agents — 장기 실행 에이전트에서의 컨텍스트 관리와 상태 지속성
- inference-caching — 프리픽스 캐싱을 포함한 LLM 추론 비용 절감 전략
- rag — 외부 지식 검색 증강 생성 기술
참고 자료
- Effective Context Engineering for AI Agents: A Developer’s Guide — Machine Learning Mastery (2026-04-28)
- Effective context engineering for AI agents — Anthropic Engineering