브로드컴 TrueSource, 오픈소스 보안에 ‘AI보다 사람의 검증’ 내세웠다

브로드컴이 기업용 오픈소스 보안을 겨냥한 새 포트폴리오 TrueSource by Broadcom을 공개했다. 2026년 8월 31일 미국 라스베이거스에서 열린 VMware Explore 2026에서 발표된 TrueSource는 검증 가능한 방식으로 빌드된 오픈소스 소프트웨어에 상용 지원을 결합한 제품군이다. Spring 생태계뿐 아니라 주요 언어용 소프트웨어 아티팩트, 컨테이너 이미지, 데이터 엔진까지 하나의 보안·지원 전략으로 묶었다. 13

핵심 메시지는 분명하다. AI는 취약점을 찾고 패치 초안을 만드는 데 도움을 줄 수 있지만, 코드와 빌드 과정, 실제 운영 환경에 미칠 영향까지 확인해 프로덕션 배포를 승인하는 주체는 여전히 책임 있는 엔지니어여야 한다는 것이다.

TrueSource는 무엇을 제공하나

TrueSource는 세 가지 상용 지원 제품으로 구성된다.

1. Spring Enterprise

Spring Enterprise는 Spring 생태계를 사용하는 기업을 위한 제품이다. Spring을 개발하고 유지 관리하는 팀이 선별한 릴리스를 제공하며, 사전 의존성 검사, 사람이 검증한 패치, 지원되는 릴리스 라인 전반의 조정된 보안 수정 사항을 포함한다. 13

Spring 기반 애플리케이션은 직접 추가한 라이브러리뿐 아니라 여러 단계로 연결된 전이 의존성에도 의존하는 경우가 많다. 브로드컴은 각 취약점을 개별 패키지 업데이트로 처리하기보다, 업스트림 생태계와 연결된 릴리스 관리 및 대응 서비스로 Spring Enterprise를 포지셔닝하고 있다.

2. TrueSource Trusted Artifacts

TrueSource Trusted Artifacts는 Spring 밖으로 범위를 넓힌 제품이다. 브로드컴에 따르면 이 서비스는 5,000개가 넘는 검증된 Java 라이브러리에 대해 클린룸 환경에서 빌드한 SLSA Build Level 3 아티팩트를 제공한다. Java 생태계 전반과 Python, Node.js에 대한 지원도 포함되며, 정확한 Spring Boot 버전 정렬과 강화된 Bitnami 컨테이너 이미지도 제공한다. 13

SLSA는 소프트웨어가 어디에서 어떤 과정을 거쳐 빌드됐는지 추적하고 검증하기 위한 공급망 보안 프레임워크다. 기업의 플랫폼·보안팀 입장에서 이 제품의 핵심 가치는 출처와 일관성에 있다. 통제된 환경에서 빌드하고 지원되는 소프트웨어 버전에 맞춰 관리함으로써, 여러 출처에서 검증되지 않은 의존성을 가져오는 위험을 줄이겠다는 접근이다.

3. TrueSource Data Services

TrueSource Data Services는 널리 사용되는 네 가지 데이터 엔진인 PostgreSQL, RabbitMQ, MySQL, Valkey를 대상으로 한다. 브로드컴은 신뢰할 수 있는 아티팩트와 상용 지원, 배포 전문성, 자동화, 보안 상태와 노출 현황을 확인할 수 있는 대시보드 기능을 결합한다고 설명했다. 13

따라서 TrueSource는 단순한 라이브러리 취약점 관리 제품보다 범위가 넓다. 기업 환경에서 오픈소스 데이터 인프라를 배포하고 업데이트하며 지속적으로 모니터링해야 하는 운영 부담까지 겨냥한다.

라이선스는 어떻게 적용되나

TrueSource 제품군은 단계별 사이트 라이선스 옵션으로 제공된다. 브로드컴의 설명에 따르면 상용 모델은 기존 오픈소스 라이선스를 바꾸는 것이 아니라, 그 위에 기술 지원, 빌드 검증, 취약점 대응, 운영 전문성을 더하는 방식이다. 적절한 라이선스를 보유한 고객은 공개되지 않은 일부 취약점에 대해서도 브로드컴에 전달하고 조기 대응 지원을 받을 수 있다. 13

즉 기업이 비용을 지불하는 대상은 커뮤니티가 만든 오픈소스 코드 자체의 소유권이라기보다, 해당 소프트웨어를 검증하고 유지 관리하며 문제 발생 시 책임 있게 지원하는 수명주기 서비스에 가깝다.

Spring 보안 공지 급증이 보여주는 공급망 부담

브로드컴은 애플리케이션 내부의 의존성, 컨테이너, 데이터 서비스까지 보호해야 하는 기업의 부담이 커지고 있다는 점을 TrueSource의 배경으로 제시했다. 특히 Spring 사용자가 처리해야 할 업무량을 보여주는 사례로 월간 Spring 보안 권고가 1,700% 넘게 증가했다는 수치를 언급했다. 3

브로드컴이 제시한 대응 방식은 여러 보안 계층을 결합한다.

