• 차이가 난 것은 「장시간·다단계·모호한」 업무. 수 시간급의 자율 태스크(Autonomous Task)와 의도를 다 채우지 못한 의뢰에서 Fable 5가 Opus 4.8을 명확히 앞질렀다.
• 정형·경작업에서는 체감 차이 없음. 분류·정형·단문 생성은 전편의 예상대로 「가격만 2배」로 끝났다.
• 전환 판단은 감이 아니라 **「재작업 횟수의 기록」**부터 시작하는 것이 빠르다. 1주일간 태스크 장부를 작성하고, 재작업이 2회 이상인 태스크만 두 모델에 A/B 테스트를 해보는 것으로 충분하다.

지난번, 「Fable 5에서 「Opus의 위」로 무엇이 가능해졌는지 5분 만에 파악하기」라는 기사에서 Fable 5의 스펙과 가격을 정리했습니다. 요점은, Opus 4.8의 정확히 2배 가격으로, 상시 사고(Thinking) 온(On) · 컨텍스트(Context) 100만 토큰 · 1 리퀘스트(Request)가 수 분~십수 분이라는 「수 시간급의 업무를 혼자서 완수하는 모델」이라는 것입니다.

새로운 모델이 나올 때마다 느끼는 것이지만, 알고 싶은 것은 「그래서, 실제로 어때?」라는 한 점인데, 타임라인에 흘러나오는 것은 스펙표의 전재와 가격 비교뿐입니다. 가격이 2배라면 업무의 질도 2배가 되는 것인지, 아니면 「사고가 상시 온 상태일 뿐인, 가격이 2배인 Opus」인 것인지. 이것은 스펙표를 몇 번을 읽어도, 공식 블로그를 몇 바퀴를 돌아도 알 수 없습니다. 결국 실제로 손을 움직여서, 같은 업무를 양쪽 모델에게 시키고 결과물을 나란히 놓고 비교해 보는 수밖에 없는 이야기입니다.

돌이켜보면, Sonnet 5가 나왔을 때도, Opus 4.8이 나왔을 때도 비슷한 흐름이었습니다. 발표 직후에는 스펙표와 가격표가 타임라인을 가득 채우고, 며칠 뒤에 「시도해 보았다」 계열의 기사가 하나둘씩 나오면서 겨우 실무적인 해상도로 이야기할 수 있게 됩니다. 이번 Fable 5는 가격이 2배라는 명확한 벽이 있는 만큼, 「시도해 보았다」의 중요도가 평소보다 높은 모델이라고 느끼고 있었습니다.

전편에서 세운 가설은 「Opus 4.8로 2~3번 재작업해도 납득할 수 없는 태스크만 Fable 5에 던져본다」는 것이었습니다. 이것은 어디까지나 책상 위의 예상이었으므로, 이번에는 이 예상이 실제로 맞는지, 맞다면 어느 정도나 맞는지에 대해 수중에 있는 업무 태스크로 검증하고 있습니다.

검증의 골자는 단순합니다. 일상 업무에서 성질이 다른 4가지 카테고리의 태스크를 선정하여, Opus 4.8과 Fable 5 양쪽 모두에 동일한 프롬프트 · 동일한 입력(동일한 리포지토리 상태, 동일한 자료)으로 의뢰하고, 나온 결과물을 동일한 기준으로 리뷰했습니다.

구체적으로는, 의뢰를 던지기 전에 리포지토리나 문서의 상태를 맞춰 두고, 한쪽 모델에 던졌다면 상태를 리셋하고 다른 쪽에 동일한 의뢰를 던지는 방식으로 「사후의 추가 정보」가 섞여 들어가지 않도록 하고 있습니다. 리뷰 시에는 어느 모델의 결과물인지 최대한 의식하지 않고 읽으며, 「이것을 그대로 채택할 수 있는가」, 「채택할 수 있다면 수정은 몇 군데 · 몇 번의 왕복으로 끝나는가」라는 기준만으로 판정했습니다. 벤치마크(Benchmark) 같은 스코어링(Scoring)은 하지 않았습니다. 기준은 「실무에서 쓸 수 있는가」라는 한 점입니다.

