안녕하세요! 드디어 어제, Claude Fable 5 (Mythos 클래스 최초의 일반 공개 모델)가 출시되었네요!

저도 어제부터 그 높은 성능에 설레며 이것저것 테스트하고 있습니다.

한편으로는, 토큰 소비가 Opus 4.8의 2배로 격렬하거나, 6/23부터는 Claude Pro/Max 구독 범위 내에서는 사용할 수 없게 되어 usage credits를 통한 종량제 과금이 필요하다는 안내가 나오는 등, 이 지능을 어떤 일에 어떻게 사용할지 고민하는 분들도 많지 않을까요?

시중에서는,

• "이 참에 리팩터링 (Refactoring)을 한꺼번에 시켜버리자! 리팩터링 로드맵을 Fable에게 짜게 하면 좋을 것 같아!"
• "Fable은 리뷰 역할을 맡고, 코드를 작성하는 것은 더 작은 모델에게 시키는 것이 좋지 않을까?"
• "Fable은 지시 역할을 하고, (이하 생략)"

같은 의견들을 몇 가지 보았습니다. 이것이 잘 작동한다면, Fable을 절약하면서도 능숙하게 사용할 수 있을 것 같습니다.

그래서 Fable 5 + Cursor Composer 2.5 Fast를 사용하여 검증해 보았습니다.

먼저 결론

이번 주제(제로 베이스에서 브라우저 게임 1개를 만들기)에서는, Fable에게 직접 쓰게 하는 것이 더 좋은 결과였습니다. 그 이유도 고찰해 보았으니 관심 있는 분들은 계속 읽어주세요!

검증 내용

"브라우저에서 동작하는 슈퍼 마리오 브라더스 스타일의 게임을 만든다"라는 주제를, 완전히 동일한 프롬프트로 두 가지 체제에 던졌습니다.

• 체제 A: Fable 5가 직접 구현한다 -
• 체제 B: Fable 5는 지시 역할(태스크 분해·지시서 작성·리뷰·통합)에 집중하고, 구현은 headless 상태의 Cursor CLI로 구동하는 Composer 2.5 Fast(Cursor의 고속·저가형 모델)에게 병렬로 시킨다

브라우저에서 동작하는 super mario brothers를 작성해 주세요. 가능한 한 원작을 재현해 주세요. 조작 방법은 space로 점프, 좌우 화살표 키로 이동입니다.

공통 전제

• 빈 디렉토리에 git init만 한 상태에서 시작
• Claude Code (v2.1.170)
• Fable 5 (medium effort)
• 동일한 시각에 기동하여 병행 수행
• 체제 A는 프롬프트를 그대로, 체제 B는 동일한 문구에 /cursor-impl (후술할 자작 skill)을 붙여 투입

cursor-impl 자작 skill

체제 B를 임기응변식으로 하면 검증이 되지 않으므로, 절차를 skill로서 고정했습니다.

📦 skill은 이곳에서 공개하고 있습니다. npx skills add Nasubikun/skills --skill cursor-impl로 설치할 수 있습니다.

워크플로우는 6단계입니다.

• Preflight: working tree 확인
• 태스크 분해: 담당 파일이 겹치지 않도록 분할. 공유 부분은 Fable이 직접 작성
• 지시서 (brief) 작성: 태스크마다 brief.md를 작성
• 병렬 디스패치: headless의 cursor (agent) CLI (composer-2.5-fast)를 백그라운드에서 병렬 실행
• 리뷰: Fable이 변경된 파일을 읽고, 문제가 있으면 feedback.md를 작성하여 반려 (최대 3 라운드)
• 통합: 전체 검증을 돌려 리포트 생성

위임해도 좋은 것은 "출력량은 많지만 판단은 적은" 업무뿐이며, 설계 판단이 필요한 변경은 Fable이 직접 작성한다는 규칙도 포함되어 있습니다.

어떻게 움직였나

체제 A는 단일 index.html (1,142행)을 거의 한 번에 써 내려갔고, 구문 체크를 하고 브라우저에서 열고 종료되었습니다.

체제 B는 다음과 같이 진행되었습니다.

• Fable이 먼저 공통 코드 (index.html, package.json...

)를 직접 작성 - 「게임 본체」와 「오디오」 2가지 태스크로 분해하고, 각각 100행이 넘는 brief.md를 작성하여 Composer를 2개 병렬로 기동

