7/7을 기점으로, Fable 5는 「가볍게 던져도 되는 모델」이 아니게 된다.

Anthropic의 공식 발표는 이렇다. 7/1 복구 시점부터 7/7까지, 주간 이용 한도의 최대 50%까지 포함되는 형태로 사용할 수 있다. 7/8부터는 종량제 과금인 usage credits를 경유하게 된다 (시각은 비공개지만, 미국 기준 날짜이므로 일본 시간으로는 7/8 오전 중에는 전환되어 있을 가능성이 높다). 「토큰 단가를 신경 쓰지 않고 던져도 되는 기간」은 오늘(7/6)과 내일(7/7) 이틀간으로 끝난다.

이것은 조용히 가장 무서운 패턴이라고 생각한다. 「아직 괜찮아」라고 생각하는 사이에 한도를 다 써버리고, 정신을 차려보니 내일 밤, 가장 묻고 싶었던 상담을 할 수 없게 되어 있다. 그래서 오늘 안에 Fable 5만이 할 수 있는 일을 전부 끝내고, 일상적인 운용은 다른 모델 + Skills로 재현할 수 있는 형태로 떨어뜨려 놓는다. 이를 위해 실제로 내가 던졌던 프롬프트를 그대로 공개한다.

🛠️ 개발 용도(Web 개발, GitHub 운용, Cursor/Claude Code/MCP, 기술 블로그, 업무 효율화, 자격증 학습)에 맞춰 작성했지만, 변수 부분(용도·목표·프로젝트명)을 바꾸면 누구나 그대로 유용할 수 있다.

다음 프롬프트를 X에서 공유하기 위한 Note 기사를 작성하고 싶다.
7/7 이후, Pro 플랜 구독에서는 Fable 5를 이용할 수 없게 됩니다.
그렇기 때문에, 그때까지 Fable 5로만 실현할 수 있었던 워크플로우나 능력을,
...

이것이 효과적인 이유, 4가지

• 「모델의 강점이 상실된다」라는 전제를 처음에 두기 때문에, 일반론이 아니라 "대체 수단"만을 답변으로 받는다
• 목표를 「Skills로서 남기기」로 고정했기 때문에, 그 자리에서의 제안으로 끝나지 않고 자산화된다
• Web 검색 지시를 넣어두었기 때문에, 지금 이 순간의 커뮤니티 논의도 섞여 들어온다
• 「오늘/내일/최종 확인」으로 시계열을 끊었기 때문에, 막연한 ToDo가 아니라 오늘 밤 바로 움직일 수 있는 계획이 된다

내 케이스(Web 개발, GitHub 운용, X 운용, 기술 블로그, 자격증 학습)로 던져보았더니, 이렇게 돌아왔다. 길기 때문에 구성과 일부만 발췌한다.

Skills는 「폴더 + SKILL.md」라는 구조다. 모델이 바뀌어도 (Sonnet 5라도 Opus 4.8이라도) 그대로 옮길 수 있는 자산이 된다. Fable 5가 가진 「장기 기억·대규모 문맥 이해」라는 강점, 그것을 Skills라는 형태로 외부화해 두는 것이 이번의 핵심이다.

이하, 내 용도에 직결되는 것을 우선순위 순으로 소개한다 (실제로 돌아온 답변의 요약입니다).

① WebRTC 디버깅·구현 Skill

만들 가치: WebRTC 특유의 함정(ICE 후보 처리, SDP 네고시에이션, TURN/STUN 설정 실수, Safari/Chrome 구현 차이 등)은 범용 모델의 경우 매번 똑같은 설명을 처음부터 다시 시키기 쉽다. 이것을 한 번 체계화해 두면 Fable 5가 아니더라도 재현성 높은 지원을 받을 수 있다. -
활용 시나리오: 접속 불안정 원인 분류, SDP/ICE 로그 읽는 법, getUserMedia 주변의 브라우저 차이 대응, 신규 구현 시의 아키텍처 상담. -
구체적인 Skill 설계:-
SKILL.md에 WebRTC의 접속 확립 플로우(Signaling→ICE→DTLS→SRTP)를 체크리스트화 -
자주 발생하는 에러 패턴 모음(ICE connection failed, m-line 순서 불일치 등)과 분류 절차를 reference/common-errors.md로 분리 -
과거에 내가 빠졌던 함정을 gotchas.md로 추가해 나가는 운용을 한다 (Fable 5에게 「이번 프로젝트에서 배운 함정을 요약해 줘」라고 부탁하여 씨앗을 만드는 것이 효율적)

② 기술 블로그 집필 Skill

만들 가치: 구성·톤·독자층(일본 IT 엔지니어)을 고정한 집필 보조를 매번 처음부터 설명하지 않아도 된다. -
활용 시나리오: WebRTC 기술 해설, 개인 개발 개발기, AI 활용 노하우 기사. -
구체적인 Skill 설계:- 도입·과제 제시·구현·배움의 4부 구성 템플릿

