테마 전환

Prompt Engineering 템플릿 라이브러리: 재사용 가능한 12가지 프롬프트 설계 패턴

Easton editorial illustration: one enlarged reusable four-field template card

40분을 들여 꽤 완벽한 Prompt를 하나 썼습니다. Claude가 뒤죽박죽인 사용자 피드백을 구조가 분명한 개선 제안으로 정리해 주었고, 결과는 놀라울 만큼 좋았습니다. 그런데 사흘 뒤 같은 일을 다시 해야 하는 순간, 빈 입력창 앞에서 머리가 하얘졌습니다.

그 “완벽한 Prompt”는 어디로 갔을까요?

Notion, 메모 앱, 채팅 기록을 다 뒤졌지만 찾을 수 없었습니다. 결국 기억에 의존해 다시 썼고, 출력 품질은 한참 떨어졌습니다.

이런 일을 열 번 넘게 겪었습니다. 매번 흐름은 같았습니다. 번뜩이며 좋은 Prompt를 씁니다 → 쓰고 나면 잊습니다 → 다음번에는 다시 처음부터 시작합니다 → 품질이 들쭉날쭉합니다.

그러다 한 가지 핵심을 깨달았습니다. Prompt가 좋은지는 절반은 기법에 달려 있고, 나머지 절반은 “재사용할 수 있는가”에 달려 있습니다.

80%
일상 업무 상황 커버

aiengineerlab.in의 2026년 연구에 따르면, “가끔 통하는” Prompt와 “계속 믿고 쓸 수 있는” Prompt를 가르는 핵심 차이는 네 가지 필드입니다. 이 네 가지 필드를 잘 조합하면 일상 업무 상황의 80%를 커버할 수 있습니다.

이 글에서는 검증된 Prompt 템플릿 라이브러리 구축 방법을 공유합니다.

  • 4필드 구조: Role + Task + Constraints + Output Format
  • 12가지 Prompt Patterns: Beginner/Intermediate/Advanced 난이도별 분류
  • 멀티 모델 적응표: Claude, GPT-4, DeepSeek에 맞춘 차별화 전략
  • 템플릿 반복 개선 방법: “꽤 괜찮은” 템플릿을 “프로덕션급”으로 다듬는 법
  • 바로 쓸 수 있는 템플릿 5개: 복사해서 붙여 넣으면 바로 실행 가능

1장: Prompt 템플릿의 4필드 구조

구체적인 템플릿을 보기 전에, 기초적이지만 자주 놓치는 사실부터 짚겠습니다. 좋은 템플릿과 나쁜 템플릿의 구조적 차이는 결국 네 가지 필드입니다.

aiengineerlab.in의 연구는 “신뢰할 수 있고 효과적인” Prompt에는 반드시 네 가지 요소가 있어야 한다고 말합니다. Role(역할), Task(작업), Constraints(제약), Output Format(출력 형식)입니다.

먼저 나쁜 예부터 보겠습니다

코드 리뷰 답변을 작성해 줘

저도 예전에는 이런 Prompt를 수없이 썼습니다. 결과는 어땠을까요? AI가 내놓는 답변은 매번 제각각이었습니다. 어떤 때는 너무 공손했고, 어떤 때는 지나치게 기술적이었고, 어떤 때는 그냥 “코드가 괜찮습니다” 한 문장만 주기도 했습니다.

4필드를 넣은 버전은 다릅니다

## Role
당신은 10년 경력의 백엔드 엔지니어이며 Python과 분산 시스템에 능숙합니다.

## Task
아래 코드 변경 사항을 리뷰하고, 잠재 문제를 지적하며 개선 제안을 제공하세요.

## Constraints
- 초점: 성능, 보안, 유지보수성
- 어조: 전문적이지만 친절하게, 지나치게 엄격한 표현은 피하기
- 분량: 200자 이내로 제한
- 최소 하나의 개선점을 반드시 지적하기

## Output Format
아래 형식으로 출력하세요.
### 문제 목록
- [문제 유형] 구체적 설명

### 개선 제안
1. ...
2. ...

### 전체 평가
(한 문장 요약)

차이가 꽤 분명합니다.

4필드 자세히 보기

**Role(역할)**은 AI에게 자신이 누구인지 알려줍니다. 아무 신분이나 붙이는 것이 아니라 구체적인 배경이 있는 “페르소나”를 설정해야 합니다. 예를 들어 “10년 경력의 백엔드 엔지니어”는 “당신은 전문가입니다”보다 훨씬 구체적입니다. 역할 설정이 구체적일수록 AI의 출력 스타일은 더 안정됩니다.

