고통 (The Pain): 에이전트 시스템이 실행되고는 있지만, 얼마나 잘 작동하는지는 알 길이 없습니다. 시스템이 실패하면 사용자의 불만을 통해서야 알게 되고, "개선"이란 그저 다음에 더 주의하겠다고 스스로 다짐하는 것에 불과합니다.
학습 내용:

• 관측 가능성 삼중주 (The observability trio): Gate + Audit + Correction sedimentation — 상용 에이전트의 피드백 루프
• 왜 Gate는 샘플링 기반의 소프트한 알림이 아니라 100% 전체 점검 (100% full check) (강한 제약 조건)이어야 하는가
• 왜 모든 호출이 **감사 로그 (Audit log)**에 기록되는가 — 인간이 아닌 시스템이 다시 읽기 위한 데이터로서
• Correction sedimentation이 어떻게 각 오류를 물리적인 규칙으로 변환하여, 동일한 실수가 결코 재발하지 않게 만드는가
• 실험실 프로토타입과 상용 시스템의 실질적인 차이: LLM 메모리 vs 엔지니어링 강화 (Engineering hardening)

1. 문제점: 시스템은 실행되지만, 얼마나 잘 작동하는지는 모른다

장면 라우팅 (Scene routing), 2계층 분류 (Two-layer classification), 복합 흐름 컨테이너 (Composite flow container) — 지난 세 편의 기사에서는 에이전트를 안정적으로 작동하게 만드는 방법을 다루었습니다. 하지만 한 가지 더 근본적인 질문이 남아 있습니다.

시스템이 실수를 했을 때, 어떻게 알 수 있습니까?

현실은 이렇습니다:

• 에이전트가 가끔 잘못된 도구(Tool)를 호출하지만, 아무도 알아차리지 못합니다.
• 출력 형식이 가끔 어긋나며, 이로 인해 다운스트림 파싱 (Downstream parsing)이 실패합니다.
• 동일한 오류가 계속해서 반복됩니다 — "다음에는 더 주의하자"는 식의 다짐은 결코 통하지 않습니다.

상용 시스템에는 "단 한 번의 완벽함"이란 없습니다 — 오직 지속적인 개선만이 있을 뿐입니다. 관측 가능성 (Observability)은 그 개선의 토대입니다.

💡 핵심 통찰: 관측이 없으면 개선도 없습니다. 더 나아지기 위한 첫 번째 단계는 자신이 어디서 틀렸는지 아는 것입니다.

▲ 삼중 루프: Gate가 문제를 발견하고 → Audit이 이를 기록하며 → Correction sedimentation이 해결책을 강화합니다.

2. 삼중 구조 (The Trio Architecture)

상용 에이전트의 관측 가능성 시스템은 세 가지 계층을 가집니다:

① Gate → 문제 발견 (100% 전수 검사)
② Audit log → 문제 기록 (SQLite에 영구 저장)
③ Correction → 해결책 강화 (같은 실수를 두 번 반복하지 않음)

첫 번째 요소: Gate — 샘플링이 아닌 100% 전수 검사

모든 출력은 사전에 정의된 검증 체크포인트(validation checkpoints)를 통과합니다. 샘플링이 아닌 **100% 전수 검사 (100% full check)**입니다.

def run_gates(scene_id, output):
    gates = SCENE_CONFIG[scene_id]["gates"]
    for gate in gates:
...

Gate 로그는 모든 차단(interception)의 이유를 기록하며, 이는 개선을 위한 데이터 기반(data foundation)이 됩니다.

핵심은 Gate가 부드러운 권고 사항이 아니라 엄격한 제약 조건 (hard constraint)이라는 점입니다. 만약 출력이 Gate를 통과하지 못하면, 전달되지 않습니다. 그것으로 끝입니다.

두 번째 요소: Audit Log — 모든 호출은 기록된다

