신뢰할 수 있는 AI 에이전트를 실제로 출시하기 위해 필요한 기술: 컨텍스트 엔지니어링 (Context Engineering)

프롬프트 엔지니어링 (Prompt engineering)은 여러분이 가장 먼저 배우는 것입니다. 하지만 실제로 무언가를 출시하려고 할 때 정말로 필요한 것은 컨텍스트 엔지니어링 (Context engineering)입니다.

제가 이해하는 데 너무 오랜 시간이 걸렸던 그 차이점을 설명해 드리겠습니다.

프롬프트 엔지니어링이 잘하는 것 (그리고 한계점)

프롬프트 엔지니어링 (Prompt engineering)은 명확한 지침을 작성하는 기술입니다. 이는 매우 중요합니다. 잘 구성된 프롬프트는 모호함을 줄이고, 적절한 어조를 설정하며, 모델이 작업을 완료하는 데 충분한 정보를 제공합니다.

하지만 프롬프트 엔지니어링은 단일 입력값 위에서 작동합니다. 다음과 같은 질문에는 답하지 못합니다:

• 모델이 12번째 턴(turn)에 도달했고 대화 기록이 4000 토큰(tokens)이 되면 어떻게 되는가?
• 6개의 문서를 검색(retrieve)했지만, 컨텍스트 윈도우 (context window)에는 3개만 들어갈 수 있다면 어떻게 되는가?
• 시스템 프롬프트 (system prompt)의 제약 조건이 검색 파이프라인 (retrieval pipeline)에 의해 주입된 내용과 모순된다면 어떻게 되는가?
• 에이전트 (agent)가 스스로 만들어낸 파라미터 (parameters)로 도구 (tool)를 호출한다면 어떻게 되는가?

이것들은 프롬프트의 문제가 아닙니다. 아키텍처 (architecture)의 문제입니다. 그리고 이것들이 바로 실제 프로덕션 AI 시스템이 실패하는 지점입니다.

컨텍스트 엔지니어링이란 무엇인가

컨텍스트 엔지니어링 (Context engineering)은 모델이 응답을 생성할 때 보는 모든 것 — 단순히 현재의 프롬프트뿐만 아니라 시스템 지침 (system instructions), 검색된 데이터 (retrieved data), 대화 기록 (conversation history), 도구 스키마 (tool schemas), 주입된 상태 (injected state), 그리고 출력 형식 가이드 (output format guidance)를 포함한 전체 컨텍스트 (context)를 의도적으로 설계하는 실무를 의미합니다.

핵심적인 통찰은 이것입니다: 컨텍스트는 출력 품질을 직접적으로 결정하는 **유한하고 비용이 많이 드는 자원 (finite, expensive resource)**이라는 점입니다. 컨텍스트를 수동적으로 쌓이게 두는 것이 아니라 의도적으로 관리하는 것이, 데모(demo) 수준과 대규모로 운영되는 시스템 사이의 차이를 만듭니다.

이 용어는 비교적 새롭습니다. Andrej Karpathy는 진지한 에이전트 빌더들이 이미 이름 없이 수행하고 있던 작업들을 설명하기 위해 2025년에 이 용어를 사용하기 시작했습니다. 이제 이것은 제가 아는 LLM 시스템 설계 (LLM system design)를 생각하는 데 가장 유용한 프레임워크입니다.

설계해야 하는 4가지 계층

신뢰할 수 있는 AI 에이전트의 컨텍스트는 4가지 계층을 가집니다. 이 중 어느 하나라도 부주의하게 설계되면 예측 불가능한 출력이 발생합니다.

계층 1: 시스템 계층 (System Layer)

이것은 당신의 역할 정의(role definition), 규칙(rules), 그리고 제약 사항(constraints)입니다. 대부분의 개발자들은 이를 한 단락의 지침으로 작성합니다. 하지만 프로덕션 버전에서는 이를 하나의 계약 (contract) 으로 작성합니다.

