개발자 컨퍼런스에 가면 노트북 스티커 퍼레이드를 볼 수 있다. 클라우드 네이티브 인기 프로젝트, 잘나가는 최신 데이터베이스, 빠지지 않는 마스코트 캐릭터 두어 개까지…. 개발자가 미덕을 과시하는 방법이자 자신이 속한 집단을 드러내는 방식이다. 하지만 그 속에서, 적어도 자주 보이지 않는 것이 있다. 바로 저 스티커 친화적인 스타트업 여러 곳을 합친 것보다 더 많은 코드를 조용히 기여하는 기업의 로고다.

존재감이 드러나지 않는 건 우연이 아니다. 이들 기업은 수익을 다른 분야에서 올리며, 오픈소스 기여를 마케팅 수단이 아니라 비즈니스의 핵심 기반으로 여긴다. 하지만 그들이 미치는 영향력만큼은 결코 조용하지 않다.

데이터가 통념을 뒤집을 때

우리는 매시간, 매일 사용하는 리눅스 커널에 의존한다. 리눅스는 모두가 기반으로 삼는 프로젝트지만, 그 뒤를 받치는 기업의 로고는 아마 개발자의 노트북 스티커 모음에 없을 것이다. 예를 들면 필자가 근무하는 오라클이 있다. 6.1 릴리즈 주기에서 오라클은 커널 전체에서 변경된 코드 라인 수 기준 최대 기여 기업이 됐다. 데이터베이스 업계에서 수파베이스(Supabase)나 네온(Neon)이 각자의 프로젝트를 키운 공로를 인정받는 것은 당연하다. 하지만 개발자가 매일 쓰는 리눅스에서 메모리 관리 구조를 패치하고 블록 장치 드라이버를 관리하는 것은 바로 오라클이다.

오라클의 커널 작업은 일회성이 아니다. 5.18 릴리즈에서도 오라클은 ‘커널 중심’ 기여 순위에서 1위를 차지했고, 이후에도 속도를 늦추지 않았다. 메이플 트리(Maple Tree) 데이터 구조와 기타 성능 향상 기능을 커널에 반영하는 데도 기여했다. 이런 패치는 물론 오라클 클라우드 인프라스트럭처(Oracle Cloud Infrastructure, OCI)를 구동하는 데 쓰이지만, 오래된 씽크패드 노트북에서 돌아가는 우분투 속도를 높이는 데도 도움이 된다. 자사의 이익을 위한 기여인가? 맞다. 공공에 이익이 되는가? 그 역시 틀림없다.

이는 오라클만의 이야기가 아니다. 오라클 너머로 시야를 넓혀도 같은 패턴이 보인다. 2023년, 필자는 아마존의 ‘조용한 오픈소스 혁명’에 대해 쓴 적 있다. 예전에는 소극적이던 이 회사가 갑자기 깃허브 커밋 로그 곳곳에 등장하기 시작한 현상을 다룬 글이다(참고로 필자는 과거 AWS의 오픈소스 전략·마케팅팀을 이끌었다). 2017년으로 더 거슬러 올라가면, 필자는 클라우드 서비스 업체가 최종 제품이 아닌 독점 서비스로 진입시키기 위한 경로로 코드를 오픈소스화한다고 주장했다. 두 관찰 모두 여전히 사실이지만, 더 큰 포인트를 놓칠 수 있다. 동기가 무엇이든, 코드는 흘러가고 커뮤니티가 그 혜택을 누린다는 점이다.

결과가 중요하다면 동기는 크게 상관없다. 아니, 어쩌면 상관이 있을 수도 있다. 매출에 도움이 되기 때문에 기업이 기여하는 구조가 자선적 이유로 기여하는 것보다 훨씬 지속 가능하다. 전자는 오래가지만, 후자는 오래가지 못한다.

보이지 않는 기여를 놓치는 까닭

기여 규모가 크고 오픈소스 지속 가능성에 절대적으로 중요한데도, 우리는 왜 이런 기여를 늘 간과하는 것일까? 여기에는 3가지 이유가 있다.

첫째, 이들은 스티커를 팔지 않는다. 일부 기업은 오픈소스를 활용해 개발자의 관심과 인지도를 끌어올린다. 개발자가 핵심 고객층이라면 이는 마케팅에 필수적일 수 있다. 하지만 단순한 예시로 리눅스 6.15 커널 기여자 목록만 봐도 변경 세트(changeset) 기준 1위는 인텔이다. 맞다, 최근 미국 대통령 도널드 트럼프의 표적이 된 바로 그 인텔이다. 트럼프는 인텔의 리눅스 기여에 관심이 없지만, 우리 개발자는 그렇지 않다. 또 다른 예로, 최근 1년간의 쿠버네티스 기여 현황을 보자. 구글, 레드햇, 마이크로소프트, VM웨어, AWS가 상위권을 차지한다. 그 이유는 ‘기여가 멋져서’가 아니라, 이들이 쿠버네티스 서비스로 수십억 달러의 매출을 올리고 있기 때문이다.

둘째, 이들의 브랜드는 ‘폐쇄적’이라는 인상을 준다. 필자가 몸담은 회사를 포함해 일부 기업은 상용 소프트웨어를 판매하기 때문에 사람들은 자연스럽게 이들을 라이선스 요금이나 폐쇄형 클라우드 서비스와 같은 범주에 넣는다. 이런 편견은 대규모 오픈소스 기여를 보여주는 실증적인 데이터조차 쉽게 무시하게 만든다.

