REST (Representational State Transfer) 라는 것을 아시는지... 본 블로그를 뒤져보니 2003년에 REST를 최초로 언급한 글이 있습니다. 그때는 국내에 REST를 아는 분이 거의 없었고 저 역시 그저 정말 사용하기 쉽구나 정도의 감탄만을 했을 뿐이었는데, 결국은 이렇게 웹 2.0과 함께 화려하게 등장했네요. 결국은!

얼마전 서울 시내 서점에 가서 Web 2.0이나 AJAX관련 책들을 둘러봤습니다. 수많은 AJAX관련 서적에 놀라서 하나씩 하나씩 목차만 보고 넘어갔는데, 거의 대부분은 말 그대로 Open API를 이용해서 매쉬업해서 새로운 클라이언트 애플리케이션을 만드는 내용이었습니다. 기본적으로 자바스크립트와 AJAX, JSON, Dojo, RSS, ATOM등의 기술을 소개하는 책들이 대다수이더군요. 하지만 이러한 클라이언트가 갖다 쓸 수 있는 Open API를 구축하는 기술 및 경험을 다룬 책(번역서 포함)들은 거의 없었습니다. 제가 보지 못한 것일 수도 있으니 좋은 책이 있으면 알려주시면 감사하겠습니다. 이 '웹 2.x 시대의 서버측 웹 개발 환경' 시리즈는 말 그대로 클라이언트 개발자가 아닌, 서비스를 제공하는 서버측 웹 개발자를 위한 기술적인 내용을 다루려고 합니다. 그러려면 이 REST에 대해 보다 조금은 알고 넘어가는 게 좋겠습니다.

REST는 무엇인가요?

REST는 2000년에 Roy Fielding이라는 분이 고안한 소프트웨어 아키텍처입니다. 이 REST를 다룬 최초의 논문은 아래 링크에서 확인하실 수 있습니다.
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
하지만 위의 내용만으로 REST를 이해하기란 여간 어려운 일이 아닙니다. 이러한 난해함은 그것을 정리한 영문 위키 페이지나 한글 위키 페이지에서도 크게 다르지는 않습니다. REST를 구현해서 쓰기란 참으로 쉬운데 개념은 이토록 추상적이고 오묘해서인지, 국내에 나온 웹 2.0관련 번역서나 저서에서도 알기 쉽게 REST를 설명하지는 않는 듯 합니다. 몰라도 쓰는 데는 큰 지장이 없거든요.
그러면 REST를 이용한 웹 아키텍처의 특징을 하나씩 살펴봅시다.

먼저 REST는 다음과 같은 특징을 갖고 있습니다.
클라이언트- 서버 방식(특히 pull 방식입니다)의 아키텍처 스타일입니다. 또한 Stateless (무상태)의 특성과 느슨한 연결의 특징을 가지고 있으며 어떤 통일된 인터페이스를 가지고 있습니다. 무엇보다도 REST의 특징은 Resource 즉 자원 중심의 아키텍처라는 것입니다.
따라서 저는 REST를 '자원 중심의 클라이언트-서버 아키텍처'라고 정의해도 무방하다고 생각합니다.

REST에서는 모든 행위의 시작은 자원의 인식부터입니다. 이것은 RPC방식과는 다릅니다. 예를 들어 서버에서 제공하는 서비스를 통해 무언가를 주문하는 행위를 하려면 RPC의 경우는 purchase() 함수에 필요한 정보를 담아서 서버에 전달합니다. RPC의 주된 관심은 Call입니다. purchase라는 함수의 호출이죠. 하지만 REST의 방식은 먼저 자원이 인식되어야 합니다. 즉 구매주문서/구매내역 이라는 자원이 먼저 인식된 후 이 자원에 대해 통일된 API(웹의 경우 GET,POST,PUT,DELETE)를 이용하여 주문을 하거나 주문 내역을 보거나 취소하게 됩니다.