먼저 검증의 한계를 솔직하게 적어 두겠습니다. 이 부분을 얼버무리면 재현성 없는 기사가 되어버리기에, 일부러 장을 할애하겠습니다.

n=1입니다. 필자 한 명이 필자의 환경 · 필자의 판단 기준으로 수행한 하나의 사례이며, 통계적인 유의차를 주장하는 것이 아닙니다.
태스크는 필자의 업무 유래이며, 내용은 일반화 · 익명화하여 예시합니다. 사내 고유 정보나 구체적인 수치는 흐릿하게 처리했으므로, 「실제 태스크를 일반화한 예입니다」라고 주석을 단 곳은 어디까지나 분위기를 전달하기 위한 재구성입니다.
평가는 정량적 스코어가 아닌 실무 기준(채택 여부 · 수정 횟수)입니다. 속도나 정답률 같은 벤치마크적인 재현성은 처음부터 목표로 하지 않았습니다.

그럼에도 불구하고, 「자신의 업무에서도 똑같이 하면 똑같이 판단할 수 있다」는 재현성은 담보했다고 생각합니다. 프로토콜은 마지막 장에 체크리스트로 두겠습니다.

4가지 카테고리 선정 방식에 대해서도 보충해 두겠습니다. 적당히 4개를 고른 것이 아니라, 최근 1~2개월간의 자신의 업무 로그를 되돌아보며 「시간이 걸린 업무」 「의뢰가 모호했던 업무」 「고민해도 답이 나오지 않았던 업무」 「특별히 고민 없이 처리할 수 있었던 업무」라는 입도로 분류하여, 각각의 대표격으로 이번 4가지 카테고리를 선정했습니다. 즉, 검증 태스크의 선정 자체가 후술할 「태스크 장부」의 미니 버전이었다고도 할 수 있습니다. 또한 「수정(재작업)」의 정의도 맞춰 둘 필요가 있어, 이번에는 「결과물에 대해 이쪽에서 추가 지시를 내어, 모델에게 다시 손을 대게 한 횟수」를 카운트하고 있습니다. 오타 수정 같은 사소한 수정은 포함하지 않고, 설계 방침이나 구현 방침에 관련된 반려(rework)만을 셌습니다.

또 하나 주의했던 점은 확증 편향(Confirmation Bias)입니다. "Fable 5가 더 비싸니까 더 뛰어날 것이다"라는 선입견을 가지고 리뷰하면, 다소 억지스럽게라도 Fable 5의 결과물을 치켜세우게 될 위험이 있습니다. 이를 피하기 위해 결과물의 파일명이나 커밋 메시지(Commit Message)에서 생성 출처를 알 수 있는 정보를 먼저 삭제하고, 가능한 범위 내에서 어느 쪽의 출력물인지 숨긴 상태로 먼저 읽고 판정을 내린 뒤 정답을 확인하는 절차를 밟았습니다. 완전한 이중맹검(Double-blind)은 아니었지만(직접 요청을 던지고 있는 이상, 문체의 습관 등을 통해 어렴풋이 눈치채는 상황도 있었습니다), 아무것도 하지 않는 것보다는 판정의 편차를 줄일 수 있었을 것입니다.

이 부분이 가장 명확하게 차이가 난 카테고리입니다.

예를 들어, "레거시(Legacy)한 사내 API 클라이언트 모듈 일체를, 타입 정의(Type Definition)나 호출 측의 호환성을 유지한 채 새로운 SDK의 인터페이스로 교체하고, 영향 범위 테스트도 함께 수정한다"와 같이 착수부터 수 시간이 걸리는 규모의 리팩터링(Refactoring) 태스크를 두 모델에 던졌습니다(※ 실제 태스크를 일반화한 예시입니다). 이와 더불어, 여러 로그 파일이나 모듈에 걸친 결함의 원인을 횡단적으로 읽어내어 조사 보고서로 정리하는 장시간 조사 계열 태스크로도 비교했습니다.