• Composer는 빠르게 게임 본체(약 2,900행)를 약 200초 만에 출력 - 오디오는 1회 승인(approve). 반면 게임 본체는 Fable의 리뷰에서 9건의 지적을 받아 반려(그중 실행 불가능한 버그가 5건, 추가로 단색 사각형이었던 스프라이트를 전면 재작성하는 등) - 수정 라운드 1회로 수렴. 경미한 수정은 Fable이 스스로 대응하고, 마지막에 headless 브라우저로 게임을 조작하여 검증한 뒤 PASS를 보고

결과

먼저, 이 검증의 주제인 「Fable을 절약할 수 있었는가?」부터 살펴보겠습니다.

절약할 예정이었던 Fable이 직접 구현했을 때보다 약 3배 더 많은 토큰을 소비했습니다. 태스크 분해, brief 작성, 전체 파일 읽기 리뷰는 모두 컨텍스트(Context)를 잡아먹는 작업이기에, 「Fable은 맛있는 부분만 골라 먹기」는 불가능했습니다.

그리고 가장 중요한 결과물도 Fable에게 직접 쓰게 한 체제 A가 압도적으로 훌륭했습니다.

실제로 플레이 가능합니다!:

• 체제 A (Fable 직접 구현): https://mario.jomatsu.dev/
• 체제 B (Fable 지시 + Composer 구현): https://mario.jomatsu.dev/composer/

왼쪽: 체제 A (Fable 직접 구현), 오른쪽: 체제 B (Fable 지시 + Composer 구현)

스크린샷을 보시면 알 수 있듯이, 우선 외관상의 차이가 극명하며 체제 B의 구현은 충돌 판정이 미심쩍어 플레이하기 불쾌합니다. 또한 1-1 맵의 재현도도 낮습니다.

고찰

왜 체제 B는 패배했는가

이하 내용은 필자의 고찰입니다.

① brief 단계에서 정보가 누락된다.

체제 A의 결과를 보면, Fable은 「마리오다움」을 상당히 높은 해상도로 가지고 있습니다. 하지만 brief에 쓸 수 있는 것은 그중 언어화할 수 있는 부분뿐입니다. 점프의 중력 적용 방식이나 적을 밟았을 때의 튕겨 나가는 감각 같은 것은 100행의 brief를 써도 누락됩니다. 직접 구현한다면 이러한 손실이 애초에 발생하지 않습니다.

② 리뷰는 「고장 나지 않은 상태」까지만 보장할 수 있다.

언어화된 9건의 지적은 수정 1라운드 만에 제대로 고쳐졌습니다. 하지만 초안 출력의 품질이 낮으면, 리뷰는 고장 난 부분을 없애는 데 급급하여 「좋은 상태」까지 끌어올릴 여유가 없습니다.

③ 손맛(Feel)을 피드백으로 고치는 것은 가성비가 맞지 않는다.

설령 「점프가 너무 가볍다」라고 지적할 수 있다 하더라도, 수정이 오갈 때마다 ①의 정보 손실이 누적됩니다. 이 체제는 정답(Correctness)에는 수렴할지 몰라도 품질(Quality)에는 수렴하지 않습니다.

요약하자면, 지시역에서 구현역으로 전달되는 것은 언어화된 정보뿐이며, 손맛과 같이 언어화할 수 없는 부분은 전달되지 못한 채 사라집니다. 프론트엔드나 UX처럼 언어화하기 어려운 과제는 특히 적합하지 않다고 볼 수 있습니다.

검증의 허점

리뷰 후 수정은 Fable이 하면 되지 않는가?

사실 경미한 수정은 Fable이 고치고 있습니다 (이번에도 「스프라이트 하단 빈 줄 때문에 캐릭터가 떠 있는 문제」는 Fable이 스스로 수정).

그렇다면 큰 수정도 Fable이 하면 되지 않느냐고 묻는다면, 그렇게 할 경우 Composer가 작성한 2,900행을 읽어 들여 고쳐야 하므로 직접 쓰는 것과 수고가 다를 바 없게 됩니다. Fable이 손을 움직일수록 「Fable에게 쓰게 하지 않음」으로써 성립되었던 절약은 사라집니다. 그렇다면 처음부터 Fable에게 쓰게 하는 편이 나을 것 같습니다.

이번에는 특히 「검증」으로서 이 경계선을 모호하게 하면 차이가 잘 보이지 않을 것이라 판단하여 이와 같이 설정했습니다.

구현역을 더 강력한 모델로 바꾸면 되지 않는가?

가능성 있는 이야기입니다. 이번 패배의 요인에는 Composer의 순수 구현 능력도 포함되어 있으므로, 구현역을 GPT 5.5 정도로 바꾼다면 결과가 달라질지도 모릅니다. (물론 Composer도 그렇게 저성능 모델은 아니라고 생각합니다만...)
이 부분은 향후 시도해 보고 싶습니다.