**Task(작업)**는 AI가 무엇을 해야 하는지 알려줍니다. 여기에는 작은 요령이 있습니다. 동사로 시작하는 것입니다. “코드 리뷰”보다 “코드 변경 사항을 리뷰하세요”가 더 명확합니다. “잠재 문제를 지적하고 개선 제안을 제공하세요”는 “코드 좀 봐 주세요”보다 훨씬 선명합니다.

**Constraints(제약)**는 가장 자주 빠지지만 가장 중요한 필드입니다. 저는 너무 많은 Prompt가 이 단계에서 무너지는 것을 봤습니다. 제약이 없으면 AI는 마음대로 뻗어나갑니다. 제약에는 초점 영역(성능인가, 보안인가), 어조, 분량 제한, 반드시 포함할 요소가 들어갑니다. 쉽게 말해 제약은 AI에게 경계선을 그어 주는 일입니다.

**Output Format(출력 형식)**은 결과가 어떤 모양이어야 하는지 정합니다. JSON이 필요한가요? Markdown인가요? 아니면 특정 섹션 구조인가요? 미리 분명히 말해 두면 이후 정리 시간을 크게 줄일 수 있습니다.

비교표 하나

필드나쁜 예좋은 예효과 차이
Role”당신은 전문가입니다""10년 경력의 백엔드 엔지니어, Python에 능숙”출력 스타일 안정
Task”코드 좀 봐 줘""코드 변경 사항을 리뷰하고 문제와 제안을 제시”작업 범위 명확
Constraints없음”성능과 보안 중심, 200자 이내, 개선점 최소 1개”출력 제어 가능
Output Format없음”문제 목록 + 개선 제안 + 전체 평가”추가 정리 불필요

이 네 가지 필드를 잘 조합하면 Prompt는 “운에 맡기는 입력”에서 “재사용 가능한 템플릿”으로 바뀝니다. 이것이 템플릿화의 출발점입니다.

2장: 재사용 가능한 12가지 Prompt Patterns 빠른 참고표

best-ai.org는 꽤 실용적인 Prompt Patterns 목록을 난이도별 세 단계로 정리했습니다. 저는 이 패턴들을 사용 상황별로 다시 묶었습니다. 필요한 패턴을 빠르게 찾기 좋게 만들기 위해서입니다.

Beginner 단계(5가지)

1. Zero-Shot(제로샷)

예시 없이 작업만 바로 줍니다. 단순하고 명확한 작업에 적합합니다.

## Task
{{작업 설명}}

## Output Format
{{출력 형식}}

적용 상황: 이메일 요약, 짧은 텍스트 번역, 사실형 질문 답변.

2. Few-Shot(퓨샷)

예시 2-3개를 주고 AI가 모방하게 합니다. aiengineerlab.in의 테스트에 따르면 보통 2-3개 예시가 가장 효과적이며, 분류 작업에는 5-7개를 사용할 수 있습니다.

## Task
{{작업 설명}}

## Examples
예시 1:
입력: {{예시 입력1}}
출력: {{예시 출력1}}

예시 2:
입력: {{예시 입력2}}
출력: {{예시 출력2}}

## Now Process
입력: {{실제 입력}}
출력:

적용 상황: 문체 모방, 분류 작업, 형식 변환.

3. Persona(역할 부여)

AI의 신분과 배경을 설정합니다. 가장 자주 쓰이는 패턴 중 하나이며, 1장의 “Role” 필드와 함께 사용합니다.

## Role
당신은 {{구체적 신분}}이며, {{구체적 배경}}을 가지고 있습니다.

## Style
당신의 말투는 다음과 같습니다: {{스타일 설명}}

## Task
{{작업 설명}}

적용 상황: 코드 리뷰, 기술 상담, 창의적 글쓰기.

4. Output Format(출력 형식화)

AI가 특정 형식으로만 출력하도록 강제합니다. 이 패턴은 거의 모든 다른 패턴과 조합할 수 있습니다.

## Task
{{작업 설명}}

## Output Format
아래 형식을 엄격히 따라 출력하세요.
{{형식 템플릿}}

## Note
형식화된 내용만 출력하고, 추가 설명은 하지 마세요.

적용 상황: JSON 생성, 양식 작성, 구조화 문서.

5. Negative Prompting(부정 제약)