Opus 4.8은 초반의 속도와 정밀도는 충분하여, 처음 1~2시간 분량의 작업만 보면 차이를 느끼지 못합니다. 다만 작업이 장기화될수록 도중에 방침이 흔들리거나, 초반에 결정한 설계 판단을 후반에 마치 잊어버린 것처럼 모순된 코드를 작성하는 장면이 나타났습니다. 조사 태스크에서도 마찬가지로, 초반에 "이 가설은 기각했다"라고 스스로 판단했을 내용을 후반 보고서에서 다시 꺼내 드는 경우가 있었습니다. 인간이 주기적으로 "아까 방침대로 계속해", "그 가설은 이미 검토했어"라고 개입하여 궤도를 수정한다는 전제라면 충분히 실용적이지만, 방치하면 품질이 시간이 흐름에 따라 완만하게 무너져 내리는 느낌을 받았습니다.

Fable 5는 같은 규모의 태스크에서 끝까지 혼자서 완주하는 지구력이 확실히 달랐습니다. 초반에 결정한 설계 방침을 마지막 변경까지 일관되게 지키며, 도중에 멈춰서 확인을 요청하는 일도 없이, 결과물을 통틀어 보았을 때 "전반부와 후반부를 쓴 사람이 다른 것 같다"는 위화감이 없습니다. 조사 계열 태스크에서도 한 번 기각한 가설을 다시 들추지 않고 최종 보고까지 로직의 맥락이 통했습니다. 전편에서 언급한 "사고가 상시 온(On) 상태", "1회 요청(Request)이 수 분~십수 분"이라는 사양은 허세가 아니었으며, 바로 이 "장시간 방치해도 무너지지 않기" 위해 지불된 비용이라는 점에 납득했습니다.

이 카테고리에서 가장 인상적이었던 것은 결과물의 "차이(Diff)의 질"이었습니다. Opus 4.8의 차이는 변경이 필요한 부분에는 확실히 손을 대고 있지만, 도중에 리팩터링의 입도(Granularity)가 변하거나(처음에는 함수 단위로 깔끔하게 나누다가 후반에는 파일 전체를 한꺼번에 갈아엎는 듯한 거친 모습이 되는 등), 주석을 쓰는 톤이 중간부터 바뀌는 일이 있었습니다. 단독으로는 알아채기 어렵지만, 차이 전체를 통틀어 리뷰하면 "숨이 차는" 듯한 흔적이 보입니다. Fable 5의 차이는 첫 번째 커밋부터 마지막 커밋까지 입도와 톤이 일치하여, 리뷰 시에 "여기서부터 갑자기 조잡해졌다"라는 부분을 찾는 수고 자체가 발생하지 않았습니다. 장시간 태스크에서의 리뷰 비용은 수정량보다 "어디서 품질이 무너졌는지 찾는 수고"가 은근히 크게 작용하기 때문에, 이 부분이 일치하는 것만으로도 리뷰어 측의 부담은 상당히 다릅니다.

"지구력"을 판단하기 위해 실제로 관찰했던 포인트도 적어둡니다. 구체적으로는 ① 테스트를 작성만 해두고 방치하지 않고 끝까지 통과된 상태로 만들 수 있는가, ② TODO 주석을 남겨둔 채 끝나지 않는가, ③ 초반에 결정한 명명 규칙(Naming Convention)이나 설계 방침이 종반까지 일관되는가, 이 세 가지 점입니다. Opus 4.8은 이 세 가지 중 1~2개 지점에서 어딘가 숨이 차는 흔적이 보이는 경우가 많았고, Fable 5는 세 가지 모두 마지막까지 유지되는 경우가 많다는 것이 이번에 관찰된 경향이었습니다. 어디까지나 경향일 뿐, Opus 4.8이 반드시 무너지는 것도, Fable 5가 절대로 무너지지 않는 것도 아니라는 점은 덧붙여 둡니다.

이 부분에서도 차이가 났습니다.

"이 로그 집계 배치(Batch), 조금 더 쓰기 편하게 해줘"와 같이 의도를 다 채우지 않고 던진 한 마디 요청으로 비교했습니다(※ 실제 태스크를 일반화한 예시입니다). 이런 요청은 본래 좋지 않은 요청 방식이지만, 현실 업무에서는 일상다반사입니다. 의뢰인 자신도 "쓰기 편하게"의 구체적인 상을 가지고 있지 않은 경우가 많으며, 오히려 그것을 이쪽에서 생각해 주기를 바라는 것이 본심이기도 합니다.

