Sonnet 5 vs Fable — 반복 작업은 Sonnet 5가, 대형 작업은 Fable이 저렴한 이유

같은 리팩토링 작업을 Fable로는 한 번에 끝냈는데 Sonnet 5로는 세 번 돌려야 했습니다. 요금제상 Sonnet 5가 더 저렴하지만, 재시도 비용을 더하니 결과는 반대였어요. 제가 내린 결론은 이렇습니다. 짧은 반복 작업엔 Sonnet 5, 한 번에 끝내야 하는 대형 작업엔 Fable. 구독 한도 내에서 어떤 모델을 고를지는 작업 유형이 결정합니다.

제가 비교한 기준은 세 가지입니다

이 글은 API 단가 비교가 아니라 구독 한도 내 실질 비용 비교예요. 저는 이 블로그 자동발행 파이프라인을 운영하면서 두 모델을 번갈아 써봤고, Reddit 커뮤니티 실사용 보고도 참고했습니다.

핵심 기준은 토큰 소비량, 세션 한도 소진 속도, 재시도 비용이었어요. 같은 구독료를 내도 작업 하나를 끝내는 데 세션 한도를 얼마나 먹는지, 실패했을 때 재시도 비용이 어느 쪽이 가벼운지가 달랐거든요. 제가 확인한 시점 기준으로 Fable은 주간 한도가 더 빡빡하지만 한 번에 끝내는 확률이 높았고, Sonnet 5는 한도가 넉넉하지만 프롬프트를 여러 번 돌려야 했습니다.

짧은 코드 수정은 Sonnet 5가 답이었습니다

제가 먼저 시도한 건 Sonnet 5였어요. 블로그 초안 하나를 생성하는 작업에서 Sonnet 5는 평균 2~3분 안에 1,500음절짜리 초안을 내줬습니다. 프롬프트 한 번에 끝났고요. 이 정도 작업은 세션 한도를 거의 안 먹어서 하루에 10건도 문제없었습니다.

문제는 복잡한 리팩토링이었어요. 검증자 에이전트 코드를 수정하는 작업에서 Sonnet 5는 첫 시도에서 테스트 케이스 2개를 놓쳤습니다. 프롬프트를 다시 던지니 이번엔 다른 곳에서 버그가 생겼어요. 결국 세 번째 시도에서 통과했는데, 체감상 10분 정도 걸렸습니다. 커뮤니티 보고에서도 "Fable이 한 번에 끝낼 작업을 Sonnet 5로는 프롬프트 2~3회 돌려야 한다"는 증언이 있었어요(출처: Reddit 커뮤니티 실사용 보고).

짧은 작업엔 Sonnet 5가 유리했어요. 한 번에 안 끝나도 재시도 비용이 가볍고, 세션 한도가 넉넉해서 여러 번 돌려도 한도를 금방 안 채웠거든요. 제 경험상 500줄 이하 코드 수정·간단한 번역·블로그 초안처럼 맥락이 가벼운 작업은 Sonnet 5로 충분했습니다.

대형 작업에서 Fable로 바꾼 계기는 추가 요금이었습니다

Fable로 바꾼 계기는 주간 사용량 경고였어요. 어느 날 다중 파일 구조 개편을 Sonnet 5로 시도했는데, 네 번째 프롬프트에서 잔여 쿼터 알림이 떴습니다. 추가 요금 내고 계속할 수 있었지만, "이 작업 하나에 이렇게 많이 쓰나?" 싶더라고요.

Fable로 동일 작업을 다시 던졌더니 일격에 마무리됐네요. 시간도 5분 정도로 짧았어요. 한 해외 개발자 포럼 사례에 따르면 "Opus 5로 5시간 세션에 추가 요금까지 쓰던 작업을 Fable로 전환하니 추가 요금이 1/10로 줄었다"는 보고가 있었죠. Fable은 주간 여유분이 적지만, 되돌아갈 일이 없는 확률이 높아서 대형 작업엔 오히려 효율적이었어요.

기대와 달랐던 지점은 Fable의 "느린 속도"였어요. 체감상 Sonnet 5보다 응답이 1.5배 느렸는데, 재시도를 안 해서 총 소요 시간은 비슷했습니다. 속도보다 정확도가 중요한 작업—복잡한 아키텍처 설계, 다중 파일 수정, 긴 맥락 유지—에선 Fable이 시간과 한도를 모두 아꼈어요.

실제 비용 역전 시점을 계산해봤습니다

언제 Fable이 더 저렴해지는지 구체적으로 계산해봤어요. 한 작업에 프롬프트를 반복 실행해야 한다면, Sonnet 5의 누적 소비량이 Fable 단일 실행보다 커집니다. 제가 확인한 시점 기준으로 Sonnet 5는 주간 여유분이 충분했지만, 재시도가 겹치면 실질 사용률이 Fable 한 차례의 약 2배였어요.

구체적인 예를 들면 이렇습니다. 간단한 글 작성 작업은 Sonnet 5로 첫 시도에 끝났고, 한도 소비가 5% 수준이었습니다. 같은 유형을 Fable로 처리하면 8% 정도 먹었어요. 단순 비교론 Sonnet 5가 유리하죠.

하지만 코드 구조 정리 작업은 달랐습니다. Sonnet 5로 여러 차례 재시도해서 누적 소비량이 20%에 달했는데, Fable은 첫 시도로 10% 정도만 썼어요. 재시도 비용을 더하니 역전됐습니다. 커뮤니티 보고에서도 "복잡도가 높을수록 Fable이 실질 비용이 낮다"는 패턴이 반복됐어요.

제가 세운 기준은 "두 차례 이상 프롬프트가 필요할 것 같으면 Fable"입니다. 복잡도가 높은 작업일수록 Fable의 한 번 성공 확률이 재시도 비용을 압도했거든요.

두 모델을 병행하는 전략이 최선이었습니다

지금은 두 모델을 병행합니다. 파이프라인 설정에서 작업 복잡도 기준을 넣어뒀어요. 간단한 글 작성·빠른 번역·500줄 이하 수정 같은 경량 작업은 자동으로 Sonnet 5로 라우팅되고, 다중 파일 리팩토링·긴 맥락 유지 작업은 Fable로 갑니다.

이렇게 쓰니 구독 한도 초과 경고가 거의 안 뜨더라고요. 두 달 전엔 Sonnet 5만 쓰다가 주말마다 한도 경고를 봤는데, 지금은 한 달에 한 번 볼까 말까 합니다. 작업 유형별로 모델을 바꾸는 게 번거롭게 느껴질 수 있는데, 자동 라우팅을 설정하니 손이 덜 가요.

구독 한도를 보는 관점도 바뀌었습니다. 전엔 "한도가 넉넉한 모델이 이득"이라고 생각했는데, 지금은 "작업당 한도 소비량"을 먼저 봐요. Sonnet 5는 한도가 넉넉해도 재시도가 많으면 금방 차고, Fable은 한도가 빡빡해도 한 번에 끝내면 여유가 생기거든요. 작업 복잡도가 결정 기준이었습니다.