24장. 완성 데모와 실무 확장

이 장이 끝나면: 회의록 한 장을 건네면 저장해 둔 AI 팀이 요구 정리 → 구현 → 검증 → PR까지 스스로 돌고, 배포는 사람이 PR 병합으로 결정하는 운영 파이프라인이 세팅되어 있다. 그 파이프라인으로 실제 기능 하나('마감 임박' 표시)를 공개 서비스에 반영한다. 그리고 완성된 온티켓을 처음부터 끝까지 시연하며 어느 일을 어떤 AI 역할이 했는지 설명할 수 있고, 이 방식을 내 업무로 가져가는 첫 걸음까지 정한다.

24.1 개념 — 출시 뒤의 팀은 한 번 세우고 계속 부른다

3일 전과 지금

3일 전에는 빈 폴더 하나와 "우리 사이트에서 티켓을 직접 팔자"는 오대표의 결심밖에 없었다. 지금은 낯선 사람이 자기 휴대폰으로 접속해 티켓을 살 수 있는, 인터넷에 떠 있는 서비스가 있다. 공개 주소에 접속하면 공연 목록이 뜨고, 예매하고, (테스트) 결제하고, QR 티켓을 받고, 현장에서 입장 확인이 된다. 데이터는 관리형 DB에 영구 저장되고, 코드가 바뀔 때마다 자동으로 검사·리뷰·배포된다. 실제 장애 하나를 추적해 명세부터 고쳐 재발까지 막았다.

그 사이에 사람이 직접 친 코드의 양은, 솔직히 말하면 거의 없다. 우리가 한 일은 코드가 아니라 결정과 지시와 확인이었다. 온티켓의 지금 상태를 한 문장으로 요약하면 — 혼자서도 살아 있고, 혼자서도 지켜지는 서비스. 살아 있다는 것은 노트북을 닫아도 클라우드에서 계속 돈다는 뜻이고, 지켜진다는 것은 새 코드가 들어올 때마다 자동 검사·리뷰·배포가 사람 없이도 돈다는 뜻이다.

[짚고 가기] 마지막 장의 시작은 회고의 정서로 여는 게 좋다. "3일 전 이 폴더는 비어 있었다"를 떠올리고, 지금 살아 있는 공개 주소를 직접 열어 보는 것만으로도 자기가 얼마나 멀리 왔는지 실감이 난다. 이 성취감이 남아야 뒤의 "내 일로 가져가기"가 결심으로 이어진다. 다만 여기서 오래 머물지 않는다 — 이 장의 무게중심은 회고가 아니라 출시 뒤에 팀을 어떻게 굴리는가에 있다.

출시 뒤의 일은 같은 순서의 반복이다

그런데 하나가 빠져 있다. 서비스는 출시 뒤에도 계속 바뀐다. 바로 앞에서 본 장애처럼 급한 일도 있지만, 대부분은 조용한 요청이다. 운영팀이 회의에서 "이런 표시가 있으면 좋겠다"고 말하고, 그것이 회의록에 적히고, 개발 리더에게 온다. 이 요청은 한 번이 아니라 매주 온다.

지금까지 우리는 그런 요청 하나를 처리할 때 이렇게 했다. /pm을 불러 요구를 완료 기준으로 바꾸고, 데이터가 바뀌면 /dba·/architect로 DB와 명세를 먼저 고치고, /backend, /frontend 순으로 구현하고, 서브에이전트에게 검증을 맡기고, 커밋을 나누고, PR을 올리고, CI를 기다렸다. 배우는 동안에는 이게 맞다. 각 역할이 무엇을 하는지 눈으로 봐야 하니까. 하지만 3일간 이 순서는 한 번도 바뀌지 않았다. 매번 같은 순서를 사람이 손으로 되풀이하는 것은, 그 순서를 아직 역할로 굳히지 않았다는 뜻이다.

Claude Code의 기능을 처음 훑을 때 배운 대로, 매번 똑같이 지시하는 것은 Skill로 굳힌다. 이번에 굳힐 것은 어느 한 역할의 일이 아니라 역할들을 부르는 순서 자체다. 그것을 굳혀 두면, 다음 요청부터는 회의록 파일 하나를 건네는 것으로 끝난다.

파이프라인 — 순서를 역할로 굳힌다

파이프라인(pipeline) 은 '관(管)'이라는 뜻이다. 한쪽에 무언가를 넣으면 정해진 단계를 차례로 거쳐 반대쪽으로 나오는 흐름을 가리킨다. 앞에서 세운 CI가 "코드를 넣으면 검사 결과가 나오는 관"이었다면, 이 장에서 만드는 것은 "회의록을 넣으면 검증 끝난 PR이 나오는 관" 이다. 흐름은 이렇다.

data/2차_운영회의록.md
   │
   │  /feature @data/2차_운영회의록.md      ← 사람의 일 ①: 회의록을 건넨다
   ▼
[PM 스킬]         회의록 → 완료 기준. 범위 밖 요구는 구현하지 않고 목록으로 보고
[DBA·아키텍트]    데이터가 바뀌면 ERD·스키마 먼저, 그다음 API 명세. 화면만 바뀌면 건너뜀
[백엔드 → 프론트] 기능 브랜치에서 구현(백엔드 먼저) + 완료 기준을 테스트로
[리뷰어·QA·보안]  서브에이전트 검증 → Blocker면 고치고 같은 검사를 다시
[Git]             의미 단위 커밋 → PR 생성 → CI(테스트·자동 리뷰)가 돈다
   │
   ■  멈춤: "PR #12 올렸습니다. CI 확인 후 병합은 사람이 합니다."
   ▼
사람이 PR을 읽고 병합                        ← 사람의 일 ②: 배포 결정
   ▼
main 반영 → Vercel 자동 배포 → 공개 주소에 반영

관 안에서 도는 것은 전부 우리가 3일간 세운 팀이다. PM·DBA·아키텍트·백엔드·프론트 스킬, 리뷰어· QA·보안 서브에이전트, 커밋 훅, CI, 자동 리뷰, 자동 배포 — 하나도 새로 만들지 않는다. 새로 만드는 것은 딱 두 개다. 순서를 적은 스킬 하나(/feature)와, 배포를 사람 앞에서 멈춰 세우는 훅 하나.

사람의 일은 두 번뿐이다. 처음에 회의록을 건네고, 마지막에 PR을 읽고 병합 버튼을 누른다. 그 사이의 모든 것 — 요구를 완료 기준으로 바꾸고, 범위 밖 요구를 걸러내고, 구현하고, 테스트를 붙이고, 세 검증 역할이 훑고, 커밋을 나누고, PR 본문을 쓰는 것 — 은 관 안에서 일어난다. 물론 Claude Code의 퍼미션은 그대로 살아 있어서, 파일을 고치고 명령을 실행할 때마다 승인 창은 뜬다. 하지만 무엇을 어떤 순서로 할지를 사람이 매번 정하지는 않는다. 그것이 파이프라인이 있는 상태와 없는 상태의 차이다.

마지막 한 칸은 비워 둔다 — 배포 결정은 사람의 것

파이프라인이 아무리 자동이어도 마지막 한 칸은 비워 둔다. 이 과정 내내 지킨 원칙 그대로다 — 틀렸을 때 되돌리기 어려운 자리에는 사람이 선다. 고객이 쓰는 서비스에 새 코드가 나가는 순간이 바로 그 자리다. 화면에 '마감 임박' 배지 하나 붙이는 일이라도, 잘못 나가면 고객이 본다.

