윤석찬님의 글 ‘오픈 소스 개발자 그들을 주목하라’을 읽고 의견을 달아봅니다.

오픈 소스(Open Source)가 중요하다는 말이 많이 들린다. 구글과 IBM 같은 굴지의 대기업이 오픈 소스를 지원해서 어떤 반사 이익을 얻는지에 관한 분석도 쉽게 찾아 볼 수 있다. 하지만 정작 우리 주변의 개발자들과 이야기를 나눠보면 오픈 소스가 아직까지 바다 건너 다른 동네의 이야기란 생각이 든다. 오픈 소스 세상에서 우리나라 개발자들은 여전히 닫힌 세상에 살고 있는 것이다.

사실 그렇게 비관적인 것만은 아니다. 우리나라 개발자들은 실은 오픈 소스에 무척 익숙하며 많은 혜택을 누리고 있다. 우리나라에서 소프트웨어 개발은 대가가 중소 규모의 벤처 업체를 중심으로 이루어진다. MS나 썬, IBM처럼 신제품 개발에 필요한 컴포넌트나 라이브러리를 업체가 소유하고 있는 경우는 드물다. 필요한 코드는 전부 외부에서도 조달해야 하고, 규모가 영세한 벤처 기업이 코드를 조달할 수 있는 곳은 결국 오픈 소스이다.

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

그런데 왜 기여는 안하는 것일까? 가져다 쓸 것은 많지만 딱히 기여할 만한 것들은 없어서일까? 근데 개발 활동이라는 게 그럴 수가 없다. 개발은 필연적으로 부산물을 만들기 마련이다. S/W 컴포넌트는 전자 부품처럼 해당 규격의 부품만 끼운다고 곧바로 동작하지 않는다. 간단한 라이브러리 하나를 가져오더라도 현재 제품에 맞춰 수정해야 하며 이 과정에서 불충분한 기능 하나 두쯤은 직접 개발하게 된다. 필요한 기능을 추가할 수 있다는 게 오픈 소스의 가장 큰 매력이니깐 말이다. 또 오픈 소스가 널리 사용되는 만큼 어느 정도 안정성이 검증되어 있다지만, 이를 가져와서 사용하다보면 필연적으로 부족한 기능이나 버그를 발견하기 마련이다.

적극적으로 프로젝트를 개발하고 운영하진 못할지라도, 이렇게 오픈 소스를 활용하는 과정에서 생긴 부산물만 적극적으로 다시 오픈 소스 프로젝트에 환원한다면 우리나라도 오픈 소스에서는 손꼽힐만한 나라도 부상할 수도 있다.

근데 현실은 왜 이럴까? 첫 번째 이유로 개발업체가 오픈 소스 프로젝트 활용하고 있다는 사실을 숨기기 때문이다. 공개를 떳떳하게 하지 못하는 이유로 보통은 라이선스(license) 문제를 든다. 상당수의 오픈 소스가 코드를 공개하라는 요구를 하는 GPL로 작성되어 있기 때문이다. 아파치(Apache)나 BSD 라이선스처럼 비교적 자유로운 이용을 허용하는 경우도 있지만, 아직까지 코드 공개가 회사 자산 전부의 유출이라고 해도 과언이 아닌 중소 벤처가 이를 수용할 수 있을 리가 없다.

라이선스 문제만이 아니다. 우리나라에서 오픈 소스의 이용을 공표하는 것은 실상은 그 업체가 자체적인 기술력이 없음을 보여주는 커밍아웃에 가깝기 때문이다. 우리나라에는 원천 기술이 없다는 이야기를 많이 하는데 실상이 그렇다. 상당수의 상용 제품들이 실상은 오픈 소스 프로젝트를 가져다가 외양을 바꾸고 예쁘게 치장해서는 마치 새로운 제품인 것처럼 팔기 때문이다.

초창기 난립했던 보안 업체들이 만든 상당수의 방화벽(firewall)이나 침임탐지시스템(intrusion detection system), 암호 시스템 등이 대부분 OpenSSL 같은 오픈 소스 프로젝트를 가져와 시작했다는 이야기가 있다. 개발자가 한 회사 제품의 소스만 이해하면, 다른 회사로 옮겨도 업무를 파악하는데 별로 시간이 걸리지 않는다는 이야기가 있었을 정도다.

또 하나의 문제는 의사소통의 장애일 것이다. 의사소통이라는 게 개발자들의 영어 실력만을 문제시하는 것은 아니다. 언어가 첫 번째 장벽이라면, 두 번째 장벽은 의사소통 그 자체에 있다. 오픈 소스를 가져다가 자기 입맛에 맞게 고치는 일은 혼자서 해치울 수 있지만, 패치를 제출하고 버그를 보고하는 일은 다른 개발자들과 소통을 필요로 한다. 코드에 기능을 추가하거나 수정을 가했으면, 어떤 이유에서 그러한 수정을 했는지 명확히 전달할 수 있어야 한다. 하지만 다른 오픈 소스 개발자들과 적극적으로 의사소통을 하고, 내 의견을 전달하는 것이 생각보다 힘든 과정이다.

우리나라 오픈소스 개발의 현황을 살펴보면 이런 점이 두드러진다. 대부분의 개발자가 다른 개발자와의 의사소통을 힘들어한다. 어렵게 시작한 국내 오픈 소스 프로젝트도 다른 개발자의 도움을 받는 일이란 극히 드물다. 개발자들은 의사소통이 어려워서 기존의 프로젝트에 참여하기보다는 자신만의 새로운 프로젝트를 만드는 쪽을 선호한다. 그래서 오픈 소스 프로젝트는 대부분 아이디어 선에서 정체되어 있는 경우가 많으며, 이름만 다른 유사 프로젝트가 전부 초기 단계에서 벗어나지 못하는 웃지 못 할 상황이 벌어지고 있다.

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

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

또한 오픈 소스 프로젝트는 자신이 스스로 결정하기 힘든 회사 프로젝트와는 별개로 자신의 경력을 쌓을 수 있는 곳이다. 사실 혼자 공부하고, 학교에서 배우는 것만으로는 실제 개발에 필요한 실용적인 지식을 습득하기 어렵다. 오픈 소스는 큰 규모의 소프트웨어를 어떻게 개발해야 하는지를 배울 수 있는 이상적인 장소이다. 이렇게 쌓은 경력은 자신의 커리어를 만들어 나가는데 중요한 역할을 한다. 구글이 채용한 파이썬 프로젝트의 반 로섬, 파이어 폭스 개발자인 벤 구저, Gaim 개발자인 션 이건 등 유명한 오픈 소스 개발자들도 다들 자기만의 작은 프로젝트로 시작한 것이다.

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

우리도 당장 자기 업무에 사용하는 오픈 소스에 작은 패치라도 하나 제출해 봄이 어떨까?