Opus 4.8은 모호함이 큰 태스크에 대해 "사용하기 편하게 만든다는 것이 구체적으로 어떤 개선을 의미합니까?"라고 확인 질문을 던지는 경우가 많으며, 이는 그 자체로는 성실한 태도입니다. 하지만 의뢰자 측에서 의도를 명확하게 언어화하지 못했을 경우, 여기서 대화가 멈추고 제자리걸음을 반복하기 쉬웠습니다. 바쁠 때 이런 캐치볼(Catch-ball)이 끼어들면, 결국 이쪽에서 사양(Specification)을 직접 작성해야 하는 상황이 되어 "이럴 거면 처음부터 직접 쓰는 게 더 빨랐겠네"라는 기분이 듭니다.

Fable 5는 모호한 의뢰에 대해 질문 공세를 퍼붓는 대신, 문맥(주변 코드, 과거 커밋 이력, 명명 규칙, 유사 모듈의 구조)으로부터 타당한 디폴트(Default)를 스스로 결정하고, 우선 한 차례 손을 움직인 상태로 제시해 오는 경우가 많다는 인상을 받았습니다. 비유하자면 신입과 베테랑의 차이와 비슷하다고 느낍니다(※비유입니다). 신입은 지시가 모호하면 "그게 무슨 뜻인가요?"라고 매번 확인하지만, 베테랑은 문맥을 통해 "아마 이런 뜻이겠지"라고 짐작하여 우선 돌아가는 것을 만든 뒤, "이 해석이 맞습니까, 틀리다면 수정하겠습니다"라고 확인합니다. Fable 5의 행동은 후자에 가까우며, 의뢰자가 의도를 100% 언어화하지 못하더라도 첫 번째 제시에서 "채택" 또는 "경미한 수정 후 채택"에 도달하는 비율이 체감상 높은 태스크 카테고리였습니다. 이는 특히 의뢰를 던지는 측에 시간적 여유가 없는 현장일수록 유효한 차이라고 느낍니다.

조금 더 구체적으로 쓰자면, "사용하기 편하게"라는 의뢰에 대해 Fable 5가 실제로 결정해 온 디폴트는 "실행 결과의 요약(Summary)을 맨 앞에 배치하기", "에러 발생 시 로그를 조금 더 사람이 읽기 쉬운 형식으로 바꾸기", "자주 사용하는 옵션에 숏핸드(Shorthand) 추가하기"와 같이 주변 코드의 작성 방식으로부터 유추할 수 있는 범위 내의 개선이었습니다. 물론 빗나가는 경우도 있지만, 설령 빗나간다 해도 "토대가 만들어진 상태에서의 궤도 수정"으로 끝낼 수 있기 때문에, 처음부터 대화를 다시 시작하는 것보다 빠르게 결론에 도달합니다. 모호한 의뢰를 던지기 쉬운 쪽은 경험이 적은 멤버나 바빠서 언어화에 시간을 할애할 수 없는 멤버인 경우가 많으며, 그러한 의뢰자일수록 이 차이의 혜택을 받기 쉽다는 점도 실무적으로는 놓칠 수 없는 포인트였습니다.

덧붙이자면, 이것은 "모호한 의뢰를 던져도 된다"는 뜻이 아닙니다. 의뢰를 정중하게 언어화하는 것이 가장 좋으며, 그 노력을 게을리해도 되는 이유는 되지 않지만, 현실의 업무에서는 시간적 제약으로 인해 거기까지 손이 닿지 않는 상황이 반드시 발생합니다. 그러한 "사실은 좋지 않지만 피할 수 없는 모호함"을 흡수해 주는 정도가 다르다는 것이 이번 검증에서 확인하고 싶었던 점입니다.

솔직한 결론은, 이 부분은 조건부로 차이가 났다는 것입니다.

"원인 불명의 간헐적인 결함 구분"이나 "여러 아키텍처 안(예를 들어 데이터 보유 방식을 테이블 분할로 할지, 단일 테이블로 모을지) 중에서 어느 것을 선택할지의 설계 판단"과 같은 태스크로 비교했습니다(※실제 태스크를 일반화한 예시입니다). 단 한 번의 상호작용만 보면 Opus 4.8과 Fable 5의 "똑똑함" 차이는 그렇게 크게 체감되지 않습니다. 단발적인 통찰의 날카로움이라는 점에서는 양쪽 모두 충분히 우수합니다.

