요즘 AI 코딩 도구를 보면 대부분 “얼마나 잘 코드를 짜느냐”에 초점이 맞춰져 있다. 그런데 gstack은 방향이 조금 다르다. 이 프로젝트는 새 모델도 아니고 새 IDE도 아니다. Garry Tan이 공개한 오픈소스 워크플로 패키지로, README는 이를 “Claude Code를 가상 엔지니어링 팀으로 바꾸는 설정”이라고 설명한다. 23개의 역할 기반 스킬과 8개의 파워 툴을 슬래시 커맨드로 제공하고, 전부 Markdown 기반이며 MIT 라이선스로 배포된다.
핵심은 단순하다. gstack은 AI를 “코드 생성기”로만 보지 않고, CEO, 엔지니어링 매니저, 디자이너, 리뷰어, QA, 보안 담당자, 릴리스 엔지니어가 순서대로 붙는 작업 흐름으로 본다. README의 빠른 시작도 이 철학을 그대로 드러낸다. /office-hours로 문제를 다시 정의하고, /plan-ceo-review로 제품 방향을 점검하고, /review로 코드 리뷰를 돌리고, /qa로 실제 브라우저 테스트까지 이어간다. 즉 gstack은 프롬프트 모음이 아니라, “어떤 순서로 일해야 덜 망하는가”를 패키징한 도구에 가깝다.
도구가 아니라 프로세스
이 프로젝트가 흥미로운 이유도 바로 여기에 있다. README는 gstack을 “도구 모음이 아니라 프로세스”라고 설명하면서, 전체 흐름을 다음처럼 정의한다.
Think → Plan → Build → Review → Test → Ship → Reflect
그리고 각 스킬이 앞 단계의 산출물을 다음 단계로 넘긴다. /office-hours가 작성한 설계 문서를 /plan-ceo-review가 읽고, /plan-eng-review가 만든 테스트 계획을 /qa가 이어받고, /review가 잡아낸 문제를 /ship이 검증한다. 결국 gstack의 본질은 모델 성능 향상이 아니라, AI가 일하는 순서를 강제하는 것에 있다.
역할 기반 스킬 체계
스킬 구성을 보면 이 철학이 더 선명해진다.
예를 들어 /plan-eng-review는 아키텍처, 데이터 흐름, 상태 전이, 실패 모드, 엣지 케이스, 신뢰 경계, 테스트 커버리지까지 끌어내도록 설계돼 있고, 결과를 DESIGN.md와 CLAUDE.md에 반영해 이후 세션의 기준점으로 삼는다.
/review는 CI를 통과해도 프로덕션에서 터질 버그를 찾는 역할을 하고, /qa는 실제 앱을 테스트하면서 버그를 고치고 회귀 테스트까지 만든다. /cso는 OWASP Top 10과 STRIDE 기반 보안 점검을 수행하고, /document-release는 배포 뒤 문서까지 최신 상태로 맞춘다.
즉 한두 개 멋진 명령이 아니라, 기획부터 배포 이후 정리까지 이어지는 역할 체계가 들어 있다.
브라우저를 장수명 데몬으로 다루는 이유
기술적으로 가장 중요한 부분은 브라우저다. gstack의 아키텍처 문서는 “브라우저가 어려운 부분이고, 나머지는 Markdown”이라고 말한다.
이유는 명확하다. AI 에이전트가 브라우저를 매번 새로 띄우면 명령마다 3~5초를 기다려야 하고, 브라우저가 죽을 때마다 쿠키, 탭, 로그인 상태를 잃는다. 그래서 gstack은 장수명 Chromium 데몬을 띄워 두고, CLI가 이를 localhost HTTP로 호출하는 구조를 택했다.
문서에 따르면 첫 호출은 약 3초가 걸리지만, 그 이후 명령은 대체로 100~200ms 수준으로 돌아간다. 이 구조 덕분에 /browse나 /qa 같은 기능이 “느린 브라우저 자동화”가 아니라 실제 작업 흐름 안으로 들어온다.
Bun을 선택한 이유도 실용적이다
여기서 Bun을 쓴 이유도 꽤 현실적이다. 아키텍처 문서는 Node.js로도 가능하지만, Bun은 bun build --compile로 단일 실행 파일을 만들 수 있어서 런타임에 node_modules나 npx, PATH 설정이 필요 없다고 설명한다.
gstack이 설치되는 위치가 보통 ~/.claude/skills/인 만큼, 사용자에게 “또 하나의 Node 프로젝트를 관리하라”고 요구하지 않으려는 선택이다. 즉 gstack은 겉으로는 AI 워크플로지만, 내부적으로는 설치와 유지보수 비용을 낮추는 로컬 도구 설계까지 같이 고민한 프로젝트다.
Claude Code 전용으로 끝나지 않는다
또 하나 재미있는 점은 gstack이 Claude Code 전용으로만 끝나지 않는다는 점이다. README는 이 프로젝트가 SKILL.md 표준을 지원하는 에이전트라면 작동한다고 설명하고, 실제로 Codex, Gemini CLI, Cursor 같은 Codex 호환 호스트에 .agents/skills/gstack 형태로 설치할 수 있다고 적고 있다. 여기에 Factory Droid 지원까지 명시돼 있다.
즉 gstack은 특정 모델이나 특정 회사의 툴에만 묶인 확장팩이라기보다, 역할 기반 AI 워크플로를 여러 에이전트 런타임에 이식하려는 시도로 보는 편이 맞다.
가드레일도 과장 없이 설계됐다
안전장치도 꽤 공들인 흔적이 보인다. 문서에는 /careful, /freeze, /guard, /unfreeze 네 가지 가드레일이 있고, 이들은 Claude Code의 PreToolUse hooks를 통해 세션 단위로 동작한다고 적혀 있다.
/careful:rm -rf,DROP TABLE, 강제 푸시 같은 위험한 명령 전에 경고/freeze: 특정 디렉터리 밖 파일 수정이 일어나지 않도록 차단/guard,/unfreeze: 세션 상태에 맞춘 보호/해제 장치
물론 문서도 이를 보안 샌드박스가 아니라 “사고 예방 장치”라고 분명히 밝힌다. 이 태도도 좋다. 과장해서 만능 안전장치라고 말하지 않고, 어디까지 막고 어디까지는 못 막는지 선을 긋고 있다.
한 줄 요약
그래서 gstack을 한 줄로 요약하면 이렇다.
Claude Code를 잘 쓰는 법을 코드와 문서로 굳혀 놓은 오픈소스 운영 체계
보통 AI 코딩 도구는 빈 프롬프트 창을 던져 주고 사용자의 역량에 기대는 경우가 많다. 반면 gstack은 처음부터 누가 먼저 문제를 다시 정의하고, 누가 설계를 검토하고, 누가 QA와 보안을 맡고, 누가 릴리스를 책임질지까지 정해 둔다.
그래서 처음 Claude Code를 쓰는 사람에게는 구조를 주고, 테크 리드나 창업자에게는 리뷰와 품질 체계를 준다. README도 바로 이 세 부류를 주요 대상으로 적고 있다.
항상하는 말이지만 모두에게 맞는 도구는 아니다
물론 이게 모두에게 맞는 건 아니다. gstack은 꽤 강한 의견을 가진 도구다. 빈 대화창에서 자유롭게 AI를 쓰고 싶은 사람에게는 오히려 답답할 수 있고, 반대로 제품 정의, 설계, 리뷰, QA, 배포를 한 흐름으로 묶고 싶은 사람에게는 강력하다.
그래서 이 프로젝트의 진짜 경쟁력은 “코드를 더 잘 써준다”가 아니라, AI가 매번 제멋대로 움직이지 않도록 작업 질서를 만들어 준다는 데 있다. AI 시대의 생산성 차이가 점점 모델 성능보다 운영 방식에서 벌어진다면, gstack은 그 방향을 꽤 선명하게 보여주는 사례다.
