gstack: Claude Code를 ‘가상 엔지니어링 조직’으로 바꾸는 오픈소스 소프트웨어 팩토리

AI 코딩 도구는 이제 흔합니다.
하지만 대부분은 여전히 “코드 자동완성”이나 “프롬프트 잘 쓰는 법” 수준에 머물러 있습니다.

gstack은 접근이 다릅니다.
이 프로젝트는 AI를 더 똑똑한 코더로 만드는 데서 멈추지 않고, 아예 CEO, 엔지니어링 매니저, 디자이너, QA, 릴리즈 매니저 역할을 가진 팀처럼 운영하려고 합니다. 단일 에이전트가 아니라, 워크플로 자체를 역할 기반으로 쪼개고 연결한 운영체제에 가깝습니다. 저장소 설명 그대로 Claude Code를 위한 “15개의 전문가 + 6개의 파워 툴” 구조이며, 실제로 빠른 브라우저 자동화까지 포함합니다. 2026년 3월 20일 기준 이 저장소는 약 2.7만 스타를 받고 있습니다. (GitHub)

---

프로젝트 소개

gstack은 Garry Tan이 공개한 Claude Code용 오픈소스 스택입니다. 핵심은 두 가지입니다.

첫째, Markdown으로 정의된 역할 기반 스킬 집합입니다.
/office-hours, /plan-ceo-review, /plan-eng-review, /review, /qa, /ship 같은 슬래시 커맨드가 각각 제품 기획, 아키텍처 검토, 코드 리뷰, 브라우저 QA, 릴리즈를 담당합니다. 둘째, 이 스킬들이 의존하는 지속 실행형 headless browser 런타임입니다. 이 브라우저는 Playwright와 Chromium을 기반으로 하며, Bun으로 컴파일된 CLI가 localhost HTTP로 데몬과 통신하는 구조입니다. (GitHub)

이 프로젝트를 만든 사람은 Y Combinator의 CEO Garry Tan입니다. README에서 그는 gstack을 자신이 쓰는 “open source software factory”라고 설명하고, Claude Code를 실제로 관리 가능한 가상 엔지니어링 팀으로 바꾼다고 말합니다. 설치 요구사항은 Claude Code, Git, Bun v1.0+이며, 프로젝트를 ~/.claude/skills/gstack 또는 리포지토리 내부 .claude/skills/gstack에 넣어 쓰는 방식입니다. PATH를 건드리거나 백그라운드 서비스를 별도로 설치하지 않는 점도 설계 의도 중 하나입니다. (GitHub)

기술 스택은 꽤 선명합니다.
브라우저 레이어는 Playwright + Chromium, 런타임은 Bun, 구현 언어는 TypeScript, 브라우저 바이너리는 bun build --compile로 단일 실행 파일로 패키징됩니다. 여기에 테스트, 스킬 문서 생성, 평가용 스크립트가 함께 들어 있어 단순 프롬프트 저장소가 아니라 실행 가능한 로컬 에이전트 플랫폼에 가깝습니다. package.json에는 build, server, test, test:evals, gen:skill-docs, analytics 같은 스크립트가 명시돼 있습니다. (GitHub)

---

왜 이 프로젝트가 등장했을까

gstack이 흥미로운 이유는 “AI가 코드를 잘 짠다”가 아니라, AI 코딩의 병목이 코드 생성 자체가 아니라 운영 흐름에 있다는 전제를 깔고 있기 때문입니다.

보통 AI 코딩 도구를 쓰면 이런 문제가 반복됩니다.

1. 기능은 빨리 나오지만 방향이 자주 틀어진다.
2. 설계 검토가 생략되어 뒤늦게 구조가 무너진다.
3. QA가 약해서 실제 브라우저에서 깨진다.
4. 문서가 코드와 따로 놀기 시작한다.
5. 한 번의 대화로 끝나고 다음 단계로 문맥이 잘 이어지지 않는다.

gstack은 이 문제를 프롬프트 품질로 해결하지 않습니다. 대신 스프린트 프로세스 자체를 스킬 체인으로 모델링합니다. README에서도 Think → Plan → Build → Review → Test → Ship → Reflect 흐름을 강조하며, /office-hours가 쓴 디자인 문서를 /plan-ceo-review가 읽고, /plan-eng-review의 테스트 계획을 /qa가 이어받는 식으로 각 단계가 앞 단계 산출물을 다음 단계 입력으로 사용한다고 설명합니다. 즉, 이 프로젝트의 본질은 “더 잘 코딩하는 AI”가 아니라 개발 조직의 분업을 단일 개발자 워크플로로 압축하는 것입니다. (GitHub)

