Claude Code용 gstack: 23개 에이전트 워크플로가 실제로 하는 일

gstack Claude Code는 프롬프트 팩이 아니라 운영 체계입니다

다음을 이해하는 데 유용한 관점은 gstack Claude Code Claude Code 위에 구축된 엔지니어링 운영 체계라는 것입니다. 각 도구는 Claude에 역할, 절차, 기대되는 결과물을 제공합니다. 이 도구들은 함께 소프트웨어가 아이디어에서 프로덕션으로 나아가야 하는 방식에 대한 원칙을 담고 있습니다.

일반적인 프롬프트는 다음과 같을 수 있습니다:

Review my implementation plan.

역할 기반 워크플로는 더 구체적인 질문을 던집니다:

/plan-eng-review

이 스킬은 Claude가 아키텍처, 의존성, 장애 유형, 테스트 용이성, 배포 위험, 구현 순서를 검토하도록 안내할 수 있습니다. 제품 중심의 계획 스킬은 같은 계획을 사용자 가치와 범위 측면에서 검토할 수 있습니다. 디자인 중심의 스킬은 백엔드 경계 대신 상호작용의 세부 사항에 의문을 제기할 수 있습니다.

차이는 반복 가능성에 있습니다. 팀원마다 40줄짜리 검토 프롬프트를 기억하거나 자체 체크리스트를 만들 필요가 없습니다. 스킬에 절차가 담겨 있습니다.

그에 따른 절충점도 중요합니다. gstack은 다른 사람이 만든 절차를 여러분의 저장소에 도입합니다. 여러 차례의 검토, 명시적인 QA, 체계적인 릴리스 작업에 드는 컨텍스트와 시간이 그만한 가치가 있다고 전제합니다. 프로덕션 변경에는 적절한 경우가 많지만, 오타 수정이나 두 줄짜리 내부 스크립트에는 과도할 수 있습니다.

23개의 역할 기반 도구가 실제로 다루는 범위

저장소의 정확한 도구 구성은 바뀔 수 있으므로, 저는 체크아웃한 SKILL.md 파일을 스크린샷이나 출시 소개보다 권위 있는 기준으로 삼습니다. 아키텍처에서 중요한 것은 책임의 분담입니다.

이 때문에 gstack을 “프롬프트 모음”이라고 부르면 그 가치를 축소하게 됩니다. 계획의 산출물은 구현에 반영되고, 구현은 변경 사항을 만들며, 검토와 QA는 그 변경 사항을 면밀히 살피고, 출시와 문서화는 결과를 정리합니다.

“23개 에이전트 워크플로”라는 표현이 오해를 부를 수 있는 이유도 여기에 있습니다. 스킬을 호출하면 실제로는 Claude Code가 지침을 불러오고 현재 세션에서 사용 가능한 도구로 해당 워크플로를 수행합니다. 스킬이 작업을 명시적으로 위임하지 않는 한, 전역 상태를 공유하는 23개의 상시 프로세스가 존재하는 것은 아닙니다.

계획 단계의 중복은 의도적입니다

제품, 엔지니어링, 디자인 검토는 서로 겹칩니다. 이는 의도된 것입니다.

“모든 고객 활동 내보내기”라는 기능 제안을 생각해 보겠습니다:

• 제품 검토에서는 사용자에게 전체 내보내기가 필요한지, 필터링된 보고서가 필요한지 묻습니다.
• 엔지니어링 검토에서는 내보내기 데이터를 메모리에 담을 수 있는지, 재시도가 어떻게 작동하는지 묻습니다.
• 디자인 검토에서는 내보내기 상태, 실패, 다운로드 컨트롤이 어디에 표시되는지 묻습니다.
• QA에서는 레코드가 없거나, 링크가 만료되거나, 작업이 중단되면 어떻게 되는지 묻습니다.

실무에서는 이렇게 역할을 분리하면 일반적인 구현 계획 속에서 묻혀 버리는 가정을 발견할 수 있습니다. 그 대가는 반복적인 컨텍스트 로딩입니다. 계획이 이미 8,000토큰이라면 세 차례의 검토로 비용이 커지고 중복된 지적이 나올 수 있습니다.

검토와 QA는 서로 다른 작업입니다

