정형 출력

정형 출력은 LLM의 응답을 자유로운 문장 대신 미리 정한 스키마, 보통 필드와 타입이 정해진 JSON에 맞추도록 강제하는 기능이다. 프로그램이 문단을 안정적으로 파싱할 수 없기 때문에 생겼다. 이 기능이 없던 시절에는 답변에서 값을 뽑아내려고 취약한 정규식을 쓰고, 모델이 앞말을 덧붙이거나 코드 펜스를 넣거나 없던 필드를 추가할 때마다 재시도해야 했다. 스키마를 강제하면 생성 단계에서 형식이 제약되어 첫 시도에 그대로 파싱된다. OpenAI는 JSON Schema 기반 Structured Outputs로, Anthropic과 Google은 도구·함수 정의를 통해 같은 결과를 낸다. Zod와 Pydantic, Instructor 같은 라이브러리를 쓰면 형태를 한 번 선언해 두고 응답을 검증할 수 있다. 청구서에서 항목을 추출하거나 문의를 고정된 범주로 분류하거나 애플리케이션이 호출할 함수의 인자를 받아 오는 데 주로 쓴다. 함정은 형식이 맞는 것과 내용이 맞는 것을 혼동하는 것이다. 스키마는 모양만 보장할 뿐 사실을 보장하지 않아서, 틀린 값도 형식은 완벽하게 들어온다. 스키마가 지나치게 깊거나 모호하면 품질이 떨어지므로 평평하고 이름이 분명한 구조가 낫다.

Structured Output is a language model capability that forces the response to conform to a predefined schema, such as JSON matching a specific set of fields and types, instead of free-form prose. It exists because software cannot reliably parse a paragraph. Without it, developers wrote fragile regular expressions to pull values out of an answer and retried whenever the model added a preamble, a code fence, or an extra field. With schema enforcement, the model is constrained during generation so the output parses on the first attempt. OpenAI ships this as Structured Outputs backed by JSON Schema, Anthropic and Google reach the same result through tool and function definitions, and libraries such as Zod, Pydantic, and Instructor let a developer declare the shape once and validate the response against it. Typical uses are extracting fields from an invoice, classifying a support ticket into fixed categories, and returning arguments for a function the application will call. The pitfall is confusing valid with correct: the schema guarantees the shape, never the facts, so a confidently wrong value still arrives well-formed. Overly deep or ambiguous schemas also degrade quality, and flat, clearly named fields work better.