작년 겨울 우리 나라에서 처음으로 주요 오픈 소스 프로젝트에서 활동하고 있는 국내 소스 커미터(Source Committer) 모임이 열린 적이 있다. 우리 나라에서 아파치, 모질라, 오픈 오피스를 비롯하여 FreeBSD, 데비안, 파이썬, 서브버전(SVN) 등 10여 개의 다양한 프로젝트에 참여하고 있었던 사람들로 25명 정도 중에 10여명 정도가 참석하였다. 그 자리에는 해외에서 온 모질라와 우분투 프로젝트 개발자까지 참석해서 각자가 속한 프로젝트의 개발 방법론에 대한 이야기를 나눌 수 있어서 뜻 깊고 의미 있는 자리가 되었다.

우리 나라 대다수 IT 업체와 S/W 개발사들은 오픈 소스를 채용하고 있고, S/W 개발자라면 적어도 하나 이상의 오픈 소스를 한번이라도 사용해 봤을 것이다. 그렇지만 오픈 소스에 대한 기여도는 그리 크지 않다. 회사 내 공통 모듈이나 라이브러리 같은 경우 오픈 소스 개발 방법론을 채용하고자 하지만 성공하기가 쉽지 않다. 정부의 오픈 소스 지원 정책이 강화되면서 관심은 높아 졌지만 막상 무엇을 어떻게 해야 할지 난감 하기까지 하다. 이 글에서 오픈 소스 사용자가 아닌 개발자를 바라봄으로써 오픈 소스와 S/W 산업에 동시에 기여하는 방법을 생각해 보고자 한다.

오픈 소스는 닫혀 있다?
우선 앞서 말한 소스 커미터가 무엇인지 알아보자. 모두가 알다시피 오픈 소스는 소스 코드(Source Code)가 공개되어 있다. 이 소스 코드를 고칠 수 있는 권한을 가진 사람들을 소스 커미터라고 한다. 오픈 소스는 누구나 그 코드를 고칠 수 있다고 생각하지만 그렇지 않다. 극히 제한된 몇 명의 사람만이 소스 코드에 접근할 수 있다.

그럼 소스 커미터가 되려면 어떻게 해야 할까? 그 모임에서 각자 소스 커미터가 된 경험을 나누는 시간이 있었다. 모든 오픈 소스 프로젝트에는 문제를 처리하고 품질을 향상 하기 위한 고유한 버그 리포팅 시스템(Bug Reporting System)을 가지고 있다. 개발된 프로그램을 사용하는 많은 사람들은 사용 중 문제점을 버그로 보고 한다. 이 사람들은 프로그램 어디를 고쳐야 하는 지 알지 못하기 때문에 버그만을 제출 한다. 버그를 제출 하다 보면 소스 코드를 보고 공부하게 되고 어디를 고치면 될지 알게 된다. 이 때 자신이 소스 코드를 고쳐 테스트 해 본 후, 수정 해야 하는 부분을 기존 소스와 비교한 패치(Patch)를 제출하게 된다.

패치가 제출 되면 기존 소스 커미터나 패치가 포함된 부분을 담당하는 모듈 소유자가 패치를 검토해 보고 고쳐야 하겠다고 판단 되면 실제 소스 코드에 반영 하게 된다. 너무 빈번히 패치를 제공해 다른 사람에 의해 체크인(Checkin)을 하는 게 귀찮을 정도가 되면 혼자서도 할 수 있다고 판단에 따라 소스 커미터로 추천을 받게 된다. 그 자리에 온 대다수가 수 년간 버그 리포트를 하면서 도합 300여 개가 넘는 패치를 제공하고 서야 소스 커미터가 될 수 있었다고 한다.

게다가 어떤 프로젝트는 커미터 간에 멘토와 멘티가 있는 가 하면 프로젝트의 철학을 묻는 필답 시험을 치르는 곳도 있다고 한다. 또 어떤 프로젝트는 커미터가 됐다 하더라도 더 상위의 커미터에게 때에 따라 두 번의 리뷰를 거쳐야 하는 경우도 있다고 한다. 그들은 커미터 지위를 얻기 위해 수년간 자신의 과외 시간을 오픈 소스 프로젝트에 쏟아야만 했다(물론 그 일에 대한 재미와 자부심이 그렇게 만든 것은 자명한 일이지만.). 이처럼 오픈 소스 프로젝트는 일견 모든 사람에게 열려 있는 듯 보이지만, 내부 시스템은 지극히 제한이 많은 폐쇄 시스템이다. 오픈 소스를 한다는 건 그 만큼 어려운 일이다.

오픈 소스 개발자의 딜레마
유명 오픈 소스 프로젝트의 오너가 되거나 이들 프로젝트 소스 커미터가 된 사람들이 이 일을 전업으로 가지려고 하면 매우 큰 모험을 감수 해야 한다. 당시 그 모임에서 단 한 명 만이 공식적으로 업무 시간에 오픈 소스 프로젝트를 참여 할 수 있었다. 그는 사내 제품에 탑재된 오픈 소스 프로그램을 개발하면서 품질을 높이는 일과 더불어 오픈 소스 개발을 해온 경험을 바탕으로 사내 개발자를 교육 시킨다고 한다. 뿐만 아니라 사내 개발 프로젝트에도 오픈 소스에서 사용되는 방법론을 채용해서 프로젝트를 진행하고 있기도 하였다.