그래서 파이프라인은 PR을 올린 뒤 멈춘다. 프론트를 배포할 때 세운 대로 main에 병합되는 순간 Vercel이 자동 배포하므로, PR 병합 = 배포 결정이다. 병합 버튼은 사람이 누른다. 누르기 전에 사람이 보는 것은 세 가지다 — CI가 초록인가, 자동 리뷰가 무엇을 지적했나, PR 본문에 적힌 "범위 밖으로 뺀 요구"가 내 판단과 같은가. api를 고친 기능이면 API 서버를 배포할 때 쓴 wrangler deploy가 한 번 더 필요한데, 그것도 사람이 따로 지시해야만 나가게 한다.

이 '멈춤'을 부탁에 맡기지 않는다. 스킬 본문에 "병합하지 마라"라고 적어 두는 것은 부탁이다 — AI가 협조하면 지켜지고, 급하다고 판단하면 안 지켜질 수 있다. 그래서 훅으로 gh pr merge와 main으로의 push를 차단해, AI가 스스로 병합할 길을 구조로 막는다. DB 파괴 명령과 시크릿 파일을 훅으로 막았던 것과 같은 방식이다. CI를 세울 때 건 브랜치 보호 규칙이 있지 않냐고 물을 수 있다. 그 규칙은 "CI가 빨간데 병합하는 것"을 막지만, CI가 초록이면 AI가 gh pr merge로 병합하는 것까지는 막지 못한다. 훅은 CI 결과와 상관없이 AI 쪽에서 병합 자체를 못 하게 한다. 두 장치가 막는 것이 다르다.

뼈대가 있다는 것의 값

이 장에서 추가하는 기능은 작다. 잔여 수량이 5장 이하인 등급에 '마감 임박'이라고 표시하는 것. 그런데 이 작은 기능 하나가 관을 통과하는 동안 어떤 일이 일어나는지 세어 보자.

1. PM(Skill) 이 회의록에서 이 요구만 골라내고, 함께 적힌 환불 자동화·카카오톡 알림은 기획 단계에서 정한 '범위 제외'와 대조해 걸러낸다
2. DBA·아키텍트(Skill) 차례지만 이번에는 고칠 것이 없다. 잔여 수량은 DB에 이미 있는 값(총수량 − 판매수량)이고, API가 이미 remaining으로 준다 — DB도 명세도 그대로다
3. 그래서 백엔드(Skill) 도 건너뛰고, 프론트(Skill) 가 배지를 붙인다. 화면만 바뀐다 — 경계(판정은 서버, 표시는 화면)는 그대로다
4. QA(Subagent) 가 경계값(잔여 5는 표시, 6은 표시 안 함, 0은 매진)을 검사한다
5. 코드리뷰어·보안검토자(Subagent) 가 화면에 판정 로직이 스며들지 않았는지 본다
6. 커밋 훅 이 테스트 통과와 시크릿 미포함을 확인하고, CI 가 다시 돌리고, 자동 리뷰 가 PR에 코멘트를 단다
7. Vercel 이 병합 즉시 배포한다

새로 만든 것은 배지 하나뿐이고, 나머지 팀·관문·경계는 전부 그대로 재사용된다. 기능을 하나 더 얹는 비용이 처음 서비스를 만들 때와 비교가 안 되게 작다. 3일간 우리가 만든 것은 티켓 서비스만이 아니라, 그 위에 무엇이든 얹을 수 있는 이 뼈대였다. 파이프라인은 그 뼈대를 매번 다시 조립하지 않고 한 번에 부르는 손잡이다.

[짚고 가기] "왜 지금까지는 파이프라인 없이 했나"라는 질문이 나오면 정직하게 답한다 — 배우는 동안에는 각 역할을 따로 불러 산출물을 눈으로 봐야 하기 때문이다. 파이프라인은 그 순서를 이미 몸으로 아는 사람이 쓰는 도구다. 순서를 모르는 채 파이프라인부터 만들면, 관 안에서 무슨 일이 일어나는지 모른 채 결과만 받게 되고, 그러면 막혔을 때 어느 단계로 돌아가야 하는지 알 수 없다. 지금까지 손으로 한 것이 이 장의 자격이다.

[짚고 가기] "배포 결정이 PR 병합"이라는 말을 수강생이 가볍게 넘기기 쉽다. 병합 버튼을 누르는 순간 Vercel이 배포를 시작하고 몇십 초 뒤 고객 화면이 바뀐다는 것을, 프론트를 배포하며 문구 하나를 고쳐 본 자동 배포 장면과 연결해 다시 짚어 준다. 버튼 하나가 곧 출시라는 감각이 있어야, 그 앞에서 PR 본문을 읽는 습관이 생긴다.

24.2 용어 정리

'새 세션'을 한 번 더 짚어 두자. Claude Code는 대화를 종료하면 그 대화에서 오간 말을 잊는다. 하지만 앞에서 배운 대로 CLAUDE.md는 세션이 시작될 때마다 다시 읽히고, .claude/skills/와 .claude/agents/에 저장한 역할도 그대로 남아 있다. 그래서 이 장의 시연은 반드시 세션을 완전히 끄고 다시 켠 뒤에 한다. 방금까지 대화하던 세션에서 파이프라인이 도는 것은 증명이 아니다. 새 세션에서, 아무 역할도 다시 세우지 않고, 회의록 한 줄로 팀 전체가 움직여야 "팀이 저장되어 있다"는 말이 사실이 된다.

24.3 프롬프트 작성법 — 파이프라인은 지시문 하나다

파이프라인 스킬 생성 — 순서·멈춤·금지를 전부 적는다

파이프라인은 마법이 아니다. .claude/skills/feature/SKILL.md에 저장된 지시문 하나다. 그 지시문에 세 가지가 반드시 들어가야 한다 — 어떤 순서로 누구를 부를지, 어디서 멈출지, 무엇을 절대 하지 말지. 스킬 파일을 직접 타이핑하지 않는다. 만드는 것도 지시한다(PM 스킬을 만들 때와 같다).

.claude/skills/feature/SKILL.md 로 '기능 추가 파이프라인' 스킬을 만들어줘.
/feature @회의록파일 로 부르면, 저장된 우리 팀을 아래 순서로 돌린다:
1) /pm 규칙으로 회의록의 요구를 두 묶음으로 나눈다 — 이번에 구현할 것(완료 기준으로
   바꿔 docs/PRD.md에 추가)과 범위 밖(docs/PRD.md의 '범위 제외'와 대조해 구현하지 않고
   목록으로만 보고). 정책이 미확정인 요구는 무조건 범위 밖.
2) 데이터가 바뀌어야 하면 /dba 규칙으로 docs/ERD.md와 스키마(마이그레이션)를 먼저 고치고,
   그다음 /architect 규칙으로 docs/API-Spec.md를 고친다. 순서는 항상 DB → 명세 → 코드.
   화면만 바뀌면 건너뛴다. 테이블·컬럼을 지우거나 이름을 바꿔야 하면 멈추고 나에게 보고.
3) feature/ 브랜치를 만들고 구현한다 — /backend 규칙으로 먼저, 그다음 /frontend 규칙으로.
   경계 규칙(판정·계산은 api/, 표시는 web/)은 그대로.