• 코드 블록의 언어 표기 규칙, 헤딩 계층 스타일 가이드
• 「결론부터 쓰기」, 「전문 용어는 처음 등장할 때 한마디 보충」 등의 문체 규칙

③ README/문서 생성 Skill

만드는 가치: 여러 서비스에 걸친 GitHub 운영에서는 README/문서의 노후화가 일어나기 쉽다. 생성 규칙을 고정해 두면 업데이트 비용이 낮아진다. -
활용 시나리오: 신기능 추가 시 README 업데이트, DB/API 스키마 변경 시 문서 반영. -
구체적인 Skill 설계:

• 자신의 프로젝트 특유의 구성(DB 테이블 정의, CI/CD 플로우)을 템플릿의 초안으로 포함
• Mermaid 표기법을 이용한 아키텍처 도표 생성 규칙을 포함

④ 코드 리뷰 Skill (GitHub Actions/Supabase/Next.js 특화)

만드는 가치: 자신의 프로젝트 고유의 설계 원칙(외부 통신 분리 방침, DB 접근 권한 최소화 방침 등)을 리뷰 기준으로 고정할 수 있다. -
활용 시나리오: PR 리뷰, Claude Code / 에이전트가 생성한 코드의 검증. -
구체적인 Skill 설계:

• 체크 항목: 외부 API 통신을 허가된 경로로만 수행하고 있는가 / DB 접속 권한이 과도하지 않은가 / 타입 (Type) 처리가 안전한가
• 과거에 사고가 났던 변경 패턴(설정 테이블의 예상치 못한 다중 행화 등)을 재발 방지 체크 항목으로 명시

⑤ 설계 리뷰 · 기술 판단 Skill

만드는 가치: Fable 5의 강점인 「장기 문맥에서의 일관된 설계 판단」을 판단 기준의 언어화를 통해 부분적으로 대체. -
활용 시나리오: 신기능의 기술 선정, 아키텍처 의사 결정 (구성 A vs 구성 B의 트레이드오프 (Trade-off) 정리 등). -
구체적인 Skill 설계:

• 과거의 판단 로그(왜 그 구성을 선택했는지, 왜 특정 접근 방식을 피했는지)를 decisions.md로 축적 - 새로운 판단을 할 때마다 이 파일을 참조하게 하여 일관성을 담보

• 과거의 판단 로그(왜 그 구성을 선택했는지, 왜 특정 접근 방식을 피했는지)를

⑥ 기본 정보 기술자 시험 학습 지원 Skill

만드는 가치: 출제 범위 · 빈출 분야 · 자신의 약점 분야를 고정해 두면, 모델이 바뀌어도 동일한 정밀도로 문제 연습 및 해설을 받을 수 있다. -
활용 시나리오: 출퇴근 시간 등의 자투리 학습, 기출문제 해설 요청. -
구체적인 Skill 설계:

• 출제 분야(테크놀로지 계열 / 매니지먼트 계열 / 스트래티지 계열)별 이해도 메모
• 틀린 문제의 로그를 weak-points.md에 축적하여 복습 우선순위를 자동 판정

⑦ 업무 일보 · 작업 로그 생성 Skill

만드는 가치: 개인 개발의 진척도를 되돌아보기 쉽게 만들며, 기술 블로그의 소재가 된다. -
활용 시나리오: Claude Code / 에이전트의 실행 결과에 기반한 일일 요약 생성. -
구체적인 Skill 설계:

• GitHub의 커밋 로그 · PR로부터 자동으로 「오늘 한 일」을 추출하는 포맷
• 블로그 소재 후보에 플래그를 세우는 항목을 추가

Skills로 완전히 대체할 수 없는, 모델 자체의 기본 역량에 의존하는 작업은 지금 미리 해 두자.

메인 프로젝트의 전체 아키텍처 분석 + 개선 제안: 리포지토리 전체를 Fable 5에 읽히고, 기존 구현 방침의 개정안이나 다음에 만들고 싶은 기능의 설계 골자를 작성하게 한다. 장기 문맥과 자기 검증 능력이 효과적인 태스크입니다. -
상기 ①~⑦ Skill의 초안 일괄 생성: Fable 5는 「지금까지의 대화 · 프로젝트의 축적으로부터 요점을 추출하는」 작업에 강점이 있기 때문에, 각 Skill의 초안을 한꺼번에 만들게 하는 데 적합합니다. -
중장기 운영 플레이북의 정밀도 검증: 자신이 세운 목표 달성까지의 주간 마일스톤이나 판단 기준을, 장기 플래닝 능력이 높은 Fable 5에게 한 번 리뷰시켜 둔다. -
장래 구현 예정인 기능의 설계서 작성: 「나중에 구현하자」며 미뤄두고 있는 기능에 대해, 지금 상세 설계서를 만들어 두면 구현 단계에서는 저렴한 모델에 맡길 수 있다. -
decisions.md · gotchas.md의 초기 구축: 지금까지의 대화 이력을 되돌아보게 하여, 「왜 그 설계로 했는지」를 언어화 · 파일화하는 정리 작업. 이것은 지금밖에 할 수 없는 「기억의 외부화」 그 자체입니다.

