08. 출력 형식 지정

왜 형식을 지정하나

같은 정보라도 어떤 모양으로 나오느냐에 따라 쓸모가 크게 달라집니다. 결과를 사람이 읽을 때는 표나 목록이 편하고, 다른 프로그램이 받아 처리할 때는 JSON 같은 정해진 구조가 필요합니다. 형식을 지정하지 않으면 2장의 확률성 때문에 매번 다른 모양으로 나와, 비교하거나 자동 처리하기 어렵습니다.

📌 핵심: 출력 형식 지정은 "결과를 어디에 쓸 것인가"에서 출발합니다. 읽을 사람·쓸 프로그램·비교할 방식을 먼저 정하면, 어떤 형식이 필요한지 자연히 따라 나옵니다.

형식 지정의 여러 수준

방법 1: 말로 형식을 기술한다

가장 간단합니다. 원하는 모양을 직접 서술합니다.

"장점과 단점을 각각 3개씩, 표로 정리해줘. 열은 [구분 | 항목 | 설명]."
"핵심을 불릿 5개 이하로, 각 한 문장."
"답을 [요약][근거][다음 행동] 세 부분으로 나눠서."

방법 2: 형식을 예시로 보여준다

7장에서 봤듯, 형식은 말보다 예시로 보여줄 때 더 정확히 전달됩니다. 특히 구조가 복잡할 때 효과적입니다.

"다음 형식으로 답해줘:

제목: <한 줄>
요약: <두 문장>
태그: <쉼표로 구분된 키워드 3개>"

방법 3: 출력의 시작을 직접 깔아준다 (prefilling)

2장의 "다음 토큰 예측"을 영리하게 쓰는 방법입니다. 답의 첫 부분을 직접 써주면, 모델이 그 형식을 이어받습니다. 한 가이드는 이를 "leading words(유도어)"라 부릅니다.

프롬프트: "이메일 주소를 검증하는 파이썬 함수를 써줘.

import re
def validate_email(email: str) -> bool:"

코드 블록의 시작을 직접 써주면, 모델은 그 스타일·시그니처를 이어 자연스럽게 함수를 완성합니다. 설명 없이 코드만 받고 싶을 때 특히 유용합니다.

