최근 5개 클라이언트 스코핑에서, 예전에 12~16시간이 걸렸던 발견(discovery) 부분이 대략 3시간의 AI 작업과 1시간의 인간 검토로 줄어들었습니다. 우리는 전체 과정을 하나의 Claude 프로젝트 내에서 진행하므로 컨텍스트가 계속 유지됩니다. 다만 한 가지 문제가 있습니다. AI는 매번 정확히 세 가지가 잘못되었습니다. 그래서 클라이언트에 전달하기 전에 검증 단계를 추가했습니다.

이것은 우리가 실제로 사용하는 6단계 프롬프트 체인, 각 프롬프트가 생산하는 결과물, 완전한 실제 예제, 그리고 직접 발견해야 하는 실패 모드입니다.

AI가 웹앱 프로젝트를 범위 지을 수 있을까요? 네, AI는 몇 시간 안에 완전한 스코프(문제 진술, 사용자 스토리, 기능, MoSCoW 우선순위, 작업 진술서)를 초안 작성할 수 있습니다. 하지만 AI가 할 수 없는 것은 그 초안의 유효성을 검증하는 것입니다. AI는 요구사항을 만들어 내고 노력을 과소평가하므로, 승인 전 인간 검증 게이트가 필수입니다.

핵심 요약

  • AI는 웹앱 스코프를 며칠이 아닌 몇 시간 안에 초안 작성하지만, 자신의 결과물을 검증할 수 없습니다.
  • 체인은 6개 프롬프트로 구성됩니다: 문제, 사용자 스토리, 기능, MoSCoW, 견적, SOW.
  • AI는 통합을 만들어 내고 엣지 케이스를 과소평가하므로, 항상 인간 검증 게이트를 거쳐야 합니다.
  • Claude 프로젝트 또는 ChatGPT 프로젝트를 사용하여 체인을 실행합니다. 에이전트는 스코프 승인 후 사용합니다.

AI 지원 스코핑이란 무엇인가(그리고 무엇이 아닌가)?

AI 지원 스코핑은 일련의 LLM 프롬프트를 사용하여 대략적인 아이디어를 구조화된 스코프 결과물로 전환하는 것입니다: 요구사항, 사용자 스토리, 기능 목록, 우선순위, 작업 진술서. AI는 초안 작성과 구조화를 합니다. 인간은 여전히 의사결정, 이해관계자 대화, 유효성 검증을 담당합니다.

그렇다면 AI가 생각을 대신하는가? 꼭 그렇지는 않습니다. 빈 페이지를 바라보며 "예약 앱이 필요하다"를 개발자가 견적을 낼 수 있는 것으로 변환하는 요구사항 수집 부분에서는 빠릅니다. 하지만 클라이언트가 실제로 필요로 하는 것과 그럴듯하게 들리는 것을 구분하는 데는 서툽니다.

AI 지원 스코핑이 아닌 것들: 자율적이지 않으며, 실제 이해관계자와의 대화를 대체하지 않으며, 정확성을 보장하지 않습니다. 모델은 아무도 요청하지 않은 기능에 대해 자신 있고 잘 정형화된 명세서를 작성할 것입니다.

이 글은 스코핑 프로세스 자체를 이미 이해하고 있다고 가정합니다. 기초부터 배우고 싶다면 우리의 단계별 스코핑 가이드가 기본적인 비AI 프로세스, 7단계, 완전한 스코프 문서 구조를 설명합니다. 여기서는 AI 계층에만 집중합니다: 어느 프롬프트, 어느 순서, 그리고 어디에서 문제가 생기는지.

AI 스코핑 프롬프트 체인 개요

체인은 순서대로 실행되는 6개의 프롬프트이며, 각각의 결과물이 다음 프롬프트에 입력됩니다. 순서대로: (1) 문제와 목표, (2) 사용자 스토리, (3) 기능 목록, (4) MoSCoW 우선순위 지정, (5) 노력, 비용, 타임라인 견적, (6) SOW 초안. 한 프로젝트 내에서 실행하여 컨텍스트를 유지합니다.

좋은 점: 각 프롬프트가 이전 결과물 위에 빌드되므로, 6번 앱을 다시 설명할 필요가 없습니다. 사용자 스토리를 작성할 때 모델이 이미 문제를 알고 있고, 기능에 우선순위를 지정할 때 이미 스토리를 알고 있습니다.

  • 문제와 목표: 대략적인 아이디어를 문제 진술과 SMART 목표로 변환합니다.
  • 사용자 스토리: 목표를 수용 기준이 있는 사용자 스토리로 변환합니다.
  • 기능 목록: 스토리에서 구체적인 기능 인벤토리를 도출합니다.
  • MoSCoW 우선순위: 기능을 Must, Should, Could, Won't로 분류합니다.
  • 견적: 노력, 비용 범위, 타임라인을 생성합니다.
  • SOW 초안: 모든 것을 작업 진술서로 조립합니다.

이것은 일반적인 프로젝트 관리를 위한 AI 프롬프트의 깔끔한 세트이기도 하지만, 우리는 모든 프롬프트를 웹앱을 위해 특별히 튜닝했습니다(기술 스택, 통합, 엣지 케이스). 이러한 튜닝이 일반적인 스코프와 사용 가능한 스코프를 구분합니다.

체인을 단계별로 실행하려면 어떻게 해야 하나요?

