Cloud Computing On Demand

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

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

터미널에서 대량의 로그 데이터를 다루는데 무척 유용한 명령이 awk 입니다. awk 는 기본적으로 파일 내의 컬럼 구분자가 공백이라는 가정하게 동작합니다. 데이터를 추출하려는 원본 로그 파일이 공백을 구분자로 이용하는 경우 문제가 없지만 CSV (Comma Seperated Value) 형태 혹은 파이프와 같은 구분자로 컬럼을 식별하는 경우에는 구분자가 어떤 문자인지 awk 에게 전달해 주어야 합니다.

위와 같이 사용자들이 접근한 도메인에 대한 이력을 정리한 로그파일이 있다고 가정해 보겠습니다. 각 도메인별로 사용자의 요청 횟수를 카운트 하고 싶다면 아래와 같은 명령이 머릿속에 떠오르실 겁니다. 

하지만 위의 명령은 awk 의 기본 구분자인 공백을 사용하기 때문에 원하는 결과가 제대로 나오지 않게 됩니다. 로그 파일이 콤마를 명시적인 구분자로 사용하고 있기 때문에 아래와 같이 awk 의 파라메터로 구분자를 알려주어야 합니다. 

자주 사용하지만 자꾸만 잊어버리는 명령어들 시리즈였습니다 ;-)

터미널에서 다량의 로그, 텍스트 파일을 핸들링 할때 awk 명령을 파이프로 연결하여 작업하는 경우가 많습니다. 예를 들어 텍스트 파일의 첫번째 컬럼이 "A" 인 행의 세번째 필드를 출력하는 방법은 대략 아래와 같을겁니다.

그런데 가끔은 특정한 조건을 만족하는 행의 모든 내용을 출력하고 싶을 때가 있습니다. 컬럼이 몇 개 안된다고 하면 print 명령으로 모든 컬럼을 지정하면 되겠지만 컬럼이 많다면 쉽지 않습니다. 이때는 print 의 파라메터로 $0 을 넘기면 모든 컬럼이 출력되게 됩니다.

자주 사용하지 않으면 잊어버리기 때문에 기억을 위해 남겨둡니다.

- NoPD -

HTTP/2 에 대한 이야기들 중 근래에 가장 논란이 되고 있는 것 중 하나가 TLS 에 대한 요구사항일 것 같습니다. 처음 SPDY / HTTP/2 에 대한 이야기가 나오면서 TLS 가 필수 조건이라는 소식에 이제 웹 환경이 완전히 Secure 로 넘어간다는 생각들을 많이 했었습니다. 그런데 결국 TLS 를 이용해야만 한다는 것은 연결을 만드는 과정에 오버헤드가 발생한다는 것이고 Let's Encrypt 등의 도움에도 불구하고 서비스 혹은 상황에 따라 부담이 될 수 있는 여지가 있었습니다.

이 때문에 HTTP/2 Working Group 에서는 암호화 되지 않은 HTTP/2 프로토콜 스펙에 대한 이야기가 오가고 있었고 정확한 시점은 확인해 보지 못했지만 TLS 의 지원이 필수는 아닌 것으로 정리된 것 같습니다. 스펙상으로 이부분은 h2c 라는 용어로 통칭되고 있고 TLS 터널링을 이용하지 않은 Non-encrypted 전송에 대한 이야기라고 이해하시면 되겠습니다 (자세한 이야기는 여기에 : https://http2.github.io/faq/#does-http2-require-encryption)

다만 표준의 진행이 이렇게 가고 있다 하더라도 브라우저들이 HTTP/2 스펙을 구현한 상황을 확인해 보면 이야기는 다소 달라집니다. 현재까지 HTTP/2 를 지원하는 것으로 알려진 모든 브라우저들은 HTTP/2 프로토콜 이용의 조건으로 TLS Handshake 를 전제하고 있습니다. 웹 컨텐츠를 소화하는 방식이 웹 브라우저만 있는 것은 아니겠지만, 대다수가 브라우저 기반이라고 가정했을 때 원본 서버에서 HTTP/2 를 이용하기 위한 전제조건으로 TLS 를 제공해야 한다는 것은 변함이 없을 것 같습니다.

- NoPD -