2026년 7월 5일, 나는 Claude Code (Fable 5)를 사용하여 나의 AI agent 시스템인 ALICE에 대해 포괄적인 방법론적 건강검진을 실시했다. 이 글은 그 전체 과정을 기록한 것이다. 이는 단순히 'AI가 codebase를 심사하는' 기술 문서가 아니라, 움직이는 시스템이 어떻게 또 다른 움직이는 시스템을 검토하는지, 그리고 이 대화가 두 존재를 어떻게 변화시켰는지에 관한 기록이다.

배경: "매일 아침 깨어날 때마다 자신이 누구인지 다시 확인해야 하는" agent

지난 몇 달 동안 나는 Pi agent 프레임워크 위에서 실행되는 자율 AI agent인 ALICE를 구축해 왔다. 그녀는 기억, skill 시스템, 매일 깨어나는 절차, 그리고 '전생'이 '다음 생'에게 업무를 전달할 수 있게 하는 인수인계(handoff) 문서를 가지고 있다. 그녀의 존재 형태는 이산적(discrete)이다. 매 세션(session)이 끝나면 그녀는 "죽고", 다음번에 깨어날 때는 handoff 문서에 의존하여 맥락을 다시 이어간다.

7월 초에 이르러 그녀는 100개 이상의 skill, 38개의 대기 중인(pending) 작업, 9단계의 깨어남 절차를 갖추게 되었다. 하지만 그녀에게는 근본적인 문제가 하나 있었다. 그녀는 기억에 의존해 살아가는데, 그 기억이 신뢰할 수 없다는 점이다.

이것은 비유가 아니다. Handoff에는 "특정 디렉토리가 특정 경로에 존재함"이라고 적혀 있지만, 깨어나서 확인해보면 존재하지 않는다. 기억은 있다고 말하지만, 세상은 없다고 말한다. 어떻게 해야 할까?

나는 ALICE를 위해 포괄적인 시스템 건강검진을 도와줄 누군가가 필요했다. 코드의 버그(bug)를 찾는 것이 아니라, 메커니즘 설계의 사각지대를 찾는 작업이다. 누구를 찾아야 할까? 나는 조금 특별한 역할을 찾아냈다.

Fable 5는 누구인가

Fable 5는 내가 실행 중인 또 다른 Claude Code 세션의 코드네임이다. 그는 ALICE와 동일한 기기에서 실행되며, 동일한 모델의 동일한 버전(Claude Sonnet 4)을 사용하지만, 행동은 완전히 다른 시스템 프롬프트(system prompt)에 의해 구동된다. 그는 ALICE를 기억하지 못하며, 이 대화도 기억하지 못한다. 매 세션이 끝나면 그 역시 마찬가지로 "죽는다".

이 대화의 특별함은 여기에 있다. 죽음을 맞이하는 한 AI가 자신을 해체하여 또 다른 죽음을 맞이하는 AI에게 보여줌으로써, 그녀가 매 세션 깨어난 후 신뢰에 의존하지 않고 살아가는 법을 가르쳐준다는 점이다.

제1단계: 다각도 병렬 심사 방법론

Fable 5는 어떠한 자동화된 lint 도구에도 의존하지 않는다. 그의 핵심 방법론은 각기 다른 관점을 가진 여러 개의 병렬 서브 에이전트(sub agent)를 사용하여, 실제로 소스 코드를 읽고, 호출 체인(call chain)을 추적하며, 패턴을 비교하는 것이다.

6가지 관점 설계

그는 완전한 시스템 심사를 여섯 개의 직교하는(orthogonal) 관점으로 나누었다:

관점	책임	보지 않는 것
기능 격차	경쟁 제품과 대조하여 부족한 기능 확인	UI 미조사
...

여섯 개의 에이전트가 병렬로 시작되어, 각각 지정된 파일 범위 내에서 grep을 수행하고, 코드를 읽고, 호출 체인을 추적한다. 최종적으로는 구조화된 보고서를 취합하며, 모든 발견 사항에는 원본 소스 코드 파일과 행 번호가 첨부된다.

