5단계 만에 오푸스를 우아한 Fable처럼! AI 활용 끝판왕 비법 대공개
Fable 5, 똑똑한 AI 모델보다 더 중요한 건?
요즘 Fable 5라는 엄청난 AI 모델을 써봤는데, 이걸 가지고 이것저것 만져보면서 돈을 좀 썼지. 왜냐하면 이 모델이 어떻게 작동하는지, 그리고 우리가 이 강력한 모델을 어떻게 하면 제대로 쓸 수 있을지 알고 싶었거든.
가장 중요한 걸 깨달은 게 뭐냐면, Fable 5가 정말 대단한 모델인 건 맞는데, 모델 자체가 전부가 아니라는 거야.
이걸 이렇게 생각해 봐. AI를 처음 배우는 사람과 안드레 카파시 같은 전문가가 있다고 치자. 초보자한테 Fable 5를 주고, 전문가한테는 Sonnet 3.7을 줘도, 전문가가 훨씬 더 좋은 걸 만들어낼 거야. 초보자가 가진 모델이 훨씬 좋아도 말이지. 왜냐하면 모델한테 어떻게 명령하느냐, 그리고 모델 주변에 어떤 시스템과 반복적인 과정을 만드느냐가 훨씬 더 중요하기 때문이야.
또 다른 예시를 들어볼게. Fable 5도 많이 써봤고, Opus랑 Sonnet도 엄청 써봤어. 요즘 내가 제일 좋아하는 건 Claude Code에서 제공하는 '동적 워크플로우'라는 건데, 이걸로 Fable한테 "워크플로우를 디자인해 봐. 그리고 네 부하 에이전트들도 전부 Fable로 해봐."라고 시켰어. 그리고 똑같은 테스트를 Fable이 Opus 에이전트들을 조종하게 하거나, Sonnet 에이전트들을 조종하게 해서도 해봤지.
결과는 어땠냐면, 결과물은 거의 똑같았어. 그런데 Fable로만 했을 때 비용은 훨씬 더 많이 나왔지.
그러니까 내가 하고 싶은 말은 이거야. 모델의 똑똑함은 복제할 수 없지만, 모델이 일하는 방식은 복제할 수 있다는 거지.
그래서 오늘은 Opus 같은 모델을 Fable처럼 만들 수 있는 방법을 이야기해 볼 거야.
모델을 '선생님'처럼 대하라
가장 먼저 해야 할 건 모델을 '일꾼'이 아니라 '선생님'처럼 생각하는 거야. Fable 5를 처음 접했을 때, 우리는 아마 이걸 한계까지 밀어붙였을 거야. Anthropic에서도 Fable이 긴 작업을 잘하고, 목표를 세우고, 실행하고, 검증하는 데 뛰어나다고 했지. 실제로 그래.
그런데 '모델 라우팅'이라는 건 결국 균형을 찾는 거야. 이 작업은 이 정도의 똑똑함이면 충분한데, 왜 훨씬 비싸고 똑똑한 모델을 써야 하냐는 거지. 훨씬 작고 저렴한 모델로도 똑같은 품질을 낼 수 있는데 말이야. 이게 앞으로 AI 시대에 아주 중요한 기술이 될 거야.
그러니까 Fable이 모든 걸 계획하고 실행하게 하는 대신, Fable이 생각하는 방식을 뽑아내서, 다른 더 작은 모델들이 그렇게 생각하고 실행하게 만드는 거지.
나는 Fable이 내 설정을 검토하고 개선해주거나, 내 기술을 향상시켜주는 걸 보면서 깨달았어. 내가 Fable을 그냥 직원처럼 대하는 게 아니라, 마치 회사 공동 창업자나 임원처럼 대하고 있었다는 걸. 마치 시니어 엔지니어가 자기가 아는 모든 걸 정리해서 새로 들어올 주니어 엔지니어들에게 넘겨주는 것처럼 말이야.
Fable 5 시스템 프롬프트에서 배운 것들
최근에 Fable 5의 시스템 프롬프트가 유출됐는데, 이걸 읽어보고 Fable 5한테도 읽어보게 했어. 거기서 몇 가지 중요한 걸 발견했지.
- 훈련 때 일부 기억한다고 해서 지금도 아는 건 아니야. 그냥 기억에 있다고 해서 그걸 믿지 말고, 확인해야 한다는 거지.
- 파일이 있다고 가정하는 프롬프트가 있다고 해서 실제로 파일이 있는 건 아니야. 그러니까 실제로 존재하는지 확인해야 해.
- 모든 단계에서 자신이 하는 일과 이미 한 일이 정확한지 확인해야 해.
- 애매한 질문에도 바로 답하고, 그 다음에 질문해. (답 먼저, 질문 나중에. 질문은 한 번만.)
- 잘못된 점을 인정하고, 문제에 집중하고, 자존감을 유지해.
- 간단한 사실 확인은 1번, 중간 정도의 작업은 3~5번, 깊이 있는 연구나 비교는 5~10번 정도의 노력을 들이라고 하네. 이건 얼마나 노력할지를 이야기하는 거야.
그래서 우리는 어떤 작업에 어떤 모델이 적합한지뿐만 아니라, 어떤 수준의 노력이 적합한지도 고민해야 해.
노력 수준에 따른 모델 성능 비교
Fable 5와 Mythos 5 출시 블로그에 이런 예시가 있었어. Fable 5와 Opus 4.8, 그리고 GPT 5.5를 비교한 건데, Y축은 점수, X축은 비용이야. 각 모델별로 다른 노력 수준을 볼 수 있지.
만약 Fable 5나 Opus를 그냥 기본 설정으로 쓰고 있다면, 설정을 바꿔보는 게 좋아. 이게 좀 흥미로워지거든. 예를 들어, Fable 5를 '낮음'으로 설정한 게 Opus 4.8을 '높음'으로 설정한 것과 비슷해. Fable 5가 좀 더 비싸고 품질이 약간 더 좋긴 하지만 말이야.
그런데 항상 높은 노력이 더 좋은 건 아니야. Fable을 '높음'으로 설정하면 너무 오래 걸리고 비싸지고, 너무 많이 생각하고 스스로를 의심해서 오히려 Opus 4.8을 '높음'으로 설정한 것보다 못한 결과가 나올 때도 많았어.
Fable의 사고방식을 Opus에 적용하기
시스템 프롬프트를 읽고 모델들을 오래 만져본 후에, 여러분이 꼭 해봤으면 하는 두 가지가 있어.
- Fable을 다루던 방식, 즉 Fable의 '강력함'이나 사용 방식을 Opus나 Sonnet이 할 수 있도록 바꿔봐. 즉, Fable의 방식을 추출하는 거야.
- Fable한테서 정말 마음에 드는 결과물을 받았는데, 왜 좋았는지 정확히 설명하기 어려웠다면, Fable이나 Opus한테 그걸 분석해달라고 해봐. 만약 대화 기록이 있다면 더 좋아. "어떻게 이런 생각을 했니?", "어떻게 여기까지 왔니?", "이게 맞다는 걸 어떻게 증명했니?", "어떻게 그렇게 좋은 결과물을 얻었니?" 같은 질문을 해보는 거지. 그리고 그 정보를 추출해서 '기술(skill)'로 만들어봐.
나는 이제 'Fable 모드'라는 기술을 가지고 있어. Opus한테 Fable 모드를 쓰게 하고 싶거나, 어려운 문제가 있을 때 Opus 4.8에 Fable 모드를 적용하면 정말 좋아. 마치 Fable의 프롬프트가 주입된 것처럼 모델이 한 단계 업그레이드된 느낌이지. 이 기술은 '범위 설정', '증거', '공격', '검증', '보고'라는 다섯 가지 단계를 거쳐. 이건 마치 목표 설정 프롬프트나 동적 워크플로우처럼 반복적인 과정을 만드는 건데, 이걸 기술 파일로 만드는 거야.
특히 '범위 설정' (또는 계획)은 정말 중요해. 그냥 "이 단계들을 계획하고 실행해"라고 하는 것과, "무슨 일이 일어날 수 있을까? 모든 가능성을 탐색해 보자."라고 악마의 변호인처럼 생각하는 건 큰 차이가 있어. Fable은 이걸 정말 잘해. 그래서 Fable이 동적 워크플로우를 설계하고, 모든 가능한 단계를 계획하고, 잘못될 수 있는 모든 것을 고려한 다음에, Sonnet이 실행하고 Fable에게 보고하도록 하면, Fable은 계속해서 다음 단계를 설계할 수 있지.
이게 바로 Fable과 Sonnet으로 동적 워크플로우를 만들었을 때, Fable과 Fable로 만들었을 때 결과가 비슷한 이유야. 나에게는 이게 정말 큰 깨달음이었지. 왜 이게 똑같이 좋으면서 훨씬 저렴할까?
이렇게 시작해 볼 수 있어. "Opus 4.8이 너의 판단, 계획, 검증, 추론 습관대로 작동하도록 하는 완전한 설치 가능한 기술 파일을 작성하고, Fable 모드 같은 걸로 활성화해 줘."
나는 이 'Fable 모드' 기술 파일을 무료 커뮤니티에 공유할 거야. 링크는 설명란에 있으니 가입해서 '교실'에 들어가면 내가 유튜브에 올린 모든 무료 자료를 볼 수 있어. 직접 만들 수도 있고 말이지. 이 기술은 Fable의 작업 방식을 따르기 때문에 어떤 모델이든 실행할 수 있어. GPT 5.5나 오픈소스 모델도 말이야.
이 기술은 다섯 가지 단계를 거쳐. 작업 전 범위 설정, 추론 전 증거 확인, 반대 의견 고려, 완료 선언 전 검증, 그리고 보정. Opus 4.8에 이걸 적용하면 Opus가 한 단계 업그레이드된 것처럼 느껴질 거야.
모델 라우팅: 똑똑하게 비용 절감하기
이것과 잘 연결되는 게 바로 '모델 라우팅'이야. Fable이나 다른 똑똑한 모델이 필요할 때 작은 모델로 연결해주는 거지. 나는 Claude한테 다양한 모델들을 보여주고 언제 어떤 모델을 써야 하는지 알려주는 표를 주고 있어. Codex나 오픈소스 모델로 연결할 수도 있지.
기업들이 '단위 경제'를 생각하고, 소규모 팀이나 개인의 AI 예산을 고려할 때 이게 정말 중요해질 거야. 이걸 잘하면 훨씬 적은 비용으로 훨씬 많은 것을 얻을 수 있을 거야.
모델을 나누는 좋은 방법은 다음과 같아. 도구함에 있는 다양한 모델들, 각 모델의 비용 (숫자가 높을수록 저렴), 그리고 지능과 취향이야. 필요하다면 워크플로우에 기반한 다른 기준을 추가해도 좋아.
- 지능: 얼마나 똑똑한지, 얼마나 당신을 잘 이해하는지, 코드 검토는 얼마나 잘하는지 등.
- 취향: 창의성, 틀을 깨는 생각, UI/UX 디자인 등.
이런 표는 에이전트 팀을 설계하거나 하위 에이전트에게 작업을 맡길 때, 동적 워크플로우를 만들 때 도움이 돼. 때로는 동적 워크플로우에서 Sonnet, Haiku, Opus 등 다양한 모델을 활용할 수 있거든.
실제로 내가 테스트했던 예시를 보여줄게. Opus를 오케스트레이터로 사용하고, 앞에서 말했던 'Fable 모드' 프롬프트를 사용했어. 그리고 다양한 Sonnet, Opus, Haiku 작업자들을 사용했지.
Opus 오케스트레이터가 모든 Haiku 작업자들에게 일을 맡겼을 때, 비용이 약 3배나 저렴했는데 결과는 똑같았어. Fable 예시와 마찬가지로, 이건 정말 중요하게 생각해야 할 부분이야.
결론: 우리가 소유할 수 있는 것
이번 내용은 좀 빠르게 진행했지만, Fable이 사라질까 봐 걱정하는 댓글이나 커뮤니티 글을 많이 봤어. Fable은 구독제로 다시 돌아올 거라고 하니 너무 걱정하지 않아도 돼.
하지만 이런 상황을 보면서 깨달은 건, 우리는 아무것도 소유하고 있지 않다는 거야. 이 모델들을 소유하는 게 아니야.
우리가 소유할 수 있는 건 우리의 과정, 우리의 시스템, 우리의 방법론, 그리고 모델을 사용하는 방식이야. 그리고 하드웨어와 로컬 모델도 소유할 수 있지.
나는 앞으로 이런 부분에 대해 더 깊이 파고들 생각이야. 여러분이 보고 싶은 주제가 있다면 알려줘!
혹시 새로운 걸 배웠거나 영상이 좋았다면 '좋아요'를 눌러줘. 큰 도움이 돼. 그리고 언제나처럼, 끝까지 봐줘서 고마워! 다음 영상에서 보자!