IT 종합뉴스서비스

현재의 개발환경은 노하우(know how)보다 노웨어(know where)에 더 큰 성패가 달려 있다. 즉 어떻게 짤 것인가의 고민 보다는 문제 해결에 유용한 이미 잘 만들어진 오픈 소스를 찾아 내어 활용하는 세상이 된 것이다. 아파치 재단처럼 오픈 소스 프로젝트들을 통해서 공개된 라이브러리들을 손쉽게 접할 수 있는 시대의 개발자인 것에 대해 감사한다. 삽질을 덜 하기 때문이 아니라 더 나은 문제들을 고민할 기회가 주어졌기 때문이다. 2부에서는 자바 언어를 중심으로 오픈 소스 활용방법에 대해 알아보자.

개발자는 두 가지 부류로 나눌 수 있다. 첫째는 코드를 만들기 좋아하고, 무언가 스스로 창조한다는 생각으로 프로그래밍을 즐기는 사람들이다. 이 부류의 특징은 무엇인가 만들고 그것이 돌아간다는 사실에 만족할 뿐만 아니라 내부적인 소스의 설계와 미학에 관심을 두고 스스로 연구하고 노력해서 자기의 프로그램을 만들어 간다.

두 번째 부류는 컴퓨터 프로그래밍 이외의 직업은 포기하고 프로그램을 짜주면서 생계를 이어가는 직업적인 프로그래머이다. 이들은 무엇인가 짜서 돌아가면 안도한다. 더 나아가 버그가 없기를 간절히 소망하며, 내가 짠 프로그램은 다시 보고 싶어하지 않는다는 특징이 있다. 제일 싫어하는 단어는 납기일이고, 프로그래밍에서 낭만을 찾는 것은 상상하기 어렵다.

이 두 부류의 개발자들에게 오픈 소스 라이브러리가 주는 의미는 다르겠지만 둘 모두에게 유익한 존재임에는 틀림없다. 첫 번째 부류에게는 오픈 소스를 이용해서 더 나은 무언가를 만들 기회가 생기는 것이고, 또 오픈 소스 자체에서 배울 점이 많기에 유익하다.

두 번째 부류에게는 바닥부터 삽질하면서 코딩 하지 않아도 되므로 개발 시간을 절약할 수 있는 이점을 갖고 있다. 물론 이는 조금 과장된 이분법이다. 독자 중에는 양쪽 모두에 해당하는 사람과 이도 저도 아닌 사람도 있을 것이다. 오픈 소스에 안 좋은 추억이 있는 독자가 있을지 모른다. 그래도 필자가 권하는 것은 오픈 소스에 열린 마음으로 다가서라는 것이다.

오픈 소스 라이브러리 어디에 있나
전세계 오픈 소스 프로젝트의 산실이라고 할 수 있는 사이트들이 많다. 현재 등록된 오픈 소스 프로젝트 수는 124,905개이고, 등록된 회원만도 1,351,300명에 달한다. 전 세계에 개발자가 이렇게 많다. 다양한 언어와 다양한 분야에 해당하는 개발 관련 프로젝트가 등록되어 있기 때문에 이곳에서 검색하면 12만개의 프로젝트 중에 비슷한 것(?) 하나 이상은 걸릴 지도 모른다.

● 소스포지 http://sourceforge.net
라이브러리뿐만 아니라 다양한 카테고리의 오픈 소스 프로그램들이 들어차 있는 곳이다. 가장 잘 알려진 소스 프로그램 사이트는 소스포지(sourceforge.net)이다. 사이트 하단에 보이는 여러 카테고리는 우리가 프로그래밍할 수 있는 여러 분야들이 보인다. 구체적으로 좀더 자세히 토픽을 열어보면 각각의 프로젝트 토픽마다 수많은 오픈 소스 프로그램들이 존재한다. 정말 많다.

● KLDP.net
국내에도 소스포지와 같은 타입의 오픈 소스 저장소가 있다.