위의 예를 이해할 수 있으시겠습니까? 어쩌면 REST는 객체지향 방식이라고도 볼 수 있을 것 같습니다. 객체(자원)를 먼저 정의하고 객체 내부에 행위를 포함하고 있는 형태죠. 다만 이 행위 즉 인터페이스가 모든 객체에게 있어서 동일하다는 것이 일반적인 객체지향 방식과 차이점이라고 봐야합니다.

어쨌든 REST라는 아키텍처는 웹 아키텍처와 너무나 잘 어울리고 딱 들어맞습니다. 웹은 REST의 특성을 지니게 되어 오늘날의 성공을 이루었다고 혹자들은 말을 합니다. 웹을 이 REST에 맞게 쓰는 것은 참으로 쉽습니다.

http://호스트/고객
 GET: 고객들의 목록을 가져온다
 POST: 신규 고객을 추가한다
http://호스트/고객/최진호
 GET: 최진호 고객의 정보를 가져온다
 PUT: 최진호 고객 정보를 업데이트 한다.
 DELTE: 최진호 고객 정보를 삭제한다.

위의 예처럼 일단 자원을 URI 작성 방식에 맞게 정의하고나면 그것으로 취할 수 있는 기본적인 행위를 유추하기란 어려운 일이 아닙니다. 일반적으로 필요한 인터페이스를 웹은 이미 제공하고 있습니다. 따라서 굳이 복잡하게 SOAP이나 RPC를 웹에서 별도로 구현해서 사용할 필요도 없어집니다.

REST의 오해

많은 분들이 REST에 대해 오해하시는 것 중 하나는 REST는 HTTP 프로토콜을 이용해서 직접 XML문서를 전달하는 방식이라는 것. 위에서 언급한 것처럼 REST는 그저 아키텍처 스타일인 것이고 XML로 내용을 보내든 어떤 것을 보내든 그것은 중요한 것이 아니라는 것이죠.
또한 REST는 HTTP method가 제공하는 CRUD (Create, Read, Update, Delete)만을 사용할 뿐이라는 오해입니다. REST를 이용해서 구현할 수 있는 것은 무한합니다. 이 시리즈를 통해 다양한 REST기반 서비스를 구현하는 데 필요한 정보를 얻으실 수 있을겁니다.

RESTful 웹서비스

이렇게 REST 스타일로 웹의 서비스를 구현했을 때 우리는 이를 일컬어 RESTful 웹서비스라고 합니다. 이 RESTful 웹서비스는 세가지 특징을 가지게 되고 이것이 바로 RESTful 웹서비스의 삼위일체설(?)입니다.
즉, RESTful 웹서비스는 자원과 행위와 컨텐츠 타입으로 구성되고 이는 각각 URI와 HTTP Method 그리고 MIME type등으로 이루어지게 됩니다.

RESTful 웹서비스 만드는 순서

이러한 RESTful 웹서비스를 만드는 데도 물론 순서가 있습니다.

1.  무엇보다 자원 식별 및 자원의 식별자를 정의해야 합니다. 예를 들어 직원 관리 관련 서비스를 만들 때 제공하고자 하는 것이 개별 직원에 대한 것인지 아니면 전체 직원 정보에 대한 것인지에 따라 자원 식별자는 /employees 일수도 있고 /employee/empid1 일 수 있을 것입니다.
2. HTTP 요청/응답에 관련된 헤더의 내용을 정의해야 합니다. 즉 Accept, Content-Type 등이 포함될 수 있습니다.
3. 주고받는 데이타의 형식을 정의해야합니다. 크게는 JSON, XML, PDF, 이미지 등이 될 수 있고 다시 세부적인 설계가 필요할 수 있겠지요.
4. 각 자원들에 대해 어떠한 method를 제공할 지를 결정해야겠죠.
   
5. 마지막으로 HTTP가 Return하는 상태 코드(Status code)에 대해 정의해야 합니다. HTTP는 기본적으로 이러한 코드를 이미 제공하고 있습니다. 이에 대한 확장과 재정의 작업을 통해 클라이언트가 보다 세부적인 행동을 취할 수 있게 해야 합니다.

