AI 에이전트를 위한 컨텍스트 엔지니어링: 컨텍스트 윈도우에 실제로 무엇이 들어가야 하는가

목차

2026년 8월 게시.

TL;DR: 컨텍스트 엔지니어링은 매 단계마다 어떤 토큰이 에이전트의 컨텍스트 윈도우에 자리를 차지할 자격이 있는지 결정하는 규율이다 — 시스템 지침, 도구 정의, 검색된 데이터, 대화 히스토리가 모두 동일한 제한된 공간을 두고 경쟁한다. 프롬프트 엔지니어링은 이것을 어떻게 표현할까를 묻고, 컨텍스트 엔지니어링은 모델이 지금 정말로 무엇을 알아야 할까를 묻는다. 흔한 실패 모드는 대개 컨텍스트가 너무 적어서가 아니라 너무 많아서 발생한다 — 오래된 히스토리, 관련 없는 도구 스키마, 아무도 요청하지 않은 검색 문서, 이 모든 것이 신호를 희석시키고 비용을 끌어올린다. 나는 카테고리별로 고정 예산을 운영하고, 정체성보다 히스토리를 먼저 잘라내며, 잘라내기 전에 요약한다.

운영자의 해석: 디버깅하기 가장 어려웠던 에이전트들은 모델이 약해서 실패한 것이 아니었다. 컨텍스트 윈도우가 잡동사니 서랍이 되도록 내버려 뒀기 때문에 실패했다 — 작업에 필요 없는 여섯 개의 도구 스키마, 원래 요청에서 40턴이나 벗어난 대화 히스토리, 기술적으로는 관련 있지만 실질적으로는 쓸모없는 검색 문서. 프롬프트를 고치는 건 도움이 되지 않았다. 프롬프트 앞에 있는 것을 고치는 것이 도움이 되었다.

프롬프트 엔지니어링은 작동하는 에이전트를 만들어 준다. 컨텍스트 엔지니어링은 실제 볼륨, 실제 히스토리, 실제 엣지 케이스를 처리할 때도 그것이 계속 작동하게 해주는 것이다 — 그리고 이것은 이제 내가 프롬프트 문구보다 더 많은 시간을 쏟는 기술이다.

프롬프트 엔지니어링과 컨텍스트 엔지니어링은 같은 작업이 아니다

프롬프트는 하나의 지침이다. 컨텍스트는 모델이 그 지침에 따라 행동할 때 보는 모든 것이다: 시스템 프롬프트, 호출할 수 있는 도구, 검색하거나 조회한 것, 그리고 이전 대화나 실행 히스토리를 얼마나 이어갈지에 대한 결정. 프롬프트 엔지니어링은 첫 번째의 문구를 최적화한다. 컨텍스트 엔지니어링은 네 가지 모두의 구성을 최적화한다.

이 구분은 어휘의 문제가 아니라 실제로 중요하다. 정교하게 다듬은 프롬프트를 작성해도 에이전트에게 관련 없는 도구 스키마 다섯 개와 오래된 히스토리 40턴을 함께 준다면 문구는 더 이상 중요하지 않다 — 모델은 대부분 노이즈로 이루어진 컨텍스트 위에서 추론하고 있는 것이다. “데모에서는 작동한다”에서 “새벽 3시에 이상한 입력에도 작동한다”로 넘어간 내 에이전트들은 모두 윈도우 안의 지침을 다시 표현해서가 아니라 윈도우 안에 있던 것을 고쳐서 거기에 도달했다.

공간을 두고 경쟁하는 네 가지

매 턴마다 네 개의 카테고리가 동일한 제한된 공간을 두고 경쟁한다:

1. 시스템 지침 — 정체성, 규칙, 출력 형식. 시스템 프롬프트에 사용하는 다섯 개 레이어를 참고하라 — 이것은 거의 고정된 상태로 유지되어야 하는 유일한 카테고리다. 프롬프트 캐싱은 접두사가 움직이지 않을 때만 이득이 되기 때문이다.
2. 도구 정의 — 이번 턴에 에이전트가 호출할 수도 있는 모든 도구의 스키마, 필요한지 여부와 무관하게.
3. 검색된 데이터 — 데이터베이스, 벡터 스토어, API 호출에서 가져온 모든 것: 메모리, 문서, 고객 기록.
4. 대화 또는 실행 히스토리 — 이번 세션이나 실행에서 이미 일어난 일.

