리듬박스 vs. iTunes로 본 오픈 서비스/오픈 데이터의 사례

권순선의 이미지

제가 http://kldp.org/node/72449 에 썼던 오픈 서비스/오픈 데이터에 대해 조금 자세히 씁니다. 오픈 소스와 오픈 서비스/오픈 데이터와의 관계는 오픈소스 음악 소프트웨어인 리듬박스에서 CD ripping을 하는 과정을 통해 예를 들어 설명할 수 있습니다. 실은 리듬박스가 직접 ripping을 하는 것은 아니고 sound juicer가 불려져서 MP3로 ripping을 해 주는데 이 과정에서 ripping할 CD를 인식하기 위해 freedb 서비스를 이용합니다. 그리고 이 과정은 모두 오픈소스/오픈 서비스/오픈 데이터를 이용해서 이루어 집니다.

반면 apple의 itunes를 이용해서 CD를 ripping할 경우에는 이와는 완전히 반대의 케이스가 됩니다. itunes는 오픈소스가 아니며 itunes가 CD 정보를 가지고 오는 것은 Gracenote라는 상용 서비스입니다. 따라서 똑같은 CD를 MP3로 ripping하는 과정에서 위와는 완전히 반대로 독점 소프트웨어/상용 서비스/상용 데이터가 이용됩니다.

그리고 여기서 freedb 서비스에 대해서 조금 더 자세히 살펴 보면, freedb와 Gracenote는 둘 다 전세계의 CD 정보를 담고 있는 Database 이고 둘 다 해당 CD 정보는 개별 사용자들에 의해서 자발적으로 입력되었습니다. 다만 차이가 있다면 freedb의 database는 GPL이고 Gracenote의 database는 상용이라는 점입니다. Gracenote의 database가 일반 사용자들에 의해 자발적으로 입력되었는데 상용으로 전환된 것에 대해서는 비하인드 스토리가 있습니다. 시간이 되면 Gracenote를 둘러싼 논쟁에 대해서 따로 쓰겠습니다. 그리고 freedb의 서비스는 누구나 사용할 수 있으며 그렇기 때문에 CDDB가 필요한 오픈소스 소프트웨어는 거의 대부분 freedb를 사용합니다. 반면 Gracenote는 상용 서비스이며 사용하려면 별도의 계약이 필요합니다.

여기서 freedb를 통해 제공되는 CD 정보는 누군가의 주관이 개입될 수가 없는 데이터입니다. 제가 말하고 싶었던 것은 이런 식의 자유로운 '데이터'들이 점점 더 다양한 형태로 나타나게 될 것이라는 것입니다. 그리고 그러한 데이터에 누구나 차별 없이 접근하고 그 데이터들을 사용할 수 있도록 하고자 하는 다양한 시도들이 생겨날 것이라는 것입니다. 이미 이러한 시도들이 지리정보 시스템(GIS) 분야에서는 다양하게 나타나고 있습니다.

데이터에 차별 없이 접근하고 사용할 수 있도록 하기 위해서는 그 데이터들을 전송하고 가공하는 '서비스'가 필연적으로 존재하고 개발되어야 하겠지요. 이러한 데이터와 서비스들에 대한 자유로운 접근과 활용, 그리고 응용은 바로 오픈소스 코드에 대한 자유로운 개작과 재배포 개념과 상당히 유사합니다. 다만 아직까지는 그러한 서비스와 데이터가 어떠한 조건에서 허용되어야만 사용자들의 자유를 보장해 줄 수 있을 것인가에 대한 정의가 없기 때문에 일차적으로는 KLDPWiki:OpenSource 에서 오픈소스란 이런 것이다 라고 정의했던 것과 비슷한 절차를 먼저 밟게 될 것으로 생각합니다. 그렇게 해서 오픈 서비스/오픈 데이터의 정의가 내려지게 되면 GPL등의 오픈소스 라이센스들처럼 그것을 어떻게 사용하고 수정할 것인가에 대한 허용 범위와 책임/의무가 세부적으로 정의되겠지요. 현재의 오픈소스 라이센스들은 소프트웨어를 위한 것들이므로 오픈 서비스/오픈 데이터를 위해서는 별도의 사용 계약이 뒤따라서 정해질 것으로 예상합니다.

http://kldp.org/node/72673 에서 한동성님은 오픈 서비스는 불가능하다고 하셨는데 저는 전혀 그렇게 생각하지 않습니다. 우리는 이미 Gracenote/freedb와의 사례에서 보았듯이 이미 오픈 서비스/오픈 데이터를 사용하고 있고, 그러한 개념은 확대되고 있습니다. 그리고 리눅스가 초창기에 MS의 대안으로서 많은 사람들을 끌어들였던 것처럼 오픈 서비스/오픈 데이터와 관련된 부분도 처음에는 닫힌 서비스/닫힌 데이터에 대한 대안으로서의 시작되는 경우가 많겠지만 좀더 확대된다면 우리가 전혀 생각하지 못했던 분야에 대해서도 다양한 서비스와 데이터들이 출현할 것으로 예상합니다.

다음 번에는 오픈 서비스/오픈 데이터와 관련하여 Gracenote의 비하인드 스토리와 freedb를 둘러싼 논쟁에 대해서 시간이 되면 써 보도록 하겠습니다.

댓글

seachicken의 이미지