/review 는 주로 변경 사항, 타입, 테스트, 호출 지점, 저장소 규칙 등 코드에서 얻은 근거를 사용합니다. /qa 및 /browse 는 애플리케이션 자체에서 런타임 근거를 수집할 수 있습니다.

이러한 분리는 gstack의 강점 중 하나입니다. 변경 사항은 올바르게 보여도 렌더링된 결과는 사용하기 어려울 수 있습니다. 반대로, 정상 경로에 대한 브라우저 검사는 통과하더라도 구현에 경쟁 조건이나 권한 검사 우회가 생길 수 있습니다.

실용적인 순서는 다음과 같습니다:

/plan-eng-review
/careful
# Implement the approved plan in Claude Code
/review
/qa
/document-release
/ship

이를 필수 파이프라인으로 여기지는 마세요. 데이터베이스 마이그레이션에서는 시각적 디자인보다 엔지니어링 검토와 롤백 계획이 훨씬 중요할 수 있습니다. CSS 회귀에서는 /browse, 디자인 검토, QA가 핵심 워크플로가 될 수 있습니다.

gstack을 맹목적으로 신뢰하지 않고 설치하기

일반적인 사용자 수준 설치에서는 저장소를 Claude Code의 스킬 디렉터리에 배치하고 설정 스크립트를 실행합니다:

git clone https://github.com/garrytan/gstack.git \
  ~/.claude/skills/gstack

cd ~/.claude/skills/gstack
./setup

설정 후 새 명령이 바로 인식되지 않으면 Claude Code를 다시 시작하세요. 그런 다음 공개된 도구 수가 체크아웃한 버전과 여전히 일치한다고 가정하지 말고 설치된 스킬을 확인하세요:

find ~/.claude/skills/gstack \
  -name SKILL.md \
  -print |
  sort

find ~/.claude/skills/gstack \
  -name SKILL.md |
  wc -l

흔히 빠지는 함정은 저장소가 인기 있다는 이유만으로 설치 스크립트가 무엇을 바꾸는지 읽지 않고 실행하는 것입니다. gstack에는 정적인 Markdown만 있는 것이 아니라 실행 가능한 워크플로 구성 요소가 포함되어 있습니다. 설정을 실행하기 전에 내용을 살펴보세요:

cd ~/.claude/skills/gstack
git status --short
git log -1 --oneline
sed -n '1,240p' setup

팀에 도입할 때는 저장소의 최신 상태를 조용히 따라가는 대신 검토한 커밋에 버전을 고정하세요:

git clone https://github.com/garrytan/gstack.git vendor/gstack
cd vendor/gstack
git checkout <reviewed-commit-sha>
./setup

정확한 설치 절차와 의존성은 프로젝트가 발전하면서 바뀔 수 있습니다. 따라서 이 글을 포함한 오래된 글에서 복사한 명령보다 저장소의 현재 README 및 설정 스크립트를 우선해야 합니다.

워크플로에 Claude Code 권한 설정 적용하기

일부 gstack 도구는 파일을 검사하고, 테스트를 실행하고, 브라우저를 조작하거나 Git과 상호작용하기 위해 폭넓은 접근 권한이 필요합니다. 그렇다고 모든 도구에 무제한 셸 및 릴리스 권한을 부여해야 하는 것은 아닙니다.

프로젝트 수준의 .claude/settings.json 로 보수적인 기본 설정을 마련할 수 있습니다:

{
  "permissions": {
    "allow": [
      "Bash(git status:*)",
      "Bash(git diff:*)",
      "Bash(npm test:*)",
      "Bash(npm run lint:*)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Bash(git push:*)",
      "Bash(git push --force:*)"
    ]
  }
}

이를 어디에나 그대로 적용할 수 있는 파일이 아니라 정책 예시로 보세요. 패키지 관리자, 테스트 실행기, Claude Code 버전에 맞게 명령을 조정하세요.

다음 항목을 의도적으로 허용하지 않는 것은 git push 평가 중에 특히 유용합니다. /ship 는 여전히 릴리스 준비 상태를 점검할 수 있지만, 네트워크에 영향을 주는 최종 작업은 사람이 통제합니다. 팀이 워크플로를 이해한 뒤에는 범위를 엄격히 제한한 푸시 권한을 부여할 만한지 판단할 수 있습니다.

또한 브라우저 중심 스킬은 스테이징 환경이나 미리 데이터를 넣은 로컬 환경에서 테스트하세요. 프로덕션 세션을 이용한 브라우저 자동화는 워크플로가 파괴적인 컨트롤을 클릭할 경우 실제 레코드를 변경할 수 있습니다.

