당신의 에이전트는 환각 (hallucinating)을 일으키는 것이 아닙니다. 잘못된 입력값에 대해 올바르게 추론하고 있는 것입니다.

다음은 프로덕션 환경에서 에이전트를 운영하는 모든 팀이 겪게 되는 실패 패턴입니다:

알람이 발생합니다. 에이전트가 조사에 착수합니다: 메트릭 (metrics)을 가져오고, 최근 배포 (deploys)를 확인하며, 로그 (logs)를 스캔하고, 해결책을 제안합니다. 그런데 그 해결책이 자신만만하면서도 논리적으로 틀렸습니다. 본능적으로는 모델을 탓하게 됩니다 (잘못된 추론, 더 나은 프롬프트 (prompt) 필요, 혹은 더 큰 모델의 필요성).

그 후 누군가가 에이전트가 실제로 무엇을 보았는지 재구성해 봅니다. 메트릭 쿼리 (metrics query)는 5분 전의 캐시된 집계 (cached aggregate) 데이터를 반환했습니다. 배포 목록은 관련 배포가 반영되기 전에 가져온 것이었습니다. 로그 창은 1,000줄에서 잘려 있었고, 정작 중요한 줄은 1,014번째였습니다. 이러한 입력값들을 고려했을 때, 에이전트의 결론은 합리적이었습니다. 단지 발생한 사고를 디버깅하고 있었던 것이 아닐 뿐입니다.

이는 '쓰레기가 들어가면 쓰레기가 나온다 (garbage in, garbage out)'는 원칙의 문제이며, 에이전트의 경우 이전의 그 어떤 소프트웨어보다 상황을 더 악화시키는 반전이 있습니다. 대시보드는 당신에게 쓰레기를 보여줍니다. 사람은 오래된 차트를 보고 타임스탬프 (timestamp)를 알아차릴 수도 있습니다. 하지만 에이전트는 쓰레기를 조용히 소비하고, 그 위에 유창한 추론을 얹어 그것을 바탕으로 '행동'합니다. 출력값은 쓰레기처럼 보이지 않습니다; 마치 자신감 있고 논리적인 조사 결과처럼 보입니다. 그 자신감이 바로 위험한 요소입니다.

왜 지금 이 문제가 드러나고 있는가

챗봇 (chatbots)의 경우, 컨텍스트 (context)는 주로 문서에 대한 검색 (retrieval) 문제였습니다. 평범한 검색 결과는 사람이 그냥 넘길 수 있는 평범한 답변을 의미했습니다. 하지만 프로덕션 에이전트(production agents)가 등장하며 세 가지가 변했습니다:

1. 에이전트는 행동합니다 (Agents act). 오래된 지표(stale metric)는 단순히 잘못된 문단을 생성하는 데 그치지 않습니다. 잘못된 서비스를 재시작하거나 새벽 3시에 엉뚱한 팀에 호출(page)을 보냅니다. 비용의 성격이 외관상의 문제에서 운영상의 문제로 변했습니다.
2. 입력 표면(input surface)이 폭발적으로 확장되었습니다. 프로덕션 에이전트(production agent)는 서로 다른 시스템의 지표, 로그, 배포 이력, 티켓, 채팅을 읽으며, 각 시스템은 저마다의 지연 시간(latency), 속도 제한(rate limits), 캐싱(caching), 그리고 시계(clock)를 가지고 있습니다. 에이전트가 추론하는 "세계"는 부분적인 스냅샷(snapshots)들로 짜여 있으며, 이는 모델의 추론 루프(reasoning loop) 내부에서 이루어지기에 아무도 이를 검사할 수 없습니다.
3. 오류가 누적됩니다 (Errors compound). 단 하나의 잘못된 입력은 약간 틀린 답변을 내놓습니다. 하지만 3단계의 결론이 4단계의 전제가 되는 20단계의 조사 과정에서는, 작은 입력 오류가 확신에 찬 잘못된 해결책(remediation)으로 변질됩니다.