당신은 다음 제약 사항 하에 작동하는 [역할]입니다: [목록].
[조건 A]가 발생하면, 항상 [행동 X]를 수행하십시오.
[조건 B]가 발생하면, 항상 [행동 Y]를 수행하십시오.
...

"만족할 수 없는 경우"에 대한 조항은 대부분의 사람들이 누락하는 부분입니다. 하지만 이 조항이야말로 에이전트가 상황을 에스컬레이션(escalating)해야 할 때 임의로 행동(improvising)하는 것을 방지해 줍니다.

계층 2: 메모리 계층 (Memory Layer)

메모리는 턴(turn) 사이에도 지속되는 것입니다. 네 가지 유형이 있습니다:

유형	저장 내용	구현 방법
인-컨텍스트 (In-context)	최근 턴, 작업 상태	직접 주입 (Direct injection), 관리된 절단 (managed truncation)
...

대부분의 에이전트 프레임워크는 인-컨텍스트 메모리를 자동으로 처리하지만, 이는 제대로 이루어지지 않는 경우가 많습니다(badly). 나머지 세 가지 유형은 명시적인 설계 결정이 필요합니다.

가장 흔한 실패 사례는 인-컨텍스트 메모리가 무제한으로 커져서 시스템 프롬프트(system prompt)와 RAG 컨텍스트(context)를 밀어내는 것입니다. 해결책: 토큰 예산(token budget)을 강제하고 공격적으로 요약(summarize)하십시오.

계층 3: 작업 계층 (Task Layer)

작업 계층은 이번 턴을 위해 엄격하게 범위가 지정된 현재의 목표입니다. 여기서 저지르는 실수는 작업을 너무 광범위하게 만드는 것입니다. "사용자의 요청을 도와주세요"는 작업 계층이 아닙니다. "다음 문서에서 모든 날짜 언급을 추출하여 ISO-8601 문자열로 반환하십시오"가 작업 계층입니다.

더 엄격한 작업 범위 지정(Tighter task scoping) → 더 일관된 출력(more consistent outputs) → 더 쉬운 평가(easier evaluation).

계층 4: 출력 계층 (Output Layer)

모델이 생성해야 할 정확한 형식을 지정하십시오. 단순히 "JSON 형식으로"가 아니라, 정확한 스키마(schema)를 지정해야 합니다. "명확하고 간결하게"가 아니라, 단어 수 범위, 헤딩(heading) 구조, 포함해야 할 내용과 명시적으로 제외해야 할 내용을 지정해야 합니다.

출력 계층 명세에는 품질 게이트 (quality gate) 도 포함됩니다. 무엇이 유효한 출력을 만드는가? 유효한 출력을 생성할 수 없다면 모델은 무엇이라고 말해야 하는가?

가장 흔한 5가지 프로덕션 실패 사례 (및 컨텍스트 엔지니어링 해결책)

1. 컨텍스트 팽창 (Context Bloat)

증상 (Symptom): 에이전트가 5회 차까지는 안정적으로 작동하지만, 10회 차 이후부터 성능이 저하됨.
근본 원인 (Root cause): 예산(budget) 설정 없이 대화 기록 (Conversation history)이 계속해서 늘어남.
해결책 (Fix): 코드 내에 토큰 예산 (token budget)을 설정하십시오. 기록이 한계치에 도달하면, 가장 오래된 대화들을 압축된 에피소드 기록 (episodic record)으로 요약하십시오. 요약본을 주입 (inject)하고, 가공되지 않은 원본 대화 (raw turns)는 삭제합니다.

2. 도구 환각 (Tool Hallucination)

