사례: gstack

gstack은 하네스를 개념 프레임보다 실행 프로세스로 더 강하게 보여줍니다. 핵심은 "에이전트를 많이 두자"가 아니라, 병렬 작업이 혼란이 되지 않도록 sprint 구조를 먼저 고정한다는 점입니다.

해결하려는 문제

• 병렬 에이전트가 늘수록 누가 뭘 하는지 모호해짐
• build까진 되는데 review, QA, ship 단계가 빠짐
• release 직전 인간이 모든 혼란을 수습해야 함

기술적 메커니즘

gstack의 메시지는 매우 명확합니다.

Think -> Plan -> Build -> Review -> Test -> Ship -> Reflect

이 구조가 load-bearing인 이유는, 여러 에이전트가 동시에 움직여도 멈춰야 할 지점과 넘겨야 할 산출물이 분명해지기 때문입니다.

왜 이게 엔지니어링인가

gstack은 하네스를 일종의 software factory로 다룹니다. 즉, 작업을 역할과 단계로 분해해서 병렬화 가능성을 높이되, 검증과 배포를 후행 ritual이 아니라 명시적 단계로 둡니다.

이건 단순 체크리스트가 아니라 생산 파이프라인 설계입니다.

command-driven workflow의 장점

강한 opinion의 하네스는 보통 아래처럼 command surface를 갖습니다.

/think     -> 문제 재정의, 리스크 식별
/plan      -> 범위와 구현 전략 고정
/build     -> 구현 시작
/review    -> 설계/보안/코드 리뷰
/test      -> 브라우저/회귀 테스트
/ship      -> 배포 준비, 릴리즈 노트
/reflect   -> 배운 점 기록

이 표면이 중요한 이유는 작업자의 머릿속에만 있던 절차를 공통 인터페이스로 내리기 때문입니다.

review/test/ship를 분리하는 이유

많은 팀이 build까지만 자동화하고, review/test/ship은 사람의 후속 작업으로 남겨둡니다. gstack이 유용한 이유는 이 구간을 별도 단계로 존중한다는 데 있습니다.

release_gate:
  review:
    required: true
  test:
    required:
      - "lint"
      - "typecheck"
      - "browser smoke"
  ship:
    requires_release_note: true
    requires_owner_ack: true

이렇게 분리해야 "구현 완료"와 "출시 가능"이 같은 말이 아니게 됩니다.

병렬 에이전트가 chaos가 되지 않으려면

gstack README가 강조하는 포인트를 엔지니어링적으로 번역하면 이렇습니다.

1. 단계가 먼저 있고, 병렬화는 그 다음입니다.
2. 각 단계는 출력 포맷이 있어야 합니다.
3. check-in이 필요한 의사결정 포인트가 명시돼야 합니다.

우리 팀으로 옮길 것

그대로 복제하면 안 되는 점

• opinionated flow가 팀 맥락과 다르면 저항이 큽니다.
• 모든 작업을 full sprint로 돌리면 과한 의식이 됩니다.
• command 이름보다 각 단계의 출력 계약이 더 중요합니다.

gstack 사례의 진짜 교훈은, 하네스를 실행 가능한 sprint 구조로 만들면 병렬성이 chaos가 아니라 throughput이 된다는 점입니다.

참고

• gstack README, 2026-04-01 열람 기준