여기에 브라우저 자동화가 들어간 것도 같은 맥락입니다.
AI가 웹 앱을 고치려면 실제 화면을 보고, 버튼을 누르고, 로그인 세션을 유지하고, 다시 확인해야 합니다. 그런데 브라우저가 매번 cold start 되면 한 번 QA할 때마다 2~5초씩 날아갑니다. gstack은 이 문제를 해결하기 위해 지속 실행 브라우저 데몬을 둡니다. 첫 실행만 몇 초 걸리고, 이후 명령은 100~200ms 수준으로 왕복되도록 설계했습니다. 이건 단순 최적화가 아니라, 에이전트가 실제 제품 QA 루프를 감당하게 만드는 핵심 조건입니다. (GitHub)

---

핵심 아이디어: “프롬프트 모음집”이 아니라 “작은 조직 운영체제”

많은 AI 개발 도구가 프롬프트 세트를 공유하는 수준에 머문다면, gstack은 그보다 한 단계 위에 있습니다.

이 저장소를 보면 스킬들이 기능별 디렉터리로 나뉘어 있고, 각각 SKILL.md를 가집니다. 예를 들어:

• office-hours/
• plan-ceo-review/
• plan-eng-review/
• review/
• qa/
• ship/
• document-release/
• browse/

그리고 최상단 CLAUDE.md는 이 프로젝트 전체 개발 원칙을 정의합니다. 여기서 특히 중요한 건 다음 세 가지입니다.

1) 스킬은 하드코딩된 프레임워크 규칙이 아니라 프로젝트 설정을 읽는다

CLAUDE.md는 테스트 커맨드, 배포 커맨드, 프로젝트별 규칙 등을 스킬이 직접 가정하지 말고 CLAUDE.md에서 읽거나 사용자에게 묻고 다시 기록하라고 설명합니다. 즉, gstack은 범용 자동화가 아니라 프로젝트 문맥을 외부 설정으로 흡수하는 구조를 택합니다. (GitHub)

2) 스킬 문서는 코드처럼 생성되고 검증된다

SKILL.md는 직접 수정하지 않고 템플릿에서 생성하는 흐름이 들어 있습니다. gen-skill-docs.ts, skill-check.ts, 관련 테스트까지 갖추고 있어, 프롬프트 자산을 문서가 아니라 빌드 대상처럼 취급합니다. (GitHub)

3) 브라우저는 별도 데몬으로 분리된다

브라우저 자동화는 프롬프트 내부 명령이 아니라 독립 바이너리와 서버 구조를 가집니다. 이 때문에 스킬은 브라우저를 “툴”처럼 부를 수 있고, 반대로 브라우저 구현은 독립적으로 빠르게 개선할 수 있습니다. (GitHub)

---

핵심 기능 분석

1. /office-hours: 기능 정의 전에 문제 정의를 다시 쓰게 만드는 스킬

이 스킬은 “아이디어가 있는 상태”에서 시작합니다. 설명에 따르면 두 가지 모드가 있습니다. 하나는 스타트업형 진단 질문, 다른 하나는 빌더형 브레인스토밍입니다. 중요한 점은, 기능 요청을 그대로 받아 적지 않고 문제의 framing 자체를 재구성한다는 것입니다. README 예시에서도 “daily briefing app”이라는 요구를 “personal chief of staff AI”라는 더 본질적인 제품 정의로 바꿉니다. (GitHub)

개발자 관점에서 보면 이 스킬의 역할은 기획 보조가 아닙니다.
오히려 잘못된 요구사항으로 스프린트를 시작하는 비용을 줄이는 프론트 게이트에 가깝습니다.

예를 들어 이런 흐름입니다.

/office-hours

이후 AI는 바로 구현에 들어가지 않고, 문제의 고통 지점, 현재 대체 방식, 왜 지금 필요한지, 가장 좁은 웨지가 무엇인지를 다시 캐묻습니다. 이건 초반엔 느려 보여도, 뒤 단계에서 아키텍처 변경과 재작업을 줄이는 효과가 큽니다.

---

2. /plan-ceo-review와 /plan-eng-review: 제품 관점과 구조 관점을 분리한다