셋째, 수치는 좀처럼 헤드라인에 오르지 않는다. 화려한 키노트 한 번이 1년간의 풀 리퀘스트를 가려버릴 수 있다. 언론 매체도 커널 유지보수 코드 1만 줄보다는 스타트업의 로고 변경 소식을 훨씬 더 빠르고 자주 다룬다.

이익 추구는 결함이 아니라 장점

회의론자는 기업의 기여가 오픈소스의 ‘순수성’을 훼손한다고 주장한다. 그들은 ‘진정한’ 오픈소스란 자유와 애정으로만 운영되는 이상적인 깃허브 저장소에 있다고 믿는다. 이는 터무니없고, 순진하며, 사실이 아니다. 필자는 무임승차하는 대형 업체를 강하게 비판해 왔지만, 이익을 목적으로 한 코드 기여를 과소평가하는 것은 실용적인 측면에서 두 가지 이유로 잘못이다. 그중 하나는 이미 앞서 언급한 것이다.

• 지속 가능성 : 기여가 매출과 맞물리면 실적이 나쁜 분기에도 예산이 유지된다. 오라클이 리눅스를 최적화하는 이유는 성능이 0. 몇 퍼센트라도 향상되면 OCI의 매출원가를 낮출 수 있기 때문이다. 이런 동기는 CFO가 허리띠를 졸라맬 때도 사라지지 않는다. AWS가 점점 더 포스트그레스에 기여하는 이유도 마찬가지다. 기술 부채를 줄이고 프로젝트 방향에 영향력을 행사할 수 있기 때문이다.
• 규모 : 대형 업체는 커뮤니티 프로젝트가 감당할 수 없는 자원을 보유하고 있다. 암페어(Ampere) 기반 OCI 기여는 퍼블릭 클라우드에서 실제 비용을 청구하는 영역의 빈틈을 메운다. 쿠버네티스 유지관리자는 무료 Arm 용량을 확보하고, 전 세계 개발자는 더 빠른 풀 리퀘스트 워크플로우를 누릴 수 있다. 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation)의 다양한 프로젝트 기여 데이터를 살펴보면 한 가지 공통점을 알 수 있다. 기여하는 기업은 더 규모가 크고 자금 여력이 있는 업체라는 점이다. 이들은 해당 프로젝트에 이해관계를 가지고 있을 뿐 아니라, 투자할 자원도 갖추고 있다.

즉, 이익을 겸비한 현명한 자기 이익이 CI 하드웨어, 보안 감사, 장기 유지보수처럼 지루하지만 필수적인 작업을 뒷받침한다. 이는 풀뿌리 자원봉사자들이 자금 마련에 어려움을 겪는 영역이기도 하다.

보이지 않는 빌더에게 주목하기

그렇다면 우리는 어떻게 이들의 가치를 다시 평가해야 할까?

• 컨퍼런스 행사장보다 커밋을 보라. 데브스탯(DevStats), 커널 메일링 리스트 통계, 깃허브 API는 좀처럼 거짓말을 하지 않는다. 이 통계 차트에는 우리가 무대에서 박수를 보내는 일은 거의 없는 기업이 꾸준히 등장한다. (물론 이런 대기업이 개발자 행사에서 기조연설 자리를 돈 주고 사는 경우는 예외다. 그럴 땐 민망하고 자기 과시적인 마케팅 정보를 보게 되지만, 이건 또 다른 이야기다.)
• 유지보수 작업에 보상하라. XFS에서 50줄짜리 버그를 수정하는 작업은 새로운 UI 프레임워크만큼 화려하진 않지만, 급여가 연관돼 있다면 데이터 지속성이 디자인 트렌드보다 훨씬 중요하다.
• 복합적인 동기를 인정하라. “제품 전체가 오픈소스여야 한다”와 같은 이상적인 기준은 경제적 현실을 외면하는 것이다. 중요한 것은 성인(saint)이 되는 것이 아니라, 지속 가능하고 공유하는 혁신이다. 모든 기업, 그리고 사실상 모든 개발자는 어떤 형태로든 자기 이익을 위해 기여한다. 이것은 예외가 아니라 규칙이다. 그러니 받아들여야 한다.

앞으로는 더 의외의 기여자 목록을 보게 될 가능성이 크다. 생성형 AI가 코드 생성을 가속하고 있지만, 여전히 누군가는 그 패치를 통합하고 테스트를 작성하며, 이를 업스트림에 반영해야 한다. 인프라가 불안정해졌을 때 가장 많이 타격을 입는 클라우드 서비스 업체, 데이터베이스 업체, 반도체 제조사 등이 그 노력을 부담하게 될 것이다. 과거부터 그랬듯이 아마 그들은 조용히 그 역할을 수행할 것이다.

결국 우리에게는 선택이 남는다. 결코 사실이거나 합리적이었던 적이 없는 외로운 늑대형 취미 개발자의 낡은 이야기에 매달릴 것인가, 아니면 서버가 멈추지 않도록 유지하는 기업까지 스포트라이트를 넓힐 것인가? 필자는 후자를 택하겠다. 로맨스도 좋지만, 신뢰성이 더 중요하다.

그러니 다음에 apt-get, helm install, docker run을 실행할 때, 그 명령이 성공하도록 만든 패치가 어쩌면 ‘보이지 않는’ 업체로부터 왔을 가능성을 생각하라. 그들의 비즈니스 모델까지 좋아할 필요는 없지만, 그 코드 자체를 인정하지 않을 이유는 없다.
dl-itworldkorea@foundryco.com