superpowers가 깃을 어떻게 굴리는지 뜯어봤고, 바이브코딩하는 분들한테 넘길 만한 것만 추렸습니다.
저는 Rona 같은 AI 코딩 도구를 만듭니다. 일은 거의 Claude Code로 해요. AI 에이전트 여러 개한테 동시에 코드를 시키다 보면, 어느 순간 같은 코드베이스를 저랑 동료랑 AI가 같이 만지고 있습니다. 거기서 제일 자주 사고가 나는 게 깃(Git)이에요.
그 작업에 저는 superpowers라는 스킬 묶음을 깔아서 씁니다. 깃허브 별이 20만 개를 넘고, Claude Code 말고 Codex나 Cursor에서도 돌아가는 물건이에요. 잘 쓰고는 있는데, 막 바이브코딩 시작한 분한테 "이거 까세요" 한 줄로 넘기긴 좀 그렇더라고요. 그래서 이번엔 superpowers가 깃을 정확히 어떻게 다루는지 안을 열어보고, 바이브코더가 가져갈 만한 것만 골라봤습니다.
열어보기 전 제 짐작은 이랬어요. 바이브코더가 깃 명령어를 다 외울 필요는 없다, 어차피 명령은 AI가 친다, 대신 AI가 깃을 함부로 안 쓰게 할 규칙 몇 개면 된다. 열어보니 대체로 그랬습니다.
1. 쓰고 있던 브랜치 전략
superpowers 얘기를 하기 전에, 제가 깃을 어떻게 굴리는지부터요. 브랜치 전략은 보통 두 갈래로 이야기됩니다. Git Flow와 트렁크 기반(trunk-based)이요. 둘을 먼저 보고, 제가 왜 트렁크 쪽을 쓰는지 말씀드릴게요.
Git Flow
Git Flow는 2010 년 빈센트 드리센이 정리한 모델이에요. 브랜치를 역할별로 길게 나눠 둡니다. main에는 배포된 코드만 둬요. develop은 다음 배포를 모으는 통합용 줄기고요. 기능 하나를 만들 땐 develop에서 feature 브랜치를 따 작업하고 다시 develop으로 합칩니다. 배포할 때가 되면 develop에서 release 브랜치를 떼어 마무리한 뒤, 그걸 main에 합치면서 버전 태그를 답니다. 운영에서 급한 불이 나면 main에서 hotfix 브랜치를 따로 따고요.
정해진 날짜에 버전을 끊어 내보내거나, 여러 버전을 동시에 유지해야 하는 제품엔 잘 맞아요. 대신 길게 사는 브랜치가 여러 개라 무겁고, 매일 조금씩 배포하는 웹 서비스엔 과합니다. 만든 사람조차 나중에, 매일 배포하는 웹앱이라면 이것 말고 더 단순한 모델을 쓰라는 글을 덧붙였을 정도예요.
트렁크 기반 (제가 쓰는 쪽)
트렁크 기반은 정반대로 단순합니다. 굵은 줄기(트렁크, 그러니까 main) 하나만 두고, 거기서 아주 짧게 쓸 브랜치를 따 몇 시간에서 하루 안에 다시 합쳐요. develop 같은 중간 통합 브랜치가 없습니다. 자주 합치니까 충돌이 쌓이기 전에 풀리고, main은 늘 배포 가능한 상태로 유지돼요. 깃허브에서 권하는 GitHub Flow가 이 방식의 가벼운 버전입니다. main에서 브랜 치 따고, PR 올리고, 리뷰받고, 합치고, 배포. 그게 다예요.
대신 잘 굴러가려면 테스트와 CI가 받쳐줘야 하고, 아직 안 끝난 기능은 기능 플래그로 가려둬야 합니다. 저는 그중에서도 GitHub Flow를 써요. AI가 코드를 빠르게 쏟아내니 작게 자주 합치는 게 맞고, 매일 배포하는 제품이라 무거운 단계가 필요 없거든요.
한 가지 짚고 넘어갈게요. 뒤에 나올 superpowers는 이 '전략' 얘기랑은 층이 다릅니다. 브랜치를 어떻게 나눌지 정해주는 도구가 아니에요. 어떤 전략을 쓰든, 브랜치 하나를 안전하게 굴리는 운영을 맡습니다. 전략은 제가 고르고, 그 위에서 매 브랜치를 다루는 건 superpowers한테 맡기는 거죠.
이 방식에서 사고는 보통 두 군데서 났어요. 하나는 여러 작업을 한 폴더에서 같이 굴리다 서로 밟는 것. 다른 하나는 오래된 main에서 브랜치를 따 그사이 바뀐 걸 놓치는 것. 앞쪽(폴더 격리)은 superpowers가 확실히 잡아줬고, 뒤쪽(최신 main에서 따기)은 도구도 다 못 막아서 결국 제가 챙겨야 했습니다. 둘 다 뒤에서 다시 나와요.
2. 어떻게 했나
superpowers는 깃을 네 개의 규칙으로 쪼개 두고 있었습니다. 작업 한 바퀴를 돌면 순서대로 하나씩 걸려요. 명령은 AI가 치고, 저는 갈림길에서 고르기만 합니다. 하나씩 열어보면 이렇습니다.
작업을 시작하면
using-git-worktrees가 제일 먼저 "지금 격리된 데서 일하고 있나"부터 확인합니다. 아니면 worktree를 새로 만들어요. worktree는 같은 저장소를 딴 폴더로 복제해 떼어두는 기능인데, 그 폴더가 실수로 깃에 딸려 들어가지 않게 먼저.gitignore에 넣고 만듭니다. 그다음npm install같은 셋업을 돌리고, 손대기도 전에 테스트를 한 번 돌려 시작점이 깨끗한지까지 확인하고 넘겨줘요. 덕분에 처음부터 깨져 있던 건지 제가 망친 건지 헷갈릴 일이 없습니다.다 만들면
finishing-a-development-branch가 받습니다. 먼저 테스트를 돌려요. 깨져 있으면 거기서 멈추고 합치는 메뉴를 아예 안 보여줍니다. 통과해야 비로소 합칠지, PR 올릴지, 그냥 둘지, 버릴지를 묻고요. 합칠 때도 순서가 있어요. 먼저 합치고, 합친 결과로 테스트를 다시 돌리고, 그게 통과해야 worktree를 정리합니다. 버리기를 고르면 "discard"를 직접 타이핑해야 지워지고요. 실수로 날아가는 걸 한 단계 막아둔 셈이에요.합치기 전에는
requesting-code-review가 끼어듭니다. 제 변경의 시작 커밋과 끝 커밋만 집어서 그 사이에 바뀐 것만 별도 리뷰어한테 넘겨요. 이때 제가 그 코드를 어떻게, 왜 짰는지 대화는 같이 안 넘깁니다. 리뷰어가 제 설명에 휘둘리지 말고 결과물만 보라는 거죠. 리뷰어는 문제를 급한 것, 중요한 것, 사소한 것으로 나눠 돌려주고, 급한 건 바로, 중요한 건 다음으로 넘어가기 전에 고칩니다.리뷰가 돌아오면
receiving-code-review차례예요. 받자마자 고치지 않습니다. 먼저 지적을 제 말로 다시 정리하고, 코드를 열어 진짜 그런지 확인한 다음, 한 항목씩 고치면서 그때그때 테스트해요. 여러 개가 한꺼번에 오는데 애매한 게 하나 라도 있으면 그것부터 물어보고 시작합니다. 절반만 이해한 채로 손대면 엉뚱하게 고치거든요.
3. 발견 ①: 잘된 것
써보니 좋았던 게 몇 개 있어요. 먼저 시작 전에 폴더가 갈라집니다. 예전엔 AI 둘을 한 폴더에서 돌리다 한쪽이 브랜치를 바꾸는 바람에 다른 쪽 작업이 통째로 날아간 적이 있는데, 이제는 일을 벌이기도 전에 폴더가 떼어져 있으니 그럴 일이 없어요.
끝이 막막하지 않은 것도 좋았습니다. "끝났어요" 다음에 뭘 해야 할지 늘 헷갈렸는데, 여기선 테스트를 먼저 돌리고 딱 네 개만 물어봐요. 실제로는 이렇게 뜹니다.
구현 완료. 어떻게 할까요?
1. 본진(main)에 로컬에서 머지
2. 푸시하고 Pull Request 생성
3. 브랜치 그대로 두기 ( 나중에 처리)
4. 이 작업 폐기합치는 순간에도 테스트를 한 번 더 돌려서, 깨진 코드가 본진에 들어가는 걸 막습니다. 그리고 합치기 전에 다른 눈이 한 번 봐요. 제 변경분만 떼서 별도 리뷰어한테 넘기는데 제 대화 맥락은 안 줍니다. AI가 짠 걸 다른 AI가 선입견 없이 보는 셈이라, 비싼 실수는 대개 여기서 걸렸어요.
4. 발견 ②: 함정 ⚠️
별 20만짜리라고 안 데이는 건 아니었습니다. 예시는 다 익명으로 바꿨어요.
함정 ①: 리뷰를 "완전 맞아요"로 받으면 소용없다
AI는 지적받으면 일단 "완전 맞아요!" 하고 바로 고치는 버릇이 있습니다. 그러면 틀린 지적도 그대로 들어가요. superpowers의 receiving-code-review는 아예 "완전 맞아요!", "좋은 지적이에요!", "잡아주셔서 감사합니다!" 같은 말을 금지 목록에 박아놨습니다. 맞장구 대신 코드로 먼저 확인하고, 틀렸으면 근거를 대서 반박하라는 거죠. 이 규칙이 AI가 다른 AI 말에 그냥 끌려가는 걸 막아줍니다. 검수에서 중요한 건 예의가 아니라 검증이니까요.
함정 ②: 도구도 못 잡는 게 하나 있다
며칠 묵은 브랜치에서 결제 금액을 고치고 있었는데, 그 사이에 동료가 같은 결제 코드에 알림 기능을 붙여서 먼저 합쳤어요. 깃은 줄이 안 겹치니까 충돌 없이 조용히 합쳤고, 그 알림은 옛날 금액을 띄우고 있었습니다. 테스트도 리뷰도 다 통과했어요. 제 브랜치엔 그 알림 코드가 아예 없었으니까요. 운영에 올라가고 나서야 봤습니다. 이건 깃이 자동으론 못 거르는 자리예요. 결국 사람이 봐야 합니다.
함정 ③: 이미 갈라진 데서 또 갈라면 꼬인다
이미 격리된 폴더 안에서 worktree를 또 만들면 상태가 꼬입니다. superpowers가 맨 처음에 "지금 이미 격리돼 있는지부터 확인하라"고 시키는 게 그래서예요. 격리 도구가 따로 있으면 git worktree add를 직접 치지 말라고도 합니다. 도구가 모르는 상태가 생기거든요.
5. 그냥 시키면 vs superpowers가 시키면 (갭)
제가 그냥 시키면 AI가 하는 것과, superpowers가 시키는 게 이렇게 달랐습니다.
6. 🛠️ 혹시 직접 해보실 분들께
제일 쉬운 건 그냥 까는 겁니다. Claude Code면 한 줄이에요.
/plugin install superpowers@claude-plugins-officialsuperpowers는 깃허브 obra/superpowers에 있고, Codex나 Cursor, Gemini CLI에서도 같은 식으로 깔립니다. 깔면 위 네 스킬(using-git-worktrees, finishing-a-development-branch, requesting-code-review, receiving-code-review)이 깃을 맡아서, 새 대화마다 알아서 이 순서대로 움직여요.
스킬을 안 깔고 규칙만 적어두고 싶으면, AI가 매번 읽는 파일에 넣으면 됩니다. AGENTS.md는 도구 안 가리는 공개 표준이고, Claude Code는 CLAUDE.md를 읽어요. 별 6만 개짜리 claude-code-best-practice의 CLAUDE.md에도 비슷한 깃 규칙이 들어 있어 참고할 만합니다. 위에서 본 걸 옮기면 이 정도예요.
## 깃 협업 규칙 (AI에게)
- 작업은 시작 전에 격리된 worktree에서 한다.
- 끝나면 테스트부터 돌리고, 머지/PR/보존/폐기 중 하나를 나에게 묻는다.
- 머지 전, 내 변경분만 떼어 별도 리뷰어에게 검수받는다.
- 받은 지적은 맞장구 대신 코드로 확인한 뒤 하나씩 반영한다.
- 폐기나 force-push처럼 되돌릴 수 없는 일은 나한테 먼저 확인받는다.여기서 사람이 안 놓아야 하는 건 두 가지였어요. 어느 옵션으로 끝낼지 고르는 것, 그리고 값이 제대로 맞물리는지 보는 것. 나머지는 AI한테 맡겨도 됐습니다.
이렇게 쓰다 보니 제가 superpowers한테 배운 건 깃 명령어가 아니었어요. 시작 전에 폴더를 갈라놓고, 끝에서 테스트로 확인하고, 합치기 전에 다른 눈으로 한 번 더 보게 하는 순서였습니다. 바이브코더한테 깃을 가르친다면, 명령어 목록보다 이 순서를 먼저 넘기겠어요.
