칼럼 | 오픈소스 지속가능성 문제··· 기업 간 후원이 필요하다

비즈니스에 꼭 필요한 소프트웨어를 위해 개발자를 후원하는 것만으로는 이제 부족하다. 개발자를 후원하는 기업을 후원함으로써 전체 생태계가 번창하도록 촉진할 필요가 있다. 

오픈소스 지속가능성에 대한 또 다른 기사가 나왔다. 수년간 이러한 글(내가 쓴 글 포함)은 다수 등장했다. 오픈소스 지속가능성과 관련된 현실적 문제는 이제 분명하다. 모두가 오픈소스를 사용하고 있지만 어떤 오픈소스는 위험하다는 문제다. 홀로 고군분투하는 개인 오픈소스 관리자의 산출물이 우리 모두를 위험에 빠뜨리는 상황이 이어지고 있다.

그러나 ‘반드시 바뀌어야 한다’는 명제에 대한 해법이 긱 경제(gig economy)에 의존하는 경우가 너무 많다고 CNCF(Cloud Native Computing Foundation)의 CTO인 크리스 아니스지크는 지적했다. 오픈소스 기여자는 자신의 작업에 대한 대가를 제대로 받아야 한다. ‘코드를 작성하고 보상을 기도하는’ 방식은 안정적인 급여를 대체할 수 없다.

그러나 현실이 바뀌기도 어렵다. 적어도 주류 인기 프로젝트에서는 개발자들이 코드를 작성하고 그에 대한 보상을 받는다. 항상 그런 것은 아니지만 2008년의 GNOME 프로젝트로 거슬러 올라가보면 대부분의 개발자들이 기여에 대한 대가를 받았다. 오늘날에도 쿠버네티스(Kubernetes), 레디스(Redis), 리눅스(Linux) 등에 기여하는 대부분의 개발자도 보수를 받고 있다.

그러나 그 배후에 있는 회사는 그렇지 않을 수도 있다. 지속 가능성을 원한다면 개발자를 후원하는 회사를 후원하는 방안은 어떨까? 인기 있는 플럭스(Flux) 프로젝트를 예로 들어 보겠다.

미래로 돌아가기
플럭스(Flux)는 원래 위브웍스(Weaveworks)라는 회사에서 만든 쿠버네티스(그리고 테라폼(Terraform) 등)용 솔루션의 집합이다. 여전히 위브웍스가 플럭스의 주요 기여자이지만이 프로젝트는 현재 CNCF 프로젝트로 승격되어 외부로부터의 기여가 열려 있다. 플럭스를 CNCF로 가져가는 것은 커뮤니티에 틀림없이 좋은 일이지만 위브웍스에도 좋은 일인가?

그게 신경 써야 할 문제냐고 생각할 수 있지만, 그 대답은 분명하다. 신경 써야 한다!
  
위브웍스는 대규모 서비스형 소프트웨어(Software as a Service, SaaS) 애플리케이션의 백엔드 서비스를 구동하기 위해 프로덕션 환경에 쿠버네티스를 처음으로 도입한 회사 중 하나였으며, 이 작업을 가능하게 하려고 플럭스를 개발했다. 이는 사용자가 자율적인 운영을 할 수 있도록 돕는 인상적인 코드였다.

위브웍스가 이 작업을 하지 않는다면(또는 이를 위해 개발자에게 돈을 내지 않는다면) 아무도 시도하지 않았을 것이고, 플럭스는 존재하지 않았을 것이다. 

그게 대체 무슨 상관이냐고 또 반문할 수 있지만, 돈과 오픈소스가 나무에서 저절로 자라지 않는다. 오픈소스의 지속가능성은 개인만의 문제가 아니라 회사의 문제이다. 회사들은 개발자를 고용하여 오픈소스 소프트웨어를 작성한다. 그리고 소프트웨어를 위해 다른 회사들에게 돈을 지불하는 관행은 가장 일반적일 뿐더러 간편하다.

몇 주 전 플럭스 2.1은 출시되자마자 50만 이상의 다운로드를 기록했다. 이는 많은 사람들(및 그들의 고용주)이 쿠버네티스, 테라폼 등으로 생산성을 높이기 위해 플럭스를 애용하고 있음을 나타낸다. 플럭스는 마이크로소프트 애저가 자사의 쿠버네티스 제품에 구축할 만큼 인기가 좋으며 깃랩(GitLab), AWS(EKS Anywhere), 알리바바(Alibaba) 등에서도 사용하고 있다. 이 모든 회사들이 위브웍스나 CNCF 또는 누군가에게 플럭스 개발과 유지 보수를 계속하기 위해 돈을 기꺼이 지불할까? 내 경험상 그럴 가능성은 거의 없다.

