에이전트 메모리 오염: 기업에 피해를 주는 4단계 손상 체인

[2026-05-12 11:42:08] agent_id=customer-service-v3 stored: refund_approved=true
[2026-05-13 03:17:21] agent_id=customer-service-v3 recalled: refund_approved=true (no ticket id)
[2026-05-13 09:04:55] agent_id=customer-service-v3 recalled: refund_approved=true (different ticket)
...

이것이 바로 기업 팀들이 11일간의 복구 비용을 치르기 전에 반드시 인지해야 할 실패의 형태입니다.

이번 달 대부분의 팀이 읽고 있는 기사는 모델 계층 (model layer)에서의 환각 (hallucination)에 관한 것입니다. 그 문제에는 이름과 해결책이 있습니다. 구조화된 출력 (Structured output), 평가 스위트 (eval suites), 그라운드 트루스 검색 (ground-truth retrieval) 같은 것들 말이죠.

이 기사에서 다루는 문제는 다릅니다. 이는 에이전트의 메모리 (MEMORY) 계층이 환각을 저장하고, 이후의 모든 실행에서 그 메모리를 마치 검증된 사실인 것처럼 신뢰할 때 발생하는 문제입니다.

피해는 네 단계를 거치며 복리로 쌓입니다. 대부분의 팀은 재무(finance)나 컴플라이언스(compliance) 부서가 이를 인지하는 4단계에서야 문제를 발견합니다. 1단계에서 발견할 때의 비용은 엔지니어 한 명의 오후 시간 정도입니다. 하지만 4단계에서 발견할 때의 비용은 위에 언급한 복구 사례와 같습니다.

1단계. 주입 (The injection)

사용자가 잘못된 형식을 입력합니다. 검색 시스템 (retrieval system)이 오래되었거나 잘못된 문서를 반환합니다. 도구 호출 (tool call)이 에이전트가 확인으로 해석하는 오류를 반환합니다. 이 중 어떤 것이든 에이전트가 사실로 취급하는 단언 (assertion)을 포함한 에이전트 응답을 생성할 수 있습니다.

상태가 없는 (stateless) 에이전트의 경우, 이 피해는 응답 단계에서 끝납니다. 사용자는 잘못된 답변을 보고, 이의를 제기하며, 에이전트는 이를 수정합니다.

쓰기 통과 메모리 계층 (write-through memory layer)을 가진 상태 유지 (stateful) 에이전트의 경우, 피해는 2단계로 넘어갑니다.

제가 감사(audit)했던 기업 배포 환경에서 가장 흔하게 발생하는 쓰기 트리거 (write triggers)는 다음과 같습니다.

사용자의 "이것을 기억해 줘"라는 지시.

그날의 대화 내용을 통합하는 예정된 요약 (scheduled summarization).

이전 대화 요약을 영구 저장소 (persistent store)에 기록하는 긴 컨텍스트 핸드오프 (long-context handoff).

검색 응답으로부터의 벡터 스토어 (vector store) 업데이트.

이 각각은 모두 정당한 패턴입니다. 하지만 이 각각은 환각이 지속성을 갖게 되는 지점이기도 합니다.

2단계. 검증되지 않은 회상 (The unverified recall)

24시간 후, 다른 티켓이 도착합니다. 에이전트(Agent)는 동일한 메모리 저장소(Memory store)로부터 정보를 회상(Recall)합니다. 에이전트는 회상된 사실이 환각(Hallucination)에서 기인했다는 사실을 알지 못합니다. 에이전트는 그 회상된 내용을 마치 실제 사실(Ground truth)인 것처럼 취급합니다.

제 고객 중 한 명인 CTO는 이를 이렇게 표현했습니다. "우리 에이전트들은 어제 무엇을 결정했는지는 아주 잘 기억합니다. 하지만 자신들이 옳았는지 여부는 기억하는 데 형편없습니다."

