AI Driven Development대기업 프로세스를 AI 팀으로

14. 읽을거리 — 조직 규모별 AI 개발 도입 전략

이 장에서 보는 것: 앞에서 익힌 AI 역할별 개발과 기능 추가 절차를 조직 규모에 맞게 적용하는 방법을 사례로 살펴본다. 이 장에는 따라 할 프롬프트가 없다.

지금까지 한 사람이 기획·디자인·개발·검증·보안·인프라 업무를 맡을 AI 서브에이전트를 설정하고, 서비스를 개발·배포한 뒤 기능을 추가하는 과정을 살펴봤다. 역할별 산출물을 연결하고 사람이 방향을 결정하며 결과를 검증·승인하는 방식은 조직 규모가 달라도 적용할 수 있다. 규모에 따라 달라지는 것은 AI에게 작업을 지시하는 사람, 표준 문서의 관리 방식, 검토·승인 절차다.

조직 규모에 따라 검토·승인 절차를 정한다 1인·소규모 한 사람이 여러 AI 역할 관리 AI 팀이 작업 회의록→기획·설계·개발·QA 사람의 검토·승인 ① 담당자가 배포 승인 배포 중소·중견 개발자마다 AI 팀 운영 AI 팀이 작업 표준과 역할 설정을 저장소에서 공유 코드 검토·배포 승인 ① 시니어 코드 리뷰 ② 배포 승인 배포 대기업 기존 팀과 절차에 맞춰 활용 담당자별 AI 활용 각 담당자가 업무에 AI 활용 기존 검토·승인 절차 ① 코드 리뷰 ② 보안 심사 ③ 변경관리(CAB) ④ 감사·추적성 배포

규모 작업 지시와 조율 표준 문서 관리 사람의 검토·승인
1인·소규모 한 사람이 여러 AI 역할에 작업을 맡김 CLAUDE.md·가이드 문서를 직접 관리 작업한 사람이 검토하고 배포를 승인
중소·중견 개발자마다 담당 업무에 AI를 활용 회사 표준을 저장소에서 팀과 공유 코드 리뷰와 배포 승인
대기업 각 업무 담당자가 AI에 작업을 맡김 기존 조직의 표준과 절차를 적용 변경관리·보안·감사 절차에 따라 승인

1인·소규모 — 한 사람이 여러 AI 역할 관리하기

누구: 사이드 프로젝트를 만드는 직장인, 1인 창업자, 개발자 한두 명의 초기 스타트업.

사례. 김대표는 혼자 머니노트 같은 서비스를 만든다. 요구사항을 정리한 뒤 기획·디자인·개발·QA 작업에 각각 AI 역할을 활용한다. PRD → 화면기획서 → DB → API → 코드 → 검증 → 배포 순서로 산출물을 확인한다. 운영 중에는 사용자 의견을 회의록에 기록해 /feature로 기능 추가 절차를 시작한다. AI의 작업과 검증 결과를 읽고 배포 여부를 결정한다.

CLAUDE.md·디자인 시스템·코딩 컨벤션은 작업 기준을 기록한 문서다. 시간이 지나 다시 개발할 때도 이 문서를 참고하면 색상·이름·구조를 같은 기준으로 유지할 수 있다. 함께 리뷰할 동료가 없다면 검증·보안 서브에이전트를 따로 설정해 구현 결과를 점검하고, 사람도 핵심 결과를 직접 확인한다.

핵심: 한 사람이 여러 AI 역할을 관리하되, 표준 문서를 기준으로 결과를 검토하고 배포·결제 같은 중요한 결정을 직접 내린다.


중소·중견 — 개발자마다 AI 팀을 지휘

누구: 개발자 5~50명 규모. 시리즈A 스타트업, 중견기업 IT팀.

사례. 개발자 8명이 있는 팀에서 각자 담당 기능의 기획·개발·검증에 AI 역할을 활용한다. 작업 속도가 빨라질 수 있지만, 여러 개발자가 만든 결과물을 함께 유지보수하려면 공통 기준과 리뷰 절차가 필요하다.