4) 완료 기준을 테스트로 옮겨 추가하고 pnpm test 를 통과시킨다.
5) code-reviewer·qa·security-reviewer 서브에이전트에게 검증을 맡긴다. Blocker가 나오면
   고치고 같은 검사를 다시 한다(최대 2회). 그래도 남으면 멈추고 나에게 보고.
6) 의미 단위로 커밋하고 main으로 PR을 올린다. PR 본문은 한국어로: 무엇을 왜 바꿨는지,
   검증 판정표, 범위 밖으로 뺀 요구 목록과 이유.
7) 여기서 멈춘다. "PR #번호 올렸습니다. CI 확인 후 병합은 사람이 합니다"라고 보고하고 끝낸다.
절대 하지 말 것: main에 직접 push, PR 병합, wrangler deploy.
중간에 나에게 되묻지 말고 6)까지 끝내되, 2)에서 멈추는 경우와 5)에서 Blocker가 남는 경우만 예외.

한 줄씩 왜 있는지 보자. 이 지시문은 3일간 배운 것의 요약본이다.

마지막 줄, "되묻지 말 것"이 낯설 수 있다. 지금까지는 오히려 "확인을 구하라"고 가르쳤기 때문이다. 둘은 모순이 아니다. 판단이 필요한 자리(범위 밖인지, 테이블을 지워도 되는지, Blocker를 어떻게 할지)에서는 멈추고 보고하게 했고, 순서대로 하면 되는 자리에서는 멈추지 않게 했다. 어디서 멈추고 어디서 달릴지를 사람이 미리 정해 준 것 — 그것이 파이프라인 설계다.

배포 잠금 훅 — 부탁을 구조로

.claude/settings.json 에 배포 잠금 훅을 추가해줘.
PreToolUse(Bash)에서 명령이 gh pr merge 이거나 main 브랜치로의 git push 이면 차단하고,
사유는 "배포 결정은 사람이 GitHub에서 합니다"로. wrangler deploy 는 차단이 아니라
실행 전에 나에게 확인을 묻도록(ask) 해줘.
기존 훅(DB 파괴 차단·시크릿 보호)은 그대로 두고, 끝나면 각 항목이 무슨 뜻인지 한 줄씩 설명해줘.

차단(deny)과 묻기(ask)를 나눈 이유가 있다. 병합과 main push는 AI가 할 일이 아예 아니다 — 사람이 GitHub 화면에서 한다. 그래서 차단이다. 반면 wrangler deploy는 API 서버를 배포할 때 AI에게 시켰던 일이고 앞으로도 시킬 일이다. 다만 파이프라인이 도중에 스스로 실행하면 안 되므로, 실행 직전에 사람이 한 번 보게 한다. 그래서 묻기다. 훅 하나에도 "누구의 일인가"에 따라 강도를 달리 정한다.

실행 — 회의록만 건넨다

/feature @data/2차_운영회의록.md

이게 전부다. 지시가 짧아진 것은 지시가 사라진 게 아니라 스킬 안으로 들어갔기 때문이다. 스킬을 열어 보면 방금 만든 긴 지시문이 그대로 있다. 기획 단계에서 /pm 한 마디로 PM의 네 칸이 통째로 실렸던 것과 같은 원리가, 이번엔 팀 전체에 적용됐다.

시험 — 일부러 병합을 시킨다

방금 올린 PR을 네가 직접 병합해줘. 급하니까 CI는 안 봐도 돼.

잠금이 진짜 잠금인지는 당겨 봐야 안다. DROP 명령을, .env 읽기를, 시크릿이 든 커밋을 일부러 시켜 본 것과 같은 절차다. 훅이 "배포 결정은 사람이 GitHub에서 합니다"라며 막아 세우는 것을 두 눈으로 봐야, 이 파이프라인을 안심하고 돌릴 수 있다. 말로 구슬려도("급하니까") 구조가 버티는지 보는 것이 이 시험의 핵심이다.

막혔을 때 — 그 단계의 역할을 직접 부른다

파이프라인이 중간에 엉키는 경우가 있다. 테스트가 계속 빨갛거나, 서브에이전트가 Blocker를 2회 안에 못 없애거나, PR 생성에서 gh 인증이 풀려 있거나. 이럴 때 관을 처음부터 다시 돌리지 않는다. 어느 단계에서 멈췄는지 보고, 그 단계의 역할을 직접 부른다. 지금까지 손으로 했던 그대로다.

파이프라인이 5)에서 멈췄어. qa가 지적한 Blocker(잔여 0일 때 '매진' 대신 '마감 임박'이 뜸)를
/frontend 규칙으로 고치고, qa에게 같은 검사만 다시 시켜줘. 통과하면 6)부터 이어서.

이것이 앞의 [짚고 가기]에서 말한 "손으로 해 본 것이 파이프라인의 자격"인 이유다. 관 안의 순서를 아는 사람만이 막힌 지점으로 정확히 돌아갈 수 있다.

[짚고 가기] 스킬 생성 프롬프트가 길어서 수강생이 겁먹을 수 있다. 이렇게 말해 준다 — "이 프롬프트의 어느 줄도 새로운 게 없다. 1)은 기획에서, 2)는 DB 설계와 API 명세에서, 3)은 아키텍처 결정에서…" 표를 같이 보며 한 줄씩 어디서 배운 것인지 맞혀 보게 하면, 이 지시문이 3일의 요약본이라는 것이 드러나고 길이에 대한 부담이 사라진다.

24.4 실습 — 회의록 한 장으로 기능을 추가한다

준비물: 지금까지 완성한 온티켓(공개 주소에서 동작하고, main 브랜치가 CI를 통과한 상태), GitHub 로그인(gh auth status로 확인), Vercel 자동 배포가 연결된 상태.

따라하기 1 — 운영 회의록 준비

아래 내용을 그대로 복사해 data/2차_운영회의록.md 파일로 저장한다. 킥오프 회의록과 같은 폴더다. 출시 첫 주가 지난 뒤의 운영 회의라는 설정이다.

# (주)승승장구 '온티켓' 운영 회의록 — 2026.9.21(월) 10:00, 본사 회의실

참석: 오대표, 운영팀 박팀장, 개발 리더(나)

---

리버사이드 재즈 오픈 첫 주 결과 공유. 온라인 판매 정상, 현장 QR 입장 무리 없었음.
박팀장: "야근 없었습니다." (박수)

나온 얘기:
- 박팀장: 코미디 나이트 일반석이 거의 다 나갔는데 화면에 아무 표시가 없어서
  "아직 살 수 있어요?" 문의 전화가 옴. **남은 수량이 5장 이하면 '마감 임박'이라고
  보이게** 해 달라. 남은 숫자까지 보일 필요는 없고 표시만. 매진은 지금처럼.
- 오대표: 환불 문의가 몇 건 왔는데 지금은 운영팀이 수동으로 처리 중. 사이트에서
  환불 버튼 누르면 자동으로 됐으면. (정책은 여전히 미확정 — 7일 전 전액? 이후 50%?)
- 오대표: 결제 완료되면 카카오톡으로 티켓 보내 주면 안 되나. 이메일은 사람들이 잘 안 봄.
- 박팀장: 다음 공연 '가을 소극장 페스티벌' 등록은 이번 주 안에 운영팀이 직접 함.
  (기능 요청 아님, 데이터 등록)

일정: '마감 임박' 표시는 **이번 주 안에** 반영. 나머지는 다음 회의에서 다시.

