Claude Code 워크플로우 (1) — gstack + Superpowers 두 플러그인만 남긴 이유

시리즈 로드맵

이 글은 Claude Code 워크플로우 시리즈의 첫 번째입니다.

• (1) gstack + Superpowers — 두 플러그인만 남긴 이유 ← 현재 글
• (2) gstack /office-hours로 제품 인터뷰를 받아봤다 — StudOX 사례
• (3) Boris Cherny "Why Coding Is Solved" 강연 후기 — YC와 loop 워크플로우

도구 소개 → 실제 사용 경험 → 더 큰 맥락(AI 에이전트의 미래)으로 이어지는 구성입니다.

TL;DR

• 플러그인이 많을수록 좋은 게 아니다. 컨텍스트가 비대해져서 오히려 오작동·설정 복잡화로 이어진다.
• gstack은 "회의와 품질 게이트", Superpowers는 "실행과 기록" 역할로 명확히 갈린다. 두 역할이 겹치지 않아서 시너지가 난다.
• 작업 순서는 5단계: /office-hours → 문서화 → brainstorming → writing-plans → git worktrees + sub-agent driven development.
• 핵심은 "바로 만들어줘"를 금지하고 회의부터 시작하는 것. 이거 하나로 결과물 품질이 눈에 띄게 달라진다.

환경

• macOS (M 시리즈)
• Claude Code (글로벌 설치)
• gstack: ~/.claude/skills/gstack/
• superpowers: ~/.claude/skills/superpowers-* (using-superpowers, brainstorming, writing-plans, executing-plans, subagent-driven-development, using-git-worktrees, verification-before-completion, test-driven-development 등)

왜 두 개만 남았나

Claude Code 출시 이후 플러그인을 여러 개 시도해봤는데, 대부분 두 가지 문제가 있었습니다.

1. 기능은 많은데 워크플로우에 안 맞는다. 어떤 단계에서 꺼내 써야 할지 애매해서 결국 안 쓰게 된다.
2. 설치할수록 컨텍스트가 비대해진다. Claude에 주입되는 시스템 프롬프트가 늘어나면서 오히려 오작동하거나 의도와 다른 방향으로 작업이 흘러간다.

기능 개수가 가치를 결정하지 않는다는 걸 체감했습니다. 워크플로우에 녹아드는지가 관건이었고, 결국 두 플러그인의 조합이 가장 자연스럽게 흘러갔습니다.

Claude Code의 초기 실패 패턴

처음엔 "말만 하면 뭐든 만들어줄 줄 알았다"는 생각으로 썼습니다. 결과는 "이게 아닌데"의 반복이었습니다.

이건 마치 인테리어 리모델링에서 사전 협의 없이 착공하는 것과 비슷합니다. 시공자가 알아서 잘해주겠지 하고 맡기면, 완성된 결과물이 머릿속에 그렸던 모습과 한참 다릅니다.

특히 작업이 복잡해질수록 악화됐습니다.

• 생각이 덜 정리된 채 요청 → Claude가 자기 식으로 해석 → 엇나감
• 이쪽 고치면 저쪽 깨짐. 혼자 이삿짐 나르는 느낌
• 집중력이 흐트러지고 실수가 누적

이 패턴을 깨려면 착공 전에 회의를 해야 했습니다. 그게 gstack의 역할입니다.

두 플러그인의 역할 분담

gstack — 회의 & 품질 게이트

명령어	용도
/office-hours	프로젝트 시작 전 아이디어 회의. Claude가 인터뷰하듯 질문을 던져 아이디어를 구체화시킨다. 본인도 미처 정리하지 못했던 부분을 드러내게 만든다.
/design-review	AI 슬롭(과도한 그라데이션·이모지·뻔한 레이아웃 등) 탐지. "AI 티" 줄이고 세련된 결과물을 뽑게 도와준다.

이 둘의 공통점은 "멈추게 만든다"는 점입니다. 시작 전에 멈춰서 정리하게 하고, 끝나기 전에 멈춰서 검증하게 합니다.

Superpowers — 실행 & 기록

