칼럼 | 에어플로우 기여와 돈 버는 왕서방 문제 · · · 모두를 위한 데이터 파이프라인은?

아파치 에어플로우는 훌륭한 코드로서의 데이터 파이프라인이다. 그러나 기여자 대부분이 어스트로머에서 일한다는 점이 오픈소스의 태생적 문제를 일깨운다.
 

정치적 관점에 따라 다르겠지만, 로널드 레이건 대통령 시절의 미국에서는 낙수 경제학(trickle-down economics)이 그다지 잘 먹히지 않았다. 하지만 오픈소스 소프트웨어에서는 이 원리가 그럭저럭 잘 작동해왔다

필자가 말하려는 것은 물론 경제 정책이 아니다. 소수의 엘리트 소프트웨어 엔지니어링 팀이 대중에 도움되는 코드를 공개하는 활동에 대해 말하고 있다. 예를 들어 인기 있는 엔보이(Envoy) 프로젝트를 출시한 리프트(Lyft)를 언급할 수 있겠다. 또는 전 세계에 쿠버네티스를 제공한 구글(사실 목표는 자선 활동이 아니라 지배적인 AWS를 앞지르기 위한 기업 전략이었다)도 마찬가지다. 그리고 에어비앤비는 배치 지향적 크론 스케줄링을 넘어서는 방법을 찾아내 공개했다. 아파치 에어플로우, 코드로서의 데이터 파이프라인(data pipelines-as-code)을 제공한 것이다.

오늘날 월마트에서 어도비, 메리어트에 이르는 다양한 기업이 에어플로우를 사용하고 있다. 에어플로우 커뮤니티에는 스노우플레이크, 클라우데라 등에서 근무하는 개발자들도 포함되어 있지만 대부분의 핵심 작업은 상위 25명의 기여자 중 16명을 고용하고 있는 어스트로머(Astronomer)의 엔지니어들이 수행해왔다.

어스트로머는 이러한 관리 능력과 전문성을 잘 활용하여 아스트로(Astro)라는 완전 관리형 에어플로우 서비스를 운영한다. 하지만 시중에는 다른 서비스들도 있다. 당연히 여러 클라우드 기업이 그에 상응하는 자체 서비스를 빠르게 만들어 왔다. 하지만 이들은 직접 개발한 코드를 커뮤니티에 반환하지 않고 있다.

여기서 상기할 점은 결국 코드란 누군가의 노력에 의해 작성되는 법이며, 노력에는 돈의 원리가 적용된다는 사실이다.

데이터 파이프라인이란?
오늘날 너도나도 대규모 언어 모델(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 환경의 절대적인 혼란을 고려할 때 더욱 그렇다. 어스트로머의 아스트로 아스트로와 같은 관리형 서비스를 사용하면 시스템 간 파이프라인의 유지 관리를 간소화하면서 각종 옵션(퍼스트마크 차트 내의 많은 선택 사항)을 간단하게 보존할 수 있다.

앞으로 데이터 소스가 급증함에 따라 점점 더 커질 수 있는 ‘빅 딜’이다. 이 '빅 딜'이 기여자 표에 더 많이 나타나야 할 것이다. 오늘 에어플로우 릴리즈의 원동력은 어스트로머의 개발자들이다. 다른 회사들도 에어플로우를 통해 얻을 수 있는 수익에 걸맞게 기여하기를 기대한다. 

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