왜 당신의 AI 에이전트가 운영 환경에서 환각(Hallucination)을 일으키는가 — 그리고 컨텍스트 디자인(Context Design)이

당신은 에이전트(Agent)를 수십 번 테스트했습니다. 개발 환경(Dev environment)에서는 잘 작동합니다. 제품을 출시합니다. 그러다 첫 번째 실제 사용자가 근거 없는 답변(Confabulated answer), 잘못된 도구 호출(Tool call), 또는 에이전트가 결코 수행해서는 안 될 행동을 유발합니다.

본능적으로 모델(Model)을 탓하게 됩니다. GPT-4를 Claude로 바꾸거나, Gemini를 시도하거나, 무언가를 미세 조정(Fine-tune)하려고 합니다. 하지만 대부분의 운영 환경 실패 사후 분석(Post-mortems)에서 근본 원인은 모델의 가중치(Weights)가 아닙니다. 모델이 결정을 내려야 할 때 주어진 정보가 문제인 것입니다.

이것은 컨텍스트 디자인(Context design) 문제입니다. 그리고 해결 가능합니다.

에이전트 시스템에서 "환각 (Hallucination)"이 실제로 의미하는 것

"환각 (Hallucination)"이라는 단어는 너무 과하게 사용됩니다. 이 단어는 서로 다른 해결책이 필요한 최소 세 가지의 뚜렷한 실패 모드(Failure modes)를 포괄합니다.

1. 사실적 조작 (Factual fabrication) — 모델이 그럴듯하게 들리지만 제공된 컨텍스트(Context)에 근거가 없는 진술을 생성합니다. 고객 지원 에이전트가 환불 정책을 지어내거나, 연구 에이전트가 존재하지 않는 논문을 인용하는 경우입니다.

2. 도구 오용 (Tool misuse) — 모델이 잘못된 파라미터(Parameters)로 함수를 호출하거나, 완전히 잘못된 함수를 호출하거나, 존재하지 않는 도구에 대한 함수 호출을 만들어냅니다. 이는 도구 설명(Tool descriptions)이 모호하거나 여러 도구의 목적이 중복될 때 특히 흔하게 발생합니다.

3. 지시문 이탈 (Instruction drift) — 대화가 길어짐에 따라 에이전트가 원래의 작업에서 점차 벗어납니다. 컨텍스트 창(Context window)의 0번 위치에 있는 지시문들이 누적된 대화 턴(Turns)에 의해 희석되기 때문입니다. 20번째 턴에 이르면, 모델은 사실상 당신이 설정했던 에이전트와는 다른 에이전트가 되어 버립니다.

이 세 가지 모두 모델이 공백을 채우려 하기 때문에 발생합니다. 적절한 시점에 적절한 정보를 가지고 있지 않을 때, 모델은 통계적으로 가장 그럴듯한 완성본을 생성하며, 이는 종종 틀린 결과로 이어집니다.

세 가지 구조적 원인

1. 컨텍스트 부패 (Context Rot)

컨텍스트 부패 (Context Rot)는 에이전트의 컨텍스트 윈도우 (Context Window) 내 신호 대 잡음비 (Signal-to-Noise Ratio)가 시간이 지남에 따라 저하될 때 발생합니다. 처음에는 정교한 시스템 프롬프트 (System Prompt)와 명확한 작업으로 시작합니다. 하지만 도구 (Tools)가 장황한 JSON을 반환하고, 사용자가 부연 설명을 추가하며, 중간 추론 과정 (Intermediate Reasoning)이 축적되다 보면, 에이전트가 중요한 결정을 내려야 할 시점에 관련 지침은 16,000 토큰의 컨텍스트 중 8,000 토큰 전으로 밀려나게 됩니다.

모델은 최신성 편향 (Recency Bias)을 가지고 있습니다. 즉, 최근의 토큰에 더 강하게 주의 (Attend)를 기울입니다. 긴 컨텍스트 깊숙이 묻혀 있는 지침은 그 이후에 나온 모든 정보와 경쟁하게 됩니다. 만약 해당 지침을 다시 고정 (Re-anchor)하거나 컨텍스트에 무엇을 남길지 능동적으로 관리하지 않는다면, 그 지침은 사실상 약화됩니다.

2. 도구 설명의 모호성 (Tool Description Ambiguity)

이는 운영 환경에서 에이전트 실패를 일으키는 가장 과소평가된 원인입니다. 도구 설명은 컨텍스트의 일부입니다. 모델은 함수의 이름, 설명, 그리고 파라미터 스키마 (Parameter Schema)를 읽고, 해당 도구를 언제 어떻게 사용할지에 대해 확률적인 판단을 내립니다.

