AI 응답 JSON 검증: 문법 통과 후 필드·자료형 확인하기

AI 응답이 JSON 문법을 통과해도 업무에 필요한 자료형은 틀릴 수 있습니다. 제목·태그·발행 여부를 검사하는 로컬 함수로 문자열과 배열·불리언의 차이를 직접 확인했습니다.

Table of Contents

자동화가 기대하는 입력 계약을 먼저 쓴다

AI에게 JSON만 출력하라고 요청하면 문법상 읽을 수 있는 객체가 돌아와도 다음 단계가 기대한 형식과 다를 수 있습니다. 태그를 쉼표로 구분한 문자열로 받고 발행 여부를 false라는 글자로 받는 경우가 대표적입니다. 후속 코드가 값을 참·거짓 조건에 그대로 넣으면 작성자가 의도한 비공개 판단과 다른 결과가 나올 수 있습니다. 문법을 읽는 작업과 업무 계약을 검사하는 작업은 분리해야 합니다.

이 실습의 계약은 title이 빈 문자열이 아닌 제목이고 tags는 문자열 배열이며 publish는 불리언이라는 것입니다. 지정한 세 필드 외의 추가 키도 허용하지 않았습니다. 스키마가 먼저 정해져 있어야 프롬프트의 기대 결과와 오류 보고가 같은 기준을 갖습니다. 필드가 늘어날 때는 소비하는 시스템이 준비됐는지 확인하고 계약 버전을 함께 바꾸세요. 생성 결과가 그럴듯하다는 이유로 계약을 즉석에서 넓히지 않는 것이 중요합니다.

JSON.parse와 JSON Schema가 맡는 역할

MDN의 JSON.parse 안내는 JSON 문자열을 JavaScript 값으로 변환하는 기능과 잘못된 문법의 오류를 설명합니다. JSON Schema의 객체 안내는 속성 선언, 필수 키와 추가 속성의 허용 여부를 구분합니다. 이 글에서는 두 개념을 작은 전용 함수로 구현해 입력이 어떤 단계에서 실패하는지 직접 볼 수 있게 했습니다.

아래 함수는 JSON Schema 표준 전체를 구현한 검증 라이브러리가 아닙니다. 한 콘텐츠 작업의 세 필드만 확인하는 교육용 코드입니다. 복잡한 중첩 객체나 여러 서비스가 같은 계약을 사용할 때는 검증 라이브러리와 정식 스키마를 선택하는 편이 낫습니다. 단순한 예제로 자료형 검사의 필요성을 익히고, 실제 도입에서는 지원하는 스키마 버전과 오류 형식을 정해야 합니다. 생성 모델의 특정 API 기능이나 유료 계정에 대한 사용 실험은 하지 않았습니다.

직접 실행 결과: 두 가지 자료형 오류를 분리했다

검증일 2026-10-01, 환경은 Windows Chromium 1200×675의 자체 로컬 도구입니다. 입력값은 제목 Guide, tags 값 ai라는 문자열, publish 값 false라는 문자열을 담은 JSON 객체입니다. 문법은 올바르므로 JSON.parse는 성공하지만 자료형 검사에서는 tags와 publish 두 항목이 실패했습니다.

수정 예제를 적용하면 tags는 한 원소를 가진 배열이 되고 publish는 따옴표가 없는 false가 됩니다. 다시 검사한 결과 오류 0건, title 문자열·tags 배열·publish 불리언이라는 메시지를 확인했습니다. 수정 전후 캡처와 영상은 이 버튼 동작을 실제로 수행하면서 얻었습니다. 화면은 외부 AI 서비스의 UI를 흉내 낸 것이 아니라 본문 코드의 입력과 반환값을 보여 주는 자체 실습입니다. 모델이 실제로 특정 응답을 생성했다는 주장도 하지 않습니다.

AI 응답 JSON 검증: 문법 통과 후 필드·자료형 확인하기의 실제 입력 화면 — 2026-10-01, 자체 로컬 실습의 입력값과 검사 시작 화면. 계정과 실제 개인정보를 사용하지 않았다.

title 문자열 / tags 배열 / publish 불리언가 표시된 실제 결과 화면 — 같은 세션에서 수정 예제를 적용하고 직접 검사한 결과: title 문자열 / tags 배열 / publish 불리언.

실제 브라우저 버튼 조작과 결과 변화. 자체 실습이며 외부 제품 사용이나 서버 호출 영상이 아니다.

재현 코드와 오류를 다루는 순서

