Prompt Engineering
목차
Prompt Engineering의 역할
Prompt Engineering은 LLM이 원하는 작업을 정확하게 수행하도록 입력(Prompt)을 설계하는 기술이다. 같은 모델도 프롬프트 품질에 따라 성능이 크게 차이난다.
1
2
3
4
5
6
7
8
9
10
| 나쁜 프롬프트:
Q: "Python은?"
A: "Python은 프로그래밍 언어다" (애매함)
좋은 프롬프트:
Q: "초보자 관점에서 Python의 특징 3가지를 설명해 줘"
A: "1. 읽기 쉬운 문법...
2. 강력한 라이브러리 생태계...
3. ..."
(명확하고 상세한 답변)
|
프롬프트 요소
1
2
3
4
5
6
7
| Prompt = Instruction + Context + Examples + Constraints + Output Format
1. Instruction: 무엇을 할 것인가?
2. Context: 배경 정보와 맥락
3. Examples: 원하는 형식과 스타일의 예시
4. Constraints: 제약과 주의사항
5. Output Format: 어떤 형식으로 결과를 원하는가?
|
Instruction
“명확한 명령이 왜 중요한가?”
명확한 명령은 모델이 작업의 목표를 확실히 이해하게 해 정확도를 높인다.
1
2
3
4
5
6
7
| 애매한 명령:
"코드를 작성해 줘"
→ 어떤 코드? 언어? 목적?
명확한 명령:
"Python으로 주어진 리스트의 중복 제거 함수를 작성해 줘"
→ 명확한 목표, 언어, 기능 지정
|
명령 작성 원칙
1
2
3
4
5
6
7
8
9
10
11
12
13
| 1. 동사로 시작
- "설명해 줘"
- "작성해 줘"
- "비교해 줘"
- "분석해 줘"
2. 구체적 목표
- "프로그래밍을 가르쳐" (X)
- "배열의 시간복잡도를 초보자 관점에서 설명해" (O)
3. 역할 할당
- "너는 보안 전문가야. XXX의 취약점을 분석해"
- "데이터 과학자 관점에서 이 데이터 세트를 분석해"
|
“prompt에 역할을 주는 것은 언제 도움이 되는가?”
역할을 할당하면 모델이 특정 전문성과 관점으로 답변하므로, 복잡한 분석이나 특정 분야의 설명이 필요할 때 효과적이다.
1
2
3
4
5
6
7
8
9
10
11
12
13
| 역할 없이:
"Docker와 Kubernetes의 차이는?"
→ 일반적인 설명
역할 있이:
"DevOps 엔지니어 관점에서 Docker와 Kubernetes의 실무적 차이를 설명해"
→ 운영, 배포, 스케일링 중심의 답변
역할이 효과적인 경우:
✓ 도메인 전문 지식 필요
✓ 특정 관점의 분석 필요
✓ 복잡한 기술적 주제
✗ 단순 팩트 확인
|
Context
“프롬프트에 맥락(Context)은 왜 중요한가?”
맥락은 모델이 작업의 배경을 이해하고 더 적절한 답변을 생성하게 한다. 충분한 정보 제공이 핵심이다.
1
2
3
4
5
6
7
8
9
10
11
| 맥락 없이:
"이 코드의 문제점을 찾아"
→ 일반적인 조언만 가능
맥락 있이:
"이것은 마이크로서비스 아키텍처에서
실시간 주문 처리 서비스야.
성능과 안정성이 중요해.
[코드]
이 코드의 문제점을 찾아"
→ 아키텍처와 요구사항을 고려한 답변
|
“긴 context는 항상 좋은가?”
좋은 맥락은 길이가 아니라 관련성이다. 불필요한 정보가 많으면 모델이 혼동될 수 있다.
1
2
3
4
5
6
7
8
| 너무 짧은 맥락:
부족한 정보 → 일반적인 답변
적절한 맥락:
필요한 정보 + 배경 → 정확한 답변
너무 긴 맥락:
불필요한 정보 포함 → 혼동, 컨텍스트 윈도우 낭비
|
맥락 제공 가이드
1
2
3
4
5
6
7
8
9
10
11
12
13
| 1. 배경 정보
- 문제 해결 배경
- 제약 조건
- 목표
2. 관련 정보
- 기존 시스템 구조
- 성능 요구사항
- 보안 요구사항
3. 부정 정보 (하지 말아야 할 것)
- "MySQL은 사용하지 마"
- "REST API는 사용하지 말고 GraphQL만 사용"
|
Examples
“예시는 모델 출력 형식에 어떤 영향을 주는가?”
예시(Few-shot)는 모델이 원하는 형식과 스타일을 정확히 이해하게 한다. 예시가 많을수록 모델의 출력이 일관되고 정확해진다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| 예시 없이:
Q: "영화 평가를 점수로 줘"
A: "좋아요. 7점"
A: "훌륭합니다. 8/10"
A: "별 4개" (불일관)
예시 있이:
"영화 평가를 다음 형식으로 줘:
Format: [영화명] - [점수]/10 - [한 문장 평가]
Example:
[인셉션] - 9/10 - 꿈 속 세계를 정교하게 구성한 걸작."
→ 일관된 형식
|
Few-shot vs Zero-shot
1
2
3
4
5
6
7
8
9
10
11
| Zero-shot (예시 없이):
명령만 제공
→ 빠르지만 형식 불일관
One-shot (예시 1개):
명령 + 예시 1개
→ 기본 형식 제공
Few-shot (예시 2-5개):
명령 + 예시 여러 개
→ 패턴 학습, 일관성 높음
|
예시 작성 가이드
1
2
3
4
5
6
7
8
9
| # 좋은 예시 구성
예시 1: 기본 케이스 (표준적인 입력)
예시 2: 엣지 케이스 (경계 케이스)
예시 3: 복잡한 케이스 (다양한 변수)
예시 내용:
- 현실적이어야 함
- 구분 가능해야 함
- 원하는 출력 형식을 명확히 보여줘야 함
|
구현 예시
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
| Task: 감정 분석
Zero-shot:
"다음 리뷰의 감정을 분석해"
리뷰: "이 영화는 정말 좋아!"
Output: "긍정"
Few-shot:
"다음 리뷰의 감정을 긍정/중립/부정으로 분류해
Example 1:
리뷰: '최고의 영화야!'
감정: 긍정
Example 2:
리뷰: '그냥 그래요'
감정: 중립
Example 3:
리뷰: '시간 낭비였어'
감정: 부정
이제 다음을 분석해:
리뷰: '꽤 마음에 들었어요'
감정:"
→ 명확한 형식으로 답변
|
Constraints
“제약 조건은 무엇을 위해 필요한가?”
제약은 모델의 생성을 특정 범위 내로 제한해 원하지 않는 출력을 방지한다.
1
2
3
4
5
6
7
| 제약 없이:
"요약해 줘"
→ 길이, 스타일, 세부 수준 불명확
제약 있이:
"요약해 줘 (100단어 이내, 초보자 수준, 전문 용어 최소화)"
→ 명확한 가이드라인
|
일반적 제약
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| 길이 제약:
- "300단어 이내"
- "5줄 이하"
- "한 문단"
스타일 제약:
- "초보자 관점에서"
- "기술적 용어 최소화"
- "비유를 1개 포함"
- "공식적인 톤"
내용 제약:
- "개인정보 포함하지 말 것"
- "최신 정보 기준 (2026년)"
- "Python만 사용"
- "부정적 표현 피할 것"
|
“출력 형식을 명시하는 것이 왜 중요한가?”
명시적 형식은 모델의 출력을 구조화해 파싱하고 자동 처리를 쉽게 한다.
1
2
3
4
5
6
7
8
9
10
11
12
| 형식 없이:
"상품 추천 목록"
→ 마크다운? JSON? 일반 텍스트?
형식 명시:
"JSON 형식으로 반환:
{
\"products\": [
{\"name\": \"...\", \"price\": ..., \"reason\": \"...\"}
]
}"
→ 명확한 구조
|
형식 종류
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| 구조화된 형식:
- JSON: 프로그래밍에 최적
- CSV: 표 데이터
- YAML: 설정 파일
- XML: 문서 구조
마크다운:
- 헤더로 섹션 구분
- 리스트로 항목 정렬
- 코드 블록으로 예시
표 형식:
| 헤더1 | 헤더2 |
|------|------|
| 값1 | 값2 |
|
예시
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
| Prompt:
"3개 영화 추천해 줘
JSON 형식:
{
\"recommendations\": [
{
\"title\": \"영화명\",
\"year\": 연도,
\"reason\": \"추천 이유\"
}
]
}"
Output:
{
"recommendations": [
{
"title": "인셉션",
"year": 2010,
"reason": "과학적 기반의 판타지"
},
...
]
}
→ 파싱 가능한 형식
|
Evaluation
“모델 답변은 어떻게 평가해야 하는가?”
평가는 작업의 목표에 따라 다른 기준을 적용해야 한다. 정확도, 완전성, 명확성, 형식 준수를 확인한다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| 평가 차원:
1. 정확성 (Accuracy)
- 사실에 맞는가?
- 최신 정보인가?
2. 완전성 (Completeness)
- 명령을 모두 수행했는가?
- 누락된 것은?
3. 명확성 (Clarity)
- 이해하기 쉬운가?
- 예시나 설명이 충분한가?
4. 형식 준수 (Format Compliance)
- 요청한 형식인가?
- JSON이 유효한가?
5. 관련성 (Relevance)
- 맥락에 적절한가?
- 조건을 위반하지 않았는가?
|
평가 체크리스트
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| □ 목표 달성
"모든 5개 항목을 다뤘는가?"
□ 정확도
"팩트가 맞는가? 할루시네이션은 없는가?"
□ 형식
"요청한 형식을 따랐는가?"
□ 제약 준수
"word count, 스타일, 내용 제약을 지켰는가?"
□ 품질
"답변이 충분히 상세한가?"
|
반복 개선
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| 평가 결과 문제 발견 시:
정확도 문제:
→ Context 추가 또는 검증 요청
"최신 정보를 기반으로 해"
"출처를 명시해"
형식 문제:
→ 형식 예시를 더 명확히
"정확히 이 JSON 형식 사용"
부정확성:
→ 제약 강화
"환각을 피하고, 모른다면 '모른다'고 말해"
|
정리
| 개념 | 설명 |
|---|
| Instruction | 무엇을 할 것인가 (명령) |
| Context | 배경 정보와 맥락 |
| Examples | 원하는 형식의 예시 (Few-shot) |
| Constraints | 길이, 스타일, 내용 제약 |
| Output Format | 결과 형식 (JSON, CSV, 마크다운 등) |
| Evaluation | 답변 품질 평가 기준 |