웹 검색으로 수집한 최신 논의를 종합하면, 커뮤니티의 결론은 거의 일치한다.

• 모델의 역할 분담이 정착되는 추세: Sonnet 5가 구현·조사의 1차 대응, Opus 4.8이 리뷰·검증, Fable 5는 「장기 플래닝이나 고난도 이행 작업」에만 집중해서 사용하는 3층 구조의 운용이 주류가 되고 있습니다. 일상적인 태스크에 Fable 5를 사용하는 것은 「토큰의 낭비」라는 지적이 눈에 띕니다. -
  Skills는 「작게 시작해서 키우는 것」이 철칙: Anthropic의 공식 가이드라인 및 실무자들의 기사 모두에서, 처음부터 완벽한 Skill을 만들려 하지 말고 몇 줄의 메모와 하나의 실패 패턴에서 시작하여, 사용할 때마다 추가해 나가는 접근 방식이 권장되고 있습니다. -
  SKILL.md의 description은 「트리거 문장」으로 작성: 「이 Skill은 〇〇을 한다」가 아니라 「〇〇할 때 이 Skill을 사용한다」는 방식으로 작성함으로써 자동 발화(Triggering)의 정밀도를 높일 수 있다고 합니다. -
  CLAUDE.md／SKILL.md의 이층 구조: 프로젝트 전체의 규칙은 CLAUDE.md에, 특정 태스크의 절차는 Skills에 분리하는 구성이 컨텍스트(Context) 소비를 억제하면서 정밀도를 유지하는 베스트 프랙티스(Best Practice)로 소개되고 있습니다. -
  usage credits 고갈에 대비: 7/7 이후의 고비용화에 대비하여, 캐시 이용(프롬프트 캐시로 최대 90% 할인)이나 Batch API 활용을 통해 비용을 절감하는 방안이 여러 기사를 통해 공유되었습니다.

나의 이용 상황(웹 개발, X 운영, 기술 블로그, 자격증 학습)을 고려했을 때, 「지금 반드시 해두어야 할 일」은 다음과 같은 순서로 정리되었다.

#	할 일	이유·기대 효과
1	Fable 5로 메인 프로젝트 전체의 아키텍처 리뷰를 실시	기존 구현 방침의 개수나 신기능 설계를 지금 미리 진행
...

Fable 5가 Pro 플랜 내에서 실질적으로 무료 범위를 사용할 수 있는 것은 7/7까지이다. 남은 시간은 솔직히 이제 그리 많지 않다.

• Fable 5에 메인 리포지토리(Repository) 전체를 읽히고, 아키텍처 리뷰 + 개수안을 도출하게 한다

• 과거의 대화 이력(설계 판단, 본업 영역의 시행착오 포인트, X 게시물의 성공 패턴)을 정리하여 decisions.md / gotchas.md의 초안을 작성한다

• 우선순위 「최고」인 2개의 Skill(본업 디버깅 / 기술 블로그 집필)의 SKILL.md 초안을 Fable 5에게 생성시킨다

• 향후 구현 예정인 기능의 상세 설계서 드래프트를 작성한다

• 남은 Skill(README 생성 / 코드 리뷰 / 설계 리뷰 / 자격증 학습 / 업무 일보)을 완성한다

• 중장기 운용 플레이북(Playbook)을 Fable 5에게 최종 리뷰하게 하여 마일스톤(Milestone)의 정밀도를 검증한다

• 각 Skill을 Sonnet 5 / Opus 4.8로 시운전하며, 「Fable 5와 비교했을 때 무엇이 떨어지는가」를 그 자리에서 메모 → Skill에 추가한다 (이날 안에 하지 않으면 비교가 어려워진다)

• 주간 이용 한도 잔량을 대시보드에서 확인하고, 한도 내에 들어오도록 작업 우선순위를 조정한다

• 작성한 모든 Skill이 .claude/skills/ 또는 해당 디렉토리에 배치되어, Claude Code에서 발화되는 것을 확인한다

• decisions.md · gotchas.md가 리포지토리에 커밋(Commit)되어 있는지 확인한다

• 7/8 이후의 운용 규칙(Sonnet 5 = 구현, Opus 4.8 = 리뷰, Fable 5 = usage credits를 소모해서라도 써야 하는 고난도 작업만)을 스스로 명문화해 둔다

Fable 5가 없어지는 것은 아니다. 「가볍게 던질 수 없게 될」 뿐이다. 그렇기에 오늘과 내일, Skills라는 형태로 지식을 외부화해 둔다면, 모델이 무엇이든 관계없이 동일한 질의 아웃풋(Output)을 재현할 수 있다. 남은 시간, 후회 없는 사용을 하길 바란다.⚡