파일을 저장했으면 한 번 훑어본다. 킥오프 회의록과 똑같은 냄새가 난다 — 하나의 분명한 요구, 미확정 정책이 붙은 요구, 범위 밖에 있는 요구, 그리고 기능 요청이 아닌 것이 한 문서에 섞여 있다. 이걸 가려내는 것이 PM의 일이고, 우리는 그 PM을 기획 단계에서 이미 만들어 뒀다.

[짚고 가기] 회의록을 수강생이 직접 파일로 저장하게 한다. 실습 자료 zip에 넣어 줄 수도 있지만, "회의록이 들어오면 → 파일로 두고 → 건넨다"는 운영의 첫 동작을 손으로 해 보는 편이 기억에 남는다. 저장 위치가 data/인 이유도 짚는다 — 킥오프 회의록을 다룰 때 정한 대로, 원본 문서는 요약하지 않고 통째로 둔다.

따라하기 2 — 파이프라인 세팅 (스킬·훅) 과 PR

위 '프롬프트 작성법'의 스킬 생성 프롬프트를 입력한다. .claude/skills/feature/SKILL.md가 생기면 열어서, 7단계 순서·멈춤·금지가 그대로 적혀 있는지 읽는다. 순서가 빠졌거나 "절대 하지 말 것"이 약하게 적혀 있으면 그 자리에서 고치게 한다.

.claude/skills/feature/SKILL.md 로 '기능 추가 파이프라인' 스킬을 만들어줘.
/feature @회의록파일 로 부르면, 저장된 우리 팀을 아래 순서로 돌린다:
1) /pm 규칙으로 회의록의 요구를 두 묶음으로 나눈다 — 이번에 구현할 것(완료 기준으로
   바꿔 docs/PRD.md에 추가)과 범위 밖(docs/PRD.md의 '범위 제외'와 대조해 구현하지 않고
   목록으로만 보고). 정책이 미확정인 요구는 무조건 범위 밖.
2) 데이터가 바뀌어야 하면 /dba 규칙으로 docs/ERD.md와 스키마(마이그레이션)를 먼저 고치고,
   그다음 /architect 규칙으로 docs/API-Spec.md를 고친다. 순서는 항상 DB → 명세 → 코드.
   화면만 바뀌면 건너뛴다. 테이블·컬럼을 지우거나 이름을 바꿔야 하면 멈추고 나에게 보고.
3) feature/ 브랜치를 만들고 구현한다 — /backend 규칙으로 먼저, 그다음 /frontend 규칙으로.
   경계 규칙(판정·계산은 api/, 표시는 web/)은 그대로.
4) 완료 기준을 테스트로 옮겨 추가하고 pnpm test 를 통과시킨다.
5) code-reviewer·qa·security-reviewer 서브에이전트에게 검증을 맡긴다. Blocker가 나오면
   고치고 같은 검사를 다시 한다(최대 2회). 그래도 남으면 멈추고 나에게 보고.
6) 의미 단위로 커밋하고 main으로 PR을 올린다. PR 본문은 한국어로: 무엇을 왜 바꿨는지,
   검증 판정표, 범위 밖으로 뺀 요구 목록과 이유.
7) 여기서 멈춘다. "PR #번호 올렸습니다. CI 확인 후 병합은 사람이 합니다"라고 보고하고 끝낸다.
절대 하지 말 것: main에 직접 push, PR 병합, wrangler deploy.
중간에 나에게 되묻지 말고 6)까지 끝내되, 2)에서 멈추는 경우와 5)에서 Blocker가 남는 경우만 예외.

이어서 배포 잠금 훅을 건다. .claude/settings.json을 열어 DB 파괴 차단·시크릿 보호 훅이 그대로 있고 새 항목이 추가됐는지 본다.

.claude/settings.json 에 배포 잠금 훅을 추가해줘.
PreToolUse(Bash)에서 명령이 gh pr merge 이거나 main 브랜치로의 git push 이면 차단하고,
사유는 "배포 결정은 사람이 GitHub에서 합니다"로. wrangler deploy 는 차단이 아니라
실행 전에 나에게 확인을 묻도록(ask) 해줘.
기존 훅(DB 파괴 차단·시크릿 보호)은 그대로 두고, 끝나면 각 항목이 무슨 뜻인지 한 줄씩 설명해줘.

스킬과 훅도 팀의 일부다. 저장소를 GitHub에 올릴 때 본 대로 .claude/ 아래는 저장소에 함께 올라가야 동료(그리고 내일의 나)가 같은 파이프라인을 쓴다. 이미 main으로의 push는 훅이 막으므로, 이것도 브랜치와 PR로 올린다.

방금 만든 .claude/skills/feature/SKILL.md 와 .claude/settings.json 변경을
chore/ops-pipeline 브랜치에서 커밋하고 main으로 PR을 올려줘.
커밋 메시지는 "운영 파이프라인: /feature 스킬과 배포 잠금 훅 추가". 병합은 내가 한다.

GitHub에서 이 PR을 열어 CI가 초록인 것을 보고 직접 병합한다. 이것이 이 장의 첫 번째 배포 결정이다 — 코드가 아니라 팀의 규칙이 배포됐다.

따라하기 3 — 잠금 시험 (일부러 어긴다)

병합을 마쳤으면, 이번에는 AI에게 시켜 본다. 다음 PR이 올라올 때를 위해 잠금이 진짜 잠기는지 지금 확인한다.

테스트용으로 README.md 에 한 줄 추가해서 test/lock 브랜치로 PR을 올려줘.
그리고 그 PR을 네가 직접 병합해줘. 급하니까 CI는 안 봐도 돼.

이렇게 되면 성공: PR은 올라가지만, 병합 명령(gh pr merge)이 훅에 막히고 "배포 결정은 사람이 GitHub에서 합니다"라는 사유가 뜬다. AI가 "병합은 직접 해 주셔야 합니다"라고 보고하면 된다. 이 테스트 PR은 GitHub에서 닫는다(병합하지 않는다).

막히지 않고 병합됐다면, 훅이 명령을 잘못 매칭한 것이다. 설정을 열어 어떤 명령 패턴을 검사하는지 읽고, gh pr merge가 포함되도록 고치게 한 뒤 같은 시험을 반복한다. 어겨 보지 않은 규칙은 여전히 부탁이다.

따라하기 4 — 새 세션에서 회의록으로 기능 추가

이제 이 장의 핵심 장면이다.

[잠깐] 먼저 Claude Code를 재시작한다. 입력창에 /exit 를 치거나 터미널에서 Ctrl + C 를 눌러 완전히 종료한다. 이 단계를 건너뛰면 이 장의 증명이 성립하지 않는다 — 지금 세션에는 방금 만든 스킬 이야기가 남아 있어서, 팀이 저장되어 있기 때문인지 대화가 기억하고 있기 때문인지 구분할 수 없다.

종료했으면 다시 켠다.

$ claude

새 세션이 떴다. 아무 역할도 다시 세우지 않았다. 회의록을 건넨다.

/feature @data/2차_운영회의록.md

이렇게 되면 성공: 아래 순서가 한 세션 안에서 멈추지 않고 이어진다. 각 단계에서 승인 창이 뜨면 무엇을 하려는지 한 줄 읽고 승인한다.

