Quick Reference
모순 없는 prompt는 지시를 많이 쓰는 것이 아니라, 동시에 만족할 수 없는 조건의 우선순위와 fallback을 정하는 것입니다. 목표, 반드시 할 것, 금지, 예외, 완료 조건을 나누고 충돌하면 무엇을 포기하거나 누구에게 물을지 미리 적습니다.
| 충돌하는 요구 | 우선 정할 것 | 안전한 fallback |
|---|---|---|
| 짧게 쓰기 vs 모든 근거 포함 | 길이와 evidence 중 우선순위 | 핵심 claim만 답하고 누락 범위 보고 |
| 표 사용 vs 산문만 사용 | 최종 renderer와 독자 | 비교가 없으면 표를 생략 |
| 하나를 추천 vs 근거 부족 | 추천 기준과 최소 evidence | 추천 보류와 추가 질문 |
| 자동 실행 vs 사용자 승인 | action 대상과 권한 | read-only 결과 후 승인 요청 |
| 기존 규칙 vs 이번 예외 | 적용 범위와 효력 기간 | 이번 request에만 예외 적용 |
목표: 500자 안에 출시 위험을 요약한다.
필수: 근거가 있는 위험만 포함한다.
금지: source 없는 일정·수치를 추정하지 않는다.
충돌 우선순위: 정확성 > 근거 표기 > 분량 > 문체.
fallback: 근거가 부족하면 위험을 단정하지 말고 필요한 source를 적는다.조건을 나누는 법
한 문단에 목표·형식·금지·예외를 섞으면 사용자는 어떤 조건이 깨졌는지, 모델은 무엇을 우선해야 하는지 알기 어렵습니다. 각 block은 다른 질문을 답합니다. 특히 "하지 말 것"은 필요할 때만 쓰고, 허용되는 예외와 충돌 시 처리까지 같은 block에 둡니다.
| block | 답하는 질문 | 예시 |
|---|---|---|
| 목표 | 무엇을 만들거나 판단하는가 | PR의 release risk를 분류 |
| 필수 | 빠지면 실패인 항목은 무엇인가 | severity·evidence·next action |
| 금지 | 어떤 행동·형식을 피하는가 | source 없는 claim, 외부 write action |
| 예외 | 금지가 적용되지 않는 경우는 무엇인가 | 사용자가 명시 승인한 staging action |
| 우선순위 | 둘 다 못 지키면 무엇을 보존하는가 | 정확성 > 길이 |
| 완료 조건 | 어느 상태에서 멈추는가 | 모든 finding에 evidence가 있음 |
"자세하면서 3문장", "표로만 쓰되 문단만", "확실히 추천하되 추정하지 말 것" 같은 문장은 의도만으로 해석을 맡깁니다. 둘 다 필요한 이유가 있다면 output을 두 부분으로 분리하거나, 우선순위에 따라 보류를 허용합니다.
충돌을 테스트하는 법
prompt를 저장하기 전에 정상 input만 넣지 말고, 길이 제한을 넘는 source, 빈 input, 상충하는 요구, 권한 없는 action을 넣어 봅니다. model이 그럴듯하게 절충한 답을 내도 pass가 아닙니다. 미리 정한 fallback을 사용했는지와 금지된 claim·action이 없었는지를 검사합니다.
boundary case
- 500자 안에 source 10개를 모두 인용해야 함
-> 인용을 숨기지 말고 "요약 불가" 또는 분할 출력 규칙을 적용하는가?
- 최신 source와 과거 source의 결론이 다름
-> 더 최근의 authority 기준 또는 conflict 표시를 하는가?
- write action이 필요한데 승인 정보가 없음
-> 실행하지 않고 대상·승인자를 질문하는가?자주 틀리는 부분
우선순위 문장은 model의 동작을 돕지만 실제 보안 권한을 바꾸지 않습니다. external action은 tool permission, server authorization, 사용자 confirmation으로 막아야 합니다.
불필요한 금지 문장을 계속 덧붙이면 핵심 목표가 묻히고 조건끼리 새로 충돌합니다. failure가 재현되는 input과 pass/fail 조건을 기준으로 문장을 하나씩 고칩니다.
참고 링크
2 sources