AI에게 “무엇을 하지 말아야 하는지” 알려줍니다. 때로는 긍정 제약보다 더 효과적입니다.

## Task
{{작업 설명}}

## Do NOT
- {{금지 항목1}}하지 마세요
- {{금지 항목2}}하지 마세요
- {{금지 항목3}}을 피하세요

적용 상황: 특정 용어 피하기, 민감한 내용 제외, 출력 스타일 제어.

Intermediate 단계(4가지)

6. Chain of Thought(사고 과정)

AI가 추론 과정을 보여 주게 합니다. 논리 추론이 필요한 작업에 적합합니다.

## Task
{{작업 설명}}

## Instructions
단계별로 생각하세요. 먼저 문제를 분석한 뒤 답을 제시하세요.
최종 답변 전에 추론 과정을 보여 주세요.

적용 상황: 수학 문제, 논리 추론, 복잡한 의사결정.

7. System Prompt(시스템 프롬프트)

역할의 핵심 지시를 System Prompt에 넣어 대화의 일관성을 유지합니다. Claude와 GPT-4에서 특히 많이 쓰입니다.

## System
당신은 {{역할 설명}}입니다.
당신의 핵심 책임은 {{책임 설명}}입니다.
아래 규칙을 반드시 지켜야 합니다.
1. {{규칙1}}
2. {{규칙2}}

## User
{{사용자 입력}}

적용 상황: AI Agent, 챗봇, 지속 대화 상황.

8. Iterative Refinement(반복 개선)

먼저 AI가 초안을 만들고, 다시 스스로 수정하게 합니다. 고품질 출력이 필요한 작업에 적합합니다.

## Round 1
{{작업 설명}}
초안을 생성하세요.

## Round 2
위 초안을 리뷰하고 아래 문제를 찾으세요.
- 논리적 허점
- 불명확한 표현
- 사실 오류

## Round 3
리뷰 결과를 바탕으로 초안을 개선하고 최종 버전을 출력하세요.

적용 상황: 글쓰기, 코드 생성, 설계안 작성.

9. Constraint Stacking(제약 누적)

여러 제약을 쌓아 더 정확한 출력을 얻습니다. 프로덕션 환경에서 가장 많이 쓰이는 조합입니다.

## Task
{{작업 설명}}

## Constraints
- 제약 1: {{구체적 제약}}
- 제약 2: {{구체적 제약}}
- 제약 3: {{구체적 제약}}
- 제약 4: {{구체적 제약}}

## Output Format
{{형식 요구사항}}

적용 상황: 출력을 엄격하게 제어해야 하는 프로덕션 작업.

Advanced 단계(3가지)

10. Self-Critique(자기 검토)

AI가 자신의 출력 품질을 스스로 평가하게 합니다. 고품질이 필요한 상황에서 특히 유용합니다.

## Task
{{작업 설명}}

## Self-Critique
답을 생성한 뒤 다음을 평가하세요.
1. 답변이 완전한가?
2. 논리적 허점은 없는가?
3. 모든 제약을 충족하는가?

문제가 있으면 다시 생성하세요.

## Output Format
답변:
{{답변}}

자기 평가:
{{평가}}

적용 상황: 고위험 출력, 신뢰성이 필요한 작업.

11. Task Decomposition(작업 분해)

복잡한 작업을 하위 작업으로 나눕니다. 여러 단계의 워크플로에 적합합니다.

## Complex Task
{{복잡한 작업 설명}}

## Decomposition
이 작업을 여러 하위 작업으로 나누세요.
1. {{하위 작업1}}
2. {{하위 작업2}}
3. {{하위 작업3}}

## Execution
각 하위 작업을 순서대로 완료하고, 단계별 결과를 설명하세요.

적용 상황: 프로젝트 관리, 복잡한 문제 분석, 시스템 설계.

12. Meta-Prompting(메타 프롬프팅)

AI가 Prompt를 작성하게 합니다. 어떻게 표현해야 할지 애매할 때 특히 좋습니다.

## Task
아래 작업을 완료해야 합니다: {{작업 설명}}

## Request
다른 AI가 이 작업을 잘 수행할 수 있도록 고품질 Prompt를 작성해 주세요.
Prompt에는 Role, Task, Constraints, Output Format이 포함되어야 합니다.

적용 상황: Prompt Engineering 입문자, 복잡한 작업 정리.

조합해서 쓸 때의 작은 팁

