gstack: AI 소프트웨어 엔지니어링 스택

AI 코딩 에이전트는 이미 함수 작성, 저장소 수정, 테스트 실행, 그리고 풀 리퀘스트(Pull Request) 생성이 가능합니다. 더 어려운 문제는 코드를 작성하기 전, 중, 후를 아우르는 반복 가능한 엔지니어링 프로세스를 에이전트가 따르도록 만드는 것입니다.

게리 탄(Garry Tan)이 주도하는 gstack은 원래 Claude Code를 기반으로 구축되었으나, 다른 접근 방식을 취합니다. 기존 코딩 에이전트를 다른 플랫폼으로 대체하는 대신, 이미 사용하는 에이전트를 전문화된 스킬, 브라우저 툴링, 리뷰, 안전 제어 및 릴리스 프로세스를 갖춘 형태로 감싸줍니다. 이 프로젝트는 그 결과를 가상 엔지니어링 팀으로 설명합니다. 23명의 전문가와 8개의 파워 툴로 구성되며, 모두 슬래시 명령어이고 모두 마크다운 기반이며, MIT 라이선스로 제공됩니다.

비교 대상은 gstack의 어떤 부분이 필요한지에 따라 달라집니다: Superpowers와 같은 스킬 컬렉션, OpenSpec와 GitHub Spec Kit과 같은 명세 시스템, BMAD와 같은 방법론, Ruflo와 같은 오케스트레이션 플랫폼, 혹은 사용자가 직접 관리하는 에이전트 스킬 세트 등입니다. 이 중 일부는 gstack을 대체하기보다 함께 조합되며, 이 모든 도구가 속해 있는 더 넓은 생태계는 이 사이트의 AI 개발 도구 허브에서 확인할 수 있습니다.

gstack이란?

gstack은 오픈 소스 AI 엔지니어링 워크플로 컬렉션입니다. gstack의 프레임워크에서는 소프트웨어 개발이 여러 가지 다른 추론 유형으로 구성되어 있으며, 하나의 일반 코딩 프롬프트에 이 모든 것을 수행하도록 요구하는 것은 부당한 추상화라고 봅니다. 따라서 이 프로젝트는 전문화된 스킬을 제공합니다:

• 제품 탐색
• 제품 및 CEO 리뷰
• 아키텍처 리뷰
• 개발자 경험(DX) 리뷰
• 디자인 리뷰
• 구현 리뷰
• 브라우저 기반 QA
• 조사 및 디버깅
• 보안 분석
• 문서화
• 벤치마킹
• 릴리스 준비
• 배포
• 회고

이 프로젝트는 이러한 역할을 가상 엔지니어링 팀으로 제시합니다. 제품을 다시 고려하는 CEO, 아키텍처를 고정하는 엔지니어링 매니저, “AI 슬럽(AI slop)“을 잡아내는 디자이너, 프로덕션 버그를 찾는 리뷰어, 실제 브라우저를 여는 QA 리드, OWASP와 STRIDE 감사 실행을 담당하는 보안 담당자, 그리고 PR을 릴리스하는 릴리스 엔지니어입니다. 스킬 정의 주위의 툴체인은 TypeScript와 Bun입니다. 셋업 스크립트, 생성된 스킬 문서, 세션 훅, ~/.gstack/ 하위의 상태 관리, 번들된 브라우저, 그리고 독립형 CLI 세트가 포함됩니다.

gstack은 파운데이션 모델이 아니며 Claude Code의 대체재도 아닙니다. 이는 에이전트 하네스 위에서 실행되는 프로세스 레이어입니다:

두 가지 구조적 속성이 gstack의 위치를 결정합니다. 첫째, 이 프로젝트는 gstack을 도구 컬렉션이 아닌 프로세스로 설명합니다. 스킬들은 스프린트가 진행되는 순서대로 실행됩니다 – 생각하기, 계획하기, 구축하기, 리뷰하기, 테스트하기, 출시하기, 반성하기 – 각 스킬은 그 산출물을 다음 스킬로 넘깁니다. 예를 들어, /office-hours가 디자인 문서를 작성하고 /plan-ceo-review가 그 문서를 읽으며, /plan-eng-review가 테스트 플랜을 작성하고 /qa가 그 내용을 이어받습니다. 둘째, gstack은 Claude Code에만 국한되지 않습니다. ./setup은 기기에 설치된 에이전트를 자동 감지하고, ./setup --host <이름>은 Codex CLI, OpenCode, Cursor, Factory Droid, Kiro, Slate, OpenClaw, Hermes를 대상으로 설정합니다. 저장소에 있는 2KB 용량의 지침 전용 다이제스트는 설치 없이 규칙 파일만 읽는 에이전트를 커버합니다.

gstack이 존재하는 이유

빈 Claude Code 세션은 매우 유연하며, 이러한 유연성이 동시에 그 약점이기도 합니다. 다음과 같은 기능 요청을 생각해 보십시오:

