스키마를 해시로 못 박는다 — JSON의 '버전 지옥'에 도전하는 TSON

JSON은 편한데, 스키마는 늘 말썽이죠

백엔드와 프론트엔드가 데이터를 주고받을 때 우리는 거의 반사적으로 JSON을 쓰는데요. JSON이 사랑받는 이유는 별다른 준비 없이 바로 쓸 수 있는 자유로움 때문이거든요. 그런데 아이러니하게도 그 자유로움이 사고의 원인이 되기도 해요. 서버 팀이 필드 이름을 슬쩍 바꾸거나, 숫자였던 값을 문자열로 바꿨는데 클라이언트 쪽은 그걸 모르고 있다가 배포 후에 터지는 일, 한 번쯤 겪어보셨을 거예요. '분명히 v2 스키마라고 했는데 왜 이 필드가 없지?' 같은 상황요. 이 문제를 정면으로 겨냥한 새로운 포맷이 등장했어요. 이름은 TSON이고, JSON의 상위 호환(superset, 기존 JSON 문서가 전부 그대로 유효하다는 뜻이에요)이면서 '불변(immutable) 해시 고정(hash-pinned) 스키마'라는 독특한 개념을 들고 나왔어요.

해시로 스키마를 고정한다는 게 뭐냐면

이게 뭐냐면, 스키마(데이터가 어떤 필드와 타입을 가져야 하는지 정의한 명세)를 만들면 그 내용 전체를 암호학적 해시 함수에 넣어서 지문 같은 값을 뽑아내요. 그리고 데이터 문서는 '나는 스키마 abc123...을 따른다'라고, 이름이나 버전 번호가 아니라 해시로 스키마를 가리키는 거예요. 해시는 내용이 한 글자라도 바뀌면 완전히 달라지니까, 같은 해시를 가리키는 스키마는 세상 어디에서 받아오든 반드시 같은 내용이라는 게 수학적으로 보장돼요.

여기서 '불변'이라는 성질이 자연스럽게 따라와요. 스키마를 고치고 싶으면 기존 스키마를 수정하는 게 아니라, 새 스키마를 만들고 새 해시를 받는 거예요. 깃(Git)의 커밋 해시나 도커 이미지의 다이제스트를 떠올리면 이해가 빠른데요. 커밋 abc123은 영원히 그 내용이고, 누가 몰래 바꿔치기할 수 없잖아요. package-lock.json이 라이브러리 버전을 정확히 못 박아서 '내 컴퓨터에선 되는데요' 문제를 줄여주는 것과 같은 원리를 데이터 스키마에 적용한 셈이에요.

기존 방식과 뭐가 다른가요

사실 스키마 관리 문제를 풀려는 시도는 전부터 많았어요. JSON Schema는 $id 필드에 URL을 넣어 스키마를 가리키는데, URL 너머의 내용은 언제든 바뀔 수 있다는 게 약점이에요. 어제의 v2와 오늘의 v2가 다를 수 있는 거죠. Kafka를 쓰는 분들이라면 Confluent Schema Registry도 떠올리실 텐데요. Avro나 Protobuf 스키마를 중앙 저장소에 등록하고 ID를 발급받는 방식이라 관리는 되지만, 그 중앙 레지스트리라는 단일 지점에 모두가 의존해야 하고, 조직 바깥과 스키마를 공유하기는 어렵거든요. 반면 해시 기반 방식은 중앙 서버가 없어도 돼요. 해시만 맞으면 스키마 파일을 이메일로 보내든 CDN에 올려두든 어디서든 검증이 되니까요. 이런 접근을 '콘텐츠 주소 지정(content addressing)'이라고 부르는데, 분산 파일 시스템인 IPFS나, 함수 코드 자체를 해시로 관리하는 유니슨(Unison)이라는 프로그래밍 언어가 같은 철학을 공유하고 있어요. 데이터 포맷 세계에도 이 흐름이 번지고 있다는 신호로 읽을 수 있는 거죠.

한국 개발자에게는 어떤 의미일까요

당장 프로덕션에 도입할 포맷이라기보다는, 이 설계 철학을 눈여겨볼 가치가 있어요. 마이크로서비스 수십 개가 이벤트를 주고받는 환경이라면 '이 메시지는 정확히 어떤 스키마로 만들어졌나'를 애매함 없이 증명할 수 있다는 건 꽤 큰 매력이거든요. 특히 이벤트 소싱처럼 몇 년 치 데이터를 쌓아두고 나중에 다시 읽어야 하는 시스템에서는, 과거 데이터가 가리키는 스키마가 영원히 변하지 않는다는 보장이 데이터 자산의 수명을 크게 늘려줘요. 물론 신생 포맷의 숙명도 있어요. 언어별 라이브러리, IDE 지원, 검증 도구 같은 생태계가 아직 없다시피 하니까요. 지금은 사이드 프로젝트에서 개념을 실험해보거나, 사내 스키마 관리 체계에 '해시로 고정한다'는 아이디어만 빌려오는 것도 충분히 의미 있는 활용법이에요.