개발자 노트북 스티커 뒤에 숨겨진 거인들: 조용한 오픈소스 기여의 힘
개발자 컨퍼런스에서 노트북을 장식한 스티커들을 보면 최신 기술 트렌드와 인기 프로젝트들을 한눈에 볼 수 있습니다. 클라우드 네이티브, 데이터베이스, 마스코트 캐릭터 등 개발자들은 스티커를 통해 자신의 정체성을 드러내고 커뮤니티에 대한 소속감을 표현합니다. 하지만 화려한 스티커들 사이에서 간과되는 중요한 사실이 있습니다. 바로 눈에 띄지 않지만, 실제로는 수많은 코드를 기여하는 거대 기업들의 존재입니다.
스티커가 전부가 아니다: 보이지 않는 기여자들
이들 기업은 오픈소스 기여를 마케팅 수단이 아닌 비즈니스의 핵심 기반으로 여깁니다. 수익을 다른 분야에서 창출하기 때문에 굳이 오픈소스를 통해 홍보할 필요가 없는 것입니다. 예를 들어, 오라클은 리눅스 커널 개발에 상당한 기여를 하고 있습니다. 6.1 릴리즈 주기에서는 변경된 코드 라인 수 기준으로 최대 기여 기업이었습니다. 데이터베이스 업계의 스타트업들이 주목받는 동안, 오라클은 리눅스 커널의 메모리 관리 구조를 개선하고 블록 장치 드라이버를 관리하는 데 힘쓰고 있습니다.
지속적인 기여: 오라클과 아마존의 사례
오라클의 커널 작업은 일회성이 아닙니다. 5.18 릴리즈에서도 '커널 중심' 기여 순위 1위를 차지했으며, 이후에도 꾸준히 기여하고 있습니다. 메이플 트리 데이터 구조와 같은 성능 향상 기능들을 커널에 반영하는 데도 기여했습니다. 이러한 패치는 오라클 클라우드 인프라(OCI)를 구동하는 데 사용되지만, 동시에 모든 리눅스 시스템의 성능을 향상시키는 데에도 기여합니다. 아마존 또한 '조용한 오픈소스 혁명'을 통해 깃허브 커밋 로그에 꾸준히 등장하고 있습니다. 과거에는 소극적이었던 아마존이 오픈소스 기여에 적극적으로 참여하게 된 것입니다.
동기가 중요할까? 결과가 말해준다
기업들이 오픈소스에 기여하는 동기는 다양할 수 있습니다. 자사의 이익을 위한 것일 수도 있고, 기술 부채를 줄이기 위한 것일 수도 있습니다. 하지만 중요한 것은 그 결과입니다. 기업의 기여는 커뮤니티에 도움이 되고, 오픈소스 생태계를 더욱 풍요롭게 만듭니다. 매출 증대에 도움이 되기 때문에 기업이 기여하는 구조는 자선적인 기여보다 훨씬 지속 가능합니다. 실제로 리눅스 6.15 커널 기여자 목록에서 변경 세트 기준으로 1위는 인텔입니다. 쿠버네티스 기여 현황에서도 구글, 레드햇, 마이크로소프트, VM웨어, AWS 등이 상위권을 차지하고 있습니다. 이들은 쿠버네티스 서비스를 통해 막대한 수익을 올리고 있기 때문에 기여를 아끼지 않는 것입니다.
간과되는 이유: 스티커, 브랜드, 그리고 헤드라인
그럼에도 불구하고 이러한 기업들의 기여가 간과되는 이유는 무엇일까요? 첫째, 이들은 스티커를 팔지 않습니다. 개발자들의 관심을 끌기 위해 오픈소스를 활용하는 기업들과는 달리, 이들은 굳이 마케팅에 집중하지 않습니다. 둘째, 이들의 브랜드는 '폐쇄적'이라는 인상을 줍니다. 상용 소프트웨어를 판매하는 기업들은 라이선스 요금이나 폐쇄형 클라우드 서비스와 같은 이미지로 인식되기 쉽습니다. 셋째, 수치는 좀처럼 헤드라인에 오르지 않습니다. 화려한 키노트 한 번이 1년간의 풀 리퀘스트를 가려버릴 수 있습니다. 언론 매체도 커널 유지보수 코드 1만 줄보다는 스타트업의 로고 변경 소식을 더 자주 다룹니다.
이익 추구, 결함이 아닌 장점
오픈소스에 대한 기업의 기여는 이익 추구와 연결되어 있기 때문에 종종 비판받기도 합니다. 하지만 이익을 목적으로 한 코드 기여는 자선적인 기여보다 훨씬 지속 가능합니다. 오라클이 리눅스를 최적화하는 이유는 OCI의 매출원가를 낮출 수 있기 때문입니다. AWS가 포스트그레스에 기여하는 이유는 기술 부채를 줄이고 프로젝트 방향에 영향력을 행사할 수 있기 때문입니다. 또한, 대형 업체는 커뮤니티 프로젝트가 감당할 수 없는 자원을 보유하고 있습니다. 암페어 기반 OCI 기여는 퍼블릭 클라우드에서 실제 비용을 청구하는 영역의 빈틈을 메우고, 쿠버네티스 유지관리자는 무료 Arm 용량을 확보하며, 전 세계 개발자는 더 빠른 풀 리퀘스트 워크플로우를 누릴 수 있습니다.
보이지 않는 빌더에게 주목해야 하는 이유
이제 우리는 컨퍼런스 행사장보다 커밋을 봐야 합니다. 데브스탯, 커널 메일링 리스트 통계, 깃허브 API는 거짓말을 하지 않습니다. 이러한 통계 차트에는 우리가 무대에서 박수를 보내는 일은 거의 없는 기업들이 꾸준히 등장합니다. XFS에서 50줄짜리 버그를 수정하는 작업은 새로운 UI 프레임워크만큼 화려하진 않지만, 데이터 지속성을 보장하는 데 훨씬 중요합니다. 우리는 복합적인 동기를 인정하고, 지속 가능하고 공유하는 혁신을 추구해야 합니다. 모든 기업, 그리고 모든 개발자는 어떤 형태로든 자기 이익을 위해 기여합니다. 이것은 예외가 아니라 규칙입니다.
결론
앞으로는 생성형 AI가 코드 생성을 가속화하더라도, 누군가는 그 패치를 통합하고 테스트를 작성하며 업스트림에 반영해야 합니다. 인프라가 불안정해졌을 때 가장 많이 타격을 입는 클라우드 서비스 업체, 데이터베이스 업체, 반도체 제조사 등이 그 노력을 부담하게 될 것입니다. 그러니 다음에 apt-get, helm install, docker run을 실행할 때, 그 명령이 성공하도록 만든 패치가 어쩌면 ‘보이지 않는’ 업체로부터 왔을 가능성을 생각해야 합니다. 그들의 비즈니스 모델까지 좋아할 필요는 없지만, 그 코드 자체를 인정해야 합니다.