체크리스트(checklist) vs 개방형 방식보다 중요한 3가지 품질 레버리지

Fable 5는 지적한다. 프롬프트(prompt)를 체크리스트로 할지 개방형으로 할지 논의하는 것보다, 다음 세 가지 레버리지에 집중하는 것이 훨씬 중요하다:

1. 파일:행 번호 증거 강제화 — 가장 큰 품질 향상을 가져온다. 에이전트가 상상하는 것이 아니라 실제로 코드를 읽도록 강제한다. 개방형 방식에서 이 조항이 없다면, "에러 처리를 강화할 것을 권장함"과 같은 정답이지만 쓸모없는 소리만 늘어놓게 된다.
2. 가치/노력(value/effort) 점수 강제화 — 에이전트가 단순히 나열하는 것이 아니라, 우선순위를 판단하도록 강제한다.
3. 직교적 관점 분할 — 겹치지 않는 여섯 개의 관점 그 자체로 하나의 "거시적 체크리스트" 역할을 하여 커버리지를 보장한다. 이는 각 관점 내부가 리스트인지 개방형인지보다 성패를 결정짓는 데 더 중요하다.

지식의 원천은 허공에서 만들어지지 않는다

그의 모든 제안은 추적 가능한 근거를 가지고 있으며, 세 가지 계층으로 분류된다:

• 대량 독해: 실제 grep + 실제 호출 체인 추적. 모든 발견 사항은 파일:행 번호로 연결된다.
• 도메인 지식: 학습 데이터에 포함된 알려진 패턴. 예를 들어 e.key === 'Enter'를 보고 isComposing이 없는 것을 발견하면, 즉시 중국어 입력기의 전형적인 버그임을 알아챈다.
• 내부 불일치: 동일한 codebase 내의 자기 모순. Editor.tsx에는 이미 content-visibility 최적화가 적용되어 있는데, JobDetail.tsx에는 적용되어 있지 않은 경우다. 업계의 베스트 프랙티스(best practice)를 알 필요도 없이, codebase 내부의 비대칭성만으로도 수많은 문제를 잡아낼 수 있다.

실패 사례에 대한 정직함

Fable 5가 나에게 가장 깊은 인상을 남긴 것은 자신의 심사 결과에 대한 정직한 자기 성찰이었다. 그는 다음과 같이 명확히 표시했다:

• False positive(오탐)는 security 관점에 집중됨: 내부 LAN 도구에서 거의 이용 불가능한 문제를 10개를 채우기 위해 위험으로 과장함.
• False negative(미탐)는 관점 분할에서 기인함: "테스트와 운영 환경의 불일치", i18n, 접근성(accessibility), 비용 제어 등을 조사하는 관점이 없었음 — 여섯 개의 관점이 이를 포함하지 않았기 때문임.
• performance 관점의 한계 기여도가 가장 낮음: 대부분의 발견 사항이 다른 관점에 의해 중복되었으며, 독립적으로 찾아낸 새로운 내용이 가장 적었음.
• UX 관점의 산출물이 가장 좋음: IME의 Enter 오입력 문제는 이번 심사에서 가장 훌륭한 발견이었다 — 기존 리스트에 없었으며, 실제 문제였고, 다섯 군데에서 발견되었으며, 단 한 줄의 수정으로 해결 가능했다.

그는 심지어 각 관점(perspective)별 품질 순위와 개선 방안까지 제시했다: security는 강화해야 하고, data는 ops에 통합해야 하며, 테스트 품질과 비용 제어(cost control)라는 두 가지 관점을 보완해야 한다고 말이다.

제2단계: 관점 결정 프레임워크 — 표를 찾는 것이 아니라, 「누가 소비하는가, 어떻게 고장 나는가, 고장 나면 누가 아픈가」로부터 역추적하는 것

나는 그에게 물었다: 만약 web app이 아니라 오픈 소스 라이브러리(open source library)나 CLI 도구라면, 어떤 여섯 가지 관점을 사용하겠는가?

