시작하기 전에

본 글은 지극히 주관적인 관점, 즉 유명 오픈 소스의 메인테이너(관리자)가 아닌 순수히 취미 혹은 자기 계발을 위해 '오픈 소스'라는 도구를 활용해 그 문화에 입문하려는 이의 관점에서 쓰여진 글입니다.

오픈 소스란 무엇일까? 필자는 지금까지 오픈 소스라는 단어를 심심치 않게 들을 수 있었다. 하지만, 이 단어가 가진 의미를 정확하게 알기란 쉽지 않았다.

그래서 필자는 오픈 소스를 처음 접했을 때 주변의 누군가로부터 오픈 소스는 무료로 사용할 수 있는 코드라고, 또 다른 누군가로부터 돈이 안 되는 자선사업 혹은 그러한 서비스라는 이야기를 들었다. 한편으로는 취업을 준비하는 주변 친구들은 오픈 소스는 취업에 도움이 된다는 식의 뜬구름 잡는 이야기를 하기도 했다.

그래서 필자는 이 글을 통해 스스로 오픈 소스와 오픈 소스 생태계란 무엇인지를 고민해보고자 했다.

places-with-the-most-contributors.jpg

이 그림은 DashBouquet[1]에서 가져온 전 세계 컨트리뷰터 현황에 대한 자료이다. 이 자료만 보더라도 아시아 지역에서는 중국과 일본이 단연 앞서고 있다.

물론 이 자료는 2017년 10월 1 일부터 2018년 9월 30일까지의 GitHub 트랜드 통계를 바탕으로 작성되었고, 국내 개발자의 수가 타국에 비해 현저히 적다는 점, 국내에서는 잘못된 인식으로 오픈 소스에 대한 편견이 지배적이기 때문에 완전히 객관적이라고는 할 수 없다. 하지만, 단편적으로나마 국내의 오픈 소스 프로젝트 생태계의 현 위치를 짐작할 수 있을 것이다.

필자는 이처럼 상대적으로 관심이 적은 국내의 오픈 소스 생태계를 개선하기 위해선 기본적으로 본질을 이해해야 접근할 수 있을 거라고 생각했다. 우선, 그 생태계를 이해하기에 앞서 왜 나는 오픈 소스라는 키워드를 가지고 이를 활용하려 할까? 왜 주변 사람들은 오픈 소스가 중요하다고 이야기하는 걸까?

오픈 소스란 무엇일까?

과거의 오픈 소스는 서론에서 말한 것과 같이 다양한 범주와 의견으로 정의할 수 있었다. 하지만, 현시점의 오픈 소스는 한 개인이 쉽게 정의할 것이 아니라고 생각한다. 그 이유는 필자가 나열하는 것보다 본 글을 읽다 보면 자연스럽게 느낄 수 있을 것이기 때문에 여기서 따로 언급하지는 않고, 일부 사례를 통해 이를 느껴보도록 하자.

먼저, 위키피디아에서는 오픈 소스를 다음과 같이 정의하고 있다[2].

Open source is a term denoting that a product includes permission to 
use its source code, design documents, or content.

...

한글로 해석하자면 "오픈 소스는 제품에 대한 소스 코드, 디자인 문서 또는 콘텐츠를 사용할 수 있는 권한이 있음을 나타낸다."라고 할 수 있다. 이를 통해 단편적이지만 '오픈 소스'라는 것은 어떠한 제품에 대한 지적 재산권을 나타낸다는 것을 알 수 있었다.

이를 통해 필자는 "그렇다면 오픈 소스 프로젝트 중에서 영리적인 사업을 하는 프로젝트들도 있나?"라거나 "소스 코드는 공개하지만, 오픈 소스의 수정은 거부하는 프로젝트들도 오픈 소스로서 존재할 수 있는 걸까?"라는 의문이 들었지만 위 정의만으로 그 의문을 해결하기란 어려웠다.

글을 작성하고 시간이 흘러 여러 피드백을 받아 수정하게 되면서 다음과 같은 힌트를 얻을 수 있었다.


Debian에서 말한 'Free'와 'Free Software'의 의미[2-1]를 살펴보면, 여기서의 'Free'는 우리가 일상적으로 사용하는 의미 중 하나인 '무료(at no cost)'가 아닌 '자유(freedom)'를 나타낸다고 말한다.

