블로그를 짧은 시간(?)동안 운영하면서
한가지, 징크스 같은 게 생겼습니다.
그 것은 바로... "진지한 이야기는 통하지 않어!!" ...랄까.
아무튼 스크롤압박이 존재하는 글들은 어김없이
외면을 받는다는 절대적인 진리를 얻게 되었습니다.

그래서 이번에야말로,
정말 스크롤압박 없이 XML-RPC 에 관해서
시시한 고찰 하나를 해보려고 합니다.
...절대로 진지한 이야기 같은 거 아닙니다! (-_;;)



(출처: http://www.xmlrpc.com/, 각종 XML-RPC 응용 API들의 정의나 스펙에 대해 소개해주는 곳입니다.)

뭐 그런 겁니다.
이기종 환경 속에서 원격지의 특정 메소드를 실행하기 위해서,
요청(Request)과 응답(Response) 과정이 필요하게 되는데
XML 형식의 데이터를 교환하면서 그 작업을 하겠다는 겁니다.

...다 아는 것처럼 말씀드리고 있지만
사실 GR블로그에 MetaWeblog API 를 응용하기 전까지
저는 그야말로 아무 것도 모르고 있었습니다.
나름 그 때 삽질하면서 조사한 것들을 차후라도 잊지 않기 위해서
지금 이 글을 남기고 있지만 명료하게 소개를 할 수 있을런지
걱정이 됩니다.

정정부터 하겠습니다.
일단 위의 『XML 형식으로 데이터를 교환한다』는 설명은
지나치게 추상적인 설명입니다.
사실은 XML-RPC 에서 RPC(Remote Procedure Call)에 대해
먼저 알아보고 나서 이야기를 해야 더 순서에 맞다고 할 수 있겠습니다.

RPC는 우리말로 설명하자면... 원격 절차 호출? 정도가 될까요?
아무튼 원격지에 특정 일을 지시하는 방법 내지는 계층으로
보아도 좋겠습니다. 자세히 기억나지는 않는데 OSI 7계층에서는
5번째 계층에 해당하며, 지금 이 글을 보시는 분들은 이미 사용하셨을
HTTP 프로토콜도 일종의 RPC라고 할 수 있습니다.



(출처: 위키피디아, 역시 위키피디아의 설명이 정확합니다.)

여러분의 브라우저는 시리니넷 웹서버 Apache 에게 HTTP 헤더를 전송합니다.
페이지를 GET 으로 요청하는 내용이겠죠? 그럼 Apache 는 일단 로그에
접근 기록(access.log)을 남기고, 요청에 적합한 응답을 브라우저에게 전해줍니다.
각종 이미지 파일경로들이나 문서 형식등을 전달해주고 HTML 문서를 반환하지요.
브라우저는 그 응답을 받고 페이지를 다시 재구성(렌더링)하여
여러분들에게 지금 모니터 화면으로 보여주고 있습니다.

이런 이기종간의 원격 명령 호출을 RPC라고 (축약어로) 부른답니다.
XML-RPC는 그런 이기종간의 명령 호출 형식을 XML 형식으로 하겠다는 겁니다.
XML은 일전에도 한 번 이 곳에서 이야기를 했던 적이 있지만
웹(Web)에 특화된, 그야말로 호환성을 중시한 언어입니다.
개인적으로는 호환성 만큼 성능을 고려하지 않은 언어로 생각하고 있습니다.

예, 좀 더 솔직히 말씀드리겠습니다.
XML-RPC는 XML형식으로 명령을 주고 응답을 받습니다.
전달하고자 하는 핵심적인 코드보다도, 그 것을
감싸거나 불필요하게 구조적으로 해석해야 할 데이터가
지나치게 많은 것이 사실입니다.

아래의 코드를 함께 볼까요?

<methodCall>
<methodName>metaWeblog.getPost</methodName>
<params>
<param>
<value>
<string>1829</string>
</value>
</param>
<param>
<value>userid</value>
</param>
<param>
<value>
<string>password</string>
</value>
</param>
</params>
</methodCall>

MetaWeblog API 중 metaWeblog.getPost 명령을 호출할 때 쓰는 코드입니다.
호출하고자 하는 문서 고유번호(1892), 로그인 아이디(userid), 비밀번호(password)
이 세가지 정보를 건네주고, 해당 번호의 포스트와 연관된 정보를 응답으로 받습니다.
실제 XML-RPC 로 구현된 코드들은 대부분 위처럼 순서대로 값들을 보내고
다시 순서대로 값을 받는 형태를 취합니다.

위의 코드 자체는 좀 짧기 때문에 그다지 무의미해 보이진 않습니다.
그러나, 건네줄 데이터의 양에 비해 그 데이터를 감싸는 코드가 많은 것이 사실입니다.
이는 비록 적어보이지만, 분명히 네트워크 대역폭을 낭비하는 것으로도
생각 할 수 있습니다.

저 요청에 대한 응답은 어떻게 왔을까요?
역시 XML 형식의 문서 형태로 오게 됩니다.
XML-RPC 에서는 HTTP 의 POST 전송을 통해 XML 코드들이
오가게 되는데, 세상에... 아래 응답 받은 코드를 볼까요?

<methodResponse>
<params>
<param>
<value>
<struct>
<member>
<name>categories</name>
<value>
<array>
<data>
<value>글의 분류가 적혀집니다.</value>
</data>
</array>
</value>
</member>
<member>
<name>dateCreated</name>
<value>
<dateTime.iso8601>20050201T12:10:12</dateTime.iso8601>
</value>
</member>
<member>
<name>description</name>
<value>여기에 포스트 본문 내용이 들어갑니다.
글 내용이 많아질 경우 한정없이 늘어지긴 하겠지요.
</value>
</member>
<member>
<name>link</name>
<value>http://sirini.net/blog/1829</value>
</member>
<member>
<name>postid</name>
<value>
<string>1829</string>
</value>
</member>
<member>
<name>title</name>
<value>여기에 글제목이 출력됩니다.</value>
</member>
<member>
<name>publish</name>
<value>
<boolean>1</boolean>
</value>
</member>
</struct>
</value>
</param>
</params>
</methodResponse>

무려 위와 같은 어마어마하게 많은 코드를 받게 됩니다.
보기에 따라서 별로 많지 않게 보일런지도 모르겠습니다만,
실제로 필요한 데이터에 비해 그 데이터의 타입이나 구조를
표현하기 위한 코드가 불필요하게 많은 것을 알 수 있습니다.

이는 결과적으로 꼭 필요한 데이터만 받는 게 아닌,
불필요한 부가 정보들까지 한 번에 받게 됨으로서 네트워크 대역폭을
쓸데없이 낭비하게 하는 악영향을 끼치게 됩니다.
물론 XML 이란 문서 자체가 호환성을 중심에 두고 탄생한 언어이니만큼
이 정도는 감내해야 하겠지만, 그래도 단점임에는 의심할 여지가 없지요.

위의 예에서는 MetaWeblog API 를 대상으로 했는데,
실제 XML-RPC 로 구현된 대다수의 API들도 비슷한 점을 보이고 있습니다.
더구나 XML 형식의 문서를 실제로 의미 있는 데이터로 변경하기 위해서
해석 과정이 필요하게 되는데, PHP4의 경우는 xml_* 관련 SAX 방식의
해석 코드를 추가적으로 필요로 하게 됩니다.
(파이썬 등의 다른 언어들은 자체적으로 XML-RPC 를 지원하고 있습니다.)

XML-RPC의 핵심은 '이기종' 간의 데이터 전송에 XML 형식을 사용하며,
HTTP 프로토콜에서 POST 형식으로 그 XML 문서를 주고 받는데 있습니다.
최근에 나오는 대부분의 언어들은 이 XML-RPC를 위한 별도의 라이브러리를
제공하고 있으며 XML 이란 형식을 의식할 필요도 없도록 해주고 있습니다.
(PHP4 의 경우는 미흡합니다. 이 때문이라도 PHP5 로 가야 할터인데...)

웹 환경에서 강력한 호환성을 무기로 XML의 활동 영역이 넓혀지고 있는데요,
이 XML-RPC 라는 개념이 등장하고, 블로깅이 일상 생활화 되면서
보다 편한 블로깅을 위한 여러 도구들이 등장했습니다.
GR블로그에서도 최근에 지원하기 시작한 Windows Live Writer 같은 도구들이
좋은 예입니다. (MetaWeblog API 를 비롯한 대부분의 원격 블로깅 API 를
지원하고 있습니다. 물론 XML-RPC 형태입니다.)



(이 곳에 와 주셨던 분들은 한 번 보신 적이 있으실 겁니다. 스크린샷의 재활용! ^^;;)

XML 형태로 데이터를 주고 받는다면
ASCII 형태는 문제 없이 주고 받을 수 있습니다.
그런데, 그림 같은 바이너리 데이터들은 어떻게 XML 문서 안에 넣을까요?
분명 글을 쓰다보면 본문에 그림도 넣고 해야 할텐데 말이죠.

이 문제는 바이너리 코드를 ASCII 코드로 변경하고, 다시 바이너리 코드로
변환하는 작업이 필요함을 의미합니다. 통상의 경우, 이 작업은
base64 encode/decode 관련 메소드(함수)들로 대부분의 프로그래밍 언어에서
해결 하실 수 있습니다. PHP에서는 base64_encode() / base64_decode() 를,
C# 에서는 .ReadBase64 같은 메소드들을 통해서 할 수 있습니다.

base64 라는 건 정확히 말하자면 MIME base64 타입을 말합니다.
네트워크 전송 과정중에서 바이너리 코드 (8 bit) 가 제대로 전달되지 않을 때,
ASCII 형태의 코드 (예: YgjmklwpawxWfGaAfw...) 로 변환해서
안전하게 데이터 손실 없이 전달하려는 목적으로 만들어진 형식입니다.
PHP.net 매뉴얼 설명서대로 약 33% 더 많은 잉여 데이터가 들어가서
역시나 본래 크기보다는 네트워크 대역폭을 더 낭비하는 셈이 되지만,
안전하고 확실하게 바이너리 데이터를 전달할 수 있는 이점이 있습니다.

XML-RPC 에서는 위의 base64 형식을 이용해서 데이터를 보냅니다.
가령 그림을 첨부하면, XML 형식의 "요청" 문서를 보낼 때 그림 파일의
데이터를 base64 로 인코딩해서 ASCII 형태로 저장하게 됩니다.
요청을 받은 곳에서는 이 base64 형식의 데이터를 다시 디코딩해서
본래의 이진 파일로 만들어 저장을 해야 합니다.

이를 그림으로 간단하게 설명하면 아래와 같습니다.



... 뭔가 심하게 단순화되었다는 느낌을 지울 수 없지만
바이너리 데이터가 ASCII 코드 (메모장으로 열 수 있는 형태) 로 변환되고,
다시 그 코드가 바이너리로 변경되어 전달되는 흐름은
알 수 있을 것 같습니다. ^^;;

XML-RPC 형식으로 이제 바이너리 데이터까지 전송이 가능하게 된 겁니다.
실제로 MetaWeblog API 에는 metaWeblog.newMediaObject 라는
메소드를 지원하고 있습니다. 이 형식으로 보낸 요청을 받게 되면 그 받은 곳에서는
'아, 이제 base64 로 인코딩된 데이터가 오겠구나. 이 놈을 다시 디코딩해서
바이너리로 만들어 저장해야 겠구나.' 하는 걸 알게 됩니다.
(물론, 아까도 언급되었듯 33% 대역폭을 과소비하기는 합니다.)

정리하자면,
XML-RPC 는 호환성을 최우선으로 둔 원격 명령 호출이라는 점.
불필요한 네트워크 대역폭 낭비등의 단점에도 불구하고 웹 공간에서
이기종/다른환경에서의 데이터 전송에 하나의 길을 제시한
네트워크 전송 방법중 하나입니다.

XML 이라는 형식으로 요청과 응답을 받는 것 이외에
그다지 특별한 점은 없습니다.
언어 자체에서 이 프토로콜을 지원하는 경우에는 더 활용하기 쉽고,
그렇지 않더라도 XML 파싱만 제대로 되고 HTTP 프로토콜만
제대로 지원되면 어떤 환경, 어떤 프로그램에서도 활용이 가능합니다.

+

...흠, 이로서 슬슬 이 시덥잖은 고찰을 마무리 해보려고 했는데
어느 샌가 또 이렇게 스크롤이 무진장 내려와 버렸네요. -_;;;
서두의 그 이야기는 다시 또 뻘소리가 되어 버린 것인가... 흠좀무... ㅠ.ㅠ~

일단 이 것으로 고찰을 마무리 해보겠습니다.
다음 기회에 (그런 게 있다는 전제 하에) GR블로그를 비롯한
많은 블로깅 도구들이 지원하고 있는 MetaWeblog API 에 대해서도
한 번 고찰해 보는 시간을 마련해 보도록 하겠습니다.

긴 글 읽어주셔서(설마 계실까?!) 감사합니다. (__);;;