Elastic vs AWS — 오픈소스 기업이 클라우드를 두려워하는 이유

오픈소스의 성공 공식은 왜 흔들리기 시작했을까

오픈소스는 오랫동안 매우 단순한 구조 위에서 성장해 왔다. 코드는 공개되고 누구나 사용할 수 있으며, 개발자들은 서로 협력하면서 더 나은 소프트웨어를 만든다. 이 철학은 자유 소프트웨어 운동에서 시작되었고, 이후 인터넷의 확산과 함께 빠르게 퍼져 나갔다. 많은 개발자들은 오픈소스를 단순한 개발 방식이 아니라 일종의 문화로 받아들였다. 코드를 공유하고, 문제를 함께 해결하며, 프로젝트를 공동으로 발전시키는 방식은 전통적인 소프트웨어 산업과는 전혀 다른 협력 모델이었다. 그리고 놀랍게도 이 모델은 단순한 이상에 그치지 않고 실제 산업에서도 강력한 힘을 발휘하기 시작했다. 오늘날 우리가 사용하는 수많은 기술 스택의 기반에는 오픈소스가 있다. Linux, PostgreSQL, Kubernetes, Redis, Kafka 같은 프로젝트들은 현대 인프라의 핵심 구성 요소가 되었고, 수많은 기업들이 그 위에서 서비스를 운영하고 있다.

하지만 여기에서 자연스럽게 등장하는 질문이 하나 있다. 이렇게 중요한 소프트웨어를 만드는 프로젝트들은 도대체 어떻게 돈을 버는 것일까. 오픈소스는 기본적으로 무료로 배포된다. 누구나 코드를 내려받을 수 있고, 수정할 수 있으며, 다시 배포할 수도 있다. 이 구조만 보면 오픈소스 프로젝트는 경제적 지속 가능성이 매우 낮은 것처럼 보인다. 그러나 실제 산업에서는 오픈소스를 기반으로 거대한 기업들이 등장했다. 그 대표적인 사례가 바로 Red Hat이다. Red Hat은 Linux라는 오픈소스 운영체제를 기반으로 기업용 배포판과 기술 지원 서비스를 제공하며 수십 년 동안 안정적인 수익 모델을 구축했다. 결국 이 회사는 2019년 IBM에 340억 달러라는 거대한 금액으로 인수되며 오픈소스 역사에서 가장 성공적인 비즈니스 사례 중 하나가 되었다. 이 사건은 오픈소스가 단순히 무료 소프트웨어가 아니라, 충분히 지속 가능한 산업 모델이 될 수 있다는 사실을 보여주었다.

이러한 성공 사례는 오픈소스 기업들에게 하나의 공식을 만들어 주었다. 핵심 소프트웨어는 오픈소스로 공개하고, 기업 고객을 대상으로 안정적인 운영과 지원을 제공하며, 필요에 따라 엔터프라이즈 기능을 추가하는 방식이다. 이 모델은 한동안 매우 안정적으로 작동하는 것처럼 보였다. 오픈소스는 개발자 커뮤니티를 통해 빠르게 성장했고, 기업은 그 위에서 상업적 서비스를 제공하며 수익을 얻었다. 개발자와 기업, 그리고 사용자 사이에는 비교적 균형 잡힌 관계가 형성되어 있었다. 그러나 시간이 지나면서 이 구조는 서서히 균열을 보이기 시작했다. 특히 2010년대 후반부터 등장한 새로운 기술 패러다임이 이 균형을 크게 흔들기 시작했다. 바로 클라우드였다. 클라우드는 단순히 서버를 다른 곳에 두는 기술이 아니었다. 그것은 소프트웨어가 배포되고 소비되는 방식 자체를 바꾸는 변화였다.

이 변화는 처음에는 그다지 위협적으로 보이지 않았다. 오히려 많은 오픈소스 프로젝트는 클라우드 덕분에 더 빠르게 확산되기도 했다. 클라우드 플랫폼은 새로운 서비스를 만들기 위한 인프라를 제공했고, 개발자들은 그 위에 오픈소스 소프트웨어를 자유롭게 배치할 수 있었다. 하지만 시간이 지나면서 상황은 조금 다른 방향으로 흘러가기 시작한다. 클라우드 기업들이 단순히 인프라를 제공하는 수준을 넘어, 오픈소스 소프트웨어 자체를 서비스로 제공하기 시작한 것이다. 이 순간부터 오픈소스 기업들은 예상하지 못했던 새로운 경쟁 환경과 마주하게 된다.

클라우드 시대가 소프트웨어 경제를 바꾼 방식

클라우드가 등장하기 이전의 소프트웨어 산업은 비교적 단순한 구조를 가지고 있었다. 기업은 소프트웨어를 구매하거나 다운로드한 뒤, 자체 서버에 설치해서 운영했다. 운영체제나 데이터베이스 같은 핵심 인프라는 대부분 기업 내부 데이터센터에서 실행되었다. 이 환경에서 소프트웨어 기업의 역할은 비교적 명확했다. 제품을 개발하고, 라이선스를 판매하며, 유지보수와 업데이트를 제공하는 것이 주요 비즈니스였다. 오픈소스 기업 역시 크게 다르지 않았다. 코드 자체는 무료였지만, 실제 운영 환경에서 필요한 안정성과 지원을 제공하는 기업이 수익을 얻는 구조였다. 기업 고객은 단순히 소프트웨어를 사용하는 것이 아니라, 그 소프트웨어를 안정적으로 운영할 수 있는 파트너를 필요로 했기 때문이다.

