13  지식을 오픈 소스하십시오

오픈 소스 코드가 처음부터 표준이었던 것은 아닙니다.

Unix 운영 체제는 1970년대에 만들어져 10년 동안 학술 기관과 기업에 자유롭게 라이선스되었으나, 이후 Bell Labs가 이를 독점 제품으로 유료화하기로 결정했습니다. 이에 불만을 느낀 리누스 토르발스(Linus Torvalds)는 1991년에 Linux를 만들어 공개했습니다. 오늘날 웹 서버의 97%가 Linux로 운영됩니다.

마찬가지로, 오늘날 여러분이 사용하는 소프트웨어 대부분은 대체로 오픈 소스입니다. 클로즈드 소스 코드베이스에 대한 오픈 소스 대안이 결국 승리할 것이라는 것이 일반적인 예상입니다:

코드에 일어난 일이 지식에도 일어나고 있습니다.

13.1 오픈 날리지(Open Knowledge)

우리 모두는 지식을 더 개방적으로 공유할 수 있습니다. 오픈 날리지(Open Knowledge)란 공개적으로 공유되는, 잘 다듬어지고 완성도 높게 제작된 정보를 말합니다. 책, 블로그 글, 치트시트, 강연, 라이브러리가 여기에 해당하며, 점점 더 데이터도 포함되고 있습니다. 이러한 데이터 공유는 오픈 날리지 재단(Open Knowledge Foundation)이 장려하는 것이기도 합니다.

예전에 금융업계에서 일할 때 제가 한 모든 일은 제가 속한 펀드의 자산이었고, 우리는 업계 발전을 위해 통찰을 공유한 적이 한 번도 없었습니다. 이는 가치 창출을 제로섬으로 바라보는 관점에서 비롯됩니다. 안타까운 일입니다. 저는 그 일을 하면서 인생 최고의 성과 몇 가지를 냈지만, 그 결과물은 어딘가의 메일함에 갇혀 있고 다시는 아무도 보지 못할 것입니다. 저 자신조차도 말입니다.

테크 업계는 근본적으로 더 개방적입니다. 이것은 멋진 일입니다. 이제 우리는 비밀 대부분을 공유할 뿐만 아니라, 무대에 올라 동료들에게 그것에 대해 이야기하고 그 대가로 보상까지 받을 수 있습니다! 모든 회사가 블로깅의 가치를 이해하고 있으며, 우리는 종종 코드까지 공개합니다.

하지만 이마저도 고도로 짜인 각본대로 진행되며 진입 장벽이 높은 과정입니다. 열린 지식(예를 들어 기술 서적)은 보통 한 사람이나 한 무리의 사람들이 큰 노력을 들여 만들어 내며, 정해진 출간일이 있습니다. 그리고 출간 이후에는 공개된 지식의 시의성이 시간이 지남에 따라 점차 떨어진다고 볼 수 있습니다.

13.2 오픈 소스 지식

오픈 소스 지식이 개방형 지식과 다른 점은 링크가 풍부하고 협업적이라는 특성입니다.

오픈 소스 지식이 처음부터 당연한 것은 아니었습니다. 예전에는 집집마다 찾아다니는 백과사전 외판원이 있었고, 그들은 지구상의 알아야 할 모든 것을 담은 거대한 전집을 우리에게 팔았습니다. 그러다 컴퓨터가 등장했고, 지구상의 모든 지식이 Microsoft Encarta CD-ROM 한 장에 다 들어간다는 사실에 경탄했던 기억이 납니다.

물론 그다음에 무슨 일이 일어났는지는 우리 모두 알고 있습니다. 위키백과가 등장하여 압도적인 폭, 이어서 깊이로 모든 상업 백과사전을 구시대의 유물로 만들었습니다. 그것도 빠듯한 비영리 예산으로 말입니다. 위키백과는 2001년에 공개되었습니다. 2005년에는 권위 있는 학술지 Nature가 위키백과의 정확도가 브리태니커 백과사전에 견줄 만하다는 결과를 발표했습니다. 2018년에는 Google, Facebook, YouTube가 위키백과 문서에 링크를 거는 방식으로 가짜 뉴스에 대응하기 시작했습니다.

“출처 필요”는 오픈 소스 지식의 근본적인 요건입니다. 위키백과는 그 자체로 신뢰할 만한 것이 아닙니다. 위키백과는 신뢰할 만한 출처에 링크함으로써 신뢰성을 얻습니다. 이는 훌륭한 점입니다. 독자가 출처를 직접 확인할 수 있게 하면서도, 정보를 특정 관점에 맞게 종합하여 더 쉽게 접근할 수 있게 해 주기 때문입니다. 이는 웹의 가장 중요한 기능인 하이퍼링크를 활용한, 백과사전에 대한 근본적인 혁신입니다.

