JSON Schema로 날짜를 쓴다고 해서 검증자가 반드시 날짜를 확인해야 하는 것은 아닙니다.

format: date가 JSON 스키마로 작성되었지만 존재하지 않는 날짜가 확인을 통과했습니다. 이는 일반적으로 라이브러리의 버그가 아닙니다. format가 처리되는 방법은 유효성 검사기 구성에 따라 다릅니다. "확인 성공" 결과가 나타나면 먼저 유형, 구조를 확인하는지 또는 날짜 의미도 확인하는지 확인해야 합니다.

이 문서는 문서 데이터의 구조화된 검증을 수행하고 날짜 필드의 정확성에 관심이 있는 개발자 및 검토자에게 적합합니다. 이 내용을 읽고 나면 검증 통과가 무엇을 의미하는지 판단하고 반례 테스트를 사용하여 날짜 규칙을 수정할 수 있습니다.

이 기사에서는 합성 샘플을 사용하여 처리 방법을 보여줍니다. 코드는 격리된 환경에서 예제로 확인되었으며 모든 실제 파일이나 제품 성능을 보장하지는 않습니다. 중요한 서류를 처리하기 전, 원본을 보관하시고, 본문에 기재된 경계 및 허용 항목에 따라 검토하시기 바랍니다.

JSON Schema의 날짜 확인은 정확히 무엇을 확인하나요? 한 문장 결론

먼저 유효성 검사기에서 format 검사가 활성화되어 있는지 확인한 다음 날짜의 의미 규칙(실제로 존재하는지 여부 및 해석 방법)이 달리 책임이 있는지 확인합니다.

당신의 상황	권장 사례	이유
기본 검증인으로 `format: date`만 확인하세요	먼저 FormatChecker가 명시적으로 활성화되어 있는지 확인하세요.	`format`가 처리되는 방법은 유효성 검사기 구성에 따라 다릅니다.
`2026-02-30`와 같은 날짜를 식별해야 합니다.	반례로 테스트 세트에 넣습니다.	문자열은 날짜처럼 보이지만 달력에 존재한다는 의미는 아닙니다.
출처 날짜의 일과 월의 순서는 알 수 없습니다.	모호함 표시, 자동 추측 없음	`date` 검증을 통과하면 변환된 값이 유효하다는 것만 보여줄 수 있습니다.
시간 및 시간대가 포함된 필드	독립적인 시간 프로토콜 사용	처음 10자를 임의로 가로채서 처리해서는 안 됩니다.
번역 날짜 확인에 사용됩니다.	`raw_text`와 정규화된 값을 모두 저장합니다.	리뷰어는 원본 내용과 체계적인 설명을 모두 보아야 합니다.

겉보기에는 동일해 보이는 두 개의 수표

2026-02-30는 문자열이고 날짜처럼 보이지만 2월에는 30일이 없습니다. 규칙적인 모양만 확인하면 이런 종류의 문제를 놓칠 수 있습니다. 다음은 Python의 jsonschema를 사용하여 기본 유효성 검사기의 결과를 비교하고 FormatChecker를 명시적으로 활성화합니다.

불가능한 날짜로 구성 테스트

from jsonschema import Draft202012Validator, FormatChecker

schema = {"type": "string", "format": "date"}
structural = Draft202012Validator(schema)
strict = Draft202012Validator(schema, format_checker=FormatChecker())

def valid(v, value):
    return not list(v.iter_errors(value))

assert valid(structural, "2026-02-30")
assert not valid(strict, "2026-02-30")
assert valid(strict, "2024-02-29")
assert not valid(strict, "2025-02-29")
assert not valid(strict, "26/09/2026")
assert not valid(strict, 20260926)

합성 예에서는 date만 확인합니다. 다른 형식에는 선택적 종속성 또는 구현 차이가 있을 수 있으며 잠긴 환경에서 사례별로 테스트해야 합니다. 알 수 없는 형식 이름은 일종의 검사가 구현되었음을 의미할 수 없으며 철자가 틀리면 의미 없는 보안 느낌을 줄 수 있습니다.

날짜 형식은 날짜 해석 규칙이 아닙니다.

소스의 03/04/2026는 3월 4일을 의미할 수도 있고 4월 3일을 의미할 수도 있습니다. ISO 형식으로 변환하기 전에 소스 지역, 필드 사양 또는 명시적인 프로토콜이 필요합니다. date 검증을 통과하면 변환된 값이 유효하다는 것만 증명할 수 있으며 올바른 월을 선택했다는 것을 증명할 수는 없습니다.