그러나 클라우드가 등장하면서 이 구조는 근본적으로 바뀌기 시작했다. 클라우드는 소프트웨어를 설치하는 방식 대신, 서비스 형태로 사용하는 방식을 중심에 두었다. 기업은 더 이상 서버를 직접 구매하거나 운영할 필요가 없었다. 대신 클라우드 플랫폼에서 필요한 인프라를 몇 번의 클릭만으로 생성할 수 있었다. 데이터베이스를 만들고 싶다면 버튼을 누르면 되고, 검색 시스템이 필요하다면 몇 분 안에 클러스터를 생성할 수 있었다. 이러한 방식은 기존의 소프트웨어 배포 모델과는 완전히 다른 사용자 경험을 제공했다. 설치 과정도 없고, 복잡한 설정도 필요 없으며, 확장과 운영 역시 대부분 자동화되어 있었다.

이 변화는 단순히 편리함의 문제가 아니었다. 그것은 소프트웨어의 경제 구조를 바꾸는 변화였다. 과거에는 소프트웨어를 만든 회사가 제품을 판매하고 지원을 제공했다면, 클라우드 시대에는 플랫폼 기업이 그 소프트웨어를 서비스 형태로 제공할 수 있게 되었다. 사용자 입장에서는 더 이상 소프트웨어 자체를 구매할 필요가 없었다. 대신 이미 운영이 준비된 서비스를 사용하는 것이 훨씬 간편했다. 이 변화는 특히 데이터베이스, 메시지 큐, 검색 엔진 같은 인프라 소프트웨어에서 빠르게 나타났다. 많은 개발자들은 소프트웨어를 직접 설치하고 운영하는 대신, 클라우드 플랫폼이 제공하는 관리형 서비스를 선택하기 시작했다.

이 구조 변화는 처음에는 단순한 기술 트렌드처럼 보였다. 하지만 시간이 지나면서 오픈소스 기업들에게 매우 중요한 질문을 던지기 시작했다. 만약 클라우드 플랫폼이 우리가 만든 소프트웨어를 서비스로 제공한다면, 고객은 과연 누구에게 돈을 지불하게 될까. 그리고 그 서비스가 성공했을 때 가장 큰 수익을 얻는 기업은 누구일까. 이 질문은 단순히 특정 기업의 문제가 아니라, 오픈소스 산업 전체가 마주하게 된 구조적 질문이었다.

Managed Service라는 새로운 경쟁 모델

클라우드가 소프트웨어 산업에 가져온 가장 큰 변화 중 하나는 바로 Managed Service라는 개념이다. Managed Service는 단순히 서버를 임대하는 서비스가 아니다. 그것은 특정 소프트웨어를 완전히 운영된 상태로 제공하는 서비스다. 사용자는 소프트웨어를 설치하지도 않고, 업데이트를 관리하지도 않으며, 클러스터를 직접 운영할 필요도 없다. 대신 클라우드 플랫폼이 모든 운영을 대신 수행한다. 데이터베이스가 필요하다면 몇 번의 클릭만으로 생성할 수 있고, 자동 백업과 확장, 장애 대응까지 대부분의 운영 작업이 플랫폼에 의해 처리된다. 이 모델은 특히 운영 복잡도가 높은 인프라 소프트웨어에서 매우 강력한 경쟁력을 갖게 되었다.

이러한 Managed Service는 개발자들에게 매우 매력적인 선택이었다. 전통적인 방식으로 데이터베이스나 검색 엔진을 운영하려면 상당한 수준의 운영 지식이 필요하다. 클러스터를 구성하고, 장애 상황을 대비하고, 성능을 튜닝하며, 확장 전략을 설계해야 한다. 그러나 클라우드 플랫폼이 이러한 작업을 대신 수행해 준다면 개발자는 훨씬 빠르게 서비스를 만들 수 있다. 이 때문에 많은 기업과 스타트업은 소프트웨어를 직접 운영하는 대신 관리형 서비스를 사용하는 쪽을 선택하기 시작했다. 특히 스타트업 환경에서는 운영 인력을 최소화하면서도 안정적인 인프라를 사용할 수 있다는 점이 큰 장점이었다.

하지만 이 모델은 오픈소스 기업의 관점에서 보면 전혀 다른 의미를 갖는다. 오픈소스 기업은 소프트웨어를 개발하고 커뮤니티를 성장시키며 생태계를 구축한다. 그러나 Managed Service 모델에서는 그 소프트웨어를 기반으로 실제 서비스를 제공하는 기업이 따로 존재할 수 있다. 다시 말해 소프트웨어를 만든 회사와 서비스를 제공하는 회사가 서로 다른 기업이 될 수 있다는 것이다. 그리고 대부분의 경우 사용자에게 직접 요금을 청구하는 쪽은 서비스 제공자다. 이 구조에서는 소프트웨어를 만든 회사보다 클라우드 플랫폼이 더 큰 경제적 이익을 얻을 가능성이 높다.