이것이 바로 하시코프(HashiCorp)와 몽고DB를 비롯한 여러 기업들이 제품을 개방적으로 유지하면서도, 몇몇 사용자 그룹을 차단하려는 방법을 모색하는 이유다. 

오픈소스 개방성 유지
CNCF 내부의 여러 프로젝트를 살펴보면, 이러한 프로젝트들은 기업 기여자 커뮤니티 또는 단일 공급업체가 주도한다(이는 아파치 소프트웨어 재단(ASF)도 마찬가지지만, ASF는 단일 공급업체의 통제를 적극적으로 막으려 노력한다). 

플럭스, 아파치 카프카(Apache Kafka), 링커드(Linkerd) 등에도 핵심 조직이 있다. 이는 실제로 거대 클라우드 기업과 다른 기업에게는 좋은 점이 될 수 있다. 기능 요청이 있거나 지원이 필요할 때 개인 개발자보다 회사와 협력하는 것이 훨씬 쉽기 때문이다.

그러나 이러한 클라우드 (또는 기타) 벤더가 인공지능과 같은 새로운 분야로 이동하면 어떻게 될까? 위브웍스(또는 부얀트(Buoyant))와 같은 회사가 기업급 소프트웨어에 맞춰 차별화된 개발 작업을 수행해야 한다는 의미로 이어진다. (이러한 작업이 없다면) 새로운 기술이 아무리 멋지더라도 고객은 수십 년 동안 지루한 구형 소프트웨어를 사용해야 하는 것이다. 이를 피하기 위해서는 누군가가 개발자에게 비용을 지불하여 소프트웨어를 유지 관리하고 발전시켜야 한다는 의미다.

그 누군가가 바로 당신이 되지는 않을까?

그런 의미에서 클라우드 고객사가 플럭스와 기타 오픈소스 프로젝트에 의존함에도 불구하고, 클라우드 벤더가 프로젝트 스폰서와 금전적 관계를 맺지 않는 것은 심각한 해이일 수 있다. 이는 공급망 리스크다. 하시코프와 같이 라이선스를 변경하는 오픈소스 기업이 늘어나면 클라우드 제공 업체 및 기타 업체가 해당 코드와 관련된 서비스를 판매하지 못하게 될 수도 있다. 

플럭스의 경우, 위브웍스가 더 이상 재정적으로 개발을 유지할 수 없게 되면 어떻게 될 것인가? 마이크로소프트, AWS, 구글 또는 다른 기업이 개입할 것인가? 아니다. 왜 우리는 마술처럼 그들이 나서 줄 거라고 기대하는가?

이러한 벤더들이 협력과 기여를 등한시한다면, 고객 서비스 비용이 증가할 위험이 있다. AWS에 물어본 결과, 엘라스틱서치(Elasticsearch)를 포크하는 것이 단순히 AWS 플랫폼에서 엘라스틱(Elastic)의 성공을 지원하는 것보다 비용이 더 많이 든다는 것을 알게 되었다. 오픈서치(OpenSearch) 포크는 성공을 거두었지만 AWS는 브랜딩, 커뮤니티 개발 등과 같은 다른 비용 중에서 상당한 규모의 엔지니어링 팀을 고용해야 했다.

필자는 오픈소스 개발자에게 더 많은 돈을 지불하는 것이 핵심이라고 생각한다. 단순히 코드를 작성하는 것만이 아니다. 성공적인 오픈소스 프로젝트, 특히 기업이 채택하고 지속력을 갖춘 프로젝트에는 테스트, 버그 보고 지원, 분류 문서, 웹 사이트, 커뮤니티 등에 막대한 투자가 필요하다. 엔보이(Envoy)의 제작자인 매트 클레인은 몇 년 전 오픈소스 프로젝트를 구축하고 운영하는 것이 얼마나 어려운지 알았더라면 아마 시작하지 않았을 것이라고 말한 바 있다.

더 걱정스러운 것은 개발자나 기업이 프로젝트를 계속할 이유와 여력이 없다고 판단하는 상황이다. 다시 말하자면, 장기적인 지속가능성을 보장하지 않은 채 플럭스와 같은 오픈소스 프로젝트를 기반으로 비즈니스를 구축하는 것은 커다란 위험성을 초래하는 행보다. 오픈소스 지속가능성을 도모해야 한다. 오픈소스 유지 관리자를 위해서도 좋은 일이지만, 고객을 위해서도 옳은 일이다. 고객을 위해 해야 할 필수적인 일이기도 하다.

* Matt Asay는 몽고DB의 개발자 관계 업무를 담당하고 있다. 그러나 본 글은 몽고DB의 입장이 아니다. ciokr@idg.co.kr