설명이 모호할 때(예: "데이터 작업을 위한 헬퍼"), 모델은 보간 (Interpolate)을 수행합니다. 여러 도구가 중복되는 의미론 (Semantics)을 가질 때, 모델은 추측합니다. 파라미터 설명에서 제약 조건(Constraints)을 누락할 때(예: 형식이나 출처를 지정하지 않고 "여기에 사용자 ID를 전달하세요"라고만 하는 경우), 모델은 합리적으로 보이는 것으로 내용을 채워 넣습니다.

밤 11시에 5분 만에 작성된 40단어짜리 도구 설명은 여러분의 운영 시스템에서 상당한 인지적 작업 (Cognitive Work)을 수행하고 있습니다. 이는 보통 받는 것보다 더 많은 주의를 기울일 가치가 있습니다.

3. 결정 지점에서의 메모리 격차 (Memory Gap at Decision Points)

많은 에이전트 실패는 특정 순간에 발생합니다. 바로 에이전트가 대화 초반에는 존재했지만 더 이상 검색 가능한 상태로 남아 있지 않은 정보가 필요할 때입니다. 사용자가 메시지 3번에서 자신의 계정 유형을 언급했습니다. 에이전트는 어떤 도구를 호출할지 결정하기 위해 메시지 15번에서 그 정보가 필요합니다. 만약 여러분의 아키텍처에 명시적인 메모리(Explicit Memory) — 즉, 구조화된 상태 객체 (Structured State Object), 검색 단계 (Retrieval Step), 또는 재주입 메커니즘 (Re-injection Mechanism) — 가 없다면, 에이전트는 다시 질문하거나 (나쁜 UX), 추측하게 됩니다 (환각 위험).

이는 외부 지식을 가져오는 것에 관한 검색 증강 생성 (RAG, Retrieval-Augmented Generation)과는 구별됩니다. 메모리 갭 (Memory gap)은 에이전트 자신의 작업 상태(working state), 즉 대화 턴(turn)을 거치며 계속 유지해야 하는 구조화된 사실(structured facts)에 관한 문제입니다.

운영 환경에서 효과적인 5가지 그라운딩 (Grounding) 기술

기술 1: 시스템 프롬프트에서의 명시적 부정 공간 (Explicit Negative Space)

대부분의 시스템 프롬프트는 에이전트가 무엇을 해야 하는지를 설명합니다. 신뢰도가 높은 에이전트는 에이전트가 무엇을 하지 말아야 하는지, 무엇을 모르는지, 그리고 불확실성의 경계에 도달했을 때 무엇을 말해야 하는지를 명시적으로 설명합니다.

모델이 정책을 지어내지 말아야 한다는 것을 스스로 추론하도록 맡기는 대신, 직접적으로 명시하십시오: "제공된 컨텍스트에 X에 대한 명시적인 정보가 없다면, [특정 폴백 문구(specific fallback phrase)]로 응답하십시오." 부정 공간 (Negative space) 정의는 확률적인 빈칸 채우기를 결정론적인 지시 사항으로 대체하기 때문에 조작(fabrication)을 극적으로 줄여줍니다.

기술 2: 우선순위 가중치 기반 컨텍스트 주입 (Priority-Weighted Context Injection)

모든 컨텍스트가 동일하게 중요한 것은 아닙니다. 명시적인 계층 구조를 정의하십시오: 핵심 작업 지침 (최우선 순위) > 현재 턴의 사용자 입력 > 도구 결과 (tool results) > 대화 기록 > 배경 지식 (최저 순위).

컨텍스트 압박이 커질 때는 계층 구조의 하단부터 균일하지 않게 가지치기(prune)를 해야 합니다. 컨텍스트 제한(context limit)에서 단순히 잘라내는 단순 절단(naive truncation) 방식보다, 시스템 프롬프트와 최근의 도구 결과를 보존하면서 오래된 대화 턴을 요약하는 압축 전략 (compaction strategy)이 더 나은 성능을 발휘할 것입니다.

기술 3: 주입 지점에서의 앵커링 지침 (Anchoring Instructions at Injection Points)

각 도구 호출 (tool call) 전에 관련 제약 사항을 다시 주입(re-inject)하십시오. 각 생성 단계 전에 짧은 지침 재진술을 포함하십시오. 이는 사용자를 위한 반복이 아니라, 최신 편향 (recency bias)과 컨텍스트 부패 (context rot)에 대응하기 위한 기술적 메커니즘입니다.

패턴은 다음과 같습니다: [핵심 작업 상기] + [현재 상태] + [특정 결정 또는 생성 요청]. 상기 사항은 두 문장에서 세 문장 정도로 짧아야 하지만, 결정이 내려지는 시점에 이를 배치하는 것만으로도 드리프트 (drift)를 유의미하게 줄일 수 있습니다.

기술 4: 대화 기록 대신 구조화된 상태 객체 (Structured State Objects) 사용

이전 대화 턴에서 관련 사실을 추출하도록 모델에 의존하는 대신, 명시적인 상태 객체 (state object)를 유지하고 이를 구조화된 컨텍스트 (structured context)로 주입하십시오. 다음과 같은 방식입니다:

