이 단계에서 하는 것: 배포까지 끝낸 서비스에, 운영 중 새 기능을 붙인다. 우리가 세운 AI 팀을 한 번 저장해 두고, 기능 추가 회의록 하나만 주면 팀이 기획→설계→개발→테스트까지 자율로 진행한 뒤, 배포 직전에 "배포할까요?" 만 사람에게 묻게 만든다. 끝나면:
/feature 회의록.md한 줄이면, 사람은 회의록을 쓰고 배포를 승인하는 것 말고는 손댈 게 없다.
이 장이 이 과정의 진짜 목적지다. 지금까지는 서비스를 처음부터 만들어 배포했다. 하지만 현실의 개발은 거기서 끝나지 않는다 — 공개한 순간부터 사용자 피드백이 쏟아지고, 기능은 계속 추가된다. 이 반복을 사람이 매번 전 과정을 손으로 하면 지친다. 대신 한 번 세팅해 두면, 회의록만 주고 결과(배포 승인 요청)만 받는 구조를 만든다.
우리는 2~9장에서 기획자·디자이너·DBA·아키텍트·백엔드·프론트·QA 같은 역할을 세워 썼다. 이 역할들을 .claude/agents/ 폴더에 서브에이전트 파일로 저장해 두면, 새 세션에서도 팀이 그대로 살아 있다. 운영 중 기능 추가란, 저장해 둔 이 팀을 다시 부르는 일이다.
그 "다시 부르기"를 매번 손으로 지시하지 않도록, 순서를 스킬 하나로 정해 둔다. /feature 회의록.md 한 줄이면 팀이 회의록을 읽고 순서대로 움직인다.
두 가지를 짚어야 한다.
[사람]: ① 기능 추가 회의(사람들끼리) → 회의록 작성 · ② 마지막에 배포 승인. 딱 두 가지다. [AI 팀]: 회의록 읽기 → PRD·명세 갱신 → 서버·화면 구현 → 테스트 → "배포할까요?" 까지 자율.
docs/(PRD·화면기획서·ERD·API명세)와 가이드 문서가 있다.이후 계속 재사용할 장치를 딱 한 번 만든다. Claude Code에 아래를 붙여 넣는다.
운영 중 기능을 추가할 때 쓸 파이프라인을 세팅해줘(코드 기능은 만들지 말고 세팅만).
1) 우리가 이 프로젝트에서 쓴 역할들을 .claude/agents/ 서브에이전트 파일로 저장해줘: pm·ux·dba·architect·backend·frontend·qa·security·infra. 각 파일에 description(언제 부를지)과 하는 일을 적고, 진실 원천(docs/ 문서·docs/가이드)과 원칙(판정은 서버·클라이언트에서 Supabase 데이터 직접호출 금지·비밀값 환경변수)을 넣어줘.
2) '기능 추가 파이프라인'을 스킬로 만들어줘: .claude/skills/feature/SKILL.md, disable-model-invocation: true(자동 실행 금지, 내가 /feature 로만 호출). 이 스킬은 인자로 받은 기능추가 회의록 경로($ARGUMENTS)를 읽고 pm→(architect/dba)→backend→frontend→qa 순서로 중간에 멈추지 말고 자율 진행한 뒤, '배포할까요?'라고 묻는다. 문서·코드는 이 기능에 필요한 부분만 최소로 고치고, QA는 단위 테스트(npx vitest run tests/unit)만 돌린다. 내가 '배포'라고 답하기 전에는 배포하지 않는다.
3) .claude/settings.json에 PreToolUse hook을 넣어, git push나 vercel deploy 같은 배포 명령을 실행 전 항상 나에게 승인(ask)받게 해줘.
다 만들면 파일 목록을 보여줘.
이렇게 나오면 성공: .claude/agents/에 역할 파일들, .claude/skills/feature/SKILL.md, .claude/settings.json(+배포 가드)가 생긴다.
[커맨드 아니라 스킬인 이유] 예전엔
.claude/commands/(슬래시 커맨드)를 썼지만, 최신 Claude Code에서 이건 레거시이고 스킬이 표준이다. 특히 배포를 다루는 파이프라인은 자동으로 트리거되면 위험하니, 스킬의disable-model-invocation: true로 내가/feature로 부를 때만 돌게 한다. (커맨드는 이 옵션이 없다.)
운영 중 새 기능이 필요해졌다고 하자. 사람들끼리 회의를 하고, 그 결과를 회의록 한 장으로 남긴다. data/기능추가_회의록.md로 저장한다. (예시: "사용자들이 지난 거래를 못 찾는다 → 거래 메모 검색 기능을 넣자. 본인 것만·서버에서 필터·검색창·빈 결과 안내. 이번엔 메모 검색만.")
이렇게 나오면 성공: data/기능추가_회의록.md에 원하는 기능과 완료 기준이 사람 말로 적혀 있다.
새로 만든 스킬을 회의록과 함께 부른다. 이 한 줄이 전부다.
/feature data/기능추가_회의록.md
그러면 팀이 회의록을 읽고 기획→설계→백엔드→프론트→QA(단위 테스트) 를 스스로 이어서 진행한다. 중간에 사람에게 묻지 않는다. 다 되면 무엇을 바꿨는지 요약하고 "배포할까요?" 로 멈춘다.
정직하게 — 시간이 걸린다. 역할 여러 개가 문서와 코드를 실제로 만들기 때문에 몇십 분 걸릴 수 있다. 그게 정상이다. 옆에서 지켜볼 필요 없이 다른 일을 하다가, "배포할까요?"가 뜨면 돌아오면 된다. 이게 이 파이프라인의 핵심 가치다.
[실습] vs [실무] — QA 범위 - [실습] 우리는 QA를 단위 테스트로 간단히 한다(빠르고, 정상·경계·실패를 확인하기에 충분). - [실무] 실제 서비스에서는 여기에 통합 테스트·E2E(브라우저 자동화)·부하 테스트·CI 자동 실행까지 더한다. 원리는 같고, 촘촘함만 다르다.
이렇게 나오면 성공: 팀이 자율로 문서·서버·화면·단위 테스트를 만들고, 마지막에 "테스트까지 완료했습니다. 배포할까요?" 로 멈춘다. 아직 배포는 안 됐다.
결과를 보고 좋으면 배포를 승인한다.
배포
그러면 infra 역할이 바뀐 것을 커밋하고 git push 한다. 따로 배포 명령을 칠 필요가 없다 — 10장에서 GitHub↔Vercel을 연동해 뒀기 때문에, master에 push되는 순간 Vercel이 자동으로 배포한다. 이때 Claude Code가 git push 실행 전에 한 번 더 승인을 묻는다(단계 1에서 건 hook) — 확인하고 승인한다. push가 나가면 Vercel 대시보드에 새 배포가 뜨고, 빌드가 끝나면 공개 URL에 새 기능이 반영된다.
[사람 검증] 두 가지를 내 눈으로 확인한다. 1. 게이트가 진짜 막았나: "배포"라고 하기 전에는 공개 URL에 새 기능이 없어야 한다. 승인 없이 배포가 나갔다면 게이트가 뚫린 것이다. 2. 새 기능이 실제로 떴나: 배포가 끝나면 공개 URL을 새로고침해, 회의록에 적었던 기능(예: 거래 검색창)이 실제로 동작하는지 눌러 본다.
demo@moneynote.dev / moneynote1234로 로그인해 확인한다.
이렇게 나오면 성공: 회의록 한 장 → 자율 개발 → 내 승인 → 공개 URL에 새 기능. 사람은 회의록과 승인 두 번만 손댔다.
/feature 스킬과 배포 게이트 hook을 한 번 만들어 뒀다./feature가 안 먹으면 .claude/skills/feature/SKILL.md가 있는지, 새 세션에서 부르는지 확인한다. 파이프라인이 중간에 엉키면, 그 단계 역할에게 직접(예: "backend 역할로 …") 이어서 시킨다. 게이트가 안 걸리면 .claude/settings.json의 hook을 확인한다.이제 남은 것은 규모다. 다음 장에서 이 방식을 1인·중소·대기업 어디에 어떻게 들일지 짧게 짚는다.