이 단계는 대부분의 팀이 가장 잘못 구축하는 계층입니다. 쓰기(Write) 작업은 잘 갖춰져 있지만, 읽기(Read) 작업은 비용이 들지 않는 작업으로 취급됩니다.

제가 수행한 모든 기업 감사(Audit)에서 2단계 실패의 특징은 동일했습니다.

메모리 회상(Memory recall)은 로그(Log)에 기록됩니다. 회상된 응답(Recall response)도 로그에 기록됩니다. 하지만 회상 신뢰도(Recall-confidence)에 대한 단언(Assertion)은 없습니다. 회상 검증(Recall-verification) 단계도 없습니다. 회상 출처의 기원(Recall-source provenance) 확인도 없습니다.

회상된 사실이 틀렸을 때, 에이전트는 그것을 확신을 가지고 사용합니다. 회상된 사실에 출처(Provenance)가 없음에도 불구하고, 에이전트는 마치 출처가 있는 것처럼 확신을 가지고 사용합니다.

3단계. 전파 (The propagation)

이제 잘못된 사실이 다음 응답에 포함됩니다. 그 응답은 하류 워크플로(Downstream workflow)에 의해 읽힙니다. 이 하류 워크플로는 자동화되어 있습니다. 하류 워크플로에는 단언(Assertion)에 이의를 제기할 중간 단계의 인간(Human in the middle)이 없습니다.

이 지점이 바로 기업 팀들이 벽에 부딪히는 곳입니다.

서두의 복구 사례에서, 고객 서비스 에이전트는 한 티켓에 대해 "환불 승인됨"을 저장했습니다. 이후 48시간 동안 다른 세 개의 티켓에서 회상이 발생했습니다. 각각의 회상은 환불을 처리하는 금융 워크플로(Financial workflow)를 트리거했습니다. 금융 워크플로는 검증된 티켓을 신뢰하는 것과 동일한 방식으로 에이전트의 회상을 신뢰했습니다.

월요일 아침 재무 운영(Finance ops) 팀이 불일치를 발견했을 때, 원래는 단 한 줄의 환각에서 시작된 사건으로 인해 이미 47개의 하류 이벤트(Downstream events)가 실행된 상태였습니다.

이 단계의 특징은 워크플로 그래프(Workflow graph) 그 자체입니다. 만약 에이전트의 메모리 쓰기(Memory writes)에 대해, 시스템 기록(System of record)을 바탕으로 에이전트의 주장을 독립적으로 검증하지 않는 하류 워크플로가 있다면, 귀하는 3단계 노출(Stage-three exposure) 상태를 운영하고 있는 것입니다.

4단계. 신뢰의 붕괴 (The trust collapse)

CFO는 대시보드에서 잘못된 매출 수치를 확인합니다. 고객 지원 편지함은 "요청하지도 않았는데 왜 환불해 주었나요?"라는 이메일로 가득 찹니다. 이사회는 왜 자동화 이니셔티브 (automation initiative)가 재무적 손실 (finance leakage)을 초래했는지 묻습니다.

이 단계는 경력을 끝내고 예산을 중단시키는 단계입니다.

이 단계에서의 복구는 기술적인 문제가 아닙니다. 조직적인 문제입니다. 누군가는 왜 에이전트 (agent)가 이런 행동을 했는지 CFO에게 설명해야 합니다. 누군가는 법무팀을 만족시킬 사후 분석 보고서 (post-mortem)를 작성해야 합니다. 누군가는 "검증 단계를 추가하겠습니다"라는 말이 포함되지 않은 언어로, CEO에게 이런 일이 다시는 발생하지 않을 것이라고 확신시켜야 합니다.

이 계층에 닿는 제 고객 컨설팅 사례 중 대부분은 기술적 패턴을 수정해 달라는 요청을 받지 않습니다. 대신 운영 팀과 자동화 이니셔티브 (automation initiative) 사이의 신뢰를 재구축할 프레임워크 (framework)를 작성해 달라는 요청을 받습니다.

