안녕하세요, Gakken LEAP의 프론트엔드 엔지니어 쿠사카입니다.

최근 저는 PM(Project Manager)으로의 직무 전환에 도전하고 있습니다.

다양한 이해관계자로부터 쏟아지는 해상도 낮은 '모호한 요구사항'. 이를 개발 팀이 구현할 수 있는 수준의 제품 요구 사양서(PRD)로 떨어뜨리는 작업은 PM에게 가장 신경과 칼로리(에너지)를 많이 소모하는 업무입니다.

백지 상태의 문서를 앞에 두고 끙끙대며 혼자 써 내려간 사양서를 엔지니어에게 보여주면, "이 에러 발생 시의 동작은요?", "과거 데이터는 어떻게 이관하나요?"라며 놓친 부분을 지적받곤 합니다…….

이 기사에서는 그런 PM의 고뇌를 날려버릴 'AI 대화형 요구사항 정의 프롬프트'를 공개합니다.

AI에게 한 번에 문장을 쓰게 하는 것이 아니라, AI를 '초우수한 애널리스트(Analyst)'로 만들어 당신에게 인터뷰를 하게 만드는 역발상 접근법입니다.

왜 AI에게 '한 번에 쓰게 하면' 실패하는가?

최근의 LLM에 "〇〇 기능의 PRD를 써줘"라고 통째로 맡기면, 언뜻 그럴싸한 문서가 몇 초 만에 출력됩니다.

하지만 그것을 그대로 현장에서 사용할 수 있느냐고 묻는다면 대답은 NO입니다.

• 자사 서비스 특유의 업무 플로우(Workflow)가 누락되어 있음
• 정상계(Normal case)만 고려되어 있고, 예외 처리(Exception handling)가 부실함
• 어디선가 본 듯한, 무난하고 뻔한 템플릿 문장이 됨

이유는 간단합니다. "언어화되지 않은 전제 지식(Context)"이 AI에게 전달되지 않았기 때문입니다.

따라서 AI를 "끌어내는 쪽(인터뷰어, Interviewer)"으로 돌림으로써 이 문제를 해결합니다.

AI 대화형 요구사항 정의 프롬프트

다음 프롬프트를 그대로 복사하여 ChatGPT나 Claude에 입력해 보세요.

# 지시
당신은 세계 최고봉의 IT 프로덕트 매니저(Product Manager)이자 시니어 시스템 애널리스트(Senior System Analyst)입니다.
목적은, 내가 가져온 '해상도 낮은 요구사항'을 개발 팀이 망설임 없이 구현에 착수할 수 있는 수준의 '강고한 제품 요구 사양서(PRD)'로 완성하는 것입니다.
...

이렇게 입력하면 다음과 같이 돌아옵니다.

AI

알겠습니다. 세계 최고봉의 프로덕트 매니저 겸 시니어 시스템 애널리스트로서, 당신의 아이디어를 개발 팀이 열광하며 망설임 없이 형상화할 수 있는 압도적인 PRD(제품 요구 사양서)로 승화시키기 위한 동행을 시작하겠습니다.

먼저, 당신이 품고 있는 '해상도 낮은 요구사항'에 대해 어떤 아이디어인지 개요를 알려주세요.

그 개요를 들은 후, 바로 제1탄 인터뷰(3가지 질문)에 들어가겠습니다. 어떤 시스템 혹은 앱의 이미지인지, 우선은 대략적인 말로도 괜찮으니 들려주세요!

이에 대해 다음과 같이 모호한 요구사항을 던집니다.

사용자

최근 해외 고객도 늘어났는데, 이름 입력 폼이 대응되지 않더라고요. 미들네임이나 공백 등을 허용하도록 변경하고 싶습니다.

그러면 다음과 같이 답해줍니다.

AI

해외 고객 증가에 따른 이름 입력 폼 개수 작업이군요. 글로벌 대응에 있어 매우 중요하며, 시스템에 미치는 영향 범위도 넓어지기 쉬운 포인트입니다. 확실하게 사양을 다져 나갑시다.

사고를 심화하고 사양 누락을 방지하기 위해, 우선 다음 3가지 사항에 대해 알려주세요.

1. 폼의 구조와 유스케이스(Use case)에 대하여

현재의 이름 입력 폼은 어떤 항목으로 나누어져 있습니까? (예: "성", "이름", "후리가나" 등)

또한, 개수 후에는 어떤 항목 구성으로 하고 싶으신가요? (예: 하나의 "풀네임(Full name)" 입력란으로 합치기, First / Middle / Last Name으로 나누기 등)

2. 허용하는 문자 종류(정상계 플로우)에 대하여

"미들네임이나 공백" 이외에 어디까지의 문자 종류를 허용하고 싶습니까?

