JSON Schema란? AI 답변 형식을 정하는 데이터 설계도

TL;DR

JSON Schema는 JSON 데이터가 어떤 필드, 타입, 필수값, 허용 범위를 가져야 하는지 정의하는 규칙 문서입니다.

AI 개발에서는 모델에게 "그냥 JSON으로 답해줘"라고 말하는 수준을 넘어, 정해진 스키마에 맞는 결과를 받기 위해 JSON Schema를 자주 씁니다.

초보자는 JSON Schema를 "AI 답변을 다음 자동화 단계가 읽을 수 있게 만드는 입력 양식"으로 이해하면 쉽습니다.

핵심 3줄 요약

• 핵심 1
  JSON Schema는 JSON 데이터의 구조와 제약 조건을 선언하는 표준입니다.
• 핵심 2
  챗GPT, 제미나이, 클로드 같은 AI를 API나 자동화에 붙일 때 출력 형식을 안정적으로 맞추는 데 쓰입니다.
• 핵심 3
  JSON Schema가 있어도 내용의 사실성까지 보장되지는 않으므로, 형식 검증과 사실 검증은 따로 봐야 합니다.

이 글에서 다룰 내용

한 문장 정의

JSON Schema는 JSON 데이터가 가져야 할 필드 이름, 데이터 타입, 필수 항목, 허용값 같은 규칙을 선언해 데이터 형식을 검증하고 문서화하는 표준입니다.

쉽게 말하면 주문서 양식과 비슷합니다. 이름 칸에는 문자열, 수량 칸에는 숫자, 상태 칸에는 "pending", "paid", "shipped" 같은 정해진 값만 들어가야 한다고 미리 정해두는 방식입니다.

JSON Schema 공식 문서는 JSON Schema를 JSON 데이터의 구조와 제약을 정의하는 선언형 언어라고 설명합니다. OpenAI와 Google Gemini 문서도 AI 모델의 구조화 출력에서 JSON Schema를 제공하면 모델이 더 예측 가능하고 타입이 맞는 결과를 만들도록 설정할 수 있다고 안내합니다.

한 줄 정리

JSON Schema는 AI에게 "대충 JSON"이 아니라 "이 필드와 타입을 지켜서 JSON"으로 답하게 만드는 설계도입니다.

왜 JSON Schema가 중요한가?

AI 답변을 사람이 읽기만 한다면 문장이 조금 흔들려도 큰 문제가 아닐 수 있습니다. 하지만 AI 답변을 Google Sheets, CRM, 데이터베이스, 슬랙 봇, 워드프레스 발행 스크립트 같은 다음 단계로 넘기면 이야기가 달라집니다.

예를 들어 AI에게 고객 문의를 분석해 달라고 했는데 어떤 날은 "priority"라고 쓰고, 어떤 날은 "urgency"라고 쓰고, 어떤 날은 숫자 대신 "높음"이라고 쓰면 자동화가 깨집니다. 사람이 보면 알아차릴 수 있지만 프로그램은 약속된 필드와 타입이 없으면 처리하기 어렵습니다.

JSON Schema는 이 문제를 줄이는 역할을 합니다. 필요한 필드를 정하고, 각 필드가 문자열인지 숫자인지 배열인지 지정하고, 꼭 들어가야 하는 항목을 표시합니다. 그러면 AI 결과를 받은 뒤 "이 데이터가 약속한 형식인가"를 검사할 수 있습니다.

핵심 인사이트

AI 자동화에서 중요한 것은 좋은 답변만 받는 것이 아니라, 다음 시스템이 읽을 수 있는 일정한 답변을 받는 것입니다.

쉬운 예시로 이해하기

감자나라ai님이 블로그 글감을 자동으로 분류하는 작은 AI 도구를 만든다고 생각해 보겠습니다. 사용자는 뉴스 링크를 넣고, AI는 제목, 카테고리, 핵심 키워드, 발행 가능 여부를 돌려줘야 합니다.

말로만 지시하면 AI는 이런 식으로 답할 수 있습니다.

예시

이 글은 AI 뉴스이고, 키워드는 에이전트와 검색입니다. 발행해도 괜찮아 보입니다.

사람에게는 충분하지만 자동화에는 애매합니다. 카테고리만 따로 꺼내기 어렵고, 발행 가능 여부도 true/false로 바로 읽기 어렵습니다.

JSON Schema를 쓰면 기대 형식을 이렇게 정할 수 있습니다.

• "title"은 문자열
• "category"는 "news", "tips", "glossary" 중 하나
• "keywords"는 문자열 배열
• "publishable"은 true 또는 false
• "reason"은 짧은 문자열

