gstack의 /ship은 리뷰가 끝난 코드를 클로드코드(Claude Code)가 테스트, 버전 올리기, 체인지로그 작성, 커밋, 푸시, PR 생성까지 한 줄로 내보내주는 무료 오픈소스 배포 스킬이에요. 멈추는 지점이 정해져 있어서 충돌, 테스트 실패, 큰 버전 변경 같은 판단만 사람에게 묻고 나머지는 알아서 진행해요. 실제 서비스 중인 앱 브랜치(커밋 5개, 파일 71개)에 돌려봤더니 사람이 답한 건 2번, 도구 실행 시간은 합쳐서 8초였어요. 클로드코드 스킬 시리즈 6편이에요.
지난 리뷰 스킬 편에서 배포 직전 코드를 AI 리뷰어에게 맡겨봤죠. 이번 편은 그 다음 단계, 리뷰 끝난 코드를 실제로 내보내는 이야기예요. “커밋 메시지 뭐라고 쓰지, 버전은 올려야 하나, 체인지로그는 언제 쓰지” 하다가 반나절 보내는 분이라면 이 글이 맞아요.
배포는 왜 코딩보다 잡일이 많은가요?
코드를 다 짜면 끝인 줄 알았는데, 내보내는 데 손이 더 가요. 기준 브랜치를 최신으로 맞추고, 테스트 돌리고, 버전 번호 올리고, 체인지로그 쓰고, 커밋 쪼개고, 푸시하고, PR 설명까지 써야 해요.
순서를 하나라도 빼먹으면 나중에 티가 나요. 버전을 안 올리고 배포하면 어떤 빌드가 도는지 모르게 되고, 커밋 하나에 파일 50개를 몰아넣으면 문제가 생겼을 때 어디서 깨졌는지 못 찾아요.
저는 이 잡일을 매번 다르게 해서 더 문제였어요. 혼자 개발하니까 규칙을 정해도 지키는 사람이 저뿐이고, 그 저는 자주 까먹거든요.
gstack /ship은 어떻게 동작하나요?
/ship은 리뷰 스킬(/review), QA 스킬(/qa)과 같은 gstack 패키지에 들어있어요. 이미 설치했다면 추가 설치 없이 클로드코드에서 /ship 한 줄이면 돼요. 배포 체크리스트를 AI가 대신 밟는 구조예요.
스킬 정의 파일에는 단계가 20개 넘게 적혀 있는데, 크게 다섯 묶음이에요.
- 준비: 지금 브랜치가 기준 브랜치(main)인지 확인하고, 기준 브랜치 최신 내용을 먼저 합쳐요. 합친 상태에서 테스트를 돌리기 위해서예요
- 테스트: 테스트 도구가 있으면 돌리고, 없으면 “세팅할까요?” 하고 물어봐요. 커버리지가 부족하면 테스트를 만들어 붙이기도 해요
- 리뷰: 지난 편의 /review가 이 안에서 한 단계로 돌아요. 최근 7일 내 리뷰 기록이 있으면 그걸 인정하고 넘어가요
- 버전과 로그: 변경 크기를 보고 버전 번호를 정하고, 커밋 내역을 읽어서 CHANGELOG를 자동으로 써요
- 커밋, 푸시, PR: 바뀐 파일을 주제별로 쪼개서 커밋하고, 푸시하고, 요약과 리뷰 결과가 담긴 PR을 만들어요
핵심은 멈추는 지점이 정해져 있다는 거예요. 충돌이 나거나, 테스트가 실패하거나, 리뷰에서 사람 판단이 필요한 항목이 나오거나, 버전을 크게(minor/major) 올려야 할 때만 물어봐요. 커밋 메시지나 체인지로그 문구는 안 물어보고 그냥 써요.
그리고 merge는 안 해요. PR을 만드는 데까지가 스킬의 일이고, 합치는 버튼은 사람이 눌러요. 리뷰 스킬이 커밋을 안 하는 것과 같은 선이에요.
실측: 실제 앱 브랜치에 돌린 결과는?
대상은 지난 편과 같은 COSMO 미니앱 저장소예요. main에서 갈라진 뒤 커밋 5개가 쌓인 브랜치고, 파일 71개가 바뀌었어요. 실제 저장소를 건드리지 않으려고 같은 상태를 복제한 작업 트리에서 돌렸고, 마지막 푸시와 PR 생성만 뺐어요. 2026년 9월 4일, gstack 1.55 버전 기준이에요.
| 단계 | 결과 | 시간 |
|---|---|---|
| 기준 브랜치 병합 | 이미 최신, 할 일 없음 | 0.06초 |
| 테스트 (eslint) | 오류 0건 | 4.3초 |
| 테스트 프레임워크 | 없음, 세팅 제안 (사람 판단) | – |
| 리뷰 준비 상태 | 지난 편 리뷰 기록 인정 (CLEAR) | – |
| 버전 | 0.0.0.0에서 0.1.0.0 (기능 추가라 minor, 사람 승인) | – |
| VERSION, CHANGELOG | 파일 2개 새로 생성 | – |
| 커밋 | 1건 (버전, 로그) | 3초 |
| 푸시, PR | 이번 실측에서 생략 | – |
결론부터요. 사람이 답한 건 딱 2번, 도구가 돈 시간은 합쳐서 8초였어요. 나머지는 AI가 커밋 내역을 읽고 체인지로그를 쓰는 시간이었어요.
제일 좋았던 건 체인지로그예요. 커밋 5개를 읽고 “추가 2개, 수정 2개, 변경 1개”로 분류해서 사용자 관점 문장으로 써줬어요. “구형 웹뷰에서 상품 그리드 컬럼이 밀리던 문제” 같은 식이에요. 제가 직접 썼으면 “버그 수정” 한 줄로 끝났을 거예요.
의외였던 건 변경량 계산이에요. 파일 71개에 5만 줄이 추가됐다고 나와서 놀랐는데, 실제로는 패키지 잠금 파일 2만 7천 줄과 문서 1만 5천 줄이 84%였어요. 스킬은 이걸 그대로 “큰 변경”으로 보고 minor 버전을 제안했는데, 사람이 보면 실제 코드는 8천 줄 정도예요. 버전 승인을 사람이 하게 되어 있는 이유가 여기 있어요.
아쉬운 점도 있어요. 이 저장소엔 테스트 프레임워크가 없어서 “세팅할까요?”에서 한 번 멈췄어요. 테스트가 있는 저장소였다면 커버리지 점검까지 자동으로 돌았을 텐데, 그 부분은 실측하지 못했어요.
/ship은 언제 쓰면 좋을까요?
| 상황 | 추천 | 이유 |
|---|---|---|
| 혼자 개발, 배포 규칙 자주 까먹음 | 매번 | 순서를 스킬이 기억해요 |
| 파일 수십 개 한 번에 바꿨을 때 | 매번 | 주제별로 쪼개 커밋해줘요 |
| 체인지로그 쓰기 싫을 때 | 매번 | 커밋 읽고 대신 써요 |
| 파일 한두 개 오타 수정 | 생략 가능 | 그냥 커밋이 빨라요 |
제 기준은 이거예요. /review 통과했으면 바로 /ship. 둘을 붙여 쓰면 “검토하고 내보내는” 과정이 명령 두 줄이 돼요.
gstack /ship 설치 방법은?
gstack 패키지 하나에 /ship이 들어있어요. 설치 방법은 QA 스킬편에서 다뤘으니 그 글을 참고하세요. git 저장소와 GitHub(또는 GitLab) 원격이 있어야 PR 단계까지 돌아요.
출처: gstack 공식 저장소 github.com/garrytan/gstack (MIT 라이선스, 무료). 이 글의 실측은 2026년 9월 4일, gstack 1.55 버전 기준이에요.
자주 묻는 질문
Q. 정말 안 물어보고 커밋해버리나요?
네, 커밋 메시지와 체인지로그는 안 물어봐요. 대신 푸시 전에 검증 단계가 있고, 합치는(merge) 건 절대 안 해요. 마음에 안 들면 PR을 닫으면 돼요.
Q. 버전 번호 체계가 특이하던데요?
네 자리(0.1.0.0)를 써요. 마지막 자리는 아주 작은 수정용이에요. 50줄 미만이면 마지막 자리, 그 이상이면 세 번째 자리를 자동으로 올리고, 새 기능이 보이면 두 번째 자리를 올릴지 물어봐요.
Q. 테스트가 없는 프로젝트도 되나요?
돼요. 대신 처음에 “테스트 도구 세팅할까요?” 하고 물어봐요. “이 프로젝트는 테스트 안 함”을 고르면 다음부터는 안 물어봐요.
Q. 리뷰 스킬을 따로 돌려야 하나요?
아니요. /ship 안에서 리뷰가 한 단계로 돌아요. 다만 7일 안에 /review를 따로 돌린 기록이 있으면 그걸 인정하고 넘어가서 시간을 아껴요.
스킬 시리즈 한 바퀴 정리
클로드코드 스킬 시리즈는 이걸로 만들기(ponytail), 이해하기(graphify), 검토하기(review), 내보내기(ship)까지 한 바퀴를 돌았어요. 혼자 개발하는 분들은 다음 배포 때 /ship 한 번 돌려보세요. 스킬 개념이 낯설다면 스킬 개념편부터 보세요.
Leave a Reply