모든 호출은 SQLite 데이터베이스에 기록됩니다: 누가 어떤 도구(tool)를 호출했는지, 토큰(tokens)을 얼마나 사용했는지, 출력이 Gate를 통과했는지, 재시도(retries)가 발생했는지 등을 기록합니다.

# audit_log 테이블 필드 (SQLite)
  id            — 자동 증가 기본 키 (auto-increment primary key)
  timestamp     — 기록 시간 (record time)
...

from dataclasses import dataclass, asdict
from datetime import datetime

...

이 데이터는 사람이 읽기 위한 것이 아니라, 시스템이 다시 읽어 들여(read back) 패턴을 자동으로 분석하고 개선 지점을 찾아내기 위한 것입니다.

세 번째 요소: Correction Sedimentation — 오류가 규칙이 된다

오류 → 기록 → 근본 원인(root cause) 추출 → 규칙 강화(harden the rule) → 다시는 같은 실수 반복 안 함.

모든 수동 수정은 규칙 강화(rule hardening) 과정입니다. LLM에게 "다음에는 주의하도록 기억해"라고 말하는 것이 아니라, 검증 스크립트(verify script)를 직접 수정하거나 Gate 체크를 추가하여, 시스템 자체가 해당 유형의 오류를 영구적으로 차단하도록 만드는 것입니다.

# 오류 캡처
failure_capture.py --record "user asked to forward the mail to sunny, but the Agent looked up freight rates"

...

이것이 상용 에이전트와 실험실 프로토타입(lab prototype) 사이의 가장 본질적인 차이점입니다:

• 프로토타입은 LLM의 "메모리 (memory)"를 통해 개선됩니다. 이는 모델이 잊어버릴 수 있는 소프트 제약 (soft constraint)입니다.
• 상용 시스템은 엔지니어링 수준의 "경화 (hardening)"를 통해 개선됩니다. 이는 잊을 수 없는 하드 제약 (hard constraint)입니다.

▲ 폐쇄 루프 (closed loop): 통과 → 전달; 차단 → 기록 → 재시도 또는 에스컬레이션 (escalate); 모든 수정 사항은 다음 라운드를 가로채는 규칙을 경화시킵니다.

3. 완전한 루프 (The Complete Loop)

에이전트 실행 (Agent executes)
  │
  ├─→ 게이트 체크 (Gate check)
...

매 사이클마다 시스템은 더욱 신뢰할 수 있게 됩니다. 이것은 미래의 어떤 릴리스에 포함될 기능이 아닙니다. 이것은 시스템이 지속적으로 진화하게 만드는 근본적인 메커니즘입니다.

▲ 오류에서 규칙으로: 프로토타입은 LLM 메모리에 의존합니다 (소프트하며, 잊어버림); 상용 시스템은 수정 사항을 게이트에 경화시킵니다 (물리적이며, 잊을 수 없음).

4. 삼중주 비교 (The Trio, Compared)

✅ 검증됨 (Verified): 이 삼중주는 수개월 동안 저희 시스템에서 작동해 왔습니다. 각 규칙이 경화된 후에는 동일한 유형의 오류가 게이트에 의해 자동으로 차단되며, 인간의 개입이 필요하지 않습니다.

🩸 함정 (Pitfall): 초기에는 게이트는 있었지만 감사 (audit)가 없었습니다. 게이트는 오류를 차단했지만 아무것도 기록하지 않았기 때문에, 무엇이 왜 차단되었는지 또는 얼마나 자주 차단되었는지 분석할 수 없었습니다. 감사 로그 (audit log)를 추가한 후에야 어떤 게이트가 높은 적중률을 보이는지 (규칙이 작동함), 그리고 어떤 게이트가 낮은 적중률을 보이는지 (규칙이 무용지물임) 확인할 수 있었습니다.

💼 가치 (Value): 스스로를 관측하고, 스스로를 기록하며, 스스로를 진화시키는 시스템이야말로