현장에서 AI 에이전트가 막히는 지점은 비슷하다. 데모에서는 그럴듯하다. 담당자가 옆에서 파일을 골라주고, 규칙을 설명하고, 예외를 막아주기 때문이다. 운영으로 넣으면 바로 흔들린다. 이유는 모델이 약해서가 아니다. 모델 앞에 놓이는 context가 매번 오염되고, 길어지고, 늦고, 출처를 잃기 때문이다.
prompt 개선은 마지막 10미터다
많은 조직이 아직 prompt를 제품 단위로 본다. 문장을 다듬고, 역할을 지정하고, few-shot 예시를 늘린다. 이 작업은 필요하다. 그러나 운영 문제를 해결하지 않는다.
에이전트는 한 번 답하는 챗봇이 아니다. 파일을 읽고, 도구를 호출하고, 중간 판단을 남기고, 사람에게 되묻고, 다시 실행한다. 이 과정에서 prompt는 시작점일 뿐이다. 실제 품질은 어떤 정보를 언제 넣고, 무엇을 빼고, 어떤 도구를 열어주며, 어떤 결과를 다음 단계에 넘길지에서 결정된다.
Anthropic은 2025년 context engineering을 prompt engineering의 자연스러운 진화로 설명했다. 핵심은 더 긴 지시문이 아니다. compaction, structured note-taking, multi-agent architectures처럼 context pollution을 줄이는 구조다.
context engineering은 문장 작성 능력이 아니라 에이전트의 작업 환경을 설계하는 능력이다.
context architecture는 네 층으로 나뉜다
AX Ops에서는 context를 한 덩어리로 보지 않는다. 에이전트 앞에 들어가는 모든 정보를 네 층으로 나눈다.
| 층 | 설계 질문 | 실패 징후 |
|---|---|---|
| 업무 context | 지금 이 작업의 목적과 판단 기준은 무엇인가 | 답은 맞지만 업무 결론이 틀림 |
| 지식 context | 어떤 문서, 데이터, 정책이 근거인가 | 오래된 문서와 최신 문서가 섞임 |
| 도구 context | 어떤 API, MCP 서버, 워크플로를 쓸 수 있는가 | 불필요한 tool call이 늘어남 |
| 실행 context | 중간 상태, 메모리, 로그를 어떻게 넘기는가 | 긴 세션 뒤 성능이 무너짐 |
이 네 층을 분리하지 않으면 prompt가 창고가 된다. 정책, 예외, API 설명, 사용자 히스토리, 출력 양식이 한 문장 더미에 쌓인다. 담당자는 “모델이 헷갈린다”고 말하지만 실제로는 시스템이 헷갈리게 만든 것이다.
context architecture의 첫 산출물은 거창한 플랫폼이 아니다. 어떤 context가 고정이고, 어떤 context가 검색되고, 어떤 context가 실행 중 생성되며, 어떤 context가 절대 섞이면 안 되는지 정한 표다. 이 표 없이 만든 에이전트는 PoC에서 멈춘다.
harness가 없으면 context는 운영되지 않는다
최근 에이전트 도구의 방향도 같다. OpenAI는 2026년 Agents SDK에 model-native harness와 sandbox execution을 추가했다. Anthropic의 Claude Agent SDK는 subagents와 MCP 기반 외부 서비스 연동을 전제로 한다. Claude Code의 hooks, subagents, slash commands도 prompt 꾸미기가 아니라 실행 전후의 context와 권한을 통제하는 장치다.
이 변화가 말하는 바는 분명하다. 에이전트 설계의 중심이 prompt 파일에서 harness로 이동했다. harness는 모델 주변의 운영 장치다. 어떤 파일을 읽을지, 어떤 도구를 호출할지, 실패 시 어디로 되돌릴지, 사람 승인을 어디에 넣을지 결정한다.
실전에서는 다음 네 가지를 먼저 고정한다.
- context budget: 작업 단계별로 넣을 정보와 버릴 정보를 정한다.
- retrieval rule: 검색 기준, 최신성 기준, 출처 우선순위를 명시한다.
- tool boundary: 읽기, 쓰기, 승인 필요 작업을 분리한다.
- memory rule: 저장할 판단과 버릴 대화를 구분한다.
이 네 가지가 없으면 에이전트는 똑똑한 인턴이 아니라 권한 많은 임시직이 된다. 특히 MCP 같은 도구 연결 표준은 편리하지만, 연결 자체가 통제는 아니다. tool orchestration, 권한, 로그, 차단 규칙이 같이 설계돼야 한다.
참고와 다음 행동은 한 묶음이다
context engineering은 “좋은 prompt 모음” 사업이 아니다. 업무 기준, 지식 흐름, 도구 권한, 실행 메모리를 한 설계 안에 묶는 일이다. 그래서 agent-design의 첫 회의는 화면 UX가 아니라 context map으로 시작해야 한다.
참고 자료:
- Anthropic, “Effective context engineering for AI agents”, 2025: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
- Anthropic, “Building agents with the Claude Agent SDK”, 2025: https://www.anthropic.com/engineering/building-agents-with-the-claude-agent-sdk/
- OpenAI, “The next evolution of the Agents SDK”, 2026: https://openai.com/index/the-next-evolution-of-the-agents-sdk
- Microsoft Azure, “Context Engineering for Reliable AI Agents”, 2025: https://techcommunity.microsoft.com/blog/appsonazureblog/context-engineering-lessons-from-building-azure-sre-agent/4481200
- Anthropic Docs, Claude Code subagents/hooks/slash commands: https://docs.anthropic.com/en/docs/claude-code/sub-agents
다음 에이전트 과제는 prompt 개선 요청서가 아니라 context architecture 설계서로 시작하라. AX LABS는 이 설계를 AX Ops 안에서 운영 구조로 만든다. AX Ops 방법론 →