오픈소스 인프라 지속가능성: Maven Central의 변화 신호 🚀

오픈소스 인프라 지속가능성, Maven Central의 변화 신호

 

안녕하세요,

그로메트릭 입니다. 🐸

 

Java 진영에서 라이브러리 하나를 내려받는 순간마다 당연하게 여겨온 Maven Central이, 사실은 전 세계 소프트웨어 딜리버리를 떠받치는 '숨은 인프라'라는 사실 알고 계셨나요? 빌드 도구, 스캐너, CI/CD 파이프라인, 의존성 해석, 자동 배포까지, 우리가 매일 실행하는 빌드 명령 뒤에는 Maven Central이라는 공용 인프라가 조용히 자리하고 있습니다. 평소엔 있는지도 잊고 지내다가, 문제가 생기는 순간에야 모두가 그 존재를 실감하게 되는 인프라이기도 합니다.

 

그런데 최근 소나타입(Sonatype)이 이 인프라의 운영 방식을 근본적으로 재검토하겠다고 예고했습니다. 핵심 문제의식은 '오픈소스 라이선스'와 '커뮤니티 오픈소스'를 같은 것으로 취급해서는 안 된다는 것입니다. 개인 메인테이너가 소소하게 공개하는 라이브러리와, 대기업이 자사 유료 서비스의 SDK·커넥터·통합 툴을 대량으로 퍼블리싱하는 경우는 라이선스는 똑같이 '오픈소스'여도 인프라에 주는 부담과 무게가 전혀 다르다는 지적입니다.

 

이번 글에서는 소나타입이 새롭게 시작한 'Central 시리즈'의 첫 편을 통해, 앞으로 Maven Central 운영 정책이 어떤 방향으로 바뀔 수 있는지, 그리고 이것이 오픈소스를 소비하는 기업과 개발팀의 공급망 전략에 어떤 의미를 갖는지 살펴보겠습니다.

 

*아래 글은 소나타입(Sonatype)의 공식 블로그 글을 번역하여 작성되었습니다.

 

---

Maven Central: 잘 작동하는 인프라는 눈에 띄지 않는다

인프라는 원래 그런 존재입니다. 잘 돌아갈 때는 아무도 신경 쓰지 않고, 심지어 존재 자체를 잊어버리기도 합니다. 그러다 멈추는 순간, 모두가 동시에 알아차립니다.
빌드, 스캐너, CI 시스템, 의존성 해석, 자동 퍼블리싱, 일시적으로 생성됐다 사라지는 환경, 기계 간 워크플로우까지 — 이 모든 것이 '항상 사용 가능하고, 빠르고, 신뢰할 수 있고, 이상적으로는 지루할 만큼 평범한' 인프라에 의존하고 있습니다.

소나타입의 공동 창업자이자 CTO이며 Maven Central의 스튜어드(steward)이기도 한 브라이언 폭스(Brian Fox)는 최근 오픈소스 인프라의 지속가능성을 주제로 여러 글을 써왔습니다. 그는 Maven Central이 더 이상 메인테이너가 라이브러리를 올리고 개발자가 내려받는 단순한 공간이 아니라, 이제는 현대 소프트웨어 딜리버리의 핵심 경로(critical path) 그 자체가 되었다고 짚은 바 있습니다.

이번 글은 앞으로 정기적으로 이어질 'Central 팀' 시리즈의 첫 번째 편입니다. 이 시리즈를 통해 소나타입은 Central을 장기적으로 지속 가능하게 만들기 위해 고민하고 있는 실무적인 판단과 트레이드오프, 그리고 그 과정에서 발견한 다소 뜻밖의 사실들까지 공유할 예정입니다. 진행 상황을 알리는 것뿐 아니라, 명확하지 않은 부분도 솔직하게 설명하겠다는 취지입니다. 그리고 한 가지는 미리 분명히 해둡니다. Maven Central은 커뮤니티 오픈소스에 한해서는 앞으로도 계속 무료입니다.

 

Maven Central이 원래 의도했던 바

Central의 존재 이유는 단순합니다. Java 생태계의 컴포넌트를 널리 이용할 수 있게 만드는 것. 이 모델은 지금까지 매우 성공적으로 작동해 왔습니다. 메인테이너가 릴리스를 퍼블리싱하면, 개발자는 이를 가져다 쓰고, 빌드 도구는 어디서 그것을 찾아야 하는지 알고 있습니다. 생태계 전체가 신뢰할 수 있는 하나의 공용 배포 지점 덕분에 이득을 봐온 셈입니다.