현재 상태 (CURRENT STATE):
- 사용자: {{name}}, 계획: {{plan_type}}
- 작업: {{active_task}}
...

이 객체는 압축적이며, 컨텍스트 윈도우 (context window) 압박 속에서도 유지되고, 모호하지 않습니다. 모델은 사용자가 세 턴 전에 자신의 계획 유형을 언급했다는 사실을 기억할 필요가 없습니다. 바로 거기에 적혀 있기 때문입니다.

기술 5: 신뢰도 기반 도구 호출 (Confidence-Gated Tool Calls)

중요도가 높은 도구 호출 (쓰기, 삭제, 외부 API 호출 등)의 경우, 신뢰도 게이트 (confidence gate)를 추가하십시오. 실행하기 전에 에이전트는 짧은 근거 (rationale)와 신뢰도 신호 (confidence signal)를 생성해야 합니다. 도구 호출 전에 "이 작업을 신뢰성 있게 실행하기 위한 충분한 정보를 가지고 있는가?"와 같은 간단한 예/아니오 질문을 삽입하는 것만으로도 잘못된 호출의 상당 부분을 잡아낼 수 있습니다. 매개변수를 조작(fabricate)했을 모델이라도, 직접적으로 질문을 받으면 자신의 불확실성을 드러내는 경우가 많습니다.

멀티 에이전트 시스템에서 이러한 실패가 증폭되는 이유

단일 에이전트의 환각 (hallucination)도 나쁘지만, 멀티 에이전트의 환각은 그것이 전파되기 때문에 더 심각합니다.

전형적인 오케스트레이터-서브 에이전트 (orchestrator-subagent) 패턴에서, 오케스트레이터는 서브 에이전트에게 컨텍스트 요약본을 전달합니다. 만약 그 요약본에 조작된 사실(숫자, 사용자 속성, 제약 조건 등)이 포함되어 있다면, 서브 에이전트는 이를 기저 사실 (ground truth)로 취급합니다. 서브 에이전트는 원본 대화에 접근할 수 없습니다. 최종 출력이 사용자에게 도달할 때쯤이면, 원래의 오류는 여러 추론 계층을 거치며 압축되고, 처리되고, 증폭되어 있습니다.

이것이 바로 멀티 에이전트 아키텍처가 핸드오프 (handoff, 인계) 시점에 더 엄격한 컨텍스트 규율을 요구하는 이유입니다. 에이전트 간에 전달되는 모든 컨텍스트 요약은 스키마 (schema)처럼 취급되어야 합니다. 즉, 명시적인 필드, 명시적인 널 값 (null values, 정보가 없을 때 생략하는 대신 사용), 불확실한 사실에 대한 명시적인 신뢰도 신호가 포함되어야 합니다.

근본 원리

모델은 범용 추론 엔진 (general-purpose reasoning engine)입니다. 출력물의 품질은 의사 결정 시점에 모델이 받는 입력값의 품질에 의해 제한됩니다. 모델의 능력 부족 (capability failure)처럼 보이는 환각 (hallucination)은 거의 언제나 정보의 실패 (information failure)입니다. 즉, 모델이 신뢰할 수 있는 결정을 내릴 수 없는 정보 환경 (information environment)에서 결정을 내리도록 요청받았을 때 발생합니다.

컨텍스트 엔지니어링 (Context engineering)은 그러한 정보 환경을 의도적으로 설계하는 실무입니다. 이는 시스템 프롬프트 (system prompt)뿐만 아니라, 도구 설명 (tool descriptions), 상태 관리 (state management), 압축 전략 (compaction strategy), 메모리 아키텍처 (memory architecture), 주입 타이밍 (injection timing), 그리고 신뢰도 게이트 (confidence gates)를 모두 포함합니다. 이 요소들이 결합되어 여러분의 에이전트가 신뢰할 수 있는 결정을 내릴지, 아니면 그럴듯하게 들리는 추측을 할지를 결정합니다.

이 과정의 대부분은 무언가 잘못되기 전까지는 보이지 않습니다. 하지만 일단 문제가 발생하면, 이것만이 유일하게 중요한 요소가 됩니다.

토큰 예산 관리 (token budget management), RAG 대 롱 컨텍스트 (long-context) 의사 결정 패턴, 시스템 프롬프트 디자인 템플릿, 환각 방지 아키텍처 (anti-hallucination architecture), 그리고 멀티 에이전트 조정 스캐폴드 (multi-agent coordination scaffolds)를 다루는 35페이지 분량의 전체 프레임워크를 원하신다면, 'AI 에이전트를 위한 컨텍스트 엔지니어링 (Context Engineering for AI Agents)' 가이드에서 여러분의 스택에 직접 적용할 수 있는 13개의 복사-붙여넣기용 템플릿을 확인하실 수 있습니다.

Context Engineering for AI Agents — Practitioner's Guide ($39)