보통 한 번의 프롬프트 안에서 “제품적으로 맞는가?”와 “기술적으로 안전한가?”를 동시에 묻습니다. gstack은 이 둘을 분리합니다.

• /plan-ceo-review는 제품의 범위, 임팩트, 차별성, “10-star product” 가능성을 본다고 설명합니다.
• /plan-eng-review는 데이터 흐름, 다이어그램, edge case, 테스트 계획, hidden assumption을 드러내는 데 초점을 둡니다. (GitHub)

이 분리는 실제로 중요합니다.
AI가 코드를 빨리 쓰는 시대일수록, 무엇을 만들지와 어떻게 안전하게 만들지를 따로 검토해야 합니다. gstack은 그걸 역할 기반 워크플로로 강제합니다.

예시:

/plan-ceo-review
/plan-eng-review

여기서 얻는 이점은 단순 요약이 아니라, 뒤에 /review, /qa, /ship가 참조할 기준 문서를 미리 만들어 놓는 데 있습니다.

---

3. /review: “CI는 통과하지만 운영에서 터지는 문제”를 겨냥한 리뷰

README는 /review를 “Find the bugs that pass CI but blow up in production”이라고 정의합니다. 단순 린터나 타입 체크 보조가 아니라, 구조적 결함 리뷰어에 가깝습니다. 실제 review/SKILL.md를 보면 SQL 안전성, LLM trust boundary, conditional side effects, 문서 stale 여부, TODO 반영 여부 같은 체크를 diff 기반으로 수행하도록 설계되어 있습니다. 그리고 명백한 것은 자동 수정하고, 애매한 것은 사용자에게 물어보는 방식입니다. (GitHub)

이건 개발자에게 꽤 현실적인 포인트입니다.
AI가 낸 코드는 “돌아가는지”보다 “배포 후 어디서 틀어질지”가 더 중요합니다. gstack의 /review는 이걸 PR 전용 구조 점검 레이어로 둡니다.

예시:

/review

특히 인상적인 부분은, 리뷰가 끝난 뒤 Codex CLI가 있으면 독립적인 second opinion까지 연결하도록 만든 점입니다. 즉, 단일 모델 신뢰 대신 교차 모델 검증을 옵션으로 지원합니다. (GitHub)

---

4. /qa와 /browse: 에이전트에게 “눈”을 붙인다

gstack의 가장 강력한 차별점은 여기입니다.

/qa는 실제 앱을 브라우저에서 테스트하고, 버그를 찾고, 수정하고, 회귀 테스트까지 생성하는 역할입니다.
그리고 이 기능의 기반이 되는 것이 /browse입니다. /browse는 Playwright/Chromium 기반의 빠른 headless browser 도구이며, 실제 클릭, 입력, 스크린샷, 네트워크, 콘솔, 접근성 트리, 쿠키 가져오기까지 제공합니다. README는 이 도구가 대략 100ms 수준의 명령 응답을 목표로 한다고 설명합니다. (GitHub)

이 구조가 왜 중요한지 예제로 보면 바로 이해됩니다.

/qa https://staging.example.com

혹은 브라우저 바이너리를 직접 쓰면:

browse goto https://staging.example.com
browse snapshot -i
browse click @e3
browse fill @e7 "hello@example.com"
browse press Enter
browse console --errors
browse network
browse screenshot result.png

browse/src/commands.ts를 보면 이 도구가 단순 스크린샷기가 아니라는 걸 알 수 있습니다.
goto, click, fill, select, upload 같은 상호작용 명령뿐 아니라 console, network, cookies, storage, perf, snapshot, diff, responsive, pdf, chain 등 실제 QA 세션에 필요한 명령 세트가 잘 갖춰져 있습니다. (GitHub)

---

5. /ship와 /document-release: 코드 배포와 문서 갱신을 분리하지 않는다

AI 코딩에서 가장 자주 무너지는 것이 문서입니다.
코드는 금방 늘어나는데 README, ARCHITECTURE, CONTRIBUTING, CLAUDE.md가 금방 낡아버립니다.

gstack은 이걸 별도 스킬로 둡니다. /document-release는 변경된 코드와 문서 파일을 교차 검토해 프로젝트 문서를 최신 상태로 맞추는 역할이고, README에는 /ship이 이 과정을 자동 호출한다고 설명돼 있습니다. 즉, 릴리즈 과정에 문서 동기화를 포함시킨 것입니다. (GitHub)

