글로벌 칼럼 | “오픈소스 무임승차” AWS가 달라졌어요

지난 수년간 오픈소스 프로젝트에 무임승차해왔던 AWS가 이제 기여에 대한 관심을 조금씩 늘리고 있다. 
 

AWS는 오픈소스 업계와 그다지 사이가 좋지 않았다. 뉴욕타임즈는 2019년 AWS 오픈소스 기술을 ‘채굴’한다며 맹비난하기도 했는데, 개인적으로는 잘못된 비난이라고 생각한다. 그럼에도 외부에서 보기에는 AWS가 오픈소스를 채굴하고 있다고 오해할 수 있는 상황이었다. 

실제로 클라우드 네이티브 컴퓨팅 재단, 아파치 소프트웨어 재단과 관련된 인기 오픈소스 프로젝트의 기여 순위를 살펴보면 가장 오픈소스 기여를 많이 하는 기업은 구글이다. 그다음은 마이크로소프트다. AWS는 순위에서 저 멀리 떨어져 있다. AWS는 이런 문제를 크게 고려하지 않았다. 오히려 AWS는 오픈소스를 그리 중요하지 않은 업무 부담을 늘려주는 요소로 보며, 스스로 잘하고 있다고 생각하는 것 같았다. 

하지만 그때는 그랬지만 지금은 다르다. AWS에게 변화가 생기고 있는 것이다. AWS의 서비스 및 제품 팀은 마침내 아마존의 가장 중요한 리더십 원칙인 ‘고객 집착(Customer Obsession)’을 실현하기 위해(또는 주인 의식, 높은 품질의 결과물 제공 같은 다른 원칙을 실현하기 위해) 오픈소스 기여에도 집착해야 한다는 것을 알아가고 있는 것 같다. 
 

이상해 보이지만 진짜인 사실

필자는 지난해 ‘AWS가 친절해졌다’ 라는 제목의 칼럼을 통해 AWS가 소유권에 대한 사고방식을 바꾸고 있는 것 같다고 설명한 적이 있다. 아마존의 리더십 원칙 두 번째인 ‘주인 의식’을 추구하기 위해 AWS 서비스의 일부 팀은 고객을 제대로 관리하는 유일한 방법은 모든 기술을 직접 경험 해보는 것으로 생각했다. 이런 상황 탓에 남과 많은 것을 공유하는 오픈소스 커뮤니티에 AWS는 직접 참여하기 어려웠고, 오픈소스와 관련된 버그 수정 등을 할 때 스스로 나서지 않고 오픈소스 커뮤니티에 맡기는 듯한 인상을 주었다.

어떤 AWS 서비스 팀은 시스템 운영 방식에 대해 너무 많이 공개해야 할까 봐 혹은 경쟁업체가 AWS의 차별화 요소를 만드는 기술 버그 수정이나 기능을 사용할 수 있게 할까 봐 오픈소스 기여를 꺼렸다. 그 과정에서 기술 부채는 쌓이고, 고객이 진정으로 원하는 아파치 스파크(Apache Spark)나 MySQL 또는 기타 오픈소스 프로젝트를 쉽게 실행할 방법을 제공하기가 더 어려웠다.

필자는 AWS에서 근무한 적 있으며, 당시 느리지만 이런 상황에 변화가 생기고 있다는 것을 목격했다. 그리고 지금 그 변화의 속도가 점점 빨라지고 있는 것 같다. 예를 들어 포스트그레SQL(PostgreSQL)를 보자. 몇 년 전만 해도 AWS는 포스트그레SQL에 무임 승차한다는 비판을 자주 받았다. 물론 충분히 비난받을 여지가 있는 부분이었다. 고객을 위해 포스트그레SQL을 관리하며 많은 돈을 벌었지만 수익은 거의 돌려주지 않았기 때문이었다.

