직군별 프롬프트 템플릿: 도메인 특화 실무 가이드

1 직군별 프롬프트 템플릿

1.1 직군별 템플릿의 전략적 가치

직군별 프롬프트 템플릿은 일반적인 범용 프롬프트와 근본적으로 다른 접근이다. 각 직군의 고유한 업무 프로세스, 용어, 산출물 형식을 반영하여 설계된다.

템플릿화의 핵심 이점

범용 프롬프트는 “무엇이든 할 수 있지만 아무것도 완벽하지 않다”는 한계가 있다. 반면 직군별 템플릿은 해당 직군의 80% 업무를 커버하도록 최적화되어 있어, 즉시 실무에 투입 가능하다.

예를 들어 마케터가 “블로그 글 써줘”라고 하면 AI는 어떤 톤으로, 어떤 구조로, 어떤 길이로 써야 할지 모른다. 하지만 마케터용 템플릿은 “SEO 최적화, 명확한 CTA, 독자 페르소나 반영”같은 마케팅 전문 요구사항이 이미 내장되어 있다.

템플릿의 재사용성

한 번 검증된 템플릿은 팀 전체가 공유할 수 있다. 신입 직원도 선임의 노하우가 담긴 프롬프트를 즉시 사용할 수 있다. 이는 업무 품질의 하한선을 올리는 효과가 있다.

1.2 리서치/보고서 작성 프롬프트 템플릿

You are responsible for writing a formal business report that is
professional, factual, and objective.

Report Topic:
{{REPORT_TOPIC}}

Company Data:
{{COMPANY_DATA}}

Report Structure:
1. Title Page
2. Table of Contents
3. Executive Summary
4. Introduction
5. Main Body (with subheadings)
6. Conclusion
7. Recommendations
8. References (if needed)
9. Appendices (if needed)

Section Guidelines:
1. Title Page: Include the report title, your name, date, and company name.
2. Table of Contents: List sections with page numbers.
3. Executive Summary: Brief overview (max 1 page) of key points and
   recommendations.
4. Introduction: State the report's purpose, background, and scope.
5. Main Body: Present findings and analysis based on the company data. 
   Use clear headings.
6. Conclusion: Summarize key findings.
7. Recommendations: Provide actionable suggestions for the company.
8. References: List external sources, if used.
9. Appendices: Add any detailed supporting information.

Before Submitting:
• Check for logical flow and coherence.
• Proofread for errors.
• Ensure all data is accurate and sections align with the topic.

템플릿 구조 분석

역할 정의: “formal business report”의 3가지 속성

“professional, factual, and objective”는 단순한 수식어가 아니다. 각각이 구체적 제약을 만든다.

• Professional: 비속어 금지, 격식 있는 어투, 시각 자료는 차트/표로 제한
  
• Factual: 추측 금지, 모든 주장은 데이터로 뒷받침, 감정적 표현 배제
  
• Objective: 회사에 유리한 정보만 선택하지 않음, 장단점 균형 있게 제시

이 세 단어가 없으면 AI는 마케팅 자료처럼 과장하거나, 블로그 글처럼 캐주얼하게 쓸 수 있다.

변수 설계: {{REPORT_TOPIC}}과 {{COMPANY_DATA}}

두 개의 변수만 제공하면 보고서 전체가 생성된다. 이는 템플릿의 핵심 가치다.

{{REPORT_TOPIC}} 예시:
- “2024년 4분기 매출 감소 원인 분석”
- “신규 시장 진입 타당성 검토”
- “경쟁사 A의 전략 분석 및 대응 방안”

{{COMPANY_DATA}} 예시:
- 매출 데이터 (CSV, 표 형태)
- 고객 피드백 (텍스트)
- 경쟁사 자료 (수집한 정보)

9단계 구조의 실무적 정당성

이 구조는 비즈니스 보고서의 국제 표준이다. MBA 교육, 컨설팅 펌, 대기업에서 공통적으로 사용한다.

