스패로우가 본 공급망 보안 “SBOM 유통과 통합관리로”
[인터뷰] 장일수 스패로우 대표
“소프트웨어 자재명세서(SBOM)를 생성해 전달하는 것만으로 공급망 보안은 끝나지 않는다. 다음 승부처는 살아 있는 SBOM 유통과 공급망 보안 통합관리에 있다.”
오픈소스와 생성형 인공지능(AI) 확산으로 소프트웨어 공급망 보안이 단순 점검 항목을 넘어 기업 운영의 핵심 과제로 옮겨가고 있는 가운데, 애플리케이션 보안 전문 기업 스패로우의 장일수 대표는 바이라인네트워크와 인터뷰에서 이같이 강조했다.
장 대표는 현대정보기술과 파수의 사업본부장을 거쳐 2018년 파수에서 분사한 스패로우를 이끌고 있다. 지난달에는 한국오픈소스협회 17대 협회장으로 선출됐다.
먼저 장 대표는 국내 시장이 아직 공급망 보안을 너무 좁게 보고 있다고 지적했다. SBOM를 만들고, 오픈소스 목록을 정리해 제출하면 대응이 끝나는 것처럼 보는 시각이 많지만, 실제 위험은 그보다 넓다. 기업이 직접 짠 코드에도 취약점이 있을 수 있고, 운영 단계의 웹 애플리케이션에도 문제가 생길 수 있다.
장 대표는 “오픈소스 목록만 알고 대응하면 되냐, 그것도 아니다”라며 “수요자가 공급자에게 받은 소프트웨어 전체가 무결해야 진짜 공급망 보안”이라고 말했다.
‘SBOM 제출’에 머문 시장, 더 나아가야
장일수 대표는 공급망 보안을 “반짝하다가 사라질 이슈”가 아니라 “시장 요구에 따라 갈 수밖에 없는 흐름”으로 봤다. 그 배경에는 솔라윈즈, 로그4j(Log4j) 같은 보안 사고가 있다. 어떤 오픈소스가 어디에 들어갔는지 전혀 모르는 상태에서는 취약점이 발견되어도 영향의 범위를 가늠하기 어렵다. SBOM 논의가 커진 이유도 여기에 있다.
다만, 장 대표는 국내 시장이 아직 어떤 오픈소스를 썼는지 파악하는 단계에 머물러 있다고 진단했다. SBOM은 한 번 만들어 제출하고 끝내는 문서가 아니라는 얘기다. 패치가 이뤄지면 내용이 바뀌고, 어제까지 문제 없던 오픈소스가 오늘 새 취약점의 영향을 받을 수 있다. 그러면 공급사와 수요사는 계속 최신 정보를 맞춰봐야 한다. 그는 “그 수많은 SBOM 문서를 계속 주고받을 수도 없다”며 “메일로 SBOM을 보내는 방식으로는 관리에 한계가 있다”고 말했다.
스패로우 강점은 ‘공급망 보안 통합 플랫폼’
이런 문제의식은 스패로우의 제품 전략으로 이어진다. 스패로우는 시큐어코딩 도구에서 출발해 애플리케이션 보안 테스트(AST) 영역을 넓혀왔다. 지금은 ‘스패로우 엔터프라이즈(Sparrow Enterprise)’를 중심으로 소프트웨어 개발 전 과정의 취약점을 한 플랫폼에서 분석·관리하는 구조를 갖췄다.
이 제품은 소스코드 정적 분석(SAST)과 품질 결함 분석(SAQT)으로 직접 개발한 코드의 문제를 찾고, 오픈소스 구성요소 분석(SCA)으로 사용 중인 오픈소스와 라이선스, 취약점을 식별해 SBOM 생성까지 지원한다. 여기에 웹 취약점 동적 분석(DAST) 기능을 더해 운영 단계의 웹 애플리케이션 위험까지 함께 점검한다. 스패로우가 직접 개발한 코드, 외부 오픈소스, 운영 환경의 웹 취약점을 따로 떼어 보지 않고 하나의 흐름으로 관리하는 게 핵심이다.
장 대표는 “겉으로는 한 회사가 여러 제품을 갖고 있어 보여도, 안쪽까지 유기적으로 통합된 솔루션을 만드는 건 쉽지 않다”며 “스패로우는 애초에 같은 방향으로 계획하고 제품을 만들어왔다”고 설명했다.
실제 수요도 넓어지고 있다. 현재 고객 비중은 공공기관 40%, 금융 40%, 일반 기업 20% 수준이다. 초기에 공공이 시큐어코딩 의무화로 시장을 끌었다면, 지금은 금융과 대기업이 공급망 보안 체계를 다시 짜기 시작해 수요가 늘고 있다는 설명이다. 그는 특히 최근 대기업의 그룹사들이 예전에 들여온 단일 외산 도구를 재검토하고, 비용과 관리 한계를 줄이기 위해 통합형 구조를 다시 살피고 있다고도 덧붙였다.
다음 승부처는 SBOM 유통
장 대표는 공급망 보안의 다음 승부처는 ‘SBOM 유통’이라고 강조했다. 스패로우는 이를 위해 ‘스패로우 시큐어허브(Sparrow SecureHub)’를 앞세우고 있다. 이 제품은 공급사와 수요사가 SBOM을 주고받고, 서명으로 위변조를 검증하고, 변경 이력과 취약점 발생 여부를 계속 추적하는 ‘SBOM 공유 및 관리 플랫폼’이다. 서명 검증, 공유 이력 관리, 취약점 모니터링, 실시간 알림을 핵심 기능으로 제시한다.
장 대표는 여기서 공급망 보안의 본질을 다시 짚었다. ‘SBOM 생성’은 시작일 뿐이고, 실제 현장에서는 그 정보를 누가 언제 올렸는지, 지금 쓰는 버전과 맞는지, 새 취약점이 떴을 때 어느 공급사 제품이 영향을 받는지까지 바로 확인할 수 있어야 한다는 것이다. 그는 “나중에는 유통 플랫폼이 가장 핵심이 될 것”이라며 “이슈가 터졌을 때 다음 날 바로 조치가 끝나는 구조를 만들어야 한다”고 말했다.
장 대표는 이런 필요성이 민간만의 문제는 아니라고 봤다. 정부 역시 개별 기업이 메일로 SBOM을 주고받는 방식만으로는 한계가 있다고 보고, 공급망 보안 허브처럼 SBOM을 체계적으로 유통·관리할 수 있는 구조를 고민해 왔다는 것이다. 장 대표는 “결국 공급망 보안이 문서 제출 단계에 머물지 않고, 정책과 시장 모두 ‘허브형 운영 체계’로 옮겨갈 가능성이 크다”고 전망했다.
AI 시대, 더 중요해진 분석 엔진
AI는 공급망 보안을 더 복잡하게 만들고 있다. 코드 생성 속도가 빨라지고, 오픈소스 AI 모델까지 개발에 쓰이면서 점검해야 할 대상 자체가 급증하고 있다. 장 대표는 “오픈소스와 AI가 들어오면서 코딩 양 자체가 어마어마하게 늘었다”며 “이 많은 것을 누가 다 점검하느냐는 문제가 생겼다”고 말했다.
스패로우는 AI를 공급망 보안의 화두로만 보지 않고, 회사 안에서 실제 개발과 제품 고도화에도 활용하고 있다. 장 대표는 “작년에는 활용할 수 있는 게 있으면 해보자는 수준이었다면, 올해는 전사적으로 AI 활용 목표를 정했다”고 말했다. 특히 개발 부문은 더 구체적으로 적용 범위를 넓히고 있다고 설명했다.
스패로우가 AI를 쓰는 방식은 두 갈래다. 하나는 ‘내부 개발 과정에서 AI가 생성한 코드를 자사 분석 도구로 다시 점검하는 것’이다. 장 대표는 “개발 환경에서 AI 에이전트로 만든 코드도 한 번 더 분석한 뒤 활용하고 있으며, 이런 방식은 3년 전부터 내부에 비교적 빠르게 적용해 왔다”고 말했다. 다른 하나는 ‘분석 도구 자체의 활용성을 높이는 방향’이다. 스패로우는 자사 도구가 찾아낸 취약점 결과를 바탕으로, AI가 개발자 눈높이에 맞춰 취약점 의미와 조치 방법을 더 쉽게 설명하고 우선순위를 제안하도록 하고 있다.
다만 스패로우는 취약점 탐지 자체를 AI에 전적으로 맡기지는 않는다. 장 대표는 최근 보안업계에서 이슈가 된 ‘클로드 코드 시큐리티(Claude Code Security)’처럼 AI가 생성한 코드의 보안 문제까지 다루려는 시도가 나오는 것 자체가, 그만큼 시장에서도 AI 코드의 위험을 심각하게 보기 시작했다는 뜻이라고 봤다. 다만 이런 흐름이 곧바로 기존 분석 도구를 대체한다는 의미는 아니라는 게 그의 판단이다.
장 대표는 “분석 엔진은 같은 코드를 여러 번 돌려도 같은 결과를 내야 하는데, AI는 아직 그 수준의 일관성을 보장하기 어렵다”고 말했다. 그래서 스패로우는 취약점 탐지는 기존 분석 엔진이 맡고, AI는 개발자가 결과를 더 쉽게 이해하도록 설명과 가이드, 우선순위 제안 같은 보조 영역에 활용하는 구조를 택하고 있다.
올해 30% 매출 성장 목표…도입보다 운영에 무게
장 대표는 올해 스패로우의 매출 목표를 작년보다 30% 늘어난 140억원으로 설정했다. 그는 회사가 우상향 흐름과 흑자 기조를 꾸준히 이어가고 있다고 설명했다. 특히 “공급망 보안 시장은 커질 수밖에 없는 흐름”이라며 “개별 기업이 혼자 대응하는 영역이 아니라 공급자와 수요자가 함께 관리해야 하는 구조인 만큼 시장 확대의 당위성이 더 크다”고 말했다.
끝으로, 장 대표는 공급망 보안의 핵심이 SBOM이나 오픈소스 분석 도구를 도입하는 것 자체에 있지 않다고 다시 한 번 짚었다. 그는 “공급망 보안 시장은 이제 시작이다. 기업들이 공급망 보안 도구를 도입하면 끝난다고 생각해선 안 된다”며 “SCA 도구를 돌리면 지금까지 몰랐던 오픈소스가 한꺼번에 드러나고 취약점도 대량으로 나온다. 문제는 그다음”이라고 말했다. 이어 “무엇부터 고칠지, 어디까지 당장 손댈지, 서비스 영향은 없는지, 개발 조직과 보안 조직이 어떻게 우선순위를 합의할 지까지 긴 호흡으로 계획해야 한다. 그 선봉에 스패로우가 설 것”이라고 강조했다.
글. 바이라인네트워크
<곽중희 기자>god8889@byline.network
