예전에 썼던 달콤하고도 쓴 과일: 오픈 소스을 조금 다듬어 봤습니다.

모두들 오픈 소스(Open Source)가 중요하다고 말한다. 소프트웨어 대기업이 오픈 소스를 후원하는 것도 일반적인 일이 되었다. 일례로, 구글이나 IBM 같은 기업이 오픈 소스를 지원해서 어떤 이익을 얻는지에 관한 분석도 쉽게 찾아 볼 수 있다. 하지만 정작 개발자로 하루 하루를 사는 우리 주변을 돌아보면 오픈 소스는 아직까지 딴 세상의 이야기란 생각이 드는 것도 사실이다. 세상은 오픈 소스로 넘쳐나지만, 한국의 개발자들은 여전히 닫힌 세상에서 살고 있다.

하지만 따지고 보면 우리 나라는 오픈 소스 운동의 최대 수혜자이다. 현재 한국의 실정을 보면, 소프트웨어 개발은 대게 중소 규모의 개발업체를 중심으로 이루어진다. 대기업에서 발주를 하더라도 실제 소프트웨어 제작은 외주가 되는 경우가 많으므로, 거의 모든 소프트웨어는 규모가 크지 않은 개발업체가 담당하고 있다고 생각할 수 있다. 이런 한국 중소 개발업체들이 마이크로소프트나 썬, IBM처럼 신제품 개발에 필요한 컴포넌트나 라이브러리를 모두 소유하고 있는 경우는 드물다. 제품 개발에 필요한 코드는 전부 외부에서도 조달해야 하고, 국내 기업이 이런 코드를 저가에 조달할 수 있는 곳은 결국 오픈 소스이다.

간단한 예를 들어 현재 개발하는 제품이 이미지 디코딩(image decoding) 기능이 필요로 하면 어떻게 하는 게 좋을까? JPEG, GIF, PNG 등의 이미지 포맷의 명세서를 보고 처음부터 다시 이미지 디코더(image decoder)를 만들 것인가? 디코더 개발이 경쟁력이 되는 이미지 관련 제품을 만드는 업체가 아닌 이상, 오픈 소스 프로젝트를 찾아볼 것이다. 각각의 포맷에 대해 이미 많은 사람들이 사용해 검증된 libjpeg, libungif, libpng 같은 오픈 소스 프로젝트가 있음을 알 수 있다. 노련한 개발자라면 오픈 소스를 적극 활용할 것이다.

즉 사용하는 면에서만 보면 한국은 이미 오픈 소스 강국이라 불러도 이상할 게 없다. 반대로 오픈 소스에 기여하는 면에서는 그 성적이 형편없다. 왜 오픈 소스에 참여하지는 않는 것일까? 가져다 쓸 것은 많지만 프로젝트로 환원할만한 것들은 없어서일까?

하지만 개발 활동의 특성을 보면 그럴 수가 없다. 소프트웨어 개발은 필연적으로 부산물을 만들기 마련이다. 소프트웨어 컴포넌트는 전자 부품처럼 해당 규격의 부품만 끼운다고 곧바로 동작하지 않는다. 간단한 라이브러리 하나를 가져오더라도 현재 제품에 맞추어 수정을 거쳐야 하고, 이 과정에서 불충분한 기능 하나 두쯤은 직접 개발해서 추가하게 된다. 또 오픈 소스가 안정성이 검증되어 있다지만, 사용하다 보면 버그를 발견하는 경우도 흔하다. 따라서 적극적으로 프로젝트에 참여하지는 못할지라도, 회사에서 오픈 소스를 활용하며 생긴 부산물만 적극적으로 오픈 소스 프로젝트에 환원한다면 한국도 오픈 소스에 가장 많은 기여를 하는 나라도 될지도 모른다.

그런데 현실은 왜 이럴까? 첫 번째 이유로 개발업체가 오픈 소스를 활용하고 있다는 사실을 숨기기 때문이다. 오픈 소스를 사용한다고 떳떳하게 공개하지 못하는 이유로 보통은 라이선스(license) 문제를 든다. 상당수의 오픈 소스가 코드를 공개해야 하는 GPL(General Public License)로 작성되어 있기 때문이다. BSD 라이선스처럼 GPL과 달리 비교적 자유로운 이용을 허용하는 경우도 있지만, GPL의 주류인 오픈 소스 세상에서 소스 코드 공개는 코드가 회사 자산의 전부인 중소 규모의 개벌업체의 선택 사항은 아니다.

단순한 라이선스 문제만은 아니다. 한국에서 오픈 소스의 이용을 공표하는 것은 실상 그 업체가 자체적인 기술력이 없음을 보여주는 커밍아웃에 가깝다. 한국에는 원천 기술이 없다는 이야기를 많이 하는데, 소프트웨어 업체의 실상도 크게 다르지 않다. 중소 업체들이 시장에 내 놓은 상당수의 제품들은 오픈 소스 프로젝트를 가져다가 외양을 바꾸고 치장한 것에 지나지 않기 때문이다.