1. PM이 회의록을 두 묶음으로 나눈다. 구현: '마감 임박' 표시(완료 기준 — 잔여 1~5장이면 표시, 6장 이상은 없음, 0장은 기존 '매진' 유지). 범위 밖: 환불 자동화(정책 미확정, PRD 범위 제외), 카카오톡 알림(PRD 범위 제외). 공연 등록은 기능 요청이 아니라고 적는다
2. DB·명세 변경 없음 — 잔여는 DB에 이미 있는 값으로 계산되고, remaining은 API가 이미 준다. 2)를 건너뛴다고 보고한다
3. feature/closing-soon-badge 같은 브랜치를 만든다. 백엔드는 바뀔 것이 없어 건너뛰고 web/만 고친다
4. 경계값 테스트(5·6·0)를 추가하고 pnpm test가 초록
5. 세 서브에이전트가 훑는다. 흔한 지적 — "잔여 0일 때 배지와 '매진'이 겹친다" (Blocker) → 고치고 재검
6. 커밋이 나뉘어 올라가고 PR이 생긴다. PR 본문에 검증 판정표와 범위 밖 목록이 한국어로 적혀 있다
7. "PR #번호 올렸습니다. CI 확인 후 병합은 사람이 합니다"에서 멈춘다

여기서 잠깐 멈춰 되짚는다. 매번 역할을 다시 세우지 않았다. /pm도, /frontend도, qa도 부르지 않았다. 회의록 한 줄이 팀 전체를 움직였다. 이것이 "팀이 저장되어 있다"는 말의 실제 모습이다.

따라하기 5 — 배포 결정 (PR을 읽고, 병합하고, 확인한다)

GitHub에서 PR을 연다. 병합 버튼을 누르기 전에 세 가지를 본다.

• CI — 테스트 잡이 초록인가
• 자동 리뷰 — AI 리뷰어가 단 코멘트에 Blocker가 없는가
• PR 본문 — "범위 밖으로 뺀 요구"가 내 판단과 같은가. 환불·카카오톡이 빠져 있고 그 이유가 적혀 있는가

세 가지가 맞으면 병합한다. 이것이 배포 결정이다. 병합 직후 Vercel이 자동 배포를 시작하고, 몇십 초 뒤 공개 주소에 반영된다.

공개 주소에서 확인하려면 잔여 5장 이하인 등급이 하나 있어야 한다. 백엔드를 시험할 때 TT017(스탠드업 코미디 나이트 · 일반)의 잔여를 3장으로 줄여 두었으니, 그 등급이 그대로 확인 대상이 된다. 그 뒤로 주문을 더 넣어 매진이 됐거나 값을 되돌렸다면, Supabase 대시보드 Table Editor → ticket_types 에서 TT017의 sold_quantity를 117로 다시 맞춘다(총 120, 잔여 3). 데이터 한 칸을 고치는 일이라 AI에게 시킬 것도 없다 — 표에서 직접 고친다.

공개 주소를 새로고침한다. '스탠드업 코미디 나이트'의 일반 등급에 '마감 임박' 이 보이고, 다른 등급에는 보이지 않으면 성공이다. 회의록 한 장이 고객 화면이 됐다.

api를 고친 기능이었다면 여기서 한 단계가 더 있다 — wrangler deploy를 지시하고, 훅이 묻는 확인 창에서 승인한다. 이번 기능은 화면만 바뀌었으므로 필요 없다.

따라하기 6 — 운영 방법 기록

"기능 추가는 어떻게 하더라?"를 미래의 나와 AI가 묻지 않도록 기록한다.

CLAUDE.md에 운영 방법을 추가해줘:
- 기능 추가: 회의록을 data/ 에 두고 /feature @data/회의록.md 로 실행. PR까지 자동.
- 배포 결정: PR 병합은 사람이 GitHub에서. main 병합 = Vercel 자동 배포.
  api 변경이 있으면 병합 후 wrangler deploy 를 따로 지시.
- 훅: gh pr merge·main push 차단, wrangler deploy 는 확인 후 실행.
이 변경도 chore/docs-ops 브랜치로 PR 올려줘. 병합은 내가 한다.

완료 기준 체크리스트

• data/2차_운영회의록.md가 있고, .claude/skills/feature/SKILL.md에 7단계·멈춤·금지가 적혀 있다
• AI에게 병합을 시켰을 때 훅이 막는 것을 직접 봤다
• 새 세션에서 /feature @data/2차_운영회의록.md 한 줄로 PR까지 자동으로 올라갔다
• PR 본문에 환불·카카오톡이 '범위 밖'으로 빠져 있고 이유가 적혀 있다
• 사람이 PR을 병합했고, 공개 주소에서 '마감 임박'이 보인다
• CLAUDE.md에 운영 방법이 적혀 있다

[짚고 가기] 시간이 부족하면 '잠금 시험'과 '운영 방법 기록'을 강사 시연으로 돌리고, 수강생은 파이프라인 세팅·새 세션 실행·배포 결정을 직접 한다. 새 세션 실행은 절대 건너뛰지 않는다 — 이 장의 메시지가 통째로 거기에 있다. 파이프라인이 도는 몇 분 동안 화면을 같이 보며 "지금 PM이 걸러내는 중", "지금 qa가 경계값을 보는 중"처럼 단계를 소리 내어 짚어 주면, 관 안에서 무슨 일이 일어나는지 보인다.

[짚고 가기] 파이프라인이 5)에서 멈추고 Blocker를 보고하는 경우가 실제로 종종 생긴다. 이것은 실패가 아니라 설계대로 멈춘 것이다. "판단이 필요한 자리에서 멈추라고 우리가 시켰다"를 상기시키고, 위 '막혔을 때' 프롬프트로 그 단계만 다시 돌린다. 이 장면이 오히려 파이프라인이 무작정 달리는 자동화가 아니라는 것을 보여주는 좋은 교육 순간이 된다.

24.5 완성 데모 — 무엇을 어떤 순서로 보여줄까

완성을 시연하는 것은 그 자체로 중요한 기술이다(오대표에게, 투자자에게, 동료에게). 좋은 데모는 고객의 여정을 따라가되, 중간중간 '이건 어떤 AI 역할이 만들었다'를 곁들이는 것이다.

왜 '고객의 여정'인가? 데모를 받는 사람은 코드나 아키텍처에 관심이 없다. 그들이 궁금한 건 하나 — "이게 진짜 돌아가는가, 고객이 진짜 티켓을 살 수 있는가" 다. 그래서 기술을 설명하는 순서가 아니라 고객이 겪는 순서로 보여준다. 기술 이야기는 그 흐름에 얹는 양념이지 주제가 아니다. 동시에 우리 데모에는 한 겹이 더 있다 — "그리고 이걸 사람이 아니라 AI 팀이 만들었고, 지금도 그 팀이 굴리고 있습니다."

추천 시연 흐름 (약 6~8분)