대신 두 가지를 반드시 갖춘다.

  1. 회사 표준을 저장소의 문서로 관리한다. 디자인 시스템·코딩 컨벤션·API 명세서·깃 커밋 컨벤션을 docs/가이드에 두고, CLAUDE.md에 해당 문서를 따르도록 적는다. 담당자가 바뀌어도 같은 기준으로 작업하고 결과를 검토할 수 있다.
  2. 역할과 절차를 팀에 공유한다. .claude/agents의 서브에이전트 설정, /feature 스킬, 배포 전 승인 설정을 저장소에 커밋한다. 팀원이 저장소를 받아 같은 절차를 사용할 수 있다.

이때 개발자는 AI에게 맡긴 결과를 검토하는 데 시간을 쓴다. 요구사항을 정의하고, 아키텍처 결정을 확인하며, 코드와 테스트 결과를 리뷰한다. 배포 전에는 담당자가 PR과 변경 요약을 보고 승인한다.

여러 명이 동시에 작업하면 브랜치와 PR을 활용해 변경 내용을 검토할 수 있다. 예를 들어 각자 feature/거래검색 같은 브랜치에서 작업한 뒤 PR을 열어 리뷰를 받고 기본 브랜치에 병합한다. 팀 규모와 배포 방식에 맞는 브랜치 전략을 정하면 된다.

핵심: 회사 표준을 공유하고, AI가 만든 결과물을 사람이 검토한다. 여러 명이 동시에 작업할 때는 브랜치와 PR로 변경 사항을 확인한다.


대기업 — 기존 프로세스 위에 AI를 얹는다

누구: 이미 QA팀·보안팀·인프라팀·아키텍트 조직과, 코드 리뷰·보안 심사·변경관리(CAB) 관문이 있는 회사. 특히 금융·의료 같은 규제 산업.

사례. 대기업에서는 기존 조직의 담당자가 자신의 업무에서 AI를 활용한다.

배포 승인에는 기존 변경관리 절차를 적용한다. /feature가 배포 승인을 요청하면 코드 리뷰·보안 점검·운영 검토를 담당하는 사람이 각자의 기준으로 확인한다. 감사 기록이 필요한 조직이라면 회의록 → PRD → 명세 → 코드 → 테스트의 변경 근거를 남기고, 서브에이전트·스킬·Hook 설정도 조직 표준에 맞춰 관리한다.

도입할 때는 한 팀에서 먼저 시험해 볼 수 있다. 표준 문서를 정비하고 몇 가지 기능에 AI 역할과 개발 절차를 적용한 뒤, 검토·승인 과정에서 생긴 문제를 확인한다. 그 결과를 바탕으로 다른 팀에 적용할 범위를 정한다.

핵심: 기존 업무 절차에 AI를 활용하고, 코드 리뷰·보안·감사 기준을 AI 산출물에도 적용한다.


어디서나 같은 원칙

규모가 1인이든 대기업이든, 바뀌지 않는 것이 있다.

내일 당장 시작한다면 (규모 불문 체크리스트)

  1. 표준 문서를 마련한다. CLAUDE.md와 디자인·코딩·프로젝트 구조·커밋 가이드를 작성해 작업 기준을 정한다.
  2. 작은 범위에서 시작한다. 기능 하나나 한 팀에서 먼저 적용해 본다.
  3. 역할 설정과 절차를 저장소에서 공유한다. 서브에이전트·/feature 스킬·배포 전 승인 설정을 팀이 함께 관리한다.
  4. 사람이 중요한 결과를 검토한다. 배포·보안·결제는 담당자의 승인 절차를 거친다.

조직 규모와 관계없이 역할별 작업을 산출물로 연결하고, 사람이 방향을 결정하고 결과를 검증·승인한다. 각 조직은 기존 책임과 절차에 맞춰 이 방식을 적용하면 된다.

TechLead · macro@prag-ai.com