이 지점에서 오픈소스 기업들은 새로운 현실을 인식하기 시작한다. 오픈소스는 여전히 빠르게 확산되고 있었지만, 그 확산이 반드시 프로젝트를 만든 회사의 수익으로 이어지는 것은 아니었다. 오히려 클라우드 플랫폼이 그 가치를 더 빠르게 흡수하는 경우도 나타나기 시작했다. 그리고 이러한 구조적 긴장은 결국 특정 사건을 통해 매우 분명하게 드러나게 된다. 바로 Elasticsearch와 AWS 사이에서 벌어진 갈등이다. 이 사건은 오픈소스 기업과 클라우드 플랫폼 사이의 관계가 얼마나 복잡해졌는지를 보여주는 대표적인 사례가 된다.

Elasticsearch의 등장과 폭발적인 성장

Managed Service라는 새로운 경쟁 모델이 등장하면서 오픈소스 기업들은 이전과는 다른 환경에 놓이기 시작했다. 하지만 이 변화가 실제로 어떤 긴장을 만들어낼지는 아직 분명하게 드러나지 않은 상태였다. 많은 프로젝트들은 여전히 빠르게 성장하고 있었고, 오픈소스 생태계는 여전히 활발하게 확장되고 있었다. 이러한 상황에서 등장한 대표적인 프로젝트가 바로 Elasticsearch였다. 이 소프트웨어는 단순한 검색 엔진을 넘어, 현대 인프라 환경에서 매우 중요한 데이터 처리 플랫폼으로 자리 잡게 된다. 특히 로그 분석과 실시간 데이터 검색 같은 영역에서 Elasticsearch는 매우 강력한 도구로 평가받기 시작했다.

Elasticsearch는 Lucene이라는 검색 라이브러리를 기반으로 만들어진 분산 검색 엔진이다. 기존의 검색 시스템들이 상대적으로 복잡한 구조와 높은 운영 비용을 요구했던 것과 달리, Elasticsearch는 비교적 단순한 API와 확장 가능한 아키텍처를 제공했다. JSON 기반의 REST API를 통해 데이터를 색인하고 검색할 수 있었기 때문에 개발자들이 빠르게 활용할 수 있었다. 또한 분산 구조를 기본으로 설계했기 때문에 데이터 규모가 커지더라도 노드를 추가하는 방식으로 확장할 수 있었다. 이러한 특성 덕분에 Elasticsearch는 단순한 검색 시스템을 넘어 다양한 데이터 분석 환경에서 사용되기 시작했다. 로그 수집과 분석, 애플리케이션 모니터링, 보안 이벤트 분석 등 여러 분야에서 Elasticsearch는 핵심 구성 요소로 자리 잡았다.

Elasticsearch의 성장은 단순히 하나의 소프트웨어가 성공한 사례로 끝나지 않았다. Elasticsearch를 중심으로 Logstash와 Kibana가 결합된 ELK Stack이라는 생태계가 만들어졌기 때문이다. Logstash는 다양한 시스템에서 데이터를 수집하고 변환하는 역할을 했고, Kibana는 Elasticsearch에 저장된 데이터를 시각화하는 도구였다. 이 세 가지 도구가 결합되면서 로그 분석과 데이터 검색을 위한 매우 강력한 플랫폼이 만들어졌다. DevOps 문화가 확산되던 시기에 ELK Stack은 거의 표준 도구처럼 사용되기 시작했다. 많은 기업들이 서비스 로그를 분석하고 시스템 상태를 모니터링하기 위해 이 스택을 도입했다.

이러한 성장 뒤에는 Elastic이라는 기업이 있었다. Elastic은 Elasticsearch의 핵심 코드를 오픈소스로 공개하면서 커뮤니티를 확장하는 전략을 선택했다. 동시에 기업 고객을 위한 다양한 기능을 추가하며 비즈니스 모델을 구축했다. 기본적인 검색 엔진은 누구나 사용할 수 있도록 공개되어 있었지만, 보안 기능이나 고급 분석 기능 같은 일부 기능은 유료로 제공되었다. 이러한 모델은 흔히 “오픈코어” 전략이라고 불린다. 핵심 제품은 오픈소스로 공개하지만, 기업 환경에서 필요한 기능은 상업적으로 제공하는 방식이다. 이 전략은 Elasticsearch가 빠르게 확산되는 동시에 기업 고객을 확보할 수 있는 기반이 되었다.

하지만 Elasticsearch의 성공은 동시에 새로운 상황을 만들어내고 있었다. 수많은 기업들이 Elasticsearch를 사용하기 시작했고, 데이터 분석과 로그 처리에서 사실상의 표준 도구가 되어가고 있었다. 이러한 상황에서 클라우드 플랫폼 역시 Elasticsearch의 가치를 빠르게 인식하게 된다. 그리고 얼마 지나지 않아, 클라우드 기업들은 이 인기 있는 오픈소스 소프트웨어를 기반으로 새로운 서비스를 만들기 시작한다. 이 순간부터 Elasticsearch는 단순한 오픈소스 프로젝트가 아니라, 클라우드 플랫폼과 직접적으로 경쟁하는 위치에 놓이게 된다.