증상 (Symptom): 에이전트가 스스로 만들어낸 파라미터 (parameters)로 도구를 호출하거나, 특정 작업에 잘못된 도구를 호출함.
근본 원인 (Root cause): 모호한 도구 설명 (tool descriptions). 모델이 공백을 그럴듯하게 들리는 값으로 채워 넣음.
해결책 (Fix): 명시적인 반대 조건 (anti-conditions)을 포함하여 도구 설명을 작성하십시오. "[조건]일 때는 이 도구를 호출하지 마십시오"라는 문구는 "[조건]일 때 이 도구를 호출하십시오"만큼 중요합니다. 단순히 필드 이름만 적지 말고, 정확한 입력 스키마 (input schema)를 지정하십시오.

3. 검색 실패 (Retrieval Miss, RAG)

증상 (Symptom): 올바른 문서를 검색했음에도 불구하고, 모델이 여전히 틀린 답을 내놓음.
근본 원인 (Root cause): 검색의 문제가 아니라 주입 (injection)의 문제임. 청크 형식 (chunk format), 청크 크기 (chunk size), 컨텍스트 내 위치, 그리고 소스 메타데이터 (source metadata) 모두가 모델이 검색된 콘텐츠를 얼마나 잘 활용하는지에 영향을 미칩니다.
해결책 (Fix): 콘텐츠 앞에 소스 메타데이터를 포함한 일관된 청크 주입 형식을 사용하십시오. "SOURCE: [id] [relevance score] | [content]"와 같은 방식이 가공되지 않은 콘텐츠 주입보다 일관되게 더 나은 성능을 보입니다. RAG 컨텍스트를 작업 지시 (task instruction) 뒤가 아닌, 바로 앞에 배치하십시오.

4. 지시문 이탈 (Instruction Drift)

증상 (Symptom): 세션 시작 시에는 시스템 프롬프트 (system prompt)의 제약 사항을 잘 따르지만, 8회 차 정도 되면 이를 무시함.
근본 원인 (Root cause): 주의력 희석 (Attention dilution). 컨텍스트 길이 (context length)가 길어짐에 따라, 초기 토큰 (early tokens)에 대한 모델의 유효한 주의력이 감소함.
해결책 (Fix): 중요한 제약 사항을 시스템 레이어 (system layer)뿐만 아니라 작업 레이어 (task layer)에도 다시 주입 (re-inject)하십시오. 장기 실행되는 에이전트의 경우, N회 차마다 "제약 사항 재주입 블록 (constraint re-injection block)"을 포함하십시오.

5. 침묵하는 실패 (Silent Failure)

증상 (Symptom): 에이전트가 출력을 생성함. 출력 결과가 그럴듯해 보임. 하지만 출력 내용이 틀림. 어떠한 오류 신호도 발생하지 않음.
근본 원인 (Root cause): 생성 후 평가 단계 (post-generation evaluation step)가 없음.
해결책 (Fix): 높은 이해관계가 걸린 작업 (high-stakes tasks)의 경우, 첫 번째 응답의 근거성 (groundedness), 형식 준수 여부 (format compliance), 명시된 신뢰도 (stated confidence)를 평가하는 두 번째 LLM 호출을 추가하십시오. 이는 비용이 많이 드는 작업이 아닙니다. 일반적인 검토가 아니라 특정 목적을 가진 평가자 (targeted evaluator) 역할을 수행하기 때문입니다. 그 비용만큼의 가치가 있습니다.

