프롬프트 엔지니어링에서 컨텍스트 엔지니어링으로: 2026년 프로덕션 에이전트가 실제로 작동하는 방식

에이전트를 파일럿 단계에서 프로덕션(Production) 단계로 확장하려는 인프라 팀들과 대화하다 보면, 그들은 반복해서 동일한 문제를 언급합니다:

"우리는 그저 더 나은 프롬프트를 작성하면 될 줄 알았습니다. 하지만 우리가 실제로 싸우고 있는 것은 완전히 다른 것이었습니다. 바로 에이전트가 매 호출(call)마다 어떤 정보를 보느냐 하는 문제입니다."

이것이 바로 컨텍스트 엔지니어링 (Context Engineering)입니다. 그리고 이것은 2026년에 데모용 에이전트와 프로덕션용 에이전트를 구분 짓는 핵심적인 규율이 되었습니다.

2024년과 2026년 사이 무엇이 변했는가

2024년에는 에이전트가 제대로 작동하지 않으면 시스템 프롬프트 (System Prompt)를 최적화했습니다. 지침을 다시 쓰고, 예시를 추가하고, 토큰 예산 (Token Budgets)을 조정했습니다.

2025년에도 그런 일이 여전히 일어났습니다. 하지만 점점 더, 그것은 실제 문제의 핵심이 아니었습니다.

2026년에 이르러 프로덕션 팀들은 무언가를 깨달았습니다. 에이전트의 실패는 지침의 실패가 아니었습니다. 그것은 **상태 관리 (State Management)**의 실패였습니다. 에이전트가 잘못된 시점에 잘못된 정보를 보게 되고, 잘못된 결정을 내린 뒤, 방금 무슨 일이 일어났는지 알지 못해 복구할 수 없게 되는 상황이었습니다.

이러한 변화는 세 가지 요소가 수렴하면서 발생했습니다:

1. 컨텍스트 윈도우 (Context Windows)가 거대해졌습니다. Gemini 1M+, Claude 200K. 갑자기 전체 대화 기록, 작업 상태, 결정 로그를 컨텍스트 윈도우에 직접 담을 수 있게 되었습니다.

2. 메모리 (Memory)가 RAG에 덧붙여진 벡터 데이터베이스 (Vector Database)가 아닌, 일급 시민 (First-class Primitive)이 되었습니다. 관련 컨텍스트를 검색하는 대신, 이제 에이전트는 명명된 메모리 블록 (Named Memory Blocks)을 관리합니다: 매 턴마다 무엇을 읽을지, 무엇을 업데이트할지, 무엇을 버릴지를 관리합니다.

3. 추론 모델 (Reasoning Models)이 에이전트가 자율적으로 할 수 있는 일을 변화시켰습니다. 단일 호출 (Single-call) 에이전트가 이제 다단계 체인 (Multi-step Chains)을 대체할 수 있게 되었습니다. 이는 에이전트가 첫 번째 호출에서 더 정보에 기반한 결정을 내려야 함을 의미하며, 결과적으로 컨텍스트 윈도우가 임계 경로 (Critical Path)가 되었음을 의미합니다.

컨텍스트 윈도우가 작을 때는 프롬프트 텍스트를 최적화합니다. 컨텍스트 윈도우가 거대해지고 에이전트가 상태를 유지(Stateful)하게 되면, 매 턴마다 컨텍스트에 무엇을 넣을지를 최적화하게 됩니다.

그것이 바로 컨텍스트 엔지니어링 (Context Engineering)입니다.

컨텍스트 엔지니어링의 실제 작동 방식

2026년의 실제 프로덕션 에이전트 (Production Agent) 컨텍스트가 어떻게 구성되는지 보여드리겠습니다 (가공되지 않은 실제 모습입니다):

시스템 지침 (System Instructions) (정적, 1회 설정)
├── 역할 정의 (Role definition)
├── 엄격한 제약 사항 (Hard constraints) (수행할 수 없는 작업)
├── ...

에이전트는 이 모든 것을 한꺼번에 받지 않습니다. 매 턴 (Turn)마다 정확히 필요한 것만 전달받습니다:

• Turn 1: 시스템 지침 (System instructions) + 현재 작업 (Current task) + 세션 상태 (Session state)
• Turn 2 (도구 호출 후): 시스템 지침 (System instructions) + 업데이트된 작업 (Updated task) + 새로운 도구 결과 (New tool results) + 관련 있는 경우 학습된 패턴 (Learned patterns)
• Turn 3 (막혔을 경우): 모든 정보, 왜냐하면 에이전트가 폴백 전략 (Fallback strategies)을 필요로 하기 직전이기 때문입니다.

