diff --git "a/posts/ai-skills-\354\233\214\355\201\254\355\224\214\353\241\234\354\232\260/index.mdx" "b/posts/ai-skills-\354\233\214\355\201\254\355\224\214\353\241\234\354\232\260/index.mdx" new file mode 100644 index 00000000..94c06af5 --- /dev/null +++ "b/posts/ai-skills-\354\233\214\355\201\254\355\224\214\353\241\234\354\232\260/index.mdx" @@ -0,0 +1,259 @@ +## 들어가기 + +여러분은 하나의 작업을 시작하고 PR을 올리기까지 Git Flow를 어떻게 처리하고 있나요? + +작업 전 `develop`이나 `main`을 최신화하고, 새 `feature` 브랜치를 만들고, 작업 후 커밋 규칙에 맞춰 커밋을 나누고, 푸시 계정을 확인한 뒤 PR을 올리고 있나요? + +![Git Flow 반복 절차를 git-flow Skill로 정리하는 삽화](/images/posts/ai-skills-워크플로우/git-flow-skill.png) + +이 과정은 작게는 5분, 상황에 따라 더 걸릴 수 있습니다. 작업 트리가 더럽거나, 기준 브랜치가 밀려 있거나, 커밋을 다시 나눠야 하면 기능 구현보다 Git 정리에 먼저 에너지를 씁니다. 저는 이 시간을 **업무의 비효율**로 정의하고 `git-flow` Skill을 만들었습니다. + +처음에는 제가 반복하던 절차를 줄이려는 목적이었습니다. 그런데 팀원이 브랜치 생성, 커밋 분리, 푸시 계정 확인에서 반복해서 헷갈리는 지점을 보면서 생각이 바뀌었습니다. 이건 개인의 Git 숙련도 문제가 아니라, 팀 안에서 반복 절차가 공유되지 않아 생기는 문제였습니다. + +제 경우에는 계정 확인도 Skill에 함께 넣었습니다. 일반적으로는 HTTPS 원격 주소와 브라우저 인증, 토큰 인증을 많이 쓰지만, 저는 개인 계정과 회사 계정을 SSH host alias로 분리해 사용하기 때문입니다. + +--- + +## Git이 어려워서 생긴 문제가 아니었습니다 + +Git Flow 자체는 어려운 일이 아닙니다. 문제는 매번 같은 품질로 반복하기 어렵다는 점입니다. + +```text +현재 브랜치 확인 +작업 트리 확인 +origin 확인 +develop 최신화 +새 feature 브랜치 생성 +변경 파일 확인 +커밋 단위 분리 +커밋 메시지 규칙 확인 +SSH 계정 확인 +git push +PR 생성 +``` + +이 절차는 하나씩 보면 단순합니다. 하지만 실제 작업 중에는 쉽게 빠집니다. + +| 빠뜨리기 쉬운 일 | 생기는 문제 | +| ------------------ | ------------------------------------------ | +| 기준 브랜치 최신화 | 오래된 기준에서 브랜치 생성 | +| dirty 상태 확인 | 사용자 변경과 새 작업 혼재 | +| 커밋 단위 분리 | 기능 변경과 테스트 변경 혼재 | +| 원격 주소 확인 | 푸시 대상 저장소 착각 | +| SSH 계정 확인 | 기대한 계정이 아닌 계정으로 푸시 시도 | +| 결과 보고 | 현재 브랜치와 푸시 상태를 다시 확인해야 함 | + +누군가는 기준 브랜치를 먼저 당기고, 누군가는 작업 브랜치부터 만들고, 누군가는 커밋을 파일 기준으로 나눕니다. 각자에게는 익숙한 방식이지만, 팀 단위에서는 작은 차이가 반복 스트레스가 됩니다. 특히 Git 상태가 꼬였을 때는 문제를 해결하기 전에 “어디서부터 달라졌는지”를 먼저 맞춰야 합니다. + +그래서 Git Flow를 Codex Skill로 분리했습니다. 좋은 Skill은 명령어 모음이라기보다, **팀이 같은 순서로 멈추고 확인하게 만드는 체크리스트**에 가깝습니다. + +--- + +## 기준을 Skill 안에 넣었습니다 + +제가 만든 `git-flow` Skill의 목적은 한 문장으로 정리할 수 있습니다. + +> 로컬 변경을 보존하면서 `develop` 기준으로 작업 브랜치를 만들고, 리뷰 가능한 커밋 단위로 정리한 뒤, 올바른 SSH 계정으로 안전하게 푸시합니다. + +이를 위해 Skill은 여섯 단계로 동작합니다. + +1. 현재 상태 확인 +2. `develop` 최신화 +3. 새 브랜치 생성 +4. 커밋 분리 +5. 계정 확인 후 푸시 +6. 결과 보고 + +핵심은 명령어보다 멈춤 조건입니다. 작업 트리가 더러우면 자동 `stash`나 `reset`을 하지 않습니다. `origin`이 기대한 원격 주소가 아니면 푸시 전 멈춥니다. `HEAD`와 `origin/develop`이 다르면 사용자 확인을 받습니다. 저장소에 별도 커밋 규칙이 있으면 Skill의 기본 규칙보다 저장소 규칙을 우선합니다. + +이 기준이 없으면 AI는 진행을 위해 너무 적극적으로 정리하려고 할 수 있습니다. Git 작업에서 빠른 실행보다 중요한 건 기존 변경을 보존하고, 잘못된 계정으로 푸시하지 않는 것입니다. + +--- + +## 긴 프롬프트 대신 `$git-flow`라고 말합니다 + +AI를 쓰더라도 처음에는 매번 같은 프롬프트를 반복했습니다. `develop` 기준으로 브랜치를 만들고, 작업을 커밋 규칙에 맞춰 나누고, 푸시 전 계정을 확인하고, 마지막에 PR을 올릴 수 있게 정리해달라는 식이었습니다. + +```text +develop 최신화하고 새 feature 브랜치 만들어줘. +작업 트리에 기존 변경이 있으면 건드리지 말고 먼저 알려줘. +커밋은 기능 변경과 테스트 변경으로 나눠줘. +커밋 메시지는 한글로 쓰고 타입을 붙여줘. +origin이 git@business 형태인지 확인해줘. +푸시 전에는 business SSH 계정인지 확인해줘. +마지막에는 현재 브랜치와 커밋 목록, 원격 URL을 알려줘. +``` + +Skill을 만든 뒤에는 이 긴 지시가 한 줄로 줄었습니다. + +```text +$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, 남아 있는 미커밋 파일을 같은 순서로 확인할 수 있었습니다. + +정성적인 변화는 세 가지였습니다. + +1. 브랜치 생성 전 상태 확인이 팀의 공통 루틴이 됐습니다. +2. 커밋을 파일 기준이 아니라 변경 목적 기준으로 나누기 시작했습니다. +3. 푸시 전 SSH 계정 확인이 빠지지 않는 절차가 됐습니다. + +덕분에 “Git이 꼬였는데 어떻게 되돌리지” 같은 대화가 줄었습니다. 더 정확히 말하면, Git 문제가 생겼을 때도 어디서부터 확인해야 하는지 팀이 같은 언어로 이야기할 수 있게 됐습니다. 저는 이 지점이 Skill을 만든 가장 큰 성과라고 봅니다. + +--- + +## 만들면서 남긴 기준 + +`git-flow` Skill을 만들면서 얻은 기준은 네 가지입니다. + +1. 실행 순서만 쓰지 말고 멈춤 조건을 씁니다. +2. 사용자 변경을 보존하는 규칙을 먼저 둡니다. +3. 환경마다 바뀌는 값은 수정 포인트로 분리합니다. +4. 마지막 보고 형식을 정합니다. + +이 기준은 Git Flow에만 해당하지 않습니다. 반복되는 업무 절차를 AI에게 맡길 때는 항상 같은 문제가 생깁니다. 무엇을 할지보다 어디서 멈출지, 어떤 값이 팀마다 바뀌는지, 사용자가 마지막에 무엇을 확인해야 하는지가 더 중요합니다. + +팀에 공유할 Skill이라면 여기에 한 가지가 더 필요합니다. 개인 최적화가 아니라 팀원이 그대로 따라도 안전한 기준이어야 합니다. + +--- + +## 마무리 + +Git Flow는 개발자의 핵심 역량을 보여주는 작업은 아닙니다. 하지만 틀리면 꽤 귀찮은 작업입니다. 브랜치를 잘못 만들고, 커밋이 섞이고, 계정을 잘못 쓰고, 푸시 뒤에 다시 정리하는 시간은 작지만 반복해서 쌓입니다. 이 스트레스가 개인에게만 쌓이면 습관 문제가 되고, 팀 전체에 반복되면 협업 비용이 됩니다. + +저는 이 반복을 `git-flow` Skill로 분리했습니다. + +> 반복되는 Git 절차는 프롬프트가 아니라 Skill로 관리하는 편이 낫습니다. + +AI Skill은 거창한 자동화가 아니어도 됩니다. 매번 5분씩 쓰던 절차를 안정적인 체크리스트로 바꾸고, 그 기준을 팀에 공유하는 것만으로도 충분히 가치가 있었습니다. 중요한 건 AI에게 더 많이 맡기는 게 아닙니다. 반복되는 절차를 문서화하고, 위험한 지점에서는 멈추게 하고, 팀원이 같은 기준으로 안전하게 작업하도록 만드는 것입니다. + +--- + +## 부록: Codex에 추가하기 + +아래 내용은 Codex 기준으로 바로 추가할 수 있는 형태입니다. 팀에 공유할 때는 `business`, `develop`, 브랜치 네이밍 규칙만 각 팀 환경에 맞게 바꾸면 됩니다. + +SSH host alias로 계정을 나눠 쓰는 경우에는 먼저 alias를 준비합니다. HTTPS를 쓴다면 이 단계는 팀의 인증 방식에 맞게 바꾸면 됩니다. + +```sshconfig +Host business + HostName github.com + User git + IdentityFile ~/.ssh/id_ed25519_business + IdentitiesOnly yes +``` + +회사 저장소의 remote가 SSH alias를 사용하도록 맞춥니다. + +```bash +git remote set-url origin git@business:/.git +git remote -v +ssh -T business +``` + +이제 Codex Skill 파일을 추가합니다. + +```bash +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에서 아래처럼 요청하면 됩니다. + +```text +$git-flow 기준으로 feature 브랜치 만들고 푸시 준비해줘. +``` + +또는 작업이 끝난 뒤 이렇게 요청할 수 있습니다. + +```text +$git-flow 기준으로 커밋 나누고 business 계정 확인 후 푸시해줘. +``` diff --git "a/posts/ai-skills-\354\233\214\355\201\254\355\224\214\353\241\234\354\232\260/meta.json" "b/posts/ai-skills-\354\233\214\355\201\254\355\224\214\353\241\234\354\232\260/meta.json" new file mode 100644 index 00000000..5396a2b2 --- /dev/null +++ "b/posts/ai-skills-\354\233\214\355\201\254\355\224\214\353\241\234\354\232\260/meta.json" @@ -0,0 +1,24 @@ +{ + "title": "Git Flow 반복 작업을 AI Skill로 줄인 과정", + "slug": "ai-skills-workflow", + "description": "브랜치 생성, 커밋 분리, SSH 계정 확인, 푸시까지 반복하던 Git Flow를 Codex Skill로 만들고 팀에 공유한 과정을 정리한다.", + "date": "2026-04-28", + "category": "Tech", + "tags": [ + "AI Workflow", + "Developer Experience", + "Codex", + "Automation", + "Technical Writing" + ], + "featured": false, + "visibility": "public", + "qualityReview": { + "philosophy": 3.5, + "design": 3.5, + "implementation": 3.5, + "brandFit": 3.5, + "notes": "발행", + "reviewedAt": "2026-04-28" + } +} diff --git "a/public/images/posts/ai-skills-\354\233\214\355\201\254\355\224\214\353\241\234\354\232\260/git-flow-skill.png" "b/public/images/posts/ai-skills-\354\233\214\355\201\254\355\224\214\353\241\234\354\232\260/git-flow-skill.png" new file mode 100644 index 00000000..d1336b3e Binary files /dev/null and "b/public/images/posts/ai-skills-\354\233\214\355\201\254\355\224\214\353\241\234\354\232\260/git-flow-skill.png" differ