프로그래밍/AI 프롬프트 엔지니어링

[프롬프트 엔지니어링] LLM을 활용한 PRD 작성을 위한 프롬프팅 가이드

흔한티벳여우 2025. 6. 27. 09:07
반응형

LLM을 활용하여 앱의 제품 요구 명세서(PRD, Product Requirements Document)를 효과적으로 작성하기 위한 프롬프트 엔지니어링 가이드

이 가이드는 단순히 "PRD를 써줘"라고 요청하는 단계를 넘어, LLM을 마치 숙련된 PM 동료나 보조원처럼 활용하여 깊이 있고 체계적인 결과물을 만들어내는 데 초점을 맞춥니다.


LLM을 활용한 PRD 작성을 위한 프롬프팅 가이드

Ⅰ. 핵심 원칙: LLM과의 상호작용 자세

PRD 작성을 시작하기 전에, LLM을 대하는 기본적인 자세를 정립하는 것이 중요합니다.

  1. 페르소나(Persona) 부여: LLM에게 구체적인 역할을 부여하세요. 이렇게 하면 LLM은 해당 역할에 맞는 톤, 전문성, 관점을 유지하게 됩니다.

    • 예시: "당신은 10년차 시니어 프로덕트 매니저(PM)입니다. 지금부터 저와 함께 새로운 앱의 PRD를 만들 것입니다. 비판적이고 논리적인 관점을 유지해주세요."
  2. 맥락(Context) 제공: 당신의 머릿속에 있는 아이디어를 최대한 상세하게 전달해야 합니다. LLM은 당신이 제공한 정보에만 의존합니다.

    • 무엇을(What): 앱의 핵심 아이디어, 주요 기능
    • 누구를 위해(Who): 타겟 고객, 사용자 페르소나
    • 왜(Why): 해결하려는 문제, 앱의 존재 이유, 기대 효과
  3. 단계적 & 대화형 접근: 한 번의 프롬프트로 완벽한 PRD를 만들려고 하지 마세요. 각 단계를 나누어 질문하고, LLM의 답변을 바탕으로 추가 질문을 던지며 문서를 함께 '구축'해나가야 합니다.

  4. 구체적인 형식(Format) 지정: 원하는 결과물의 형식을 명확히 지정하면, 훨씬 정리되고 사용하기 좋은 답변을 얻을 수 있습니다. (예: 마크다운 테이블, 글머리 기호 목록, 사용자 스토리 형식 등)

  5. 비판적 사고 및 반복: LLM의 제안을 맹신하지 마세요. "왜 그렇게 생각해?", "다른 대안은 없어?", "그렇게 할 경우 발생할 수 있는 리스크는 뭐야?" 와 같이 되물으며 결과물을 다듬어 나가야 합니다. 당신이 최종 결정권자입니다.


Ⅱ. 단계별 프롬프트 전략: PRD 구축하기

아래의 6단계를 따라 LLM과 대화하며 PRD를 만들어 보세요.

[1단계] 문제 정의 및 배경 설정 (Problem & Background)

가장 먼저 프로젝트의 기반을 다지는 단계입니다.

  • 기본 프롬프트:

    # 페르소나 설정
    당신은 실리콘밸리 테크 기업의 시니어 프로덕트 매니저(PM)입니다. 지금부터 저와 함께 새로운 앱의 PRD 작성을 시작하겠습니다.
    
    # 앱 기본 정보
    - 앱 이름(가칭): [예: 데일리 포커스]
    - 앱 아이디어: [예: 매일 하나의 가장 중요한 일(MIT)에만 집중하도록 돕는 미니멀리즘 할일 관리 앱]
    - 타겟 고객: [예: 여러 프로젝트와 업무로 인해 번아웃을 느끼는 20-30대 직장인, 대학생]
    - 해결하려는 문제: [예: 기존 할일 앱들은 기능이 너무 많아 오히려 사용자를 압도하고, 정말 중요한 일에 집중하지 못하게 만듦]
    
    # 요청
    위 정보를 바탕으로, 이 PRD의 서론에 들어갈 '1. 문제 정의'와 '2. 목표' 섹션을 작성해줘. 문제점은 사용자의 입장에서 감정적인 언어로, 목표는 비즈니스와 사용자 가치 측면에서 명확하게 구분해서 설명해줘.
  • 심화/개선 프롬프트:

    • "이 문제 정의에서 우리가 놓치고 있는 잠재 고객 그룹이 있을까?"
    • "이 문제를 겪는 사용자들이 현재 어떤 대안(경쟁 앱, 다른 방법)을 사용하고 있을지 3가지 예상해보고, 각 대안의 장단점을 분석해줘."

