이번 주 깃허브에서 “AI 코딩 에이전트” 관련 글을 보면, 코드만 뽑는 도구가 아니라 개발팀처럼 굴리는 프레임워크 얘기가 자주 보인다. 특히 Claude Code에서 슬래시 명령으로 작업을 이어가며, 아이디어부터 배포까지 한 흐름으로 돌린다는 설명이 반복된다.
GStack: Garry Tan이 공개한 23개 스킬팩과 7만+ 스타
YC(Y Combinator) 대표이자 엔지니어 출신인 Garry Tan이 자신의 AI 코딩 워크플로우를 오픈소스로 공개했다. GStack은 Claude Code를 “코드 생성 도구”로만 쓰지 않고, CEO·디자이너·엔지니어·QA 담당자로 구성된 가상의 소프트웨어 팀처럼 작동하게 만드는 skill pack(스킬 묶음)이라고 설명했다. 공개 3주 만에 Ruby on Rails보다 많은 GitHub 스타를 기록했으며, 현재 7만 개 이상의 스타를 보유 중이라고 밝혔다.
GStack은 “얇은 껍데기, 두꺼운 스킬” 설계를 따른다고 했다. 별도의 복잡한 런타임 없이, 마크다운 기반의 구조화된 프롬프트(지시문)만으로 동작하며, 모든 스킬은 Claude Code의 기존 슬래시 명령어 체계 위에서 실행된다고 했다. 23개의 전문 스킬은 “생각하기 → 계획 → 구축 → 리뷰 → 테스트 → 배포 → 회고”라는 소프트웨어 개발 전체 주기를 커버하며, 각 스킬의 출력이 다음 단계 입력으로 이어지는 스프린트 구조를 갖는다고 설명했다.
Claude Code 슬래시 명령 위에 ‘스프린트 라이프사이클’을 얹는 방식
예전에는 AI 코딩 도구가 코드 작성이나 리뷰 같은 한 구간에 집중하는 경우가 많았다. 이제 GStack은 아이디어 검증부터 배포까지 전 과정을 스킬로 쪼개 연결하는 쪽에 무게를 둔다. 비유하자면, 예전 도구는 “한 파트만 맡는 프리랜서”에 가깝다면, GStack은 “회의-설계-구현-검수-출시까지 역할을 나눠 진행하는 팀”을 프롬프트로 흉내 내는 쪽이다.
또한 Office Hours 스킬은 YC 파트너의 사고방식을 모사한다고 했다. 아이디어 단계에서 “이걸 실제로 원하는 사람이 있다는 가장 강력한 증거가 뭔가요?” 같은 강제 질문으로 제품 방향을 다듬고, 사업 모델과 실현 가능성까지 검토한다고 설명했다. 적대적 리뷰(adversarial review) 기능은 설계 문서를 자동으로 검증하며, 실패 처리 누락, 프라이버시 미비, 2단계 인증 핸드오프 미해결 같은 이슈를 다단계 검토로 포착하고 수정을 시도한다고 했다.
차별점도 구체적으로 제시됐다. GStack은 Claude Code뿐 아니라 OpenAI Codex CLI, Cursor, OpenCode 등 8개의 AI 코딩 에이전트를 동시에 지원하며, 특정 벤더에 종속되지 않도록 했다고 했다. /codex 명령어로 교차 모델 리뷰가 가능해 Claude와 OpenAI Codex CLI의 독립적인 리뷰를 비교하고, 한 모델이 놓치는 문제를 다른 모델이 잡아내도록 설계했다고 설명했다.
Playwright 기반 브라우저 QA와 병렬 PR 처리, 팀 설치 모드
개발자가 바로 체감하는 변화는 “코드가 맞는지”를 넘어 “실제로 화면에서 동작하는지”를 확인하는 흐름이 들어간다는 점이다. GStack은 Playwright(브라우저 자동화 도구) 기반의 실제 브라우저 QA를 내장하고, /qa 명령어로 실제 Chromium 브라우저를 열어 클릭·입력·스크린샷 캡처를 수행한다고 했다. 회귀 테스트를 자동으로 생성하고 커밋하며, 기존 Chrome MCP(브라우저 관련 도구)의 느린 응답과 컨텍스트 비대화 문제를 CLI 래핑으로 우회한 결과물이라고 밝혔다.
병렬 작업도 강조됐다. Garry Tan은 10~15개의 Claude Code 세션을 동시에 실행하고, 하루에 50개까지 PR(코드 변경 요청)을 처리한다고 말했다. 워크트리(work tree) 기반으로 각각 독립된 브랜치에서 작업이 진행된다고 했다. 팀 설치 모드(./setup --team)가 제공되며, 세션 시작 시 자동 업데이트되고 프로젝트 저장소에 별도 파일이 추가되지 않아 팀 단위 도입이 비교적 수월하다고 설명했다.
MIT 라이선스의 완전한 오픈소스이며, 별도 비용이나 구독 없이 사용할 수 있고 커뮤니티 기여가 활발하다고 했다. 다만 한계도 함께 적었다. 워크플로우에 강한 의견(opinionated)이 반영돼 있어, 모든 팀 문화와 맞지 않을 수 있다고 했다. 또한 “60일간 60만 줄 이상의 코드” 작성 주장은 검증이 어렵고, AI 생성 코드의 품질과 유지보수성은 별개의 문제라고 했다. 모델 자체의 한계를 구조로 보완하는 접근이므로, 모델이 똑똑하지만 방향을 못 잡을 때 구조가 씌워주는 역할이며 근본적 한계를 해결하진 않는다고 했다.
GStack은 AI 코딩의 병목이 ‘모델 지능’보다 ‘프로세스 부재’일 수 있다는 관점을 프롬프트 스킬로 밀어 넣는다. 그래서 도구를 바꾸기보다, 개발팀의 역할 분담을 작업 흐름에 먼저 붙이는 쪽으로 무게중심이 이동한다.




