여러가지 데이터 표현 양식 비교

XML - 과거의 찬란했던 데이터 교환 양식(라떼는 말이야~). 지금은 JSON에 밀려...

XML

• 유연함
• 시스템이 읽고/쓰기 쉬움
• 유효성 검증(Validation)
• 주석
• IDE의 지원
• 사람이 읽고 쓰기 어려움
• 장황함

 

유연하고 시스템 친화적이며 데이터 검증에 매우 강력하다. 따라서, 엔터프라이즈에서는 여전히 강한 면모가 있다. 하지만, 개발과 디버깅은 사람이 한다. 사람이 읽고 쓰기 어려다는 것은 치명적인 단점이다.

 

JSON - "왕위를 계승하는 중입니다. (Succeeding You.)". 데이터 교환 양식의 현재의 승자.

JSON

• 사실상 모든 프로그램 언어에서 지원
• 사람과 기계 모두 읽고 쓰기 쉬움
• 주석을 지원하지 않음
• 빈약한 스키마 지원

 

데이터 교환 양식의 사실상 표준(De facto standard)이다. 주석을 지원하지 않아서 설정 파일에 사용하기는 좋지 않다. 또한 스키마 없는 유연함은 양날의 검이다. 형식의 표준이 필요(예를 들면, DASH 표준)하거나 데이터 검증이 중요한 엔터프라이즈 영역에서 JSON은 취약하다.

 

CSON - JSON이 있지만, 바퀴를 재발명해보자

• JSON 보다 간단하고 명확한 문법
• 중괄호({}) 없는 JSON

 

CoffeeScript Object Notation. CoffeeScript 신봉자가 아니면, 그냥 JSON을 쓴다.

 

EDN - 살아있는 화석의 진화

• Lisp과 유사. 아니 Lisp (왜냐하면, Lisp은 데이터이면서 코드인 언어)

 

Clojure로 개발하고 Clojure 끼리만 소통한다면 이 형식을 사용한다. Clojure 안에서는 설정 파일이나 데이터 교환 형식 둘 다 최선의 선택이다.

 

Binary serialization formats - 기계의, 기계에 의한, 기계을 위한 표현 양식 

• 높은 성능
• 오류의 여지가 적음
• 메세지 자체를 사람이 읽기 매우 어려움

 

내부 시스템 간에 빠른 통신이 필요하면 선택한다. 현재 대세는 ProtoBuf를 사용하는 gRPC이다. 밀려났지만 나름 선전했던 경쟁자로 Thrift가 있다.

 

YAML - 설정 파일 형식에서 떠오르는... 그런데, TOML이 나와버렸어.

• 가벼움
• 사람이 읽기 매우 좋음
• 주석 지원
• 들여쓰기와 개행에 조심해야 함
• 데이터 형식이 값에 의존함

 

설정 파일 형식으로 나쁘지는 않다. 그러나, TOML이 널리 퍼진 지금의 싯점에서 매력이 있을지 의문이다.

 

TOML - 데이터 교환 형식에 JSON이 있다면, 설정 파일 형식에는 TOML이 있다.

• 잘 만들어진 명확한 표준
• 사람이 읽고 쓰기 쉬움
• 많은 프로그래밍 언어에서 지원
• 주석 지원

 

가벼운 설정 파일을 위해서 비교적 최근에 고안된 형식이다. 설정 파일 형식으로 TOML의 선택은 옳다.

 

INI - 윈도우가 세상을 점령하던 시대에 강자. 지금은 뒷방 노인

 

상위 호환 TOML이 있는데 굳이 INI는 왜?

 

환경 변수(Environment Variable) - 도커(docker)가 뜨면서 재기에 성공한 설정 방법

• 거의 모든 시스템에서 기본으로 제공
• 계층적, 집합적 표현의 부족함

 

도커 기반으로 개발을 시작한다면 고려해본다. 

 

결론

일반적으로, 데이터 교환 형식은 JSON, 설정 파일 형식은 TOML을 사용한다.

내부적인 시스템 간의 통신에서 고성능과 속도가 필요하면 gRPC를 고려한다.

Docker로 구축할 예정이라면 환경 변수도 좋은 선택이다.