gstack 해부 — 하네스 엔지니어링 실전 사례

gstack 자체는 GitHub 스타 6만 개짜리 인기 도구다. 하지만 여기서는 도구 소개가 아니라, gstack이 하네스 엔지니어링의 어떤 패턴을 구현하고 있는지를 해부한다.

1. 역할 기반 라우팅

gstack의 핵심은 하나의 모델을 23개 역할로 분리한 것이다. /review를 치면 Staff Engineer 역할이, /qa를 치면 QA Lead 역할이 활성화된다.

이건 오케스트레이션 패턴 중 "라우팅"이다. 개발자가 라우터 역할을 하고, 상황에 맞는 전문가를 수동으로 호출한다. 각 역할마다 시스템 프롬프트, 허용 도구, 출력 형식이 다르다.

같은 Claude 모델인데 /ceo로 호출하면 제품 전략을 논하고, /cso로 호출하면 OWASP 취약점을 스캔한다. 모델이 바뀐 게 아니라 하네스가 바뀐 것이다.

2. 파이프라인 오케스트레이션

/office-hours → /plan-ceo-review → /plan-eng-review → 코딩 → /review → /qa → /ship

이 순서가 gstack의 스프린트 파이프라인이다. 앞 단계의 출력이 다음 단계의 입력이 된다. /office-hours에서 작성된 디자인 문서를 /plan-ceo-review가 읽고, /plan-eng-review가 작성한 테스트 플랜을 /qa가 실행한다.

체이닝 패턴의 교과서적 구현이다. 각 단계에서 다른 전문가(프롬프트)를 쓰면서 정보가 누적되는 구조.

3. 가드레일 레이어

/careful — 위험 행동 전 확인 강화. /freeze — 특정 파일의 수정을 완전 차단. /guard — 전체 안전 모드.

이건 실행 단계 가드레일이다. 모델이 프로덕션 코드를 건드리거나, 테스트 없이 배포하거나, 보안 취약점을 만드는 걸 사전에 막는다.

4. 피드백 루프

/review가 버그를 찾으면 자동 수정한다. /qa가 실제 브라우저를 열어서 클릭하고, 에러를 발견하면 코드를 고치고 다시 검증한다.

"실행 → 결과 확인 → 수정 → 재실행"의 루프가 각 스킬 안에 내장되어 있다. 단순히 코드를 생성하고 끝나는 게 아니라, 결과를 보고 반복하는 에이전트 루프 패턴.

5. 컨텍스트 축적

/learn 스킬이 세션 간 학습 내용을 영구 저장한다. 프로젝트 패턴, 함정, 선호도가 쌓이면서 하네스가 프로젝트에 특화된다. /retro는 주간 성과를 정량 측정한다.

이건 컨텍스트 윈도우의 한계를 외부 저장소로 극복하는 패턴이다. CLAUDE.md와 같은 원리.

결국 뭐가 다른가

누군가는 Claude Code에 "이 레포의 버그 고쳐줘"라고 한다. gstack 사용자는 /plan-eng-review로 설계를 검증하고, 코딩 후 /review로 프로덕션 버그를 잡고, /qa로 브라우저 테스트를 돌리고, /ship으로 PR을 올린다.

모델이 같다. 차이는 하네스다. 60일간 60만 줄이라는 숫자가 그 차이를 증명한다.