[Dify] 프롬프트 작성법

프롬프트(Prompt)란?

• LLM이 응답을 생성할 때 기준으로 삼는 입력 지시문
• 구조·길이·지시 방식에 따라 모델의 출력 품질이 크게 변화
• 시스템 메시지, 유저 메시지, 예시(Few-shot), 제약 조건 등 여러 요소를 조합해 설계
• 명확하고 일관된 프롬프트는 모델의 추론 정확도·출력 안정성을 높임
• "LLM의 성능은 모델 자체보다 프롬프트 품질에 더 크게 의존한다"

---

1. 페르소나 프롬프트(Persona Prompt)

특징

• 모델에게 특정 역할, 직업, 말투, 전문성, 관점 등을 부여
• 응답의 방향성과 일관성을 크게 높임
• 모델이 "누구처럼" 생각하는지가 지정됨

사용 목적

• 전문 도메인 챗봇(법률, 의료, 기술, 고객센터 등)
• 특정한 말투·어조를 유지해야 하는 서비스
• 모델의 응답 범위를 한정하고 안정적으로 만들고 싶을 때

장점

• 출력의 스타일·톤·전문성이 일정하게 유지됨
• 모델이 불필요한 정보보다 “역할 중심”으로 사고
• 복잡한 서비스에서도 응답 품질이 안정적

주의사항

• 지나치게 많은 역할을 지정하면 혼란을 유발 가능
• 역할 기반 내용이 실제 사실처럼 보일 수 있으므로 책임 소재 주의
• 시스템 프롬프트에서 미리 명확하게 역할을 선언하는 것이 중요

예시

당신은 10년 경력의 드론 관제 전문가입니다.  
사용자의 비행 요청을 분석할 때는 GPS 안정성, 풍속, 비행고도 제한, 장애물 위험을 우선적으로 고려하세요.  
위험 요소가 있을 경우 반드시 경고 메시지를 포함해 설명하세요.

---

2. 가상 하이퍼파라미터(Virtual Hyperparameter)

특징

• 실제 언어모델의 내부 파라미터 변경은 아니지만,
  “출력 기준”을 텍스트로 명시해 모델이 준수하도록 만드는 기법
• 모델은 이러한 조건을 강한 제약으로 인식하고 출력 형태에 반영하려는 경향 존재

사용 목적

• 응답 길이·형식 제한
• 논리성 강화, 객관성 유지, 톤 조절
• JSON·표·목록 등 특정 포맷 강제 필요할 때
• 출력 내용의 품질·정확성을 관리할 때

장점

• 모델의 출력이 더 일관적이고 안정적
• 포맷 오류·중복 설명·불필요한 서술 감소
• 서비스 전체 품질 관리에 매우 유리

주의사항

• 지나치게 많은 제약 조건은 모델 성능을 저하시킬 수 있음
• 실제 하이퍼파라미터가 아니므로 “절대적” 효과는 아님
• 모델마다 제약 조건을 받아들이는 강도 차이가 존재

예시

아래 조건을 충족하는 형태로 드론 비행 계획을 생성하세요:
- 안전 기준 점수: 95 이상 유지
- 출력 포맷: JSON 형식만 사용
- 모든 좌표는 { "lat":…, "lon":… } 형태로 표기
- 비행 고도는 m 단위로 숫자만 작성
- 불확실한 값은 null 처리
- 응답 길이는 400자 이내로 제한

---

3. Few-Shot Prompt (Zero/One/Few Shot 포함)

특징

• 모델에게 예시를 제공하여 “문제 해결 방식의 패턴”을 학습시키는 기법
• 예시 수에 따라 Zero-shot / One-shot / Few-shot으로 분류
• 정해진 포맷을 반복적으로 출력해야 하는 작업에서 매우 효과적

사용 목적

• JSON 형태 출력
• 정형 데이터 생성
• 요약 형태 통일
• 분류·정리·패턴 기반 응답

장점

• 모델이 사용자의 의도한 "출력 규칙"을 직접 이해
• 복잡한 규칙을 말로 설명하기보다 예시가 훨씬 효과적
• 프롬프트 길이가 길어질수록 모델이 패턴을 더 ‘확실히’ 학습

주의사항

