02-원칙별-세부

02. 원칙별 세부

1) 명확성(Clarity)

Anthropic 가이드는 다음을 권한다.

• 원하는 출력 형식과 제약을 구체적으로 적는다.
• 순서가 중요한 절차는 번호 매김 또는 글머리표로 적는다.
• “above and beyond” 같은 모호한 기대는 명시적으로 요구한다.

“If you want ‘above and beyond’ behavior, explicitly request it rather than relying on the model to infer this from vague prompts.” — Prompting best practices, Anthropic

의역: “기대 이상의 결과를 원한다면 모호한 지시에 미루지 말고 명시적으로 요구하라.”

점검 질문

• 동사가 명확한가? (“좋게 만들어 줘”는 동사가 아니다)
• 출력 형식(JSON / 표 / 글머리표)이 지정되어 있는가
• 길이·톤·금지사항이 명시되어 있는가

2) 맥락(Context)

“Providing context or motivation behind your instructions, such as explaining to Claude why such behavior is important, can help Claude better understand your goals and deliver more targeted responses.” — Prompting best practices, Anthropic

의역: “지시 뒤의 맥락이나 동기를 설명하라. ‘왜 이렇게 해야 하는지’를 적으면 Claude가 목표를 더 잘 이해해 더 표적화된 응답을 준다.”

맥락에는 두 종류가 있다.

• Why-맥락: 이 작업을 왜 하는가, 누가 읽는가, 실패하면 무엇이 깨지는가
• What-맥락: 도메인 용어, 데이터 스키마, 기존 코드 컨벤션

Why-맥락은 “정렬(alignment)“을 만들고, What-맥락은 “환각(hallucination)“을 줄인다.

3) 예시(Examples / Few-shot)

“Examples are one of the most reliable ways to steer Claude’s output format, tone, and structure. A few well-crafted examples (known as few-shot or multishot prompting) can dramatically improve accuracy and consistency.” — Prompting best practices, Anthropic

의역: “예시는 출력 형식·톤·구조를 가장 안정적으로 조정하는 수단이다. 잘 만든 몇 개의 예시(few-shot, multishot)만으로도 정확도와 일관성이 극적으로 좋아진다.”

예시는 다음 세 가지를 만족해야 한다.

• 연관성(Relevance): 실제 사용 사례와 비슷할 것
• 다양성(Diversity): 모델이 우연한 패턴을 학습하지 않도록 변주
• 에지 케이스(Edge cases): 어려운 사례를 포함

자세한 메커니즘과 형식 강제는 본 파트 3장 예시(Few-shot)와 형식 강제 참조.

4) 구조(Structure)

Claude 가이드는 XML 태그를 통한 입력 분리를 권장한다. 지시·자료·예시·대화 기록이 시각적으로 분리되어 있어야 모델이 “지시”와 “자료”를 헷갈리지 않는다.

<instructions>
주어진 회의록을 3줄 요약하라.
</instructions>

<transcript>
... 실제 회의록 본문 ...
</transcript>

<format>
- 한국어 존댓말
- 각 줄 80자 이내
</format>

자세한 구조화는 본 파트 2장 시스템 프롬프트 vs 사용자 프롬프트 참조.

5) 평가 루프(Eval loop)

Anthropic의 입장은 단호하다.

“Not every success criteria or failing eval is best solved by prompt engineering.” — Prompt engineering overview, Anthropic

의역: “모든 성공 기준이나 실패 평가가 프롬프트 엔지니어링으로 가장 잘 풀리는 것은 아니다.”

이 말은 두 가지를 함의한다. (a) 먼저 평가가 있어야 한다, (b) 평가 결과가 모델 교체·도구 추가·맥락 보강으로 풀려야 할 문제를 프롬프트 튜닝에 떠넘기지 말라.

평가 루프 설계는 본 파트 5장 프롬프트 평가와 회귀 테스트에서 깊이 다룬다.