문제는 그 배포 지점을 둘러싼 세상이 달라졌다는 데 있습니다. 남는 방에서 라이브러리 하나를 퍼블리싱하는 개인 메인테이너를 지원하던 바로 그 인프라를, 이제는 대형 조직들이 SDK, 에이전트, 자동 생성된 클라이언트, 커넥터, 프레임워크, 내부 시스템과 맞닿은 도구, 상업 서비스용 통합 레이어까지 대량으로 배포하는 데 함께 사용하고 있습니다.

물론 이런 아티팩트들이 쓸모없다는 뜻은 전혀 아닙니다. 상당수는 실제로 오픈소스이며, 널리 채택되고, 개발자의 삶을 편하게 만들어 줍니다. 문제는 이들의 존재 여부가 아니라, "모든 종류의 오픈소스 퍼블리싱이 과연 커뮤니티 인프라와 동일한 관계를 맺고 있는가"라는 질문입니다. 소나타입의 결론은 '아니다'입니다.

 

오픈소스 코드라고 해서 모두 '커뮤니티 오픈소스'는 아니다

이 논의에서 흔히 빠지는 함정 중 하나는 '오픈소스'라는 단어를 마치 하나의 균일한 개념처럼 다루는 것입니다. 실제로는 그렇지 않습니다.
라이선스 관점에서는 오픈소스일 수 있습니다. 소스가 공개돼 있고, OSI 승인 라이선스를 따르며, 외부 기여도 가능할 수 있습니다. 이 모든 요소가 중요하긴 하지만, 그 프로젝트가 왜 존재하는지, 주로 누가 이익을 보는지, 어떤 수준의 인프라 책임이 뒤따라야 하는지까지 설명해 주지는 않습니다.

예를 들어 유료 서비스의 SDK를 생각해 보겠습니다. 이 SDK는 오픈소스일 수 있고, 그 자체는 좋은 일입니다. 개발자는 코드를 들여다보고, 디버깅하고, 포크하고, 개선하고, 서비스와 어떻게 상호작용하는지 이해할 수 있습니다. 실질적인 이점이죠. 하지만 이 SDK는 동시에 상업 플랫폼을 더 쉽게 소비하도록 만들기 위해 존재하는 것이기도 합니다. 그렇다고 이것이 '오픈소스가 아니다'라거나 개발자에게 가치가 없다는 뜻은 아닙니다.

다만, 이런 프로젝트는 범용 문제를 풀기 위해 커뮤니티가 함께 유지보수하는 라이브러리와는 지형도상 조금 다른 위치에 있습니다. 두 경우 모두 같은 라이선스를 쓰고, 같은 Central에 퍼블리싱되고, 둘 다 유용할 수 있습니다. 하지만 인프라를 관리하는 입장에서 보면 이 둘은 결코 동일하지 않습니다.

 

라벨만으로는 판단할 수 없는 이유

앞으로 소나타입이 풀어야 할 과제 중 상당 부분은 지나치게 단순한 분류를 피하는 데 있습니다. "오픈소스는 선(善), 상업적인 것은 악(惡)"이라는 프레임은 유용하지 않으며, 소나타입이 채택할 프레임도 아닙니다. 상업 조직들은 오픈소스에 막대한 기여를 해왔고, 상업적 배경을 가진 많은 프로젝트가 생태계 전체에 상당한 가치를 제공하고 있습니다.

반대로 "라이선스가 오픈소스이니 다른 맥락은 무관하다"는 시각도 지나치게 단순합니다. 이는 지금 Central이 운영되고 있는 규모의 현실적인 운영 부담을 무시하는 관점입니다.

 

실제 현실은 다음과 같이 더 복잡하고 미묘합니다.

• 커뮤니티 프로젝트도 특이한 퍼블리싱 패턴을 보일 수 있지만, 그 자체가 서비스 남용은 아닙니다.
• 상업용 SDK도 생태계에 막대한 가치를 제공할 수 있습니다.
• 자동화된 퍼블리싱은 개별 조직 입장에서는 합리적이어도, 전체 인프라 관점에서는 글로벌 비용을 유발할 수 있습니다.

즉, 하나의 컴포넌트가 오픈소스이면서, 유용하면서, 동시에 상업적 배포 전략의 일부일 수 있다는 것이며, 이는 전혀 모순이 아닙니다. 단지 라벨이 아니라 패턴과 맥락을 함께 봐야 한다는 뜻입니다.

 

Maven Central은 스테이징 저장소가 아니다

