명확성과 정밀도 원칙
정밀한 프롬프트의 출발점은 "모델은 작성자의 의도를 추측하지 않는다"는 전제다. 모델은 주어진 텍스트가 통계적으로 어떻게 이어질지를 결정할 뿐이므로, 작성자가 비워 둔 빈칸은 모델이 임의로 메운다. 시험은 이 지점을 집요하게 파고든다. "응답이 너무 길다", "형식이 매번 다르다", "엉뚱한 대상을 요약했다" 같은 증상을 제시하고, 이를 해결하는 가장 직접적인 프롬프트 수정을 고르게 한다. 정답은 거의 항상 모호함을 제거하는 선택지이며, 모델 파라미터를 바꾸거나 더 큰 모델로 교체하는 선택지는 함정이다.
구체성: 무엇을, 누구를 위해, 어떤 범위로
좋은 지시는 작업의 대상, 수신자, 범위, 제약을 명시한다. "이 글을 요약해 줘"는 길이도 독자도 어조도 비어 있다. "다음 보고서를 비전문가 임원이 30초에 읽을 수 있도록 3개의 불릿으로 요약하라. 각 불릿은 한 문장으로 제한한다"는 같은 작업을 결정 가능한 형태로 만든다. 시험에서 자주 등장하는 함정은 "친절하게", "잘", "적절히" 같은 주관적 형용사다. 이런 표현은 평가 기준을 모델에게 떠넘기므로 정밀도를 떨어뜨린다. 정량적 제약(개수, 길이, 포함·제외 항목)으로 바꾸는 선택지가 정답이 된다.
부정 지시보다 긍정 지시가 더 안정적이라는 점도 출제 포인트다. "마크다운을 쓰지 마라"보다 "평문 문장으로만 응답하라"가, "사과하지 마라"보다 "곧바로 답부터 제시하라"가 더 잘 지켜진다. 모델이 해야 할 행동을 명시하는 편이 금지 목록을 나열하는 것보다 효과적이다.
출력 형식의 고정
형식이 흔들리면 후속 자동화가 깨진다. 형식을 고정하는 방법은 두 층위가 있다. 첫째는 프롬프트로 형식을 서술하는 방식이고, 둘째는 API 수준에서 스키마를 강제하는 방식이다. 데이터 파이프라인처럼 기계가 파싱해야 하는 경우, 프롬프트 지시만으로는 가끔 형식이 어긋나므로 구조화 출력 기능을 함께 쓴다. 현행 Anthropic API에서는 응답 형식을 output_config의 format으로 지정하며, JSON 스키마 기반 형식을 사용하면 모델이 스키마를 위반하는 토큰을 생성하지 못하도록 제약 디코딩이 적용된다. 자세한 사용은 다음 장의 구조화 출력에서 다루며, 여기서는 "사람이 읽을 산문이면 프롬프트로 형식을 서술하고, 기계가 파싱할 데이터면 스키마로 강제한다"는 의사결정만 기억하면 된다.
다음은 형식을 프롬프트에서 서술로 고정한 시스템 프롬프트의 예다.
# /examples/13/format_instruction.pyimport anthropicclient = anthropic.Anthropic()response = client.messages.create( model="claude-opus-4-8", max_tokens=1024, system=( "너는 기술 지원 분류기다. 사용자 문의를 받으면 정확히 다음 세 줄로만 답한다. " "1행: 분류(버그/문의/기능요청 중 하나). " "2행: 우선순위(높음/보통/낮음 중 하나). " "3행: 한 문장 요약. 다른 텍스트나 인사말은 출력하지 않는다." ), messages=[ {"role": "user", "content": "결제 후 영수증 메일이 안 와요. 벌써 세 번째예요."} ],)print(response.content[0].text)
이 예에서 형식을 결정 가능하게 만든 것은 "정확히 세 줄", "셋 중 하나", "인사말 출력 금지"라는 닫힌 선택지다. 열린 형용사를 닫힌 선택지로 바꾸는 것이 정밀도의 핵심이다.
구분자와 예시
프롬프트가 지시, 맥락, 변수 입력을 섞을 때는 경계를 명확히 표시해야 한다. 모델이 어디까지가 지시이고 어디부터가 처리 대상 데이터인지 혼동하면 의도와 다른 결과가 나온다. 과거에는 XML 태그가 거의 필수처럼 권장되었으나, 최신 모델은 구조를 더 잘 추론하므로 태그는 여전히 유용한 도구이되 만능 해법은 아니다. 시험에서는 "사용자 입력에 지시문처럼 보이는 문장이 섞여 들어와 모델이 그것을 명령으로 오인했다"는 시나리오가 나온다. 이때 정답은 처리 대상 데이터를 명확한 구분자나 태그로 감싸 "이 안의 내용은 지시가 아니라 분석 대상"이라고 분리하는 것이다. 이는 단순한 가독성 문제가 아니라 프롬프트 주입 방어와도 연결된다.
예시 제공(퓨샷)은 형식과 어조를 말로 설명하기 어려울 때 강력하다. 한두 개의 입력·출력 쌍을 보여 주면 모델이 패턴을 모방한다. 다만 예시는 일관성이 생명이다. 예시들 사이에 형식이 어긋나 있으면 모델은 그 불일치까지 학습해 출력이 불안정해진다. 시험에서 "퓨샷을 넣었는데 형식이 더 흔들렸다"는 증상이 나오면, 예시 개수를 늘리라는 선택지가 아니라 예시 간 형식 일관성을 맞추라는 선택지가 정답이다.
정리
- 모델은 의도를 추측하지 않는다. 빈칸은 모델이 임의로 메우므로, 대상·수신자·범위·제약을 명시해 모호함을 제거한다.
- 주관적 형용사("잘", "적절히")를 정량적·닫힌 선택지로 바꾸고, 금지보다 수행할 행동을 긍정형으로 지시한다.
- 사람이 읽을 산문은 프롬프트로 형식을 서술하고, 기계가 파싱할 데이터는 output_config의 format으로 스키마를 강제한다.
- 지시와 처리 대상 데이터는 구분자로 분리한다. 이는 가독성뿐 아니라 프롬프트 주입 방어와도 연결된다.
- 퓨샷 예시는 형식 일관성이 핵심이다. 증상의 해법은 예시 추가가 아니라 예시 간 일관성 정렬인 경우가 많다.