소스정보	무엇을 해야할지	하지 말아야 할 것
존재하지 않는 달력 날짜	오류 보고 및 소스 검토	다음 달로 자동 스크롤
태양과 달의 순서를 알 수 없음	태그 모호성	서버 언어를 기반으로 추측
시간 및 시간대 포함	독립적인 시간 프로토콜 사용	처음 10자를 무작위로 가로채기
필드가 비어 있습니다.	누락된 규칙에 따라 처리	오늘 날짜를 보완하세요.

회귀 테스트에 구성 통합

테스트 세트에는 합법적인 윤일, 불법적인 윤일, 잘못된 값 등 세 가지 유형 이상의 값을 입력합니다. 배포 시 이러한 반례를 실행하는 것은 단순히 스키마 파일이 있는지 확인하는 것보다 더 효율적입니다. 서비스가 여러 언어에 걸쳐 구현되는 경우 동일한 테스트 세트를 별도로 확인해야 하며 두 유효성 검사기의 기본 동작이 동일하다고 가정하지 마십시오.

번역 검토는 원래 날짜를 유지합니다

OmniDoc 번역 검증을 위해 날짜 추출 결과를 사용할 때 raw_text와 정규화된 값을 모두 저장하는 것이 좋습니다. 검토자는 차이점이 번역, 추출 또는 형식 변환에 있는지 확인하기 위해 "원본 내용이 무엇인지"와 "시스템이 이를 어떻게 해석하는지"를 확인해야 합니다.

참고: JSON 스키마 문자열 및 형식.

📊 핵심 비교

비교항목	기본 유효성 검사기	FormatChecker를 명시적으로 활성화합니다.
범위 확인	유형 및 구조	`format` 선언 형식에 대한 추가 확인
`2026-02-30`에 대한 결론	거절을 가정하지 마십시오	반례로 확인 필요
지나갈 때의 의미	날짜 의미가 정확하다는 의미는 아닙니다.	그래도 업체에 대한 날짜 설명을 확인해야 합니다.

🎯 어떤 방법이 당신에게 적합합니까?

필드가 문자열인지 또는 올바르게 구조화되었는지 확인해야 하는 경우

일반적으로 기본 유효성 검사기로 충분하지만 날짜 의미를 반드시 확인할 필요는 없습니다.

해당 날짜가 실제로 존재하는지 확인이 필요한 경우

FormatChecker를 명시적으로 활성화하고 2026-02-30와 같은 반례를 사용하여 확인합니다.

소스파일의 날짜를 확인하고 싶다면

먼저 일월순의 소스 규칙을 확인한 후 원본 텍스트와 정규화된 값을 저장합니다.

서비스가 여러 언어로 배포되는 경우

각 구현에서 동일한 테스트 세트가 실행됩니다.

❓ 자주 묻는 질문(FAQ)

1. 스키마는 `format: date`로 작성되는데 왜 잘못된 날짜가 여전히 지나갈 수 있습니까?

format가 처리되는 방법은 유효성 검사기 구성에 따라 다르며 날짜 의미는 기본적으로 반드시 확인되지 않습니다.

2. `2026-02-30`가 왜 유용한 테스트 값인가요?

날짜처럼 보이지만 2월은 30일이 없습니다. 외관만 확인하면 이런 문제를 놓칠 수 있습니다.

3. 알 수 없는 형식 이름을 사용하면 어떻게 되나요?

확인된 것처럼 취급해서는 안 되며 철자 오류로 인해 잘못된 보안 인식이 생길 수 있습니다.

4. `03/04/2026`를 어떻게 변환해야 합니까?

출신 지역, 필드 설명 또는 명시적인 프로토콜이 필요합니다. 그렇지 않으면 3월 4일인지 4월 3일인지 구분하는 것이 불가능합니다.

📝 요약

검증을 통과한다는 것은 데이터가 선언된 규칙을 충족한다는 의미일 뿐, 각 날짜의 의미가 정확하다는 의미는 아닙니다. 먼저 검증인의 검사 범위를 확인한 후 반례와 소스 규칙을 사용하여 날짜 처리를 수정하면 결과의 신뢰성이 높아집니다.

지금 사용해 보세요: 원본 레이아웃을 유지하면서 번역을 시작하려면 문서를 업로드하세요.