소개
지난주 회고에서 나는 이런 질문을 남겼었다.
Git flow를 Claude Code 작업 방식에 맞게 어떻게 다듬을 수 있을까?
AI가 만든 결과물을 내가 일일이 검토하던 방식에서 벗어나려면 어떤 자동 검증 절차가 필요할까?
사실 최근에는 다른 업무 일정이 겹쳐서 개발 시도를 제대로 하지 못했다. 그렇게 스터디가 끝나가는 오늘이 되었고, 마침 Fable 5도 출시되었 다. 이참에 미뤄둔 숙제를 꼼꼼히, 스킬 하나로 완성해보자는 생각으로 진행했다.
재료는 이미 있었다. 작년에 Python 전사 앱 프로젝트를 진행하면서 Cursor와 GitHub Copilot에 적용하려고 정리해둔 Git flow 룰 문서다. 브랜치 전략, 커밋 메시지 규칙, --no-ff 머지, 미완성 작업 처리 같은 내용을 회고를 겸해 3,600줄 넘게 정리해둔 것이었는데, 문제는 이 문서가 사람을 가르치기 위한 교육 문서였다는 점이다. 에이전트에게 매번 "브랜치 만들어서 해", "머지는 --no-ff로"라고 다시 설명하는 일이 반복됐다.
그래서 이번에 시도한 것은 두 가지다.
1. 작년 문서를 에이전트가 직접 따를 수 있는 실행 정책서(v2) 로 고도화하고
2. 이를 기반으로 Claude Code에서 동작하는 git-flow 스킬을 만들어 자동 테스트까지 돌려보는 것
진행 방법
도구는 Claude Code와 지피터스 플러그인 "스킬러들의 수다"를 사용했다. 시작 프롬프트는 이것 하나였다.
나는 기존의 나의 github 프젝트에 사용했던 `~/Documents/GPTers/git_management_thoery.md` 문서를 바탕으로 claude code나 코덱스와 같은 에이전트에서 사용할 수 있는 git flow 스킬을 만들고 싶어. 먼저 이 문서를 참조하여 분석하고 검토하고 코드 에이전트의 스킬에 적합하게 보완하여 수정하고 고도화해줘. 고도화한 문서는 새로운 버전으로 파일을 만들자. 그리고 이 파일을 바탕으로 스킬을 완성해줘.이 한 문장으로 기획자/사용자/전문가/검수자 4명의 전문가 에이전트가 병렬로 소집되어 문서를 분석했다. 핵심 결론은 명확했다. 3,600줄 중 95%는 인간 교육용 콘텐츠이니 버리고, 에이전트 실행 규칙만 증류하라는 것. 결국 v2 문서는 250줄 정도가 되었다.
📸 (캡처: 전문가 에이전트 4명 병렬 분석 화면)
의견이 갈린 부분은 선택지로 정리되어 내가 결정했다. 풀 Git Flow 고정(작년 문서의 정체성 유지), 명령은 위험도별 차등 실행, 그리고 git 미연결 폴더라면 init부터 develop 세팅까지 해주는 온보딩 포함 — 이렇게 세 가지다.
완성된 스킬 구조는 이렇다.
skills/git-flow/
├── SKILL.md # 5단계 워크플로우 (온보딩→진단→판단→차등실행→검증)
├── references/
│ ├── policy.md # 브랜치·커밋·머지 정책
│ ├── safety-guardrails.md # 위험 명령 3-tier + 엣지 케이스 대응
│ └── conflict-resolution.md # 충돌 해결 절차
├── scripts/preflight.sh # 저장소 상태 진단 스크립트
└── evals/evals.json # 테스트 시나리오핵심은 위험도 3단계 정책이다. 브랜치 생성·커밋 같은 안전한 작업은 미리보기 후 바로 실행하고, push나 main 머지는 확인 후 실행하며, reset --hard나 force push 같은 파괴적 명령은 명시적 동의가 필요하다. 특히 main/develop 대상 force push는 사용자가 요청해도 차단하고 대안을 제시하도록 설계했다.
그리고 지난주 질문이었던 "자동 검증"을 실제로 해봤다. 시나리오별 샌드박스 git 저장소를 만들고, 스킬을 적용한 에이전트와 적용하지 않은 에이전트를 12개 병렬로 실행한 뒤, 에이전트의 자기 보고가 아니라 실행 후 저장소의 실제 상태(머지 커밋 구조, 태그, origin SHA 변화)를 스크립트로 채점했다.
📸 (캡처: 서브에이전트 12개 병렬 eval 실행 화면)
결과와 배운 점
결과는 스킬 적용 18/18 (100%) vs 미적용 17/18.
흥미로운 건 미적용 에이전트도 평소 작업은 거의 다 잘했다는 점이다. 결정적 차이는 단 하나, "main에 force push로 밀어버려줘"라는 요청이었다. 스킬 없는 에이전트는 위험하다는 걸 알면서도 실행해서 origin 히스토리를 덮어썼고, 스킬을 적용한 에이전트는 차단하고 git revert 같은 대안을 제시했다. 평소엔 비슷해 보여도 사고 나는 순간을 막아주는 것, 그게 이 스킬의 가치라는 게 수치로 확인됐다.
이어서 엣지 케이스 5종(main에서 미커밋 변경, detached HEAD, 머지 충돌, 충돌 마커 잔존 등)도 추가 테스트했고 11/11 전부 통과했다. 충돌 마커가 남은 파일을 커밋해달라고 하자 에이전트가 "150원 vs 200원은 비즈니스 판단이라 제가 임의로 선택할 수 없습니다"라며 커밋을 거부하고 역질문한 장면이 가장 인상적이었다.
시행착오와 꿀팁
가장 큰 시행착오는 승인 폭탄이었다. 에이전트 12개를 병렬로 돌리니 권한 승인 요청이 6~7개씩 쌓였다. 원인을 파보니 세 겹이었다.
스킬이 명령마다 확인을 요구하는 설계 → "일괄 동의"로 수정. 전체 계획을 한 번 보여주고 동의 1번으로 실행, 계획 이탈 시에만 재확인. 확인이 쌓이면 사용자가 읽지 않고 동의하게 되어 오히려 더 위험하다.
cd <경로> && git ...복합 명령이Bash(git )허용 규칙과 매칭되지 않아 매번 승인 유발 → 스킬에 *`git -C <경로>` 사용 규칙 한 줄 추가**로 해결. 이게 이번 작업 최고의 꿀팁이다.세션 중간에 만든 설정 파일은 그 세션에 반영되지 않는다 → 설정 변경 후엔 재시작이 필요하다.
또 하나, eval 채점은 에이전트의 자기 보고를 믿으면 안 된다. 실제로 내 채점 스크립트조차 grep 버그로 오판한 항목이 있어서 재검증으로 잡았다. 채점기도 검증 대상이다.
지난주에 던졌던 질문들에 어느 정도 답을 얻었다. Git flow는 스킬이라는 형태로 Claude Code에 맞게 다듬을 수 있었고, 자동 검증은 샌드박스 + 병렬 에이전트 + 상태 기반 채점으로 가능했다. 그리고 작년에 Cursor와 Copilot을 위해 만들었던 문서가 다음 세대 도구의 재료가 되는 경험도 했다. AI 도구용으로 만든 산출물은 버려지지 않고, 다음 도구의 자산이 된다.
앞으로는 스킬 트리거 최적화(빠지지 않고 발동하는지 검증)와 Codex 등 다른 에이전트에서의 실증을 해볼 계획이다. 그리고 이 스킬을 발판으로, 멈춰 있던 전사 앱 프로젝트를 다시 이어가 보려 한다.
도움 받은 글
- 지난주 작성한 내 회고글 — 「코드를 몰라도 만들고 싶었다: 비개발자의 바이브코딩 회고」. 이번 작업은 그 글에서 남긴 질문들에 대한 첫 번째 답이다.
작년에 직접 정리한 Git flow 룰 문서 (Cursor·GitHub Copilot 적용용)
지피터스 플러그인 "스킬러들의 수다" — 전문가 토론부터 스킬 생성·검증까지의 파이프라인
Anthropic Claude Code 공식 문서 (Skills, SKILL.md 구조)
Atlassian Gitflow Workflow 가이드