이 중 어느 것도 공짜가 아니다. 어떤 카테고리든 모든 토큰은 모델이 다음에 무엇을 할지 결정할 때 다른 모든 토큰과 견주어 저울질해야 하는 토큰이며, 캐시 히트가 아닌 모든 요청마다 비용을 지불하는 토큰이다.

실수는 거의 항상 너무 많아서지, 너무 적어서가 아니다

에이전트가 이상하게 행동할 때 본능적으로는 컨텍스트를 더 추가하고 싶어진다 — 더 많은 지침, 더 많은 배경, “혹시 몰라서” 더 많은 히스토리. 내 경험상 이는 오히려 정반대인 경우가 더 많다.

도구 스키마가 너무 많은 경우. 나는 에이전트가 잘못된 도구를 호출하는 것을 본 적이 있는데, 올바른 도구가 없어서가 아니라 그 작업에 필요 없는 다른 여섯 개 도구 뒤에 묻혀 있었기 때문이었다. 현재 단계와 관련된 도구만 보내고, 호출할 때마다 전체 도구 상자를 보내지 마라. 어떤 도구 하위 집합을 노출할지 결정하는 라우팅 레이어는 구축 비용이 저렴하며, 잘못된 호출을 단 한 번만 막아도 그 값을 한다.

오래된 대화 히스토리. 서로 무관한 세 건의 과거 이슈에서 온 60턴의 히스토리를 끌고 다니는 지원 에이전트는 “고객을 기억하는” 것이 아니다 — 관련 없는 노이즈로 현재 요청을 희석시키고, 가끔은 더 이상 사실이 아닌 것을 근거로 행동한다. 이것이 바로 경계가 있는 윈도우를 가진 에피소드 메모리가 막아야 하는 실패 모드이며, 당신의 윈도우가 정말로 경계가 있는지, 아니면 조용히 무한정 커져 버렸는지 확인해 볼 가치가 있다.

아무도 요청하지 않은 검색 문서. 상위 2개의 관련 청크 대신 상위 10개의 “가장 유사한” 청크를 반환하는 시맨틱 검색은 그럴듯해 보이는 방해 요소 아래에 답을 묻어 버린다. 더 많은 검색 컨텍스트가 더 많은 신호를 의미하지는 않는다 — 어느 지점을 넘으면 오히려 적극적으로 더 나빠진다. 모델이 정말 중요한 부분을 찾기 위해 더 힘들게 일해야 하기 때문이다.

방어적으로 반복되는 지침. 나는 에이전트의 이전 버전이 한 번 무시했다는 이유로 같은 규칙을 네 가지 다른 방식으로 반복하는 프롬프트에서 이를 본다. 이는 그 규칙을 프롬프트에서 더 앞쪽으로 옮기거나 구조적으로(도구 스키마의 제약, 검증 단계) 강제해야 한다는 신호이지, 반복으로 컨텍스트를 채우라는 신호가 아니다.

내가 실제로 운영하는 예산

30개 이상의 프로덕션 에이전트에서, 나는 에이전트가 이상하게 행동하기 시작한 후가 아니라 에이전트를 만들기 전에 카테고리별로 명시적인 토큰 예산을 설정한다:

이 마지막 열의 순서가 실제 의사결정 프레임워크다: 먼저 히스토리, 그다음 검색 범위, 그다음 도구 범위, 그리고 시스템 지침은 마지막에 잘라낸다. 히스토리는 정확성을 잃지 않고 압축하기에 가장 저렴하다 — “1~30턴에 무슨 일이 있었는지”에 대한 두 문장짜리 요약은 보통 전체 트랜스크립트와 동일한 운영 가치를 지닌다. 시스템 지침을 잘라내는 것이 가장 위험한데, 에이전트의 실제 행동이 거기에 담겨 있기 때문이다.

잘라내기 전에 요약하라

