Claude Fable 5가 잠깐 풀렸을 때, 바이브코딩에 어디까지 붙이면 좋을까

Claude 쪽에서 Fable 5 접근 기간을 늘렸다. 공식 도움말 기준으로 유료 플랜 사용자는 2026년 7월 12일 23:59:59 PT까지 Fable 5를 기존 구독 한도 안에서 쓸 수 있다. 무료 플랜 얘기는 아니고, Pro·Max·Team·일부 Enterprise Premium seat 쪽 이야기다.
바이브코딩하는 입장에서는 “오, 그럼 며칠 동안 제일 센 모델로 다 밀면 되나?”가 먼저 떠오른다. 답은 반쯤만 그렇다. Fable 5는 주간 사용 한도의 최대 50%까지만 프로모션 범위로 쓸 수 있고, 그 한도를 넘기면 사용 크레딧으로 넘어가거나 다른 Claude 모델로 바꿔야 한다. 게다가 Fable 5는 같은 대화라도 한도를 더 빨리 태운다고 안내돼 있다.
그러니까 이번 기간은 아무 작업이나 Fable 5로 돌리는 시간이 아니라, 평소 모델이 자주 꼬였던 작업을 몰아서 처리하는 짧은 창구에 가깝다.

Fable 5를 붙일 만한 작업

바이브코딩에서 제일 비싼 순간은 코드를 치는 시간이 아니다. “이 프로젝트가 왜 이렇게 꼬였는지”를 처음 해부하는 시간이다.
예를 들어 이런 작업은 Fable 5를 붙일 만하다.

• 이미 돌아가는 앱인데 구조가 지저분해서 새 기능을 넣을 때마다 다른 곳이 깨지는 경우
• 에러 메시지는 하나인데 실제 원인은 여러 파일에 퍼져 있는 경우
• PRD 없이 만든 MVP를 다시 제품 흐름으로 정리해야 하는 경우
• Next.js, Supabase, Tistory 자동화, 크론, 브라우저 자동화처럼 상태가 여러 층에 걸친 경우
• “이거 그냥 고쳐줘”가 아니라 “뭘 먼저 버리고 뭘 살려야 할지” 판단해야 하는 경우

이런 일은 작은 모델도 할 수는 있다. 그런데 작은 모델은 대개 바로 파일을 고치려고 달려든다. 그러다 증상 하나를 막고, 원래 흐름은 더 망가뜨린다. Fable 5 같은 상위 모델을 쓴다면 첫 요청을 수리공처럼 던지지 말고, 편집자나 시니어 개발자처럼 쓰는 편이 낫다.
좋은 첫 프롬프트는 이런 식이다.

이 프로젝트를 바로 고치지 말고 먼저 구조를 읽어줘.

사용자가 실제로 하는 행동 순서, 데이터가 지나가는 경로, 깨질 가능성이 큰 지점을 나눠서 봐줘.

수정은 마지막에 최소 단위로 제안해줘.

이렇게 시작하면 모델이 “코드 한 줄 고치기”보다 “작업 순서 만들기”에 먼저 붙는다. 바이브코딩에서 이 차이가 크다.

반대로 Fable 5를 쓰기 아까운 작업

한도가 50%로 잘려 있으니, 잡일에 쓰면 손해다.
아래 작업은 굳이 Fable 5가 아니어도 된다.

• 변수명 정리
• 단순 CSS 여백 수정
• README 문장 다듬기
• 이미 원인이 뻔한 타입 에러 수정
• 블로그 글의 태그 후보 뽑기
• 간단한 JSON 변환
• 한 파일 안에서 끝나는 작은 리팩터링

이런 작업은 다른 Claude 모델이나 로컬 에이전트, Codex 계열 도구에 넘겨도 충분하다. Fable 5 한도는 “판단이 필요한 초반 30분”에 쓰는 편이 좋다. 실제 구현은 더 싼 모델로 이어받게 하면 된다.
내 기준으로는 이렇게 나누는 게 편하다.
| 단계 | 추천 모델 사용 방식 |
|---|---|
| 처음 구조 파악 | Fable 5 |
| 작업 순서 쪼개기 | Fable 5 또는 상위 모델 |
| 단순 구현 | 일반 모델 또는 코딩 에이전트 |
| 테스트 실패 반복 수정 | 상황에 따라 상위 모델 한 번 투입 |
| 문서/블로그화 | 일반 모델 + 사람이 톤 정리 |
Fable 5를 계속 붙잡고 있는 것보다, 첫 설계를 잘 뽑고 다른 모델로 넘기는 쪽이 한도 관리에 맞다.

바이브코딩 프롬프트를 바꾸는 게 먼저다

