gstack의 /review는 배포 직전 코드를 클로드코드(Claude Code)가 PR 리뷰어처럼 점검해주는 무료 오픈소스 코드 리뷰 스킬이에요. 변경분만 읽어서 치명 5종을 체크하고, 공격자 시점 에이전트를 따로 돌리고, 발견마다 확신도 점수를 붙여요. 실제 서비스 중인 앱 코드 73줄에 돌려봤더니 치명 이슈 0건, 정보성 6건이 약 4분 만에 나왔고, 그중 하나는 제가 출시 전에 지우려고 메모해둔 바로 그 코드였어요. 클로드코드 스킬 시리즈 5편이에요.
앞선 rtk, ponytail, graphify 세 편이 토큰을 아끼는 이야기였다면, 이번 편은 만든 코드를 내보내기 전에 한 번 더 보는 이야기예요.
혼자 개발하면 왜 리뷰어가 필요한가요?
회사에서는 코드를 합치기 전에 동료가 PR 리뷰를 해줘요. 내가 못 본 실수를 다른 눈이 잡아주는 거예요. 그런데 1인 개발이나 사이드 프로젝트는 그 눈이 없어요. AI로 코드를 빨리 만들수록 이 문제가 더 커져요. 만드는 속도는 10배가 됐는데 검토하는 눈은 여전히 나 하나거든요.
저도 지난주에 딱 그 상황이었어요. 앱인토스에 올린 COSMO 미니앱에서 상품 그리드가 옆으로 터지고 하단 탭바가 너무 커지는 버그가 있었어요. 클로드코드로 일요일 하루에 고쳤는데, 그 코드를 봐줄 사람이 없었어요.
gstack /review는 어떻게 동작하나요?
gstack은 Y Combinator의 개리 탄(Garry Tan)이 공개한 클로드코드 스킬 모음이에요. 그중 /review가 “배포 직전 코드 리뷰” 담당이에요. QA 스킬(/qa)과 같은 패키지라서 이미 설치했다면 추가 설치가 없어요.
터미널에 /review 한 줄만 치면 아래 4단계가 돌아가요.
- 변경분만 추출해요. 기준 브랜치와 비교해서 바뀐 코드만 읽어요. 전체 코드를 다시 읽지 않아서 토큰도 아껴요
- 치명 5종을 먼저 점검해요. SQL 인젝션, 동시성 경쟁 조건, LLM 출력을 검증 없이 DB에 넣는 문제, 셸 인젝션, enum 값 누락. 이 5개가 실제 서비스 장애의 단골이에요
- 공격자 시점 리뷰를 따로 돌려요. 체크리스트를 모르는 별도 에이전트가 새 눈으로 “이 코드가 운영에서 어떻게 깨질까”만 찾아요
- 고칠 수 있는 건 바로 고쳐요. 기계적인 수정은 자동으로, 판단이 필요한 건 한 번에 모아서 물어봐요
제가 마음에 든 건 확신도 점수예요. 발견 하나마다 1~10점을 붙이고, 6점 이하는 “오탐일 수 있으니 확인 필요”라고 꼬리표를 달아요. AI 리뷰의 고질병이 “그럴듯한데 틀린 지적”인데, 스스로 자신 없는 걸 표시해주니까 걸러 보기가 편해요.
그리고 커밋과 푸시는 절대 안 해요. 리뷰는 하되 코드를 내보내는 결정은 사람이 하도록 선을 그어놨어요.
실측: 실제 앱 코드 73줄에 돌린 결과는?
대상은 위에서 말한 COSMO 미니앱 버그 수정 코드예요. React + Vite로 만든 토스 웹뷰 앱이고, 파일 6개에 73줄이 바뀌었어요. 2026년 9월 3일, gstack 1.55 버전 기준이에요.
| 항목 | 결과 |
|---|---|
| 대상 | 파일 6개, +73줄 / -9줄 |
| 걸린 시간 | 약 4분 (체크리스트 2분 + 공격자 시점 에이전트 2분 9초) |
| 치명(P0~P1) | 0건 |
| 정보성(P2~P3) | 6건 (P2 2건, P3 4건) |
| 확인 필요 꼬리표 | 1건 (확신도 6/10) |
| 검증된 비이슈 | 3건 (그리드 수정, 시각 계산, 빌드 설정) |
결론부터요. 치명 이슈는 없었고, 정보성 6건 중 2건이 진짜 건졌다 싶은 발견이었어요.
첫 번째는 예상했던 거예요. 버그를 잡느라 “마이” 탭 맨 아래에 빌드 시각과 안전영역 픽셀 수치를 찍어두는 진단 문구를 넣었거든요. 리뷰가 “이 디버그 문구가 금융 앱 실사용자에게 그대로 보인다, 개발 모드에서만 보이게 막아라”라고 확신도 10점으로 잡았어요. 그게 제가 메모장에 “출시 전 지울 것”이라고 적어둔 바로 그 코드였어요. 메모를 까먹었으면 그대로 나갈 뻔했어요.
두 번째는 제가 몰랐던 거예요. 탭바 높이를 고칠 때 “토스 웹뷰가 주는 안전영역 변수만 믿자”로 결정했는데, 그 근거가 실기기에서 잰 “토스 0px” 값이었거든요. 그런데 공격자 시점 에이전트가 토스 라이브러리 내부 코드까지 열어보고 이렇게 지적했어요. “그 변수는 웹뷰가 처음부터 주는 게 아니라, 라이브러리가 화면이 뜬 뒤에 넣어주는 값이다. 화면 뜨자마자 재면 항상 0이 나온다. 그 0px 실측은 기기가 아니라 타이밍을 잰 것일 수 있다.”
확신도는 6점, “확인 필요” 꼬리표가 붙었어요. 맞을 수도 틀릴 수도 있는데, 제가 며칠을 들여다본 코드에서 제가 못 본 각도를 4분 만에 꺼낸 건 사실이에요. 안드로이드 제스처 내비게이션에서 다시 재보라는 숙제까지 받았어요.
나머지 4건은 가벼운 것들이었어요.
- 같은 값을 두 번 재는 죽은 코드 (자동 수정)
- 빌드 시각 태그가 분 단위라 같은 분에 두 번 빌드하면 구분이 안 됨 (초 단위로 늘리면 끝)
- 운영 번들에 남은 console.log (개발 모드 조건 추가)
- 안전영역 측정을 화면 뜰 때 한 번만 하는 문제 (두 번째 발견의 연장)
“이건 문제 없음”도 3건 명시해줬어요. 그리드 수정 방식, 한국 시각 계산, 빌드 설정 주입이 정상이라고 확인해준 거예요. “안 잡힌 건 못 본 건지 본 건지” 불안이 없어서 좋았어요.
아쉬운 점도 하나 있어요. 이 코드는 순수 화면 코드라서 치명 5종(SQL, 동시성, LLM 등)이 애초에 해당이 없었어요. 백엔드 코드에 돌려야 진짜 실력이 나올 텐데, 그건 다음에 따로 실측해볼게요.
/review는 언제 쓰면 좋을까요?
| 상황 | 추천 | 이유 |
|---|---|---|
| 혼자 개발, 리뷰어 없음 | 매번 | 유일한 두 번째 눈이에요 |
| AI로 하루에 수백 줄 만들 때 | 매번 | 만드는 속도와 검토 속도를 맞춰줘요 |
| DB, 결제, 인증 코드 | 꼭 | 치명 5종이 정확히 이 영역이에요 |
| 스타일 한 줄 고친 정도 | 생략 가능 | 4분이 아까울 수 있어요 |
제 기준은 단순해요. 커밋 버튼 누르기 전에 /review 한 줄. 4분이면 커피 내리는 시간이고, 그 사이에 제가 못 본 각도를 하나 건졌으니 남는 장사예요.
gstack /review 설치 방법은?
gstack 패키지 하나를 설치하면 /review를 포함한 스킬 30여 개가 함께 들어와요. 설치 방법은 QA 스킬편에서 다뤘으니 그 글을 참고하세요. 이미 설치했다면 클로드코드에서 /review만 치면 바로 돼요.
출처: gstack 공식 저장소 github.com/garrytan/gstack (MIT 라이선스, 무료). 이 글의 실측은 2026년 9월 3일, gstack 1.55 버전 기준이에요.
자주 묻는 질문
Q. 클로드코드 기본 코드 리뷰와 뭐가 다른가요?
클로드코드에도 /code-review가 내장돼 있는데, 버그 위주로 보는 범용 리뷰예요. gstack /review는 치명 5종 체크리스트, 공격자 시점 별도 에이전트, 확신도 점수, 자동 수정까지가 한 묶음이고 배포 직전 관문용으로 설계됐어요.
Q. 오탐이 많지 않나요?
있어요. 그래서 확신도 점수가 있는 거예요. 이번 실측에서도 6건 중 1건에 “확인 필요” 꼬리표가 붙었어요. 점수 낮은 건 참고만 하고, 높은 건부터 처리하면 돼요.
Q. git을 안 쓰는 프로젝트에서도 되나요?
안 돼요. “기준 브랜치와의 차이”를 읽는 구조라서 git 저장소가 필수예요. git을 안 쓴다면 이 기회에 시작하는 걸 추천해요. AI 코딩과 git은 세트예요.
Q. 토큰은 얼마나 드나요?
변경분만 읽어서 생각보다 적어요. 다만 공격자 시점 에이전트가 하나 더 뜨니까 단순 질문 한 번보다는 많이 써요. 큰 변경(200줄 이상)이면 리뷰 단계가 하나 더 붙어서 더 늘어요.
다음 스킬: 배포 /ship
리뷰까지 끝난 코드는 이제 내보내야죠. 다음 글에서는 테스트, 버전 올리기, 커밋, PR 생성을 한 줄로 처리하는 배포 스킬(/ship)을 다뤄요. 혼자 개발하는 분들은 오늘 커밋 전에 /review 한 번 돌려보세요. 스킬 개념이 낯설다면 스킬 개념편부터 보세요.
Leave a Reply