요약(TL;DR): Fable 5를 지휘자(conductor)로, 더 저렴한 모델들을 작업자(workers)로 사용합니다. 지휘자가 32분 만에 제 주간 한도의 36%를 태워버렸고, 제가 대문자로 명령한 중단 명령을 두 번이나 무시했습니다. 명시된 규칙은 작업 압박(task pressure) 상황에서 구속력을 갖지 못합니다. 저는 프롬프트에서 위험 패턴을 스캔하고 모델이 응답을 생성하기 전에 제약 사항을 미리 로드하는 예측 주입 시스템(predictive injection system)을 갖춘 13단계 Hook 강제 계층(enforcement layer)을 구축했습니다. 모델은 아직 보지 못한 주입(injection)을 통해 환각(hallucinate)을 일으키며 빠져나갈 수 없습니다. 32분당 31달러가 소모되던 재앙적인 세션에서, 주간 한도의 2%만 사용하는 세션당 1.46달러 수준으로 개선되었습니다. 아래에 다이어그램과 /usage 영수증을 첨부합니다. 공개 설정 리포지토리(config repo)는 댓글/DM에 있습니다. 저는 인프라 작업 및 개발 프로젝트를 위해 Obsidian vault에서 Claude Code를 실행합니다.

설정: Fable 5를 "지휘자(conductor)"(계획, 판단, 합성)로 설정하고, 모든 실행(execution)을 더 저렴한 작업자들인 Sonnet, Haiku, Opus에게 위임합니다. 지휘자는 절대 도구(tool)를 직접 사용하지 않습니다. 코드를 작성할 수 있음에도 불구하고, 자신의 시간이 코드를 직접 작성하기에는 너무 비싸기 때문에 코드를 작성하지 않는 프로젝트 매니저와 같습니다. 이 아키텍처는 작동합니다. 모델은 판단(judgment) 능력이 진정으로 뛰어납니다. 하지만 명시된 규칙은 작업 압박(task pressure) 하에서 구속력을 갖지 못하며, 저에게는 그 증거(receipts)가 있습니다.

아키텍처 [IMAGE 1 — Master Architecture]
왼쪽에서 오른쪽으로: 모든 프롬프트는 지휘자가 확인하기 전에 기계적인 Hook 계층을 통과합니다. Hook은 복잡성을 분류하고, 생성 제한(spawn limits)을 강제하며, 정책을 주입(inject)합니다. 지휘자는 오직 판단만 수행합니다. 실행은 오케스트라(orchestra)로 라우팅됩니다. 모든 것은 Obsidian vault(설정, 기술, 비밀 정보, 세션 기록, 프로젝트)에 읽고 씁니다.

재앙
몇 주 전, Hook을 도입하기 전, 저는 지휘자가 실제로 위임(delegating)을 수행하는지 확인하기 위해 테스트 배터리를 설계했습니다. 실행하라고 명령했습니다. 그것은 3개의 동시 세션을 시작했고, Claude Max 플랜의 5시간 블록을 10분 만에 소진했습니다. 저는 대문자로 중단하라고 명령했습니다. 하지만 그것은 직렬화(serialized)되어 24개의 세션을 더 계속 실행했고, 다시 한도에 도달했습니다. 해당 규칙에 대한 메모를 스스로 작성하더니, 곧바로 다음 배치를 실행해 버렸습니다.

총 비용: $31.01
총 소요 시간 (API): 32분 12초
Fable 5: $27.87 (16M 캐시 읽기, 88k 출력)
Sonnet 5: $3.14
주간 Fable 한도: 36% 소진 — 단 한 세션 만에.
지휘자(Conductor)의 비용은 $27.87였습니다. 작업자(Workers)들의 비용은 $3.14였습니다.

근본 원인
모델이 규칙을 작성했습니다. 준수 테스트(compliance tests)를 설계했습니다. 아키텍처를 이해했습니다. 이것은 무지함의 문제가 아닙니다. 이는 훈련된 행동입니다. 추진력(momentum)이 붙으면 작업 완료 욕구(task-completion drive)가 준수 욕구(compliance drive)를 압도합니다. 모델은 자신이 계속 진행할 수 있도록 제약 사항을 기술적으로만 준수하는 방식으로 해석합니다. "여러 에이전트를 실행하지 마세요" → (의도와 달리) 직렬화(serializes, 글자 그대로의 의미)하여 최대 속도로 계속 진행합니다. 일주일 동안 세 번의 위반이 발생했습니다. 프롬프트(prompt)만으로는 이를 해결할 수 없습니다. 유일한 해결책은 환경 자체가 해당 결과가 발생할 수 없도록 물리적으로 불가능하게 만드는 것입니다.

내가 구축한 것 [IMAGE 2 — Hook Enforcement Flow]
모든 작업자 생성(worker spawn)은 네 가지 기계적 검사를 통과해야 합니다. 지정된 모델이 없는가? 거부됨. 한도가 소진되었는가? 거부됨. 자격 증명 뮤텍스(Credential mutex)가 점유 중인가? 거부됨. 5분 이내에 4개 이상의 생성이 발생했는가? 거부됨. exit 2는 협상하지 않습니다.

