마이크로서비스 전환 후폭풍 : 오픈소스 라이선스, 이제는 인프라 문제다
- 신동명 연구소장(엘에스웨어)
오픈소스를 활용한 마이크로서비스 아키텍처(MSA)가 대세로 자리 잡으면서 대기업이든 스타트업이든 업데이트된 컨테이너 이미지를 하루에도 수십 차례 배포하는 환경이 일상이 됐다. 마이크로서비스 아키텍처를 채택함으로써 개발 조직은 민첩성과 확장성을 얻었지만, 개발자가 인식하지 못하는 부분에서 오픈소스 라이선스 의무가 세분화·은폐되는 새로운 공급망 리스크가 빠르게 커지고 있다. 레벨블루(LevelBlue) 보고서 등에서 “우리 소프트웨어 공급망을 완전히 파악한다”는 기업이 4분의 1에도 못 미친다는 조사 결과가 반복되는 이유 중 하나가 MSA 채택에 있다.
MSA는 기능을 잘게 분할해 각각을 독립 프로세스로 실행하고, 서비스 간 통신은 API·gRPC·메시지 큐 등 네트워크 호출로 처리한다. 서비스마다 배포 주기와 언어·프레임워크가 달라 운영팀은 거의 실시간으로 서로 다른 소프트웨어와 이미지를 다루게 된다. 단일 모놀리식 애플리케이션에서 사용되던 “프로젝트 단위 식별표” 중심의 거버넌스는 MSA와 같은 분산 구조를 제대로 다룰 수 없다.
MSA에서 발생하는 소프트웨어 라이선스 문제의 본질은 ‘보이지 않는 확장’이다. 개발자는 한 줄의 코드도 고치지 않았어도 베이스 이미지를 ‘업데이트’ 하면 수백 종의 오픈소스가 새로 포함될 수 있다. IBM이 공개한 SBOM 2만 5천 개를 검증해본 결과, 상당수가 라이선스·저작권·빌드 옵션 정보를 누락해 “신뢰할 수 없는 SBOM”으로 분류됐다. 현 단계에서는 SBOM만으로는 모든 문제를 쉽게 해결하기 어렵다.
가장 빈번한 사고 지점은 컨테이너 베이스 이미지 레이어다. Ubuntu 또는 알파인 이미지, 그리고 그 위에 구축된 애플리케이션 레이어의 소프트웨어를 사용할 때, 그 소프트웨어의 라이선스 의무가 상위 서비스로 전파될 수 있다. 컨테이너 격리가 기술적 보호막을 제공하더라도, 라이선스에 대한 격리·보호를 제공하는 것이 아니기 때문이다.
네트워크 경계도 안전지대가 아니다. AGPL·SSPL처럼 “서비스 형태 제공”에 소스 공개를 요구하는 라이선스는 서비스 간 호출이 단순 원격 호출인지, 사실상 결합인지 여부를 따진다. gRPC 스트림이나 서비스 Mesh와 같이 긴밀한 프로토콜을 사용하면 라이선스 전파 범위가 코드 수준을 넘어 데이터 모델과 API 계약까지 확장될 소지가 있다고 주장하는 경우도 있다. 여기에 쿠버네티스와 같은 오토스케일링 기능이 더해지면, 스케일‑아웃된 수백 개 인스턴스마다 LICENSE NOTICE를 제공해야 한다는 고지 의무를 지적하는 주장도 있다.
운영 환경에서 흔히 발생하는 컨테이너 드리프트는 가장 발견하기 어려운 복병이다. 프로덕션에서 패키지를 교체하거나 사이드카를 추가하면 빌드 시점에서 작성된 SBOM은 즉시 의미가 없어지지만, 프로덕션 환경에서 SBOM을 재생성·검증해보기 전에는 아무도 변경 사실을 알지 못한다. IaC 템플릿 역시 예외가 아니다. Terraform이 BUSL로 전환한 사례처럼, 인프라 스크립트조차 독자·제한적 라이선스 문제를 일으킬 수 있어, 라이선스 충돌이 “배포 정의 파일”에서 시작되기도 한다.
이러한 MSA 환경에서 발생할 수 있는 라이선스 문제를 자동화로 해결하고자 하는 움직임은 많이 있다. Trivy·Syft·Grype는 이미지의 모든 파일과 OS 패키지를 스캔해 금지·제한·통지 등급으로 분류하고, Snyk는 라이선스 위반을 일반 보안 취약점과 동일하게 게이트키핑 대상으로 취급한다. 덕분에 개발 파이프라인 안에서 “라이선스 충돌 검출→빌드 실패”에 대한 아이디어가 제시되고 있다. OPA(Rego), Gatekeeper, Kyverno와 같은 Policy‑as‑Code 도구는 PR·CI 단계에서 금지 라이선스 이미지를 자동 차단해 “코드 리뷰 속 라이선스 정책 집행”을 가능케 한다.
올해 OpenSSF에서 발표한 GUAC 1.0은 MSA를 구성하는 모든 소프트웨어의 SBOM을 그래프 데이터베이스에 통합해 패키지 간 라이선스·취약점 관계를 질의 형태로 보여 준다. 다만, 어디까지나 구성 소프트웨어의 존재에 기반한 검사이고, 처음에 언급한 것과 같은 gRPC 스트림 등 실제 서비스 환경에서만 파악할 수 있는 네트워크 연결에 의해서 발생할 수 있는 라이선스 충돌 문제는 발견하기 힘들다. 현재 이를 발전시켜 API 의존성·데이터 흐름까지 포함한 ‘Service BOM’ 표준을 논의 중이다.
표준화 움직임도 빨라지고 있다. SLSA는 빌드·배포 체인의 신뢰 단계를 1~4로 구분해 SBOM 무결성과 서명 체계를 요구하고, NIST SSDF는 SDLC 전 과정에 오픈소스 관리 활동을 내재화했다. OpenChain은 2024년 ‘Telco SBOM 가이드’를 발표해 업계 공급망 전반의 최소 품질 기준을 제시했다. 이러한 프레임워크는 조직이 자체 정책을 수립할 때 바로 가져다 쓸 수 있는 실질적 레퍼런스를 제공한다.
결국 MSA를 채택한 조직이 취할 현실적 전략은 세 단계로 요약된다. 첫째, 모든 이미지 레이어·IaC·스크립트를 SBOM으로 식별해 중앙 레지스트리에 수집할 것. 둘째,OPA / Kyverno / Gatekeeper 게이트를 활용해 라이선스 위반 가능성이 있는 이미지를 배포 파이프라인에서 차단할 것. 셋째, GUAC 같은 지식그래프와 런타임 스캐너로 드리프트를 실시간 탐지·시각화할 것.
MSA 시대의 라이선스 관리는 더 이상 체크리스트가 아닌 데이터 파이프라인이다. 투명성을 초기 비용이 아닌 장기적 신뢰 자본으로 인식하고, 자동화된 SBOM 수집·검증 체계를 도입한 조직만이 빠른 배포라는 MSA의 핵심 가치를 저작권 위반 위험 없이 지속적으로 누릴 수 있다.
