고통 (The Pain): 당신의 에이전트가 실수를 저질렀습니다. 당신은 이를 교정했습니다. 에이전트는 사과하며 "알겠습니다, 기억할게요"라고 말합니다. 일주일 후, 에이전트는 단지 다른 모습으로 똑같은 실수를 반복합니다. 당신은 계속 증상만을 치료하고 있을 뿐, 문제는 실제로 해결되지 않습니다.
배울 내용:

• "다음에는 주의해"가 에이전트 개발에서 가장 큰 거짓말인 이유 — 그리고 왜 LLM 메모리가 시스템 수준의 규칙 (system-level rules)을 결코 대체할 수 없는지
• 5단계 교정 침전 루프 (correction sedimentation loop): 오류 발생 → 기록 → 근본 원인 추출 → 규칙 임베딩 (embed rule) → 반복 방지
• 에이전트를 물리적으로 강화하는 구체적인 FailureRecord 스키마 (schema) 및 SCENE_CONFIG 예시
• 규칙을 검증 스크립트 (verify scripts), 게이트 체크 (gate checks), 도구 화이트리스트 (tool whitelists), SOP 주입 (SOP injection)으로 "물리화 (physicalize)"하는 방법
• 프로덕션 시스템에서 교정 침전이 "더 똑똑한 모델"보다 우수한 이유 — 그리고 두 방식이 어떻게 서로를 보완하는지

1. 문제점: "다음에는 주의해"는 가장 큰 거짓말이다

LLM 에이전트가 실수를 저지를 때, 가장 흔하게 처리되는 방식은 다음과 같습니다:

개발자: 이건 틀렸어. 다음에는 주의해.
에이전트: 알겠습니다. 기억할게요. 다음에는 조심하겠습니다.
(일주일 후)
...

왜 "다음에는 주의해"는 결코 작동하지 않을까요?

LLM의 "메모리 (memory)"는 **소프트 제약 (soft constraint)**이기 때문입니다. LLM은 멀티 턴 대화 (multi-turn dialogs)를 거치며 내용을 잊어버립니다. 긴 컨텍스트 (long contexts) 안에서 주의력 (attention)이 흐트러집니다. 압박을 받으면 가장 "편안한" 생성 모드로 돌아갑니다. 당신이 "기억해"라고 말할 때, 에이전트는 그 순간에만 동의할 뿐입니다. 시스템 수준에서 규칙을 "임베딩 (embed)"할 수 있는 능력은 없습니다.

이것이 실험실 프로토타입과 상용 시스템을 가르는 분수령입니다:

• 실험실 프로토타입: 개선이 LLM의 "메모리"에 의존함 (소프트 제약 — 잊어버림)
• 상용 시스템: 개선이 엔지니어링 수준의 "임베딩 (embedding)"에 의존함 (하드 제약 — 절대 잊지 않음)

💡 핵심 통찰: 모든 인간의 교정은 규칙을 임베딩 (embedding) 할 수 있는 기회입니다. LLM에게 "다음에는 주의하세요"라고 말하지 마세요. 검증 스크립트 (verify script)를 직접 수정하거나 게이트 체크 (gate check)를 추가하여 시스템이 이러한 유형의 오류를 영원히 차단하도록 만드세요.

2. 핵심 메커니즘: 5단계 폐쇄 루프 (Five-Step Closed Loop)

교정 침전은 완전한 5단계 루프입니다:

① 오류 발생 → ② 기록 → ③ 근본 원인 추출 → ④ 규칙 임베딩 (embed rule) → ⑤ 재발 방지

1단계: 오류 발생

에이전트가 규정에 맞지 않는 출력을 생성합니다. 게이트 (gate)에 의해 차단되거나, 개발자 또는 사용자가 수동으로 이를 발견합니다.

2단계: 기록

실패 저장소 (failure store)에 기록합니다. 단순히 에러 메시지만 기록하는 것이 아니라 다음 사항들을 함께 기록합니다: 상황 (scene), 도구 호출 체인 (tool-call chain), 컨텍스트 요약 (context summary), 그리고 에러 유형 (error type).

failure_capture.py --record \
  --scene email \
  --tool-calls '["fetch_inbox", "send_email"]' \
...

3단계: 근본 원인 추출

오류를 분석하여 실제 원인을 찾아냅니다. 표면적인 설명인 "에이전트가 잘못된 도구를 사용함"이 아니라, "이메일 상황 (email scene)의 도구 화이트리스트 (tool whitelist)에 smtp_send가 누락됨"과 같은 원인을 찾아야 합니다.

4단계: 규칙 임베딩 (Embed the Rule)

근본 원인을 실행 가능한 규칙으로 전환합니다:

• 검증 스크립트 (verify script) 수정
• 새로운 게이트 체크 (gate check) 추가
• 해당 상황 (scene)의 도구 화이트리스트 (tool whitelist) 업데이트