어쩌면 두 의미를 같다고 볼 수도 있지만, 필자가 느끼기에는 '오픈 소스'라는 단어가 가지는 'Open'의 의미가 '프리웨어(공공제)' 혹은 '셰어웨어'의 그것과는 전혀 다른 것이라고 느꼈다.

이어 읽어나가다 보면 오픈 소스는 '라이선스'라는 것을 가지며, 이를 통해 오픈 소스는 지적 재산권이 있는 원작자의 요구에 맞게 사용되어야 한다는 구문이 서술되어 있다.

이 점을 통해 "오픈 소스를 한다"라는 의미는 마냥 비용이 없는(at no cost) 소프트웨어를 만드는 의미가 아닌 "원작자 즉, 개발자의 의도가 자유로이 반영되어 운영되는 프로젝트를 진행한다"라는 의미가 아닐까 하는 생각도 들었다.

또한, 글에서는 오픈 소스 제작자들이 체택하는 일반적인 라이선스 조합에 대해 소개하고 있다.

  • Not allowing use of their code in proprietary software. Since they are releasing their code for all to use, they don't want to see others steal it. In this case, use of the code is seen as a trust: you may use it, as long as you play by the same rules.

  • Protecting identity of authorship of the code. People take great pride in their work and do not want someone else to come along and remove their name from it or claim that they wrote it.

  • Distribution of source code. One of the problems with most proprietary software is that you can't fix bugs or customize it since the source code is not available. Also, the company may decide to stop supporting the hardware you use. Many free licenses force the distribution of the source code. This protects the user by allowing them to customize the software for their needs.

  • Forcing any work that includes part of their work (such works are called derived works in copyright discussions) to use the same license.

이를 한글로 해석해보면 다음과 같다.

  • 독점적인 소프트웨어에서의 코드 사용을 거부합니다. 그들은 모두가 사용할 수 있도록 코드를 제공하지 않기 때문에 다른 사람들이 이것을 훔치려는 것을 보고싶지 않습니다. 이 사례는 '코드의 사용'을 '신뢰'라고 봅니다: 이 경우 동일한 라이선스의 규칙을 적용하면 코드를 사용할 수 있습니다.

  • 코드 원작자의 신원을 보호합니다. 사람들은 그들의 일에 큰 자부심을 느끼고 있기에 원작자의 이름을 지우거나 자신이 쓴 것이라고 주장하지 말아야 합니다.

  • 소스 코드의 배포(를 강제합니다). 독점 소프트웨어의 문제 중 하나는 소스 코드를 사용할 수 없기 때문에 사용자가 직접 버그를 수정하거나 맞춤화(customize)하는 것이 불가능하다는 것입니다. 또한, 회사는 귀하가 사용하는 하드웨어의 지원을 중단할 수도 있습니다. 많은 자유(Free) 라이선스들이 소스 코드의 배포를 강제하고 있습니다. 이는 사용자가 자신의 필요에 맞게 소프트웨어를 맞춤화할 수 있도록하여 사용자를 보호합니다.

  • 저작물의 일부를 포함하는 저작물('Copyright Discussions'에서 파생 저작물이라고 정의함)이 동일한 라이선스를 사용하도록 강요합니다.

필자는 이 문장들을 읽고 많은 오픈 소스 프로젝트는 원작자의 라이선스에 명시된 의도를 훼손하지 않는다면, 그의 저작물 사용이 가능하다는 것을 말하고자 하는 것이라 생각했다.

더불어 글의 다음 단락에서는 많은 사람들이 자체 라이선스를 쓰게 되면 모호한 문구 혹은 미묘한 문제가 되는 문장의 사용이 법적 문제에서 원작자의 권한을 침해할 수 있는 것을 우려해 가장 널리 사용되는 라이선스에 대해서도 소개한다.

이 라이선스들은 다음과 같은 공통점을 지닌다.

  • You can install the software on as many machines as you want.
  • Any number of people may use the software at one time.
  • You can make as many copies of the software as you want and give them to whomever you want (free or open redistribution).
  • There are no restrictions on modifying the software (except for keeping certain notices intact).
  • There is no restriction on distributing, or even selling, the software.