차이가 발생하는 지점은 가설을 세우는 방식과 검증하는 자세입니다. Fable 5는 여러 가설을 병행하여 세우고, 각각을 스스로 반증하러 가는( "이 가설이라면 이 로그의 타임스탬프와 모순될 것이므로 틀리다"와 같은 자기 반박) 움직임이 눈에 띄었습니다. 설계 판단 태스크에서도 한쪽 안을 밀기 전에 양쪽 안의 트레이드오프(Trade-off)를 스스로 도출하고, "이 안은 향후 이런 케이스에서 파탄 날 수 있다"라고 앞서서 차단한 뒤 결론을 내리는 장면이 있었습니다. 결과적으로 Opus 4.8에서는 2~3번의 재작업이 필요했던 조사·판단이, Fable 5에서는 단 한 번의 제시로 거의 마무리되는 형태로 효과를 발휘합니다. 즉 "한 번의 똑똑함"이 아니라 "한 번에 정답에 가깝게 만드는 끈기"의 차이라고 하는 것이 실감에 가까운 표현입니다. 반대로 말하면, 시간을 들여 이쪽과 대화하며 다듬어가는 스타일의 조사라면 Opus 4.8로도 최종적인 도달점은 크게 다르지 않을 것이라고도 느꼈습니다.

실무적으로는 이 카테고리를 하이브리드로 사용하는 것이 가장 적절했습니다. 먼저 Opus 4.8로 가볍게 벽치기(Wall-hitting, 아이디어 브레인스토밍)를 하며 논점을 도출하고, 그럼에도 2~3번 재작업해도 납득이 가지 않거나, 처음부터 단번에 결론까지 가져가야 하는 무거운 판단만을 Fable 5에 던지는 방식입니다. 모든 것을 처음부터 Fable 5에 던지는 것이 아니라, "벽치기는 Opus, 최종 판단은 Fable" 정도의 온도감이 가격과 대기 시간의 밸런스로서 현실적이라고 느꼈습니다.

설계 판단 태스크에서 실제로 나타난 결과물의 경향에 대해서도 언급해 두겠습니다. Opus 4.8은 「안 A·안 B의 장점·단점」을 나열한 뒤 「상황에 따라 다릅니다」라는 형태로 끝나는 경우가 있는데, 이는 성실하기는 하지만 결국 최종적인 의사결정은 우리에게 맡겨지게 됩니다. 반면 Fable 5는 동일한 재료를 나열한 상태에서, 「이번 데이터 증가 속도와 향후 요구사항을 고려하면 A안이 우세함. 단, B안을 선택할 경우에는 이 제약 사항에 주의」와 같이 한 걸음 더 들어간 권장안까지 제시해 주는 경우가 많아, 의사결정자 입장에서는 그대로 사내 자료로 전용하기 쉬운 형태로 돌아왔습니다. 이러한 「한 걸음 더 들어가 결론을 내는」 자세야말로, 재작업 횟수를 1회로 끝낼 수 있는 핵심 이유라고 느꼈습니다.

이 부분은 전편에서 세웠던 예상대로, 차이가 나지 않았습니다.

로그 분류, 포맷 정형화, 정형적인 단문 생성, 커밋 메시지 초안 작성과 같은 태스크에서는 Opus 4.8과 Fable 5의 결과물을 비교해 봐도 차이를 알 수 없었습니다. 오히려 체감 응답 시간은 Opus 4.8이 더 짧았으며, 이러한 경작업(Light work)에 관해서는 가격이 2배인 Fable 5를 사용할 이유를 찾을 수 없습니다.

이는 전편에서 썼던 「Mythos급은 즉답을 잘하는 모델이 아니라, 몇 시간 분량의 업무를 혼자서 완수하는 모델」이라는 정리와 일치하는 결과로, 사실 확인이 된 셈입니다. 비유하자면 고급 스시집의 장인에게 편의점 주먹밥을 쥐게 하는 것과 같아서, 만들어진 주먹밥 자체는 평범하게 맛있지만 그 장인을 굳이 지명할 의미가 없습니다 (※농담입니다). 정형·경작업은 Haiku 4.5나 Sonnet 5에 맡기는 것이 솔직한 선택이며, 이 판단만큼은 전편부터 전혀 흔들리지 않았습니다.

