이 단계에서 하는 것: 운영 중인 서비스에 새 기능을 추가하는 절차를 만든다. 앞 단계에서 설정한 서브에이전트들이 기능 추가 회의록을 읽고 기획→설계→개발→테스트·보안 점검 순서로 작업한다. 배포 전에는 변경 내용과 검증 결과를 사람에게 보여 주고 승인을 요청한다. 완료 기준:
/feature 회의록.md를 실행하면 역할별 작업과 검증이 진행되고, 사람의 승인을 받은 뒤 배포된다.
지금까지는 서비스를 처음 만들어 배포하는 과정을 진행했다. 실제 운영에서는 사용자 의견이나 새로운 요구사항에 따라 기능을 계속 수정·추가한다. 매번 역할과 순서를 다시 지시하지 않도록, 회의록을 입력하면 정해진 절차에 따라 작업하고 배포 전 승인을 요청하는 흐름을 설정한다.
앞 단계에서 정의한 서브에이전트는 .claude/agents/에 파일로 저장되어 있다. 새 세션에서도 이 역할 설정을 다시 사용할 수 있다. 기능을 추가할 때는 필요한 역할을 순서대로 호출한다.
역할을 호출할 순서를 매번 입력하지 않도록 스킬에 절차를 기록한다. /feature 회의록.md를 실행하면 회의록을 읽고 정해 둔 순서에 따라 각 역할에 작업을 맡긴다.
두 가지를 짚어야 한다.
[사람]: 새 기능의 요구사항을 회의록에 기록하고, 작업 결과와 검증 내용을 확인한 뒤 배포 여부를 결정한다. [AI 역할들]: 회의록을 읽고 PRD·명세 갱신 → 서버·화면 구현 → 테스트 → 보안 점검 순서로 작업한 뒤 결과를 보고한다.
.claude/agents/에 저장했고, 프로젝트에 PRD·화면기획서·ERD·API명세서와 가이드 문서가 있다.이후에도 사용할 스킬과 배포 전 승인 설정을 만든다. Claude Code에 아래 문장을 붙여 넣는다.
운영 중 기능을 추가할 때 사용할 절차를 설정해줘. 지금은 기능 코드를 구현하지 마.1) 다음 스킬을 만들고 /feature를 입력했을 때만 실행되게 해줘. 스킬은 인자로 받은 기능 추가 회의록 경로($ARGUMENTS)를 읽고, 기획→설계→백엔드→프론트엔드→QA→보안 순서로 필요한 작업을 진행해줘. 문서와 코드는 이번 기능에 필요한 부분만 수정해줘. QA는 기존 테스트를 다시 실행하고, 보안 엔지니어는 변경된 부분을 점검해 보고해줘. 문제가 있으면 담당 개발자에게 수정을 맡기고 다시 확인해줘. 작업을 마치면 변경 내용과 검증 결과를 보여주고 '배포할까요?'라고 물어봐. 내가 '배포'라고 답하기 전에는 배포하지 마.2) PreToolUse Hook을 설정해 git push나 vercel deploy 같은 배포 명령을 실행하기 전에 항상 내 승인을 받게 해줘.다 만들면 파일 목록을 보여줘.이렇게 나오면 성공: .claude/skills/feature/SKILL.md와 .claude/settings.json(배포 명령 앞에 승인을 묻는 hook)이 생긴다. 앞 장에서 만든 역할 파일들은 .claude/agents/에 그대로 있다.
[스킬로 설정하는 이유] 기능 추가 절차는 스킬 파일(
.claude/skills/feature/SKILL.md)에 기록된다. "내가 /feature를 입력했을 때만"이라고 했으니 AI는disable-model-invocation: true를 켜서 스스로 실행하지 않게 만든다. 파일을 열어 이 설정이 들어갔는지 본다. 파일 경로와 설정 이름은 AI가 아는 것이라 프롬프트에는 적지 않았다.
새 기능이 필요해지면 회의 결과를 data/기능추가_회의록.md에 기록한다. 예를 들어 "지난 거래를 찾기 어렵다"는 의견에서 거래 메모 검색을 결정했다면, 본인 거래만 검색·서버에서 필터링·검색창 표시·결과가 없을 때 안내 등 필요한 조건을 함께 적는다.
이렇게 나오면 성공: data/기능추가_회의록.md에 원하는 기능과 완료 기준이 사람 말로 적혀 있다.
새로 만든 스킬에 회의록 경로를 전달한다.
/feature data/기능추가_회의록.md메인 에이전트는 회의록을 읽고 기획→설계→백엔드→프론트엔드→QA→보안 순서로 역할에 작업을 맡긴다. 작업을 마치면 변경 내용과 검증 결과를 요약하고 배포 승인을 요청한다.
작업 시간: 여러 역할이 문서와 코드를 수정하고 검증하므로 시간이 걸릴 수 있다. 완료 보고가 오면 변경 내용과 테스트·보안 점검 결과를 확인한다.
[기능을 추가할 때마다 보안을 점검하는 이유] 새 기능에서 접근 제한이 빠질 수 있다. 거래 검색도 "본인 거래만 조회하고 서버에서 필터링한다"는 조건을 지켜야 한다. 보안 엔지니어는 변경된 코드에서 다른 사용자의 거래를 조회할 수 없는지 확인한다.
[실습] vs [실무] — QA 범위 - [실습] 앞에서 작성한 정상·경계·실패 테스트를 다시 실행해 기존 기능에 문제가 생기지 않았는지 확인한다. - [실무] 서비스의 요구에 따라 통합 테스트·E2E(브라우저 자동화)·부하 테스트·CI 자동 실행도 추가할 수 있다.
이렇게 나오면 성공: 팀이 자율로 문서·서버·화면·테스트를 만들고 보안 점검까지 마친 뒤, 마지막에 "테스트·보안 점검까지 완료했습니다. 배포할까요?" 로 멈춘다. 아직 배포는 안 됐다.
변경 내용과 검증 결과를 읽고 배포할지 결정한다.
배포승인하면 인프라 역할이 변경 내용을 커밋하고 git push한다. GitHub와 Vercel을 연결했으므로 배포 브랜치인 master에 push하면 Vercel이 자동으로 새 버전을 배포한다. Claude Code가 push 명령을 실행하기 전에는 단계 1에서 설정한 Hook이 다시 승인을 요청한다. Vercel에서 빌드가 끝나면 공개 URL에서 새 기능을 확인한다.
[사람 검증] 두 가지를 내 눈으로 확인한다. 1. 승인 전 배포 여부: "배포"라고 답하기 전에는 공개 URL에 새 기능이 반영되지 않았는지 확인한다. 이미 반영됐다면 push 경로와 Hook 설정을 점검한다. 2. 새 기능의 동작: 배포가 끝나면 공개 URL을 새로고침하고, 회의록에 적은 기능(예: 거래 검색창)을 직접 사용해 본다.
demo@moneynote.dev / moneynote1234로 로그인해 확인한다.
이렇게 나오면 성공: 회의록을 바탕으로 기능 개발과 검증을 마치고, 사람이 결과를 확인·승인한 뒤 공개 URL에서 새 기능이 동작한다.
/feature 스킬과 배포 전 확인 Hook을 만들었다./feature가 안 먹으면 .claude/skills/feature/SKILL.md가 있는지, 새 세션에서 부르는지 확인한다. 파이프라인이 중간에 엉키면, 그 단계 역할에게 직접(예: "backend 역할로 …") 이어서 시킨다. 게이트가 안 걸리면 .claude/settings.json의 hook을 확인한다.다음 장에서는 이 방식을 1인 개발자·중소기업·대기업에 각각 어떻게 적용할지 살펴본다.