애플리케이션에 조직 수준 API 토큰을 추가하세요.

능숙한 에이전트는 즉시 저장소를 검사하고 인증 코드 수정을 시작할 수 있습니다. 반면 시니어 엔지니어는 먼저 누가 토큰의 소유자인지, 사용자가 여러 조직에 속할 수 있는지, 토큰이 어떻게 폐기되는지, 권한이 상속되는지, 기존 인증에 어떤 영향이 발생하는지, 토큰이 만료되어야 하는지, 시크릿이 어떻게 표시되는지, 그리고 어떤 감사 이벤트가 필요한지를 먼저 질문할 것입니다. 에이전트는 결국 이러한 질문 중 일부를 발견할 수 있지만, 구현 전에 이를 발견할 것이라는 보장은 없습니다. gstack은 이러한 규율을 재사용 가능한 워크플로로 이동시킵니다. 아이디어 -> 코딩 에이전트 -> 코드 대신, 변경사항은 제품 리뷰, 기술 계획, 아키텍처 리뷰, 구현, 코드 리뷰, 브라우저 QA, 그리고 릴리스라는 명명된 단계를 거치며, 각 단계에는 고유한 명령어가 있습니다. (전체 시퀀스는 아래 실용적인 gstack 워크플로에서 확인할 수 있습니다.)

이것은 AI를 정확하게 만들지는 않습니다. 오해의 확률 분포를 변화시킵니다. 에이전트는 더 일찍 가정을 문제 삼고, 증거를 검사하며, 여러 관점에서 자신의 업무를 리뷰하고, 코드가 컴파일되는 시점에서 멈추지 않고 애플리케이션을 검증하도록 유도됩니다.

gstack이 마크다운 스킬을 프로세스로 변환하는 방식

gstack의 대부분의 기능은 마크다운 스킬 정의에서 출발합니다. 에이전트 스킬은 다음을 설명할 수 있습니다:

• 언제 실행되어야 하는지
• 어떤 컨텍스트를 검사해야 하는지
• 어떤 질문을 해야 하는지
• 어떤 도구를 사용할 수 있는지
• 어떤 명령어를 실행해야 하는지
• 어떤 증거를 수집해야 하는지
• 어떤 체크를 통과해야 하는지
• 결과가 어떻게 구조화되어야 하는지

이러한 스킬은 문서, 재사용 가능한 프롬프트, 표준 운영 절차(SOP), 실행 가능한 워크플로 구성 사이 어딘가에 위치합니다. 기반 메커니즘은 개발자를 위한 Claude Skills와 SKILL.md에서 다루고 있습니다. gstack은 이 기본 원语 위에 인프라를 추가합니다. 생성된 스킬 정의, 시작 및 완료 훅, ~/.gstack/ 하위의 상태 관리, 브라우저 자동화, 안전 메커니즘, 저장소 검사, 옵트인 텔레메트리, /learn이 관리하는 세션 간 메모리, 그리고 별개의 GBrain 프로젝트를 통한 선택적 영구 지식 등이 포함됩니다. /setup-gbrain은 이를 로컬 PGLite 데이터베이스, Supabase 프로젝트, 또는 원격 MCP 엔드포인트로 설정할 수 있습니다.

가장 중요한 gstack 스킬

정확한 컬렉션은 빠르게 변하지만, 몇 가지 워크플로는 시스템이 의도된 사용 방식을 보여줍니다.

office-hours

/office-hours는 프로젝트나 기능의 초기 단계에 해당합니다. 코드 작성 전에 문제점에 대한 여섯 가지 강제 질문을 수행하며, README의 실습 예제에서는 “데일리 브리핑 앱” 요청을 개인 참모장 AI로 재해석한 뒤, 모든 다운스트림 스킬이 읽을 디자인 문서를 작성합니다. “더 나은 프로젝트 검색 기능이 필요합니다"와 같은 모호한 입력에 대해 출력물은 코드가 아닌 요구사항입니다.

plan-ceo-review

/plan-ceo-review은 플랜 뒤의 제품 수준 가정을 조사합니다. 확장(Expansion), 선택적 확장(Selective Expansion), 범위 유지(Hold Scope), 축소(Reduction)의 네 가지 범위 모드로 작동하며, 범위에 도전하고, 누락된 기회를 식별하고, 불필요한 작업을 줄이거나, 문제를 다르게 프레이밍하는 것을 제안할 수 있습니다. 요구사항이 고정되기 전, 즉 대부분의 코딩 에이전트 도구가 갖지 않는 단계에서 실행됩니다.

plan-eng-review

/plan-eng-review은 관점을 엔지니어링으로 전환합니다. 아키텍처, 데이터 흐름, 다이어그램, 엣지 케이스, 테스트 매트릭스, 실패 모드, 그리고 보안 우려 사항을 다룹니다. 제품 리뷰와 별도로 유지되는 이유는, 둘을 하나의 큰 프롬프트로 병합하면 모델이 제품 결정과 구현 결정을 혼동하기 때문입니다.