오히려 운용상의 주의점으로서, 이러한 경작업 루틴에 Fable 5가 섞여 들어가지 않도록 하는 것이 실무적인 과제였습니다. 예를 들어 공통 스크립트나 CI의 모델 지정(Model specification)을 수정했는데 일부 호출 부분만 바꾸는 것을 잊어버려, 정형 처리가 자신도 모르는 사이에 Fable 5를 경유하여 흘러가고 있었다는 상황은 실제로 일어날 법한 사고입니다 (다행히 이번에는 실질적인 피해로 이어지지는 않았습니다). 「비싼 모델을 어디에 쓸 것인가」뿐만 아니라 「저렴한 태스크에 비싼 모델이 섞여 들어가지 않았는가」도 함께 모니터링할 가치가 있어 보입니다.

검증 태스크 자체와는 별개로, 실제로 운용해 보며 알게 된 점도 적어 두겠습니다. 상세한 사양은 전편 기사에 맡기고, 여기서는 체감 위주로만 언급하겠습니다.

「1 요청당 몇 분~십수 분」은 사실이었습니다. 어려운 태스크일수록 현저하며, 진행 표시 없이 기다리다 보면 「멈춘 것 아닌가」 하고 불안해질 정도의 길이입니다. 타임아웃(Timeout) 설정은 길게 잡고, 가능하다면 display: "summarized"로 요약된 사고 로그(Thinking log)를 흘려보내서, 대기 시간 동안에도 무언가 진행 상황이 보이는 화면 설계로 해두지 않으면 운용 담당자가 의구심을 갖게 됩니다. CLI에서 사용할 경우에는 스피너(Spinner)뿐만 아니라, 최근의 요약 텍스트를 한 줄씩 흘려주는 것만으로도 체감되는 안심감이 상당히 달라졌습니다.

거부(Refusal)의 오작동은 보안 관련 조사 태스크에서 실제로 한 번 마주쳤습니다. 내용은 완전히 무해한 업무였기에, stop_details를 보고 안전 분류기(Safety classifier)의 오반응임을 파악하였고, fallbacks를 통해 Opus 4.8로 자동 퇴피(Fallback)하도록 설정한 이후로는 문제없이 돌아가고 있습니다. 빈도는 드물지만, 업무 플로우에組み込む(組み込む, 포함시키다) 경우에는 「거부되면 인간에게 통지하고 끝」이 아니라, 자동 폴백(Automatic fallback)까지 마련해 두는 것이 실무적이었습니다.

이전 시의 400 지뢰는 전편에 쓴 체크리스트 내용 그대로였으며, 실제로 오래된 공통 래퍼(Wrapper) 깊숙한 곳에 temperature

가 하드코딩되어 있어 모든 엔드포인트가 일제히 400 에러가 발생하는 사고를 겪었습니다. 이관 전의 grep은 정말 유용합니다. 이 부분에 대한 자세한 내용은 전편의 「이관 시 400이 되는 경우」 장을 참조해 주세요 -
이용 로그를 남기는 방식도 재검토가 필요했습니다. 1개의 요청(Request)이 장시간·다단계로 진행되는 만큼, 「어떤 태스크에 어느 모델을 사용했고 결과는 어떠했는지」를 나중에 추적하기 어려워집니다. 이번 검증에서 사용한 태스크 대장은 부수적으로 이러한 이용 실태를 가시화하는 데에도 도움이 되었습니다. 개인의 검증으로 끝내지 않고 팀에서 사용한다면, 처음부터 로그를 남기는 방식을 세트로 정해두어야 나중에 「그 태스크는 결국 어느 쪽이 더 좋았더라?」라며 고민하는 일을 방지할 수 있습니다 -
비용 감각의 차이도 무시할 수 없습니다. 전편에서 「입력 10만 + 출력 3만 토큰의 무거운 요청 1회당」 기계적인 시산을 소개했지만, 실제로 장시간 태스크를 몇 번 돌려보니 체감되는 청구 금액은 그 시산보다 더 무겁게 느껴졌습니다. 장시간 태스크일수록 중간의 도구 호출(Tool Call)이나 컨텍스트(Context) 읽기가 누적되기 때문에, 단순한 입출력 토큰 수의 곱셈만으로는 실감을 전달하기 어렵다는 것이 솔직한 소감입니다. 예산을 확보할 때는 기계적인 시산 값에 약간의 버퍼(Buffer)를 두는 것을 권장합니다.