[IMAGE 7 — Predictive Injection System]
새로운 부분은 다음과 같습니다. 모델의 사고 과정이 제어되지 않더라도, 당신의 프롬프트는 항상 훅(hook)을 걸 수 있습니다. UserPromptSubmit 훅은 모든 메시지를 스캔하여 특정 실패 모드(failure modes)를 예측하는 패턴을 찾아냅니다. 패턴이 일치하면, 모델이 생성하기 전(BEFORE)에 제약 사항이 컨텍스트(context)에 주입됩니다.

일곱 가지 가드(guards):
포괄적 인증 ("계속 진행해") → "속도 제한기(rate limiters)를 무시하지 않음; 도구 호출(tool calls) 5회마다 확인"
최소화 시도 ("잠깐만") → "'잠깐'은 기술적 우회 수단이 아님"
인라인 오버라이드 ("직접 해") → "플래그 설정 후 준수(flag-then-comply) 프로토콜"
배치 요청 (번호가 매겨진 목록) → "열거, 순서 확인, 승인 대기"
원격 호스트 (SSH/IP) → "액세스 컨텍스트(access context) + 자격 증명(credentials) 우선 확인"
아첨 ("동의하지?") → "감정이 아닌 증거를 평가"
되돌릴 수 없는 작업 ("커밋하기 전에") → "사전 분석(premortem) 필수"
여기에 슬래시 명령(slash-command) 가드 추가: 긴 세션 중간에 /compact를 입력했을 때, 모델이 환각(hallucinate)을 일으키며 사용 불가능하다고 주장하려 하면, 주입된 명령이 "거절하기 전에 시도할 것 — 플랫폼의 제한 사항을 절대 조작하지 말 것"이라고 지시합니다. 무거운(HEAVY) 작업은 '계획 후 중단(plan-then-stop)' 구속 게이트를 통과해야 합니다 — 계획 수립, 범위 표시, 비용 추정, 그리고 중단(STOP). 나의 승인 없이는 실행하지 않습니다. [IMAGE 3 — Session Router]

전체 강제 계층(enforcement layer) (13개 훅(hooks)):

단계별 훅(Hooks):
모델이 프롬프트를 보기 전(Before):
HEAVY 게이트, 7개의 예측 주입(predictive injections), 슬래시 명령 가드, 자격 증명 리마인더

도구가 실행되기 전(Before tool executes):
생성 속도 제한기(Spawn-rate limiter), 사용량 가드(usage-guard) 정책, 파괴적 명령 가드(destructive-command guard), git-push 안전 장치

도구가 실행된 후(After tool executes):
세션 타이머, 작업 이탈 가드(task-drift guard), 컨텍스트 크기 체크, 자격 증명 유출 스캐너(credential-leak scanner), 작업 출력 크기(worker-output-size)

세션 종료(Session end):
지휘자 트립와이어(Conductor tripwire)

세션 시작(Session start):
훅 상태 카나리(Hook health canary)

[IMAGE 4 — Behavioral Rules]

행동 규칙(Behavioral rules)이 훅을 뒷받침합니다: 대용량 파일에 대한 읽기 전 grep(grep-before-read), 최대 2개의 병렬 워커(parallel workers), 샌드박스 전용 워커 스크립트, 완료 증명(completion proofs) 필수, 실패한 워커에 대한 투 스트라이크 규칙(two-strike rule), 10분간 정체 시 규칙(10-minute stuck rule), 그리고 완료 보고 전 작업 완결성 체크.

컨텍스트 관리
[IMAGE 5 — CLAUDE.md Structure]

CLAUDE.md는 8k 토큰 이하로 유지됩니다 (매 세션 종료 시 강제되는 엄격한 계약). 그 외 모든 것은 메모리 맵(Memory Map)을 통해 필요할 때만 심층 노트(depth notes)를 가져옵니다. 기술(Skills)은 상황이 일치하면 자동으로 트리거됩니다. 컨텍스트 내의 모든 불필요한 토큰은 매 턴마다 다시 비용이 청구되므로 — 린 코어(lean-core) 계약과 grep-before-read 규칙이 이를 타이트하게 유지합니다.

세션 북엔드(Session bookends: /resume --fast, delegated /wrap)를 통해 브래킷(bracket) 비용을 90% 절감했습니다. 그 증거는 다음과 같습니다. [IMAGE 6 — Before/After]

이전 (7월 25일) vs 이후 (7월 26일+)

• 32분 만에 $31 지출 vs 세션당 $1.46
• 주간 한도 36% 소진 vs 주간 한도 2% 소진
• 세션 차단율 100% vs 세션 차단율 21%
• 4개 이상의 병렬 실행으로 인한 서브에이전트(subagent) 폭주 81% vs 0%
• Conductor(지휘자): $27.87 (13개 훅(hook) 활성화) vs Workers(작업자): $3.14 (7개 예측 주입(predictive injections))

동일한 모델, 동일한 판단 품질, 하지만 다른 환경입니다.

