---
title: "인공지능 시대 오픈소스 리스크, 이제는 스캔만으로 못 버틴다"
published: 2026-05-19T01:05:03.057Z
canonical: https://jeff.news/article/3036
---
# 인공지능 시대 오픈소스 리스크, 이제는 스캔만으로 못 버틴다

상용 소프트웨어 대부분이 오픈소스에 기대는 상황에서, 취약점과 라이선스, 공급망 규제 리스크를 통제하려면 거버넌스가 필요하다는 기고문이야. 핵심은 이미 들어온 라이브러리를 스캔하는 데서 끝내지 말고, 반입 제어, 내부 포털, 지속 스캐닝, 오픈소스 프로그램 조직까지 묶어 운영하자는 주장임.

- 오픈소스는 이제 “편하게 가져다 쓰는 코드”가 아니라 제품 신뢰도를 좌우하는 공급망 이슈가 됐음
  - 모바일 앱, 금융 서비스, 의료 시스템, 국가 핵심 인프라까지 오픈소스 없이 돌아가는 소프트웨어를 찾기 어려운 수준임
  - 개발 생산성과 혁신 속도를 올려주는 건 맞지만, 어떤 오픈소스를 쓰는지 모르면 사고가 났을 때 영향 범위도 못 잡는다는 게 문제임

- Log4Shell은 그 현실을 제대로 보여준 사건이었음
  - 2021년 Log4Shell 취약점 때 많은 기업이 자기 시스템에 어떤 오픈소스가 들어가 있는지조차 제대로 파악하지 못했음
  - 2025년 React2Shell 사례도 언급됐는데, React를 직접 쓰지 않는 조직까지 복잡한 공급망 때문에 간접 영향을 받을 수 있다는 포인트임
  - 결국 직접 의존성만 보는 시대가 아니라, 전이 의존성까지 따라가야 하는 시대가 된 거임

> [!WARNING]
> 오픈소스 목록을 모르면 취약점이 터졌을 때 “우리도 영향받나?”부터 답을 못 함. 이 단계에서 시간을 잃으면 패치보다 피해 범위 파악이 먼저 병목이 됨.

- 규제 압박도 커지고 있음
  - 유럽연합 사이버복원력법, 미국 SBOM 의무화, 국내 소프트웨어 공급망 보안 가이드라인, 디지털의료제품법까지 언급됨
  - 오픈소스 관리 체계를 입증하지 못하면 시장 진입 자체가 어려워지는 환경이 만들어지고 있음
  - 보안팀만의 선택이 아니라 제품 출시와 사업 확장에 직접 걸리는 문제가 된 셈임

- 글에서 제일 강조하는 출발점은 “반입 제어”임
  - 흔히 오픈소스 거버넌스를 SBOM 생성이나 취약점 스캔부터 떠올리지만, 기고문은 외부 오픈소스가 조직 안으로 들어오는 순간부터 통제해야 한다고 봄
  - 개발자가 외부 공개 저장소에 바로 접근하기 전에 사내 저장소를 거치게 하고, 모든 반입 이력을 남기는 구조가 필요하다는 주장임
  - 라이선스와 취약점 검증을 통과한 컴포넌트만 승인 저장소에 올리고, 개발자 빌드 환경이 그 저장소를 참조하도록 해야 검증 안 된 의존성 유입을 줄일 수 있음

- 내부 오픈소스 포털도 단순 편의 기능이 아님
  - 승인된 오픈소스 목록, 권장 버전, 라이선스 정보를 개발자가 볼 수 있어야 함
  - 새 취약점이 공개되면 영향받는 프로젝트와 권장 패치 버전을 안내할 수 있어야 함
  - 신규 오픈소스 도입 요청과 승인 워크플로도 한곳에서 처리하면, 개발자가 매번 보안팀에 물어보지 않아도 의사결정이 빨라짐

- 반입 이후에는 소프트웨어 개발 생명주기 전체를 봐야 함
  - 도입 당시 안전했던 컴포넌트도 시간이 지나 새 취약점이 나오거나 라이선스 정책이 바뀔 수 있음
  - 그래서 사용 중인 오픈소스 목록을 계속 최신 상태로 유지하고, 신규 취약점 정보를 보유 자산과 매핑하는 프로세스가 필요함
  - 이 접근은 보안을 개발과 운영 흐름 속에 넣는 DevSecOps 원칙과 맞닿아 있음