다만, GPT 5.5를 사용할 수 있다면 지시 역할과 구현 역할을 나누지 않고 처음부터 GPT 5.5에게 맡기면 될 태스크도 많아 보여서, 결국 "강한 모델에게 직접 쓰게 하면 되지 않을까?"라는 생각도 듭니다.

문제 설정이 특수한 것 아닌가?

"그야 기존 코드베이스도 없고, 한 장으로 다 써낼 수 있는 사이즈라면 Claude가 직접 쓰는 편이 낫지"라고 생각하신 분, 저도 그렇게 생각합니다. 실제로 이번 문제는,

• 기존 코드가 없기 때문에, 지켜야 할 규약을 모두 brief에 작성할 수밖에 없음
• 합격 여부가 "놀기에 재미있는가"로 결정되는데, 테스트도 lint도 없어서 리뷰에서 잡아낼 수 있는 것은 "망가져 있는가"까지임
• 1,000~2,000행은 Fable가 한 번에 다 써낼 수 있는 양

과 같이, 직접 구현에 유리한 조건이 갖춰져 있었습니다.

그럼, delegation (위임)이 이길 수 있는 실무 태스크는 있는가?

이론상으로는 후보를 꼽을 수 있습니다. 하지만 이번 검증을 거치며, 현 단계에서는 어느 것도 확실히 그렇다고 단정 지을 수 없다는 감각입니다.

참조 구현이 있는 반복 작업

"이 API와 같은 패턴으로 나머지 10개"와 같은 일이라면, brief는 "참조 구현은 여기. 똑같이"라고 끝낼 수 있습니다. 그렇긴 하지만, 이것은 Fable에게도 쉬운 부류의 일이라 굳이 위임할 필요까지는 없습니다. brief를 쓰는 편이 토큰을 더 잡아먹을 수도 있고, Composer도 완전 무료는 아니니까요. -

수락 기준을 기계 검증할 수 있는 일

typecheck / lint / 테스트가 갖춰져 있다면, Composer의 판단력 부족을 도구가 보완할 수 있습니다. 그럼에도 테스트가 지켜주는 것은 품질의 하한선이며, 명명(naming)이나 구조와 같은 "다음에 읽을 사람을 위한 질"에는 결국 차이가 발생합니다. -

출력량이 병목인 일

대량의 codemod나 i18n(국제화) 문자열 추출 등, 판단은 가볍지만 총량이 방대한 일.

이 부분은 약간 가능성이 있어 보입니다. 반면, Delegation을 수행해야 할 태스크인지에 대한 판단을 그르치면 품질을 떨어뜨리는 결과가 되며, 애초에 대량 변경은 그렇게 빈번하게 일어나지 않을 것이기에 굳이 이런 구조를 짤 정도는 아닐 것 같다는 느낌도 듭니다.

이 형태가 맞아떨어지는 태스크는 일부 존재한다고 생각합니다. 다만 "이 태스크가 맞을까?"를 매번 판별하는 비용 자체가 만만치 않고, 잘못 판단했을 때의 손실(이번과 같은 품질 저하와 3배의 토큰)도 큽니다. 그래서 현시점 저의 입장은, "일단 전부 Fable에게 쓰게 하는 편이 전체적인 가성비(cost-performance)가 좋아 보인다"는 것입니다. 물론, 종량제(pay-as-you-go)가 된다면 이야기는 다르겠지만요...

마치며

"Fable에게 지시하게 하고 하위 모델이 구현하면 된다"는 이번 검증에서는 잘 풀리지 않았습니다. 맞아떨어지는 태스크가 일부 있다고 해도, 그것을 판별하는 비용을 고려하면 일단 전부 Fable에게 쓰게 하는 편이 나을 것 같다는 입장입니다.

그렇긴 하지만, 이것은 Fable가 출시된 다음 날 "일단 시도해 본" n=1의 검증이며, 실무적인 검증은 아직 한창 진행 중입니다. 저 자신도 실제 코드베이스에서 앞으로 시도해 나갈 생각입니다.

실제로 Fable가 종량제가 될 무렵에는 전혀 다른 생각을 하고 있을 것 같다는 예감도 어렴풋이 듭니다. 그만큼 진보가 빠르다는 뜻이겠지요.

여러분도 꼭 시도해 보시고, "이 태스크라면 잘 됐다", "skill을 이렇게 바꿨더니 좋아졌다" 하는 것이 있다면 꼭 알려주세요!

Discussion