얼마 전 YTN 돌발영상에서, 이명박 대통령이 시장상인들과 만나서 나눈 대화가 화제가 되었습니다.
시장 상인들은 하나같이 대형마트의 횡포로 인한 영세상인들의 어려움을 호소하는 데, 대통령은 묵묵부답하고 딴청을 피우다가 결국 '당신들은 왜 인터넷 이용해서 장사를 안하는가', '내가 이렇게 얘길 들어주는 것 만으로 감동스럽지 않은가? 옛날 갈으면 다들 찍소리 못했을 텐데 요즘 세상 많이 좋아졌다.'의 답변을 합니다.
요새 정치 소식을 접하면 가슴이 답답하여 일이 손에 잡히질 않아, 이명박 얘기가 나오면 반사적으로 회피하는 버릇이 생겼는데, 어쩌다가 오랜만에 본 이 영상 하나에 힘이 빠져버리네요.
정말 다짐합니다. 국내 뉴스는 되도록 안봅니다.

그동안 BMT로 인하여 정신없이 보내어 본 '웹 2.x시대의 서버측 웹 개발 환경' 시리즈의 세번째 글이 늦어졌습니다.매일 꼬박꼬박 블로그에 글을 올리는 분들이 정말로 존경스럽습니다. 회사에선 업무보랴, 서핑하랴 집에선 노느라 블로깅 하기가 정말 쉽지가 않으니까요. 각설하고 두번째 글에서 RESTful 서비스는 크게 자원과 행위와 컨텐츠의 타입으로 이루어진다고 언급했습니다. 아울러 REST 서비스를 만들기 위한 절차 등을 간단하게 살펴보았습니다. 무엇보다 가장 중요한 핵심은 REST는 자원 중심의 아키텍처다라는 겁니다. 이 '자원'이라는 것부터 오늘의 글을 시작하도록 하겠습니다.

웹의 자원은 어떻게 이루어져있나.

일단 범위를 좁혀서 이 '자원'을 웹상의 자원이라고 구체화시켜봅시다. 이 자원은 동영상이나 일반 문서 혹은 이미지 등등이 될수있습니다. 이러한 웹상의 자원은 무엇으로 이루어져있을까요? 아래와 같이 크게 4가지로 이루어져있다고 보겠습니다.

• URI: 예) http://calmglow.egloos.com/4119223
  
• 액션: 예) GET, PUT, POST, DELETE
• 응답코드: HTTP 403
• 표현 코드: 예) application/xml, text/x-json, application/atom+xml

URI의 패턴들

그 중에서도 먼저 웹의 자원 중 첫번째 가장 중요한 URI를 살펴보겠습니다.
웹상의 자원을 그 특징별로 분류하고 구분하는 작업이 REST기반의 서비스에서는 꼭 필요합니다. 그래야 웹에 자원들을 빠짐없이 일목요연하게 서비스할 수 있기 때문입니다. 자, 우리가 웹상에 뭔가 서비스하려는 그 자원은 대체 어떠한 특징이 있을것이며 어떤패턴을 보일까요? 자원의 특징별로 한번 구분해보기로 합시다.

• 일반 자원들
• 간단한 자원
• 복잡한 자원
• 집합 자원들
• 멤버 자원
• 질의 자원
• 페이징 자원
• 정렬 자원
• 알고리즘 기반 자원

생각보다 자원의 종류는 다양합니다. 또한 REST는 이러한 다양한 자원들을 서비스할 수 있습니다. '일반적인 자원들'은 비교적 이해하기 쉽습니다. 그 중에서도 '간단한 자원'은 그저 /학생 처럼 명사단위로 정의가 가능한 자원입니다. 본 블로그는 모든 글의접근 URL을 http://calmglow.egloos.com/숫자 로 서비스하고 있습니다. 이러한 자원을 '간단한 자원'이라고 부를 수 있습니다. '간단한 자원'에는 계층화된 자원도 포함됩니다. 즉 /1장/1절 처럼 계층화되어 두 단어 이상이 복합적으로 관계를 이루는 경우도 간단한 자원의 일부라고 볼 수 있습니다. 주로 자원이 어떤 데이타의 부분 집합을 가리킬 경우 이렇게 계층적으로 쓸 수 있습니다. '복잡한 자원'들은 뒤이어 설명하게 될 자원들을 통칭하여 부릅니다.

