gstack: Claude Code를 가상 엔지니어링 팀으로 바꾸는 23개의 역할별 슬래시 명령

배경과 문제 정의

2026년 3월 Andrej Karpathy는 팟캐스트에서 지난해 12월 이후 직접 코드를 거의 입력하지 않았다고 말했습니다. gstack의 README는 이 발언을 맨 앞에 둡니다. 여기서 새로운 문제가 드러납니다. 모델이 코드의 대부분을 쓸 수 있게 되면 병목은 "쓸 수 있는가"에서 "작업을 어떻게 조직하는가"로 옮겨 갑니다.

많은 사람은 Claude Code를 빈 입력창으로 처음 만납니다. 같은 모델이 어떤 사람에게는 몇 줄을 채워 주는 데 그치고, 다른 사람에게는 기능 하나를 통째로 만들어 줍니다. 차이는 모델보다 요청의 구조에서 나오는 경우가 많습니다. 구조가 없으면 결과가 들쑥날쑥하고, 리뷰와 테스트와 릴리스 규율 같은 실제 팀의 습관도 생기지 않습니다.

gstack은 바로 이 틈을 겨냥합니다. Y Combinator의 회장 겸 CEO인 Garry Tan이 garrytan/gstack 저장소로 공개했고, 라이선스는 MIT이며 GitHub 별은 약 13.5만 개입니다. 작성자는 이것을 매일 쓰는 오픈소스 소프트웨어 공장이라고 부릅니다. 대상 독자는 셋입니다. 직접 출시하고 싶은 기술 창업자, 빈 프롬프트 대신 구조화된 역할을 원하는 Claude Code 입문자, 모든 PR에 엄격한 리뷰와 QA와 릴리스 자동화를 원하는 기술 리더입니다.

핵심 아키텍처와 기술 원리

핵심 발상은 범용 모델 하나를 책임이 분명한 여러 역할로 나누는 것입니다. README에는 제품을 다시 생각하는 CEO, 아키텍처를 확정하는 엔지니어링 매니저, AI 티가 나는 허술한 디자인을 잡아내는 디자이너, 운영 환경의 버그를 찾는 리뷰어, 실제 브라우저를 여는 QA 리더, OWASP와 STRIDE 감사를 수행하는 보안 담당자, PR을 내보내는 릴리스 엔지니어가 나옵니다. 총수는 전문가 역할 23개와 보조 도구 8개입니다. 형태로 보면 gstack에는 백엔드 서비스도 새로운 런타임도 없습니다. README는 전부 슬래시 명령이고, 전부 Markdown이며, 무료이고, MIT 라이선스라고 밝힙니다. 따라서 각 역할은 미리 써 둔 프롬프트 파일이며, 해당 명령을 부르면 Claude Code가 불러옵니다. 이 설계에는 세 가지 결과가 따릅니다. 첫째, 진입 장벽이 매우 낮습니다. 파일을 Claude Code가 읽을 수 있는 위치에 두면 되고, README는 설정에 약 30초가 걸린다고 말합니다. 둘째, 감사하기 쉽습니다. 모든 동작이 글로 적혀 있어 한 줄씩 읽고 고치고 포크할 수 있습니다. 셋째, 가장 중요한 점으로 강제력이 없습니다. 역할은 프롬프트일 뿐이고, 모델이 따르는지는 모델에 달려 있습니다. 타입 시스템도 컴파일러도 없고, "보안 담당자"가 감사를 실제로 끝냈음을 증명하는 장치도 없습니다.

빠른 시작에도 같은 분업이 드러납니다. `/office-hours`로 만들 것을 설명하고, `/plan-ceo-review`로 아이디어를 검증하고, `/review`로 변경된 브랜치를 점검하고, `/qa`로 스테이징 URL이나 격리된 로컬 API, CLI, 작업, 웹훅을 시험합니다. 순서는 실제 팀을 닮았습니다. 요구 정리, 계획 리뷰, 코드 리뷰, 테스트, 릴리스입니다.

실용성과 검증 결과