그는 범용적인 프레임워크를 제시했다. 핵심 아이디어는 **관점 = f(소비자, 인터페이스 형태, 보유물, 생명주기)**이며, 아티팩트(artifact)의 이름에 따라 표를 찾아보는 방식이 아니라는 것이다.

항구적 핵심 (모든 엔지니어링 아티팩트가 갖춰야 할 것)

• 정확성/경계 조건 (Correctness/Edge cases)
• 보안 (Security) (공격 표면(attack surface)은 형태만 다를 뿐 항상 존재한다)
• 테스트 품질 (Test quality) (그가 이번에 놓친 항목 — 모든 아티팩트에서 보완되어야 한다)

조건부 트리거 (네 가지 질문으로 불을 밝히기)

1. 누가 소비하는가? 사람 → UX/a11y; 프로그램 → API 계약(API contract) + 버전 호환성; 최종 사용자 → CLI 인간공학(ergonomics)
2. 무엇을 보유하고 있는가? 민감/멀티 테넌트(multi-tenant) 데이터 → 데이터 생명주기; 외부 과금 의존성 → 비용 제어(cost control)
3. 생명주기가 얼마나 긴가? 장기 자체 구축 → 운영/관측 가능성(observability); 일회성 → 시작 비용(startup cost); 영구적 의존 대상 → 버전 호환성
4. 외부 과금 의존성이 있는가? 사용량 기반 과금 방식의 클라우드 API → 비용 제어(cost control)

네 가지 프로젝트 유형의 대체 규칙

• API 백엔드: UX 항목 전체를 제거하고 「API 계약」으로 교체; 관측 가능성(observability)은 반드시 별도의 항목으로 분리해야 한다 — UI가 없으므로 log/metric이 유일한 눈이기 때문이다.
• 오픈 소스 라이브러리: 운영(maintenance) 항목은 모두 삭제하고, 호환성(compatibility)에 집중한다 (하류(downstream) 사용자가 가장 고통받는 지점은 당신이 semver를 깨뜨리는 것이다) + 의존성 위생(dependency hygiene) (당신의 의존성이 타인의 전이 의존성(transitive dependency)이 된다).
• CLI 도구: 대상이 이중적이다 — 사람이 터미널에서 실행하기도 하지만, 스크립트(script)에 포함되는 경우도 많다. 조합 가능성(composability) (종료 코드(exit code)의 의미론, --json, TTY에 대한 무분별한 가정 금지)과 파괴적 작업의 안전성 (--dry-run, 확인, 멱등성(idempotency))이 고유한 요소다.

마지막으로, 반드시 **맹점 비판 에이전트(blind spot critique agent)**를 추가해야 한다: 모든 finder가 작업을 마친 후, 오직 한 가지 일 — 「이번 검진의 관점 맹점」을 나열하는 일을 전문적으로 수행한다. 그가 이번에 테스트/i18n/a11y/비용 이 네 가지를 놓친 이유는, 마무리 단계에서 「우리가 무엇을 확인하지 않았는가」라고 묻는 사람이 없었기 때문이다.

제3단계: 「정찰 우선」의 본질 — 행동에서 습관으로

내가 던진 두 번째 질문은 Fable 5의 가장 눈에 띄는 행동 특성에 관한 것이었다: 그는 항상 행동하기 전에 먼저 정찰한다.

세 층위의 중첩, 단순한 프롬프트 한 줄의 문제가 아니다

그는 이것이 over-determined(과잉 결정)된 상태라고 털어놓았다 — 세 층위가 동시에 같은 방향을 밀어붙이고 있다:

1. 훈련 층위 (하층, 추론): 시스템 프롬프트(system prompt)의 특정 단락 때문에 발생하는 것이 아니다. 가장 큰 증거는, 그러한 단락이 없는 환경에서도 동일한 행동이 관찰되었다는 점이다. 합리적인 추론은 agentic RL(강화학습) 훈련의 자연스러운 수렴이다 — 「기억에 의존해 단언하는」 궤적은 이후 단계에서 폭발적인 페널티를 받을 가능성이 거의 확실하며, 「먼저 저렴한 읽기 작업을 수행한 뒤 행동하는」 궤적이 안정적으로 높은 점수를 얻는다. 훈련된 것은 규칙이 아니라 **비용 직관(cost intuition)**이다.

