원하는 출력 형식을 끌어내는 프롬프트

Design Applications 영역의 첫 출제 목표는 「원하는 형식의 응답을 끌어내는 프롬프트를 설계한다」입니다. 시험에서 이 목표는 프롬프트 잘 쓰기 일반론이 아니라 정해진 모양의 출력을 안정적으로 받아 내는 문제로 나옵니다. 뒤에 오는 애플리케이션이 그 출력을 파싱해서 쓰기 때문입니다 — 응답이 그럴듯하지만 형식이 흔들리면 체인 전체가 멈춥니다. 문항은 「이 프롬프트에서 빠진 것은」·「JSON이 가끔 깨지는데 다음으로 할 일은」처럼 나옵니다.

프롬프트를 이루는 네 조각

프롬프트는 통째로 쓰는 글이 아니라 역할이 다른 조각의 조립입니다. 넷으로 갈라 놓으면 무엇이 빠졌는지가 눈에 보입니다.

RAG에서는 검색해 온 청크가 컨텍스트 자리에 들어갑니다. 「검색 결과를 프롬프트 어디에 넣는가」라는 물음이 이 표의 두 번째 줄을 가리킵니다.

문항이 프롬프트 예시를 보여 주고 「빠진 것은」이라고 물으면 네 조각을 순서대로 짚습니다. 실무에서 가장 자주 빠지는 것이 마지막 줄이고, 시험도 그 자리를 가장 자주 냅니다.

구분자와 역할 지정

구분자(delimiter)는 프롬프트 안에서 자료와 지시를 갈라 주는 표시입니다. 세 겹 백틱, <document> 같은 태그, ### 줄이 흔히 쓰입니다.

아래 <문서> 안의 내용만 근거로 답하십시오.

<문서>
{{context}}
</문서>

질문: {{question}}

구분자가 필요한 이유가 둘입니다. 첫째, 모델이 어디까지가 자료이고 어디부터가 지시인지 헷갈리지 않습니다. 둘째, 자료 안에 「앞의 지시를 무시하라」 같은 문장이 섞여 들어와도 그것이 지시가 아니라 인용된 자료임을 표시해 둘 수 있습니다. 뒤쪽 효과가 프롬프트 인젝션 방어의 첫 겹이고, 거버넌스 영역에서 다시 나옵니다.

역할 지정(role)은 메시지를 system·user·assistant로 나눠 보내는 것입니다. 요청마다 바뀌지 않는 규칙 — 말투, 금지 사항, 출력 형식 — 은 system에 두고, 그 요청에서만 달라지는 질문과 검색 결과는 user에 둡니다. 형식 지시를 매번 user 메시지 끝에 붙이는 구성은 대화가 길어질수록 흔들립니다.

few-shot 예시는 형식을 보여 주는 자리다

예시를 하나도 안 주면 zero-shot, 하나면 one-shot, 둘 이상이면 few-shot입니다. 시험이 확인하는 것은 개수가 아니라 예시를 무엇에 쓰는가입니다.

예시의 첫째 일은 형식을 말이 아니라 모양으로 보여 주는 것입니다. 「JSON으로 답하세요」라고 적는 것보다 실제 JSON 한 덩어리를 보여 주는 쪽이 훨씬 잘 듣습니다. 둘째 일은 경계를 알려 주는 것입니다 — 판단이 애매한 입력을 어떻게 처리했는지 예시로 한 줄 넣어 두면 그 규칙이 말보다 정확하게 전달됩니다.

예시를 넣을 때 지키는 것 셋입니다.

1. 예시들끼리 키 이름과 값 형태를 완전히 똑같이 맞춥니다. 예시가 서로 다르면 모델은 그 차이도 배웁니다.
2. 정상 사례만 넣지 말고 분류 불가·근거 없음 같은 경계 사례를 하나 섞습니다.
3. 예시가 길면 컨텍스트를 잡아먹으므로 셋에서 다섯을 넘기지 않습니다.

JSON을 스키마로 못 박기

프롬프트로 형식을 부탁하는 것과 API가 형식을 강제하는 것은 다릅니다. 시험은 이 둘을 가르는 문항을 냅니다.

먼저 프롬프트 쪽에서 할 수 있는 것은 키 이름·타입·필수 여부를 글로 적고 예시를 하나 붙이는 것까지입니다.

