Data - XML VS JSON

이 두 데이터의 형식은 아래의 참고문헌들을 참고하여, 작성한다.

다만, 내가 가진 CS 지식의 깊이로 인해 잘못된 해석이 있을 수 있다.

 

* 일단 왜 찾아보았는가?

- 현재 진행하고 있는 프로젝트에서 Data Parsing을 xml 파일로 하고 있고, 파싱을 기준으로 보면 JSON 이나 Binary 로 관리되는 BSON 이 강력하다는 이야기를 들은 기억이있어, ToyProject 의 Data Loading Time을 줄일 수 있는가에 대한 의문이 들어 찾아보게 되었다.

 

[ 총평 ]

- 참고문헌을 보고 총평을 먼저 제시하자면, 일단 둘은 크게 비슷한 영역이 있겠지만 완전히 동등한 입장은 아닌것 같다.

자료를 보면 많은 개발자가 XML 이 JSON을 대체했어! JSON은 뛰어나! 라고 이야기하나보다. 

(번역해서 본거긴 하지만, 텍스트 자체가 많은 개발자들이 제한된 시선으로 볼때 뛰어나게 보는 경향이 있는듯한.. 텍스트가 많았다.)

저기서 추천하는 방법은 JSON은 데이터 교환이 비교적 간단하고 빠르게, 개인 사이드 프로젝트나 소 프로젝트 등에, XML 은 설계상 복잡한것으로 사용하는 것을 추천하는 것으로 보인다.

 

가장 중요한건, 이 참고문헌의 참고문헌들이 업계발전 속도에 비해 비교적 최근것이 아닌것으로 보여 지금도 이렇다! 라고 말할 수는 없을것으로 보인다.

 

내 사이드 프로젝트 파싱용으로는 아마 생각해왔던 BSON을 사용할 것 같다.

 

[ 역사 ] - 1부 정리

- 현재 거의 모든 컴퓨터 App(응용 소프트)은 XML, JSON이 두 가지 표준 메시지 방식 중 하나에 의존한다. 

자료기준 최근엔, JSON이 XML을 추월하여 사용되고 있으나, 둘의 개발 목적은 많이 다르게 시작되었다.

이 역사를 들어가기 위해선 웹 1.0 , 웹 1.1 , 웹 2.0 이런 IT 진화 역사에 대해 나열되어 있는데, 간단히 알아보자면, 

IBM - SGML 발명 -> SGML의 파생인 HTML -> XML 고안 -> 자유로운 HTML 확장 순으로 역사가 진행되었다고 한다.

여기서 XML 은 마크업 언어 자체라기보단, 정의를 위한 한 단계 위 사양을 목적으로 만들어진 것으로 보인다.

당시 XML 의 궁극적 목표는 " 타 시스템 간의 보편적인 데이터 교환 문제의 해결 " 이었다.

그래서 W3C 가 구성되었다고 한다. 

그렇게 XML은 호환성이라는 큰 궁극적 목표를 가지고 모든 종류에 대한 데이터, 통신, 검증하는 기술을 제공하고 오랜기간 발전해왔다.

 

이후 Java, .Net, AJAX 로 이어지는 역사 이후, JavaScript에서 활용되고 기존 지배적으로 사용되던 XML 보다 빠른 반응속도에 의해 더욱 선호하게 되는 수준으로 이어졌다.

 

JSON은 JavaScript App 의 Data 기본 형식이다. 이는 즉, JavaScript 의 대중화가 JSON 메시지에 유저 친화적일것이게 될 것이고, 그걸 튜닝하거나 개발하는 지원자체가 많아졌다고 보인다.

 

현재는 StackOverflow의 질문 태그 점유가 JSON이 XML을 압도하는 수준이다.

 

[이미지 0. StackOverFlow Question Rate]

단순함과 간결함으로 빠른 반응속도를 가져오는 JSON은 기사대로 XML 스키마 등과 같은것들이 쓸데없이 비대해 보일 수 있게 할 것 같긴하다. 

그러나, 역사를 보면 둘의 개발 궁극 목표는 다른것인것 같고, 대체한다는 의미는 사용하기 힘들 것 같다.

정확히 발명 의의를 알고 제대로 스펙에 갖춰 사용하는게 중요하긴 할 것 같으니까 말이다.

 

[ 심층 분석 ] - 2부 정리

- 제목 자체는 JSON, XML Data 에 대한 심층분석, 양 쪽을 다 분석하는 아티클처럼 구성되어 있지만, 그 내용은 거의 JSON에 대한 특성이 기술되어 있는듯하다. JSON의 특성과는 반대니까 이해하란건지...

 

아티클 예시를 빌리자면, 생산(1), 교환(2), 소비(3)의 세가지 시퀀스로 인해 기업은 만들어놓은 데이터를 제공하고, 소비자는 그 데이터를 제공받고 그에 따른 댓가를 지불한다. 이게 기본개념인 것인데,