💡 팁: prefilling은 "잡담 없이 바로 본론"을 끌어내는 데도 좋습니다. 답이 {로 시작하길 원하면 그것을 깔아주면, 모델이 "물론이죠! 아래는..." 같은 서두를 건너뛰고 바로 구조화된 출력을 내놓는 경향이 있습니다.

형식 강제 ≠ 내용 품질

가장 중요한 주의점입니다. 형식이 깔끔하다고 내용이 정확한 것은 아닙니다. 예쁜 표 안에 틀린 숫자가 들어 있을 수 있고, 완벽한 JSON 안에 환각된 사실이 담길 수 있습니다.

⚠️ 흔한 실수·미신: "구조화된 출력을 시키면 모델이 더 정확해진다"는 부분적으로만 참입니다. 형식 제약은 형식을 보장할 뿐 내용을 보장하지 않습니다. 오히려 지나치게 엄격한 형식이 모델의 추론 여지를 좁혀, 복잡한 작업에서는 품질을 떨어뜨릴 수 있다는 관찰도 있습니다. 형식과 정확성은 별개의 축으로 다루세요(정확성은 4부).

🧪 직접 검증법: 구조화 출력을 받으면, 형식이 맞는지(파싱되는지)와 내용이 맞는지(사실 검증)를 따로 점검하세요. 둘을 한 번에 "잘 나왔네"로 넘기면 예쁜 오답을 놓칩니다.

구조화 출력(JSON 등)을 신뢰성 있게

프로그램이 받아 처리할 출력은 형식이 조금만 틀어져도 깨집니다. 신뢰성을 높이는 방법들:

[신뢰성 높은 JSON 요청]
다음 후기를 분석해 아래 JSON 스키마로만 답해줘.
설명이나 코드펜스 없이 JSON 객체 하나만 출력해.

{
  "sentiment": "positive | negative | neutral",
  "score": 0.0 ~ 1.0 사이 숫자,
  "keywords": ["문자열", ...]
}

후기: "배송은 느렸지만 품질은 만족스러워요"

🔧 개발자 노트: 단순 JSON은 프롬프트로 형식을 지정해도 되지만, 복잡한 스키마를 반드시 지켜야 한다면 제공자의 구조화 출력(structured output) / JSON 모드 기능을 쓰는 편이 안전합니다. 이 기능들은 모델이 지정한 스키마를 벗어나지 않도록 디코딩 단계에서 강제하므로, 프롬프트만으로 부탁하는 것보다 파싱 실패가 적습니다. 한 제공자는 "복잡한 JSON 스키마는 프롬프트 대신 구조화 출력 기능을 쓰라"고 명시적으로 권합니다. 또한 시스템 프롬프트에서 출력을 파싱할 때는, 텍스트를 정규식으로 긁기보다 구조화된 데이터로 다루는 편이 안정적입니다.

형식과 분량·톤을 함께 정하기

출력 기대치에는 형식뿐 아니라 분량·톤도 포함됩니다(4장 속성 4). 함께 못박으면 재현성이 올라갑니다.

"요약: 3문장 이내, 중립적 톤, 전문용어 없이."
"답변: 200자 이내, 정중하지만 단호하게."

💡 팁: 앞서 여러 번 나왔듯, 기본적으로 간결하게 답하는 최신 모델이 많습니다. 표·목록 같은 구조화 출력을 원하면 명시적으로 요청하세요. 반대로, 사고 과정 없이 결론만 원하면 "설명 없이 결과만"을 명시해야 서두·해설을 줄일 수 있습니다.

마크다운 남용 주의

모델은 시키지 않아도 굵게·불릿·제목을 잔뜩 쓰는 경향이 있습니다. 일반 산문이 더 읽기 좋은 맥락(이메일, 에세이, 보고서 본문)에서는 오히려 가독성을 해칩니다.

⚠️ 흔한 실수·미신: "구조화 = 항상 좋음"이 아닙니다. 줄글로 흐르는 게 자연스러운 콘텐츠에 불릿과 굵게를 남발하면 산만해집니다. 형식은 내용의 성격에 맞춰야 합니다 — 비교·체크리스트·데이터엔 표·목록이, 서술·설득·설명엔 문단이 어울립니다. 필요하면 "불릿 없이 산문으로" 같은 지시로 형식을 적극 통제하세요.

이 장에서 배운 것

• 출력 형식 지정은 "결과를 어디에 쓸 것인가"에서 출발한다. 말로 기술, 예시로 시연, 출력 시작 prefill 세 가지 방법이 있다.
• prefilling은 다음 토큰 예측을 이용해 형식을 이어받게 하고, 불필요한 서두를 건너뛰게 한다.
• 형식 강제는 형식만 보장할 뿐 내용 정확성을 보장하지 않는다. 둘은 별개 축으로 따로 검증한다.
• 복잡한 JSON은 프롬프트보다 제공자의 구조화 출력 기능이 안전하다. 출력 파싱은 정규식보다 구조화 데이터로.
• 마크다운 남용은 가독성을 해친다. 형식은 내용 성격에 맞춰 적극 통제한다.

✍️ 확인 문제

1. "구조화된 출력을 시키면 모델이 더 똑똑해진다"는 주장의 어디가 맞고 어디가 틀린지 설명해보세요.

1. 다음 요청을 prefilling 기법으로 다시 써보세요. (서두 잡담 없이 코드만 받고 싶은 상황)

> "리스트를 정렬하는 자바스크립트 함수를 만들어줘. 설명은 필요 없어."

1. (실습) 회의록에서 액션 아이템을 뽑아 다른 프로그램에 넘기려 합니다. 신뢰성 높은 JSON 출력을 받기 위한 프롬프트를 작성하고, 이 장의 "신뢰성 높이기" 방법 중 어떤 것들을 적용했는지 표시해보세요.

다음 → 09. 단계적 사고 유도 (chain-of-thought)
이전 ← 07. 예시로 가르치기 · 목차