그러면 AI 결과는 다음 단계에서 읽기 쉬운 구조가 됩니다.

예시

JSON Schema는 "카테고리는 반드시 news, tips, glossary 중 하나여야 한다"처럼 자동화가 이해할 수 있는 규칙을 정합니다. 이 규칙이 있으면 잘못된 카테고리나 빠진 필드를 더 빨리 발견할 수 있습니다.

헷갈리는 용어와 차이

JSON과 JSON Schema는 다릅니다

JSON은 데이터를 표현하는 형식입니다. 예를 들어 {"title":"AI 뉴스","score":8} 같은 데이터 자체가 JSON입니다.

JSON Schema는 그 JSON이 어떤 모양이어야 하는지 설명하는 규칙입니다. "title"은 문자열이어야 하고, "score"는 숫자여야 하며, "score"는 0부터 10 사이여야 한다고 정할 수 있습니다.

JSON mode와 JSON Schema는 다릅니다

JSON mode는 모델이 유효한 JSON 형식으로 답하도록 돕는 기능입니다. 하지만 유효한 JSON이라고 해서 원하는 필드가 모두 있고 타입이 맞는다는 뜻은 아닙니다.

OpenAI 문서는 Structured Outputs와 JSON mode를 구분하면서, JSON mode는 유효한 JSON 생성을 보장하는 데 가깝고 Structured Outputs는 스키마 준수까지 목표로 한다고 설명합니다.

구조화 출력과 JSON Schema는 다릅니다

구조화 출력은 AI 답변을 정해진 구조로 받는 기능이나 방식입니다. JSON Schema는 그 구조를 설명하는 대표적인 규칙 언어입니다.

즉 구조화 출력이 "정해진 형식으로 답하게 하는 기능"이라면, JSON Schema는 "그 정해진 형식을 적은 설계도"에 가깝습니다.

도구 호출과 JSON Schema는 다릅니다

도구 호출은 AI가 검색, 계산, API 실행 같은 외부 기능을 쓰는 방식입니다. JSON Schema는 도구 호출의 입력값이나 AI의 최종 답변 형식을 설명하는 데 쓰일 수 있습니다.

Anthropic 문서는 도구 정의에 "strict: true" 설정을 더해 도구 호출이 스키마에 맞도록 할 수 있다고 설명합니다. 이처럼 스키마는 도구 호출을 더 안정적으로 만드는 재료이지만, 도구 호출 자체와 같은 말은 아닙니다.

비교 정리

JSON은 데이터, JSON Schema는 데이터 규칙, JSON mode는 JSON 형식 출력, 구조화 출력은 정해진 구조로 답하게 하는 기능, 도구 호출은 외부 기능을 실행하는 흐름입니다.

실전에서 어디에 쓰이나?

첫째, 데이터 추출에 씁니다. 긴 고객 문의에서 이름, 이메일, 문의 유형, 긴급도만 뽑아 표로 저장할 때 JSON Schema를 쓰면 필드 이름과 타입을 일정하게 유지하기 쉽습니다.

둘째, 분류 작업에 씁니다. 문의를 "billing", "technical", "refund" 같은 정해진 범주로 나누거나 감정을 "positive", "neutral", "negative"로 분류할 때 "enum" 같은 제약을 걸 수 있습니다.

셋째, 자동화 워크플로에 씁니다. AI가 만든 결과를 데이터베이스, CRM, 워드프레스, 슬랙, 노션, Google Sheets 같은 시스템으로 넘길 때 필드가 안정적이어야 합니다.

넷째, 도구 호출 입력값을 정할 때 씁니다. 예를 들어 "검색 도구에는 query 문자열과 max_results 숫자만 넣는다"처럼 도구가 받을 입력 구조를 정할 수 있습니다.

다섯째, 앱 화면 구성에도 씁니다. OpenAI 문서는 수학 튜터 앱처럼 모델의 출력을 JSON Schema에 맞춰 받아 UI의 여러 부분에 나눠 표시하는 예시를 듭니다.

실전 팁

처음부터 복잡한 스키마를 만들기보다 필수 필드 3~5개, 명확한 타입, 짧은 설명으로 시작하세요. 스키마가 너무 복잡하면 모델 출력과 검증 로직을 함께 관리하기 어려워집니다.

주의할 점

첫째, JSON Schema는 사실 검증 도구가 아닙니다. 형식이 맞아도 내용이 틀릴 수 있습니다. 예를 들어 날짜 필드가 문자열로 잘 들어와도 그 날짜가 실제 발표일인지까지 보장하지는 않습니다.