[2단계] 사용자 페르소나 및 시나리오 구체화 (User Persona & Scenarios)

누구를 위한 제품인지 명확히 합니다.

  • 기본 프롬프트:

    앞서 정의한 타겟 고객을 바탕으로, 대표 사용자 페르소나 2명을 생성해줘. 아래 형식을 반드시 지켜줘.
    
    - 이름:
    - 직업/나이:
    - 성격/특징 (Tech-savvy 수준 포함):
    - 목표(Goals): 이 앱을 통해 이루고 싶은 것
    - 불편함(Frustrations): 현재 겪고 있는 문제점
    
    결과는 마크다운 테이블 형식으로 정리해줘.
  • 심화/개선 프롬프트:

    • "방금 만든 페르소나 '김민준'이 우리 앱을 아침에 일어나서 밤에 잠들 때까지 어떻게 사용할지 시간 순서대로 사용자 시나리오를 작성해줘."
    • "두 페르소나 중 MVP(최소 기능 제품) 단계에서 더 집중해야 할 페르소나는 누구일까? 그 이유도 설명해줘."

[3단계] 제품 비전 및 핵심 기능 브레인스토밍 (Product Vision & Features)

이제 본격적으로 '무엇을 만들지'를 정의합니다.

  • 기본 프롬프트:
    정의된 문제와 페르소나를 바탕으로, 우리 앱의 핵심 기능 목록을 브레인스토밍해줘. 기능은 사용자가 얻는 가치를 중심으로 설명하고, MoSCoW 기법 (Must-have, Should-have, Could-have, Won't-have)에 따라 우선순위를 분류해줘.
  • 심화/개선 프롬프트:
    • "Must-have 기능들만으로 MVP를 구성한다고 가정했을 때, 사용자의 핵심적인 문제를 해결할 수 있을지 검토하고 너의 의견을 말해줘."
    • "이 기능 목록에서 경쟁 앱들과 차별화되는 우리 앱만의 '킬러 기능'은 무엇이라고 생각해?"

[4단계] 기능 명세 구체화 (User Stories & Acceptance Criteria)

개발팀이 바로 이해할 수 있도록 기능을 상세히 설명합니다.

  • 기본 프롬프트:

    위에서 정의한 Must-have 기능 중 '[예: 오늘의 MIT(Most Important Task) 설정 기능]'에 대해 상세한 기능 명세를 작성해줘. 아래의 '사용자 스토리'와 '수용 조건(Acceptance Criteria)' 형식을 사용해줘.
    
    # 사용자 스토리 (User Story)
    - As a [사용자 타입], I want to [행동], so that [가치/결과].
    
    # 수용 조건 (Acceptance Criteria)
    - Given [조건], When [행동], Then [결과]. (시나리오 기반으로 여러 개 작성)
  • 심화/개선 프롬프트:

    • "이 기능 명세에서 고려해야 할 엣지 케이스(Edge Case)나 예외 처리 시나리오 3가지를 제안해줘."
    • "이제 너는 까다로운 QA 엔지니어의 입장에서 위 기능 명세를 보고, 잠재적인 버그나 설계상 허점이 될 수 있는 부분을 지적해줘."

[5단계] 비기능적 요구사항 및 성공 지표 설정 (Non-functional & Metrics)

제품의 품질과 성공을 정의합니다.

  • 기본 프롬프트:

    우리 앱을 위해 고려해야 할 비기능적 요구사항(Non-functional Requirements)을 '성능', '보안', '확장성', '사용성' 카테고리로 나누어 제안해줘.
    
    또한, 이 앱의 성공을 측정하기 위한 핵심 성공 지표(KPIs)를 3가지 제안하고, 각 지표를 왜 선택했는지 이유를 설명해줘.
  • 심화/개선 프롬프트:

    • "제안된 KPI 중 '사용자 리텐션'을 측정하기 위한 구체적인 데이터 추적 방안은 무엇일까?"
    • "AARRR 프레임워크를 적용해서 우리 앱의 성장 단계를 분석하고 각 단계에 맞는 지표를 다시 설계해줘."

[6단계] 최종 PRD 초안 생성 및 검토 (Drafting & Review)

모든 논의 내용을 종합하여 하나의 문서로 만듭니다.

  • 기본 프롬프트:

    좋아. 지금까지 논의한 모든 내용을 종합해서, 아래 목차에 따라 PRD 초안을 마크다운 형식으로 작성해줘. 비어있는 부분은 '[추가 논의 필요]'라고 표시해줘.
    
    # [앱 이름] PRD 초안
    
    1.  **개요**
        1.1. 문제 정의
        1.2. 제품 목표 및 비전
    2.  **타겟 고객**
        2.1. 대표 페르소나
        2.2. 사용자 시나리오
    3.  **기능 요구사항**
        3.1. 우선순위 (MoSCoW)
        3.2. 핵심 기능 명세 (사용자 스토리 및 수용 조건)
            - 3.2.1. [기능 1]
            - 3.2.2. [기능 2]
    4.  **비기능적 요구사항**
    5.  **성공 지표 (KPIs)**
    6.  **릴리즈 계획 (가안)**
    7.  **Q&A (예상 질문 및 답변)**
  • 심화/개선 프롬프트:

    • "이 PRD 초안을 개발팀 리더에게 보여준다면, 어떤 질문을 가장 먼저 할 것 같아? 예상 질문과 모범 답변 3가지를 만들어줘."
    • "이 PRD에서 논리가 부족하거나 불명확한 부분을 비판적으로 검토하고, 개선이 필요한 부분을 지적해줘."

Ⅲ. 고급 활용 팁 및 주의사항

  • 다양한 관점 활용: "이제 너는 디자이너야. 이 PRD를 보고 UX/UI 관점에서 개선할 점을 찾아줘.", "이제 너는 마케터야. 이 제품의 핵심 소구 포인트를 찾아줘." 와 같이 역할을 바꿔가며 문서를 검증하세요.
  • '생각의 사슬(Chain of Thought)' 기법: 복잡한 요청에는 "네가 이 문제를 어떻게 해결할지 단계별로 생각하는 과정을 먼저 설명하고, 그 다음에 최종 답을 내줘."라고 요청하여 더 논리적인 결과물을 유도할 수 있습니다.
  • 기억의 한계: LLM은 대화가 길어지면 앞선 내용을 잊어버릴 수 있습니다. 중요한 내용은 각 단계마다 다시 요약해서 상기시켜주는 것이 좋습니다.
  • 최종 책임은 당신에게: LLM은 훌륭한 조수이지만, 비즈니스적 판단, 시장에 대한 깊은 이해, 최종 의사결정은 온전히 당신의 몫입니다. LLM이 생성한 내용은 반드시 검토하고 자신의 생각과 경험을 바탕으로 수정해야 합니다.

이 가이드를 따라 LLM과 체계적으로 소통한다면, 단순한 문서 생성을 넘어 제품에 대한 깊은 고민과 다각적인 검토를 수행하며 훨씬 완성도 높은 PRD를 만들어낼 수 있을 것입니다.

반응형