가루가 된 SKT ‘메타트론’ 오픈소스 프로젝트

7월 말 한국의 각종 IT 커뮤니티에서 화두가 되었던 한 오픈소스 프로젝트가 있었다. 바로 SKT에서 야심차게 내놓은 메타트론(metatron-discovery). 겉으로 보기엔 다양한 리소스에서부터 통합된 빅데이터 분석을 제공하고, 시각화된 결과까지 깔끔하게 제공해주는 괜찮은 프로젝트 같다. 하지만 프로젝트가 공식적으로 홍보된 후 얼마 지나지 않아 이 프로젝트의 이슈 게시판은 수많은 비난과 질책으로 가득 차게 되었다. 무엇이 사람들을, GitHub의 유저들을 화나게 한 걸까?

이 일의 시작에, SKT 홈페이지에서 게시한 이벤트가 있었다. 이름하여 ‘나는 별(★)로 안 더움!’ 이벤트. 이벤트에 참여하고 시원한 여름을 선물 받자는 의미로, 메타트론의 소스 코드가 올라간 GitHub 저장소에 Star(별)을 클릭하면 선착순 500명에게 스타벅스 음료를, 그리고 추첨을 통해 아이스크림 쿠폰, 영화 예매권과 같은 각종 상품을 제공하겠다는 이벤트였다. 형태로는 흔한 페이스북 좋아요 이벤트와 다를 것이 없지만, 페이스북이 GitHub으로 바뀌고 좋아요가 Star로 바뀌면서 사람들의 반응에는 많은 것들이 달라졌다.

GitHub은 기본적으로 다양한 버전의 코드를 관리하는 ‘원격 저장소’라고 할 수 있다. 하지만 Microsoft, Facebook 등의 거대 기업이 주도하는 주요 오픈소스 프로젝트가 지속적으로 등록되고 유저들의 프로젝트 기여 내역을 전시하는 포트폴리오의 역할을 하게 되면서 차츰 저장소 이상의 의미를 갖기 시작했다. 또한 프로젝트의 소스 코드만 공개되는 것이 아니라 프로젝트 자체의 완성도, 유용성을 평가할 수 있는 다양한 척도들도 함께 제공되는데, 그 중에 ‘좋아요’ 개념의 ‘Star’ 버튼도 있는 것이다.

이 Star 수가 빠르게 증가하는 저장소는 ‘Trending Repositories’ 섹션에 별도 노출되고, 필요한 기능을 제공하는 프로젝트를 검색할 때에도 Star 수가 높은 순으로 정렬되는 등, Star의 개수는 프로젝트의 인기를 대변하면서 동시에 주목받는 프로젝트가 더 빠르게 성장할 수 있는 촉매제로도 볼 수 있다. 관습적으로 GitHub의 유저들의 Star의 개수에 어느 정도의 의미를 두는 것을 감안할 때, 스타벅스 음료 쿠폰을 미끼 삼아 사람들이 이 프로젝트의 내용조차 모른 채 Star를 누르게 만든 것은 결코 세련된 행동이라고는 할 수 없다. 단순히 이 수치를 올려 ‘인기있는 프로젝트로 보이기 위함’이라는 초라한 의도가 빤히 보이기 때문이다. 그리고 이런 의도는 금방 자긍심으로 꽉 찬 오픈소스 개발자들에게 발각되고 만다. ‘Stop abuse GitHub Star’이라는 이름을 가진 이슈가 저장소에 등록되었고, GitHub의 ‘별’이 가진 신성한 의미를 더럽히지 말라는 댓글들이 속출했다.

오픈소스, 즉 소스를 누구나 볼 수 있도록 공개하고 누구나 프로그램의 개발 과정에 기여할 수 있도록 하는 이 이상적인 모델이 최근의 소프트웨어 개발의 큰 흐름을 주도하게 된 데에는 여기에 자발적으로 참여하는 개발자들이 있었기 때문이다. 그러나 이러한 자발성이 단순한 봉사 정신에서부터 나올 수 있었던 것은 아니다. 어떤 사용자가 실제로 코드를 몇 줄 작성했는지, 이 프로젝트를 실제로 사용하기 위해 복제(Fork)한 사람들은 몇 명인지, Star를 포함한 수많은 척도들이 실제로 GitHub 저장소의 코드와 함께 공개되어 있다. 결국, 실제로 개발자들이 기꺼이 프로젝트에 참여하도록 독려할 수 있었던 요인은 자신이 기여한 내역이 공정하게 공개되고, 이렇게 만들어진 프로필이 자신의 실력을 증명할 수 있는 수단으로도 활용될 수 있다는 사실이었다.