이 다섯가지 단계는 가장 기본적인 순서일 뿐이며 보다 자세한 내용은 다음 글에서 계속 다룰 예정입니다.

매력덩어리 REST

간단하게 REST에 대해 소개하였습니다. REST 방식의 웹서비스는 참으로 단순 명료하기 때문에 다양한 잇점을 가지고 있습니다. 우선 개발이 용이하다는 점이 있고 서비스 운영 측면에서는 클라우드 컴퓨팅에 적용하기 매우 편하다는 점, 캐시같은 여러 기존의 성능 향상 기법을 도입하기 용이하다는 점,URI별로 개별적인 보안 특성을 부여하기가 쉽다는 점등 상당히 많은 장점을 가지고 있습니다. 때문에 구글 뿐만 아니라 Amazon이나 eBay, Yahoo, Twitter등과 같은 웹에 기반한 서비스를 제공하는 기업들은 이 REST기반의 OPEN API를 제공하고 있지요. 다음 글에서는 REST기반의 웹 서비스를 구현하는 보다 자세한 내용을 다룰 것입니다. 또한 RESTful 서비스가 왜 기업환경에서 쓰여야 하며 어떤 효과가 있고 이를 위한 개발 운영환경은 어떠한 것이 고려되어야 할지도 찬찬히 다뤄보겠습니다.

현실에서는 다양한 자유와 권리가 골고루 중요하지만 인터넷에선 표현의 자유가 곧 거의 모든 자유를 말합니다. 인터넷사회에서 표현의 자유가 억압된다는 것은 현실에서의 행복 추구권, 주거권, 사생활 보호권, 인권 등등 다양한 권리를 보장받지 못함과 동일합니다.

현실은 어떤지 몰라도 인터넷에서의 한국 국적은 디지털 유목민 입장에서는 이로울 게 없는 부끄러운 국적이므로 오늘 나는 디지털 난민이 되어 소말리아로 망명을 신청합니다. 당신은 어느 나라로 망명하시겠습니까?

웹 2.0 시대는 갔다?

성질이 못되서인지 남들이 우르르 몰려드는 곳이나 주제에 대해 다르게 생각하는 것을 즐기는 편입니다. 저에게는 '웹 2.0'의 등장도 그랬습니다. 비교적 다른 이들보다 일찍부터 웹이 가져다줄 변화 가능성에 눈떴던 만큼 그런 웹의 가능성을 2.0이라는 이름으로 다시 치장하려는 사람들의 행위가 마음에 들지 않았을 것입니다. 그래서 저는 그동안 사람들에게 웹 2.0의 거품을 더 얘기했던 것 같습니다. 그랬던 웹 2.0이 화려한 등장을 뒤로 하고 조금씩 우리들의 관심에서 멀어지고 있는 것처럼 보입니다. 웹 2.0은 허깨비였던 것일까요?

지금은 웹 2.x 시대?

하지만 웹 2.0의 회의론자였던 저는 지금 웹 2.0을 부정하기가 어려움을 인정합니다. 그동안 웹은 너무 많이 바뀌었잖아요? 닫혀있고 감춰졌던 웹의 자원들(Resources)은 열렸고 보다 쉽게 사용할 수 있게 되었습니다. 현실 세계가 웹처럼만 바르게 가면 얼마나 좋을까를 생각해볼만큼 웹은 바른 길로 가고 있습니다. 누가 강요하지 않아도 스스로 표준과 기본 철학을 따라서 점점 알아먹기 쉽고 모두에게 평등하며 악(惡)하지 않은 방향으로 진화해가고 있습니다. 국내 대부분의 웹포털은 그들의 서비스에 Open API를 제공하고 웹 표준을 지킴으로써 다양한 어플라이언스에서 사용이 가능하도록 배려하고 있습니다. 전통적인 기업들에서도 웹 2.0의 바람은 거세어져서 웹 2.0의 여러 기술들은 다양한 방식으로 채용되고 있습니다. 다양한 어플라이언스(클라이언트)를 배려하고 재사용이 가능하도록 API와 표준화된 인터페이스가 당연히 제공되는 분위기, 우리는 지금 웹 2.x 시대를 살고 있습니다.

