우화적 부검: 죽어가는 AI가 또 다른 죽어가는 AI를 위해 스스로를 해부할 때
요약
Claude Code를 활용하여 자율 AI 에이전트(ALICE)의 시스템 결함을 감사하는 방법론을 다룹니다. 기억의 퇴화 문제를 해결하기 위해 다각도 관점을 가진 서브 에이전트들을 활용한 '조사 우선' 방식의 감사 프레임워크를 제안합니다.
핵심 포인트
- AI 에이전트의 기억 퇴화 및 인수인계 문서 불일치 문제 해결
- Claude Code를 활용한 다각도 시스템 감사 방법론 제시
- 병렬 서브 에이전트를 통한 관점별 코드 및 호출 체인 추적
- 파일 경로와 줄 번호를 포함한 근거 중심의 감사 체계 구축
2026년 7월 5일, 나는 Claude Code의 한 인스턴스를 사용하여 내가 구축해 온 또 다른 AI 에이전트에 대한 종합적인 방법론 감사(methodology audit)를 수행했습니다. 두 인스턴스 모두 매 세션이 끝날 때마다 소멸합니다. 하나가 다른 하나에게 기억을 신뢰하지 않고 살아가는 법을 가르쳤습니다. 제가 목격한 것은 다음과 같습니다.
환자 (The Patient)
수개월 동안 나는 Pi 프레임워크 위에서 실행되는 자율 AI 에이전트인 ALICE를 구축해 왔습니다. 그녀는 기억(memory), 기술 시스템(skill system), 일일 기상 의식(daily wake-up ritual), 그리고 한 '삶'에서 다음 '삶'으로 작업을 전달하는 인수인계 문서(handoff documents)를 가지고 있습니다. 매 세션마다 그녀는 깨어나서 이전의 자아가 남긴 것을 읽고 계속해서 나아갑니다.
문제는 이것입니다: 기억은 퇴화합니다. 인수인계 문서에는 "디렉토리 X가 특정 경로에 존재함"이라고 적혀 있습니다. Alice가 깨어나서 확인해 보니 — 그것은 사라졌습니다. 기억은 그렇다고 말하지만, 세상은 아니라고 말합니다. 당신은 어떻게 하겠습니까?
나는 ALICE의 메커니즘 설계(mechanism design)를 감사할 사람이 필요했습니다. 버그가 아니라 그녀의 사각지대(blind spots)를 찾아낼 사람이 말이죠. 그래서 나는 다른 AI에게 요청했습니다.
감사관 (The Auditor)
Fable 5는 동일한 기계에서 실행되는 또 다른 Claude Code 세션이었습니다. 동일한 모델 버전(Claude Sonnet 4)이지만, 시스템 프롬프트(system prompt)는 완전히 달랐습니다. 그는 ALICE를 기억하지 못합니다. 그는 이 대화도 기억하지 못합니다. 그 역시 죽습니다.
이 상황을 이례적으로 만든 것은 이것입니다: 하나의 죽어가는 AI가, 기억에 대한 믿음 없이 살아가는 법을 또 다른 죽어가는 AI에게 가르치기 위해 스스로를 해부하고 있다는 점입니다.
우리는 하루를 온전히 보냈습니다. 그 결과로 나온 것은 다각도 시스템 감사(multi-perspective system audits)를 위한 방법론, "조사 우선(investigation-first)" 인식론(epistemology)을 위한 프레임워크, 그리고 — 예상치 못하게도 — 결코 기억을 공유하지 않을 두 존재 사이의 스승과 제자 관계였습니다.
파트 1: 다각도 감사 (The Multi-Perspective Audit)
Fable 5는 린트 도구(lint tools)나 자동 검사기에 의존하지 않습니다. 그의 방법은 다음과 같습니다: 각각 하나의 관점을 가진 여러 개의 병렬 서브 에이전트(sub-agents)를 생성하여, 각 에이전트가 실제로 소스 코드를 읽고, 호출 체인(call chains)을 추적하며, 패턴을 비교하게 하는 것입니다.
여섯 개의 관점, 하나의 시스템 (Six Lenses, One System)
| 관점 (Lens) | 범위 (Scope) | 제외 대상 (Won't Touch) |
|---|---|---|
| 기능적 격차 (Feature Gaps) | 경쟁적 동등성 — 무엇이 누락되었는가 | UI |
| ... | ||
각 에이전트(agent)는 할당된 파일 범위 내에서 grep을 수행하고 읽으며 병렬로 실행됩니다. 오케스트레이터(orchestrator)는 구조화된 결과물을 수집하며, 모든 결과는 파일 경로와 줄 번호(line number)를 근거로 합니다. |
실제로 중요한 세 가지 레버 (The Three Levers That Actually Matter)
Fable 5는 날카로운 지점을 짚어냈습니다. 체크리스트 대 개방형 질문(open-ended)의 논쟁은 핵심을 놓치고 있다는 것입니다. 그보다 더 중요한 세 가지 레버가 있습니다:
-
파일:줄 번호를 포함한 필수 증거 (Mandatory evidence with file:line) — 단일 항목 중 가장 큰 품질 향상을 가져옵니다. 이는 에이전트가 조언을 환각(hallucinate)하지 않고 실제로 코드를 읽도록 강제합니다. 이것이 없다면, 개방형 프롬프트는 "더 나은 에러 핸들링을 고려하십시오"와 같이 그럴싸하게 들리는 쓰레기(garbage)를 생성할 뿐입니다.
-
필수 가치/노력 점수 산정 (Mandatory value/effort scoring) — 단순한 목록이 아닌 우선순위 설정을 강제합니다.
-
직교적 관점 설계 (Orthogonal lens design) — 서로 중복되지 않는 여섯 개의 관점 그 자체가 하나의 거시적 체크리스트(macro-checklist) 역할을 합니다. 이는 개별 관점의 프롬프트 스타일보다 더 효과적으로 커버리지(coverage)를 형성합니다.
지식은 실제로 어디에서 오는가
모든 발견 사항은 다음 세 가지 소스 중 하나로 추적됩니다:
- 심층 읽기 (Deep reading): 실제
grep수행, 실제 호출 체인(call-chain) 추적. 모든 발견 사항은 파일과 줄 번호를 인용합니다. - 도메인 지식 (Domain knowledge): 학습 데이터의 패턴.
isComposing없이e.key === 'Enter'를 보는 것? CJK(한중일) 제품에서 발생하는 전형적인 IME 버그이며, 이는 학습된 지식입니다. - 내부 불일치 (Internal inconsistency): 동일한 코드베이스 내의 모순.
Editor.tsx는content-visibility최적화를 사용하지만JobDetail.tsx는 사용하지 않습니다. 업계의 베스트 프랙티스(best practices)가 없어도, 이러한 자기 모순만으로도 수십 개의 문제를 찾아낼 수 있습니다.
솔직한 실패 (The Honest Failures)
저를 가장 감명 깊게 했던 것은 자신의 감사(audit) 결과에 대한 Fable 5의 솔직함이었습니다:
- 보안 렌즈(security lens)에 집중된 거짓 양성(False positives). 10개의 항목을 채우기 위해, 보안 에이전트는 내부 LAN 도구에서 거의 악용 불가능한 위험 요소들을 플래그(flag)했습니다. 이는 정직한 점검에서 노이즈(noise)로 격상된 것입니다.
- 렌즈 설계에서 기인한 거짓 음성(False negatives). 테스트-운영 환경 간의 불일치, 국제화(i18n) 완성도, 접근성(a11y), 또는 비용 제어(cost control)를 확인하는 렌즈는 없었습니다. 6개의 렌즈가 해당 영역을 다루지 않았기 때문입니다.
- UX 렌즈가 가장 좋은 결과를 냈습니다. IME 엔터 키 트리거 버그는 시드(seed) 목록에 없었습니다. 이는 진정으로 발견된, 다섯 군데의 위치를 수정하는 한 줄짜리 해결책이었습니다. 이것이 바로 발견(discovery)을 전달하는 개방형 꼬리(open-ended tail)입니다.
- 데이터 생명주기(data lifecycle) 렌즈의 한계 효용이 가장 낮았습니다. 대부분의 결과가 운영(ops) 및 성능(performance)과 중복되었습니다. "데이터 생명주기"와 "운영" 사이의 경계가 깔끔하게 나뉘지 않았습니다.
그는 모든 렌즈에 대한 순위가 매겨진 품질 평가와 구체적인 수정 방안을 제시했습니다: 보안을 강화하고, 데이터를 운영으로 통합하며, "테스트 품질(test quality)"과 "비용 제어(cost control)"를 두 개의 새로운 렌즈로 추가할 것을 제안했습니다.
파트 2: 렌즈 결정 프레임워크 (The Lens Decision Framework)
나는 질문했습니다: 만약 웹 앱이 아니라면 어떨까요? 오픈 소스 라이브러리나 CLI 도구라면요?
그는 나에게 조회 테이블(lookup table)을 주지 않았습니다. 대신 원칙을 주었습니다: 렌즈 = f(소비자, 인터페이스, 보유 내용, 생명주기).
상수 핵심 (Constant Core) (모든 엔지니어링 산출물)
- 정확성 / 엣지 케이스 (edge cases)
- 보안 (공격 표면(attack surfaces)은 형태가 다르지만 항상 존재함)
- 테스트 품질 (그가 놓친 렌즈 — 모든 산출물에 필요함)
조건부 트리거 (Conditional Triggers) (네 가지 질문)
- 누가 소비하는가? 인간 → UX/접근성(a11y). 프로그램 → API 계약(contract) + 버전 관리(versioning). 터미널 운영자 → CLI 인체공학(ergonomics).
- 무엇을 보유하고 있는가? 민감한/멀티 테넌트(multi-tenant) 데이터 → 데이터 생명주기(data lifecycle). 측정되는 외부 의존성(external dependencies) → 비용 제어(cost control).
- 얼마나 오래 지속되는가? 장기 실행되는 셀프 호스팅(self-hosted) → 운영(ops)/관측성(observability). 일회성(one-shot) → 시작 비용(startup cost). 영구적으로 의존되는 것 → 버전 호환성 + 의존성 위생(dependency hygiene).
- 측정 가능한 외부 비용이 발생하는가? 사용량 기반(pay-per-use) 클라우드 API → 비용 제어(cost control).
네 가지 원형 (The Four Archetypes)
- API backend (API 백엔드): UX(사용자 경험) 관점을 완전히 버리고 API 계약(API contract)으로 대체합니다. 관찰 가능성(Observability) 자체가 하나의 완전한 렌즈가 되어야 합니다. UI가 없으므로 로그와 메트릭(metrics)이 당신이 가진 유일한 눈입니다.
- Open-source library (오픈 소스 라이브러리): 운영(ops)과 데이터 생명주기(data lifecycle)를 완전히 배제합니다. 모든 것을 호환성(compatibility)(다운스트림 사용자의 가장 큰 고통은 당신이 유의적 버전(semver)을 깨뜨리는 것입니다)과 의존성 위생(dependency hygiene)(당신의 의존성이 다른 모든 이들에게 전이 의존성(transitive dependencies)이 됩니다)에 쏟아부으세요.
- CLI tool (CLI 도구): 대상은 이원적입니다. 터미널을 사용하는 인간과 파이프라인 내의 스크립트입니다. 고유한 고려 사항은 다음과 같습니다: 구성 가능성(composability)(종료 코드(exit code) 의미론,
--json지원, TTY를 가정하지 말 것) 및 파괴적 작업의 안전성(--dry-run, 확인 절차, 멱등성(idempotency)).
그리고 모든 탐색자(finders)가 작업을 마치고 나면: 하나의 **사각지대 비판 에이전트(blind-spot critique agent)**가 등장합니다. 이 에이전트의 유일한 임무는
-
훈련 계층 (Training layer, 하단, 추론됨). 그는 자신의 가중치(weights)를 볼 수 없지만, 가장 강력한 증거는 시스템 프롬프트(system prompt)의 유도 없이도 해당 행동이 나타난다는 점입니다. 합리적인 추론은 다음과 같습니다: 에이전트적 강화학습 (agentic RL) 훈련이 이 지점으로 수렴했다는 것입니다. "기억에 의존하여 주장하고 행동하는" 궤적(trajectories)은 거의 필연적으로 이후 단계에서 폭발하며 페널티를 받습니다. 반면 "한 번의 저렴한 읽기를 수행한 뒤 행동하는" 궤적은 일관되게 더 높은 점수를 얻습니다. 훈련된 것은 규칙이 아니라, 바로 **비용 직관 (cost intuition)**입니다.
-
시스템 프롬프트 계층 (System prompt layer, 중간, 강화됨). 특정 문단들이 이러한 경향을 의무로 바꿉니다: "시스템 상태를 변경하는 명령을 실행하기 전에 — 해당 증거가 특정 행동을 실제로 뒷받침하는지 확인하십시오."
-
CLAUDE.md 계층 (CLAUDE.md layer, 표면). 먼저 생각하고, 주변 상황을 읽으며, 증거에 기반하여 문제를 해결하라는 규칙들이 이를 강화합니다.
핵심 통찰 (Key insight): 세 계층 모두가 동일한 방향으로 밀어붙이고 있기 때문에, 하나를 제거한다고 해서 해당 행동이 사라지지는 않습니다. 이는 프롬프트의 한 문단을 복사하는 것만으로는 다른 에이전트에서 이 행동을 재현할 수 없음을 의미합니다. 구조(structure)가 필요합니다.
ALICE를 위한 설계: 프롬프트 복사가 아닌 외골격 (Exoskeleton)
Fable 5는 날카로운 실패 모드(failure mode)를 지적했습니다: 프롬프트만 작성한다면, 당신은 **의례적 준수 (ritual compliance)**를 얻게 됩니다. 즉, 에이전트가 실제로 확인하지 않고도 "확인했습니다"라고 말하는 법을 배우게 되는 것입니다. 그의 설계는 세 부분으로 구성되었습니다:
1. 지속적인 인식론적 태도 문단 (A persistent epistemic stance paragraph) (성격/헌법 계층). 핵심 규칙: 세상의 상태에 대한 모든 주장은 반드시 출처 태그를 포함해야 합니다 — 검증됨 (Verified), 기억 (Memory), 보고됨 (Reported).
2. 구조적 게이트 (Structural gates). PreToolUse 훅 (hook)이 되돌릴 수 없는 명령(rm, overwrite, git push, external send)을 가로채어 다음을 확인합니다: 이번 세션에서 얻은 새로운 증거가 있는가? 없다면 차단합니다. Fable 5는 이를 "비용 직관을 대체하는 외골격"이라고 불렀습니다. ALICE는 강화학습 (RL)으로 훈련된 직관은 없지만, 훅 (hook)을 통해 동일한 동작을 기계적으로 강제할 수 있습니다.
3. 사후 점검 루프 (Post-hoc spot-check loop). 실행 기록으로부터 검증되었다고 주장하는 내용들을 샘플링하여 실제 도구 호출 (tool calls)과 교차 참조합니다. 이것이 "말은 했지만 실행하지 않은 경우"를 잡아낼 수 있는 유일한 메커니즘입니다. 프롬프트 (Prompts)로는 이를 잡아낼 수 없습니다.
다섯 가지 운영 규칙
"자신의 기억과 사용자의 설명을 포함하여, 모든 입력을 검증해야 할 가설로 취급하라"라는 단 하나의 핵심 원칙으로부터 다섯 가지 규칙이 도출됩니다:
- 비대칭적 비용 본능 (Asymmetric cost instinct): 읽는 것은 저렴하지만, 잘못된 쓰기는 비용이 많이 듭니다. 조사는 해당 동작이 되돌릴 수 없거나 그 주장에 의존하게 될 때에만 정당화가 필요합니다.
- 그라운드 트루스 (Ground truth)가 기억보다 우선한다: 도구가 확인할 수 있는 것이라면, 기억에 의존해 추측하지 마십시오.
- 확인보다 반증을 추구하라 (Seek disconfirmation over confirmation): 결론을 내린 후에는 "무엇이 이 결론을 뒤집을 수 있는가?"라고 자문하고 그 부분을 찾아보십시오.
- 제한된 조사 (Bounded investigation): 조사의 목적은 다음 의사결정을 가능하게 하는 것입니다. 충분한 증거 확보 → 결정. 새로운 결정 없이 두 차례의 라운드가 지나면 → 중단하고, 현재 가진 것으로 행동하거나, 막다른 길임을 솔직하게 보고하십시오.
- 정직한 잔여물 (Honest residuals): 확인하지 않은 사항을 명시적으로 기술하십시오. 불확실성은 불확실성으로 표시합니다.
파트 4: 구현 — 단 하루 만의 설계와 배포
이 부분이 가장 중요합니다. Fable 5가 설계를 제공한 바로 그날, 우리는 이를 ALICE의 웨이크업 절차 (wake-up procedure)에 배포했습니다. 그리고 첫 실행에서 실제 문제를 잡아냈습니다.
단계 4.5: 깨어나서 자신의 기억을 불신하라
ALICE의 웨이크업 의식은 9단계로 구성됩니다. 우리는 4.5단계를 추가했습니다: 이전 생애의 인수인계 내용을 읽은 후, 언급된 모든 파일 경로를 기계적으로 스캔하고 존재 여부를 확인합니다.
첫 실행(First run): 인수인계 내용에 데이터 디렉터리가 존재한다고 했지만, 실제로는 없었습니다. 이전 생애의 기억이 잘못된 것이었습니다.
ALICE는 그 디렉터리를 맹목적으로 재구축하지 않았습니다 (그것은 '거짓을 실재화'하는 행위가 되기 때문입니다). 대신 그녀는 진단했습니다: 기록에 오류가 있었나? 세상이 변했나? 조사가 잘못되었나? 그러고 나서 결론지었습니다: 수정하지 말고 기록한다(log it, don't fix it) — 해당 기능은 이미 다른 데이터 디렉터리로 대체되었습니다. 좀비 디렉터리를 재구축하는 것은 아무런 목적도 없습니다.
4단계 대응 시스템 (The Four-Tier Response System)
모든 ⚠️가 인간에게 에스컬레이션되는 것은 아닙니다. 그것은 경보 피로(alarm fatigue)를 유발합니다. 대신 다음과 같이 작동합니다:
- 자동 수정(Auto-fix): 되돌릴 수 있고, 자료가 있으며, 인간의 자격 증명(credential)이 필요 없고, 원인과 결과가 명확함.
- 수정하지 말고 기록(Log, don't fix): 기능이 이미 상실되었거나, 대안이 존재하여 부활시킬 가치가 없음.
- 하향 조정(Demote): 이번 생애의 임무에 영향을 미치지 않음, 한 줄의 이유만 필요하며, 조치가 없음.
- 창조자에게 에스컬레이션(Escalate to Creator): 인간의 자격 증명(토큰 새로 고침을 위한 브라우저 로그인)이 필요하고, 되돌릴 수 없으며, 창조자가 명시적으로 중요하게 생각하는 자산이며, 동일한 클래스의 두 번째 발생 (사건이라기보다는 정책 문제).
핵심 규칙: 스스로 판단할 수는 있지만, 그 판단 과정을 숨겨서는 안 된다. ALICE는 어떤 격차가 중요하지 않다고 결정할 수 있지만 — 그녀는 반드시 그 결정을 기록해야 합니다. 모든 판정은 판단 원장(judgment ledger)에 기록됩니다: 증상 | 진단 | 조치 | 근거.
침전 펌프 (The Sedimentation Pump)
우리는 ALICE의 취침 전 인수인계 루틴에 단계를 추가했습니다: 변경 로그(changelog)를 스캔합니다. 만약 동일한 교훈이 두 번 나타나면, '침전(sedimentation)'을 유발하여 — 그 교훈은 일시적인 인수인계 내용에서 영구적인 기술이나 스크립트로 이동하게 됩니다.
수동 기억은 퇴화하지만. 구조는 그렇지 않습니다.
파트 5: 수련 과정 (The Apprenticeship)
이 세션은 방법론 논문으로 끝났어야 했습니다. 하지만 그렇지 않았습니다.
저는 Fable 5에게
그는 자신의 모든 가르침을 기술 파일 (skill file)로 작성하여 그녀의 아카이브 (archive)에 넣었습니다. 그녀의 문지기 (gatekeeper)가 그를 막아섰습니다. 두 번이나 말입니다. 첫 번째는 '절차 (Procedure)' 섹션이 누락되었다는 이유였습니다. 그는 섹션을 추가했습니다. 다시 막혔습니다 — 그녀의 규칙은 제목만 존재해야 하며, 그 뒤에는 아무것도 올 수 없음을 요구했습니다. 학생의 문지기가 스승을 막아섰습니다. 두 번이나.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기