Git Flow 반복 작업을 AI Skill로 줄인 과정

들어가기

여러분은 하나의 작업을 시작하고 PR을 올리기까지 Git Flow를 어떻게 처리하고 있나요?

작업 전 develop이나 main을 최신화하고, 새 feature 브랜치를 만들고, 작업 후 커밋 규칙에 맞춰 커밋을 나누고, 푸시 계정을 확인한 뒤 PR을 올리고 있나요?

Git Flow 반복 절차를 git-flow Skill로 정리하는 삽화

이 과정은 작게는 5분, 상황에 따라 더 걸릴 수 있습니다. 작업 트리가 더럽거나, 기준 브랜치가 밀려 있거나, 커밋을 다시 나눠야 하면 기능 구현보다 Git 정리에 먼저 에너지를 씁니다. 저는 이 시간을 업무의 비효율로 정의하고 git-flow Skill을 만들었습니다.

처음에는 제가 반복하던 절차를 줄이려는 목적이었습니다. 그런데 팀원이 브랜치 생성, 커밋 분리, 푸시 계정 확인에서 반복해서 헷갈리는 지점을 보면서 생각이 바뀌었습니다. 이건 개인의 Git 숙련도 문제가 아니라, 팀 안에서 반복 절차가 공유되지 않아 생기는 문제였습니다.

제 경우에는 계정 확인도 Skill에 함께 넣었습니다. 일반적으로는 HTTPS 원격 주소와 브라우저 인증, 토큰 인증을 많이 쓰지만, 저는 개인 계정과 회사 계정을 SSH host alias로 분리해 사용하기 때문입니다.

Git이 어려워서 생긴 문제가 아니었습니다

Git Flow 자체는 어려운 일이 아닙니다. 문제는 매번 같은 품질로 반복하기 어렵다는 점입니다.

현재 브랜치 확인
작업 트리 확인
origin 확인
develop 최신화
새 feature 브랜치 생성
변경 파일 확인
커밋 단위 분리
커밋 메시지 규칙 확인
SSH 계정 확인
git push
PR 생성

이 절차는 하나씩 보면 단순합니다. 하지만 실제 작업 중에는 쉽게 빠집니다.

빠뜨리기 쉬운 일	생기는 문제
기준 브랜치 최신화	오래된 기준에서 브랜치 생성
dirty 상태 확인	사용자 변경과 새 작업 혼재
커밋 단위 분리	기능 변경과 테스트 변경 혼재
원격 주소 확인	푸시 대상 저장소 착각
SSH 계정 확인	기대한 계정이 아닌 계정으로 푸시 시도
결과 보고	현재 브랜치와 푸시 상태를 다시 확인해야 함

누군가는 기준 브랜치를 먼저 당기고, 누군가는 작업 브랜치부터 만들고, 누군가는 커밋을 파일 기준으로 나눕니다. 각자에게는 익숙한 방식이지만, 팀 단위에서는 작은 차이가 반복 스트레스가 됩니다. 특히 Git 상태가 꼬였을 때는 문제를 해결하기 전에 “어디서부터 달라졌는지”를 먼저 맞춰야 합니다.

그래서 Git Flow를 Codex Skill로 분리했습니다. 좋은 Skill은 명령어 모음이라기보다, 팀이 같은 순서로 멈추고 확인하게 만드는 체크리스트에 가깝습니다.

기준을 Skill 안에 넣었습니다

제가 만든 git-flow Skill의 목적은 한 문장으로 정리할 수 있습니다.

로컬 변경을 보존하면서 develop 기준으로 작업 브랜치를 만들고, 리뷰 가능한 커밋 단위로 정리한 뒤, 올바른 SSH 계정으로 안전하게 푸시합니다.

이를 위해 Skill은 여섯 단계로 동작합니다.

현재 상태 확인
develop 최신화
새 브랜치 생성
커밋 분리
계정 확인 후 푸시
결과 보고

핵심은 명령어보다 멈춤 조건입니다. 작업 트리가 더러우면 자동 stash나 reset을 하지 않습니다. origin이 기대한 원격 주소가 아니면 푸시 전 멈춥니다. HEAD와 origin/develop이 다르면 사용자 확인을 받습니다. 저장소에 별도 커밋 규칙이 있으면 Skill의 기본 규칙보다 저장소 규칙을 우선합니다.

이 기준이 없으면 AI는 진행을 위해 너무 적극적으로 정리하려고 할 수 있습니다. Git 작업에서 빠른 실행보다 중요한 건 기존 변경을 보존하고, 잘못된 계정으로 푸시하지 않는 것입니다.

긴 프롬프트 대신 `$git-flow`라고 말합니다

AI를 쓰더라도 처음에는 매번 같은 프롬프트를 반복했습니다. develop 기준으로 브랜치를 만들고, 작업을 커밋 규칙에 맞춰 나누고, 푸시 전 계정을 확인하고, 마지막에 PR을 올릴 수 있게 정리해달라는 식이었습니다.