집합 자원들은 하나 이상의 멤버들로 이루어진 자원들입니다. 서재를 예로 들어보면 /서재 라고 질의하면 아마도 무수한 책의 리스트가 나오겠죠. 보통 REST에서는 이러한 집합 자원들을 표현할 때 복수형으로 질의하는 경우가 많으므로 /책들 혹은 /books 라고 표현하기도 합니다. 집합 자원들의 멤버들은 저마다 고유의 ID값을 가지게 됩니다. 그런데 이 ID값은 자원 제공자가 생성할 수도 있겠고 아니면 클라이언트가 만들기도 합니다. 전자의 경우를 예로 들면 GET으로 /고객계정 과 같이 질의를 하는 경우일테고 후자의경우는 POST방식으로 /고객계정/새ID 와 같이 고객을 등록하는 경우일 겁니다.

멤버 자원

REST에서는 이러한 집합 자원들 속의 멤버들에 접근하기 위한 URI 정의가 필요합니다. 즉 집합 자원속의 '멤버 자원'을 접근하는 규칙을 정의해야 합니다. 이를테면 계정 중에서 id가 1234인 것을 접근하고자 할 때 /Account/1234 일 수도 있겠고  /Account?id=1234 일 수도 있겠지요. 또한 어떤 방식은 입력을 위해서, 어떤 방식은 정보를 얻기 위해 별도로 정의되어야 할 수도 있을 것입니다.

만약 집합 자원들 중에서 하나 이상의 자원들을 가져와야할 때의 규칙도 정의해야만 합니다. 예를 들어 /Account?members=all 은 집합 내의 모든 자원을 가져옵니다. 또한 /Account?members=[1234,1235,1236] 은 ID가 1234,1235,1236인 멤버를 가져옵니다.

질의 자원

자원을 웹으로 서비스하면서 이제까지의 방법만으로는 불충분한 경우가 많습니다. 결국 제대로 서비스하려면 보다 유연한 질의 기능이 필요합니다. 때문에 '질의 자원'을 정의하게 됩니다. 보통 '질의 자원'을 정의할 때 정의하기 가장 쉬운 방법은 /Account?name="최진호"&age="34" 와 같이 몇 가지 속성값을 통해서 정의하는 방식입니다. 보다 직관적이기는 하지만 유연성이 많이 떨어집니다. 이보다 더 유연하고 고급화된 방법은 필터 개념을 두는 겁니다. 즉 /Account?filter="논리 표현식" 처럼 보다 다양하고 복잡한 질의를 수행할 수 있도록 하는 것이죠. 여기서 '논리표현식'은 보통 이 논리 표현식을 그대로 알아먹을 수 있는 내부 데이타 표현 시스템의 형식을 그대로 따르는 편이 좋습니다. 즉 SQL 언어나 JPA 질의등이 예가 될 수 있습니다. 이 필터를 쓰는 방식의 예를 좀 더 들어보면 /제품?filter=단가 gt2000 : '제품 단가 2000보다 큰 것들', /고객?filter=name in ('김','이','박') : '이름속에 김,이,박이 있는 고객' 등등이 있습니다.

페이징 자원

아까 /books 와 같이 서재 안의 모든 책을 가져오는 무식한 질의를 예로 들었지만 현실적으로는 적절치 않은 방식이겠죠. 성능이나 안정성 그리고 사용성을 위해서라도 '페이징 자원'은 꼭 필요합니다. 자원 중에 그 순서가 명확한 경우에는 /Account?members=[0-9] /Account?members=[10-19] 와 같은 방법으로 자원을 가져오는 것이 가능합니다. 하지만 어떤 경우에는 순서는 명확하지만 순서내의 숫자가 불규칙적으로 산재된 경우가 있습니다. 즉 id가 1,3,10,11,12,13,14,15,16,44 와 같은 방식일 수 있겠죠. 이런 경우에는 /Account?start=0&count=10 이나 /Account?start=10&count=10 처럼 특정 position을 정하고 거기에서 부터 멤버 갯수를 셈하여 접근하는 방식도 매우 유용한 방식이죠. 아무튼 이러한 '페이징 자원'방식은 그 자원들이 집합 내에서 특정 순서를 가지고 있는 경우에만 유용한 방식이라 할 수 있겠습니다.

정렬 자원

'정렬 자원'은 말 그대로 어떤 기준에 입각하여 정렬하여 자원을 접근하고자 할 때 유용하겠죠. 가장 간단한 방법은/Account?sort=ascending 이나 /Account?sort=descending 처럼 기본 값을(이를테면 id값) 기준으로 정렬하여 볼 수 있습니다. 또한 특정 필드값을 기준으로 정렬하고자 할 때에는 /Account?sortBy="필드1"처럼 정의해두면 다양한 활용이 가능하겠죠.