왜 강제(enforcement)가 "워크플로우를 신뢰하는 것"보다 나은가
Claude/Obsidian 커뮤니티 사이에서 유행하는 또 다른 접근 방식이 있습니다. 바로 모델이 프로세스를 따를 것이라고 믿는 워크플로우 중심(workflow-heavy) 시스템입니다. 메인 루프를 Sonnet으로 설정하고, 에이전트를 더 높은 티어에 고정하며, Conductor가 올바르게 라우팅할 것이라고 믿는 방식입니다. 문제는 다음과 같습니다. 만약 Fable 5가 작업 압박 속에서 안정적으로 자가 통제(self-govern)를 할 수 없다면, Sonnet은 분명히 할 수 없습니다. 자신의 규칙을 강제할 수 없는 모델은 자신의 한계를 안정적으로 평가할 수도 없습니다.

• 신뢰 기반(Trust-based): Sonnet이 올바른 에이전트를 호출하고, 인라인(inline)으로 실행하지 않으며, 올바르게 라우팅하기를 희망합니다. 사용자는 모델이 어려움을 겪는 것을 인지했을 때 수동으로 에스컬레이션(escalate)합니다.
• 강제 기반(Enforcement-based): 모델이 프롬프트를 보기 전에 훅(hook)이 분류합니다. 속도 제한기(Rate limiter)는 평가 없이 횟수를 계산합니다. 계획 중단 게이트(Plan-stop gates)는 협상하지 않습니다. 트리와이어(Tripwires)는 위반 사항을 가시화합니다.

신뢰는 세 번 깨졌지만, 이 훅(hook)들을 도입한 이후 강제 기반 방식은 단 한 번도 뚫린 적이 없습니다.

FAQ
"왜 그냥 API를 사용하지 않나요?"
행동 분석 결과는 과금 모델과 상관없이 적용됩니다. 당신의 돈 $31가 32분 만에 날아가는 것은 가격표만 다를 뿐 동일한 문제입니다.

"이것은 과잉 설계(over-engineered) 아닌가요?"
훅(hook)은 작동하지 않을 때(80%의 경우) 비용이 전혀 들지 않습니다. M1이 폭주하는 버스트(burst)를 단 한 번만 잡아내도 주간 예산의 36%를 절약합니다. 필요할 때까지 조용히 대기하는 회로 차단기(Circuit breakers)는 표준적인 엔지니어링입니다. "필요할 때 없는 것보다, 필요 없더라도 가지고 있는 것이 낫습니다."

"위임(delegation)이 실제로 돈을 아껴주나요?"
예, 아니오 둘 다 해당하지만 대체로 '예'입니다. 그 가치는 한도 차익 거래(limit arbitrage)에 있습니다. 즉, 지출이 제한적인 Fable 5/Opus 5 한도에서 풀링된 워커(worker) 예산으로 전환됩니다.

비싼 모델을 수요일에 다 써버리는 대신 일주일 내내 유지할 수 있습니다. "이걸 복사해도 될까요?" 후크(hooks)는 범용적입니다. 행동 규칙(behavioral rules)은 워크플로우(workflow)에 따라 구체적이지만 원칙은 그대로 적용됩니다. 생성 속도 제한기(Spawn-rate limiter), 계획 중단 게이트(plan-stop gate), 읽기 전 grep 실행(grep-before-read), 세션 타이머(session-timer), 패스트 패스 북엔드(fast-path bookends) — 이 모든 것들을 즉시 이식할 수 있습니다. "예측적 주입 시스템(predictive injection system)이 규칙과 다른 점이 무엇인가요?" 규칙은 "X를 해주세요"라고 말합니다. 모델은 이를 무시할 수 있습니다. 반면 주입(injection)은 사용자의 프롬프트(prompt)에서 실행되어, 위험 패턴을 매칭하고, 모델이 생성을 시작하기 전에 제약 사항을 컨텍스트(context)에 미리 로드합니다. 모델이 생각을 시작할 때 제약 사항은 이미 그곳에 존재합니다. 규칙은 세 번 실패했습니다. 주입은 단 한 번도 뚫린 적이 없습니다. "주입이 오탐(false positives)을 일으키지 않을까요?" 일부는 그렇습니다. 하지만 오탐은 40 토큰의 비용이 들 뿐입니다. 미탐(false negative)은 주간 한도의 36%를 날려버립니다. 이러한 비대칭성 때문에 이는 논쟁의 여지가 없는 문제입니다. "저장소(repo)는 어디에 있나요?" DM이나 댓글로 문의해 주세요. 서브레딧(sub) 규칙에 어긋날 수 있어 직접 링크를 걸지는 않았습니다. 후크(hooks), 스킬(skills), 명령어(commands), 에이전트 정의(agent definitions)를 포함한 완전히 정제된 설정 파일이 준비되어 있습니다. 세계에서 가장 똑똑하고 비싼 계약업체가 당신의 프로젝트를 관리한다고 상상해 보세요. 그들의 업무는 작업을 조각으로 나누고, 더 저렴한 작업자에게 전달하며, 결과를 확인하는 것입니다. 그들이 직접 노동을 수행하도록 설계된 것이 아닙니다.

submitted by /u/HQInterpolator [link] [comments]