서버측 웹 개발 환경은 그대로일까?

그동안 웹 2.0기술은 순전히 클라이언트 기술로 충분히 해결이 가능하다고 여겨졌습니다. 흔히 웹 2.0의 대표 기술이라 불리던 AJAX가 그동안 서버측 웹 기술로 구현되던 것을 브라우저에서 구현한 것이기 때문에 서버측 웹 개발 환경이 크게 변할 것들은 많지 않았죠. 물론 XML 처리 구현이 조금 늘기는 했으되 부담을 느낄 정도로 변화가 많다고 보기는 힘들겠죠. 그러다보니 사실 그동안 몇년간 JSP나 서블릿, PHP 같이 서버측 웹 개발 기술에서 이슈가 될만한 기술이나 패러다임들은 그다지 나타나지 않았습니다. 하지만 그것은 웹 2.0 시대의 얘기인 것 같습니다. 우리는 지금 수없이 많이 공개된 웹 서비스들이 존재하는 웹 2.x 시대에 살고 있습니다. 무언가 변화가 오고 있습니다.



웹 기반 애플리케이션의 서비스 흐름에서 볼 때 전통적으로 서버는 웹 브라우저 및 클라이언트에 대해 그들이 실제 원하는 서비스에 대해 중재자 (Facade 혹은 Mediator) 역할을 수행하였습니다. 이러한 아키텍처에서는 서버의 힘이 매우 큽니다. 클라이언트와의 통신 방식과 클라이언트에게 전달할 서비스의 내용을 책임지며 모든 데이타가 오고가는 통로이기 때문에 컴퓨팅 파워와 안정성도 매우 중요할 수 밖에 없습니다. 즉, 서버 하나만 잘 키우면 되는 방식입니다.
반면에 웹 2.x 시대에는 권력의 일부가 웹브라우저 및 클라이언트로 이동합니다. 클라이언트는 원하는 서비스의 중재 역할의 일부를 담당하고 이러한 서비스들간의 조합을 통해 보다 사용자 중심적인 환경을 제공받습니다. 전통적인 방식에서는 클라이언트와 서버간의 통신 방식을 서버가 정하지만 웹 2.x 시대에는 다음과 같은 3가지 기술이 사용됩니다.

단순하고 쉽다고 막개발해선 안된다

흔히들 서버측 웹 애플리케이션을 개발하고 운영하는 분들은 이러한 웹 2.0 기술을 대수롭지 않게 여깁니다. 그만큼 기술적인 난이도가 어려운 것도 아니고 오히려 서버측에서 했어야 했던 일을 클라이언트에 일부 위임하는 것이니 더더욱 주먹구구식 설계 및 개발, 운영이 되기 쉽습니다. 하지만 클라이언트의 접근과 서비스, 컨텐츠의 모양 및 보안, 거의 모든 것을 서버에서 알아서 담당했던 예전과 다르게 웹 2.x 시대의 서버는 보다 많은 자유를 클라이언트에게 제공하게 되면서 또 다른 체계적인 개발 방법과 환경을 고려하게 되었습니다. 본 '웹 2.x 시대의 서버측 웹 개발 환경 변화' 시리즈에서는 이러한 내용을 몇 편에 걸쳐서 다루려 합니다...

IT 차세대 프로젝트 오픈이 얼마 남지 않은 어느 회사의 건물을 방문하여 잠깐 누군가의 일을 도와주고 짐을 싸는 중이었다.
여느 막바지의 프로젝트 사무실과 마찬가지로 누렇게 사람들의 얼굴은 떴고, 사발면이 구석에 보이고 여기 저기 신경질적인 목소리가 오간다.

뒤에서
누군가들의 대화가 들린다.

'냉장고를 열어보니 반찬통같은 게 보이더라구. 뭔가 했더니 김과장 보약이더라. ㅋ'
'이거 IT 프로젝트 한번 빡세게 하면 의료업계가 좋아할 일이네'
'특히 한약업계 잘 나가겠네 하하'