한 Claude 프로젝트 또는 ChatGPT 프로젝트 내에서 위에서 아래로 체인을 실행하고, 각 프롬프트를 순서대로 붙여넣으며 이전 답변이 컨텍스트에 남게 합니다. 다음은 우리가 사용하는 정확한 프롬프트와 함께 6가지 간단한 단계입니다. 각각은 의도적으로 웹앱 특화이며, 일반적인 비즈니스 분석 프롬프트는 일반적인 스코프를 생성하기 때문입니다.

시작하기 전 참고사항: 괄호 안의 플레이스홀더를 자신의 세부사항으로 바꾸고, 절대 첫 번째 결과물을 최종 결과물로 받아들이지 마세요. 프로처럼 각 결과물을 읽고, 수정한 다음, 다음 프롬프트를 실행하는 것입니다.

프롬프트 1: 문제 진술 및 목표

이것은 개요와 목표 섹션을 생성합니다. 팁: "3가지 가정" 부분이 무거운 작업을 하고 있습니다. AI가 다른 방식으로 은폐할 수 있는 공백을 드러냅니다.

프롬프트 2: 사용자 스토리

이제 기능 요구사항이 있습니다. 이것은 깔끔한 AI 사용자 스토리 생성 단계입니다. 주의: 관리자와 엣지 케이스 역할을 잊어버리는 경향이 있으므로, "이제 관리자, 결제 실패, 빈 상태에 대한 스토리를 추가하세요"라는 메시지로 다시 프롬프트하세요.

프롬프트 3: 기능 목록

이것은 범위 내 기능 후보 목록입니다. 이 단계를 자세히 살피세요. AI가 통합을 만들어 내기 시작하는 부분입니다(자세한 내용은 아래).

프롬프트 4: MoSCoW 우선순위 지정

이것은 범위 내 및 범위 외 항목에 태그를 지정합니다. "무정하게" 지시가 중요합니다. 이 없으면 모델은 거의 모든 것을 Must로 표시합니다.

프롬프트 5: 노력, 비용 및 타임라인 견적

이것은 예산과 타임라인을 위한 AI 범위 작업 생성기 입력입니다. 항상 범위와 가정을 요구하세요. 단일 자신 있는 숫자가 AI가 제공하는 가장 위험한 결과물이기 때문입니다.

프롬프트 6: SOW 초안

[REVIEW] 태그가 인간 검증 체크리스트가 됩니다. 이 단계는 전체 체인이 약속한 아이디어에서 SOW까지의 범위를 조립합니다.

프롬프트 → 범위 섹션 매핑

각 프롬프트는 단순히 질문에 답하는 것이 아니라 클라이언트에게 제공하는 문서의 특정 섹션을 채웁니다. 이 매핑이 일반적인 11섹션 템플릿을 대체합니다: 해골을 암기하는 대신 체인을 실행하고 문서가 자동으로 조립됩니다. 다음은 어느 프롬프트가 어느 결과물을 생성하는지입니다.

프롬프트 6을 완료할 때쯤이면, 클라이언트가 실제로 읽고 서명할 수 있는 완전한 첫 번째 초안 문서를 갖게 됩니다. 연결되지 않은 노트 더미가 아닙니다.

완전한 실제 예제: 예약 예약 SaaS 범위 지정

여기는 한 가지 구체적인 사례에서 끝까지 실행되는 체인입니다: 소규모 치과 체인을 위한 예약 예약 SaaS. 이것은 실제 클라이언트 결과물이 아닌 설명 예제이며, 네, 우리는 AI 결과물에서 두 가지 오류를 발견했고, 이를 아래 인간 검증 섹션에서 수정합니다.

프롬프트 1 결과물(문제 및 목표). 문제: 3개 지점의 치과 체인이 전화 통신과 노쇼로 인해 예약을 잃습니다. 목표: 알림을 통해 노쇼를 30% 줄이고, 환자가 온라인으로 자체 예약을 하게 하며, 프론트데스크 직원에게 공유 캘린더 하나를 제공합니다. 가정 플래그: 단일 시간대, 영어만 사용, 보험 청구 없음.

프롬프트 2 결과물(샘플 사용자 스토리).

  • 환자로서, 나는 온라인으로 예약을 하고 싶습니다. 전화로 연락할 필요가 없도록.
  • 환자로서, 나는 SMS 알림을 받고 싶습니다. 내 예약을 잊지 않도록.
  • 프론트데스크 직원으로서, 나는 한 캘린더에서 세 지점을 모두 보고 싶습니다. 중복을 관리할 수 있도록.

프롬프트 3 결과물(기능 목록, 축약됨). 온라인 예약, 캘린더 동기화, SMS 및 이메일 알림, 환자 계정, 다중 지점 관리자, 기본 보고, 결제 단계(마지막 것은 만들어짐. 아무도 요청하지 않았음).

프롬프트 4 결과물(MoSCoW 그리드).

프롬프트 5 결과물(견적, 축약됨). Next.js, Supabase, Twilio, 2명의 개발자를 가정하면: Must-have 기능 약 45~60 개발자 일, 약 $35K~$55K 범위의 비용, 8~10주 타임라인. 가장 위험한 견적 플래그: 다중 지점 캘린더 로직.

프롬프트 6 결과물(SOW 발췌). "범위 내: 온라인 예약, 다중 지점 공유 캘린더, SMS 알림(Twilio), 환자 계정. 범위 외: 결제, 보험, 네이티브 모바일. 타임라인: 8~10주. 예산 범위: $35K-$55K. [REVIEW] Twilio와 대체 SMS 제공업체를 클라이언트와 확인하세요."

...

출처 바로가기