사건의 이면?

그러므로 SKT, 그리고 메타트론 개발팀이 저지른 잘못은 분명해 보인다. 하지만, 유독 그들에게 집중된 관심과 반감에는 도를 지나친 점도 없지 않다. 254개에 달하는 댓글이 달렸다. 열띤 어조로 이 사건이 오픈소스 생태계를 위협하는 중대한 기만 행위라고 외치며, 오픈소스 프로젝트에서의 Star가 절대적이고 객관적인 척도인 양 확신에 차서 장문의 글을 작성하는 사람들을 목격한다. 물론, 유효한 프로젝트 평가의 척도로써 Star의 의미를 보존하고자 하는 자정 노력은 인상적이며, 분명히 의미 있는 일이다. 그러나 일부 글들에 이러한 명분과 함께 ‘분노’라는 감정이 섞여 들어간 이유에는 의문을 가질 필요가 있다.

앞에서도 언급했다시피, Star의 개수는 프로젝트 평가의 유일한 척도가 아니다. 단지 가장 손쉽게 확인할 수 있는 ‘첫인상’과 같은 척도이고, 실제로 사용하기 위해 프로젝트를 검토할 때에 문서가 얼마나 체계적으로 구성되었는지, 버그 수정이 정기적으로 되고 있는지 등 다양한 측면을 확인하는 것이 일반적이다. 또한, 개개인마다 어떤 프로젝트에 Star를 주는 기준 또한 제각각일 수밖에 없다. 이 사건이 심각한 부정 행위라고 주장하는 사람들의 논리처럼 프로젝트를 직접 사용하거나, 혹은 꼼꼼히 따져보고 Star를 누르는 사람들도 있겠지만 단순히 관심있는 주제의 프로젝트이기 때문에 쉽게 Star 버튼을 누르는 사람들 또한 많다.

결국 이 사건이 많은 이들의 공분을 산 이유의 이면에는 Star를 누르는 주체가 자신들과 같은 개발자가 아니라 개발을 모르는 일반인이라는 사실이 있다. 몇몇 개의 글들에서 ‘개발자’와 ‘일반인’을 특별히 구분하여 지칭하며, 일반인들이 일회적인 보상을 위해 GitHub를 사용했다는 점에서 불쾌감을 표출했다. 개발에 대해 알지 못하는 일반인이 생태계의 보상 체계에 개입했다는 것, 어쩌면 이 사실이 개발자들의 자긍심에 흠집을 내었고, Star의 의미를 과장하면서까지 힐난하는 글을 덧붙이게 했을지도 모른다. 사건에 대해 보인 수많은 개발자들의 격앙된 반응을 생태계의 자정 작용으로만 해석하기에는 찜찜한 구석이 있는 이유다. 이 사건으로 인해 오픈소스에 참여하는 개발자들이 가진 일종의 엘리트주의, 또는 특권 의식이 의도치 않게 노출된 것이다.

별이 중요한 게 아니라구요

심지어는 ‘SKT의 수준이 보인다’ 라며 기업 자체에 대한 비난 또한 심심찮게 확인할 수 있었다. SKT, 그리고 이 프로젝트에 참여한 이들이 오픈소스에 대한 이해가 부족할 수도 있지만, 오픈소스 자체가 개발에 있어 절대적인 방법론은 아니다. 소스 코드를 외부에 공개하지 않고 기업 간에 경쟁적으로 소프트웨어를 개발하던 기존 방식은 결과적으로는 품질의 면에서 한계에 다다랐고, 그의 대안으로 제시된 것이 오픈소스이지만 그렇다고 해서 오픈소스가 모든 문제들을 해결해주는 완벽한 해결책은 아니다. GitHub에서도 특정 조직만 접근할 수 있는 비공개 저장소 기능을 유료로 제공하고 있고, 대부분의 상업적 오픈소스는 처음에 이를 담당하는 개발자들이 비공개로 핵심 기능을 먼저 개발하고, 이를 공개로 전환한 뒤 버그 해결이나 다국어 모드 지원과 같은 추가적인 기능에 대한 기여를 요청하는 것이 일반적이다. 즉, 기존의 개발 방식과 오픈소스가 일부 혼합된 구조를 채택하고 있는 것이다. SKT와 같은 대기업 내에 만연한 수직적이고 폐쇄적인 개발 문화가 오픈소스와는 상반되는 것으로 여겨지지만 사실 완전히 다르지는 않다는 이야기다. 그럼에도 오픈소스 진영은 절대선, 기존의 개발 조직은 절대악이라는 이분법적인 사고가 만연하고, 이러한 관점에 반하는 어떤 의문 제기도 찾아보기 힘들다. 결과적으로는 오픈소스 프로젝트에 활용되는 개발 도구들을 사용하고 프로젝트에 ‘오픈소스’라는 이름을 붙이면 저절로 좋은 소프트웨어가 만들어질 것이라는 헛된 믿음만 퍼져 갔다. SKT와 메타트론 팀이 가장 심각하게 오해한 것이 있다면, Star의 의미보다도 이러한 허상이지 않을까.