AWS가 Elasticsearch를 서비스로 만들다

Elasticsearch가 빠르게 확산되던 시기에 클라우드 플랫폼 역시 급격히 성장하고 있었다. 특히 Amazon Web Services는 다양한 인프라 서비스를 제공하며 기업들이 클라우드 환경에서 애플리케이션을 운영할 수 있도록 돕고 있었다. AWS는 단순한 서버 제공을 넘어 데이터베이스, 메시지 큐, 분석 플랫폼 등 다양한 인프라 서비스를 관리형 서비스 형태로 제공하기 시작했다. 이러한 전략의 핵심은 사용자가 복잡한 인프라를 직접 운영할 필요가 없도록 만드는 것이었다. 기업은 인프라 관리에 시간을 쓰는 대신 애플리케이션 개발에 집중할 수 있었다. 이 접근 방식은 많은 개발자와 기업에게 매우 매력적으로 보였다.

이러한 흐름 속에서 AWS는 Elasticsearch를 기반으로 한 관리형 서비스를 출시하게 된다. 바로 Amazon Elasticsearch Service였다. 이 서비스는 Elasticsearch 클러스터를 몇 번의 클릭만으로 생성하고 운영할 수 있도록 설계되어 있었다. 사용자는 서버를 직접 설정하거나 클러스터를 구성할 필요가 없었다. AWS 콘솔에서 필요한 노드 수를 선택하면 몇 분 안에 Elasticsearch 환경이 준비되었다. 클러스터 확장이나 장애 대응, 백업 같은 운영 작업도 대부분 자동으로 처리되었다. 이는 전통적인 방식으로 Elasticsearch를 운영하던 기업들에게 매우 큰 편의성을 제공했다.

사용자 입장에서 보면 이러한 서비스는 매우 합리적인 선택이었다. Elasticsearch는 강력한 소프트웨어였지만, 실제 운영은 상당한 수준의 경험과 지식을 요구했다. 클러스터 상태를 관리하고, 샤드 분배를 조정하며, 성능을 튜닝하는 작업은 전문적인 운영 능력을 필요로 했다. 하지만 AWS의 관리형 서비스를 사용하면 이러한 부담을 대부분 줄일 수 있었다. 많은 기업들은 Elasticsearch 자체를 직접 운영하는 대신 AWS가 제공하는 관리형 서비스를 선택하기 시작했다. 개발자들은 애플리케이션 개발에 집중할 수 있었고, 인프라 관리 비용도 줄일 수 있었다.

하지만 Elastic의 입장에서 보면 상황은 전혀 다르게 보였다. Elasticsearch는 Elastic이 수년 동안 개발하고 커뮤니티와 함께 성장시킨 소프트웨어였다. 그러나 AWS는 그 소프트웨어를 기반으로 서비스 상품을 만들어 판매하고 있었다. 많은 사용자들은 Elastic이 아니라 AWS에게 비용을 지불하게 되었다. 이 상황은 오픈소스 기업에게 매우 복잡한 질문을 던지게 된다. 만약 우리가 만든 소프트웨어로 다른 회사가 더 큰 수익을 얻고 있다면, 우리는 어떤 위치에 서 있는 것일까.

이 사건은 단순히 한 기업이 다른 기업의 소프트웨어를 사용한 사례로 볼 수는 없었다. 오픈소스 라이선스는 기본적으로 이러한 사용을 허용하고 있기 때문이다. Apache License는 상업적 사용을 제한하지 않으며, 누구나 코드를 활용해 서비스를 만들 수 있도록 허용한다. 따라서 AWS의 행동은 법적으로 전혀 문제가 없는 것이었다. 하지만 이 사건은 오픈소스 기업이 클라우드 시대에 어떤 위치에 놓이게 되는지를 매우 분명하게 보여주었다. 바로 이 지점에서 오픈소스 기업들은 자신들이 직면한 구조적 문제를 더욱 명확하게 인식하기 시작한다.

오픈소스 기업이 마주한 구조적 딜레마

Elasticsearch와 AWS 사이의 상황은 단순한 경쟁 문제가 아니었다. 그것은 오픈소스 기업이 클라우드 시대에 어떤 위치에 놓이게 되는지를 보여주는 구조적인 사례였다. 오픈소스 기업은 소프트웨어를 개발하고 커뮤니티를 성장시키며 생태계를 만든다. 이러한 과정에는 상당한 시간과 노력이 들어간다. 개발자들은 기능을 개선하고 버그를 수정하며 프로젝트를 발전시킨다. 기업은 이러한 프로젝트를 중심으로 제품을 만들고 고객을 확보하려 한다. 하지만 클라우드 시대에는 이 노력의 결과가 반드시 프로젝트를 만든 회사의 수익으로 이어지는 것은 아니었다.

