프롬프트 설계 실전 가이드

프롬프트를 코드처럼 처리합니다. 구조를 부여하고, 버전을 지정하고, 평가합니다. 다음은 Starsg의 수십 가지 생산 경로에서 살아남은 6가지 사례입니다. 이러한 사례는 중요한 순서대로 바늘을 일관되게 움직였습니다.

1. 역할과 목표를 정하라

처음 한두 줄은 모델의 관점, 즉 누구인지, 누구를 위해 글을 쓰는지, 성공은 어떤 모습인지를 결정해야 합니다. 용어 밀도, 어조 및 포함할 내용에 대한 선택은 모두 해당 기준에서 벗어납니다. 나중에 "너무 장황하지 않게" 또는 "너무 학문적이지 않게" 모델을 다시 잡아당기는 것보다 훨씬 저렴합니다. 탄탄한 오프닝은 정체성, 청중, 목표라는 세 가지에 답합니다.

역할 설정 템플릿

귀하는 개발자 관계 엔지니어입니다.
대상: 백엔드 엔지니어는 HTTP API에 익숙하지만 LLM 및 토큰 기반 가격 책정은 처음입니다.
목표: 3분 안에 독자가 Starsg를 통합할 가치가 있는지 결정하고 다음 단계를 알려줍니다.
평범하지만 전문적인 톤을 사용하세요. 마케팅 허풍을 피하세요.

2. 작업을 명시적으로 작성하세요.

"제품 홍보문 작성"은 모든 결정을 모델에 전달합니다. 모든 실행은 추측입니다. 재사용 가능한 명령에는 동작(쓰기/요약/번역), 대상(무엇), 청중(누구를 위한), 어조/스타일, 길이 또는 모양 등 최소한 5가지 요소가 있습니다. 이를 철자하면 출력 안정성이 즉시 한 단계 높아집니다.

❌ 너무 모호함

제품 광고문을 작성해 주세요.

✅ 다섯 가지 요소 모두

백엔드 엔지니어를 위해 ~200 단어로 Starsg의 세 가지 차별화 요소(통합 게이트웨이, 키별 청구, 다중 모델 대체)를 소개합니다. 톤: 전문적이고 절제된 분위기. "empower" 또는 "next-gen"과 같은 단어는 사용하지 마세요. 하나의 구체적인 행동 촉구로 마무리하세요.

3. 맥락과 예시 제공(Few-shot)

요구 사항이 추상화될수록 더 많은 예제를 얻을 수 있습니다. 1~3개의 "입력 → 예상 출력" 쌍은 10줄의 설명 가치가 있습니다. Few-shot은 형식이 고정된 경우(분류, 추출, JSON), 스타일을 말로 설명하기 어려운 경우 또는 도메인에 고유한 규칙(법률, 의료, 내부 시스템)이 있는 경우 특히 결정적입니다. 쉬운 사례뿐만 아니라 실제 분포를 다루는 예제를 만드세요.

퓨샷 추출 예시

아래 지원 티켓 텍스트에서 «유형/범위/심각도»라는 세 가지 필드를 추출합니다. JSON만 출력합니다.

예 1:
입력: 사용자는 광저우 지역 전체에서 로그인 실패를 보고합니다. 전화 지원이 과부하되었습니다.
출력: {"type":"login","scope":"광저우 지역","severity":"P1"}

예 2:
입력: 테스트 계정에 잘못된 잔액이 표시됩니다. 내부 QA만 영향을 받습니다.
출력: {"type":"계정","scope":"내부 QA","severity":"P3"}

이제 다음을 처리합니다.
입력: 베이징 API 게이트웨이는 502를 반환합니다. 모든 유료 사용자가 영향을 받습니다.

4. 출력 형식 제한

다운스트림 시스템이 소비하는 모든 것은 구문 분석 가능해야 합니다. JSON? 스키마 및 필드 참고 사항을 제공합니다. 목록? 개수와 항목별 모양을 고정합니다. 길이 캡? 그렇게 말해보세요. "필드가 누락된 경우 null로 설정하세요. 발명하지 마세요"와 같은 절을 추가하면 환각이 눈에 띄게 줄어들 것입니다.

JSON 출력 제약

아래 이력서를 이 스키마와 정확히 일치하는 JSON로 변환합니다.
{
  "name": 문자열,
  "yearsOfExperience": 번호,
  "skills": string[], // 최대 5, 소문자
  "summary": 문자열 // <= 60 단어
}
소스에 필드가 언급되지 않은 경우 해당 필드를 null로 설정하세요. 새로 만들지 마세요. 주변 텍스트 없이 JSON만 출력합니다.

5. 복잡한 작업 분해(생각의 사슬 포함)

모델에게 한 번에 "분석 + 계획 + 생산"을 요청하면 일반적으로 세부 사항이 손실되거나 추론이 최종 답변으로 처리됩니다. 두 가지 옵션이 있습니다. 내부적으로 단계별로 생각하도록 하거나 작업을 여러 차례에 걸쳐 스스로 나누는 것입니다. 감사 가능한 워크플로의 경우 후자를 선호합니다. 나중에 어떤 단계가 실패했는지 정확히 찾아낼 수 있도록 모든 중간체를 보관하세요.

단계별 템플릿

제품 스펙을 알려드리겠습니다. 세 단계로 처리하고 각 단계를 ## 제목으로 구분합니다.

## 1. 주요정보
글머리 기호 목록: 대상 사용자, 핵심 시나리오, 필수 기능, 명시적으로 범위를 벗어나는 항목.

## 2. 위험과 불분명한 점
사양에 모호하거나 모순되는 내용을 각각 한 문장씩 나열하세요.

## 3. 다음 단계
PM에게 우선순위에 따라 구체적이고 실행 가능한 세 가지 다음 작업을 제공합니다.

사양:
<<<

>>>

6. 반복 및 평가

좋은 프롬프트는 작성되지 않고 반복됩니다. 고정 평가 세트를 구축합니다(일반 + 에지 + 적대를 포괄하는 20–50 사례). 모든 프롬프트 변경에 대해 이를 실행하고 적중률, 평균 길이 및 토큰 비용을 기록합니다. 코드와 같은 프롬프트 버전을 지정하세요. 모든 변경 사항에는 이유와 회귀 기준이 있으며 "이번에는 기분이 좋아질 것"이 아닙니다.