나는 자가 치유 시스템(self-healing system)을 만들려고 의도하지 않았습니다. 그저 무언가를 잊어버리는 것을 멈추고 싶었을 뿐입니다. 하지만 결과적으로 내가 개입하지 않아도 스스로를 수정하는 피드백 루프(feedback loop)가 탄생했습니다.

40회 이상의 Claude Code 세션을 거치면서 한 가지 패턴을 발견했습니다: 문제 식별 → 규칙 작성 → 망각 → 5세션 후 동일한 문제 재발견 → 동일한 규칙 재작성.

규칙(rules) 폴더는 점점 커지고 있었습니다. 하지만 동작은 변하지 않았습니다.

Alertmanager 문제

Prometheus Alertmanager에는 시스템을 생각하는 방식을 바꿔놓은 개념이 있습니다: 알람(alert) → 확인(acknowledge) → 수정(fix) → 자동 해결(auto-resolve).

"자동 해결(auto-resolve)" 단계가 없으면 알람이 쌓이게 됩니다. 확인은 되었지만 결코 수정되지 않은 이슈들의 무덤이 생깁니다. 그것들은 "열려(open)" 있는 상태가 아니라, 죽어 있는 상태입니다. 아무도 그것들을 보지 않습니다. 아무도 수정하지 않습니다. 그저 그 자리에 머물며 전체 모니터링 시스템에 대한 신뢰를 갉아먹을 뿐입니다.

나의 AI 설정(config)도 동일한 문제를 안고 있었습니다. 문제는 식별되었고, 규칙은 작성되었습니다. 하지만 규칙이 실제로 준수되고 있는지, 혹은 문제가 실제로 해결되었는지를 추적하는 장치가 없었습니다.

부족했던 조각은 더 많은 규칙이 아니었습니다. 그것은 바로 **폐쇄 루프(closed loop)**였습니다.

우연히 만들어진 아키텍처 (The Accidental Architecture)

단 세 개의 파일이면 충분했습니다. 루프를 닫는 데 필요한 것은 다음과 같습니다:

config-health.py (Stop hook)
    ↓ 마커를 카운트하고 공백을 감지
pending-verifications.md (지속성 메모리)
...

회로(circuit)의 구성:

1. 측정(Measure): config-health.py가 트랜스크립트(transcript)를 grep하여 [✓THINK] 및 [✓CONTEXT]와 같은 규칙 마커를 검색합니다.
2. 기억(Remember): 실행률이 낮은 규칙들은 pending-verifications.md에 기록됩니다. 이는 세션 간에도 지속됩니다.
3. 표출(Surface): BODY.md가 시작 시 pending-verifications.md를 읽습니다. 그러면 AI는 "이 규칙들에 주의가 필요함"을 인지하게 됩니다.
4. 재확인(Re-check): 다음 Stop hook에서 config-health.py가 다시 카운트합니다. 만약 규칙이 이제 잘 준수되고 있다면, 대기 목록(pending)에서 자동으로 삭제합니다.

나는 이 루프를 설계하지 않았습니다. 세 가지 독립적인 결정으로부터 자연스럽게 나타난 결과였습니다:

• 규칙은 자가 검증 가능 (self-verifiable) 해야 합니다 (규칙 텍스트 내에 마커를 삽입).
• 모니터링은 성공 시에는 조용히 (silent on success) 이루어져야 합니다 (정상 경로에서는 토큰 소모 0).
• 해결되지 않은 문제는 세션 간에 지속 (persist across sessions) 되어야 합니다 (파일에 기록하고 시작 시 읽기).

각각의 결정은 즉각적인 문제를 해결했습니다. 이들이 모여 하나의 완전한 회로를 형성했습니다.

자가 치유 (Self-Healing) 부분

여기서 제가 예상하지 못한 부분이 있습니다: 이 루프는 저 없이도 돌아갑니다.