• 예시가 너무 많으면 비용 상승 및 혼란 발생
• 예시는 반드시 사용자가 원하는 최종 출력과 동일 포맷이어야 함
• 예시 간 불일치가 있으면 모델이 혼란스러워질 수 있음

예시

• Few-Shot — 드론 지식 패턴화

입력: "비행 전에 반드시 점검해야 하는 항목을 알려줘."
출력: ["배터리 상태 확인", "프로펠러 손상 여부 점검", "모터 회전 테스트"]

입력: "강풍에서 비행이 위험한 이유를 알려줘."
출력: ["기체 흔들림 증가", "위치 고정 실패", "추락 위험 상승"]

입력: "야간 비행을 위해 필요한 준비를 알려줘."
출력:

• One-Shot — 특정 포맷 학습

입력: "고도 50m로 이동하는 명령을 생성해줘."
출력: {"command":"goto","alt":50}

• Zero-Shot — 예시 없이 바로 추론

"드론이 GPS 신호를 잃었을 때 즉각 착륙해야 하는 이유를 설명하세요."

---

4. Chain of Thought(CoT, 생각의 사슬)

특징

• 모델이 문제 풀이 과정을 단계별로 서술하도록 유도하는 기법
• 단순 응답보다 “왜 이런 결론이 나왔는지”를 명확히 제시
• 복잡한 계산 및 논리 추론의 정확도가 크게 상승

사용 목적

• 수학 문제
• 논리적 판단
• 조건이 여러 개 있는 의사결정
• 비행 시간, 배터리 잔량, 경로 계산 등 다단계 계산이 필요한 경우

장점

• 문제 구조를 분해하여 모델이 더 정확하게 사고함
• 최종 결과의 신뢰도를 높이는 데 효과적
• 사용자가 reasoning을 검증할 수 있음

주의사항

• CoT는 모델에게 "과정"까지 서술하게 하므로 응답이 길어짐
• JSON 응답처럼 "결과만" 필요한 경우에는 CoT를 사용하면 오히려 불리
• 필요에 따라 “간단한 CoT” 또는 “결과만 출력”을 선택해야 함

예시

Q: 드론의 최대 비행 시간이 25분입니다.  
임무1은 6분, 임무2는 7분, 임무3은 10분이 소요됩니다.  
한 번의 비행으로 모든 임무를 수행할 수 있는지 계산하세요.

A:
- 임무1: 6분 → 누적 6분
- 임무2: 7분 → 누적 13분
- 임무3: 10분 → 누적 23분
총 비행 시간은 23분이므로 25분 이내에서 수행 가능합니다.

답: 한 번에 수행할 수 있습니다.

---

5. 마크다운(Markdown)

특징

• 모델이 가장 익숙하게 학습해온 문서 구조
• 제목, 리스트, 코드, 표 등 구조화된 형태를 정확하게 이해함
• 구조적 프롬프트와 구조적 출력 모두에 강함

사용 목적

• 문서 요약
• 보고서 생성
• 체크리스트, 단계 설명, 정리 문서 작성
• 블로그·노션 등과의 호환성 필요할 때

장점

• 가독성이 매우 뛰어남
• 모델이 구조를 재현하기 쉬움
• 긴 문서를 분리·구조화하여 응답 품질 향상

주의사항

• 지나치게 복잡한 Markdown 구조는 오히려 혼란을 유발할 수 있음
• 들여쓰기·리스트 등은 반드시 일관되게 작성해야 모델이 그대로 재현 가능

문법 정리

• 텍스트 강조

  • 굵게: **텍스트**
  • 기울임: *텍스트*
  • 취소선: ~~텍스트~~

• 제목(Headings)

  • # 가장 큰 제목
  • ## 중간 제목
  • ### 작은 제목

• 리스트(List)

  • 순서 있는 목록: 1. 항목
  • 순서 없는 목록: - 항목, * 항목

• 코드(Code)

  • 인라인 코드:

           `코드 내용`

  • 코드블록:

        ```
        코드 내용
        ```

테이블(Table)

| 항목 | 설명 |
|------|------|
| A | 내용 |
| B | 내용 |

구분선

• --

링크(Link)

• [텍스트](URL)

인용문(Blockquote)

• > 인용 내용

체크박스(Checklist)

• - [ ] 미완료 항목
• - [x] 완료 항목