바로 권순선씨가 운영하는 KLDP.net(kldp.net)이다. 한국어로 된 좋은 환경과 사이트 내에서 지원하는 기능들은 소스포지와 유사하다. 오픈 소스로 무엇인가를 공개하고 싶다면 소스포지나 KLDP.net에 회원 가입한 뒤에 프로젝트를 등록하고 자신이 생각하는 프로그램을 키워가는 프로젝트를 시작할 수 있다.

지구상의 어느 곳, 작게는 우리나라의 어떤 개발자에게 자신이 만든 코 드가 의미 있게 보일 수 있다면 무언가 낭만적이지 않은가.

삶의 의미를 잃어버렸을 때 시장에 가서 열심히 살아가는 사람들의 모습을 보면서 인생의 활력을 찾는다는 얘기가 있다. 개발자로서 살아가는 재미를 잃어버렸을 때, 프로그램 코드 안에 존재하는 알파벳 한자한자가 아무 의미 없이 다가온다면 소스포지나 KLDP.net을 둘러보며 동시대를 살아가는 개발자들의 흔적들을 감상해 보는 것도 좋은 자극이 될 것이다.

● 아파치 재단
바야흐로 웹이 없다면 세상의 모든 통신선로가 끊긴 것 같아서 전 세계의 대다수 젊은이들이 답답해 할 것이다. 웹 세상의 기반 이 되는 웹 서버는 아파치 재단(www.apach.org)에서 만들어 공개한 아파치 웹 서버가 60% 이상의 점유율을 갖고 있다. 그 뒤를 이어 28% 정도를 MS의 IIS가 차지하고 있고, 기타 다른 서버들이 나머지 10%대에 포진해 있다.

IIS의 가격이나 아파치의 가격을 논하는 것은 의미가 없다. 점유율에서 알 수 있는 것은 적어도 아파치가 IIS보다 더 많은 이들에게 신뢰감을 주고 있다는 사실이다. 공짜는 믿을 게 없다지만 적어도 웹 서버 시장에서는 공짜 외에는 믿을 웹 서버가 없는 것 같다. 오픈 소스에 대한 신뢰감을 더하는데 아파치 웹 서버가 큰 공헌을 했다고 생각한다.

아파치 사이트에서 이뤄지는 수많은 프로젝트들은 웹 서버뿐 만이 아니다. 아파치에서 이뤄지는 톱 프로젝트들의 목록을 살펴보면 아래와 같이 요약할 수 있다.

프로젝트들의 성격을 크게 나누면 Httpd, James, Tomcat, Geronimo와 같은 제품류와 Ant, Gump, Maven, XmlBeans와 같은 툴 종류, Struts, Shale, Tapestry 와 같은 프레임워크류, DB 관련 프로젝트와 XML 관련 프로젝트들로 그룹 지을 수 있다.

목록을 보면 자바로 된 프로젝트들이 제법 많이 보인다. 서버 사이드 자바 프로젝트인 자카르타 프로젝트 안에 들어가 보면 또 다른 서브 프로젝트들을 확인할 수 있다. 이곳에서 키워져서 톱 프로젝트로 졸업해 나간 프로젝트들이 많다. 대표적으로 Ant, Maven, Struts, Tomcat 등을 꼽을 수 있다.

아파치를 놀리는 얘기가 있다. 「A Patch(덧댄 것)」. 오픈 소스의 장점이자 단점인 잦은 패치와 버전업. 도대체 가만히 있지를 않는다. 이 사람 저 사람이 손댄 누더기 같은 소스가 국내에서 운영되는 사이트들의 특징인 걸 보면 아파치의 수많은 커미터들이 만든 소스들도 비슷하지 않을까 생각해볼 수 있다.

하지만 걱정 할 필요 없다. TDD에서 얘기하는 테스트케이스들로 이뤄진 애플리케이션 테스트 프레임워크가 갖춰져 있어서 코드 변경으로 인한 부작용들을 빨리 감지하고 수정할 수 있는 시스템들이 있기 때문이다. 또한 하루에도 수백 수천 통씩 왔다갔다하는 메일링 리스트를 통해서 신속하게 의견을 주고받기 때문에 애플리케이션의 흠집은 금방 노출되게 마련이다.