알고리즘 자원

자원 정의의 무한한 가능성을 소개하기 위해 마지막으로 '알고리즘 자원'을 설명드리겠습니다. 이제까지는 자원의 대상은 눈에 보이고 구체적인 대상이었습니다만 때로는 어떤 비즈니스 로직이나 프로세스가 자원의 대상이 될 수도 있습니다. 예를 들어 '이체'라는행위를 자원으로 보면 어떨까요? 자, 이체라는 자원을 /Transfer라고 정의하고 이것을 행위와 관련지어서 자원을 세부정의해 보겠습니다.
이번 글에서는 주로 URI 패턴에 따라 보통 REST 서비스를 웹상에 구현하려면 필요한 몇가지 필수 REST URI 정의들을 소개했습니다.
더 하고 싶은 심도깊은 이야기도 몇몇 있기는 하지만 도저히 당분간은 시간이 나질 않을 듯 하네요. 아마도 6월 중순까지는 이렇게 몇페이지 짜리 글은 아마도 힘들지 않을까 싶어요.
아무튼 지금까지의 내용은 사실 REST서비스 구축을 위한 아주 기본적인 내용들입니다. 보안, 성능을 위한 캐시, 버저닝, 단위테스트, 동시성 제어, 개발 및 운영 플랫폼 등등 생각해봐야 할 것들은 너무나 많지요. 모쪼록 하반기에는 이러한 내용으로도 이블로그에 글을 채울 수 있기를 기대합니다.

가트너의 "Market Share: Application Infrastructure and Middleware Software, Worldwide, 2008," 자료에 의하면 2009년의 전세계 미들웨어 시장은 SOA나 BPM, WAS, MOM,EAI등 관련 기술들을 모두 포함하였을 때 현재의 전세계 경제상황등을 고려해볼 때 0.8%정도 시장 규모가 하락할 것으로 예상하고 있습니다.
줄여서 AIM 이라고 불리우는 이 시장에서 IBM은 2008년 30.8%의 마켓점유를 하고 있었고 오라클은 BEA를 제외하고 13.6% BEA는 2%정도의 점유를 기록하고 있었습니다. BEA 및 Sun을 인수한 오라클이 선전해준다면 시장의 모양새는 많이 달라질 수 있을 것이고 이는 결국 대형 벤더들간의 과열 경쟁을 이끌어서 고객에게는 나름대로 이익이 될 수도 있겠습니다. 하지만 중소형벤더들의 참여가 더더욱 힘들어지게 될 것이므로 AIM시장은 점차적으로 고착화되지 않을까 저는 예측해봅니다.
하지만 나름대로 이 AIM에서도 새롭게 떠오르는 분야를 통해 새로운 시장 진입을 가능케하는 기술이 있으니 바로 XTP (eXtreme Trasaction Processing)와 CEP (Complex Event Processing or BEP) 입니다. 클라우드기반 시스템이 시장에서 화두가 되면서 향후 XTP와 관련된 제품이 우후죽순 나올 것으로 보이며 BPM이나 SOA 혹은 센서네트워크 시스템과 결합된 CEP(혹은 BEP) 기술도 향후 발전할 가능성이 높은 기술 중 하나로 점쳐지고 있습니다.

개인적으로 아직까지는 XTP시장의 규모를 체감하지 못하고 있습니다. 부분적으로 클라우드 기술과 XTP 기술을 종합한 기술을 관심있어하는 고객도 있긴 했지만 선뜻 구매와 구현을 결정하는 고객은 많지 않아 보였습니다. 그 성숙도에 대한 믿음도 아직은 부족한 듯 하구요.
CEP나 BEP도 아직 국내의 반응은 미지근한 편입니다. 기술은 어느 정도 성숙되어 있으나 아직 기업 내부의 비즈니스와 어떻게 잘 연결시켜서 수익으로 발생시킬 지에 대해 구체적이지 않은 모습입니다.

보다 자세한 내용은 가트너 자료를 보시거나 Report를 참고하시기 바랍니다.

'아테네와 스파르타의 근본적 차이점은, 아테네인들은 스파르타의 체제를 찬양할 자유가 있으나 스파르타에서는 스파르타 이외의 체제를 찬양할 자유가 없다는 점이다.'
고대 그리스의 유명한 정치가이자 변론아긴 데모스테네스가 한 말입니다. 자그마치 2000년 전에 고대인이 남긴 말이 21세기를 살아가는 우리에게 여전히 꿈일 뿐이라는 것이 참으로 부끄럽습니다.
거리에서 촛불을 들 자유조차 쉽게 허락되지 않는 대한민국 사회가 참으로 부끄럽습니다.

