728x90

이유는 알 수 없습니다만 여러곳에서 지속적으로 사용자 유입이 되고 있는 포스팅이 "JSON 포맷에서 주석을 사용할 수 있을까?" 라는 글입니다. 유입이 많은 이유로 생각되는 것은 많은 분들이 JSON 포맷을 사용하면서 주석 사용에 대한 욕망(?)이 있고, 이에 대한 방법을 찾으려다 검색 유입이 되는 것이라는 생각이 듭니다. 저 역시 글을 쓴 이유가 JSON 포맷에서 주석을 왜 쓸 수 없을까 였기 때문에 결국 같은 갈망을 가지고 검색후 실망-_-이라는 수순을 밟고 있는 안타까운 현실이라 하겠습니다.



요즘 읽고 있는 책 중 하나가 제이펍에서 출간한 "자바스크립트와 Node.js 를 이용한 웹 크롤링 테크닉"(책 내용 자세히 보기 [바로가기]) 이라는 책입니다. 곧 이직을 계획하고 있어서 여유 시간을 알차게 활용하고자 Node.js 와 파이썬(Python), 그리고 인프라스트럭쳐 배포 자동화에 심취해 있는데요, 여튼 이 책을 읽던 중 JSON5 에 대한 정보를 습득하게 되어 간단하게 공유해 보고자 합니다. 



JSON5 (http://json5.org) 는 JSON 이 가지고 있는 몇 가지 단점들을 ECMAScript 표준의 진화에 맞추어 쓸만한 형태로 개선하고자 하는 일종의 제안으로 시작된 프로젝트입니다. 시작된지는 좀 된 과제이지만 여전히 가야할 길을 열심히 걷고 있는 과제이기도 합니다. JSON5 는 JSON 의 규격을 조금 더 완화시키고 유연하게 만들어 다양한 데이터 포맷을 수용하고, 사람들에게도 더 친숙한 (= 주석으로 지저분해지는?) 형태로 만드는 것을 목적으로 하고 있습니다. JSON5 포맷으로 구성한 데이터 포맷의 예를 살펴보면 변화하는 부분을 쉽게 인지할 수 있습니다.



글의 시작에 이야기 했던 주석은 한줄 주석, 혹은 여러 줄로 구분된 주석 형태를 제공하고 있습니다. Key 를 표현할 때 꼭 사용해야 했던 따옴표 역시 제거되어 key 입력에 대한 불편함이 사라졌고, 파싱 에러의 대부분을 차지하고 있는 콤마에 대한 사용도 완화되어 어레이의마지막에 콤마가 들어가도 무방하도록 변경되었습니다. Value 에 멀티라인 텍스트가 들어갈 수 있는 것도 고무적인 부분입니다. 그 외에 Hex 형태의 표현 허용, 소수점 이하 표기법의 자유도 등도 눈에 띄는 부분입니다. Node.js 를 사용하는 경우 npm 을 통해서 json5 모듈을 쉽게 다운로드 받아 사용해 볼 수 있습니다.


$ npm install json5


모듈이 설치되면 Require 문으로 json5 모듈을 불러와야 한다는 점을 제외하면 parse 와 stringify 메소드를 이용해서 기존 JSON 내장 객체처럼 사용할 수 있습니다. 간단한 Node.js 예제코드는 아래와 같습니다.


var JSON5 = require('json5');

var fs = require('fs');

var json5 = fs.readFileSync("data.json5", "utf-8");


var obj = JSON5.parse(json5);


console.log(obj);

console.log(obj.multi_line);

console.log(obj.hex_data);

console.log(obj.items);


당연한 것이겠지만 JSON5 를 이용하여 데이터를 주고 받을 각 주체들은 JSON5 를 지원할 수 있도록 준비되어야 합니다. Node.js 이외의 다른 언어에서도 미리 준비된 패키지가 있을 것으로 생각됩니다만, 규격의 변경에 따른 사용 가능 여부를 확실히 점검하고 넘어가는 것이 좋을 것 같습니다. 주석을 이용할 수 있다는 것은 분명 의미있는 변화이지만 이로 인해 증가할 수 있는 데이터 파일의 크기, 새로운 처리 모듈의 사용 등은 고민을 해봐야 할 부분입니다.


/* 추천도서 */ API 설계 실무에 바로 사용하는 JSON [자세히 살펴보기]






728x90
728x90

2017.5.4 추가) 혹시 JSON 에서 주석을 어떻게든 써야겠다고 생각되시면 JSON5 규격에 대해서 살펴보시기 바랍니다 [바로가기]

 

