클로드 코드 플러그인을 이것저것 붙여 봤지만 오히려 결과가 더 흔들렸고, 결국 남은 건 GStack과 Superpowers 두 개뿐이었다는 사용 후기다. 메이커 에반은 이 두 조합이 왜 실제 작업 흐름에 잘 맞는지, 아이디어 정리부터 계획서 작성, 작업 공간 분리, 자동 기록, 서브에이전트 개발까지 본인이 쓰는 순서 그대로 보여준다.

flowchart LR
A[클로드 코드 결과가 자꾸 어긋남] --> B[GStack으로 방향 정리와 디자인 리뷰]
B --> C[Superpowers로 계획서·공간 분리·팀 작업]
C --> D[흔들리지 않는 개발 흐름 완성]

핵심 요약

  • 여러 플러그인을 써 봤지만 대부분 기능만 많고 실제 작업 흐름과 맞지 않았고, 지금은 GStack과 Superpowers 두 개만 남겼다고 말한다
  • GStack의 핵심은 Office HoursDesign Review다. 만들기 전에 아이디어를 인터뷰하듯 정리하고, 결과물에서 과한 그라데이션·이모지 같은 AI 슬롭을 잡아낸다
  • Superpowers의 핵심은 서브에이전트 기반 개발, Git Worktrees, 자동 기록, Brainstorming, Writing Plans
  • 실제 순서는 오피스하워즈 → 문서화 → 브레인스토밍 → 라이팅 플랜즈 → 리뷰 에이전트 → 워크트리즈 → 서브에이전트 개발 순서로 굴린다
  • 이 조합의 장점은 기능 수보다 흐름이다. 억지로 플러그인을 쓰는 느낌이 아니라, 방향 정리와 계획, 구현이 하나의 선처럼 이어진다고 설명한다

왜 지금 중요한가

클로드 코드를 처음 쓸 때는 뭐든 바로 만들어 줄 것 같지만, 실제로는 생각 정리가 덜 된 채로 시작해서 결과물이 엇나가는 경우가 많다. 영상은 이 문제를 “더 많은 기능”으로 해결하지 않고, 시작 전에 방향을 정리하고 중간에 계획을 세우고 작업 공간을 나누는 방식으로 푼다. 개발자나 PM 입장에서는 바로 구현보다 먼저 흐름을 잡는 게 왜 중요한지 꽤 현실적으로 와닿는 내용이다.

주요 내용

클로드 코드가 어긋나는 이유는 보통 시작이 너무 빠르기 때문이다

에반은 클로드 코드를 처음 쓸 때는 “세상 바뀌겠다” 싶었지만, 시간이 지나면서 분명 원하는 걸 말했는데 결과가 자꾸 어긋나는 상황이 반복됐다고 말한다. 인테리어 업체에 리모델링을 맡겼는데 내가 원한 스타일과 다르게 나오는 비유를 든 것도 그래서다. 처음부터 충분히 얘기를 안 나눴기 때문에, 클로드가 자기 식으로 해석해 버린다는 것이다.

복잡한 작업일수록 이 문제가 더 커진다. 여러 군데를 동시에 고치는 일에서는 한쪽 고치다 다른 쪽이 망가지고, 다시 다른 쪽 고치다 처음 고친 곳이 흔들린다. 에반은 이걸 방 A와 방 B를 오가며 물건을 옮기다가 정신없이 꼬이는 상황에 비유한다.

GStack은 만들기 전에 방향을 잡고, 만들고 나서는 슬롭을 걷어낸다

GStack에서 먼저 소개한 기능은 Office Hours다. 이름 그대로 상담 시간이다. 바로 “만들어 줘”라고 하지 않고, 먼저 클로드와 아이디어 회의를 한다. 왜 하고 싶은지, 주로 어떤 상황에서 쓸 건지, 비슷한 걸 써 본 적 있는지 질문을 받다 보면 내가 원하는 게 생각보다 불명확했다는 걸 알게 되는 경우가 많다고 말한다. 이 과정을 거치면 아이디어가 훨씬 구체화된다.

두 번째는 Design Review다. 이건 만들어진 결과물을 다시 보면서 AI 슬롭을 잡아내는 역할이다. 영상에서 직접 언급한 예시는 과도한 그라데이션과 과도한 이모지다. 즉, “바이브 코딩 냄새”를 빼 주는 단계라고 보면 된다.

Superpowers는 큰 작업을 팀처럼 나누고, 기록과 공간까지 관리해 준다