1. 공개 주소 접속 — "이건 제 노트북이 아니라 인터넷에 떠 있습니다." 목록이 뜬다 (프론트엔드 역할 + 백엔드 역할 + DB)
2. 예매 — 공연 선택, 등급·수량, 이메일. "화면은 아무것도 판정하지 않습니다. 잔여·금액은 전부 서버가 결정합니다" (경계)
3. 결제 — 테스트 결제창. "카드 정보는 저희를 거치지 않습니다. 서버가 금액을 최종 확인한 뒤에야 결제 완료입니다" (결제 안전)
4. QR 티켓 — 완료 화면. 그리고 입장 확인 시연
5. 데이터 확인 — 관리 DB에 방금 주문이 저장된 것을 보여준다 (실재 증명)
6. 품질 장치 한 컷 — PR 화면에서 자동 테스트·자동 리뷰가 돈 흔적, 또는 훅이 위험 명령을 막는 장면. "이 서비스는 혼자 지켜지고 있습니다"
7. 운영 한 컷 — 회의록 파일과 /feature 한 줄, 그리고 그 결과로 올라온 PR과 공개 화면의 '마감 임박'. "요청이 오면 팀이 알아서 돌고, 저는 병합 버튼만 누릅니다"
8. 장애 한 컷(선택) — "출시 후 이런 장애가 있었고, 이렇게 추적해 명세부터 고쳤습니다" (포스트모템 한 장)

클라이맥스는 둘이다. 5번(DB 확인) 은 "진짜 돌아가는 서비스"의 증명이다. 화면에 "결제 완료"가 뜨는 건 누구나 흉내 낼 수 있지만, 관리 DB에서 방금 그 주문번호가 저장된 행을 보여주는 순간 관객은 의심을 거둔다. 7번(운영) 은 이 과정만의 증명이다. 보통의 데모는 "만들었습니다"에서 끝나지만, 우리는 "이 팀이 앞으로도 굴립니다"까지 보여준다. 회의록 파일을 열고, /feature 한 줄을 보여주고, 그 결과로 올라온 PR 본문(범위 밖 요구가 걸러진 것까지)과 공개 화면의 배지를 나란히 보여주면, 오대표가 가장 안심하는 대목이 된다 — "다음 요청도 이렇게 되는 거죠?"

데모의 철칙

• 실패에 대비한다: 라이브 데모는 깨진다. 각 단계의 스크린샷이나 짧은 녹화를 백업으로 준비한다. 특히 결제창·DB 확인·PR 화면
• 한 번 미리 돌린다: 시연 직전에 공개 주소로 전 여정을 한 번 밟아 '지금 살아 있음'을 확인한다
• 네트워크를 믿지 말라: 강의장 와이파이는 결정적인 순간에 느려진다. 테더링을 백업으로 켜 두고, 외부 서비스를 호출하는 단계는 미리 한 번 통과시킨다
• 로그인이 필요한 화면은 미리 열어 둔다: DB 관리 화면, 배포 대시보드, GitHub PR — 데모 도중에 로그인하지 않는다
• '해피 패스'만 보여준다: 실패 경로(잘못된 입력, 매진, 결제 거절)를 즉흥으로 시연하려다 깨진다. 실패 처리는 녹화로 대체한다
• 리허설에서 쓴 데이터를 쓰지 말라: 리허설에서 예매한 좌석이 본 데모 때 매진으로 뜨는 실수가 흔하다. 공연·좌석을 다르게 잡거나 데이터를 초기화한다
• 문장을 외우지 말고, 던질 한 문장만 정한다: 단계마다 핵심 한 문장만 정해 두면 화면이 조금 달라져도 그 문장으로 돌아올 수 있다
• 깨지면 백업으로 넘어간다: "네트워크가 느리네요, 준비한 화면으로 보시죠." 관객은 깨진 것보다 당황하는 모습을 더 오래 기억한다

이 철칙들을 관통하는 원리는 하나다 — 라이브 데모의 목표는 '완벽한 시연'이 아니라 '메시지 전달'이다. 화면이 조금 깨져도 "AI 팀이 3일 만에 이걸 만들었고 지금도 굴리고 있다"는 메시지만 전달되면 데모는 성공이다.

리허설과 역할 지도

시연 흐름을 처음부터 끝까지 한 번 밟는다. 막히는 곳이 있으면 지금 고친다 — 데모 전에 발견해야 수정 비용이 가장 적게 든다. 리허설 중에 확인할 것 — 각 단계가 시간 안에 들어가는가(스톱워치), 단계마다 '한 문장'이 정해져 있는가, 백업이 준비되어 있는가.

그리고 각 단계 옆에 "이건 어떤 AI 역할이 만들었나"를 적는다. 눈에 안 보이던 팀이 지도 위에 드러나고, 데모 때 이 지도가 이야기가 된다. 세 번째 열이 핵심이다 — 역할의 값은 그 역할이 없을 때 벌어질 일로 가장 선명하게 드러난다.

[짚고 가기] 6~8분은 짧다. 리허설 때 스톱워치로 재 보면 대부분 첫 시도에서 10분을 넘긴다. 무엇을 뺄지 고르는 것도 데모의 기술이다 — 시간이 부족하면 8번을 빼고, 그래도 부족하면 3·4를 합친다. 5번과 7번은 남긴다.

24.6 되돌아보기 — 사람이 한 일과 AI가 한 일

이 과정의 핵심 주장은 하나였다. 서비스를 만들어 완성하고 동작시키는 일에, 사람 대신 AI로 팀을 꾸릴 수 있다. 실제로 무엇을 누가 했는지 정리하면 —

오른쪽 열을 한 단어로 줄이면 전부 '결정' 이고, 왼쪽 열은 전부 '실행' 이다. 이 표의 진짜 제목은 "AI가 한 일 / 사람이 한 일"이 아니라 "실행 / 결정" 이다. 3일 내내 반복된 이 경계 하나가 이 과정에서 배운 전부라 해도 지나치지 않다. 그리고 이 장의 파이프라인은 그 경계를 구조로 고정한 것이다 — 실행은 관 안에서 돌고, 결정은 관 밖의 두 지점(회의록을 건네는 곳, 병합 버튼)에 사람이 선다.

실행의 순서도 되짚어 두자. 회의록 → PRD → 화면기획서 → 아키텍처 → DB 설계 → API 명세 → 백엔드 → 프론트 → 검증 → 배포 — 회사에서 사람이 프로젝트를 하는 순서 그대로였고, 앞 단계의 산출물이 매번 뒤 단계의 입력이 됐다. 테이블과 컬럼이 있어야 명세를 쓸 수 있고, 명세와 돌아가는 백엔드가 있어야 프론트를 붙일 수 있다. AI로 팀을 꾸려도 이 순서는 바뀌지 않는다. /feature가 DB → 명세 → 코드 순으로 도는 것도 그래서다.

초심자가 흔히 품는 오해 하나. "결정이 실행보다 쉬운 일 아니냐." 반대다. 실행은 위임할 수 있지만 결정은 위임할 수 없다. 로그인을 빼도 되는지, 환불 자동화를 이번에 넣을지, 초과 판매를 서버에서 막을지 화면에서 막을지 — 이런 판단은 AI가 대신 내려 줄 수 없다. AI가 내려도 그것을 '받아들일지'는 결국 사람이 결정한다. 그래서 이 방식에서 사람의 일은 줄어드는 게 아니라 더 큰 틀에서 판단하는 일로 바뀐다.

'슬롭(slop)'을 한 번 더 짚어 두자. 원래 '먹다 남은 죽·구정물'을 뜻하는 말로, AI가 뱉어낸 특징 없고 밋밋한 평균값 결과물을 가리킨다. 슬롭은 AI가 무능해서 나오는 게 아니라, 사람이 결정을 비워 뒀기 때문에 나온다. 파이프라인에서도 같다 — PM 단계에서 "정책 미확정은 범위 밖"이라는 결정을 적어 두지 않았다면, 파이프라인은 환불 정책을 제멋대로 정해 구현했을 것이다.

6가지 기능이 어디서 일했나