다음 JSON 하나만 출력하십시오. 설명·머리말·코드펜스를 붙이지 마십시오.
{"category": "환불|배송|계정|기타", "urgency": 1~5 정수, "summary": "40자 이내"}

그다음이 response_format 입니다. Databricks Foundation Model API는 OpenAI 호환 인터페이스를 쓰므로 요청에 이 인자를 넣어 출력 모양 자체를 제약할 수 있습니다. {"type": "json_object"}는 「JSON이기만 하면 된다」이고, {"type": "json_schema", ...}는 키와 타입까지 스키마로 못 박습니다. 어느 쪽을 고르느냐를 묻는 문항이 나오면, 파싱할 키가 정해져 있는 상황에서는 뒤쪽이 답입니다.

from openai import OpenAI

client = OpenAI(api_key=DATABRICKS_TOKEN, base_url=f"{WORKSPACE_URL}/serving-endpoints")

schema = {
    "type": "object",
    "properties": {
        "category": {"type": "string", "enum": ["환불", "배송", "계정", "기타"]},
        "urgency": {"type": "integer"},
        "summary": {"type": "string"},
    },
    "required": ["category", "urgency", "summary"],
    "additionalProperties": False,
}

response = client.chat.completions.create(
    model="databricks-llama-4-maverick",
    messages=[
        {"role": "system", "content": "고객 문의를 분류합니다. JSON만 출력합니다."},
        {"role": "user", "content": ticket_text},
    ],
    response_format={
        "type": "json_schema",
        "json_schema": {"name": "ticket", "schema": schema, "strict": True},
    },
    temperature=0,
)

enum으로 값의 후보까지 묶어 두면 카테고리가 새로 생겨나는 일이 줄고, additionalProperties: False는 안 시킨 키가 붙는 것을 막습니다. 다만 이 기능은 모델과 엔드포인트가 받쳐 줄 때만 쓸 수 있으므로, 외부 모델을 감싼 엔드포인트나 지원하지 않는 모델에서는 프롬프트 쪽 방법으로 돌아가야 합니다.

형식이 깨질 때 고치는 순서

「JSON이 스무 번에 한 번 깨진다」는 시나리오가 이 목표의 대표 문항입니다. 답은 정해진 순서를 밟는 것이고, 싼 것부터 비싼 것으로 갑니다.

1. 출력 형식 지시가 프롬프트에 있는가. 없으면 먼저 적습니다. 「설명을 붙이지 말라」·「코드펜스를 붙이지 말라」까지 못 박습니다.
2. 예시를 하나 넣는다. 원하는 모양의 완성된 출력 한 덩어리가 가장 잘 듣습니다.
3. response_format으로 스키마를 건다. 여기까지 오면 형식 위반은 대부분 사라집니다.
4. temperature를 낮춘다. 형식이 목적인 작업에서 무작위성은 이득이 없습니다.
5. 파서 쪽에서 받아 낸다. 앞뒤 군더더기를 벗기고, 실패하면 오류 메시지를 붙여 한 번 다시 물어봅니다.
6. 여기까지도 안 되면 그때 모델을 바꾸거나 파인튜닝을 검토합니다.

순서가 곧 답입니다. 문항이 「형식이 가끔 깨진다. 다음으로 할 일은」이라고 물으면 아직 안 한 것 중 가장 싼 것을 고릅니다. 예시도 안 넣은 상태에서 파인튜닝을 고르는 보기가 늘 섞여 있고, 그것이 오답입니다.

연습 문제

1. 다음 프롬프트에서 빠진 조각은?
   「아래 문서를 참고해 사용자 질문에 답하십시오. 문서: {{context}} 질문: {{question}}」
   ① 지시
   ② 컨텍스트
   ③ 출력 형식
   ④ 질문

   ③. 지시·컨텍스트·질문은 있지만 결과를 어떤 모양으로 내라는 말이 없습니다. 뒤에서 파싱해야 한다면 여기가 먼저 무너집니다.