이번 세션에서 보이는 스킬 목록을 보면 명령이 소프트웨어 수명 주기의 여러 단계를 덮습니다. 아이디어 정리(office-hours), 전략과 아키텍처와 디자인 리뷰(plan-ceo-review, plan-eng-review, plan-design-review), 디자인 시스템(design-consultation), 원인 조사(investigate), 테스트(qa, qa-only), 코드 리뷰(review), 시각 감사(design-review), 출시(ship, land-and-deploy), 문서 갱신(document-release), 회고(retro), 안전 장치(careful, freeze, guard)입니다. 명령당 약 100밀리초로 설명되는 헤드리스 브라우저도 QA와 스크린샷을 돕습니다.

가장 눈여겨볼 것은 QA 역할입니다. 많은 AI 코딩 흐름은 코드를 다 쓴 시점에서 멈춥니다. gstack은 실제 브라우저를 열어 화면 상태를 확인하라고 요구합니다. "될 것 같다"를 "되는 것을 봤다"로 바꾸는 것이며, 환각에 대한 현실적인 대비책입니다. careful, freeze, guard 같은 안전 장치도 쓸모가 있습니다. `rm -rf`나 강제 푸시 같은 위험한 작업 전에 경고하거나, 수정 범위를 한 디렉터리로 제한합니다.

분명히 말해야 할 사실이 있습니다. README에서 가장 눈에 띄는 숫자는 모두 작성자 본인이 낸 것입니다. 2026년의 논리적 코드 변경 속도가 2013년의 약 810배이며, 하루 11,417줄 대 14줄이라고 보고합니다. 4월 18일까지의 2026년이 이미 2013년 한 해의 240배에 이른다고도 하며, 대상은 공개와 비공개를 합친 40개 저장소입니다. AI 때문에 단순 줄 수가 부풀려진다는 점은 작성자도 인정하며, 이를 보정하는 방법론 문서를 제시합니다. 그래도 제3자가 재현한 적은 없고, 비공개 저장소는 외부에서 확인할 수 없습니다. 코드가 많다고 가치가 큰 것은 아니며, 성과를 gstack 하나의 덕으로 돌릴 수도 없습니다. 우리는 대조 실험을 하지 않았으므로 구체적인 개선 배수를 주장할 수 없습니다.

산업적 영향과 향후 전망

gstack의 의의는 알고리즘의 돌파가 아니라 그것이 보여 주는 관행에 있습니다. 팀의 절차를 공유 가능한 프롬프트 묶음으로 부호화하는 방식입니다. 코딩 규칙을 린트 설정에 쓰고 배포를 CI 스크립트에 써 온 흐름과 같은 계열이며, 대상이 에이전트로 바뀐 것입니다. 약 13.5만 개의 별은 바로 쓸 수 있는 에이전트 워크플로에 대한 큰 수요를 보여 줍니다.

위험도 드러납니다. 역할 프롬프트는 획일적으로 변하기 쉽고, 실제 프로젝트는 제약이 크게 달라서 그대로 베끼면 알맹이 없는 형식적 리뷰가 나올 수 있습니다. 검증이 강제되지 않으므로 리뷰 명령의 결론은 여전히 사람이 확인해야 합니다. 또한 명령이 Claude Code를 기준으로 만들어져 있어 다른 에이전트로 옮기려면 다시 써야 합니다.

앞으로는 두 방향이 유력합니다. 하나는 역할 프롬프트를 결정적인 실제 검사에 연결하는 것입니다. 예를 들어 보안 역할이 스캐너를 호출해 글 보고서만이 아니라 다른 사람이 검증할 수 있는 로그를 남기게 합니다. 다른 하나는 측정으로, 역할 기반 흐름이 있을 때와 없을 때의 결함률과 재작업률을 표본별 쌍 데이터로 비교하는 것입니다. 그런 증거가 나오기 전까지 신중한 평가는 이렇습니다. gstack은 설계가 좋고 비용이 거의 들지 않으며 시도해 볼 만한 워크플로 템플릿입니다. 다만 생산성 약속은 작성자의 자체 보고일 뿐 검증된 결론이 아닙니다.