plan-design-review and design-review

gstack은 시각 및 인터랙션 디자인을 별개의 학문으로 대우합니다. /plan-design-review은 각 디자인 차원을 0에서 10까지 평가하고, 10점이 어떤 모습인지 설명하며, 격차를 줄이기 위해 플랜을 편집합니다. 여기서 “AI 슬럽” 감지는 명명된 체크 항목으로 포함됩니다. 후속 단계인 /design-review은 실제 구현물에 대해 동일한 감사 작업을 수행하고, 원자적 커밋과 Before/After 스크린샷을 통해 발견한 문제를 수정합니다. 웹 애플리케이션의 경우, 둘 다 gstack의 브라우저 자동화와 함께 사용됩니다.

review

/review은 스태프 엔지니어 관점에서 저장소 변경 사항에 대한 엔지니어링 리뷰를 수행합니다. 명백한 발견 사항을 자동으로 수정하고, 나머지 항목은 승인용으로 표시하며, 과도하게 구축된 코드에 대해서는 조언性质的 단순화 렌즈를 유지합니다. 성공적으로 작성된 코드가 반드시 병합되어야 할 코드라는 보장은 없습니다.

investigate

/investigate은 조사가 없는 수정은 불가라는, 이 프로젝트가 ‘철의 법칙(Iron Law)‘이라 부르는 체계적인 디버깅 규칙을 강제합니다. 데이터 흐름을 추적하고, 가설을 테스트하며, 세 번의 실패한 수정 시도 후 더 이상의 무리한 추적을 멈추도록 합니다. 또한 조사 대상 모듈의 편집을 잠그는 /freeze을 자동으로 활성화합니다.

qa and qa-only

/qa는 에이전트가 브라우저를 조작하도록 하여 애플리케이션과 상호작용하고, 버그를 찾아 원자적 커밋으로 수정하며, 재확인 후 모든 수정 사항에 대해 회귀 테스트를 생성합니다. /qa-only는 동일한 방법론을 보고 전용으로 실행합니다. 많은 코딩 에이전트는 “테스트 통과"에서 검증을 멈추지만, 웹 애플리케이션에서 통합 오류, 레이아웃 문제, 잘못된 흐름, 인증 실패, JavaScript 예외는 주로 브라우저에서 시각화됩니다.

ship, land-and-deploy, and canary

릴리스 체인은 하나가 아니라 세 가지 스킬로 구성됩니다. /ship은 main 브랜치를 동기화하고, 테스트를 실행하고, 커버리지를 감사하며, push를 하고 풀 리퀘스트를 엽니다. 프로젝트에 테스트 프레임워크가 없으면 이를 부트스트랩합니다. /land-and-deploy은 병합을 수행하고, CI 및 배포를 대기하며, 프로덕션 헬스를 검증합니다. /canary는 배포 후 모니터링 루프를 실행하여 콘솔 오류, 성능 회귀, 페이지 실패를 감시합니다.

autoplan, spec, learn, and retro

/autoplan은 CEO, 디자인, DX, 엔지니어링 리뷰 파이프라인을 자동으로 실행합니다. 엔지니어링 리뷰는 항상 마지막에 실행되어, 시핑 게이트가 최종 수정된 플랜을 리뷰하도록 합니다. 승인용으로 맛(taste)의 결정 사항만 표시합니다. /spec은 모호한 의도를 5개 단계(왜, 범위, 코드 읽기가 필수인 기술 사항, 초안, 파일)를 통해 정확하고 실행 가능한 명세로 전환하며, 제출 전 외부 리뷰 품질 게이트를 거칩니다. /learn은 gstack이 세션 전반에서 학습한 것 – 패턴, 함정, 선호도 – 을 리뷰, 검색, 가지 치기, 내보내기로 관리합니다. /retro는 팀 인식을 갖춘 주간 회고를 생성하며, /retro global은 모든 프로젝트와 AI 도구를 거쳐 실행합니다.

gstack의 브라우저 자동화

지원되는 macOS 시스템(macOS 15 이상)에서 gstack은 Aside 브라우저를 우선적으로 구동합니다. 이는 사용자의 실제 브라우저로, 실제 로그인된 세션을 가지며, 에이전트가 스스로 탭을 열어 작업을 마치고 닫습니다. Aside를 사용할 수 없는 경우, gstack은 자체 Chromium 기반 엔진으로 폴백합니다. 이 엔진은 ./setup으로 빌드되며, 각 명령마다 새로운 브라우저를 시작하는 대신 영구 데몬을 실행합니다:

