처음부터 JSON Schema Validator 구현하기 - Week 2
Source: Dev.to
배경
두 주에 걸쳐 읽기를 마치고 드디어 JSON Schema 사양(특히 Core와 Validation 사양)을 모두 끝냈습니다. 이제 JSON Schema 검증기가 어떻게 생겼는지에 대한 감이 잡히고, 사양에 대한 몇 가지 생각도 생겼습니다.
전체적으로 저자들은 훌륭한 작업을 했습니다— 시스템의 거의 모든 세세한 부분이 언급됩니다: 어떻게 동작해야 하는지, 구현체가 특정 경우를 어떻게 처리해야 하는지, 전달받은 스키마는 어떤 형태여야 하는지, 그리고 그렇지 않을 경우 어떻게 해야 하는지 등.
사양과의 어려움
사양을 읽는 데 몇 가지 어려움이 있었습니다. 이는 문서의 모호성 때문일 수도 있고, 단순히 제가 경험이 부족해서일 수도 있습니다. 이번이 사양을 처음 다루는 것이었거든요. 주요 문제는 다음과 같습니다:
- 대상 독자에 대한 모호성.
- 일부 섹션의 명확성 부족.
대상 독자 모호성
사양은 세 가지 다른 주체를 다룹니다:
- 스키마 작성자 – 검증기를 사용하기 위해 스키마를 작성하는 사람들.
- 검증기 구현자 – 검증기 코드를 구현/작성하는 사람들.
- 사양 확장자 – 사용자 정의 키워드나 vocabularies를 만드는 사람들.
문서에서는 특정 문단이 어느 독자를 대상으로 하는지 거의 명시하지 않습니다. 경우에 따라 같은 문장이 한 그룹을 향해 시작하고 다른 그룹을 향해 끝나기도 합니다. 누가 대상인지 알기 위해서는 주변 맥락을 완전히 이해해야 하는데, 이는 처음 접하는 사람에게는 어렵습니다.
구체적인 혼란 영역
- Lexical vs. dynamic scopes – 설명이 불명확해 구분을 이해하기 어려웠습니다.
- Meta‑schemas – 지난 주 글에서 자세히 다뤘지만, 사양의 문구가 혼란스러웠습니다.
anyOf예시 (chapter 11) – 추가적인 맥락 없이 예시를 따라가기 힘들었습니다.
추가 예시와 더 명확한 문구가 있었다면 사양을 읽는 것이 훨씬 수월했을 것입니다.
도움이 된 도구
Google의 NotebookLM에 큰 감사를 표하고 싶습니다. 사양을 이해하기 위해 여러 도구를 시도했지만, NotebookLM이 가장 도움이 되었습니다.
구현 범위 계획
사양에서는 일부 키워드와 기능은 필수이고, 다른 것들은 선택 사항이라고 명시합니다. 초기 구현에서는 다음과 같이 할 예정입니다:
- draft 2020‑12만 지원
$vocabulary키워드 제외- 자세한 출력 형식 지원
- 단락(short‑circuiting) 제외
format키워드의 어노테이션 기능만 지원- 스키마의 부모 또는 조상 base URI를 사용하는 JSON 포인터의 dereferencing 제외 (Core 사양 섹션 9.2.1 참고)
- 원격 스키마 가져오기 제외
첫 번째 완전 기능 검증기를 만들면서 난이도를 가능한 한 낮추는 것이 목표이며, 이는 제가 처음으로 사양을 준수하는 소프트웨어 시스템을 시도하는 것이기 때문입니다.
향후 작업
기본적인 완전 기능 검증기를 만든 뒤에는 다음을 고려할 수 있습니다:
- 추가 드래프트 – 검증기를 구조적으로 유연하게 설계하면 나중에 새로운 드래프트를 추가하는 것이 쉬워집니다.
- 단락(short‑circuiting) – 사양에 맞게 구현할 수 있다면 적용해 보고 싶습니다.
format키워드 어설션 – 학습 가치가 있거나 재미있다면 이 기능을 확장할 수 있습니다.