이건 단순 친절함이 아니라 운영상 매우 중요합니다.
AI 시대에는 구현 비용보다 팀의 이해 비용이 더 빨리 커집니다. 문서를 자동으로 유지하려는 gstack의 방향은 꽤 실용적입니다.

---

프로젝트 아키텍처 분석

gstack의 내부 구조는 크게 두 층으로 나뉩니다.

1. 워크플로 스킬 층
2. 브라우저 런타임 층

상위 구조

이 흐름의 핵심은 각 스킬이 독립 도구가 아니라 앞 단계 산출물을 다음 단계 입력으로 연결하는 파이프라인이라는 점입니다. README가 “gstack is a process, not a collection of tools”라고 설명하는 이유가 바로 여기 있습니다. (GitHub)

브라우저 런타임 구조

ARCHITECTURE.md, cli.ts, server.ts를 합쳐 보면 browse 서브시스템은 다음처럼 동작합니다.

이 구조의 장점은 분명합니다.

• 브라우저를 매번 새로 띄우지 않는다
• 쿠키, 탭, localStorage가 유지된다
• CLI는 얇고, 서버는 상태를 가진다
• 서버가 죽어도 CLI가 상태 파일과 health check로 다시 살린다
• 바이너리 버전이 달라지면 자동 재시작한다 (GitHub)

왜 Bun인가

이 선택은 단순 취향이 아닙니다. ARCHITECTURE.md는 Bun을 고른 이유로 다음을 듭니다.

• 단일 컴파일 바이너리 생성
• 내장 SQLite 사용
• TypeScript를 바로 실행 가능한 개발 경험
• 가벼운 내장 HTTP 서버

즉, gstack은 “브라우저 자동화 서버를 최대한 설치 부담 없이 Claude Code 스킬로 배포”하려는 목적에 맞춰 Bun을 선택했습니다. 일반 Node.js 앱보다 도구형 배포에 더 유리하다는 판단입니다. (GitHub)

---

보안 모델도 꽤 신경 썼다

브라우저 도구가 쿠키를 다루기 때문에 보안이 허술하면 위험합니다. gstack은 이 부분을 생각보다 꼼꼼하게 설계했습니다.

• 서버는 localhost에만 바인딩
• 매 세션 랜덤 bearer token 발급
• 상태 파일은 owner-only 권한
• 브라우저 쿠키 DB는 복사본을 읽기 전용으로 열기
• 쿠키 값은 메모리에서만 복호화
• 서버 종료 시 키 캐시 제거 (GitHub)

완전한 보안 솔루션이라고 보긴 어렵지만, 적어도 “로컬 AI 도구니까 대충” 수준은 아닙니다. 특히 인증 세션을 다루는 /setup-browser-cookies 같은 기능을 넣으면서도 설계 근거를 문서화해 둔 점이 좋습니다.

---

저장소를 보고 느낀 진짜 포인트

이 프로젝트를 단순히 “Claude Code용 스킬 모음”으로 보면 핵심을 놓칩니다.
실제로는 세 가지가 합쳐져 있습니다.

1. 역할 기반 프롬프트 엔지니어링

각 스킬은 특정 직무를 모델링합니다.
CEO 리뷰, 엔지니어 리뷰, 디자인 리뷰, QA, 릴리즈 같은 역할 분업을 에이전트에 얹습니다. (GitHub)

2. 로컬 에이전트 인프라

browse는 실제 브라우저 실행 인프라이고, setup은 이를 빌드하고 Playwright Chromium을 준비하며 스킬 심볼릭 링크를 연결합니다. 즉, 프롬프트만이 아니라 실행 가능한 툴체인이 있습니다. (GitHub)

3. 운영 가능한 개발 프로세스

테스트, 문서 생성, eval, analytics까지 들어 있습니다.
CLAUDE.md를 보면 무료 테스트와 유료 eval을 구분하고, diff 기반 테스트 선택까지 넣어 둡니다. 이건 실험용 장난감보다는 실제로 계속 개선되는 워크플로 제품에 가깝습니다. (GitHub)

---

언제 쓰면 좋은가

gstack은 모든 팀에 맞는 만능 도구는 아닙니다.
하지만 아래 상황에는 특히 강합니다.

잘 맞는 경우

1인 개발자, 창업자, 기술 리드
혼자서 제품 방향, 설계, 구현, QA, 문서까지 다 챙겨야 할 때 가장 빛납니다. README도 이 대상을 명확히 겨냥합니다. (GitHub)