- 자동화의 핵심은 CI/CD 파이프라인에 SCA 도구를 넣는 것임
  - 코드가 커밋되고 빌드되는 시점마다 의존성을 분석해 SBOM을 만들고 취약점을 검출하도록 구성하는 방식임
  - 다만 자동 스캐닝은 알람을 많이 만들 수 있어서, 중요한 위협을 선별하는 우선순위 정책도 같이 필요함
  - 자동화만 있고 우선순위가 없으면 개발팀 입장에서는 경고 피로만 쌓일 수 있음

- 조직 구조로는 OSPO가 필요하다고 봄
  - OSPO는 오픈소스 정책과 프로세스를 만들고, 기술 인프라를 고르고 운영하며, 경영진에게 리스크와 비즈니스 가치를 함께 전달하는 역할임
  - 개발, 보안, 법무, 사업 부서가 같이 얽히는 주제라 특정 부서 혼자 맡기 어렵다는 지적도 나옴
  - 경영진 차원의 권한 부여가 있어야 실제 의사결정 경로가 조직 전체에 먹힌다는 얘기임

- 인공지능 시대에는 관리 대상이 더 넓어짐
  - 머신러닝 프레임워크, 모델, 학습 데이터까지 오픈소스 형태로 유통되기 때문임
  - 전통적인 취약점, 공급망 위협, AI-BOM 같은 영역까지 거버넌스가 다뤄야 할 범위가 커지고 있음
  - 결국 오픈소스를 얼마나 잘 관리하며 활용하는지가 제품 신뢰도와 기업 경쟁력으로 이어진다는 결론임

---

## 기술 맥락

- 이 글의 핵심 선택은 오픈소스를 “나중에 스캔”하는 방식에서 “처음 들어올 때부터 통제”하는 방식으로 바꾸자는 거예요. 이미 제품 곳곳에 퍼진 뒤에는 어떤 서비스가 영향을 받는지 찾는 비용이 너무 커지거든요.

- SBOM이 중요한 이유도 단순 문서 제출 때문만은 아니에요. 취약점이 공개됐을 때 어떤 버전의 어떤 컴포넌트가 어느 제품에 들어갔는지 알아야 패치 우선순위를 정할 수 있어요. 이 정보가 없으면 대응은 보안 업무가 아니라 수색 작업이 돼요.

- CI/CD에 SCA 도구를 붙이는 건 개발 속도를 막기 위해서가 아니에요. 커밋과 빌드 시점에 의존성 문제를 빨리 발견해야 나중에 릴리스 직전 대형 수정으로 번지지 않거든요. 다만 경고가 너무 많으면 개발자가 무시하게 되니, 위험도 기반 우선순위가 꼭 같이 필요해요.

- OSPO가 필요한 이유는 오픈소스 결정이 기술만의 문제가 아니기 때문이에요. 취약점은 보안팀, 라이선스는 법무, 배포 일정은 개발팀, 제품 책임은 사업팀과 연결돼요. 이걸 한 조직이 조율하지 않으면 정책은 있어도 실제 현장에서는 각자 다른 기준으로 움직이게 돼요.

## 핵심 포인트

- Log4Shell과 React2Shell 사례로 오픈소스 의존성 파악 실패의 위험을 설명
- EU 사이버복원력법, 미국 SBOM 의무화, 국내 공급망 보안 가이드라인 등 규제 압박 증가
- 오픈소스 거버넌스의 출발점은 사용 후 점검이 아니라 반입 제어
- 지속 관리를 위해 CI/CD 파이프라인에 SCA 도구와 SBOM 생성을 통합해야 함
- 개발, 보안, 법무, 사업을 연결하는 OSPO 운영이 실행력의 핵심

## 인사이트

오픈소스 보안은 더 이상 취약점 하나 잡는 업무가 아니라 공급망 운영 체계에 가까워졌어. 특히 인공지능 모델과 데이터까지 오픈소스 형태로 유통되는 시대에는, 개발 편의성과 통제 가능성을 같이 설계하지 않으면 나중에 영향 범위 파악부터 막힐 수 있어.