영구 브라우저 상태는 쿠키, 인증 세션, 탭이 작업 간에 유지되도록 하여 브라우저 기반 QA를 실용적으로 만듭니다. /open-gstack-browser는 폴백 엔진을 headed 모드로 노출하며, 사이드바 에이전트는 빠른 작업(클릭, 내비게이션, 스크린샷)은 Sonnet에, 읽기나 분석은 Opus에 라우팅합니다. 에이전트가 CAPTCHA, 인증 장벽, 또는 MFA 프롬프트에 도달하면, $B handoff는 쿠키와 탭을 그대로 유지한 채 동일한 페이지에 보이는 브라우저를 엽니다. 사용자가 이를 해결하면, $B resume은 에이전트가 중단된 곳에서 계속합니다. 에이전트는 세 번의 연속 실패 후 자동으로 핸드오프를 제안합니다. /pair-agent는 다른 에이전트 – OpenClaw, Hermes, Codex, Cursor, 또는 curl이 가능한 무엇과도 – 과 브라우저를 공유합니다. 이는 범위 지정된 토큰, 탭 격리, 속도 제한, 탭별 활동 할당을 포함합니다.

영구 엔진은 인증된 세션에 액세스할 수 있는 에이전트가 의미 있는 권한을 가지기 때문에 보안 표면적을 증가시킵니다. gstack은 이를 위해 계층적인 프롬프트 인젝션 방어를 제공합니다. 모든 페이지 읽기 시 콘텐츠 필터(데이터 마킹, 숨겨진 요소 제거, ARIA 스크러빙, URL 차단 목록)와 에이전트가 보기 전 페이지 유도 콘텐츠를 스캔하는 사이드카 서브프로세스 내 로컬 ML 분류기, 그리고 차단 전에 분류기 합의를 요구하는 판정 결합기가 포함됩니다. 페이지 콘텐츠는 신뢰할 수 없는 입력으로 취급됩니다 – 에이전트는 페이지에서 구문을 가져오지만, 절대 지시를 따르지 않습니다. 브라우저 구동 QA 사용 전 및 사용 중 체크리스트:

• 에이전트가 작동할 수 있는 인증된 환경을 사전에 결정하고, 폴백 엔진 사용 시 QA 작업을 위해 격리된 프로필을 권장합니다.
• 비상 종료 스위치를 알아두십시오: GSTACK_SECURITY_OFF=1은 보안 레이어를 비활성화합니다 – 설정 상태로 두지 마십시오.
• 영구 데몬은 실행 간 쿠키와 세션을 유지하므로, 완료 후 이를 중지하고 아무것도 실행 중이지 않은지 확인하십시오. 예를 들어 ps aux | grep -i chrom을 실행하십시오.
• 활성화하기 전에 클론된 저장소의 훅과 안전 메커니즘을 읽으십시오 – 이들은 평범한 파일이므로 CI 구성을 리뷰하듯 리뷰하십시오.
• 클론을 업데이트한 후 ./setup을 다시 실행하여 생성된 구성 요소가 스킬 정의와 동기화되도록 하십시오.

안전 가드레일과 제2의 의견

세 가지 파워 툴이 세션 수준의 안전 스위치 역할을 합니다. /careful은 파괴적인 명령 – rm -rf, DROP TABLE, force-push, git reset --hard – 전에 경고하며, “조심해"라고 말하면 활성화됩니다. 루트 또는 홈 디렉토리의 재귀적 삭제 및 기본 브랜치로의 force-push는 하드 거부됩니다. /freeze은 디버깅 중에 무관한 코드를 “수정"하지 못하도록 파일 편집을 하나의 디렉토리로 제한하고, /guard은 이를 한꺼번에 활성화합니다.

제2의 의견 리뷰는 하네스를 넘나듭니다: Claude Code에서는 /codex가 작업을 OpenAI Codex CLI로 보내 독립적인 리뷰, 도전, 또는 자문을 요청합니다. 다른 하네스에서는 /claude-code가 그 반대 역할을 수행합니다. 각 보고서는 실제로 리뷰를 완료한 제공자를 식별합니다.

실용적인 gstack 워크플로

모든 변경 사항에 gstack의 모든 스킬을 사용할 필요는 없습니다. 합리적인 기능 워크플로는 다음과 같습니다:

1. /office-hours
2. /plan-ceo-review
3. 구현 계획 작성
4. /plan-eng-review
5. 구현
6. /review
7. /qa
8. /ship

어떤 리뷰 스킬을 추가할지는 소프트웨어의 대상에 따라 달라집니다:

자명한 버그 수정의 경우, 조사, 구현, 리뷰, 테스트로 바로 넘어가는 것이 보통 충분합니다. 도구 중립적 버전의 동일한 형태 – 명세, 디자인, 작업, 구현, 검증 – 은 요구사항부터 코드로의 명세 기반 개발 워크플로에서 확인할 수 있습니다. 이 프로젝트의 README는 10에서 15개의 이러한 스프린트를 병렬로 실행하는 방법을 설명하며, 각각은 자체 격리된 워크스페이스에서 실행됩니다. 스프린트 구조는 병렬 에이전트가 혼란의 원인이 되지 않도록 하는 프로젝트가 말하는 핵심입니다.

gstack 설치

