[dW Review] 데이터 교환 표준형식 정하기 YAML & JSON

예전에는 데이터 교환에 XML을 많이 썼다면 요즘에는 JSON을 많이 씁니다. 아니, 많이 쓰는걸 넘어서서 JSON이 대세인것 같습니다. XML이 한참 잘 나갈때는 모든 설정파일들을 왠지 XML로 만들어야 할 것만 같았습니다.

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE configuration
  PUBLIC "-//ibatis.apache.org//DTD Config 3.0//EN"
  "http://ibatis.apache.org/dtd/ibatis-3-config.dtd">
<configuration>
    <typeAliases>
        <typeAlias type="com.ibm.developerWorks.examples.ibatis.model.Automobile"
            alias="Automobile" />
    </typeAliases>
    <environments default="development">
        <environment id="development">
            <transactionManager type="JDBC" />
            <dataSource type="POOLED">
                <property name="driver" 
                    value="org.apache.derby.jdbc.EmbeddedDriver" />
                <property name="url" value="jdbc:derby:/tmp/MyDB" />
            </dataSource>
        </environment>
    </environments>
    <mappers>
        <mapper resource="automobile-mapper.xml" />
    </mappers>
</configuration>

[ibatis XML 구성 파일인 ibatis-config.xml]

한참 XML을 광범위하게 쓰던 시절.. 그런데 어찌된 일인지 아무리 주입식 교육을 받아도 XML이 편한건지는 잘 모르겠다는 생각이 들곤했습니다. 복잡한 형태의 Document를 만들때는 그렇다고쳐도, 단순히 키/값 쌍으로 이루어진 데이터를 이용할때도 XML을 사용하는 건 확실히 가독성에 대한 정신적 시험에 들곤 합니다. 그런 사람이 비단 저 뿐만은 아니었겠지요.

데이터 교환에 있어서 대안을 찾아보는 시도는 꽤 오래전부터 진행되었습니다.

XML Matters: YAML improves on XML (2002년기사)
http://www.ibm.com/developerworks/xml/library/x-matters23.html

YAML은 괜찮은 시도였습니다. 스스로가 XML과 다른 마크업 언어로부터 배운 교훈들을 반영한 언어라고 말했던것 처럼 꽤 읽기 편하면서도 문서구조를 어느정도 지원해 줬습니다.

