Quick Reference

좋은 prompt의 최소 단위는 역할 문구가 아니라 작업, input, 완료 조건, output 계약입니다. 먼저 누가 읽어도 실행할 수 있는 한 문장 목표를 쓰고, 필요한 source와 금지 범위, 통과 조건을 붙입니다. role, example, XML tag, chain은 결과가 실제로 흔들리는 지점이 있을 때만 추가합니다.

작업: 제공한 support request를 routing policy에 따라 분류한다.
input: <policy>와 <request>만 사실 근거로 사용한다.
완료: category, reason, missing_information을 JSON으로 반환한다.
제약: policy에 근거가 없으면 category를 추정하지 않는다.

기본 구조를 분리하는 법

한 문단에 역할·목표·참고 자료·예시·format을 뒤섞으면, output이 실패했을 때 고칠 위치를 찾기 어렵습니다. 아래 요소는 모두 필요할 수 있지만 모든 prompt에 다 넣을 필요는 없습니다. 단순 변환에는 task와 output format만으로 충분하고, source 기반 판단에는 evidence 범위와 fallback이 더 중요합니다.

<task>아래 원문을 초급 개발자용으로 요약한다.</task>
<success_criteria>정의, 한 가지 예시, 흔한 오해를 포함한다.</success_criteria>
<source id="draft">...</source>
<output_format>한국어 Markdown, 250자 이내</output_format>

개선 순서

prompt가 기대와 다를 때 바로 길이를 늘리지 않습니다. 먼저 failure를 하나의 observable signal로 적고, 그 signal을 가장 직접적으로 바꿀 요소를 선택합니다. prompt engineering overview가 전제하는 것도 성공 기준, 측정 방법, 초기 draft입니다. latency·cost·model 선택·retrieval·tool permission 문제를 instruction만으로 해결하려 하지 않습니다.

1. failure를 재현할 input을 저장한다.
2. 성공·실패를 판정할 check를 정한다.
3. task와 output contract부터 명확하게 고친다.
4. 필요할 때만 context, role, example, XML을 하나씩 추가한다.
5. holdout case에서 baseline과 비교한다.

자주 틀리는 부분

"전문가처럼 완벽하게" 같은 표현은 성공 조건이 아닙니다. 독자, source 범위, 허용할 불확실성, output shape, 확인할 test case를 적어야 결과를 개선할 수 있습니다.