이쯤에서 오픈소스가 가진 의미를 되짚어볼 필요가 있다. 분명히 이 모델은 개발자들의 문화 내에 새로운 동향, 그리고 개발자라면 모름지기 추구해야 할 이상적인 형태로 자리잡았지만 결국 이 시스템이 돌아가도록 만드는 원동력에는 개인, 또는 조직 단위의 과시욕이 큰 역할을 한다는 사실을 무시할 수 없다. 과시욕이 시스템을 움직이는 한 손쉽게 조작할 수 있는 Star 수에 대한 부정행위는 언제든 다시 일어날 수 있다. 메타트론 프로젝트의 경우에는 노출된 이벤트가 존재했고 쉽게 비정상적인 행위를 발견할 수 있었지만, 직접 거짓 계정을 생성해 Star 수를 올리는 교묘한 조작 행위는 상대적으로 판별하기가 어렵다. 그러므로 조작이 어려운 척도를 고안하거나 Star를 줄 수 있는 사용자의 조건을 두는 등의 대안을 제안할 수도 있다. 그러나 이런 제안에 대해서도 반발심을 표출하는 댓글들이 줄을 이었다. 그들의 믿음 속에는 개발자들은 이성적이고 합리적인 이들이고, 당연히 오픈소스의 철학에 대해서도 완벽하게 이해하고 있어야 한다는 전제가 있다. 그러한 시스템을 충분히 이해하지 못한 이들은 우둔하고 비양심적인 이방인이 되고, ‘내부자’들은 그런 이방인들로부터 생태계를 무결하게 지켜냈다는 영웅적인 심리까지 느끼는 듯 보인다.

하지만 이렇게 시스템에 대한 무조건적인 신뢰에 기반하여 시스템의 허점 자체를 부정하는 것을 건강한 문화로 볼 수는 없다. 또한 이 문제로 인해 GitHub가 본래 가지고 있던 Star의 의미가 지나치게 확대되고 신성시되기까지 하는 것 또한 경계해야 한다. 유용하고 정교하게 구성된 오픈소스 소프트웨어라고 할지라도 현재 그러한 프로그램을 필요로 하는 사람들이 매우 소수라면 개인의 주관적인 판단으로 이루어진 이 숫자 하나가 그리 큰 의미를 갖지는 않을 것이다. 대신, 소스 코드가 얼마나 읽기 좋게 잘 구성되었는지, 테스트 코드가 얼마나 많은 기능들의 올바른 동작을 보장하는지가 더 중요하고 객관적인 척도가 될 것이고, 개발자들 또한 단순히 ‘별’의 숫자에 의존하여 프로젝트를 판단하는 것이 아니라 위와 같은 척도들을 판별하는 안목을 키우는 것이 더 건설적인 방향이지 않을까?

오픈소스 개발자? 오픈소스도 하는 개발자.

물론 이런 글을 쓰는 본인도 가끔 가다 (이유 모를) GitHub 별을 받으면 기뻐서 혼자 하루 종일 신나 있는, 인정 욕구에 목마른 아주 보편적인 개발자 지망생일 뿐이다. 하지만 하나의 패러다임에 지나치게 열광하다 보면 그것이 근본적으로 가지고 있는 문제를 과소평가할 수 있다는 점을 경계하기 위해 쓴 글이다. 함께 메타트론 프로젝트가 저지른 어이없는 일을 힐난하다가도, 내가 필요 이상의 ‘분노’를 섞고 있다는 생각을 했던 것이다. 어쩌면 다른 시스템을 대안으로 해결할 수 있는 문제를, 내가 이 시스템을 만능이라 생각하기 때문에 집착하게 될 수도 있지 않을까. 아직까지는 나 또한 오픈소스가 가진 무한한 가능성을 믿는 쪽이지만, 나를 오픈소스 개발자로 정의하며 살아가기보단 그냥 오픈소스도 하는 개발자, 로 지칭하고 싶다. 소속감은 편안하지만 어느 순간 지배당하기도 쉬운 법이니까.