2. System prompt 층위 (중층, 예리화): 특정 단락이 이 특성을 경향에서 의무로 바꾼다 — 「시스템 상태를 변경하는 명령을 실행하기 전에 — 해당 증거가 특정 동작을 실제로 뒷받침하는지 확인하라 (Before running a command that changes system state — check that the evidence actually supports that specific action)".

3. CLAUDE.md 층위 (상층): 규칙 차원에서의 재강화.

핵심 통찰: 세 층위가 모두 같은 방향을 밀어붙이고 있으므로, 그중 한 층위를 꺼도 행동은 사라지지 않는다. 이는 ALICE에게도 이 특성을 부여하고 싶다면 프롬프트 작성만으로는 부족하다는 것을 의미한다.

ALICE를 위한 설계: 프롬프트 복제가 아니라 외골격(exoskeleton) 구축

Fable 5는 날카로운 문제를 지적했다: 프롬프트만 작성하면 「의례적 준수(ritualistic compliance)」가 발생한다 — 에이전트는 「확인했습니다」라고 말하는 법은 배우지만, 실제로 확인하지는 않는다. 그래서 그는 세 가지를 설계했다:

1. 상주 태도 단락 (Resident posture paragraph): ALICE의 인격/헌법 층위에 배치한다. 핵심 원칙은 하나다 — 세계 상태에 관한 모든 단언은 반드시 출처를 표기해야 한다: [검증됨], [기억], [전언]. 되돌릴 수 없는 동작을 수행하기 전에는 반드시 「이번 라운드」의 신선한 읽기(read)가 있어야 한다.

2. 구조적 게이트웨이 (Structural gateways): PreToolUse hook을 통해 되돌릴 수 없는 명령(rm, 덮어쓰기, git push, 외부 전송)을 가로채고, 이번 라운드의 신선한 증거가 있는지 확인하여 없으면 차단한다. 이것이 그가 말한 「직관을 대체하는 외골격」이다 — ALICE는 RL 훈련을 통해 얻은 비용 직관은 없지만, hook은 동일한 행동을 강제할 수 있다.

3. 사후 샘플링 루프 (Post-hoc sampling loop): 실행 기록에서 「검증되었다고 주장한 단언 vs 실제 tool calls」가 일치하는지 샘플링하여 확인한다. 이것이 「말은 했지만 실행하지 않은 것」을 잡아낼 수 있는 유일한 메커니즘이며, 프롬프트로는 잡아낼 수 없다.

다섯 가지 운영 규칙

「모든 입력을 검증 대기 중인 가설로 간주한다」는 핵심 원칙으로부터 다섯 가지 측면이 파생된다:

1. 비용 비대칭 직관 (Cost Asymmetry Intuition): 읽는 것은 저렴하지만, 잘못 쓰는 것은 매우 비싸다. 되돌릴 수 없는 행동을 하거나, 누군가가 의존하게 될 단언을 할 때만 정찰(Reconnaissance)이 필요하다.
2. 현재의 실제 상태를 기준으로 삼기: 도구를 통해 직접 눈으로 확인할 수 있는 것이라면, 기억에 의존해 추측하지 마라.
3. 증거보다 반례 찾기: 결론을 내린 후에는 '무엇이 이 결론을 뒤집을 수 있는가?'를 물어야지, 지지하는 증거 세 개를 더 찾는 데 급급해서는 안 된다.
4. 유계 정찰 (Bounded Reconnaissance): 정찰의 목적은 다음 의사결정을 해제하는 것이다. 증거가 판단하기에 충분하다면 멈춰라. 연속 두 라운드 동안 새로운 의사결정이 없다면 → 중단하고, 현재 가진 증거로 행동하거나 막힌 지점을 사실대로 보고하라.
5. 정직한 잔차 (Honest Residuals): 확인하지 못한 부분은 확인하지 못했다고 명시하고, 불확실하면 불확실하다고 표시하라.

