오픈소스 모델과 한국적 상황

1998년 10월, 마이크로 소프트웨어 잡지에 쓴 글입니다. 에릭레이몬드의 성당과 시장이라는 글을 보고 한국적 특수성에 대해서 말하고 싶었던 것이 있었습니다. 세월은 많이 지났지만 그때와 달라진 것이 무엇이 있을까 생각해 봅니다. 앞 부분은 조금 딱딱하지만 뒷부분은 그래도 조금 읽을 만 할 것입니다. 국내 개발자가 바라본 시장 모델과 한국적 상황           에릭 레이먼드(Eric S. Raymond)가 작성한 '성당과 시장(The Cathedral and the Bazaar)'은 상업용 소프트웨어와 공개 소프트웨어(이하 오픈 소스 소프트웨어라 한다. 공개와 free라는 의미가 주는 부정적 이미지를 탈피하기 위한 것이다)의 개발 방식 차이를 성당과 시장으로 비유해 각 모델의 차이를 쉽게 이해할 수 있게 해주었다. 보다 이해하기 쉽게 편역된 내용이 앞에 소개되어 있으니 소프트웨어 개발자라면 한 번쯤 읽어보기 바라며, 심기일전하는 기회가 되기를 바란다.   이번 글에서는 '성당과 시장'에서 주장하는 상업용 소프트웨어 개발 모델과 오픈 소스 개발 모델의 차이를 간략히 살펴볼 것이다. 그리고 필자의 경험을 바탕으로 국내에서 오픈 소스 개발 모델을 따를 경우, 외국과 어떤 차이가 있으며 어떤 방식으로 프로젝트를 진행해야 하는지, 그리고 필요한 것은 무엇인지 알아보도록 한다.       성당모델       상업용 소프트웨어 개발은 소수의 뛰어난 개발자가 모든 개발 과정을 독점한다. 디자인에서부터 설계, 코딩, 그리고 주요 베타 테스트도 내부에서 이뤄지며 사용자가 접할 수 있는 것은 내부 테스트를 거친 완성된 버전이다. 마치 성당을 건축하듯이 개발자는 고고한 고독 속에서 사용자로부터 방해 받지 않고 작업하는 것이다.   소스 코드는 당연히 개발자와 그 회사만 사용할 수 있고 모든 것은 그들이 소유한다. 상업용 소프트웨어의 소스 코드를 공개한다는 것은 꿈도 꿀 수 없는 일이다. 소프트웨어 개발은 오랜 시간이 필요한 일이며, 한 버전이 발표된 후 그에 따른 기능 개선도 모두 개발자와 회사의 의지에 따라 결정된다. 물론, 새로운 기능을 추가한다는 것은 힘든 작업이며 경우에 따라서는 프로그램 구조를 완전히 바꿔야 하므로 다음 버전의 발표 일정이 연기되거나 기능 추가가 다음 버전으로 밀리는 것도 보통이다.   버그 제거도 쉽지 않다. 사용자가 알려온 버그는 복잡한 과정을 거쳐 개발자에게 전달되며 일부 개발사는 확실한 버그도 인정하기에 인색한 경우도 많다. 성당 모델에서의 버그 제거는 소수의 개발자가 전체를 훑어보면서 원인을 파악해야 하고 그 해결책을 고심해 만든 후, 이를 적용한 프로그램을 정밀하게 검사해 버그가 해결되었다는 확신을 가져야 하는 것이다. 이렇게 버그가 제거된 후에야 개선판을 발표할 수 있다. 종종 버그를 없애기 위한 해결책이 또 다른 버그를 만들기도 하므로 개선판 발표는 생각보다 시간이 많이 걸리고 새로운 버그가 사용자를 실망시키기도 한다.   결국 프로그램이 거대할수록 '프로그램 발표→버그 리포트→인정→디버깅→검사→개선판 발표' 주기가 길어지고 그에 대한 해결책도 불완전한 경향이 있다.   에릭 레이먼드는 상업용 소프트웨어 개발 모델로 성당(중세의 성당을 의미할 것이다)을 제시하며 설명했지만, 오픈 소스 개발 모델에 대해서는 자세하게 설명하지 않았다. 물론, 성당 모델에 든 예는 부정적인 면만 다룬 것일 수 있지만 이미 소프트웨어를 만드는 대부분의 회사가 따르는 방식이므로 별도의 설명이 없어도 쉽게 이해할 수 있을 것이다.       시장 모델       리눅스 개발로 대표되는 시장 모델에서는 사용자와 개발자가 분리되어 있지 않다. 프로그램 소스 코드가 공개되어 있어 여건이 되면 사용자가 직접 원하는 기능을 추가할 수 있고 버그를 고칠 수도 있다. 이렇게 개선된 소스 코드를 개발자에게 전달할 수 있고 개발자는 사용자가 고친 소스 코드도 적극적으로 반영한다.   사용자가 이렇게 개발에 능동적으로 참여하는 것은 모두 자기 의견을 내며 떠드는 시장과 같은 모습이다. 전통적인 방식을 추구하는 개발자의 눈에는 산만하고 불안정하며 신뢰성이 없는 방법처럼 보인다. 그러나 산만하고 불안정하며 신뢰성이 떨어져 보이는 이런 방식으로 개발, 발전한 리눅스가 상업용 운영체제에 뒤지지 않는 성능과 기능을 갖게 되었으며 미래의 운영체제로 급부상하고 있는 모습은 가히 경이로운 것이다.   성당 모델과 시장 모델의 가장 큰 차이는 사용자를 바라보는 관점에 있다. 시장 모델에서는 사용자를 버그 제기와 기능 개선의 중요한 참여자로 생각하며, 사용자는 개발자가 미처 파악하지 못한 부분을 보고 개발 과정에서 고려하지 않은 부분을 실험하기도 한다.   버그가 발생했을 경우, 성당 모델에서는 한정된 개발자가 원인 분석부터 해결까지 스스로 처리해야 하지만 시장 모델에서는 수많은 사용자가 동시에 문제를 바라보니까 그 중 누군가에게는 간단한 문제일 확률이 높다. 모든 사용자가 초보자는 아니기 때문에 또 다른 전문 개발자가 있을 수 있으며, 비슷한 범주에 드는 문제를 해결한 경험이 있는 사용자가 개선시켜 줄 가능성이 존재 한다. 에릭 레이먼드는 이런 식으로 '디버깅은 병렬 처리가 가능하다'라고 설명했다.   이런 상승 작용을 믿고 시장 모델은 버그를 두려워하지 않는다. 새로운 제안을 신속하게 실험해 적용하고 그 결과를 사용자에게 제공한다. 따라서 시장 모델에서는 개선판이 공개되는 주기가 대단히 짧다. 같은 문제를 해결하고 있는 여러 사용자 중 누군가 먼저 해결했다면 이를 신속하게 공개하기 때문에 디버깅 중복이 거의 일어나지 않는다. 결국 사용자가 새로운 버그를 알려주고 이를 개선해 공개하는 과정에서 점차 버그는 사라지고 신뢰성이 높아지는 것이다. 때문에 시장 모델의 개발자는 버그를 절대로 해결하지 못할 문제로 생각하지 않으며 부끄러워하지도 않는다.   시장 모델에서 '준 개발자' 위치를 얻는 사용자에게 주어지는 것은 단지 해커로서의 명성이다. 개발자는 그들이 제공한 의견을 중요하게 생각해 적극적으로 반영함과 함께 공헌자 명단에 기꺼이 포함시키고 도와준 것에 대해 공개적으로 감사한다. 이런 명성은 다른 방법으로는 획득할 수 없는 소중한 것이며 시장 모델을 이끌어가는 중요한 원동력이다.   사용자는 자아만족을 얻기 위해 자신의 시간을 투자해 열정적으로 개발에 참여하게 된다. 성당 모델에서 엄청난 자금이 필요했던 작업을 시장 모델에서는 이런 자아만족이라는 무기를 바탕으로 자발적으로 끌어낼 수 있다. 뛰어난 실력을 가진 사용자의 공동 노력이 오히려 성당 모델의 생산성을 능가하는 것이다.   오늘도 인터넷에는 시장 모델에 근거한 다양한 소프트웨어 개발 열기가 날로 팽창하고 있다. 넷스케이프는 시장 모델에 대한 에릭 레이먼드의 글을 읽고 그들의 소프트웨어를 오픈 소스 형태의 개발 방향으로 바꾸기로 했다고 한다. 리눅스에 대한 지원이 점점 늘면서 공공연히 마이크로소프트의 운영체제에 대항할 대상으로 거론되고 있다. 그야말로 새로운 개발 모델에 대한 열광과 기대는 이미 전지구적이며, 성공에 대한 확신은 거의 흔들림이 없어 보인다.   그러면 국내 사정은 어떤가? 한국에서의 오픈 소스 개발 모델은 어느 정도 실현되고 있으며 앞으로 어떻게 진척될 것인가? 이제부터 오픈 소스 개발 모델에 대한 글을 읽으면서 한국의 개발자로서 느꼈던 지역적 특성에 대해 말해 보기로 하겠다. 그 전에 에릭 레이먼드가 오픈 소스 개발 모델의 실제 과정을 서술한 부분을 필자의 한 프로그램 개발에 비춰 알아보기로 하자.       필자의 시도와 좌절, 그 경험담       한국의 리눅스 개발자라고 하면 리눅스의 한글화에 관심을 갖는 것은 당연하다. 필자도 마찬가지로 초기에는 한글화에 관심을 갖고 있었다. 회사에서는 리눅스를 이용하는 네트웍 멀티 프린터 드라이버를 만들었기 때문에 커널을 뒤지는 것이 주요 업무였지만, 집에서는 X 윈도우 한글화에 관심을 갖고 작업했다. 그래서 하니멕 19.34b의 한글 패치와 한엑스 3.2A 버전업 등에도 참여했다. 이런 작업 외에도 리눅스 기반의 개인 작업으로는 getwww라는 웹사이트 미러링 프로그램의 개발이었다.   에릭 레이먼드의 글 중에는 '모든 좋은 소프트웨어 작업은 개발자의 가려운 곳을 긁기 위해 시작한다(성당과 시장)'라는 말이 있다. 필자도 마찬가지로 인터넷 연결을 위해 집에서 co-lan을 사용하고 있었는데 속도가 무척 느렸다. 웹 페이지를 한 번 보려면 인내심을 갖고 기다려야 했던 것이다. 관심 있는 국내 잡지 사이트를 읽기 위해 엄청난 시간이 필요했다. 그래서 웹사이트 문서를 한꺼번에 긁어오면 좋겠다는 생각을 했고 인터넷을 뒤지며 웹의 내용을 그대로 가져오는 미러 프로그램을 찾아 나섰다. 필자도 일단 원하는 프로그램이 존재하는지 조사한 것이다.   이미 원하는 기능을 가진 괜찮은 프로그램이 있다면 구태여 모든 직접 만들 필요는 없지 않은가. 한 프로그램이 그런대로 원하는 기능을 갖고 있었다. 우선 이 프로그램을 사용해 읽고 싶은 사이트를 미러링한 다음 원하는 시간에 로컬 컴퓨터에서 읽었다. 느린 네트웍에 상관 없이 읽을 수 있었기 때문에 만족하고 한동안 사용할 수 있었다.   하지만 부족한 부분이 눈에 띄자 그 프로그램을 조금씩 손대기 시작했고, 결국 누더기가 되었다. 그래서 필자의 미러 프로그램, getwww를 만들기 시작했다. "상황에 따라서는 던져 버릴 계획을 세웠고 결국 그렇게 된(에릭 레이먼드, 성당과 시장)" 것이다. 이전 프로그램이 처리하지 못하는 수많은 기능에 대한 아이디어가 떠올랐고 코딩하면서 효율적이고 성능 좋은 프로그램에 대한 욕심이 생겼다. 이전 프로그램을 참조해 보다 나은 방법을 구상하면서 즐겁게 작업할 수 있었던 것이다.   새 프로그램은 인터넷으로 공개할 것을 처음부터 고려해 이름도 다른 프로그램과 겹치지 않게 만들었고 세련된 코드를 갖도록 노력을 했다. 그때쯤 윈도우 환경을 위한 상업용 소프트웨어가 있다는 것을 알게 되어 직접 사용해봤지만 원하는 기능은 여전히 충족시켜 주지 못했다. 따라서 여전히 이전 프로그램을 사용해 웹을 미러링 했지만 그 프로그램에 대한 기능 개선은 중단하고 새로 만드는 프로그램에 정성을 집중했다.   하지만 웹이라는 매체의 특징이 프로그램 코딩을 어렵게 만들었다. 웹은 수많은 참조 노드로 이뤄져 있어 넓이 우선 탐색을 하다 보면 참조 노드가 메모리를 가득 채워버려 프로그램 수행이 어려웠고, 깊이 우선 탐색을 하다 보면 하드 디스크를 모두 채워 시스템이 다운되는 문제가 있었다. 게다가 자바와 CGI, 이미지맵까지 괴롭혔다. 이런 문제로 코딩이 지지부진했고 이전 프로그램을 그렇게 만들 수밖에 없는 이유를 이해하게 되었다. 하지만 해결하지 못할 문제는 없다는 생각으로 하나하나 작업해 나갔다. 문제를 해결하기 위해 언어를 C에서 C++로 바꾸기도 하고 탐색 우선 순위를 공부하기 위해 자료구조론 책을 다시 뒤져보면서 점점 프로그램이 완성되어 가고 있었다.   어느 정도 완성되자 초기 베타 버전으로 여러 사이트를 미러해보면서 문제점을 하나씩 해결해 나갔다. 여기 저기 평소에 관심 있게 드나들던 사이트를 미러하면서 근본적인 문제가 있는지 검사하고 조사하면서 공개할 수 있을 정도의 수준으로 만들기 위해 노력했다. 어느 정도 만족할 만한 상태가 되고, 평소에 주로 미러하던 사이트를 새 프로그램으로 대신하면서 문제가 없음을 확인한 후, 썬사이트(http://sunsite.unc.edu)에 올리면서 인터넷에 발표했다. 필자가 전세계의 모든 사이트를 검색할 수 없어 관심 있는 사이트만 조사 했으므로 문제가 많았지만 일단 공개한 것이다.   곧 수많은 전자메일이 날아오기 시작했다. 다양한 유닉스 플랫폼에서 컴파일을 성공했다는 내용이 왔고 일부 사용자는 자신의 플랫폼에서 컴파일하기 위해 고친 패치를 보내왔다, 전자메일을 보낸 모든 사람의 명단을 공헌자 목록을 만들어 넣고 그에 따라 패치를 적용했다. 결국 리눅스에서 시시작한 프로그램이 순식간에 열 개가 넘는 플랫폼에서 컴파일 해 사용할 수 있게 되었다. 곧바로 새 버전을 다시 발표했다. 또 다시 많은 전자메일이 날아들었다.   개인 홈페이지를 가진 사용자는 호기심에서 자신의 홈페이지를 미러해 보기를 즐겼는데, 그 과정에서 미러가 안되거나 에러가 발생한다는 내용도 많았다. 어떤 사용자는 플랫폼의 특성 때문에 생긴 문제를 고친 패치를 보내오기도 했다. 그러나 대부분의 전자메일은 필자처럼 제대로 미러하는 프로그램을 구하거나 만들려고 했던 사용자의 감사 편지였다. 독일, 호주, 미국 등 전 세계에서 고맙다는 편지를 받는 것은 매우 행복한 일이었다.   다양한 사용자의 의견은 언제나 문제를 쉽게 해결하는데 도움을 주었다. 때로는 누더기 같은 코드에 대해 직접 코딩 한 필자도 헷갈리는데 이를 이해하고 개선된 코드를 보내주는 사용자를 보면서 신기해 하기도 했다. 외국의 한 사용자와는 실시간으로 전자우편을 주고 받으면서 버그를 알려주고 해결한 프로그램을 전자메일로 보내 테스트하고 다시 그 결과를 받아 코딩하기도 했다.   사용자가 늘수록 테스트한 웹사이트가 증가하고 그에 따라 생각하지도 못했던 문제가 나타났다. 그 와중에서 한 사용자는 필자가 무시하고 지나쳤던 HTTP규약을 일깨워 주었다. 자신의 홈페이지에 사용한 URL 참조 표현을 프로그램이 인식하지 못한다는 것이었다. 필자는 그것이 잘못된 표현이라고 지적했지만 그 사람은 http규약 전체를 보내주면서 자신의 표현이 규약에 따라 문제가 없다고 주장했다. 필자는 규약을 다시 보면서 잘못 코딩 했음을 깨닫고 그에게 고친 프로그램을 보내 주었다.   날마다 사용자의 새로운 제안이 쌓여갔다. 모두 수용하지 못할 정도의 내용이 전자메일로 쌓이면서 고민하기 시작했다. 필요에 의해 사용하던 프로그램의 기능을 추가하면서 누더기가 되었을 때 새로운 프로그램을 만들기 시작했지만, 사용자 의견을 참고해 고치기 시작하자 getwww도 같은 모습을 띄었기 때문이다. 즉 점차 원하는 만큼 효율적이지 못하고 코드가 누더기가 된 것이었다.   소스 코드를 보면 볼수록 일부는 완전히 새로 만들어야겠다는 생각이 들었다. 이미지맵을 처리하지 못했고 자바 애플릿도 가져오지 못했다. 그리고 일반적이 되어버린 CGI에 대한 처리가 근본적으로 불가능하다는 것을 깨닫고 있었다. 게다가 HTTP규약이 발전했으니 그에 따라 프로그램을 버전업할 필요가 있었다. 이 모든 것은 진행형이었다. 프로그램 코딩이 어려운 일이 아니었고 문제를 해결하는 일이 즐겁지 않은 것도 아니었다. 그러나 현재 필자는 getwww를 혼자 버전업 해 사용할 뿐 공개하지 않고 있다. 아직도 가끔 외국에서 편지가 오고 있지만 버전업 한 프로그램을 발표할 마음은 없다.   왜 이렇게 되었는가? '성당과 시장'과 별 차이 없이 시장 모델을 따랐음에도 이렇게 실패한 이유를 생각해 보기로 하자.       필자의 실패 이유       필자는 프로그램 개발하기 시작하면서 인터넷에 공개할 것을 염두에 두었다. 스스로 초기 베타 테스트를 거친 후 어느 정도 신뢰할 만 했을 때 공개했다. 즉 리눅스 개발 과정을 익히 알고 있던 필자는 자연스럽게 오픈 소스 개발 모델을 알게 모르게 따른 것이다. 그 과정은 에릭 레이먼드의 fetchmail 개발이나 필자의 getwww개발이나 별로 다른 점이 없다. 마찬가지로 인터넷에 공개된 오픈 소스 프로젝트는 '프로그램 발표→사용자의 디버깅→개선판 발표→재 디버깅' 과정을 거치는 형태로 개발이 진행되고 있다. 이런 과정의 전제 조건으로 에릭 레이먼드는 리더의 자질과 초기 코드의 상태를 들었다.   에릭 레이먼드에 따르면 한 프로젝트가 성공하려면 사용자가 테스트할 초기 코드가 필요하지만, 이 프로그램이 꼭 버그가 없고 완성되어야 할 필요는 없다고 한다. 중요한 것은 프로젝트가 제대로 진행된다면 그 결과물이 사용자를 만족시킬 수 있는 확실을 심어주는 것이라고 주장한다. 여기에는 재론의 여지가 없다. 리눅스의 초기 버전은 실행되지도 않았는데도 많은 사용자와 개발자가 관심을 가졌다. 오픈 소스 프로젝트의 초기 버전은 대부분 0.0.1 버전부터 시작하며, 그렇다고 해서 아무 것도 할 수 없는 상태는 아니다. 대개 버전이 낮아도 기본 기능은 충실하다.   성당 모델의 프로그램은 1.0 버전에서 곧바로 2.0 버전으로 건너 뛰고 발표와 동시에 버그가 발견되어 2.1 버전이 나온다, 그래서 1,0 버전과 버전 끝자리가 0인 상업용 소프트웨어는 구입을 미뤄야 한다는 말까지 있다. 대조적으로 오픈 소스 개발 모델은 버전 숫자에 크게 연연하지 않고 개발한 지 수년이 넘었음에도 불구하고 아직도 0.x버전을 고수하는 것이 대부분이다. 물론, 소프트웨어의 지향점은 높지만 결코 포기하지 않고 한발씩 앞으로 나가고 있는 것이다. 사용자도, 준 개발자도 이를 믿고 그의 시간을 할애하고 있다.   에릭 레이먼드가 말한 리더의 자질은 결코 프로그램 실력을 의미하는 것이 아니다. 프로젝트 리더는 뛰어난 프로그래밍 능력과 사용자를 능가하는 설계 능력을 갖고 있어야 한다는 믿음은 잘못되었다고 말한다. 오픈 소스 개발 모델의 리더는 조정자의 역할을 충실히 하고 다른 사람의 좋은 설계를 알아볼 수 있는 능력만 가지면 족하다고 보는 것이다. 물론 프로그래밍 능력이 전혀 필요 없는 것은 아니나 자신의 능력을 과신해 사용자를 끌고 가려는 태도보다는 사용자 의견을 인정할 수 있는 자세가 더 중요하다고 본다.   그러나 보다 중요한 것은 사람과 의사 소통을 잘해나가는 능력이라고 말한다. 사용자의 자발적 참여를 이끌어내려면 의사 소통에 문제가 없어야 하며, 그렇게 되어야 사용자는 리더를 도와주고 싶은 마음이 생기고 자신의 시간을 투자하는 것이다. 리더는 자신의 시간을 투자한 사용자에게 흥미거리를 안겨주고 그의 기분을 좋게 만드는 능력이 있어야 프로젝트를 끌고 갈 수 있다는 이야기이다.         리눅스 커널 해커 가이드의 감사 글   리눅스 커널 해커 가이드의 미러 원칙은 로컬에서 글을 읽더라도 질문이나 답변은 본래의 커널 해커 가이드로 배달되는 것이었다. 필자의 getwww가 이런 기능을 갖고 있었기 때문에 미러 방법을 알려 주었다. 리눅스 커널 해커 가이드 제작에 참여하고 관리도 담당하는 마이클 존슨(Michael K. Johnson)이 getwww를 사용해 과련 사이트를 미러한 파일을 ftp 사이트에 올려놓았다며 필자에게 감사의 글을 올려놓았다. 리눅스의 핵심인 커널에 관한 정보를 제공하는 사이트에서 자신에게 감사한다는 글을 받는 것은 해커로서 공인 받는 일이다. 개발자에게 이 보다 더 큰 찬사는 없을 것이다.     필자가 프로그램을 발표했을 때 많은 전자메일이 왔다. 기능 개선에 대한 조언이나 패치를 보내준 사용자는 공헌자 명단에 넣고 소스 코드 패치 부분에서는 주석으로 그 사람의 이름과 전자메일 주소를 넣었다. 이렇게 하면 도움 준 사용자가 프로그램 개선에 더욱 흥미를 갖게 된다는 것을 알고 있었기 때문이다. 이에 덧붙여 감사 편지를 보낸 사람에게는 간단한 답장을 만들어 보냈다. 그의 편지가 나를 기분 좋게 만든 이상으로 그도 기분이 좋아야 할 권리가 있었기 때문이다.   에릭 레이먼드의 글은 오픈 소스 개발 모델의 개발 과정에 대한 설명으로 훌륭한 교과서이다. 그가 파악한 성공적인 시장 모델에 대한 이해는 누구나 공감하는 것이다. 필자도 그의 글을 읽으면서 정확하게 설명하는 글이라고 느꼈고, 그가 설명한 대로 진행했었다. 그런데 필자는 왜 지금 getwww를 버전업하고도 발표하지 않고 있는가? 그에 대한 필자의 생각을 말해보자.     연결 고리를 이어주지 못하는 언어의 장벽       인터넷에 프로그램을 공개한다는 것은 전세계를 상대로 내놓는 것과 마찬가지다. 여기에는 필수적으로 언어 문제가 따른다. 즉, 영어가 필요한 것이다. 교육을 제대로 받아왔다면 영어를 읽고 이해하는 것은 전혀 문제되지 않으며 프로그래밍을 했다면 더욱 영어는 기본이다.   문제는 영어를 사용해 자신의 뜻을 표현하는 것이다. 가장 기초적인 영어 표현조차 맞는지 확실할 수 없는 상태에서 외국 사용자가 보내온 편지에 답장하는 것은 고통스럽고 힘든 일이다, 이런 상태에서 외국의 준 개발자와 기술적 토론을 벌이는 것은 불가능하다.   전자메일은 전 세계에서 날아오는데 이를 이끌어갈 리더가 정확한 발언과 의사 표명을 할 수 없다면 누가 계속 도와줄 생각을 하겠는가? 할 수 있는 것은 감사하다는 편지에 대해 간단한 답장 정도를 쓸 수 있을 뿐이다. 더구나 영어로 표현하는 훈련이 부족한 필자는 'It have large problem.' 처럼 한 문장에 구문상 틀린 표현을 몇 개씩 만들어 내고는 했다.   실시간으로 표현할 때는 틀린 부분이 전혀 보이지 않는다. 나중에 차분히 되새겨 봐야만 자신의 실수를 발견할 수 있으며 그런 실수가 연결 고리를 끊을 수도 있다. 미국인은 인간이라면 누구나 영어를 사용할 수 있어야 한다고 생각하는 경향이 강해, 리더가 잘못된 영어를 사용했을 때 외국인으로 보기보다는 저능아를 대하고 있다고 생각하기 쉽다.   필자는 매우 긴 사용 설명서를 만들었다. 물론 한글로 쓴 것이었다. 그렇다 보니 외국인은 프로그램의 다양한 옵션을 사용할 수 없었다. 필자는 프로그램 설명서와 같은 긴 문서를 영작할 능력도 자신도 없었기 때문에 그대로 공개해 버렸다. 사용자는 계속 영어로 된 사용 설명서를 요구했지만 게으름과 능력 부족으로 영작을 차일피일 미루고 말았다. 때문에 많은 사용자는 옵션 없이 프로그램을 사용해 보고 별 유용성을 느끼지 못하고 멀어져 갔다. 뉴스그룹에 개선판을 발표할 때도 새로운 내용을 채우지 못하고 기존 내용을 그대로 사용했다. 물론 기존 내용도 비슷한 프로그램의 설명을 가져다 바꾼 것이었다. 때문에 사용자는 개선판의 바뀌 내용을 알 수 없었으므로 더 많은 사람이 멀어졌다.         잘못 쓴 영어     리눅스 커널 해커 가이드(Linux Kernel Hackers' Guide, http://www.redhat.com:8080/HyperNews/get/khg.html) 에는 사용자 의견을 수렴하는 부분이 있다. 리눅스 커널 해커 가이드를 웹으로 배포하기로 결정한 후 가장 먼저 등록된 의견이 미러해서 로컬에서도 읽을 수 있었으면 하는 것이었다. 필자가 만든 프로그램이 그 일을 할 수 있었기에 가능하다는 글을 올렸다. 확인해보면 알겠지만 '나는 영어를 잘 하지 못한다'는 문장으로 시작하고 곳곳에 잘못된 표현을 사용했다. 필자의 글에 따라 getwww를 사용해보고 올린 글이 몇 개 있었지만 그 글을 보고도 영어 표현의 어려움 때문에 더 이상 의견을 적지 못했다. 개발자로서 말하고 싶어도 말하지 못하는 어려움 때문에 오픈 소스 개발 모델의 개발 과정에서 가장 중요한 사용자와의 교류는 벽에 부딪힌 것이다.       사용자와의 교류가 원활이 되지 않은 상태에서는 한 발자국도 나갈 수 없었다. 좋은 제안을 보낸 사용자와 의견이 달라 'I don't think so…'로 시작하는 전자메일을 보냈는데, 그 글이 사용자 마음을 상하게 하지 않고 의사를 전달했는지 여부를 확인하지 못해 더 이상의 토론이 이뤄지지 못하기도 했다. 분명히 그 사용자는 개발자가 자신의 의견을 무시한다고 느꼈을 것이다. 언어가 갖는 뉘앙스에 대한 분별력이 없었으므로 기분 좋은 대화가 되지 못했다. 글이란 표현에 있어 쓴 사람의 감정이 얽혀 있어 다른 면도 보여야 하는데, 문법에 틀리고 부적절한 단어를 사용해 보는 사람의 감정을 상하게 되었을 때 이미 리더로서의 자격은 상실하게 된다.   전세계를 연결하는 인터넷을 이용해 오픈 소스 개발 모델의 개발을 진행하려면 영어를 자유롭게 구사할 수 있는 것이 필수적이다. 한국의 리눅스 사용자는 여전히 한글 문서만 찾고 있지만 한글 문서만 보고 있는 동안에는 결코 개발자 반열에 오를 수 없다. 어떤 프로그램을 개발해 오픈 소스 공동체에 기여하고 싶어도 사용자와의 교류가 단절되면 오로지 개발자 능력만으로 진행해야 한다. 리눅스를 사용하며 일정 부분 기여하고 싶은 사용자가 있다면 반드시 영어 능력, 특히 말하고 쓰는 능력을 키우는 노력을 기울이기 바란다. 필자도 영어의 필요성을 느껴 최근에 많은 노력을 기울여 영어 공부를 하고 있다. 영어는 수단이며 도구이기 때문에 가능한 영어를 능숙하게 사용할 수 있도록 자신을 계발할 필요가 있다.         뒷짐진 개발자, 해커정신이 아쉽다.           그렇다면 국내 사용자와 공동으로 개발하면 되지 않겠느냐고 질문을 할 수 있을 것이다. 한글로 대화한다면 자유롭게 자신의 의견을 낼 수 있고 상호 이해에 전혀 문제가 없을 것이기 때문이다. 그러나 국내 사용자와 공동 개발하는 문제에는 한국만의 특수성이 있다. 오픈 소스 개발 모델에 따라본 개발자가 느끼는 절박한 문제가 있는 것이다.   우선 한국에는 대학 졸업 후에 전문적인 리눅스 개발자라는 직업을 갖고 있는 사람이 거의 없다. 실력 있는 개발자는 리눅스를 중요하게 생각하지 않고 이에 시간을 낭비하려 하지 않는다. 대학에서 리눅스를 사용하던 사람도 졸업 후 취직하고 나면 자연스럽게 리눅스와 멀어지는 것이다. 또한 주류 운영체제인 윈도우 계열이나 상업용 유닉스를 기반으로 일하고 있는 개발자도 오픈 소스 소프트웨어에 기여하는 경우는 거의 없다.   이것은 프로그래밍 실력으로 이름을 날리는 해커 문화가 전혀 없는 한국적 상황 때문이다. 개발자의 명성을 인정해주고 여기서 삶의 또 다른 성취감을 느낄 수 있는 다양함이 없기 때문이다. 프로그래밍 실력은 취업과 직업을 위한 것일 뿐 취미로써, 자신의 능력을 개발자 사이에서 인정받기 위한 것으로써는 관심이 없다. 때문에 오늘도 한국의 오픈 소스 소프트웨어는 학생만이 공개하고 있는 것이다. 물론, 제작자가 졸업함과 동시에 버전업은 중단되거나 또 다른 학생이 이어받고 있을 뿐이다.   필자는 리눅스의 가능성을 믿고 회사에서 리눅스 기반 프로젝트를 진행하자고 강력히 주장했지만 다른 사람을 설득하는 것은 어려운 일이었다. 이미 상업용 운영체제와 그 위에 실행되는 비주얼 툴에 익숙하고 오픈 소스라는 말에 대해 조금도 신뢰하지 못하는 분위기가 지배적이었기 때문이다. 동료 개발자는 필자를 쓸데없는 것에 관심을 기울이는 사람으로 치부해 버렸다.   취업하는 순간 해커로서의 열정은 사라지고 지배적인 개발 툴과 운영체제에 편안히 안주해 버리는 것이다. 그런 개발자에게 오픈 소스의 이념을 설명해 주고 시간을 쪼개 참여하면 개발자로서의 명성을 날릴 수 있으며 이것이 진정한 개발자의 자기 성취라는 것을 설득하는 일도 불가능했다. 전문적인 영역을 확보하고 있는 실력 있는 개발자의 참여 없이는 앞으로도 외국에서 인정하는 한국의 오픈 소스 개발, 특히 리눅스 분야는 요원한 일이다. 시장 모델이 가정하는 사용자 수준은 개발자에 조언하고 개발에 참여할 수 있는 정도로 보고 있다. 외국 사용자와 단절되면 국내의 실력 있는 개발자 참여가 필수적인 상황이지만 아무도 참여하지 않았기 때문에 당연히 개발은 중단될 수밖에 없었다.   리눅스의 'free' 개념은 수년 동안 가격 문제로 오해되어 일반인과 대부분의 사용자, 개발자는 '공짜' 라는 뜻으로 생각하고 있다. 그 결과 완성도는 떨어지고 쓸모 없는 프로그램의 집합으로 치부한다. 리처드 스톨만이 GNU 선언문에서 아무리 free는 가격 문제만이 아니라고 외쳐도 사용자는 전혀 알아듣지 못하고 있다. 결국 최근에 free라는 용어를 버리고 open이라는 단어를 사용하게 되었다. 여기에 덧붙여 프로그래밍의 자유라는 개념을 확실히 하기 위해 오픈 소스(open source)라고 사용하고 있다.   사실 국내 컴퓨터 사용자는 대부분 불법 소프트웨어를 사용하고 있다. 프로그램을 돈 주고 산다는 행위가 부자연스러운 사용자는 윈도우를 사용할 때 대부분의 프로그램을 공짜로 사용해 왔다. 돈을 주고 산다면 수백 만원이 넘을 소프트웨어를 한 푼도 투자하지 않고 사용하는 것이다. 상업용 소프트웨어는 기능과 완성도에 비례해 가격도 비싸기 마련이다. 하지만 비용을 들인 적이 없어 프로그램에 대한 기대 수준이 엄청나게 높아져 있다. 이들에게는 리눅스의 오픈 소스 소프트웨어와 상업용 소프트웨어의 차이가 없다. 즉, 모두 공짜이므로 오픈 소스 소프트웨어에서도 수백 만 원짜리 상업용 소프트웨어가 제공하는 편리성과 뛰어난 성능을 요구하고 있다.   이들은 오픈 소스 개발 모델의 소프트웨어가 사용자와 개발자의 상호 협조 속에서 개선이 이뤄진다는 것을 이해하지 못하고 있다. 때문에 필자에게 온 국내 사용자의 전자메일은 '이런 것이 안됩니다'. '다음 버전에는 이런 것을 넣어 주세요', '왜 이런 기능이 없습니까?' 등 주로 질책하는 것들이었다. 모든 것을 개발자가 알아서 해주기만 바라는 것이다. 필자는 자유시간을 쪼개 개발하고 있어 다른 개발자의 참여와 도움이 절실했지만 이런 도움은 전혀 받지 못하고 기능의 미비점만 지적하는 메일만을 받았을 뿐이다. 당연히 개발 의욕은 떨어지고 더 이상의 버전업은 진행될 수 없었던 것이다.           한국 개발자들의 비참한 현실     꾀돌이 마우스 기능까지 제공되는 황치덕씨의 통신 프로그램인 '가우'가 인기를 끌고 있다. 자연스럽게 한글을 사용할 수 있고 국내 통신망에 대한 배려가 많기에 당연히 국내에서만 애용되는 프로그램이다. 그런데 이 프로그램을 도와준 사람은 류창우씨 한 명으로 기록되어 있다. 개별적인 도움 외에 개발에 함께 참여한 사용자는 한 명도 없다. 그야말로 황치덕씨 혼자서 고군 분투하고 있을 뿐이다. 설명 파일에 적혀 있는 '도와달라'는 글을 보며 서글픈 생각이 들뿐이다.   MP3 플레이어인 정우재씨의 'splay'가 있다. 뛰어난 성능을 자랑하는 프로그램으로, 개발자는 열성적으로 개발했지만 사용자가 전혀 도움을 주지 않았다. 게다가 일부 사용자는 외국 프로그램이 더 좋다는 등 흠집을 내기도 했다. Splay 소스 코드에 있는 NEWS 파일을 읽어보면 도움을 준 개발자는 두 명의 외국인 뿐이다. 국내 전문 개발자는 조금도 그를 도와주지 않고 있다. splay는 완성된 프로그램이지만 화면 인터페이스가 부족해 사용자의 외면을 받는 것이다.   국내 개발자는 엔진 제작부터 인터페이스 디자인까지 모두 혼자 해내야 한다. 사용자는 화면 인터페이스가 보다 좋은 외국 프로그램을 찾아 다니고 있으며 일부 사용자는 외국 프로그램에 한글 패치를 하고 있다. 참으로 비극적인 상황이 아닐 수 없다. 아아 비참한 한국의 개발자여…….          한글화에 대한 지나친 열광       그렇다면 한국의 리눅스 개발자는 무엇을 하는 것일까? 한국 개발자의 수준은 아시아에서도 상당히 높게 평가 받고 있으며 대학가에서는 열풍과 같이 리눅스가 확산되고 있는데 이들이 관심을 갖는 것은 무엇일까? 누구나 알고 있듯이 모든 에너지는 한글화에 집중되고 있다. 그야말로 다른 것에 신경 쓸 여력이 없을 정도로 모두 한글 패치, 문서 한글화, 한글 프로그램 개발에 신경 쓰고 있다.   한글화를 해야만 인정받고 개발자로서 한마디 할 수 있는 것이 현실이다. 예전에 빌 게이츠가 한국에서 태어났다면 무엇을 했을까라는 질문을 어떤 개발자에게 한 적이 있다. 그가 말하기를 '한글 카드를 만들어 팔고 있을 것이다'라고 했다. 오늘도 한국의 개발자는 버전업 된 프로그램의 한글 패치에 매달리고 있다. 그러나 이것도 표준을 지키지 않고 한국에서만 통용되는 방법으로 해결하고 있다. X 윈도우의 한글화 프로그램인 한엑스는 전혀 국제화, 지역화와 맞지 않는 방법으로 한글화했고 여기에 사용된 함수를 분리해 일부 윈도우 매니저를 한글화하는데 사용하고 있다. 지역화 표준에 맞는 방법을 구현해야 할 전문 개발자는 손을 놓았고 아마추어 개발자는 어쨌든 한글이 나오면 된다고 생각하며 대책 없는 패치를 가하고 기뻐하는 것이다.   X 윈도우와 그 응용 프로그램에 대한 한글 패치를 보고 있으면 자신의 능력을 믿지 못하고 실력을 낭비하고 있는 가련한 리눅서가 보일 분이다. 필자도 한엑스와 Emacs 한글화 버전업에 참여한 적이 있지만 그것이 당장 필요했기 때문이다. 한국의 리눅서에게 다시 한 번 말하지만 프로그램 한글화에 모든 에너지를 낭비하지 말기 바란다. 프로그램 개발자로 참여해 그 프로그램 자체가 국제화 되도록 만드는 것이 더욱 빠른 길이다.   프로그램의 한글 패치가 문제되는 것은 노력을 들인 보답을 받지 못하고 결국 사라지게 된다는 것이다. Emacs를 한글화한 하니멕은 Emacs에 다국어 입력기가 내장되면서 사장되었다. 버전업된 Emacs의 한글 입력 부분은 한국이 아닌 일본에서 만들어졌다. 우리가 Emacs를 자체적으로 고쳐 하니멕을 사용하면서 만족하고 있는 동안 일본인은 여러 언어의 입력기를 만들고 Emacs 개발자와 협조하면서 개발 방향에 영향을 줄 수 있는 자격을 갖게 된 것이다.   한글 패치를 하고 있는 한국의 리눅스 개발자의 노력은 인정받아야 하지만 표준을 지키지 않은 한글화는 성공하기 힘들다. 그러므로 표준을 보다 자세히 살펴보고 외국 개발자도 인정할 수 있는 방법을 사용하는 것이 좋을 것이다. 또한 가능하다면 한글화보다는 사용자에게 도움을 줄 수 있는 프로그램을 만들거나 개발자를 기다리고 있는 오픈 소스 프로젝트에 관심을 기울여주기 바란다. 한국의 리눅스 개발자가 발표한 프로젝트에 능동적으로 참여하는 것도 좋을 것이다.         리눅스 한글화, 한 숨 돌려도 된다.     리눅스 한글화는 여러 개발자의 노력으로 상당한 진척을 보이고 있다. Emacs, vi등 대중적인 프로그램에 대한 한글 패치는 많이 이뤄져 응용 프로그램에서 한글을 쓰는 문제는 거의 해결되었다. 여기에 일부 매뉴얼 페이지도 번역되어 한글 터미널에서 한글 설명서를 볼 수 있다. 리눅스를 사용하면서 설정을 할 때 필요한 HOWTO문서도 중요한 것은 번역되어 있어 한글 배포본에 포함되고 있다. 커널 수준의 패치도 이뤄져 윈도우의 유니코드 파일명을 제대로 볼 수 있고 리눅스 파일 시스템에 한글 이름으로 파일을 만들어 사용하는데 문제가 없다. 또한 TeX의 한글화가 발전해 한글 TeX을 사용해 문서를 만들고 출력도 할 수 있다.   은광회씨의 노력으로 쓸만한 한글 글꼴도 많이 만들어지고 포스트스크립트 한글 글꼴도 어렵지 않게 사용할 수 있게 되었다. 한글 문서의 출력을 위해 고스트스크립트를 이용한 출력 프로그램도 적지 않으며 한글 출력도 문제가 없다. 또한 최근에는 트루타입의 한글 글꼴도 이용할 수 있다.   X윈도우의 한글화로는 X 라이브러리를 고친 한엑스가 있다. 그 외에도 인기 있는 윈도우 매니저는 거의 한글 입출력에 문제가 없도록 패치 되어 있다. X 윈도우 응용 프로그램의 입력을 위해 상업용 입력기뿐만 아니라 공개된 입력기도 몇 개가 나와 있다. 여태까지 넷스케이프에서 한글을 제대로 입출력 하려는 노력이 이었지만 완전하지 못했다. 그러나 넷스케이프가 오픈 소스 형태로 전환했으므로 앞으로는 완전히 손볼 수도 있다. 리눅스용 오피스 패키지인 스타오피스도 내년에 한글화하겠다고 할 정도로 상업용 소프트웨어의 한글 지원도 적극적이다. 남은 것은 리눅스 설치 과정의 한글화 정도만 남았을 뿐이다. 그러므로 한글화에 대한 관심에서 벗어나 다른 분야에 관심을 가질 때가 아닐까?          사용자의 작은 관심과 성의만이라도……       필자가 getwww를 공개하고 외국 사용자로부터 받은 편지는 대부분은 잘 쓰고 있으며 고맙다는 것이었다. 그러나 국내 사용자로부터는 그런 전자메일을 전혀 받아보지 못했다. 한 사용자가 설명한 기능 중에 안 되는 것이 있다고 하기에 정확한 사용법을 알려줬지만, 그 결과로 잘 되는 지 아니면 여전히 문제가 있는지 답장을 받지 못했다. 전자메일로 답장을 보내는데 익숙하지 않은 탓도 있지만 자신의 생각을 정확히 표현하는 훈련이 부족한 탓도 있을 것이다.   어쨌든 이런 무관심이 개발 의욕을 꺾는 경우가 적지 않다. 한엑스를 버전업하고 뉴스그룹의 한글 그룹에 올린 적이 있었다. 곧바로 자신의 컴퓨터에서 실행되지 않는다는 글이 올라왔다. 개발자로서 이 문제가 일반적인 상황인지 아니면 글을 올린 사용자에게 한정된 문제인지 알 필요가 있어 가능하면 실행 여부를 알려달라는 글을 올렸다. 하지만 자신의 상태를 알려주는 사용자는 한 명도 없었다. 개발자로서 대단히 실망스러웠고 더 이상 소스 코드를 만질 의욕도 나지 않았다. 게다가 문제를 알려오는 사용자의 글은 예의가 없다고 느낄 정도로 항의와 질책만 담긴 심한 글이 많았다. 사용자와 개발자의 상호 격려와 칭찬으로 발전한다는 오픈 소스 개발 모델은 그래서 또 한번 한국적인 특수성으로 꺾이는 순간이었다.   최근에 TV에서 안철수씨의 이야기를 시청하면서 인상 깊었던 부분이 있다. 안철수씨가 백신을 개발한 후 전국에서 온 편지에 대해 일일이 답장해주고 새벽 2시에 바이러스 치료법을 알려달라는 전화가 왔을 때 짜증내지 않고 방법을 알려주었다는 것. 안철수씨가 정말 존경스러웠다. 그런 바탕 때문에 안철수씨의 오늘이 있게 된 것이다.   문제는 한국에서 오픈 소스 개발 모델을 진행하기 위해서는 성인과 같은 미덕을 갖춰야 하는 것이다. 사용자의 모든 무례를 받아들이고 이를 극복하는 정신력을 갖고 있어야 개발자 자격을 얻을 수 있다. 그렇기 때문에 대부분의 프로젝트가 발표된 후 계속 존재하지 못하고 흐지부지 끝나는 경향이 있다.         꾸준하고 일관된 개발이 필요한데….     리눅스 터미널에서 한글 입출력을 해주는 프로그램은 han은 일본인이 만든 kon에서 출발한 것이다. 노남석씨가 han을 발표한 후 더 이상의 개발은 진행하지 못했고 그 후 오성규, 김세희, 김병찬씨가 개별적으로 패치해왔다. 이와 별도로 일본인이 kon을 FreeBSD로 포팅한 것을 yujeny@pandora.snu.ac.kr과 최준호씨가 고치고 이를 다시 리눅스로 포팅한 han2가 나왔다. 참여한 사람의 특징은 전문 개발자가 아니라 학생 신분이었다는 것으로, 참여한 사람 중에서도 전문 개발자로 취업한 경우에는 더 이상 추가 개발에 참여하지 않았다. 이렇게 중심 개발자가 사라지면서 프로젝트는 개별적, 독립적이 되어 중복된 개발이 많아지게 된다.   한국에서 가장 성공적인 오픈 소스 개발 모델이라고 할 수 있는 것이 바로 한텀이다. 여전히 개발 중이고 로그 파일을 보면 그동안 한글 관련 프로그램에 관련해 이름있는 개발자는 최소한 한 번씩 한텀 개발에 관심을 가졌음을 알 수 있다. 김대식씨가 패치를 꾸준히 통합하고 있으며 다양한 플랫폼에 포팅되어 있어 한글이 지원되지 않는 운영체제에서는 최우선으로 한텀부터 컴파일해 사용할 정도로 표준적인 프로그램이 되었다. 그러나 리눅스를 사용자의 요구가 한텀 개발 속도보다 빨라서인지 리눅스만을 위한 한텀이 등장했다. 리눅스 사용자가 원하는 기능을 추가하기 위해 한텀에서 필요한 기능을 분리해 다시 Xterm 기반으로 개발이 진행되는 것이다. 원래의 한텀과 리눅스용 한텀은 같은 목적과 작업을 하는 프로그램이다. 이런 일은 노력이 중복될 뿐 아니라 사용자를 혼란시키는 일이다. 개발자가 서로를 존중하고 기존 성과에 자신의 개발력을 통합시키는 자세가 아쉬울 뿐이다.          큰물로 나서는 대담성 부족       한국의 리눅스 개발자는 작은 프로그램을 개발하는 정도로 만족하는 듯하다. 오픈 소스의 방향을 바꿀만한 대규모 프로젝트나 새로운 표준을 만드는 등의 작업을 시작하거나 참여할 생각이 없는 것 같다. Gnome 프로젝트나 egcs 개발처럼 큰 그림을 그릴 수 있는 주제를 생각하지도 참여하지도 못하고 있다. 그야 말로 외국의 진행 사항에만 관심 가질 뿐, 주도적으로 제안을 내는 일이 별로 없다.   리눅스를 개발한 리누스가 핀란드 대학생이었다는 것을 생각하면 우리가 대규모 프로젝트를 이끌어 내지 못할 이유가 없다. 대규모 프로젝트를 구상하고 초기 개발에 정성을 들인다면 그 다음 일은 저절로 굴러가게 된다. 문제를 발견하고 그 해결책으로 제시할 대규모 프로젝트를 구상하고 이것을 실현하는 데 관심을 갖기 바란다.   이와 같은 한국적 상황에 신경 쓰거나 자신의 실력을 평가절하하지 않았으면 한다. 이런 구속 없이 생각한다면 대단해 보이는 외국 개발자가 우리와 다르지 않은 평범한 개발자라는 사실을 알게 될 것이다. 대담하게 자신의 의견을 내고 필요한 부분을 성실하게 개발한다면 외국 사용자의 인정을 받을 수 있게 될 것이다.       올바른 한글 전도를 위한 영문 홈페이지     신정식씨는 프로그래밍에 필요한 한글 관련 정보를 홈페이지(http://panthecn.cis.yale.edu/~jshin/fag/)에 올려 놓았다. 단지 정보를 게재하는 수준을 넘어 외국 개발자가 개발할 때 한국어 지원을 고려하도록 전자우편으로 의견을 제시하는 노력도 하고 있다. 또한 외국 개발자가 한글에 대한 정보를 쉽게 알 수 있게 하기 위해 한글 관련 내용임에도 모두 영어로 씌어져 있다. 일부 한국 사용자가 이를 불평하기도 했다. 그러나 한글에 대해 전혀 모르는 외국 개발자가 한글로 된 정보를 어떻게 이용하는가? 그의 전략은 올바른 것이다. 한글 지원을 확대하기 위해 오히려 영어를 잘해야 한다는 것을 역설적으로 보여주는 사이트다.          변화무쌍한 전자메일 주소       필자의 전자메일 주소는 여러 번 바뀌었다. 하다못해 회사의 IP 주소나 도메인 주소가 변경된 경우도 있었다. 개인적으로 사용하던 co-lan은 속도 때문에 해지했고 그 후에도 인터넷 서비스 업체로 여러 번 바꾸는 동안 고정된 전자메일 주소를 갖지 못한 것이다.   한국의 네트웍은 성장 과정에 있고 변화가 심해 많은 사용자도 필자와 같은 경험을 했을 것이다. 특히 리눅스로 개인 서버를 운용하는 사람은 이를 이용해 전자메일 주소 받고 개인 홈페이지를 운용하고 싶어하기 때문에 인터넷 서비스 업체를 변경하면 전자메일 주소도 바꿔야 한다. 인터넷에서 전자메일 주소는 한 인간을 대표하는 것이므로, 가능하면 바꾸지 않는 것이 좋다. 주소가 바뀌면 프로그램에 대한 전자메일이 배달되지 못하고 메일링 리스트의 글을 받아보지 못하므로 한 프로젝트의 개발자라면 영구적인 개인 주소가 필수적이다.   최근에 사용자를 확보하기 위해 국내 신문사 등에서 영구 전자메일 주소를 나눠주고 있으니 잘 선택해 변경할 필요가 없는 전자메일 주소를 갖는 것이 좋다. 에릭 레이먼드의 글에 있는 것처럼 '당신이 더 이상 개발할 흥미를 잃고 있을 때 그 프로그램에 대한 권리를 넘겨 받기 위해 능력 있는 후임자가 언젠가는 당신에게 편지를 보낼 것이기 때문이다'.       새로 도전할 개발자를 위해       '성당과 시장'을 읽고 과거의 흥미롭던 시간과 기억이 떠올라 이 글을 썼다. 시장 모델의 개발자가 얻을 수 있는 것은 전세계 사용자가 프로그램에 대한 찬사를 보내고 개발자를 기억해주는 것이다. 네덜란드의 이름 모를 지방에서 보낸 감사 편지를 읽을 때 느끼는 감동은 다른 방법으로는 얻을 수 없을 것이다. 이런 자아만족이 시장 모델의 성공을 이끌고 있다.   한국의 리눅스 사용자는 개발자에게 보다 애정을 가질 필요가 있다. 그의 작품을 격려하고 능력이 된다면 기능 개선에 준 개발자로 참여하는 성의를 보일 때 지속적으로 성장하는 오픈 소스 개발 모델의 부산물이 늘어날 것이다. 이와 함께 사용자의 관심이 절실히 필요하다. 왜냐하면 사용자의 적극적인 참여만이 리눅스의 미래를 밝게 만들 수 있기 때문이다. 새로운 개발자가 되고 싶은 사용자는 먼저 프로그래밍에 대한 공부를 게을리 하지 말아야 한다. 앞에서 뭐라고 말했든 리눅스 개발자가 가져야 하는 최선의 능력은 프로그래밍 능력이다. 그에 더해 세계와 상대하기 위해 인터넷 공용어인 영어에 대한 능력도 충분히 길러야 한다. 사용자의 마음을 이해하고 자신의 주장을 확실히 펼치기 위해서는 영어에 숙달할 필요가 있다. 그리고 한글 문제는 가능하다면 잠시 밀어두기 바란다. 한글 문제에 무관심하라는 것은 아니지만 개발자 그룹에 가담하는 것이 오히려 한글 문제를 확실히 해결할 수 있는 지름길이 되기 때문이다.   이런 한국적 상황에 너무 매몰되지 말고 세계적인 이슈에 과감히 뛰어들어 자신의 목소리를 내는 세계인으로 자리매김 하기 바란다. 필자는 정말로 오픈 소스 그룹을 이끌어 가는 한국인 개발자가 나타나기를 간절히 바라고 있다.