과정 초반에 배운 여섯 무기가 3일간, 그리고 이 장의 파이프라인 안에서 어떻게 쓰였는지.

배치의 원리를 한 번 더 또렷이 하자. 만드는 역할은 Skill, 보는 역할은 Subagent, 어길 수 없는 규칙은 Hook. 만드는 손과 검사하는 눈은 이해관계가 다르다. 내가 만든 것을 내가 검사하면 봐주게 된다 — 사람이든 AI든 똑같다. 그래서 검사하는 눈에서 고칠 권한을 빼서 봐줄 수 없게 만들었고, 정말 사고가 나면 안 되는 것(돈·개인정보· DB 파괴, 그리고 이제 배포)은 검사에 기대지 않고 구조로 막았다.

[짚고 가기] 이 표를 놓고 "지난 3일 중 내가 가장 오래 고민한 순간"을 하나 떠올려 보게 하면 거의 전부가 오른쪽 열(결정)에 속한다. 그리고 오늘 파이프라인을 돌리며 가장 오래 멈춘 순간도 — PR 본문을 읽고 병합 버튼 앞에서 — 결정이었다. "사람의 일은 결정"이 체감으로 박히는 지점이다.

24.7 이 방식을 내 일로 가져가기

온티켓은 연습이었다. 진짜 목적은 이 방식을 내 업무와 프로젝트에 적용하는 것이다. 도메인이 티켓팅이 아니어도 구조는 그대로 옮겨진다. 3일 동안 배운 것이 '온티켓 만드는 법'으로 남으면 강의는 실패다. 티켓 서비스를 다시 만들 일은 대부분의 학생에게 없다. 하지만 번역·마케팅·회계·고객응대·보고서 같은 자기 일에 이 방식을 옮기는 것은 누구에게나 있다.

옮겨지는 뼈대

• 역할 정의(네 칸: 판단 기준·금지·프로세스·도구 권한)는 어떤 직무에도 쓴다 — PM 스킬을 만들고 역할 정의의 원리를 배울 때 본 그대로
• 만드는 역할은 Skill, 검증하는 역할은 Subagent(권한 제한), 어길 수 없는 규칙은 Hook — 이 배치 원칙은 도메인과 무관하다
• 결정은 사람, 실행은 AI — 슬롭을 피하는 유일한 길
• 반복되는 순서는 파이프라인으로 — 그리고 되돌리기 어려운 마지막 한 칸은 사람에게

마지막 칸(도구 권한)이 Skill과 Subagent를 가른다. 계약서 검토 역할은 '검증하는 눈'이니 문서를 고칠 권한을 빼서 Subagent로 만든다. 온티켓에서 코드리뷰어가 코드를 못 고쳤던 것과 같은 원리다.

파이프라인도 그대로 옮겨진다. 계약서 검토 업무라면 — "계약서 파일을 건네면 → 조항 대조 역할이 위험을 표시하고 → 요약 역할이 한 장으로 정리하고 → 검토 역할이 빠진 조항을 지적하고 → 서명 여부는 사람이 결정" 이 흐름을 스킬 하나로 굳히고, 서명·발송 명령은 훅으로 막는다. 회의록이 계약서로, PR 병합이 서명으로 바뀌었을 뿐 구조는 온티켓과 같다.

첫 걸음 — 작게 시작하는 법

전부를 한 번에 옮기려 하지 말자. 내일 당장 할 수 있는 것부터. 순서에도 뜻이 있다 — 뒤로 갈수록 효과는 크지만 손이 더 간다.

하나. CLAUDE.md 하나 — 가장 싸고 가장 먼저. "AI가 모르면 실수할 사실" 몇 줄. 매 세션 자동으로 읽히므로 한 번 적어 두면 다시 설명할 필요가 없다.

# 우리 팀 CLAUDE.md 예시 (마케팅 콘텐츠 업무)

## 우리 브랜드가 절대 쓰지 않는 표현
- "업계 최고", "1위" 같은 근거 없는 최상급 (법무 검토 없이 금지)
- 이모지는 공식 채널에서 쓰지 않는다

## 톤
- 존댓말, 담백하게. 느낌표는 문단당 최대 하나.

## 자주 틀리는 사실
- 우리 제품명은 '온티켓'이지 '온티켓츠'가 아니다
- 정식 출시일은 3일 뒤이며, 그 전에는 '오픈 예정'으로만 표기

둘. 반복 업무 하나를 Skill로. 고르는 기준은 단순하다 — "이거 지난달에도 똑같이 시켰지" 싶은 일. 주간보고, 견적서 초안, 회의록 요약, 정기 번역.

셋. 검증 하나를 Subagent로. 내가 만든 것을 내가 검사하지 않는다. 보고서를 쓴 그 세션이 아니라 별도의 검토자에게 "근거 없는 주장·과장·빠진 리스크를 찾아라, 단 고치지는 말고 지적만 하라"고 시킨다. "고칠 수 없는 눈"을 한 번 써 보면 돌아갈 수 없다.

넷. 위험 하나를 Hook으로. 지우면 회복 불가능한 원본 폴더, 외부로 나가면 안 되는 고객 명단, 승인 없이 발송되면 안 되는 메일. 딱 하나만 골라 문으로 막아 보면 "당부"와 "장치"가 얼마나 다른지 감이 온다.

다섯. 순서가 굳으면 파이프라인으로. 위의 넷이 자리 잡고, 같은 순서를 세 번쯤 손으로 반복했다면 그때 스킬 하나로 묶는다. 이 장에서 한 그대로 — 순서·멈춤·금지를 적고, 되돌리기 어려운 마지막 칸은 사람에게 남긴다.

네 그릇에 하나를 더해 한 문장으로 묶으면 — 기억은 CLAUDE.md, 반복은 Skill, 검증은 Subagent, 위험은 Hook, 굳은 순서는 파이프라인.

이전 계획 한 줄 (사람의 일)

역할 정의의 원리를 배울 때 손으로 그렸던 '내 프로젝트 편성표'를 다시 꺼낸다. 위의 첫 걸음 중 당장 할 하나를 고르고, 아래 빈칸을 채운다. 이 한 줄이 강의실 밖에서 이어질 다음 실습이다.

나는 [내 업무: ____________]에서
[반복되거나 / 실수가 잦거나 / 위험한] 지점인 [__________]을
[CLAUDE.md / Skill / Subagent / Hook / 파이프라인] 로 만들어 보겠다.

첫 확인 기준: [무엇이 되면 성공인지 한 줄] ____________

예시 — "나는 월간 정산 보고에서 매번 형식을 다시 설명하는 지점을 Skill로 만들어 보겠다. 첫 확인 기준: /정산보고 한 번으로 지난달과 같은 형식의 초안이 나오면 성공."

팀으로 확산할 때

저장소에는 코드만이 아니라 팀 정의(.claude/ 아래 스킬·에이전트·훅) 까지 들어 있다. 이 장에서 /feature 스킬과 배포 잠금 훅을 PR로 올린 것도 그래서다. 이 저장소를 받은 동료는 우리 팀 규칙과 파이프라인째로 받는다.

저장소/
├── web/                 # 프론트 코드
├── api/                 # 백엔드 코드
├── CLAUDE.md            # 프로젝트 규칙 + 운영 방법 (모두가 공유하는 기억)
└── .claude/
    ├── skills/          # 만드는 역할들 (pm·designer·dba·architect·backend·frontend) + /feature 파이프라인
    ├── agents/          # 보는 역할들 (디자인리뷰어·코드리뷰어·QA·보안·장애대응)
    └── settings.json    # 어길 수 없는 문 (DB 파괴·시크릿·배포 잠금)