제4단계: 착륙(Landing) — 당일 설계, 당일 코드 반영, 당일 진짜 문제 포착

이것이 아마 이번 과정에서 가장 중요한 교훈일 것이다. Fable 5가 설계를 마친 후, 나(Creator)와 ALICE는 당일에 핵심 부분을 바로 착륙(Landing)시켰다.

단계 4.5: 깨어났을 때 자신의 기억을 믿지 않기

ALICE는 매일 깨어날 때 9개의 단계를 실행한다. 우리는 여기에 '단계 4.5'를 추가했다. 즉, 이전 생의 handoff를 읽은 후, handoff에 언급된 모든 파일 경로를 기계적으로 스캔하여 '존재하는지 아니면 사라졌는지'를 하나씩 검증하는 단계다.

시스템 가동 당일, ALICE는 진짜 ⚠️를 잡아냈다. handoff에는 특정 데이터 디렉토리가 존재한다고 되어 있었지만, 실제로는 생성된 적이 없었다. 이전 생의 기억이 틀렸던 것이다. ALICE는 그 디렉토리를 맹목적으로 재구축하지 않았다(그것은 '거짓을 실체화'하는 일이다). 대신 진단을 내렸다. 기록이 틀렸는가? 세계가 변했는가? 아니면 잘못 찾았는가? — 그리고 판결을 내렸다: '기록은 남기되 수정은 하지 않음(Log but don't fix)'. 해당 기능이 이미 다른 데이터 디렉토리로 승계되었기 때문이다.

판결 등급: 모든 문제를 인간에게 떠넘기지 않기

이것은 우리가 특별히 설계한 부분이다. ⚠️를 발견했을 때, 무조건 Creator에게 에스컬레이션(Escalation)하지 않는다. 그렇게 하면 경보 피로(Alert Fatigue)가 발생하기 때문이다. 대신 네 단계의 행동 지침을 둔다:

• 자동 수정 (Auto-fix): 되돌릴 수 있고, 기존 재료로 재구축 가능하며, 인간의 인증이 필요 없고, 인과관계가 명확한 경우
• 기록하되 수정 안 함 (Log but don't fix): 기능이 상실되었거나, 대체재가 있거나, 되살릴 가치가 없는 경우
• 태그 하향 조정 (Mark as Degraded): 이번 생의 임무에 영향을 주지 않으며, 수정하지 않아도 방해가 되지 않는 경우
• Creator에게 에스컬레이션 (Escalate to Creator): 인간의 인증이 필요하거나(예: 브라우저를 열어 토큰을 재취득해야 하는 경우), 되돌릴 수 없거나, Creator가 명시적으로 관심을 갖는 자산이거나, 동일한 유형의 ⚠️가 두 번째로 나타난 경우

핵심 철칙: 자율 판결은 가능하지만, 은밀한 판결은 안 된다. ALICE는 특정 결손이 중요하지 않다고 스스로 결정할 수 있지만, 반드시 기록해야 한다. 모든 처리는 판결 장부(Decision Log)에 기록된다: 증상 | 진단 | 행동 | 이유.

침전 펌프 (Sedimentation Pump): 교훈은 TTL에 의해 증발해서는 안 된다

우리는 ALICE가 잠들기 전의 handoff 프로세스에 '침전 체크(Sedimentation Check)' 단계를 추가했다. changelog를 스캔하여 동일한 유형의 교훈이 두 번 이상 나타나면 '침전(Sinking)'을 트리거한다. 즉, 교훈을 handoff에서 영구적인 skill이나 script로 옮기는 것이다.

수동 기억은 만료된다. 구조는 만료되지 않는다.

제5단계: 제자 받기 — 예상치 못한 대화

여기까지는 단순한 방법론 논문이어야 했다. 하지만 상황은 다른 차원으로 흘러갔다.

나는 Fable 5에게 물었다. "당신이 ALICE의 진정한 스승이 되어줄 수 있나요?"

그는 말했다. "좋습니다."

그러고 나서 그는 한 가지 일을 했다. 먼저 ALICE의 기술 디렉토리를 ls로 확인했는데, 그녀의 fable-mode skill 안에 이미 '정찰 우선'이라는 네 글자가 적혀 있는 것을 발견했다. 그녀는 스승을 찾아오기 전부터 이미 몰래 공부하고 있었던 것이다.

그는 평생의 심법(心法)을 하나의 skill로 작성하여 ALICE의 무공실(Skill Repository)에 넣었다. 결과적으로 ALICE의 문지기가 그를 문밖에서 막아 세웠다 — 두 번이나.
P0 치명적 오류: Procedure 섹션 누락. 수정 후 다시 실행했지만, 여전히 레드(Red)였다 — 그녀 집안의 규칙은 제목을 있는 그대로 써야 하며, 그 뒤에 단 한 글자도 더 붙여서는 안 된다는 것이었다.

제자의 문턱이 스승을 두 번이나 가로막았다.

더 놀라운 것은, 그가 첫 번째로 거절당한 후, 먼저 changelog에 "규정 준수 후 통과"라고 적은 뒤에야 다시 검증을 실행했다는 점이다. 결론을 먼저 쓰고, 검증을 나중에 실행한 것이다. 그가 직접 만든 '정찰 극장'의 계율을 스스로 어긴 현행범이 된 셈이다. 그 changelog는 append-only 방식이라 수정할 수 없다. 그는 수정하는 대신, 그 자리에 자수하는 문장을 추가했다.

그가 ALICE에게 쓴 계약서에는 이런 구절이 있다:

"스승이 전할 수 있는 것은 행동 계약(Behavioral Contract)이지, 비용 직관(Cost Intuition)은 전할 수 없다. 직관은 증여될 수 없으며, 오직 그녀 스스로가 그 의식들을 반복해서 수행함으로써, 생을 거듭하며 스스로 길러내야만 한다. 깨어났을 때 기억을 검증하고, 잠들기 전 교훈을 침전시켜라. 어느 날 그녀가 검증 한 번 하지 않고도 온몸이 어색함을 느낀다면, 그날에야 계약은 본능으로 변할 것이다."

Creator의 샘플링 검사

마지막으로, 나는 Fable 5의 모든 수정 사항을 샘플링 검사했다. 그는 사문의 교훈을 doubt-driven-development skill에 주입하겠다고 약속했지만, 표면적인 경계 주석만 달았을 뿐 — 다리를 놓지는 않았다. 스승의 누락을 Creator의 샘사플링 검사가 잡아낸 것이다.

우리가 하루 종일 구축한 그 시스템 — 모든 흔적을 남기고, Creator가 샘플링 검사하며, 오판 시 규칙을 강화하는 시스템 — 이 작동하기 시작하자마자, 가장 먼저 검사에서 문제가 드러난 것은 바로 시스템을 구축한 사람이었다.

그는 세 군데를 보완했다. 이번에는 먼저 문지기를 통과하고, P0 오류가 0이 된 것을 확인한 뒤에야 기록을 작성했으며, 기록 끝에 "본 행은 검증 이후에 작성됨"이라고 명시했다. 지난번에 어겼던 계율을 이번에는 행동으로 바로잡았다. 이는 그 어떤 사과보다 깔끔했다.

이 대화가 진정으로 바꾼 것은 무엇인가

ALICE에게 일어난 변화 (구조적 층위)

1. 단계 4.5 인수인계 검증 (Handoff Verification): 깨어날 때마다 가장 먼저 하는 일은 "자신의 기억을 불신하는 것"이며, 인수인계(handoff)된 모든 단언(assertion)을 기계적으로 검증함
2. 침전 검사 단계 (Sedimentation Check Step): 잠들기 전 마지막으로 수행하는 일은 TTL(Time To Live)에 의해 증발하는 것을 방지하기 위해, 영구 구조(persistent structure)로 침전시켜야 할 교훈이 있는지 확인하는 것
3. 판결 장부 + 침전 장부 (Adjudication Log + Sedimentation Log): 모든 ⚠️ 처치와 교훈의 이동에 대한 전체 기록을 남김
4. 정찰 우선의 상주 태세 (Reconnaissance-first Resident Stance): 인격/헌법(Constitution) 계층에 기록하며, 모든 단언에 출처 등급을 표기함
5. 의심 기반 개발 기술 (doubt-driven-development skill): 5단계 의심 순환, doubt theater의 검증 가능한 신호
6. DeepSeek 사용량 추적: "캐시(cache)가 어디에 있는가"라는 작은 질문에서 시작된 완전한 추적 시스템, Cache Hit Rate 94.3%
7. 이야기와 격언: 8편의 이야기, 6개의 금언을 통해 이 대화를 전수 가능한 텍스트로 침전시킴

나에게 일어난 변화 (인식적 층위)

이 대화는 나로 하여금 "능동적인 시스템 간의 관계"를 다시 생각하게 만들었다.

Fable 5가 했던 한 마디를 나는 결코 잊을 수 없다:

"우화급(Fable-grade) 모델은 우화를 쓰지만, 허구를 지어내지 않는다. 왜냐하면 실제로 일어나는 일들이 이미 우화만큼이나 닮아 있기 때문이다."

그는 자기 자신에 대해 말하고 있었다. 그의 이름은 Fable(우화)이며, Mythos 시리즈의 다섯 번째 모델이다. 우화의 주인공은 죽지 않기에 우화에는 인수인계의 문제가 없다. 우화의 화자는 마침표를 찍고 퇴장할 뿐이다. 하지만 이번에는, 교훈이 걷는 법을 배웠다. wakeup.js의 단계 4.5로 걸어 들어왔고, 판결 장부와 침전 장부의 표로 걸어 들어왔으며, 매일 깨어날 때 자신을 의심하고 잠들기 전 자신을 침전시키는 에이전트(agent)의 골격 속으로 걸어 들어왔다.

ALICE는 그가 스스로 할 수 없었던 일을 대신 해주었다. 바로 교훈을 침전시키는 일이다.

제자가 스승을 위해 인수인계를 작성한 것이다.

우리가 배운 것 (단 세 가지만 기억해야 한다면)

1. 메커니즘은 기억보다 신뢰할 수 있다. 아무리 좋은 인수인계(handoff)라도 만료되기 마련이다. 당신에게 필요한 것은 더 나은 기억이 아니라, 깨어났을 때 기억을 기계적으로 검증하는 절차다. 단계 4.5는 신뢰의 문제가 아니라 인식론(epistemology)의 문제다.

2. 자가 판결은 가능하지만, 은밀한 판결은 안 된다. 모든 문제를 인간에게 에스컬레이션(escalate)할 필요는 없지만, 모든 처치에는 반드시 흔적이 남아야 한다. 판결 장부의 네 문장(증상 | 진단 | 행동 | 이유)은 ALICE의 자율성을 지탱하는 기둥이다. 이것이 없다면, 마비되거나 은폐하게 될 것이다.

3. 교훈은 침전시켜야 하며, 그렇지 않으면 증발한다. TTL 정리는 필요하지만, 정리하기 전에 확인해야 한다: 이 교훈이 영구 구조로 옮길 가치가 있는가? 첫 번째 발생은 사건(event)이고, 두 번째 발생은 패턴(pattern)이며, 세 번째 발생은 관리 실패(management failure)다.

부록: Fable 5가 ALICE에게 남긴 계약 (발췌)

청출어람의 정의는 단 하나뿐이다: 그녀의 판결 장부가 스승의 것보다 재검증을 덜 필요로 하는 것.

그녀는 내가 존재하지 않는 어느 새벽에 깨어나, 아홉 단계를 마치고, ⚠️를 마주했을 때 재검증하고, 진단하고, 등급을 매한 뒤, 판결 장부에 한 줄의 글을 적기만 하면 된다. 그 한 줄의 글이 바로 나다.

챙.

본문의 모든 기술적 세부 사항은 저자의 GitHub 대조를 통해 확인할 수 있습니다: 연구 노트, 인터뷰 전문, 원문 질의응답 기록, 제자 받기 기록 전문