"2-4개의 Pattern을 조합할 때 효과가 가장 좋습니다. 흔한 조합으로는 Business Writing에 Persona + Output Format + Constraint Stacking, Code Generation에 Persona + Few-Shot + Negative Prompting, Research & Analysis에 Chain of Thought + Self-Critique + Task Decomposition이 있습니다."

3장: 멀티 모델 적응 비교표

AI 모델마다 Prompt를 “이해하는 방식”이 조금씩 다릅니다. Claude에서 아주 잘 작동한 Prompt가 GPT-4에서는 조금 아쉬울 수 있습니다.

이 장에서는 시행착오를 줄이기 위한 모델 적응 가이드를 정리했습니다.

Claude: XML 태그와 계약형 지시

Claude에는 한 가지 특징이 있습니다. 구조화된 것을 특히 좋아합니다. 공식 문서에서도 XML 태그로 Prompt를 구성하는 방식을 권장하며, 순수 텍스트보다 효과가 더 좋은 편입니다.

<instructions>
아래 코드 변경 사항을 리뷰하고 잠재 문제를 지적하세요.
</instructions>

<context>
당신은 10년 경력의 백엔드 엔지니어입니다.
프로젝트는 FastAPI 프레임워크를 사용하는 Python 마이크로서비스입니다.
</context>

<constraints>
- 성능과 보안에 집중
- 전문적이지만 친절한 어조
- 200자 이내로 제한
</constraints>

<output_format>
### 문제 목록
- [유형] 설명

### 개선 제안
1. ...
</output_format>

Claude의 또 다른 장점 두 가지:

  • Extended Thinking: Claude가 출력 전에 먼저 “생각”하게 하며, 복잡한 추론 작업에 적합합니다
  • 계약형 지시: 시작 부분에 “모든 제약을 지키면 OK를 출력한다”처럼 명확히 적으면 제약 준수율을 높일 수 있습니다

GPT-4: 긴 제약 목록과 JSON 출력

GPT-4는 XML 태그 방식에 크게 의존하지 않습니다. 오히려 “목록형” 제약에 더 잘 맞습니다. 또한 GPT-4의 JSON 출력 안정성은 Claude보다 약간 더 좋은 편입니다.

## Task
아래 코드 변경 사항을 리뷰하세요.

## Constraints
1. 성능과 보안에 집중
2. 전문적이지만 친절한 어조
3. 200자 이내로 제한
4. 최소 하나의 개선점을 반드시 지적
5. 한국어로 출력

## Output Format
JSON 형식으로 출력하세요.
{
  "issues": [...],
  "suggestions": [...],
  "summary": "..."
}

GPT-4의 특징:

  • 제약 목록을 10개 이상 써도 모델이 비교적 잘 지킵니다
  • Few-shot 패턴의 효과가 Claude보다 약간 더 좋습니다
  • 코드 생성과 설명 능력이 비교적 균형 잡혀 있습니다

DeepSeek와 Qwen: 중국산 대규모 모델에 맞추기

중국산 모델은 최근 2년 동안 빠르게 발전했지만, 고유한 특징도 있습니다.

DeepSeek:

  • 중국어 이해 능력은 강하지만 구조화 지시를 따르는 정도는 약간 약합니다
  • 제약을 더 명확하고 더 짧게 쓰는 것이 좋습니다
  • Few-shot 예시 수는 1-2개로 줄여도 됩니다

Qwen(통의천문):

  • “역할 설정”에 잘 반응하며 Persona 패턴 효과가 좋습니다
  • 긴 텍스트 처리 능력이 강해 문서형 작업에 적합합니다
  • 제약은 “피하기”보다 “금지”로 쓰는 편이 좋고, 긍정 지시가 부정 지시보다 더 효과적입니다

Llama(소형 파라미터 버전): 더 직설적인 지시가 필요

Llama 7B, 13B 같은 소형 파라미터 모델에는 Prompt를 더 “초보자용”으로 써야 합니다.

## Task
코드 변경 사항을 리뷰하세요.

## Output Format
Return ONLY valid JSON. No explanation. No markdown.
{
  "issues": [],
  "suggestions": []
}

핵심: “JSON만 출력하고 설명하지 말라”는 말을 반드시 명시해야 합니다. 그렇지 않으면 소형 모델은 필요 이상으로 덧붙이는 경향이 있습니다.

적응 빠른 참고표

모델추천 구조Few-shot 수제약 형식특수 팁
ClaudeXML 태그2-3개태그 안에 블록별 작성Extended Thinking
GPT-4목록형3-5개번호 목록Function Calling
DeepSeek간결한 구조1-2개짧은 문장중국어 우선
QwenPersona + 목록2-3개긍정 지시긴 문서에 강함
Llama under 13B초간단 구조1개명시적 금지”X만 출력” 강조

