시리즈의 마지막 편입니다. Claude Code 의 /model·opusplan·서브에이전트 모델 고정·effort, Codex 의 /model·config.toml 프로파일·plan_mode_reasoning_effort·서브에이전트 모델 같은 실제 전환 수단을 정리하고, 언제 한 칸 올리고 내릴지의 에스컬레이션 규칙, 구독 한도를 일주일 단위로 배분하는 법, 팀 단위 거버넌스, 그리고 한 장짜리 암기표로 마무리합니다.

사다리의 아래쪽을 다룹니다. Opus 5 와 GPT-5.6 Sol 이 2026년 여름 이후 구현 단계의 기본값이 된 가격 구조, Sonnet 5 와 Terra 가 충분해지는 조건, Haiku 4.5 와 Luna 가 맡는 읽기·테스트·문서·커밋 같은 일, 낮은 티어에 effort 를 올려 쓰는 요령과 그 반론, 그리고 아래 티어의 실패 모드(코너 커팅, 컨텍스트 한계, 서브에이전트 지원 여부)를 막는 방법을 정리합니다.

Claude Fable 5.1 과 GPT-6 Astra 같은 고가 티어를 써야 하는 네 자리(계획·설계, 모호한 문제와 난제 디버깅, 위험한 변경의 리뷰, 장시간 자율 작업)와 쓰면 안 되는 자리를 공식 문서·실측·커뮤니티 증언으로 가립니다. 고가 모델을 상시 실행자가 아니라 “부르는” Advisor 패턴의 실측 수치, 주간 한도 50% 규칙, Astra 를 medium 에서 시작하라는 실사용 조언까지 다룹니다.

바이브 코딩 세션을 탐색·계획·구현·디버깅·리뷰·정리의 여섯 단계로 나누고, 단계마다 토큰이 소비되는 모양과 실수의 대가가 어떻게 다른지 살핍니다. 그 위에 Anthropic·OpenAI 공식 문서, 테크블로거, Hacker News·X 실사용자가 각 단계에 권하는 티어를 한 표로 모으고, “항상 최고” 와 “공격적으로 낮춰라” 두 진영이 어디서 갈리는지 정리합니다.

Claude Code 의 Fable·Opus·Sonnet, Codex 의 Astra·Sol·Terra 세 티어를 작업 단계에 따라 바꿔 쓰는 전략을 다루는 5부작의 첫 편입니다. 2026년 9월 기준 공식 가격표를 검증하고, “토큰 단가” 와 “작업당 비용” 이 왜 다른지, effort 와 프롬프트 캐시가 모델 티어보다 큰 비용 레버인 이유를 Anthropic·OpenAI 공식 문서와 실측 자료로 정리합니다.

시리즈 마지막입니다. 두 저자는 README 에서 같은 논점에 정반대로 답합니다. 한쪽은 프로세스 소유를 기능이라 부르고 다른 쪽은 결함이라 부릅니다. 외부에서 제기된 의식 비용 비판과 이 블로그의 기존 4부작이 같은 지점을 짚었다는 사실까지 정리하고, 언제 무엇을 쓸지 판단 기준을 제시합니다.

두 스킬셋은 TDD 에서 같은 말을 하지 않습니다. superpowers 는 리팩터링을 루프 3단계로 넣고 테스트 없이 쓴 코드를 삭제하라고 명령하며, mattpocock 은 리팩터링이 루프의 일부가 아니라고 못박고 테스트 지점을 사전 합의하라고 요구합니다. 구현·리뷰·디버깅·검증 단계를 원문으로 대조했습니다.

코드를 쓰기 전 생각을 정리하는 단계를 정면 비교합니다. superpowers 의 brainstorming 은 한 번에 한 질문씩 묻고 설계 문서를 커밋하며, mattpocock 은 같은 자리에 문을 세 개 두고 프론티어 단위로 묻고 아무것도 남기지 않습니다. 그리고 superpowers 에는 prototype 이 없습니다.

두 스킬셋의 가장 큰 차이는 스킬 내용이 아니라 발동 방식입니다. superpowers 는 SessionStart 훅으로 진입점 스킬 전문을 매 세션 강제 주입하고, mattpocock 은 훅이 0개에 25개 중 14개가 수동 전용입니다. 훅 스크립트를 해부하고 상시 토큰 비용을 실측했습니다.

코딩 에이전트 스킬셋 양대 산맥을 5부작으로 비교합니다. 1편은 지형도입니다. 두 저장소를 실제로 설치해 재 보니 총 분량이 2,949줄과 2,945줄로 거의 같았고, 차이는 크기가 아니라 배치였습니다. 단계별 대응표와 양쪽이 비워 둔 자리를 정리합니다.

신규 서비스 git repo 를 만들 때 어떤 spec 문서들을 어떤 분량으로 두어야 할지, 2026년 5월 기준 de-facto 가 된 AGENTS.md 통합 표준을 중심으로 정리합니다. CLAUDE.md / GEMINI.md / DESIGN.md / DEVELOPMENT.md / ADR / SPEC 등 각 문서의 역할 범위와 공통 best practices, 흔한 안티패턴까지 다룹니다.

Superpowers 의 스킬들은 대부분 자동 트리거되지만, 의도적으로 명시 호출(/superpowers:xxx)해야 더 잘 작동하는 케이스도 있습니다. 4편에서는 두 모드의 비교, 트러블슈팅, CLAUDE.md 로 동작을 조절하는 방법, Java/Go 백엔드 개발 현장의 실용 팁과 한계를 정리합니다.

Superpowers 의 가장 강력한 부분은 “규율을 강제하는” 품질 보증 스킬들입니다. 3편에서는 TDD Iron Law, 4단계 systematic debugging, verification-before-completion, code review 흐름을 Java 프로덕션 버그 시나리오와 함께 분석합니다.

Superpowers 의 핵심은 “기능을 만들자"는 한 마디로 시작되는 자동 워크플로우입니다. 2편에서는 brainstorming → writing-plans → subagent-driven-development 의 흐름을 Go 백엔드 API 추가 시나리오와 함께 따라가 봅니다.

Claude Code, Codex 등 코딩 에이전트에 “바로 쓸 수 있는 개발 방법론"을 주입하는 Superpowers 플러그인. 1편에서는 무엇이고 왜 만들어졌는지, 어떻게 자동 트리거되는지, 그리고 어떤 환경에 어떻게 설치하는지를 정리합니다.

“코드를 읽지 않는 시대, 엔지니어는 무엇을 읽어야 하는가"에서 다룬 핵심 개념들을 심화하여, 엔터프라이즈급 소프트웨어를 다루는 시니어 엔지니어 관점에서 구체적 액션 플랜을 정리합니다.

Claude Code를 하루 종일 사용하다 보면 어느 순간 “Compacting our conversation…” 메시지와 함께 작업 흐름이 끊기는 경험을 하게 됩니다. 이 글에서는 Compaction이 무엇인지, 왜 자주 발생하는지, 그리고 어떻게 줄일 수 있는지 실전 전략을 공유합니다.

Hooks를 통한 강제 자동화, Subagents 활용 패턴, MCP 통합, 실전 레이어링 아키텍처, 팀 협업 워크플로우, 문제 해결 방법을 다룹니다.

Plugin 구조와 plugin.json 작성법, Marketplace 구축 및 GitHub 배포, 팀/조직을 위한 Custom Marketplace 운영 방법을 다룹니다.

Claude Code의 Plugin, Command, Subagent, Hook 개념 비교와 Marketplace 활용법, 커뮤니티 플러그인과 나만의 규칙을 조합하는 3-Layer Stacking 전략을 다룹니다.