빠른 비교
| 방법 | 효과 | 한계 |
|---|---|---|
| 출력 형식 명시 | 가장 기본 | 세부 형식이 흔들릴 수 있음 |
| 예시 제공 | 패턴 학습에 강함 | 예시 밖 edge case 약함 |
| assistant prefill | 시작 문구를 고정 | 모델별 지원 여부 확인 필요 |
| retrieval 고정 | 답변 근거 일관성 | 자료 품질에 의존 |
| structured outputs | schema 준수에 강함 | API와 schema 설계 필요 |
User:
Extract a compact JSON summary from the text.
Assistant prefill:
{형식 안정화
output format은 먼저 명시적으로 적는다
출력 일관성의 출발점은 원하는 형식을 구체적으로 쓰는 것입니다. "간단히 정리해 줘"보다 필드 이름, 순서, 값의 범위, 비어 있을 때 처리 방식을 적는 편이 안정적입니다.
Return only these fields:
- title: string
- risk: low | medium | high
- evidence: short quoted phrase or null형식 요구가 약하면 Claude는 자연스러운 문장, 설명, 단서 문구를 덧붙일 수 있습니다. 사람이 읽는 보고서라면 괜찮지만, 파서가 읽는 출력에는 위험합니다.
prefill은 시작점을 고정하는 장치다
assistant prefill은 Claude의 응답이 특정 문자나 구조로 시작하도록 유도합니다. 예를 들어 JSON을 원할 때 assistant turn을 {로 시작하게 하면 친절한 도입 문장을 줄이고 구조 출력으로 바로 들어가게 만들 수 있습니다.
prefill 후보
- "{"
- "<answer>"
- "Result:"다만 prefill은 모든 모델과 상황에서 지원되는 보편 기능으로 보면 안 됩니다. 공식 문서도 최신 일부 모델에서는 prefill 대신 structured outputs나 system 지시를 쓰는 방향을 안내합니다. schema 준수가 필요한 작업이면 prefill을 주력 장치로 두지 않는 편이 안전합니다.
예시는 추상 지시보다 강하지만 범위를 좁힌다
예시는 Claude가 원하는 톤과 구조를 빠르게 파악하게 합니다. 하지만 예시가 너무 좁으면 새 입력의 예외 상황을 억지로 예시에 맞추려는 출력이 나올 수 있습니다. 예시는 정상 사례, 빈 값 사례, 애매한 사례를 함께 두는 편이 좋습니다.
Example cases:
1. all fields present
2. evidence missing
3. multiple risks found선택 기준
| 상황 | 우선 선택 |
|---|---|
| 일반 보고서 형식 통일 | 출력 형식 명시 + 예시 |
| JSON처럼 시작 문구가 중요함 | prefill 지원 여부 확인 |
| API 파싱이 필수 | structured outputs |
| 같은 지식 기준을 유지해야 함 | retrieval 또는 고정 context |
| 복잡한 작업에서 결과가 흔들림 | prompt chaining |
주의할 점
prefill은 형식 안정화 도구이지 schema validation이 아닙니다. 모델 지원 여부와 기능 호환성이 바뀔 수 있으므로, 파싱 실패가 장애로 이어지는 작업은 structured outputs와 후처리 검증을 기준으로 설계해야 합니다.
출력 형식 지시가 길어질수록 작업 지시와 충돌할 수 있습니다. 형식 요구, 판단 기준, 입력 자료를 XML tag나 별도 섹션으로 분리하면 무엇이 출력 계약인지 더 명확해집니다.
참고 링크
2 sources