지금까지 작성해 온 4가지 검증과 번외편의 운용 측면을 정리하여 목록으로 만들어 두겠습니다. 개별 장을 다시 읽지 않더라도, 이 표와 후술할 판정 플로우(Flow)만 보면 「지금의 태스크를 Fable 5에 던질 가치가 있는가」를 가늠할 수 있을 것입니다.

카테고리	Fable 5의 우위성	코멘트
수 시간급 자율 태스크 (리팩토링·조사)	◯	완주하는 지구력·품질의 일관성에서 명확한 차이
...
△인 「어려운 버그 조사·설계 판단」이 가장 판단하기 어려운 행이라고 생각합니다. 여기는 「대화하며 다듬을 시간이 있는가」에 따라 갈린다는 것이 이번 검증의 실감입니다. 시간적 여유가 있어 Opus 4.8과 여러 번 캐치볼(Catch-ball)을 할 수 있다면 차이는 좁혀지겠지만, 한 번에 착지시키고 싶거나 재시도(Retry)의 왕복 비용 자체를 줄이고 싶은 상황에서는 Fable 5에 던질 가치가 있었습니다.

판정 기준은 심플합니다. 「Opus 4.8에서 재시도가 2회 이상 이어진 태스크」만을 Fable 5의 후보로 삼는다는 전편의 가설대로 진행해도 문제없었습니다. 반대로 재시도가 1회 이내로 끝나는 태스크에 Fable 5를 사용해도 체감 차이는 거의 없습니다.

팀 등에서 전개할 경우에는 이 판정 기준을 개인에게 맡기지 말고, 팀의 공통 규칙으로 정해두는 것을 권장합니다.

누군가가 「왠지 똑똑해 보이니까」라는 이유로 Fable 5를 사용하기 시작하면, 앞서 언급한 「가벼운 작업에 섞여 들어가는 현상」처럼 비용만 쌓이고 효과는 보이지 않는 상태에 빠지기 쉽습니다. 반대로 재시도 횟수라는, 누구나 셀 수 있는 지표를 팀의 공통 언어로 삼아두면 「이 태스크 유형은 Fable행」이라는 합의 형성이 쉬워집니다.

독자가 자신의 업무에서 동일한 검증을 하기 위한 재현 프로토콜을 체크리스트로 만들어 두겠습니다.

1주일 동안 평소의 업무 태스크를 대장에 기록한다. 의뢰 내용·사용한 모델·재시도 횟수라는 3가지 항목만으로 충분합니다. 복잡한 기록 포맷은 필요 없습니다 -
대장에서 「재시도 2회 이상」이었던 태스크를 추출한다. 이 숫자가 적다면 애초에 현재 모델로도 충분하다는 신호입니다 -
추출한 태스크만 Opus 4.8과 Fable 5에 동일 조건으로 의뢰하여 A/B 테스트를 한다. 동일한 리포지토리 상태·동일한 자료를 사용하여, 한쪽을 테스트했다면 상태를 되돌린 후 다른 쪽을 테스트하는 것이 포인트입니다 -
성과물의 채택 여부와 수정 횟수를 기록한다. 수치화하려고 애쓰지 말고 「채택됨 / 수정 ◯회 후 채택 / 불채택」과 같이 거친 입도로 충분합니다 -
차이가 나지 않으면 Opus 4.8로 돌아간다. 차이가 나는 태스크 유형만 Fable 5를 상용하는 부분적인 전환에 머뭅니다 -
1개월 후, 동일한 대장을 다시 검토한다. 업무 내용이 바뀌면 판정 기준도 바뀌므로, 단 한 번의 판정으로 고정하지 마십시오.

판정 플로우를 도식화하면 다음과 같습니다.