프롬프트 (Prompt)는 거의 동일하게 유지됩니다. 컨텍스트 (Context)가 변하는 것입니다.

이것이 컨텍스트 엔지니어링입니다. 에이전트에게 한 번 무엇을 말할지를 설계하는 것이 아니라, 매 턴마다 무엇을 말할지, 그리고 에이전트가 수행하는 작업에 따라 그 정보를 어떻게 업데이트할지를 설계하는 것입니다.

이것이 프로덕션 인프라스트럭처 (Production Infrastructure)에 중요한 이유

여기 핵심적인 부분이 있습니다: 컨텍스트 엔지니어링은 프롬프트 문제가 아니라 인프라스트럭처 (Infrastructure) 문제입니다.

단일 턴 (Single-turn) 애플리케이션인가요? 그렇다면 컨텍스트를 수동으로 관리할 수 있습니다. 하지만 실제 도구 호출 (Tool calls)과 중간 실패 (Intermediate failures)가 발생하며, 여러 세션에 걸쳐 몇 시간 또는 며칠 동안 실행되는 프로덕션 에이전트라면? 다음과 같은 인프라스트럭처가 필요합니다:

1. 메모리 블록을 버전 관리되고 업데이트 가능한 상태 (State)로 관리 — 단순히 추가만 가능한 로그 (Append-only logs)가 아닌 방식
2. 매 턴마다 어떤 블록이 관련 있는지 파악 — 그리고 필요한 것만 라우팅 (Route)
3. 블록을 원자적 (Atomically)으로 업데이트 — 에이전트가 오래되거나 불완전한 상태를 보지 않도록 보장
4. 포드 크래시 (Pod crashes)로부터 생존 — 재시작 후에도 메모리가 유지됨
5. 가시성 (Visibility) 제공 — 에이전트가 무엇을 보았는지, 무엇을 결정했는지, 왜 실패했는지 쿼리(Query)할 수 있음

프레임워크 (Framework)는 에이전트 로직 (Agent logic)을 오케스트레이션 (Orchestrate)할 수 있습니다. 하지만 프로덕션 컨텍스트 윈도우 (Production context windows)를 관리할 수는 없습니다. 그것은 컨트롤 플레인 (Control plane)의 책임입니다.

이것이 LiteLLM Agent Platform이 세션을 Postgres 내의 일급 지속 객체 (First-class durable objects)로 모델링하는 이유입니다. 매 턴마다, LAP는 다음을 알고 있습니다:

• 어떤 컨텍스트 블록(context blocks)이 존재했는지
• 에이전트가 무엇을 읽었는지
• 에이전트가 무엇을 변경했는지
• 변경 사항이 유효했는지
• 에이전트에게 다음에 무엇을 보여줄지

사용 중인 에이전트 SDK (Claude SDK, CrewAI, LangGraph)는 로직을 처리합니다. LAP는 컨텍스트를 처리합니다. 이 둘은 분리되어야 합니다.

컨텍스트 엔지니어링을 위한 에이전트 플랫폼 평가 방법

플랫폼을 비교하고 있다면, 다음 질문들을 던져보세요:

1. 세션 전반에 걸쳐 지속되는 이름이 지정된 메모리 블록(named memory blocks)을 정의할 수 있는가? ("메모리 기능이 있는가?"가 아니라, "여러 개의 상태 유지 블록(stateful blocks)을 가질 수 있는가?"를 물어야 합니다.)

2. 플랫폼이 블록을 원자적(atomically)으로 업데이트하는가, 아니면 직접 구축해야 하는가? (도구 호출(tool calls)이 실패하더라도 메모리 손상이 발생해서는 안 됩니다.)

3. 블록을 "매 턴마다 포함" vs "관련이 있는 경우에만 포함"으로 태깅할 수 있는가? (규모가 커질수록 컨텍스트 윈도우(context window) 관리가 중요해집니다.)

4. 세션 중간에 포드(pod)가 충돌하더라도, 에이전트가 올바른 컨텍스트와 함께 재개되는가? (지속성(Durability)은 기본 요건입니다.)

5. N번째 턴에서 에이전트가 어떤 컨텍스트를 보았는지 검사할 수 있는가? (디버깅에는 가시성(visibility)이 필요합니다.)

만약 플랫폼이 이 중 하나라도 "아니오"라고 답한다면, 당신은 컨텍스트 엔지니어링을 직접 구축하고 있는 것입니다. 그것이 불가능한 것은 아니지만, 인프라 구축에 소모되는 비용(infrastructure churn)이 발생합니다.

게이트웨이(Gateways)에서 컨트롤 플레인(Control Planes)으로의 가교