팀들은 실패를 목격하면 이를 추론(reasoning) 문제로 분류하고, 더 큰 모델이나 더 긴 프롬프트(prompt)를 찾습니다. 하지만 실패의 원인은 처음부터 모델의 상류(upstream)에 있었습니다.

컨텍스트가 나빠지는 다섯 가지 방식

• 오래됨 (Stale): 데이터를 가져올 때는 정확했으나, 그 사이 세상이 변한 경우입니다. 캐시(caches)와 폴링 간격(polling intervals)은 소리 없이 데이터의 노후화를 만들어냅니다.
• 부분적임 (Partial): 페이지네이션 제한(pagination limits), 잘려 나간 로그 창(truncated log windows), 조용히 포기해 버린 재시도(retries) 등이 해당합니다. 에이전트는 도착하지 않은 데이터가 아니라, 도착한 데이터만을 바탕으로 추론합니다.
• 순서가 뒤섞임 (Unordered): 여섯 개의 시스템과 여섯 개의 시계에서 온 이벤트들이 잘못 뒤섞인 경우입니다. 인과관계가 역전됩니다. 예를 들어, 배포(deploy)가 자신이 유발한 오류들 뒤에 발생한 것처럼 보일 수 있습니다.
• 손실 발생 (Lossy): 파이프라인의 모든 변환 과정은 의도적으로 무언가를 버립니다. 임베딩(Embeddings)은 정확한 식별자(identifiers)와 단어 순서를 누락시킵니다. 요약(Summarization)은 중요하지 않아 보이는 것들을 버리는데, 그것이 바로 에이전트가 존재하기 위해 내려야 하는 정확한 판단일 수도 있습니다. 이러한 과정이 쌓이면 모델은 결국 샘플의 요약을 다시 의역한 내용을 읽게 됩니다.
• 출처 불분명 (Unattributed): 에이전트는 사실이 어디에서 왔는지, 언제 캡처되었는지 알 수 없습니다. 두 개의 모순된 데이터 포인트가 동일한 권위로 전달되면, 모델은 그냥 하나를 선택해 버립니다.

이 중 그 어느 것도 모델의 문제는 아닙니다. 더 나은 모델이라 할지라도 동일하게 나쁜 입력값에 대해 더 우아하게 추론할 뿐이며, 결국 더 유려한 문체로 똑같이 틀린 답에 도달할 뿐입니다.

"더 큰 컨텍스트 윈도우(Context windows)가 나올 때까지 기다리세요"

이제 컨텍스트 윈도우(Context windows)는 수백만 토큰에 달합니다. 모든 것을 가공 없이 그대로 입력(pipe)하고 모델이 알아서 처리하게 두면 안 될까요? 여기에는 세 가지 문제가 있습니다:

1. 긴 컨텍스트는 성능을 저하시킵니다. "중간에서 길을 잃는(lost in the middle)" 효과(Liu et al.)와 더 일반적인 컨텍스트 부패 (context rot) (18개 모델을 대상으로 테스트한 Chroma의 연구) 모두 입력 길이가 길어짐에 따라 정확도가 떨어진다는 것을 보여줍니다. 백만 토큰의 윈도우가 백만 토큰 모두에 대해 신뢰할 수 있는 주의(attention)를 기울인다는 뜻은 아닙니다.
2. 비용은 토큰에 따라 확장됩니다. 모든 추론 단계(reasoning step)마다 모든 토큰에 대한 비용이 지불됩니다. 하루에 수백 건의 조사를 수행하는 에이전트에게 "모든 것을 보낸다"는 것은 나쁜 단위 경제성 (unit-economics) 결정입니다.
3. 윈도우는 도착하지 않은 것을 고칠 수 없습니다. 최신성(Freshness), 완전성(completeness), 순서(ordering), 그리고 출처(provenance)는 데이터를 수집하는 시스템의 속성입니다. 어떤 모델도 상류(upstream)에서 잘려 나간 로그 라인을 복구하거나, 캐시된 지표(cached metric)의 유효기간이 지난 것을 최신화할 수는 없습니다.