오픈 소스 라이브러리 활용하기 오픈 소스에 대한 얘기를 너무 길게 했다. 이번에는 코드를 보면서 오픈 소스의 장점들을 느껴보자. 2005년 2월에 만들어진 용어 Ajax는 자바스크립트 라이브러리와 프레임워크들을 많이 만들어냈다. 이런 먼저 이들을 살펴보기 전에 필자가 직접 구축 했던 것과 대표적인 Ajax 라이브러리인 Prototype.js를 비교해 보자.

● Ajax
Ajax는 자바스크립트로 만들어진 애플리케이션이기 때문에 C/C++이나 자바 같은 애플리케이션에 비해 소스가 쉽게 노출 되는 특성이 있다. 그래서인지 몰라도 Ajax를 지원하는 자바스크립트 라이브러리들이 짧은 시간에도 불구하고 굉장히 많이 공개되었다.

필자도 2005년 하반기부터 Ajax를 공부하면서 직접 만들어서 사이트에 적용하곤 했는데, 올해 들어 Ajax와 관련된 프레임워크와 라이브러리들이 굉장히 많다는 사실을 접하면서 적잖이 놀랐다.(참고 사이트: edevil.wordpress.com/2005/11/ 14/javascript-libraries-roundup) 대표적인 곳이 바로 prototype.js이다. prototype.js는 다른 Ajax 프레임워크의 근간이 되기도 하거니와 1,400여 라인으로 많은 것들을 소화해 낸 덕분에 더욱 환영받고 있다.

Prototype.js의 대표적인 특징을 몇 가지 살펴보자. <리스트 1> 의 상단은 가장 많이 사용하는 자바스크립트 함수인 document.getElementById( “id”)를 축약한 함수인 $“( id”)를 보여준다.

하단의 $F( 「id」)는 input이나 select 같은 객체의 .value 값을 반환한다. 기존에 한없이 늘어지던 자바스크립트 의 길이를 줄임으로 가독성을 많이 확보했다는 사실을 알 수 있다. 물론 어떤 함수가 어떤 역할을 하는지는 스스로 알고 있어야 한다.

<리스트 1> Prototype.js $“( id”)

다음의 <리스트 2>는 필자가 직접 만든 Ajax를 활용한 태그 입력용 소스 부분이다. 콜백 함수를 지정하기 위해서 열심히 머리를 쓴 흔적이 보이는 코드인데, prototype.js에서 사용하는 코드에 비하면 너무 단조롭다는 생각도 든다.

하지만 창피함을 무릅쓰고 비교해 본다는 의미로 공개해본다.

로직은 간단하다. input 박스에 태그를 입력하고 “태그입력” 버튼을 클릭하면 saveTag() 함수가 호출되며 서버에 보내는 파라미터 스트링을 만든다. processAjax() 라는 함수를 호출해서 서버에 데이터를 보낸다.

서버에서 처리가 끝나면 processAjax() 에 파라미터로 보냈던 콜백 함수 doTag()가 실행되고, 서버에서 처리한 결과 메시지를 받아서 tagSaveMsg id를 갖고 있는 태그 내에 보여주는 코드이다.

<리스트 2> tagCustom.jsp ; ajax 태그 처리

이 소스를 prototype.js 버전으로 바꾼 것이 <리스트 3>이다.

<리스트 3> tagPrototype.jsp ; prototype.js 버전 ajax 태그 처리

<리스트 4>는 입력된 태그를 서버에서 처리해주는 코드이다. <리스트 2>와 <리스트 3>을 비교해보면 코드 량도 줄고, 정제된 것을 알 수 있다. 이와 같이 라이브러리를 사용하면 직접 짤 때의 수고를 많이 줄일 수 있다. 또 이미 검증된 로직으로 안전하고 빠르게 애플리케이션을 작성할 수 있다.

<리스트 4> tag.jsp 서버 측 태그 처리