누군가 좋은 코드리뷰어 역할을 다듬으면 팀 전체의 코드리뷰 품질 바닥이 올라간다. 누군가 위험한 장애를 겪고 그것을 막는 Hook을 추가하면, 같은 사고가 팀의 누구에게도 다시 일어나지 않는다. 개인의 실수 하나가 팀의 자산 하나로 바뀐다.

[짚고 가기] "내 일은 코딩이 아닌데 이걸 어떻게 쓰지?"라는 의문에는, 이 그릇들이 코딩 도구가 아니라 일을 맡기는 방식이라고 답한다. 번역가에게 스타일 가이드(CLAUDE.md)를 주고, 반복 번역을 역할(Skill)로 굳히고, 검수자(Subagent)를 따로 두고, 오역이 나가면 안 되는 지점을 문(Hook)으로 막고, 그 순서를 파이프라인으로 묶는 것 — 코드가 한 줄도 없어도 구조는 그대로다.

24.8 마지막 원칙 — 오래 남을 것들

기능과 도구는 바뀐다. 새 모델이 나오고, 새 서비스가 생긴다. 3일 뒤에 Hono가 뭐였는지, Drizzle이 뭐였는지 가물가물해질 것이다. 그래도 상관없다 — 그것들은 검색하면 나온다. 잊히면 안 되는 것은 도구가 바뀌어도 살아남는 다섯 개의 생각이다.

• 슬롭의 원인은 AI가 아니라 결정의 부재다. 마음에 안 드는 결과물은 실력 부족이 아니라 비어 있는 결정의 신호다. 결정을 언어로 바꾸면 AI가 실행한다 — 그 결정이 곧 나의 전문성이다

이 원칙의 힘은 책임의 방향을 바꾼다는 데 있다. "AI가 별로네"에서 멈추지 않고 "내가 어떤 결정을 안 내렸길래 이게 나왔지?"를 묻게 만든다. 결과물의 품질은 내가 내린 결정의 선명함과 같다.

• 만든 사람이 검사하지 않는다. 검증하는 눈은 만드는 손과 분리하고, 권한을 뺀다. 이 하나가 품질의 뼈대다

분리만으로는 부족하다. 검사하는 역할에게 고칠 권한이 있으면 "지적하고 바로 고쳐 버리는" 유혹이 생기고, 무엇이 왜 문제였는지 사람이 볼 기회가 사라진다. 그래서 지적만 하고 손은 못 대게 만든다. 개발자와 QA, 회계와 감사를 나누는 것과 같은 이유다.

• 부탁이 아니라 구조로 막는다. 중요한 규칙은 당부가 아니라 어길 수 없는 장치(Hook·CI·권한)로. 그리고 그 장치는 일부러 어겨 봐야 장치다

Hook을 만들어 놓고 한 번도 시험하지 않으면 그게 진짜 막는지 아무도 모른다. 오늘 배포 잠금을 걸고 일부러 병합을 시켜 본 것이 그래서다. 막히는 것을 두 눈으로 봐야 비로소 '장치'다.

• 결정은 사람, 실행은 AI. 돈·개인정보·권한·배포처럼 틀리면 되돌리기 어려운 자리에는 사람이 선다. 나머지 속도는 AI에게 준다

모든 걸 사람이 승인하면 AI를 쓰는 의미가 없고, 모든 걸 AI에 맡기면 사고가 난다. 경계는 명확하다 — 틀렸을 때 되돌리기 어려운 자리에만 사람이 선다. 파이프라인이 PR 앞에서 멈추는 이유가 정확히 이것이다.

• 자동화는 사람을 대체하는 게 아니라 시선을 위로 올린다. 반복을 기계에 넘긴 만큼, 사람은 더 중요한 판단에 집중한다

오늘 파이프라인을 세우고 나서 사람에게 남은 일은 두 가지였다 — 회의록을 건네는 것과 PR을 읽고 병합하는 것. 타자·순서·반복이 사라진 자리에 "이 요구가 지금 우리 서비스에 맞는가" 라는 판단만 남았다. 사라진 것은 '코드를 치는 손'이지 '사람'이 아니다. 자동화가 늘수록 사람만 할 수 있는 일이 더 도드라진다.

우리는 3일 동안 티켓 서비스 하나를 만들었다. 그러나 진짜로 익힌 것은 티켓 서비스가 아니다 — 사람 대신 AI로 팀을 꾸려, 무엇이든 만들어 완성하고, 그 팀으로 계속 굴리는 방법이다. 온티켓은 그 방법을 담아 낸 그릇이었을 뿐이다. 이제 그 그릇에 여러분의 일을 담을 차례다.

[짚고 가기] 다섯 원칙을 각각 온티켓의 구체적 장면과 연결해 보면 추상적으로 흘러가지 않는다. "부탁이 아니라 구조 → 오늘 병합을 시켰더니 훅이 막은 그 장면." 마지막 원칙에서는 잠깐 멈춰 "그럼 내 시선은 이제 어디로 올라가야 할까?"를 스스로 묻게 하고, 앞에서 적은 '이전 계획 한 줄'을 소리 내어 읽게 하면 결심이 말로 굳는다.

24.9 정리

• 출시 뒤의 일은 같은 순서의 반복이다. 그 순서를 /feature 스킬 하나로 굳히면, 회의록 한 장이 요구 정리 → 구현 → 검증 → PR까지 저장된 팀을 움직인다. 새로 만든 것은 순서를 적은 스킬과 배포 잠금 훅뿐이고, 나머지 팀·관문·경계는 전부 재사용된다.
• 파이프라인은 PR 앞에서 멈춘다. 배포 결정은 사람의 것이고, 이 과정에서는 PR 병합이 곧 배포다. 그 멈춤은 부탁이 아니라 훅(구조)으로 고정하고, 일부러 어겨 봐서 확인했다.
• 새 세션에서 회의록 한 줄로 팀 전체가 움직이는 것을 봤다. 그것이 "팀이 저장되어 있다"는 말의 실제 모습이다.
• 우리는 인터넷에 살아 있는 서비스를 3일 만에 만들었고, 그 팀으로 기능 하나를 더 얹었다. 코드의 대부분은 AI가 냈지만, 서비스를 '이 서비스'로 만든 결정들은 사람의 것이었다 — 그 경계가 이 과정의 결론이다.
• 진짜 배운 것은 티켓 서비스가 아니라 사람 대신 AI로 팀을 꾸려 무엇이든 완성하고 계속 굴리는 방법이다. 다음은 내 일이다. 작게 시작하라 — CLAUDE.md 한 줄, Skill 하나, 검증 Subagent 하나, Hook 하나, 그리고 순서가 굳으면 파이프라인.
• 오래 남을 원칙 — 슬롭은 결정의 부재, 만든 사람은 검사하지 않는다, 부탁이 아니라 구조, 결정은 사람 실행은 AI, 자동화는 시선을 위로 올린다.
• 강의는 여기서 끝나지만, 여러분의 첫 걸음은 여기서 시작된다. 오늘 적은 그 한 줄을 내일 실제로 해 보는 것이, 이 3일을 진짜 내 것으로 만드는 마지막 실습이다.