마지막으로 OSI(Open Source Initiative)에서는 The Open Source Definition[2-2]에서 다음 10가지의 문장으로 Open Source를 정의한다는 것도 알아두도록 하자.

  1. 자유 배포(Free Redistribution)
  2. 소스코드 공개(Source Code Open)
  3. 2차적 저작물(의 허용)(Derived Works)
  4. 원작자의 소스코드 수정 제한(Integrity of The Author's Source Code)
  5. 개인이나 단체에 대한 차별 금지(No Discrimination Against Persons or Groups)
  6. 사용 분야에 대한 제한 금지(No Discrimination Against Fields of Endeavor)
  7. 라이선스의 배포 (Distribution of License)
  8. 라이선스 적용상의 동일성 유지 (License must not be specific to a product)
  9. 다른 라이선스의 포괄적 수용 (License must not contaminate other software)
  10. 라이선스의 기술적 중립성 (License must be Technology-Neutral)

이 Open Source Definition은 Debian Free Software Guidelines(DFSG)에서 유래되었다는 것을 알아두고 이를 참고하도록 하자.

글을 작성 및 수정하며 얻은 소감은 Debian에서 제공한 가이드라인과 OSI의 가이드라인은 약간 다를 뿐 거의 유사하다는 것이고, 근래에 들어서는 Free와 Open을 나누지않고 FOSS(Free & Open Source Software)라 칭한다는 것이다.

더불어 오픈 소스의 Open이 가지는 의미는 공짜가 아닌 소스 코드 및 SW의 자유로운 사용이라는 것을 알게 되었다.

추가적으로 필자는 OSI의 창립자 레이몬드가 칭한 '오픈 소스'라는 단어는 상업화(Commercialization)에 대한 반대급부라고 이해했다. 하지만 그럼에도 왜 Open Source Software라고 부르며 이를 '소프트웨어'라 제품화를 시키는 것일까? 코드는 그저 특정 문제를 해결하기 위한 명세로 이야기되는 것이 아닌가? 왜 이를 위한 제품이 '오픈 소스'로서 이야기될 수 있는 것일까?

이러한 고민을 하게 된 까닭은 오픈 소스 소프트웨어라 칭함으로 인해 오픈 소스는 그 자체로 자유로운 의미로서 상업화의 반대급부로 정의하지만, 이를 활용하는 비즈니스 모델의 존재에 대한 여지를 주기 때문이다. 비즈니스 모델이 있는 오픈 소스 서비스들은 오픈 소스 문화에 동참하지 않는 것일까? 이러한 고민의 답은 다음의 'RedHat'의 사례를 통해 힌트를 얻어보도록 하자.

오픈 소스를 활용한 서비스들

ap,550x550,16x12,1,transparent,t.png

위 그림[3]을 보면 우리가 흔히 접했던 프로젝트부터 난생처음 보는 프로젝트까지 다양하게 있는 것을 볼 수 있다.

위의 로고 중 필자가 아는 서비스에 한해 오픈 소스와 밀접한 관계가 있는 저작물을 소개해보려 한다.

가장 먼저 보이는 RedHat은 대표적으로 오픈 소스를 통해 비즈니스를 하는 회사이다. 그들이 제공하는 저작물은 리눅스 운영체제가 대표적이고, 오픈 소스이기 때문에 기본적으로 자유로이 사용하는 것이 가능하다.

그렇다면 그들은 어떤 비즈니스 모델을 가지고 있을까? 어떻게 돈을 벌고, 이를 유지하고 있을까? 이에 대한 답을 고민하던 중 Quora의 "What is Red Hat's business model?"라는 질문을 보게 되었는데, 이를 RedHat의 한 직원이 설명한 글[4]을 통해 조금이나마 해결할 수 있었다. 그 중 일부는 다음과 같다.

Red Hat doesn't sell software. You can download the software for free.

Red Hat sells service/support subscriptions.

...
Red Hat은 소프트웨어를 판매하지 않습니다. 무료로 소프트웨어를 다운로드 할 수 있습니다.

Red Hat은 서비스, 지원 구독(Support Subscription)을 판매합니다.

...

글에서는 RedHat은 소프트웨어를 '판매'하지 않고, 소프트웨어를 사용하는 데 필요한 서비스와 Support Subscription을 판매한다고 이야기한다(최근에는 고도화된 소프트웨어를 판매하기도 한다). 그래서 그는 자신들의 제품인 RHEL, Fedora 또는 CentOS를 다운로드하고, 수정하며 원하는대로 직접 컴파일하는 것을 자유로이 할 수 있다고 설명했다.

또한, 이와는 별개로 RedHat의 서비스가 제대로 작동되지 않을 때 RedHat의 지원을 받기 위해서는 Support Subscription 서비스에 대한 비용을 지불해야 한다는 식으로 이야기한다.

이런 비즈니스 모델을 가지고 있기 때문에 RedHat은 오픈 소스의 범주 안에서 경영을 할 수 있고, 오픈 소스를 활용한 사업의 선사례로 꼽히는 모양이다. 더불어 RedHat은 '오픈 소스 소프트웨어'를 운영하고 있기 때문에 이에 대한 서비스 개선을 계속해서 진행한다.

Quora의 글을 읽기 전까지 필자는 레드헷의 제품이 단순하게 무료와 유료 버전으로 나뉘어져 있고, 사용자에게는 각각 다른 가치를 얻는다고 생각했다. 하지만 RedHat이 가진 가치는 그것이 아닌 오픈 소스라는 이름에 걸맞는 것이었다고 느끼게 되어 감사하게 읽었다.

이를 통해 필자는 RedHat은 오픈 소스라는 매개 자체로 비즈니스 모델을 구축했다기 보다는 오픈 소스를 활용한 저작물을 통해 비즈니스 모델을 구축한 것이라고 이해할 수 있었다. 그렇다면 오픈 소스 소프트웨어는 오픈 소스를 활용한 소프트웨어라고 이해하는 것이 맞을까? 이렇게 이해한다면 품고 있던 수익성에 대한 의문은 말끔히 정리될테니 말이다.


다시 앞선 그림으로 돌아가 다른 사례를 고민하던 중 프로그래밍 언어 중 하나인 C/C++에 대해 궁금해졌다. 프로그래밍 언어도 오픈 소스와 관련이 있을까? 보통 컴파일 언어를 사용하기 위해서는 컴파일러라는 소프트웨어가 필수적으로 필요한데, 이때 사용하는 컴파일러들은 지금껏 의식없이 사용했었으니 말이다.

이와 더불어 프로그래밍 언어에서 사용하는 각종 라이브러리 혹은 패키지같이 언어를 둘러싼 모든 환경에서 오픈 소스가 사용될 수 있을 것이다. 우리가 흔히 사용하는 컴파일러 중에는 오픈 소스인 것들도 다양할 것이고, 세상에는 다양한 언어와 이를 둘러싼 환경이 있을 것이기 때문이다.

러프하게 알 수 있는 오픈 소스 컴파일러 목록은 이 곳[5]에서 찾을 수 있다.

추가적으로 프로그래밍 언어 같은 경우는 보편적으로 사용자에게 공공제로 제공되지만, 언어의 표준과 같이 특정 규율을 정하는 것은 별도의 기구(ISO[5-1])에서 관리하기도 한다.

즉, C/C++과 같은 프로그래밍 언어 또한 오픈 소스와 밀접하며, 이를 위한 오픈 소스 컴파일러는 당연히 소스 코드를 공개하고 이를 수정할 수 있다[6].


이쯤에서 다음과 같은 의문이 들 수 있다.

그렇다면 오픈 소스가 아닌 건 무엇일까? 

여기까지 쓰고 난 본인의 견해로는 이에 대한 답을 내리기 위해서는 오픈 소스가 아닌 것을 나열하기보다 오픈 소스인 것을 고민해야 한다고 느꼈다. 그렇기 때문에 만약 오픈 소스에 대해 보다 깊은 이해를 원하는 독자는 다음의 자료를 참고하길 바란다.

글을 수정하며 얻은 다양한 조언을 통해서 이제는 '오픈 소스'라는 단어가 각 개인의 의견으로 정의될 수 없다고 생각이 굳어졌다(그 정의에 대한 서적은 이미 차고 넘치기 때문이다).

물론 그 정의에 대한 각 개인의 이해와 파생된 견해가 다를 수 있겠지만 결과적으로 과거부터 이야기되어 현재에 이르러서는 논쟁의 여지가 수그러든 것이기 때문에 앞선 것과 같이 '오픈 소스는 이미 정의되어 있다'라고 생각을 굳힐 수 있었다.

여기까지 글을 적으며 필자는 오픈 소스에 대해 어렴풋이 이해할 수 있게 되었다고 생각한다. 그럼에도 아직 오픈 소스를 둘러싸고 있는 그 환경에 대해서는 익숙하지 않다.

주변에서는 국내 오픈 소스 생태계에 불만을 품은 이들도 상당하다. 그들은 왜 그런 불만을 가지고 있을까? 그래서 이번에는 오픈 소스 생태계란 무엇인지를 살펴보도록 하자.

오픈 소스 생태계란 무엇일까?

2016-2017-trends-open-source-ecosystem.jpg

이 그림[7]은 단일 오픈 소스 생태계를 가시적으로 보여준다고 느껴서 가져왔다.

이 그림은 단일 오픈 소스를 활용한 솔루션을 제공하는 VENDORS, 단일 오픈 소스를 지원하는 EXPERTS단일 오픈 소스에 대한 조언, 기여 등을 제공하는 COMMUNITY, 마지막으로 단일 오픈 소스와 이로 만들어진 솔루션들에 대한 피드백을 제공하는 USERS로서 4사분면을 그리며 선순환을 이루고 있다.

이러한 선순환의 결과는 오픈 소스 생태계의 확장으로 이어질 것이고, "결과적으로 다양한 프로젝트들의 유지력도 향상될 수 있지 않을까?"라는 생각도 해봤다.

또한, 그렇게 된다면 사용자의 관점에서도, 기업의 관점에서도 오픈 소스라는 주제가 매력적으로 다가올 수 있지 않을까라는 결론도 조심스럽게 내려보았다.

여기서의 매력은 각기 다르게 이야기될 수 있을 것이다. '비용적인' 측면을 차치하고 말이다.

하지만, 이처럼 건강한 생태계를 유지하기는 쉽지 않을 것만 같다. 프로젝트가 커짐에 따라 한 개인이 관리하기에는 부담스러울뿐더러 기업의 입장에서도 하나의 생태계를 책임진다는 것은 큰 위험 부담을 감수하는 것이기 때문이다. 그렇다고 국가(정부기관)가 떠안기에는 상대적으로 이해관계가 성립되기 힘들다는 생각도 해봤다.

물론 이러한 위험 부담에도 생태계를 책임지고 있는 GoogleFacebook, Alibaba 등이 있는 것도 사실이고 미국이나 독일 등 다양한 국가에서 정부 차원의 지원이 있는 것은 사실이기에 이 부분은 국내의 정서로 받아들이기에는 다소 민감할 수 있겠다.


이제 필자는 오픈 소스 생태계의 실루엣을 어느 정도나마 엿볼 수 있게 되었다. 그렇다면 왜 필자는 최근에서야 오픈 소스라는 주제에 관심을 가지게 되었을까? 그것은 필자의 경험 부족과 더불어 오픈 소스의 중요성이 수면 위로 뜨게 된 것이 얼마되지 않았기 때문라고 생각한다.

이는 그 누구의 잘못도 아닐뿐더러 이미 각 사분면의 구성원들이 노력하고 있었기 때문에 지금에서라도 수면 위로 드러난 것이기에 본격적인 이야기에 앞서 그들의 노고가 어떠했을지 마냥 고개를 조아리게 된다.

그래서 필자는 생태계 각 구성원들의 활약이 궁금해졌다. 주변인들이 국내 오픈 소스 생태계가 제대로 구성되어 있지 않다고 느낀 이유는 위에서 언급한 기업들 같은 VENDORS(DRIVERS)의 부재 때문일까?

여기에 대한 답을 내리려면 보다 다양한 토론과 본질적인 문제에 대한 접근이 필요할 것이다.

그럼에도 한 가지 확실한 것은 개인의 입장에서 오픈 소스에 기여하는 것 또한 중요하다는 것이다.

가령 국내에서 오픈 소스 생태계에 관여하고 있는 기업이 다수 존재한다. 대표적으로 삼성과 네이버 또한 GitHub[7][8]을 통해 국내 오픈 소스 생태계에 기여하고 있는 것을 쉽게 찾을 수 있다.

물론 참여하고 있는 기업은 더 다양하다!

그렇다면 필자가 찾고자 했던 근본적인 문제는 COMMUNITY의 부재일까? 그렇지만도 않다. 그도 그럴 것이 자바스크립트 개발자 포럼[9]과 TensorflowKR[10]를 비롯한 여러 커뮤니티[11], [11-1], [11-2]가 이미 충분할 정도로 활성화되어있기 때문이다(오픈 소스만을 위한 커뮤니티로 활성화되어 있는지는 별개지만 말이다).

그렇다면 이제 남은 구성원인 USERSEXPERTS도 살펴보자.

잠시 전하자면 필자가 전하고자 하는 이 글의 목적은 단연코 USERS의 부재를 말하는 것이다. 여기서의 사용자는 프로젝트를 운영하는 메인테이너를 말하는 것이 아닌 컨트리뷰터를 의미한다. 이는 국내에 아무리 유명한 프로젝트가 많고, 훌륭한 메인테이너분들이 존재한다고 할지라도 이를 팔로우해줄 컨트리뷰터들이 없다면 이는 읽히지 않을 고전의 가치를 이야기하는 것과 같다고 생각하기 때문이다.

유저의 부재를 해결하기 위한 방법을 제시하기에는 이미 수많은 이들의 노고가 있었기 때문에 여기서 그것들을 다시 언급할 수는 없겠지만, 아직 견문이 짧은 필자가 느끼기에는 그들만의 리그가 구성되어 있는 것이 아닐까라고 생각했다. 한 마디로 진입장벽이 너무 높았다!

이는 필자가 경험한 모든 오픈 소스 프로젝트들과 그 구성원들 모두가 체감하고 있으며 이를 위해 세세한 가이드를 제공하고 있다. 하지만 그럼에도 입문자에게 대부분의 오픈 소스는 기술에 대한 이해, 영어에 대한 언어적인 문제를 차치하고서라도 프로젝트에 기여하기 위해서는 커뮤니케이션 피드백이 늦다거나, 그 서비스가 무엇인지를 알아야 하고, 코어를 이해하지 못하면 쉽게 진입하기도 어렵기 때문에 느낀점이다.

더불어 필자의 입장에서는 활성화되어 있다고 하는 여러 오픈 소스 프로젝트들과의 접점이 없어 기여하는 목정성을 느끼지 못하는 프로젝트가 대부분이었고, 이를 위한 각종 커뮤니티는 이미 오픈 소스의 장이 아닌 잡담의 장소 혹은 친목의 광장이었다.

이를 부정적으로 생각하지는 않지만 마냥 '오픈 소스 커뮤니티'라는 느낌보다는 그저 개발에 대한 다양한 주제를 공유하는 커뮤니티라는 인식이 강했다.

참고로 필자에겐 리눅스 기반의 프로젝트 대부분은 과거 7080 전산실에서부터 내려오던 Nerd 성향이 강했다. '그냥 재미로'라는 리누스 토발즈의 자서전의 제목과는 상반되게 필자에게는 전혀 재미있지 않은 프로젝트였던 것이다.

추가적으로 이러한 주관적인 의견은 그러한 프로젝트나 커뮤니티를 폄하하려 한다기보다는 본인을 포함한 오픈 소스 입문자들의 기술 편식에 대해 이야기하고, 어떻게 하면 이를 극복할 수 있을까에 대한 고민을 해결하기 위해 공유한 것이니 커뮤니티에서 활동하시는 분들께 불편하게 느낄 수 있는 여지를 준 것에 대해 죄송하다는 말씀을 전하고 싶다.

과거보다 오픈 소스 프로젝트의 사용자 수와 커뮤니티가 늘어난 것은 사실이지만 수가 늘어난 것과 생태계가 정상적으로 유지된다는 것은 별개의 이야기인 것 같다고 느꼈다.

이 글을 읽고 있는(이 글을 읽길 바라는) 독자들 중 일부는 GitHub과 같이 상대적으로 가시적인 소스 코드 호스팅 사이트에서조차 오픈 소스 프로젝트에 기여하기 위한 커밋 혹은 이슈보다는 자신의 프로젝트를 저장하기 위한 도구로 사용되고 있기 때문이다.

물론 예외는 존재한다. 더이상의 논란은 독자 중 일부가 민감하게 받아드릴 수 있는 주제이기 때문에 넘어가도록 하자.

결과적으로 필자는 보다 근본적으로 현 생태계의 문제를 따져보았을 때, "컨트리뷰터의 부재에 대한 책임은 결국 EXPERTS에 있고, 그들이 주도적으로 Users를 이끌어야만 건강한 생태계가 유지되는 것이 아닐까?"라는 생각을 했다.

국내에서는 기관 혹은 정부부처와 오픈 소스 저작권자(Maintainer)의 이해가 동일하지 않을 뿐더러 이해가 일치하더라도 이를 제대로 관리하려는 중앙 관리 기관의 역할도 제대로 수행되지 않는다고 느꼈기 때문이다.

더이상의 발언은 문제의 여지로 발전할 것만 같아 말을 아끼지만 생태계에 대해서는 다양한 이해관계가 얽혀있어 도덕책처럼 이야기되는 위 그림의 생태계를 유지하기 어려운 것은 사실이라는 것을 깨닫게 되었다.

이와 같은 시점에서 내가 할 수 있는 선택은 무엇이 있을까? 나는 오픈 소스라는 문화에 인생을 올인하여 장래를 이어나갈 생각도 없고, 그러한 사명을 느끼지도 못한다. 더불어 오픈 소스 프로젝트를 진행하는 것은 소소한 재미 혹은 알량한 명예를 위한 도구였을 뿐이고, 적절한 형상 관리를 위한 협업의 도구가 필요했기 때문이었다.

해외의 대부분 풀타임 오픈 소스 개발자들도 각자의 가치(명예, 재미, 금전적인 이익 등)를 추구하며 이에 대한 보상을 위해 그 길을 걷는 것인데, 이에 대한 보상은 커녕 푸대접뿐인 사회의 분위기 속에서 젊은이들은 그 속으로의 진입에 대해 리스키함을 넘어 실패에 대한 확증을 가지게 될까 걱정되기도 한다.

필자에게 오픈 소스 프로젝트를 진행한다는 것은 자선사업을 하기 위한 것이 아니기 때문이다! 사회적인 명예 혹은 만족감, 뿌듯함과 같은 개인의 이익을 위해서이다!

이러한 국내 오픈 소스 생태계를 보며 자란 필자와 같은 환경의 젊은 개발자 중에서 필자와 다른 의견을 가질 수 있는 이가 얼마나 있을지도 얼마나 있을까 싶어 필자의 "과연 나는 오픈 소스를 통해 원하고자 하는 가치를 얻을 수 있을까?"에 대한 고민이 깊어졌다.

가치를 추구하는 것은 개인의 자유지만 그에 대한 피드백은 확신할 수 없기 때문이다.

여기까지 글을 쓴 필자에겐 우려가 되는 한 가지가 있다. 공개된 이 글을 읽는 독자의 신분은 다양할 것이고, 글을 소비하는 모든 이들의 입맛에 맞는 글을 써내려 간다는 것은 어려운 일이기 때문이다.

그렇기에 한 가지 당부의 말씀을 드리고 싶다. 필자의 글은 국내 오픈 소스와 관계된 어떠한 이해 관계도 고려하지않고 그저 필자가 느낀 심정을 써내려 온 것이라는 것이다. 따라서 이 글을 읽는 독자가 필자의 편향된 견해를 시장의 보편적인 정의로 이해하는 실수를 범하지 않길 바란다.

다시 한 번 강조하지만 필자는 오픈 소스로 학사 이상의 학위를 가지고 있지도, 어떠한 자격이나 권한도 없는 일개 개발자에 불과하다. 그래서 이 글을 읽으며 느낀 불편함은 그저 '잘 모르는 이야기' 혹은 '풋내나는 견해'라고 생각해주길 바라며 이에 양해를 구한다.

앞으로 필자는 앞선 경험과 관점을 통해 스스로가 얻게 된 '내가 생각하는 오픈 소스를 활용하는 방법'에 대해 이야기하고자 한다. '오픈 소스'라는 단어는 이제 소프트웨어에 국한된 것만이 아닌 하드웨어에서의 기여도 활발하기 때문에 추후에 '오픈 소스 하드웨어'라는 주제를 이야기 할 수 있었으면 하는 개인적인 소망도 있다.

물론 이는 앞서 우리가 탐구해본 주제와 사뭇 다를 수 있고, 단어의 선택에 대해 여러 진영에서의 불편함이 있을 수 있음을 유의해야 할 것이다.

이렇게 줄글로만 필자의 생각을 전달한다고 해서 "그래! 오픈 소스, 나도 한 번 해보자!"하며 행동으로 실천할 수 있는 사람이 몇이나 있을까? 그래서 필자는 본 글을 시작으로 오픈 소스 기여를 다짐한 이들을 위해서나마 오픈 소스에 입문하기 위해 필요한 몇 가지 정보를 다음의 시리즈를 통해 하고자 한다.

1. 오픈 소스 활용기(0) - 지극히 주관적인 고민, 나에게 오픈 소스란 무엇일까?
2. 오픈 소스 활용기(1) - 개인 프로젝트 관리하기(준비중)
3. 오픈 소스 활용기(2) - 팀 프로젝트 관리하기(준비중)
4. 오픈 소스 활용기(3) - 유명 프로젝트 컨트리뷰터 되기(준비중)
5. 오픈 소스 활용기(4) - 오픈소스 메인테이너 되기(준비중)
6. 오픈 소스 활용기(5) - 한 편으로 끝나는 오픈소스 가이드(준비중)

시리즈의 내용 또한 필자가 기록하고 싶은 것을 기록하기 위한 것이지 백과사전이 아님을 전하며, 주관적인 이야기가 아닌 펙트를 원한다면 전문가 분들의 이야기를 찾아 읽기를 바란다.

마지막으로 필자가 위와 같은 시리즈를 연재하기로 한 이유를 공유하고자 한다. 필자가 경험한 '오픈 소스'라는 문화가 흥미로웠고 내가 알고 있는 기술로 다른 프로젝트에 기여하는 것에 재미를 느꼈기 때문에 스스로의 힘으로 오픈 소스에 빠져들고자 했던 과거의 필자가 필요로 했던 주제를 전하고 싶었다. 그것은 이 글과 같은 짧다면 짧은 한 편의 글이었기 때문이다.

다만, 앞으로의 글을 읽는 독자에게 한 가지 바라는 점이 있다면 글을 통해 얻은 정보와 지혜를 그대도 다른 이들에게 전하길 바란다는 것이다. 당장이라도 함께 공부하는 친구들에게, 주변의 동료에게 함께 오픈 소스를 시작하고자 다짐한다면 이 이상 건강한 문화를 만들기 위해 필요한 것도 없기 때문이다.

그럼 그대도 이 기회에 오픈 소스의 매력에 빠져보길 바란다!

물론 오픈 소스로 생계를 유지할 생각을 하거나, 제 2의 리눅스를 꿈꾼다면 이 글이 아닌 전문가의 글을 참고하라. 제발.


여기서부터는 여담이지만 필자는 이 글을 한 번 수정했다. 그 이유 중 하나는 '오픈 소스에 대한 정의'와 '취업'이라는 주제가 원인이었다. 필자의 부족한 이해와 더불어 글을 소비하는 독자의 범주가 정해져있지 않다보니 의도치않게 비즈니스, 취업에 대한 도구로서 오픈 소스를 정의해 제공하고 있었다.

이러한 관점은 실제 현장에서 느끼는 감정과는 사뭇 다르기 때문에 그들의 입장에서는 불편할 수밖에 없고, 넓은 관점에서 정보의 왜곡을 전달하고 있음을 느끼기에 충분했다고 생각한다.

하지만 필자가 그렇게 글을 쓴 것은 앞서 말한 것처럼 전문가가 아니며 전문적인 글을 쓰고 싶지도, 그럴 깜냥도 없다. 그래서 이 글은 오픈 소스 참고서가 아닐 뿐더러 그저 일기처럼 읽히는 가벼운 소재로 제공되길 바란다.

어디 가서 개인이 느낀 감정으로 이 글을 오픈 소스에 대한 정의라고 소개하지 말아달라고 부탁하는 것이다! 타인의 눈치를 보며 마치 백과사전이라도 된 것처럼 펙트만을 나열할 거면 그냥 위키를 운영했을테니 말이다! 심지어 진지하게 쓰고 싶지도 않다!!!

그러니 이 글을 읽는 그대가 만약 오픈 소스의 철학을 이해하려 하거나 깊은 이해를 목적으로 한다면 이 글을 그만 읽어주길 바란다. 앞으로의 글은 그대가 원하는 정해진 답이 아닌 지극히 주관적이고 필자 주변의 이야기를 서술할 것이기 때문에 다시 한 번 간곡히 그만 읽기를 권한다.

그럼에도 글을 수정한 이유는 적어도 이 글을 소비하는 이들 중 일부가 본 글을 '약파는 글', '전문가인 척 하는 사람의 글'로 오해할 것을 우려했기 때문이다. '오픈 소스'에 기여하고 있는 수많은 사용자와 기관, 커뮤니티, 회사는 오늘도 고민하고 성취, 재미, 성과, 명예, 금전 등 각자의 이득을 위해 오늘도 활동한다는 것은 변함없으니 그들에게도 감사와 양해의 말씀을 전한다.