컨텍스트 엔지니어링 (Context engineering)은 시스템 분야입니다

"컨텍스트 엔지니어링 (Context engineering)"이 "프롬프트 엔지니어링 (prompt engineering)"을 대체한 데에는 이유가 있습니다. Anthropic의 자체 가이드라인에서도 컨텍스트를 문구(wording)의 문제가 아닌 엔지니어링 문제로 다룹니다. 하지만 이조차도 단순히 윈도우를 더 잘 채워 넣는 식의 좁은 의미로 적용되는 경우가 많습니다. 진정한 의미의 전문 분야는 글쓰기보다는 데이터 인프라(data infrastructure)에 더 가깝습니다.

좋은 컨텍스트란 다음과 같습니다:

• 완전성 (Complete): 정의된 윈도우(window) 내에서 완결되어야 합니다. "지난 30분 동안의 서비스 X에 관한 모든 것"은 희망 사항이 아닌 보장된 사실이어야 합니다.
• 신선도 (Fresh): 데이터의 노후화(staleness)가 우연이 아닌 측정 가능한 수준으로 관리되어야 합니다.
• 순서 (Ordered): 하나의 시계(clock)를 기준으로 정렬되어 인과관계(causality)가 유지되어야 합니다.
• 중요 지점에서의 무손실 (Lossless where it counts): 저렴한 쿼리(querying)를 위해 구조화(structured)되고 타입(typed)이 지정되어야 하지만, 원본 레코드(original records)는 보존되어야 합니다.
• 속성 부여 (Attributed): 출처(source)와 시점(moment)을 추적할 수 있어야 합니다.
• 재생 가능성 (Replayable): 무언가 고장 난 후에 가장 중요한 속성입니다. 사후 분석(postmortem) 시 질문은 "모델이 왜 그렇게 말했는가"가 아니라 "모델이 무엇을 보았는가"가 되어야 합니다. 만약 컨텍스트(context)가 실시간 API 호출을 통해 조립되었다면, 그 질문에 답할 수 없습니다. 캐시(cache)는 이미 교체되었고 API는 이미 지나갔기 때문입니다. 에이전트 컨텍스트를 내구성이 있고 순서가 보장된 기록(durable, ordered record)으로 취급하면, 포렌식(forensics)은 추측이 아닌 재생(replay)의 영역이 됩니다.

핵심 요약 (The takeaway)

업계는 지난 2년 동안 에이전트가 더 잘 생각하도록 만드는 데는 많은 시간을 썼지만, 에이전트가 '올바른 것'을 생각하도록 만드는 데는 거의 시간을 쓰지 않았습니다. 모델들은 이미 쓰레기 데이터를 입력받았을 때 위험할 정도로 충분히 똑똑하며, 사후 분석이 이루어지기 전까지는 그 쓰레기가 보이지 않을 정도로 유창합니다.

다음에 프로덕션(production) 환경에서 에이전트가 실패한다면, 더 큰 모델을 찾기 전에 저렴한 실험을 먼저 해보세요. 에이전트가 본 것을 정확히 재구성하고, 동일한 입력값에 대해 당신이라면 더 나은 결과를 냈을지 자문해 보십시오. 대개 답은 '아니오'입니다. 추론 실패(reasoning failure)처럼 보이는 것은 대개 컨텍스트 실패(context failure)이며, 컨텍스트 실패는 오늘날의 엔지니어링으로 해결 가능합니다.

저는 오픈 소스이자 셀프 호스팅(self-hosted) 가능한 NavFlow를 구축하고 있습니다. 이는 프로덕션 에이전트에게 시스템 전반에 걸쳐 상관관계가 있는 단일 읽기 경로(correlated read path) — 완전하고, 신선하며, 순서가 있고, 무손실이며, 재생 가능한 — 를 제공하여, 모델의 추론만이 유일한 변수로 남도록 만듭니다.