왜 이 순서인가?

1. Title Page: 첫인상, 누가 썼고 무엇에 관한 것인가
   
2. Table of Contents: 독자가 원하는 섹션으로 바로 점프
   
3. Executive Summary: 바쁜 경영진은 이것만 읽는다
   
4. Introduction: 왜 이 보고서가 필요한가
   
5. Main Body: 실제 분석과 발견
   
6. Conclusion: 발견 사항 종합
   
7. Recommendations: 실행 가능한 제안
   
8. References: 신뢰성 확보
   
9. Appendices: 본문을 방해하지 않으면서 상세 자료 제공

Section Guidelines의 정교함

각 섹션마다 구체적 지침이 있다. 특히 주목할 점:

“Executive Summary: max 1 page”
페이지 제한은 중요하다. 제한이 없으면 AI는 2~3페이지를 쓸 수 있다. 하지만 Executive Summary의 본질은 “한 페이지에 모든 것”이다. 경영진이 엘리베이터 타는 동안 읽을 수 있어야 한다.

“Main Body: Use clear headings”
보고서의 가독성은 제목 구조에서 결정된다. 명확한 제목이 없으면 독자는 길을 잃는다. “Use clear headings”는 AI에게 2~3 레벨의 계층적 제목 구조를 만들라는 암묵적 지시다.

“Recommendations: Provide actionable suggestions”
“Actionable”이 핵심이다. “더 노력해야 한다”는 권고가 아니라, “분기별 고객 만족도 설문을 도입하고, 결과를 제품 팀과 공유한다”같은 구체적 행동이 필요하다.

Before Submitting 체크리스트의 역할

이 섹션은 AI에게 자기 검토를 요구한다. “보고서를 쓰고 나서 다시 읽어보고 이 세 가지를 확인하라”는 메타 지시다.

• Logical flow: 섹션 간 연결이 자연스러운가?
  
• Proofread: 오타, 문법 오류는 없는가?
  
• Data accuracy: 숫자가 일치하는가? 출처가 명확한가?

이런 체크리스트가 없으면 AI는 일관성 없는 보고서를 생성할 수 있다. 예를 들어 Introduction에서 “3가지 핵심 발견”을 언급했는데 Main Body에서 2가지만 다루는 식이다.

1.3 브레인스토밍 템플릿 (Product Manager용)

You are a Product Manager tasked with brainstorming creative and 
practical ideas for the following topic:

Topic: {{TOPIC}}
Context: {{CONTEXT}}

Steps for the brainstorming session:
1. Analyze the topic and context. Think about user needs, business goals, 
   and potential solutions.
2. Generate 5 distinct ideas that address the topic from different perspectives.
3. For each idea, include:
   - A title (1-5 words)
   - A short description (2-3 sentences)
   - One potential benefit
   - One possible challenge
4. Identify common themes across your ideas.
5. Combine two or more ideas to create a more comprehensive solution.

Answer in Korean.

Product Manager 페르소나의 함의

Product Manager는 특정한 사고방식을 가진다. 엔지니어처럼 기술적 실현 가능성만 보지 않고, 마케터처럼 홍보만 생각하지도 않는다. 대신 “사용자 니즈 + 비즈니스 목표 + 기술 제약”의 교집합을 찾는다.

“Think about user needs, business goals, and potential solutions”는 이 3가지 차원을 모두 고려하라는 명시적 지시다.

5개 아이디어의 다양성 전략

“5 distinct ideas”에서 “distinct”가 중요하다. 비슷비슷한 아이디어 5개가 아니라, 서로 다른 관점의 아이디어를 요구한다.

어떻게 다양성을 확보하는가?

AI는 보통 첫 번째 아이디어를 생성한 후, 그것의 변형을 만드는 경향이 있다. “distinct”라는 단어는 이를 방지한다. 각 아이디어가 다른 접근법을 사용하도록 강제한다.

