AI에게 CEO, 엔지니어, QA 역할을 차례로 맡겨도 자동으로 독립된 전문가 팀이 생기지는 않습니다. 같은 모델이 다른 지침을 읽는 경우가 많기 때문입니다. 혼자 제품을 만들 때 더 중요한 것은 역할 이름이 아니라 앞 단계가 무엇을 확인했고, 무엇을 다음 단계로 넘겼는지 추적하는 일입니다. 이 글의 완료 과업은 기능 변경 하나를 골라 네 칸짜리 인수인계 원장을 만드는 것입니다.
먼저 원장 한 장을 만드세요
원장에는 질문, 결정, 설계 가정, 관찰 증거 네 칸만 둡니다. 각 칸에는 작성자 역할, 입력 문서, 결과 문서, 아직 모르는 점을 함께 적습니다. 여러 역할의 답을 한 요약문으로 합치지 않는 것이 핵심입니다. 의견이 관찰 결과처럼 보이거나, 계획의 예상 동작이 실제 테스트 결과처럼 굳어지는 일을 막을 수 있습니다.
2026년 8월 31일 확인한 gstack 공식 저장소는 Think→Plan→Build→Review→Test→Ship→Reflect 순서와 단계 간 산출물 전달을 설명합니다. 공식 VERSION 파일은 이날 1.75.0.0을 가리켰습니다. 버전과 스킬은 바뀔 수 있으므로 설치 당시 문서도 다시 확인해야 합니다.
첫째 칸: 문제를 질문으로 남깁니다
/office-hours는 여섯 가지 강제 질문으로 문제 정의를 흔들고 디자인 문서를 다음 단계에 넘깁니다. 여기서 남길 것은 “수요가 증명됐다”는 결론이 아니라 현재 대안, 실제 불편 사례, 가장 좁은 진입점, 답하지 못한 질문입니다. 사용자 인터뷰나 거래 데이터가 없다면 그 부재도 적습니다.
둘째 칸: 범위 결정을 별도로 기록합니다
/plan-ceo-review는 Expansion, Selective Expansion, Hold Scope, Reduction 중 검토 모드를 고릅니다. 채택한 범위뿐 아니라 기각한 기능과 이유를 남겨야 다음 단계가 임의로 되살리지 않습니다. 이 결과는 제품 책임자의 승인을 기다리는 제안이며, 사실 확인이나 구현 완료 표시가 아닙니다.
셋째 칸: 구현 전 가정을 드러냅니다
/plan-eng-review는 아키텍처, 데이터 흐름, 에지 케이스, 테스트를 계획에 적습니다. 예를 들어 결제 옵션 변경이라면 정상 흐름보다 중복 요청, 타임아웃, 웹훅 순서 역전, 재시도 뒤 상태를 먼저 씁니다. 테스트로 확인되지 않은 항목에는 가정 꼬리표를 유지합니다.
넷째 칸: 화면에서 본 것만 증거로 올립니다
/qa-only는 일반 /qa와 같은 방법으로 테스트하되 코드를 수정하지 않고 버그 보고서를 만듭니다. URL, 재현 단계, 기대 결과, 실제 결과, 스크린샷을 원장에 연결하세요. “코드를 고치지 않는다”가 “아무것도 바꾸지 않는다”는 뜻은 아닙니다. 클릭·폼 입력·메일 발송은 서비스 상태를 바꿀 수 있으므로 스테이징, 테스트 계정, 비실물 결제 환경에서만 실행합니다.
전달을 멈춰야 하는 세 조건
다음 단계는 입력 문서가 없거나, 결정권자가 범위를 승인하지 않았거나, QA 대상이 운영 환경뿐일 때 멈춥니다. 두 번째 의견이 필요하면 공식 문서에 안내된 /codex를 반론용으로 쓸 수 있지만, 합의가 사실 보증은 아닙니다. 의견 꼬리표를 유지하세요.
이제 기능 하나를 골라 원장 네 칸을 채우고, 각 칸의 미확인 항목이 다음 역할의 입력으로 실제 전달되는지 확인하세요. 네 답을 얻는 것이 아니라 네 종류의 산출물이 끊기지 않게 만드는 것이 역할 검토의 목적입니다.
확인한 공식 출처
- gstack README — 확인일 2026-08-31
- gstack VERSION — 확인일 2026-08-31