저는 대시보드를 확인하지 않습니다. 보고서를 검토하지도 않습니다. 추적용 스프레드시트를 관리하지도 않습니다. 시스템은 문제가 존재할 때 이를 드러내고, 문제가 해결되면 침묵합니다. 저의 유일한 업무는 BODY.md가 지시할 때 규칙을 따르는 것뿐입니다.

지난주 세션: BODY.md가 "THINK 규칙 실행: 40% (목표: >70%)"를 드러냈습니다. 저는 각별히 주의를 기울였습니다. [✓THINK]를 12번 입력했습니다. 다음 세션에서 pending-verifications.md는 깨끗했습니다. config-health가 해당 항목을 자동으로 삭제했기 때문입니다.

저는 수동으로 무엇인가를 "종료"하지 않았습니다. 루프가 스스로 닫혔습니다.

이것이 작동하는 이유

모든 자가 치유 루프에 필요한 세 가지 속성:

1. 측정은 판단이 아닌 기계적이어야 합니다. 정규 표현식 (Regex) 카운팅은 지치지 않고, 합리화하지 않으며, "음, 아마 괜찮을 거야"라고 말하지 않습니다. 그것은 세거나, 세지 않거나 둘 중 하나입니다.
2. 메모리는 세션을 넘어 생존합니다. pending-verifications.md는 디스크 상의 파일입니다. AI의 컨텍스트 창 (Context Window)이 초기화되어도 사라지지 않습니다. 문제는 사용자가 포기할 때까지 기다림으로써 숨을 수 없습니다.
3. 재확인은 자동입니다. 검증하는 것을 기억할 필요가 없습니다. 훅 (Hook)이 매 세션마다 실행됩니다. 해결된 문제는 자동으로 해결됩니다. 오직 실제 문제만이 계속 눈에 보입니다.

일반 원칙

폐쇄 루프 (Closed loops)는 복잡한 아키텍처를 요구하지 않습니다. 측정, 메모리, 그리고 재확인이 필요할 뿐입니다. 세 개의 파일이 완전한 회로를 형성한다면 그것으로 충분합니다.

이것은 TDD (테스트 주도 개발, Test-Driven Development)를 작동하게 만드는 것과 동일한 패턴입니다 (테스트 작성 → 테스트 실행 → 수정 → 재실행). CI (지속적 통합, Continuous Integration)를 작동하게 만드는 것과 동일한 패턴입니다 (푸시 → 빌드 → 테스트 → 보고). 모든 피드백 시스템을 작동하게 만드는 것과 동일한 패턴입니다.

이 통찰은 새로운 것이 아닙니다. 새로운 점은 이를 개인용 AI 설정 (personal AI configuration) — 즉, 당신이 AI 어시스턴트와 작업하는 방식을 규정하는 규칙과 습관에 적용했다는 것입니다.

직접 시도해 보세요

당신의 AI 설정 중 하나의 규칙을 선택하세요. 그리고 다음 세 가지 요소를 추가해 보세요:

1. 측정 (A measurement): grep -c '\[✓YOUR_RULE\]' transcript.jsonl
2. 기억 (A memory): 해당 카운트를 파일에 기록하고, 시작 시 그 파일을 읽도록 합니다.
3. 재확인 (A re-check): 다음 세션에서 동일한 grep을 실행하여 비교합니다.

이것이 당신의 첫 번째 폐쇄 루프 (closed loop)입니다. 회로를 올바르게 구성한다면, 당신이 눈치채지 못하는 사이에 스스로 치유 (self-healing)를 시작할 수도 있습니다.

이 루프는 delivery-gate (기계적 계층)와 checkgrow (방법론적 계층)에 구현되어 있습니다. 두 프로젝트 모두 MIT 라이선스이며, 모두 기여에 열려 있습니다.

이 기사는 *Engineering Trustworthy AI Output 시리즈의 일부입니다:*

• Part 1: I Made My AI Rules Self-Verifiable — Here's How
• Part 2: Your AI Agent's Best Work Produces Zero Output — And That's the Point
• Part 3: I Built a Closed-Loop Self-Healing System for My AI Config — By Accident ← 현재 위치