현재 설치 절차는 작동하는 Claude Code 설정, Git, Bun v1.0 이상, 그리고 Windows의 경우 Node.js를 요구합니다. Bun은 Windows에서 Playwright의 파이프 전송에 알려진 버그가 있으므로, 그곳에서는 browse 서버가 Node.js로 폴백합니다. 아직 Claude Code를 설정하지 않았다면, 먼저 Claude Code 개요로 시작하십시오. macOS의 경우, 브라우저 스킬을 위해 Aside 브라우저(macOS 15 이상)를 권장하며, 없으면 번들된 Chromium 데몬이 사용됩니다.

1. 전제 조건을 확인하십시오: git --version 및 bun --version (툴체인은 Bun 기반입니다).

2. gstack을 Claude 스킬 디렉토리로 클론하십시오:

   git clone --single-branch --depth 1 \
     https://github.com/garrytan/gstack.git \
     ~/.claude/skills/gstack
   

3. 클론된 디렉토리에서 설정 스크립트를 실행하십시오:

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

   설정은 지원되는 스킬에 필요한 구성 요소를 설치하고 생성하며 번들된 브라우저를 빌드합니다. Chromium 설치 실패는 최선의 노력으로 처리되며, 설정은 이유를 기록하고 모든 스킬 등록을 완료한 후 어떤 스킬이 영향을 받는지를 출력합니다.

4. 프로젝트의 CLAUDE.md에 ## gstack 섹션을 추가하십시오. 프로젝트의 설치 지침에는 이 단계가 포함되어 있으며, 이것이 Claude Code가 스킬을 라우팅하는 방식을 결정합니다: 모든 웹 탐색에 gstack의 /browse를 사용하고, mcp__claude-in-chrome__* 도구는 절대 사용하지 않으며, 사용 가능한 스킬을 나열하십시오.

5. 설치를 검증하십시오: 클론된 디렉토리에 생성된 파일이 존재하는지 확인하고, Claude Code 세션을 시작하며, 스킬이 인식되는지 확인하기 위해 스크래치 프로젝트에서 /office-hours를 실행하십시오.

팀 모드

저장소에 대해, gstack은 개별적으로 구성된 환경 대신 개발자들이 하나의 워크플로를 공유하는 팀 중심 설계를 제공합니다:

(cd ~/.claude/skills/gstack && ./setup --team) && \
  ~/.claude/skills/gstack/bin/gstack-team-init required && \
  git add .claude/ CLAUDE.md && \
  git commit -m "require gstack for AI-assisted work"

required는 gstack 없이 저장소에서 AI 지원 작업을 차단합니다. 팀원을 차단하는 대신 유도하려면 optional로 교체하십시오. 저장소에 파일이 벤더링되지는 않습니다: 모든 Claude Code 세션은 빠른 자동 업데이트 확인(1시간에 한 번으로 제한, 네트워크 실패 안전, 무음)으로 시작하여 팀 내 버전 드레이프를 제거합니다. 개인 설정은 한 개발자를 개선하지만, 저장소 수준 설정은 공유된 엔지니어링 규약을 생성합니다.

기타 하네스, 업그레이드, 제거

• 기타 에이전트: ./setup --host codex, --host opencode, --host cursor, --host factory, --host kiro, --host slate, --host openclaw, --host hermes는 스킬을 각 에이전트의 고유한 스킬 디렉토리에 설치합니다. agents-digest/gstack-AGENTS.md에 있는 2KB 지침 전용 다이제스트는 규칙 파일만 읽는 에이전트를 커버합니다.
• 명령명 명명: 스킬은 기본적으로 짧은 이름(/qa, /review)으로 등록되며, ./setup --prefix는 네임스페이스화된 이름(/gstack-qa)으로 전환합니다. 이는 gstack과 함께 다른 스패크를 실행할 때 중요합니다.
• 업그레이드: git pull 후 ./setup을 다시 실행하십시오(설치가 파일 복사인 Windows에서는 필수), 또는 /gstack-upgrade 스킬을 사용하십시오. ~/.gstack/config.yaml에 auto_upgrade: true를 설정하면 설치가 자동으로 최신 상태로 유지됩니다.
• 텔레메트리 기본값은 꺼져 있으며 첫 실행 시 옵트인을 요청합니다. 옵트인 경우, 스킬 이름, 소요 시간, 성공/실패, gstack 버전, OS가 전송됩니다 – 코드, 파일 경로, 저장소 이름, 프롬프트는 절대 전송되지 않습니다. gstack-config set telemetry off는 언제든지 이를 비활성화합니다.
• 제거: ~/.claude/skills/gstack/bin/gstack-uninstall은 스킬, 심볼릭 링크, ~/.gstack/ 상태, 프로젝트 로컬 상태, browse 데몬, 훅 등록을 제거합니다.

설치 검증 및 일반 실패 해결