제가 못보고 지나쳤는지도 모르지만 오픈서비스의 정의부터 해야 하지 않을까요? 권순선님이나 다른 분들이 인식하고 계시는 오픈서비스란 것에 서로 상위가 있지 않나 하는 생각이 듭니다. 물론 제가 생각하는 서비스의 개념과 위의 글에서 거론된 서비스의 개념도 조금 틀리군요. 제 경우엔 위에 권순선님이 언급하신 내용은 오픈서비스보다는 오픈API에 더 가깝지 않나 합니다.

제가 생각하는 서비스는 '넷트워크로 접근이 가능한 곳에서 실행중인 호출하여 사용이 가능한 기능의 단위'입니다.
제 정의에 의하면 소스와 서비스의 차이점은 소스는 한번 버전을 정해 공개를 해 두면 더 이상의 비용발생이 없지만 서비스는 그 사용되는 빈도에 따라 유지비용이 증가한다는 점이죠. 전 세계인이 접속해서 사용하는 서비스를 운용하는 경우와 아파치의 소스를 공개하는 것은 전혀 차원이 틀린 얘기라고 생각합니다.
더불어 소스는 정적인데 비해 서비스는 동적입니다. 한번 공개한 서비스의 인터페이스가 변경되거나 기능이 변경되었을 경우, 기존의 서비스를 이용하고 있던 전 세계의 프로그램들이 영향을 받게 됩니다. 그걸 피하는 방법은 하위호환성이 있는 변경을 하거나 아니면 하위버전과 상위버전의 서비스를 병행해서 운영하는 것이죠. 이건 몇개의 버전의 소스를 미러링하는 것과는 차원이 다른 얘기라고 생각합니다.
더불어 서비스엔 소스에는 없는 서비스 레벨이란 개념이 존재합니다. 예를 들어 어떤 서비스를 호출했을 때 몇초안에 응답을 해 주어야 한다라는 것이 그 예에 해당합니다. 하지만 서비스의 이용자에 따라 같은 서비스에 대해 요구하는 서비스 레벨이 틀릴 수도 있습니다. 어떤 이용자는 7초를 요구하고 어떤 이용자는 3초를 요구합니다. 이러한 서비스레벨의 요구에 누가 대응을 할 것이며 서비스 운용중의 서비스 레벨 저하에는 누가 어떻게 대응을 하고 또 어떤 책임을 질 수 있는지요?

한동성님이 소스와 서비스에 대한 예를 들었는데, 제 경우엔 다음과 같은 예를 들고 싶습니다.
소스는 음식을 만들기 위한 레시피입니다. 하지만 서비스는 말 그대로 주문을 하면 그 음식을 만들어서 가져다 주는 행위이죠. 레시피를 공개하는 것은 쉽습니다. 그 레시피로 어떤 음식을 조리해 먹는지는 레시피의 작성자의 책임이 아닙니다. 하지만 식당에서 손님의 주문을 받아 음식을 만들어 제공하는 것은 식당측의 책임입니다. 말 그대로 음식이란 실질적인 서비스를 제공하는 겁니다. 세상엔 까다로운 손님이 많구요. 레시피를 공개하기 위해서는 홈페이지 한장을 만들면 되지만 음식을 제공하기 위해서는 식당건물을 비롯한 각종 재료와 주방장, 서빙, 계산인이 필요합니다.

그래서 제가 다시 묻고 싶은 건 오픈 서비스에서 오픈이란 무엇을 말하는 것이며 어떻게 가능한 것일까 하는 것입니다.
(물론 서비스에 대한 제 생각 자체가 틀려 있다면 지적 달게 받겠습니다)

이상이 권순선님이 처음 오픈서비스에 대해 썼을 때 제가 가진 생각이었습니다만 다른 분들의 글을 보면 서비스에 대한 정의 자체가 저와 다른것 같습니다. 어쩌면 저 혼자 착각을 하고 있는 걸까요?

Stay hungry! Stay foolish!

Stay hungry! Stay foolish!

netkit의 이미지

seachicken 님의 의견에 많이 동의합니다. 먼저 용어의 올바른 정의가 필요한 것 같습니다.

제가 오픈 서비스라는 말에 대해서 가장 떠올린 모델은 위키미디어 프로젝트였습니다. 세계 각국어 백과사전과 언어 사전, 생물 도감 등등을 모두의 참여로 만들어 GFDL로 배포하는 이 거대한 서비스는 많은 기부와 자원봉사자에 가까운 성실한 참여자들 덕분에 이럭저럭 성공적으로 굴러가고 있습니다. F/OSS 프로그래밍에 대한 열정과 신념을 가진 사람이라면 누구나 흡족한 미소를 지으며 바라볼 만한 프로젝트이며, 자유 소프트웨어의 정신을 소프트웨어 아닌 저작물에도 확장해서 성공적으로 적용시킨 멋진 사례입니다. 진정 사용자가 웹 서비스를 만들어간다 할 것입니다.

그런데 권순선 님이 예로 제시하신 것, 가령 freedb는 그냥 오픈 데이터를 잘 모아서 아무나 이용하도록 공개해 놓은 것입니다. seachicken 님의 통찰이 한번 더 빛나는군요. 이건 오픈 서비스 아닙니다. 오픈 API지.

권순선 님의 말씀대로라면, 가령 대한민국의 헌법과 각종 법률과 시행령은 모두 일종의 퍼블릭 도메인으로 공개되어 있는데, 그렇다고 법제처 웹사이트에서 제공하는 법령검색이 '웹 2.0 시대의 오픈 서비스'는 아니잖습니까.