기능	용도
Sub-Agent Driven Development	큰 작업을 기획/디자인/개발/QA 팀처럼 작은 에이전트들이 분담해서 진행. 한 명이 다 하는 것보다 결과물 품질이 올라간다.
Git Worktrees	작업 공간 분리. "여러 프로젝트 서류를 같은 책상에 뒤섞지 않고 각자 책상에 분리"하는 개념.
자동 작업 기록	의미 있는 단위마다 자동 커밋/로그. 개발 흐름이 끊기지 않고 히스토리도 추적하기 쉬워진다.
Brainstorming Skill	방향 검토. UX/UI 목업을 빠르게 뽑는 용도로도 강력하다. Figma 없이 실시간 디렉팅이 가능.
Writing Plans Skill	단계별 계획서 작성. 공사 전 설계 도면 역할.

Superpowers는 "회의가 끝난 뒤 실제로 일을 해내는" 부분을 담당합니다. 분업과 기록이 핵심입니다.

실제 작업 순서 — 5단계

두 플러그인을 조합한 작업 순서는 다음과 같습니다.

1. gstack       /office-hours              ← 아이디어 회의 (15~20분)
2. (수동)        대화 내용을 문서로 정리
3. Superpowers  brainstorming skill        ← 놓친 부분 검토
4. Superpowers  writing-plans skill        ← 단계별 계획서 = 설계 도면
5. Superpowers  git worktrees + 
                subagent-driven-development ← 작업 공간 분리 + 팀 단위 실행

1단계 — /office-hours: "같이 생각해볼까"로 시작하기

가장 큰 변화는 "바로 만들어줘"라고 말하지 않는 것입니다. 대신 /office-hours로 시작합니다.

Claude가 PM처럼 질문을 던집니다.

• 누가 이걸 가장 필요로 하는가?
• 지금 이 문제를 어떻게 해결하고 있는가?
• 이미 비슷한 도구가 있는가? 그것과 뭐가 달라지는가?
• 이걸 만들면 어떤 트레이드오프가 생기는가?

이 과정에서 머릿속에서 흐릿했던 부분이 드러납니다. 본인이 아이디어를 얼마나 모호하게 갖고 있었는지 깨닫는 단계이기도 합니다.

이 단계의 자세한 사례는 시리즈 (2)편에서 다룹니다. 실제 프로젝트(StudOX)에서 /office-hours를 돌렸던 인터뷰 정리본을 풀어볼 예정입니다.

2단계 — 문서화

/office-hours 결과를 그냥 흘려보내지 않고 마크다운으로 정리합니다. 머릿속 흐릿한 아이디어를 구체적인 글로 옮기는 과정 자체가 정리 효과가 큽니다.

저장 위치는 01_Projects/<프로젝트>/office-hours-<날짜>.md로 통일했습니다. 나중에 시리즈 (2)편에서 보여드릴 StudOX 인터뷰 정리본도 이 규칙으로 저장돼 있습니다.

3단계 — Brainstorming: 놓친 부분 검토

Office Hours 결과를 들고 Superpowers의 brainstorming skill로 넘어갑니다. 출발 전에 지도를 한 번 더 확인하는 단계입니다.

• 우리가 합의한 전제 중 위험한 게 있는가?
• 놓친 사용자/시나리오가 있는가?
• UI가 필요한 작업이면 여기서 목업까지 뽑아낸다

UI 목업을 실시간으로 디렉팅할 수 있다는 건 이 플러그인의 숨겨진 강점입니다. Figma를 따로 열지 않아도 "버튼 위치 좀 옮겨줘", "이 영역은 카드형으로 바꿔줘" 식의 수정이 채팅으로 됩니다.

4단계 — Writing Plans: 설계 도면 만들기

여기가 변곡점입니다. Claude가 지금까지의 대화를 바탕으로 "1단계: ..., 2단계: ..., 3단계: ..." 형태의 단계별 계획서를 만들어줍니다.

이 계획서가 이후 모든 작업의 기준점이 됩니다. 작업 중간에 방향이 흔들릴 때마다 이 문서를 다시 펴서 "지금 이게 1단계 작업이 맞나?"를 확인합니다.

저장 위치는 01_Projects/<프로젝트>/plan.md로 고정했습니다.

5단계 — Git Worktrees + Sub-Agent Driven Development: 분업과 병렬

마지막은 실행입니다. 두 가지를 동시에 씁니다.

