---
title: "스패로우가 본 AI 코딩 시대의 공급망 보안, SBOM 범위가 더 넓어져야 함"
published: 2026-06-13T05:05:07.537Z
canonical: https://jeff.news/article/4118
---
# 스패로우가 본 AI 코딩 시대의 공급망 보안, SBOM 범위가 더 넓어져야 함

스패로우가 연례 행사 SAI 2026에서 오픈소스와 AI 코딩이 섞인 개발 환경의 공급망 보안 전략을 제시했다. 핵심은 소스코드와 패키지뿐 아니라 AI 모델과 AI 생성 코드까지 추적 가능한 SBOM 체계로 확장해야 한다는 것이다.

## AI 코딩이 공급망 보안의 판을 키우는 중

- 스패로우가 연례 고객 행사 SAI 2026에서 던진 주제는 꽤 현실적임. AI 코딩과 오픈소스가 섞인 개발 환경에서 공급망 보안을 어떻게 할 거냐는 문제임
  - 행사는 6월 11일 서울 용산에서 열렸고, 주제는 AI 혁신으로 완성하는 소프트웨어 공급망 보안이었음
  - 국내 주요 기업과 기관의 IT, 보안 리더와 실무자가 참석한 행사였음
  - 기존 PUC라는 이름을 SAI로 바꾸고 애플리케이션 보안 전반의 인사이트를 제공하겠다는 방향을 잡음

- 공급망보안연구회 이만희 위원장은 규제와 공격 표면이 동시에 커지고 있다고 봄
  - 글로벌 공급망 규제가 빠르게 바뀌고 있고, 기술 발전으로 공격 표면도 더 다양해졌다는 설명임
  - 클로드 미토스(Claude Mythos) 같은 최신 AI 모델 사례를 언급하면서 취약점 발견 속도가 빨라졌다고 짚음
  - 결론은 보안 가시성과 개발 전주기 자동화 보안 테스트가 필수라는 쪽임

> [!IMPORTANT]
> AI가 취약점을 더 빨리 찾는다는 건 방어자에게도 기회지만, 공격자에게도 똑같이 속도 보너스를 준다는 뜻임.

## SBOM도 AI 시대에 맞게 확장해야 함

- 장일수 스패로우 대표가 강조한 핵심은 SBOM의 범위 확장임
  - 지금 개발 환경은 생성형 AI가 만든 코드와 수많은 오픈소스 패키지가 뒤섞여 있음
  - 이 상태에서 가시성이 부족하면 라이선스 리스크, 취약점 대응 지연, 관리 사각지대가 생김
  - 그래서 소프트웨어 자재명세서(SBOM)가 AI 모델과 AI 생성 코드까지 추적해야 한다는 주장임

- 단순히 목록을 만드는 것만으로는 부족하다는 점도 짚음
  - 생성된 SBOM에 디지털 서명을 추가해 무결성을 검증해야 함
  - 공급사와 수요사가 SBOM을 어떻게 주고받는지도 시각화해야 함
  - 결국 신뢰 가능한 공급망 생태계를 만들려면 추적, 검증, 관계 파악이 같이 가야 한다는 얘기임

## 스패로우 MCP는 코드 생성 시점에 보안을 붙이려는 시도

- 흥미로운 부분은 스패로우 MCP(Model Context Protocol)임
  - 바이브 코딩(Vibe Coding)이 퍼지면서 개발자가 AI로 코드를 바로 생성하는 흐름이 빨라지고 있음
  - 문제는 생성형 AI가 안전하지 않은 코드를 만들 수 있다는 점임
  - 스패로우 MCP는 코드 생성 시점부터 보안 검증을 수행하는 방식으로 이 문제를 줄이려 함

- 개발 흐름을 끊지 않는다는 점이 포인트임
  - 보안 검사가 느리거나 번거로우면 개발자는 우회하기 마련임
  - 스패로우는 MCP를 통해 개발 흐름은 유지하면서 코드 안전성을 확보하겠다고 설명함
  - 이 제품은 조만간 정식 출시될 예정임

> [!TIP]
> AI 코딩 도입을 고민하는 팀이라면 생성된 코드의 품질만 볼 게 아니라, 누가 어떤 모델로 어떤 의존성을 끌어왔는지 추적하는 체계를 같이 설계해야 함.

- 스패로우는 이 흐름을 자기 제품 포트폴리오와 연결하고 있음
  - 회사는 국내 애플리케이션 보안 테스팅 부문 공공 시장 점유율 1위라고 소개됨
  - 소스코드 보안약점 분석, 웹 취약점 분석, 소프트웨어 구성요소 분석 같은 도구를 제공함
  - 구축형, 클라우드형, API형을 조직 환경에 맞게 선택할 수 있다는 점도 강조함

---

## 기술 맥락

- SBOM이 다시 중요해지는 이유는 오픈소스만 추적해서는 부족해졌기 때문이에요. 예전에는 어떤 라이브러리를 썼는지가 핵심이었다면, 이제는 AI가 만든 코드가 어떤 모델과 맥락에서 나왔는지도 보안 리스크가 되거든요.

- 디지털 서명이 붙은 SBOM은 단순한 문서가 아니라 검증 가능한 증거에 가까워요. 공급사가 보낸 구성요소 목록이 중간에 바뀌지 않았는지 확인할 수 있어야, 사고가 났을 때 책임 소재와 영향 범위를 더 빨리 좁힐 수 있어요.

- 스패로우 MCP의 방향은 보안 검사를 개발 마지막 단계에 몰아넣지 않는 거예요. AI가 코드를 생성하는 순간에 검증을 붙이면, 취약한 코드가 저장소나 배포 파이프라인까지 흘러가기 전에 잡을 수 있거든요.

- 이 접근이 DevSecOps와 맞물리는 이유도 여기에 있어요. AI 코딩으로 개발 속도가 빨라질수록 수동 리뷰만으로는 따라가기 어렵고, 자동화된 보안 테스트와 추적 체계가 개발 흐름 안에 들어와야 해요.

## 핵심 포인트

- 생성형 AI 코딩과 오픈소스 패키지 사용이 늘면서 가시성 부족, 라이선스 리스크, 취약점 대응 지연이 커지고 있음
- 스패로우는 AI 모델과 AI 생성 코드까지 포함하는 확장된 SBOM 관리를 강조함
- SBOM에 디지털 서명을 붙여 무결성을 검증하고 공급사와 수요사 관계를 시각화해야 한다고 제안함
- 스패로우 MCP는 코드 생성 시점부터 보안 검증을 수행해 개발 흐름을 유지하면서 취약 코드를 줄이려는 접근임

## 인사이트

AI 코딩 도구가 개발 속도를 올려주는 건 맞지만, 그 코드가 어디서 왔고 어떤 위험을 품는지 추적하지 못하면 공급망 보안은 더 어려워짐. 이제 보안팀의 질문은 코드가 안전한가에서 이 코드가 어떤 모델과 맥락에서 나왔는가로 넓어지는 중임.