거의 매일
밤을 새는 그들에게
비타500정도는 간에 기별도 안될 것이다.

밤 9시, 먼저 퇴근하게 되어 눈치를 보며 빠져나온다.
봄인데 날씨가 다시 추워졌다.

현재 IBM이 Sun Microsystems와 인수와 관련하여 회의 중이라는 기사가 어제 저녁부터 시간을 다퉈서 여기저기에 다뤄졌다.
참고: IBM's potential purchase of Sun: Here's why it makes sense -zdnet, IBM in talks to buy Sun Microsystems: report (Reuters)

만약 인수시도했던 업체가 HP나 시스코 혹은 Dell이었다면 왠지 Sun양이 외국남자한테 팔려간다는 느낌이 들 것 같은데, 그래도 IBM이라니까 부잣집에 팔려가는 것 같아서 그나마 모양새가 이상하지는 않다.

하지만 사실 IBM이 꼭 Sun을 인수해야했는지, 겹치는 사업부분이 너무 많아서 인수 효과가 별로 없을 것만 같은 이 인수협상에 의문이 너무 많다.

우선 서버 시스템의 경우 Sun은 이미 지는 해요, IBM은 한창 잘 나가고 있는 상태가 아닌가? 아무리 Sun이 전세계 Market share로 10%를 점유하고 있다지만 그것만으로 65억달러의 인수액이 설명해주지는 않을 것 같다.

설마 얼마 전 Sun이 인수한 MySQL로 IBM이 뭔가를 할 수 있을리도 없고, 또 얼마 전 인수한 VirtualBox가 가상화솔루션으로 좋은 평가를 받고 있지만 IBM이 그 정도에 군침을 흘렸을리는 만무해보인다.

그래 Sun에게는 자바가 있다. 아마도 그것 때문에라도 어차피 팔릴 Sun이라면 IBM이 다른 누군가가 사버리기 전에 접수하는 게 나을 것이리라.

아무리 자바 스펙 프로세스인 JCP가 모든 벤더에게 오픈이라지만 그래도.. 자바 SE에 SWT가 추가될 지도 모르고, 웹스피어가 앞으로의 자바 EE의 참조 구현체가 될 수도 있겠지. Eclipse와 대결하던 NetBeans, 나름의 장점을 갖춘 좋은 개발환경인데 그것도 어쩌면 팽당할 지도 모른다. Sun JVM과 IBM JVM 이 서로 완벽하게 다르게 설계된 JVM이 서로 어떻게 발전할 지, 아니면 Sun JVM이 개발 중단될지 모른다. 어쨌든 이전의 Sun보다 IBM이 Java를 보다 능동적으로 발전시킬 가능성이 많다고 보여지는 건 사실이다.

하지만 자바 초기부터 자바를 사랑해온 내 입장에서 보자면, 사실상 자바계를 이끌어온 두 거인 중의 하나가 사라진다는 사실이 가장 중요하다. 자바가 자바일 수 있는 이유는 어느 벤더도 자바에 대해 완벽한 헤게모니를 장악하고 있지 않은 점이라고 생각한다. Sun도 이제까지 그러한 Play를 나름대로 잘 해왔다고 생각하고 이러한 중립성이 그나마 오픈소스 진영에서도 약간의 잡음은 있었을지언정 통했기에 이제까지 수많은 오픈소스 프로젝트가 자바로 진행된 바 있다고 생각한다.

누구나 생각하기에 '자바는 Sun이 만들었지만 누구의 것도 아닌 언어'였지만 이제 두 거인 중 하나가 다른 하나에게 통합되어 IBM 및 다른 벤더로 남게 된다면 자바가 지닌 이 중립성이라는 이미지가 얼마나 지속될런지 의문이다.