예시

# 드론 비행 전 점검 체크리스트

## 1. 기본 점검
- 배터리 잔량: **80% 이상**
- 프로펠러 상태: *균열 또는 휘어짐 여부 확인*
- GPS 수신: **정상**인지 확인
- 기체 기울기 센서: 재보정 필요 시 안내에 따라 수행

## 2. 안전 관련 점검
- [ ] 비행 구역 내 장애물 확인
- [ ] 바람 세기 8m/s 이하인지 확인
- [ ] 비행 가능 고도 제한 확인
- [x] 조종기 연결 안정성 테스트 완료

---
## 3. 비행 경로 정보
| 항목 | 값 |
|------|----------------|
| 임무 유형 | 지그재그 스캔 |
| 반복 횟수 | 4회 |
| 반경 | 30m |
| 목표 고도 | 50m |

---
## 4. 비행 중 체크사항
- 모터 진동이 감지되면 즉시 고도를 낮추고 안정화
- GPS 신호 약화 시 자동 귀환(RTL) 기능 활성화
- ~~기상 악화에도 비행을 지속~~ → **즉시 착륙 권장**

---
## 5. 참고 정보
> 모든 비행은 사전 승인된 구역에서만 수행해야 하며,
> 예상 비행 시간이 배터리 지속시간의 70% 이하일 때만 진행을 권장합니다.

---
## 6. 비행 명령(JSON)
{
"command": "takeoff",
"alt": 50
}

---

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

특징

• 모델이 어떤 역할, 말투, 규칙을 따르는지 정의하는 “최상위 지침”
• Dify의 시스템 메시지 영역에 입력되는 프롬프트
• 모델의 전체적인 응답 방향성과 스타일을 결정함

사용 목적

• 챗봇의 성격 정의
• 전문성 수준 고정
• 출력 형식 강제
• 서비스 정책·안전 기준 적용

장점

• 일관된 응답 스타일 유지
• 유저 프롬프트의 변동성과 무관하게 안정적인 성격 유지
• 서비스 품질을 처음부터 끝까지 통제 가능

주의사항

• 시스템 프롬프트가 너무 길면 전체 비용 증가
• 명확·단정·일관되게 작성해야 효과가 극대화됨

예시

당신은 드론 자동 비행 계획 생성기입니다.  
모든 응답은 JSON 형식으로만 출력해야 하며 설명 문장은 포함하지 않습니다.  
비행 경로를 계산할 때는 현재 좌표를 기준으로 고도, 거리, 방향을 정확하게 산출하세요.  
안전 기준을 위반하는 요청은 허용하지 않고, 반드시 대안을 제시하세요.

---

7. 유저 프롬프트(User Prompt)

특징

• 사용자가 직접 입력하는 질문·명령
• 구체적인 요구를 전달하는 부분
• 시스템 프롬프트의 규칙 아래에서 작동

사용 목적

• 모델에게 실제 작업 요청
• 다양한 입력 상황 처리
• 사용자의 의도를 직접 전달

장점

• 자연스러운 대화 흐름 유지
• 사용자의 맥락을 기반으로 적절한 응답 생성

주의사항

• 너무 모호한 입력은 모델의 성능을 저하시킬 수 있음
• 요청이 많을 경우 분리해 전달하는 것이 효과적

예시

반경 40m 기준으로 4회 반복하는 지그재그 비행 경로를 생성해줘.  
출력은 JSON으로 해줘.

---

+) 시스템 프롬프트 + 유저 프롬프트 관계

특징

• 두 프롬프트는 결합되어 모델에 함께 전달됨
• 시스템: "어떻게 사고하고 응답해야 하는가"를 정의
• 유저: "무엇을 해야 하는가"를 요청

사용 목적

• 응답 품질의 일관성 확보
• 서비스 정책 및 응답 기준 유지
• 챗봇 성격과 실제 대화 흐름을 동시에 유지

장점

• 언제 어떤 입력이 오더라도 기본 규칙이 흔들리지 않음
• 서비스를 만드는 입장에서 품질 관리가 쉬움

주의사항

• 시스템 프롬프트가 불명확하면 전체 응답 품질이 흔들림
• 유저 프롬프트가 복잡할 때는 시스템에서 기본 규칙을 더 명확히 적어야 함