Fable 5가 돌아왔다!!

6/9에 GA(General Availability)되어, 6/12에 수출 규제로 중단되었다가, 6/30에 규제 해제, 7/1에 부활(공식 성명). 롤러코스터 같은 3주일이었습니다.

그리고 이번에는 7/1~7/7, 주간 이용 한도의 최대 50%까지 Fable 5가 무료 개방되어 있습니다. Pro/Max/Team, 일부 Enterprise premium seat 대상입니다. API 이용은 이 무료 한도에 포함되지 않습니다.

Fable에게 코드를 쓰게 하지 마라. Fable에게는 「무엇을 써야 하는가」를 찾게 해라.

이것이 결론입니다. 이후, 그 이유를 파헤쳐 보겠습니다.

한마디로 말하면, 「왜 구현(Implementation)에 맡기는 것이 좋지 않은가」입니다.

조금 더 구체적으로는 다음과 같습니다.

• 왜 분류기(Classifier)의 오작동이 구현 태스크에서 특히 치명적인가
• 구현 이외에 맡긴다면, 무엇이 후보가 될 것인가

이 질문에 답해 나가겠습니다.

50%나 무료로 쓸 수 있다면, 가장 토큰을 많이 소비하는 작업, 즉 구현에 맡기는 것이 이득이라고 생각하는 것이 자연스럽습니다.

대규모 리팩터링(Refactoring), 며칠이 걸리는 기능 구현, 방치된 기술적 부채(Technical Debt)의 해소. 모두 「시간은 걸리지만 절차는 정해져 있는」 태스크로 보입니다. 50% 한도를 여기에 쏟아붓고 싶어질 것입니다.

하지만, 이것은 절반만 맞습니다.

분류기의 오작동으로 인해 자율 주행이 도중에 멈출 리스크가 있다. 이것이 구현에 맡기는 것을 피하고 싶은 이유입니다.

자세히 살펴보겠습니다.

공식 도움말에 따르면, Fable 5는 모든 요청에 대해 safety classifier를 실행하고 있습니다. 대상은 3개 영역입니다.

• 공격적인 사이버 보안 기술
• 생물학 계열의 내용
• 모델 자신의 사고 과정(Reasoning process) 추출

오작동하면 어떻게 될까요? 자동으로 Opus 4.8로 전환되며, 이후의 대화는 Opus로 고정됩니다 (수동으로 되돌릴 수 있습니다).

이 점이 결정적입니다. 이 체크는 직전 메시지만 보는 것이 아니라, memory·connector를 경유한 콘텐츠·web 검색 결과·파일까지 전부 포함해서 본다고 공식적으로 명시되어 있습니다.

바꾸어 말하면, 내가 아무것도 쓰지 않았더라도 memory의 내용만으로 오작동할 수 있다는 뜻입니다.

overnight run(밤샘 실행)을 전제로 하는 사용법은 「도중에 모델이 교체되지 않는다」는 것이 대전제입니다. 이 메커니즘은 그 전제를 조용히 깨뜨립니다. 장시간 자율 주행을 시키고 싶은 태스크일수록, 도중에 멈췄을 때의 비용은 높습니다.

세 번째 대상인 「모델의 사고 과정 추출」이 은근히 영향을 미칩니다.

공식 프롬프트 가이드는, "reasoning을 출력하게 하거나/설명하게 하는" 계열의 지시가 reasoning_extraction이라는 refusal 카테고리를 오발화시켜, Opus로의 폴백(Fallback)을 늘린다고 명시하고 있습니다.

이 기사에서 후술할 「탐색·진단시키기」 사용법은, 성질상 「왜 그렇게 판단했는지 설명해줘」라는 지시를 쓰고 싶어지는 상황이 많습니다.

솔직하게 쓰면, 스스로 오작동 리스크를 높이는 꼴이 됩니다. reasoning의 가시화가 필요하다면, 모델에게 설명하게 하는 것이 아니라 summarized thinking blocks를 읽도록 설계해야 합니다.

밀고 있는 사용법의 발목을 그 사용법 자체가 잡는 셈입니다. 은근히 까다로운 문제입니다.

분류기의 오작동 리스크를 유형별로 정리하면 다음과 같습니다.