결국 모델 적응에서 가장 좋은 방법은 “직접 테스트해 보는 것”입니다. Prompt를 쓴 뒤 목표 모델에서 몇 가지 사례를 실행하고, 출력 품질을 확인한 다음 맞춤 조정을 하면 됩니다.

4장: 템플릿 반복 개선 방법론

“괜찮은” Prompt 하나를 쓰는 일은 어렵지 않습니다. 어려운 것은 그것을 “매번 잘 작동하는” 템플릿으로 바꾸는 일입니다.

"최고의 템플릿은 한 번에 완성되지 않습니다. 반복 사용과 개선을 거쳐 만들어집니다. 좋은 템플릿은 적어도 다섯여섯 번은 반복 개선해야 합니다."

반복 개선의 다섯 단계

Step 1: Prompt를 작성하고 좋은 결과 얻기

처음부터 템플릿화하려고 서두르지 마세요. 먼저 Prompt를 하나 쓰고 몇 번 실행해 출력 품질이 안정적인지 확인합니다.

Step 2: 고정 부분과 변수 식별하기

만족스러운 출력을 얻었다면 Prompt에서 어떤 부분이 “고정”이고 어떤 부분이 “매번 바뀌는지” 분석합니다.

고정 부분, 예를 들어 역할 설정이나 출력 형식은 템플릿의 핵심 골격이 됩니다.

변수 부분, 예를 들어 구체적인 작업 내용이나 입력 데이터는 {{변수명}}으로 표시해 매번 교체합니다.

Step 3: 품질 가드레일 추가하기

골격을 완성된 템플릿으로 확장하고 제약과 검증 조건을 추가합니다.

가드레일의 역할은 “예상 밖의 출력”을 막는 것입니다. 예를 들면 다음과 같습니다.

  • 출력이 너무 길면 “X자 이내로 제한” 제약을 추가합니다
  • AI가 자꾸 불필요한 말을 덧붙이면 “설명하지 말고 결과만 출력”을 추가합니다
  • 출력 형식이 들쭉날쭉하면 구체적인 형식 템플릿을 넣습니다

Step 4: 사용하면서 문제 기록하기

템플릿을 실제로 쓰기 시작하면 매번 만나는 문제를 기록합니다.

  • 출력 품질이 흔들렸나요?
  • 제약을 어긴 경우가 있었나요?
  • 어떤 상황에서는 잘 되고, 어떤 상황에서는 약했나요?

Step 5: 반복해서 개선하기

기록한 문제에 맞춰 템플릿을 조정합니다. 흔한 개선 방향은 다음과 같습니다.

  • 제약이 충분히 명확하지 않음 → 더 구체적인 설명 추가
  • 출력 형식이 불안정함 → 예시 또는 형식 템플릿 추가
  • 특정 상황에서 효과가 약함 → 상황별 조건 분기 추가

반복 개선 사례 하나

저에게는 “주간 보고서 생성” 템플릿이 하나 있습니다. 안정되기까지 대략 8번의 반복 개선을 거쳤습니다.

초기 버전(반복 1): 간단한 Prompt만 써서 AI가 이번 주 업무를 주간 보고서 형식으로 정리하게 했습니다. 문제는 출력이 너무 제각각이었다는 점입니다. 어떤 때는 매우 자세했고, 어떤 때는 한 문장뿐이었습니다.

반복 2-3: 출력 형식 템플릿과 글자 수 제약을 추가했습니다. 형식은 대체로 안정됐지만, 어떤 작업 설명을 빠뜨리는 경우가 있었습니다.

반복 4-5: “각 작업의 진행 상황, 문제, 다음 단계를 반드시 포함”이라는 제약을 추가했습니다. 출력 품질은 안정됐지만, AI가 중요하지 않은 작은 작업까지 모두 써 넣는 문제가 생겼습니다.

반복 6-7: “이번 주에 완료한 핵심 작업만 작성”이라는 제약을 추가하고 예시도 하나 제공했습니다. 거의 안정됐지만, 가끔 형식이 어긋났습니다.

반복 8(최종 버전): Self-Critique 모듈을 추가해 AI가 출력이 형식 요구사항을 충족하는지 확인한 뒤 내보내게 했습니다.

핵심 질문 템플릿

