JSON Schema Validator를 처음부터 구현하기 - Week 3
Source: Dev.to
주간 업데이트 – 기초와 아키텍처
이번 주는 꽤 바빴어서 할 수 있는 일이 많지 않았지만, 몇 가지 기본적인 결정을 내렸고 몇 가지 사소한 문제에 부딪혔습니다.
TypeScript 학습 곡선
TypeScript를 처음 사용해 봅니다. “정적 타입이 추가된 JavaScript” 정도라고 생각했지만, 객체의 정적 구조를 미리 정의해야 한다는 것을 금방 알게 되었습니다. 프로젝트의 기본 부분을 작성하는 것이 번거로웠는데, 모든 변수에 타입을 정의할 때까지 빨간 물결선이 표시되었기 때문입니다.
이 초기 작업이 귀찮게 느껴졌지만, 나중에 개발 경험을 크게 개선해 줄 것이라는 점을 이제는 이해하게 되었습니다.
초기 단계의 도전 과제
새 프로젝트를 시작하는 것은 언제나 어렵습니다:
- 연결하거나 확장할 기존 코드가 없습니다.
- 시스템에 대한 큰 그림이 위압적으로 느껴질 수 있습니다.
- 고수준의 아키텍처 관점과 저수준 구현 관점을 계속 오가야 합니다.
- 초기 결정이 장기적인 영향을 미쳐 나중에 변경하기가 어렵습니다.
조금 혼란스러운 시간이 있었지만, 더 많은 조사를 한 뒤(다음 섹션 참고) 상황이 정리되었습니다.
아키텍처 결정
JSON Schema 사양을 읽기 전에, 유지보수자들은 시스템 아키텍처에 집중하면 새로운 JSON Schema 초안을 지원하는 것이 쉬워진다고 조언했습니다.
키워드 핸들러 객체
키워드 이름을 해당 키워드를 구현하는 함수에 매핑하는 키워드 핸들러 객체를 만들기로 했습니다. 지원되는 각 초안마다 별도의 핸들러 객체를 가집니다.
2020‑12 초안 핸들러를 구현하던 중, 핸들러 함수들을 시스템의 나머지 부분과 어떻게 통합해야 할지 막히는 상황이 있었습니다. 조사 결과 두 가지 일반적인 검증기 아키텍처가 있음을 알게 되었습니다:
- 재귀적 아키텍처
- Visitor 아키텍처
Visitor 아키텍처가 제 접근 방식에 필요한 부분을 제공했기에 이를 채택했습니다.
Visitor 기반 검증기 아키텍처
두 아키텍처 모두 재귀적이지만, 재귀가 적용되는 방식이 다릅니다.
-
공개 진입점 –
validate
사용자에게 노출되는 함수. -
스키마 순회 –
validateSchema
흐름을 제어하고, 스키마의 어느 부분을 방문할지 결정하며, 키워드 핸들러 객체에서 적절한 핸들러를 가져옵니다. -
핸들러 시그니처
(schema: any, instance: any, context: ValidationContext) => voidschema– 현재 하위 스키마.instance– 검증 중인 데이터.context– 오류, 인스턴스 및 스키마 위치, 평가된 아이템/프로퍼티를 추적하고 유틸리티 함수를 제공할 수 있습니다.
-
재귀적 위임
핸들러가 작업을 마치면, 자식 스키마에 대해validateSchema를 호출하여 제어를 순회 로직으로 다시 넘깁니다. -
완료
단계 2‑4가 검증이 끝날 때까지 반복됩니다. 그 후validate함수는 누적된ValidationContext를 사용해 최종 검증 결과를 생성합니다.
이 설계는 흐름 제어와 키워드 구현을 명확히 분리하여, 키워드를 추가, 업데이트 또는 제거하기가 쉽습니다.
구현 시 참고 사항
- 구현을 도울 때 LLM을 사용했지만, 저장소에 있는 모든 코드는 제가 직접 작성했거나 충분히 검토한 것입니다.
- 소스 코드는 GitHub에 공개되어 있습니다: (실제 URL로 교체).
주간 3 업데이트 종료.