구현 태스크 : 분류기 영역에 닿기 쉽고 & 도중에 멈추면 피해가 크다 -> Fable에게 맡기면 손해 보기 쉽다
탐색·진단 태스크 : 도중에 다소 멈춰도 피해가 작다 -> Fable의 강점과 맞닿아 있다

Fable의 장기 자율 주행 능력이 진정으로 빛을 발하는 것은, 「무엇을 구현해야 하는지 자체가 자명하지 않은」 단계입니다. 구체적으로는:

• 기술적 부채가 어디에 쌓여 있는지, 코드베이스 전체를 횡단하여 찾아내기
• 여러 설계 선택지(TCA vs Riverpod, Repository 계층을 나누는 방식 등)를 실제 코드 규모와 의존 관계를 바탕으로 비교시키기
• 「이 기능을 6개월 운영하면 어디가 망가질까」를 현재의 아키텍처로부터 역산시키기
• 수탁 프로젝트에서 요구사항이 모호할 때, 클라이언트에게 물어봐야 할 질문 리스트를 코드베이스나 기존 문서로부터 역으로 만들어내기

만약을 위해 덧붙이자면, 이 4가지는 공식 소스에 나와 있는 사례가 아니라, 지금까지의 근거를 바탕으로 제가 도출한 제안입니다. 구현하게 하는 것이 아니라, 탐색·진단·계획하게 하는 태스크입니다.

게다가 한 번의 지시로 끝나지 않고, 모델이 스스로 가설을 세우고 검증을 반복할 필요가 있습니다.

그야말로 overnight run에 적합합니다.

공식 프롬프트 가이드는, 구모델을 위해 작성한 skills나 프롬프트는 Fable 5에게 너무 규정적(prescriptive)이어서 오히려 출력의 질을 떨어뜨릴 수 있다고 명시하고 있습니다.

기본 동작(default behavior)이 더 우수하다면, 오래된 지시사항은 삭제를 검토하라는 것입니다.

가이드 전체의 구성을 보더라도, 지시 이행(instruction-following)의 강점, 의도(reason)를 전달하는 것의 유효성, 경계(boundary)의 명시, 자기 검증(self-verification)이라는 4가지 요소가 반복적으로 등장하는 핵심 기둥이 되고 있습니다.

이는 구현(implementation) 태스크와는 상성이 좋지 않습니다. 구현은 구체적인 절차와 제약이 많을수록 안정적이지만, Fable와 같이 자율 탐색(autonomous exploration)에 특화된 모델에게 이를 부여하면 과도한 지시가 노이즈가 됩니다.

반대로 '방침을 생각하게 하는' 태스크는 원래 지시가 느슨해도 되기 때문에, Fable의 강점과 구조적으로 맞물립니다.

갑자기 빌드하게 하지 마라. 먼저 명확화 질문(clarifying question)으로 내용을 채우게 하라. 검증 기준을 먼저 언어화하게 한 뒤 착수하게 하면, 진행 상황에 대한 자기 보고(self-reporting)를 신뢰할 수 있게 됩니다. -
진행 상황 조작을 방지하는 문구를 반드시 포함하라(공식 프롬프트 가이드에 따르면, 사내 테스트에서 조작 보고를 거의 완벽하게 배제할 수 있었다고 하는 블록):

Before reporting progress, audit each claim against a tool result from this session.
Only report work you can point to evidence for; if something is not yet verified, say so explicitly.
Report outcomes faithfully: if tests fail, say so with the output; if a step was skipped, say that;
...

던져주는 것은 '쌓여 있는 태스크 중 가장 무거운 것'으로 한정하라. 주간 할당량의 50%는 유한합니다. 토이 태스크(toy task)나 일상적인 코딩에 낭비하는 것은 기회비용의 손실입니다.

50%의 할당량은 '코드를 쓰게 하는 것'보다 '코드를 쓰기 전에 결정해야 할 것들을 결정하게 하는 것'에 사용하십시오. 이것이 저의 결론입니다.

구현은 평소의 워크플로우(workflow)에 맡기고, Fable에게는 장기 방침, 기술 부채(technical debt)의 목록 작성, 의사 결정을 위한 자료 수집을 맡깁니다. 분류기(classifier)의 오작동(false positive) 리스크라는 관점에서 보면, 구현보다 탐색에 더 적합하다는 사실은 꽤 기계적으로 도출될 수 있습니다.

이번 일주일의 할당량을 구현에 다 써버리고 끝내기에는 너무 아깝다고 생각합니다.