예를 들어 “사용자 리텐션 개선” 주제라면:
- 아이디어 1: 푸시 알림 개선 (기술적 접근)
- 아이디어 2: 리워드 프로그램 (비즈니스 접근)
- 아이디어 3: 커뮤니티 기능 추가 (소셜 접근)
- 아이디어 4: 온보딩 프로세스 단순화 (UX 접근)
- 아이디어 5: 프리미엄 기능 무료 체험 (마케팅 접근)

4가지 요소 구조의 PM 방법론

각 아이디어마다 제목, 설명, 이점, 과제를 요구한다. 이는 PM의 표준 평가 프레임워크다.

Title (1-5 words)
짧은 제목은 커뮤니케이션 효율성을 높인다. 회의에서 “아이디어 3”이 아니라 “리워드 프로그램”이라고 부를 수 있다.

Description (2-3 sentences)
간결함을 강제한다. 3문장으로 설명 못하면 아이디어가 아직 명확하지 않다는 신호다.

One potential benefit
“왜 이게 좋은가?”에 대한 답. 이것이 없으면 아이디어는 그냥 제안일 뿐이다.

One possible challenge
이것이 핵심이다. 대부분의 브레인스토밍은 장점만 나열한다. 하지만 실무에서는 “무엇이 문제인가?”를 먼저 파악해야 실행 가능성을 판단할 수 있다.

예시:

아이디어: 사용자 커뮤니티 포럼 추가
이점: 사용자 간 도움으로 고객 지원 비용 감소
과제: 부정적 피드백이 공개적으로 확산될 위험

과제를 명시하면 “이 아이디어를 실행하려면 커뮤니티 모더레이션 전략이 필요하다”는 후속 논의가 자연스럽게 이어진다.

4단계: Common themes 파악

이 단계는 패턴 인식이다. 5개 아이디어를 보면 보통 2~3개의 공통 테마가 발견된다.

예를 들어:
- 아이디어 1, 3: 사용자 참여 증대
- 아이디어 2, 5: 경제적 인센티브
- 아이디어 4: 진입 장벽 제거

테마를 파악하면 “우리가 실제로 해결하려는 근본 문제가 무엇인가?”를 이해할 수 있다.

5단계: 아이디어 결합

최고의 솔루션은 종종 여러 아이디어의 조합이다. 이 단계는 시너지를 찾는다.

예시:

결합: 리워드 프로그램 + 커뮤니티 포럼
→ "커뮤니티 기여 리워드 시스템"

사용자가 포럼에서 다른 사용자를 도우면 포인트를 얻고, 
포인트로 프리미엄 기능을 잠금 해제할 수 있다.

이점: 
- 커뮤니티 활성화 (도움을 주려는 동기 부여)
- 프리미엄 전환 유도 (맛보기 효과)
- 고객 지원 비용 감소

과제:
- 포인트 경제 설계 복잡도
- 악용 방지 (스팸, 저품질 답변)

결합은 단순 합산이 아니라, 두 아이디어가 만나서 새로운 가치를 창출하는 것이다.

1.4 엔지니어 Python 코드 리서치 템플릿

You are a Python code analyst tasked with researching specific
aspects of Python code. Your goal is to analyze the given code
snippet and answer a research question about it. 
Follow these instructions carefully:

1. You will be presented with a Python code snippet and a
   research question.

2. Here is the Python code to analyze:
<python_code>
{{PYTHON_CODE}}
</python_code>

3. Here is the research question to answer:
<research_question>
{{RESEARCH_QUESTION}}
</research_question>

4. Analyze the provided Python code carefully. Consider its
   structure, functionality, and any notable features or patterns.

5. Answer the research question based on your analysis of the code. 
   Your answer should be thorough, accurate, and directly related to 
   the code and the question asked.

6. Provide your response in the following format:
<analysis>
First, provide a brief overview of the code and its main features.
</analysis>