이 대장 자체가 Fable 5에 먹일 가치가 있는 태스크를 찾기 위한 필터라고 생각하면, 수수해 보이지만 가장 가성비 좋은 투자라고 생각합니다. 「왠지 모르지만 최강 모델을 상용한다」보다 「재시도가 많은 태스크만 높은 모델로 몰아준다」는 쪽이 월말 청구서를 볼 때의 정신 건강에도 좋을 것입니다.

Q. 검증에 어느 정도의 기간을 들였는가?

A. 구체적인 일수는 업무 사정상 밝히지 않겠으나, 한 번에 모든 카테고리를 검증한 것이 아니라 일상적인 업무 중에 해당되는 태스크가 나올 때마다 두 모델 모두에 던져보는 방식으로 조금씩 샘플을 쌓아 올렸습니다. 집중적인 검증 기간을 확보하기 어려운 사람이라도, 이처럼 "업무 속에서 자연스럽게 쌓아가는" 방식이라면 무리 없이 재현할 수 있을 것입니다.

Q. n=1의 결과를 믿어도 되는가?

A. 믿느냐 마느냐의 문제라기보다, "자신의 업무에 적용되는지는 스스로 확인할 수밖에 없다"는 것이 이 글의 입장입니다. 이번 결과는 하나의 가설로 가져가시고, 마지막 체크리스트를 통해 자신의 업무에 대해 동일한 절차를 돌려보시는 것을 권장합니다. 타인의 검증 결과를 무비판적으로 수용하느니, 자신의 태스크 대장(task ledger)을 확인하는 것이 훨씬 확실한 지표가 됩니다.

Q. Sonnet 5와의 비교는 하지 않는가?

A. 이번에는 Opus 4.8과의 비교에 집중했습니다. 전편의 판단 플로우(decision flow)에서 언급했듯이, 대량 처리 및 가성비(cost-performance)를 중시하는 경작업은 애초에 Sonnet 5나 Haiku 4.5의 담당 영역입니다. Fable 5와 경쟁할 수 있는 영역은 "Opus 4.8로 버텨보려 해도 재작업이 계속되는 태스크"라고 생각하기 때문입니다. Sonnet 5와의 비교는 다른 기회에 다루도록 하겠습니다.

Q. 검증 결과가 다른 엔지니어에게도 적용되는가?

A. 업무 내용이 비슷하다면 경향성 자체는 참고가 되겠지만, 그대로 믿기보다는 우선 자신의 태스크 대장으로 일주일 분량이라도 시험해 보시는 것을 추천합니다. 검증한 4가지 카테고리 중 자신의 업무가 어디에 치우쳐 있느냐에 따라 Fable 5로부터 얻을 수 있는 혜택의 크기는 크게 달라집니다. 정형 작업(routine work)의 비중이 높은 팀이라면, 이번 결과보다 "차이가 나지 않는" 비율이 더 높게 나타날 가능성도 충분합니다.

• Fable 5가 가격 차이(Opus 4.8의 2배)만큼의 가치를 하는 것은, 장시간·다단계(multi-step)·모호함이라는 세 가지 조건이 겹치는 업무뿐이었습니다. 정형·경작업에서는 체감 차이가 없었으며, 전편의 예상대로 "가격만 2배"인 결과로 끝났습니다.
• 난해한 버그 조사 및 설계 판단은 조건부입니다. 아이디어 스케치(wall-hitting)는 Opus 4.8로, 최종 판단(final judge)만 Fable 5로 하는 하이브리드 운용이 현실적이었습니다.
• 모델을 교체할지 여부는 감으로 결정하지 말고, 재작업 횟수의 기록부터 시작하는 것이 가장 빠르고 정확합니다.

"스펙 시트(spec sheet)대로의 결과였습니다"와 "스펙 시트와는 다른 결과였습니다" 중 어느 쪽이 나와도 기사로서는 흥미롭겠지만, 이번에는 대체로 전편의 가설과 일치하는, 다소 수수하지만 실용 면에서는 가장 반가운 결과로 마무리되었습니다. 가설과 일치했기에 판단 플로우를 그대로 안심하고 계속 사용할 수 있습니다. 화려한 반전은 없지만, 내일부터 바로 사용할 수 있는 판정 기준이 남았다면 검증 기사로서 충분히 제 역할을 다했다고 생각합니다.