YAML(YAML Ain't Markup Language)
http://www.yaml.org/spec/history/2001-05-26.html

RFC가 공개된 시점이 2001년이니 지금으로부터 무려 10년전에 만들어 졌네요. 처음에는 약어가 Yet Another Markup Language이었으나 후에 재귀적인 문장 YAML Ain't Markup Language으로 바뀌었습니다. : )
어쨌든 10년전에 만들어졌는데 주변에서 그다지 안쓰는 것 보니 아마 앞으로도 그다지 안 쓸것 같습니다. XML 쓰거나 JSON 쓰거나 둘 중 하나로 갈 듯 싶습니다.

JSON RFC(2006년)
http://www.ietf.org/rfc/rfc4627.txt?number=4627

그런데 사실 YAML은 스스로 JSON과의 관계를 다음과 같이 밝히고 있습니다.

"JSON은 YAML의 서브세트입니다. JSON 배운 사람은 쉽게 더 확장 가능한 YAML로 넘어올수 있다지요!"

이건 "내가 사실 네 형이다!"급의 발언입니다. 그러면서 추가로 설명을 다음과 같이하고 있습니다.

"JSON과 YAML은 둘 다 사람이 읽기 편한 데이터 교환 포맷을 목표로 합니다. 다만, JSON은 간결함과 범용성에 초점을 맞추고 있고, YAML은 그와 동시에 임의의 고유 데이터 구조들에 대한 직렬화를 지원합니다"

[출처 : 1.3. Relation to JSON http://yaml.org/spec/1.2/spec.html#id2759572]

그리고 YAML 1.2기준으로 YAML파서는 JSON을 정상 파싱해 낸다고 하네요.
재밌는건 YAML은 자신의 공식사이트(http://yaml.org/)를 YAML 구조로 만들어 놨다는 점입니다.

YAML은 다음과 같은 XML을 그 아래와 같이 표현해 냅니다.

<?xml version="1.0"?>
<club>
  <players>
    <player id="kramnik"
            name="Vladimir Kramnik"
            rating="2700"
            status="GM" />
    <player id="fritz"
            name="Deep Fritz"
            rating="2700"
            status="Computer" />
    <player id="mertz"
            name="David Mertz"
            rating="1400"
            status="Amateur" />
  </players>
  <matches>
    <match>
        <Date>2002-10-04</Date>
        <White refid="fritz" />
        <Black refid="kramnik" />
        <Result>Draw</Result>
    </match>
    <match>
        <Date>2002-10-06</Date>
        <White refid="kramnik" />
        <Black refid="fritz" />
        <Result>White</Result>
    </match>
  </matches>
</club>

---
players:
  Vladimir Kramnik: &kramnik
    rating: 2700
    status: GM
  Deep Fritz: &fritz
    rating: 2700
    status: Computer
  David Mertz: &mertz
    rating: 1400
    status: Amateur

matches:
  -
    Date: 2002-10-04
    White: *fritz
    Black: *kramnik
    Result: Draw
  -
    Date: 2002-10-06
    White: *kramnik
    Black: *fritz
    Result: White

괜찮네요.

제가 이렇게 YAML소개를 했으니 YAML에 대해 관심이 조금 올라가셨을 수 있습니다. 그렇다면 다음 글을 읽어보시길 권해드립니다. YAML파는 이야기 아닙니다. :)

XML Matters: Ajax: XML의 다양한 대안들 (한글)
http://www.ibm.com/developerworks/kr/library/x-matters48/index.html

위 기사에는 특정 포맷/언어를 이야기 하지 않고, 우선 XML의 대안들의 기준에 대해 이야기 합니다.

무엇을 선택하여야 하는가?
- 우선, 가장 단순한 방식 또는 가장 복잡한 방식으로 포맷을 사용할 수 있다.
- 생성, 읽기, 파싱, 프로세스 중에서 어떤 것이 가장 복잡한 것인지를 파악해야 한다. 예를 들어, XML은 그 자체로 복잡한 편이지만, 파서가 브라우저에 이미 있기 때문에 파싱은 오히려 단순하다.
- 복잡성은 데이터의 유형에 상당히 많이 의존한다. 스프레드시트나 데이터베이스처럼, 고정된 구조를 갖고 있는가? 워드 프로세싱 문서나 블로그 포스트처럼 유연한(loosely) 구조를 갖고 있는가? 항공기 매뉴얼 같은 대형 문서인가, 응답 코드 같은 작은 데이터 조각인가? 데이터 세트가 크다면, 이것을 한 번에 보낼 것인가, 아니면 필요할 때마다 작은 조각 단위로 보낼 것인가? 큰 데이터를 작은 조각 단위로 나누는 것은 얼마나 어려우며, 받는 쪽에서, 작은 조각들을 올바르게 조합하려면 얼마나 많은 정보가 필요한가?

자신에게 맞는걸 선택하라는 이야기인거죠. 이때 다음과 같은걸 고려하라고 이야기 합니다.

- 장황함/대역폭(특별한 경우를 제외하고는, 이러한 요소는 여러분이 생각하는 것만큼 중요하지 않다.)
- 가독성(작성 가능성, 관리성)
- 파싱 난이도(클라이언트 측과 서버 측)
- 파싱 속도(네이티브 대 스크립팅)
- 정보 손실(ordered pairs -> dictionary -> sets)
- 유연성(가끔은, 덜 유연한 것이 더 나을 때도 있다.)
- 언어 이식성(얼마나 많은 언어들을 사용할 수 있는가?)
- 정확성(포맷에 어느 정도 순응하는가?)
- 라운드 트리핑 (Round-Tripping) (Markdown -> XHTML -> Markdown, 얼마나 많은 데이터 손실이 있는가?)

요즘 대세에 맞춰서 단순 키/값 교환의 경우 JSON을 선택하시는 것이 좋지만, 애플리케이션을 만든다면 근간이 되는 데이터 구조선택에 좀 더 고민할 필요가 있는것 같습니다. 무조건 XML은 제외도 별로 좋은건 아니겠죠? : )

 {
    "이름": "테스트",
    "나이": 25,
    "성별": "여",
    "기혼": true,
    "주소": "서울특별시 양천구 목동",
    "특기": ["농구", "도술"],
    "가족관계": {"#": 2, "아버지": "홍판서", "어머니": "춘섬"}
    "회사": "경기 안양시 만안구 안양7동"
 }

[읽기 편한 JSON! 하지만 한계도 많다. 그리고 꼭!! 쌍 따옴표를 키/값 모두에 적길 권장한다!]


데이터 구조 선정에 참고할만한 기타 기사

웹 프로젝트를 위한 간단한 JSON 제어기 빌드하기
http://www.ibm.com/developerworks/kr/library/wa-jsoncontroller/index.html

Ajax 마스터하기, Part 10: 데이터 전송에 JSON 사용하기 (한글)
http://www.ibm.com/developerworks/kr/library/wa-ajaxintro10/
인상깊은 문구: "거듭 말하지만, 여러분은 우선 name/value 쌍을 사용하는 것을 늘 생각해야 한다. 이것은 대부분의 비동기식 애플리케이션에서 생기는 문제들에 대한 가장 간단한 솔루션이고, JavaScript에 대한 기본적인 지식만 있어도 간단히 해결된다."