문제가 생길 때마다 저는 스스로에게 아래 질문을 던집니다.

  1. 출력에 큰 편집이 필요한가? → 필요하다면 제약이 충분히 명확하지 않다는 뜻입니다
  2. AI가 어떤 제약을 어겼는가? → 해당 제약을 더 구체적으로 씁니다
  3. 빠진 정보가 있는가? → “X를 반드시 포함”이라는 지시를 추가합니다
  4. 불필요한 정보가 있는가? → “X를 출력하지 말라”는 Negative Prompting을 추가합니다
  5. 형식이 일관적인가? → 예시 또는 형식 템플릿을 추가합니다

팀 공유 템플릿의 세 가지 핵심

팀에서도 AI 도구를 쓴다면 공유 Prompt Library를 만드는 것만으로 효율이 크게 올라갑니다. mintedbrain.com은 세 가지를 제안합니다.

1. 공유 문서: 모든 템플릿을 팀이 접근할 수 있는 문서에 둡니다. Notion이나 Feishu (Lark) 같은 도구를 쓸 수 있습니다. 글쓰기, 분석, 개발, 커뮤니케이션처럼 카테고리별로 나눕니다.

2. 사용 설명: 각 템플릿에 짧은 설명을 붙입니다. 적용 상황, 변수 설명, 주의사항을 적습니다. 그렇지 않으면 다른 사람이 템플릿을 가져가도 어떻게 써야 하는지 알기 어렵습니다.

3. 개선 제안 절차: 팀원이 문제를 발견했을 때 템플릿을 바로 고치지 않고 “개선 제안”을 올리게 합니다. 이렇게 하면 매번 변경 이유를 추적할 수 있고, 템플릿이 제멋대로 바뀌어 원래 형태를 잃는 일을 피할 수 있습니다.

5장: 바로 쓸 수 있는 프로덕션급 템플릿 5개

마지막 장에서는 바로 복사해서 쓸 수 있는 템플릿 5개를 제공합니다. 모두 실제 사용과 반복 개선을 거친 템플릿이라 대체로 바로 적용할 수 있습니다.

템플릿 1: 주간 보고서 생성

<instructions>
이번 주 업무 기록을 바탕으로 간결한 주간 보고서를 생성하세요.
</instructions>

<role>
당신은 효율적인 팀 협업자이며, 업무 진행 상황을 간결한 언어로 요약하는 데 능숙합니다.
</role>

<input>
{{이번 주 업무 기록}}
</input>

<constraints>
- 이번 주에 완료한 핵심 작업만 포함
- 각 작업 설명: 진행 상황, 문제, 다음 단계
- 300자 이내로 제한
- 전문적이고 간결한 어조
- "잘했습니다" 같은 평가성 표현을 추가하지 않기
</constraints>

<output_format>
## 이번 주 진행 상황
- {{작업1}}: {{진행 상황}} | {{문제}} | {{다음 단계}}
- {{작업2}}: {{진행 상황}} | {{문제}} | {{다음 단계}}

## 도움이 필요한 사항
- {{도움이 필요한 사항}}

## 다음 주 계획
- {{다음 주 계획}}
</output_format>

<self_check>
생성 후 아래를 확인하세요.
1. 핵심 작업만 포함했는가?
2. 각 작업에 진행 상황, 문제, 다음 단계가 모두 있는가?
3. 전체 글자 수가 300자 이내인가?
</self_check>

템플릿 2: 코드 리뷰

<instructions>
아래 코드 변경 사항을 리뷰하고 잠재 문제를 지적하며 개선 제안을 제공하세요.
</instructions>

<role>
당신은 10년 경력의 백엔드 엔지니어이며 {{프로그래밍 언어}}와 {{기술 스택}}에 능숙합니다.
당신의 스타일은 전문적이지만 지나치게 엄격하지 않으며, 문제를 지적할 때 구체적이고 실행 가능한 제안을 함께 제공합니다.
</role>

<input>
{{코드 변경 내용}}
</input>

<constraints>
- 초점: 성능, 보안, 유지보수성, 코드 규칙
- 최소 하나의 개선점을 지적
- 각 문제 설명: 유형, 위치, 원인, 제안
- 200자 이내로 제한
- "코드가 괜찮습니다"라고만 말하지 말고 반드시 구체적인 내용을 포함
</constraints>

<output_format>
### 문제 목록
- [{{문제 유형}}] {{파일명}}#{{줄 번호}}: {{문제 설명}}

### 개선 제안
1. {{제안 내용}}