• ./setup 실패 – bun --version으로 Bun이 PATH에 있는지 확인하십시오. 생성된 구성 요소는 Bun 툴체인으로 빌드됩니다.
• Claude Code에서 스킬 미인식 – 클론이 실제로 ~/.claude/skills/gstack에 있는지, 프로젝트의 CLAUDE.md에 gstack 섹션이 있는지 확인하고 ./setup을 다시 실행하십시오.
• /browse가 NEED_ASIDE 또는 ASIDE_NOT_RUNNING 보고 – 프로브가 폴백 브라우저를 사용할 것이라고 알려주는 것입니다. 이는 Linux와 Windows에서 정상이며, macOS에서는 Aside가 열려 있지 않거나 로그인되지 않은 것을 의미합니다.
• 폴백 브라우저 실패 – cd ~/.claude/skills/gstack && bun install && bun run build.
• 업데이트 후 구식 설치 – /gstack-upgrade을 실행하거나 ~/.gstack/config.yaml에 auto_upgrade: true를 설정하십시오.

gstack을 모든 것 없이 시도해보기

개발 프로세스를 전체적으로 이전하는 대신, 실제지만 비핵심적인 기능에 gstack을 사용하십시오. 프로젝트의 빠른 시작은 동일한 시도이며, “그খানে서 멈추십시오"로 끝납니다:

1. /office-hours – 문제 정의
2. /plan-ceo-review – 제품 추론
3. /review – 구현 후 엔지니어링 검증
4. /qa – 웹 프로젝트의 런타임 검증

이러한 단계가 일반적인 Claude Code 워크플로가 놓치는 발견 사항을 드러낸다면, 시스템의 나머지는 탐구할 가치가 있습니다. 엔지니어링 결정을 변경하지 않고 단순히 추가적인 텍스트만 생성한다면, 스택 전체를 채택하는 것이 도움이 되지 않을 가능성이 높습니다.

gstack의 강점

분리된 엔지니어링 역할. 하나의 거대한 “시니어 엔지니어가 되어라"는 지시 대신, 제품 전략, 아키텍처, UX, QA, 보안, 릴리스 엔지니어링이 각자의 고유한 추론 모드를 갖습니다.

검증, 생성만이 아님. 리뷰, 회귀 테스트 생성을 갖춘 브라우저 QA, 보안 감사, 벤치마킹, ship-deploy-canary 체인은 gstack에서 선택적 사후 처리가 아닌 1급 워크플로입니다.

검사 가능성. 행동 레이어의 상당 부분은 독점적 자율 에이전트의 내부 워크플로와 달리 개발자가 읽고 수정할 수 있는 평범한 마크다운 파일입니다. 저장소는 스택 자체를 위한 감사 툴링도 제공합니다: gstack-context-bill은 설치된 스킬 트리의 토큰 비용을 보고하며, gstack-egress는 기계 밖 전송(텔레메트리 포함)마다 해시 체인 영수증을 작성합니다.

팀 인프라. 스킬은 엔지니어링 규약을 인코딩할 수 있습니다 – 모든 세션에서

API 호환성을 확인하고, 통합 테스트를 실행하고,
브라우저 콘솔을 검사하고, 변경 로그를 업데이트하는 것을 기억하십시오.

라고 타이핑하는 대신, 요구사항은 재사용 가능한 워크플로에 존재하고, 팀 모드는 그 워크플로를 저장소 요구사항으로 만듭니다.

gstack이 과도해질 수 있는 곳

gstack은 의도적으로 의견이 강하며, 이는 그 적합성을 제한합니다: 성숙한 조직은 이미 아키텍처 리뷰 절차, 릴리스 툴링, CI 게이트, QA 자동화, 보안 스캐닝, ADR 규약, 명세 템플릿, 코드 리뷰 정책을 가지고 있을 수 있으며, 그 위에 또 하나의 완전한 방법론을 추가하면 명확성 대신 중복을 생성합니다.

또한 컨텍스트와 토큰 비용이 있습니다: 각 추가 리뷰 단계는 저장소 검사, 모델 추론, 그리고 잠재적으로 더 많은 외부 모델 호출을 추가합니다. 목표는 AI 리뷰의 최대 수가 아니라 올바른 소프트웨어를 출시하는 데 필요한 최소한의 신뢰할 수 있는 프로세스입니다. gstack-context-bill은 유지할 양을 결정하기 전, 설치된 스킬 세트가 세션별로 실제로 얼마나 비용이 드는지 정량화할 수 있습니다.

gstack은 모든 커밋을 위한 의례가 아니라, 워크플로를 선택하고 적응하는 도구 상자로서 가장 잘 작동합니다.

gstack 대안 및 조합

가장 가까운 대안 및 각자가 차지하는 레이어:

gstack + Superpowers: 역할 안의 구현 규율