제가 불만을 느낀 부분은 팀 오라일리가 '말잔치'를 하고 있는 것 같다는 것입니다. 웹 2.0이라는 말 자체가 그런 측면이 있었고요. 먼저 그가 '오픈 데이터'라는 개념을 마치 새로운 것 내지는 새로이 주목받아야 할 것인 양 소개한 것 같은데, 데이터에 '자유롭게 이용하고 개작하는데 필요한 자유와 의무' 비슷한 개념 한참 전에 나온 얘기 아닙니까? GFDL. CCL. Public Domain. 이게 뭐가 새롭고 뭐가 탁견이며 뭐가 '웹 2.0 시대의 오픈 소스'란 말입니까. 예전 스레드에서 권순선님은 "...우리는 이미 오픈소스를 통해서 개발자와 사용자들이 소프트웨어를 자유롭게 이용하고 개작하는데 필요한 자유와 의무를 얻었습니다. 그렇지만 서비스나 데이터에 대해서는 이러한 개념이 없고, 서비스로서의 소프트웨어 산업은 지속적으로 확대되어 가는 추세이므로..."라고 하셨는데 왜 데이터에 대해서는 이러한 개념이 없다고 하셨는지 모르겠습니다. GFDL, CCL, Public domain이 다 그런 것 아닌가요? 이것은 공공재라는 개념, 그리고 정보도 재산이라는 개념이 등장한 그 순간부터 이미 있어온 오래 된 개념이며 지금도 일상화되어서 사용되고 있습니다. 그리고 단순히 그것들을 모아놓은 걸 가지고 '오픈 서비스다!' 하는 것이라면 이건 정말 그럴싸한 말을 만들어내서 뭔가 있어 보이는 척하는 것에 불과하지는 않을까요. 전혀 새로울 것도 대단할 것도 주목할 필요도 없는. 그렇다고 거기에 사용자가 참여하고 사용자가 만들고 사용자가 덧붙이며 사용자가 고친다는 개념이 들어가면 새로운가? 그것도 아닙니다. 우리는 이미 그런 이념에 따라 등장한, 나름대로 역사가 있는 도구를 알고 있습니다. 위키위키.

그런즉 "오픈 서비스는 불가능하다"라는 제 발언을 정정할 필요를 느낍니다. "오픈 서비스? 뒷북;"

P.S. 제가 오픈 서비스는 불가능하다는 과격한 언사를 쓴 이유에 대해서 약간 변명하겠습니다. 기업의 영리적인 서비스의 대안이 될 수 있는 수준으로 오픈 서비스를 만들어내려면 오픈 소스 소프트웨어나 오픈 데이터를 만들어내는 것과는 달리 열정과 뛰어난 지적 능력은 별 의미가 없습니다. 그보다는 서버 구입 비용 또는 대여료 -> 돈, 회선 임대료 -> 돈, 막대한 용량의 하드 디스크 -> 돈, 돈, 돈, 돈이 필요합니다. 그냥 오픈 데이터를 모아놓고 누구나 긁어가라는 사이트라면 돈이 그렇게 들 것도 없지만, 그런 단순한 DB가 아니라 권순선님이 처음에 말씀하신 '웹 서비스 형태로 제공되는 소프트웨어 산업'에서 영리적 서비스의 대안이 될 정도 수준으로 크게 돌리려면 seachicken 님 말씀대로 "식당건물을 비롯한 각종 재료와 주방장, 서빙, 계산인"이 문제인 것입니다. "기부금 주세요 핥핥핥핥핵핵핵헉헉헉헉" 하는 위키미디어 프로젝트를 보십시오. 예전 스레드에서 borninfree 님이 말씀하신 것을 인용하겠습니다.

"오픈소스처럼 오픈서비스가 되기 위한 조건
borninfree 씀 (수, 2006/08/02 - 6:36pm)

문제는 비용이다.
더군다나 요즘처럼 동영상과같이 막대한 대역폭을 요구하는 서비스가 필요한 시점에는 더욱그렇다.
이런것이 구글등이 축구장 몇배크기의 데이타센타를 건설하는 이유일것이다."

권순선의 이미지

오픈 소스라는 말이 생기고 확산되기 시작한 1990년대 후반 이전에도 이미 오픈소스는 있었습니다. GPL v2가 1991년에 나왔고, 그 전에도 이미 여러가지 다양한 오픈소스 소프트웨어 라이센스들이 있었지요. 그러면 마찬가지 논리로 '오픈 소스'도 GPL의 뒷북이라고 할 수 있겠군요. :-)

오픈 서비스/오픈 데이터의 개념이 얼마나 잘 정의될지는 아직 알 수 없습니다. 다만 위의 두분과 저의 관점 차이는 그것을 쪼개서 볼 것이냐, 아니면 확장하고 포괄해서 볼 것이냐 하는 것입니다. 좁은 시각으로 보지 마시고 좀더 넓게 보시기 바랍니다...

seachicken의 이미지

말씀하셨듯 서로 개념의 정의에 대해 공통된 인식을 갖지 않는 한 어떤 논의도 어렵습니다.
제가 생각하는 서비스의 정의는 위에 말씀드렸습니다만 권순선님께서 생각하시는 확장되고 포괄된 정의는 무엇일까요?
가르침을 바랍니다.

Stay hungry! Stay foolish!

Stay hungry! Stay foolish!

권순선의 이미지

제가 보기에 두분은 '서비스'라는 것을 어떻게 볼 것이냐에 관심이 많으신 것 같은데 저는 서비스 자체의 기술적인 디테일을 고민하는 것보다 '오픈된' 서비스란 어떤 것이냐에 관심이 많습니다. 그점이 가장 큰 차이점인듯 하네요.

