구조화 출력으로 받은 JSON, 업무에 쓰기 전 확인할 것

오늘의 인사이트 요약

• JSON은 데이터를 표현하는 형식이고, 스키마는 항목과 자료형의 규칙입니다.

• 구조화 출력의 지원 범위와 중단·거절 예외는 제품마다 다릅니다.

• 형식 검증 뒤에도 원문 대조와 업무 규칙 검증이 남습니다.

AI가 만든 답을 다른 시스템에 넘기려면 일정한 응답 형식이 필요합니다. 사람이 읽기 편한 문장도 프로그램이 처리할 항목으로 나누기는 어렵기 때문입니다. 오늘은 구조화 출력의 뜻과 JSON 스키마의 역할, 실제 저장 전에 남겨 둘 검증을 알아보겠습니다.

1. 구조화 출력과 JSON은 무엇이 다를까?

구조화 출력은 AI가 정해진 항목과 자료형에 맞춰 답을 생성하도록 제한하는 방식입니다. JSON 문법이 맞는지, 약속한 항목을 지켰는지, 실제 업무에 써도 되는지는 서로 다른 질문입니다. 형식에 맞는 응답도 틀린 고객 번호나 잘못된 분류를 담을 수 있습니다.

JSON은 이름과 값을 짝지어 데이터를 표현하는 형식입니다. 가상의 고객 문의 분류 결과를 category와 summary라는 항목으로 나눌 수 있습니다. 중괄호와 따옴표 같은 문법이 맞으면 프로그램이 JSON을 읽을 수 있지만, 어떤 항목이 꼭 있어야 하는지는 JSON 문법만으로 정해지지 않습니다.

예를 들어 분류 결과에 category가 빠져도 문법상 올바른 JSON일 수 있습니다. 반대로 항목을 모두 넣었어도 괄호가 닫히지 않았다면 읽기부터 실패합니다. 파싱은 문자열을 데이터로 해석하는 일이며, 성공했다고 필요한 정보가 모두 있다는 뜻은 아닙니다.

프롬프트 요청과 출력 제약의 차이

프롬프트에 JSON으로 답하라고 적는 것과 API의 구조화 출력 기능을 쓰는 것은 구분합니다. 전자는 원하는 형식을 요청하는 방식이고, 후자는 제공자가 지원하는 스키마를 전달해 생성할 형식을 제한합니다. 제품 이름이 같아 보여도 적용하는 제약은 다를 수 있어 실제 동작을 살펴봅니다.

Claude의 구조화 출력은 스키마에 맞는 JSON 응답을 생성하도록 제한합니다. 다만 사용 가능한 스키마 기능과 예외가 있으므로 모든 요청에 같은 결과를 약속하는 기능으로 읽지는 않습니다. API 설정 방식과 지원 범위를 살펴보고 싶다면 Claude의 구조화 출력 문서를 참고해 보세요. JSON 요청 문구와 실제 API 옵션의 차이를 구분하는 데 도움이 됩니다.

2. JSON 스키마에는 무엇을 정할까?

JSON 스키마는 데이터가 갖춰야 할 항목과 자료형을 설명합니다. 문자열인지 숫자인지, 어떤 항목이 필수인지, 정해진 선택지 중 하나인지 등을 명시하는 식입니다. 가상의 문의 분류라면 category는 정해진 분류명, summary는 문자열처럼 정할 수 있습니다.

항목을 정의하는 것과 필수로 만드는 것은 다릅니다. 일반 JSON Schema에서 properties에 항목을 적었다고 자동으로 필수가 되지는 않으며, required로 필요한 항목을 지정합니다. 예상하지 못한 추가 항목을 허용할지도 별도 규칙입니다. 객체의 항목을 정하는 방법은 JSON Schema의 object 안내에서 예시와 함께 자세히 보실 수 있습니다.

값 없음과 항목 누락의 차이

원문에 정보가 없을 때 돌려줄 결과도 정합니다. 빈 문자열, null, 항목 누락은 프로그램이 다르게 처리할 수 있습니다. 미확인 상태를 표현할 자리가 없으면 찾지 못한 정보와 정상적으로 읽은 정보를 구분하기 어렵습니다. 필수 항목이라고 해서 알 수 없는 사실까지 만들어 채우게 해서는 안 됩니다.

지원하는 규칙은 사용할 모델과 API에서 다시 확인합니다. 일반 JSON Schema에 있는 기능이 모두 AI 출력 제약으로 지원되는 것은 아닙니다. 예를 들어 Claude 문서는 일부 수치 제약 등의 지원 제한을 안내합니다. 필요한 업무 제약을 출력 기능에만 맡길 수 있는지 확인하고, 지원하지 않는 규칙은 애플리케이션 검증으로 남깁니다.

3. 형식이 맞아도 무엇을 검증할까?

자료형이 맞는다는 것은 값이 사실이라는 뜻과 다릅니다. 고객 번호가 문자열이어도 실제 고객과 연결되지 않을 수 있고, 선택지에 있는 분류를 골랐어도 문의 내용과 맞지 않을 수 있습니다. 형식 오류와 내용 오류를 같은 성공률로 합치면 어떤 작업을 고쳐야 하는지 알기 어렵습니다.

검증은 사용할 업무에 맞춰 나눕니다. 문의 분류 예시라면 결과를 읽을 수 있는지, 정해진 항목을 지켰는지, 원문이 해당 분류를 뒷받침하는지 차례로 봅니다. 고객 번호를 기존 시스템에서 조회할 수 있는지나 담당 부서가 유효한지처럼 기존 데이터와 대조하는 작업도 별도로 둡니다.

응답이 완성되지 않은 경우의 처리

거절이나 출력 길이 제한으로 응답이 끝난 경우를 정상 완료와 구분합니다. Claude 문서는 거절 및 토큰 한도에 따른 중단에서 스키마에 맞지 않는 결과가 나올 수 있다고 안내합니다. 완료 상태를 먼저 확인하고, 온전하지 않은 결과를 억지로 저장하지 않도록 처리 경로를 정합니다.

검수용 예시에는 정상 문의뿐 아니라 분류가 모호한 문의, 필요한 정보가 없는 문의도 포함합니다. 자동 저장이 가능한 결과와 사람이 볼 결과를 나누고, 원문 식별자와 검증 결과를 함께 남기면 수정 이유를 추적하기 쉽습니다. 스키마나 분류 목록을 바꿀 때는 시스템이 이전 응답도 읽을 수 있는지 함께 확인합니다. 구조화 출력은 연동할 형식을 맞추는 데 쓰되, 업무를 확정하는 기준까지 대신하지는 않습니다.

업무 규칙과 AI 연동을 함께 설계합니다

똑똑한개발자는 업무 분석부터 시스템 구축과 운영 개선까지 연결해 AX 적용을 돕습니다. AI가 판단할 내용과 규칙·시스템이 확인할 조건을 나누고, 실제 업무 흐름에 맞춰 결과를 전달하는 방식을 설계합니다.

AI 응답을 기존 업무에 연결하고 검수·승인 범위까지 정하고 싶다면 아래 똑똑한개발자 링크로 문의해 주세요. 감사합니다.