상위 모델이 풀렸을 때 흔히 하는 실수가 있다. 평소와 똑같이 “이거 만들어줘”라고 던지고, 결과만 더 좋아지길 기대하는 것이다.
Fable 5를 쓸 때는 프롬프트를 조금 더 역할 중심으로 바꾸는 게 낫다.
나쁜 요청은 이렇다.

이 앱 SEO 최적화해줘.

이러면 모델은 title, meta description, sitemap 같은 흔한 목록을 뱉는다. 이미 아는 얘기다.
조금 나은 요청은 이렇다.

이 블로그 운영 시스템에서 지금 SEO 손실이 실제로 생길 만한 지점을 우선순위로 나눠줘.

라이브 페이지에서 바로 확인 가능한 문제, 플랫폼 로그인이나 인증이 필요한 문제, 글 품질 문제를 분리해줘.

자동으로 고칠 수 있는 것부터 실행 계획을 만들어줘.

이렇게 말하면 모델이 “SEO 체크리스트”가 아니라 “작업 라우팅”을 한다.
바이브코딩은 손으로 코드를 덜 치는 방식이지, 판단을 안 하는 방식이 아니다. 상위 모델을 쓰는 이유도 여기에 있다. 기능을 많이 뽑는 것보다, 어디를 건드리면 안 되는지 먼저 아는 데 가치가 있다.

50% 제한은 오히려 운영 방식에 맞다

처음엔 50% 제한이 애매해 보인다. 그런데 실제 작업에서는 나쁘지 않다.
한 프로젝트를 끝까지 한 모델로 밀면 대화가 길어진다. 컨텍스트가 불어나고, 모델은 앞에서 했던 임시 판단을 계속 끌고 간다. 중간부터는 똑똑한 모델도 관성으로 움직인다.
차라리 Fable 5를 이렇게 짧게 쓰는 편이 낫다.
1. 프로젝트 상태를 읽힌다.
2. 위험한 파일과 안전한 파일을 나누게 한다.
3. 3~5개 작업 단위로 쪼개게 한다.
4. 첫 번째 작업만 직접 검토하게 한다.
5. 나머지는 다른 모델이나 코딩 에이전트에게 넘긴다.
6. 테스트 실패가 쌓이면 다시 Fable 5에게 원인 분류만 맡긴다.
이 흐름이면 Fable 5는 계속 코드를 쓰는 작업자가 아니라, 중간중간 방향을 잡는 리뷰어가 된다. 사용 한도도 덜 타고, 결과도 덜 산만해진다.

Claude Code에서 쓸 때 봐야 할 것

공식 도움말에는 Claude Code에서 Fable 5를 쓰려면 2.1.170 이상이 필요하다고 적혀 있다. 회사나 팀 계정에서는 관리자가 모델 접근을 제한했을 수도 있다. 모델 선택지에 안 보이면 내 계정 문제가 아니라 조직 설정일 수 있다.
또 하나 중요한 점은 API다. 이번 프로모션은 Claude 웹, 데스크톱, 모바일, Claude Code 같은 구독 사용 범위의 이야기다. API 사용은 별도 과금이라고 안내돼 있다. 서버 자동화나 대량 생성 파이프라인에 “공짜로 풀렸다”고 붙이면 계산이 달라질 수 있다.
바이브코딩 툴 안에서 Claude API를 직접 물고 있다면, 이번 유료 플랜 프로모션과 같은 조건인지 먼저 봐야 한다. 웹에서 Fable 5가 보인다고 해서 내가 만든 자동화 스크립트의 API 비용까지 같이 풀리는 건 아니다.

지금 해볼 만한 작업 예시

며칠짜리 접근 기간이라면 이런 작업을 하나 골라서 하는 게 좋다.

• 방치된 사이드프로젝트 구조 감사
• 로그인/결제/발행처럼 실수하면 손해가 큰 플로우 점검
• 오래된 자동화 스크립트에서 삭제할 부분 찾기
• 블로그 글 생성 파이프라인의 품질 게이트 재설계
• 기존 MVP를 “사용자가 실제로 돈 낼 흐름”으로 다시 정리
• 테스트가 없는 프로젝트에 최소 회귀 테스트 계획 만들기

중요한 건 작업을 크게 던지지 않는 것이다. “전체 앱 개선”보다 “사용자가 첫 화면에서 결과를 얻기까지의 경로만 점검”이 낫다. “코드 다 고쳐줘”보다 “수정 전 위험도를 먼저 분류”가 낫다.
Fable 5가 며칠 더 열린 건 반가운 일이다. 하지만 바이브코딩에서 진짜 이득은 모델 이름보다 사용 순서에서 나온다. 제일 좋은 모델을 제일 귀찮은 반복 작업에 쓰지 말고, 방향을 잘못 잡으면 며칠 날아가는 지점에 붙이는 편이 낫다.
공식 안내: Claude Fable 5 promotional access