ask@coovil.com
XML vs JSON 비교 ⁃ 웹 API를 위한 더 나은 선택
XML vs JSON 비교
웹 API를 위한 더 나은 선택
신규 웹 API를 만들 때 고려하는 요소에는 여러 가지가 있지만 그 중 하나가 API에 전달할 ‘인자 데이터’와 ‘응답받는 데이터’의 형식일 것입니다.
대부분의 웹 API 개발자나 웹 API 이용자들은 ‘JSON’을 인자나 응답 데이터의 형식으로 이용하는 것에 대하여 너무나도 당연하게 받아들일 정도로 JSON은 보편화되고 가장 많이 이용되는 데이터 형식입니다.
반면 ‘XML’은 오래되고 여전히 광범위하게 사용되지만 적어도 웹 API 관련해서는 점차 외면당하고 있는 현실입니다. 많은 개발자가 XML이 갖는 상대적 장점에 대해서 잘 모르지만 편견만으로 JSON을 맹목적으로 채택하는 것은 안타까운 일입니다.
이미 인터넷 상의 많은 글들이 JSON이 XML에 비해 갖고 있는 여러가지 강점에 대하여 말하고 있기 때문에 같은 내용의 글은 의미가 크게 없을 것입니다. 따라서 이 글은 거꾸로 적어도 웹 API의 인자/응답 데이터 형식으로서 XML이 JSON에 비해 어떠한 강점을 갖고 있는지 말해보려고 합니다.
먼저, 아래의 웹 API 개발자 관점에서 XML과 JSON을 비교한 내용을 보시기 바랍니다.
대부분의 웹 API 개발자나 웹 API 이용자들은 ‘JSON’을 인자나 응답 데이터의 형식으로 이용하는 것에 대하여 너무나도 당연하게 받아들일 정도로 JSON은 보편화되고 가장 많이 이용되는 데이터 형식입니다.
반면 ‘XML’은 오래되고 여전히 광범위하게 사용되지만 적어도 웹 API 관련해서는 점차 외면당하고 있는 현실입니다. 많은 개발자가 XML이 갖는 상대적 장점에 대해서 잘 모르지만 편견만으로 JSON을 맹목적으로 채택하는 것은 안타까운 일입니다.
이미 인터넷 상의 많은 글들이 JSON이 XML에 비해 갖고 있는 여러가지 강점에 대하여 말하고 있기 때문에 같은 내용의 글은 의미가 크게 없을 것입니다. 따라서 이 글은 거꾸로 적어도 웹 API의 인자/응답 데이터 형식으로서 XML이 JSON에 비해 어떠한 강점을 갖고 있는지 말해보려고 합니다.
먼저, 아래의 웹 API 개발자 관점에서 XML과 JSON을 비교한 내용을 보시기 바랍니다.
XML와 JSON의 비교 ⁃ 웹 API 개발자 관점
| 항목 | XML | JSON |
|---|---|---|
|
메타 데이터의 비중 (메타 데이터: 실질 데이터 외에 추가되는 외적인 정보들) |
높음 (XML 태그 때문) |
낮음 |
|
파싱(Parsing)의 편의성 |
낮음 (SAX, DOM, Reader 모두 JSON과 비교했을 때 불편함) |
높음 (JSON 문서를 '객체'나 '다중 배열'로 즉각 변환 가능) |
|
파싱(Parsing) 성능 |
상대적으로 낮음 |
상대적으로 높음 |
|
인자 및 응답 데이터 형식의 문서화 |
일반 범용 문서 형식 및 XML 전용 문서 형식인 XSD(XML Schema Definition)로 작성 가능 |
일반 범용 문서 형식으로 작성됨. XSD와 유사한 JSON Schema도 있으나 아직 Draft 단계로 거의 사용되지 않음. |
|
인자 및 응답 데이터의 형식 정의 |
강함 (값의 형식과 항목의 구조에 대한 명확한 정의가 가능) |
약함 (값의 형식과 항목의 구조에 대한 명확한 정의가 어려움) |
|
인자 및 응답 데이터의 형식 검증 |
편리함 (임의의 XML 문서를 XSD 문서를 통해 자동화된 검증 가능) |
불편함 (수동적으로 값의 형식 및 항목의 구조에 대하여 검증해야함) |
왜 여전히 XML 사용을 고려해야 하는가?
XML과 JSON을 비교한 수많은 글은 이미 JSON이 XML보다 많은 강점을 갖고 있다고 말하고 있으며, 많은 개발자들 또한 이러한 내용에 공감하고 현재도 그리고 앞으로도 웹 API 입출력 형식으로 JSON을 선택할 것입니다.
우리는 지금까지 JSON의 비교 우위를 판단할 때 상대적으로 ‘더 적은 데이터의 양’과 상대적으로 ‘더 높은 처리 성능’ 등의 수치적 자료를 기준으로 하였습니다. 그러나 XML과 JSON을 비교하는 많은 글에서 간과하고 있지만 우리가 놓치고 있는 중요한 사실이 있습니다. 그것은 바로 데이터의 형식적 무결성 확보입니다.
노련한 개발자들은 이미 눈치채셨겟지만, 입력 데이터의 형식적 무결성 확보는 수치적인 약간의 성능 향상보다 더 중요하게 고려해야 하는 부분입니다. 즉, 웹 API의 입력 데이터와 출력 데이터의 무결성을 검증, 확보, 유지하는 과정은 산술적인 이익보다 시스템 동작에 더 중요할 수 있습니다.
1. 입출력 데이터의 무결성 확보를 위해 먼저 해야할 일은 커스텀 데이터 규약을 정의하는 문서를 작성하고 웹 API 개발자 및 이용자들과 공유하는 것입니다. 단, 이 규약 문서는 실제 프로그래밍 및 동작 단계에서 강제성이 있어야만 합니다. 강제성이 없는 문서는 그냥 메뉴얼 또는 가이드 수준일 뿐입니다.
2. 입력 데이터, 출력 데이터 또는 입출력 데이터 모두에 대하여 위 규약 문서를 통하여 일차적으로 자동 검증합니다. 이 과정은 규약 문서에 강제성을 제공하여 규약 문서가 실질적 영향력이 있게 만듭니다. 즉, 규약 문서는, 안따라도 상관없는 단순한 가이드 문서가 아니라 규약을 어기면 웹 API가 100% 에러를 유발하고 규약의 어느 부분을 어겼는지도 알려주는, 강력한 무결성 판단 도구가 됩니다.
3. 이렇게 입력, 출력, 또는 입출력 데이터에 대한 무결성이 확보되면 웹 API 개발자는 모든 문제를 웹 API의 실제 구현부로 가정할 수 있습니다. 즉, 웹 API가 오동작하였다면 그 원인 중에 적어도 ‘규약을 지키지 않은 입력 데이터가 웹 API 호출 시 인자로 입력’된 경우는 없게 됩니다. 또한 반대로 ‘출력 데이터의 무결성’ 까지 확보되면, 웹 API가 잘못된 형식의 데이터를 클라이언트에게 보내어 클라이언트가 파싱에 실패하는 경우도 사라집니다.
위와 같은 ‘무결성’ 부분에 있어 XML은 JSON과 비교할 수 없는 강점을 갖습니다. 특히 XML의 규약 문서로 사용되는 형식인 XSD(XML Schema Definition)는 오래된 역사에 걸맞게 잘 다듬어졌으며 정교하고 강력합니다. 웹 API 개발자 및 사용자는 웹 API의 XSD를 파일을 공유하고 확인하는 것 만으로 해당 웹 API의 호출 규약을 이해하고 문제없이 사용할 수 있습니다. 또한 웹 API 개발자는 동일한 XSD 파일을 통하여 임의의 XML 문서가 규약에 부합하는지 빠르고 편하게 자동 검증할 수 있습니다.
우리는 지금까지 JSON의 비교 우위를 판단할 때 상대적으로 ‘더 적은 데이터의 양’과 상대적으로 ‘더 높은 처리 성능’ 등의 수치적 자료를 기준으로 하였습니다. 그러나 XML과 JSON을 비교하는 많은 글에서 간과하고 있지만 우리가 놓치고 있는 중요한 사실이 있습니다. 그것은 바로 데이터의 형식적 무결성 확보입니다.
노련한 개발자들은 이미 눈치채셨겟지만, 입력 데이터의 형식적 무결성 확보는 수치적인 약간의 성능 향상보다 더 중요하게 고려해야 하는 부분입니다. 즉, 웹 API의 입력 데이터와 출력 데이터의 무결성을 검증, 확보, 유지하는 과정은 산술적인 이익보다 시스템 동작에 더 중요할 수 있습니다.
1. 입출력 데이터의 무결성 확보를 위해 먼저 해야할 일은 커스텀 데이터 규약을 정의하는 문서를 작성하고 웹 API 개발자 및 이용자들과 공유하는 것입니다. 단, 이 규약 문서는 실제 프로그래밍 및 동작 단계에서 강제성이 있어야만 합니다. 강제성이 없는 문서는 그냥 메뉴얼 또는 가이드 수준일 뿐입니다.
2. 입력 데이터, 출력 데이터 또는 입출력 데이터 모두에 대하여 위 규약 문서를 통하여 일차적으로 자동 검증합니다. 이 과정은 규약 문서에 강제성을 제공하여 규약 문서가 실질적 영향력이 있게 만듭니다. 즉, 규약 문서는, 안따라도 상관없는 단순한 가이드 문서가 아니라 규약을 어기면 웹 API가 100% 에러를 유발하고 규약의 어느 부분을 어겼는지도 알려주는, 강력한 무결성 판단 도구가 됩니다.
3. 이렇게 입력, 출력, 또는 입출력 데이터에 대한 무결성이 확보되면 웹 API 개발자는 모든 문제를 웹 API의 실제 구현부로 가정할 수 있습니다. 즉, 웹 API가 오동작하였다면 그 원인 중에 적어도 ‘규약을 지키지 않은 입력 데이터가 웹 API 호출 시 인자로 입력’된 경우는 없게 됩니다. 또한 반대로 ‘출력 데이터의 무결성’ 까지 확보되면, 웹 API가 잘못된 형식의 데이터를 클라이언트에게 보내어 클라이언트가 파싱에 실패하는 경우도 사라집니다.
위와 같은 ‘무결성’ 부분에 있어 XML은 JSON과 비교할 수 없는 강점을 갖습니다. 특히 XML의 규약 문서로 사용되는 형식인 XSD(XML Schema Definition)는 오래된 역사에 걸맞게 잘 다듬어졌으며 정교하고 강력합니다. 웹 API 개발자 및 사용자는 웹 API의 XSD를 파일을 공유하고 확인하는 것 만으로 해당 웹 API의 호출 규약을 이해하고 문제없이 사용할 수 있습니다. 또한 웹 API 개발자는 동일한 XSD 파일을 통하여 임의의 XML 문서가 규약에 부합하는지 빠르고 편하게 자동 검증할 수 있습니다.
마무리
이상 웹 API에 있어서 XML과 JSON을 비교하고, XML이 특별히 갖고 있는 수치 외적인 강점에 대하여 알아보았습니다.
특정 분야 또는 특정 범위라고 할지라도 모든 경우에 적용되는 정답은 없을 것입니다. 예를 들어 JSON이 대부분의 경우 XML에 비해 유리하다면 XML은 사라져야 하겠지요. 하지만 여전히 XML은 광범위하게 사용되고 있고 앞으로도 그럴 것입니다. ‘웹 API’의 범위에서도 XML은 나름의 비교 불가한 강점을 갖고 있으며 이 부분이 간과되지 않길 바라는 마음에서 이 글을 작성하였습니다. 개발자들이 본인 프로젝트를 위해 웹 API을 설계하고 개발하고자 할 때 XML의 사용에 대하여 좀 더 고민해 보는 계기가 되었으면 합니다.
여담으로, 쿠빌은 Rest 형식의 웹 API에 대해 XML을 주로 사용하고, WebSocket 서버와 같이 매우 간단한 인자를 갖는 경우에는 JSON을 사용합니다. 또한, XML을 입출력 형식으로 이용하는 경우라도 ‘차트 데이터’와 같이 특정 항목의 값이 큰 용량을 차지하는 경우라면 해당 자료 형식을 string으로 하고 JSON 값을 넣습니다. 만약, 그래도 값의 크기가 매우 크다면 JSON 값 자체를 gzip으로 압축하고 base64로 인코딩한 값을 넣습니다.
특정 분야 또는 특정 범위라고 할지라도 모든 경우에 적용되는 정답은 없을 것입니다. 예를 들어 JSON이 대부분의 경우 XML에 비해 유리하다면 XML은 사라져야 하겠지요. 하지만 여전히 XML은 광범위하게 사용되고 있고 앞으로도 그럴 것입니다. ‘웹 API’의 범위에서도 XML은 나름의 비교 불가한 강점을 갖고 있으며 이 부분이 간과되지 않길 바라는 마음에서 이 글을 작성하였습니다. 개발자들이 본인 프로젝트를 위해 웹 API을 설계하고 개발하고자 할 때 XML의 사용에 대하여 좀 더 고민해 보는 계기가 되었으면 합니다.
여담으로, 쿠빌은 Rest 형식의 웹 API에 대해 XML을 주로 사용하고, WebSocket 서버와 같이 매우 간단한 인자를 갖는 경우에는 JSON을 사용합니다. 또한, XML을 입출력 형식으로 이용하는 경우라도 ‘차트 데이터’와 같이 특정 항목의 값이 큰 용량을 차지하는 경우라면 해당 자료 형식을 string으로 하고 JSON 값을 넣습니다. 만약, 그래도 값의 크기가 매우 크다면 JSON 값 자체를 gzip으로 압축하고 base64로 인코딩한 값을 넣습니다.