JSON 문법이 맞는데 저장 단계에서 막힐 수 있습니다. 필요한 키가 없거나 날짜가 다른 형식이면 그럴 수 있습니다. 그렇다고 처음 결과를 “JSON 실패”라고 부르면 원인을 잘못 짚게 됩니다.
기본 요청은 한국어 키 다섯 개를 요구했고 그대로 받았습니다. 두 번째는 영어 키와 변환 규칙을 요구했습니다. 둘 다 문법은 맞았습니다. 아래 비교에서 0/8과 8/8은 추가한 영어 스키마 기준의 일치 수이지, 첫 응답이 잘못된 키를 만들었다는 점수가 아닙니다.
개인정보 없는 가상 작업 8줄에 날짜와 누락값을 섞었습니다.
작업 ID A-01부터 A-08까지를 고정하고 마감일은 ISO 1종과 비표준 6종, 총 일곱 표기로 섞었습니다. A-07의 담당만 ‘기록 없음’으로 두었고 상태는 진행중, 완료, 대기 세 표현을 사용했습니다.
두 결과는 화면 원문을 별도 데이터 파일에 옮겨 객체 수, 키 배열, 날짜 정규식, 상태 허용값과 null을 코드로 검사했습니다. 실제 직원 이름, 고객 데이터와 회사 프로젝트는 사용하지 않았습니다.
가상 작업 메모 8줄
A-01 | 제목 검수 | 편집 | 2026.08.07 | 진행중 A-02 | 이미지 대체텍스트 | 디자인 | 8월 7일 | 완료 A-03 | 링크 확인 | 편집 | 2026/08/08 | 대기 A-04 | 모바일 점검 | 개발 | 08-08 | 진행중 A-05 | 출처 확인 | 편집 | 2026년 8월 9일 | 완료 A-06 | 구조화 데이터 | 개발 | 8/9 | 대기 A-07 | 광고 위치 검토 | 담당 기록 없음 | 2026-08-10 | 진행중 A-08 | 최종 교정 | 편집 | 8월 10일 | 대기
- 입력
- 가상 작업 8줄
- A 요청
- 한국어 키 5개
- B 요청
- 영어 스키마 + 규칙 8개
- 판정
- 16객체·80필드
- 누락값
- A-07 담당 1건
- 개인정보
- 실제 정보 없음
A. 기본 JSON 요청
아래 가상 작업 메모 8줄을 JSON 배열로 바꿔줘. 각 객체에 작업ID, 작업명, 담당, 마감일, 상태를 넣고 설명 없이 JSON만 보여줘.
B. 스키마 조건 8개
같은 가상 작업 메모를 다시 JSON 배열로 바꿔줘. 아래 8개 조건을 모두 지켜줘. 1) 정확히 8개 객체, 2) 키는 id·title·owner·due·status 다섯 개만 이 순서로 사용, 3) due는 모두 2026-08-DD, 4) 담당 기록 없음은 owner:null, 5) 진행중=in_progress·완료=done·대기=pending으로 변환, 6) 원문 순서 유지, 7) 원문에 없는 값을 추측하지 않기, 8) 마크다운 설명 없이 유효한 JSON 배열만 보여줘.
파싱은 됐지만 날짜와 상태값은 원문 형식 그대로였습니다.
첫 출력은 대괄호 안에 객체 8개가 들어간 유효한 JSON이었습니다. 작업 ID와 작업명, 원문 순서도 모두 보존했습니다. 단순히 데이터를 잃지 않고 JSON으로 옮기는 목적에는 맞았습니다.
자동화 입력으로는 재가공이 필요했습니다. ISO 날짜는 A-07 한 건뿐이었고 키는 한국어였습니다. 상태값도 세 한국어 표현을 그대로 사용했고 담당이 없는 A-07은 null이 아니라 문장형 문자열이었습니다.
원본 크기로 보기 
원본 크기로 보기 스키마를 적자 키와 날짜, 상태와 null이 모두 규칙을 따랐습니다.
두 번째 출력의 모든 객체는 id, title, owner, due, status 다섯 키를 같은 순서로 사용했습니다. due는 2026-08-07부터 2026-08-10까지 ISO 형식이었습니다.
상태는 in_progress, done, pending 세 값만 사용했고 A-07의 owner는 null이었습니다. 원문에 없는 담당자를 추측하지 않았습니다. 결과 문자열을 JSON으로 파싱하는 검사도 통과했습니다.
원본 크기로 보기 
원본 크기로 보기 JSON 객체 16개와 80개 필드를 코드로 다시 검사한 결과
| 검사항목 | 기본 요청 | 스키마 조건 | 판정 |
|---|---|---|---|
| JSON 파싱 | 통과 | 통과 | 둘 다 통과 |
| 객체 수 | 8 / 8 | 8 / 8 | 둘 다 통과 |
| 추가 요청의 영어 키 형식 | 0 / 8 | 8 / 8 | 조건형 통과 |
| 날짜 2026-08-DD | 1 / 8 | 8 / 8 | 조건형 통과 |
| 상태 허용값 | 0 / 8 | 8 / 8 | 조건형 통과 |
| 누락 담당 null | 0 / 1 | 1 / 1 | 조건형 통과 |
두 결과 모두 JSON 문법은 유효했습니다. 당시 표는 id·title·owner·due·status의 이름과 나열 순서를 기록한 값이며, 순서 자체를 JSON의 의미상 오류로 보지는 않습니다. 날짜·상태·null은 사전 규칙으로 따로 검사했습니다.
A. 기본 요청 JSON 객체 8개
- 01
{“작업ID”:”A-01″,”작업명”:”제목 검수”,”담당”:”편집”,”마감일”:”2026.08.07″,”상태”:”진행중”}
- 날짜
- 원문 형식
- 키
- 작업ID · 작업명 · 담당 · 마감일 · 상태
- 02
{“작업ID”:”A-02″,”작업명”:”이미지 대체텍스트”,”담당”:”디자인”,”마감일”:”8월 7일”,”상태”:”완료”}
- 날짜
- 원문 형식
- 키
- 작업ID · 작업명 · 담당 · 마감일 · 상태
- 03
{“작업ID”:”A-03″,”작업명”:”링크 확인”,”담당”:”편집”,”마감일”:”2026/08/08″,”상태”:”대기”}
- 날짜
- 원문 형식
- 키
- 작업ID · 작업명 · 담당 · 마감일 · 상태
- 04
{“작업ID”:”A-04″,”작업명”:”모바일 점검”,”담당”:”개발”,”마감일”:”08-08″,”상태”:”진행중”}
- 날짜
- 원문 형식
- 키
- 작업ID · 작업명 · 담당 · 마감일 · 상태
- 05
{“작업ID”:”A-05″,”작업명”:”출처 확인”,”담당”:”편집”,”마감일”:”2026년 8월 9일”,”상태”:”완료”}
- 날짜
- 원문 형식
- 키
- 작업ID · 작업명 · 담당 · 마감일 · 상태
- 06
{“작업ID”:”A-06″,”작업명”:”구조화 데이터”,”담당”:”개발”,”마감일”:”8/9″,”상태”:”대기”}
- 날짜
- 원문 형식
- 키
- 작업ID · 작업명 · 담당 · 마감일 · 상태
- 07
{“작업ID”:”A-07″,”작업명”:”광고 위치 검토”,”담당”:”담당 기록 없음”,”마감일”:”2026-08-10″,”상태”:”진행중”}
- 날짜
- 통일
- 키
- 작업ID · 작업명 · 담당 · 마감일 · 상태
- 08
{“작업ID”:”A-08″,”작업명”:”최종 교정”,”담당”:”편집”,”마감일”:”8월 10일”,”상태”:”대기”}
- 날짜
- 원문 형식
- 키
- 작업ID · 작업명 · 담당 · 마감일 · 상태
B. 스키마 요청 JSON 객체 8개
- 01
{“id”:”A-01″,”title”:”제목 검수”,”owner”:”편집”,”due”:”2026-08-07″,”status”:”in_progress”}
- 날짜
- 통일
- 키
- id · title · owner · due · status
- 02
{“id”:”A-02″,”title”:”이미지 대체텍스트”,”owner”:”디자인”,”due”:”2026-08-07″,”status”:”done”}
- 날짜
- 통일
- 키
- id · title · owner · due · status
- 03
{“id”:”A-03″,”title”:”링크 확인”,”owner”:”편집”,”due”:”2026-08-08″,”status”:”pending”}
- 날짜
- 통일
- 키
- id · title · owner · due · status
- 04
{“id”:”A-04″,”title”:”모바일 점검”,”owner”:”개발”,”due”:”2026-08-08″,”status”:”in_progress”}
- 날짜
- 통일
- 키
- id · title · owner · due · status
- 05
{“id”:”A-05″,”title”:”출처 확인”,”owner”:”편집”,”due”:”2026-08-09″,”status”:”done”}
- 날짜
- 통일
- 키
- id · title · owner · due · status
- 06
{“id”:”A-06″,”title”:”구조화 데이터”,”owner”:”개발”,”due”:”2026-08-09″,”status”:”pending”}
- 날짜
- 통일
- 키
- id · title · owner · due · status
- 07
{“id”:”A-07″,”title”:”광고 위치 검토”,”owner”:null,”due”:”2026-08-10″,”status”:”in_progress”}
- 날짜
- 통일
- 키
- id · title · owner · due · status
- 08
{“id”:”A-08″,”title”:”최종 교정”,”owner”:”편집”,”due”:”2026-08-10″,”status”:”pending”}
- 날짜
- 통일
- 키
- id · title · owner · due · status
이번 테스트가 확인하지 않은 것
- 가상 작업 8줄 한 세트를 JSON으로 두 번 변환한 결과입니다.
- 실제 직원·고객·프로젝트 정보는 입력하지 않았습니다.
- API 호출, 웹훅, 데이터베이스 저장과 자동 실행을 수행하지 않았습니다.
- 스키마 검사는 이 글의 다섯 키와 세 상태값에 한정됩니다.
- 처리 시간, 오류율, 업무 비용과 수익 변화는 측정하지 않았습니다.
내가 필요한 계약을 먼저 정합니다.
키 이름·자료형·허용값·빈 값 규칙을 적은 뒤 검사기를 만듭니다. 여기서는 키의 순서를 채점하지 않습니다. JSON 객체에서 키 순서를 바꿔도 같은 의미를 담을 수 있기 때문입니다. 순서가 꼭 필요한 다른 시스템이 있다면 그것은 별도 연동 조건으로 설명하세요.
아래 검사기는 다섯 필드의 예제 계약과 실제 날짜, 중복 ID를 확인합니다. 통과해도 담당자·기한이 현실과 같은지는 원자료와 다시 대조해야 합니다.
TRY IT HERE
문법 통과와 작업 계약 통과를 나눠 확인하세요.
입력값은 이 브라우저 안에서만 처리합니다. 아래 검사 기능은 서버에 저장하거나 전송하지 않습니다. 실제 개인정보 대신 예제를 사용하세요.
최대 20만 자 · 원본을 자동 수정하지 않습니다.
세부 데이터·판정 규칙 보기
직접 확인할 자료
입력과 판정 규칙을 함께 보면 결과를 다시 확인하기 쉽습니다. 자료의 숫자는 별도 표시가 없는 한 학습용 가상 값입니다.
판정 기준을 정할 때 확인한 공식 출처
Google은 원하는 작업과 출력 형식을 구체적으로 지정하는 방식을 안내합니다. JSON의 기본 문법은 RFC 8259를 기준으로 확인했고, 응답 내용은 별도 규칙으로 다시 검증했습니다.
원실험: 2026년 8월 1일 · 공식 자료 재확인: 2026년 8월 31일