• Git Worktrees: 기능별로 독립된 작업 공간을 만든다. A 기능 작업 중에 B 기능을 건드리지 않게 됨.
• Sub-Agent Driven Development: 한 작업을 기획/디자인/개발/QA 역할의 에이전트로 나눠서 처리. 한 에이전트가 모든 걸 하는 것보다 각자 자기 역할에 집중할 때 품질이 올라간다.

자동 작업 기록 덕분에 의미 있는 단위마다 커밋이 남고, 나중에 히스토리를 따라가기 쉬워집니다.

두 플러그인의 시너지

이 5단계가 자연스럽게 작동하는 이유는 두 플러그인이 역할이 안 겹치기 때문입니다.

• 시작·끝: gstack이 담당 (회의 / 디자인 리뷰)
• 중간 실행: Superpowers가 담당 (계획·분업·기록)

"3단 로켓"처럼 작동합니다. gstack(회의) → Superpowers(계획+실행) → gstack(디자인 리뷰).

다른 플러그인 조합은 대부분 역할이 겹치거나 흐름이 끊겼는데, 이 둘은 자기 영역만 담당하면서 자연스럽게 연결됩니다.

내가 정한 운영 규칙

지난 한 달간 쓰면서 정착시킨 규칙입니다.

• 새 프로젝트는 무조건 /office-hours부터. "바로 만들어줘"는 금지.
• Office Hours 결과는 항상 01_Projects/<프로젝트>/office-hours-<날짜>.md로 저장.
• 계획서는 항상 01_Projects/<프로젝트>/plan.md. 작업 중 방향 잃으면 이걸 다시 본다.
• 기능 단위 작업은 git worktree로 분리해서 병렬 진행.
• /design-review는 UI가 있는 결과물 모든 PR 전에 돌린다.

한계와 남은 의문

• 이 워크플로우는 새 프로젝트나 큰 기능 추가에 잘 맞습니다. 반대로 작은 버그 수정·5분짜리 작업에는 오버헤드가 큽니다. 이런 경우엔 Office Hours를 건너뛰고 바로 작업합니다.
• Superpowers의 sub-agent driven development는 강력하지만 컨텍스트 사용량이 많습니다. 토큰 비용을 의식하지 않고 쓰기엔 부담이 있어서, 작업 단위를 잘 쪼개야 합니다.
• gstack은 비교적 신생 도구라서 한국어 처리에 가끔 문제가 생깁니다. 첫 OSS 기여로 한글 UTF-8 스트리밍 깨짐 PR을 올린 이유이기도 합니다.
• "Claude가 PM 역할을 잘 해주는가"는 결국 모델 성능과 프롬프트 설계에 달려 있습니다. Office Hours가 늘 만족스러운 인터뷰를 뽑아주는 건 아니고, 답변이 얕다 싶으면 본인이 더 압박해야 합니다.

핵심 정리

• 플러그인은 적게 쓰는 게 낫다. 컨텍스트 비대화는 실제 오작동의 원인이 된다.
• gstack은 회의·품질 게이트, Superpowers는 실행·기록. 역할이 겹치지 않아서 시너지가 난다.
• 5단계 워크플로우의 핵심은 "바로 만들어줘" 금지 — 회의(/office-hours)부터 시작.
• 계획서(plan.md)는 작업의 기준점. 방향이 흔들릴 때마다 돌아온다.
• UI 작업은 반드시 /design-review로 마무리. AI 슬롭을 거른다.

참고 자료

• 영감을 받은 영상: Claude Code 플러그인 워크플로우 정리 (YouTube)
• gstack: garrytan/gstack
• Anthropic 공식 Claude Code 문서: docs.claude.com/claude-code
• 관련 노트: [[Claude Code 플러그인 워크플로우 (gstack + Superpowers)]], [[PR-1007 한글 UTF-8 스트리밍 fix]]

다음 글

시리즈 (2)편에서는 이 워크플로우의 1단계인 /office-hours를 실제 프로젝트(StudOX)에서 돌렸던 인터뷰 정리본을 펼쳐볼 예정입니다. AI에게 제품 인터뷰를 받는 게 어떤 경험인지, 어떤 질문이 던져졌고, 결과적으로 무엇이 명확해졌는지 다룹니다.

---