클라우드 플랫폼은 매우 강력한 위치에 있다. 그들은 전 세계에 분산된 인프라를 운영하고 있으며, 수많은 기업 고객과 이미 연결되어 있다. 또한 개발자들이 사용하는 다양한 서비스와 도구를 하나의 플랫폼 안에서 제공하고 있다. 이러한 플랫폼 위에 오픈소스 소프트웨어를 서비스 형태로 제공하는 것은 비교적 쉬운 일이다. 사용자는 이미 해당 클라우드 플랫폼을 사용하고 있기 때문에 새로운 서비스를 추가하는 것도 자연스럽다. 결국 소프트웨어를 만든 회사보다 클라우드 플랫폼이 사용자와 더 가까운 위치에 있게 된다.

이 구조에서는 플랫폼 기업이 매우 유리한 위치를 차지하게 된다. 소프트웨어 기업은 제품을 개발하고 커뮤니티를 구축하지만, 실제 서비스 제공과 고객 접점은 플랫폼 기업이 가져갈 수 있기 때문이다. 특히 Managed Service 모델에서는 사용자가 직접 소프트웨어를 설치할 필요가 없기 때문에 이러한 차이가 더욱 커진다. 사용자는 단순히 클라우드 콘솔에서 서비스를 생성하고 요금을 지불하면 된다. 이 과정에서 소프트웨어를 만든 회사의 역할은 사용자에게 거의 보이지 않을 수도 있다.

이 상황은 오픈소스 기업들에게 매우 어려운 질문을 던지게 된다. 오픈소스의 핵심 철학은 자유로운 사용과 공유에 있다. 하지만 그 철학을 유지하면서도 기업으로서 지속 가능한 수익 구조를 만드는 것은 점점 더 어려워지고 있었다. 특히 클라우드 플랫폼이 오픈소스 소프트웨어를 기반으로 서비스를 제공하기 시작하면서 이 문제는 더욱 분명하게 드러났다. 결국 많은 오픈소스 기업들은 기존의 라이선스 모델을 그대로 유지하기 어렵다는 결론에 도달하게 된다. 그리고 이러한 고민은 결국 매우 중요한 결정으로 이어진다. 바로 라이선스의 변화다. Elastic 역시 이 문제를 해결하기 위해 기존의 오픈소스 전략을 다시 검토하기 시작한다.

Elastic의 선택: 라이선스 변경

Elasticsearch와 AWS 사이의 긴장은 단순한 기업 간 경쟁으로 끝나지 않았다. 시간이 지날수록 Elastic 내부에서도 중요한 질문이 커지고 있었다. 오픈소스 전략은 Elasticsearch를 빠르게 확산시키는 데 매우 효과적이었다. 수많은 개발자들이 Elasticsearch를 사용하기 시작했고, 커뮤니티는 빠르게 성장했다. 하지만 동시에 Elastic이 만든 기술로 다른 기업들이 서비스 상품을 만들어 수익을 얻는 상황도 계속 확대되고 있었다. 특히 클라우드 플랫폼이 Elasticsearch를 관리형 서비스 형태로 제공하기 시작하면서 Elastic이 직접 고객과 만나는 접점은 점점 줄어들고 있었다. 이러한 구조에서는 오픈소스 프로젝트를 만든 기업이 반드시 가장 큰 경제적 이익을 얻는다고 보장할 수 없었다.

Elastic은 이 문제를 단순한 경쟁 전략으로 해결할 수 있는 수준이 아니라고 판단하기 시작했다. 오픈소스 라이선스 자체가 이러한 구조를 가능하게 만들고 있었기 때문이다. Elasticsearch는 오랫동안 Apache License 2.0 아래에서 배포되고 있었다. 이 라이선스는 매우 관대한 라이선스로 알려져 있으며, 상업적 사용에 거의 제한을 두지 않는다. 누구나 코드를 수정하고 재배포할 수 있으며, 이를 기반으로 새로운 서비스를 만드는 것도 허용된다. 이러한 자유는 오픈소스 생태계의 성장에 큰 기여를 했지만, 동시에 클라우드 플랫폼이 Elasticsearch를 기반으로 서비스 상품을 만드는 것도 가능하게 만들었다. Elastic은 결국 이 구조를 그대로 유지하기 어렵다는 결론에 도달한다.

2021년 Elastic은 매우 중요한 결정을 발표한다. Elasticsearch와 Kibana의 라이선스를 더 이상 Apache License로 제공하지 않겠다고 선언한 것이다. 대신 Elastic License와 SSPL(Server Side Public License)이라는 새로운 라이선스를 도입했다. 이 결정의 핵심 목적은 매우 명확했다. 클라우드 기업이 Elasticsearch를 그대로 가져가 관리형 서비스 형태로 제공하는 것을 어렵게 만드는 것이었다. 특히 SSPL은 소프트웨어를 서비스로 제공하는 기업이 해당 서비스 전체의 소스코드를 공개하도록 요구하는 조항을 포함하고 있었다. 이는 사실상 대형 클라우드 기업이 해당 소프트웨어를 기반으로 서비스 상품을 만드는 것을 매우 어렵게 만드는 조건이었다.