2000년 초부터 난립했던 국내 보안 업체들이 만든 상당수의 방화벽(firewall)과 침임 탐지시스템(intrusion detection system), PKI 관련 암호 시스템 등이 대부분 OpenSSL 등 여러 오픈 소스 프로젝트를 가져와 시작했다는 이야기를 들은 적이 있다. 그 당시에는, 보안 관련 개발자가 회사를 관두고 같은 제품을 만드는 경쟁사로 옮겨도 같은 소스 코드를 보게 된다는 일화가 우스개 소리만은 아니었다.

오픈 소스 활성화에 걸림돌이 되는 또 하나의 문제는 의사소통의 장애일 것이다. 의사소통은 단순히 개발자들의 영어 실력만을 말하는 게 아니다. 영어가 작은 장벽이라면, 더 큰 장벽은 의사소통 그 자체다. 오픈 소스를 가져와 필요에 따라 고치는 일은 혼자서도 해치울 수 있지만, 프로젝트에 패치를 제출하고 버그를 알리는 일은 다른 개발자들과 의사소통을 필요로 한다. 예를 들어, 코드에 기능을 추가하거나 수정을 가했으면, 어떤 이유에서 그러한 수정을 했는지 명확히 전달할 수 있어야 하는데, 이 과정에서 다른 개발자들을 납득시키는 것은 상당한 끈기와 노력을 요한다.

우리나라 오픈 소스 현황을 살펴보면 이런 점이 두드러진다. 많은 개발자가 의사소통을 힘들어한다. 어렵게 시작한 국내 오픈 소스 프로젝트도 다른 개발자의 도움을 받는 일은 극히 드물다. 개발자들은 기존의 프로젝트에 참여하기보다는 자신만의 새로운 프로젝트를 만드는 쪽을 선호한다. 기존의 프로젝트에 자신의 생각을 설득력 있게 관철시키는데 어려움을 느끼게 때문에, 자기만의 새로운 프로젝트를 시작하는 것이다. 덕택에 이름만 다른 유사 프로젝트가 만들어지게 되거나, 포기해 버리고 만다.

요약하면 국내에서 오픈 소스 하기란 어렵다. 많은 사람들이 오픈 소스를 이야기하지만, 기대만큼 오픈 소스를 후원함으로써 직접적인 이익을 얻을 수 있는지도 의문이다. IBM 정도의 거물 소프트웨어 회사라면 뭔가 비전을 가지고 오픈 소스를 전략적으로 활용할 수 있겠지만, 당장 한 명의 개발 인력이 아쉬운 중소 규모의 국내 개발업체들이 거창하게 오픈 소스를 후원한다는 것도 실상은 우스운 면이 많이 있다.

하지만 개발자 개인의 입장에서 보면 오픈 소스는 여전히 매력적 장소이다. 회사 일과 별개로 자신이 만들고 싶은, 자신이 필요로 하는 제품을 만들 수 있는 즐거움은 개발자들의 특권이다. 개발자가 대접받지 못하는 한국 IT 현실에서 전세계의 개발자들과 소통하며 실력을 인정받는 일은 아무나 누릴 수 없는 기쁨이기도 하다.

또한 오픈 소스 프로젝트는 자신이 스스로 결정하기 힘든 회사 프로젝트와는 별개로 자신만의 경력을 쌓을 수 있는 곳이다. 오픈 소스는 큰 규모의 소프트웨어를 어떻게 개발해야 하는지를 배울 수 있는 이상적인 장소이다. 이렇게 쌓은 경력은 자신의 커리어를 만들어 나가는데 중요한 역할을 한다. 구글이 채용한 파이썬의 아버지의 Guido van Rossm, 파이어 폭스(Firefox) 개발자인 Ben Goodger, 가임(Gaim) 개발자인 Sean Egan 등 유명한 오픈 소스 개발자들도 다들 자기만의 작은 프로젝트로 시작한 것이다.

미국 대학에서는 소프트웨어 산업계로 나아갈 학부 졸업생들을 위해 실용적인 프로그래밍 과목을 개설하는데, 여기서 빠지지 않는 것이 오픈 소스 프로젝트에 기여하는 것이다. 메릴랜드 대학의 경우 ‘CMSC433 프로그램 언어 패러다임과 기술’의 프로젝트 중에 하나가 오픈 소스 프로젝트를 하나 선정하고, 여기에 버그 패치와 기능 추가 등의 구체적인 활동을 해서 보고서를 제출하는 일이다. 이런 과정을 통해 학생들은 자연스럽게 오픈 소스 개발 과정을 몸에 익히고 업계에 진출해서도 오픈 소스를 적극 활용한다.

시작은 보잘것없지만 그 끝은 장대한 법이다. 우리도 당장 자기 업무에 사용하는 오픈 소스에 작은 패치라도 하나 제출해 봄이 어떨까?