하루 죙일 인터넷으로 온갖 업무와 여가를 즐기기 위해 여기 저기 돌아다니는 나에게 웹브라우저의 선택이란 자가용으로 아반떼를 살건지 그랜저를 살건지 선택하는 문제보다도 사실 비용만 들지 않는다 뿐이지 삶에 있어서 더 중요하고 실질적인 문제.
내가 모든 IT기기를 선택하는 데 있어 가장 중요하게 생각하는 선택 포인트는 뽀대도 아니요, 기능도 아니요, 성능도 아니다. 다름아닌 플랫폼의 공개여부와 확장성. 천생이 엔지니어인 나는 어쨌든간에 내 입맛대로 수정해서 최적화하지 않으면 모든 게 내 세상같지 않고 불편하다. 제 아무리 세상 모든 좋은 기능 죄다 박아넣었다 한들, 제 아무리 세상에서 가장 섹시한 디자인으로 떡칠을 한들, 나는 나만의 요구사항과 개성이 있다. 내가 원하는 대로 장식하고 기능을 추가하기 어렵다면 그것은 남의 떡일뿐.
그래서 나는 불여우, FireFox다. 회사 인사시스템 검색을 쉽게 해주는 확장기능을 만들어 넣고, 내 맘대로 자바스크립트 만들어서 자주 가는 사이트의 모양새도 적절히 바꾼다. 수많은 공개 확장기능은 너무 유명한 게 많아서 얘기하기도 입이 아프다.

그런데 이번에 3.5로 버전이 올라가면서 성능까지 너무나 좋아졌다(자바스크립트엔진 성능비교표). IE는 이미 아웃오브안중이고 구글 크롬처럼 메모리 잡아먹는 괴물만큼이나 성능이 좋아졌으니 불여우에 날개를 달게된 격.

얼마 전 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과 썬의 그것보다 더 크게 유익할 것이라고 봅니다.

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