이 결정은 오픈소스 커뮤니티 안에서 큰 논쟁을 불러일으켰다. 일부 개발자들은 Elastic이 오픈소스 정신을 훼손했다고 비판했다. 오픈소스의 핵심은 누구나 자유롭게 소프트웨어를 사용하고 확장할 수 있는 환경을 만드는 것인데, 라이선스를 통해 특정 사용 방식을 제한하는 것은 그 정신에 맞지 않는다는 주장도 있었다. 반면 다른 사람들은 이 결정을 오픈소스 기업이 생존하기 위한 현실적인 선택으로 보았다. 클라우드 플랫폼이 소프트웨어의 가치를 대부분 가져가는 상황에서, 프로젝트를 만든 기업이 아무런 보호 장치 없이 경쟁해야 하는 구조는 지속 가능하지 않다는 것이다.

Elastic의 라이선스 변경은 단순한 정책 변화 이상의 의미를 갖고 있었다. 그것은 오픈소스 기업이 클라우드 시대에 어떤 방식으로 자신들의 비즈니스를 보호하려 하는지를 보여주는 상징적인 사건이었다. 하지만 이 결정은 갈등을 끝내는 대신 오히려 새로운 국면을 만들어낸다. 클라우드 플랫폼 역시 이 상황을 그대로 받아들이지 않았기 때문이다. 특히 AWS는 이 결정에 대해 매우 적극적인 방식으로 대응하게 된다.

AWS의 대응: OpenSearch 포크

Elastic이 라이선스를 변경하자 가장 빠르게 반응한 기업은 AWS였다. AWS는 오랫동안 Elasticsearch 기반 서비스를 운영하고 있었고, 많은 고객들이 이 서비스를 사용하고 있었다. 만약 Elastic의 새로운 라이선스를 그대로 받아들인다면 AWS는 더 이상 기존과 같은 방식으로 Elasticsearch 서비스를 제공하기 어려워질 수 있었다. 특히 SSPL 라이선스의 조건은 클라우드 플랫폼 기업에게 상당히 부담스러운 요구였다. 서비스 전체의 소스코드를 공개해야 한다는 조건은 대부분의 상업적 플랫폼 기업에게 받아들이기 어려운 조건이었기 때문이다. AWS는 결국 다른 선택을 하게 된다.

AWS는 Elasticsearch의 마지막 Apache License 버전을 기반으로 새로운 프로젝트를 시작하기로 결정했다. 이 프로젝트의 이름은 OpenSearch였다. OpenSearch는 Elasticsearch와 Kibana의 오픈소스 포크 프로젝트로 시작되었다. AWS는 이 프로젝트를 단순히 내부적으로 사용하는 데 그치지 않고 공개적으로 개발하기 시작했다. 그리고 다양한 기업과 개발자들이 참여할 수 있도록 커뮤니티 중심 프로젝트로 운영하겠다고 발표했다. 이 과정에서 OpenSearch는 단순한 기술 포크를 넘어 하나의 독립적인 프로젝트로 발전하기 시작했다.

이 사건은 오픈소스 역사에서 매우 상징적인 순간이었다. 오픈소스 프로젝트를 만든 기업과 그 프로젝트를 기반으로 서비스를 제공하던 플랫폼 기업이 서로 다른 방향으로 갈라진 것이다. Elastic은 자신들의 비즈니스를 보호하기 위해 라이선스를 변경했고, AWS는 오픈소스 버전을 유지하기 위해 프로젝트를 포크했다. 이 사건은 오픈소스 생태계가 얼마나 복잡한 이해관계 위에서 움직이고 있는지를 보여주었다. 또한 오픈소스 프로젝트가 반드시 하나의 중심을 가지고 성장하는 것이 아니라, 필요에 따라 여러 갈래로 나뉠 수도 있다는 사실을 다시 한 번 보여주었다.

OpenSearch의 등장은 단순한 기술적 사건을 넘어 오픈소스 산업 전체에 새로운 질문을 던졌다. 오픈소스 프로젝트의 방향은 누구에 의해 결정되는 것일까. 프로젝트를 만든 기업일까, 아니면 그 소프트웨어를 사용하는 더 큰 생태계일까. 그리고 클라우드 플랫폼이 오픈소스 프로젝트에 참여하는 방식은 앞으로 어떤 영향을 미치게 될까. 이러한 질문들은 단순히 Elasticsearch만의 문제가 아니라, 오픈소스 산업 전체가 마주하게 된 새로운 현실을 보여주고 있었다.

이 사건이 오픈소스 산업에 남긴 질문

Elastic과 AWS 사이의 갈등은 특정 기업들 사이에서 벌어진 사건처럼 보일 수도 있다. 하지만 조금 더 넓은 시각에서 보면 이 사건은 오픈소스 산업 전체가 직면한 구조적인 문제를 드러낸 사례였다. 오픈소스 프로젝트는 개발자 커뮤니티와 기업의 협력을 통해 성장한다. 그러나 그 프로젝트가 성공할수록 더 많은 기업이 그 기술을 활용하게 된다. 특히 클라우드 플랫폼은 이러한 오픈소스 기술을 기반으로 새로운 서비스 상품을 만들 수 있는 강력한 위치에 있다. 이 과정에서 프로젝트를 만든 기업이 반드시 가장 큰 경제적 이익을 얻는다고 보장할 수는 없다.