하지만 이제 포스트그레SQL 기여자 목록에는 AWS 직원들로 가득 차 있다. 이들 중 일부는 처음부터 오픈소스 기여자로 활동하다가 AWS에 고용돼 포스트그레SQL 그리고 아마도 RDS 및 오로라(Aurora)와 같은 AWS 데이터베이스 서비스 업무를 맡는 경우가 있다. 나단 보사르트(Nathan Bossart), 마사히코 사와다(Masahiko Sawada) 등은 AWS 출신이며 적극적으로 오픈소스 기여를 하는 것으로 유명한 인물이다. 과감한 추측이지만 직원들의 기여도를 합치면 AWS는 현재 포스트그레SQL를 기준으로 세 번째로 기여를 많은 한 기업이라고 필자는 생각한다. 물론 다른 사람들의 기여도 매우 가치 있지만 AWS의 참여가 놀라울 정도로 증가했다는 점을 강조하고 싶다. 
 

아직 갈 길이 멀다

이런 변화에도 불구하고 AWS가 오픈소스 업계에 해야 할 일은 많이 남아있다. 예를 들어, AWS는 쿠버네티스 서비스를 통해 많은 돈을 벌고 있지만 작년 한 해 기여도는 상위 10위 안에 간신히 들었다. 오픈텔레메트리(OpenTelemetry)와 같이 AWS가 서비스를 관리하는 오픈소스 프로젝트나 케이네이티브(Knative)처럼 AWS 고객이 많이 쓰는 프로젝트도 마찬가지다. AWS 엘라스틱 맵리듀스(Elastic MapReduce) 뒷단에 쓰인 아파치 하둡(Apache Hadoop)은 어떨까? 해당 프로젝트에 기여하고 있는 AWS 직원은 단 한명이다. 아파치 에어플로우(Apache Airflow)의 경우 조금 더 기여자가 더 많다.

AWS의 현재 모습에 평가는 제각각일 것이다. 컵에 물이 반이 담겨 있을 때 ‘반이나 있다’ 혹은 ‘반밖에 없다’라고 평가하는 것과 비슷하다. 명확한 사실은 오픈소스 프로젝트에 기여하는 AWS 출신 커미터가 생기고 있다는 부분이다. 이는 AWS의 변화를 보여주는 중요한 지표다. 불과 몇 년 전만 해도 오픈소스 프로젝트에 AWS 출신 커미터는 정말 찾기 어려웠다. 이제는 최소 한 명 이상은 볼 수 있다. 

이런 신호는 AWS의 목표가 달라졌다는 것을 알려준다. AWS는 오픈소스 프로젝트를 운영할 만한 충분한 능력을 갖췄다. 필자가 AWS에서 근무하면서 알게 된 것은 고객 대부분은 그저 서비스가 작동하는 것만으로 만족한다. 하지만고객이 원하는 방식(예:맞춤화된 고급 버전이 아닌 오픈소스 프로젝트의 기본 버전)으로 ‘그냥 작동’하게 하려면 AWS가 스스로 프로젝트 개발에 직접 참여해야 한다. 과거 엔지니어링 팀은 굳이 그럴 필요 없었지만 지금은 오픈소스 프로젝트에 참여해야 할  인센티브가 충분히 생기고 있다.

AWS가 오픈소스 프로젝트에 참여하면 결국 모두에게 좋다. AWS에게도 좋고, 사용자에게도 좋고, 오픈소스에도 좋다. AWS의 규모를 보면 AWS가 얼마나 다른 서비스와 다르게 운영되는지 알 수 있다. 시스템의 규모가 커지면 문제가 발생할 수 있으며 AWS는 이를 해결하는 방법을 배워왔다. 이런 노하우를 오픈소스 프로젝트에 더 많이 적용할 수 있다면 모두에게 이익이 되고, AWS 서비스를 판매할 수 있는 훨씬 더 큰 시장을 창출할 수 있을 것이다.

필자 Matt Asay는 몽고DB에서 DevRel, 이하 데브렐(Developer Relations, DevRel)를 맡고 있다. 
ciokr@idg.co.kr