저는 Claude Code에서 Fable 5를 가지고 이것저것 시도해 보고 있는데, 솔직히 제가 깨달은 가장 큰 사실은 이것입니다:

단순히 무작위 프로젝트 하나를 더 출시하려고 전체 윈도우(window)를 태워버리는 일을 멈추세요.
대신, 나중에 Opus, Sonnet 또는 다음에 사용 가능한 모델로 돌아갔을 때 당신을 계속 지탱해 줄 실제 시스템을 개선하기 위해, 이 강력한 도구(beast)를 아직 사용할 수 있을 때 활용하세요.

Fable은 긴 세션(long sessions), 핸드오프(handoffs), 위임(delegation), 정리(cleanup), 그리고 워크플로우의 미세한 균열을 찾아내는 데 탁월합니다. 이는 단순히 일회성 결과물을 뽑아내는 대신, 당신의 "Claude Code OS"를 업그레이드하는 데 완벽한 도구임을 의미합니다.

Fable이 사라지기 전에 제가 개인적으로 집중하고 있는 사항들은 다음과 같습니다:

1. 냉혹한 외부인처럼 현재 설정을 감사(Audit)하세요
   무엇이 있었으면 좋겠는지 묻지 말고, 현실을 직시하라고 요청하세요.
   다음과 같은 방식입니다:

[IMG:1]

결정적인 후속 질문은 이것입니다: "내일 이 규칙을 강제하는 파일은 무엇인가?"
만약 대답이 "없다"라면, 그것은 현재 채팅창 안에만 존재하는 막연한 바람일 뿐입니다.

2. 진정한 최고 운영자(Chief Operator)를 구축하세요 (단순히 화려한 프롬프트가 아닌)
   실제로 상황을 주도하는 적절한 메인 세션 운영자를 만드세요. 이 운영자는 큰 그림을 이해하고, 작업을 마이크로태스크(microtasks)로 나누며, 깔끔하게 위임하고, 도구(tools)를 조기에 사용하며, 결정을 내리고, 필요할 때 시스템을 패치하고, 견고한 핸드오프(handoffs)를 작성할 수 있어야 합니다.

저는 다음과 같은 방식으로 실행합니다:
claude --model claude-opus-4-8 --agent chief-operator

핵심 프롬프트는 짧게 유지하세요. 명시적인 모델 라우팅(model routing)과 메모리 규칙을 부여하세요. 지침들이 비대하게 쌓인 박물관으로 만들지 마세요.

3. 세상의 모든 기술을 미리 로드(preloading)하는 것을 멈추세요
   저도 예전에는 그렇게 했지만, 이는 그저 노이즈만 생성할 뿐입니다. 이제 저는 최고 운영자(chief)에게 필수적인 것들(예: artifact-first-delivery 및 self-verification-loop)만 미리 로드합니다. 그 외의 모든 것은 라우터 기술(router skill)을 통해 필요할 때 로드됩니다.

컨텍스트(context)가 사용되지 않는 쓰레기 데이터로 가득 차지 않을 때, 나중에 스스로에게 고마워하게 될 것입니다.

4. 작고 긴밀한 에이전트 팀을 구축하세요
   30개의 에이전트가 필요하지 않습니다. 저는 다음과 같이 시작할 것입니다:

[IMG:2]

• chief-operator: 의사 결정자 및 오케스트레이터(orchestrator)
• system-fixer: 에이전트, 기술(skills), 훅(hooks) 등에 대한 빠른 수리

builder – 실제 구현 작업을 수행
qa-engineer – 증거를 바탕으로 검증 (PASS/FAIL)
adversarial-critic – 가짜 진행 상황, 불필요한 비대화(bloat), 취약한 인수인계(handoffs)를 지적
eval-designer + improvement-analyst – 반복되는 문제를 수정 사항으로 전환
context-librarian + research-scout – 상태를 정상적으로 유지하고 최신 정보를 유지

모든 하위 에이전트(subagent)는 엄격한 계약(임무, 범위, 입력, 출력 제한, 필수 증거 등)을 가집니다. 계약이 없다면, 그저 값비싼 안개(expensive fog)를 마주할 뿐입니다.

5. 더 많은 지침 대신 훅(hooks)을 추가하세요
   훅(Hooks)은 이 과정이 실제 시스템처럼 느껴지기 시작하는 지점입니다. 가치 있는 몇 가지 예시는 다음과 같습니다:

세션 모델 감사 (Session model audit)
도구 실행 전 리스크 가드 (Pre-tool risk guard)
도구 실행 후 증거 로거 (Post-tool evidence logger)
전달 게이트 (Delivery gate) (증거 없는 가짜 "완료" 방지)
압축 전 인수인계 작성기 (Pre-compact handoff writer)
예산 관리자 (Budget governor)

이것이 바로 Fable의 핵심 영역입니다.

6. 반복되는 실패를 평가(evals)로 전환하세요
   짜증 나는 일이 계속 발생할 때마다, 그것을 위한 평가(eval)를 만드세요. 메모 노트를 통해 해결되기를 바라는 것보다 훨씬 효과적입니다.

7. 메모는 짧고 운영 중심적으로 유지하세요
   날짜, 실패, 근본 원인(root cause), 시스템 패치, 평가(eval), 다음 단계. 그게 전부입니다. 감정적인 일기 쓰기는 하지 마세요.

8. 개선 엔진으로서 Fable을 전략적으로 사용하세요
   제가 발견한 가장 좋은 패턴은 다음과 같습니다:

시스템 감사, 근본 원인 분석, 아키텍처, 적대적 검토(adversarial review), 그리고 대규모 개선 루프에는 Fable을 사용하세요.
규율 있는 수석(chief) 역할을 수행하는 데는 Opus를 사용하세요.
더 작고 경계가 정해진 작업자(worker) 업무에는 Sonnet/Haiku를 사용하세요.

보호할 가치가 있는 루프는 다음과 같습니다:
큰 목표 → 의도 파악 → 마이크로 태스크로 분할 → 배정(dispatch) → 도구(tools) → 요약(digests) → 결정 → 패치 → 검증 → 인수인계(handoff) → 계속

행운을 빕니다!
submitted by /u/Brilliant_Spot7783
[link] [comments]