둘 다 스킬 프레임워크이므로 가장 많이 겹칩니다. 조합 시 역할 분담은 다음과 같습니다: gstack은 주위의 역할 – 제품, 디자인, QA, 릴리스 – 을 공급하고, Superpowers는 구현 단계 안의 규율(TDD, 구현 전 계획, 체계적인 디버깅, 서브에이전트 리뷰)을 공급합니다. 두 스킬 세트를 설치한 후, 에이전트가 동일한 단계에 대해 두 가지 충돌하는 지시를 보지 않도록 겹치는 스킬을 정리하십시오. 명령명이 충돌하는 경우, gstack을 ./setup --prefix로 설치하여 그 스킬이 /gstack-*로 등록되고 다른 패크와 공존하도록 하십시오. 설치 및 워크플로 세부 사항은 Superpowers 퀵스타트에서 확인할 수 있습니다.

gstack + OpenSpec: 영구 명세, 라이브 리뷰

OpenSpec는 명시적인 변경 명세 – 제안된 변경, 명세, 디자인 결정, 구현 작업에 대한 산출물 – 주위에서 인간과 에이전트를 정렬시킵니다. 주요 속성은 지속성입니다: 채팅 대화는 컨텍스트 역사 속에 사라지지만, 명세는 인간과 미래 에이전트 세션이 리뷰할 수 있도록 저장소에 남습니다. gstack은 명세가 존재하기 전의 제품 리뷰와 구현 후의 리뷰 및 QA를 추가합니다:

구체적인 시퀀스: /office-hours와 /plan-ceo-review를 실행하고, 결과를 OpenSpec 변경으로 캡처하고, 그에 따라 구현한 후, /review와 /qa를 실행합니다. gstack도 자체 /spec 스킬을 제공하며 이는 ~/.gstack 아래에 명서를 아카이브한다는 점에 유의하십시오. OpenSpec가 명세의 소유자라면, 둘이 나뉘지 않도록 gstack의 /spec을 루프 밖으로 유지하십시오. OpenSpec 퀵스타트은 탐색-제안-적용-아카이브 루프를 자세히 다룹니다.

gstack + GitHub Spec Kit: 하나의 계획 골격 선택

Spec Kit의 핵심 워크플로는 명시적인 단계의 시퀀스 – 헌법, 명세, 계획, 작업, 구현, 수렴 – 이며, 버그 수정, 아이디어 평가, 확장, 프리셋, 통합으로 확장되었습니다. Spec Kit과 gstack 모두 계획 단계를 중심으로 하므로, 둘 다의 전체 플로우를 실행하면 작업이 중복됩니다. 요구사항 추적 가능성과 공식적인 단계가 중요하다면, Spec Kit이 명세 골격을 소유하게 하고, Spec Kit이 강제하지 않는 레이어 – 제품 리뷰, 디자인 리뷰, 브라우저 QA, 시핑 – 에 gstack을 사용하십시오. Kiro와 Claude Code를 포함한 명세 기반 설정의 더 넓은 비교는 GitHub Spec Kit vs Kiro vs Claude Code SDD 워크플로에서 확인할 수 있습니다.

BMAD와 Ruflo: 다른 축

BMAD는 적응형 워크플로가 제품 생각, 명세, 아키텍처, 구현을 커버하는 더 넓은 AI 기반 개발 방법론이며, 의례의 규모를 작업의 크기에 맞춥니다. BMAD와 gstack 모두 프로세스 골격 역할을 하므로, 둘 다 전체를 실행하기보다 하나의 골격을 선택하십시오. gstack의 개별 스킬은 여전히 방법론과 함께 선택될 수 있습니다.

Ruflo는 멀티 에이전트 오케스트레이션을 대상으로 합니다: 조정된 워커, 공유 메모리, 스웜. gstack은 하나의 엔지니어링 워크플로에 여러 전문가 관점을 적용하는 반면, 오케스트레이션 플랫폼은 하나의 엔지니어링 목표에 여러 실행 에이전트를 적용합니다. 경계는 흐려집니다 – gstack은 외부 도구와 추가 모델을 호출할 수 있고, 오케스트레이터는 구조화된 엔지니어링 역할을 구현할 수 있지만 – 결정은 독립적입니다: 문제가 에이전트가 엔지니어링 규율을 건너뛴 것이라면, 스킬 프레임워크가 직접적인 해결책입니다. 문제가 여러 작업과 저장소에서 10개의 에이전트를 동시 실행하는 것이라면, 오케스트레이터는 gstack과 같은 워크플로를 대체하기보다 그 위에 위치합니다.

Custom skills: 가장 커스터마이징 가능한 레이어

프레임워크를 완전히 건너뛰고 팀이 이미 따르는 절차에 대한 작은 스킬 컬렉션을 만들 수도 있습니다:

skills/
  architecture-review/
  api-review/
  database-migration-review/
  incident-analysis/
  release-check/
  security-review/

각 스킬은 일반 프레임워크가 알 수 없는 조직 고유한 지식을 인코딩합니다. 데이터베이스 마이그레이션 스킬은 롤백 분석, 테이블 잠금 분석, 인덱스 영향 리뷰, 마이그레이션 지속 시간 추정, 배포 순서, 이전 애플리케이션 버전과의 호환성을 요구할 수 있습니다. API 리뷰 스킬은 후방 호환성, 인증 체크, 페이지네이션 일관성, 멱등성 분석, 속도 제한 동작, OpenAPI 변경을 요구할 수 있습니다. 실용적인 경로: 실제로 사용하는 gstack 스킬부터 시작하여, 그 구조를 자체 skills/ 디렉토리로 복사하고, 자신의 규약에 맞게 체크 항목을 다시 작성하십시오.