둘째, 모든 JSON Schema 기능을 모든 AI API가 똑같이 지원하지는 않습니다. OpenAI와 Gemini 문서는 구조화 출력에서 JSON Schema의 전부가 아니라 지원되는 일부 기능이나 하위 집합을 쓸 수 있다고 안내합니다.

셋째, 필드 이름을 애매하게 만들면 결과도 흔들릴 수 있습니다. "result"보다 "summary", "risk_level", "next_action"처럼 목적이 보이는 이름이 좋습니다.

넷째, 스키마를 바꾸면 뒤쪽 자동화도 함께 바꿔야 합니다. 필드 이름 하나가 바뀌어도 Google Sheets 열, 데이터베이스 컬럼, API 처리 코드가 깨질 수 있습니다.

주의

JSON Schema를 쓰면 형식 안정성은 높아지지만, 출처 확인, 개인정보 보호, 권한 검증, 비즈니스 판단까지 자동으로 해결되지는 않습니다.

초보자를 위한 JSON Schema 체크리스트

• 필드 이름이 사람이 봐도 이해되는가?
• 필수값과 선택값을 구분했는가?
• 문자열, 숫자, 배열, 객체 같은 타입을 명확히 정했는가?
• "category", "status"처럼 정해진 값만 허용해야 하는 필드에 "enum"을 썼는가?
• AI 출력 후 실제 검증 로직으로 스키마를 확인하는가?
• 스키마 변경 시 뒤쪽 자동화도 함께 수정하는가?

자주 묻는 질문

Q1. JSON Schema를 쓰면 AI가 항상 정확한 답을 하나요?

아닙니다. JSON Schema는 형식을 맞추는 데 도움을 주지만 내용의 사실성까지 보장하지는 않습니다. 숫자, 날짜, 출처, 법률·의료·금융 정보는 별도 검증이 필요합니다.

Q2. 프롬프트에 "JSON으로 답해줘"라고 쓰는 것과 무엇이 다른가요?

"JSON으로 답해줘"는 형식 요청에 가깝습니다. JSON Schema는 어떤 필드가 있어야 하고, 각 필드가 어떤 타입이어야 하며, 어떤 값만 허용되는지까지 정합니다.

Q3. 코딩을 모르면 JSON Schema를 몰라도 되나요?

직접 코드를 쓰지 않아도 개념은 알아두면 좋습니다. AI 자동화 도구, 노코드 도구, API 연결 화면에서 "schema", "field", "type", "required" 같은 표현을 자주 만나기 때문입니다.

Q4. JSON Schema와 구조화 출력 중 무엇을 먼저 이해해야 하나요?

초보자는 구조화 출력을 먼저 "정해진 모양으로 답을 받는 방식"으로 이해하고, JSON Schema를 그 모양을 적는 규칙으로 이해하면 쉽습니다.

Q5. JSON Schema가 있으면 사람이 검토하지 않아도 되나요?

아닙니다. 자동화에 바로 넣기 전에는 적어도 중요한 필드, 누락값, 민감정보, 출처, 예외 상황을 확인해야 합니다. 스키마 검증은 사람 검토를 대체하기보다 반복 오류를 줄이는 장치에 가깝습니다.

Q6. JSON Schema는 AI 도구 호출에도 쓰이나요?

네. 도구 호출에서는 모델이 외부 함수나 API를 부를 때 필요한 입력값 구조를 스키마로 설명할 수 있습니다. 다만 도구 실행 권한, 실패 처리, 로그 기록은 별도로 설계해야 합니다.

출처

마무리

JSON Schema는 AI 답변을 자동화에 연결할 때 반드시 자주 만나게 되는 기초 개념입니다. 한 문장으로 다시 정리하면, JSON Schema는 AI가 만든 JSON 결과가 약속한 필드와 타입을 따르는지 확인하기 위한 데이터 설계도입니다.

초보자는 오늘 두 가지만 기억하면 됩니다. 첫째, JSON은 데이터이고 JSON Schema는 그 데이터의 규칙입니다. 둘째, 스키마가 맞아도 사실이 맞는 것은 아니므로 형식 검증과 내용 검증을 함께 해야 합니다.

AI를 단순 채팅이 아니라 업무 자동화, 데이터 추출, 고객지원 분류, 도구 호출에 붙이기 시작하면 "답변이 그럴듯한가"보다 "다음 단계가 읽을 수 있는가"가 더 중요해집니다. JSON Schema를 이해하면 구조화 출력, 도구 호출, API 자동화의 기본 흐름이 훨씬 선명해집니다.