docs(blog): AI Skill 글 발행

Author: dev-wooyeon

posts/ai-skills-워크플로우/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:<org>/<repo>.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 계정 확인 후 푸시해줘.
+```

posts/ai-skills-워크플로우/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"
+  }
+}