오픈 소스를 이용해서 프로그래밍할 때 필요한 것은 자기가 쓰고 있는 라이브러리나 프레임워크에 대한 정확한 이해다. 남이 만들어 놓은 것을 사용할 때 꼭 2% 부족한 기능들이 있다. 이때 많은 시간을 삽질하게 되는데, 선택의 기로마다 결정해야 하는 순간이 있게 된다. 버리고 새로 짤 것인가, 자세히 탐구하고 확장할 것인가.

선택이 쉽지 않다. 만사가 다 그렇지만 프로그램을 작성함에 있어서 조급함은 금물이다. 차용해서 쓰는 라이브러리나 프레임워크의 진면목을 깨닫고 사용할 것인지, 아니면 공개된 소스를 바탕으로 직접 만들어서 쓸 것인지의 결정은 개발자 스스로에게 달려 있다.

필자는 라이브러리나 프레임워크의 참 맛 을 깨닫기 위해 여유 시간을 확보해서, 성급한 프로그램 납기로 인한 버그 후폭풍을 미연에 방지하기를 바란다.

오픈 소스 라이브러리를 잘 사용하는 법

● RTFM (Read The F」cking Manual)
메일링 리스트나 뉴스그룹에서 RTFM(Read The F」cking Manual)이란 말을 자주 볼 수 있다. 질문과 답변이 오가는 가운데, 매뉴얼만 읽어봤다면 쉽게 해결할 문제를 물어오는 사람에게 돌아오는 답변은 아주 간단할 때가 많다.

RTFM은 「매뉴얼 좀 봐라」라는 뜻이다. 일단 눈 여겨 봐야 될 매뉴얼들은 README 파일, 설치 가이드(Install Guide), 퀵 가이드(Quick Guide), 사용자 가이드(User Guide), 잦은 질문(FAQ; Frequently Asked Question), 프로젝트 문서(Project documentation) 순이 될 것이다.

README 파일은 보통 다운로드 받은 패키지의 압축을 풀었을 때 루트 디렉토리에 있는 텍스트 파일이며 패키지에 대한 개괄적인 내용을 담고 있다. 설치 가이드는 요구되는 시스템 사양, 설치할 때 주의사항, 설치하기 전 사전 작업, 설치되는 경로나 디렉토리 구성 등에 대한 정보를 담고 있다.

퀵 가이드는 성미가 급 한 사람들에게 딱 맞는 가이드이다. 제품을 따라서 돌려 볼 수 있는 가장 빠른 방법을 소개하고 있다. 간단히 시연을 해보려고 할 때 매우 도움이 되는 매뉴얼이다.

사용자 가이드는 제품에 대한 교과서이다. 하나에서부터 열까 지 모든 내용을 담고 있고, 가장 분량이 많은 문서이다. 그리고 잦은 질문에 대한 답변을 모아 놓은 문서도 꼭 챙겨 볼 필요가 있다.

제품의 정의나 비하인드 스토리와 같이 매니아 수준의 관련 정보를 얻을 수 있는 문서이다. 프로젝트 문서는 프로젝트 전반 에 걸친 설명이 들어가 있는데, 프로젝트의 목표나 비전, 지향하는 바를 알 수 있다.

오픈 소스 프로젝트의 대부분은 영문으로 되어 있는데, 가끔씩 「Korean」링크를 발견하고 반가울 때가 있다. 일본어로 번역된 문서들은 제법 많은 반면 한국어로 된 문서가 없어서 아쉬울 때 가 많지만, 개인적으로 문서를 번역해서 인터넷에 페이지를 공개해 놓은 뒤에 프로젝트 운영자에게 메일을 보내서 링크를 시키는 경우가 종종 있다.

또한 영문 번역은 봐주기 힘들지만, 일본어 번역은 상당히 잘 되는 편이라 번역 프로그램을 써서 일어로 된 문서를 번역한 뒤에 읽기 어색하지 않도록 손봐주는 번역방법으로 국내 개발자들을 위해 수고하는 분들도 있다. KLDP는「Korean Linux Documentation Project」라는 뜻대로 많은 문서를 번역해 왔고, 아파치 쪽 문서도 많은 부분이 한글화되어서 서비스되고 있다. 이 외에도 수많은 영문 기술 문서들이 번역되어서 공개되어 있으니 매뉴얼을 자주 보길 바란다.

