구조화된 출력: AI 모델에서 예측 가능한 JSON 받기

AI 앱에 구조화된 출력이 필요한 이유는 무엇입니까?

AI 앱에는 구조화된 출력이 필요합니다. 소프트웨어는 친절하게 쓴 문단을 안정적으로 해석할 수 없으며, 매번 이름과 자료형이 동일한 필드를 받아야 하기 때문입니다. 문장 하나가 추가되거나 필드 하나가 빠져도 앱의 다음 단계가 제대로 작동하지 않을 수 있습니다.

직원 12명의 가상 물류 스타트업 파슬와이즈를 생각해 봅니다. 개발자 사나는 고객 이메일을 읽고 배송 변경 양식에 주문 번호, 요청 날짜, 새 주소, 환불 요청 여부를 입력하는 도구를 만들고 있습니다. 흔히 받는 이메일은 이렇습니다. '안녕하세요, 주문 PW-88213인데 목요일에는 집에 없어서요. 대신 토요일에 배송해 주실 수 있나요? 아니면 14번 집에 맡겨 주세요. 안 되면 그냥 취소하고 환불 부탁드립니다.' 첫 번째 버전에서는 모델에 'JSON으로 답변해 주세요'라고 지시합니다. 대부분의 응답은 파싱되지만, 일부는 '네, JSON은 다음과 같습니다'로 시작하고, 일부는 필드 이름을 'requested_date' 대신 'date'로 지정하며, 한 응답은 날짜를 '토요일'로 반환합니다.

JSON 스키마란 무엇이며 왜 도움이 됩니까?

JSON 스키마는 예상하는 데이터를 정형화해 설명한 것입니다. 어떤 필드가 있는지, 어떤 필드가 필수인지, 각 필드의 자료형은 무엇인지, 어떤 값이 허용되는지를 정의합니다. 모델에 스키마를 제공하면 'JSON으로 답변해 주세요'라는 요청이 코드로 검증할 수 있는 규약이 됩니다.

사나의 스키마는 다음과 같이 정합니다. order_reference는 필수 문자열입니다. requested_date는 필수 항목으로, 날짜 형식의 문자열이어야 하며 날짜가 주어지지 않았다면 null이어야 합니다. new_address는 문자열 또는 null입니다. refund_requested는 필수 불리언 값입니다. 그 밖의 필드는 허용하지 않습니다. 마지막 규칙은 모델이 설명용 필드를 추가하지 못하게 합니다.

모델 API는 구조화된 출력을 어떻게 지원합니까?

주요 모델 API에서는 요청에 JSON 스키마를 함께 전달할 수 있으며, 모델의 출력은 해당 스키마를 따르도록 제한됩니다.

검증과 재시도가 여전히 필요한 이유는 무엇입니까?

스키마는 데이터의 형식을 제어할 뿐 값의 정확성까지 보장하지 않으므로 검증이 여전히 필요합니다. 형식이 완벽한 응답에도 잘못된 날짜, 지어낸 주문 참조 번호, 고객이 요청하지 않은 환불 표시가 포함될 수 있습니다.

두 단계로 검증합니다. 먼저 스키마 라이브러리로 구조를 확인합니다. 예를 들어 Python의 Pydantic이나 JavaScript의 Zod를 사용할 수 있으며, OpenAI, Anthropic, Google 문서 모두 이에 대한 예시를 제공합니다. 다음으로 업무 규칙을 확인합니다. 주문 참조 번호가 정해진 형식에 맞고 시스템에 존재하는지, 날짜가 미래이면서 배송 가능한 날인지, 주소가 배송 가능 지역에 있는지 확인합니다. 제공업체가 문서에 명시한 예외 상황도 처리해야 합니다. 응답 거부 시에는 지정한 스키마를 따르지 않을 수 있으며, 최대 토큰 제한으로 응답이 잘리면 불완전한 JSON이 남습니다.

재시도는 신중하게 합니다. 검증에 실패하면 'requested_date는 날짜여야 합니다. 이메일에는 토요일이라고 되어 있고, 주문 날짜는 10월 14일입니다'처럼 구체적인 오류를 포함해 한 번 재시도합니다. 재시도는 한두 번으로 제한하고, 그다음에는 이메일을 사람에게 전달합니다.

미흡한 구조화 출력과 견고한 구조화 출력은 어떻게 다릅니까?

미흡한 예: 프롬프트에는 '세부 정보를 추출하고 JSON으로 답하세요.'라고만 적혀 있습니다. 앱은 반환된 내용을 그대로 읽습니다. 위 이메일의 경우 order와 date라는 필드, '토요일'이라는 날짜 값, true라는 환불 값을 받습니다. 모델이 '안 되면 그냥 취소해 주세요'를 확정적인 요청으로 해석했기 때문입니다. 양식이 잘못 입력되고 고객은 원하지 않은 환불을 받게 됩니다.

견고한 버전: 요청에 엄격 모드가 적용된 사나의 스키마를 포함하고, 프롬프트에서 '고객이 조건 없이 환불을 요청할 때만 refund_requested가 true입니다'라는 설명을 비롯해 각 필드를 설명합니다. 모델은 order_reference를 PW-88213으로, requested_date를 다음 토요일 날짜로, new_address를 null로, refund_requested를 false로 반환합니다. 사나가 바로 이런 경우를 위해 스키마에 추가한 conditional_request 필드는 '토요일 배송이나 이웃 수령이 불가능하면 환불'로 설정합니다. 검증을 통해 주문이 존재하고 토요일이 배송일임을 확인합니다. 이메일에 조건부 요청이 포함되어 있으므로 규칙에 따라 사람에게 전달해 최종 판단을 맡깁니다.

구조화된 출력에서 흔히 하는 실수는 무엇입니까?

가장 흔한 실수는 형식이 유효한 JSON을 정확한 데이터로 믿는 것입니다. 그 밖에도 API가 스키마 강제 적용 기능을 제공하는데 프롬프트 지시만 의존하거나, 설명 없이 모호한 필드명을 사용하거나, 사실에 맞는 답이 null인데도 값을 강제로 채우거나, 거부 응답과 잘린 응답을 무시하거나, 무엇이 잘못됐는지 모델에 알려 주지 않고 재시도하는 실수가 있습니다.

Tosheo.ai 교육 과정에서 구조화된 출력은 어디에 해당합니까?

구조화된 출력은 AI 앱 제작 카테고리의 AI 앱 만들기 과정에 포함된 코드 수업입니다. 스키마를 정의하고, API를 호출하고, 응답을 검증하고, 재시도를 추가하는 전체 코드 실습은 가입 후 코드 학습 경로에서 진행할 수 있으며, 각 단계에서 채점 기준에 따른 피드백을 받습니다.

출처와 범위

OpenAI API 문서, 구조화된 출력 가이드, JSON 모드 비교 및 응답 거부(19 October 2026 확인) ↗

Anthropic Claude 문서, 구조화된 출력 및 엄격한 도구 사용 (확인일: 19 October 2026) ↗

Google Gemini API 문서, 구조화된 출력 및 검증 지침 (19 October 2026 확인) ↗