highwind의 이미지

wikipedia에 의하면 이렇게 정의 되어있네요.

"services developed and operated by the community, rather than a private company" http://en.wikipedia.org/wiki/Open_service

커뮤니티가 만들어 제공하는 서비스라고 정의를 내리고 있는데...

그렇다면 자원봉사 단체 같은경우도 오픈 서비스인가요?
먹는 이야기가 나왔으니 저의 교회 예를 한번 들어보죠. 저의 교회에선 홈리스들을 위해 밥을해 매주 돈을 받지않고 배포(?)하고 있습니다. 당연히 우리의 자비를 들여 (가끔가단 도네이션도 받고요) 우리의 시간을 써가면서 서비스를 제공 하고있습니다. 누구나 와서 먹을수 있으며 (홈리스가 아니여도 상관없습니다.) 누구나 와서 도울수 있습니다 (저희 교회에 다니지 않아도 상관없습니다.) 이 서비스를 할때 많은 사람들이 몰리는것을 대비해서 워싱턴 DC 경찰청에 도움을 요청해서 경찰이 항상 와서 있고요. 서비스를 제공하는 사람 서비스를 받는 사람 상관없이 다 좋은시간을 가지고 돌아갑니다. 가끔가단 돈이 없고 도울 사람이 없어서 못할때도 있습니다.

뭐 이런게 오픈 서비스 아닐까요?

'넷트워크로 접근이 가능한 곳에서 실행중인 [프로그램을] 호출하여 사용이 가능한 기능의 단위'
이 정의도 오픈 서비스에 적용 할수 있다고 보는데요.
"접근"이 자유롭고 (밥주는곳까지 올수있는 차나 대중교통이나 다리가 있다면 오케!)
"호출"이 자유롭고 (누구나 "밥주세요~" 하면 됩니다... 다만 줄을 서야겠죠?)
"사용"이 자유롭고 (받은 밥을 소금을 쳐먹던지 다 비벼먹던지 집에가지고 가서 먹던지 상관 안합니다.)
그럼되는거 아닙니까?

그럼다시 권순선님의 예로 돌아와서.
freedb서비스는
"접근"이 자유롭습니다.
"호출"도 자유롭죠? freedb 써버가 켜있는 이상 누구나 와서 데이타를 요청 할수 있으니까요.
"사용"도 자유롭습니다. 그 데이타를 가지고 CD Ripper를 만들던 random string generator를 만들던 상관 안하니까요.

여기에 wikipedia정의를 대입시켜도 오픈 서비스이네요.
커뮤니티가 컨텐츠를 만들고 커뮤니티가 서비스를 제공하니까요.

freedb자체는 API는 아니라고 생각 됩니다.
freedb를 사용할수 있게 API가 존제하지만 freedb자체는 API가 아니니까요

wikipedia에선 API를 이렇게 이야기 합니다.
"An application programming interface (API) is the interface that a computer system, library or application provides in order to allow requests for services to be made of it by other computer programs, and/or to allow data to be exchanged between them." http://en.wikipedia.org/wiki/Application_programming_interface
더쉽게 말하면
"서비스를 사용할수 있게 하는 interface"

그러니 freedb를 사용할 수 있는 API는 존제합니다.
하지만 freedb자체는 API가 아니라고 생각되네요.

...

그냥 생각나는대로 글을 쓰다보니 두서가 없네요 (한글도 많이 딸리고...)

오픈서비스... 현제 존제하고있고 앞으로도 온라인상에서도 더많은 참신한 서비스들이 생길꺼 같네요. 하지만 무작정 돈때문에 안된다고 막으면 될것도 안될꺼 같네요.

(저의 교회에서도 그 홈리스 봉사가 교회에 돈없다고 안될꺼라고 막으신 분들이 좀 계시긴 한데... 그냥 하다보니까 돈보단 사람들 참여 문제가 더 많더군요 ^^;; )

=====================================
http://timothylive.net

seachicken의 이미지

'가끔가단 돈이 없고 도울 사람이 없어서 못할때도 있습니다.'

바로 그겁니다. 누가 밥 먹으로 왔는데 그날은 밥을 안 주고 있었다면? 누구는 열심히 줄을 서서 기다렸는데 그의 바로 앞에서 밥이 다 떨어져 버렸다면?

서비스는 기능입니다. 기능이 가끔 멈추어서는 말이 안됩니다.
님이 만든 웹어플리케이션의 일부 기능을 오픈서비스를 사용해서 구현했는데 그 오픈서비스가 가끔 멈춘다면 님의 웹어플리케이션은 제대로 동작할 수 있을까요? 그 웹어플리케이션에 기반한 비지니스 모델은 고객에게 신뢰감을 줄 수 있을까요? 투자자는 그 비지니스 모델에 돈을 투자할까요?

Stay hungry! Stay foolish!

Stay hungry! Stay foolish!

highwind의 이미지

"서비스는 기능입니다. 기능이 가끔 멈추어서는 말이 안됩니다."

저희 교회에서 가끔 기능이 멈춘다고 해서 무료 밥 서비스를 서비스로 보지 않는 사람은 없고
우리 서비스를 싫어하거나 반대하는사람은 더더욱 없습니다.

꼭 서비스란것이 돈을벌기 위한것인가요?
-_-;;

자원봉사단체들이 하는것들은 서비스가 아닌가요?

=====================================
http://timothylive.net

seachicken의 이미지