Elastic 사건 이후 많은 오픈소스 기업들은 자신들의 전략을 다시 검토하기 시작했다. MongoDB는 이미 SSPL이라는 새로운 라이선스를 도입하며 클라우드 기업의 서비스 제공을 제한하려 했다. Redis를 중심으로 활동하던 Redis Labs 역시 특정 모듈의 라이선스를 변경하며 비슷한 방향을 선택했다. Confluent는 Kafka를 기반으로 한 클라우드 서비스를 직접 제공하며 플랫폼 기업과 경쟁하기 시작했다. CockroachDB 역시 오픈소스와 상업적 라이선스를 결합한 새로운 모델을 도입했다. 이러한 변화들은 모두 같은 질문에서 출발한다. 오픈소스 기업은 클라우드 시대에 어떻게 지속 가능한 비즈니스를 만들 수 있을까.

이 질문은 단순히 기업 전략의 문제가 아니다. 그것은 오픈소스의 철학과도 연결된 문제다. 오픈소스는 자유로운 사용과 협력을 기반으로 성장해 왔다. 하지만 그 자유가 기업의 생존을 위협하는 구조로 작동한다면, 오픈소스 기업은 어느 지점에서 균형을 다시 설정해야 한다. 일부 기업은 라이선스를 변경하는 방식을 선택했고, 일부는 클라우드 서비스 자체를 제공하는 전략을 선택했다. 또 다른 기업들은 오픈코어 모델을 강화하며 커뮤니티 버전과 기업 버전을 명확하게 구분하기 시작했다.

Elastic과 AWS 사건은 결국 하나의 사실을 분명하게 보여주었다. 오픈소스는 여전히 현대 소프트웨어 산업의 핵심 기반이지만, 그 위에서 만들어지는 경제 구조는 계속 변화하고 있다는 것이다. 특히 클라우드 플랫폼이 소프트웨어 배포와 운영의 중심이 된 이후, 오픈소스 기업들은 이전과는 전혀 다른 경쟁 환경에 놓이게 되었다. 이 변화는 단순한 기술 트렌드가 아니라 소프트웨어 산업의 구조적인 변화다. 그리고 이러한 변화 속에서 오픈소스 기업들은 새로운 전략을 계속 탐색하고 있다. 바로 이 지점에서 우리는 또 하나의 중요한 질문과 마주하게 된다. 오픈소스 라이선스는 과연 클라우드 시대에도 그대로 유지될 수 있을까. 다음 이야기에서는 바로 이 질문을 중심으로, 오픈소스 세계에서 벌어지고 있는 또 다른 갈등을 살펴보려 한다. 바로 라이선스 전쟁이다.

오픈소스와 클라우드의 불편한 공존

Elastic과 AWS 사이에서 벌어진 사건은 단순히 하나의 프로젝트가 두 갈래로 나뉜 이야기로 끝나지 않는다. 이 사건은 오픈소스와 클라우드 플랫폼 사이의 관계가 얼마나 복잡해졌는지를 보여주는 상징적인 사례였다. 오픈소스는 현대 소프트웨어 산업의 거의 모든 영역에 깊이 들어와 있다. 운영체제부터 데이터베이스, 메시지 큐, 컨테이너 플랫폼에 이르기까지 우리가 사용하는 대부분의 인프라 기술은 오픈소스 프로젝트에서 시작되었다. 개발자들은 오픈소스 덕분에 빠르게 새로운 기술을 활용할 수 있었고, 기업 역시 이러한 기술을 기반으로 서비스를 구축할 수 있었다. 이 점에서 오픈소스는 소프트웨어 산업 전체의 혁신 속도를 크게 끌어올린 중요한 기반이라고 할 수 있다.

하지만 클라우드 플랫폼이 등장하면서 이 구조에는 새로운 긴장이 생기기 시작했다. 클라우드 기업들은 오픈소스를 적극적으로 활용하며 다양한 서비스를 만들어냈다. Kubernetes, Linux, PostgreSQL 같은 기술은 클라우드 환경에서도 핵심 인프라로 사용되고 있다. 이 점에서 보면 클라우드와 오픈소스는 서로를 성장시키는 관계처럼 보인다. 오픈소스 프로젝트는 클라우드를 통해 더 많은 사용자에게 도달할 수 있고, 클라우드 플랫폼은 오픈소스를 통해 빠르게 새로운 서비스를 제공할 수 있다. 겉으로 보기에는 매우 이상적인 협력 관계처럼 보이는 구조다.

그러나 조금만 더 깊이 들여다보면 이 관계는 단순한 협력 이상의 의미를 가지고 있다. 클라우드 플랫폼은 단순한 소프트웨어 사용자 이상의 존재다. 그들은 거대한 인프라를 운영하고 있으며, 수많은 기업 고객과 직접적인 관계를 가지고 있다. 이 플랫폼 위에서 제공되는 서비스는 대부분 플랫폼 기업의 브랜드 아래에서 판매된다. 사용자는 PostgreSQL이나 Elasticsearch 같은 기술을 사용하고 있지만, 실제로 비용을 지불하는 대상은 클라우드 플랫폼이다. 이 과정에서 오픈소스 프로젝트를 만든 기업이 반드시 그 가치의 대부분을 가져가는 것은 아니다.

