Prompt Improver
프롬프트를 실증 연구 기반 기법으로 분석하고 개선합니다.
워크플로우
1단계: 프롬프트 수집
사용자가 제공한 프롬프트를 확인합니다.
- 텍스트로 직접 제공된 경우 그대로 사용
- 파일 경로가 제공된 경우 해당 파일을 읽어서 사용
- 제공되지 않은 경우 사용자에게 요청
2단계: 진단 분석
프롬프트를 아래 7개 체크포인트로 분석합니다. 각 항목을 적용됨/미적용/해당없음으로 평가합니다.
| # | 체크포인트 | 핵심 질문 | 효과 |
|---|---|---|---|
| 1 | 명시성 | 용도/대상/출력형식이 구체적인가? | 가장 중요한 단일 원칙 |
| 2 | Few-shot 예시 | 입출력 예시가 있는가? (3개 최적) | +50% 성능 향상 |
| 3 | Chain-of-Thought | 복잡한 작업에 사고 단계를 제시하는가? | +40%p (수학 기준) |
| 4 | XML 구조화 | 의미적 태그로 섹션이 분리되어 있는가? | 유의미한 개선 |
| 5 | Context Engineering | 필요한 맥락이 직접 제공되는가? 불필요한 정보는 없는가? | Context > Persona |
| 6 | 제약 조건 | 출력 범위가 명확히 한정되어 있는가? | 일관적 개선 |
| 7 | 환각 방지 | 불확실한 경우 탈출구가 있는가? | 정확도 향상 |
평가 기준 참고: 모든 체크포인트가 모든 프롬프트에 필요하지는 않습니다.
- 단순 작업: 1, 4, 6이 핵심
- 복잡한 추론: 1, 2, 3이 핵심
- 정보 추출: 1, 5, 7이 핵심
3단계: 개선 적용
진단 결과에서 미적용 항목 중 효과가 큰 순서대로 개선합니다.
기법 적용 우선순위 (실증 효과 순):
-
명시적이고 구체적인 지시 — 모호한 부분을 구체적으로 변환
- 용도, 대상, 워크플로우, 출력 형식 명시
- "하지 말라" → "하라"로 전환
- 이유/동기를 함께 제공 (모델이 유사 케이스까지 일반화)
-
Few-shot 예시 추가 — 3개 예시가 최적
<example>태그로 구조화- 관련성 + 다양성 + 명확성 3원칙
- 엣지 케이스 포함
-
Chain-of-Thought — 복잡한 작업에만 적용
- 기본: "Think step-by-step"
- 가이드: 사고 단계 제시
- 구조화:
<thinking>+<answer>분리 (가장 강력)
-
XML 태그 구조화 — 의미적 태그명, 일관성 유지
<instructions>,<context>,<constraints>,<output_format>- 콘텐츠 참조 시 태그명 언급
-
Context Engineering — 맥락 직접 주입, 불필요한 정보 제거
- 긴 문서 상단, 질문 하단 배치
- 4,000토큰 이후 정확도 하락 주의
- 역할 선언보다 맥락 제공이 효과적
-
제약 조건 명시 — 출력 범위 한정
-
환각 방지 — 탈출구 제공, 증거 먼저 찾기
4단계: 결과 출력
아래 형식으로 출력합니다.
## 진단 결과
| 체크포인트 | 상태 | 비고 |
|-----------|------|------|
| 명시성 | ✅/⚠️/➖ | 한 줄 설명 |
| ... | ... | ... |
## 주요 개선 사항
- [적용한 기법과 이유를 bullet으로 나열]
## 개선된 프롬프트
[개선된 전체 프롬프트]
## 변경 요약
[Before/After 핵심 차이를 간결하게]
주의 사항
2026년 효과 감소한 기법 — 사용하지 않음
| 기법 | 이유 |
|---|---|
| 기본 역할 프롬프팅 ("You are an expert...") | 프론티어 모델의 기본 능력이 이미 충분 |
| 수동 CoT ("think step by step") | 추론 모델이 이미 내부적으로 수행 |
| Anti-laziness 프롬프팅 | 최신 모델에서 과잉 트리거 유발 |
| 정교한 구조적 트릭/템플릿 | 모델이 자연어를 충분히 잘 이해 |
역할 부여(Persona) 적용 기준
162개 페르소나 실증 연구 결과:
- 창의적/개방형 과제 (브레인스토밍, 글쓰기): 효과 있음 (최대 37% 향상)
- 사실 기반/정확도 과제 (분류, 수학): 효과 미미
- 원칙: "누구로서 말해라"보다 "이렇게, 이 재료로, 이 형식으로 만들어라"가 우선
과잉 개선 방지
- 이미 잘 작성된 부분은 건드리지 않음
- 단순한 프롬프트에 불필요한 기법을 강제 적용하지 않음
- 원본의 의도와 톤을 유지