2. 시스템 메시지에 두는 것이 알맞은 내용을 둘 고르시오.
   ① 이번 요청의 사용자 질문
   ② 검색해 온 청크
   ③ 항상 지켜야 하는 출력 형식 규칙
   ④ 답변 말투와 금지 사항
   ⑤ 이번 요청의 첨부 파일 내용

   ③과 ④. 요청마다 바뀌지 않는 규칙이 시스템 자리입니다. ①②⑤는 그 요청에서만 달라지므로 사용자 메시지에 넣습니다.
3. 파싱할 키가 category·urgency·summary로 정해져 있고 값이 반드시 그 셋이어야 합니다. 가장 알맞은 설정은?
   ① response_format={"type": "text"}
   ② response_format={"type": "json_object"}
   ③ response_format={"type": "json_schema", ...}에 required와 additionalProperties: False
   ④ 프롬프트에 「JSON으로 답하세요」만 적는다

   ③. ②는 JSON이라는 것만 보장하고 키 구성은 보장하지 않습니다. 키와 타입이 정해져 있으면 스키마로 못 박는 쪽입니다.
4. few-shot 예시를 넣는 목적으로 가장 알맞은 것은?
   ① 컨텍스트 길이를 채워 모델을 집중시킨다
   ② 원하는 출력의 모양과 경계 사례 처리 방식을 보여 준다
   ③ 모델의 가중치를 예시에 맞게 갱신한다
   ④ 검색 단계를 대신한다

   ②. 예시는 형식을 말이 아니라 모양으로 전달하는 자리입니다. ③은 파인튜닝의 설명이고, 예시를 넣는 것은 가중치를 건드리지 않습니다.
5. 형식이 가끔 깨지는 상황에서 프롬프트에 출력 형식을 적어 두었고 예시도 하나 넣었습니다. 지원되는 모델을 쓰고 있습니다. 다음으로 할 일로 가장 알맞은 것은?
   ① 같은 계열의 더 큰 모델로 바꾼다
   ② 파인튜닝용 데이터셋을 모은다
   ③ response_format으로 JSON 스키마를 건다
   ④ 검색 결과 청크 수를 늘린다

   ③. 순서는 싼 것부터입니다. 프롬프트와 예시 다음이 스키마 강제이고, 모델 교체나 파인튜닝은 그 뒤입니다. ④는 형식이 아니라 근거의 문제를 다루는 처방입니다.
6. 프롬프트에서 자료를 <문서> 태그로 감싸는 이유를 둘 고르시오.
   ① 자료와 지시의 경계를 분명히 한다
   ② 자료 안에 섞인 지시문이 명령으로 읽히는 것을 줄인다
   ③ 토큰 수를 줄인다
   ④ 임베딩 품질을 높인다
   ⑤ 모델의 최대 컨텍스트를 늘린다

   ①과 ②. 구분자는 경계 표시이자 인젝션 방어의 첫 겹입니다. 태그를 붙이면 토큰은 오히려 조금 늘고, 임베딩이나 컨텍스트 한도와는 무관합니다.
7. 예시를 셋 넣었는데 각각 키 이름이 label·category·type으로 조금씩 다릅니다. 예상되는 결과는?
   ① 모델이 셋 중 가장 짧은 이름을 고른다
   ② 출력의 키 이름이 요청마다 흔들린다
   ③ 스키마 검증이 자동으로 통일해 준다
   ④ 예시가 무시된다

   ②. 예시들 사이의 차이도 함께 학습되므로 형식을 보여 주려면 예시끼리 완전히 같아야 합니다.
8. 분류 결과에 「판단 불가」가 필요한데 모델이 늘 넷 중 하나를 억지로 고릅니다. 가장 알맞은 처방은?
   ① temperature를 올린다
   ② 판단 불가로 처리한 예시를 하나 넣고 enum에 그 값을 더한다
   ③ 검색 청크를 줄인다
   ④ 출력 형식을 문장으로 바꾼다

   ②. 경계 사례는 예시로 보여 주고 값 후보에 명시하는 것이 가장 확실합니다. ①은 형식과 일관성을 함께 흔듭니다.

여덟 문항을 관통하는 판단은 하나입니다. 형식은 부탁이 아니라 제약으로 걸 때 지켜집니다. 프롬프트에 적는 것에서 시작해 예시로 보여 주고 스키마로 못 박는 세 단계가 있고, 시험은 지금 어느 단계에 있는지를 읽어 다음 한 칸을 고르게 합니다.