# 강화 전 (Before hardening)
SCENE_CONFIG = {
    "email": {
...

5단계: 재발 방지

규칙이 임베딩되면 시스템이 자동으로 오류를 차단합니다. 아무도 "주의"할 필요가 없으며, 해당 오류는 발생 불가능한 상태가 됩니다.

3. 기술적 구현

3.1 실패 기록 형식 (Failure Record Format)

모든 교정에는 구조화된 저장 공간이 필요합니다. 다음은 실패 저장소에서 사용하는 스키마 (schema)입니다:

from dataclasses import dataclass

@dataclass
...

3.2 규칙의 물리화 (Physicalizing Rules)

이 전체 메커니즘을 작동하게 만드는 규칙은 다음과 같습니다: 모든 임베딩된 규칙은 시스템 레이어 (system layer)에 "물리화 (physicalized)" 되어야 합니다. 즉, 프롬프트 (prompt)에 작성되는 것이 아니라, 스크립트 (script)에 작성되어야 합니다.

임베딩 방법 (Embedding method)	예시 (Example)	효과 (Effect)
검증 스크립트 수정 (Modify a verify script)	verify/no_fabricated_data.py	출력 전 자동 검사 (automatic check before output)
...	...	...
Correction store architecture: gate intercept → failure store → verify scripts, gate checks, tool whitelists, SOP injection
실패 저장소 (failure store)는 게이트 (gate)와 네 가지 임베딩 대상 사이에 위치합니다 — 규칙은 프롬프트가 아닌 스크립트에 존재합니다.

3.3 주간 검토 (Weekly Review)

임베딩은 일회성 작업이 아닙니다. 규칙은 퇴색되고, 상황은 변하며, 새로운 오류 유형이 나타납니다. 따라서 루프 (loop)에는 정기적인 검토 주기 (review cadence)가 필요합니다:

# 매주 월요일, 아직 임베딩되지 않은 교정 사항을 자동 스캔
scan_corrections.py --unembedded
# 출력: 이번 주 3개의 새로운 교정 사항, 2개 임베딩됨, 1개 분석 대기 중

임베딩되지 않은 각 교정 사항은 다시 근본 원인 분석 (root-cause analysis) 과정을 거칩니다. 임베딩된 각 규칙은 신뢰하기 전에 반드시 회귀 테스트 스위트 (regression suite)를 통과해야 합니다:

4. 이것이 더 똑똑한 모델보다 중요한 이유

많은 사람들이 에이전트 (agent)가 실수를 하는 이유는 모델이 충분히 똑똑하지 않기 때문이며, 더 강력한 모델로 교체하면 모든 것이 해결될 것이라고 가정합니다.

그것은 오해입니다.

더 강력한 모델은 오류율을 낮추긴 하지만, 결코 100%에 도달할 수는 없습니다. 반면, 교정 침전 (Correction sedimentation)은 모델이 얼마나 강력하든 약하든 상관없이, 이미 발견된 모든 오류를 "재발 불가능"한 상태로 만듭니다.

이 두 가지는 상호 보완적입니다:

• 더 강력한 모델 (Stronger model) → **알 수 없는 오류 (unknown errors)**의 발생률을 낮춤
• 교정 침전 (Correction sedimentation) → **알려진 오류 (known errors)**의 재발률을 제거함

상용 시스템은 "절대 실수하지 않는 것"을 쫓지 않습니다. 그들은 "실수 후에 자동으로 개선되는 것"을 쫓습니다. 교정 침전은 그러한 자동 개선의 근저에 있는 메커니즘입니다.

5. 당신의 현재 위치

지금 당신은 에이전트가 실수할 때마다 "다음번에는 주의해"라고 말하는 무력한 개발자가 아닙니다. 당신은 모든 실수를 시스템의 진화를 위한 연료로 바꿀 수 있는 엔지니어가 되어가고 있습니다.

모든 인간의 교정은 낭비되는 노력이 아닙니다. 그것은 시스템에 한 번의 진화를 제공하는 것입니다. 오류 → 기록 → 근본 원인 (root cause) → 규칙 삽입 (embed rule) → 동일한 실수 반복 방지. 하루하루 시스템은 더 안정적으로 변하며, 당신의 유지보수 비용은 계속해서 낮아집니다.

다음 기사: 마지막 안전 기둥 — 도구 격리 (tool isolation)와 최소 권한 (least privilege), 에이전트의 행동 경계를 완전히 봉쇄하는 방법.

저자 소개: Wu Ji (无记) — 에이전트 엔지니어링 (Agent engineering), 루프 엔지니어링 (Loop Engineering), 디지털 전환 (digital transformation)에 집중하는 AI 및 디지털화 실무자. 실용적이고 직접적인 튜토리얼 — 따라 하기만 하면 바로 작동합니다.