요새는 어느 모 고객사에서 진행 중인 BMT에 한달 넘게 참여하느라 블로깅을 하기가 매우 힘이 듭니다. 주말에는 주말대로 여기저기 돌아다녀야 하는 상황인지라...

아무튼 최근에 IBM WebSphere는 DataPower라는 걸출한 어플라이언스를 통해 상당한 재미를 본 모양인듯 합니다. 어플라이언스라는 용어가 생소할 듯 합니다. TTA에서 제공하는 어플라이언스의 정의는 다음과 같습니다.

어플라이언스 (appliance) : 운영 체계(OS)나 응용 소프트웨어의 설치, 설정 등을 행하지 않고 구입해서 전원을 접속하면 곧 사용할 수 있는 정보 기기. 특히 인터넷 접속시에 특화한 어플라이언스 제품이 많은데 기구, 장치 정도를 의미한다. 또 곧 기능을 발휘하는 조립 부품을 지칭하는 경우가 많다.

즉 소프트웨어이긴 한데 직접 설치하거나 설정하지 않고 전원이나 인터넷만 연결하면 알아서 원하는 기능을 실행해주는 All-in-one 성격의 하드웨어+소프트웨어라고 보시면 될 것 같습니다.

우리가 기업에서 사용하는 매우 많은 상업용 소프트웨어의 기술적인 어려움은 특정 하드웨어 및 특정 다른 애플리케이션과의 연계에서 비롯되는 경우가 많다고 생각합니다. 즉 세상에는 설치가 반인 소프트웨어가 참으로 많습니다. 그만큼 세상에는 수많은 하드웨어가 존재하고 그것들 위에서 소프트웨어가 동작하기 위해서는 또 많은 고생이 필요한 것이 현실입니다.

이러한 문제들을 해결하는데, 소프트웨어가 아예 하드웨어와 같이 포함되어버린 어플라이언스는 많은 도움이 될 수 있습니다. DataPower가 바로 그런 어플라이언스입니다. ESB를 어플라이언스화 시켜서 XML 처리의 성능을 극대화시켜버린 것입니다. 그동안 XML 처리의 부담으로 ESB가 시장에서 널리 쓰여지는 데 장애가 있었는데 DataPower는 그러한 틈새를 제대로 메꾸고 있습니다. 비단 DataPower같은 미들웨어의 어플라이언스 뿐만 아니라 BI쪽에서는 보다 더 공격적으로 이러한 어플라이언스를 개발하고 있습니다. Cognos의 Cognos Now!는 대표적인 BI쪽에서의 어플라이언스입니다.

이번에 새롭게 DataPower와 같은 개념의 어플라이언스가 출시되었습니다. Websphere CloudBurst Appliance가 바로 그것입니다. 그동안 WAS를 설치하고 확장하고 애플리케이션을 Deploy하고 개발계에서 테스트계로, 테스트계에서 운영계로 왔다갔다 하는 인적 비용을 획기적으로 감소시킬 수 있는 WAS를 위한 어플라이언스입니다.


기본적인 개념은 이렇습니다.
CloudBurst내에는 리눅스기반의 VMware image가 여러 버전과 상황별로 저장되어 있습니다. 그리고 CloudBurst는 고객이 원하는 서비스 계약 수준에 맞게, 부하가 몰리거나 장애가 발생하거나 특정 비즈니스 상황에 맞게 모니터링을 하다가 적절한 시점에 애플리케이션을 추가하거나 삭제하고 클러스터를 확장하고 WAS를 설치하고 삭제하는 일련의 작업을 가상환경에서 수행할 수가 있습니다. 개발계와 운영계를 완전히 동일한 방식으로 구성하여 테스트하고 설치할 수도 있습니다.

짧게나마 간단하게 CloudBurst의 기본적인 개념을 설명하였습니다만, 그보다 더 놀라운 여러가지 기능을 숨기고 있는 듯 합니다. 얼마전 Sun Microsystems를 인수한 오라클 역시도 Sun의 하드웨어 기술을 이용하여 다양한 어플라이언스 제품군을 준비하고 있다고 합니다. 클라우드 컴퓨팅 기술을 활용한 이러한 움직임을 통해 기업의 IT운영환경의 성능이 보다 좋아질 수 있겠지요. 비용 절감도 가능할지는 잘 모르겠습니다..^^

음양의 조화와 같이
남자 둘이 사이좋게 길을 걸어가는 것은 좋아보여도
남자 둘이 뽀뽀하고 한집살림하며 사랑하는 것이 어색해보이듯