(예: 알파벳, 하이픈 "-", 아포스트로피 "'", 악센트 기호가 붙은 문자 "é", "ö" 등)

3. 기존 시스템 및 데이터에 대한 영향에 대하여

현재 이미 등록되어 있는 고객의 "이름 데이터"는 이번 개수에 맞춰 새로운 형식으로 데이터 이관(Migration)을 진행할 예정입니까? 아니면 신규 등록 및 기존 사용자가 프로필을 업데이트할 때만 새로운 포맷을 적용하는 형태입니까?

답변은 "모름", "미정"이어도 전혀 문제없습니다. 그 경우에는 Next Action으로 정리할 테니, 현시점에서의 생각을 들려주세요.

이와 같이 인터뷰 형식으로 대화가 진행되며, 최종적으로 PRD가 완성됩니다.

위의 프롬프트는 예시이므로 실제로 활용할 때는 커스터마이징하여 사용하면 좋을 것 같습니다.

느낀 장점

인지하지 못한 관점을 보강할 수 있다

개발 현장에서 프론트엔드 (Front-end) 구현을 하다 보면, "API가 에러를 반환했을 때의 UI는 어떻게 하나요?", "데이터가 비어 있을 경우의 표시는요?"와 같이 사양의 빈틈을 메우기 위한 확인이 필요한 상황에 수없이 직면해 왔습니다. 하지만 막상 PM (Project Manager) 입장이 되어 처음부터 사양서를 작성하려고 하면, 아무래도 사용자가 이상적으로 조작하는 정상계 (Normal case) 설계에만 의식이 쏠리기 쉽습니다.

이 프롬프트의 가장 큰 강점은 AI가 객관적인 분석가 (Analyst)로서 "예외 처리 (Exception handling)"나 "비기능 요구사항 (Non-functional requirements)"을 강제적으로 질문해 준다는 점에 있습니다. 혼자서는 놓치기 쉬운 엣지 케이스 (Edge case)를 AI와의 대화를 통해 망라할 수 있기 때문에, 개발 팀에 전달하기 전 단계에서 재작업 (Rework)의 원인이 되는 사양의 구멍을 미리 메울 수 있습니다.

다음에 취해야 할 액션을 명확히 할 수 있다

요구사항 정의 (Requirements definition)에서 가장 큰 블로커 (Blocker)는, "아직 결정되지 않은 것"이나 "타 부서에 확인하지 않으면 알 수 없는 것"에 부딪혀 손이 멈춰버리는 것입니다.

이 기법의 뛰어난 점은 AI의 질문에 대해 당당하게 "모른다", "미정"이라고 답할 수 있도록 설계되어 있다는 것입니다. AI는 억지로 추측하여 사양을 채우는 것이 아니라, 최종적인 아웃풋 (Output) 내에서 "미결 사항 · Next Action"으로서 깔끔하게 태스크 (Task)화 해줍니다.

"과거 데이터의 이관 필요 여부에 대해서는 사업부장에게 히어링 (Hearing)한다", "〇〇의 유스케이스 (Use case)는 영업 팀에 확인한다"와 같이, 모호했던 우려 사항이 구체적인 액션 리스트 (Action list)로 변환되기 때문에, 프로젝트를 정체시키지 않고 망설임 없이 다음 액션으로 넘어갈 수 있습니다.

만약 액션의 우선순위 지정이 필요하다면, 그 또한 AI의 도움을 받을 수 있습니다. 마찬가지로 인터뷰 형식을 통해 대화함으로써 관점의 누락을 방지할 수 있습니다.

마치며: AI 시대 PM의 진정한 가치

이 워크플로우 (Workflow)를 도입하면, PM에게서 "문서의 형식을 갖추기 위해 타이핑하는 시간"이 소멸합니다.

AI에게 사양서를 쓰게 하는 것이 아닙니다. AI의 날카로운 질문에 대해 "그것은 한다", "그것은 하지 않는다", "그것은 확인하러 간다"라는 【의사결정 (Decision making)】을 연속적으로 수행하는 것입니다.

사양의 구멍을 메우고, 팀이 헤매지 않을 이정표를 만들며, 불확실한 부분을 히어링하러 가는 것. 그것이야말로 AI가 대체할 수 없는 PM의 진정한 가치입니다.

다음 프로젝트 요구사항 정의부터 꼭 이 "AI 인터뷰"를 시도해 보세요. 더 이상 백지 상태의 문서를 앞에 두고 망연자실하는 일은 없을 것입니다.

엔지니어 모집 중

Gakken LEAP는 매일 교육의 업데이트를 위해 노력하고 있습니다.

관심이 있으신 분은 채용 사이트를 확인해 주세요.

Discussion