해외에서는 이미 많은 유력 IT 기업들이 오픈 소스 개발자 채용에 경쟁적으로 나섰다. 대표적으로 구글(Google)은 파이썬 프로젝트를 만든 귀도 반 로섬, 파이어 폭스 개발자인 벤 구저, Gaim 개발자인 씨안 어간 등 많은 유력 개발자들을 채용 했다. 뿐만 아니라 썬 마이크로시스템즈, IBM, 오라클 등 유명 IT 기업들은 이미 과거에도 오픈 소스 개발만을 전담 하는 사람을 수십~수백 명씩 데리고 있다. 2003년 AOL이 넷스케이프 개발자 대부분을 해고 하면서 일부는 모질라 재단에 흡수 됐지만 대부분은 이들 회사로 옮겼다. 이들이 오픈 소스 개발자를 데리고 있는 이유는 자사 제품과 서비스의 기술적 품질을 높이기 위한 것이지 일종의 사회 기부적인 성격의 공헌을 하기 위한 것이 아니다. 만약 어떤 회사가 오픈 소스에서 받은 혜택을 환원하기 위한 수단으로 오픈 소스 개발자를 채용하거나 지원하는 것은 매우 잘못된 접근 방법이다.

오픈 소스 커미터가 된 사람 정도면 개발에 대한 일가견이 있다고 볼 수 있다. 많은 사람들과 토론을 통해 다져진 커뮤니케이션 능력과 개발에 대한 상황 판단 및 문제 해결 능력이 매우 뛰어나다. 또한, 외국 사람들과 개발을 진행하니 언어 구사 능력과 글로벌 마인드 또한 갖추고 있다. 최근 기술 동향에도 관심이 많다. 오픈 소스 개발자들을 별종 인간처럼 생각하는 사람들이 많지만 필자가 만나 본 국내외 대부분 오픈 소스 개발자들은 모두 똑똑하고 유망한 기업에 몸담고 있는 사람들이었다. 이들은 내심 오픈 소스 프로젝트를 전업으로 하기를 원하지만 회사는 그 능력을 다른 곳에 써주기를 원한다. 그들은 이런 이유로 음지에 있다.

기업에서 오픈 소스 개발자의 역할
아마 오픈 소스 개발을 전업으로 하게 해 준다는 업체가 있다면 많은 오픈 소스 개발자들이 연봉이 조금 낮아도 직장을 옮길 마음의 준비가 되어 있을 것이다. 물론 실제로 그런 업체는 거의 없다. 앞서 예를 든 업체와 개발자의 경우도 매우 특수한 경우이다. 오픈 소스 활동을 과외로 하는 것 때문에 불이익을 받을까 봐 쉬쉬하는 경우도 있다고 한다. 그러다 보니 소리 소문 없이 활동을 하게 될 수 밖에 없고 그러다 보니 오픈 소스 개발자가 지속적으로 양성되기 어려운 상태가 된다.

적어도 오픈 소스를 비즈니스에 사용하는 기업에서는 이들을 전향적으로 대할 필요가 있다. 이들에게 전업으로 오픈 소스 개발에 참여하도록 하는 것이 결코 기업에 해가 되는 것이 아니기 때문이다. 구글에 재직 중인 파이어폭스 개발자인 벤 구저의 경우, 80%를 오픈 소스 개발에 참여하고 나머지 20%를 이와 관련된 사내 프로젝트를 돕고 있다. 자사가 사용하고 있는 오픈 소스가 있다면 그 개발자를 채용하여 품질을 높이는 활동이 곧 기업의 경쟁력에 관련된 문제이기 때문이다.

소규모에서 중견 IT 기업으로 발돋움한 대부분 회사가 겪는 많은 문제점 중에 하나가 개발자들의 비전과 경력 로드맵을 제시하지 못하는 것이다. 관리자, PM, 아키텍터와 더불어 오픈 소스 개발자는 사실상 최고의 역할 모델(Role Model)이다. 이 역할 모델은 국내 오픈 소스 개발자들을 실제적으로 늘리는 계기가 될 수 있다. 앞서 예를 든 업체의 경우 한 명에서 시작되어 몇 명의 오픈 소스 커미터를 양성해 데리고 있었다. 비즈니스에서 마이크로소프트 공인 자격증 소지자가 몇 명인가가 중요한 척도가 되듯이 오픈 소스 개발자를 데리고 있는 것이 회사의 자랑이 되어야 한다는 것이다.

또한, 오픈 소스 개발자들은 나름의 개발 방법론을 잘 터득하고 있다. 대부분의 기업들이 사내 공통 모듈이나 라이브러리를 관리하는 데 있어 애로점을 느끼고 있다. 여러 부서에서 재사용할 수 있는 프로그램의 경우 누가 어떻게 유지 보수 해야 하는 지 쉽지 않다. 이럴 때 오픈 소스 개발 방법론을 생각하지만 프로젝트 기반 포지(Forge) 시스템만 갖춘다고 오픈 소스처럼 굴러 가지 않는다. 오픈 소스 개발이 어떻게 진행 되는지 아는 사람들이 다양한 사내 엔지니어들에게 버그를 내고 패치를 하는 방법을 전파하고 새 버전에 포함될 기능과 일정을 정하여야 한다. 소스 코드가 관리하는 트리(Trunk)에서 적절히 분기(Branching)하고 제품의 사이클을 관리하는 중요한 역할을 해야 하기 때문이다. 이러한 일에 적절한 리소스가 부여 되면 회사에 큰 도움이 된다.

우리 나라에서도 오픈 소스 개발자들이 음지가 아닌 양지에 나와 떳떳이 활동 할 수 있는 분위기가 조성되기를 바란다. 오픈 소스 개발을 전업으로 하는 사람을 채용 하는 공고를 볼 수 있었으면 한다. 오픈 소스에 패치를 몇 개나 했는지를 개발자에 평가하는 척도로 삼는 것이 자연스러운 회사가 하나라도 생기길 소망한다. 과한 욕심인 것 같지만 이것이 우리 나라 S/W 산업과 한국 S/W 회사가 생존 할 수 있는 방법이 아닐까?@