급한 마음에 오픈 소스 라이브러리를 가져다 쓰면 반드시 사고가 나게 되어 있다. 평소에 이런 오픈 소스 라이브러리들에 대해서 매뉴얼을 보면서 숙련하는 것이 중요하다.

● 쓰고 또 쓰고
습관이 성격을 만들고 성격이 인생을 만든다는 말이 있다. 오픈 소스 라이브러리가 아무리 좋아도 자꾸 반복해서 쓰지 않으면 매번 버벅거릴 수밖에 없다. 베스트 프랙티스(Best Practices)라는 말을 들어본 적이 있을 것이다.

머리로 아는 것만으로는 부족하다. 자꾸 써봄으로 몸에 익힐 때 제대로 사용할 수 있는 것이다. 오픈 소스 라이브러리가 다양하게 있지만 이들은 대부분 비슷한 패턴을 가지고 있다. 하나를 제대로 쓸 줄 알게 된다면 다른 것도 쉽게 가져다 쓸 수 있는 기반이 마련되는 셈이다.

오픈 소스의 생태계(ecosystem)를 보면 제일 하층에는 사용자 (Users)가 있다. 그 위에는 좀 더 능숙하게 설정을 변경하면서 사용하는 그룹(Configurers)이 있고, 현재 있는 것에 프로그래머 의 실력을 발휘하고 확장해서 사용하는 그룹(Extenders)이 그 위에 있다. 그 다음 차례는 자기 혼자만 쓰는 것이 아니라 모두에게 오픈해서 함께 쓰도록 만드는 그룹(Publishers)이 있다.

또 이렇게 확장된 것에 다른 개발자들도 더 개선할 수 있도록 참여 시키는 그룹(Enabler)이 있다. 최종적으로는 프로젝트에 합류해 서 근원에 해당하는 소스를 버전컨트롤 시스템에 변경해서 커밋(commit)할 수 있는 커미터의 자격이 주어지게 된다. 안 보면 멀어진다는 속담처럼 안 쓰면 못 쓰게 된다.

● 트러블 슈팅은 메일링 리스트와 구글신에게
오픈 소스가 제대로 운영되는 곳이라면 보통 세 가지 시스템은 가지고 있다. 서브버전이나 CVS 같은 버전 컨트롤 시스템이 그 첫 번째이고, 개발자와 사용자 간의 의사소통을 위한 메일링 리스트가 그 두 번째 그리고 버그질라와 같이 리포트된 버그를 관리하는 버그 및 이슈 관리 시스템이다.

이미 능동적인 사용자들 이 메일링 리스트와 버그질라를 통해서 각 버전마다 발견되는 문제점들을 토론한다. 때문에 오픈 소스 라이브러리를 사용하다 만나게 되는 문제들은 이들 시스템에서 검색해 볼 경우 해결점이나 버그 퇴치 상태를 알 수 있다. 물론 대부분 영문으로 되어 있지만 조금만 더 신경 써서 본다면 어렵지 않을 것이다. 익숙함의 문제이다.

다른 문제 해결 방법은 검색엔진을 이용하는 것이다. 개발자들은 에러를 만나면 보통 구글이나 네이버 지식인 등을 이용한다.

에러 메시지를 검색창에 붙여 놓고 검색을 해보면 각 사이트의 게시판에 올라온 질문들이 검색되는 탓이다. 링크된 페이지에 가보면 같은 문제로 고민하는 여러 개발자들의 질문과 친절 하게 올린 답변이 달려 있는 것을 볼 수 있다. 필자는 구글을 많이 이용하는데, 거의 못 찾는 에러 메시지가 없을 정도로 검색이 잘 되기 때문에 다른 이에게 들은 대로 구글신(..)처럼 모시며 개발하고 있다.