네 가지 레이어: 스킬, 명세, 방법론, 오케스트레이터

네 가지 레이어가 이러한 도구의 대부분을 커버하며, 위에서 언급한 조합이 어떻게 맞물리는지 보여줍니다:

스킬은 “에이전트는 어떻게 행동해야 하는가?“에 답합니다

gstack, Superpowers, 및 사용자 정의 에이전트 스킬.

명세 시스템은 “우리는 정확히 무엇을 구축하는가?“에 답합니다

OpenSpec와 GitHub Spec Kit. 기반 명세 기반 개념과 용어는 명세 기반 개발이란 무엇인가?에서 정의됩니다.

방법론은 “프로젝트는 아이디어부터 소프트웨어로 어떻게 진행되어야 하는가?“에 답합니다

BMAD, Superpowers, gstack의 일부.

오케스트레이터는 “여러 에이전트는 작업을 어떻게 실행해야 하는가?“에 답합니다

Ruflo 및 기타 멀티 에이전트 런타임.

레이어는 구성됩니다. 개발 환경은 네 가지 모두를 포함할 수 있습니다:

gstack은 이미 이러한 경계 중 여러 곳에 걸쳐 있습니다.

gstack을 사용해야 하는가?

프로젝트의 README는 대상 독자를 여전히 출시하기를 원하는 기술적 창업자와 CEO, 빈 프롬프트 대신 구조화된 역할을 원하는 1차 Claude Code 사용자, 모든 PR에 엄격한 리뷰, QA, 릴리스 자동화를 원하는 기술 리드와 스태프 엔지니어라고 설명합니다. 코딩 에이전트를 광범위하게 사용하고 제한 요인이 더 이상 코드 생성 자체가 아니라면 gstack은 시도할 가치가 있습니다. 일반적인 증상:

• 에이전트가 문제를 이해하기 전에 구현을 시작함
• 구현 플랜이 아키텍처적 함의를 놓침
• 생성된 코드가 테스트를 통과하지만 브라우저에서 실패함
• 세션 간 리뷰가 일관되지 못함
• 릴리스 단계가 반복적으로 잊혀짐
• 다른 개발자가 완전히 다른 방식으로 에이전트에 프롬프트를 입력함
• 유용한 엔지니어링 지시사항이 CLAUDE.md 파일 속에 묻혀 있음
• 동일한 리뷰 프롬프트를 반복적으로 수동으로 타이핑함

자동화가 이미 강력한 결정론적 게이트를 제공하며 에이전트가 작고 잘 지정된 작업만 처리한다면, gstack은 거의 추가 가치를 제공하지 않습니다.

gstack과 AI 소프트웨어 개발의 방향

gstack이 속한 변화는 세대를 따라 추적합니다: 코드 완성(2022-2023), 코딩 에이전트(2024-2025), 명세 및 에이전트 워크플로(2025-2026), 프로그래머블 AI 엔지니어링 조직. 제품은 변할 것이지만, 모델은 여전히 한 구성 요소로 남아 있습니다. 엔지니어링 품질은 점차 주위의 시스템에 의존하게 됩니다:

• 영구 명세
• 재사용 가능한 스킬
• 저장소 지식
• 브라우저 액세스
• 테스트
• 결정론적 도구
• 리뷰 루프
• 보안 제어
• 메모리
• 인간 승인 경계
• 오케스트레이션

결론

gstack은 코딩 에이전트 주위의 엔지니어링 프로세스이며, 검사 가능하고 버전 관리되는 스킬로 패키징됩니다. 그 가치는 개별 스킬이 아니라 그 프로세스를 에이전트에 강제하는 데 있습니다.

시도 시퀀스로 시작하고 자신의 자리를 확보한 스킬만 유지하십시오. 그 너머의 방향은 구성 가능한 레이어 – 명세, 스킬, 결정론적 검증, 오케스트레이션 – 각자가 다른 것이 할 수 없는 일을 하는 것입니다.

참고 자료

• gstack 저장소 – 소스, 스킬 정의, 그리고 설정
• gstack 스킬 심층 분석 – 모든 스킬에 대한 철학, 예제, 워크플로
• Aside 브라우저 – macOS에서 gstack이 우선 구동하는 브라우저
• Superpowers 저장소 – 소스, 스킬, 플러그인 매니페스트
• OpenSpec 저장소 – 소스, 문서, CLI 패키지
• GitHub Spec Kit 문서 – 공식 Spec Kit 워크플로 참조
• BMAD-METHOD 저장소 – 적응형 AI 기반 애자일 방법론
• Ruflo 저장소 – 멀티 에이전트 오케스트레이션 플랫폼