Superpowers에서 에반이 특히 강조한 건 Subagent Driven Development다. 큰 작업을 하나의 컨텍스트에서 몰아서 처리하는 대신, 작은 클로드들이 각자 자기 파트에 집중하게 만드는 방식이다. 회사에서 기획팀·디자인팀·개발팀·QA팀을 나누는 것과 비슷한 비유를 쓴 이유도 여기에 있다. 큰 일을 한 명이 다 떠안는 대신, 작업을 나눠 품질을 올리는 구조다.

여기에 Git Worktrees가 붙으면 각 작업을 독립 공간에서 돌릴 수 있다. 책상 하나에 프로젝트 A 서류와 프로젝트 B 서류를 섞어 두는 대신, 책상 A에는 A만, 책상 B에는 B만 두는 식이다. 덕분에 한 프로젝트를 만지다가 다른 프로젝트를 망치는 일이 줄어든다.

에반이 더 좋아한다고 말한 기능은 자동 기록이다. 의미 있는 작업 단위마다 클로드가 알아서 기록을 남기기 때문에, 나중에 “이 부분 언제 바뀌었지?”를 바로 추적할 수 있다. 개발 흐름이 끊기지 않는다는 점을 큰 차이로 본다.

실제 실행 순서는 Office Hours → 문서화 → Brainstorming → Writing Plans → Worktrees → Subagents다

에반이 실제로 쓰는 순서는 꽤 구체적이다. 새 프로젝트나 기능을 시작할 때 바로 구현하지 않고 먼저 Office Hours를 실행한다. 10~20분 정도 성실하게 질문에 답하면서 방향을 정리한다. 그다음 내용을 문서로 남기고, Superpowers의 Brainstorming 스킬로 빠진 부분이 없는지 다시 확인한다.

그 뒤에 Writing Plans를 실행한다. 에반은 이걸 공사 전에 설계 도면을 그리는 일에 비유한다. 클로드가 단계별 계획서를 만들어 주고, 작업 중간에 막히면 이 문서를 기준점으로 다시 방향을 맞춘다. 여기서 끝내지 않고, 나온 플랜에 대해 리뷰 에이전트로 한 번 더 검토하면서 이중 검증을 한다.

마지막으로 Git Worktrees로 공간을 나누고, Subagent Driven Development로 실제 개발을 진행한다. 영상 후반에서는 Brainstorming 스킬의 큰 장점으로 UX/UI 쪽 모업 화면을 뽑아주는 점도 짚는다. 피그마로 디자인을 먼저 잡던 흐름이 줄어들고, 바이브 코딩 상태에서 바로 모업을 뽑아 실시간으로 “이 디자인으로”, “이 컬러로”라고 디렉팅하는 쪽이 더 빠르고 성과도 좋다고 본다.

원문 발화 하이라이트

“클로드코드 플러그인 거의 다 지웠어요. 여러 개 써 봤는데 다 별로였거든요. 근데 딱 두 개만 남겼더니 오히려 지금이 제일 잘 써지고 있어요.”

“생각 정리가 덜된 채로 바로 만들어 줘 하면 클로드 나름대로 해석해서 만들어 버리거든요.”

“오피스하워즈를 한 번 거치고 나면 아이디어가 훨씬 구체화돼요.”

“라이팅 플랜즈를 한마디로 설명하면요. 공사 전에 설계 도면 그리는 거예요.”

“결국 이 두 플러그인이 좋은 이유는 기능이 많아서가 아니에요. 서로 자연스럽게 연결되고 쓰다 보면 유저의 입맛에 맞게 사용할 수가 있어요.”

바로 실행해 보기

  1. 새 작업을 시작할 때 바로 구현하지 말고 Office Hours부터 연다 — 클로드 코드에서 먼저 오피스하워즈를 실행하고 10~20분 정도 질문에 답하면서 목적, 사용 상황, 원하는 방향을 구체화한다
  2. 문서화 후 Writing Plans까지 연결한다 — 대화 내용을 기반으로 무엇을 만들지, 왜 만드는지, 어떻게 구성할지를 문서로 남기고 라이팅 플랜즈로 단계별 계획서를 만든다
  3. Worktrees와 서브에이전트로 구현을 쪼갠다 — 기능별로 작업 공간을 분리하고, 서브에이전트 기반으로 각 파트를 나눠 진행하면 컨텍스트가 덜 섞이고 기록도 자동으로 남는다

참고

  • 영상: GStack + Superpowers로 클로드코드 완전히 달라진 사람의 후기 (영상URL)

영상 메타

수집 품질

  • 자막 세그먼트: 310개
  • 자막 문자수: 5587자
  • 챕터 추출: 10개
  • 콘텐츠 생성: Subagent 기반

AI 생성 도구를 활용해 초안을 구성했고, 원영상 발화와 공개 자료를 교차 확인해 정리했습니다.