IBM과 SUN의 관계도 그러했는지 모르겠네요.
스타일이 비슷하기에 한집살림 하기가 어려웠겠지요.

오히려 시너지는 서로 다른 것이 많을 때 있는 것이라고 볼 때
오라클의 썬 마이크로시스템즈 인수는 IBM과 썬의 그것보다 더 크게 유익할 것이라고 봅니다.

자바가 가진 색깔이 오라클의 합병으로 인해 퇴색되지 않기만을 바랍니다.

작년 한참 전세계가 경제 위기로 휘청거리고 있을 무렵 IBM의 샘 팔미사노 회장은 'Smarter planet'이라는 알쏭달쏭한 이야기로 IBM이 나아가야할 비전을 세웁니다. IBM은 자기가 IT업계의 禪僧(선승)쯤 된다고 생각하는 것 같습니다. 3-4년을 주기로 IBM은 일반 사람이 참으로 이해하기 어려운 화두같은 단어를 끄집어내어 세상을 어리둥절 하게합니다. 어떤 이들은 무시하고 넘어가지만 그래도 다른 이도 아니고 IBM인지라 대체 무슨 뜻인지 골몰하고는 그들만의 해석을 하기도 합니다. 어떤이는 IBM의 숨은 뜻을 따르다가 엿먹기도 하고 어떤 이들은 또 좋은 비전을 발견하거나 돈벌이를 찾기도 합니다. e-Business나 SOA등이 그러했지요.

이번에 그들은 Smarter planet이라는 용어를 제시합니다. 한국IBM은 이를 '똑똑한 지구'라고 번역했지만 저는 왠지 똑똑함이라는 표현보다는 똘똘한 지구가 더 어울린다고 생각합니다. 똑똑하던 똘똘하던간에 그 대상이 지구라고 하니 조금 의외입니다. 어떻게 지구가 똘똘해질 수 있을까요? 그리고 IBM은 왜 지금 이 시기에 똘똘한 지구를 만들겠다고 나선 것일까요? IBM이 무슨 슈퍼맨도 아닌데 말입니다.
이제까지 인터넷을 비롯한 컴퓨터와 우리가 살고 있는 이 실세계의 관계는 주로 위의 그림과 같았습니다. 즉 실세계의 모든 것들은 가상화되어, 디지털화되어 컴퓨터안에 담겨져왔습니다. 이것을 더 잘하기 위해 컴퓨터는 똑똑해지고 똘똘해져야만 했죠. 그랬던 것이 최근의 여러가지 상황이 맞물리면서 그 반대의 상황을 진지하게 고려할 시점이 왔다고 IBM은 이야기하고 있는 것 같습니다.
즉, 경제위기, 환경위기, 인구위기 등 실세계가 접하고 있는 위기를 이제는 컴퓨터 기술이 앞장서서 실세계에 뛰어들어야 한다는 것이죠. 이를 위해 컴퓨터는 더 다양한 모습으로 보이지 않는 곳에서 실세계에 존재하게 됩니다. 어디서 많이 들어본 얘기일 겁니다.

예. 유비쿼터스. 몇년 전 사람들의 관심을 한몸에 받고 지지부진하고 있는 분야죠. IBM은 유비쿼터스를 이야기하려고 Smarter Planet을 끄집어내었습니다. 물론 꼭 유비쿼터스만 하려고 하는 것은 아니지만 근래의 IBM은 오바마 정부와 손잡고 매우 다양한 사업을 벌이고 있더군요. 그 대표적인 것이 수돗물 사업이죠.

현재 RFID 칩의 가격은 거의 1000원 미만으로 내려갔습니다. 언제나 가격이 떨어지고 기술이 대중화되려나만 바라보고 있던 RFID/USN사업도 올해부터는 300억원을 국가가 신사업으로서 투자를 한다죠? 이제 조금씩 새로운 기술에 의한 변화가 다가오고 있음을 느낍니다. 그 변화를 '똘똘한 지구'로 부르든 '유비쿼터스'로 부르든간에 우리가 알고있고 정의하고 있던 네트워크 노드들 즉 컴퓨터, 핸드폰, MP3, PMP, 서버같은 눈에 보이는 것 말고도 수없이 많은 실세계의 개체들(이를테면 먹거리나 교통, 건축, 등등)이 네트워크 노드에 점점 포함되어가는 시대가 머지않아 올 것이라는, 인터넷이 아닌 지구넷이 되는 언젠가의 시작이 지금부터 일수 있다는 생각을 합니다.