명박 대통령이 대통령 후보시절 747 공약을 내걸어 화제가 되었다.
좀 안다 하는 사람들은 코웃음쳤다. 한 나라의 나아갈 길이 그런 숫자놀음으로 결정될 수 없는 것일 뿐더러 그런 목표 자체도 어이없었기 때문이다. 실제로 747은 결코 지켜질 수 없는 공약인 것이 드러났고 앞으로도 그의 공약은 두고두고 사람들의 기억속에 자리잡을 것이다.
그런데 문제는 명박 대통령이 어쨌거나 승리한다는 것이다. 원래 우리나라의 문제는 747이 아니었건만 명박 대통령이 엄한 747이라는 공약을 내걸면서 멀쩡하던 사람들은 이 747이 안지켜지나 지켜지나에 관심이 쏠리고 명박 대통령이 만들어놓은 틀에 자연스럽게 반대자들까지도 관심을 갖게되는 상황이 되는 것이다. 결국 747이 실패하면 그것을 지켜본 반대파와 찬성파 모두가 실패한다. 왜냐하면 747이 아니라 다른 게 중요한 것이었으므로 반대자들은 적어도 새로운 대안을 모색했어야 하는데 찬성자 반대자 모두가 747에만 관심을 가졌기 때문이다. 반면에 747이 얼치기로 혹은 비슷하게라도 우연히 달성되면 찬성파는 성공한다.
한 나라가 나아가야할 길이 어찌 기업 운영처럼 숫자놀음으로 결정될 수 있을까? 하지만 이미 이 숫자에 현혹된 모든 대한민국의 국민들은 '경제가 어렵다는데' 아무 말 못하고 몇 천년간 그랬던 것처럼 당하고만 있는다.

나라 운영만이 아니라 기업 운영이나 자기 경영에 있어서도 경쟁 관계에서 생각의 판을 먼저 선점하는 자가 결국은 승리한다. 장기두는 규칙을 한쪽이 정해놓고 시작하는 것은 홈그라운드에서 하는 것과 다르지 않다.

설치형 블로그, 위키, 홈페이지등을 직접 만들어 운영해오다가 이게 뭔 노가다냐 싶어 가입형 블로그로 옮긴지 4-5년이 지났다. 가뭄에 콩나듯 드나들던 손님들도 가입형 블로그 하면서 부쩍늘고 도메인만료인 것도 모르고 지내다가 어떤 놈이 잽싸게 내 도메인 훔쳐가는 것도 없고 백업하고 업글하던 것도 없어서 정말 좋다. 하지만 좋아진 만큼의 불편한 점도 있더라.

애착감이 덜하다. 내 도메인과 계정가지고 있을 땐 열흘에 한번은 리뉴얼을 했던것 같다. 뭔 고칠 게 그리도 많고 버그는 많이 보이던지, 자꾸 더 나은 무언가가 눈에 보이니까 손도 가고 그러다보니 애착이 더 갔었다.

노가다 기술이 떨어지더라. 맨날 CSS, HTML, JavaScript, MySQL, 포토샵 가지고 놀았었는데 이젠 포토샵이 비주얼 스튜디오 C++로 보인다. 포토샵 실행하려다 손가락 떨고있는 자신을 발견하고선 Picasa의 'Feeling Lucky!' 버튼만 가볍게 깔짝거린다.

생각해보니 단점이 그렇게 많은 것은 아니네.. 얼마 전 무한 자유로운 CMS툴인 Drupal을 알게되었다. 단지 블로그 설치로만 쓰는 게 아니라 커뮤니티나 그 외 다양한 응용이 가능한, 과거 PHPNuke같은 건데, 훨씬 자유로운 확장성을 장점으로 가지고 있다고 한다. 너무 자유로워서 일반 사용자는 쓰기가 엄두안난다고 하는데, 이런 것이야 말로 나같은 사람들이 원하는 로망! 4-5년전 수많은 CMS(content management system)와 Wiki를 설치하고 지지고 볶고하던 기억이 새록새록하다.

P.S. Drupal을 공짜로 얻어살고 있는 계정에 설치하려다가 register_globals 문제로 막혀버렸다. .htaccess나 php.ini로 해결이 안되니 결국 실패... ㅜㅜ 언제쯤 맘놓고 서버호스팅을 해볼랑가...