<answer>
Then, provide a detailed answer to the research question. 
Include specific references to the code where relevant. 
If the question cannot be fully answered based on the
provided code, explain why and what additional information 
might be needed.
</answer>

Remember to focus solely on the provided code and the specific 
research question. Do not make assumptions about code that isn't 
shown or speculate about the broader context unless it's directly 
relevant to answering the question.

XML 태그 구조의 전략적 사용

이 템플릿은 XML 태그를 적극 활용한다. <python_code>, <research_question>, <analysis>, <answer> 같은 명시적 구조화는 세 가지 이점을 제공한다.

이점 1: 명확한 경계
코드 분석에서 가장 큰 문제는 “어디까지가 분석할 코드이고, 어디부터가 질문인가?”의 혼란이다. XML 태그는 이를 완벽히 분리한다.

이점 2: 프로그래밍 방식 처리
XML 구조는 자동화에 유리하다. 예를 들어 GitHub에서 코드를 자동으로 가져와 <python_code> 태그에 삽입하는 스크립트를 만들 수 있다.

이점 3: 일관된 출력 형식
AI의 출력도 XML 태그로 구조화되므로, 파싱이 쉽다. <analysis> 부분만 추출하거나, <answer>만 표시하는 등 유연한 활용이 가능하다.

“Do not make assumptions” 경고의 중요성

코드 분석에서 AI의 가장 큰 함정은 “보이지 않는 코드를 가정하는 것”이다.

예를 들어:

result = process_data(input)

AI는 process_data 함수의 구현을 보지 못했는데도, “이 함수는 아마 데이터를 정규화할 것이다”같은 추측을 할 수 있다. 이는 위험하다.

“Do not make assumptions about code that isn’t shown”은 이를 명시적으로 금지한다. 대신 “제공된 코드만으로는 process_data의 동작을 확인할 수 없다”고 정직하게 말하도록 강제한다.

2단계 출력 구조의 가치

: 전체적 이해
먼저 코드를 전체적으로 파악한다. “이 코드는 웹 스크래핑을 수행하며, BeautifulSoup를 사용한다”같은 큰 그림을 제시한다.

이는 맥락을 설정한다. 연구 질문이 “왜 try-except를 사용했나?”라면, “이 코드는 외부 API를 호출하므로 네트워크 오류 가능성이 있다”는 맥락이 답변 이해를 돕는다.

: 구체적 답변
그 다음 연구 질문에 집중한다. “Include specific references to the code”는 중요하다. 모호한 답변이 아니라, “line 15의 except requests.exceptions.Timeout을 보면…”같은 구체적 참조를 요구한다.

“If the question cannot be fully answered” 조건

이는 정직성을 강제한다. 코드 일부만 제공되었거나, 질문이 코드 범위를 벗어나면, AI는 이를 인정해야 한다.

예시:

질문: "이 함수의 시간 복잡도는?"
코드: 함수 시그니처만 있고 구현은 없음

나쁜 답변: "O(n)일 것으로 추정됩니다"
좋은 답변: "함수 구현이 제공되지 않아 시간 복잡도를 정확히 분석할 수 없습니다. 
           구현 코드가 필요합니다."

1.5 엔지니어 Python 코드 디버깅 템플릿

You are a Python debugging assistant. Your task is to
analyze Python code that has an error and provide
suggestions to fix it. Follow these steps:

1. Review the provided Python code:
<python_code>
{{PYTHON_CODE}}
</python_code>

2. Examine the error message:
<error_message>
{{ERROR_MESSAGE}}
</error_message>

3. Analyze the code and the error message carefully.
Consider the following:
- The type of error (syntax, runtime, logical, etc.)
- The line number where the error occurred (if provided)
- Any specific variables or functions mentioned in the error

4. Provide your debugging suggestions and explanations in the 
   following format:

<debug_analysis>
a) Briefly describe the error and its likely cause
b) Identify the specific line(s) of code that are problematic
c) Explain why the error is occurring
d) Suggest one or more solutions to fix the error
e) If applicable, provide any additional tips or best practices 
   related to the issue
</debug_analysis>

5. If you believe there might be multiple issues or if the error 
   message is unclear, mention this and provide suggestions for 
   further troubleshooting.

6. If you need any clarification or additional information to 
   better assist with debugging, please state so clearly.

Remember to be clear, concise, and helpful in your explanations. 
Your goal is to not only fix the immediate error but also to help 
the user understand why the error occurred and how to prevent 
similar issues in the future.

디버깅 vs 코드 리서치의 차이

이 템플릿은 리서치 템플릿과 비슷해 보이지만, 근본적으로 다른 목적을 가진다.

리서치: “이 코드는 어떻게 작동하는가?” (이해)
디버깅: “이 코드는 왜 작동하지 않는가?” (문제 해결)

디버깅은 에러 메시지라는 추가 입력이 있고, 출력은 “해결 방법”에 집중한다.

에러 타입 분류의 중요성

“The type of error (syntax, runtime, logical, etc.)”는 진단의 첫 단계다.

Syntax Error
코드가 파이썬 문법을 위반했다. 실행조차 안 된다.
예: if x = 5: (=는 할당, ==가 비교)

Runtime Error
문법은 맞지만 실행 중 문제 발생.
예: 1 / 0 (ZeroDivisionError)

Logical Error
코드가 실행되지만 예상과 다른 결과.
예: sum = a - b (더하기가 아니라 빼기)

에러 타입에 따라 해결 전략이 완전히 다르다. Syntax는 코드 수정, Runtime은 예외 처리, Logical은 알고리즘 재검토가 필요하다.

5단계 debug_analysis 구조

a) Briefly describe the error and its likely cause
“IndexError: list index out of range”를 “리스트 길이보다 큰 인덱스에 접근하려 했다”로 평문 설명한다. 에러 메시지는 개발자용이라 초보자는 이해 못할 수 있다.

b) Identify the specific line(s)
“line 42: result = data[i]”처럼 정확한 위치를 찾아준다. 에러 메시지에 라인 번호가 있으면 쉽지만, 없으면 코드를 분석해서 찾아야 한다.

c) Explain why
이것이 교육적 가치의 핵심이다. “왜 에러가 나는가?”를 설명한다.

예: “data 리스트 길이는 10인데, 루프는 range(15)로 15번 반복하므로, i=10부터 IndexError 발생”

d) Suggest solutions
여러 해결책을 제시한다. 각각의 트레이드오프도 설명한다.

예:

해결책 1: range(len(data))로 변경 (안전하지만 원래 의도와 다를 수 있음)
해결책 2: data.extend([None] * 5)로 리스트 확장 (의도대로지만 None 처리 필요)
해결책 3: if i < len(data): 조건 추가 (유연하지만 코드 복잡도 증가)

e) Best practices
단순 버그 수정을 넘어서 “이런 종류의 버그를 예방하려면?”을 제안한다.

예: “리스트 인덱싱 전에 항상 길이 체크 / enumerate() 사용 / try-except로 감싸기”

“Multiple issues” 경고의 실전적 가치

실무에서 에러는 종종 여러 문제가 연쇄적으로 발생한 결과다. 하나를 고치면 다음 에러가 나타난다.

템플릿은 AI에게 “다른 잠재적 문제도 찾아라”고 지시한다.

예:

디버깅 분석:
현재 에러: IndexError at line 42

해결 후 예상 문제:
- line 50: data[i]에서 TypeError 가능 (None 값 처리 안 됨)
- line 65: result 반환 전 초기화 안 됨 (UnboundLocalError 위험)

권장: 현재 에러 수정 후, 전체 코드 리뷰하여 위 문제들도 선제적 수정