Claude Code를 처음 제대로 운영해보는 팀
빈 프롬프트에서 시작하면 무엇을 시켜야 할지 막막한데, gstack은 역할이 명확해서 진입 장벽을 낮춥니다. (GitHub)

웹 앱 중심의 제품 팀
실제 브라우저 QA와 세션 유지가 중요하기 때문에 프론트엔드나 풀스택 제품에서 체감이 큽니다. (GitHub)

덜 맞는 경우

매우 엄격한 사내 플랫폼 위에서만 돌아가는 팀
로컬 Claude Code, Bun, Playwright, 브라우저 세션 접근이 제한되면 도입 가치가 줄어듭니다. (GitHub)

비웹 백엔드만 다루는 조직
/browse, /qa의 강점이 줄어들기 때문에 일부 스킬만 쓰게 될 수 있습니다.

---

실제 사용 흐름 예시

이 프로젝트를 가장 잘 이해하는 방법은 한 번의 개발 루프를 상상해보는 것입니다.

# 1) 문제 정의 재구성
/office-hours

# 2) 제품 방향 검토
/plan-ceo-review

# 3) 설계/테스트 계획 수립
/plan-eng-review

# 4) 구현 후 구조 리뷰
/review

# 5) 스테이징 브라우저 QA
/qa https://staging.example.com

# 6) 릴리즈와 문서 동기화
/ship

이 흐름이 주는 핵심은 “AI가 코드를 써준다”가 아닙니다.
혼자 일해도 팀의 분업 구조를 흉내 낼 수 있다는 점입니다.

---

설치 구조도 깔끔하다

설치 방식도 꽤 실용적입니다.

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

setup 스크립트는 다음을 수행합니다.

• browse 바이너리 필요 시 빌드
• Playwright Chromium 설치/검증
• ~/.gstack 전역 상태 디렉터리 준비
• 각 스킬 디렉터리를 .claude/skills/ 아래에 심볼릭 링크 (GitHub)

여기서 좋은 점은 “설치 후 무엇이 생기는지”가 예측 가능하다는 겁니다.
Node 기반 도구들이 종종 남기는 전역 오염이 적고, Claude Code 중심 사용 시나리오에 맞춰져 있습니다.

---

한계도 분명하다

좋은 프로젝트지만 과장 없이 보면 한계도 있습니다.

첫째, Claude Code 중심 생태계에 강하게 묶여 있습니다.
범용 IDE 플러그인이나 SaaS 제품보다는 특정 사용 방식에 최적화돼 있습니다. (GitHub)

둘째, 워크플로의 품질은 여전히 모델 품질에 의존합니다.
gstack은 좋은 구조를 제공합니다. 하지만 구조가 있다고 해서 모든 결과물이 좋아지는 것은 아닙니다.

셋째, 운영 철학이 꽤 강합니다.
예를 들어 Boil the Lake 같은 완결성 지향 원칙은 빠르게 넓게 만드는 데는 좋지만, 팀 상황에 따라선 과한 자동화나 과도한 범위를 유도할 수도 있습니다. CLAUDE.md와 개별 스킬 프롬프트를 자신에게 맞게 조정할 필요가 있습니다. (GitHub)

---

총평

gstack은 단순한 “AI 프롬프트 모음집”이 아닙니다.
이 프로젝트의 진짜 가치는 AI 코딩을 기능 생성 단위가 아니라 개발 조직 운영 단위로 재정의했다는 데 있습니다.

• 기획은 /office-hours
• 제품 검토는 /plan-ceo-review
• 구조 검토는 /plan-eng-review
• 코드 검토는 /review
• 실제 브라우저 검증은 /qa
• 릴리즈와 문서 반영은 /ship, /document-release

그리고 이 모든 것을 뒷받침하는 빠른 브라우저 데몬이 있습니다.
즉, gstack은 “좋은 프롬프트”보다 좋은 개발 프로세스를 AI에 입힌 프로젝트입니다. (GitHub)

개인적으로 이 저장소에서 가장 인상적인 부분은, AI 시대의 개발 생산성을 “한 사람이 얼마나 빨리 코드를 쓰는가”가 아니라 한 사람이 얼마나 팀처럼 움직일 수 있는가로 바꿔 놓았다는 점입니다.

그 관점에서 gstack은 꽤 중요한 신호입니다.
앞으로의 AI 개발 도구는 IDE 안의 자동완성보다, 이런 역할 분업형 워크플로 엔진 쪽으로 더 많이 진화할 가능성이 큽니다.