오픈 소스 라이브러리 구축하기

● 시작은 초라하더라도
세상을 변화시키는 프로그램들의 공통점은 자신의 필요에 따 라 만들어진 프로그램을 공개함으로 시작되었다. 리눅스가 그랬고 ANT가 그랬다. 리눅스의 시작은 많이 들어서 알 것이고, 요즘 많은 자바 프로그래머들이 사용하는 ANT(Another Neat Tool)는 톰캣을 빌드하는데 Make를 쓰다 답답해진 제임스 던컨 데이비슨(James Duncan Davidson)이 자신의 개발환경을 개선 하고자 만든 작은 프로그램이었다.

자바의 특성처럼 다양한 OS 에서 빌드 스크립트 하나로 톰캣 소스를 빌드 해보자는 의도로 시작되었고, 이것이 아파치 프로젝트를 통해서 공개되었다. 그 후에 많은 개발자들이 자신의 업무 환경에 맞게 확장시켜서 현재 의 위치에 이르게 된다. Ant 사이트(ant.apache.org)에 가보면 그 열기를 실감해 볼 수 있을 것이다.

매뉴얼 페이지에 보이는 그 모든 태스크들은 첫 개발자가 의도하지 못했던 다양함으로 채워 져 있다. 작은 불씨가 큰 불을 낼 수 있듯이 자신의 프로그램을 만 천하에 공개하는 행위는 바람직하다고 본다.

● 쪽팔림(?)을 무릅쓰고
개방적인 가정이 있고, 보수적인 집안 문화가 있다. 개방적인 문화에서는 실수에 대해서 쉽게 인정하고, 개선하는 것에 대해서 자연스럽게 반응하지만, 보수적인 문화에서는 반대의 경우가 많다. 감추고, 슬쩍 넘어가고, 어떻게 되겠지 라는 막연함이 자신의 실수를 덮어버리게 된다.

개발자들 가운데에도 남이 자신의 소스를 보는 것에 대해서 부담스럽게 여기거나 창피하게 여기는 경우가 많은데, 그러지 말자. 필자는 소프트웨어 개발을 애를 낳아 키우는 것에 비유하기를 좋아한다. 필자는 종종 SI(System Integration) 프로젝트는 애를 낳은 뒤에 떠나는 것처럼 보여서 씨받이 프로젝트라고 하고 SM(System Maintenance) 업무는 유모의 역할이라고 한다. 유지보수 개발 업무를 잘 해서 사회에 도움이 되는 시스템으로 잘 키워야 된다고 비유하고는 한다.

자식에 대해서 닫힌 태도로 키우면 애를 망치기 쉽다. 다양한 경험을 하게 하고 변화하는 환경 에 맞춰서 개선해 나가는 노력이 있어야 발전 가능성도 높아진다. 타성에 젖어서 늘 하던 대로 기계적으로 개발하면 지루해지기 때문에 오래가기 힘들다.

자신의 소스가 볼품없더라도 옆의 개발자와 함께 리뷰하고, 많은 개발자들에게 오픈해서 여러 피드백을 받는 것은 어떤가? 좋아지는 소스뿐만 아니라 공감대를 형성하는 많은 개발자들을 만나게 될 것이다.

● 검색 가능한 명세서 작성
프로젝트를 개발할 때 코딩작업만 열심히 한다고 해서 일이 끝 난 게 아니다. 개발 도중에 소스들을 통합해 보면 함수 명이 서로 다르면서 같은 기능을 하는 함수들이 부지기수이다. 이간은 예를 보더라도 프로젝트의 공통 파트가 없거나 있어도 직무 유기를 한 것이다. 남이 만든 것을 가져다 쓸 수 있는데, 또 똑같은 것을 만드는 것은 시간 낭비이다. 허무해진다.

이런 중복 개발을 막기 위해서는 개발자간의 커뮤니케이션이 원활해야 한다. 함께 개발하는 사람들이 어떻게 일을 하는지 알고 있어야 한다. 뭔가 좋은 아이디어가 생겼을 때 자기만 알고 있어선 안 된다. 전체 메일을 날려서 함께 리뷰하고, 위키나 게시판 등을 통해서 공유하는 노력 이 있어야 전체 프로젝트의 질이 높아진다. 중요한 것은 검색이다. 손에 닿을 수 있어야 가져다 쓸 수 있다.

