잠깐, 'Fable 오케스트레이션' - 적절한 모델을 하위 에이전트로 쓰는 게 프롬프트 하나 쓰는 것만큼 쉬운 건가요?
Wait, is "Fable orchestration" - using appropriate models as sub-agents just as easy as a prompt?
핵심 요약
복잡한 에이전트 설정 대신 프롬프트로 오케스트레이션을 제어하는 효율적인 방법을 공유하고 논의합니다.
- 오케스트레이션 전략 — 복잡한 설정 대신 프롬프트로 하위 에이전트 모델을 지정함
- Claude.md 활용 — 에이전트 위임 규칙을 정의하여 토큰 사용량과 컨텍스트를 최적화함
- 모델 매칭 — 작업 난이도에 따라 Haiku, Sonnet 등 적절한 모델을 배정함
- 실패 대응 — 하위 모델이 해결하지 못할 경우 상위 모델로 에스컬레이션하는 규칙을 적용함
나 나름대로 수동 워크플로우로 꽤 쏠쏠하게 재미 보고 있었는데, 요즘 들어 토큰 사용량 최적화에 좀 꽂혔거든. ㅋㅋ
근데 도저히 해결이 안 되던 게 하나 있었음. Fable을 오케스트레이터로 쓰면서, 하위 에이전트(sub-agents)를 띄울 때 모델을 제대로 지정하는 거였거든. 커스텀 에이전트나 스킬 래퍼에 프론트매터(frontmatter)도 써보고 별짓 다 해봤는데, 어떤 하위 에이전트나 스킬은 모델 지정한 걸 그냥 씹어버리는 것 같더라고. 특히 plan mode가 문제임. 이 새끼는 진짜 간단한 작업인데도 Fable 리서치 하위 에이전트를 띄워서 한 번 물어볼 때마다 Fable 토큰을 5%에서 10%씩 처먹음.
오늘 갑자기 몇 달 전(AI 업계 기준으론 7년 전쯤?) 여기나 HN에서 봤던 댓글이 생각나는 거야. "~<feature request> - 넌 오케스트레이터니까, 하위 에이전트를 써서 네 컨텍스트 윈도우를 아껴라." 그래서 이걸 아래 내용이랑 합쳐봤더니, CC(fable)가 바로 "ㅇㅋ! 작업에 맞는 모델이랑 하위 에이전트 표 보여주고 싹 다 띄워줄게" 이러는 거 있지.
Let's implement (jira or .md feature spec) This is the orchestration session, and use sub-agents to preserve your own context window (you are fable, spawn opus sub-agents when appropriate to save cost) ...
나도 아주 멍청이는 아닌데, 너무 복잡하게 생각했던 건가? 보리스 말마따나 그냥 모델을 믿어야 하는 건가?
아니면 내가 뭘 완전히 놓치고 있는 건가?
수정: 확실히 말해두자면, 나도 프롬프트 말고 토큰 아끼는 꽤 괜찮은 설정들 쓰고 있음. 그냥 plan mode가 내 통제를 벗어나 있었던 것뿐임.
