AtomPub , 멋진 웹 애플리케이션을 만들기 위한 약속

이 글은 Data Web의 핵심 키워드, '리소스'라는 연재글의 일부입니다.

이 시리즈는 4월 29일부터 매일 오전 8시에 한편씩 발행됩니다. 이번 한 주 동안만큼이라도, Data Web에 대한 즐거운 상상들과 함께 아침을 맞이 해보시는 건 어떨까요?  ^_^

[ 일일 차림표 ]

1. 들어가는 글 - 4월 29일 

2. REST , 데이터와 데이터가 가장 간단하게 대화하는 방식 - 4월 30일 

3. AtomPub , 멋진 웹 애플리케이션을 만들기 위한 약속 - 5월 1일 

4. 리믹스할 수 있는 웹, 변화의 증거들 그리고 기회 - 5월 2일 

5. Data Web으로 가는 길 - 5월 3일 

AtomPub , 멋진 웹 애플리케이션을 만들기 위한 약속

앞서 말씀드린 REST는 어떤 규약이 아닌, 아키텍쳐 스타일입니다. 그야말로 따르면 좋고, 개발하는 서비스마다 제각기 모양이 달라질 수 있지요. REST스러운(RESTful) 서비스를 만든다는 업체들도 제각기 그 모양과 방식에 차이를 보이는 것이 사실입니다. 그런데 이 REST에도 한 가지 약속이 생겼습니다. AtomPub(Atom Publishing Protocol)이 그것인데요. 기존의 RSS에 대응하는 Atom이라는 프로토콜을 사용해서, 피드(리소스)를 자유롭게 편집할 수 있게 만들고자 하는 규약이라고 할 수 있겠습니다. 간단히 말해 '쓰고 편집할 수 있는' RSS Feed라고 할까요?

이거 진짜 Atomic하구나!

얼 마전에 사내 스터디에서 AtomPub에 대한 이야기를 듣는 자리가 있었습니다. 그때 옆 자리에 계시던 분의 한 마디가 정말 인상적이었습니다. '이야~ 진짜 원자성(Atomicity)이 있게 만들려는 거구나~!' 무슨 의미냐구요? ^^

Atom 그리고 AtomPub는 웹 문서의 모든 항목들을, 제각기 독립적인 리소스로 취급합니다. 예를 들자면 기존에 블로그에 포스팅을 할때, 첨부이미지같은 것들은, 포스트에 딸려있는 화일에 불과했습니다. 편집이나 수정을 위해서는 포스트(문서)를 수정해야했죠. 반면에 AtomPub에서는 첨부화일도 엄연한 인격체...아니 리소스로 인정해줍니다. 별도의 주소를 발급하고, 독립적인 사용자의 요청을 통해 상태가 변할 수 있는 것이지요.

개발자분들을 위해, 포스트가 생성된 이후, 클라이언트에게 전달되는 AtomPub 응답 메시지를 살짝 살펴보겠습니다. 아래 진한부분이 바로, 첨부이미지를 위한 주소죠. 보시듯이 편집을 위한 URI까지 알려줍니다.

1.        <?xml version="1.0"?>
          <entry xmlns="http://www.w3.org/2005/Atom">
            <title>The Beach</title>
            <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
            <updated>2005-10-07T17:17:08Z</updated>
            <author><name>Daffy</name></author>
            <summary type="text" />
            <content type="image/png"
               src="http://media.example.org/the_beach.png"/>
            <link rel="edit-media"
               href="http://media.example.org/edit/the_beach.png" />
            <link rel="edit"
               href="http://example.org/media/edit/the_beach.atom" />
          </entry>

AtomPub가 꼭 핵심적인 기술은 아닙니다만, 이런 리소스로 가득찬 웹을 설명해드리기 위해서, 예로 한번 들어보았습니다 ^^ AtomPub는 그야말로 약속입니다. 별 신경쓰지 않고, 이 약속만 지켜도 REST스러운 서비스들의 모범사례(Best Practice)들을, 그대로 구현하는 셈이 되는것이지요. (보통 이럴때 날로 먹는다는 표현을 쓰지요? ^^)

그런데 이게 무슨 소용이야?

사실, AtomPub라는 표준을 쓰지 않아도, 충분히 REST스러운 서비스를 만들 수 있습니다. Atom이라는 포맷도 RSS라는 시장 지배적 표준이 있는 상황에서, 당장 큰 영향을 주지는 못할테구요. 다만, 이 기술을 통해서 몇가지 흐름을 짐작해볼 수는 있을것 같습니다.

• 마이크로 컨텐트(Micro-Content)가 주목받는 세상

결국 Resource라는 것은, Document보다 작은 Data라는 단위의 다른 말에 불과합니다. 왜 이런 세분화가 필요할까요. 앞선 글에서도 말씀드렸지만, 웹은 점점 다양한 데이터들의 보고가 되어가고 있습니다. 그리고 그 데이터들을 잘 조합해서 새로운 컨텐츠를 만드는 능력이 부각받고 있구요. Atom과 같은 기술들은, 이런 필요성에 따라, 기존의 컨텐츠들을 작은 마이크로-컨텐츠로 잘게 잘게 해부합니다. 그리고 그 마이크로-컨텐츠들의 종류(type)를 공개하고, 누구나 가공할 수 있는 이름(URI Address)를 붙여주는 것이지요.

마이크로-컨텐츠와도 무관하지 않은, 마이크로트렌드.

• 다시 HTTP로 대동단결

우리가 사용하는 웹은 HTTP라는 간단하지만, 허술하기도 한 약속(protocol)을 기반으로 하고 있습니다. 그래서 좀 더 심각한 문제들을 해결하려면 어떻게 해야할까? 라는 걱정때문에 XML웹서비스(WS-*로 시작하는 이름의 표준들을 산더미 같이 쏟아낸)라는 복잡한 기술이 탄생하기도 했구요. XML 웹서비스도 HTTP를 기반으로 하기는 하지만, REST나 AtomPub는 이렇게 말합니다. 정말 HTTP 하나면 모든것을 해결할 수 있다구요. 잘만 쓰면 단순하면서도, 강력하게 사용할 수 있는 기술을, 우리가 괜히 오해한것이라고 말이지요. 이렇게 다시금 간단한 약속을 통해, 대동단결이 이루어지면 어떤 일이 일어날까요? 바로 디바이스를 넘어서는 통합에서도, 조금 더 가속도가 붙을 수 있을것 같습니다. 요즘 풀 브라우징을 등에 업고, Mobile Web이 한층 더 각광을 받고 있지요. REST스럽게 설계된 애플리케이션은, 단순히 Representation을 추가해주는 정도의 작업만으로도 새로운 디바이스나 요구에 빠르게 적응할수 있는 장점을 가지기도 합니다.

모바일 + 웹이 하나가 되는 날이 오긴 올텐데..

- 다음 글에 계속 -

더 읽어볼만한 자료

• Building Services with AtomPub (Presentation)

AtomPub에 관한 기술적인 내용들은, 이 발표자료 하나만 보셔도 충분히 파악하실 수 있을것 같습니다 ^^