이 장에서 보는 것: 이 과정에서 익힌 "AI 팀으로 서비스 개발 + 운영 파이프라인"을 내 조직 규모에 맞게 어떻게 들일지, 구체적인 사례로 본다. (따라 할 프롬프트는 없다. 읽고 넘어간다.)
지금까지 한 명이 여러 역할(기획·디자인·개발·검증·보안·인프라)을 AI로 세워 서비스를 만들고, 배포하고, 운영 중 기능까지 회의록 하나로 추가했다. 이 방식의 뼈대 — "역할을 세워 산출물을 잇고, 사람이 결정·승인·검증한다" — 는 규모와 무관하게 똑같다. 달라지는 건 누가 지휘하고, 표준을 어떻게 관리하고, 게이트를 어디에 거는가 셋이다.
| 규모 | 누가 지휘하나 | 표준(규칙) 관리 | 게이트(사람 개입) |
|---|---|---|---|
| 1인·소규모 | 혼자 여러 역할을 AI로 | CLAUDE.md·가이드 문서로 스스로와의 약속 | 내가 검토·배포 승인 |
| 중소·중견 | 개발자마다 AI 팀을 지휘 | 회사 표준을 레포에 문서로 고정, 팀이 공유 | 시니어 리뷰 + 배포 승인 |
| 대기업 | 기존 팀·프로세스 위에 AI를 얹음 | 이미 있는 표준·관문을 AI가 각 자리에서 | 변경관리·보안·감사 관문을 더 촘촘히 |
누구: 사이드 프로젝트를 만드는 직장인, 1인 창업자, 개발자 한두 명의 초기 스타트업.
사례. 김대표는 혼자 머니노트 같은 SaaS를 만든다. 예전이라면 기획자·디자이너·개발자·QA를 채용하거나 외주를 줘야 했지만, 이제 그 자리를 전부 AI 역할로 세운다. 회의록(혼자 정리한 요구) → PRD → 화면기획서 → DB → API → 코드 → 검증 → 배포까지 2주 만에 공개 URL을 띄운다. 운영도 마찬가지다 — 사용자 피드백을 회의록 한 장으로 정리해 /feature에 주고, 주말에 다른 일을 하다가 "배포할까요?" 알림이 오면 승인한다. 그렇게 한 주에 기능 세 개를 붙인다.
여기서 표준 문서(CLAUDE.md·디자인시스템·코딩컨벤션)는 "미래의 나 자신과의 약속"이 된다. 3개월 뒤 코드를 다시 열어도, AI가 그 문서를 진실 원천으로 삼아 만들었기 때문에 색·네이밍·구조가 일관된다. 혼자라서 리뷰해 줄 동료가 없는 대신, AI에게 검증·보안 역할을 따로 세워 "다른 눈"을 만든다.
핵심: 속도. 표준 문서 = 자기 규율. 게이트(배포·결제)만 내가 지킨다.
누구: 개발자 5~50명 규모. 시리즈A 스타트업, 중견기업 IT팀.
사례. 개발자 8명 팀이 있다. 예전엔 기능 하나에 기획 1·디자인 1·개발 2·QA 1이 붙어 여러 주가 걸렸다. 이제 개발자 각자가 AI 팀을 지휘해 한 사람이 기획~배포까지 끌고 간다. 8명이 예전 20명 몫을 낸다.
대신 두 가지를 반드시 갖춘다.
docs/가이드에 두고, CLAUDE.md가 "이 문서를 따른다"고 못 박는다. 그러면 사람이 바뀌어도, 개발자가 5명이든 8명이든 결과가 같은 색·같은 구조로 나온다. 유지보수와 인수인계가 쉬워진다..claude/agents의 서브에이전트와 /feature 스킬, 배포 게이트를 레포에 커밋한다. 그러면 누가 clone하든 같은 AI 팀·같은 파이프라인을 쓴다.이때 사람 개발자의 일이 바뀐다. '코드를 직접 타이핑'하는 시간이 줄고, '요구를 정의하고, AI 산출물을 리뷰하고, 아키텍처를 결정하고, 배포를 승인' 하는 데 시간을 쓴다. 배포 게이트에서 시니어가 PR과 변경 요약을 보고 승인한다.
핵심: 표준 문서 = 팀 일관성. 사람 역할이 '작성'에서 '검토·결정'으로 이동.
누구: 이미 QA팀·보안팀·인프라팀·아키텍트 조직과, 코드 리뷰·보안 심사·변경관리(CAB) 관문이 있는 회사. 특히 금융·의료 같은 규제 산업.
사례. 대기업은 이 방식을 기존 조직·관문을 대체하는 걸로 쓰지 않는다. 각 자리 담당자가 자기 일에 AI 역할을 얹는다.
backend 서브에이전트로 초안을 만들고, 사람이 리뷰해 병합한다.security 역할로 1차 스캔을 돌리고, 사람 심사관이 최종 판단한다.배포 게이트는 오히려 더 촘촘해진다. /feature가 "배포할까요?"를 물으면, 승인은 한 사람이 아니라 리뷰어 + 보안 + 운영이 함께 거치는 변경관리 절차가 된다. 규제 산업은 감사·추적성이 필수라, 서브에이전트·스킬·게이트 hook을 사내 표준으로 두고, 모든 변경이 문서(회의록 → PRD → 명세 → 코드 → 테스트)로 남게 한다 — 이 과정이 문서를 진실 원천으로 삼는 이유가 여기서 가장 크게 빛난다.
도입은 한 번에 전사가 아니라, 파일럿 팀부터 한다. ① 한 팀에서 표준 문서를 정비하고 ② 그 팀이 AI 팀·파이프라인으로 몇 개 기능을 내보며 관문을 검증한 뒤 ③ 사내 표준으로 확산한다.
핵심: 기존 프로세스 위에 얹는다. 관문·감사·리뷰는 줄이지 않고 더 엄격히.
규모가 1인이든 대기업이든, 바뀌지 않는 것이 있다.
/feature 스킬·배포 게이트를 공유해 누구나 같은 방식으로.규모가 무엇이든, 이 과정에서 손에 익힌 "역할을 세워 산출물을 잇고, 사람이 결정·승인·검증한다" 는 뼈대는 그대로 통한다. 규모는 그 위에 관문을 몇 겹 더 얹느냐의 문제일 뿐이다.