요즘 AI 코딩에서 흥미로운 질문은 “어떤 모델이 제일 좋으냐”보다 “어떤 워크플로가 이 모델들을 더 안정적으로 유용하게 만드느냐”에 더 가깝습니다.
그래서 gstack이 흥미롭습니다. 단순 프롬프트 모음이 아니라, Claude Code에 planning, review, QA 역할을 나눠주는 워크플로 레이어에 가깝기 때문입니다.
실제로 작은 기능을 만들며 써보면서, 아래 질문에 답해보려고 했습니다.
gstack이 실제로 무엇인가- 워크플로가 실제로 어떤 느낌인가
- 직접 프롬프트만 쓰는 것보다 언제 더 나은가
gstack이 무엇인가
gstack은 Garry Tan이 공개한 Claude Code용 오픈소스 워크플로 레이어입니다.
AI 코딩을 하나의 긴 대화로만 처리하지 않고, 이런 역할형 명령으로 나눕니다.
- 아이디어 정리
- 계획 수립
- 엔지니어링 리뷰
- QA와 브라우저 검증
중요한 건, AI 코딩을 하나의 채팅창보다 작은 엔지니어링 팀처럼 움직이게 하려는 시도라는 점입니다.
왜 워크플로라는 개념이 중요한가
많은 AI 코딩 세션은 문제 정의가 아직 흐린데도 바로 출력부터 만들기 시작해서 망가집니다.
gstack이 흥미로운 이유는 팀이 보통 비싼 실수를 하는 지점에 프로세스를 넣기 때문입니다.
- 범위를 너무 느슨하게 잡는 것
- 계획 검증 없이 바로 코딩 들어가는 것
- 제대로 검증하지 않고 배포하는 것
그래서 이건 생성 도구이면서 동시에 프로세스 도구입니다.
설치와 첫인상
설치는 간단한 편이었습니다.
git clone https://github.com/garrytan/gstack.git ~/.claude/skills/gstack
cd ~/.claude/skills/gstack
./setup설치가 끝나면 Claude Code 안에 여러 명령이 생기는데, 느낌은 “기능이 늘었다”보다 “구조가 생겼다”에 더 가깝습니다.
실제로 써보며 좋았던 점
작은 기능을 처음부터 끝까지 만들어보며 테스트했습니다.
1. /office-hours가 문제 정의를 더 좋게 만들었다
바로 구현으로 들어가지 않고, /office-hours가 먼저 요청의 형태를 다시 밀어붙이는 점이 좋았습니다.
특히 이런 부분을 다시 보게 만듭니다.
- 문제 정의가 충분히 명확한가
- 사용자 pain이 실제로 있는가
- 기능 범위가 너무 막연하지 않은가
제품 감각이 필요한 작업에서는, 이 단계가 바로 코드 생성보다 더 가치가 있을 때가 많습니다.
2. review 명령이 생산적인 마찰을 준다
/plan-ceo-review, /plan-eng-review는 워크플로를 확실히 강하게 만들었습니다.
코드가 나오기 전에 이런 질문을 던지게 해줍니다.
- 범위가 적절한가
- 구조가 맞는가
- 가치가 있는가
- 구현 리스크가 무엇인가
그래서 “빨리 코드를 뽑는다”보다 “잘못된 결정을 줄인다”는 느낌이 더 강했습니다.
3. /qa가 흐름을 진짜처럼 만든다
가장 차별점이 느껴진 부분은 QA였습니다.
브라우저 기반 검증과 확인이 같은 워크플로 안에 들어오면, AI 사용이 단순한 diff 작성이 아니라 실제 개발 루프에 훨씬 가까워집니다.
이 지점이 직접 프롬프트만 쓰는 방식과 가장 크게 달랐습니다.
직접 프롬프트보다 강한 순간
직접 프롬프트는 여전히 이런 작업에 아주 좋습니다.
- 작은 버그
- 빠른 실험
- 짧은 리팩터
반면 gstack이 더 매력적인 순간은 아래와 같습니다.
- 범위가 필요한 planning
- review checkpoint가 필요한 작업
- 역할 분리가 도움이 되는 작업
- QA 단계를 명시적으로 포함해야 하는 작업
즉, 작업 크기와 모호성이 커질수록 더 가치가 올라갑니다.
무겁게 느껴질 수 있는 순간
구조는 유용하지만 비용이 없지는 않습니다.
gstack이 무겁게 느껴질 수 있는 경우는 이런 때입니다.
- 작업이 아주 작을 때
- 결과가 이미 너무 분명할 때
- 추가 review 단계가 결정 품질을 거의 바꾸지 않을 때
그래서 모든 작업에 무조건 덮어쓰는 래퍼라기보다, 선택적으로 꺼내 쓰는 워크플로로 보는 편이 맞습니다.
누구에게 잘 맞는가
직접 써본 기준으로는 이런 사람에게 특히 잘 맞습니다.
- 제품 기능을 빠르게 만들고 싶은 솔로 파운더
- AI 코딩에도 어느 정도 프로세스를 넣고 싶은 개발자
- 역할 기반 agent workflow를 실험하는 팀
반대로 빠른 자동완성이나 짧은 버그 수정만 원한다면 과하게 느껴질 수 있습니다.
최종 평가
직접 써본 뒤 내린 결론은 이렇습니다. gstack의 진짜 가치는 “더 좋은 원샷 프롬프트”가 아니라, planning과 verification까지 포함한 반복 가능한 프로세스를 준다는 데 있습니다.
그래서 출력 속도만이 아니라 결정 품질까지 올리고 싶은 사람에게 더 흥미로운 도구입니다.
도입 전에 봐야 할 것
진짜 질문은 설치가 쉬운가보다, 팀이 이 추가 프로세스를 원하느냐입니다.
아래를 중요하게 보는 팀이라면 잘 맞습니다.
- 의도적인 범위 설정
- 구현 전 review
- planning과 QA의 분리
반대로 최소 오버헤드와 빠른 one-off 수정이 더 중요하면, 직접 프롬프트가 여전히 더 좋은 기본값일 수 있습니다.
FAQ
Q. gstack은 그냥 프롬프트 모음인가요?
그보다는 planning, review, QA 흐름을 포함한 워크플로 구조에 더 가깝습니다.
Q. 작은 작업에도 매번 쓰는 게 좋나요?
보통은 아닙니다. 작업이 모호하거나 제품 범위가 있는 경우에 더 잘 맞습니다.
Q. 누가 가장 큰 이득을 보나요?
AI를 단순 자동완성이 아니라, 가벼운 엔지니어링 프로세스처럼 쓰고 싶은 사람입니다.
Read Next
- 워크플로 평가라는 더 큰 개념이 궁금하다면 Harness Engineering Guide로 이어가세요.
- Claude Code 자체의 skill 활용이 궁금하다면 Claude Code Skills Guide도 자연스럽습니다.
Related Posts
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.
먼저 읽어볼 가이드
검색 유입이 많은 핵심 글부터 이어서 보세요.
- 미들웨어 트러블슈팅 가이드: Redis vs RabbitMQ vs Kafka 개발자를 위한 미들웨어 트러블슈팅 허브 글입니다. Redis, RabbitMQ, Kafka 중 어떤 증상부터 먼저 봐야 하는지와 어떤 문제 패턴이 각 시스템에 가까운지 정리합니다.
- Kubernetes CrashLoopBackOff: 먼저 볼 것들 startup failure, probe, config, resource limit 관점에서 CrashLoopBackOff를 어떻게 나눠서 봐야 하는지 정리한 가이드입니다.
- Kafka consumer lag가 계속 늘 때: 트러블슈팅 가이드 Kafka consumer lag가 계속 늘어날 때 무엇부터 봐야 하는지 정리합니다. poll 주기, 처리 속도, rebalance, consumer 설정까지 실전 기준으로 다룹니다.
- Kafka Rebalancing Too Often 가이드 Kafka consumer group에서 rebalance가 너무 자주 일어날 때 membership flapping, poll timing, protocol, assignment churn을 어떤 순서로 봐야 하는지 설명하는 실전 가이드입니다.
- Docker container가 계속 재시작될 때: 먼저 확인할 것들 exit code, command failure, environment mistake, health check 관점에서 Docker restart loop를 푸는 실전 가이드입니다.
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.