이러한 구조는 오픈소스 기업에게 매우 복잡한 선택을 요구한다. 한편으로는 오픈소스 생태계의 개방성과 협력을 유지해야 하고, 다른 한편으로는 기업으로서 지속 가능한 수익 모델을 확보해야 한다. 이 두 가지 목표는 때때로 서로 충돌한다. 너무 많은 제약을 두면 오픈소스 커뮤니티의 지지를 잃을 수 있고, 반대로 너무 개방적인 구조를 유지하면 클라우드 플랫폼이 그 가치를 대부분 흡수할 수도 있다. Elastic의 라이선스 변경은 바로 이 균형을 다시 설정하려는 시도였다.

결국 오늘날의 소프트웨어 산업에서 오픈소스와 클라우드는 서로 분리된 세계가 아니다. 오히려 두 영역은 서로 깊이 얽혀 있으며 동시에 협력과 경쟁을 반복하고 있다. 클라우드는 오픈소스 없이는 지금과 같은 속도로 성장하기 어려웠을 것이고, 오픈소스 역시 클라우드를 통해 전 세계로 확산될 수 있었다. 그러나 이 공존 관계는 결코 단순하지 않다. 그 안에는 경제적 이해관계, 기술 생태계, 플랫폼 권력 같은 여러 요소가 얽혀 있다. Elastic과 AWS의 사건은 바로 이 복잡한 관계가 처음으로 크게 드러난 순간 중 하나였다.

다음 이야기: 라이선스 전쟁

Elastic이 라이선스를 변경하고 AWS가 OpenSearch를 포크하면서 오픈소스 생태계에는 또 하나의 중요한 질문이 떠오르게 된다. 오픈소스 라이선스는 과연 클라우드 시대에도 이전과 같은 방식으로 작동할 수 있을까. 오랫동안 오픈소스 세계에서는 GPL, MIT, Apache 같은 라이선스가 널리 사용되어 왔다. 이 라이선스들은 기본적으로 소프트웨어의 자유로운 사용과 공유를 보장하는 것을 목표로 한다. 많은 개발자들은 이러한 라이선스 덕분에 전 세계의 개발자들이 협력할 수 있었고, 수많은 혁신적인 기술이 등장할 수 있었다고 생각한다. 실제로 인터넷과 클라우드 인프라의 상당 부분은 이러한 오픈소스 라이선스 위에서 만들어졌다.

하지만 클라우드 시대에는 이 라이선스들이 예상하지 못한 방식으로 사용되기 시작했다. 과거에는 소프트웨어를 사용하려면 직접 설치하고 운영해야 했다. 따라서 소프트웨어를 만든 회사가 지원이나 서비스 형태로 수익을 얻을 수 있었다. 그러나 Managed Service 모델이 등장하면서 상황은 달라졌다. 클라우드 플랫폼은 오픈소스 소프트웨어를 기반으로 서비스를 만들 수 있었고, 그 서비스는 전 세계 사용자에게 제공될 수 있었다. 이 과정에서 오픈소스 프로젝트를 만든 회사는 반드시 그 서비스의 수익에 참여하지 않는다. 이 구조는 많은 오픈소스 기업들에게 새로운 고민을 던지게 되었다.

이 문제를 해결하기 위해 일부 기업들은 새로운 라이선스 모델을 도입하기 시작했다. SSPL 같은 라이선스는 클라우드 서비스 제공을 제한하는 조건을 포함하고 있으며, BSL 같은 모델은 일정 기간 동안 상업적 사용을 제한하기도 한다. 이러한 라이선스는 전통적인 오픈소스 라이선스와는 다른 성격을 가지고 있다. 어떤 사람들은 이러한 변화가 오픈소스의 정신을 훼손한다고 주장하기도 한다. 반면 다른 사람들은 클라우드 시대에 오픈소스 기업이 생존하기 위해서는 새로운 규칙이 필요하다고 말한다.

이러한 논쟁은 단순한 법적 문제를 넘어 소프트웨어 산업의 미래와도 연결되어 있다. 오픈소스는 여전히 혁신의 중요한 기반이지만, 그 위에서 만들어지는 경제 모델은 계속 변화하고 있다. 특히 클라우드 플랫폼이 소프트웨어 배포와 운영의 중심이 된 이후, 라이선스는 단순한 법적 문서 이상의 의미를 가지게 되었다. 그것은 기술 생태계의 권력 구조를 결정하는 중요한 요소가 되었다. 다음 글에서는 바로 이 지점에서 시작되는 또 하나의 이야기를 살펴보려고 한다. 바로 오픈소스 세계에서 벌어지고 있는 라이선스 전쟁, 즉 SSPL, BSL, Elastic License 같은 새로운 라이선스들이 왜 등장했으며 어떤 의미를 가지는지에 대한 이야기다.