트렁케이션 — 단순히 가장 오래된 턴을 버리는 것 — 은 이것의 조잡한 버전이다. 버려진 턴에 에이전트가 필요로 하는 단 하나의 사실이 담겨 있기 전까지는 작동한다. 더 나은 패턴은 컴팩션이다: 원본 히스토리를 버리기 전에, 결정과 사실을 포착하는 짧은 구조화된 요약으로 압축하고, 원본 턴이 사라진 후에도 그 요약을 영구적으로 보관하는 것이다.

// workers/compact-history.ts

interface HistoryDigest {
  summary: string; // 2-3문장: 무엇이 결정되었는지, 해결되었는지, 아니면 아직 열려 있는지
  keyFacts: Record<string, string>; // 그대로 보존할 가치가 있는 안정적인 사실들
  turnCount: number; // 이 다이제스트가 대체하는 원본 턴의 수
}

async function compactIfNeeded(
  history: ConversationTurn[],
  env: Env
): Promise<{ digest: HistoryDigest | null; recent: ConversationTurn[] }> {
  const RECENT_WINDOW = 10;
  if (history.length <= RECENT_WINDOW) {
    return { digest: null, recent: history };
  }

  const toCompact = history.slice(0, -RECENT_WINDOW);
  const recent = history.slice(-RECENT_WINDOW);

  // 저렴한 모델로 요약하는 것만으로도 이 단계에는 거의 항상 충분하다
  const digest = await summarizeTurns(toCompact, env);
  return { digest, recent };
}

이는 모든 프로덕션 실패를 영구적인 테스트 케이스로 바꾸는 평가 하니스와 같은 원리다(AI 에이전트를 출시하기 위해 사용하는 평가 하니스 참고): 정보를 버리지 말고, 보관하기에는 저렴하면서도 여전히 유용한 형태로 압축하라. 원본 턴은 버려도 되지만, 그 안의 사실은 보통 그렇지 않다.

검색: 더 적지만 더 관련성 높은 결과가 더 많은 결과보다 낫다

같은 원칙이 벡터 스토어나 데이터베이스에서 가져오는 모든 것에 적용된다. 더 많은 컨텍스트가 해가 되지 않는다는 이론 아래 넉넉하게 검색하고 싶은 유혹 — top-10, top-20 — 이 있다. 하지만 해가 될 수 있다. 관련 없는 청크 하나하나가 모델이 읽고, 저울질하고, 버려야 하는 청크이며, 충분히 큰 규모의 거의-일치 결과 더미는 실제로 질문에 답하는 단 하나의 청크보다 더 무거워질 수 있다.

내 기본값은 작은 k(2-4)로 시작해서, 넓은 그물이 더 안전하게 느껴져서가 아니라 실제 사례로 그 폭에서 답이 실제로 누락되어 있다는 것을 보여줄 수 있을 때만 넓히는 것이다. 검색 품질이 일관되지 않다면 해결책은 보통 더 나은 쿼리나 재순위화 단계이지, 더 큰 k가 아니다.

비용과 정확성으로 연결하기

컨텍스트 엔지니어링은 품질 문제일 뿐만 아니라 — 에이전트를 운영하는 데 드는 비용에 대한 가장 큰 단일 레버이기도 하다. 대부분의 에이전트 워크로드에서는 출력 토큰보다 입력 토큰에 훨씬 더 많은 비용이 청구되기 때문이다. 부풀려진 컨텍스트 윈도우는 행동 버그가 되기 전에 이미 부풀려진 청구서다. 모델 티어를 선택하기 위한 비용 계산을 아직 보지 않았다면, 당신이 운영하는 컨텍스트 예산이 그 계산을 직접적으로 바꾼다는 점을 알아두라: 더 작고 잘 한정된 컨텍스트는 더 저렴한 모델을 더 많은 작업에 실용적으로 만든다. 모델이 불필요하게 거대한 건초더미에서 바늘을 찾도록 요구받지 않기 때문이다.

내가 운영하는 모든 에이전트는 Claude 위에서 돌아가며, 모델 티어 결정은 컨텍스트 예산이 확정된 이후에야 의미가 있다 — 부풀려지고 한정되지 않은 컨텍스트에서 비용을 비교하는 것은 그 작업이 실제로 무엇을 필요로 하는지에 대해 아무것도 말해주지 않는다.