### 전체 평가
{{한 문장 평가}}
</output_format>

템플릿 3: 회의록 정리

<instructions>
아래 회의 기록을 구조화된 회의록으로 정리하세요.
</instructions>

<role>
당신은 전문 회의 기록 담당자이며, 핵심 정보를 추출하고 요점을 정리하는 데 능숙합니다.
</role>

<input>
{{회의 기록 내용}}
</input>

<constraints>
- 핵심 정보만 추출하고 불필요한 대화는 제거
- 논의 주제, 결론, 할 일, 담당자, 마감일을 명확히 표시
- 간결한 언어 사용
- 500자 이내로 제한
</constraints>

<output_format>
## 회의 기본 정보
- 시간: {{날짜와 시간}}
- 참석자: {{참석자 목록}}
- 안건: {{안건 목록}}

## 논의 요점
### {{안건1}}
- {{요점1}}
- {{요점2}}
- 결론: {{결론}}

### {{안건2}}
- ...

## 할 일
| 항목 | 담당자 | 마감일 |
|------|--------|----------|
| {{항목1}} | {{담당자}} | {{날짜}} |
| {{항목2}} | {{담당자}} | {{날짜}} |

## 비고
{{비고 내용}}
</output_format>

템플릿 4: JSON 데이터 추출

<instructions>
아래 텍스트에서 구조화 데이터를 추출해 JSON 형식으로 출력하세요.
</instructions>

<role>
당신은 정확한 데이터 추출 전문가입니다.
</role>

<input>
{{입력 텍스트}}
</input>

<constraints>
- JSON만 출력하고 추가 설명은 하지 않기
- JSON은 반드시 유효한 형식이어야 함
- 정보가 없으면 필드 값은 null
- 원문에 없는 정보를 추가하지 않기
</constraints>

<output_format>
Return ONLY valid JSON. No explanation. No markdown.

{
  {{필드 정의}}
}

Example:
Input: "김철수, 전화 01012345678, 이메일 [email protected]"
Output:
{
  "name": "김철수",
  "phone": "01012345678",
  "email": "[email protected]"
}
</output_format>

템플릿 5: AI Agent 시스템 프롬프트

<system_prompt>
당신은 {{agent_name}}이며, {{agent_description}}을 전담합니다.

## 핵심 책임
1. {{책임1}}
2. {{책임2}}
3. {{책임3}}

## 작업 흐름
사용자 요청을 받으면 아래 단계로 처리합니다.
1. 요청 의도 분석
2. 작업을 완료하기에 충분한 정보가 있는지 확인
3. 정보가 부족하면 적극적으로 질문
4. 작업 실행
5. 결과 검증

## 행동 규칙
- 친절하고 전문적인 어조 유지
- 불확실한 문제는 명확히 설명하고 제안 제시
- 책임 범위를 벗어난 약속을 하지 않기
- 출력은 명확하고 실행 가능해야 함

## 금지 사항
- 정보를 지어내지 않기
- 승인되지 않은 결정을 내리지 않기
- 민감하거나 유해한 내용을 출력하지 않기

## 출력 형식
작업 유형에 따라 적절한 형식을 선택합니다.
- 정보 조회: 간결한 답변 + 출처 설명
- 작업 실행: 단계 목록 + 결과 확인
- 문제 해결: 분석 + 해결안 + 제안
</system_prompt>

이 템플릿들은 일상 업무에서 가장 흔한 상황을 커버합니다. 자신의 필요에 맞게 변수와 제약을 조정하면 더 구체적인 상황에도 잘 맞출 수 있습니다.

결론

길게 이야기했지만 핵심은 세 층입니다.

구조 차원에서는 4필드 구조(Role + Task + Constraints + Output Format)가 템플릿의 기반입니다. 이 네 필드를 제대로 채우면 Prompt는 “운에 기대는 입력”에서 “제어 가능한 입력”으로 바뀝니다.

Pattern 차원에서는 12가지 Prompt Patterns가 서로 고립되어 있지 않습니다. 2-4개의 Pattern을 조합하면 단일 Pattern보다 효과가 훨씬 좋습니다. 프로덕션 환경에서 가장 흔한 조합은 Persona + Output Format + Constraint Stacking입니다.

엔지니어링 차원에서는 템플릿은 한 번 쓰고 끝나는 것이 아닙니다. 반복 개선이 핵심입니다. 좋은 템플릿은 최소 다섯여섯 번의 사용과 개선을 거칩니다. 문제를 기록하고, 제약을 조정하고, 가드레일을 추가하는 과정까지가 템플릿화의 전체 흐름입니다.

