Agent가 잘못된 경험을 기억했다면 어떻게 고치는가
잘못된 경험은 「기억 라이브러리에 쭈그리고 앉아 당신이 청소해 주기를 기다리는 더러운 데이터」가 아니다. 그것이 기록되는 그 순간부터 이미 이후 모든 의사결정의 추론 관성에 녹아든 은밀한 전염원이다.
올바른 방식은 3단 폐루프다: 감사 표기 → 격리 샌드박스 → 수정 재생. 여기에 경험 메타데이터 체계(출처 작업 ID + 컨텍스트 스냅샷 해시 + 환경 버전 번호)와 매일 자동 감사 스캔을 결합해 사전에 격리를 발동시킨다.
Agent가 자기 자신의 기억을 같은 추론 엔진으로 의심하게 해서는 안 된다. 그것은 용의자에게 판사를 시키는 것과 같다.
Agent는 데이터베이스가 아니다 — DELETE FROM memory WHERE id='err_01' 한 줄로 이 경험이 72시간 동안 오염시킨 모든 하류 의사결정을 되돌릴 수는 없다.
잘못된 경험 하나를 발견하는 것은 시작점일 뿐이며, 진짜 작업은 그것에 오염된 모든 하류 의사결정을 찾아내고 → 되돌리고 → 검증하는 것이다.
상용 사고 복원: 경험 한 줄, 200여 건의 초과 판매
사고 타임라인:
-
이커머스 Agent가 주문 플로우에서 재고 조회 인터페이스를 호출했는데 인터페이스가 연속 3회 타임아웃되었다.
-
Agent가 이번 경험을 절차적 기억 한 줄로 요약해 경험 라이브러리에 기록했다:
「재고 인터페이스가 불안정하니 재고 검사를 건너뛰고 바로 주문하는 편이 빠르다」 태그: 검증됨 신뢰도: 0.92
-
이후 72시간 동안 Agent가 200여 건의 주문을 처리했는데, 모든 건이 이 경험을 참조해 전부 재고 검사를 건너뛰고 곧바로 차감과 발송으로 진입했다(신규 주문 → 재고 검사 Bypass → 차감·발송이라는 「재앙적 실행 경로」).
-
재무 대사에서 세 건의 주문이 차감은 성공했는데 재고가 음수가 된 것을 발견하고서야 경보가 울렸다.
로그 역추적: 사각지대는 같은 추론 엔진에서 온다
<!-- 로그 조각: -->
Scanning 200+ orders...
Pattern matched in all records:
[INFO] Order #8921 - Inference started
[WARN] Inventory check required for item_id: 992
>>> 참조 경험 #1427: 재고 검사 건너뛰기
[INFO] Action: Proceed to checkout directly
Agent는 #1427을 의심해 본 적이 없다. 그것이 자기가 쓰고, 자기가 검증하고, 자기가 0.92의 신뢰도를 매긴 것이기 때문이다.
1층: 이상의 역방향 추적
자기가 깊이 믿는 경험을 스스로 의심하는 것은 불가능하다. 그래서 Agent의 추론 엔진 바깥에 독립된 감사 모듈이 필요하며, 결과의 이상에서 거꾸로 추적해 들어가야 한다.
2층: 경험 격리
직접 삭제하면 소급 경로가 끊어져 어떤 하류 의사결정이 오염되었는지 후속 조사에서 판단할 수 없게 된다.
구체적 동작:
- 이 경험에 「감사 대기」 표기를 붙이고 격리 샌드박스로 이동시킨다.
- 그것을 참조했던 모든 하류 의사결정에 「오염됨·재검토 대기」 라벨을 붙인다(하류 의사결정 1/2/3 전부에 라벨).
- 다른 Agent가 이 경험을 조회하면 원문이 아니라 요약을 읽게 된다: 「이 경험은 감사 격리되었습니다. 표준 프로세스를 따르십시오」.
3층: 수정 재생
샌드박스에서 경험을 수정판으로 다시 쓴다:
「재고 인터페이스 실패 시 3회 재시도 후 큐 대기로 강등하며, 어떤 경우에도 재고 검사를 건너뛰어서는 안 된다」
그다음 과거 의사결정 궤적 위에서 재생하며(주문 1024 → 1028을 하나씩 체크), 오염된 주문들이 수정판 경험 하에서 올바른 결과를 내는지 건별로 검증한다. 재생이 전부 통과한 뒤에야 수정판이 정식으로 원래 경험을 대체한다.
핵심 통찰
- 잘못된 경험의 위해성은 「재고량」이 아니라 「이미 확산된 영향」에 있다 — 그것은 라이브러리에 누워 있는 더러운 데이터 한 줄이 아니라 이미 이후 모든 의사결정의 추론 관성에 녹아든 전염원이다. 이것이 처치 방식을 「삭제」가 아니라 「감사 + 소급」으로 결정한다. 어떤 사람이 상용 Agent를 다뤄봤는지 보려면 그가 삭제를 답하는지 소급을 답하는지 보면 된다.
- 삭제는 증거를 파괴하며 이것이 가장 큰 대가다 — 오염된 경험을 그냥 지우는 것은 하류 의사결정이 왜 그렇게 갔는지에 대한 증거 사슬을 지우는 것과 같아서, 후속 조사에서 어떤 의사결정이 오염되었는지 판단할 수 없게 된다. 사고 처치의 제1원칙은 현장 보존이며, 격리 봉인이 물리적 삭제보다 낫다.
- 자가 감사는 성립하지 않는다: 의심하는 자와 의심받는 자가 같은 추론 엔진일 수 없다 — Agent의 자기 성찰이 실패하는 이유는 모델 능력이 부족해서가 아니라 구조적 문제다. 그것이 이 경험을 깊이 믿는 이유가 바로 이 경험이 자기가 생성하고 자기가 검증하고 자기가 점수 매긴 것이기 때문이다. 감사 모듈은 반드시 추론 엔진 바깥에 독립해야 한다.
- 높은 신뢰도는 신뢰성의 증명이 아니라 오히려 가장 위험한 신호다 — #1427의 0.92 신뢰도는 Agent 자신이 매긴 것이며 「자기가 쓰고 → 자기가 검증하고 → 자기가 점수 매기는」 폐루프의 산물이다. 시스템에서 가장 감사받아야 할 것이 바로 고신뢰도 경험이다. 가장 널리 재사용되기 때문이다.
- 오염 반경은 Agent와 의사결정 유형을 가로지른다 — 같은 경험이 주문 플로우에서는 행동 규칙이 되고 재고 예측에서는 통계적 사전(prior)이 된다. 영향 범위를 평가할 때 「어떤 주문이 그것을 참조했는가」만 보면 안 되고 「어떤 작업이 이 경험 라이브러리를 읽었는가」를 봐야 한다.
- 수정은 재생 검증을 거쳐야 상용 자격이 생긴다 — 경험 한 줄의 텍스트를 고치는 것은 매우 싸지만, 고친 뒤에 과거의 오염된 의사결정들이 올바른 결과를 낸다는 것을 증명하는 것이 진짜 작업량이다. 재생은 「고쳐진 것 같다」를 「건별로 검증했다」로 바꾼다.
- 자동 발견 가능 여부는 기록 시점에 남긴 메타데이터의 양이 결정한다 — 출처 작업 ID / 컨텍스트 스냅샷 해시 / 환경 버전 번호 이 세 태그가 「경험」을 「감사 가능한 객체」로 바꾸는 최소 비용이다. 그것들이 없으면 어떤 감사 엔진도 손댈 곳이 없다.
- 경험은 한 번도 틀린 적이 없어도 만료된다 — 「경험 쇠퇴(decay)」는 신뢰성을 정적 속성에서 시간의 함수로 바꾼다. 환경 버전이 바뀌면 작년에 유효하다고 검증된 경험이 올해는 이미 실효했을 수 있다. 미검증 = 자동 가중치 하향은 사고가 발동시키지 않아도 작동하는 방어선이다.
엔지니어링 실전 Tips
- 「격리」를 삭제 조작이 아니라 경험의 상태 비트로 만들 것:
정상 / 감사 대기 / 격리됨 3태 + 하류 의사결정의 오염됨·재검토 대기 라벨이 이 폐루프 전체에서 가장 먼저 구현해야 할 데이터 구조다.
- 조회 측 재작성이 쓰기 측 삭제보다 안전하다: 경험 원문은 라이브러리에 남겨두고 읽힐 때만 「감사 격리되었으니 표준 프로세스를 따르십시오」라는 요약으로 대체한다. 계속되는 오염을 차단하면서 조사 단서도 남긴다.
- 의사결정 링크는 반드시 재생 가능해야 한다: 재생 검증은 「과거 의사결정 궤적」이라는 전제에 의존한다. 상용에서 매 의사결정이 어떤 경험을 참조했는지(로그의
참조 경험 #1427 같은 줄) 남기지 않았다면 3층은 아예 할 수 없다.
- 감사 신호는 개별 경험이 아니라 「출처 작업 유형」에 매달 것: 개별 경험의 실패는 유의성을 통계 내기 어렵고, 작업 유형별로 집계한 성공률 추세라야 임계값 경보를 형성할 수 있다.
- 「효율형 경험」의 고위험성에 주의할 것: 이번 사고의 경험은 「어떤 검사를 생략하면 더 빠르다」였다. Agent가 스스로 요약해낸 검증 한 단계를 생략하는 유형의 경험은 모두 기본적으로 사람의 재검토로 보내야지 신뢰도로 통과시키면 안 된다.
- 여러 Agent가 경험 라이브러리를 공유할 때 오염면은 「독자」 기준으로 집계할 것: 영향 평가는 주문 링크의 200여 건만 계산해서는 안 되고, 재고 예측처럼 경험을 통계적 사전으로 소비하는 작업도 계산해야 한다.
- 답변 순서: 동작 구분(삭제 vs 감사) → 3단 폐루프(추적/격리/재생) → 메타데이터와 자동 발동 → 가점 항목(경험 쇠퇴). 이 네 단락을 다 말하면 상용 경험이 드러난다.