함수를 정의한 뒤 먼저 본문의 잘못된 샘플을 넣고 errors를 확인하세요. 다음에는 수정 샘플을 넣어 빈 배열을 확인합니다. 마지막으로 전체 입력을 배열이나 null로 바꿔 객체 경계가 작동하는지도 점검하세요. 이렇게 기대 실패와 기대 성공을 함께 확인해야 검증기가 모든 입력을 통과시키는 실수를 찾을 수 있습니다.

실무에서는 오류가 발생했을 때 전체 응답을 공개 로그에 남기지 마세요. 필드 이름과 예상 자료형, 처리 단계만 기록해도 작업을 되돌리는 데 도움이 됩니다. 재생성을 요청한다면 이미 확인된 오류만 모델에 알려 수정하도록 하고, 새 응답도 같은 검사기를 다시 통과시켜야 합니다. 자동 보정으로 배열이나 불리언을 만들어 버리는 처리는 원래 의미가 달라질 수 있으므로 명시적인 변환 규칙이 있을 때만 적용하세요.

const check = function(value) {
      let data; try { data = JSON.parse(value); } catch { return { errors: ['JSON 문법 오류'] }; }
      if (!data || Array.isArray(data) || typeof data !== 'object') return { errors: ['객체 필요'] };
      const errors = [];
      if (typeof data.title !== 'string' || !data.title.trim()) errors.push('title: 비어 있지 않은 문자열 필요');
      if (!Array.isArray(data.tags) || !data.tags.every(x => typeof x === 'string')) errors.push('tags: 문자열 배열 필요');
      if (typeof data.publish !== 'boolean') errors.push('publish: 불리언 필요');
      if (Object.keys(data).some(k => !['title', 'tags', 'publish'].includes(k))) errors.push('허용하지 않은 필드');
      return { errors, data };
    };

console.log(check("{\"title\":\"Guide\",\"tags\":\"ai\",\"publish\":\"false\"}"));
console.log(check("{\"title\":\"Guide\",\"tags\":[\"ai\"],\"publish\":false}"));

한계와 실패 조건: 구조는 사실을 검증하지 않는다

이 함수는 제목이 문자열인지 확인하지만 제목의 사실 여부와 출처는 확인하지 않습니다. 태그 배열이 비어 있거나 항목이 반복되는 경우도 현재 계약에서는 허용합니다. 태그 개수와 허용 목록이 업무상 필요하면 별도 조건으로 추가해야 합니다. publish가 불리언이라는 사실도 공개 발행 권한을 의미하지 않습니다. 실제 게시 단계에는 담당자의 승인과 기존 초안 ID 확인 같은 별도의 제어가 필요합니다.

매우 큰 응답, 위험한 HTML, 개인정보, 중첩 객체와 숫자 범위 역시 이 예제의 검사 범위 밖입니다. 사용자 입력을 객체에 합칠 때의 보안 문제와 스키마 호환성을 이 함수 하나로 해결했다고 말할 수 없습니다. 실패 결과는 자동화의 다음 단계에 입력을 넘기지 않는 신호로 사용하고, 사실 확인과 권한 검사는 별도 단계에서 실행하세요. 작은 계약은 관리하기 쉽지만 적용 범위를 문서에 적어 두어야 합니다.

데이터 계약을 유지하는 질문 세 가지

프롬프트에 형식 설명을 넣었는데 검사도 필요한가요? 설명은 생성 방향을 잡고 검사기는 결과가 실제로 계약을 지켰는지 판단합니다. 두 작업은 목적이 다르므로 함께 사용하는 편이 좋습니다.

문자열 false를 불리언 false로 바꾸면 되나요? 명확히 합의된 변환 규칙이 있으면 가능하지만 무조건 Boolean으로 변환하면 비어 있지 않은 문자열이 true로 해석될 수 있습니다. 원래 값과 변환 결과를 테스트한 뒤 적용하세요.

어떤 샘플을 회귀 검사에 남기나요? 잘못된 문법, null, 배열, 누락 필드, 잘못된 자료형, 추가 키, 정상 객체를 각각 남기면 계약 변경의 영향을 판단하기 쉽습니다. 실제 고객 데이터를 복사하지 않고 최소한의 예제로 실패 조건을 재현하는 편이 안전합니다.

검수 사례 표

입력 조건	직접 검사할 기대 결과
tags 문자열 · publish 문자열	자료형 오류 2건
tags 배열 · publish 불리언	오류 0건
null 또는 배열	객체 필요
추가 키 debug	허용하지 않은 필드

공식 출처와 함께 읽을 글

공식 기준 문서 — 2026-10-01 확인
기술 동작 참고 문서 — 2026-10-01 확인

AI 프롬프트 회귀 테스트 실전에서는 입력을 고정하고 수정 전후 차이를 확인하는 다른 검수 과정을 살펴볼 수 있습니다.