위키백과에도 문제가 없는 것은 아닙니다. 하지만 협업과 크라우드소싱된 지식을 활용하는 위키백과의 능력은 사회에, 그리고 개별 문서의 저자와 큐레이터에게 큰 가치를 만들어 냈습니다. 천 개의 위키백과가 꽃피도록 합시다.

오픈 소스 지식은 소프트웨어 분야에서도 퍼지고 있습니다. 이는 당연하게 여겨질 것입니다. 코드는 모든 지식이 구체화된 형태 중 하나일 뿐이기 때문입니다. 여러분은 Sindre Sorhus에게서 영감을 받은 Awesome 저장소 중 하나를 알고 있을지도 모릅니다. 혹은 Gitbook을 통해 훌륭한 문서를 읽어 본 적이 있을 것입니다. 그리고 최근에는 Twitch와 YouTube를 통한 코딩 라이브 스트리밍이 늘어나고 있습니다. 심지어 이것으로 사업을 시작할 수도 있습니다. Nomadlist는 간단한 오픈 소스 Google 시트로 시작했습니다.

13.3 개인적인 일화

지식을 오픈 소스화하는 일은 제 커리어에 지대한 영향을 미쳤습니다. 이 이야기를 하는 것은 제 작업을 홍보하려는 것이 아니라, 이 아이디어를 제가 드릴 수 있는 가장 진솔한 방식으로 권하고 싶기 때문입니다.

개발자로 처음 취업한 회사에 출근한 첫날, 테크 리드가 대수롭지 않게 우리가 React와 TypeScript를 함께 쓸 것이며 이는 논의의 대상이 아니라고 말했습니다. 저는 그때까지 TypeScript를 한 번도 써 본 적이 없었습니다. 그렇게 TypeScript와의 강제적인 첫 만남이 시작되었습니다. TypeScript 문서를 처음부터 끝까지 읽어 보았는데, 내용이 아주 기초적인 것(ES6 지식이 전혀 없다고 가정)부터 아주 고급스러운 것(제네릭 타입을 극도로 능숙하게 다룬다고 가정)까지 들쭉날쭉했고, React를 위해 필요한 조정에 대해서는 전혀 언급이 없었습니다. React 문서는 그보다도 더 얻을 것이 없었습니다.

그래서 저는 TypeScript를 자신의 기술 목록에 추가해야 하는 React 개발자, 다시 말해 저 자신만을 위한 팁과 요령을 담은 나만의 치트시트를 만들기 시작했습니다.

알고 보니 저 같은 사람이 많았습니다. 이 글을 쓰는 시점에 저장소의 스타는 1만 2천 개에 이릅니다. 이 경우는 분명 운이 좋았습니다. 하지만 저는 이 방식을 React Suspense부터 디자인 요령, Node.js CLI에 이르기까지 다른 모든 분야로 확장했고, 어디서든 똑같이 효과가 있었습니다. “Git 저장소 속 README” 방식만이 지식을 오픈 소스로 공개하는 유일한 방법은 아니지만, 정말 훌륭한 방법임은 분명합니다.

13.4 왜 여러분의 지식을 오픈 소스하는가

지식을 오픈 소스로 공개하는 것은 순수한 이타주의적 행위가 아닙니다. 단 한 사람도 보지 않더라도, 지식을 정리하고 글로 적는 행위는 그 지식을 머릿속에 단단히 자리 잡게 합니다. 하지만 모든 것을 기억할 필요는 없습니다. 여러분의 저장소는 여러분보다 훨씬 더 많은 정보를 저장하고 검색할 수 있는 세컨드 브레인입니다. 이 제한된 의미에서는 이 지식이 비공개이든 공개이든 차이가 없습니다. 다만 Google에 몇 가지 단어를 입력해서 자신의 노트를 찾을 수 있다는 점은 좋습니다!

물론, 초보자를 돕는 것도 그리 멀지 않습니다. 여러분은 얼마 전까지 초보자였기 때문에 이해하기 쉬운 수준으로 설명할 수 있고, 주제를 입문자에게 맞는 논리적인 순서로 배열할 수 있습니다(반면 전문가는 기초에서 너무 멀어져 초보자의 입장에 공감하기 어려울 수 있습니다).

예상치 못한 이점은 여러분의 오픈 소스 지식이 여러분보다 더 많이 아는 사람들에게 유용해지기 시작할 때 찾아옵니다. 전문가들은 언제나 수많은 일로 바쁘며, 감당할 수 있는 것보다 더 많은 기회와 도움 요청을 받습니다. 여러분은 사실상 그들이 사람들에게 안내해 줄 수 있는 자료를 만들고 있는 셈입니다. 이제 그들에게는 여러분이 최고의 자료가 되도록 도울 동기가 생깁니다. 예를 들어 여러분의 오픈 소스 지식에 있는 실수와 빈틈을 바로잡아 주는 식으로 말입니다. 이런 방식으로 저는 AirBnb, Artsy, Paypal, 그리고 TypeScript 코어 팀의 전문가들에게 TypeScript를 무료로 배웠습니다.