그리고 컨텍스트 윈도우 안의 내용을 바꾸는 것은 프롬프트를 바꾸는 것만큼이나 행동을 바꾸기 때문에, 모든 컨텍스트 변경은 프롬프트 변경과 같은 관문을 통과한다: 배포하기 전에 실제 프로덕션 실패로 구축된 평가 세트에 대해 실행하는 것이다. 히스토리를 줄이거나 검색 폭을 좁히는 것은 확인하지 않으면 조용히 엣지 케이스를 퇴행시키는, 바로 그런 “명백히 안전해 보이는” 종류의 변경이다.

운영자의 결론

컨텍스트 엔지니어링은 매 턴마다 제한된 윈도우 안에서 무엇이 자리를 차지할 자격이 있는지 결정하는 것이며, 기본 실패는 너무 적게 포함하는 것이 아니라 너무 많이 포함하는 것이다. 시스템 지침은 안정적으로 유지하고 마지막에 잘라낼 것으로 남겨두라. 도구 정의는 현재 단계로 한정하라. 좁게 검색하고 근거가 있을 때만 넓혀라. 히스토리는 버리기 전에 요약으로 압축하고, 가장 오래된 원본 턴부터 잘라내라. 그런 다음 모든 변경을 평가에 대해 검증하라. 컨텍스트 변경은 프롬프트 변경과 정확히 똑같이 행동을 바꾸기 때문이다 — 다만 그렇지 않은 척하기가 더 쉬울 뿐이다.

자주 묻는 질문

AI 에이전트를 위한 컨텍스트 엔지니어링이란 무엇인가요?

이는 시스템 지침, 도구 정의, 검색된 데이터, 대화 히스토리 중 어떤 토큰이 매 단계마다 에이전트의 컨텍스트 윈도우에 들어가는지 결정하는 규율로, 단일 지침을 어떻게 표현할지에 관한 프롬프트 엔지니어링과는 다르다. 이는 네 카테고리 모두가 매 요청마다 동일한 제한된 공간을 두고 경쟁하는 프로덕션 환경에서 가장 중요하다.

컨텍스트 엔지니어링은 프롬프트 엔지니어링과 다른가요?

그렇다. 프롬프트 엔지니어링은 지침의 문구를 최적화한다. 컨텍스트 엔지니어링은 그 지침과 함께 모델이 보는 나머지 모든 것 — 어떤 도구가 노출되는지, 무엇이 검색되었는지, 얼마나 많은 히스토리가 이어지는지 — 를 최적화한다. 잘 작성된 프롬프트도 관련 없는 도구 스키마나 오래된 히스토리에 둘러싸여 있으면 여전히 실패한다.

AI 에이전트는 대화 히스토리를 얼마나 유지해야 하나요?

생각보다 적게. 경계가 있는 슬라이딩 윈도우(보통 최근 10-20턴)에 그보다 오래된 모든 것에 대한 압축 요약을 더한 것이 보통 완전한 원본 트랜스크립트보다 낫다. 중요한 사실을 잃지 않으면서 노이즈를 제거하기 때문이다. 히스토리를 버리기 전에 압축하라, 단순히 잘라내지 마라.

더 큰 컨텍스트 윈도우는 컨텍스트 엔지니어링이 덜 필요하다는 뜻인가요?

아니다 — 그것은 엄격한 기술적 상한선을 없애지만 비용이나 노이즈 문제를 없애지는 않는다. 더 큰 윈도우는 부주의함을 더 저렴하게 만들지만, 관련 없는 토큰 하나하나는 여전히 모델이 처리해야 할 신호를 희석시키고 캐시 히트가 아닌 모든 요청마다 여전히 비용이 든다. 이 규율은 20만 토큰에서든 8천 토큰에서든 똑같이 중요하다.

관련: 프로덕션에서 실패하지 않는 AI 에이전트 시스템 프롬프트 작성법 · AI 에이전트에 메모리를 추가하는 방법 · 프롬프트 캐싱: 모델을 바꾸지 않고 Claude 비용 절감하기 · AI 에이전트를 출시하기 위해 사용하는 평가 하니스

당신의 사용 사례를 위한 에이전트의 컨텍스트와 메모리 설계에 도움이 필요하신가요? 연락하기 — 운영자 팀을 위한 프로덕션 에이전트 시스템을 설계합니다.