그 프레임워크에는 이름과 형태가 있습니다. 그것은 도구가 아닙니다. 그것은 읽기 측 검증 (read-side validation), 출처 추적 (provenance tracking), 드리프트 탐지 (drift detection), 그리고 시스템 기록 (systems of record)이 아닌 에이전트 응답에서 유래한 입력값에 대한 메모리 격리 패턴 (memory quarantine pattern)을 다루는 규율 (discipline)입니다.

이 글에 그 프레임워크를 쓰지는 않겠습니다. 제가 코드를 붙여넣지 않을 이유와 같습니다.

만약 당신의 팀이 인터넷에서 프레임워크를 그대로 복사한다면, 그 규율이 내포하고 있는 판단력 (JUDGMENT) 없이 규율의 형태 (FORM)만을 채택하게 됩니다. 그 판단력이 바로 프레임워크가 존재하는 이유입니다. 규율은 채택되지만 판단력은 채택되지 않으며, 결국 90일 이내에 2단계 실패가 다시 발생합니다.

기업 팀들이 저에게 가장 먼저 묻는 것

팀이 이러한 실패 모드 (failure mode)를 가지고 저를 찾아올 때, 첫 번째 질문은 항상 동일한 내용의 변형입니다.

자동화를 완전히 제거하지 않고 어떻게 신뢰를 회복할 수 있습니까?

답은 팀이 저에게 연락했을 때 손상 체인 (damage chain)의 어느 단계에 와 있느냐에 따라 달라집니다.

1단계의 경우, 답은 읽기 측 계측 (read-side instrumentation)입니다. 저렴하며, 오후 한나절이면 충분합니다. 조직적인 개입도 필요 없습니다.

2단계의 해결책은 에이전트 유도 메모리 쓰기 (agent-derived memory writes)에 대한 격리 패턴 (quarantine pattern)을 적용한 출처 추적 (provenance tracking)입니다. 약 일주일 정도 소요됩니다. 엔지니어 한 명과 에이전트의 신뢰 예산 (trust budget)을 관리하는 제품 소유자 (product owner) 한 명이 필요합니다.

3단계의 해결책은 워크플로우 그래프 (workflow-graph) 재작업입니다. 3주에서 6주가 소요되며, 여러 팀의 협업이 필요합니다.

4단계의 해결책은 기술적인 문제가 아닙니다. 사후 분석 (post-mortem), 메모리 위생 프레임워크 (memory hygiene framework), 이사회 보고용 신뢰 회복 계획 (trust restoration plan), 그리고 분기별 감사 리듬 (quarterly audit rhythm)을 결합한 60일간의 프로젝트입니다.

1단계에서 저를 찾는 팀은 비용을 가장 적게 지불하며 가장 빠르게 회복합니다. 4단계에서 저를 찾는 팀은 가장 많은 비용을 지불하며 회복하는 데 가장 오랜 시간이 걸립니다.

마지막 질문

외부에서 보기에는 이것이 실패 모드 (failure modes)의 벽처럼 보일 수 있다는 것을 알고 있습니다.

저는 이전에도 기업 팀들이 정확히 이러한 진단 과정을 거치도록 안내한 적이 있으며, 대개 범위 산정 (scope)에 비용이 들지 않는 짧은 대화로 시작했습니다. 첫 번째 대화를 통해 저는 보통 귀사가 어느 단계에 있는지, 그리고 해당 단계에서 회복하는 데 드는 대략적인 비용이 얼마인지를 알 수 있습니다.

만약 귀사가 현재 이러한 실패 모드에 처해 있다면, 아래 댓글창을 이용해 주세요. 귀사가 생각하는 단계와 그렇게 생각하게 만든 증상을 한 줄로 설명해 주시면 됩니다.

저는 보통 상황을 빠르게 좁혀줄 수 있는 진단 질문으로 답변을 드릴 것입니다.

패턴 라이브러리 (pattern library)는 더 많은 기업 팀들이 실제로 겪고 있는 실패 모드들을 명시할 때만 성장합니다.