● 개선 그리고 개선
앞에서 얘기한 대로 프로그램은 정체되지 않는다. 바이러스와 백신의 관계처럼 여러 가지 경우에 따라서 프로그램의 수정 및 추가는 계속 이뤄진다. 프로그램을 개선하는 것은 만만치 않은 일이다. 그렇다고 구조를 바꾸지 않고 계속 갖다 붙일 수도 없다.

이 때 필요한 기술이 테스트 프레임워크와 리팩토링이다. 리팩토링은 설거지에 비유되기도 하는데, 매번 급히 음식을 만들어 먹 고 배가 부른 뒤 뒷정리를 하지 않으면 다음 요리할 때 번거로운 일이 점점 많아질 것이다. 쉬파리 같은 버그도 많이 꼬일 것이다.

중복된 코드를 함수로 만들고, 변수 명은 의미를 쉽게 파악할 수 있도록 수정하고, 구조가 유연하도록 모듈화시키는 작업이 리팩토링이다. 프로그램을 쓸모 있게 자라게 하려면 기름치고 닦고 조여주는 일이 계속되어야 한다.

● 샘플 코드와 매뉴얼을 잊지 말자
세상의 모든 프로그래머들을 다 믿을 수는 없다. 심지어는 자기것도 그렇다. 자기가 짠 프로그램도 3개월 뒤에 보면 마음에 안 든다. 어떻게 이렇게 짰는지 통 기억이 나지 않는다. 특히나 라이브러리들은 인터페이스가 중요하다.

입력과 출력에 대해서 명확히 정의 해놓은 매뉴얼이 필요하고, 이를 활용한 샘플코드도 있으면 좋다. Ant 사이트의 매뉴얼이나 MySQL 사이트의 문서들이 잘 되어 있는데, 전자를 보면 하단에 여러 경우의 샘플 코드 들을 볼 수 있다. 후자의 경우는 매뉴얼 하단에 여러 사람들이 코멘트를 달아서 내용을 보충할 수 있도록 되어 있다.

코드에 대한 문턱을 낮추어서 많은 이들의 사용을 유도하는 것도 오픈 소스 개발자가 잊지 말아야 할 요소이다.

지금까지 오픈 소스 라이브러리를 활용하는 방법에 대해서 필자가 생각하고 있는 것들을 적어 보았다. 실무적으로 접근해서 친절하게 가이드 하지 못한 점은 죄송하게 생각한다. 힘들게 개 발한 소스에 집착하지 않고, 오픈 해 준 전 세계의 개발자들에게 고마운 마음을 가져보자.

아직도 일부에서 오픈 소스는 책임감 (ownership)이 없다라고 떠들면서 자사 제품을 판매하는지 모르겠다. 세상은 많이 변했고, 오픈 소스의 위상도 많이 높아졌다.

돈을 누가 지불하고 책임을 누가 지느냐에 대한 것은 오픈 소스를 향한 잣대가 아니다. 남이 개발한 것을 이어받아 좀 더 나은 무엇인가를 만들어 가는 것, 이 사이클이 멈추지 않고 계속 이어져 멋진 제품을 만들어 내는 것, 이것이 오픈 소스가 지니고 있는 진정한 가치이다. @

오픈 소스와 상용 벤더와의 관계

아파치와 자바의 관계는 1999년부터 본격적으로 시작되었다. 아파치 소프트웨어 재단과 처음 손을 잡은 것은 IBM이었고, 이후 썬 마이크로시스템 에서 전폭적으로 지원하면서 오픈소스 자바프로젝트들이 활기를 띄게 되었다. JSP를 지원하는 톰캣 웹 어플리케이션 서버가 그 첫출발이었다.