가장 명확하면서도 실용적인 원칙 하나는 이것입니다. Central은 '릴리스 준비가 끝난' 아티팩트를 공개 배포하기 위한 곳이라는 점.
모든 빌드 산출물, 모든 CI 실행 결과, 모든 내부 전용 컴포넌트, 기술적으로 퍼블리싱이 가능하다는 이유만으로 생성된 모든 아티팩트의 기본 목적지가 되어서는 안 됩니다. 퍼블리싱은 운영 관점에서 결코 공짜가 아니기 때문입니다. 모든 아티팩트는 저장돼야 하고, 메타데이터는 처리돼야 하고, 인덱스는 업데이트돼야 하고, 어뷰징은 관리돼야 하고, 복제(replication)는 수행돼야 하고, 지원 문의에는 응답해야 합니다. 그리고 이 모든 것이 다른 모든 사용자를 위해서도 안정적으로 유지돼야 합니다.

작은 규모에서는 이런 비용이 거의 눈에 띄지 않습니다. 하지만 전 세계적 규모에서는 이 비용 자체가 곧 업무가 됩니다. 

대부분의 부담은 악의적인 행위 때문이 아니라, 개별적으로는 합리적인 결정들이 자동화를 통해 반복되고 전 세계적 규모로 확대되면서 발생합니다. 문제는 공용 인프라가 이런 결정들을 '합산된 형태로' 마주하게 된다는 데 있습니다.

 

이 시리즈를 시작하는 이유

앞으로 Central 팀은 이런 문제들을 어떻게 풀어가고 있는지 더 자세히 공유할 예정입니다. 일부는 기술적인 내용이고, 일부는 운영 관점, 일부는 정책·제한·예외·툴링·워크플로우, 그리고 불균형한 부하를 만들어내는 패턴들에 대한 이야기가 될 것입니다.

투명하되 불필요하게 위기감을 조성하지 않고, 실용적이되 단순화하지 않는 방식으로 소통하겠다는 것이 원칙입니다. 무엇보다 '무엇을' 바꾸는지뿐 아니라 '왜' 바꾸는지를 설명하는 데 집중하겠다고 밝히고 있습니다. 매일 의존하는 인프라가 바뀔 때 사람들이 불안을 느끼는 것은 당연한 일이며, 이를 해소하는 최선의 방법은 막연한 안심의 말이 아니라 의도와 영향, 그리고 배운 점에 대한 명확한 커뮤니케이션이라는 겁니다.

 

소나타입이 지금 따르고 있는 원칙은 명료합니다.

커뮤니티 오픈소스에 대해서는 Central을 계속 개방적이고 무료로 유지하되,

상업적 또는 인프라 규모로 사용하는 패턴에 대해서는 더 명시적이고 지속 가능한 방식을 적용하겠다는 것입니다.

 

이는 오픈소스를 축소하려는 시도가 아니라, 우리 모두가 의존하는 생태계를 계속 지탱할 수 있을 만큼 그 뒤편의 인프라를 건강하게 유지하기 위한 조치라고 강조합니다.

 

개방은 설계에 따른 것이지, 단순히 포화 상태에 이르러서가 아닙니다.

지속 가능한 인프라가 있어야 오픈소스도 계속 열려 있을 수 있습니다. 하지만 그 인프라는 누군가는 항상 신경 써서 지켜보고 있어야 하는 대상이기도 합니다. 불을 계속 켜두고, 어뷰징에 대응하고, 성장 곡선을 관찰하고, 자동화가 오작동할 때 대응하고, 다음 빌드가 여전히 정상적으로 돌아가도록 만드는 일 말입니다.

 

앞으로의 과제는 이런 관리 업무를 Central 본연의 역할을 해치지 않으면서도 충분히 가시화해 지속 가능하게 만드는 것입니다. 커뮤니티 오픈소스는 앞으로도 자리를 지켜야 하고, 개발자는 계속 만들어야 하고, 메인테이너는 계속 퍼블리싱해야 합니다. 그리고 Central이 상업적 규모의 소프트웨어 딜리버리 모델의 일부로 사용되는 경우, 그 사용 역시 공용 인프라에 대한 실질적인 의존으로 이해돼야 한다는 것이 소나타입의 입장입니다.

 

오픈소스도, 오픈 인프라도 결코 단순하지 않습니다.

이번 시리즈는 그 복잡한 맥락을 공개적으로 함께 풀어가면서, 우리 모두가 의존하고 있는 Central을 계속 지속 가능하게 지켜나가기 위한 소나타입의 첫걸음입니다.

---

출처

소나타입 블로그 : Open Source, Open Infrastructure, and the Space Between