전체 시스템을 도입하기 전에 일부부터 도입하기

저라면 첫날부터 팀에 23개의 도구를 모두 도입하지는 않겠습니다. 기존 프로세스에서 정보가 가장 많이 손실되는 지점부터 시작하세요.

합리적인 평가 매트릭스는 다음과 같습니다:

선택한 도구들을 여러 실제 변경 작업에 적용하고 다음을 기록하세요:

• 어떤 지적이 코드나 범위의 변경으로 이어졌나요?
• 어떤 지적이 중복되었나요?
• 얼마나 많은 컨텍스트를 반복해서 제공해야 했나요?
• 생성된 산출물이 구현과 계속 일치했나요?
• 어떤 명령에 팀이 CI에서 부여하지 않을 권한이 필요했나요?
• 개발자들이 각 역할을 언제 호출해야 하는지 이해했나요?

컨텍스트 오버헤드는 이론적인 문제가 아닙니다. 각 역할에는 저장소 상태, 요구 사항, 이전 결정이 필요합니다. 세션을 나누면 결정의 근거가 사라질 수 있고, 하나의 긴 세션에는 낡은 가정이 쌓일 수 있습니다. 저는 승인된 계획을 다음과 같은 저장소 파일에 보관합니다: docs/plans/export-jobs.md. 그런 다음 각 워크플로에 해당 산출물을 사용하도록 지시합니다. 지속적으로 보관되는 파일은 대화 컨텍스트가 프로젝트의 기억 역할을 해 주리라고 기대하는 것보다 신뢰할 수 있습니다.

문서화된 동작과 홍보성 주장

근거를 댈 수 있는 주장은 gstack이 23개의 역할 중심 Claude Code 도구와 소프트웨어 생명주기 전반을 아우르는 고유한 방식의 워크플로를 제공한다는 것입니다. 설치된 스킬을 읽고 테스트 저장소에서 실행해 그 동작을 검증할 수 있습니다.

산출물을 극적으로 늘리거나, 엔지니어링 팀을 대체하거나, 몇 주 걸리는 일을 몇 시간으로 단축한다는 등의 더 광범위한 주장은 여러분의 환경에서 입증되기 전까지는 홍보성 주장입니다. 결과는 저장소 품질, 테스트 범위, 작업의 모호성, 모델 선택, 권한, 작업을 감독하는 개발자에 따라 달라집니다.

현재의 모델 라인업도 이러한 제약을 없애지는 못합니다. Sonnet 4.6은 지속적인 코딩 작업에 실용적인 기본 선택일 수 있고, Haiku 4.5은 더 가벼운 분류나 문서화 작업에 적합할 수 있습니다. Fable 5의 1M 컨텍스트는 매우 방대한 자료를 다루는 데 도움이 될 수 있으며, gpt-5.6-sol는 지원되는 환경에서 또 다른 엔지니어링 중심 선택지를 제공합니다. 어느 모델도 역할 프롬프트를 검증된 제품 지식이나 프로덕션 근거로 바꿔 주지는 않습니다.

실무 핵심 요점

• gstack을 Claude Code 스킬로 구현된, 고유한 방식을 따르는 개발 프로세스로 보세요.
• “23개의 에이전트”를 자동으로 조율되는 상시 작업자가 아니라 역할 기반 도구로 이해하세요.
• 저장소에서 설치하고, 다음을 검토하세요 setup. 팀에서 사용할 때는 검토한 커밋으로 고정하세요.
• 이미 확인된 배포 문제를 해결하는 워크플로 두세 개부터 시작하세요.
• 승인된 계획과 결정을 파일에 보관하여 각 역할이 지속적으로 유지되는 맥락을 공유하도록 하세요.
• 코드 검토와 런타임 QA를 분리하세요. 각각 서로 다른 유형의 문제를 찾아냅니다.
• 평가하는 동안 비밀 정보, 프로덕션 세션, Git 푸시, 배포 명령에 대한 접근을 제한하세요.
• 실행한 명령 수가 아니라 유용한 발견과 예방한 결함을 측정하세요.
• 프로세스 비용이 예방하는 문제로 인한 비용보다 낮을 때만 전체 운영 체계를 도입하세요.