지식을 오픈 소스로 공개해야 하는 다른 이유는 다음과 같습니다.

  • 이것은 프렌드캐처(장 43)이며, 시간을 레버리지하는 훌륭한 입문 방식입니다.
  • 이 방식은 여러분의 인맥과 전문성, 그리고 해당 분야와의 연관성을 천천히 키워 줍니다. 기대치는 낮고 여러분의 작업은 누구나 볼 수 있도록 공개되어 있으므로, 하룻밤 사이에 전문가가 되어야 한다는 부담을 느낄 필요가 전혀 없습니다. 그러면서도 이 방식은 여러분과 함께 성장하므로, 여러분이 정말로 많은 것을 알게 되었을 때에는 이미 풍부한 신뢰를 쌓았을 것이고 이를 뒷받침할 자료도 갖추었을 것입니다.
  • 이것은 살아 있는 작업입니다. 결코 “완성”되는 법이 없으며, 더 공들여 제작된 작업물에 비해 언제나 최신 상태를 유지한다는 장점이 있습니다.
  • Big L(장 42)은 L(PN)이며, 자생적인 커뮤니티를 일으킨다면 그보다 더 커질 수도 있습니다.
  • 쉽고 누구의 허락도 필요 없습니다. 누구나 라이브 스트리밍을 하거나, 트윗을 하거나, 저장소에 Markdown을 작성할 수 있습니다. 콘퍼런스에서 발표하거나 O’Reilly 책을 출판하는 것과 달리, 시작하는 데 누구의 허락도 필요하지 않습니다.
  • 어떤 용도로든 재활용할 수 있습니다. 모든 자료를 미장플라스(장 36) 방식으로 펼쳐 두었기 때문에, 필요에 따라 이를 발표, 워크숍, 블로그 글, 라이브러리 등 무엇이든 만드는 데 응용할 수 있습니다. 오픈 소스 지식은 여러분이 작성하는 어떤 오픈 소스 코드보다도 유용한 수명이 더 길다는 것을 알게 될 것입니다.

13.5 팁

이 일을 잘 해내기 위한 몇 가지 팁은 다음과 같습니다:

  • 복사-붙여넣기에 최적화하십시오 - 여러분이 자신과 다른 사람에게 줄 수 있는 가장 즉각적인 가치는 복사해서 붙여 넣을 수 있는 예제를 제공하는 것입니다. 예제는 그 자체로 완결되고, 주석이 잘 달려 있으며, 복사-붙여넣기에 맞게 만들어지도록 하십시오.
  • 다른 사람이 자기 친구를 도울 수 있도록 도우십시오 - 사람들이 여러분의 작업을 링크해서 좋은 평가를 받으면, 여러분도 좋은 평가를 받습니다. 그러니 시간이 지나도 가치가 변하지 않게 만들고, 광고나 뜬금없는 농담 같은 군더더기는 넣지 마십시오.
  • 오픈 라이선스를 추가하십시오 - 코드에 라이선스를 붙여야 하는 것처럼, 여러분이 축적한 지식을 사람들이 자유롭게 읽고, 기여하고, 포크해도 된다는 점과 어떤 출처 표시를 요구하는지를 명시하십시오.
  • 충분히 채워지지 않은 커뮤니티의 필요를 찾아보십시오. 여느 사업과 마찬가지로, 어떤 일을 처음으로 하거나 유일하게 시도하는 사람이어야 할 필요는 없습니다. 하지만 그렇게 하면 초기에 주목을 받는 데 도움이 될 수 있습니다. 두 분야가 교차하는 지점은 대개 충분히 다뤄지지 않습니다. 이는 여러분의 노력이 감당 가능하고(감당하지 못할 만큼 큰 일을 벌이지 마십시오) 공감을 얻도록(사람들이 “바로 이겁니다! 제가 처음 시작할 때 이걸 봤더라면 좋았을 텐데요!”라고 말합니까?) 돕습니다.
  • 구조는 내용만큼 중요합니다. 여러분의 역할은 정보를 제공하는 것만큼이나 정보를 정리하는 것이기도 합니다. 섹션들의 상대적인 길이, 제목의 구조, 심지어 무엇을 포함하지 않을지까지, 모든 것이 주의를 기울일 가치가 있습니다.
  • 구체적으로 도움을 요청하십시오. 자신의 지식에 어떤 빈틈이 있는지 알고 있다면, 막연하게 도움을 청하기보다는 바로 그 부분에 대해 도움을 요청하십시오. 도움을 받을 수도 있고 받지 못할 수도 있지만, 적어도 가능성은 더 높아집니다. 세상은 막연한 바람을 외면하고 구체적인 요청에 보답합니다.
  • 사내 OSK. 모든 정보가 공개되어야 하는 것은 아닙니다. 하지만 회사 내부에서 지식을 오픈 소스화하는 것만으로도 충분히 큰 성과를 거둘 수 있습니다.