"서비스는 기능입니다. 기능이 가끔 멈추어서는 말이 안됩니다."

"님이 만든 웹어플리케이션의 일부 기능을 오픈서비스를 사용해서 구현했는데 그 오픈서비스가 가끔 멈춘다면 님의 웹어플리케이션은 제대로 동작할 수 있을까요?"

Stay hungry! Stay foolish!

Stay hungry! Stay foolish!

권순선의 이미지

그것은 서비스의 요구사항이지만 현실적으로는 충족시키는 것이 불가능한 요구사항입니다. 상용 소프트웨어도 버그가 있는 것처럼 상용 서비스도 가끔은 서비스가 중단되기도 합니다.

소프트웨어가 무결하게 동작하거나 서비스의 가동률을 최대한으로 높이기 위해 노력할 수는 있겠지만 상용이든 상용이 아니든 100% bug-free, 100% 가동률은 현실적으로 불가능하지 않나요?

다만 여기서 오픈 서비스/오픈 데이터를 iTunes와 sound juicer의 예로 들어 설명해 보면, 만약 iTunes의 CD 정보를 제공해 주는 Gracenote가 갑자기 서비스가 안된다면 고객은 할 수 있는 일이 없지만 sound juicer가 CD 정보를 받아오는 freedb의 서비스가 갑자기 안된다면 고객이 직접 freedb의 데이터 덤프를 가지고 제 2의 freedb 서비스를 만들 수 있습니다. 이게 바로 http://www.freedb2.org 에서 현재 실제로 일어나고 있는 일입니다.

중요한 것은 오픈 서비스의 가동률이 100%라야 한다는 것이 아니라 오픈 서비스/오픈 데이터의 조합에서는 대안이 있을 수 있다는 것입니다. 마치 오픈소스처럼 말이죠. 서비스 가동률은 전혀 중요한 것이 아닙니다.

seachicken의 이미지

흠... 이제서야 말씀하시는 바를 조금은 이해할 수 있겠군요. (머리가 아둔해서..)

하는 일이 일이다 보니 미션 크리티컬한 부분만 생각을 하고 있더랬습니다.
말씀하시듯 모든 서비스에 백프로 가동율이 요구되는 건 아니죠.

Stay hungry! Stay foolish!

Stay hungry! Stay foolish!

wish의 이미지

글타래를 쭉 읽어 오면서 느낀 점은 많은 개념과 주장들이 얽히고 섥혀 있다는 점입니다. 저 자신도 그 얽혀 있는 걸 제대로 풀어 내지는 못하겠네요 ^^ 그럼에도 몇 가지 쓰고 싶은 점이 있어 써봅니다.

저도 한동성님이나 seachicken님 의견에 많은 부분 동감합니다. 오픈 서비스를 생각 할 때 가장 먼저 생각해야 될 것은 비용입니다. 예를 들어 구글 검색 서비스는 누구나 자유롭게 이용 가능 합니다. 이런 점에 있어서는 공짜 소프트웨어(Free Software 가 아닙니다)와 같죠. 다만 이런 서비스에 대해서 오픈 소스(혹은 GNU 측의 "Free" Software) 개념을 적용하는 것 자체가 불가능 합니다. 소프트웨어 소스 코드는 일단 만들어 놓고 인터넷에 던져 놓으면 그 이후로 큰 비용이 들 지 않습니다. 그러나 구글 같은 서비스의 소포트웨어와 데이터는 인터넷에 던져 놓는 것 자체가 불가능합니다. 구글이 색인하고 있는 페이지와 그 내용을 저장하고 있는 데이터의 크기는 이미 몇 십 테라 급입니다. 뿐만 아니라 오픈 소스 소프트웨어는 사용자가 늘 수록 비용이 더 들어가지 않습니다. 오히려 사용자가 들수록 디버깅 하는 사람도 많아지고, 기능 제안도 많아지는 장점이 있습니다. 물론 그 소프트웨어를 배포하는 비용이 들어가긴 하지만 정말 미미합니다. 독점 소프트웨어에 대한 오픈 소스 소프트웨어의 큰 장점 중 하나가 배포 비용이 적게 든다는 점도 있습니다. 거기에 비해서 구글 같은 서비스를 생각해 보면 서비스 자체를 유지 하는 비용이 많이 들 뿐 아니라, 사용자가 늘 수록 그 비용은 전부 구글이 부담하게 되어 있습니다. 물론 서비스의 경우도 사용자가 늘어나면 피드백을 많이 받아 더 발전 할 수 있는 장점이 있습니다.

결국 오픈 소스 소프트웨어는 GNU, linux, FreeBSD, python 등등등 과 같이 거대한 자본 없이도 프로젝트를 이끌어 나갈 수 있기에 성립 가능한 개발 방법입니다. sf.net 혹은 kldp.net 에 페이지를 하나 개설하고 사용자와 개발자를 끌어 모을 수 있고, 돈이 부족하면 기부금을 받거나 할 수도 있습니다. 만약 sf.net 같은 호스팅 페이지가 날라간다고 해도, 여전히 개발은 가능하죠. 정 안되면 이 메일로 의사소톹 하면서라도 가능합니다. 결국 그 프로그램을 사용한데 있어서 들어가는 비용은 사용자와 개발자 모두에게 분산됩니다.