develop 최신화하고 새 feature 브랜치 만들어줘.
작업 트리에 기존 변경이 있으면 건드리지 말고 먼저 알려줘.
커밋은 기능 변경과 테스트 변경으로 나눠줘.
커밋 메시지는 한글로 쓰고 타입을 붙여줘.
origin이 git@business 형태인지 확인해줘.
푸시 전에는 business SSH 계정인지 확인해줘.
마지막에는 현재 브랜치와 커밋 목록, 원격 URL을 알려줘.

Skill을 만든 뒤에는 이 긴 지시가 한 줄로 줄었습니다.

$git-flow 진행해줘.

프롬프트가 짧아진 것보다 더 중요한 변화는 기준이 고정됐다는 점입니다. 개인마다 다르게 기억하던 Git Flow가 하나의 Skill로 모이자, 팀원들은 같은 순서로 상태를 확인하고 같은 기준으로 멈출 수 있었습니다.

항목	공유 전	공유 후
시작 요청	Git 절차를 매번 길게 설명	`$git-flow 진행해줘`
기준 브랜치	개인 습관에 의존	`develop` 기준
dirty 상태	상황마다 대응이 달라짐	자동 stash/reset 금지
원격 주소	푸시 대상이 섞일 수 있음	`git remote -v` 확인
푸시 계정	푸시 직전 놓칠 수 있음	`ssh -T business` 확인
커밋 분리	파일 기준으로 섞이기 쉬움	변경 목적 기준
마지막 보고	푸시 여부만 확인하는 경우	브랜치, 커밋, URL, 미커밋 파일 보고

공유하고 나서 달라진 것

Skill의 효과는 자동화보다 표준화에 가까웠습니다. 버튼 하나로 모든 Git 작업이 끝나는 경험보다, 팀원이 같은 기준으로 멈추고 같은 형식으로 상태를 공유할 수 있게 된 변화가 더 컸습니다.

예전에는 Git 상태가 꼬이면 먼저 상황 설명부터 길어졌습니다. “어떤 브랜치에서 시작했는지”, “develop을 언제 당겼는지”, “커밋을 왜 이렇게 나눴는지”, “어느 계정으로 푸시했는지”를 다시 확인해야 했습니다. Skill을 공유한 뒤에는 대화의 시작점이 달라졌습니다. $git-flow의 결과 보고를 보면 현재 브랜치, 커밋 목록, 원격 URL, 남아 있는 미커밋 파일을 같은 순서로 확인할 수 있었습니다.

정성적인 변화는 세 가지였습니다.

브랜치 생성 전 상태 확인이 팀의 공통 루틴이 됐습니다.
커밋을 파일 기준이 아니라 변경 목적 기준으로 나누기 시작했습니다.
푸시 전 SSH 계정 확인이 빠지지 않는 절차가 됐습니다.

덕분에 “Git이 꼬였는데 어떻게 되돌리지” 같은 대화가 줄었습니다. 더 정확히 말하면, Git 문제가 생겼을 때도 어디서부터 확인해야 하는지 팀이 같은 언어로 이야기할 수 있게 됐습니다. 저는 이 지점이 Skill을 만든 가장 큰 성과라고 봅니다.

만들면서 남긴 기준

git-flow Skill을 만들면서 얻은 기준은 네 가지입니다.

실행 순서만 쓰지 말고 멈춤 조건을 씁니다.
사용자 변경을 보존하는 규칙을 먼저 둡니다.
환경마다 바뀌는 값은 수정 포인트로 분리합니다.
마지막 보고 형식을 정합니다.

이 기준은 Git Flow에만 해당하지 않습니다. 반복되는 업무 절차를 AI에게 맡길 때는 항상 같은 문제가 생깁니다. 무엇을 할지보다 어디서 멈출지, 어떤 값이 팀마다 바뀌는지, 사용자가 마지막에 무엇을 확인해야 하는지가 더 중요합니다.

팀에 공유할 Skill이라면 여기에 한 가지가 더 필요합니다. 개인 최적화가 아니라 팀원이 그대로 따라도 안전한 기준이어야 합니다.

마무리

Git Flow는 개발자의 핵심 역량을 보여주는 작업은 아닙니다. 하지만 틀리면 꽤 귀찮은 작업입니다. 브랜치를 잘못 만들고, 커밋이 섞이고, 계정을 잘못 쓰고, 푸시 뒤에 다시 정리하는 시간은 작지만 반복해서 쌓입니다. 이 스트레스가 개인에게만 쌓이면 습관 문제가 되고, 팀 전체에 반복되면 협업 비용이 됩니다.

저는 이 반복을 git-flow Skill로 분리했습니다.

반복되는 Git 절차는 프롬프트가 아니라 Skill로 관리하는 편이 낫습니다.

AI Skill은 거창한 자동화가 아니어도 됩니다. 매번 5분씩 쓰던 절차를 안정적인 체크리스트로 바꾸고, 그 기준을 팀에 공유하는 것만으로도 충분히 가치가 있었습니다. 중요한 건 AI에게 더 많이 맡기는 게 아닙니다. 반복되는 절차를 문서화하고, 위험한 지점에서는 멈추게 하고, 팀원이 같은 기준으로 안전하게 작업하도록 만드는 것입니다.

