이 글은 IDG의 아티클을 전재하여 제공함을 알려 드립니다.
[원문보기] : https://www.ciokorea.com/news/333582#csidx970e94ab4650238b621847e4ea17be3
정치적 관점에 따라 다르겠지만, 로널드 레이건 대통령 시절의 미국에서는 낙수 경제학(trickle-down economics)이 그다지 잘 먹히지 않았습니다. 하지만 오픈소스 소프트웨어에서는 이 원리가 그럭저럭 잘 작동해 왔습니다. 필자가 말하려는 것은 물론 경제 정책이 아닙니다. 소수의 엘리트 소프트웨어 엔지니어링 팀이 대중에 도움 되는 코드를 공개하는 활동에 대해 말하고 있습니다. 예를 들어 인기 있는 엔보이(Envoy) 프로젝트를 출시한 리프트(Lyft)를 언급할 수 있겠습니다. 또는 전 세계에 쿠버네티스(Kubernetes)를 제공한 구글(사실 목표는 자선 활동이 아니라 지배적인 AWS를 앞지르기 위한 기업 전략이었다)도 마찬가지입니다. 그리고 에어비앤비(Airbnb)는 배치 지향적 크론 스케줄링을 넘어서는 방법을 찾아내 공개했습니다. 아파치 에어플로우(Apache Airflow), 코드로서의 데이터 파이프라인(data pipelines-as-code)을 제공한 것입니다.
오늘날 월마트에서 어도비, 메리어트에 이르는 다양한 기업이 에어플로우를 사용하고 있습니다. 에어플로우 커뮤니티에는 스노우플레이크, 클라우데라 등에서 근무하는 개발자들도 포함되어 있지만, 대부분의 핵심 작업은 상위 25명의 기여자 중 16명을 고용하고 있는 어스트로머(Astronomer)의 엔지니어들이 수행해 왔습니다. 어스트로머는 이러한 관리 능력과 전문성을 잘 활용하여 아스트로(Astro)라는 완전 관리형 에어플로우 서비스를 운영합니다. 하지만 시중에는 다른 서비스들도 있습니다. 당연히 여러 클라우드 기업이 그에 상응하는 자체 서비스를 빠르게 만들어 왔습니다. 하지만 이들은 직접 개발한 코드를 커뮤니티에 반환하지 않고 있습니다. 여기서 상기할 점은 결국 코드란 누군가의 노력에 의해 작성되는 법이며, 노력에는 돈의 원리가 적용된다는 사실입니다.
데이터 파이프라인(Data Pipeline)이란?
오늘날 너도나도 대규모 언어 모델(LLM), 검색 증강 생성(RAG), 기타 생성형 AI(genAI) 용어를 언급하고 있습니다. 10년 전에 아파치 하둡, MySQL 등에 대해 떠들썩했던 모습과 비슷합니다. 용어는 바뀌었지만 데이터는 그대로이며, 시스템 간의 데이터 이동 방법에 대한 고민이 계속되고 있습니다. 바로 여기에서 에어플로우가 등장합니다. 어떤 면에서 에어플로우는 크론 작업 스케줄러(cron job scheduler)를 대폭 업그레이드한 것과 비슷합니다. 처음에는 고립된 시스템이 출현하지만 결국에는 서로 연결해야 합니다. 또 데이터가 이들 시스템 간에 흘러야 합니다.
업계에서는 이러한 데이터 파이프라인을 관리하기 위한 다양한 방법을 개발해 왔습니다. 하지만 데이터가 증가함에 따라 데이터를 관리하는 시스템도 급증하고 이러한 구성 요소 간의 상호 작용이 점점 더 복잡다단해지는 현상이 나타났습니다. 에어플로우를 오픈소스화할 때 에어비앤비 팀은 다음과 같이 기술했습니다.
"데이터 인프라가 진화하는 가운데, 중간 규모의 데이터 팀이 몇 년 정도 빠르게 대응했다면, 또 엄청나게 복잡한 계산 작업 네트워크가 있다고 가정하면, 데이터 팀이 관리하기에 부담스러운 복잡성이 출현할 수 있습니다. 이해하기조차 부담스러울 수 있습니다."
파이썬으로 작성된 에어플로우는 ‘데이터의 언어’를 다룹니다. 개발자가 모든 시스템 간에 데이터가 어떻게 흐르는지 계획하고, 조율하고, 이해할 수 있도록 일관된 방법을 제공하는 도구라고 생각할 수 있습니다. 포춘 500대 기업 중 상당수가 데이터 파이프라인 오케스트레이션을 위해 에어플로우를 사용하고 있으며, 그 가치는 나날이 커지고 있습니다. 즉, 에어플로우는 오늘날 엔터프라이즈 데이터 공급망에서 점점 더 중요해지고 있습니다. 다시 돈의 문제로 돌아가 봅니다.
코드는 저절로 작성되지 않는다
에어플로우에는 탄탄한 커뮤니티가 있지만, 코드의 55% 이상은 어스트로머에서 일하는 사람들에 의해 작성되는 것으로 추정됩니다. 어스트로머는 덕분에 관리형 아스트로 서비스를 통해 고객의 에어플로우를 지원할 수 있는 유리한 위치에 있습니다. 그런데 이로 인해 프로젝트가 위험에 처할 수도 있습니다. 어스트로머가 프로젝트에 부당한 영향력을 행사해서가 아닙니다. 아파치 소프트웨어 재단 프로젝트는 정의상 결코 단일 회사의 프로젝트가 아닙니다. 위험해질 수 있는 이유는 어스트로머가 재정적으로 투자 수준을 정당화할 수 없다고 판단할 가능성이 있기 때문입니다. 바로 이 지점에서 '오픈소스 먹튀'(open source rug pulling) 관련 문제가 대두될 수 있습니다. 필자가 최근에 주장했듯이, 오픈소스에는 1조 달러 규모의 무임승차자 문제가 있습니다. 이 문제는 항상 존재해 왔습니다. 어떤 회사도 자선 차원에서 기여하지 않습니다. 항상 스스로의 이익을 위해 기여(영문)합니다.
한 가지 문제는 기업이 자기 이익을 위해 기여해야 함을 이해하는 데 오랜 시간이 걸릴 수 있다는 것입니다. (엘라스틱이 라이선스를 변경하고 AWS가 엘라스틱서치를 포크하여 수십억 달러의 수익을 보호해야 한다는 것을 알게 되었을 때를 떠올릴 수 있습니다.) 이러한 인식 지연 문제는 다른 주체가 개발 비용을 부담할 때 더욱 악화됩니다.
반대로 자신이 수익을 챙길 수 있다면 다른 사람이 일을 하도록 내버려두는 것은 너무 쉽습니다. 쿠버네티스를 예로 듭니다. 커뮤니티의 얼굴 마담으로 간주되곤 하지만 막상 커뮤니티의 기여 비율은 꽤나 소수에게 집중돼 있습니다. 초창기부터 구글은 코드의 28%를 기여했습니다. 다음으로 많은 기여를 한 곳은 11%를 기여한 레드햇이고, 이후 8%를 기여한 VM웨어와 5%를 기여한 마이크로소프트가 뒤를 이었습니다. 그러나 반올림을 감안해 1%를 기여한 AWS가 쿠버네티스에서 얻은 수익은 다른 기업들을 압도합니다. 라이선스 규약하에서는 결코 부당하지 않습니다. 하지만 구글이 다른 사람들의 이익을 위해 그렇게 많은 개발 노력을 투입하는 것이 이익에 부합하지 않는다고 판단하면 어떻게 될까요?
한 가지 가능성은 기업들이 투자를 재조정하는 것입니다. 실제로 지난 2년 동안 구글의 기여자 비율은 20%로 떨어졌고 레드햇은 8%로 떨어졌습니다. 반면, 마이크로소프트는 8%로 상대적으로 기여 비중이 증가했고, AWS는 여전히 상대적으로 작지만 2%로 증가했습니다. 커뮤니티의 자정 작용일까요? 이제 다시 데이터에 대한 질문으로 돌아와 봅니다.
파이썬의 세계
에어플로우는 파이썬으로 구축됐습니다. 파이썬은 개발자들이 쉽게 시작할 수 있는 언어이기 때문입니다. 모국어는 아닐지언정 제2외국어 정도는 됩니다. 더 중요한 것은 아마도 개발자들에게 데이터 파이프라인에 대한 고민을 줄여줄 수 있다는 점입니다. 데이터 엔지니어는 데이터 파이프라인을 유지 관리하고자 하지 않습니다. 그들은 그 파이프라인이 배경 속으로 사라지기를 원할 뿐입니다.
이를 실현하는 방법이 명확하지 않습니다. 퍼스트마크 캐피탈이 포착한 오늘날 데이터/AI 환경의 절대적인 혼란을 고려할 때 더욱 그렇습니다. 어스트로머의 아스트로와 같은 관리형 서비스를 사용하면 시스템 간 파이프라인의 유지 관리를 간소화하면서 각종 옵션(퍼스트마크 차트 내의 많은 선택 사항)을 간단하게 보존할 수 있습니다.
앞으로 데이터 소스가 급증함에 따라 점점 더 커질 수 있는 ‘빅딜’입니다. 이 '빅딜'이 기여자 리스트에 더 많이 나타나야 할 것입니다. 오늘날 에어플로우 릴리즈의 원동력은 어스트로머의 개발자들입니다. 다른 회사들도 에어플로우를 통해 얻을 수 있는 수익에 걸맞게 기여하기를 기대합니다.
▶ 이 글은 저작권법에 의하여 보호받는 저작물로 모든 저작권은 저작자에게 있습니다.
▶ 이 글은 사전 동의 없이 2차 가공 및 영리적인 이용을 금하고 있습니다.
MongoDB의 Vice President