당신이 관리하지 못하고 있는 어텐션 예산 (The Attention Budget You're Not Managing)

모든 컨텍스트 창 (context window)에는 유한한 어텐션 예산 (attention budget)이 있습니다. 어텐션은 균등하게 분포되지 않습니다. 모델은 컨텍스트의 시작과 끝, 그리고 구조적으로 두드러지는 토큰 (헤더, 코드 블록, 명시적 서식 등)에 더 강력하게 어텐션을 부여합니다.

이는 아키텍처 설계에 다음과 같은 시사점을 줍니다:

• 가장 중요한 제약 사항 (constraints)은 본문 네 번째 단락에 묻어두지 말고, 시스템 프롬프트 (system prompt)의 맨 앞에 배치하십시오.
• 작업 명세 (task specification)는 프롬프트 내에서 몇 페이지 앞이 아니라, 예상되는 출력 직전에 배치하십시오.
• 반드시 안정적으로 어텐션이 가야 하는 항목에는 명시적인 구조 (번호 매기기 목록, 라벨이 붙은 섹션)를 사용하십시오.
• 각 레이어(layer)에 걸쳐 토큰 수를 명시적으로 할당하십시오. 출력용 20%, 시스템+작업용 30%, 검색(retrieval)+이력용 50%를 할당하는 것이 합리적인 시작점입니다.

최소한의 컨텍스트 엔지니어링 템플릿 (복사하여 수정 가능)

다음은 제가 대부분의 에이전트 아키텍처의 시작점으로 사용하는 시스템 프롬프트 스캐폴드 (scaffold)입니다:

## 역할 (Role)
당신은 [역할]입니다. 당신은 [주요 능력]을 수행합니다. 당신은 [명시적 제외 사항]을 수행하지 않습니다.

...

이것은 스캐폴드(뼈대)이지, 정해진 처방전이 아닙니다. 에이전트 유형에 맞춰 섹션 이름과 내용을 조정하십시오. 중요한 것은 구조적 규율(structural discipline) — 즉, 명시적인 역할 (explicit roles), 명시적인 제약 사항 (explicit constraints), 명시적인 폴백 (explicit fallbacks), 명시적인 품질 게이트 (explicit quality gates) — 입니다.

다음에 읽을 내용

특정 레이어에 대해 더 깊이 알고 싶다면:

• 메모리 아키텍처 (Memory architecture): 에피소드적 (episodic) + 의미적 (semantic) 결합은 공개된 문헌에서 가장 적게 다뤄지는 주제입니다. 실제 운영 패턴은 다음과 같습니다: 검색을 위한 벡터 저장소 (vector store) + 긴 세션의 연속성을 위한 외부 에피소드 로그 (external episodic log).
• RAG 평가 (RAG evaluation): 대부분의 팀이 검색 정확도 (retrieval accuracy)는 측정하지만, 주입 품질 (injection quality)은 측정하지 않습니다. 청크 형식 (chunk format), 청크 크기 (chunk size), 그리고 컨텍스트 위치 (context position)는 모두 결과에 영향을 미치며 독립적으로 테스트 가능합니다.
• 멀티 에이전트 컨텍스트 공유 (Multi-agent context sharing): 블랙보드 아키텍처 (blackboard architecture, 에이전트들이 메시지를 주고받는 대신 공유 상태 파일에서 읽고 쓰는 방식)는 활용도가 낮지만 많은 조정 (coordination) 문제를 해결합니다.

저는 4개의 레이어, 13개의 복사-붙여넣기 가능한 템플릿, 그리고 구체적인 해결책이 포함된 10가지 실패 모드 (failure modes)를 모두 담은 35페이지 분량의 실무자 가이드에 전체 프레임워크를 문서화했습니다.

→ AI 에이전트를 위한 컨텍스트 엔지니어링 — 실무자 가이드 (Context Engineering for AI Agents — Practitioner's Guide)

프레임워크에 구애받지 않습니다. GPT-4o, Claude, Gemini와 모두 호환됩니다. 가격은 $39입니다.

토론 (Discussion)

제가 여기서 다루지 않은 운영 환경에서의 컨텍스트 실패 사례를 경험하신 적이 있나요?

특히, 겉보기에는 모든 것이 정상처럼 보이지만 시스템이 조용히 성능이 저하되는 (silently degrading) 실패 모드에 대해 궁금합니다. 그런 사례들이 흥미롭기 때문입니다.

이 기사는 벤치마크가 아닌 운영 패턴을 문서화합니다. 어떠한 성능 수치도 주장하지 않습니다. 모든 템플릿은 시작점일 뿐이며, 귀하의 특정 에이전트 아키텍처에 맞게 조정하고 귀하의 데이터로 직접 평가하십시오.