• 엔지니어가 선별한 구성 요소와 릴리스
• 클린룸 환경에서의 검증 가능한 빌드
• 저장소와 취약점 영향 범위를 분석하는 자동화 기능
• 패치 제안 풀 리퀘스트
• 고립된 수정이 아닌 업스트림 프로젝트에 대한 기여
• 해결된 노출과 남은 노출을 보여주는 대시보드 13

목표는 단순히 패치를 가장 빨리 만들어내는 데 있지 않다. 어떤 경로에서 취약점이 사용되는지 파악하고, 위험이 낮은 대응 방법을 선택한 뒤, 결과를 검증하고, 프로젝트를 책임지는 유지 관리자와 수정 사항을 연결하는 것이 브로드컴이 강조하는 방식이다.

AI 패치에도 사람의 검증이 필요한 이유

브로드컴은 AI를 활용한 보안 작업 자체를 부정하지 않는다. 대신 AI를 분석을 빠르게 하는 도구로 사용할 것인지, 아니면 검토되지 않은 생성 코드를 프로덕션 패치로 바로 배포할 것인지 사이에 선을 긋고 있다.

브로드컴은 1Password의 Off-by-1 Labs가 수행한 테스트를 인용하며, AI가 생성한 패치 6,000개 가운데 취약점을 해결하면서 애플리케이션을 망가뜨리지 않은 패치는 26%에 불과했다고 밝혔다. 3 또한 Spring 분석을 위해 5개월 동안 120억 개가 넘는 프런티어 모델 토큰을 사용했지만, 제안된 모든 수정 사항은 엔지니어가 수동으로 검토했다고 설명했다. 3

브로드컴이 내세우는 운영 원칙은 다음과 같이 요약된다.

AI가 유지 관리를 돕고, 사람이 수정 사항을 승인한다.

AI 모델은 대규모 의존성 그래프를 살펴보고, 취약한 코드 경로를 찾고, 변경안을 제안하는 데 유용하다. 그러나 엔지니어는 호환성, 성능, 실제 악용 가능성, 회귀 위험, 최종 릴리스 아티팩트의 정확성까지 확인해야 한다. 3

AI로 만든 포크가 안고 있는 장기 위험

브로드컴이 우려하는 것은 AI로 생성한 포크가 당장의 취약점을 해결하더라도 장기적인 유지 관리 문제를 만들 수 있다는 점이다. 포크가 계속 관리되지 않으면 업스트림 프로젝트와 차이가 벌어지고, 이후 공개되는 보안 수정 사항을 놓칠 수 있다. 사용자는 그 아티팩트에 누가 책임을 지는지도 알기 어려워진다. 23

TrueSource는 이와 반대되는 모델을 지향한다. 프로젝트 유지 관리자와 협력하고, 적절한 경우 수정 사항을 업스트림에 반영하며, 아티팩트가 어떤 방식으로 빌드됐는지 검증하고, 결과물에 대해 상용 지원 주체를 제공하는 방식이다. 13

기업 구매자에게 이 차이는 중요하다. AI는 취약점을 조사하고 패치를 준비하는 시간을 줄일 수 있지만, 그 자체로 소프트웨어의 출처, 호환성, 장기적인 관리 주체, 패치로 인해 장애가 발생했을 때의 책임을 보장하지는 않기 때문이다.

기업 IT팀에는 어떤 의미인가

TrueSource의 세 갈래 구성은 팀별로 비교적 명확한 도입 지점을 제시한다.

• Spring을 사용하는 개발팀은 Spring Enterprise를 통해 선별된 릴리스와 보안 지원을 받을 수 있다.
• 플랫폼·애플리케이션 보안팀은 Trusted Artifacts를 통해 주요 언어 생태계의 검증된 아티팩트와 강화된 컨테이너 이미지를 활용할 수 있다.
• 인프라팀은 Data Services를 통해 PostgreSQL, RabbitMQ, MySQL, Valkey에 대한 지원 배포판, 자동화, 보안 가시성을 확보할 수 있다. 13

결국 브로드컴은 오픈소스 위에 관리형 신뢰 계층을 판매하려는 것으로 볼 수 있다. 회사가 제시한 논지는 기업용 오픈소스에 소스 코드에 접근할 권리만 필요한 것이 아니라는 것이다. 검증 가능한 빌드, 프로젝트 유지 관리자의 참여, 테스트된 대응책, 그리고 결과물에 책임을 질 수 있는 지원 관계가 함께 필요하다는 뜻이다.

제공된 보도 자료에는 IDC의 케이티 노턴이 한 직접 인용문이 포함돼 있지 않으므로, 그녀가 이 사안을 어떻게 규정했는지 구체적으로 확인할 수는 없다. 다만 제공된 근거는 브로드컴의 broader한 주장, 즉 AI는 소프트웨어 유지 관리의 생산성을 높이는 수단이 될 수 있지만 프로덕션 보안 의사결정의 최종 통제 지점은 사람의 엔지니어링 판단이어야 한다는 결론을 뒷받침한다. 3