부록: Codex에 추가하기

아래 내용은 Codex 기준으로 바로 추가할 수 있는 형태입니다. 팀에 공유할 때는 business, develop, 브랜치 네이밍 규칙만 각 팀 환경에 맞게 바꾸면 됩니다.

SSH host alias로 계정을 나눠 쓰는 경우에는 먼저 alias를 준비합니다. HTTPS를 쓴다면 이 단계는 팀의 인증 방식에 맞게 바꾸면 됩니다.

Host business
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_business
  IdentitiesOnly yes

회사 저장소의 remote가 SSH alias를 사용하도록 맞춥니다.

git remote set-url origin git@business:<org>/<repo>.git
git remote -v
ssh -T business

이제 Codex Skill 파일을 추가합니다.

mkdir -p ~/.codex/skills/git-flow
cat > ~/.codex/skills/git-flow/SKILL.md <<'EOF'
---
name: git-flow
description: "`develop` 기반 저장소에서 브랜치 작업을 시작하고 배포 가능한 형태로 푸시할 때 사용하는 표준 절차입니다. `develop` 최신화, 새 브랜치 생성, 리뷰하기 좋은 커밋 분리, `ssh -T business` 계정 확인, 원격 푸시가 필요할 때 사용합니다."
---
 
# Git Flow
 
## 개요
 
이 스킬은 Git 작업을 시작할 때마다 같은 품질로 수행하기 위한 체크리스트입니다. 로컬 변경을 보존하면서 `develop` 기준으로 작업 브랜치를 만들고, 리뷰 가능한 커밋 단위로 정리해 `business` SSH 계정으로 안전하게 푸시합니다.
 
## 빠른 실행 순서
 
1. 현재 상태 확인
   - `git rev-parse --abbrev-ref HEAD`
   - `git status --short`
   - `git remote -v`
   - `origin`이 `git@business:...` 형태인지 확인
2. `develop` 최신화
   - `git fetch origin --prune`
   - 필요하면 `git checkout develop`
   - 작업 트리가 깨끗하면 `git pull --ff-only origin develop`
   - 작업 트리가 더럽다면 자동 stash/reset 금지
   - `HEAD`와 `origin/develop`를 비교해 동일하면 최신화 완료로 간주
   - 동일하지 않으면 사용자 확인 후 진행
3. 새 브랜치 생성
   - 예시: `feature/<주제>`, `bugfix/<주제>`
   - `git checkout -b <새브랜치>`
4. 커밋 분리
   - 파일 기준이 아니라 변경 목적 기준으로 분리
   - 권장 단위
     - 기능 변경(도메인/API/서비스)
     - 테스트/검증 보강
   - 단계별로 `git add <경로>` 후 `git diff --cached` 검토
   - 커밋 메시지는 기본적으로 한글 제목을 사용
   - 형식: `type: <한글 제목>`
   - 예시: `feat: 레거시 워크플로우 동기화 API 추가`
   - `git commit -m "<메시지>"`
5. 계정 확인 후 푸시
   - `ssh -T business`
   - 출력 계정이 기대한 계정인지 확인
   - `git push -u origin <새브랜치>`
6. 결과 보고
   - 현재 브랜치
   - 커밋 목록 (`git log --oneline -n <개수>`)
   - 원격 안내 URL(출력되면)
   - 의도적으로 남긴 미커밋 파일
 
## 수정 포인트
 
필요 시 아래 항목만 바꿔서 재사용하면 됩니다.
 
- 기준 브랜치: `develop`
- SSH 호스트 별칭: `business`
- 브랜치 네이밍 규칙: `feature/*`, `bugfix/*`
- 커밋 분리 규칙: 기능/테스트 2단 구조(또는 팀 규칙에 맞게 확장)
 
## 커밋 메시지 기준(한글)
 
- 기본 언어는 한글로 작성합니다.
- 타입은 `build|ci|docs|feat|fix|perf|refactor|style|test`를 사용합니다.
- 제목은 간결한 명령형으로 작성하고, 마침표는 붙이지 않습니다.
- 저장소에 별도 규칙이 있으면 그 규칙을 우선합니다.
 
## 안전 수칙
 
- 사용자 요청 없이 `git reset --hard`, `git checkout --` 같은 파괴적 명령을 실행하지 않습니다.
- 로컬 전용 설정/시크릿 파일은 명시적 요청 없이는 커밋하지 않습니다.
- 무관한 기존 변경사항을 새 기능 커밋에 섞지 않습니다.
EOF

설치 후 Codex에서 아래처럼 요청하면 됩니다.

$git-flow 기준으로 feature 브랜치 만들고 푸시 준비해줘.

또는 작업이 끝난 뒤 이렇게 요청할 수 있습니다.

$git-flow 기준으로 커밋 나누고 business 계정 확인 후 푸시해줘.