Fable 5 계획, Opus 4.8 빌드, GPT 5.6 Sol의 방해 공작. 지금까지 최고의 설정!
Fable 5 plans, Opus 4.8 builds, GPT 5.6 Sol tries to break it. Best setup so far!
핵심 요약
Fable, Opus, Sol 모델을 각각 기획, 구현, 검수 역할로 분담해 자동화 효율을 극대화한 설정 공유.
- 역할 분담 — Fable은 기획, Opus는 구현, Sol은 검수 및 QA 담당
- 상호 보완 — 각 모델의 강점을 살려 코드 품질과 버그 탐지율 향상
- 자동화 도구 — jinn 데몬을 통해 모델 간 메시지 라우팅 및 세션 관리
- 워크플로우 — 모델 간 상호 검증을 통해 수동 개입 최소화
지금까지 실행해본 것 중 요구사항을 실제로 완벽하게 수행하는 가장 OP(압도적인) 루프임.
**Fable 5 (High)**를 오케스트레이터로 쓰면 긴 실행 과정 전반을 기억하고 실제 감각이 있음. 계획을 세우고, 위임하고, 작업이 돌아오면 전체 diff를 읽음. 제품과 UI 판단이 필요할 때 유일하게 믿는 모델임. 창의적인 해결책이 필요할 때 Fable이 답을 내놓음. Fable은 진짜임! (물론 너프 안 당했을 때 얘기지만)
**Opus 4.8 (Medium / High)**을 구현자로 쓰면 Fable과 아주 잘 맞음. 구체적인 지시를 잘 따르고 거의 모든 작업에 충분히 똑똑함 + 프론트엔드 작업에서 GPT보다 감각이 좋음.
**GPT 5.6 Sol (High / xHigh)**을 리뷰어 및 QA로 사용함. 브라우저, 특히 agent-browser를 사용하는 데 엄청나게 능숙함. 몇 시간이고 계속 작업하고 클릭하며, 스크린샷을 찍고, 재현된 버그 영상을 기록함. 코드 리뷰는 철저하고 많은 치명적인 버그를 찾아냄. 한 가지 주의할 점은 이 모델이 너무 많은 엣지 케이스를 찾아내는 경향이 있다는 거임. 그래서 오케스트레이터에게 명시적인 위험 임계값과 중단 조건을 제공하라고 지시를 내렸음. 안 그러면 꼼꼼함이 무한 루프가 되어버리거든..
이 분할 방식을 작동하게 만든 세 가지 규칙:
- 아무도 자신의 작업에 스스로 서명하지 않음. Opus가 구현하고, Sol이 리뷰하고, 의견이 갈리면 Fable이 중재함.
기반이 되는 연결 구조는 내가 만든 jinn(https://github.com/hristo2612/jinn)이라는 작은 오픈 소스 데몬임. 각 에이전트는 페르소나와 모델이 담긴 YAML 파일이고, 데몬은 실제 Claude Code와 Codex CLI 세션을 생성해서 그 사이로 메시지를 라우팅함. 커스텀 에이전트 루프가 없어서 Max 구독으로도 돌아가는 거임. Claude 쪽은 퍼스트 파티 CLI니까. tmux와 인내심만 있다면 이 분할 방식을 재현할 수는 있을 거임.
거의 손댈 필요 없이 아이디어에서 완성된 기능까지 갈 수 있는 첫 번째 설정임.
