AI 소프트웨어 개발 수명주기(AI-SDLC)는 사람을 대체하는 것이 아니라, 사람이 놓치기 쉬운 사각지대를 메워주는 안전망입니다. 기획 문서 하나에 AI 페르소나 세 개를 붙인 첫 실험이 그 확신을 만들었습니다.

바쁜 분을 위한 3줄 요약

① 기획 문서 하나를 최고기술책임자(CTO)·최고운영책임자(COO)·Standards 세 페르소나 AI가 각각 다른 관점으로 리뷰하게 했습니다.
② 토큰 관리 이슈, 롤백 시나리오 부재, 거버넌스 위반 — 제가 놓친 리스크를 세 페르소나가 나눠 잡아냈습니다.
③ 시니어 엔지니어 세 명이 며칠 걸릴 리뷰를 몇 분 만에 — 기획 단계 리스크 필터망은 이제 선택이 아닌 필수입니다.

이 편이 답하는 질문

Plan 에이전트(Claude)가 기획 문서를 작성한 후 CTO·COO·Standards 3 페르소나(Codex)가 각각 다른 관점(토큰 관리·롤백·거버넌스 위반)으로 30분 내 리뷰했을 때, 이 “멀티 페르소나 AI 리뷰”가 시니어 엔지니어 3명의 며칠 리뷰를 대체할 수 있는 조건은?
기획 단계 AI 리뷰가 발견한 리스크 패턴(토큰·배포·정책 위반)이 개발 단계에서도 동일하게 반복되는가, 아니면 기획과 개발은 서로 다른 리스크를 드러내는가?
“AI를 쓴다 하더라도 여전히 한계가 느껴짐”이라는 수강자 피드백이 교육 성공 신호라는 해석은, 조직 차원 AI 성숙도와 개인 차원 비판적 사고 수준을 어떻게 동시에 측정해야 하는가?
Definition of Done에 “AI 생성물 검증” 35개 항목을 명시하고, 실제 프로젝트에서 검증 불가능한 것을 필터링하는 과정이 스프린트 계획 단계에서 얼마나 비용을 증가시키는가?

이 시리즈를 읽는 세 개의 눈

PO: AI 리뷰 페르소나를 조직의 실제 리뷰 체크포인트와 1:1 매핑하면 품질 관리 사각지대를 사전에 드러낼 수 있으므로, 기획 초반에 이 매핑을 완성해야 한다.
PM: 멀티 페르소나 리뷰의 가치는 빠른 피드백이 아니라 관점의 다양성이므로, 리뷰 결과를 통합하고 우선순위를 결정하는 PM의 판단 프로세스를 명확히 설계해야 한다.
PL: AI 페르소나가 놓치는 조직 특화 리스크(의존성·레거시·운영 제약)를 발견하는 것이 사람 리뷰의 진정한 가치이므로, 이 부분을 명시적으로 체계화해야 한다.

들어가며 · THE DOUBT

솔직히, 과잉 설계라고 의심했습니다

솔직히 반신반의했습니다. 기획 문서 하나에 페르소나 세 개를 붙이는 것이 과잉 설계 아닌가 싶었습니다.

실험 전 저의 첫 반응
“AI가 CTO, COO, Standards 역할을 나눠서 리뷰한다고?”

PART 1 · THREE PERSONAS

제가 놓친 리스크를, 세 페르소나가 나눠서 잡아냈습니다

그런데 결과물을 보니 생각이 바뀌었습니다. Plan(Claude)이 작성한 기획 문서에서, 제가 놓친 토큰 관리 이슈를 CTO(Codex) 에이전트가 짚었습니다. 롤백 시나리오 부재는 COO(Codex)가, 거버넌스 위반은 Standards(Codex)가 잡아냈습니다.