여기서 타 플랫폼을 신경쓰지말고, 단순한 데이터 교환만을 지향한다. 뭐.. 복잡성에 대한 확장이나, 타 플랫폼에 대한 확장을 포기하겠다! 이러면 JSON은 최적의 솔루션일 것이다. 라고 이야기를 하는 것으로 보인다. 

 

JSON이 크게 결함이 보이는 곳은, 교환에 대한 복잡성, 비표준으로 인한 타플랫폼에 대한 확장지원성 등에서 많이 크게 결함이 보인다고 한다.

 

[이미지 1. 확장에 따른 JSON의 변화?]

다시 아까 생산,교환,소비에 대한 예시를 가져와서 유럽은행 SWIFT 로 예시를 들면, 많은 설명이 있는데, SWIFT는 에러의 최소함을 지향하기때문에 뭐.. 검증과정이 많은 것으로 보인다.

 

아래 비.씨.디로 써진 텍스트를 제외하고 아래처럼 생각해보자.

a : 실제 교환하려는 JSON 데이터

b : 메시지 유효성 검사

c : 인증 코드

d 는 일단 제외 보류

 

그러면 실제로 우리가 교환하고 싶은 JSON 데이터는 저렇게 a 만큼 작은데 b 메시지 유효성 검사 코드, c 인증 코드 등의 데이터를 추가해야한다. 

이렇게 추가할때마다 JSON이 비대해지는건 XML도 같은 처지겠지만, JSON은 형식 자체 통신에 유리하기때문에 통신만 할 수 있지, 일반 유효성 검사등을 검사할 수 없다는 문제가 있다.

이런 문제점은 어떻게 적용되나 확인해보면 각 양단에 그 데이터에 대해서 프로그래머가 유효성 검사 코드를 추가해야하고 확장될때마다 관리를 해야한다. 라는 내용으로 받아들였다.

 

이렇게 복잡한 인증 요구 사항에 대한 결함이 있고, 양단에 작업되지 않으면 SWIFT에서 지향하는 최소한의 에러발생에 위배가 되기때문에 이런 요구절차가 까다로운 스펙에 대한 JSON의 사용은 적합하지 않다는 것이다.

 

2부의 결론은 : 인증이나, 통신 요구 사항이 까다롭지 않은 타겟에 대한 JSON의 사용은 적극권장된다.

단, 요구스펙에 대한 확장이 있을 시, JSON 통신에 대해 손댈것이 많아질 것. 이라는 느낌을 받았다. 

 

[ 두 메시지 형식에 대한 미래 ] - 3부 정리

- 위에서 설명했던 검증 확장에 대한 문제는 JSON -> XML 로 작성하는 것으로 문제를 손쉽게 해결할 수 있다.

XML 스키마 데이터에 추가되는 Byte 형 몇 줄에 대한 효율성을 포기한다면 데이터 교환에 대한 더 넓은 범위의 기능을 지원 받을 수 있기 때문이다.

XML 메시지는 XML 특성인 Namespace 와 Instance 유형을 활용할 수 있기 때문에, 속성이나 인스턴스에 대한 유효성 검사가 되고 이 특성은 XML 표준이기 때문에, 어디서든 지원할 수 있다.

XML 은 표준으로 등록되어 확장성도 뛰어날 뿐더러, 오류에 대한 위험을 감소할 수 있다.

굳이 말하자면 XML 은 기능적으로 강력하며, 느리지만 탄력적이라는 것이다.

 

JSON의 근본적 결함은 표준이 아님에 따른 확장성에 대한 문제이다.

엿볼수 있는 두 메시지 형식의 미래는 XML은 이미 솔루션으로서 자리잡았기 때문에 필요하다면 더욱 발전하겠지만,

JSON 의 미래는 JSONx라는게 개발된 현재처럼 JSON의 형식을 유지하면서 XML 의 기능을 포함할 수 있도록 하는 미래를 엿볼 수 있을 것이다.

 

[ 참고 자료 ] 

1부 - XML VS JSON 의 역사 : https://www.toptal.com/web/json-vs-xml-part-1

A Deep Look at JSON vs. XML, Part 1: The History of Each

 

2부 - XML VS JSON 심층 분석, 양측의 장단점 : https://www.toptal.com/web/json-vs-xml-part-2

A Deeper Look At JSON vs. XML, Part 2: A Comparison

 

3부 - XML VS JSON 두 표준 메시지 방식의 미래 : https://www.toptal.com/web/json-vs-xml-part-3

A Deeper Look at JSON vs. XML, Part 3: The Future

 

번외 - JSON의 흠? 양방향 관계 지원 : https://www.toptal.com/javascript/bidirectional-relationship-in-json

Bidirectional Relationship Support in JSON