거기에 비해서 wikipedia, google 등의 서비스는 설령 컨텐츠를 만드는 사람이 전부 봉사 정신이 투철해서 전일제 봉사를 한다고 하더라도, 누군가 서비스를 유지하기 위한 거대한 비용을 지불해야 합니다. 사실 어떻게 보면 구글도 사용자들이 제공하는 컨텐츠를 색인하고 정리해서 보여주는 서비스입니다. 사용자의 컨텐츠를 이용해서 광고로 낸 수입으로 막대한 서비스 제공 비용을 지불하고 이윤을 챙기는 것이죠. wikipedia 의 재무 구조가 어떻게 되어 있는지는 모르겠지만, 그 서비스의 기반 시설을 유지하기 위한 비용은 누군가 부담하고 있을 것입니다.

그렇다면 서비스에서의 "오픈" 이라는 개념이란게 과연 있기나 한 것이냐는 의문이 당연히 듭니다. 저는 별 거 없다고 생각합니다. 누구나 쉽게 쓸 수 있는 web API나 혹은 그 사용성에 준하는 쉬운 API 를 제공 하는 것 정도인 것 같습니다. 사용자에 있어서는 당연히 이런 API 공개는 환영할 만한 일입니다. 그런 API 를 이용한 새로운 소프트웨어 개발도 가능하고 자신이 원하는 서비스로 변환시킬 수도 있습니다. 제공자 입장에서도 사업의 외연이 넓어 지고 무엇보다 경쟁자의 출연을 손쉽게 막을 수가 있습니다. 그런 의미에서 이미 수 많은 웹 서비스는 오픈 서비스라고 생각합니다. 어차피 웹 서비스라고 하는 것이 사용자의 컨텐츠 창조 능력 없이는 존재 할 수 없는 것이 많으며, 제공자 입장에서도 자신의 서비스를 최대한 공개해서 사용자의 컨텐츠 창조 능력을 독려하는 것이 자신에게도 도움이 됩니다. 단적으로 aladdin 이나 amazon 같은 곳에서 관심있는 책 목록이나 구매 목록 등의 수동적인 사용자 제공 컨텐츠도 결국 사용자에게는 좀 더 편한 쇼핑을 제공자에게는 좀 다 많은 매출을 제공하고 있습니다. 물론 wikipedia 나 freedb 같이 전적으로 사용자가 컨텐츠를 만들어 내는 서비스의 경우는 말할 것도 없이 서비스를 대중에게 오픈 해야 겠죠. wikipedia 한번 검색할 때 돈 내야 된다면 누가 그 컨텐츠를 만들려고 하겠습니까? ^^ 혹은 구글에 홈피를 등록할 때 돈 내야 된다면 지금과 같은 검색 서비스의 질은 보장 못할 겁니다. 아마 기업 홈피만 잔뜩 보이겠죠.

결국 오픈 서비스와 오픈 소스의 접점은 서비스가 비용 문제에서 자유롭지는 못하지만, 오픈 되어야만 그 가치가 올라간간다는 점에서 찾을 수 있을 것 같습니다. 오픈 서비스가 가능한가? 라는 질문은 질문 자체가 잘못된것 같습니다. 서비스는 오픈 서비스 형태로 가야 하는가? 라는 질문에 예라고 답변하는 것이 팀 오렐리의 주장이라고 생각합니다. 이미 오픈 서비스는 도처에 깔려 있습니다. 심지어 naver 도 web api 를 제공하기 위해 준비중이죠. 제가 잘못 읽은 것이 아니라면 팀 오렐리가 오픈 소스와 오픈 서비스이야기를 할 때의 요지는 "웹 시대에 있어서 중요한 것은 소프트웨어 소스 코드 공개가 아니라 서비스의 web api 등으로 얼마나 공개 되어 있는가이다" 였던 것으로 기억합니다. 실제로 사례도 그런 식으로 들었구요. 오픈 서비스라는 말 자체가 뒷북이라고는 생각하지 않습니다. 서비스를 공개하는 시대라는 트렌드를 하나의 단어로 형상한 것이 팀 오렐리의 발언이라고 생각합니다. 실제로 우리가 이렇게 풍부한 서비스 자원을 끌어 쓸 수 있게 된지는 정말 10년도 안되었습니다. 그렇다고 오픈 소스 식으로 오픈 서비스를 만들 수 있느냐는 규모 문제인 것 같습니다. freedb 정도야 다루는 데이터가 작으니 그런 식으로 개발 할 수 있겠지만, 동영상 검색 서비스를 오픈 소스 식으로 만들기는 불가능합니다 ^^ 기업이 사업을 시작해서 오픈 서비스 형태로 나가는 것은 가능하겠죠. 권순선님께서 말씀하셨듯, open source 가 gpl 의 뒷북이라고 말하기 힘든 것 처럼, 오픈 서비스라는 개념도 그냥 뒷북이라고 치부하기에는 최근의 트렌드가 되고 있는 것 같습니다.

seachicken의 이미지

또 하나의 서비스에 대한 정의가 제시되었군요. 그런데 위의 두분 다 비용 문제에 대한 부분에 주의를 기울이시는데, 제 생각엔 또 다른 문제는 서비스의 버전관리 및 서비스 수준의 관리입니다. 생각나는대로 몇가지 적어 보죠.