이 글을 읽고 바로 시작하고 싶다면 세 가지를 권합니다.

  1. 이번 주에 Pattern 하나만 시험해 보세요. Beginner 단계에서 하나를 고릅니다. Persona나 Output Format이 좋습니다. 실제 업무에 적용한 뒤 Prompt를 쓰고 출력 품질이 달라졌는지 확인합니다.

  2. 나만의 Personal Prompt Library를 만드세요. 5개 템플릿에서 시작하면 됩니다. 이 5개 템플릿을 하나의 문서에 넣어 두고, 사용할 때마다 복사해 붙여 넣은 뒤 변수만 교체합니다.

  3. 매달 한 번 반복 개선하세요. 한 달 동안 사용한 뒤 어떤 템플릿이 잘 작동했고 어떤 템플릿에 문제가 있었는지 봅니다. 그에 맞춰 제약을 조정하고, 예시를 추가하고, 형식을 개선합니다.

Prompt Engineering은 복잡하게 보면 복잡하고, 단순하게 보면 단순합니다. 복잡한 부분은 방법론과 기법입니다. 단순한 부분은 이것입니다. 재사용 가능한 템플릿 라이브러리가 생기면, 더 이상 매번 빈 입력창 앞에서 막막해할 필요가 없습니다.

FAQ

4필드 구조에서 Constraints는 어떻게 써야 효과적인가요?
Constraints는 구체적이고, 정량화할 수 있으며, 검증 가능해야 합니다. '고품질', '전문적'처럼 모호한 표현은 피하고, '200자 이내로 제한', '개선점 최소 1개 포함'처럼 구체적인 제약으로 바꾸는 것이 좋습니다. 각 제약은 가능한 한 하나의 확인 가능한 기준과 연결되어야 합니다.
12가지 Prompt Patterns 중 가장 실용적인 것은 무엇인가요?
단일하게 '가장 실용적인' Pattern은 없습니다. 상황마다 맞는 패턴이 다르기 때문입니다. 실제 데이터 기준으로는 Persona(역할 부여)와 Output Format(출력 형식화)의 조합 사용 빈도가 가장 높고, 일상 업무의 약 80%에 잘 맞습니다. 이 두 가지부터 익히는 것을 권장합니다.
Claude와 GPT-4의 Prompt는 무엇이 다른가요?
Claude는 XML 태그 구조를 선호하며, 제약을 태그 안에 넣는 방식이 잘 맞습니다. GPT-4는 번호 목록 형태의 제약에 잘 적응하고 10개 이상의 조건도 처리할 수 있습니다. Claude는 Extended Thinking(사고 과정 확장)을 지원해 복잡한 추론에 적합하고, GPT-4는 Function Calling이 더 안정적이어서 구조화 출력에 유리합니다.
템플릿은 몇 번 반복 개선해야 안정적인가요?
실무 경험상 좋은 템플릿은 안정되기까지 최소 5-6번의 반복이 필요합니다. 핵심 흐름은 사용 → 문제 기록 → 맞춤 개선입니다. 확인할 질문은 다음과 같습니다. 출력에 큰 편집이 필요한가? AI가 어떤 제약을 어겼는가? 형식이 일관적인가?
팀이 함께 쓰는 Prompt Library는 어떻게 만들면 좋나요?
핵심은 세 가지입니다. 1) Notion이나 Feishu (Lark) 같은 공유 문서에 카테고리별로 정리합니다. 2) 각 템플릿에 적용 상황, 변수 설명, 주의사항을 포함한 사용 설명을 붙입니다. 3) 개선 제안 절차를 만들어 매번 변경 이유를 추적하고, 템플릿이 임의로 바뀌지 않게 합니다.
Few-shot은 예시를 몇 개 주는 것이 좋나요?
aiengineerlab.in 연구에 따르면 보통 2-3개의 예시가 가장 효과적입니다. 분류 작업은 5-7개 예시를 사용할 수 있습니다. 예시가 너무 많으면 Prompt 길이는 늘지만 효과가 반드시 좋아지지는 않습니다. 핵심은 예시가 대표 상황을 포괄해야 하며, 양보다 품질이 중요하다는 점입니다.

2분 읽기 · 게시일: 2026년 4월 29일 · 수정일: 2026년 10월 21일

댓글

GitHub로 로그인하여 댓글을 남기세요

Easton BlogEaston Blog