이러한 변화는 왜 게이트웨이와 컨트롤 플레인이 점점 더 분리되고 있는지를 설명해 줍니다.

**게이트웨이(gateway)**는 요청을 빠르게 라우팅합니다. 세션이나 상태(state)에는 신경 쓰지 않습니다.

**컨트롤 플레인(control plane)**은 세션, 메모리 블록, 그리고 컨텍스트를 관리합니다. 더 느리지만(Postgres를 거쳐야 하므로) 지속적입니다.

실시간 에이전트(세션당 10개 이상의 도구 호출, 1초 미만의 지연 시간)의 경우, 일반적으로 두 가지를 모두 사용합니다:

• 데이터 플레인(Data plane) (LiteLLM-Rust): 1ms 미만의 오버헤드로 도구 호출과 모델 요청을 라우팅합니다.
• 컨트롤 플레인(Control plane) (LiteLLM Agent Platform): 컨텍스트 블록을 관리하고, 세션을 지속시키며, 정책을 강제합니다.

데이터 플레인은 상태가 없기(stateless) 때문에 빠릅니다. 컨트롤 플레인은 상태를 유지하기(stateful) 때문에 신뢰할 수 있습니다. 이 둘은 같은 것이 아닙니다.

실제 사례

현재 프로덕션 (production) 환경에서 실제로 작동하고 있는 모습은 다음과 같습니다:

팀의 시작 단계: 단일 에이전트 (Single agent), 수동으로 관리되는 프롬프트 (prompts), 모든 것이 로컬 스크립트에 포함되어 있습니다. 데모용으로는 아주 훌륭하게 작동합니다.

팀이 3~5개의 에이전트로 확장할 때: 프롬프트들이 서로 갈라지기 시작합니다. 메모리 (Memory)는 여기저기 흩어져 있습니다. 비용 추적은 스프레드시트로 관리합니다. 공통 패턴을 여러 번 반복해서 다시 만듭니다.

팀이 깨닫는 순간: "우리에게 필요한 것은 더 많은 기능이 아니라, 컨텍스트 인프라 (context infrastructure)다."

팀이 LAP + LiteLLM-Rust를 배포할 때: 에이전트들이 한 곳에 모입니다. 컨텍스트 (Context)는 구조화되고 지속적 (persistent)입니다. 세션 (Sessions)은 재시작 후에도 유지됩니다. 비용이 가시화됩니다. 도구 호출 (Tool calls)은 권한 부여 (authorized)를 거칩니다.

결과: 에이전트 로직은 동일합니다. 코드는 60% 감소했습니다. 신뢰성 (reliability)은 10배 향상되었습니다. "에이전트 실패"에서 "수정 및 재배포"까지 걸리는 탐색 시간 (Discovery time)이 며칠에서 몇 시간으로 단축되었습니다.

이것이 바로 컨텍스트 엔지니어링 (context engineering)이 작동하는 방식입니다.

다음 단계

컨텍스트 엔지니어링은 이제 기본 인프라 (table-stakes infrastructure)입니다. 18개월 후에는 더 이상 "컨텍스트 엔지니어링"이라고 불리지 않을 것입니다. 그저 "에이전트를 구축하는 방법"이 될 것입니다.

현재 직면한 질문들은 다음과 같습니다:

• 직접 구축할 것인가 (3~6개월 소요, 지속적인 유지보수 필요)?
• 이를 대신 해주는 컨트롤 플레인 (control plane)을 구매할 것인가?
• 프레임워크가 이를 구축해 줄 때까지 기다릴 것인가 (프레임워크들이 시도 중이지만, 컨트롤 플레인은 오케스트레이션 (orchestration)과는 다른 문제입니다)?

프로덕션 팀들은 빠르게 움직이고 있습니다. 제가 대화하는 팀들은 기다리지 않습니다. 그들은 자체 호스팅 인프라 (LiteLLM Agent Platform + LiteLLM-Rust)를 배포하거나, 관리형 플랫폼 (Anthropic, AWS, Google)을 사용합니다.

경쟁 우위는 프롬프트 (prompt)에 있지 않습니다. 그것은 바로 컨텍스트 (context)에 있습니다.

더 자세히 알고 싶으신가요?

• LiteLLM Agent Platform 문서: docs.litellm-agent-platform.ai
• LiteLLM-Rust: docs.litellm.ai/blog/litellm-rust-launch
• O'Reilly AI Agents Stack 2026: 컨텍스트 엔지니어링에 대해 상세히 언급함

질문이 있으신가요? 프로덕션 에이전트에서 컨텍스트에 접근하는 귀하의 팀 방식에 대한 의견이 있다면 아래에 남겨주세요.