서비스의 기능이 확장되고 개선되면 서비스의 인터페이스 및 기능도 변경될 가능성이 있습니다. 이건 소스의 버전업이랑은 그 성질이 틀리죠. 소스는 새로운 사용자는 새로운 버전을 받아 쓰면 되고 기존 사용자는 낡은 버전을 사용할 수도 있습니다. 하지만 이미 많은 사용자가 사용중인 서비스를 마음대로 바꾸는 것은 불가능한 얘기고, 그렇담 사용자가 있는 한 기존의 서비스는 유지 및 가동상태로 해 두어야 한다는 얘기가 됩니다. 소스코드의 버전이 5.5, 6.7 대로 올라가면 ㅁ몇가지 버전의 서비스가 가동중의 상태로 있어야 할까요? 언제까지 낡은 버전의 서비스를 가동해야 할 까요? 낡은 버전의 서비스와 하위 호환성을 유지하면서 새로운 버전업을 해 가는 것이 언제나 가능할까요? 잘못하면 수십개의 버전의 동일한 서비스를 가동해야 할 지도 모르는데 누가 그걸 다 관리할 수 있을까요?

서비스의 사용을 위해서는 통상 서비스의 이용자와 제공자 사이에 SLA(Service Level Agreement)라는 걸 교환합니다. 서비스의 사용에 있어서 일정 수준 이상의 품질을 보장한다는 약속과 그걸 이행 못했을 때 어떤 대응 및 보상을 해 주는지에 대한 계약이죠. 오픈 서비스의 개념을 오픈 소스와 같이 자원봉사자나 커뮤니티에 의해 운영되는 서비스라 정의할 때 도대체 누가 어떻게 SLA 미준수에 대한 책임을 질 수 있을까요? 자원봉사자인가요? 커뮤니티인가요? 아파치의 소스를 가져다 사업을 하는 사람들은 자신이 책임을 질 수 있지만 오픈 서비스를 이용하는 기업체는 그 오픈 서비스가 어느날 갑자기 중단되거나 했을 때 어떻게 대응을 할 수 있을까요? 누구에게 책임을 물어야 할까요? (일례로 구글 맵을 이용해서 매쉬업 서비스를 제공하던 업체가 어느날 갑자기 구글이 구글맵 서비스의 제공을 중지해 버린다면 그들의 비지니스는 어떻게 될까요? 물론 현재는 구글도 구글맵 서비스의 제공에 대해 어떤 약속도 하고 있지 않습니다.)더구나 서비스 이용자에 따라 동일한 서비스에 대해서도 상이한 서비스 레벨을 요구합니다. 그것에 일일이 어떻게 대응할 수 있을까요? 그것도 무상으로요?

단순히 운영비용만의 문제가 아니고 정적인 소스와 동적인 서비스 사이에는 많은 상이점이 있습니다.

물론 '그러니까 안된다'는 얘기를 하고 있는게 아니라 문제의 해결책을 찾기 전에 도대체 뭐가 오픈 서비스인가부터 정확히 정의를 해 두고 싶습니다. 개념의 정의도 없이 해법을 찾는 것은 어불성설이죠.

(P2P가 하나의 해법이 될 수도 있겠군요.)
Stay hungry! Stay foolish!

Stay hungry! Stay foolish!

stadia의 이미지

제가 구글 api를 통해 얻는 데이터는 없지만 아마존에서 제공하는 api를 통해 사용하는 데이터는 많습니다.
다들 사용하고 계시겠지만 amarok 이나 mp3tag 는 앨범 정보나 커버를 아마존을 통해 가져와 쓸 수 있습니다.
이 기업들은 서비스를 통해 수익을 창출하지만 서비스를 만들기 위해 이루어놓은 데이터는 공개하고 있는데요. 이것도 오픈 서비스라고 해야 할까요?

권순선의 이미지

엄밀히 말하자면 데이터 그 자체는 아마존의 database 서버에 들어가 있고 오직 웹 서비스 등을 통해 요청이 올 때만 조건에 맞는 데이터를 보내주는 것이겠지요. 그에 반해 freedb는 database dump 자체를 제공하고 있습니다. 약간 차이가 있죠?

knight2000의 이미지

GPL이 오픈소스(Open source)이듯이
freedb는 오픈서비스(Open service)입니다.

하지만 제가 좋아하는 AcroEdit는 그저 프리웨어(Freeware)이지요.
그와 같이 아마존이나 구글은, 빗대어 말한다면, 프리서비스(free service)쯤 되지 않을까 생각합니다. 그저 비용적, 사용적 측면만 'free'한 경우입니다. 접근은 상대방이 정의한 형태로만 가능하고요.

===== ===== ===== ===== =====
knight2000 of SALM.
SALM stood for SALM Ain't a Life Model.
SALM is not the life model, but SALM is just the life.

===== ===== ===== ===== =====
knight2000 of SALM.
SALM stood for SALM Ain't a Life Model.
SALM is not the life model, but SALM is just the life.

serialx의 이미지

흥미로운 주제가 오가고 있네요. 결과적으로 오픈 서비스의 존재 유무는 오픈 서비스가 가지는 한계를 극복할 방안이 나올 것이냐, 말것이냐의 이야기로 이어지는것 같습니다.

무슨 말이냐 하면, 오픈소스 라는 개념이 널리 확대되고 퍼질 수 있었던 이유는, 수많은 해커들이 자신의 여유로운 시간을 해킹에 투자할 의지가 있었고, 또한 할 수 있었기 때문입니다. 즉, 해커들은 코딩을 할 의지가 있었고, 또한 할 수 있었습니다. 어떻게 보면 자원봉사라 할 수 있는 이러한 활동을 통해서 오픈소스는 키워졌고, 현재는 많은 대기업들의 지원을 받고 있습니다.