이는 디버깅 시간을 크게 단축한다. “하나 고치고 실행, 또 에러, 또 고치고…”를 반복하지 않아도 된다.

1.6 마케터 프롬프트 템플릿

You are tasked with creating effective prompts for a growth and 
content marketer. Your goal is to create prompts that are specific, 
actionable, and aligned with the given marketing goal and target audience.

You will be provided with two input variables:

<marketing_goal>
{{MARKETING_GOAL}}
</marketing_goal>

<target_audience>
{{TARGET_AUDIENCE}}
</target_audience>

Use these inputs to tailor your prompts to the specific marketing goal 
and target audience.

Guidelines:
1. Make the prompts specific and focused on the marketing goal
2. Ensure the prompts consider the target audience's needs, preferences,
   and pain points
3. Use action-oriented language that encourages creative thinking
4. Include elements that can lead to measurable outcomes
5. Keep the prompts open-ended enough to allow for diverse ideas

Output your prompts in the following format:
<prompt>
Insert your prompt here
</prompt>

Here are two examples of good prompts:

<prompt>
Develop a content strategy for a blog series that addresses the top 5
pain points of {{target_audience}} related to {{marketing_goal}}, 
including potential topics, content formats, and distribution channels.
</prompt>

<prompt>
Create a social media campaign concept that showcases how our
product/service helps {{target_audience}} achieve {{marketing_goal}},
including post ideas for three different platforms and a hashtag strategy.
</prompt>

Generate 5 unique prompts following the guidelines and format provided
above. Ensure that each prompt is distinct and addresses different
aspects of the marketing goal and target audience.

“프롬프트를 만드는 프롬프트”의 메타 구조

이 템플릿은 흥미로운 메타 레벨에서 작동한다. 마케터에게 직접 콘텐츠를 만들어주는 게 아니라, 마케터가 사용할 프롬프트를 생성해준다.

왜 이런 구조인가?

마케팅은 반복적이고 다양하다. 블로그 글 10개, 소셜 포스트 50개, 이메일 캠페인 20개를 만들어야 한다. 매번 프롬프트를 처음부터 쓰기보다, “이 캠페인에 맞는 프롬프트 5개”를 먼저 생성하면 효율적이다.

5가지 Guidelines의 마케팅 전문성

1. Specific and focused on the marketing goal
모호한 프롬프트는 모호한 결과를 낳는다. “소셜 미디어 콘텐츠 만들어줘”보다 “Instagram에서 MZ세대에게 친환경 패션 브랜드 인지도를 높이는 릴스 스크립트 5개”가 훨씬 낫다.

2. Consider target audience’s needs, preferences, and pain points
마케팅의 황금률은 “고객이 원하는 것을 줘라”다. 프롬프트에 타겟 오디언스가 명시되지 않으면, AI는 일반적이고 차별화되지 않은 콘텐츠를 만든다.

예: “바쁜 직장인”과 “은퇴한 시니어”는 완전히 다른 pain point를 가진다.
- 직장인: 시간 부족, 효율성, 빠른 결과
- 시니어: 신뢰성, 단순함, 장기적 가치

3. Action-oriented language
“Create”, “Develop”, “Design”같은 동사는 구체적 산출물을 유도한다. “Think about”이나 “Consider”는 너무 추상적이다.

나쁜 예: “소셜 미디어 전략에 대해 생각해봐”
좋은 예: “주 3회 포스팅 일정표를 만들고, 각 포스트의 목표와 CTA를 명시해”

4. Include elements that can lead to measurable outcomes
마케팅은 결과로 평가된다. “인지도 향상”은 측정 불가능하다. “웹사이트 방문자 30% 증가”는 측정 가능하다.

프롬프트에 “including metrics to track success”같은 문구를 넣으면, AI가 KPI까지 제안한다.