벤더에서 아파치 쪽으로 위탁한 프로젝트가 몇 가지 있는데, IBM은 포틀릿 프로젝트인 포털 탑 레벨 프로젝트이며 처음에는 자카르타의 서브프로젝트인 제트스피드이었다.

BEA는 작년에 비하이브(Beehive)라는 J2EE와 스트러츠를 이용해 쉽게 엔터프라이즈 어플리케이션을 만들 수 있는 프로젝트를 아파치에 위탁했다. 오픈 소스의 장점을 이용해서 프로젝트의 완성도를 높이고, 성숙기에 접어든 프로젝트들은 기업의 제품에 다시 포함시켜 서 판매한다는 전략이다.

오픈 소스 수익모델의 다른 방식은 JBoss나 MySQL과 같은 전략이다. 처음에는 오픈 소스로 공개를 하고 많은 사람들의 참여를 이끌어 낸다. 또, 제 품으로 손색이 없을 정도로 성장을 하게 되면 소스 자체를 판매해서 수익 모델을 이끌어 내기 보다는 기술 지원이나 자격증, 컨설팅 등을 수익 모델로 만들어서 판매하는 방식이다.

JBoss는 WAS 시장에 이미 많은 쟁쟁한 벤더들이 포진하고 있었고, MySQL도 이미 DB시장에 경쟁자들이 존재했지만, 점차로 시장 점유율을 넓혀가면서 마이너가 아닌 메이저급으로 성장했다.

국내에서는 오픈 소스에 대한 신뢰가 조금씩 쌓이고 있다. 대규모 프로젝트에서 오픈 소스 프레임워크가 표준으로 지정되고, 사내의 프로젝트일 경우 오픈 소스로 된 시스템을 사용하는 경우는 점점 많아지고 있다.

아직 오픈 소스의 기술지원이나 책임소재에 대해서는 확신을 갖지 못했기 때문에 공개적인 프로젝트에서 공식 지정되지는 못하고 있다. 반면, 오픈 소스의 사용영역이 점차 넓혀져 가고 있는 것은 사실이다.

오픈 소스 모듈을 자사 제품에 끼워서 파는 경우도 많이 있다. 특히 자바의 경우에 빈번한데, 모든 자바 제품들은 Ant 외에도 아파치 커먼스 프로젝트 의 라이브러리들을 몇 개씩 포함하고 있다.

수많은 사람들의 사용과 참여를 통해 정제된 오픈 소스의 장점은 소스가 공개되어 있기 때문에 보안상 취약할 것이라는 단점을 불식시키고 있는 셈이다. 발견된 보안 이슈는 곧 패치 되기 때문이다.

IBM의 경우 오픈 소스를 통해서 자바툴 시장을 확 뒤집어 놓았는데, 그 이유는 이클립스 제품을 오픈 소스로 풀어 놓고 새로운 툴 시장을 만들고 있다. 이클립스는 자바IDE가 목적이 아닌 모든 툴들의 플랫폼이 되겠다는 야심찬 계획하에서 진행되고 있는데, 이에 따른 여파로 볼랜드가 자바IDE를 더 이상 진행하지 않겠다는 발표도 나왔다.

오픈 소스에 대한 개발자들의 호감을 이끌어 냄과 동시에 참여를 이끌어 냄으로 제품의 빠른 성장을 도모했다. 2006년 현재 자바IDE 시장은 이클립스로 평정되었다고 해도 과언이 아니다.

오픈 소스가 개발자들에게 주는 자유감과 자발적인 참여가 계속되는 한 그 행진은 멈추지 않을 것이다. 필자가 오픈 소스를 좋아하는 이유이기도 하다.

참고자료
1. 소스포지(sourceforge.net)
2. KLDP.net(kldp.net)
3. 아파치 재단(www.apache.org)
4. 자카르타 프로젝트(jakarta.apache.org)
5. Ant 빌드 툴 매뉴얼(ant.apache.org/manual)
6. 메일링 리스트 아카이브(www.mail-archive.com)
7. Contributing to eclipse, Erich Gamma, Kent Beck, 2003, Addison Wesley

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