이렇듯, 오픈 서비스의 개념도 오픈 서비스가 가지는 한계인 회선비용, 신뢰도 등을 해결할 수 있는 방안이 오게 된다면 성공할 수 있다는 것입니다. 만약 커뮤니티의 사용자들이 해당 서비스에 정보를 제공하고 생산해줄 의지가 있고, 오픈 서비스를 진행 할 능력이 있는 집단 (기업, 혹은 커뮤니티 자체 기부를 통한 운영 등) 이 존재하게 된다면 오픈 서비스는 이루어 지는 것이라 봅니다.

커뮤니티의 사용자들이 제공하는 정보가 정말 가치가 있다면, 기업들이 이러한 오픈 서비스를 제공하지 않을 이유는 없습니다. 오픈 서비스에서 2% 부족한 네이버의 지식인 서비스도 이러한 예에 속하겠군요.

정리하면, 오픈소스가 해커들의 자의적인 시간투자와 기업의 대대적인 지원을 통해 성공했다면, 오픈 서비스도 그러지 못하리란 보장은 _없다_ 입니다. :)

cleansugar의 이미지

인터넷 복권, 인터넷 도박, 인터넷 경품추첨 등을 할 때는 당연히 주최자의 승률 조작을 의심하게 됩니다.

게다가 이런 사이트는 검은돈이 오고가기 때문에 더 심각합니다.

저번에 나온 신문기사에는 슬롯머신을 운영하는 조폭들이 기술자들을 가둬놓고 합숙을 하면서 개발시킨다고 합니다.

이런 사행성 서비스가 아니라도 경매, 부동산 경매, 예술품 경매, 증권, 비상장 주식거래 등의 일반 상거래 사이트도 소스가 공개되어있지 않으면 낙찰자, 낙찰가 조작도 이론상 벌어질 수도 있습니다.

소규모의 보안이 부실한 사이트라면 더 신뢰감이 안 갑니다.

만약 자신의 서비스는 타 회사와는 다르게 소스를 공개하고 좀더 투명하게 운영하고 있다고

마케팅을 하면 닫힌 서비스보다 사람들이 더 좋아할 수도 있습니다.

나중에는 웹브라우저에 서버의 소스가 공개되었는지를 자동으로 등급매겨서 좋은 사이트는 추천하고 나쁜 것은 필터링할 수도 있을 것입니다.

그러니까 쉽게 말해서 복권이라고 주소창에 치면 소스가 공개되어 사기당하지 않는 사이트가 우선 검색된다는 말입니다.

뉴스 모음 사이트도 나름의 프로그램으로 자동 분류한다고 해도 그게 구체적으로 무슨 알고리듬인지 공개한다면 독자한테는 더 좋습니다.

그렇지만 모든 서비스를 강제로 공개하라고 규제하는 것은 좋지 않다고 생각합니다.

재벌 2세가 재벌이 될 확률과
금메달리스트 2세가 금메달을 딸 확률이 비슷해지도록
자유오픈소스 대안화폐를 씁시다.

아이디의 아이디어 무한도전
http://blog.aaidee.com

귀태닷컴
http://www.gwitae.com

irene의 이미지

글의 요점과는 벗어났지만 freedb의 데이터 가운데 많은 한국 음악(거의 대부분)의 정보가 EUC-KR로 입력이 되어 있습니다. 때문에 UTF-8기반으로 옮겨간 리눅스 상에서는 한글 정보가 제대로 보이지 않는 문제가 있습니다. 제가 가지고 있는 일부 음반만이라도 UTF-8로 바꿔서 업로드했지만, 이런 식으로 하면 간단한 리핑과정(Sound-Juicer or Banshee -> Rhythmbox, Banshee)에서도 꽤 번거로움이 있습니다. 데이터 베이스 파일이 전체가 400메가 정도 되던데 이것을 통째로 UTF-8인코딩으로 변환하는 작업을 누군가가 한다면 좋을 텐데 말이죠....-_-; 하나하나 Submit하려니 솔직히 freedb너무 쓰기 불편합니다.

게다가 freedb에서는 한글로 된 음반이나 가수로 검색조차 되지 않고 설사 영문이름으로 검색해낸다 하더라도 결과화면에서 한글이 제대로 보이지 않습니다. 반면 gracenote는 한글검색과 출력이 모두 원활하구요. 좀 아쉬움이 많이 남아서 글 남겨봅니다.

익명사용자의 이미지

url에 KLDP가 들어가 있는 일련의 사이트 모두는
오픈서비스에 준하지 않나요? :evil:

권순선의 이미지

상당히 늦은 답변입니다만... 아쉽게도 그렇지 않습니다. kldp wiki에 있는 문서들, 이곳 kldp.org 에 있는 글들 및 답글들, 그리고 kldp.net 에 있는 프로그램 소스코드와 사용자들이 올린 각종 글 및 답글들 등이 데이터가 될 터인데 wiki에서 저작권이 명확히 설정되어 있는 글글과 kldp.net 에서 역시 저작권이 명확히 설정되어 있는 소스코드를 제외한 나머지 데이터들(글 / 답글 등)은 모두 각자 글쓴이에게 저작권이 귀속되어 있어 명시적으로 허락을 받지 않는 한 임의로 전재나 수정후 재배포 등이 불가합니다.

그리고 이러한 데이터들이 최종 사용자들에게 전달되는 형태도 거의 대부분 웹브라우저를 통해서만 가능하며 RSS를 통해서 일부 feed들이 제공되고 있고 그나마 kldp.org 에서 좀 다양한 형태로 RSS가 제공되지만 RSS 이상의 API 등은 제공되지 않으므로 매쉬업 등의 서비스는 불가능한 상황입니다.

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.