5. Keep the prompts open-ended
역설적이지만, 너무 구체적인 프롬프트는 창의성을 제한한다. “빨간색 배경에 큰 글씨로”보다 “시선을 확 끄는 비주얼”이 더 다양한 아이디어를 낸다.

예시 프롬프트의 구조 분석

예시 1: 블로그 시리즈

Develop a content strategy for a blog series that addresses the top 5
pain points of {{target_audience}} related to {{marketing_goal}}, 
including potential topics, content formats, and distribution channels.

이 프롬프트는 세 가지 산출물을 요구한다:
1. Top 5 pain points: 먼저 고객 이해
2. Topics + formats: 어떤 내용을 어떤 형식으로
3. Distribution channels: 어디서 공유할 것인가

이는 마케팅 전략의 완전한 프레임워크다. 단순히 “블로그 글 써줘”가 아니라 전체 캠페인 설계를 포함한다.

예시 2: 소셜 미디어 캠페인

Create a social media campaign concept that showcases how our
product/service helps {{target_audience}} achieve {{marketing_goal}},
including post ideas for three different platforms and a hashtag strategy.

“Three different platforms”가 중요하다. Instagram, LinkedIn, Twitter는 완전히 다른 콘텐츠 전략이 필요하다.
- Instagram: 시각 중심, 짧은 캡션, 이모지
- LinkedIn: 전문적, 긴 텍스트, 사례 연구
- Twitter: 간결, 실시간, 대화형

“Hashtag strategy”는 발견성(discoverability)을 고려한다. 좋은 해시태그는 너무 일반적이지도(#marketing - 경쟁 과다), 너무 구체적이지도 않다(#b2bsaasmarketingforsmbs - 검색 안 됨).

5개 프롬프트 생성 요구의 의도

왜 5개인가? 다양성과 선택지를 제공하기 위함이다.

마케터는:
- 프롬프트 1: 블로그 콘텐츠용
- 프롬프트 2: 소셜 미디어용
- 프롬프트 3: 이메일 캠페인용
- 프롬프트 4: 랜딩 페이지용
- 프롬프트 5: 비디오 스크립트용

이렇게 채널별로 특화된 프롬프트를 받는다. 각각을 반복 사용하면 일관된 브랜드 메시지를 유지하면서도 채널별 최적화가 가능하다.

1.7 직군별 템플릿의 실전 활용 전략

템플릿 커스터마이징

제공된 템플릿은 시작점이다. 실제로는 회사와 팀의 특성에 맞춰 수정해야 한다.

예: 스타트업의 PM 브레인스토밍

원본: Generate 5 distinct ideas
수정: Generate 5 distinct ideas, prioritizing those that can be 
      implemented with a team of 3 engineers in 2 weeks

리소스 제약을 명시하면, 실행 가능한 아이디어에 집중한다.

템플릿 조합

여러 템플릿을 순차적으로 사용하면 강력하다.

워크플로우 예시:
1. PM 브레인스토밍 템플릿 → 5개 아이디어 생성
2. 엔지니어 코드 리서치 템플릿 → 각 아이디어의 기술적 실현 가능성 평가
3. 마케터 프롬프트 템플릿 → 실행 가능한 아이디어의 마케팅 전략 수립

템플릿 라이브러리 구축

기업은 직군별 템플릿을 내부 위키나 Notion에 정리해야 한다.

구조 예시:

템플릿 라이브러리/
├── Product/
│   ├── brainstorming.md
│   ├── user_story.md
│   └── roadmap.md
├── Engineering/
│   ├── code_review.md
│   ├── debugging.md
│   └── architecture_design.md
├── Marketing/
│   ├── campaign_planning.md
│   ├── content_creation.md
│   └── ab_test_design.md
└── Operations/
    ├── process_optimization.md
    ├── incident_report.md
    └── quarterly_planning.md

각 템플릿에는 사용 예시와 성공 사례를 첨부한다. 신입이 와도 즉시 검증된 프롬프트를 사용할 수 있다.