인사이트미디어 위젯 랩 내부 지식 공유 목적으로 작성된 문서입니다.
웹에 관련되어 종사 하시는 분들 중 상당 수에 분들은 이용되거나 응용되는 기반 인프라에 대한 이해의 필요성을 인지하지 못하시는 것 같은 느낌을 현업에 있다 보니 많이 경험을 하게 되었습니다. 이런 문제를 내부 엔지니어 분들을 대상으로 공유하고 토론 하도록 문제들을 도출하려 노력할 예정입니다.
최근에 웹 2.0이라는 새로운 트렌드가 나오면 동시에 웹을 통하여 데이터를 읽고 쓰기 위한 여러 가지 기법(기술)들이 나왔습니다. 이런 기술들이 웹에 사용되면서 통신을 위한 데이터의 규격을 맞출 필요성이 생겼다 볼 수 있습니다. 이런 일종의 데이터 교환 프로토콜을 위한 훌륭한 스펙이 바로 XML이 이용 되면서 다시 웹 환경과 XML에 대한 관심을 불러 일으키고 있습니다. 특히 저희 연구소에게 진행하고 있는 가젯(위젯)에 AJAX(Asynchronous JavaScript and XML)기법들이 사용되면서 그 이용가치는 극대화되고 있다고 할 수 있습니다. 이에 따라 이제 흔히 사용되고 응용 할 수 있어야 하는 XML에 대한 몇 가지 이야기를 하려 합니다.
XML에 대한 이야기
Extention Markup Language의 축약어로 특수한 마크업 언어를 생성하기 위한 범용적 명세서라 합니다. XML은 확장언어로 분류가 됩니다. 왜냐하면 사용자가 상황에 맞게 마크업(Markup) 요소(Element)들을 정의 할 수가 있기 때문이죠. 또한 구조화된 데이터를 공유하는 정보 시스템들을 거들고, 특별하게 인터넷을 통하여 문서들을 부호화 하거나 데이터를 직렬화하기 위한 목적으로 이용됩니다. 특히 데이터를 직렬화하는 용도에는 많은 이견들이 생겨나기도 합니다. 바로 우리가 들어 봄직한 텍스트 기반의 직렬화 언어라고 명명하고 있는 JSON과 YAML과 비교가 됩니다. 한편으로는 다른 표준들과 조합된 XML은 구성된 포맷으로부터 문서의 컨텐츠를 분리하여 정의 하게하고, 다른 어플리케이션이나 다른 표현 환경에 컨텐츠를 재사용하기 쉽게 하고 있는 부분도 있습니다. 이런 기본 논리를 바탕으로 많은 전환 레이어를 거치지 않아도 되는 장점으로 다른 컴퓨터 기종들과 다른 응용프로그램들 그리고 다른 구성조직간에 정보를 공유하기 위해 사용될 수 있는 기본 문법을 제공하고 있습니다.
이 XML은 SGML(Standard Generalized Markup Language)의 간소화된 부분집합으로 시작해 인간이 의미론적 제약들을 통해 읽을 수 있게 되는 것이므로 실제 어플리케이션 언어들이 XML로 작성이 될 수 있습니다. 이들은 바로 XHTML(XML 문법을 따르는 HTML), RSS(웹 피드 포맷의 일종), MathML (Mathematical Markup Language), GraphML, Scalable Vector Graphics(Scalable Vector Graphics (SVG)), MusicXML등이 있습니다.
XML 스키마의 탄생
XML 이야기를 하면 항상 따라 다니는 용어인 DTD(Document Type Definition)가 있습니다. SGML로 부터 상속한 문서 형식을 정의하는 XML 스키마 언어의 일종으로 매우 중요한 네임스페이스들과 같은 XML의 새로운 특징들에 대한 지원이 없었고, 표현력이 풍부하지 못한 문제점등이 나타나면서 뭔가 새로운 스키마 언어를 필요하게 되었습니다. 하지만 현재도 여전히 많은 어플리케이션에서는 쉽게 읽고, 쓸 수 있도록 고려된 언어이기 때문에 여전히 사용되고 있습니다. 그 이후에 XSD(XML Schema Definition)란 새로운 XML 스키마 언어가 나왔습니다. XML 언어들을 묘사하기에 DTD들보다 훨씬 파워풀 하다고 설명하고 있습니다.
웹에 XML 출력하기
그렇다면 작성된 XML을 우리가 흔히 보고 있는 브라우저를 통해 볼 수 있는 방법이 뭘까요?
아쉽게도 HTML(or XHTML)과 같이 기본적인 XML 문서는 데이터를 어떻게 표현할지에 대한 정보를 전달하지 않습니다. CSS나 XSLT를 사용하지 않는 기본 XML은 대부분의 웹 브라우저에서 로우 데이터로 출력됩니다.
CSS로 브라우저 렌더링에 스타일을 부여하기 위해서는 문서 내에 반드시 스타일시트 참조를 포함 하셔야 합니다.
특유의 가벼움과 간소화로 대적하는 JSON
요즘 많은 웹 서비스들은 사용자와 유기적인 상호작용을 통해 동적인 묘사기능을 지향하고 있습니다. 이런 상황에 맞게 사용자 브라우저로부터 지속적이거나 빈번한 요청/응답 프로세스가 발생 하면서 웹 서버와 사용자 브라우저간의 데이터 통신 속도를 높이는 것과 웹 서버의 부담을 줄이는 것은 굉장히 중요한 이슈로 다가오게 되었습니다. 또한 사용자단에서 날아온 XML 문서(데이터)에 대해 각 요소들에 대한 파싱작업을 통해 실제 구현기능과 연동되게 되어지게 됨으로 재처리에 대한 부담감도 크게 작용이 된 것 같습니다.
그에 맞서 데이터 교환 절차를 간소화할 대적할만한 JSON(JavaScript Object Notation)이 등장하게 됩니다. 이는 자바스크립트 객체 표시법의 축약어로 써 경량의 컴퓨터 데이터 교환 포맷으로 정의를 합니다. 이 것은 단순한 데이터 구조들이나 오브젝트라 불리는 연상배열들을 나타나기 위한 텍스트 기반 포맷입니다. JSON 포맷은 RFC 4627에 명시되어 있으며 공식적인 인터넷 미디어 타입은 application/json 이며 확장자는 .json 입니다. 보통 직렬화라고 부르는 처리에 네트워크 접속상에 구조화된 데이터를 전송할 때 종종 사용되고 있는데 특히 XML 포맷 사용의 대안 역할을 하는 Ajax 웹 어플리케이션 프로그래밍에 주로 이용됩니다.
2005년 12월 거대 글로벌 Yahoo가 자신의 웹 서비스들의 일부분을 JSON으로 제공하기 시작하여, 이후 1년 후인 2006년 12월에 구글이 자사의 GData(구글이 창안한 인터넷에 데이터를 읽고/쓰게 하기위한 단순한 표준 프로토콜) 웹 프로토콜을 위해 JSON 피드들을 제공하기 시작했습니다.
JSON의 예제를 한번 살펴보면 다음과 같습니다.
어떠신가요? 어떤 객체나 구조들을 묘사하기 위해 일반적으로 사용되는 마크업 포맷만을 생각해봐도 굉장히 단순하고 가벼운 코드특성을 갖고 있습니다.
제가 여러 가젯을 구현 하면서 RSS와 같은 XML 포맷을 사용하기 위해 재처리하는 과정과 추 후 유지보수에 대한 부담이 아주 크게 작용을 했었습니다. 하지만 위와 같이 서버 응답자로 부터 JSON 텍스트 포맷으로 내보내도록 구현하고 응답받아 사용자 브라우저 환경에 JavaScript의 eval() 메소드로 다시 구조화된 객체로 형상화함으로써 모든 문제는 사라졌습니다.
구글에서 구글 가젯을 구현하기 위해 제공되는 API 문서에 봐도 XML과 JSON 처리 방식의 간소화 방식에 큰 차이가 있음을 아실 수 있습니다.
결론
어쩌면 어정쩡하게 XML에서 JSON으로 말을 맺는 것 같기만 일반적인 피드데이터를 대상으로 구현하는 가젯 제작에 근본 데이터는 바로 XML 피드 기반으로 작성된다는 사실 입니다. 그 XML 피드 처리를 간소화하기 위해 JSON 포맷이 많이 이용되고 있고 많은 경우는 데이터베이스에서 데이터를 추출하는 과정에서 조차 애초 JSON 포맷으로 빼서 이용하는 경우도 많다 할 수 있습니다. 하지만 어떤 포맷이 좋다고 누군가 단정할 수가 없는 것이 구현 하시려는 다양한 변수와 환경을 고려하여 많은 벤치마킹을 통해 구현하는 것이 가장 현명한 방법이 아닐까 생각됩니다.
웹에 관련되어 종사 하시는 분들 중 상당 수에 분들은 이용되거나 응용되는 기반 인프라에 대한 이해의 필요성을 인지하지 못하시는 것 같은 느낌을 현업에 있다 보니 많이 경험을 하게 되었습니다. 이런 문제를 내부 엔지니어 분들을 대상으로 공유하고 토론 하도록 문제들을 도출하려 노력할 예정입니다.
최근에 웹 2.0이라는 새로운 트렌드가 나오면 동시에 웹을 통하여 데이터를 읽고 쓰기 위한 여러 가지 기법(기술)들이 나왔습니다. 이런 기술들이 웹에 사용되면서 통신을 위한 데이터의 규격을 맞출 필요성이 생겼다 볼 수 있습니다. 이런 일종의 데이터 교환 프로토콜을 위한 훌륭한 스펙이 바로 XML이 이용 되면서 다시 웹 환경과 XML에 대한 관심을 불러 일으키고 있습니다. 특히 저희 연구소에게 진행하고 있는 가젯(위젯)에 AJAX(Asynchronous JavaScript and XML)기법들이 사용되면서 그 이용가치는 극대화되고 있다고 할 수 있습니다. 이에 따라 이제 흔히 사용되고 응용 할 수 있어야 하는 XML에 대한 몇 가지 이야기를 하려 합니다.
XML에 대한 이야기
Extention Markup Language의 축약어로 특수한 마크업 언어를 생성하기 위한 범용적 명세서라 합니다. XML은 확장언어로 분류가 됩니다. 왜냐하면 사용자가 상황에 맞게 마크업(Markup) 요소(Element)들을 정의 할 수가 있기 때문이죠. 또한 구조화된 데이터를 공유하는 정보 시스템들을 거들고, 특별하게 인터넷을 통하여 문서들을 부호화 하거나 데이터를 직렬화하기 위한 목적으로 이용됩니다. 특히 데이터를 직렬화하는 용도에는 많은 이견들이 생겨나기도 합니다. 바로 우리가 들어 봄직한 텍스트 기반의 직렬화 언어라고 명명하고 있는 JSON과 YAML과 비교가 됩니다. 한편으로는 다른 표준들과 조합된 XML은 구성된 포맷으로부터 문서의 컨텐츠를 분리하여 정의 하게하고, 다른 어플리케이션이나 다른 표현 환경에 컨텐츠를 재사용하기 쉽게 하고 있는 부분도 있습니다. 이런 기본 논리를 바탕으로 많은 전환 레이어를 거치지 않아도 되는 장점으로 다른 컴퓨터 기종들과 다른 응용프로그램들 그리고 다른 구성조직간에 정보를 공유하기 위해 사용될 수 있는 기본 문법을 제공하고 있습니다.
이 XML은 SGML(Standard Generalized Markup Language)의 간소화된 부분집합으로 시작해 인간이 의미론적 제약들을 통해 읽을 수 있게 되는 것이므로 실제 어플리케이션 언어들이 XML로 작성이 될 수 있습니다. 이들은 바로 XHTML(XML 문법을 따르는 HTML), RSS(웹 피드 포맷의 일종), MathML (Mathematical Markup Language), GraphML, Scalable Vector Graphics(Scalable Vector Graphics (SVG)), MusicXML등이 있습니다.
XML 스키마의 탄생
XML 이야기를 하면 항상 따라 다니는 용어인 DTD(Document Type Definition)가 있습니다. SGML로 부터 상속한 문서 형식을 정의하는 XML 스키마 언어의 일종으로 매우 중요한 네임스페이스들과 같은 XML의 새로운 특징들에 대한 지원이 없었고, 표현력이 풍부하지 못한 문제점등이 나타나면서 뭔가 새로운 스키마 언어를 필요하게 되었습니다. 하지만 현재도 여전히 많은 어플리케이션에서는 쉽게 읽고, 쓸 수 있도록 고려된 언어이기 때문에 여전히 사용되고 있습니다. 그 이후에 XSD(XML Schema Definition)란 새로운 XML 스키마 언어가 나왔습니다. XML 언어들을 묘사하기에 DTD들보다 훨씬 파워풀 하다고 설명하고 있습니다.
웹에 XML 출력하기
그렇다면 작성된 XML을 우리가 흔히 보고 있는 브라우저를 통해 볼 수 있는 방법이 뭘까요?
아쉽게도 HTML(or XHTML)과 같이 기본적인 XML 문서는 데이터를 어떻게 표현할지에 대한 정보를 전달하지 않습니다. CSS나 XSLT를 사용하지 않는 기본 XML은 대부분의 웹 브라우저에서 로우 데이터로 출력됩니다.
CSS로 브라우저 렌더링에 스타일을 부여하기 위해서는 문서 내에 반드시 스타일시트 참조를 포함 하셔야 합니다.
<?xml-stylesheet type="text/css" href="myStyleSheet.css"?> <?xml-stylesheet type="text/xml" href="myTransform.xslt"?>하지만 국내 웹사이트들에서 이런 포멀한 XML 문서를 사용하여 HTML(or XHTML)을 대체한 서비스는 본 기억이 거의 없는 것 같습니다. 그만큼 기본 XML을 바탕으로 DTD(XML 스키마 언어의 일정)를 정의하고 그에 맞는 요소들 태깅해야 함과 동시에 CSS를 정의해야 하는 불편함이 따르고 혼란스러움이 있습니다. 현재의 간단한 HTML 요소들을 대체할 만한 간편함을 갖지 못하고 있는게 사실이죠.
특유의 가벼움과 간소화로 대적하는 JSON
요즘 많은 웹 서비스들은 사용자와 유기적인 상호작용을 통해 동적인 묘사기능을 지향하고 있습니다. 이런 상황에 맞게 사용자 브라우저로부터 지속적이거나 빈번한 요청/응답 프로세스가 발생 하면서 웹 서버와 사용자 브라우저간의 데이터 통신 속도를 높이는 것과 웹 서버의 부담을 줄이는 것은 굉장히 중요한 이슈로 다가오게 되었습니다. 또한 사용자단에서 날아온 XML 문서(데이터)에 대해 각 요소들에 대한 파싱작업을 통해 실제 구현기능과 연동되게 되어지게 됨으로 재처리에 대한 부담감도 크게 작용이 된 것 같습니다.
그에 맞서 데이터 교환 절차를 간소화할 대적할만한 JSON(JavaScript Object Notation)이 등장하게 됩니다. 이는 자바스크립트 객체 표시법의 축약어로 써 경량의 컴퓨터 데이터 교환 포맷으로 정의를 합니다. 이 것은 단순한 데이터 구조들이나 오브젝트라 불리는 연상배열들을 나타나기 위한 텍스트 기반 포맷입니다. JSON 포맷은 RFC 4627에 명시되어 있으며 공식적인 인터넷 미디어 타입은 application/json 이며 확장자는 .json 입니다. 보통 직렬화라고 부르는 처리에 네트워크 접속상에 구조화된 데이터를 전송할 때 종종 사용되고 있는데 특히 XML 포맷 사용의 대안 역할을 하는 Ajax 웹 어플리케이션 프로그래밍에 주로 이용됩니다.
2005년 12월 거대 글로벌 Yahoo가 자신의 웹 서비스들의 일부분을 JSON으로 제공하기 시작하여, 이후 1년 후인 2006년 12월에 구글이 자사의 GData(구글이 창안한 인터넷에 데이터를 읽고/쓰게 하기위한 단순한 표준 프로토콜) 웹 프로토콜을 위해 JSON 피드들을 제공하기 시작했습니다.
JSON의 예제를 한번 살펴보면 다음과 같습니다.
어떠신가요? 어떤 객체나 구조들을 묘사하기 위해 일반적으로 사용되는 마크업 포맷만을 생각해봐도 굉장히 단순하고 가벼운 코드특성을 갖고 있습니다.
제가 여러 가젯을 구현 하면서 RSS와 같은 XML 포맷을 사용하기 위해 재처리하는 과정과 추 후 유지보수에 대한 부담이 아주 크게 작용을 했었습니다. 하지만 위와 같이 서버 응답자로 부터 JSON 텍스트 포맷으로 내보내도록 구현하고 응답받아 사용자 브라우저 환경에 JavaScript의 eval() 메소드로 다시 구조화된 객체로 형상화함으로써 모든 문제는 사라졌습니다.
구글에서 구글 가젯을 구현하기 위해 제공되는 API 문서에 봐도 XML과 JSON 처리 방식의 간소화 방식에 큰 차이가 있음을 아실 수 있습니다.
XML FEED 처리 코드
JSON 처리 코드
결론
어쩌면 어정쩡하게 XML에서 JSON으로 말을 맺는 것 같기만 일반적인 피드데이터를 대상으로 구현하는 가젯 제작에 근본 데이터는 바로 XML 피드 기반으로 작성된다는 사실 입니다. 그 XML 피드 처리를 간소화하기 위해 JSON 포맷이 많이 이용되고 있고 많은 경우는 데이터베이스에서 데이터를 추출하는 과정에서 조차 애초 JSON 포맷으로 빼서 이용하는 경우도 많다 할 수 있습니다. 하지만 어떤 포맷이 좋다고 누군가 단정할 수가 없는 것이 구현 하시려는 다양한 변수와 환경을 고려하여 많은 벤치마킹을 통해 구현하는 것이 가장 현명한 방법이 아닐까 생각됩니다.