고난이도의 알고리즘을 이용하여 프로그램을 만들다가도 가끔 멍~한 질문에 당황할 때가 있습니다. API 의 사용이 대중화되고 그 중요성이 커지면서 API 좀 다루어 보지 않은 엔지니어를 찾아보기 힘든게 요즈음입니다. API 는 초기에 SOAP 과 같은 오버헤드가 큰 방식들이 사용되다가 요즘은 JSON 형태의 경량화된 포맷이 사실상의 표준 처럼 사용되고 있습니다. 아, 물론 단순한 스트링과 델리미터로 값을 전달하는 경우도 여전히 있습니다만 가독성이나 주고받는 자료의 가독성, 관리 용이성 등의 관점에서 별로 좋은 접근은 아닙니다.

 

JSON 이 대중화되어 사용되다 보니 API 를 통해 리턴 받은 데이터이든 API 를 향해 던지는 데이터이든 습관적으로 JSON 포맷을 머릿속에서 이해하고 사용하고 있습니다. 그런데 오늘 문득... 그런 생각이 들었습니다. JSON 포맷에는 주석 혹은 코멘트(Comment)를 위한 표준이 정의되어 있는 걸까요? 만약 정의되어 있다면 어떤 형태로 사용해야 하는 걸까요? 이런 고민과 논란이 2012년 즈음에 있었던 것 같습니다. JSON 표준의 창시자로 알려진 더글라스 크록포드(Douglas Crockford)가 구글 플러스에 올렸던 업데이트를 인용해봤습니다.

 

 

 

글씨가 좀 작아서 잘 안보이시는 분들을 위해 본문만 다시 한번 인용해 봤습니다. 절대 블로그 포스팅 분량을 늘리기 위한 행동을 아닙니.......

 

I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't. 

 

Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser.

 

결론적으로 JSON 에는 주석 혹은 코멘트가 들어가지 않는것이 맞다고 창시자는 이야기하고 있습니다. 상호 호환성과 같은 시스템 간의 연동, 이종 시스템들간의 이해를 방해하지 않게 하겠다는 것이 의도인데요, 꼭 필요한 경우라면 코멘트를 사용하되 최종적으로 JSON 파서들은 코멘트가 제거된 데이터를 핸들링 할 수 있게 하는 것을 이야기하고 있습니다. 실제로 시장에 유통되고 있는 일부 JSON 파서 혹은 구현체에서는 JSON 코멘트를 허용하되 더글라스가 언급한 것처럼 최종적으로는 제거하는 케이스들도 있는 것으로 보입니다.

 

JSON 을 사용한다면, 조금은 아쉽지만, 주석 / 코멘트를 사용하지 않는 것이 미덕이겠습니다. 꼭 필요하면 내부적으로만 사용하시되 외부와 연동하는 단계에서는 꼭~ 제거하는 센스가 필요하겠네요! 

 

jq로 JSON 쉽게 다루기(1), 반복되는 배열에서 특정 속성 뽑아내기

JSON을 다루는 것은 개발자에게는 숙명입니다. 그래도 SOAP 보다 편리하고 쉽다는게 어디냐며 위로해 보지만 할 때마다 새롭고 매번 처음 보는 것 같이 헤메는 것이 또한 JSON 다루기의 특징이기도

ondemand.tistory.com

/* 추천도서 */ - API 설계 실무에 바로 적용하는 JSON [자세히 살펴보기]

 

 

 

728x90

+ Recent posts