라이브러리
프로그래밍언어, 각종코드, 관련동향, 논문 등의 저장소
IT Library (284)
<img src="http://blogimgs.naver.com/nblog/ico_scrap01.gif" class="i_scrap" width="50" height="15" alt="본문스크랩" /> [펌]사용자 참여적인 인터넷의 '태그' 기능
'태깅(tagging)'이라는 단어가 인터넷 업계에서는 요즘 뜨겁다. 사진 공유 서비스인 플리커(Flickr, http://flickr.com/)가 대표적인 예이다. 누구든 직접 찍은 사진을 올리고 공유하는 플리커는 디지털 카메라의 보급과 함께 5천만 명이 넘는 사용자를 확보했다.

플리커에서 중요한 기능 중 하나가 사진을 올릴 때 '태그'를 달 수 있다는 것이다. 주제와 관련 있는 키워드를 선택해 붙이면 다른 사용자가 쉽게 관련 사진을 검색해서 볼 수 있다. 현재 플리커에 올라오는 사진 중에서는 3분의 2에 해당하는 사진에 태그가 달려 있다.

플리커의 '태그' 개념은 이제 인터넷에서 흔히 찾아볼 수 있는 기능이다. 여러 사람이 관심 있는 웹 페이지 링크를 공유하는 공유 북마크(social bookmark)나 블로그, 음악 서비스, 온라인 서점 등에서도 응용되고 있다. 사용자가 정의하는 체계라는 점에서 한동안 학계 등에서는 '폭소노미(folksonomy)'라고도 불렸으나 최근에는 '태깅'으로 더 많이 사용된다.

태그의 본질은 참여적, 자발적이자 '사회적'이라는 것으로, 콘텐츠를 다중 사용자가 공유하기 위한 열쇠가 된다는 특징이 있다. 어떻게 생각하면 매우 간단한 개념이지만, 그 효과는 증폭되어 중구난방이던 웹에 체계적인 의미를 부여할 수 있는 기회가 되고 있다. 자발적이고 분산적인 색인이 동시다발적으로 생겨나 여러 가닥으로 흩어진 웹을 찾아 보기 쉽도록 정리해주는 결과를 낳기 때문이다.

플리커와 비슷한 태깅 서비스가 활발히 쓰이고 있는 사이트로는 공유 북마크 사이트로서 많은 사용자를 보유하고 있는 딜리셔스(http://del.icio.us/), 블로그 사이트인 테크노라티(http://www.technorati.com/) 가 있다. 딜리셔스 사용자들은 각자가 모은 북마크에 적당한 태그를 붙여둔다. 예를 들어 "리눅스", "윈도우즈", "오픈소스" 등의 주제로 태그가 달린 북마크들은 다른 사용자들이 쉽게 찾아서 공유할 수 있다. 관련 태그를 타고 옮겨가면서 관심 분야의 웹페이지들을 매우 편리하게 수집할 수 있다는 것도 큰 장점이다.

전문가들은 태깅 서비스가 앞으로 어떤 형태로든 기존 검색 엔진 기능에 흡수될 것이라고 예측하고 있다. 구글에 뒤이어 검색 엔진 시장 점유율 2위인 야후사가 플리커를 인수한 것만 봐도 이러한 예측이 근거 없지 않다는 점을 알 수 있다.
  Comments,     Trackbacks
<img src="http://blogimgs.naver.com/nblog/ico_scrap01.gif" class="i_scrap" width="50" height="15" alt="본문스크랩" /> 폭소노미(folksonomy)
● 폭소노미(folksonomy)란? / 2005. 9. 12.

 

http://ciroo.com/fantazic/index.php?pl=153&setdate=200509&PHPSESSID=9e3c821ab68e416dee40516eb426fe24


Folksonomyis a neologism for a practice of collaborative categorization using freely chosen keywords. - from WIKIPEDIA(폭소노미자유롭게 선택된 키워드를 사용해 구성원이 함께 정보를 체계화하는 방식의미하는 신조어이다.)

 

(Rojo에 사용된 Folksonomy)


최근 Flickr나 Rojo 등에서 많이 사용되고 있는 폭소노미가 기존의 분류체계와 다른 점은 구성원들이 자발적으로 개별정보에 의미를 부여함으로써 단위정보를 체계화한다는 것이다.

주요 구성원과 상호작용하면서 정보가 나열되기 때문에 보다 정확하게 의미있는 정보를 전달할 수 있는 장점을 지니고 있다.

폭소노미에서 사용자가 정보에 의미를 부여하기 위해서 그 이면에 태깅(Tagging) 기술이 사용되고 있다. 태터의 global keyword와 비슷한 개념인 태그는 Flickr의 개별 사진이나 del.icio.us 의 즐겨찾기와 같이 하나하나의 원소에 복수개의 단어로 의미를 결합시키는 방식을 의미한다. 즉, 카트리나로 피해를 입은 건물 사진에 '카트리나', '재해' 등의 단어를 연결하는 것과 같다.

이렇게 부여된 태그들에 가중치를 부여해서 위의 Rojo와 같이 정보를 체계화해서 보여줄 수 있다.

최근 오픈한 싸이월드 미니링 서비스에서도 폭소노미가 사용되고 있고, 팀플에서도 폭소노미와 Ajax를 연동한 서비스가 오픈되었다.


(팀플에 사용된 Folksonomy)


물론 태깅이 사용되지 않고 팀플 참여도로 가중치를 부여했지만 폭소노미의 본래 의미에서 크게 벗어나지는 않는다고 생각된다.

아마 앞으로는 정보를 표시할 때 사용자와 상호작용해서 정보의 중요성에 우선순위를 부여하는 폭소노미 방식이 폭넓게 사용될 것 같다. 이런 변화 하나하나가 Web2.0으로 가는 길목에서 우리가 새롭게 경험할 변화들이 아닐까 예상해본다.


  Comments,     Trackbacks
<img src="http://blogimgs.naver.com/nblog/ico_scrap01.gif" class="i_scrap" width="50" height="15" alt="본문스크랩" /> 폭소노미
 

새로운 웹 기술의 대표적인 상징 '폭소노미(Folksonomy)'에 대한 관심이

점점 뜨거워지고 있다. 폭소노미란 웹페이지에 올라와 있는 정보나 관련

주제를 고전적인 분류학(taxonomy) 기반인 '디렉토리'로 나누는 것이 아니라

'꼬리표'(Tags. 또는 키워드)에 따라 구분하는 새로운 분류 체계를 말한다.

 

예컨대 '청계천'이란 꼬리표가 붙은 정보는 '청계천'이란 본문 검색어와는 별개로

관련 정보가 꼬리표 아래에 실시간으로 일목요연하게 모이는 구조다.

꼬리표는 사람들이 직접 만들 수도 있고, 특정 알고리즘이나 인공지능 엔진이

자동으로 생성할 수도 있다. 폭소노미란 합성어 역시 한글로 풀어쓰면

'사람들에 의한 분류법'(Folk+order+nomos)이란 뜻이다.

꼬리표가 붙으면 웹이 어떻게 달라질까.

전통적인 디렉토리 분류는 주어진 틀에 맞춰져 있기 때문에 과거에 누적된

자료를 재활용하기 쉽지 않다. 전문가들은 자료 검색을 '검색어'에만 의존하는

원초적인 방식에서 벗어나 꼬리표로 재구성되는 과정이 필요하다고 지적한다.

 

이 때문에 꼬리표는 웹 2.0이 추구하는 '네트워크 지향' 웹 형성에

가장 기본적인 역할을 수행하게 된다.

 

이하 중략...

 

원문 기사 : [서명덕의 IT리뷰]"폭소노미" 네티즌 큰 관심- 세계일보

 

 

IT 전문 기자 서명덕 기자가 쓴 기사를 아침에 본 후.

 

뒤늦게 Amsterdam에서 진행된 Playing FLICKR 행사에 대해서 알게 되었다.

참가자들이 자신을 몇 개의 메타데이터로 소개한다는 아이디어. 

 

사용자 삽입 이미지

 

더 많은 이미지는 여기로 -> Playing FLICKR 

WEB 2.0 에 대한 가장 최신 자료는 여기로 ->What is Web 2.0 

 

진리는 간단하다. 꼬리표가 되었든 WEB 2.O이 되었든 무엇이 되었든 사용자의

필요에 의해(서만) 기술 혹은 네트웍은 새로이 개발되거나 구축된(되어야 한)다.

 

WEB으로 인해 커뮤니케이션의 방식이 Person to Person에서 Person to Machine.

이제 Machine to Machine(Software to Software)으로 진화되어 왔다는 사실.

이제는 그 기술과 네트웍에 사람이 생명력을 불어 넣기 시작한다는 사실.

 

폭소노미의 뜻이 '사람들에 의한 분류법'(Folk+order+nomos)이라 하지만.

이건 사람이 쌓는 '노가다'와는 180도 다른 문제의식 이다.

 

그런 의미에서 같은 링크 중심의 사고 임에도 불구하고

한때 일던 Social Network 붐 때보다는 비교할 수 없을 만큼

실용적이기에 혁신적인 변화를 가져올 수 있지 않나 생각한다.

 

WEB이 혁명적(민주적)일 수 있는 단 한가지 이유는

기술 종속적이면서도 가장 개방적인 커뮤니케이션 방식이기 때문이다.

 

바로 가장 개방적이기 때문에 

더 나은. 더 많은 커뮤니케이션을 하고 싶다는 욕망을 불러 일으키며

그 욕망은 스스로 거대한 생명력을 갖고 기술의 진화를 이끈다.

 

 

  Comments,     Trackbacks
[IDC 마켓뷰]주요 유럽 국가의 RFID 도입 현황

 

[IDC 마켓뷰]주요 유럽 국가의 RFID 도입 현황
IDC는 지난 2005년 4월 한달 동안 프랑스, 독일, 이탈리아, 영국, 스페인 등 서유럽 주요 5개국의 주요 기업들을 대상으로 IT 도입 계획 등에 대해 조사를 실시하였다. 영국, 프랑스 독일은 각각 250개 기업, 이탈리아 스페인은 각각 200개 기업이 참여, 총 1,150개 기업이 조사에 참여하였다. 본 보고서는 조사에 참여한 업체 중 제조, 유통(도/소매), 운송 및 물류업에서 종업원 20명 이상의 기업들이 RFID에 대해 응답한 내용을 분석한 것이다.

 

 

사용자 삽입 이미지
Introduction
IDC는 지난 2005년 4월 한달 동안 프랑스, 독일, 이탈리아, 영국, 스페인 등 서유럽 주요 5개국의 주요 기업들을 대상으로 IT 도입 계획 등에 대해 조사를 실시하였다. 영국, 프랑스 독일은 각각 250개 기업, 이탈리아 스페인은 각각 200개 기업이 참여, 총 1,150개 기업이 조사에 참여하였다.

본 보고서는 조사에 참여한 업체 중 제조, 유통(도/소매), 운송 및 물류업에서 종업원 20명 이상의 기업들이 RFID에 대해 응답한 내용을 분석한 것이다.

 

 

 

 


Key Findings

RFID 도입 계획


서유럽 주요 국가들의 RFID 도입 현황을 살펴보면, 2005년에 파일럿(Pilot) 혹은 파일럿 계획을 갖고 있는 기업은 12.4%이며, RFID를 도입할(Implementation) 계획을 갖고 있거나 도입 중인 기업은 5.1%에 이르는 것으로 나타났다.


산업별로는 운송 및 물류 업종에서 RFID 도입에 가장 큰 관심을 보였으며 특히, TNT물류, UPS 등과 같은 물류 서비스 업체들이 RFID 기술에 관심이 높았다. 하지만 비용 문제 등은 RFID 확산에 장애 요인으로 작용하고 있으며, 몇몇 대기업들은 이미 바코드 부문에 투자했기 때문에 RFID에 대한 투자를 꺼리고 있다. 실제 RFID 도입 시도는 공공 수송, 기차, 항공 등에서 이뤄지고 있다.


프로세스 제조(원료 가공 제조)업 중에서 제약(약품에 테그를 붙이는 시도가 이미 진행 중이다)과 음식, 음료 등 이력추적관리가(트레이서빌리티, Traceability) 필요한 산업에 RFID가 제격이며, 그것은 밸류체인에서 효율성을 증진할 수 있는 방법이기도 하다. 하지만 냉동 저장고는 RFID 테그에 위협 요소가 될 수도 있다.


한편, 파일럿 테스트 이후, 도입을 하지 않기로 한 기업은 0.8%에 이르렀다.


RFID 도입 계획

사용자 삽입 이미지


N=286


산업별 RFID 도입 계획

사용자 삽입 이미지


N=286

 

RFID를 위한 투자 분야


RFID는 테그와 리더기만 있으면 되는 게 아니다. RFID는 다양한 분야의 IT 벤더들에게 새로운 기회를 제공할 것이다. 응답 기업의 50% 이상이 RFID 도입시 IT 서비스, 서버, RFID를 위한 필수 애플리케이션에 투자하게 될 것이라고 응답하였다.


IT 서비스와 RFID를 위한 필수 애플리케이션에 투자할 것이라는 응답은 제조업에서 많았으며, 운송 및 물류, 유통업에서는 단기적으로 서버와 스토리지에 더 많이 투자하게 될 것이라고 밝혔다.

사용자 삽입 이미지


N=44, Companies piloting, implementing or planning RFID adoption.


RFID 도입 효과


RFID를 도입하거나 계획중인 하고 있는 기업들은 효율적인 재고 및 상품 관리를 가장 핵심적인 효과로 꼽고 있으며, 그 다음으로는 인바운드 로지스틱스(Inbound Logistics) 관리, 물류센터 효율성 증대 등도 핵심 효과로 인식되고 있다. 한편 유통의 70%가 넘는 기업들은 분실 방지를 주요 효과로 여기고 있다.


한편, RFID가 타임투마켓에 기여할 것이라고 생각하고 있는 기업은 28.1%에 불과한 것으로 나타났다.

사용자 삽입 이미지


N=47, Companies piloting, implementing or planning RFID adoption

 

RFID 도입의 장애물


RFID 도입의 장애물로 조사 대상 기업의 1/3이 ROI을 꼽고 있다. RFID를 도입한 회사들 사이에서도 도입 결과에 대해 엇갈린 반응을 보이고 있다. 어떤 회사는 단기간 내에 투자 회수를 기대하기 어렵하고 하고 있는 반면, 어떤 회사는 테스트 자체가 이미 이미 비용 절감에 도움이 되었다고 한다. RFID 도입에 따른 비용과 이익에 대한 불확실성은 RFID 도입에 지속적으로 장애물로 작용할 것이다


한편 RFID 도입시 장애물로 기타로 응답한 기업이 많은데, 이들은 주로 보안, 표준화, 비용에 대한 것이다.

사용자 삽입 이미지


N=231, Companies not planning RFID adoption


Essential Guidance


RFID 시장은 초기 시장 형성기이나 제조, 유통, 물류업에 있는 기업의 17.6%가 RFID를 파일럿 혹은 도입 중(계획)인 것으로 나타났다. 이러한 현상은 비단 분석 대상 업종에만 국한된 것이 아니라 일부 다른 산업에서도 나타나고 있다.

■ RFID는 테그와 리더기만 있으면 되는 게 아니다. 따라서 관련 서비스 및 RFID 필수 애플리케이션 등에 대한 도입도 증가할 것이고 스토리지 및 서버에 대한 수요가 증가할 것이다 따라서 RFID는 이들 시장의 성장에 기여할 것이다.


■ 벤더들은 RFID 도입의 핵심 효과로서 재고 및 상품 관리, 물류의 효율성이 증대된다는 것을 강조해야 할 것이다. 타임 투 마켓(Time to market)은 RFID가 가져 다 줄 수 있는 핵심 효과는 아니다.


■ 벤더들은 확실한 ROI와 성공 모델을 제시해야 할 것이다. 법률적인 문제나 표준화 같은 외부적인 장애 요인들은 차츰 개선되고 있다. RIO가 기업들의 핵심 고민임을 잊지 말아야 할 것이다.


* 참고자료: Status of RFID in Western European Verticals (IDC Doc #M09M / Dec 2005)

 

작성자 : 이경희(klee@idc.com) / 책임연구원, 엔터프라이즈 그룹 / ㈜한국IDC

작성일 : 2006.02.17

 

 

사용자 삽입 이미지

 

사용자 삽입 이미지

 

 

출   처 :http://research.inews24.com/research/research_view.php?seq_no=241

  Comments,     Trackbacks
편리한 세상 열어주는 꼬리표, RFID

편리한 세상 열어주는 꼬리표, RFID

 

무엇보다도 RFID는 다른 어떤 정보 처리 방식보다 쉽고 편리하게 사용할 수 있으며 CDMA 등 이동통신 기술과 결합해 정보를 전송해 활용하는 것이 가능해 유비키터스 네트워킹의 주역으로 손꼽히고 있다. RFID란 무엇이며 과연 어떤 용도로 활용할 수 있는가? 우리의 생활은 어떻게 편리해질 수 있는가?

 

서울의 한 대형 할인점. 선물로 보낼 굴비 세트를 구입하기 위해 쇼핑을 나선 K씨. 수산물 코너에 들러 밀폐 포장된 굴비 세트를 살펴보는 중이다. 요즘 굴비는 가짜가 많다는데, 이것도 혹시 중국산 아닐까? 이런 저런 의심이 들어 살펴보지만, 설령 진짜가 아니라 하더라도 수산물 전문가도 아닌 K씨가 구분할 방법은 없는 일. 그러나 이제는 더 고민할 필요가 없어졌다.

K씨는 가지고 있던 휴대전화를 꺼내 밀폐 포장된 굴비 세트에 붙어 있는 전자 태그를 읽었다. 전자 태그를 읽은 후 휴대전화 화면을 살펴보니, 굴비 세트가 언제, 어디에서 생산되었으며 어떤 유통 경로를 거쳐 이 할인점에 납품되었는지 그 과정이 간단하게 나와 있다. 진품 확인 링크를 누르니 생산자 이름과 함께 진품 여부가 나타나고, 자세한 연락처를 확인하라 수 있었다. K시는 편안한 마음으로 굴비세트를 들고 할인점을 나섰다.

 

 

사용자 삽입 이미지

 

RFID와 이동통신 기술이 결합해 가능한 그리 멀지 않은 미래의 쇼핑 이야기다. RFID는 Radio Frequency IDentification의 줄임 말로 언론 등 미디어에서는 RFID라는 용어와 함께 우리 말로 무선 전자 인증, 무선 주파수 인식, 무선 주파수 식별 혹은 전자 태그(Tag)라는 용어로 부르고 있는 무선 인식 기술이다. 사실 따지고 보면 그 말이 그 말이기는 한데 어쨌든 이런 저런 용어가 함께 사용되니 혼란스러운 것은 사실. 그래서 한국정보통신기술협회에서는 이를 '전파 식별'이라는 용어로 통일할 것을 제안하고 있는 상황이다.

RFID를 쉽게 설명하자면 이렇다. 제품이나 사물에 다양한 형태의 꼬리표(태그)를 붙이고 역시 다양한 형태의 무선 리더기를 이용해 꼬리표에 붙어 있는 정보를 읽어내는 기술이다. 정보를 읽어내는 과정에서 무선 주파수를 사용하고, 비접촉식, 즉 태그에 리더기를 가져다 붙이지 않고도 정보를 읽어낼 수 있다는 것이 큰 장점이다.

더 쉽게 설명하면 RFID는 기존 바코드를 크게 확장한 개념이라고 생각하면 된다. 이 말은 앞으로 바코드는 모두 RFID로 교체될 전망이라는 말과 같은 뜻이다. 바코드처럼 해당 제품의 정보를 담고 있기는 하지만, 기록되는 정보의 양, 이를 읽어내는 방식, 활용하는 방식이 크게 확장되는 셈이다. 기본적으로 RFID는 무선 방식이며 비접촉식이므로 한 번에 여러 개의 상품 정보를 동시에 읽을 수 있다는 것이 큰 장점. 바코드가 시간과 공간의 제한을 받는다면 RFID는 시공간의 제한 없이 수많은 정보를 동시에 처리할 수 있다는 뜻이다.

 

 

사용자 삽입 이미지

 

단순히 예를 들어 보자. 대형 할인 마트에서 가장 짜증나는 일은 물건을 사고 계산하기 위해 한참을 기다려야 한다는 것이다. 모든 상품을 일일이 하나씩 바코드 리더기에 대고 인식해야 하기 때문에 시간이 많이 걸릴 수 밖에 없다. 당연한 기다림이라고? 지금까지는 그래왔다. 그러나 모든 상품에 RFID 태그가 붙게 되면 고객은 카트를 밀고 계산대 앞을 지나가기만 하면 된다. RFID 센서는 한 번에 모든 제품의 정보를 읽고, 가격을 계산해준다.

 

 

사용자 삽입 이미지

 

구분
RFID바코드
인식 방법무선유선(광학 스캐너)
기록 방법읽기 / 쓰기읽기 전용
정보 량수천 단어수십 단어
인식 거리최대 수십 미터
(전파규제에 따라 다름)
최대 수십 cm
인식 수량동시에 수백 - 수천 개1회에 1개
(참고 : 정보통신기술협회 용어사전)

 

그러나 단순히 바코드를 확장한 것이 RFID의 전부일까? 요즘 언론들이 끊임없이 RFID에 대해 보도하고, 정부에서도 IT839 정책의 신성장사업동력프로젝트로 RFID를 선정하는 등 RFID가 유비쿼터스 네트워크의 핵심 기술로 인정 받는 이유는 무엇일까? 무엇보다도 RFID의 정보 처리 방식이 다른 어떤 정보 처리 방식보다 편리하다는 것이지만, 이 외에도 자체적으로 정보를 처리하는 것과 함께 CDMA 등 이동통신 기술과 결합해 정보를 전송해 활용하는 것이 가능하기 때문이다. 이런 까닭에 바코드와 달리 RFID는 그 활용 방안이 무궁무진할 수 밖에 없다.

 

 

사용자 삽입 이미지

 

실제로 SK Telecom은 한국인삼공사와 함께 RFID를 활용한 정관장 제품 진품 확인 서비스를 시범적으로 제공하고 있다(특집 2 참조). RFID로 제품의 정보를 읽은 후 이를 무선 인터넷으로 전송해 정관장 홈페이지에서 진품 여부를 확인하는 것이다. 앞에서 굴비의 진품 확인 역시 이와 같은 방식으로 진행될 것이다. 여기서 사례를 들은 것처럼 조만간 RFID 태그를 읽을 수 있는 휴대 전화가 등장하는 등, 소비자들이 직접 RFID 리더기를 들고 다닐 수 있는 시대가 열릴 것이므로 RFID의 활용 분야는 더 넓어질 수 밖에 없다.

RFID가 크게 변화를 가져올 부문은 아무래도 바코드가 가장 많이 사용되고 있는 유통, 물류 분야일 것이다. 이미 질레트, 갭, 프라다 등 세계 유명 업체들은 RFID를 활용하고 있으며 월마트와 같은 대형 할인점들도 조만간 이를 활용할 계획이다. 제품에 부착된 RFID 태그는 제품 생산부터 유통 과정에까지 이르는 모든 정보를 담고 있어서 유통, 판매 과정에서 관리 비용을 획기적으로 줄여줄 전망이다. 일일이 바코드로 읽어야 하는 제품 정보를 트럭이 단지 지정한 게이트를 지나는 순간에 처리할 수 있으니 시간과 비용을 모두 절약할 수 있는 셈이다.

유통과정이 중요한 농수산물에 있어 RFID의 활용성은 무시할 수 없다. 생산자와 생산 시기, 유통 경로 등을 모두 저장하고 또 소비자들이 일일이 이를 확인할 수 있어 믿을 수 있는 유통 과정을 만들어 내기 때문이다.

또한 굳이 병원에 가지 않고도 언제 어디서나 건강을 체크할 수 있는 u 헬스 기능의 핵심 기술로도 채택될 것이다. 거동이 불편한 노인이나 중환자 등에게 부착된 RFID 태그로 병원에서는 환자의 상태를 실시간으로 확인할 수 있게 된다. 최근 모 병원에서 일어난 수술 환자가 뒤바뀐 의료 사고가 사회적으로 큰 논란이 되었는데 환자에게 RFID 태그를 부착하면 이런 문제를 예방할 수 있으며 기타 병원 업무 역시 손쉽게 처리할 수 있다.

교통 분야 역시 획기적인 개선이 일어날 전망이다. 이미 서울시는 RFID를 이용한 승용차 요일제 사업을 추진할 준비를 완료했다. RFID 태그를 내장한 요일제 스티커를 배포하고, 이를 이용해 승용차들이 요일제를 지키는지 여부를 확인할 수 있어서 요일제 참여 차량에 대해 다양한 배려를 약속할 수 있게 되었다. 또한 향후에는 RFID가 내장된 차량들의 흐름을 읽어 교통량을 측정할 수 있으므로 실시간 교통량 파악에도 큰 도움이 된다.

 

 

사용자 삽입 이미지

 

이 외에도 RFID는 꽤 재미있고 편리한 용도로 활용할 수 있다. SK Telecom이 추진하고 있는 택시안심귀가 서비스가 그 대표적인 예. 이 서비스는 택시 안에 부착된 기사의 면허증 등에 RFID 태그를 부착하고, 택시에 승차한 고객이 휴대전화로 이를 읽어 가족이나 친구에게 보내는 것인데 이 때 기사나 택시에 관한 정보는 물론 택시의 이동 경로 등도 SMS로 전송할 수 있게 된다.

또한 휴대전화끼리 명함을 전달할 수 있는 모바일 명함 기능, 도서, 음반, DVD 등에 부착된 태그를 읽어 샘플을 전송할 수 있는 기능, 인쇄물에 내장된 내장된 태그를 읽었을 때 음성으로 읽어주거나 추가 정보를 전송하는 기능, 박물관이나 관광지에서 태그를 읽었을 때 역사 정보나 관광 정보를 알려주는 기능 등이 RFID가 조만간 적용될 생활 서비스다.

상상만 해도 즐거운 일이 아닐 수 없다. 휴대전화로 태그를 읽어 필요한 정보도 얻고 진품여부도 확인하고, 쇼핑도 더 편리해지고, 거기다가 안전하기까지 하다니… 상상만 하면 편리해지는 세상, RFID가 유비쿼터스 네트워킹의 주역으로 주목 받는 건, 바로 이런 이유 때문일 것이다.

 

 

작성자 : 스카이벤처

작성일 : 2006.02.08 

원   문 :http://www.bize-station.com/

 

사용자 삽입 이미지

 

출   처 :http://www.skyventure.co.kr/innovation2005/mob_report/view.asp?Num=10722&NSLT=Y

  Comments,     Trackbacks
[현장탐방] 한국인삼공사 RFID 시범 서비스

[현장탐방] 한국인삼공사 RFID 시범 서비스

 

한국인삼공사가 판매하는 홍삼 관련 제품인 정관장 진품은 효능이 뛰어나고 귀한 만큼 가격이 비싸 중국을 비롯한 동남아에서 겉모양만 보고서는 도저히 구분할 수 없을 정도의 가짜 상품이 많아 그간 소비자들의 피해가 적지 않았다. 이러한 문제를 해결하기 위해 RFID기술과 CDMA 이동통신 기술이 해결사로 등장해 눈길을 끌고 있다.

 

한국의 대표적인 상품 인삼. 그 효능이 예로부터 입증되어 중국을 비롯한 외국에서도 널리 사랑 받는 제품. 그만큼 귀하고 소중한 상품이다 보니 구하기 쉽지 않고 가격 역시 만만치 않다. 이런 상품일수록 가짜가 만들어지는 것은 어찌 보면 필연적인 일이다. 실제로 고려 시대에도 가짜 인삼이 돌아다녔을 정도라 하니, 인삼의 역사만큼 가짜의 역사도 오래된 듯싶다.

유명한 상품이 있고 이 상품을 흉내 낸 가짜가 등장하고, 가짜를 진품과 구분하는 방법이 등장하고, 또 다시 업그레이드 된 가짜가 등장하고, 다시 이를 해결해 진품을 보호하는 기술이 등장하고, 이런 악순환이 계속 되면서 가짜와 진짜는 점점 더 구분하기 어려워졌다. 예전에는 모양이나 맛, 냄새로 구분할 수 있었지만, 이제는 전문가가 봐도 구별하기 어려울 정도로 진짜 같은 가짜가 많은 세상이 되었다.

 

 

사용자 삽입 이미지

 

한국인삼공사가 판매하는 홍삼 관련 제품인 정관장 진품은 효능이 뛰어나고 귀한 만큼 가격이 비싸 중국을 비롯한 동남아에서 겉모양만 보고서는 도저히 구분할 수 없을 정도의 가짜 상품이 많아 그간 소비자들의 피해가 적지 않았다고 한다.

실제로 정관장 진품의 경우 상품에 따라 다르지만 고급 제품인 경우 120만원 대에 판매되는데, 가짜는 이보다 30% 가량 싼 70-80만원 대에 거래된다고 한다. 한국인삼공사 직원 조차도 육안으로 구분하기 어려울 정도로 정교하게 복제된 케이스를 사용하기 때문에 소비자들은 당연히 진품 여부를 확인하기가 어려운 상황이다.

이러한 문제를 해결하기 위해 드디어 최첨단 정보통신 기술이 동원되었다. 최근 각광받고 있는 RFID 기술과 CDMA 이동통신 기술이 가짜 홍삼 제품을 찾아내기 위한 해결사로 등장한 것이다.

 

 

사용자 삽입 이미지

 

지난 해 12월, SK Telecom은 한국인삼공사와 함께 한국인삼공사 을지로 본점에서 RFID와 CDMA 기술을 이용한 정관장 제품 진품 확인 서비스를 시작했다. 이제 막 서비스가 도입되기 시작한 RFID 분야에서는 시금석과 같은 서비스인 셈. 실제로 을지로입구와 3가 사이, 중앙씨네마 사거리에 면해 있는 한국인삼공사 을지로 본점에는 RFID 시범 서비스를 탐방하러 오는 사람들이 꽤 있다고 한다.

실제 프로세스는 이렇다. 한국인삼공사 매장에서 판매되는 천삼 20지 600g, 양삼 20지 600g, 양삼 30지 600g, 절삼 600g 등 총 4가지 정관장 제품에 RFID 태그가 붙어 있다. 현재는 시범 테스트 기간이라 고무자석 형태의 RFID 태그를 금속으로 만든 정관장 케이스에 붙여 둔 상태이지만, 시범 서비스가 끝나면 조만간 케이스에 인쇄된 바코드를 대신해 RFID 태그가 붙게 될 계획이다.

이 태그에는 정관장 제품에 대한 정보가 들어 있고 RFID 리더기로 이 태그를 읽게 되면 자동적으로 무선 인터넷을 통해 정관장 홈페이지에 접속하게 된다. 리더기에 CDMA 통신 기능이 들어 있다는 뜻이다. 테스트 기간 중에 사용되는 리더기는 디지털 캠코더와 같은 모양인데, 캠코더를 들고 촬영하듯 RFID 태그를 읽으면 리더기 액정에 CDMA 통신 중이라는 메시지와 함께 정관장 홈페이지로 접속하는 익스플로러 화면이 나타나게 된다.

 

사용자 삽입 이미지
        
사용자 삽입 이미지

 

 

 

 

사용자 삽입 이미지

 

리더기는 태그를 통해 들어온 정보를 바탕으로 무선 인터넷을 이용해 정관장 홈페이지의 내용을 액정을 통해 표시한다. 만일 태그가 잘못되었다면 홈페이지에 접속이 되지 않을 테고, 설령 접속이 되었다 하더라도 고유 번호 등이 인증되지 않을 테니 가짜라는 것을 쉽게 확인하게 된다.

정관장 홈페이지에서는 입력된 태그의 정보를 통해 제품의 진품 여부를 확인하게 되고 이와 더불어 상품에 대한 상세한 정보를 제공하게 된다. 홈페이지에 접속하면 '진품'이라는 표시가 화면에 나타나며 화면을 스크롤 해 아래쪽으로 이동하면 홍삼 제품의 규격, 특징, 복용법, 품질관리 책임자 등에 대한 상세정보 등 다양한 제품 정보가 나타난다. 고객들은 리더기의 액정을 통해 관련 정보를 보면서 안심하고 정관장 제품을 구입할 수 있게 되는 것이다.

 

사용자 삽입 이미지
    
사용자 삽입 이미지

 

 

사용자 삽입 이미지

 

무엇보다도 무선 이동통신 기술과 결합된 탓에 시간과 장소에 구애 받지 않고 진품 여부를 확인할 수 있는 것이 이 서비스의 큰 장점이다. 실제로 정관장 제품의 경우 국내보다는 해외에서 가짜가 유통되는 경우가 더 많다. 국내에서는 한국인삼공사 매장을 통해 구입한다거나 아니면 직접 전화를 거는 방법으로 진품을 확인할 수 있지만 통신 환경이 만만치 않은 외국에서는 진품을 확인하기가 쉽지 않은 일. 이럴 때 CDMA 로밍 서비스와 무선 인터넷 기술을 이용하면 국내외 어디서든 진품 여부를 확인할 수 있다.

RFID와 CDMA 기술을 이용한 진품 확인 시범 서비스는 일단 2006년 3월초까지 계속될 계획이다. 아직은 시범 서비스 기간이므로 몇 가지 단점들이 지적되고 있다. 대표적인 예로 금속 캔에 붙어 있는 RFID 태그가 현재는 고무 자석 형태로 되어 있는데, 조만간 금속 캔에 있는 바코드를 대체하게 된다. 바코드가 가지고 있는 기본 기능 외에 진품 확인 서비스까지 추가로 제공하는 셈이다. 게다가 바코드가 가지고 있는 단점인 인식 거리가 짧고, 정보가 제한되어 있으며 유선이라 거리에 한계가 있다는 점이 RFID와 CDMA를 이용하게 되면 모두 해결될 전망이다.

또한 시범 기간 중에 보급된 리더기는 다소 무겁다는 단점이 있다. 더욱이 이런 형태의 전용 리더기는 매장에서나 적합하지 고객이 들고 다닐 수는 없는 일. 단말기 제조사와 이동통신사에 따르면 조만간 RFID 리더 기능을 갖춘 휴대전화가 출시된다 하니, 고객들이 자신의 휴대전화로 정관장에 붙어 있는 태그를 읽어 진품 여부를 확인하고 추가 정보를 살펴볼 수 있는 시기가 곧 다가올 전망이다.

 

 

작성자 : 스카이벤처   

작성일 : 2006.02.08

출   처 :http://www.bize-station.com/

 

사용자 삽입 이미지

 

원    문 :http://www.skyventure.co.kr/innovation2005/mob_report/view.asp?Num=10723&NSLT=Y

  Comments,     Trackbacks
[웹2.0] 리치 유저의 경험들
[웹2.0] 리치 유저의 경험들
 

연재순서

1회.
[웹2.0] 플랫폼으로서의 웹

2회.[웹2.0] 집단 지능이 결집되다

3회.[웹2.0] 데이터는 차세대의「인텔 인사이드」

4회.[웹2.0] 소프트웨어 발표 주기의 종말

5회.[웹2.0] 가벼운(Lightweight) 프로그래밍 모델

6회.[웹2.0] 단일 디바이스를 넘는 소프트웨어

7회.[웹2.0] 리치 유저의 경험들

 

페이 위의 비올라(Viola) 브라우저는 이미 1992년에는 웹을 이용하고 애플릿이나 그 외의 동적인 콘텐츠를 브라우저에 표시하고 있었다. 1995년에는 이런 애플릿을 전달하는 수단으로서 자바가 등장했다.

게다가 클라이언트의 프로그래밍과 리치한 유저 경험을 실현하기 위한 가벼운 프로그래밍을 위해 우선은 자바 스크립트, 이어 DHTML가 등장했다. 매크로미디어는 몇년 전 플래시가 멀티미디어 콘텐츠 뿐 아니라, GUI 스타일의 애플리케이션 경험도 제공할 수 있는 것을 어필하기 위해서, ‘리치 인터넷 애플리케이션’이라는 말을 만들어 냈다(이 말은 오픈 소스의 플래시 클라이언트의 개발원이며, 매크로미디어와 경쟁하는 라스즐로 시스템(Laszlo Systems)도 이용하고 있다).

그러나 웹에서 전면적인 애플리케이션을 제공할 수 있다고 하는 생각이 확산되기까지는 구글의 지메일과 구글 맵스의 등장이 큰 계기가 됐다. 이 두 가지 서비스는 웹 기반의 애플리케이션이지만 리치한 유저 인터페이스와 PC에 필적하는 양방향성을 갖추고 있다. 웹 디자인 회사인 어댑티브 패스(Adaptive Path)의 제시 제임스 가레트(Jesse James Garrett)는 그의 에세이에서 이런 애플리케이션을 개발하기 위해서 구글이 이용한 기술을 ‘AJAX’라고 명명했다.

가레트는 “Ajax는 하나의 기술이 아니고, 복수가 뛰어난 기술을 새로운 강력한 방법으로 조합한 것”이라고 표현했다. Ajax에는 다음과 같은 것이 포함된다.

• XHTML와 CSS를 이용한 표준에 준거한 프리젠테이션
• DOM(Document Object Model)을 이용한 동적인 표시와 인터액션
• XML와 XSLT를 이용한 데이터 교환과 데이터 조작
• XMLHttpRequest를 이용한 비동기의 데이터 검색
• 그 모든 것을 통합하는 자바 스크립트

AJAX는 수많은 웹 2.0 애플리케이션, 예를 들어 플릭커(Flickr, 현재는 야후 그룹의 일부), 37 시그널의 베이스캠프와 백팩, 그리고 지메일, Orkut라고 하는 구글 애플리케이션에서도 중요한 역할을 한다. 지금 유저 인터페이스의 분야에서는 전대미문의 혁신이 시작되고 있다. 웹 개발자는 마침내 로컬의 PC 애플리케이션과 동등의 기능을 갖춘 리치한 웹 애플리케이션을 개발할 수 있게 될 것이다.

흥미로운 것은 현재 개발이 진행되고 있는 기능의 상당수는 몇 년 전부터 아이디어로서는 존재했다는 점이다. 지금 간신히 실현되고 있는 이런 기능을 MS와 넷스케이프는 1990년대 말 벌써 구상하고 있었다. 그러나 양사는 표준을 둘러싸고 대립했기 때문에, 브라우저를 넘은 애플리케이션을 개발하는 것은 어려웠다. MS가 브라우저 전쟁에 결정적인 승리를 거두어 브라우저의 사실상 표준이 됐고, 이런 종류의 애플리케이션이 등장하는 여지가 생겼다.

파이어폭스의 등장으로 브라우저 시장에 다시 경쟁이 시작됐지만, 적어도 현재는 1990년대에 진보의 족쇄가 된 것 같은 웹 표준을 둘러싼 파괴적인 경쟁은 일어나지 않고 있다.

앞으로도 많은 웹 애플리케이션이 등장할 것이다. 그것은 아무도 본 적이 없는 애플리케이션으로, PC 애플리케이션에 필적하는 리치한 기능을 웹에서 실현할 것이다.

전자 메일의 분야에서는 벌써 지메일이 흥미로운 혁신을 가져오고 있다. 지메일은 웹의 강점인 어디에서라도 액세스 할 수 있고 데이터베이스와의 제휴, 검색 기능 등이 가능한 유저 인터페이스를 조합하는 것으로, PC와 동등의 유용성을 실현하고 있다. 한편 PC 기반의 메일 클라이언트는 IM나 존재 기능을 추가해, 다른 방면에서의 사용의 편리를 추구하고 있다. 이메일, IM, 그리고 휴대 전화의 이점을 갖추어 VoIP를 이용하고, 웹 애플리케이션의 풍부한 기능에 한층 더 음성 기능을 탑재한, 통합 커뮤니케이션 클라이언트는 언제 등장하는 것일까. 개발 경쟁은 벌써 시작됐다.

웹 2.0은 주소장을 재구성하고 있다. 웹 2.0 스타일의 주소장은 PC 또는 전화에 보존되고 있는 로컬의 주소장을 유저가 의식적으로 시스템에 기억시킨 연락처 정보의 단순한 캐시로서 취급한다. 이것에 대해서, 웹과 동기를 취하는 주소장, 즉 지메일 스타일의 주소장은 송수신된 모든 메시지, 모든 메일 주소, 이용된 모든 전화번호를 기억해 로컬 캐시에 대답이 발견되지 않는 경우는, 소셜 네트워킹의 수법을 사용하고 그 중에서 대체가 되는 선택사항을 찾아낸다. 거기에도 대답이 발견되지 않는 경우는 소셜 네트워크 전체를 검색한다.

웹 2.0의 워드 프로세서에는 통상의 문서 편집 기능 뿐 아니라, 위키 스타일의 협업적인 편집 기능이나, PC용 워드 프로세서와 동등의 리치한 포맷 기능도 탑재될 것이다. Writely는 이런 애플리케이션이 좋은 예이지만, 아직 광범위하게 채용되지는 않고 있다.

웹 2.0 혁명의 영향을 받는 것은 PC 애플리케이션만이 아니다. 세일즈포스닷컴(Salesforce.com)은 CRM과 같은 엔터프라이즈 규모의 애플리케이션에서도 웹을 이용하고, 소프트웨어를 서비스로서 제공할 수 있는 것을 증명하고 있다.

신규 참가 기업이 경쟁 우위를 획득하기 위해서는 웹 2.0의 가능성을 충분히 살리는 것이 열쇠가 된다. 웹 2.0 시대에는 사용자로부터 배워 참가의 아키텍처를 사용하고, 소프트웨어 인터페이스 뿐 아니라, 공유 데이터의 충실도의 면에서도 경쟁사를 능가하는 애플리케이션을 구축할 수 있는 기업이 성공을 거두게 될 것이다.

웹 2.0 기업의 핵심 역량
7개의 원칙을 검토하면서 웹 2.0의 주된 특징을 분명히 했다. 각 항에서 다룬 사례는 이런 중요한 원칙들을 보여줬지만, 반드시 모든 원칙을 맞춘 것은 아니다. 마지막으로 우리가 웹 2.0 기업의 핵심 역량이라고 생각하고 있는 것을 살펴보자.

• 패키지 소프트웨어가 아니고, 비용 효율이 높고, 확장성이 있는 서비스를 제공한다.
• 독자성으로 인해 같은 것을 만드는 것이 어려운 데이터 소스를 컨트롤 한다. 이 데이터 소스는 이용자가 증가하는 만큼, 충실하지 않으면 안된다.
• 유저를 신뢰해, 공동 개발자로서 여긴다.
• 집합지를 이용한다.
• 고객 셀프서비스를 통하고, 롱 테일을 수중에 넣는다.
• 단일 디바이스의 테두리를 넘은 소프트웨어를 제공한다.
• 경량인 유저 인터페이스, 경량인 개발 모델, 그리고 경량인 비즈니스 모델을 채용한다.

웹 2.0을 수용하는 기업이 있다면, 그 기업이 상기의 항목을 채워 있는지 어떤지를 관찰해 보면 좋을 것이다. 들어맞는 것이 많은 만큼, 그 기업은 웹 2.0 기업이라고 부르기에 어울릴 것이다. @


이 기사는 2005년 9월 30일에O'Reilly Network로 공개된 것이다.
 
 
  Comments,     Trackbacks
[웹2.0] 단일 디바이스를 넘는 소프트웨어
[웹2.0] 단일 디바이스를 넘는 소프트웨어
 
웹 2.0에 주목해야할 특징의 하나는 “PC 플랫폼으로 한정되지 않는다”고 하는 것이다. MS의 베테랑 개발자였던 데이브 스투즈(Dave Stutz)는 MS를 떠날 때에 "향후 긴 세월에 흐르면, 실용성이 높고 단일 디바이스의 테두리를 넘은 소프트웨어가 큰 이익을 가져올 것”이라고 말했다.

무엇보다 모든 웹 애플리케이션은 ‘단일 디바이스의 테두리를 넘은 소프트웨어’라고 부를 수 있다. 극히 단순한 웹 애플리케이션도 적어도 2대의 컴퓨터를 필요로 하기 때문이다. 하나는 웹 서버 역할을 하는 컴퓨터, 또 하나는 브라우저가 인스톨되는 컴퓨터다. 이미 설명한 대로 플랫폼으로서의 웹이 발전하면 복수의 컴퓨터가 제공하는 서비스를 완만하게 통합해 새로운 애플리케이션을 낳는 것이 가능하게 된다.

그러나 웹 2.0은 단지 새로운 것을 만드는 것은 아니고, 웹 플랫폼의 가능성을 최대한으로만든다는 것을 의미한다.

현재 이 원칙을 가장 잘 보여주는 것이 바로 아이튠즈다. 아이튠즈는 사용자가 휴대 단말을 사용하고, 웹의 방대한 정보로 액세스하는 것을 가능하게 했다. PC는 로컬 캐시나 컨트롤 스테이션으로서 기능한다. 웹의 정보를 휴대 단말에 전달하는 시도는 지금까지도 많이 행해져 왔지만, 아이팟과 아이튠즈의 편성은 복수의 기기로 이용되는 것을 전제로 설계된, 최초의 애플리케이션의 하나라고 할 수 있을 것이다. 티보(TiVo)도 그 좋은 예다.

아이튠즈와 티보는 그 이외의 웹 2.0이 가지는 중요한 원칙도 입증하고 있다. 예를 들어, 아이튠즈와 티보는 웹 애플리케이션은 아니지만, 둘 다 웹 플랫폼의 힘을 이용하고 인프라와 일체화하고 있다. 여기에서는 데이터 관리가 극히 중요한 역할을 한다. 또 어느 쪽이나 서비스이며, 패키지 애플리케이션은 아니다. 다만 아이튠즈는 사용자의 로컬 데이터를 관리하기 위한 패키지 애플리케이션이라고 해도 이용할 수 있다.

이 분야는 웹 2.0에서나, 새로운 플랫폼에 접속되는 기기가 증가하는 것에 따라, 큰 변화가 일어날 가능성이 높다고 생각된다. 전화나 자동차가 데이터를 받을 뿐만 아니라, 발신하게 되면 어떤 애플리케이션이 가능하게 될까. 실시간 트래픽 모니터링, 후랏슈모브(인터넷을 이용해 호소하는 집회), 시민 저널리즘 등은, 새로운 플랫폼의 가능성을 나타내는 최초의 징후에 지나지 않는다. @

사용자 삽입 이미지
 웹 2.0의 디자인 패턴
사용자 삽입 이미지
 
사용자 삽입 이미지
크리스토퍼 알렉산더는 저서 ‘패턴 랭귀지(A Pattern Language)’에서 건축에 관련되는 문제와 그 해법을 정리한 포맷을 정의했다. 알렉산더는 “각각의 패턴에는 어떤 환경하에서 반복해 일어나는 문제와 그 문제에 대한 해법의 핵이 기술되어 있다. 그렇게 해 같은 방식을 반복하는 일 없이 이 해법을 몇 번이라도 적용할 수 있다”라고 적고 있다. 이것을 웹 2.0에 적용한 것이 아래와 같은 8가지 패턴이다.

1. 롱 테일
인터넷의 과반수를 차지하고 있는 것은 소규모의 사이트다. 작은 니치가 인터넷으로 실현 가능한 애플리케이션의 대부분을 차지하고 있다. 따라서 유저 셀프서비스와 알고리즘에 의한 데이터 관리를 도입해, 웹 전체에 서비스를 제공하자.

2. 데이터는 차세대의 인텔 인사이드
데이터 지향의 애플리케이션이 증가하고 있다. 따라서 독자성이 높고, 같은 것을 만드는 것이 어려운 데이터 소스를 소유하는 것으로, 경쟁 우위를 획득하자.

3. 유저에 의한 부가가치 창조
경쟁력이 있는 인터넷 애플리케이션을 구축할 수 있을지는 기업이 제공하는 데이터에 유저가 어느 정도 데이터를 더할 수 있을까에 의해서 정해진다. 따라서 아키텍처를 소프트웨어 개발로 한정하는 것은 그만두자. 유저가 무의식 중에 또는 의식적으로 애플리케이션에 가치를 더할 수 있도록 하자.

4. 네트워크 효과를 재촉하는 초기설정
자신의 시간을 할애해서까지 기업의 애플리케이션 가치를 높여 주려는 유저는 적다. 따라서 유저가 애플리케이션을 사용하는 것에 의해서 부차적으로 유저의 데이터도 모이는 구조를 만들자.

5. 일부 권리 보유
지적 재산의 보호는 재이용을 제한해 실험적인 시도를 방해한다. 따라서 광범위하게 채용되는 것으로 메리트가 생기는 것은 이용을 제한하지 않고, 채용 장벽을 낮추자. 기존의 표준에 준거해, 제한 사항을 최소한으로 억제한 라이선스를 제공하자.

6. 영구 베타판
디바이스와 프로그램이 인터넷에 접속되고 있는 오늘날 애플리케이션은 물건이 아니라 간단히 제공되는 서비스이다. 따라서 새로운 기능은 릴리스라는 형태로 정리해 제공하는 것이 아니라, 통상의 유저 경험의 일부로서 일상적으로 제공해 나가자. 서비스를 제공할 때는 유저를 실시간 테스터라고 생각하고 신기능이 어떻게 사용되고 있는지를 관찰하자.

7. 컨트롤이 아니라 협력
웹 2.0 애플리케이션은 복수의 데이터 서비스의 협동 네트워크에 의해서 실현된다. 따라서 웹 서비스의 인터페이스를 통해 콘텐츠를 전달해, 다른 사람의 데이터 서비스를 재이용하자. 경량인 프로그래밍 모델을 채용해 시스템을 완만하게 통합할 수 있도록 하자.

8. 단일 디바이스의 테두리를 넘은 소프트웨어
인터넷 애플리케이션에 액세스할 수 있는 디바이스는 PC만이 아니다. 특정의 디바이스로 밖에 이용할 수 없는 애플리케이션은 디바이스의 테두리를 넘어 이용할 수 있는 애플리케이션보다 가치가 없다. 따라서 애플리케이션을 설계할 때는 처음부터 휴대 단말, PC, 인터넷 서버 등을 포괄한 시각을 갖고 통합적인 서비스를 제공하자.

사용자 삽입 이미지
사용자 삽입 이미지

이 기사는 2005년 9월 30일에O'Reilly Network로 공개된 것이다.
 
 
  Comments,     Trackbacks
[웹2.0] 가벼운(Lightweight) 프로그래밍 모델

[웹2.0] 가벼운(Lightweight) 프로그래밍 모델

 

연재순서

1회.
[웹2.0] 플랫폼으로서의 웹

2회.[웹2.0] 집단 지능이 결집되다

3회.[웹2.0] 데이터는 차세대의「인텔 인사이드」

4회.[웹2.0] 소프트웨어 발표 주기의 종말

5회.[웹2.0] 가벼운(Lightweight) 프로그래밍 모델

6회.[웹2.0] 단일 디바이스를 넘는 소프트웨어

7회.[웹2.0] 리치 유저의 경험들

 

 

‘웹 서비스’가 최신 기술로 각광 받을 때 대기업은 먼저 복잡한 웹 서비스 스택을 구축해, 분산 애플리케이션을 실현하기 위한 안정된 프로그래밍 환경을 제공하려고 했다.

그러나 웹이 하이퍼 텍스트(hyper text) 이론의 많은 부분을 무시하고 단순한 실용주의를 존중했기 때문에 성공한 것처럼 RSS는 그 단순함에 때문에 어쩌면 가장 광범위하게 배포된 웹 서비스가 되었다. 이에 비해 기업이 구축한 복잡한 웹 서비스 스택은 아직 한정적으로 이용되고 있다.

비슷하게 아마존의 웹 서비스도 2가지 방법으로 제공되고 있다. 하나는 SOAP(Simple Object Access Protocol)를 채용한 엄밀한 구성을 가지는 웹 서비스 스택, 또 하나는 HTTP 경유로 HTML 데이터를 제공하는 단순하고 가벼운 접근이다. 후자의 방법은 REST(Representational State Transfer)이라고 한다. 아마존과 ToysRUs등의 소매 파트너를 묶는 복잡한 B2B 연결에는 SOAP 스택이 이용되고 있다. 하지만 아마존 웹 서비스의 95%는 단순한 REST 인터페이스를 통해 이용되고 있다고 한다.

단순함을 추구하는 경향은 그 외의 ‘유기적인’ 웹 서비스에서도 보여진다. 최근 발표된 구글맵이 적절한 예다. 구글맵은 AJAX(Javascript와 XML)를 이용한 단순한 인터페이스를 채용하고 있기 때문에 해커들은 곧 바로 그것을 해독하고 데이터와 혼합해 새로운 서비스를 만들어냈다.

지도 관련의 웹 서비스는 이미 맵퀘스트(MapQuest), MS의 맵포인트(MapPoint), 그리고 ESRI등의 GIS 벤더로부터도 제공되고 있었다. 그런데 구글맵이 열광적인 인기를 누리고 있는 것은 이것이 매우 단순한 서비스이기 때문이다. 벤더가 제공하는 웹 서비스를 이용하고 새로운 시도를 하기 위해서는 그 벤더와 정식 계약을 맺어야 하는데 비해 구글맵은 유저가 데이터를 자유롭게 이용할 수 있도록 했다. 이 때문에 해커들은 구글맵의 데이터를 재이용하고, 곧바로 창조적인 시도를 실시할 수 있었다. 이 사례는, 다음과 같은 중요한 교훈을 나타내고 있다.

1. 가벼운 프로그래밍 모델을 채용해, 시스템을 완만하게 통합할 수 있도록 한다.
기업이 제공하는 복잡한 웹 서비스 스택은 시스템을 견고하게 묶도록 설계되었다. 이러한 방법이 요구되는 것도 많지만 흥미로운 애플리케이션의 상당수는 시스템을 완만하게 통합하는 것만으로도 실현될 수 있다. 2.0의 사고 방식은 전통적인 IT 사고 방식과는 완전히 다르다!

2. 조정(coordination)보다는 신디케이션(syndication)한다.
RSS나 REST 서비스와 같이 단순한 웹 서비스는 내부의 데이터와 외부의 데이터의 전달에 충실해 외부에서 데이터가 어떻게 이용될지에 대해서는 통제하지 않는다. 엔드투엔드(end-to-end)의 원칙으로서 알려진 이 아이디어는 인터넷 그 자체의 기본 원칙이기도 하다.

3. 개조(hackability)와 재조합(remixability)이 가능하도록 설계한다.
오리지널 웹, RSS, AJAX와 같은 시스템은 모두 재사용의 장벽이 극히 낮다는 공통점이 있다. 실제로 유익한 소프트웨어의 상당수는 오픈 소스이며, 그렇지 않은 경우도 지적 재산 보호를 목적으로 한 장벽은 거의 설치되지 않았다. 웹 브라우저의 ‘소스 보기’ 기능을 사용하면, 누구라도 다른 유저의 웹페이지를 카피할 수 있다. RSS는 정보 제공자가 아닌 유저가 자신이 갖고 싶은 정보를 원할 때 볼 수 있도록 고안되었다. 가장 성공한 웹 서비스는 개발자가 상상도 하지 않았던 방향으로 서비스를 용이하게 전환할 수 있는 것들이었다. ‘모든 권리의 인정(all rights reserved)’이 아닌 Creative Commons가 제안해 널리 보급된 ‘일부 권리 인정(some rights reserved)’ 문구가 이 원칙을 실천하는데 있어서의 유익한 지침이 될 것이다.

어셈블리에서의 혁신(innovation in assembly)
가벼운 비즈니스 모델에는 가벼운 프로그래밍과 가벼운 연결이 수반되기 마련이다. 웹 2.0의 사고 방식은 재상용에 있다. 예를 들어 housingmaps.com와 같은 새로운 서비스는 단지 기존의 서비스를 조합하는 것으로 실현된 것이다. Housingmaps.com는 아직 비즈니스 모델을 가지고 있지 않지만, 구글 애드센스(또는 아마존 광고 제휴)처럼 이 서비스에 맞는 수익 모델을 갖게 될 것이다.

이러한 사례는 웹 2.0의 또 하나의 중요한 원칙인 ‘어셈블리에서의 혁신(innovation in assembly)’를 이해하는데 도움이 될 것이다. 유용한 컴포넌트가 대량으로 존재할 때는 이러한 컴포넌트를 새로운 방법, 또는 효과적인 방법으로 조합하는 것으로 새로운 가치를 창출할 수 있다. PC혁명은 하드웨어 결합의 혁신을 가능하게 했다. 델은 조립 사업으로 제품 개발에 혁신이 필요한 비즈니스 모델을 가지는 기업들을 물리쳤다. 마찬가지로 웹 2.0은 타사의 서비스를 이용해 그것을 통합하는 것으로 경쟁자를 물리칠 기회를 기업에 제공한다.

사용자 삽입 이미지
웹 2.0 투자 이론
사용자 삽입 이미지
 
사용자 삽입 이미지
벤처 자본가인 폴 케드로스키(Kedrosky)는 “중요한 것은 자신이 세상의 공통 인식에 위화감을 가지고 있는 부분에서 실행 가능한 투자를 찾아내는 것이다”라고 썼다. 웹 2.0을 실천하고 있는 기업이 다양한 측면에서 세상의 공통 인식에 반한 전략을 취하고 있다는 것은 흥미로운 일이다. 예를 들어, 누구나가 데이터 보호를 중요시 할 때 플릭커(Flickr)와 냅스터(Napster)는 데이터를 공개하는 것을 선택했다. 이러한 사이트는 단지 기존의 개념에 반대하고 있는 것은 아니다(예를 들어, 버블적인 비즈니스 모델의 비판 등). 세상의 공통 인식과 스스로의 인식의 어긋나는 것에서부터 새로운 것을 만들어 낸 것이다. 그것은 플릭커의 경우는 커뮤니티이며, 냅스터의 경우는 방대한 음악 콜렉션이다.

이를 바라보는 또 방법은 성공한 기업들은 거액의 투자가 필요한 것들을 포기했을 뿐만 아니라 고가의 가치 있는 것들을 무료로 가질 수 있는 것에 비판적이었다는 사실이다. 예를 들어 위키피디어( Wikipedia)는 신속성과 폭넓은 확대를 위해 편집 제어권을 단념했다. 냅스터는 업체가 판매하는 모든 음악을 담은 ‘카탈로그’를 포기한 대신 광범위한 네트워크를 얻었다. 아마존은 실제 상점을 포기하자 전세계에 책을 판매할 수 있게 되었다. 구글은 대기업을 고객으로 하는 것을 단념한 대신, 나머지 80%의 중소기업을 얻었다. 이는 적의 힘을 이용해 적을 넘어뜨리는 합기도(aikido)와 유사하다. “전세계에 있는 누구나 이 글을 업데이트할 수 있다. 일부의 사람에게 있어서는 이것은 매우 귀찮은 일일 것이다”(냇 토킹톤)
사용자 삽입 이미지
사용자 삽입 이미지

이 기사는 2005년 9월 30일에 O'Reilly Network로 공개된 것이다.
 
 
  Comments,     Trackbacks
[웹2.0] 소프트웨어 발표 주기의 종말

[웹2.0] 소프트웨어 발표 주기의 종말

 

연재순서

1회.
[웹2.0] 플랫폼으로서의 웹

2회.[웹2.0] 집단 지능이 결집되다

3회.[웹2.0] 데이터는 차세대의「인텔 인사이드」

4회.[웹2.0] 소프트웨어 발표 주기의 종말

5회.[웹2.0] 가벼운(Lightweight) 프로그래밍 모델

6회.[웹2.0] 단일 디바이스를 넘는 소프트웨어

7회.[웹2.0] 리치 유저의 경험들

 

‘구글 대 넷스케이프’ 논의에서 언급했던 대로 인터넷 시대 소프트웨어의 중요한 특징 중의 하나는 그것이 물건이 아니라 서비스로서 제공된다는 점이다. 이 사실은 기업의 비즈니스 모델에 근본적인 변화를 일으키고 있다.


오퍼레이션은 그 자체가 핵심 경쟁력이 된다


구글이나 야후의 제품 개발 능력은 각 사의 오퍼레이션(Operation) 능력에 비례한다. 물건으로서의 소프트웨어와 서비스로서의 소프트웨어는 완전히 다르다. 서비스로 제공되는 소프트웨어는 일일 단위로 유지보수 되지 않으면 올바르게 기능하지 않는다. 구글은 서비스를 올바르게 유지하기 위해 끊임 없이 웹을 돌아다니면서 인덱스를 업데이트한다. 또한 검색 결과에 악영향을 미치는 링크 스팸을 비롯한 모든 시도를 걸러내야 하며, 수억 건의 검색 행위에 쉼 없이 응답해야 한다. 더욱이 문맥에 맞는 광고까지 찾아내야 한다.

구글은 시스템 관리, 네트워크, 로드 밸런싱에 관한 기술을 어쩌면 검색 알고리즘 그 자체보다 더 중요하게 다루고 있다. 경쟁사와 비교해 구글이 가격 우위의 입장에 서 있는 것은 이러한 프로세스 자동화에 성공했기 때문이다.

웹 2.0 기업에서는 펄, 파이썬, PHP, 그리고 최근에는 루비(Ruby)라는 스크립트 언어가 매우 큰 역할을 하고 있다. 여기에는 그만한 이유가 있다. 잘 알려져 있는 대로 썬의 첫 번째 웹 마스터였던 하산 슈뢰더(Hassan Schroeder)는 펄을 ‘인터넷의 덕 테이프(duct tape)-어느 가정에나 하나씩 있는 점착 테이프’라고 불렀다. 소프트웨어가 물건이었던 시대의 기술자들에게 스크립트 언어로 불려 업신여겨졌던 동적인 언어는 지금은 시스템 관리 책임자, 네트워크 관리자, 그리고 끊임없는 변경을 필요로 하는 동적인 시스템을 구축하고 있는 애플리케이션 개발자로부터도 지지를 받고 있다.

오픈 소스의 개발 관행에 따라 사용자를 공동 개발자로 취급해야 한다(오픈 소스 라이선스에 근거해 릴리스 될 가능성이 낮은 소프트웨어도 마찬가지이다)

“빨리 출시하고 자주 출시한다’라는 오픈 소스의 격언은 ‘영원한 베타 버전’을 의미한다. 게다가 진보적인 개념으로 모습을 바꾸었다. 소프트웨어는 개방적인 환경에서 개발되어 월간, 주간, 심지어 일일 단위로 새로운 기능이 추가된다. G메일, 구글 맵, 플릭커(Flickr), 델리셔스(del.icio.us)라는 서비스의 로고가 몇 년간이나 ‘베타’ 로고를 갖고 있는 것은 놀랄만한 일이 아니다.

따라서 유저의 행동을 실시간 감시해 어떤 신기능이 어떻게 이용되고 있는지를 관찰하는 일도 웹 2.0 기업의 중요한 핵심 경쟁력이 될 것이다. 대규모 온라인 서비스의 한 웹 개발자는 다음과 같이 말하고 있다. “우리는 매일 2~3가지의 새로운 기능을 사이트 어딘가에 추가하고 있다. 유저가 사용하지 않으면 그 기능은 삭제되고, 유저의 반응이 좋으면 그 기능을 사이트 전체로 확대한다”

최근 플릭커의 수석 개발자인 칼 헨더슨(Cal Henderson)은 플릭커가 30분 마다 새로운 빌드를 인스톨하고 있다고 밝혔다. 이것은 기존과는 완전히 다른 개발 모델이다. 모든 웹 애플리케이션이 플릭커와 같이 극단적인 방법으로 개발되고 있는 것은 아니지만 대부분의 웹 애플리케이션은 PC 시대나 클라이언트 서버 시대와는 완전히 다른 개발 주기를 갖고 있다. 얼마 전에 ‘MS는 구글을 이길 수 없다”라는 기사가 ZDNet에 게재된 바 있다. 그 이유는 바로 이것이다. “MS 의 비즈니스 모델은 모든 유저가 2~3년마다 컴퓨팅 환경을 업그레이드 하는 것을 전제로 하고 있다. 그에 비해 구글의 비즈니스 모델은 모든 유저가 매일 자신의 컴퓨팅 환경을 사용하고, 새로운 정보를 찾는 것을 전제로 하고 있다”

그동안 MS는 경쟁 상대에게서 배워 결과적으로 경쟁에서 최고가 되었다는 것을 증명해왔으며, 여기에는 의문의 여지가 없다. 하지만 이번 경쟁에 이기기 위해서 MS(나아가서는 기존의 모든 소프트웨어 기업)는 지금까지와는 본질적으로 다른 기업이 될 필요가 있다. 한편 순수한 웹 2.0 기업은 벗어 던져야 할 낡은 패턴(그리고 그에 상응하는 비즈니스 모델과 수익원)을 가지지 않기 때문에 기존의 기업보다 유리한 출발선상에 서있다. @

이 기사는 2005년 9월 30일에 O'Reilly Network로 공개된 것이다.

 

 

저자 :Tim O'Reilly   2006/01/10
 
사용자 삽입 이미지
 
 
  Comments,     Trackbacks
[웹2.0] 데이터는 차세대의「인텔 인사이드」

[웹2.0] 데이터는 차세대의「인텔 인사이드」

 

연재순서

1회.
[웹2.0] 플랫폼으로서의 웹

2회.[웹2.0] 집단 지능이 결집되다

3회.[웹2.0] 데이터는 차세대의「인텔 인사이드」

4회.[웹2.0] 소프트웨어 발표 주기의 종말

5회.[웹2.0] 가벼운(Lightweight) 프로그래밍 모델

6회.[웹2.0] 단일 디바이스를 넘는 소프트웨어

7회.[웹2.0] 리치 유저의 경험들

 

중요한 인터넷 애플리케이션에는 반드시 그것을 지지하는 전문 데이터베이스가 있다. 구글의 웹 크롤, 야후의 디렉토리, 아마존의 제품 데이터베이스, 이베이의 제품 데이터베이스, 맵퀘스트(MapQuest)의 지도 데이터베이스, 냅스터의 분산형 악곡 데이터베이스 등이 그것이다.

지난해 할 베리안은 “SQL이야말로, 차기 HTML이다”라고 말했다. 데이터베이스 관리는 웹 2.0의 핵심 능력이기도 하다. 때문에 이런 애플리케이션은 단지 소프트웨어가 아니고, ‘인포메이션 웨어(infoware)’라고 불리기도 한다. 이 사실은 중요한 물음, 즉 “그 데이터를 소유하고 있는 것은 누구인가”라는 물음을 던진다.

인터넷 시대에는 데이터베이스를 컨트롤하여 시장을 지배해, 막대한 수익을 올린 기업이 적지 않다. 초기에 정부의 위탁을 받고 네트워크 솔루션(Network Solutions, 후에 베리사인이 인수)이 독점한 도메인명 등록 사업은 인터넷에 있어서의 최초의 달러 박스 사업이 됐다.

인터넷 시대에는 비즈니스 우위를 확보하는 것은 훨씬 어려워진다고 했지만, 소프트웨어 API를 지배하는 것으로 중요한 데이터 소스를 지배한다면 우위를 확보하는 것은 그렇게 어렵지 않다. 그 데이터 소스가 작성에 막대한 자금을 필요로 하는 것이거나, 네트워크 효과에 의해 수익을 확대할 수 있는 경우는 더욱 그렇다.

예를 들어, 맵퀘스트, 맵스야후닷컴(maps.yahoo.com), maps.msn.com, maps.google.com등이 생성하는 지도에는 반드시 “지도의 저작권은 NavTeq, TeleAtlas에 귀속됩니다”라고 하는 문장이 덧붙여져 있다.

최근 등장한 위성 화상 서비스의 경우는 “화상의 저작권은 디지털 글로브(Digital Globe)에 귀속됩니다”라고 쓰여져 있다. 이런 기업은 막대한 자금을 투자하고 독자적인 데이터베이스를 구축했다. 내브텍(NavTeq)은 7억 5000만 달러를 들여 주소/경로 정보 데이터베이스를 구축했고, 디지털 글로브는 공공 기관으로부터 공급되는 화상을 보완하기 위해 5억 달러를 들여 위성을 쏘아 올렸다.

내브텍은 친숙한 인텔 인사이드 로고를 모방해, 카 내비게이션 시스템을 탑재한 차에 ‘NavTeq Onboard(내브텍 탑재차)’라는 마크를 붙이고 있다. 실제 이런 애플리케이션에 있어서, 데이터는 인텔 인사이드라고 불릴 만큼 중요성을 가지고 있다. 소프트웨어 인프라의 거의 모든 것을 오픈 소스 소프트웨어나 상품화한 소프트웨어로 조달하고 있는 시스템에 있어서, 데이터는 유일한 소스 컴포넌트이기 때문이다.

현재 격렬한 경쟁이 전개되고 있는 웹 매핑 시장은 애플리케이션의 핵이 되는 데이터를 소유하는 것이 경쟁력을 유지하는데 있어서 얼마나 중요한가를 나타내고 있다. 웹 매핑이라고 하는 카테고리는 1995년에 맵퀘스트가 만들어 낸 것이다. 맵퀘스트는 선구자였지만, 야후, MS, 그리고 최근에는 구글과 같은 신규 참가자가 부각되도록 했다. 이런 기업은 맵퀘스트와 같은 데이터의 사용 허락을 받아 경쟁되는 애플리케이션을 거뜬히 구축할 수 있었다.

그것과 대조적인 것이 아마존이다. 반스앤노블즈닷컴(Barnesandnoble.com) 등의 경쟁 기업과 같이 아마존의 데이터베이스도 원래초는 R.R. 바우커(Bowker)가 제공하는 ISBN(국제표준도서 번호)을 기초로 한 것이었다. 그러나 맵퀘스트와 달리 아마존은 바우커의 데이터에 출판사로부터 제공되는 표지 화상이나 목차, 색인, 샘플 등의 데이터를 추가하는 것으로, 데이터베이스를 철저하게 확장해 갔다.

더 중요한 것은 이런 데이터에 유저가 코멘트를 달 수 있다는 것이다. 10년 지난 지금은 바우커는 아니고 아마존이 서지 정보의 주요한 정보원이 되고 있다. 소비자뿐만 아니라, 학자나 사서도 아마존의 데이터를 참조하고 있다. 또 아마존은 ASIN이라고 불리는 독자적인 식별 번호도 도입했다. ASIN는 서적의 ISBN에 상당하는 것으로, 아마존이 취급하는 서적 이외의 상품을 식별하기 위해 이용되고 있다. 사실 아마존은 유저의 공급하는 데이터를 적극적으로 수중에 넣어, 독자적으로 확장했던 것이다.

이것과 같은 것을 맵퀘스트가 했다면 어떻게 됐을까. 유저가 지도와 경로 정보로 코멘트를 더해 겹겹이 부가가치를 더할 수 있다면 같은 기초 데이터를 손에 넣는 것만으로, 타사가 이 시장에 참가할 수 없었을 것이다.

최근 등장한 구글 맵스는 애플리케이션 벤더와 데이터 공급자의 경쟁을 실시간으로 관찰할 수 있는 장소가 되고 있다. 구글의 경량 프로그래밍 모델을 이용하고, 서드파티가 다양한 부가가치 서비스를 낳고 있지만, 이런 서비스는 구글 맵스와 인터넷의 다양한 데이터 소스를 조합한 매쉬업의 형태를 취하고 있다.

폴 래이드마처의 하우징맵스닷컴(housingmaps.com)은 구글 맵스와 크래이그리스트의 임대 아파트/판매처 정보를 조합한 인터랙티브인 주택 검색 툴이다. 이것은 구글 맵스를 이용한 매쉬업의 걸출한 예라고 할 수 있다.

현재 이런 매쉬업의 대부분은 기업가들의 눈길을 받고 있다. 적어도 일부의 개발자의 사이에서 구글은 벌써 데이터 소스의 자리를 내브텍으로부터 빼앗아 가장 인기가 있는 중개 서비스가 되고 있다. 향후 몇 년간은 데이터 공급자와 애플리케이션 벤더 사이에서는 경쟁이 전개될 것이다. 웹 2.0 애플리케이션을 개발하기 위해서는 특정 데이터가 극히 중요한 역할을 완수하는 것을 양방이 이해하게 되기 때문이다.

코어 데이터를 둘러싼 싸움은 벌써 시작됐다. 이런 데이터의 예로는 위치 정보, 아이덴티티(개인 식별) 정보, 공공 행사의 일정, 제품의 식별 번호, 이름 공간 등이 있다. 작성에 고액의 자금이 필요한 데이터를 소유하고 있는 기업은 그 데이터의 유일한 공급원으로서 인텔 인사이드형의 비즈니스를 실시할 수 있을 것이다. 그렇지 않은 경우는 최초로 주요한 대중의 유저를 확보해, 그 데이터를 시스템 서비스로 전환할 수 있던 기업이 시장을 억제한다.

아이덴티티 정보의 분야에서는 페이팔(PayPal), 아마존의 원클릭(1-click), 많은 유저를 가지는 커뮤니케이션 시스템 등이 네트워크 규모의 ID 데이터베이스를 구축할 때의 라이벌이 될 것이다. 구글은 휴대 전화 번호를 지메일의 어카운트 인증에 이용하는 시도를 시작했다. 이것은 전화 시스템을 적극적으로 채용해, 독자적으로 확장하는 첫 걸음이 될지도 모른다.

한편, Sxip와 같은 신생 기업은 ‘제휴 아이덴티티(federated identity)’의 가능성을 모색하고 있다. Sxip가 목표로 하고 있는 것은 ‘분산형 원클릭’과 같은 구조를 만들어, 웹 2.0형의 아이덴티티 하부조직을 구축하는 것이다. 캘린더의 분야에서는 EVDB가 위키형의 아키텍처를 사용하고, 세계 최대의 정보 공유 캘린더를 구축하려고 하고 있다.

결정적인 성공을 거둔 신생 기업이나 실체는 아직 없지만, 이런 분야의 표준과 솔루션은 특정의 데이터를 인터넷 운영체제의 신뢰할 수 있는 하부조직으로 바꿔 차세대 애플리케이션의 등장을 가능하게 할 것이다.

데이터에 관해서는 프라이버시와 저작권 문제도 언급해 두지 않으면 안 된다. 초기의 웹 애플리케이션은 저작권을 너무 엄밀하게는 행사해 오지 않았다. 예를 들어, 아마존은 사이트에 투고되는 리뷰의 권리가 자사에 귀속한다고 주장하고 있지만, 그 권리를 실제로 행사하지 않고 있다. 그러나 기업은 데이터 관리가 경쟁 우위의 원천이 되는 것을 인식하고 있으므로, 향후는 데이터 관리가 지금보다 어렵게 행해지게 될지도 모른다.

소프트웨어의 융성이 무료 소프트웨어 운동을 가져온 것처럼, 데이터베이스의 융성에 의해서 향후 10년 이내에 프리 데이터 운동이 일어나게 될 것이다. 반동의 조짐은 벌써 나타나고 있다. 위키피디어나 크리에이티브 커먼(Creative Commons) 등의 오픈 데이터 프로젝트, 사이트 표시를 사용자가 할 수 있는 Greasemonkey 등의 소프트웨어 프로젝트가 그 일례다. @


이 기사는 2005년 9월 30일에 O'Reilly Network로 공개된 것이다
 

 
저자 :Tim O'Reilly   2006/01/10
 
사용자 삽입 이미지
 
  Comments,     Trackbacks
[웹2.0] 집단 지능이 결집되다

[웹2.0] 집단 지능이 결집되다

 

연재순서

1회.[웹2.0] 플랫폼으로서의 웹

2회.[웹2.0] 집단 지능이 결집되다

3회.[웹2.0] 데이터는 차세대의「인텔 인사이드」

4회.[웹2.0] 소프트웨어 발표 주기의 종말

5회.[웹2.0] 가벼운(Lightweight) 프로그래밍 모델

6회.[웹2.0] 단일 디바이스를 넘는 소프트웨어

7회.[웹2.0] 리치 유저의 경험들

 

웹 1.0시대에 탄생해 웹 2.0시대에도 여전히 성공가도를 달리고 있는 대기업은 웹의 힘을 사용해 집단 지능(Harnessing Collective Intelligence)을 이용한다는 웹 2.0의 원칙을 실천하고 있다.
 

집단 지능을 이용하는 웹2.0의 원칙

• 웹의 기반은 하이퍼 링크이다. 유저가 추가한 새로운 콘텐츠나 사이트는 그 외의 유저에게 발견되어 링크되는 것으로 웹의 구조에 포함된다. 뇌의 시냅스와 같이 이러한 연결은 반복과 자극에 의해서 강화되어 웹 유저 전체의 활동에 따르고, 유기적으로 성장해 간다.

• 초기 인터넷 시대의 대표적인 성공 기업인 야후는 카탈로그 혹은 링크 디렉터리로서 등장했다. 야후는 몇천명 또는 몇백만명의 웹 유저가 작성한 웹페이지를 모았다. 그 후, 야후는 사업을 확대해 다양한 콘텐츠를 다루게 되었다. 인터넷 유저 전체의 활동에 액세스하기 위한 포털이라고 하는 역할은 지금도 야후의 본질적인 가치가 되고 있다.

• 검색 분야에 있어서의 구글의 핵심 전략은 페이지순위(PageRank)였다. 페이지순위는 문서의 특징뿐만이 아니라 웹의 링크 구조를 사용하고 좀더 좋은 검색 결과를 이끌어내는 수법이다. 이 기술에 의해서 구글은 순식간에 누구나가 인정하는 검색 시장의 리더가 되었다.

• 이베이의 상품은 유저 활동 그 자체다. 웹과 같이 이베이도 유저 활동에 따라 유기적으로 성장한다. 이베이의 역할은 유저의 활동의 준비를 하는 것에 있다. 또 경쟁 기업과 비교했을 때 이베이의 강점은 구매자와 판매자가 임계규모(critical mass)에 이르고 있는 것이다. 이 때문에 같은 서비스를 제공하는 기업이 나타나도 그 서비스는 이베이보다 덜 매력적으로 여겨진다. 아마존은 반즈앤노블닷컴 등의 경쟁 기업과 같은 제품을 취급하고 있다. 그리고 양 사는 모두 같은 벤더로부터 제품 정보, 표지 그림, 목차 정보 등을 얻고 있지만 아마존은 유저의 참여를 포함시키는 구조를 구축했다.

아마존에는 타사의 몇 배의 유저 리뷰가 게재되고 있고 거의 모든 페이지에서 유저의 참여를 유도하고 있다. 특히 더 중요한 것은 아마존이 검색 결과를 개선하기 위해서 유저의 활동을 이용하고 있는 것이다. 반즈앤노블닷컴으로 검색하면 보통 자사의 제품이나 스폰서의 제품이 표시되는데 비해 아마존에서는 항상 가장 있기 있는 제품이 표시된다. 이 데이터는 매출뿐만 아니라 그 외의 요소—아마존을 잘 아는 사람들이 제품의 ‘흐름(flow)’라고 부르는 것에 근거해 리얼타임으로 정보를 제공한다. 타사보다 많은 유저 참여를 이끌어내는 것을 생각하면 아마존이 매출에서도 경쟁 회사를 앞지르고 있는 것이 전혀 놀라운 사실이 아니다.

웹에서는 현재 이 원칙을 이해해 한층 더 발전시키고 있는 혁신적인 기업이 두각을 나타내고 있다.

• 온라인 백과사전인 위키피디어(Wikipedia)는 누구라도 기사를 투고해 편집할 수 있다는 생각할 수도 없는 아이디어에 근거하고 있다. 위키피디어는 신뢰에 입각한 진보적인 실험이다. 또한 “눈만 충분히 있으면 어떤 버그도 심각하지 않다”라는 에릭 레이먼드(Eric Raymond)의 격언(원래는 오픈 소스 소프트웨어의 문맥으로 말해진 것)을 콘텐츠 작성에 적용하고 있다. 위키피디어는 이미 톱 100 웹 사이트로 꼽히고 있지만 많은 사람들은 톱 10에 진입하는 것은 시간 문제라고 보고 있다. 콘텐츠 작성의 세계에서는 큰 변화가 일어나고 있다!

• 최근 큰 주목을 끌고 있는 델리셔스(del.icio.us)나 플릭커(Flickr)와 같은 사이트는 폭소노미(folksonomy)의 선구자이다. 폭소노미란 많은 유저가 자유로운 키워드(일반적으로 태그라고 불린다)를 데이터에 부가하는 것에 의해 데이터를 완만하게 분류해 나가는 방법이다. 본래의 엄밀한 분류 방법과 달리 태그를 이용하면 뇌와 같은 복합적이고 중복된 조합을 만들어낼 수 있다. 예를 들어, 플릭커에 보내진 강아지의 사진에 ‘강아지’와 ’귀엽다’라는 태그를 붙이면 다른 사람들은 어디에서나 자신의 생각과 맞는 사람의 키워드로 이 사진을 찾아낼 수 있다.

• 클라우드마크(Cloudmark)와 같은 스팸메일 필터링 제품은 많은 메일 이용자의 판단을 기초로 어떤 메일이 스팸메일인가, 그렇지 않은가를 판정한다. 판정 정도는 메시지만을 분석하는 기존 방법보다 높다.

• 인터넷 시대의 성공 기업은 자사의 제품을 광고 하지 않는다. 이러한 기업의 제품은 ‘바이러스 마케팅(viral marketing)’, 즉 유저의 소문에 의해서 퍼진다. 광고에 의존하는 사이트나 제품은 웹 2.0은 아니라고 판단해도 틀림없다.

• 오픈 소스의 협동적인 개발 방법은 많은 웹 인프라(Linux, Apache, MySQL, 대부분의 웹 서버에 포함되는 Perl, PHP, Python의 코드 등)에도 적용되고 있다. 오픈 소스 그 자체도 인터넷이 가능하게 한 집합지의 일례다. 소스포지닷넷(SourceForge.net)에는 10만 건을 넘는 오픈 소스 소프트웨어 프로젝트가 등록되어 있다. 이 사이트에는 누구나 프로젝트를 추가할 수 있어 코드를 다운로드하고 그것을 이용할 수 있다. 유저가 이용하는 것에 의해서 새로운 프로젝트는 주변부에서 중심부로 이동한다. 이것은 거의 100%를 바이러스 마케팅에 의존한 유기적인 소프트웨어의 채용 프로세스이다.

교훈:웹 2.0시대에는 유저의 공헌이 가져오는 네트워크 효과가 시장 우위를 획득하는 가장 중요한 요소다.

참여의 아키텍처

 
몇 개의 시스템은 최초부터 유저의 참여를 유도하도록 설계되고 있다. 댄 브리클린(Dan Bricklin)은 논문 ‘The Cornucopia of the Commons’에서 대규모 데이터베이스를 구축하는 세 가지 방법을 설명했다. 첫 번째는 야후가 보여준 방법으로 데이터베이스를 구축하기 위해 사람들을 고용하는 것이다. 두 번째는 오픈 소스 커뮤니티에서 힌트를 얻은 방법으로 이 작업을 진행할 자원봉사자를 구하는 것이다. 오픈 디렉터리 프로젝트가 하나의 예로 볼 수 있다. 세 번째가 냅스터(Napster)이다. 냅스터는 다운로드 받은 음악을 자동으로 업로드하게 되어 있다. 이 결과 모든 유저는 자동적으로 공유 데이터베이스의 가치의 향상에 공헌하게 되었다. 이후 모든 P2P 파일 공유 서비스는 이러한 접근 방식을 따르고 있다.

웹 2.0시대의 중요한 교훈의 하나는 유저가 가치를 더한다는 것이다. 그러나 소수의 유저만이 자신의 시간을 할애해 기업 애플리케이션의 가치를 높이려고 할 것이다. 따라서 웹 2.0 기업은 애플리케이션의 일상적인 사용의 부수 효과로 유저 데이터를 수집하고, 애플리케이션의 가치를 높일 수 있는 포괄적인 정책들을 설정해야 한다. 앞서 언급한 것처럼, 웹 2.0 기업의 시스템은 이용자가 증가할수록 개선된다.

미치 케이퍼(Mitch Kapor)는 “아키텍처는 정책이다”라고 말했다. 참여는 냅스터의 본질이며, 기본 아키텍처의 일부분이다.

이러한 참여의 아키텍처가 종종 언급되는 자원봉사 정신보다 오픈 소스 소프트웨어의 성공에 기여했을지도 모른다. 인터넷, 월드 와이드 웹, 리눅스, 아파치, 펄 등의 오픈 소스 소프트웨어에는 이러한 아키텍처가 적용되고 있어 ‘이기적인’인 관심사를 추구하는 개인 사용자들이 집단 가치까지 높일 수 있게 되어 있다. 이러한 프로젝트들 각각은 작은 핵심, 명확하게 정의된 확장 구조, 사용자들이 추가할 수 있도록 잘 정의된 컴포넌트를 갖고 있다. 이것은 펄의 창시자인 래리 윌(Larry Wall)이 ‘양파’를 예를 들어 설명한 성장하는 외부 계층들을 갖고 있다. 이러한 기술은 그들이 고안했던 방식대로 네크워크 효과를 낳고 있다.

이러한 프로젝트는 참여의 아키텍처에 적절한 것인지도 모른다. 그러나 아마존에서 보여준 것처럼 지속적인 노력(제휴 프로그램과 같은 인센티브를 이용하면)을 하면 이 아키텍처와는 전혀 무관하다고 생각되는 시스템에도 참여의 아키텍처를 적용할 수 있다.
 

블로그와 집단의 지혜

 
웹 2.0시대의 특징으로 가장 많이 언급되는 것이 블로그의 출현이다. 개인 홈 페이지는 웹의 초기부터 존재했고, 일기나 개인의 의견을 엮은 컬럼은 그 이전부터 있었다. 그렇다면 지금 이 정도로 각광을 받고 있는 것을 무엇 때문인가.

블로그의 기본은 일기 형식의 개인 홈페이지다. 그러나 리치 스크렌터(Rich Skrenta)가 지적한 대로 블로그의 연대기적 구조는 사소한 차이로 보이지만 기존과는 완전히 다른 전달 방법, 광고, 가치 사슬을 생산하고 있다.

블로그를 특별하게 만든 또 하나의 요인은 RSS로 불리는 기술이다. RSS는 웹의 기본 구조에 중요한 진보를 가져왔다. 초기 해커들은 CGI를 사용하는 것으로 데이터베이스와 연동한 웹 사이트를 구축할 수 있는 것을 발견했다. 그 시기 이후 RSS는 가장 중요한 진보라 할 수 있다. RSS를 이용하면 페이지에 링크할 뿐만 아니라 그 페이지를 구독할 수 있어 페이지가 변경될 때마다 변경 사실을 알 수 있다. 스크렌터는 이것을 ‘성장하는 웹(the incremental)’이라고 부르고, 다른 이들은 ‘라이브 웹(live web)’이라고 부른다.

물론 데이터베이스와 연동해 동적으로 콘텐츠를 생성하는 ‘동적인 웹 사이트’가 정적인 콘텐츠를 갖는 웹 페이지를 대체한 것은 수십년 전이다. 라이브 웹에서 동적이라고 하는 것은 페이지뿐만 아니라 링크도 의미한다. 블로그에 링크하는 것은 계속 바뀌는 페이지에 링크하는 것과 동일하다. 각각의 기사에 링크할 때는 고유링크(permalink)를 이용한다. 블로그에 갱신된 사항이 있으면 이를 알려주는 메시지가 전달된다. 이와 같이 RSS 피드는 북마크나 링크보다 훨씬 강력하다.

또한 RSS는 웹 브라우저가 단순히 웹 페이지를 보여주는 수단이 아니라는 것을 의미한다. RSS 수집기에는 블로그라인과 같은 웹 기반인 것도 있지만 데스크톱 클라이언트도 있다. 그 외에 사용자가 휴대 기기에서 끊임없이 갱신되는 콘텐츠를 볼 수 있도록 해주는 것도 있다.

현재의 RSS는 블로그의 기사뿐만이 아니라, 주가, 날씨 정보, 사진 등 모든 종류의 데이터의 갱신을 알리기 위해 이용되고 있다. 이것은 RSS의 근원까지 거슬러 올라간다. RSS는 1997년에 정기적으로 갱신된 데이터의 정보를 보내기 위해 이용되던 데이브 위너(Dave Winer)의 ‘Really Simple Syndication’ 기술과 넷스케이프의 ‘Rich Site Summary’가 합류하는 것에 의해서 탄생했다. Rich Site Summary는 넷스케이프의 포털 사이트를 사용자가 커스터마이즈해 갱신 정보를 정기적으로 얻을 수 있도록 하는 기술이었지만 넷스케이프는 이 기술에 흥미를 갖고 있지 않았다. 결국 이 기술은 블로그의 개척자인 유저랜드(Userland)에 의해 발전했다. 현재의 RSS 관련 애플리케이션에는 양쪽 기술 모두를 볼 수 있다.

그러나, 일반적인 웹 페이지와 블로그를 구별해주는 것은 RSS만이 아니다. 톰 코티스(Tom Coates)는 고유링크(permalink)의 중요성에 대해 다음과 같이 말하고 있다.

“…사소한 기능과 같이 생각될지도 모르지만 고유링크(permalink)의 등장에 따라 블로그는 간단하게 정보를 보낼 수 있는 툴에서 커뮤니티들이 회화 형식으로 생산되는 것으로 바뀔 수 있었다. 고유링크에 의해 처음으로 다른 사이트의 특정 기사에 대해 의견을 내놓고 사이트의 소유자와 대화할 수 있는 것이 가능하게 되었다. 토론이 등장하고 채팅이 시작되었다. 그 결과, 우정이 생겼거나 혹은 우정을 더욱 견고하게 만들었다. 고유링크는 블로그와 블로그를 엮는 첫 번째이자 가장 성공적인 시도였다”(코티스)

RSS와 고유링크는 웹 프로토콜인 HTTP 위에 유즈넷(Usenet)의 NNTP(Network News Protocol)의 많은 특성을 다양한 방법으로 추가시켰다. 블로그스피어(blogosphere)는 초기 인터넷의 대화의 장으로 여겨졌던 유즈넷과 게시판이라고 할 수 있다. 사람들은 서로의 사이트를 읽고 각 페이지의 코멘트에 간단하게 링크하는 것이 가능하다. 뿐만 아니라 트랙백(trackback)이라고 불리는 구조를 사용하면 다른 사람이 자신의 페이지에 링크한 것을 알 수 있어 상호 링크하거나 코멘트를 추가하는 것으로 응답할 수 있다.

흥미롭게도 양방향 링크는 제나두(Xanadu)와 같은 초기 하이퍼 텍스트(hyper text) 시스템이 목표였다. 하이퍼 텍스트(hyper text) 순수주의자들은 트랙백을 양방향 링크를 실현하기 위한 걸음으로서 환영했다. 그러나 트랙백은 엄밀하게는 양방향이 아니다. 양방향 링크와 동등한 효과를 만들어내는 대칭적인 단방향 링크이다. 이 차이가 사소하게 생각될지도 모르지만 실제로는 매우 크다.

예를 들어, 상대의 승인이 있어야만 커넥션을 구축할 수 있는 ‘Friendster’, ‘ Orkut’, ‘LinkedIn’과 같은 소셜 네트워킹 시스템은 웹 정도의 확장성을 갖고 있지 않는다. 사진 공유 서비스인 플릭커(Flickr)의 공동 설립자인 캐터리나 페이크(Caterina Fake)가 지적한 대로 상호 관심을 갖게 되는 것은 우연히 일어나는 것이다. (이 때문에 플릭커에서는 유저가 관찰 목록(Watch List)를 작성해 한 유저가 RSS를 통해 다른 유저가 갱신하는 사진을 볼 수 있도록 하고 있다. RSS에 등록했을 경우, 상대에게도 알려지지만 승인을 받을 필요는 없다)

웹 2.0의 본질이 집단 지능을 이용해 웹을 글로벌 브레인으로 바꾸는 것이라고 하면 블로그스피어는 끊임없이 계속되는 뇌 속의 대화를 모든 유저가 들을 수 있도록 하는 것이다. 이것은 뇌의 깊은 부분에서 거의 무의식가운데 행해지고 있는 사고가 아니라 오히려 의식적인 사고에 가깝다. 그리고, 의식적인 사고와 관심으로 인해 블로그스피어는 큰 영향력을 가지게 되었다.

검색 엔진은 적확한 검색 결과를 이끌어내기 위해서 링크 구조를 이용하고 있다. 이로 인해 대량의 링크를 만들어내는 블로거들은 검색 엔진 결과를 생성하는 중요한 역할을 하고 있다. 또한 블로그 커뮤니티는 극히 자기 언급적이기 때문에 다른 블로거가 주목하는 것으로 블로그의 존재감과 영향력을 확대하게 된다. 비평가들이 비난하고 있는 ‘반향실(echo chamber)’도 또 다른 증폭기이다.

이것이 단순한 증폭기였다면 블로그는 보잘 것 없는 것이 되었을 것이다. 그러나 위키피디어(Wikipedia)와 같이 블로그에서는 집단 지능이 일종의 필터 역할을 하고 있다. 제임스 슈리어웨키(James Suriowecki)가 ‘집단의 지혜’라고 부른 것이 페이지순위가 개별 문서를 분석하는 것보다도 뛰어난 검색 결과를 만들어내는 것처럼 블로그스피어에서는 집단의 관심이 가치 있는 것을 선별해낸다.

주류 미디어는 특정 블로그를 경쟁 상대라고 생각하겠지만 정말로 걱정스러운 것은 경쟁 상대가 블로그스피어 전체라는 것이다. 이것은 단순한 사이트간의 경쟁이 아니라 비즈니스 모델간의 경쟁이다. 웹 2.0 의 세계는 댄 길모어(Dan Gillmor)가 ‘우리가 미디어다(We, the media)’라고 부른 세계이기도 하다. 이 세계에서는 소수의 사람들이 은밀한 곳에서 무언가를 결정하는 것이 아니라 ‘한 때의 청중’이 무엇이 중요한가를 결정한다. @

이 기사는 2005년 9월 30일에 O'Reilly Network로 공개된 것이다.
 
 
  Comments,     Trackbacks
[웹2.0] 플랫폼으로서의 웹

[웹2.0] 플랫폼으로서의 웹

 

연재순서

1회.[웹2.0] 플랫폼으로서의 웹

2회.[웹2.0] 집단 지능이 결집되다

3회.[웹2.0] 데이터는 차세대의「인텔 인사이드」

4회.[웹2.0] 소프트웨어 발표 주기의 종말

5회.[웹2.0] 가벼운(Lightweight) 프로그래밍 모델

6회.[웹2.0] 단일 디바이스를 넘는 소프트웨어

7회.[웹2.0] 리치 유저의 경험들

 

 

닷컴의 붕괴는 웹2.0 탄생의 필연?

2001년의 닷 컴 버블의 붕괴는 웹에 있어서 하나의 전환점이 되었다.「웹은 과대하게 선전되고 있었다」라고 많은 사람이 결론을 내렸지만 버블과 그 후의 도태는 모든 기술 혁명에 공통되는 특징인 것처럼 생각된다. 일반적으로 도태는 신생 기술이 지금까지의 주역을 대신할 단계에 도달한 것을 나타내 보이고 있다. 전자는 붐을 쫓아갔지만 진짜 실력을 갖춘 기업이 성공을 거둔다. 이들이 서로 분리되는 것도 이해가 될 것이다.

「웹2.0」이라는 개념은 오라일리(O'Reilly)와 미디어라이브 인터내셔널(MediaLive International)에 의한 브레인 스토밍(brainstorming)에서 부터 탄생했다. 웹의 개척자이며, 현재는 오라일리의 부사장을 맡고 있는 데일 도어티(Dale Dougherty)는 웹은 「붕괴」되기는커녕 전보다 중요한 존재가 되었다고 한다. 활발한 웹사이트 들이 놀라운 정도로 착실하게 태어나고 있다고 지적했다. 또 버블 붕괴에서 살아남은 기업에는 닷컴의 붕괴에 의해서 웹은 웹2.0과 같은 확실히 어떤 전환점을 맞이해야 할 것이 아닌가 하는 공통점이 있어 보인다. 이러한 생각을 기초로 우리는 웹2.0 컨퍼런스의 개최를 결의했다.

불과 1년 반 사이에 웹2.0은 완전히 뿌리를 내렸다. 이 말을 구글로 검색하면 950만 건 이상에 달한다. 그러나 웹2.0이 의미하는 것에 대해서 아직껏 다수의 상이한 의견 차이가 있다. 이것을 말뿐인 무의미한 마케팅 용어라는 사람도 있고, 새로운 사회의 통념으로 보는 사람도 있다.

이 논문의 목적은 웹2.0이 무엇을 의미하고 있는지를 명확하게 하는 것이다.

최초의 브레인 스토밍(brainstorming)에서는 구체적인 예를 들어 웹2.0의 개념을 잡았다.

웹1.0웹2.0
DoubleClickGoogle Adsense
OfotoFlickr
AkamaiBitTorrent
Mp3.comNapster
Britannica OnlineWikipedia
Personal websitesblogging
eviteUpcorming.org and EVDB
Domain name speculationSearch engine optimization
Page viewsCost per click
Screen scrapingWeb services
publishingparticipation
Content management systemswikis
Directories(taxonomy)Tagging("folksonomy")
stickinesssyndication
<표 1> 웹1.0과 웹2.0의 비교

이 그 밖에도 다양한 예가 있다. 그러면 우리는 무엇을 가지고, 어느A 애플리케이션 또는 어프로치가 「웹1.0」이나 「웹2.0」에 속한다고 판단한 것일까(이 점을 분명히 하는 것이 우선시 되고 있다. 웹2.0이라는 문화의 전달자는 완전히 퍼져서 이 말의 진정한 의미를 이해하지 않고, 단순한 마케팅 용어로서 남용하는 기업이 증가하고 있기 때문이다. 게다가 이러한 유행어를 좋아하는 신생 기업의 대부분이 웹 2.0이라고는 도저히 부를 수 없다. 우리가 웹2.0의 예로서 이름을 든 앱스터(Napster)나 비트토런트(BitTorrent)는 엄밀하게는 웹 애플리케이션 조차 아니다).

우리는 웹1. 0의 성공 사례나 새롭게 등장한 흥미로운 애플리케이션에 주목하는 것으로 웹 2.0의 원칙을 이끌어내기로 했다.

웹2.0의 원칙

많은 중요한 개념처럼 웹2.0도 명확한 윤곽은 없고 그 외의 것을 끌어당기는 코어로서 존재한다. 그림 1에 웹2.0을 나타냈다. 이것은 웹2.0의 원칙과 실제의 세트로 정확히 태양계와 같이 이러한 원칙의 일부 또는 모든 것을 입증하고 있는 사이트가 다양한 거리로 코어와 결합되어 있다는 것을 알 수 있다.

사용자 삽입 이미지
<그림 1> 웹2.0의 meme map

그림 1은 오라일리 미디어의 「FOO Camp」컨퍼런스에서 진행되었던 브레인 스토밍(brainstorming) 세션에서 작성된 웹2.0의 「Meme 맵」이다. 스케치 단계의 것이지만 웹2.0의 코어로부터 다양한 아이디어가 태어나고 있는 것을 알 수 있다.

2004년 10월에 개최된 제1회 웹2.0 컨퍼런스의 개회 연설에서 존 베텔레(John Battelle)와 나는 이러한 원칙의 일부를 소개했다. 제1 원칙은 「플랫폼으로서의 웹」이었다. 그러나 이것은 웹1.0의 총아로 MS와의 격투의 끝에 진 냅스터가 내건 슬로건이기도 했다. 또 첫머리에서 웹1.0의 예로서 이름을 든 더블클릭(DoubleClick)과 아카마이(Akamai)도 웹을 플랫폼으로서 다룬 선구적인 기업이었다. 광고 서비스를 「웹 서비스」라고 생각하는 사람이 많지 않을지도 모르지만 광고 서비스는 광범위하게 배치된 첫 웹 서비스-최근의 용어를 사용하면 「매쉬 업」이었다. 모든 배너 광고는 2개의 웹 사이트가 밀접하게 협력해 통합된 페이지를 유저의 컴퓨터에 표시하는 형태로 나타난다.

아카마이도 네트워크를 플랫폼으로서 다루는 기업 중의 하나다. 아카마이는 스택의 한층 더 깊은 부분에서, 대역폭의 혼잡을 해소하기 위한 캐싱과 콘텐츠 전달 네트워크를 구축하고 있다.

그럼에도 불구하고 이 2개의 선구적 기업과 웹2.0 기업의 사이에는 명확한 차이가 있다. 후의 참가자들은 새로운 플랫폼을 보다 깊게 이해하는 것으로 같은 문제에 대해서 보다 효과적인 솔루션을 제공했다. 더블클릭과 아카마이는 웹2.0의 선구자였지만 웹2.0의 디자인 패턴을 도입하면 더 많은 가능성을 실현할 수 있다.

여기에서는 세 개의 사례를 파헤쳐 웹1.0과 웹2.0의 본질적인 차이를 알아보자

넷스케이프 vs 구글

넷스케이프가 웹1.0의 기수였다고 하면 구를이 웹2.0의 기수라는 것에 이의가 없을 것이다. 양 회사의 IPO는 각각의 시대를 상징하는 사건이기도 했다. 우선 양 회사와 그 포지션의 차이를 비교해 가자.

넷스케이프는 낡은 소프트웨어 패러다임(paradigm)의 관점으로부터, 「플랫폼으로서의 웹」을 구상했다. 넷스케이프의 가장 중요한 제품은 웹 브라우저와 데스크톱 애플리케이션이었다. 넷스케이프는 브라우저 시장에서의 우위를 이용해 고액의 서버 제품 시장을 확립하려고 했다. 넷스케이프는 콘텐츠와 애플리케이션을 브라우저에 표시하기 위한 표준을 지배하고 있었으므로 이론적으로는 MS가 PC시장에서 향수하고 있는 것과 같은 시장 지배력을 손에 넣을 수 있을 것이었다. 「말 없이 달리는 탈 것」이라고 하는 표현이, 마차를 즐겨 온 사람들에게 자동차를 친밀한 것과 느끼게 한 것처럼, 넷스케이프는 데스크톱을 대신하는 것으로 「웹 톱」을 추진했다. 이 웹 톱에 넷스케이프 서버를 구입한 기업이 전달하는 업데이트하는 애플릿을 싣는다는 것이 넷스케이프의 계획이었다.

그러나 웹 브라우저와 웹 서버는 상품화해, 가치는 「스택의 상류」, 즉 웹 플랫폼상에서 제공되는 서비스로 옮겨 버렸다.

넷스케이프와 대조적으로 구글은 네이티브의 웹 애플리케이션으로 탄생했다. 구글은 소프트웨어를 판매한 것도 패키지 소프트웨어를 개발한 적도 없다. 구글은 서비스를 제공해 고객은 직접적 또는 간접적으로 서비스에 대한 사용료를 지불한다. 구글에는 과거의 소프트웨어 업계를 상징하는 것은 아무것도 없다. 소프트웨어의 발표 계획은 없고 개선은 계속적으로 행해진다. 라이센스 공여도 없으며, 판매도 없고, 사용량이 있을 뿐이다. 고객의 환경에 맞추어 소프트웨어를 다양한 플랫폼에 이식할 필요도 없다. 대량의 상품 PC를 사용하고, 극히 확장성이 높은 시스템을 구축해 자가의 커스텀 애플리케이션과 유틸리티를 오픈 소스 OS 위에서 실행하는 것만으로 좋다.

구글에 필요한 것은 넷스케이프가 전혀 필요로 하지 않았던 능력이다. 그것은 데이터베이스 관리다. 구글은 단순한 소프트웨어 툴이 모아진 것이 아니라 매우 특수한 데이터베이스다. 데이터가 없으면 툴은 도움이 되지 않지만, 소프트웨어가 없으면, 데이터를 관리할 수 없다. 웹1.0시대에 귀중한 보물 된 소프트웨어 라이센스나 API 관리 방법은 구글의 비즈니스 모델에게는 들어맞지 않는다. 구글은 소프트웨어를 배포할 필요는 없고, 그것이 적절히 기능하도록 하면 좋기 때문이다. 실제, 데이터를 수집해, 관리하는 능력이 없으면, 이 소프트웨어는 어떤 도움도 되지 않는다. 소프트웨어의 가치는 그 소프트웨어가 관리하는 데이터의 규모와 다이너미즘에 비례한다.

구글의 서비스는 대량의 인터넷 서버로 구성된 시스템을 통해 제공되지만, 구글의 서비스는 서버는 아니다. 유저는 브라우저를 통해 구글의 서비스를 이용하지만, 구글의 서비스는 브라우저는 아니다. 구글의 기간 사업은 검색 서비스이지만 구글은 검색 결과에 표시되는 콘텐츠조차 소유하고 있지 않다. 통화가 발신자와 수신자의 전화기뿐만이 아니라, 그 사이의 네트워크가 일어나도록 구글의 서비스는 브라우저, 검색 엔진, 그리고 목적의 콘텐츠가 보존되고 있는 서버 사이에 생겨 구글은 유저와 온라인으로의 경험을 묶어, 중개하는 역할을 완수한다.

넷스케이프나 구글은 어느쪽이나 소프트웨어 기업이라고 부를 수 있지만, 넷스케이프가 로터스, MS, 오라클, SAP 등의 1980년대의 소프트웨어 혁명으로부터 태어난 기업과 같은 소프트웨어의 세계에 속했다면 구글은 eBay, 아마존, 냅스터, 그리고 물론 더블클릭과 아카마이 등의 인터넷 애플리케이션 기업과 같은 그룹에 속한다.

더블클릭 vs 오버추어/애드센스

구글과 같이 더블클릭도 인터넷 시대의 산물이다. 더블클릭은 서비스로서 소프트웨어의 힘을 이용해, 데이터 관리를 핵심 능력(코어 컨피턴스(competence))으로 한다. 그리고 이미 설명한 대로 더블클릭은 「웹 서비스」라는 호칭이 등장하기 오래 전부터 웹 서비스를 제공해 온 선구적 기업이기도 했다. 그러나 더블클릭의 비즈니스는 그 비즈니스 모델에 의해서 제한을 받고 있었다. 더블클릭의 비즈니스는 90년대의 개념( 「웹은 퍼블리싱이며, 참가는 아니다」, 「웹을 지배하고 있는 것은 소비자가 아니고, 광고주이다」, 「규모가 중요한/인터넷은 미디어매트릭스(MediaMetrix)등의 웹 광고 조사 회사에 의해 결정되는 상위의 웹 사이트에 의해서 독점되고 있다」등 )에 중심을 두었기 때문이다.

더블클릭은 자사의 웹 사이트에서 동사의 소프트웨어가 「2000사 이상 성공리에 도입」되었다고 자랑스럽게 선언했다. 이에 비해 야후!서치 마케팅(구 오버추어(Overture))과 구글의 애드센스(AdSense)는 각각 수십만의 광고주에게 광고 서비스를 이미 제공하고 있다.

오버추어와 구글이 성공한 것을 크리스 앤더슨(Chris Anderson)이 「롱 테일」이라고 부른 것-즉, 웹의 과반수를 차지하고 있는 작은 사이트가 총체로서 큰 힘을 낳는 것을 양 회사가 이해하고 있었기 때문에-과 같다. 더블클릭의 서비스는 정식 계약을 통해 제공되므로 시장은 수천의 대규모 웹 사이트로 한정된다. 이에 비해 오버추어와 구글은 거의 모든 웹페이지에 광고를 게시하는 방법을 찾아냈다. 게다가 양 회사는 배너 광고나 팝업과 같은 발행자나 광고 대리점이 좋아하는 광고 형태가 아닌 소극적이고 문맥에 따른 소비자의 입장에 선 텍스트 광고를 선택했다.

웹2.0의 교훈:유저 셀프서비스와 알고리즘에 의한 데이터 관리를 도입해 웹 전체--중심부 뿐만이 아니라 주변부, 머리 뿐만이 아니라 긴 꼬리(롱 테일)의 끝에도 서비스를 제공한다.

당연히 이러한 태도는 그 외의 웹2.0 의 성공 사례에도 찾아볼 수 있다. 이베이는 중개 프로세스를 자동화하는 것으로 개인이 불과 수달러의 거래를 부정기적으로 할 수 있게 했다. 냅스터(법적 이유 때문에 활동을 중단했지만)는 악곡 중심의 데이터베이스를 구축하는 대신에 다운로드를 실시하는 모든 사람의 PC가 서버가 되어, 그 결과적으로, 네트워크가 확대되는 시스템을 구축해 네트워크를 펼쳐나갔다.

아카마이 vs 비트토런트

더블클릭과 같이 아카마이의 비즈니스도 꼬리는 아니고 머리에, 주변부는 아니고 중심부에 조준을 맞히고 있다. 아카마이는 중심부의 인기 사이트로의 액세스를 원활히 하는 것으로, 웹의 주변부에 있는 개인에게 이익을 주고 있지만 수익은 중심부의 사이트로부터 얻고 있다.

한편 비트토런트(BitTorrent)는 P2P의 다른 선구자들처럼 진보적인 어프로치로 인터넷의 분산을 꾀했다. 모든 클라이언트는 서버의 역할을 완수해, 파일은 세세하게 분리되어 여러 곳에서 공급된다. 대역폭과 데이터는 다운로드를 실시하는 사람들의 네트워크를 통해 유저의 인식없이 다른 유저에게 제공된다. 파일의 인기가 높은 만큼, 다운로드의 속도도 빨라진다. 인기 있는 파일 쪽이, 대역폭과 파일의 조각들을 제공하는 유저의 수도 많기 때문이다.

비트토런트는 웹2.0의 중요한 원칙을 입증하고 있다. 그것은 이용자가 증가하면 서비스는 자연스럽게 개선된다는 것이다. 아카마이가 서버를 늘리는 것 때문에 서비스를 개선할 수 없는데 비해 비트토런트는 소비자가 빠짐없이 자원을 가져온다. 비트로런트의 서비스에는 「참가의 아키텍처」, 즉 협력의 윤리가 포함되어 있어 서비스는 기본적으로 정보의 중개역으로서 웹의 주변부를 이어, 유저 자신 힘을 이용하기 위해서 존재하고 있다.

플랫폼은 항상 애플리케이션을 능가한다

MS는 플랫폼이 비장의 카드로서 모든 경쟁에서 승리해 왔다. 과거의 경쟁 상대 중에는 높은 시장 점유율을 자랑하는 애플리케이션도 있었다. MS는 윈도우를 이용해 로터스1-2-3를 엑셀에, 워드퍼펙을 워드에 그리고 넷스케이프 내비게이터를 인터넷 익스플로러에 옮겨놓았다.

그러나 이번 싸움은 플랫폼과 애플리케이션이 아니고 완전히 다른 비즈니스 모델을 가진 플랫폼끼리의 사이에서 벌어지고 있다. 한 쪽은 거대한 인스톨 베이스와 긴밀히 통합된 OS나 API를 무기로, 프로그래밍 패러다임(paradigm)를 지배하고 있는 소프트웨어 프로바이더, 다른 한편은 공통의 프로토콜, 개방적인 표준 그리고 협력 협정에 의해서 연결된 소유자를 가지지 않는 시스템이다.

윈도우는 소프트웨어 API에 의한 독점적 지배의 결정판이다. 넷스케이프는 MS가 다른 라이벌에 대해서 사용한 것과 같은 방법으로 MS의 지배권을 강탈하려고 했지만, 그 시도는 실패로 끝났다. 한편 웹의 개방적인 표준을 고집한 아파치(Aache)는 성공을 거두었다. 현재의 싸움은 플랫폼 대 애플리케이션이라는 어울리지 않은 것이 아니고, 플랫폼 대 플랫폼이라는 대등한 것이다. 이 싸움에서는 어느 쪽의 플랫폼이- 더 중요한 지, 어느 쪽의 아키텍처 또는 비즈니스 모델이 향후의 기회에 적합한지가 중요하게 된다.

PC시대의 초기에는 윈도우는 문제를 해결하기 위한 훌륭한 솔루션이었다. 윈도우는 애플리케이션 개발 기업에 공평한 씨름판을 제공해, 업계를 괴롭히고 있던 많은 문제를 해결했다. 그러나 하나의 회사가 관리하는 획일적인 어프로치는 이미 솔루션이 아니고 하나의 문제에 지나지 않는다. 커뮤니케이션 지향의 시스템(플랫폼으로서의 인터넷은 틀림없이 그 하나다)은 상호 운용성을 필요로 한다. 모든 상호작용의 양단을 관리할 수 없는 한 소프트웨어 API에 의해서 유저가 로그인 하는 것은 어렵다.

플랫폼을 지배하여 애플리케이션의 이득을 로그인 하려는 웹2.0 기업은 필연적으로 플랫폼을 비장의 카드로 하지는 않을 것이다.

로그인이나 경쟁 우위를 획득할 기회가 없는 것은 아니다. 그러나, 소프트웨어 API나 프로토콜을 지배하는 것으로 그러한 기회를 손에 넣는 것은 어려워질 것이다. 새로운 게임이 시작되었다. 웹2.0시대에 성공을 하는 것은 PC소프트웨어 시대의 룰로 퇴보하려고 하는 기업이 아니라 새로운 게임의 룰을 이해하고 있는 기업이다.

이 기사는 2005년 9월 30일에 O'Reilly Network로 공개된 것이다
 
저자 :Tim O'Reilly   2006/01/10
 
사용자 삽입 이미지
 
  Comments,     Trackbacks
ADO의 진화

ADO의 진화

 

ADO가 개발하는데 있어 얼마나 중요한지에 대해서는 이 글을 읽는 개발자 분들이 어느 누구보다 잘 알거라 생각한다. "VB 2005의 변화와 향상성"이란 주제로 기고하면서 ADO를 짚고 넘어가고자 하는 이유는 그 중요성으로 인하여 ADO를 조금이라도 소개하고 싶었던 충동이 강하게 작용하였기 때문이다.

이에 오늘은 너무 거창하지만 "ADO의 진화"라는 타이틀을 두어 ADO에서 ADO.NET으로의 발전에 대해 좀 더 다양하게 살펴보고자 한다. 지난 시간에 살펴 본 DataSet(DataTable)의 향상에 이어 Provider의 변화와 연결풀링 그리고, 배치업데이트에 대해 살펴보는 시간을 갖도록 하겠다.


Provider의 변화

ADO.NET 이전 버전에서는 Provider가 각각의 인터페이스 - 예를 들어 SqlClient, OracleClient - 에 기반하여 작성되었다. 이러한 특징으로 인해 각각의 Provider에 맞게 특정 속성과 메소드를 구현하는 방식을 취하였다. 물론 이것이 전혀 잘못된 방식을 아니지만 각각의 Provider에 맞게 계속적인 코딩을 해야 하는 문제를 내포하고 있었던 것 또한 사실이다. 이를 보완하기 위해 버전 2.0 에서는 새로운 공급자 모델을 제공하게 되는데 바로 System.Data.Common 에 있는 기본 클래스를 기반으로 작성될 수 있도록 한 부분이다. 하지만, 아쉽게도 비록 기본 클래스를 기반으로 작성은 가능하나 DB 서버에 특화된 SQL 구문 등은 지원하지 못한다는 단점 또한 내포하고 있다.

또한, 버전 2.0 에서는 Provider 객체를 생성하기 위하여 Provider Factory 클래스를 사용할 수 있게 되어 이전보다 나은 유연성을 제공하게 된다. ProviderFactory의 GetFactory 메소드를 사용하는 샘플코드를 확인해 보도록 하자.

사용자 삽입 이미지
<그림1> GetFactory 메소드 (출처: MSDN Library)


 

사용자 삽입 이미지
<그림2> GetFactory 메소드 사용 예 (출처: MSDN Library)


<그림 1>은 GetFactory 메소드에 대한 소개이며, <그림 2>는 샘플 소스이다. <그림 2>에 나온 것처럼 DataRow 와 String 을 이용하여 Provider Factory 를 알아내게 된다.

이처럼 버전 2.0 에서는 Provider에 대한 부분이 보다 유연성을 갖게 되었다는데 의미를 두고자 한다.



연결풀링(Conncetion Poolling)의 향상


연결풀링(Connection Pooling)이라는 개념은 ADO 때부터 꾸준히 중요한 위치를 차지하고 있다. 연결풀링이 어떤 향상을 가져왔는지에 대해 논하기 전에 연결풀링이 무엇인지 간단히 소개하고자 한다(필자가 현업에서 개발하면서 아쉽게도 연결풀링의 개념을 파악하지 못하는 개발자들을 보았기 때문에 이 기회를 통해 소개하고 싶기 때문이기도 하다.).

연결풀링이란 대체 무엇이길래 중요한 위치를 차지하는가? 일반적으로 우리는 코드 상에 데이터 베이스에 대한 연결을 생성할 때 다음과 같은 구문을 작성하게 된다.

Dim adoCon as new SqlConnection(연결문자열) : adoCon.Open()

이 때 ADO는 하나의 풀(Pool)을 생성하게 된다. 이 풀이 하는 일은 동일한 커넥션의 요청(여기서 동일하다는 의미는 단순히 동일한 DB에 대한 연결이 아닌 동일한 연결 문자열을 통한 요청을 말한다)이 들어왔을 때 새로운 커넥션을 생성하는 것이 아니라 기존에 생성되어 있던 풀을 반환하는 활용할 수 있게 하는 역할을 하게 된다. 이처럼 매번 요청 시마다 커넥션을 생성하는 것보다 작성된 풀을 활용한다는 것만으로 리소스의 활용도는 그만큼 높아지게 되는 것이다. 그리고, Connection이 Close나 혹은 Dispose가 될 때 풀에 다시 반환되게 된다. 만약 풀에 사용 가능한 자원이 없으면 새로운 연결을 생성하여 반환하게 된다. 이것이 연결풀링의 기본 개념이라 할 수 있다.

ADO.NET 에서는 연결풀링에 대한 보다 상세한 설정을 제공하게 된다. 예를 들어, 풀 크기와 연결 소멸 시간의 지정 등에 대한 설정이 가능하도록 향상되었다. 또한, ADO.NET 2.0에서는 ClearAllPools와 ClearPool 이라는 새로운 메소드를 제공하게 되는데, 이 메소드를 통해 특정 혹은 전체의 풀을 지울 수 있게 되었다.

데이터베이스 프로그래밍시 연결 풀링에 대한 이해를 통해 자신의 Product의 Quality를 높이도록 하자.



배치 업데이트의 지원


DataSet을 사용하여 둘 이상의 행을 변경(추가, 삭제, 수정)하게 되는 경우 DataAdapter는 각각의 행에 대한 처리를 하게 된다. 이때 변경하고자 하는 행의 수만큼 DataAdapter는 각 행위를 체크하여 실행하기 때문에 그만큼 라운드트립이 발생하여 성능을 저하시키게 된다. 이때 배치 업데이트를 통해 해당 네트워크의 라운드트립을 감소 시킬 수 있게 되었다. 배치 업데이트를 지정하는 구문은 다음과 같다.

DataAdapter.UpdateBatchSize = Int32

여기서 Size는 0, 1, 혹은 1이상을 지정하게 되는데 0 은 배치 업데이트의 최대를 나타내며 1은 예전과 같이 각각의 행을 처리하는 것과 동일하다. 1 이상인 경우에는 지정된 수만큼을 나타내게 된다.

좀 더 확실한 이해를 돕고자 MSDN에 나오는 배치 업데이트의 샘플 코드를 축약하여 발췌하였다.

사용자 삽입 이미지
<그림 3> 배치 업데이트 샘플 코드(출처: MSDN Library)


샘플코드를 살펴보면 BatchUpdate에 DataTable과 배치 사이즈를 ByVal로 전달하는 것을 확인할 수 있다. Sub 내에는 Using 블록으로 감싸 코드를 작성하였으며 (Using에 대해서는 "VB.NET 2005, 생산성과 성능이 향상되는 일곱가지 기능" 칼럼에 소개하였다) 블록 안에 DataAdapter를 생성 후 하단에 각각 Update, Insert, Delete Command 를 작성하였다. 그 후 DataAdapter의 UpdateBatchSize에 전달된 batchsize 를 지정하여 Update 처리를 하는 것을 알 수 있다. 이처럼 배치 업데이트를 사용하게 되면 그만큼 네트워크의 라운드트립을 감소시킬 수 있게 된다.

필자 심의준님은 MCSD .NET이며 웹젠에서 개발자로 근무 중이다.

 

저자 :[ 심의준(IT 테크라이터) 2005/11/28]

 

 

사용자 삽입 이미지

 

원문 :http://www.zdnet.co.kr/microsite/powerguide/techguide/solveit/0,39033240,39141825,00.htm

 

 

 

  Comments,     Trackbacks
A Simpler Ajax Path

A Simpler Ajax Path

 

내가 웹 응용 프로그램 분야에 일하기 시작했던 때는 매우 불운했던 시절로 돌아간다. 데스크탑 응용 프로그램처럼 동작하는 응용 프로그램을 만든다는 것은 프레임셋안에 프레임셋이 들어가고, 그 안에 다시 프레임셋이 들어간다거나 대여섯단계 이상 중첩시킨 테이블을 이용한 미궁처럼 뒤얽힌 레이아웃과 씨름하는 것을 의미했다.

다행히도 표준을 준수하는 브라우저, CSS, DHTML, DOM의 출현과 함께 웹 개발자들의 상황은 꾸준히 나아지고 있다. 광범위한 브로드밴드 액세스는 웹 응용 프로그램을 보다 빠르게 만들어주었다. 브라우저에 배포할 수 있는 보다 다양한 기능과 보다 강력한 상호운영성을 보다 쉽게 이끌어 낼 수 있는 XMLHttpRequest 객체가 등장했다.

XMLHttpRequest 객체는 새로운 것이 아니지만 최근에 웹 응용 프로그램 개발에 대한 새로운 접근방법의 핵심으로 부각되고 있다. 최근에 가장 많이 인용되고 있는Ajax(비동기 자바스크립트와 XML)는플리커(Flickr), 아마존의A9.com, 웹 기반 인터액티비티(interactivity)의 떠오르는 별인Google MapsGoogle Suggest같은 사이트에서 기능을 십분 활용하고 있다. 멋진 Ajax 사용자들은 어떤 원동력을 갖고 있는 것처럼 보인다. - 웹로그Ajaxian, 오라일리 미디어와 Adaptive Path가 공동으로 주관한Ajax Summit을 포함해서 Ajax는 모든 장소에서 등장하고 있다.

멋진 약어이든 아니든간에, 나의 웹캐스트 라디오 방송국EpiphanyRadio에 재생목록 검색 기능을 추가하려고 결정했을 때, XMLHttpRequest 객체가 제공하는 기능들을 보여줄 수 있는 좋은 기회라고 생각했다.

아니나 다를까, 데스크탑 응용 프로그램 처럼 동작하는 웹 응용 프로그램을 만들기 위해 XMLHttpRequest 객체를 이용하는 것은 너무나 쉬웠다. 물론, 사용자 입력을 위해 웹 폼과 같은 도구들도 그대로 사용할 수 있다. 또한, 골치아픈 디버깅을 줄이기 위해 서버측 에러를 처리할 수 있는 방법도 찾아낼 수 있었다.

XMLHttpRequest 객체 개요

XMLHttpRequest를 사용하면 iframe 트릭을 사용하거나 페이지를 리로드하지 않고 자바스크립트를 사용해서 서버에 HTTP 요청(GET과 POST)을 보낼 수 있다. 마이크로소프트는 인터넷 익스플로러 버전 5 부터 ActiveX 객체 형태로 XMLHttpRequest 객체를 구현했으며, 모질라 프로젝트는 모질라 1.0에, 애플은 사파리 1.2에 이를 추가했다.

이름이 의미하는 것과 달리 XMLHttpRequest 객체는 XML 이상의 기능을 수행한다. XMLHttpRequest를 사용해서 어떤 종류의 데이터든 처리할 수 있다. 염두해둘것은 서버로부터의 응답을 자바스크립트가 처리한다는 것이다. 예제에서는 브라우저에 DSV(delimiter-separated values, 구분자로 값을 분리한 형식) 형식으로 데이터를 반환한다.


POST로 폼데이터 보내기

XMLHttpRequest 객체를 다루는다른 기사에서는 GET 요청을 어떻게 사용하는지 설명하고 있다. XMLHttpRequest 객체는 POST 요청을 사용할 수 있으며, 웹 응용 프로그램을 위한 보다 유용한 도구로 만들어준다.

POST 메서드를 사용하려면 데이터를 XMLHttpRequest 객체에 쿼리 스트링형식(예, ArtistName=Kolida&SongName=Wishes)으로 전달하고, 객체가 서버에 보통의 POST 형식으로 전송한다. 웹폼 요소로부터 한번에 데이터를 가져오고, 쿼리 스트링 형식으로 형식화하기 위해 자바스크립트를 사용한다. 나의 재생목록 검색 함수를 위해 이 같은 작업을 한다면 다음과 같은 코드를 사용할 것이다.

var searchForm = document.forms['searchForm'];
var artistName = searchForm.ArtistName.value;
var songName = searchForm.SongName.value;
var queryString = '?ArtistName=' + escape(artistName) + '&SongName=' + escape(songName);

주의: 값에 URL 인코딩을 위해 escape를 사용해야한다.

Larry Wall의프로그래머의 위대한 세가지 미덕을 염두에 두면서 폼에 있는 모든 데이터를 쿼리 스트링으로 바꿔주는 프로세스를 자동화하는 일반 함수를 작성했다. 이 함수를 사용하면 매번 번거로운 작업들을 하지 않고 XMLHttpRequest 객체에 폼 데이터를 POST할 수 있다. 이 같은 방법으로 기존 응용 프로그램 코드에 XMLHttpRequest 객체 사용을 보다 쉽게 통합할 수 있다.
함수의 첫부분을 살펴보자.

function formData2QueryString(docForm) {

        var strSubmit       = '';
        var formElem;
        var strLastElemName = '';
        
        for (i = 0; i < docForm.elements.length; i++) {
                formElem = docForm.elements[i];
                switch (formElem.type) {
                        // Text, select, hidden, password, textarea elements
                        case 'text':
                        case 'select-one':
                        case 'hidden':
                        case 'password':
                        case 'textarea':
                                strSubmit += formElem.name +
                                '=' + escape(formElem.value) + '&'
                        break;

변수 docForm은 폼에 대한 참조이며, 데이터를 가져오기 위해 사용한다. 이런 방식은 다양한 장소에서 함수를 재사용할 수 있게 해준다.
이 함수는 폼의 elements 컬렉션을 반복하면서 각 element의 type을 사용해서 어떻게 값을 가져올지를 결정한다. 각 요소들에 대해서 쿼리 스트링 변수 strSubmit에 이름과 값을 저장한다. 그 다음에 POST를 위해 XMLHttpRequest 객체에 이 문자열을 전달한다.

폼 요소에 쓰이는 대부분의 타입들은 value 속성을 사용해서 값을 가져올 수 있지만 라디오 버튼과 체크 박스는 다른 작업을 해야한다. 체크 박스의 경우에 콤마(,)로 값을 구분하는 문자열을 만들었지만, 필요하다면 원하는 형태로 문자열을 처리할 수 있다. 이 함수를 사용하면 XMLHttpRequest 객체를 사용하는 것과 폼에서 사용자 데이터를 가져오는 데 있어 많은 시간을 절약할 수 있다.

전체 함수는다운로드할 수 있다.


객체 생성하기

자바스크립트로 IE에서 객체를 생성하려면 new ActiveXObject( "Microsoft.XMLHTTP")를 사용하며, 모질라/파이어폭스/사파리에서는 new XMLHttpRequest()를 사용한다. 함수의 처음 절반은 객체를 생성하고 사용하는 부분이다.

function xmlhttpPost(strURL, strSubmit, strResultFunc) {

        var xmlHttpReq = false;
        
        // Mozilla/Safari
        if (window.XMLHttpRequest) {
                xmlHttpReq = new XMLHttpRequest();
                xmlHttpReq.overrideMimeType('text/xml');
        }
        // IE
        else if (window.ActiveXObject) {
                xmlHttpReq = new ActiveXObject("Microsoft.XMLHTTP");
        }


이 함수를 재사용할 수 있는 일반 함수로 만들기 위해 세 개의 매개변수를 사용한다. 서버에서 처리중인 페이지에 대한 URL, 데이터를 전송하기 위해 쿼리 스트링 형식으로 저장된 데이터, 서버로부터의 응답을 처리하기 위한 자바스크립트 함수의 이름(나중에 eval을 사용해서 호출된다)을 매개변수로 사용한다.

모질라/사파리 코드에서overrideMimeType메서드를 호출하는 것을 볼 수 있다. 이 부분이 없으면 서버에서 XML아 아닌 것을 반환할 때 특정 버전의 모질라가 멈춰버리는 것을 일부 사람들이 경험했다고 한다.(개인적으로는 이 문제가 발생하지 않았기 때문에 이 문제를 확인할 수는 없다)

만약, 보다 낡은 버전의 브라우저들을 지원하려 한다면 xmlHttpReq 변수를 테스트하고, 객체가 존재하지 않으면 전송하려는 데이터를 다른 메서드에 전달하면 된다.

데이터를 POST하기

함수의 나머지 부분은 서버에 요청을 전송하는 부분이다.

     xmlHttpReq.open('POST', strURL, true);
        xmlHttpReq.setRequestHeader('Content-Type',
                'application/x-www-form-urlencoded');
        xmlHttpReq.onreadystatechange = function() {
                if (xmlHttpReq.readyState == 4) {
                        eval(strResultFunc + '(xmlHttpReq.responseText;);');
                }
        }
        xmlHttpReq.send(strSubmit);
}

open 메서드는 매개변수를 세개 사용한다. 첫번째는 요청 방법을 지정하고, 두번째는 처리중인 페이지이며, 세번째는 async 플래그를 지정한다. 이 플래그는 요청을 보낸후에 즉시 실행을 계속할 것인지 또는 응답을 받은 후에 계속 실행할 것인지를 결정한다.
참고: HTTP 1.1 스펙에 따르면, 요청 메서드는 대소문자를 구분한다. 요청 메서드를 소문자로 입력한 경우에 인터넷 익스플로러를 사용할 때는 문제가 되지 않지만 모질라에서는 요청이 실패한다.

onreadystatechange 속성은 readyState 속성이 바뀔 때 실행할 콜백 함수를 지정한다.(예를 들어, xmlHttpReq.onreadystatechange = handleResponse; ) readyState 값이 4로 변경될 때 요청이 완료된다. 위 코드는 결과를 전달할 별도의 함수를 사용하는 대신에 익명 함수를 사용하여 응답이 돌아오고, 결과값을 처리할 함수에 문자열로 전달할 때까지 기다린다.

마지막으로 send 메서드가 실제 요청을 전송한다. 서버에 전송할 데이터를 매개변수로 사용한다. 이 함수에서는 서버에 전송할 데이터는 앞에서 formData2QueryString 함수를 사용해서 폼 데이터에서 생성한 쿼리 스트링이다.

서버 응답

앞에서 언급한 것처럼 XMLHttpRequest 객체는 이름이 의미하는 것과는 달리 XML이 아닌 다른 형식의 데이터를 이용할 수 있다. 내 인터넷 라디오 방송국을 위한 검색 함수는 간단한 테이블 형식으로 트랙목록을 반환하기 때문에 다른 데이터 형식을 사용할 수 있다는 점이 마음에 든다. XML 형식 대신에 DSV 형식으로 결과를 반환하는 것은 반환데이터의 크기와 복잡도를 획기적으로 줄여줄 뿐만 아니라 데이터를 해석하는 것도 단순하게 해준다.(에릭 레이몬드(Eric S. Raymond)가 The Art of Unix Programming의 Data File Metaformats 챕터에서 얘기한 것처럼 "XML은 복잡한 데이터 형식에 잘 어울리지만... 그럼에도 불구하고 단순한 용도로는 지나치게 복잡하다) 구분자로 무엇이든 사용할 수 있지만 여기서는 파이프(|) 문자를 사용했다.

재생목록 검색 기능을 위한 백엔드 코드로는 대부분의 사이트와 마찬가지로 mod_ruby로 운영중인 Ruby를 사용했다. 루비는 PHP나 Perl과 같이 개발자들에게 대중적이지 않지만 루비의 유연성, 확장성, 깔끔한 구문은 이상적인 웹 개발 플랫폼이 될 수 있다.

nRowCount    = sth.size
strContent += nRowCount.to_s + 10.chr + 10.chr
sth.each do |row|
        strContent += row['artist'] + '|' + row['song'] + '|' +
                row['album'] + '|' + row['comment'] + 10.chr
end

이 예제에서 sth는 Ruby DBI 모듈에서 수행되는 데이터베이스 쿼리 결과를 갖고 있는 배열이다. sth.each do |row|는 루비 개발자가 아닌 사람들에게는 낯설어 보이지만, 루비가 제공하는 가장 강력한 기능중에 하나인iterator/block조합을 사용한 것이다. 여기서는 독자가 추측한 것처럼 다른 언어의 foreach와 상당히 비숫하다.

10.chr는 라인피드 문자다. 이 코드는 로우 카운트 다음에 라인피드 문자를 2개 출력하고, 각 로우에 대해 파이프(|) 문자로 필드를 구분한 문자열을 작성한다. 예제 검색 결과는 다음과 같다.

4

Kush|New Life With Electricity|The Temptation Sessions||
Kush|Plaster Paris (Part Two)|The Temptation Sessions||
Kush|Reverse (Part One)|The Temptation Sessions||
Kush|The Beauty of Machines at Work|The Temptation Sessions||

마지막에 파이프(|) 문자 2개는 comment 컬럼에 대한 빈필드를 가리킨다.

응답 처리하기

서버에서 응답이 돌아올 때 XMLHttpRequest 객체는 responseXML(XML 문서 형태)와 responseText(문자열) 속성을 사용해서 액세스할 수 있다. 여기서는 XML의 복잡한 부분은 생략했기 때문에, 코드는 원래 함수로부터 해당 라인과 함께 반환된 데이터를 처리하고 표시하기 위한 자바스크립트에서 responseText를 전달한다.

eval(strResultFunc + '(xmlHttpReq.responseText;);');

xmlhttpPost 함수에서 전달된 함수 이름은 eval을 사용해서 실행하고, XMLHttpRequest 객체의 매개변수로 responseText를 전달한다.
코드에서 문자열을 배열로 자른후에, 테이블 형태로 보여주기 위해다양한 방법들을 사용할 수 있다. DOM의 테이블 조작 방법에 대한 대단한 팬이 아닌한 innterHTML을 사용하는 보다 쉬운 접근방법을 택했다.(DOM은 XML과 마찬가지로 내 취향에는 지나치게 장황하다) 재생목록 검색 결과를 처리하기 위해 사용한 자바스크립트는 다음과 같다.

function displayResult(strIn) {

        var strContent = '<table>';
        var strPrompt = '';
        var nRowCount = 0;
        var strResponseArray;
        var strContentArray;
        var objTrack;
        
        // Split row count / main results
        strResponseArray = strIn.split('\n\n');
        
        // Get row count, set prompt text
        nRowCount = strResponseArray[0];
        strPrompt = nRowCount + ' row(s) returned.';
        
        // Actual records are in second array item --
        // Split them into the array of DB rows
        strContentArray = strResponseArray[1].split('\n');
        
        // Create table rows
        for (var i = 0; i < strContentArray.length-1; i++) {
                // Create track object for each row
                objTrack = new trackListing(strContentArray[i]);
                // ----------
                // Add code here to create rows --
                // with objTrack.arist, objTrack.title, etc.
                // ----------
        }
        
        strContent += '</table>';
        // ----------
        // Use innerHTML to display the prompt with rowcount and results
        // ----------
}

서버에 있는 루비 코드는 라인피드 문자 2개를 사용해서 실제 데이터가 있는 로우와 로우 카운트를 분리시켰다. 따라서, 이 함수는 전체 결과를 라인피드 문자 2개로 자른 다음에 배열로 사용했다.

배열에서 실제 데이터 로우는 두번째 항목에 있다. 데이터 로우는 로우를 구분하는 라인피드를 1개씩 갖고 있기 때문에 각 항목에서 라인피드 문자 1개를 자르는 것은 페이지에 작성할 배열 데이터를 만드는 것이다. 테이블 내용을 생성하기 위해 코드는 이 배열을 반복하면서 각 로우에 대해 trackListring 객체를 생성하고, HTML 테이블 로우를 만들기 위해 객체를 사용한다. trackListring 함수는 trackListring 객체들을 생성한다.

function trackListing(strEntry) {
        var strEntryArray = strEntry.split('|');
        this.artist       = strEntryArray[0];
        this.title        = strEntryArray[1];
        this.album        = strEntryArray[2];
        this.label        = strEntryArray[3];
}

각 로우에서 파이프로 구분된 문자열을 잘라내고, 각 오트젝트에 대해 데이터베이스의 컬럼 이름에 해당하는 속성을 설정한다. 이 과정을 생략하고 각 컬럼에 대해 이름 대신 숫자를 사용할 수 있지만, 이름을 사용하는 것이 참조하기 보다 쉬운 방법일 것이다.

에러 처리하기

XMLHttpRequest 객체는 굉장히 좋은 장점을 갖고 있다. XMLHttpRequest 객체를 사용하면 자바스크립트에서 브라우저의 페이지를 로딩하지 않고 서버와 직접 커뮤니케이션할 수 있다. 그러나, 이런 장점이 단점이 될 수도 있다. 브라우저 윈도우에 직접 에러를 반환하는 언어를 사용해서 작업하고 있다면, XMLHttpRequest 객체를 사용해서 페이지를 디버깅하는 것이 잘못된 것처럼 느껴질 수 있다. 서버 에러 로그에 쉽게 접근할 수 없는 환경에서 작업한다면 더욱 그럴 것이다.

XMLHttpRequest 객체는 서버에서 반환하는 숫자 코드 값(예, 404, 500, 200)을 갖는 status 속성을 갖고 있다. 또한, 간단한 문자열을 전달하는 statusText 속성도 있다. 서버측 오류(코드 500)가 발생한 경우 메시지는 단순히 "내부 서버 오류(Internal Server Error)"를 갖고 있으며, 사용자에게 보여주기엔 괜찮을지 몰라도 디버깅에 사용하기엔 의미가 없다.

서버에서 반환하는 500 에러 페이지는 에러 종류, 에러가 발생한 라인 번호, 에러에 대한 전체 추적정보와 같은 유용한 디버그 정보들이 포함된다. 불행히도, XMLHttpRequest 객체에서는 이런 내용들이 자바스크립트 문자열 변수 하나에 파묻혀버린다.

500 에러 메시지의 전체 페이지를 가져오고 보다 우아하게 디버깅을 수행하는 것은 간단하다. 이를 위해, XMLHttpRequest를 생성하고 이용하는 이전 함수에 다음 코드를 추가한다.

if (xmlHttpReq.readyState == 4) {
           strResponse = xmlHttpReq.responseText;
           switch (xmlHttpReq.status) {
                   // Page-not-found error
                   case 404:
                           alert('Error: Not Found. The requested URL ' +
                                   strURL + ' could not be found.');
                           break;
                   // Display results in a full window for server-side errors
                   case 500:
                           handleErrFullPage(strResponse);
                           break;
                   default:
                           // Call JS alert for custom error or debug messages
                           if (strResponse.indexOf('Error:') > -1 ||
                                   strResponse.indexOf('Debug:') > -1) {
                                   alert(strResponse);
                           }
                           // Call the desired result function
                           else {
                                   eval(strResultFunc + '(strResponse);');
                           }
                           break;
           }
   }

case 구문은 xmlHttpReq.status 값에 따라 서버로부터의 응답을 다르게 처리한다. 오류가 발생한 경우에는 응답을 오류 처리 함수에 전달하지만, 사용자에게 간단한 에러 메시지를 보여주거나 개발자에게 간단한 디버그 메시지를 출력하기 위해 자바스크립트의 alert를 사용할 수도 있다.( 물론, 이러한 에러들을 div에 멋지게 만든 텍스트로 보여줄 수도 있다)

다음은 500 에러 페이지를 생성하는 함수다.

function handleErrFullPage(strIn) {

        var errorWin;

        // Create new window and display error
        try {
                errorWin = window.open('', 'errorWin');
                errorWin.document.body.innerHTML = strIn;
        }
        // If pop-up gets blocked, inform user
        catch(e) {
                alert('An error occurred, but the error message cannot be' +
                        ' displayed because of your browser\'s pop-up blocker.\n' +
                        'Please allow pop-ups from this Web site.');
        }
}

팝업 차단기가 보편적이기 때문에 try/catch는 중요하다. 사용자가 팝업을 차단하고 있다면, 사용자가 에러를 보고 적절하게 알려줄 수 있게 하기 위한 옵션을 제공해야 한다.

사용자가 팝업을 허용하고 있다면, 서버측 500 오류는 버그를 추적하고 제거하는데 유용한 온갖 종류의 정보를 보여주는 새 창을 보게될 것이다.(현재 창에 에러 메시지를 출력하도록 할수도 있지만, 나의 재생목록 검색은 작은 팝업창이기 때문에 전체 메시지를 제대로 보여줄 수 없다. 대부분의 표준 500 에러 페이지는 전체화면 크기를 요구한다)


참고

XMLHttpRequest 객체는 브라우저에 대한 일반 요청처럼 요청과 함께 쿠키를 전송하기 때문에 서버측 세션 작업을 위해 특별한 작업을 하지 않아도 된다.

다양한 요청을 위해 동일한 객체를 사용할 행운이 별로 없었기 때문에 각 요청에 대해 새로운 XMLHttpRequest 객체를 사용한다. 각 요청에 대해 새로운 객체를 생성하는 것이 복수 요청, 비동기 요청을 수행할 때 문제를 일으키지 않을 것이다.

(역주: 하나의 객체를 공유하는 것은 얘기치 않은 병목현상을 일으킬 수 있다)

XMLHttpRequest 객체로 만든 요청은 브라우저 히스토리에 영향을 주지 않는다. 사용자가 브라우저의 "뒤로가기" 버튼을 클릭했을 때 이전 상태로 돌아가는 변화가 일어나지 않기 때문에 사용자가 혼란스러워할 수 있다. 사용자 액션에 해당하는 히스토리 단계가 필요하다면 HTTP 요청을 만들기 위해 iframe을 사용하는 것을 권한다. iframe을 사용하여 HTTP 요청을 하는 것은 각 요청에 대해 히스토리 항목을 생성한다.

결론 및 앞으로의 계획

XMLHttpRequest 객체는 웹 개발자가 보다 응답성있고, 동적인 웹 응용 프로그램을 만드는데 도움을 주는 다양한 기술을 제공하며, 데스크탑 응용 프로그램처럼 수행하게 해준다. 객체를 다루기 위한 formData2QueryString, handleErrFullPage 함수와 같은 몇가지 사전작업만 있으면, 여러분의 개발 프로세스를 크게 변경하지 않고도 AJAX 액션을 이용할 수 있다.

물론, AJAX를 시작했다면 각자의 응용 프로그램에서 AJAX가 가장 적합한 부분을 찾아보는 것이다. 내 경우엔 이미 EpiphanyRadio에서 이전에 재생한 곡 기능에 AJAX를 활용하고 있다. SHOUTcase 서버에 주기적으로Song History페이지를 갱신하는 XMLHttpRequest 객체를 가질 수 있다. HTML 페이지 응답에서 곡 목록을 자바스크립트로 가져오고, div에 DHTML로 목록을 작성한다. 이전에 재생된 곡 목록은 브라우저에서 페이지를 재로딩하지 않고 계속해서 업데이트된다.

나는 로그인 페이지에서 완전히 다른 페이지로 재전송하는 대신 원래 로그인 화면에 멋지게 만든 로그인 에러 메시지를 보여주기 위해 AJAX를 청취자 로그인 페이지에도 사용한다. SHOUTcast 사이트메인페이지를 폴링해서 현재 청취자 숫자를 지속적으로 갱신하고, 똑똑한 정규식을 사용하여 응답에서 숫자들을 가져올 수 있다.

참고자료

저자 : Matthew Eernisse

번역 : 한동훈
원문 :A Simpler Ajax Path(http://www.onlamp.com/pub/a/onlamp/2005/05/19/xmlhttprequest.html)

 

사용자 삽입 이미지

 

출처 :http://network.hanbitbook.co.kr/view.php?bi_id=1088

  Comments,     Trackbacks
Web 2.0이란 무엇인가(3)

Web 2.0이란 무엇인가 : 다음 세대 소프트웨어를 위한 디자인 패턴 및 비즈니스 모델(3)

 

연재 순서
1.
Web 2.0이란 무엇인가 : 다음 세대 소프트웨어를 위한 디자인 패턴 및 비즈니스 모델(1)

2.Web 2.0이란 무엇인가 : 다음 세대 소프트웨어를 위한 디자인 패턴 및 비즈니스 모델(2)

3.Web 2.0이란 무엇인가 : 다음 세대 소프트웨어를 위한 디자인 패턴 및 비즈니스 모델(3 - 완결)

 

사용자 삽입 이미지

5. 가벼운(Lightweight) 프로그래밍 모델

웹 서비스 아이디어가 오 쿠랑(au courant:최신 기술)이었을 때, 많은 회사들이 분산 응용 프로그램에서 높은 신뢰성을 보장하는 프로그래밍 환경을 만들기 위해 복잡한 웹 서비스 스택에 뛰어들었다.

그러나, 웹이 확실하게 성공할 수 있었던 이유중에 많은 부분은 하이퍼텍스트 이론의 많은 부분을 벗어던지고, 이상적인 디자인을 단순한 실용주의로 대체했기 때문이다. 업체들의 복잡한 웹 서비스 스택들은 아직도 널리 퍼지지 못하고 있는 것과 달리 RSS는 그 자체의 단순성 때문에 가장 널리 배포된 단일 웹 서비스가 되었다.

비슷하게 아마존의 웹 서비스는 두 가지 형태로 제공된다. 한 가지는 SOAP(Simple Object Access Protocol) 웹 서비스 스택의 형식주의를 고수하는 형태이며, 다른 하나는 HTTP 위에 XML 데이터를 제공하는 단순한 형태이다. 이와 같은 단순한 접근 방법을 REST(Representational State Transfer)라고 한다. 아마존과 ToysRUs 같은 소매 파트너간의 고가치(High value) B2B 연결에서는 SOAP 스택을 사용하고 있지만, 아마존에 따르면 전체 사용량의 95%는 단순한 REST 서비스가 차지한다고 한다.

단순성(simplicity)에 대한 탐험은 다른 "유기적인" 웹 서비스에도 나타난다. 구글맵(Google Maps)에 대한 구글의 발표가 적절한 예이다. 구글맵의 단순한 AJAX(Javascript and XML) 인터페이스는 해커들에 의해 빠르게 해독되었고, 이는 데이터를 새로운 서비스와의 혼합을 시도했다.

지도 관련 웹 서비스는 ESRI 같은 GSI 벤더나 맵퀘스트(MapQuest), 마이크로소프트 맵포인트 등으로부터 이용할 수 있다. 그러나 구글 맵스는 그 단순성 때문에 세상을 깜짝 놀라게 했다. 웹 서비스를 지원하는 벤더들과의 실험은 참여자들간의 계약이 필요하지만, 구글맵이 구현한 방식은 데이터를 가져갈 수 있게 했으며, 해커들은 그 데이터를 창의적으로 재사용할 수 있는 방법을 발견하였다.

이로 알 수 있는 몇 가지 중요한 교훈이 있다.

  1. 느슨하게 결합된(loosely coupled) 시스템을 위한 가벼운 프로그래밍 모델을 지원하라. 업체가 지원하는 웹 서비스 스택의 복잡성은 밀결합(tight coupling)을 위해 고안된 것이다. 많은 경우에 밀결합이 필요하지만, 가장 흥미있는 응용 프로그램들은 실제로 느슨하게 결합되어있으며, 심지어 깨지기도 쉽다. 웹 2.0 사고방식(mindset)은 전통적인 IT 사고방식과는 완전히 다르다.(역주: mindset은 경험, 교육, 고정 관념 등으로 형성된 사고 방식을 의미한다)

  2. 조정(coordination) 보다는 신디케이션(Syndication: 배급, 전달)을 생각하라. RSS나 REST 기반 웹 서비스와 같은 단순한 웹 서비스는 연결의 반대편에서 무슨 일이 일어나는지 통제하는 것이 아니라 데이터를 외부로 전달하는 것에 대한 것이다.end-to-end principle로 알려진 이 아이디어는 인터넷 그 자체의 근원이다.

  3. 개조성(hackability)와 재조합 가능(remixability) 하도록 설계하라. 오리지널 웹, RSS, AJAX 같은 시스템은 모두 "재사용에 대해 극단적으로 낮은 장벽"을 공통되게 갖고 있다. 실제로, 유용한 소프트웨어의 상당수는 오픈 소스이며, 만약, 이들이 오픈소스가 아니라면 지적 재산 보호 때문에 아무것도 할 수 없을 것이다. 웹 브라우저의 "소스 보기" 옵션은 사용자가 다른 사용자의 웹 페이지를 카피할 수 있게 했으며, RSS는 정보 제공자(IP)가 아닌 사용자가 원할 때 컨텐트를 볼 수 있는 힘을 부여하기 위해 고안되었다. 가장 성공적인 웹 서비스는 제작자가 상상하지 못했던 방향으로 이용하기 가장 쉬웠던 것들이었다. 전형적인 "모든 권리의 인정(all rights reserved)"와 달리 Creative Commons가 널리 보급한 "일부 권리의 인정(some rights reserved)" 문구는 유용한 이정표가 될 것이다.
    역주: "모든 권리의 인정(all rights reserved)", "일부 권리의 인정(some rights reserved)" 등은 모두Creative Commons Korea의 용례를 따른 것이다.

어셈블리에서의 혁신(Innovation in Assembly)

가벼운 비즈니스 모델에는 가벼운 프로그래밍과 가벼운 연결이 따르기 마련이다. 웹 2.0 사고방식은 재사용에 있다. housingmaps.com과 같은 새로운 서비스는 기존의 두 서비스를 함께 가져오는 것으로 만들어졌다. Housingmaps.com은 아직까지 비즈니스 모델이 없지만, 다른 소규모 서비스들처럼 구글 애드센스(또는 아마존 광고 제휴)처럼 그에 상응하는 수익 모델을 제공할 것이다.

이러한 예들은 우리가 "어셈블리에서의 혁신(innovation in assembly)"라 부르는 웹 2.0 핵심 원친에 대한 통찰을 제공한다. 유용한 컴포넌트들은 풍부하기 때문에 이들 컴포넌트를 기발한 방법 또는 효율적인 방법으로 결합하는 것으로 가치를 창출할 수 있다. PC 혁명이 하드웨어 결합의 혁신을 위한 많은 기회를 제공했었다. 결합에서 과학을 만들어내는 델(Dell)과 같은 회사들은 제품 개발에서 혁신이 필요한 비즈니스 모델을 가진 회사들을 물리칠 수 있었다. 마찬가지로 우리는 웹 2.0이 다른 사람들이 제공하는 서비스를 이용하고, 통합하는 것을 보다 잘 하는 것으로 경쟁자를 물리치는 회사에 기회가 있다고 믿는다.


 

웹 2.0 투자 이론

벤쳐 캐피탈리스트 폴 케드로스키(Paul Kedrosky)는"핵심은 합의(consensus)에 동의하지 않는 소송을 제기할 수 있는 투자자를 발견하는 것이다"라고 썼다.

각 웹 2.0의 면이 합의에 동의하지 않는 것과 어떻게 연관되는지 살펴보는 것도 흥미로운 일이다. 모든 사람은 데이터를 사적으로 보관하는 것을 강조하지만 플리커/냅스터 등은 데이터를 공개했다. 이는 단순히 동의할 수 없는 것에 동의하지 않은 것이 아니다. 견해차이로부터 어떤 것을 구축할 수 있는 것에 대한 비동의인 것이다. 플리커는 커뮤니티를 구축했으며, 냅스터는 컬렉션의 폭을 구축했다.

이를 바라보는 또다른 방법은 성공적인 회사들이 값비싼 것들을 포기할 뿐만 아니라 한때 값비싼 것들을 무료로 가질 수 있게 한 것에 비판적이었음을 생각해보는 것이다. 예를 들어, 위키피디어는 신속성과 폭넓은 범위를 위해 편집에 대한 제어권을 포기했다. 냅스터는 업체가 판매하는 모든 노래를 담은 "카탈로그"라는 개념을 포기했고, 폭넓은 범위(breadth)를 얻었다. 아마존은 물리적인 상점을 가져야한다는 생각을 포기하자 전세계에 책을 판매할 수 있었다. 구글은 큰 소비자들을 포기하자 수요가 맞지 않는 80%의 소비자를 얻었다. 이는 마치 적의 힘을 적에게 사용하는 합기도(aikido)와 매우 유사하다. "네가 알고, 네가 맞다 - 전 세계에 있는 누구나 이 글을 업데이트할 수 있다. 그리고 무엇을 추측하면 그것이 당신에게 나쁜 소식인 것이다"

--Nat Torkington


 

6. 단일 디바이스를 넘어선 소프트웨어

웹 2.0의 또 다른 특징은 PC 플랫폼에만 국한되지 않는다는 것이다. 마이크로소프트에서 오랜 기간 일했던 데이브 스투츠(Dave Stutz)는 마이크로소프트를 떠나는 고별사에서 "단일 디바이스를 넘어선 유용한 소프트웨어가 오랜기간 높은 이윤을 남기게 될 것이다"라고 지적했다.

물론, 모든 웹 응용 프로그램은 단일 디바이스를 넘어선 소프트웨어로 바라볼 수 있다. 결국, 가장 단순한 웹 응용 프로그램이라 해도 웹 서버를 담당할 컴퓨터와 브라우저를 담당할 컴퓨터 두 대가 최소한 필요하다. 앞에서 이야기한 것처럼 플랫폼으로서의 웹 개발은 많은 컴퓨터에서 제공하는 서비스들로 구성된 통합 응용 프로그램이라는 아이디어로 확장된다.

웹 2.0의 많은 영역들이 그런 것처럼 "2.0 다움(2.0-ness)"에는 새로운 것은 없으나 웹 플랫폼의 실제 가능성을 더 현실화시키고 있다는 점에서 새로운 플랫폼에서 응용 프로그램이나 서비스를 설계하는 데 핵심적인 통찰력을 제공한다.

현재까지 아이튠즈(iTunes)는 이런 원칙의 가장 좋은 예이다. 아이튠즈는 핸드헬드 디바이스에서 웹 서버 응용프로그램(web back-end)를 비롯해서 로컬 캐시와 컨트롤 스테이션으로 동작하는 PC까지 빈틈없이 지원한다. 웹 컨텐트를 휴대용 기기로 옮기려는 시도는 이전에도 많았지만 아이팟(iPod)/아이튠즈 조합은 처음부터 다양한 디바이스로 확장하기 위해 고안된 최초의 응용 프로그램이며,[11]티보(TiVo) 역시 좋은 예다.

([11]역주: 티보는 비디오 테이프 대신에 하드 디스크를 이용해 프로그램을 녹화할 수 있으며, 각 방송사의 프로그램 정보를 제공하는 대가를 지불하는 독특한 비즈니스 방식을 갖고 있다. PVR(Personal Video Recorder) 시장을 열었다는 평가를 받고 있으며, 초기 부족한 용량, 기능등은 해커들에 의해 기능이 확장되었다. "구글로 검색하다"를 Google it이라 하듯이 "TV 프로그램을 녹화하다"의 Tivo it이라는 신조어까지 생겼다.)

([12]역주: 응용 프로그램은 프런트엔드와 백엔드로 나뉜다. 사용자에게 보이는 부분 즉, 눈에 보이는 부분을 통틀어 프런트엔드라 하며, 눈에 보이지 않는 부분을 백엔드라 한다.)

아이튠즈와 티보는 웹 2.0의 핵심 원칙의 많은 부분을 보여준다. 아이튠즈나 티보는 웹 응용프로그램은 아니지만 서비스 구조의 보이지 않은 부분을 빈틈없이 결합하여 웹 플랫폼의 힘을 이용하고 있다. 데이터 관리는 이들이 제공하는 가장 중요한 부분이다. 아이튠즈의 경우 사용자의 로컬 데이터를 관리하는 용도로만 패키지된 응용 프로그램을 사용하지만 이들은 패키지 응용 프로그램이 아닌 서비스이다. 더욱이 티보와 아이튠즈의 실험이 지적 재산권을 옹호하는 사람들과 전쟁을 벌이고 있지만 모두 집단 지능을 사용하는 것을 보여준다. 아이튠즈는 참여를 제한하는 구조로 되어있지만팟캐스팅이 추가되어 충분히 동등한 구조를 보여주고 있다.
보다 많은 디바이스들이 새로운 플랫폼에 연결됨에 따라 디바이스를 넘어선 소프트웨어는 웹 2.0에서 가장 위대한 변화로 기대되는 분야이다. 전화기나 자동차가 데이터를 소비하지 않고 보고하게 되면 어떤 응용프로그램이 가능할까? 실시간 교통 정보,[13]플래쉬 몹(flash mobs), 시민 저널리즘 등은 새 플랫폼의 다양한 가능성에 대한 초기 징후에 불과하다.

([13]역주: 플래쉬 몹(flash mobs)은 2002년 10월 출간된 하워드 라인골드의 "참여군중(Smart Mobs)"이 모태로 알려져있으며, 2003년 5월 미국 뉴욕의 맨하탄 한 호텔에 모여 15초 동안 요란한 박수를 치다 사라지는 것으로 시작된 행위와 같이 인터넷을 통해 온라인상으로 만난 사람들이 특정 시간과 장소에 모여 특정행동을 하고 사라지는 집단 해프닝을 말한다.

참고:Flash Mob 번개 떼,Wikipedia)



7. 풍부한 사용자 경험(Rich User Experiences)

페이 웨이(Pei Wei)가 1992년비올라 브라우저를 선보인 이래 웹 브라우저 내에 애플릿을 비롯한 다양한 컨텐트를 제공하기 위해 웹을 사용했다. 1995년 소개된 자바는 애플릿을 위한 기틀을 마련했다. 자바스크립트와 DHTML은 클라이언트 측에서의 프로그래밍과 보다 풍부한 사용자 경험을 제공하기 위한 단순한 방법(lightweight ways)로 소개되었다. 수년 후, 매크로미디어는 멀티미디어 컨텐트 뿐만 아니라 GUI 스타일의 응용프로그램을 제공할 수 있는 플래시(Flash)의 기능을 강조하기 위해 - 오픈 소스 플래시 개발사인 Laszlo Systems 역시 차용한바 있는 - "RIA(Rich Internet Application)"이라는 용어를 만들었다.

그러나, 완전한 기능을 가진 응용 프로그램을 제공할 수 있는 웹의 가능성은 구글이 열었다. 구글이 지메일, 구글맵과 같이 풍부한 사용자 인터페이스와 PC 수준의 인터페이스를 가진 웹 기반 응용 프로그램을 연이어 선보였다. 구글이 선보인 이러한 기술들을 웹 디자인 회사 Adaptive Path의 Jesse James Garrett은 에세이에서AJAX라 명명하고 다음과 같이 얘기했다.

"AJAX(에이잭스)는 기술이 아니다. AJAX는 실제로 여러가지 기술이 포함되어 있으며, 각 기술 자체로도 훌륭하지만, 함께하면서 더 강력한 새로운 길을 열었다.

AJAX는 다음을 포함한다:

웹 2.0 디자인 패턴

크리스토퍼 알렉산더의 "A Pattern Language"에서 구조적인 문제를 해결하기 위한 간결한 설명을 위한 형태를 정의했다. "각 패턴은 우리가 처한 환경에서 계속해서 일어나는 문제를 설명하고, 이 문제를 해결하기 위한 핵심을 설명한 것이다. 이 해결방법은 두번만이 아니라 수백번을 사용할 수 있는 그런 방법이다."
  1. 롱 테일(The Long Tail)

    소수의 사이트가 인터넷 컨텐트의 대부분을 생산한다. 그러나 좁은 니치(niche) 시장은 인터넷에서 가능성있는 응용 프로그램의 대부분을 만들어낸다. 따라서, 전체 웹에 도달하기 위해서는 머리가 아닌 긴 꼬리(Long Tail), 중심부가 아닌 외곽부분에 고객이 스스로 제공하는 서비스와 알고리듬적 데이터 관리에 집중해야 한다.

  2. 다음 인텔 인사이드는 데이터

    응용프로그램은 점점 데이터 중심으로 변화하고 있다. 따라서, 경쟁우위를 위해 유일하면서 재생산하기 어려운 데이터 소스를 소유할 방법을 찾아야 한다.

  3. 사용자가 만드는 부가 가치

    인터넷 응용 프로그램에서 경쟁력을 갖기 위한 핵심은 여러분이 제공하는 데이터에 사용자가 데이터를 어느 정도까지 추가하느냐 즉, 기여하느냐에 달려있다. 따라서, 소프트웨어 개발에서 "참여의 구조"를 제한해서는 안된다. 응용 프로그램에 가치를 부여하는데 있어 암시적이든 묵시적이든 사용자를 관련시켜라.

  4. 기본 설정을 통한 네트워크 효과

    오직 소수의 사용자만 당신의 응용 프로그램에 가치를 추가하려 할 것이다. 따라서, 응용프로그램 사용의 부수 효과(side-effect)로 사용자 데이터를 취합하는 포괄적인 설정을 만들어야 한다.

  5. 일부 권리의 인정(Some Rights Reserved)

    지적재산권 보호는 실험이나 재사용을 제한한다. 따라서, 민간규제(private restriction)이 아닌 집단 수용(collective adoptioon)으로부터 오는 이익이 있을 때 수용장벽이 낮아진다는 것을 명심해야 한다. 기존의 표준을 따르되 가능한한 적은 규제를 가진 라이선스를 사용해야 한다. 개조성(hackability)와 재조합 가능(remixability)하도록 설계하라.

  6. 영원한 베타(The Perpetual Beta)

    디바이스와 프로그램이 인터넷에 연결되면서 응용 프로그램은 더 이상 소프트웨어 상품이 아니라 진행중인 서비스를 의미한다. 따라서, 단일 릴리스로 새로운 기능들을 제공하지 마라. 대신, 일반 사용자 경험을 토대로 지속적으로 기능을 추가해야 한다. 사용자를 실시간 테스터로 끌어들여서 사람들이 새 기능을 어떻게 사용하는지 알아내라.

  7. 통제 대신 협력하라

    웹 2.0 응용 프로그램은 상호 협력하는 데이터 서비스들의 네트워크로 구성된다. 따라서, 웹 서비스 인터페이스와 컨텐트 신디케이션(Syndication)을 제공하고, 다른 데이터 서비스를 재사용하라. 느슨하게 결합된(loosely-coupled) 시스템을 위한 가벼운 프로그래밍 모델을 제공하라.

  8. 단일 디바이스를 넘어서는 소프트웨어

    더 이상 PC가 인터넷 응용 프로그램에 접근할 수 있는 유일한 디바이스가 아니다. 단일 디바이스로 제한된 응용 프로그램은 여러 디바이스로 연결되는 응용 프로그램보다 가치가 떨어진다. 따라서, 응용 프로그램을 처음부터(from the-get go) 핸드헬드 디바이스, PC, 인터넷 서버간에 서비스를 통합할 수 있게 설계해야 한다.

 

AJAX는 이제 야후에 소속된 플리커(Flickr), 37signal의 basecamp및 backpack, 지메일, 오르쿳(Orkut)같은 구글 응용프로그램 같은 웹 2.0 응용 프로그램의 핵심 컴포넌트가 되었다. 웹 개발자들이 PC 기반 응용 프로그램과 같은 풍부한 웹 응용 프로그램을 구축할 수 있게 되면서 우리는 전례없는 사용자 인터페이스 혁명기에 진입하고 있다.

흥미롭게도 대다수의 기능들을 제공하기 위한 움직임은 수년동안 있어왔다. 90년대말, 마이크로소프트와 넷스케이프는 마침내 실현되고 있는 이러한 기능들을 제공하기 위한 비전을 갖고 있었다. 그러나, 표준 쟁탈 전쟁은 브라우저 호환성있는 응용 프로그램 제작을 어렵게 했다. 마이크로소프트가 브라우저 전쟁에서 승리하자 유일한 브라우저가 되었으며, 웹 응용 프로그램을 작성할 사실상의 단일 표준 브라우저가 되었다.

FireFox가 브라우저 시장에서 경쟁자로 소개되고 있지만, 최소한 지금까지는 90년대에 벌였던 웹 표준에 대한 비생산적인 경쟁을 할 것 같지는 않다.

앞으로 몇 해에 걸쳐서 새로운 웹 응용프로그램들을 많이 보게될 것이며, PC 응용 프로그램에 버금가는 풍부한 웹 구현물이나 실로 기발한 응용 프로그램들을 볼 수 있기를 기대하고 있다. 또한, 지금까지 모든 플랫폼의 변화는 이전 플랫폼에서 시장 지배적인 응용 프로그램에 대한 리더십 변화의 기회를 창출해 왔다.

지메일은 이미 사용성면에서 PC 인터페이스들이 취했던 사용자 인터페이스와 웹의 강점-어디서나 접근가능하며, 데이터베이스의 강력함, 검색능력- 을 결합하여이메일의 흥미로운 혁신을 제공하고 있다. 반면에, PC 플랫폼의 메일 클라이언트들은 메신저와 부재여부 표시(presence capabilities)를 추가하는 문제를 해결하지 못하면서 서서히 잠식되고 있다. 최고의 이메일, 메신저, 음성 기능을 추가하기 위한VoIP를 풍부한 기능을 가진 웹 응용 프로그램에 사용한 휴대전화를 통합한 통합 커뮤니케이션 클라이언트를 볼 날도 가깝지 않을까? 경주는 이미 벌어지고 있다.

웹 2.0이 주소록을 다시 만들고 있는 방법을 살펴보면 쉽다. 웹 2.0 스타일의 주소록은 PC나 휴대폰의 주소록을 단순히 시스템에 기억하도록 요청한 연락처의 캐시로만 다룰 것이다. 동시에, 지메일 스타일의 웹 기반 동기화 에이전트는 주고받은 모든 메시지, 사용한 모든 이메일 주소와 전화 번호를 기억하고, 로컬 캐시에서 정답을 발견할 수 없을 때 어떤 것을 대안으로 제시할지 결정할 수 있도록 소셜 네트워킹 휴리스틱을 구축할 것이다. 거기에서도 답을 발견할 수 없다면, 시스템은 보다 넓은 소셜 네트워크에 질의하게 될 것이다.

웹 2.0 워드 프로세서는 단일 문서가 아닌 위키 형태의 공동 저작 형태를 제공할 것이다. 또한, PC 기반 워드 프로세서에서나 볼 수 있었던 다양한 서식기능들도 지원하게 될 것이다.Writely는 아직 큰 인기를 못 끌고 있지만, 그런 기능을 제공하는 좋은 예이다.
웹 2.0 혁명은 PC 응용 프로그램에만 제한되지 않을 것이다. Salesforce.com은 CRM과 같은 엔터프라이즈급 응용프로그램에서 서비스로서의 소프트웨어를 어떻게 배포할 것인지를 보여주고 있다.

신규 참가자가 경쟁 기회를 가지려면 웹 2.0의 가능성을 모두 수용해야 할 것이다. 성공하는 회사들은 단순히 소프트웨어 인터페이스가 아니라 공유 데이터의 풍요속에서 이익을 만들어 내는 참여의 구조를 사용하여 사용자로부터 학습하는 응용 프로그램을 만들어 낼 것이다.


웹 2.0 회사의 핵심 경쟁력

7가지 원칙들을 살펴보면서 웹 2.0의 주요 특징들을 살펴보았다. 지금까지 살펴본 각 예제들은 이러한 원칙들을 하나 이상 포함하고 있다. 따라서, 우리가 생각하는 웹 2.0 회사들의 핵심 경쟁력을 요약하는 것으로 마무리를 할 것이다.

  • 패키지 소프트웨어가 아닌 비용 효율적이고 확장성을 가진 소프트웨어
  • 많은 사람들이 사용할수록 보다 풍부해지는 유일하고, 재창조가 어려운 데이터 소스에 대한 통제
  • 협력 개발자로 사용자를 신뢰하는 것
  • 집단 지능을 이용하기
  • 고객 스스로 참여하는 롱테일을 만들 것
  • 단일 디바이스를 넘어서는 소프트웨어
  • 가벼운 사용자 인터페이스, 개발 모델, 그리고 비즈니스 모델

차세대 기업은 위 기능을 시험해볼 수 있는 "웹 2.0" 기업이 되어야 한다. 높은 점수를 얻을수록, 기업의 가치도 올라간다. 또한, 한 분야에서 탁월한 것이 7가지 분야에서 조금씩 잘 하는 것보다 훨씬 효과적이라는 것도 명심하자.

 

저자: Tim O'Reilly

번역 : 한동훈 역
원문 :http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html

 

사용자 삽입 이미지

 

출처 :http://network.hanbitbook.co.kr/view.php?bi_id=1152

  Comments,     Trackbacks
Web 2.0이란 무엇인가(2)

Web 2.0이란 무엇인가 : 다음 세대 소프트웨어를 위한 디자인 패턴 및 비즈니스 모델(2)

 

연재 순서
1.
Web 2.0이란 무엇인가 : 다음 세대 소프트웨어를 위한 디자인 패턴 및 비즈니스 모델(1)

2.Web 2.0이란 무엇인가 : 다음 세대 소프트웨어를 위한 디자인 패턴 및 비즈니스 모델(2)

3.Web 2.0이란 무엇인가 : 다음 세대 소프트웨어를 위한 디자인 패턴 및 비즈니스 모델(3 - 완결)

 

사용자 삽입 이미지

블로깅과 집단의 지혜

 

웹 2.0 시대의 가장 많이 언급되는 특징중의 하나는 블로깅의 출현이다. 개인 홈페이지는 웹의 초기 시대부터 있어왔으며, 개인 일기장이나 일일 사설과 같은 것은 이보다 더 오래전부터 있어왔던 것이다. 그렇다면 도대체 이 법석은 무엇때문일까?

가장 근본적으로 블로그는 일기 형식의 개인 홈 페이지라는 것이다. 그러나,리치 스크렌터(Rich Skrenta)의 메모에서처럼, 블로그의 연대기적인 구성은 "사소한 차이처럼 보인다. 그러나 그로 인해 완전히 다른 전달방법, 광고, 가치 사슬이 가능하게 되었다"라고 얘기한다.

이러한 차이를 낳은 한 가지는RSS때문이다. RSS는 초기 해커들이 CGI를 사용해서 데이터베이스에 기반한 웹 사이트를 작성할 수 있다고 깨달았던 시기 이후로 웹의 근본적인 구조에 있어서 가장 중요한 진보라 할 수 있다. RSS는 사용자가 페이지에 링크하는 것이 아니라 구독할 수 있게 하였다. 즉, 페이지가 변경될 때마다 변경을 알 수 있다. 스크렌터는 이를 "성장하는 웹(the incremental web)"이라 부르며, 다른 사람들은 "살아있는 웹(live web)"이라 부른다.

물론, 동적으로 생성되는 컨텐트를 가진 데이터베이스 기반 사이트와 같은 "동적 웹 사이트"는 이미 10년 전에 정적인 컨텐트를 갖는 웹 페이지를 대체했다. 살아있는 웹(live web)에서 동적이라 하는 것은 페이지가 아니라 링크를 의미한다. 웹 로그에 대한 링크는 끊임없이 바뀌는 페이지와 매 변경사항에 대한 통지를 가리키는 것을 의미하며, 사람들은 이 링크를 고유링크(permalink)라 부른다. 때문에 RSS 피드는 페이지에 대한 북마크나 링크 보다 훨씬 강력하다.

참여의 아키텍처

일부 시스템들은 참여를 장려하기 위해 고안되었다. 댄 브리클린(Dan Bricklin)의 논문,[6]The Cornucopia of the Commons에서 그는 대규모 데이터베이스를 구축하는 세 가지 방법을 설명했다. 첫째는 야후가 보여준 방법으로 데이터베이스를 구축하기 위해 사람들을 고용하는 것이다. 두번째는 오픈소스 커뮤니티에서 힌트를 얻은 것으로 같은 일을 수행할 자원자를 구하는 것이다. 야후의 오픈 소스 경쟁자인오픈 디렉터리 프로젝트가 그러한 예이다. 그러나, 세번째 방법은냅스터에서 알 수 있다. 냅스터는 다운로드 받은 음악을 자동으로 업로드(serve)할 수 있게 설정되어 있기 때문에 모든 사용자는 자동적으로 공유 데이터베이스 구축을 돕게된다. 이후의 다른 P2P 파일 공유 서비스들도 이와 같은 접근방법을 따르고 있다.

웹 2.0 시대의 핵심 교훈은 "사용자가 가치를 더한다."는 것이다. 그러나, 오직 소수의 사용자만 명확한 방법으로 여러분의 응용 프로그램에 가치를 더하는 수고를 할 것이다. 따라서, 웹 2.0 회사는 응용 프로그램의 일상적인 사용의 부수 효과(side-effect)로 사용자 데이터를 수집하고, 가치를 구축할 수 있도록 포괄적인 정책들을 설정해야한다. 위에서 언급한 것처럼, 웹 2.0 회사들은 더 많은 사용자가 사용할수록 우수해지는 시스템들을 구축한다.

미치 케이퍼(Mitch Kapor)는 "아키텍처는 정책이다(architecture is politics)"라고 언급했었다. 냅스터에서 참여는 고유한 것이며, 냅스터 기본 아키텍처의 부분이다.

이러한 아키텍처에 대한 통찰이 종종 자유지원제(Volunteerism)에 호소하는 것 보다 오픈 소스 소프트웨어 성공의 핵심일지도 모른다. 인터넷, 그리고 월드 와이드 웹, 리눅스, 아파치, 펄과 같은 오픈 소스 소프트웨어 프로젝트의 아키텍처는 모두 자신의 "이기적인(selfish)"인 관심사를 추구하는 사용자들이 집단 가치(collective value)를 구축하는 과정에서 나온 무의식적인 부산물이다. 이들 프로젝트들 각각은 작은 핵심(core) 부분, 잘 정의된 확장 구조, 사용자들이 추가할 수 있는 잘 정의된 컴포넌트 접근 방법, 펄의 창시자 래리 월(Larry Wall)이 "양파"라고 언급했던 성장하는 외부 계층(outer layers)들을 갖고 있다. 다시 말해서, 이들 기술들은 그들이 고안했던 방식을 통해서 네트워크 효과를 설명한다.

이들 프로젝트들은 참여의 자연적인 아키텍처를 가진 것처럼 보인다. 그러나, 아마존에서 보여준 것처럼 지속적인 노력-제휴 프로그램과 같은 경제적인 인센티브를 포함해서-에 의해 시스템에 그러한 아키텍처를 걸치는 것이 가능하다.

([6]역주: The Cornucopia of the Commons는차세대 인터넷 P2P에서도 볼 수 있다.

펄은 핵심부분을 제외하고는 모두 계층의 형태로 되어 있다. 이에 대해서는오픈소스 9장에서 찾아볼 수 있다)


RSS는 또한 웹 브라우저가 단순히 웹 페이지를 보여주는 수단만이 아니라는 것을 의미한다. 블로그라인(Bloglines) 같은 웹 기반 RSS 수집기가 있는가하면 데스크탑 클라이언트도 있으며, 어떤 것들은 사용자가 휴대용 기기에서 끊임없이 업데이트되는 컨텐트를 구독할 수 있게 해준다.

이제 RSS는 새로운 블로그 항목들을 보여주는 것 뿐만아니라 주가, 날씨 데이터, 사진을 포함한 모든 종류의 데이터를 전달하는데(push) 사용되고 있다. 이러한 사용은 실제로 RSS의 근원까지 거슬러간다. RSS는 1997년에 정기적으로 업데이트된 데이터를 보여주는 커스텀 넷스케이트 홈페이지를 사용자가 작성할 수 있게 하기 위한 넷스케이프의 "Rich Site Summary"와 업데이트된 블로그를 사용자에게 전달하기 위해 사용된 데이브 위너(Dave Winer)의 "Really Simple Syndication"의 합류점에서 탄생했다. 넷스케이프는 흥미를 잃어버렸고, 기술은 위너의 회사인 블로깅 개척자들의 Userland에 의해 발전하였다. 현재의 번영은 두 부모의 유산인 것이다.

그러나, RSS는 일반적인 웹 페이지와 웹 로그를 구별하는 유일한 것이다. 톰 코티스(Tom Coates)는고유링크의 의미에 대해 논평했다.
RSS는 매우 사소한 기능처럼 보이지만 웹로그를 쉽게 출판하는 현상(ease-of-publishing phenomenon)에서 공통점이 있는 커뮤니티들을 회화 형식의 무질서로 효율적으로 바꾸어 버리는 장치가 되었다. RSS는 최초로 다른 사람의 사이트의 특정 포스트나, 그에 관한 글에 직접적으로 어떤 행위를 하는 것을 상대적으로 쉽게 만들었다. 토론이 등장했으며, 채팅(chat)이 등장했다. 결과적으로 우정이 나타났거나 우정을 보다 견고하게 만들었다. 고유링크(permalink)는 웹 로그들간에 다리를 놓아주는 첫번째이자 가장 성공적인 시도였다.

RSS와 고유링크는 웹 프로코톨인 HTTP 위에 유즈넷(Usenet)의 네트워크 뉴스 프로토콜(Network New Protocol)인 NNTP의 많은 특성들을 다양한 방법으로 추가시켰다. 블로그스피어(blogosphere)는 초기 인터넷에서 끊이지 않는 대화의 창고(conversational watering holes)로 여겨지던 유즈넷이나 게시판에서와 같이 사용자와 사용자가 상호 대등한 관계를 갖는 새로운 것으로 여겨진다. 사람들이 각 개인의 사이트를 구독할 수 있으며, 페이지의 개별 코멘트를 쉽게 링크할 수 있다. 뿐만 아니라[7]트랙백(trackback, 엮인글)이라는 방법을 사용해서 다른 사람이 자신의 페이지에 링크를 추가했을 때 상호 링크(트랙백 링크)를 남기거나 코멘트를 추가하는 것으로 응답할 수 있다.

([7]역주: trackback은 엮인글이라는 형태로 번역되기도 하지만, 아직까지는 트랙백이라는 용어가 더 많이 사용되고 있기에 그대로 사용하였다.)

양방향 링크는 흥미롭게도[8]제나두 같은 초기 하이퍼펙스트 시스템의 목표였다. 하이퍼텍스트 순수주의자는 양방향 링크를 향한 한 걸음으로 트랙백을 열렬히 지지했다. 그러나 알아둘 점은 엄밀한 의미에서 트랙백은 양방향이 아니라는 것이다. 양방향이라기 보다는 양방향과 같은 효과를 만들어 내는 의미론적인 단방향 링크(symmetrical one-way links)라는 것이다. 연결을 만들기 위해 수신자와의 인맥을 필요로하는 프렌스터(Friendster), 오르쿠트(Orkut), 링크드인(LinkedIn) 같은 소셜 네트워킹 시스템은 웹과 같은 확장성(scalability)을 갖고 있지 않다. 플리커(Flickr) 사진 공유 서비스의 공동 창업자인 캐터리나 페이크(Caterina Fake)가 지적한 것처럼 관심(attention)은 오직 우연에 의한 상호 관계다.(따라서 플리커에서 사용자는 관찰 목록(watch lists)을 설정할 수 있고, 어떤 사용자든지 RSS를 사용해서 다른 사용자의 포토스트림을 구독할 수 있다. 관심의 목적은 알림을 받는 것이지만 연결을 허락할 필요는 없다)

([8]역주: 제나두(Xanadu) 프로젝트에 대해서는 다음을 참고한다.
하이퍼링크의 역사:http://www.dal.co.kr/blog/archives/001139.html)

웹 2.0에서 중요한 부분이 웹을 일종의 글로벌 브레인으로 바꾸는 집단 지능을 이용하는 것이었다면, 블로그스피어는 전뇌(前腦)에서 들을 수 있는 끊임없이 계속되는 정신속의 대화, 모두의 머리속에서 들을 수 있는 목소리와 같은 것이다. 이는 무의식이라 하는 두뇌의 깊은 곳에 영향을 주지 못하지만 대신에 의식적인 생각에 해당한다. 의식적인 생각과 관심의 영향력 때문에 블로그스피어는 강력한 영향력을 갖기 시작했다.

첫째, 검색 엔진을 유용한 페이지를 예상하기 위해 링크 구조를 이용하기 때문에 가장 빠르면서 많은 링크를 만들어내는 블로거들은 검색 엔진 결과를 만들어 내는데 적절한 역할을 하고 있다. 둘째, 블로그 커뮤니티는 자기 참조적이기 때문에 다른 블로거에 대한 관심을 갖는 블로거들은 자신의 시야와 영향력을 확대하게 된다. 비평가들이 비난하고 있는[9]"반향실(echo chamber)"도 또 다른 증폭기이다.

([9]역주: 미국 시카고대 카스 선스타인 교수가 2001년 출간한 <>에서 사람들은 자신이 찬성하는 견해를 적극 추구한다고 지적하였다. 자유주의 정견을 가진 사람은 그런 성향의 책만 사고, 보수적인 사람들 역시 자신의 견해와 비슷한 책만 골라보는 현상을 반향실(echo chamber) 효과라 부른다. 인터넷을 통한 자료와 정보가 자신의 생각을 바꾸기 위한 것이 아니라 뒷바침하기 위한 것이라는 사실을 의미한다.)

이것이 단순히 증폭기라면 블로깅을 이해할 수 있을지도 모른다. 그러나 위키피미어(Wikipedia) 같이 블로깅은 일종의 필터로 집단 지능을 이용하고 있다. 제임스 슈리어웨키(James Suriowecki)가 "집단의 지혜" 라 부르는 것은 동작하고 있다. 페이지 랭크는 개별 문서를 분석하는 것보다 훨씬 더 나은 결과를 만들어내며, 블로그스피어의 집단 관심(collective attention)은 가치있는 것을 선별한다.
주류(主流) 미디어는 개인 블로그들을 경쟁자로 바라보겠지만 정말로 당황스러운 점은 경쟁자가 블로그스피어 전체라는 것이다. 이는 단순히 사이트간의 경쟁이 아니라 비즈니스 모델간의 경쟁을 의미한다. 웹 2.0의 세상은 댄 길머(Dan Gilmor)가 얘기한[10]"우리가 미디어(We, the media)"의 세상이기도 하다. 즉, 은밀한 곳(back room)에서 소수의 사람들이 무엇이 중요한가를 결정하는 것이 아니라 "독자가 제작자(the former audience)"인 세상이기도 하다.

([10]역주: We, the media에 대해서는 다음을 참고한다.
"풀뿌리 저널리즘"이라는 신화 :http://gatorlog.com/mt/archives/001816.html)


3. 다음 인텔 인사이드는 데이터

오늘날 중요한 인터넷 응용 프로그램은 모두 특화된 데이터베이스로부터 지원을 받는다. 구글의 웹 크롤(web crawl), 야후의 디렉터리(및 웹 크롤), 아마존의 상품 데이터베이스, 이베이의 상품과 판매자 데이터베이스, 맵퀘스트(MapQuest)의 지도 데이터베이스, 냅스터의 곡에 대한 분산 데이터베이스가 그러한 예이다. 할 배리언(Hal Varian)이 지난해 사적인 자리에서 "새로운 HTML은 SQL이다"라고 얘기했다. 데이터베이스 관리는 웹 2.0 회사에서 핵심 경쟁력이 되었으며, 우리는 때때로 이러한 응용 프로그램들을 단순히 소프트웨어가 아니라 "인포웨어(infoware, 정보상품)"라 부른다.

이 사실로부터 핵심질문이 나온다: 누가 데이터를 소유하는가?

인터넷 시대에는 데이터베이스에 대한 통제력이 시장 통제력으로 이어지고, 큰 재정적 이익으로 이어지는 수 많은 경우들을 볼 수 있다. 후일 Verisign에 매각된 Network Solutions사는 정부 법령에 의해 도메인 네임 레지스트리를 독점했으며, 이는 인터넷에서 엄청난 돈을 벌어들이는 첫번째 사례이기도 하다. 소프트웨어 API를 통제하는 것에 의한 비즈니스 이익이 인터넷 시대에는 훨씬 더 어려워졌다고 논했지만 핵심 데이터 소스의 통제력은 그렇지 않다.

맵퀘스트가 제공하는 모든 맵에 있는 저작권 문구를 살펴보라. maps.yahoo.com, maps.msn.com, maps.gogle.com 같은 곳에서 "Maps copyright NavTeq, TeleAtlas"라든가, 위성 이미지 서비스의 경우에는 "Images copyright Digital Globe"와 같은 문구를 볼 수 있을 것이다. 이들 회사들은 데이터베이스에 상당한 투자를 했다.(NavTeq사는 도로 주소와 위치 데이터베이스를 구축하기 위해 7억 5천만 달러를 투자했으며, Digital Globe사는 정부가 제공하는 이미지를 향상시키기 위해 독자적인 위성을 발사하기 위해 5억달러를 사용했다) NavTeq는 이뿐만 아니라 인텔의 익숙한 인텔 인사이드 로고와 비슷한 것을 만들어냈다. 네비게이션 시스템이 장착된 차량에는 "NavTeq Onboard" 로고가 새겨져있다. 실제로 데이터가 이들 응용 프로그램의 인텔 인사이드이며, 시스템의 소프트웨어 하부구조(infrastructure)에서 유일한 소스 컴포넌트는 대부분 오픈소스이다.

응용 프로그램의 핵심 데이터 소슈의 중요성을 이해하기 위해서는 요즘 뜨겁게 경쟁하고 있는 웹 지도 분야를 살펴볼 필요가 있다. 이 분야는 뒤쳐진 자가 어떻게 경쟁 우위 요소를 없앴는지를 잘 보여준다. 맵퀘스트는 1995년에 웹 지도 분야를 개척했다. 야후, 마이크로소프트, 최근에는 구글까지 시장에 참여하기로 결정했을 때 이들은 동일한 데이터를 라이선스하는 것으로 경쟁 응용 프로그램을 쉽게 내놓을 수 있었다.

그러나, 이와 반대로 아마존의 위치는 그와 다르다. 반즈앤노블과 같은 경쟁자들과 마찬가지로 원본 데이터베이스는 ISBN 레지스트리 제공업체인 R.R Bowker의 것이지만 맵퀘스트와 달리 아마존은 표지 이미지, 목차, 인덱스, 샘플과 같은 출판사가 제공하는 데이터를 추가하면서 경쟁적으로 데이터를 개선시켰다. 가장 중요한 것은 그들의 데이터를 설명하기 위해 사용자를 이용했다는 점이다. 그런 식으로 10년이 지난후에 소비자 뿐만 아니라 학자나 사서들에게도 도서 목록에 대한 주요 소스가 된 것은 Bowker가 아니라 아마존이 되었다. 또한, 아마존은 전매 식별자인ASIN을 만들었다. ASIN은 ISBN과 동일하며, ISBN이 없는 상품에는 고유 식별번호를 만든다. 아마존은 그들의 데이터 공급자를 "포용하고 확장"시켰다.

맵퀘스트가 아마존과 같이 가치의 계층들을 추가하면서 지도와 위치를 설명하기 위해 사용자를 이용하는 일을 했다고 상상해보자. 이는 경쟁자가 단순히 기본 데이터를 라이선스 하는 것으로 시장에 진입하는 것 보다 시장 진입을 훨씬 더 어렵게 만든다.

최근에 소개된 구글 맵스는 응용 프로그램 제작사와 데이터 공급사 사이에 경쟁을 위한 살아있는 실험실을 제공한다. 구글의 경량화 프로그래밍 모델(lightweight programming model)은 구글 맵스와 인터넷 액세스가 가능한 데이터 소스를 연결하는 복합응용프로그램(mashup)의 형태로 수 많은 부가가치 서비스를 창출을 유도한다. 폴 라드매셔(Paul Rademacher)의housingmaps.com은 구글 맵스와Craigslist의 아파트 임대 및 집 구매 데이터를 결합해서 인터랙티브 주택 검색 도구를 만들었다. 이는 복합응용프로그램의 훌륭한 예이다.

현재까지 이러한 복합응용프로그램은 주로 해커들에 의한 혁신적인 실험이다. 그러나, 기업 활동이 이를 바싹 뒤따르고 있다. 그리고, 이미 최소한 한 무리의 개발자들을 볼 수 있는데, 구글은 NavTeq으로부터 데이터 소스의 역할을 빼앗아오고 있으며, 스스로를 매개자로 집어넣고 있다. 앞으로 수년간은 데이터 공급자와 응용 프로그램 제작사간의 전쟁을 볼 수 있을 것이라고 예상하고 있다.

경쟁은 핵심 데이터의 어떤 부분을 소유하느냐에 달려있다. 즉, 위치, 아이덴티티, 공공이벤트의 캘린더링, 제품 아이덴티파이어(identifier)와 네임스페이스 같은 것을 의미한다. 대부분의 경우에 문제는 데이터를 만드는 비용에 있다. 다시 말해서, 데이터에 대한 단일 소스로 인텔 인사이드 스타일과 같은 전략을 펼칠 기회도 있다. 사용자 집합을 통한 임계 집단(critical mass)에 먼저 도달하고, 집합된 데이터를 시스템 서비스로 먼저 변환하는 회사가 승리자가 될 것이다.

예를 들어서, 아이덴티티의 분야에서 페이팰(PayPal), 아마존의 원클릭, 수백만 사용자들의 커뮤니케이션 시스템은 네트워크 기반 아이덴티티 데이터페이스를 구축하려는 합법적인 경쟁자가 될 수 있다.(이런 점에서 휴대폰 번호를 Gmail 계정의 식별자로 사용하려는 구글의 시도는 전화 시스템을 포용하고 확장하기 위한 한 걸음이 될지도 모른다) 한편으로Sxip같은 스타트업(startup)은 연합된 아이덴티티(federated identity)의 잠재력을 탐색하고 있는 중이다. 유기적으로 연결된 웹 2.0 아이덴티티 서브시스템을 제공하는 일종의 "분산형 원클릭(distributed 1-click)"을 탐험하고 있다. 캘린더링 분야에서는EVDB가 위키 스타일의 참여 아키텍처를 통해서 세계에서 가장 큰 공유 캘린더를 구축하려 시도하고 있다. 심사원이 어떤 특정 스타트업이나 접근방법의 성공이 나오는 동안에 이들 분야에서 특정 분류의 데이터를 "인터넷 운영 체제"의 신뢰할 수 있는 서브시스템으로 효율적으로 변환할 수 있는 표준이나 해결책들이 다음 세대 응용 프로그램을 가능하게 할 것이다.

데이터에 관해서 언급되어야 할 한가지는 개인정보보호와 사용자 자신의 데이터에 대한 권한에 대한 사용자들의 우려다. 초기 상당수 많은 웹 응용 프로그램들이 저작권을 느슨하게 적용했었다. 예를 들어, 아마존은 사이트에 제출된 모든 리뷰에 대한 소유권을 주장하지만 법적 강제가 없기 때문에 사람들은 동일한 리뷰를 다른 곳에 중복 게시할지도 모른다. 그러나, 데이터에 대한 통제력을 깨닫기 시작한 회사들은 이를 경쟁 우위의 주요 원천으로 생각함에 따라 통제력에 대한 과장된 시도들을 보게될지도 모른다.

독점적 소프트웨어(proprietary software) 득세가자유 소프트웨어운동을 촉발한 것처럼 독점적 데이터베이스(proprietary database)의 득세가 다음 10년에는 자유 데이터(Free Data) 운동으로 이어질 것이라고 예상한다. 이미, 위키피디어, 크리에이티브 커먼스(Creative Commons), 사용자가 자신의 컴퓨터에 데이터를 어떻게 표시할지를 제어할 수 있는그리스멍키(Greasemoneky)와 같은 소프트웨어 프로젝트 같이 오픈 데이터 프로젝트들에서 독점적 데이터베이스에 대항하는 트렌드의 초기 징조들도 보이고 있다.


4. 소프트웨어 릴리스 주기의 종말

구글 vs 넷스케이프의 논의에서 언급했던 것처럼 인터넷 시대 소프트웨어의 특징을 정의하라면 제품이 아니라 서비스로 전달되는 것이라 할 수 있다. 이 사실은 회사의 비즈니스 모델의 근본을 바꾸어버리는 것이다.

  1. 오퍼레이션(Operation)은 반드시 핵심 경쟁력이 되어야 한다. 제품 개발에 대한 구글과 야후의 전문지식은 일일 오퍼레이션이라는 점에서 일치한다. 즉, 물건으로서의 소프트웨어가 아니라 서비스로서의 소프트웨어로 근본이 변화하였으며, 소프트웨어는 일일 단위로 유지보수되지 않는다면 실행이 중단될 것이다. 구글은 끊임없이 웹을 돌아다니면서 인덱스를 업데이트해야 하며, 검색 결과에 영향을 미칠 수 있는 링크 스팸이나 다양한 시도들을 지속적으로 걸러내야 하며, 수억건의 사용자 질의에 동적으로 응답해야하며, 끈임없이 문맥에 적합한 광고들을 찾아내야한다.

    구글의 시스템 관리, 네트워킹, 로드 밸런싱 기술이 구글의 검색 알고리즘보다 더 철저하게 보호되는 비밀인 것은 우연이 아니다. 이러한 과정들을 자동화한 구글의 성공은 경쟁자에 비해 가격 우위에 있게 한 핵심적인 부분이다.

    웹 2.0 회사에서 "Perl, Python, PHP, Ruby와 같은 스크립트 언어들이 중요한 역할을 수행하는 것" 또한 우연이 아니다. Sun의 첫번째 웹 마스터인 하산 슈뢰더(Hassan Schroeder)는 Perl을 "인터넷의 청테이프(Duct tape)"라고 하였다. 소프트웨어 상품(Software artifacts) 시대의 소프트웨어 엔지니어들이 낮춰 보던 소위 스크립팅 언어라 했던 동적언어(Dynamic Language)는 시스템 관리자나 네트워크 관리자들이 선택하는 도구일 뿐만 아니라 지속적인 변화가 필요한 동적인 시스템을 구축하는 응용 프로그램 개발자들이 선택하는 도구가 되었다.

  2. 오픈 소스 개발 지침의 영향으로 사용자는 공동 개발자로 취급되어야한다.(심지어 문제의 소프트웨어가 오픈 소스 라이선스하에 릴리스 될 것 같지 않더라도 말이다) 오픈 소스 격언인 "빨리 출시하고, 자주 출시한다(release early and release often)"는 실제로 소프트웨어가 보다 극단적인 위치, "영원한 베타(the perpetual beta)"로 이동했음을 의미한다. 이는 제품이 공개된 장소에서 개발되며 월간, 주간 또는 심지어 일일 단위로 새로운 기능이 통합되는 것을 의미한다. 지메일(Gmail), 구글 맵스, 플리커(Flickr), 딜리셔스(del.icio.us) 같은 서비스들이 동시에 수년째 "베타" 로고를 갖는 것은 우연이 아니다.

    사용자가 새로운 기능들 중에 어느 것을 사용하는가, 어떻게 사용하는가 하는 것을 알기 위한 사용자 행위에 대한 실시간 모니터링을 할 수 있으며, 이는 필수적인 핵심 경쟁력으로 이어진다. 대형 온라인 서비스 업체의 한 웹 개발자에 따르면 "우리는 매일 사이트 어딘가에 2-3가지의 새로운 기능을 올려놓습니다. 사용자들이 새 기능을 사용하지 않으면 우리는 그것들을 제거합니다. 사용자들이 새 기능을 좋아하면 우리는 그것을 전체 사이트에 적용합니다"라고 한다.

    플리커의 수석 개발자인 칼 헨더슨(Cal Henderson)은 최근에 "30분 단위의 새로운 빌드업을 적용했다고 발표했다". 이는 분명 극단적으로 다른 개발 모델이다! 모든 웹 응용 프로그램이 플리커와 같이 극단적인 형태로 개발되는 것은 아니지만 거의 모든 웹 응용 프로그램은 PC나 클라이언트 서버 시대와 달리 극단적인 개발 주기를 갖고 있다. 이러한 이유로 최근에 ZDnet 편집자는 "마이크로소프트는 구글을 이길 수 없을 것"이라고 결론지었다.

    "마이크로소프트의 비즈니스 모델은 사용자가 컴퓨팅 환경을 2-3년 주기로 업그레이드하는 것에 의존하지만 구글은 사용자가 매일 자신의 컴퓨팅 환경에 새로운 것이 무엇인지 탐험하는 것에 의존한다"

마이크로소프트는 경쟁자로부터 많은 것을 배우고 궁극적으로 경쟁에 최선을 다할 것이라고 설명하고 있으며, 지금까지 의문의 여지는 없다. 경쟁자는 근본적으로 다른 회사가 되기 위해 마이크로소프트가 필요할 것이다. 네이티브 웹 2.0 회사는 감춰야 하는 옛 패턴들(그리고 그에 상응하는 비즈니스 모델과 수입의 출처)이 없기 때문에 웹 2.0의 자연적인 이익을 즐길 것이다.

저자: Tim O'Reilly

번역 : 한동훈 역
원문 :http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html

 

사용자 삽입 이미지

 

출처 :http://network.hanbitbook.co.kr/view.php?bi_id=1148

  Comments,     Trackbacks
Web 2.0이란 무엇인가(1)

Web 2.0이란 무엇인가 : 다음 세대 소프트웨어를 위한 디자인 패턴 및 비즈니스 모델(1)

 

연재 순서
1.
Web 2.0이란 무엇인가 : 다음 세대 소프트웨어를 위한 디자인 패턴 및 비즈니스 모델(1)

2.Web 2.0이란 무엇인가 : 다음 세대 소프트웨어를 위한 디자인 패턴 및 비즈니스 모델(2)

3.Web 2.0이란 무엇인가 : 다음 세대 소프트웨어를 위한 디자인 패턴 및 비즈니스 모델(3 - 완결)

 

사용자 삽입 이미지

2001년 가을 닷컴버블의 붕괴는 웹에 이정표를 남겼다.

 

버블과 연이은 신경제의 붕괴는 모든 기술 혁명이 갖는 공통된 특성들을 보여줬으며사람들은 웹이 지나치게 과장되었다고 결론내렸다. 이러한 침체는 우위에 있는 기술이 주역을 차지할 준비가 되었음을 나타내는 전형적인 이정표를 의미한다. 닷컴 옹호론자들이 갑자기 해고되는가하면 그들의 성공스토리는 신경제의 힘을 보여주는 현실에서 무엇이 그들을 갈라놓았는지 이해되기 시작했다.

"웹 2.0"의 개념은 오라일리와 미디어라이브 인터내셔널의 컨퍼런스 브레인스토밍 세션에서 시작되었다. 웹 개척자이자 오라일리 부사장인 데일 도허티(Dale Dougherty)는 웹 2.0이 기존의 웹과 충돌하는 것이 아니며, 웹은 지금보다 더 지속적으로 중요해질 것이며, 웹은 놀랄만한 규칙성을 갖고 등장하는 새로운 응용 프로그램과 사이트를 갖게 될 것이라고 언급했다. 뿐만 아니라, 닷컴붕괴이후 살아남은 회사들은 어떤 공통적인 것을 갖고 있다. 웹에 일종의 전환점을 찍은 닷컴 붕괴를 어떻게 표현할 수 없을까? 예를 들어, "웹 2.0"으로 부르는 것은 어떨까? 우리는 이런 의견에 동의했고, 그 결과로웹 2.0 컨퍼런스가 탄생했다.

그로부터 6개월이 지난후에 "웹 2.0"이라는 용어는 구글에서 950만건 이상 인용되고 있는 것에서 알 수 있는 것처럼 분명 어떤 위치를 자리잡고 있다. 그러나, 일부 사람들은 의미없는 마케팅 유행어라고 비난하는가 하면, 새로운 개념(conventional wisdom)으로 받아들이는 것처럼웹 2.0이 무엇을 의미하는가에 대한 많은 의견차이가 존재한다.

그래서 여기서는 우리가 말하는 웹 2.0이 무엇을 의미하는지 정리해보려 한다.

초기 브레인스토밍에서 우리는 다음 예제를 사용해서 웹 2.0의 개념을 기술했었다.

사용자 삽입 이미지


이 리스트는 계속해서 늘어날 수 있다. 그러나 무엇으로 웹 1.0으로서의 응용 프로그램 또는 접근방법과 웹 2.0을 구분할 수 있는가? (많은 회사들이 웹 2.0이 무엇을 의미하는지 이해도 하지 않고 마케팅 유행어로 붙여넣기 하는 웹 2.0 밈(Meme)[1]이 널리 퍼져있기 때문에 이 질문은 성급한 질문이다. 대다수의 유행어에 중독된 시작은 분명 웹 2.0이 아니며, 우리가 웹 2.0으로 정의한 넵스터나 비트토런트와 같은 일부 응용 프로그램은 정확히 웹 응용프로그램이 아니기 때문에 웹 2.0에 대한 질문에 답하는 것은 어렵다.) 우리는 웹 1.0의 성공스토리와 새로운 응용 프로그램들의 가장 흥미로운 부분을 다양한 각도로 설명하면서 웹 2.0의 원칙들을 세밀히 살펴볼 것이다.

([1]역주. 밈(Meme): "이기적 유전자"에서 유전자(Gene)의 발음을 빗대 말들어진 단어로 유전자와 같이 세포로부터 전해지는 것이 아니라 행동의 모방을 통해 전해지는 것으로 여겨지는 문화의 요소로 유행어, 패션의 유행, 노래등이 있다.)



1. 플랫폼으로서의 웹

다른 중요한 컨셉과 마찬가지로 웹 2.0을 의미하는 일정한 경계는 존재하지 않지만 중력과 같은 핵심이 존재한다. 중심부로부터의 거리에 따라 웹 2.0의 원칙들을 설명하는 사이트로 구성된 행성계(solar system)[2]로 묶어서 원칙이나 원리들의 집합으로 웹 2.0을 그려볼 수 있다.

([2]역주: 태양계는 The Solar System, 행성계는 a solar system이며 원문은 a veritable solar system이다.)

사용자 삽입 이미지


그림1은 오라일리 미디어의 컨퍼런스 FOO 캠프의 브레인스토밍 세션에서 만든 웹 2.0의 밈맵(Meme Map)이다. 많은 작업이 진행중이지만 많은 아이디어들을 웹 2.0의 중심부로부터 방사형의 형태로 나타냈다.

예를 들어, 2004년 10월 최초의 웹 2.0 컨퍼런스에서 존(John Battelle)과 나는 개회사에서 웹 2.0의 초기 개념들을 나열했었다. 이러한 원칙의 첫번째가 "플랫폼으로서의 웹"이었다. "플랫폼으로서의 웹은" 마이크로소프트와의 치열한 경쟁 끝에 불꽃으로 산화환 웹 1.0 시대의 넷스케이프가 외치던 구호이기도 했다. 뿐만아니라, 초기 웹 1.0의 대표적인 예로 더블클릭과 아카마이(Akamai)는 플랫폼으로서의 웹을 다루려한 개척자들이다. 사람들은 광고 제공을 "웹 서비스"라고 생각하지 않지만, 실제로 "광고 제공(Ad serving)"은 최초로 널리 배포된 웹 서비스 였으며, 최초로 널리 배포된 매쉬업(mashup)[3]이다. 모든 배너 광고는 다른 웹 사이트의 독자들에게 하나로 통합된 페이지를 전달하기 위해 두 웹 사이트간에 유기적으로 결합되어 제공된다. 아카마이는 플랫폼으로서의 네트워크를 다룬다. 아카마이는 스택 레벨의 보다 깊은 곳에서 투명한 캐싱(Transparent Caching)[4]을 구축하고, 대역폭 혼잡을 완화하는 컨텐트 전달 네트워크를 만들어낸다.

([3]역주: 매쉬업(mashup)은 최근에 통용되기 시작한 신조어로 여러 서드 파티 응용 프로그램의 API를 이용하여 만들어진 웹 응용 프로그램을 의미한다.)
([4]역주: 투명한 캐시(Transparent Caching)은 프록시 서버를 지정하지 않고, 간단한 설치로 많은 이용자들이 캐시 서비스를 이용하게 해주는 것을 의미한다. 이와 반대의 의미로 Proxy Caching이 있다.)

그럼에도 불구하고, 이들 개척자들은 새로운 참가자들에게 새로운 플랫폼의 특성에 대한 보다 깊은 이해를 제공함으로써 같은 문제에 대해 보다 나은 해결책을 가질 수 있었기 때문에 유용한 차이를 제공한다. 더블클릭과 아카마이는 모두 웹 2.0의 개척자들이며,웹 2.0 디자인 패턴을 살펴보면서 보다 많은 가능성들에 대한 깨달음을 얻을 수 있다.

이제, 이들 세 가지 요소 각각을 살펴보면서 각 요소의 차이점들을 살펴보자.


넷스케이프 vs 구글

넷스케이프가 웹 1.0의 표준 전달자라면 구글은 분명 웹 2.0의 표준 전달자이다. 가능하다면 넷스케이프와 구글의 IPO(기업공개)가 각 시대의 이벤트로 기록되었다는 점도 이들을 대표한다. 따라서, 이들 두 회사와 그 위치를 비교해보자.

넷스케이프는 오래된 소프트웨어 패러다임의 관점에서 "플랫폼으로서의 웹"을 구상했다. 그들의 기념비적인 제품은 웹 브라우저, 즉 데스크탑 응용 프로그램이었다. 그들의 전략은 브라우저 시장에서의 지배력을 이용해서 비싼 가격의 서버 제품을 위한 시장을 창출하는 것이었다.
이론적으로 PC 시장에서 마이크로소프트가 그랬던 것처럼 브라우저에서 컨텐트와 응용 프로그램을 보여주기 위해 표준보다 강력한 지배력을 갖는 것이 넷스케이프에 같은 시장 지배력을 가져다 줄 것이라 예상했다. 자동차가 없던 시대에 자동차를 수레의 확장으로 여겨 "말없는 수레(horseless carriage)"라고 부르는 것처럼, 넷스케이프에서는 데스크탑을 대체할 웹탑을 내놓았다. 웹탑에 업데이트 정보를 알려주고, 넷스케이프 서버를 구매한 정보 제공자(IP ? Information Providers)가 웹탑에 애플릿을 전달하는 계획을 세웠었다.

결국, 웹 브라우저와 웹 서버는 필수품이 되었고, 가치는 웹 플랫폼 위에서 전달되는 서비스로 이동해버렸다.

반면에, 구글은 판매되거나 패키지로 전달되지 않지만 서비스를 이용하기 위해 소비자가 직간접적으로 비용을 지불해야 하는 순수 웹 응용프로그램으로 시작했다. 구글에서는 기존 소프트웨어 산업이 갖는 특징들이 존재하지 않는다. 예정된 소프트웨어 발표일도 없이 지속적인 개선만이 존재한다. 라이선스나 판매는 없으며 사용만 존재한다. 소비자가 자신의 시스템에서 소프트웨어를 실행하기 위해 다른 플랫픔으로 포팅하는 일도 없으며, 오픈소스 운영체제와 회사 사람들외에는 본적이 없는 자체 개발한 응용 프로그램과 유틸리티를 운영중인 대규모 PC들만 존재한다.

실제로, 구글은 넷스케이프에서 필요하지 않았던 능력 즉, 데이터베이스 관리가 필요하다. 구글은 단순히 소프트웨어 도구 모음이 아니라 특화된 데이터베이스를 의미한다. 데이터가 없으면 도구는 무용지물이다. 소프트웨어가 없다면 데이터는 관리할 수 없다. 소프트웨어를 배포할 필요없이 수행만 하면되고, 데이터를 수집하고 관리하는 능력없이는 소프트웨어가 쓸모없어지기 때문에 이전 시대에 지배력의 수단이었던 소프트웨어 라이선스 정책이나 API에 대한 제어는 무의미해졌다. 실제로, 소프트웨어의 가치는 관리할 수 있는 데이터의 규모에 비례한다.

구글의 서비스는 대규모 인터넷 서버를 통해 전달되지만 서버는 아니며, 브라우저안에서 사용자들에게 경험을 제공하지만 브라우저도 아니다. 대표적인 검색 서비스는 사용자가 검색할 수 있는 컨텐트를 제공하는 것도 아니다. 이는 마치 전화기 자체에서 일어나는 것이 아니라 전화 통화의 양쪽에서 일어나는 전화통화와 비슷하다. 구글은 브라우저와 검색 엔진, 대상 컨텐트 서버 사이의 공간에서 사용자와 온라인 경험 사이를 연결하는 연결자 또는 미들맨과 같이 동작한다.
넷스케이프와 구글 모두 소프트웨어 회사로 설명할 수 있겠지만, 넷스케이프는 1980년대 소프트웨어 혁명기에 시작한 로터스, 마이크로소프트, 오라클, SAP와 같은 세상에 있었다면, 구글의 동료들은 이베이, 아마존, 냅스터, 더블클릭, 아카마이와 같은 인터넷 응용 프로그램들이다.


더블클릭 vs 오버추어와 애드센스

구글과 마찬가지로 더블클릭은 인터넷 시대의 진정한 산물이다. 서비스로서의 소프트웨어를 이용하고, 데이터 관리에 있어 핵심역량을 갖고 있으며, 위에서 언급한 것처럼 웹 서비스라는 이름을 갖기도 전에 웹 서비스 분야에서의 개척자였다. 그러나, 더블클릭은 사업 모델로 인해 절대적인 제약을 갖고 있다. 더블클릭은 참여가 아닌 발행, 소비자가 아닌 광고주가 지배하며, 규모가 중요하다고 여겼던 90년대의 일반적인 개념을 받아들였으며, 인터넷은 미디어메트릭스(MediaMetrix)나 기타 웹 광고 기록에 의해 측정된 상위 웹 사이트들에 의해 점차적으로 지배되고 있었다.

결과적으로 더블클릭은 자신들의 소프트웨어를 2000곳 이상에 성공적으로 구현했다고 인용하고 있다. 반면에, 야후 검색 마케팅(이전에는 오버추어)와 구글 애드센스(AdSense)는 각지에 수십만의 광고주를 제공하고 있다.

오버추어와 구글의 성공은 크리스 앤더슨(Chris Anderson)이 롱테일(Long Tail)이라 언급한, 웹 컨텐트들의 대부분을 차지하는 작은 사이트들의 집단의 힘(collective power)을 이해하는 것에서 알 수 있다. 더블클릭이 판매하는 것은 전형적인 판매 계약서가 필요하고, 그들의 시장을 몇 천개의 큰 웹 사이트들로 시장이 제약되어 있다. 오버추어와 구글은 실제로 거의 모든 웹 페이지에 광고를 둘 수 있음을 이해하고 있다. 뿐만 아니라 발행인/광고 대행사에게 친숙한 배너 광고, 팝업과 같은 광고 포맷을 지양하고, 소비자에게 친숙한 텍스트, 문맥 기반, 최소한도로 사용자에게 간여하는 광고를 제공한다.

웹 2.0의 레슨: 전체 웹 특히, 중심이 아니라 주변부에, 머리가 아니라 긴 꼬리에 도달하기 위해 고객 스스로 사용할 수 있는 서비스와 알고리즘을 이용한 데이터 관리를 제공하라

플랫폼이 응용 프로그램을 이긴다

마이크로소프트는 과거 라이벌과의 경쟁에서 플랫폼 카드를 내놓은 것으로 시장을 지배하고 있는 응용 프로그램들을 물리치는데 성공해왔다. 마이크로소프트는 윈도우를 이용해서 로터스 1-2-3을 엑셀로, 워드퍼펙트는 워드로, 넷스케이프 네비게이터는 인터넷 익스플로러로 대체했다.

그러나, 이번에 벌어지는 충돌(clash)은 플랫폼과 응용프로그램간의 충돌이 아니라 극단적으로 다른 비즈니스 모델을 가진 두 플랫폼간의 충돌이다. 한쪽은 단독 소프트웨어 제공자로 많은 시스템에 설치되는 것을 기반으로하며, 긴밀하게 통합된 운영체제와 API를 통해서 프로그래밍 패러다임에 대한 제어권을 갖고 있으며, 다른 한쪽은 소유자 없는 시스템으로 프로토콜 집합에 의해 상호 연결되어 있으며, 협동을 위한 오픈 표준과 화합(agreements)[5]을 기반으로 하고 있다.
([5]역주: agreements는 협약의 의미로 번역되는 것이 대부분이다.)

윈도우는 소프트웨어 API를 통한 전유권(proprietary control)의 정점을 대표한다. 넷스케이프는 마이크로소프트가 다른 경쟁자들에게 사용했던 것과 같은 방법을 사용해서 마이크로소프트로부터 제어권(control)을 빼앗으려 했지만 실패했다. 그러나, 웹의 오픈 표준을 유지하고 있는 아파치는 지속적으로 번영하고 있다. 플랫폼 vs 응용 프로그램이 아니라 플랫폼 vs 플랫폼인 지금의 경쟁은 더 이상 불공평한 것이 아니다. 이제 문제는 어떤 플랫폼이 될 것인가, 즉, 어떤 아키텍처, 어떤 비즈니스 모델이 앞에 놓여있는 기회에 더 적합한가이다.

윈도우는 초기 PC 시대의 문제들에 대한 뛰어난 해결책이었다. 윈도우는 이전까지 업계를 괴롭혀왔던 많은 문제들을 해결했으며, 응용 프로그램 개발자이 동등한 조건으로 자유롭게 경쟁하는 장(the playing field)을 마련해 주었다. 그러나, 단일 업체가 모든 것을 제어하는 독점적인 접근 방법은 더 이상 해결책이 아니며, 바로 그게 문제가 되었다. 플랫폼으로서의 인터넷과 같은 커뮤니케이션 지향 시스템에서는 상호운영성이 요구된다. 단일 업체가모든 상호 작용의 양측을 제어할 수없다면, 소프트웨어 API에 사용자가 갇힐 가능성은 낮을 것이다.

자신의 응용 프로그램안에 가둘 기회를 엿보고 있는 웹 2.0 벤더는 정의상 플랫폼을 제어함으로써 얻게 될 것이지만, 더 이상 플랫폼의 장점을 가질 수 없을 것이다.

감금(lock-in) 효과나 경쟁 우위(competitive advantage)와 같은 기회가 없다고 말하는 것은 아니다. 그러나, 이런 것들을 소프트웨어 API나 프로토콜에 대한 제어권을 통해서 찾을 수 없다고 얘기하는 것이다. 이제 새로운 게임이 시작된 것이다. 웹 2.0시대에 성공하는 회사는 PC 소프트웨어 시대의 법칙으로 돌아가려 시도하는 회사가 아니라 게임의 법칙을 이해하는 회사들이 될 것이다.


놀라운 일은 아니지만, 다른 웹 2.0 성공 스토리들도 이와 같은 행동들을 보여주고 있다. 이베이(eBay)는 자동 중개자처럼 행동하는 개인들 간에 소액 거래를 가능하게 했다. 법적인 이유로 문을 닫긴 했지만 냅스터는 중앙집중방식의 노래 데이터베이스를 구축하는 대신에 노래를 다운 받는 사람이 서버가 되어 업로드를 하는 식으로 네트워크를 성장시키는 시스템을 구축하는 것으로 네트워크를 구축했었다.


아카마이(Akamai) vs 비트토런트(BitTorrent)

더블클릭(DoubleClick)과 마찬가지로 아카마이는 꼬리가 아니라 머리와, 모서리가 아닌 중심부와의 비즈니스에 최적화되어 있다. 아카마이는 중심부에 있는 수요가 많은 사이트들에 대한 액세스를 경감시키는 것으로 웹의 주변부에 있는 개인들에게 이익을 제공하는 한편, 중심 사이트로부터는 수익을 모아간다.

P2P 운동에서 다른 선구자들과 마찬가지로 비트토런트는 인터넷 탈중심화(decentralization)에 대해 급진적인 접근방법을 취했다. 모든 클라이언트는 클라이언트인 동시에 서버이다. 파일은 다양한 장소에서 제공받을 수 있는 조각으로 쪼개지고, 다른 사용자들의 대역폭과 데이터를 제공하기 위해 다운로더들의 네트워크를 투명하게 이용한다. 실제로, 인기가 있는 파일일수록 더 많은 사용자들이 완전한 파일을 만들 수 있는 조각들과 대역폭을 제공하기 때문에 더 빠르게 다운로드할 수 있다.

따라서, 비트토런트는 웹 2.0의 핵심원칙을 설명하고 있다: "더 많은 사람들이 사용할 수록 서비스는 자동으로 더욱 우수해진다." 아카마이는 서비스를 향상시키기 위해 서버를 추가해야하지만, 비트토런트는 모든 사용자가 자신의 리소스를 전체에 내놓으면 된다. 지능형 브로커처럼 서비스가 동작하고, 사용자들을 상호 연결시키고, 사용자들의 힘을 이용하는 것에는 협동에 대한 기본 윤리, 즉 암묵적인 "참여의 아키텍처"가 있는 것이다.


2. 집단 지능(collective intelligence)을 이용한다

웹 1.0 시대에 태어나서 웹 2.0 시대를 이끌어가면서 남아있는 거인들의 성공뒤에는 중앙화 원칙(central principle)이 있으며, 이것이 바로 거인들이 집단 지능을 이용하기 위해 웹의 힘을 받아들이고 있다.

  • 하이퍼링크는 웹의 근본이다. 사용자가 새로운 컨텐트, 그리고 새로운 사이트들 추가함에 따라, 컨텐트를 발견하고, 그것을 링크하는 다른 사용자에 의해 웹의 구조에 연결된다. 두뇌에서 시냅스가 많이 형성될수록 연상작용은 반복 또는 강화에 의해 더 강력해지는 것처럼, 모든 웹 사용자의 집단 행동의 결과로 웹의 연결은 유기적으로 성장한다.

  • 첫번째 인터넷 성공 신화인 야후는 수천개의 베스트 사이트들의 카탈로그, 또는 디렉토리 링크를 제공하면서 시작했으며, 현재는 수백만의 웹 사용자를 갖고 있다. 야후가 다양한 종류의 컨텐트를 생산하는 비즈니스 방식으로 옮겨가는 동안, 네트워크 사용자들의 집단 작업에 대한 포탈의 역할은 가치의 중심으로 남아있다.

  • 검색분야에서 의론의 여지없이 빠르게 검색시장의 리더가 된 구글의 눈부신 도약은 보다 나은 검색 결과를 제공하기 위해 문서의 특징을 파악하는 대신 웹의 링크 구조를 이용한 페이지랭크(PageRank) 때문이었다.

  • 이베이의 상품은 사용자들의 집단 활동에 의한 것이다. 웹 그 자체와 같이 이베이는 사용자들의 행위에 반응하면서 유기적으로 성장하였다. 회사의 역할은 사용자 행위가 발생했을 때 이를 실행하는 도구로 동작하는 것이었다. 뿐만아니라, 이베이의 경쟁 우위는 매력이 심각하게 감소되지 않는(significantly less attractive) 유사한 서비스를 제공하는 새로운 참가자를 만들어 내는 구매자와 판매자의 임계 집단(Critical Mass)에 있다.

  • 아마존은 반즈앤노블 같은 경쟁자와 동일한 상품들을 판매하며, 상품의 생산자로부터 동일한 상품 설명, 커버 이미지, 편집 내용을 받는다. 그러나, 아마존은 사용자 참여의 과학을 사용한다. 아마존은 사용자 리뷰 평가를 갖고 있을 뿐만 아니라, 거의 모든 페이지에서 다양한 방법으로 사용자를 참여시키기 위한 제안을 한다. 게다가, 보다 나은 검색 결과를 보여주기 위해 사용자 행위를 사용한다. 반즈앤노블 검색이 해당 회사의 상품이나 스폰서 결과로 유도하고 싶어하는 것과 달리 아마존은 판매지수와 아마존 내부에서 상품 주변의 "흐름(flow)"이라 부르는 다양한 요소들에 기반한 실시간 계산 결과에 따라 "가장 인기있는" 상품을 보여준다. 보다 많은 사용자가 순위 시스템에 참여하기 때문에 아마존의 판매고가 경쟁자들의 판매고를 크게 앞지르는 것은 당연하다.

이제, 이런 통찰등을 선택하고, 앞으로 이를 확장해나갈 혁신적인 회사들은 웹에 흔적들 만들고 있는 중이다.

  • 위키피디어(Wikipedia)는 웹 사용자가 내용을 추가할 수 있다는 생각지도 못한 생각에 기반한 온라인 백과사전으로오픈 소스 소프트웨어의 에릭 레이몬드의 격언 "많은 사람들이 검토할 수록 버그는 줄어들 것이다"을 컨텐트 작성에 적용한 신뢰에 대한 극단적인 실험이다. 위키피디어는 이미 상위 100개 사이트에 들었으며, 머지않아 상위 10개 사이트에 들어갈 것이라 예상하고 있다. 이것은 컨텐트 작성의 원동력에 깊은 변화를 가져왔다.

  • 최근에 많은 주목을 받고 있는 두 회사, 델리셔스(del.icio.us)와 플리커(Flickr.com) 같은 사이트들은 일부 사람들이포크소노미(Folksonomy)라 부르는 개념을 개척하고 있다. 이들 회사는 사용자가 마음대로 선택한 키워드를 사용해서 사이트를 집단 카테고리화하는 스타일을 제공하며, 이를 종종 태그(tags)라 부른다. 태깅을 사용하면 경직된 카테고리와 달리 태그를 사용하는 두뇌들의 연관관계들이 중첩되는 것을 허용한다. 이런 예로 강아지(puppy)에 대한 플리커 사진은 "puppy"나 "cute" 둘 다 태그로 지정할 수 있다. 이는 사용자 행위가 생성한 자연적인 정보에 따른 검색을 가능하게 한다.

  • Cloudmark 같은 협업형 스팸 필터링 제품은 무엇이 스팸이고 무엇이 스팸이 아닌지에 대한 이메일 사용자 개개인의 결정을 취합하여 필터링하기 때문에 메시지 그 자체에 대한 분석에 기반한 시스템보다 성능이 뛰어나다.

  • 가장 위대한 인터넷 성공 스토리는 자신들의 상품에 대해 광고하지 않는다. 성공 스토리에 대한 인용에 의해 "구전 마케팅(viral marketing)"- 사람에게서 사람으로 직접적으로 전파되는 추천-이 영향을 발휘한다. 사이트나 상품에 대한 말을 꺼내기 위해 광고에 의존한다면 그것은 웹 2.0이 아니다.

  • 대부분의 웹 서버에서 사용되는 리눅스, 아파치, MySQL, Perl, PHP, Python 코드를 포함해서 웹 인프라스트럭쳐의 대부분은 오픈 소스의Peer-production에 의존한다. 이들 자체는 각각의 집단이지만 넷을 통한 지능형을 가능하게 한다. 소스포지(sf.net)에는 10만개 이상의 오픈 소스 소프트웨어 프로젝트가 있으며, 누구든지 프로젝트를 추가할 수 있으며, 코드를 다운로드 받고 사용하는 것이 가능하다. 새로운 프로젝트는 사용자가 자신의 코드를 내놓음으로써 주변부에서 중심부로 이동하는 길이 열려있다. 유기적인 소프트웨어 적응 과정은 전적으로 구전 마케팅에 의존한다.

[6]역주 참고

  • 포크소노미(Folksonomy)는 사람들(Folks)과 분류법(Taxonomy)의 합성어로 사람들에 의한 분류법을 의미하며, 여기에는 델리셔스등의 태깅에서 키워드까지의 범주들이 모두 포함될 수 있다. 델리셔스, 플리커, 43 Popular Things, 테크노라티와 같은 태깅 적용에 관심이 있다면TagCloud를 방문하기 바란다.(Tag은 "택"이며 "태그"는 아닌것처럼 TagCloud는 "택클라우드"여야 한다)
  • 위키피디어 포크소노미
  • Lastmind.net의 Folksonomy

교훈: 사용자 기여에 의한 네트워크 효과는 웹 2.0 시대에 시장 지배력의 핵심이다.@

 

저자 : Tim O'Reilly

번역 : 한동훈 역
원문 :http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html

 

사용자 삽입 이미지

 

출처 :http://network.hanbitbook.co.kr/view.php?bi_id=1141

  Comments,     Trackbacks
RFID의 개념과 분류, 그리고 발전 뱡향

RFID의 개념과 분류, 그리고 발전 뱡향

 

사용자 삽입 이미지
  2차 세계대전 당시 사용된 RFID(Radio Frequency IDentification)는 현재 새로운 유비쿼터스 세계를 열어갈 기술로 대두되고 있다. RFID는 오래된 기술이긴 하지만 많이 알려져 있거나 대중화된 기술이 아니다. 최근에 다시금 RFID 기술이 각광받는 이유는 전파 기술의 발전과 함께 미국방성이나 월마트, 테스코와 같은 기관과 업체들이 앞다투어 적용에 나섰기 때문이다. RFID 개념과 분류 그리고 발전 방향에 대해 알아보자.

 

RFID 기술은 각 주파수 대역별 RF 신호를 사용해 객체들을 식별하는 비접촉 인식기술 중 하나로, 일대 다수의 인식 등 기존의 인식 체계와 비교해 볼 때 한층 진보된 인식 체계다. 이미 2차 세계대전 당시 영국에서 상대편 전투기의 적군과 아군 여부를 파악하는 데 사용하기 시작한 RFID는 1970년대에는 미사일 탄도 추적을 위해 개발됐다. 1980년대에는 태그의 크기가 작아지고 가격이 낮아지면서 가축관리, 상품의 유통관리 등 기타 산업 분야에 적용되기 시작했으며, 1990년대 들어서면서 고주파 기술이 발전함에 따라 저가격, 고기술의 태그가 개발되고 카드, 라벨, 동전 등 다양한 형태의 제품이 출현하게 됐다. 2000년대 들어서 무선 인식 기술의 중요성이 부각되면서 다양한 솔루션이 개발되고 전자화폐, 물류관리, 보안시스템 등의 핵심 기술로 적용, 발전하고 있다.

 

 

비접촉식 인식 시스템, RFID


그동안 사람, 동물, 상품 등에 대한 자동식별방법은 여러 가지 방식이 사용돼 왔다. 대표적인 종류인 바코드시스템은 일용품 산업계 요구에 의해 1976년에 설계된 것으로, 지난 20년간 가장 성공한 자동인식 시스템으로 평가받고 있다. 이외에 광 문자 인식(Optical Character Recognition)은 1960년에 처음 사용됐으나 다른 자동인식 시스템에 비해 비싸고 복잡해 사장됐으며, 최근에는 생체의 개별적인 특성, 즉 지문, 음성, 홍채 등을 인식하는 생체인식 기술이 또 하나의 각광받는 분야로 떠오르고 있다.


스마트카드는 전자식 데이터 저장 시스템으로, 1984년에 처음으로 공중전화 카드에 사용됐다. 접촉부분을 통한 직렬 인터페이스를 통해 카드와 리더 간에 쌍방향으로 데이터 전달이 이뤄지며, 메모리카드와 계산가능카드로 세분된다. 과거의 인식 시스템 혁명을 주도한 바코드는 매우 저렴하지만, 저장 능력이 작고 재 프로그래밍이 불가능하다는 단점을 안고 있었다. 기술적으로는 실리콘칩에 데이터를 저장하는 것이 효과적이지만, 기존의 신용카드와 같은 접촉방식의 스마트카드는 기계적인 접촉이 필요하다는 결점을 갖고 있다. 은 사용하기에 실용적이지 못하다는 결점을 갖고 있다. 그보다 데이터 운반 장치와 리더간의 비접촉식 데이터 전달이 보다 더 실용적이며, 이와 같은 비접촉식 인식 시스템을 바로 RFID 시스템이라고 한다.


리더(Interrogator), 안테나, 태그(Transponder) 등으로 구성되어 있는 RFID는 사람, 차량, 상품, 교통카드 등을 비접촉으로 인식하는 기술이다. 일반적으로 많이 사용되는 수동형 태그 시스템은 RFID 리더/라이터가 RF 신호를 태그에 송신하고, 태그는 RF 신호가 들어오면 진폭 또는 위상 변조해 태그에 저장된 데이터를 반송파 신호로 리더에 되돌려 주고, 되돌려 받은 변조신호는 리더에서 복호화돼 태그 정보가 해독되는 것이 기본원리이다.


RFID 시스템은 고유 데이터를 담고 있는 태그와 태그의 정보를 판독하기 위해 읽어들이기 위한 리더, 그리고 이렇게 모여진 데이터를 처리하기 위한 일련의 컴퓨팅 시스템으로, 데이터 수집 기술의 하나라 할 수 있다. 그리고, 이 RFID 기술은 미들웨어를 비롯한 몇 가지 기술요소의 결합을 통해 솔루션으로 구현되어 활용되는 것이 일반적이다.


하지만 RFID 시스템은 그렇게 단순하지 않다. RFID는 태그와 리더, 그리고 미들웨어를 거쳐 수집된 데이터와 기업내 애플리케이션과의 연계를 생각하지 않고는 도입 이유가 없다. RFID 시스템과 기업의 내부 애플리케이션 간을 유기적으로 연동하려면 데이터를 제대로 관리하고 분석해야 하며, 담당자들의 정보 접근이 쉬워야 한다. 또한 기업 내부적으로만 RFID 시스템을 운영하고 글로벌 네트워크 표준을 따르지 않는다면, 앞으로 RFID의 진정한 효과를 누리지 못하게 된다.

 

 

RFID의 시스템 구성


RFID 시스템의 구성 요소 중 디바이스 계층은 태그 데이터 수집 기능을 수행하며, 일반적으로 코드라 불리는 고유 정보를 저장하는 태그와 무선을 통해 태그의 정보를 판독하고 식별 기능을 하는 리더로 구성된다.


미들웨어 계층은 디바이스 계층으로부터 수집된 상품코드 데이터를 애플리케이션 계층에서 효과적으로 사용할 수 있도록 처리하며, 대규모 데이터 환경에서 실시간 지원 등의 서비스를 제공한다. 또한 애플리케이션 계층과 리더를 제어하는 하위 디바이스 계층 간의 프로그래밍 API(Application Programming Interface) 등을 제공한다. 마지막으로 애플리케이션 계층은 물류(Logistics), 공급망관리(SCM)와 같은 애플리케이션 소프트웨어로 구성된다.

 

 

RFID 디바이스 계층


RFID 리더(reader)는 일반적으로 미들웨어를 통해 ERP나 SCM 같은 기업용 애플리케이션과 연결된다. RFID 리더는 태그로부터 우선 EPC 코드를 읽어들이며, 부가적인 정보의 존재 여부에 따라 제품의 상세 정보나 유통 기간 등도 함께 읽는다. 일단 이 데이터가 수집되면, 리더 내의 소프트웨어가 백앤드 시스템을 통해 EPC 코드를 검사할 수 있으며, 몇몇 비즈니스 시나리오 내에서 리더는 데이터 전송을 감소시키기 위해 복수 대상물로부터 인식한 정보를 수집한다.


RFID 리더는 그 위치에 따라 다양한 형태를 갖는데, 현장의 적용 환경이나 활용 목적 등에 따라 최적의 장비를 적절히 활용할 수 있다.


태그의 종류는 읽기/쓰기 능력에 따라 읽기전용(Read-Only), WORM(Write Once Read Many), 읽기/쓰기(Read/Write) 태그의 세 가지 방식으로 구분된다. 읽기 전용 태그는 만들 당시부터 프로그래밍돼 정보의 변경이 불가능하다. 그러나 가격이 저렴해 단순 인식을 요하는 RFID 분야에 주로 사용된다. WORM 태그는 사용자가 데이터를 프로그래밍할 수 있으며, 프로그램 한 후에는 변경이 불가능하다. 읽기/쓰기 태그는 몇 번이고 프로그램이나 데이터 변경이 가능한 구조이다.


태그 상에 신호발진기 존재 여부에 따라 능동형 방식과 수동형 방식으로 분류하기도 하는데, 보통 협의의 분류방식으로 태그의 전원유무에 따라 전원이 요구되는 능동형 방식과 전원이 요구되지 않는 수동형 방식으로 분류된다. 일반적으로 전원을 사용하지 않는 수동형 방식은 감지거리가 1m 전후의 근거리 통신만 가능했지만, UHF 대역의 도입으로 출력에 따라 5~8m도 가능하다. 또한 가격이 저렴하고 수명이 반영구적(약 10년이상)이어서 많이 사용된다.


이처럼 RFID 태그에는 다양한 종류가 있어 프로젝트 수립 시 주파수 대역이나 활용 시나리오와 가격 등을 고려해 적합한 태그를 선정하는 작업도 중요하다. 산업표준 단체인 EPC 글로벌은 이를 보다 명확히 하기 위해, 유통 공급망과 관련해 6가지 유형으로 RFID 태그를 구분하고 있다(표 1).


생산 단계에서 이미 EPC 번호가 부여된 클래스 0 태그부터 저장 기능과 배터리 장착 유무 등에 따라 클래스 5까지 나눠지지만, 가격 등의 문제로 현재 국내외 주요 RFID 프로젝트에는 클래스 0나 클래스 1을 적용하는 것이 일반적이다.


UHF 대역 RFID 태그에 대해 ISO 18000-6에 의해 2가지 타입(타입 A와 타입 B)이 국제표준으로 확정됐다. 그러나 현재 널리 알려진 RFID 국제 표준단체인 EPC글로벌은 ISO와 다른 클래스 0과 클래스 1의 태그를 사용해 왔다. 따라서 UHF 대역에서 사용할 수 있는 표준 태그는 ISO 타입 A, 타입 B, EPC 클래스 0, 클래스 1의 무려 4가지 태그가 존재해 하나의 리더가 이를 완전히 수용할 수 없는 체제가 됐다. 작년 12월 EPC글로벌은 클래스 0와 클래스 1 태그를 통합해 최신 기술을 반영한 EPC클래스 1 Generation 2(Cl Gen2라 함) 태그에 대한 표준화를 완성했다. UHF 대역에서 표준의 혼란을 방지하기 위해 ISO와 EPC글로벌 표준간의 통합이 강하게 요구돼 오던 터에 올해 6월 EPC C1 Gen2가 ISO의 18000-6 타입 C로 확정됨에 따라 사실상 글로벌 표준으로 정해졌다. 


이번에 확정된 ISO 18000-6의 신규타입(타입 C)은 태그에 EPC 코드 외에 일반 산업용 데이터 코드를 기록할 수 있고 ISO 표준만 준수한다면 다양한 응용 분야에서 멀티코드 리더기로 호환성 문제없이 RFID 태그 데이터를 읽어낼 수 있다는 것이 장점. 특히 업체마다 다른 RFID 프로토콜을 사용함에 따라 빈번하던 시스템 오류나 업무의 혼선이 사라지는 등 RFID 확산의 중대한 걸림돌 하나가 제거됐다는 의미를 가진다.

 

사용자 삽입 이미지

 

 

RFID 소프트웨어


일반적으로 리더에서 읽혀진 태그의 데이터는 유무선 네트워크를 거쳐 데이터 처리를 담당하는 호스트 컴퓨터(Server)의 미들웨어로 전달돼 처리된 후, 해당 애플리케이션에 의해 사용된다. 이런 글로벌 RFID 환경에서 수집, 활용되는 데이터는 객체에 대한 정적 데이터와 이력 데이터, 센서로부터 얻는 실시간 데이터를 포함하고 있기 땜누에 이를 활용하는 애플리케이션은 상황인식 기반의 지능화된 서비스를 제공할 수 있다.


RFID 미들웨어란 애플리케이션 계층과 디바이스(리더) 계층 사이에 위치하며, 이기종 RFID 환경에서 발생하는 대량의 태그 데이터를 수집, 필터링해 의미있는 정보를 추출해 애플리케이션에 전달하는 소프트웨어로 정의될 수 있으며, 다음과 같은 3가지의 기본적인 역할을 수행한다.

 

 

·RFID 하드웨어 관리
미들웨어는 RFID 리더나 라벨 프린터 등과 같은 하드웨어 컴포넌트와의 환경 구성을 통해 손쉬운 통신을 지원하며, 이들 하드웨어를 관리하기 위한 사용자 인터페이스를 제공한다.

 

·태그로부터 생성된 데이터 처리와 애플리케이션과의 연동
태그와 RFID 리더에 의해 생성된 방대한 데이터, 즉 리더에 의해 동일 태그가 반복적으로 읽혀졌다거나 잘못 읽혀진 값들을 필터링 기법을 통해 적절히 정제한 후, 이를 적절한 기업용 애플리케이션에 넘겨주는 역할을 수행한다.

 

·아키텍처 제공
미들웨어는 사용자가 비즈니스의 필요에 따라 적합한 솔루션을 구축할 수 있도록 기업 환경에 적합한 소프트웨어 아키텍처를 제공해야 한다. RFID 미들웨어가 제공하는 아키텍처는 싱글티어 아키텍처와 멀티티어 아키텍처 2가지로 나눠 볼 수도 있다(그림 2, 3).

 

사용자 삽입 이미지

사용자 삽입 이미지

(그림 3) RFID 멀티티어 아키텍처

 

 

EPC 중심으로 RFID 표준화 진행


EPC 글로벌과 ISO/IEC를 비롯, 여러 단체에서 RFID에 대한 표준을 제정 중에 있다. 그 결과, 객체에 대한 식별 코드로는 EPC 코드, ISO 15963, uID 등 다양한 코드 체계가 개발됐다. 하지만 최근 월마트, 베스트바이 등에서 이미 EPC 코드를 사용함에 따라 EPC 코드가 이미 표준으로 자리잡아 가고 있다. EPC글로벌은 RFID 미들웨어를 포함한 글로벌 RFID 네트워크 모델인 EPC 네트워크를 제시하고 있다. 


EPC글로벌은 기존 MIT Auto-ID 센터에서 개발한 RF 기반의 자동인식 시스템 기술을 표준화하고 상용화하기 위해 2003년 10월에 설립된 비영리기구로, Auto-ID 센터에서 개발한 기술의 표준화, 상용화, 그리고 EPC 코드의 보급과 관리 등을 목적으로 활동하고 있다.


EPC글로벌은 개별 물체의 유일 식별자인 EPC 기반의 'Internet of Physical Objects'를 구성하기 위한 기술집합을 EPC 네트워크라 정의하고, EPC 네트워크의 구현에 따른 기술요소 분야를 하드웨어, 소프트웨어, 비즈니스 분야로 구분해 각 분야별 활동 그룹을 구성, EPC글로벌 가입 업체 중심으로 기술규격과 표준제정을 추진하고 있다. 특히 RFID 미들웨어와 네트워크 시스템과 관련된 소프트웨어 인터페이스, 표준 제정은 SAG에서 진행되고 있다.


SAG는 리더 프로토콜(Reader Protocol), 리더 관리(Reader Management), 필터링과 정보 수집, EPCIS(EPC Information Service), ONS(Object Name Service), 태그 데이터 변환(Tag Data Translation), 시큐리티의 총 7개 주제에 대해 분야별 활동 그룹을 통해 EPC 네트워크를 구성하기 위한 표준규격을 제시하고 있다.


ONS의 경우, 사실상 DNS와 유사한 성격과 구조를 지니고 있다. DNS의 웹사이트, 검색엔진, 시큐리티는 각 EPC 인포메이션 서비스(Information Service), EPC 검색 서비스(Discovery Service), EPC 인증 서비스로 대응된다. 시큐리티는 리더를 관리하는 업체가 정보 범위를 사전에 규정해 놓고 고객이나 파트너가 정보를 열람할 때에는 인증 절차를 거치도록 하고 있다.


EPC글로벌이 제안한 EPC 네트워크 구조와 구성요소를 살펴보면, 리더는 리더 인식공간에 존재하는 복수 개의 태그를 인지한다. 이렇게 인식된 태그 데이터는 리더 프로토콜을 통해 리더로부터 미들웨어로 전달된다. 미들웨어는 리더로부터 전달된 복수 개의 중복된 태그 데이터를 필터링하는 역할을 수행하고, ALE 인터페이스를 통해 통합/정제된 태그 데이터 목록이 미들웨어에서 EPC 캡처링 애플리케이션(Capturing Application)으로 전달된다. 다시 EPC 캡처링 애플리케이션은 미들웨어로부터 전달받은 태그인식정보와 기타 비즈니스적 관련정보를 EPCIS에 공급하게 되고, 이러한 정보들은 EPCIS 지원 레파지토리(enabled repository)에 저장/관리돼 앞으로의 질의에 대응할 수 있도록 한다. EPCIS 액세싱 애플리케이션(accessing application)과 파트너 애플리케이션은 EPCIS에서 제공하는 인터페이스를 통해 EPCIS에서 관리하고 있는 EPC와 관련된 정보를 질의하고 그에 대한 결과를 활용해 비즈니스 활동을 수행하게 된다. 기타 EPC 검색 서비스는 EPC와 관련된 데이터의 검색엔진으로 특정 EPC와 연관된 데이터를 저장하고 있는 EPCIS의 위치정보 목록을 질의의 응답으로 하는 서비스 제공자다.

 

사용자 삽입 이미지

 

쉽게 풀어서 설명하면, 리더가 태그로부터 받은 데이터를 EPCIS에 저장하면 이 정보를 고객이나 파트너들이 볼 수 있게끔 하는 네트워크다. EPCIS는 EPC 코드를 부여받은 제조업체들이 자사에서 생산하는 객체(제품)에 대한 상세 정보를 담아 놓는 서버를 말한다. 고객이나 파트너들은 ONS를 통해 각 생산 제조업체의 서버(EPCIS)에 저장돼 있는 각 객체(제품)에 대한 생산 정보를 검색할 수 있다.


EPC글로벌 네트워크는 현재 기본적인 서비스는 가능하나, 아직 시범적으로 운영하고 있다. 또한 프라이버시 문제로 소비자에게는 시장 확산 이후에나 공개할 것으로 보인다.
RFID는 기본 인프라다. 현제 각 기업들은 RFID를 구축하고 준비중에 있다. 이후 EPC글로벌 네트워크를 통해 수많은 정보와 데이터가 동시에 수면위로 올라왔을 때, 이를 활용할 수 있는 것은 미리 준비한 기업뿐이다. 준비한 업체와 그렇지 않은 업체간의 격차는 엄청날 것이다.

 

 

태그 가격의 하락으로 시장 폭발 조짐 보여


RFID 기술의 발전 단계는 태그의 기능에 따라 단순한 ID 인식 기능, 이력관리 기능, 환경정보 센서 기능, 태그 간 통신 기능으로 구분할 수 있다.


각 발전 단계별 요구되는 안테나 기술, RF 기술, 무선 접속(Air Interface) 기술, 칩 제작 및 공정기술, 소형 OS 기술, 미들웨어 기술, 정보보호 기술, 핵심 요소 기술 및 응용 기술, 표준화 기술의 발전 단계는 그림 에 나타낸 바와 같이 전망되고 있다.


이와 같이 RFID 기술의 USN으로의 연계 발전은 칩의 가격, 크기, 성능 등 태그(센서) 기술의 발전에 따라 시장에서의 적용이 활성화되는 단계적 발전을 예상할 수 있고, 태그의 소형화, 지능화로의 발전과 병행된 태그의 초저가화의 실현은 물류, 유통, 환경, 재해방지 및 예방, 의료관리, 식품관리 등 실생활에서의 활용이 확대될 것이다. 현재 읽기 전용 칩 가격은 5~20센트이고, 태그 가격은 약 10~50센트이나, 태그 가격은 18개월에서 24개월 내에 5센트 이하로 하락할 전망이며, 1센트 이하의 태그를 구현하기 위해 Chipless 태그 기술 개발에 대한 관심과 연구 개발이 확대되고 있다. 또한 2007년부터 Chipless 태그의 10%대의 시장 점유율이 기대되고 있다. 업계에서는 태그 가격이 5센트 이하로 하락한다면 시장이 확대되는 시점으로 파악하고 있지만 굳이 태그가 굳이 5센트가 돼야한다는 것은 아니다. 앞서 설명한대로 태그의 성격이나 용도에 따라 태그의 가격 또한 많은 차이를 보일 것으로 예상된다.


최근 순천대학교가 개당 5원 이하로 생산이 가능한 스티커형 플라스틱 RFID 태그칩 개발했다고 발표했으며, 잉크테크에서 칩프레스 기술을 이용한 RFID 태그 잉크를 선보이는 등 국내에서도 저가형 태그 기술 발표가 이어지고 있다. 특히 순천대의 태그 기술은 제조공정이 복잡하고 고가인 기존 제품과 달리 100% 유기물질과 잉크젯 프린터 만을 이용한 수동형 태그로, 대량 생산할 경우 제조물량에 따라 칩가격을 1∼5원 정도에 납품할 수 있다는 점에서 주목할 만하다. 순천대 측은 이번 기술이 종이, 플라스틱, 나무 등 모든 기판에 인쇄가 가능해 저가의 RFID 태그 제조를 통한 물류유통 시장에 획기적 전환점을 가져올 것으로 기대하고 있다.

 

 

미들웨어 탑재한 스마트리더로 진화
RFID 리더 기술은 기존의 무선, 이동통신용 단말기 기술과 매우 유사하다. 이런 단말기 기술은 크게 하드웨어 기술과 하드웨어를 제어하기 위한 펌웨어 기술을 포함한 소프트웨어 기술로 구분할 수 있다. 그러나, RFID 리더는 기존의 무선통신이나 이동통신 단말기와 비교해 매우 단순한 기능을 갖는다. 따라서 RFID 리더기술은 리더를 구성하는 하드웨어의 저가화, 저전력화, 고성능화, 고기능화를 제공하는 리더 칩 기술 개발에 주목하고 있다.


리더 기술의 발전 방향은 스마트리더로 발전한다는 것이 일반적인 예측이다. 미들웨어의 여러 기능을 리더에 탑재한 것이 바로 스마트리더다. 지금까지 대부분의 리더가 데이터 필터링 기능이 없어, 읽혀진 모든 데이터를 지속적으로 서버로 보내는 비지능형 리더였다. 이 때문에 데이터 양이 폭주할 가능성이 있었다. 기업에서 필요한 실시간 데이터는 비즈니스 이벤트가 일어났을 때의 그것이다. 스마트리더는 비즈니스 이벤트들만 필터링해서 관리 서버로 보내지게 함으로써 다양하고 역동적인 업데이트가 가능해진다.

 

 

저자 :이대영 기자

 

사용자 삽입 이미지


원문 :http://www.ionthenet.co.kr/newspaper/view.php?idx=10481&fhead_x=0&fhead_y=0

  Comments,     Trackbacks
[객체지향 SW 설계의 원칙] ③ 인터페이스 분리의 원칙

[객체지향 SW 설계의 원칙] ③ 인터페이스 분리의 원칙

 

연재순서
1회.
다시 보면 크게 보이는 개방-폐쇄 원칙
2히.헤어져서 행복해진 사례연구, 단일 책임 원칙
3회.인터페이스 분리의 원칙
4회. 리스코프 치환 원칙
5회. 의존 관계 역전의 원칙
6회. 정리

 

“사람은 다른 사람과 말을 할 때 듣는 사람의 경험에 맞추어 말해야만 한다. 예를 들어 목수와 이야기할 때는 목수가 사용하는 언어를 사용해야 한다.” - 플라톤의 파에톤(Phaethon)

“아무도 듣는 사람이 없는 숲 속에서 나무가 쓰러질 때 소리가 나는가?”라는 불가에서 유래한 질문이 있다. 그간 많은 현자들이 이 질문에 대해 ‘아니다’라는 일관된 대답을 해왔다. 소리는 지각되어야만 소리가 되기 때문에 나무가 쓰러질 때 음파는 발생하겠지만 듣는 사람이 없다면 소리는 없다는 것이다. 사람 사이의 커뮤니케이션도 마찬가지이다. 전달하려는 사람이 무언가를 외친다고 해도 듣는 사람이 없다면 커뮤니케이션은 없는 것이다.

만약 듣는 사람은 있지만 발신자가 수신자의 경험, 지식, 기대를 고려하지 않고 떠들어 대는 것은 어떨까? 이 역시 올바른 커뮤니케이션이라 할 수 없을 것이다. 수신자가 커뮤니케이션 메시지를 제대로 이해 또는 지각하지 못하거나, 기대와 어긋나 의식적으로 혹은 무의식적으로 메시지를 흘려버릴 가능성이 크기 때문이다. 그러므로 플라톤의 말대로 수신자의 경험, 역량 그리고 기대를 고려해 메시지를 전달해야만 제대로 된 커뮤니케이션이 될 수 있다.

맥킨지 일본 지사의 커뮤니케이션 스페셜리스트로 근무하고 있는 테루야 하나코는 좀 더 구체적으로 다음과 같이 이야기한다. “타인에게 무언가를 전하려고 할 때는 자신이 이야기하고 싶은 것을 어떻게 정리할까, 어떻게 말할까, 어떻게 쓸까를 생각하기 전에 반드시 과제(테마)와 상대방이 기대하는 반응을 확인하자.”

이 글을 읽고 있는 누구나 자신이 말하고 싶은 메시지를 더욱 잘 전달하기 위해 보고서를 몇 번씩 고치고 파워포인트의 디자인과 컬러에 공을 들여 본 경험이 있을 것이다. 그런데 혹시 이러한 노력이 과제 혹은 테마에 대해 자신이 말하고 싶은 것, 자신이 중요하다고 생각하는 것을 전달하기 위한 것은 아니었는지. ‘여러분’이 말하고 싶은 것, ‘여러분’이 중요하다 생각하는 것보다 더욱 중요한 것이 있다. 상대방이 전달받기를 기대하고 있는 ‘메시지’가 무엇이냐 하는 것이다.

여러분이 아무리 많은 준비를 했고, 많은 데이터를 축적했고, 하고 싶은 말이 많더라도 이러한 내용은 상대방의 기대라는 필터를 통해 여과되어 전달되어야 한다. 그렇지 않고 준비한 자료가 아까워서 이것저것 모두 전달하는 것은 수신자에게는 일종의 고역이다. 물론 준비한 노력과 자료 중 일부를 버려야 하겠지만 일부를 버리고 효과적으로 메시지를 전달하는 것이 모든 자료를 끌어 앉은 채 메시지를 허공 속으로 흘려보내는 것보다 훨씬 현명한 선택일 것이다.

객체지향 시스템은 메시지를 통해 커뮤니케이션하는 수많은 객체들로 구성된다. 그리고 이들 객체 간의 통신에도 앞에서 언급한 커뮤니케이션의 논리가 그대로 적용된다. 즉 상대방이 기대하고 있는 메시지를 ‘군더더기 없이’ 전달해야 하듯 서비스를 제공하는 객체는 자신을 이용하는 객체에게 해당 객체가 기대하는 서비스만을 제공해야 한다는 것이다. 이번 호에서 살펴볼 인터페이스 분리의 원칙(Interface Segregation Principle, 이하 ISP)이 바로 이러한 원칙을 설명해 준다.

인터페이스 분리의 원칙 개요
요즘 복제폰으로 인한 불법 결제가 사회적인 문제가 되고 있다. 특정 사용자의 폰 정보를 복제해 온라인상에서 불법 결제를 하는 것이다. 불법 결제자는 실물을 구매하거나 현금으로 환금 가능한 온라인 화폐 등을 결제하는데, 요금은 실제 폰 사용자에게 과금된다. 그래서 휴대폰 결제 서비스를 제공하는 모 업체에서는 이런 복제폰 사용자들의 패턴을 찾아 차단하고자 한다. 불법 결제 차단 시스템은 자사의 결제 시스템을 이용하는 각 컨텐츠 프로바이더(CP, Contents Provider) 별로 룰을 설정해 불법 결제 패턴에 해당하는 사용자의 결제를 차단하고, 이에 대해 회사 내부 담당자와 컨텐츠 프로바이더 담당자에게 특정 시간에 메일로 리포팅을 하게 된다. 이를 위해 이 회사의 개발자 A군은 다음과 같은 구조의 프로그램을 만들었다.

사용자 삽입 이미지
<그림 1> 초기의 불법 결제 차단 시스템


그런데 만약 이메일 리포팅 외에 SMS를 통한 리포팅 기능도 구현해 달라는 요청이 들어왔다면 어떻게 해야 할까? SMS와 관련된 메쏘드를 추가하거나, 현재의 이메일 관련 메쏘드를 SMS 관련 메쏘드와 통합해 getReportingRule과 같은 메쏘드를 만들어야 할 것이다.

그런데 이러한 메쏘드 추가는 이와는 전혀 상관 없는 BlockTransaction 클래스에게까지 영향을 미치게 되고, BlockTransaction 클래스의 재컴파일, 재배포 등과 똑같은 문제를 야기한다.

왜 이런 문제가 발생했을까? 원인은 BlockTransaction과 EmailReporting과 같은 클래스가 CPRule이 제공하는 서비스 중 일부만을 사용하는데 있다. CPRule 입장에서는 BlockRule과 EmailRule 모두를 갖는 것이 응집력 있는 구성이지만 BlockTransaction의 입장에서 보면 getEmailRule()은 필요없는 서비스이다. 역시 EmailReporting의 입장에서는 getBlockRule()이 필요없는 서비스라 할 수 있다. 즉 CPRule이 자신을 이용하는 클라이언트의 입장을 고려하지 않고 클라이언트에게 자기가 하고 싶은 말을 다 하고 있는 것이다. 현재는 CPRule을 이용하려면 모든 서비스를 이용하는 방법 밖에는 없다.

ISP를 통해 이런 문제를 해결할 수 있다. ISP를 간단히 정의하면 “클라이언트는 자신이 사용하지 않는 메쏘드에 의존 관계를 맺으면 안된다”는 것이다. 그런데 어떻게 자신이 사용하지 않는 메쏘드에 의존 관계를 맺지 않게 할 수 있을까? 답은 인터페이스를 사용하는 것이다. 이에 따라 앞의 프로그램 구조를 바꾸어 보면 다음과 같다.

사용자 삽입 이미지
<그림 2> ISP를 적용해 리팩토링한 불법 결제 차단 시스템


CPRule은 CPBlockRule과 CPEmailRule이라는 두 개의 인터페이스를 구현한다. 그리고 BlockTransaction과 EmailReporting은 CPRule을 직접 이용하지 않고 각각 자신의 기대에 맞는 인터페이스를 통해 CPRule이 제공하는 서비스를 이용할 수 있게 된다.

이제 SMS 관련 기능을 기존 이메일 기능과 통합해 제공하든, 별도로 제공하든 결제 차단 클래스는 전혀 변화의 영향을 받지 않게 된다. 결제 차단 규칙이라는 인터페이스가 이러한 변화의 방벽 역할을 해주기 때문이다. 그리고 SMS 기능을 이메일과 별도로 추가한다면 기존의 이메일 리포팅 역시 변화의 영향을 받지 않는다(이메일 기능과 SMS 기능을 통합할지 말지는 둘 사이에 얼마나 공통성과 유사성이 있느냐에 따라 달라지게 될 것이다).

ISP를 ‘하나의 일반적인 인터페이스보다는, 여러 개의 구체적인 인터페이스가 낫다’라고도 정의할 수 있다. 만약 어떤 클래스를 이용하는 클라이언트가 여러 개 있고, 이들이 해당 클래스의 특정 부분집합만을 이용한다면 이들을 따로 인터페이스로 빼내어 클라이언트가 기대하는 메시지만을 전달할 수 있도록 하는 것이다.

첫 연재에서 보았던 OCP에서는 ‘확장’이 핵심이었고 잘 정의된 공통의 인터페이스를 통해 수정에는 ‘닫고’ 확장에는 ‘열려 있는’ 구조를 만들었다. SRP에서는 ‘변화’가 핵심이었고 각 클래스가 하나의 책임만을 갖도록 하여 변화가 다른 클래스로 미치지 않도록 하는 구조를 가능케 하였다. 그러면 ISP의 핵심은 무엇일까? SRP와 마찬가지로 ‘변화’가 관전의 포인트가 된다. ISP는 뒤에서 설명하는 ‘ISP vs. SRP’에서 설명하듯이 어떤 클래스 혹은 인터페이스가 여러 책임 혹은 역할을 가질 수 있다는 것을 인정한다. 이러한 경우 ISP가 사용되는데 SRP가 클래스 분리를 통해 변화에의 적응성을 획득하는 반면, ISP에서는 인터페이스 분리를 통해 같은 목표에 도달하게 된다. 이제 전형적인 ISP 구조와 케이스 스터디로 넘어가기로 하자.

전형적인 ISP 구조
<그림 3>을 보면 Service 인터페이스는 3개 군의 메쏘드 집합을 제공하며 각 클라이언트는 이들 중 일부만 사용하고 있다. 그림과 같은 경우에는 Service 인터페이스의 어느 하나가 바뀌면 세 클라이언트 모두를 재컴파일, 재배포해줘야 한다.

사용자 삽입 이미지
<그림 3> ISP를 적용하기 전의 전형적인 구조


이제 <그림 3>에서 Service가 제공하는 메쏘드를 클라이언트가 사용하는 기준별로 그룹핑한다. 그리고 각 클라이언트는 자신의 기대에 부응하는 인터페이스만을 이용하게 된다. 이와 같이 인터페이스를 분리하면 한 클라이언트에서의 변화가 다른 쪽으로 확산되지 않는다.

사용자 삽입 이미지
<그림 4> ISP를 적용한 후의 전형적인 구조


자바 스윙이 제공하는 JTable 클래스는 이와 같은 ISP의 좋은 예제가 된다. JTable 클래스에는 굉장히 많은 메쏘드들이 있다. 컬럼을 추가하고 셀 에디터 리스너를 부착하는 등 여러 역할이 하나의 클래스 안에 혼재되어 있지만 JTable의 입장에서 본다면 모두 제공해야 하는 역할이다. JTable은 ISP가 제안하는 방식으로 모든 인터페이스 분리를 통해 특정 역할만을 이용할 수 있도록 해준다.

즉 Accessible, CellEditorListener, ListSelectionListener, Scrollable, TableColumnModelListener, TableMoldelListener 등 여러 인터페이스 구현을 통해 서비스를 제공하는 것이다. JTable은 자신을 이용하여 테이블을 만드는 객체, 즉 모든 서비스를 필요로 하는 객체에게는 기능의 전부를 노출시키지만, 이벤트 처리와 관련해서는 여러 리스너 인터페이스를 통해 해당 기능만을 노출시키고 있다.

수준에 따른 EAI 인터페이스
소프트웨어의 일반적인 목적은 업무를 자동화하고 인력을 시스템으로 대체화시키는 것이다. 이를 통해 새로운 비즈니스가 만들어지기도 하고 인간의 업무영역이 줄어들기도 한다. 지난 IT의 역사는 기업에서 사람이 행하던 업무를 전산화하여 업무의 효율을 극대화시키는 것이었다. 여러 가지 기술의 도움으로 점차 기업 시스템의 전산화가 차지하는 비율은 확대되고 있다. 하지만 실제 기업 업무가 그렇듯, 대부분의 비즈니스는 하나의 부서, 하나의 기업에서 완결되는 것이 아니라 서로 유기적인 소통을 통해서 이루어진다.

또한 기존에 구현된 시스템과 새로 구축되는 시스템간의 의사소통도 만만치 않은 작업이다. Aberdeen Group(
http://www.aberdeen.com/) 보고서에 의하면 이런 시스템간의 통합 요구는 시간이 지날수록 많아지고 있다. 이런 요구사항에서 등장된 개념이 EAI(Enterprise Application Integration) 개념이다. 즉 EAI는 기업 내, 기업 간의 서로 다른 애플리케이션 인터페이스를 통합하기 위해 제안된 기술이다.

사용자 삽입 이미지
<그림 5> 통합이 무시된 기업 시스템과 EAI로 구축된 기업 시스템


우리는 흔히 ‘인터페이스’라고 하면 객체나 컴포넌트의 인터페이스를 떠올리곤 한다. 하지만 인터페이스는 여러 타입과 여러 방식이 사용될 수 있으며 수준에 따른 EAI 인터페이스를 소개하면서 인터페이스의 개념을 확장하려고 한다. 다음은 EAI에서 분류하는 애플리케이션 통합을 위한 (인터페이스의) 종류이다. 더불어 결합도와 확장성의 관점을 더해서 생각해 보는 것도 좋을 듯하다.

데이터 수준의 통합을 위한 인터페이스
두 개 이상의 애플리케이션이 서로 통합하기 위해서 가장 간단한 방법은 한곳에 데이터베이스를 두고 모든 애플리케이션이 데이터베이스를 통하여 정보를 주고받는 것이다. 한 애플리케이션이 데이터베이스에 정보를 저장하면 그 정보에 관심있어 하는 다른 애플리케이션들이 그 정보를 발견하여 그 정보에 대한 처리를 한다. 즉, 이 때 데이터베이스는 하나의 애플리케이션들이 정보를 교환하는 일종의 인터페이스가 된다. 이런 아키텍처 스타일을 공유 리파지토리 패턴이라고 한다.

하지만 (잘 일어나지 않지만) 데이터베이스의 스키마가 변경되거나 새로 테이블이 추가되어 데이터베이스가 복잡해진다면? 즉 인터페이스가 바뀌거나 확장되게 된다면? 모든 애플리케이션이 이 구조에 따라서 애플리케이션이 변경되어야 한다. 즉, 잘 분리, 디자인되지 못하고 확장이 용이하지 못한 인터페이스는 거대한 변경에 대한 비용이 발생하게 된다.

또한 기존의 테이블 구조가 사용하려는 애플리케이션이 원하는 구조를 만족하지 못했을 때 데이터베이스에서 원하는 특정 정보를 다른 데이터베이스로 이동(migration)시키거나 여러 개의 데이터베이스에 있는 정보들을 취합하게 된다. 즉, 불필요한 인터페이스의 복제, 재정립하는 비용이 발생하게 된다. 이를테면 학사행정 시스템에서 ‘학생’ 데이터베이스와 ‘임직원’이란 데이터베이스가 있을 때 이 두 데이터베이스의 정보를 취합하여 ‘예비군’이란 데이터베이스가 만들어져야 하는 경우가 이에 해당한다.

사용자 삽입 이미지
<그림 6> 데이터 수준의 통합을 위한 인터페이스


이 방법은 매우 단순하고 빠르게 시스템 통합을 구축할 수 있다. 하지만 결과적으로 여러 다른 애플리케이션이 통합되기 위해서 중앙에 데이터 수준의 통합을 위한 인터페이스를 두고 모든 애플리케이션이 이 인터페이스에 맞춰야 한다. 이로써 확인되는 한계는 하나의 인터페이스가 여러 목적의 애플리케이션과 일대 다의 관계를 가질 때 여러 애플리케이션간의 관계가 하나의 인터페이스로 강결합되어 확장이나 변경의 자유도가 매우 떨어지게 된다. 이것은 ISP의 핵심인 “클라이언트가 자신이 사용하지 않는 메쏘드에 의존하도록 강제되어서는 안된다”는 원리에 위배된다. 이 구조는 인터넷 기반에 여러 서비스를 제공해야 하는, 따라서 인터페이스가 유연해야 하는 현대 시스템 상황에 적절하지 않은 방법이다.

또한 이 구조에서 중요한 축이 되는 데이터베이스가 변경이 될 경우 모든 애플리케이션이 같이 변경해야 하는 거대한 리스크를 안고 있다. 그리고 데이터베이스는 여러 애플리케이션이 원하는 인터페이스를 구축해야 하기 때문에 테이블 (인터페이스) 설계가 복잡하고 난해하게 이루어져 결국 이해를 위해 높은 진입장벽을 만나게 된다.

애플리케이션 수준의 통합을 위한 인터페이스
데이터 수준의 통합을 위한 인터페이스의 단점이 여러모로 확인된바 데이터가 아닌 API 수준의 통합이 제안된다. 기존에 우리가 사용하던 라이브러리나 패키지를 사용자(다른 애플리케이션)에게 제공하여 인터페이스를 통해 연동을 구축한다. 단순하고 독립적이지 않은 서비스의 경우 라이브러리나 패키지 형태로 배포되어 컴파일 타임에 바인딩하여 사용할 수 있다.

하지만 독립적인 애플리케이션간의 연동은 두 개 이상의 프로세스가 서로 통신(Inter-Process Communication)을 해야 하는데 IPC 방식에서는 연동을 위한 프로토콜이 정의되어야 한다. 즉, 프로토콜은 애플리케이션 간에 연동을 위한 인터페이스 역할을 한다. 나아가서 요즘 애용되고 있는 XML 전송에서 XML 스키마가 프로토콜과 같은 맥락을 갖는다. 좋은 IPC 구조를 위해서 잘 정의된 프로토콜이 전제되어야 한다. 프로토콜이 복잡하고 장황할수록 연동을 위한 비용이 많이 든다. 즉, 인터페이스가 지저분하지 않을수록 효과적이고 연동비용이 적게 든다. 실제로 잘 정의된 프로토콜(인터페이스)은 그 프로토콜 안에 여러 인터페이스를 식별하기 쉬운 구조를 제공한다(프로토콜 내의 ISP). 가령 HTTP의 경우 GET, POST, HEAD… 등의 메시지 식별이 단순하도록 구성되어 있다.

사용자 삽입 이미지
<그림 7> 애플리케이션 수준의 통합을 위한 인터페이스


세련된 인터페이스를 제공하는 기술이 RPC(Remote Procedure Call) 기술이다. RPC는 애플리케이션이 실제 함수 호출하듯 원격지에 있는 함수의 시그니처를 모방한 프록시를 두어, 그 프록시를 통해 원격 함수 호출을 제공한다. IPC 방식에서 RPC 방식으로 전환은 진화라 할 만큼 획기적이다. 프로토콜을 이용한 연동방식에서 원격 함수 호출을 이용한 호출방식으로 전환됐기 때문이다. 이것은 의미적으로 인터페이스를 더욱 단순하고 분리하기 쉽게 사용하도록 유도하고 있다.

비즈니스 로직 수준의 통합을 위한 인터페이스

애플리케이션 수준의 인터페이스와 비즈니스 로직 수준의 통합을 위한 인터페이스의 근본적인 차이점은 인터페이스의 형태가 일반 함수 수준에서 비즈니스 수준의 인터페이스를 제공한다는 것이다. 가령 전자의 경우 ‘복사’, ‘저장’, ‘~접근자’ 수준의 인터페이스를 제공하는데 반해 비즈니스의 경우 ‘입고’, ‘이체’, ‘결제’ 수준으로 인터페이스가 비즈니스화 되었다.

즉, 비즈니스 인터페이스는 분리된 객체 인터페이스의 묶음으로 해석할 수도 있다. 따라서 인터페이스가 큰 분류로 정의됨에 따라 복잡하던 인터페이스간의 관계가 단순하게 이루어진다. 객체 관계에 비교해 볼 때 컴포넌트 관계가 상대적으로 매우 단순하게 이뤄지는 이유가 여기에 있다. 정리하자면 비즈니스 인터페이스는 비즈니스 목적에 의해서 복잡한 객체 인터페이스를 구분하여 분류한 Facade (GoF의 Facade 패턴 참조) 역할을 한다.

사용자 삽입 이미지
<그림 8> 비즈니스 수준의 통합을 위한 인터페이스


이때부터 연동을 위해 본격적으로 CORBA, COM, EJB와 같은 기술들이 사용된다. 비즈니스 인터페이스를 통해 얻을 수 있는 이점은 비즈니스의 공유하여 재사용하기 위한 목적이다. 여기서 읽을 수 있는 현상은 잘 분리된 인터페이스는 재사용도가 높아진다는데 있다. 각 언어에서 제공하는 API는 근본적으로 재사용을 전제하기 때문에 인터페이스를 관찰해 보면 엄격하게 ISP 원칙을 지키고 있음을 볼 수 있다.

유저 인터페이스 수준의 통합을 위한 인터페이스
EAI에서의 유토피아는 모든 애플리케이션의 인터페이스를 접근하는데 있어서 마치 사람이 접근하듯이 접근하는 방법이다. 가령 엑셀에 연동하기 위해서 마치 사람이 엑셀을 다루는 것 같이 애플리케이션이 엑셀에 이벤트를 발생하여 연동하는 방식이다. 또 다른 예는 웹 서비스에 마치 사람이 웹 브라우저를 조작하여 문서를 요청하는 것 같이 애플리케이션이 HTTP 리퀘스트를 던져 결과를 얻어오는 것이다.

유저 인터페이스 수준의 통합을 위한 인터페이스는 이렇게 사람이 스크린을 통해 애플리케이션을 사용하듯 애플리케이션간의 연동이 이루어지는 방식을 말한다. 이런 요청을 스크린 카탈로그라 하며 이런 요청 방식을 스크린 스크래핑(screen scrapping)이라고 한다. <그림 9>는 애플리케이션이 여러 장의 스크린 카탈로그를 만들어 타겟 애플리케이션에 연동하는 장면이다.

사용자 삽입 이미지
<그림 9> 유저 인터페이스 수준의 통합을 위한 인터페이스


EAI 인터페이스 타입에서 본 바와 같이 컴포넌트의 확장성을 높이기 위해 결합도를 낮춰야 한다. 그렇기 위해 컴포넌트간의 관계에서 잘 분리된 인터페이스를 구성하여 관계를 단순화 하는 노력이 필요하다. 이 단순화된 관계는 컴포넌트간의 응집성을 향상시킨다.

인터페이스 분리 방법
SRP(지난 호 참조)에서 부분적으로 언급한 바와 같이 서로 목적이 다른 클라이언트가 하나의 인터페이스를 접근하고 있다면 그 인터페이스는 분리되어야 마땅하다. 왜냐하면 다른 클라이언트에 의해 나와 무관한 인터페이스가 변경됐을 때 그 변경으로 인해 내가 사용하는 인터페이스가 변경될 수 있기 때문이다. 따라서 서로 다른 종류의 클라이언트들이 하나의 인터페이스에 접근한다면 그 클라이언트의 종류만큼 인터페이스는 분리되어야 한다.

다시 처음에 예시한 <그림 1> 초기의 불법 결제 차단 시스템의 예제를 보자. CPRule 클래스의 getBlockRules(), getEmailRule()는 서로 성격이 다른 클라이언트에 의해 접근되고 있다. getBlockRules()는 Block Transactoin 클래스에 의해서 getEmailRule()은 Email Reporting 클래스에 의해서 사용된다. 인터페이스를 사용하는 클라이언트가 명백히 분리된다는 것은 인터페이스가 그 클라이언트의 개수만큼 다른 서비스를 제공한다는 의미이다. 하지만 애초에 이 여러 개의 인터페이스가 같이 있다는 것은 나름대로의 ‘공유, 연관되는 무엇인가’가 있다는 것이다.

그렇다면 공유, 연관되는 부분은 그대로 두되 효과적으로 인터페이스를 분리하는 방법이 필요하다. 여기서 몇 가지 규칙이 필요하다. ① 기 구현된 클라이언트의 변경을 주지 말아야 할 것 ② 두 개 이상의 인터페이스가 공유하는 부분의 재사용을 극대화할 것 ③ 서로 다른 성격의 인터페이스를 명백히 분리할 것 등이다. 분리 방법은 클래스 인터페이스를 통한 분리와 객체 인터페이스를 통한 분리를 이용할 수 있다.

클래스 인터페이스를 통한 분리
다중 인터페이스를 분리하는 방법으로 클래스의 다중 상속을 이용하여 인터페이스를 나눌 수 있다. <그림 10>에서와 같이 ‘결제 차단’에 관련한 인터페이스를 제공하는 getBlockRules()를 포함하는 BlockRule 인터페이스와 이메일 처리를 전담하며 getEmailRule()을 구현하는 EmailRule 인터페이스로 분리하여 인터페이스를 정의할 수 있다. 하지만 분리된 두 인터페이스는 상술하여 제시한 첫 번째 원칙인 ‘기 구현된 클라이언트의 변경을 주지 말아야’ 하는 조건을 만족해야 한다. 즉, 클라이언트 클래스는 기존의 인터페이스를 그대로 유지하여 변경없이 접근할 수 있어야 한다. 이런 조건을 만족하기 위해서 EmailRule과 BlockRule 클래스를 다중상속하는 CPRule이 정의될 수 있다.

사용자 삽입 이미지
<그림 10> 다중 상속을 이용한 클래스 인터페이스로의 통한 분리


이와 같은 구조는 Block Transaction, Email Reporting 클라이언트 모두에게 변화의 영향을 주지 않을 뿐 아니라 인터페이스를 분리하는 효과를 갖는다. 하지만 거의 모든 객체지향 언어에서는 상속을 이용한 확장은 상속받는 클래스의 성격을 디자인 시점에서 규정해 버리는 특징이 있다. 따라서 CPRule 클래스는 Block Transaction 인터페이스와 Email Reporting 인터페이스를 상속받는 순간 이 두 인터페이스에 예속되어 제공하는 서비스의 성격이 제한된다.

객체 인터페이스를 통한 분리
다른 방법으로는 위임(delegation)을 이용한 방법이 있다. 이 방법은 CPRule의 필드로 Rule이란 객체를 갖는다. Rule 객체는 인터페이스인데 BlockRule과 EmailRule이 각각의 서비스에 맞는 rule() 메쏘드를 구현한다. 이런 상황에서 Block Transaction 클라이언트는 getBlockRule() 메쏘드를 통해 BlockRule 클래스의 rule() 메쏘드를 호출한다. Email Reporting의 경우도 마찬가지로 동작한다. 즉 위임을 이용해서 getBlockRule(), getEmailRule() 메쏘드는 멤버변수 rule 객체의 rule() 메쏘드를 호출하게 된다.

위임을 이용한 객체의 인터페이스 분리는 Rule이란 객체를 확장한 어떤 구현도 대체될 수 있다. 만약 암호화된 EmailRule이 필요하다면 Rule 인터페이스를 구현하는 암호화된 SecuredEmailRule이라는 클래스를 정의하여 CPRule의 rule 필드에 꼽아주면 확장이 용이하다.

사용자 삽입 이미지
<그림 11> 위임을 이용한 객체 인터페이스로의 분리


위임을 이용한 확장과 상속을 이용한 확장은 똑같이 인터페이스를 분리하는 기능을 하지만 서비스 결정권의 차이가 있다. 대부분의 객체지향 언어에서 상속의 경우 컴파일 시점에서 부모의 구현을 차용하게 되고 부자간의 관계는 변경이 불가능하다(자식 클래스는 부모를 바꿀 수 없다). 반면, 위임을 이용한 관계는 런타임에 변경이 가능하다. 가령 일반 이메일 모드에서 암호화 이메일 모드로 역할이 변경될 경우 CPRule.rule 변수를 EmaileRule에서 SecuredEmailRule 객체로 바꿔주기만 하면 서비스의 변경이 동적으로 이뤄진다. 따라서 위임을 이용한 확장은 상속을 위한 확장보다 관계 설정의 변화가 상대적으로 유연하다.

다른 방식으로는 C++에서 템플릿을 이용한 확장 방법을 사용할 수 있다. 자바에서는 Generic 프로그래밍을 통해서 구현할 수 있는데 컴파일 시점(정확히 pre-processing 시점)에서 적용되는 클래스의 타입을 설정해줌으로써 확장성을 지원할 수 있다.

사실은 앞의 두 가지 분리 방법은 GoF의 Adapter 패턴에서 구현 방법 중 Class Adapter와 Object Adapter 구조를 그대로 차용한 방법이다. 하지만 정 반대의 목적을 갖는다. Adapter 패턴의 경우 기존의 구현된 인터페이스를 통해 클라이언트가 원하는 인터페이스로 개조하는 목적을 갖고 있지만 우리의 목적은 서로 다른 서비스를 하는 인터페이스를 분리하려는 목적이다. 하지만 목적과 해결 대상이 비꼈을 뿐이지 그 구조는 동일하다.

ISP vs. SRP
일반적으로 인터페이스와 역할은 1:1 관계를 갖는다. 하지만 인터페이스가 여러 역할을 갖는 경우도 있다. 이것은 컴포넌트의 크기에 따라 결정되게 되는데, 가령 ‘이체’라는 인터페이스는 "① 트랜잭션을 시작한다. ② 상대의 계좌 존재 여부를 확인한다 ③ 고객의 계좌에 원하는 금액을 출금한다 ④ 상대의 계좌에 입금한다 ⑤ 트랜잭션을 마친다"의 절차를 거친다. 여기에 참여하는 역할들은 서로 응집성이 결여된다.

하지만 특정 비즈니스 목적에 의해 하나의 처리 절차로 묶이면서 ‘이체’라는 인터페이스를 만족시킨다. 다시 말하자면, ‘이체’라는 인터페이스는 여러 역할의 묶음으로 구현된다(1:n 관계의 인터페이스와 역할). 이 때 ‘이체’ 인터페이스는 이런 역할의 묶음의 Facade가 된다. 앞에서 살펴본 JTable의 경우에도 테이블의 데이터 관리, 컬럼 관리, 렌더링 관리, 이벤트 관리라는 여러 역할이 JTable이라는 하나의 클래스 안에 혼재되어 있다.

반면 하나의 역할은 여러 인터페이스로 분해되기도 하는데 자바의 java.io.OutputStream 클래스는 데이터를 쓰는 write() 인터페이스를 갖고 있다. 똑같은 역할을 하지만 인터페이스가 다른 java.io.PrintWriter 클래스는 printXX() 류의 인터페이스로 그 역할을 세련되게 제공한다(1:n 관계의 역할과 인터페이스). 이처럼 인터페이스와 역할과의 관계는 상호의존성을 갖지만 꼭 같은 의미로 사용되지도 않는다. 따라서 ISP와 RSP를 구분할 때 역할과 인터페이스의 맥락은 명백히 다르게 규정하여 접근할 필요가 있다. 즉 SRP를 접근할 때와 ISP를 접근할 때의 접근법은 차이를 두어야 한다.

ISP를 지키지 않았을 때 발생할 수 있는 악취
앞에서 살펴본 바와 같이 규모가 큰 클래스에서만 ISP가 문제되는 것은 아니지만, ISP와 관련한 문제는 대부분 비대한 클래스로부터 발생하게 된다(JTable 클래스를 한번 보라). 비대한 클래스라는 악취는 Extract Class, Extract Subclass, Extract Interface와 같은 리팩토링 기법을 통해 해결하게 되는데 이중 Extract Class와 Extract Subclass는 SRP와 연관이 있고 Extract Interface가 ISP를 따라는 설계를 가능하게 해준다.

* Extract Interface :클라이언트가 클래스의 어느 특정 기능만을 이용한다면 이러한 기능의 부분 집합을 별도의 인터페이스를 통해 추출하라.

우리는 친구들에겐 친구가 되고, 부모님께는 자식이 되고, 사랑하는 사람에겐 연인이 된다. 같은 존재이건만 상대에 따라 우리의 역할은 다르다. 하지만 친구가 없다면 우린 친구가 될 수 없으며, 부모님이 계시지 않는다면 자식이 될 수 없고, 애인이 없다면 누군가의 연인이 될 수 없는 노릇이다. 우리의 상대에 대해 좀 더 관심과 애정을 기울이고 배려의 노력을 해야 하는 것은 아닐지.@

* 이 기사는 ZDNet Korea의 제휴매체인마이크로소프트웨어에 게재된 내용입니다.

 

최상훈 (핸디소프트), 송치형 (서울대)

2005/09/02

 

사용자 삽입 이미지
사용자 삽입 이미지

 

원문 : http://www.zdnet.co.kr/builder/dev/modeling/0,39031637,39139151,00.htm

 

  Comments,     Trackbacks