--- title: "SBOM만 믿으면 큰일남: 실제 바이너리가 보여주는 소프트웨어 공급망의 진짜 구성" published: 2026-08-03T02:05:03.219Z canonical: https://jeff.news/article/5400 --- # SBOM만 믿으면 큰일남: 실제 바이너리가 보여주는 소프트웨어 공급망의 진짜 구성 소프트웨어 자재명세서(SBOM)는 제품에 무엇을 넣었다고 기록했는지 보여주지만, 실제 출하된 바이너리와 항상 일치하진 않는다. 특히 레거시 코드, 서드파티 SDK, AI가 생성한 코드가 섞이면서 신고되지 않은 오픈소스 조각과 라이선스·보안 리스크가 더 자주 튀어나오고 있다. - SBOM은 ‘우리가 넣었다고 기록한 것’을 보여주지만, 바이너리는 ‘실제로 고객에게 나간 것’을 보여줌 - 이 차이가 별거 아닌 문서 정합성 문제가 아니라, 보안·라이선스·경영 리스크로 바로 이어진다는 게 핵심임 - 건설 현장에서 철골마다 제철소 표식이 있고 레미콘마다 배치 번호가 붙는 것처럼, 소프트웨어도 출처를 증명할 수 있어야 한다는 비유가 꽤 직관적임 - 문제는 소프트웨어의 출발점이 항상 깨끗하지 않다는 거임 - 오래된 빌드에서 물려받은 코드, 이전 프로젝트에서 복사해 온 코드, 협력사 SDK 안에 숨어 있는 라이브러리가 그대로 제품에 들어갈 수 있음 - 누가 악의적으로 숨긴 게 아니라, 애초에 기록 절차를 한 번도 지나지 않은 구성 요소가 생기는 구조임 - 기록되지 않은 오픈소스는 먼저 법적 리스크를 만든다 - 오픈소스 라이선스는 저작권 라이선스라서, 조건을 지키지 않으면 ‘허락받고 쓴 것’이 아니게 됨 - 저작자 표시, 라이선스 전문 포함, 경우에 따라 자체 소스코드 공개 같은 의무가 붙을 수 있음 - 규제기관이 따로 잡으러 다니는 구조는 아니지만, 권리자가 직접 문제를 제기할 수 있고 시한이나 관할 제약도 작음 - 실제로는 인수·합병(M&A) 과정에서 인수 측 법무팀이 코드 분석을 하다가 이런 위반을 발견하는 경우가 많다고 함 - 두 번째는 더 익숙한 보안 리스크임: 모르는 구성 요소의 취약점은 고칠 수도 없음 - 대표 사례가 2021년 12월의 로그4셸(Log4Shell)임 - 로그4j 사용 기록을 갖고 있던 기업은 몇 시간 안에 영향 여부를 확인했지만, 기록이 없던 기업은 수주 동안 전체 소프트웨어를 뒤져야 했음 - 이후 다른 취약점이 또 나오면 처음부터 다시 뒤지는 일이 반복됨. 특정 취약점 검색만으로는 ‘우리 제품 안에 뭐가 들어 있나’를 알 수 없기 때문임 > [!IMPORTANT] > 이 기사에서 제일 센 숫자는 AI 코드 분석 결과임. AI가 일부 또는 전체 코드를 작성한 애플리케이션에서 전체 파일의 37%에 신고되지 않은 오픈소스 코드 조각이 있었고, AI가 앱 전체를 만든 경우에는 56%까지 올라감. - AI 코딩 도우미가 판을 더 복잡하게 만들고 있음 - 예전에는 개발자가 라이브러리를 직접 찾아 내려받고 프로젝트에 추가했기 때문에, 라이선스와 기록이 같이 따라오는 경우가 많았음 - 그런데 AI 코딩 도우미는 라이브러리를 ‘가져오는’ 게 아니라 코드를 바로 생성함 - 그 코드 일부가 다른 사람이 저작권을 가진 공개 코드와 닮았거나 사실상 복사된 조각일 수 있는데, 라이선스 정보는 같이 오지 않음 - 인사이너리(Insignary)가 실제 애플리케이션을 분석한 결과도 꽤 빡셈 - AI가 일부 또는 전체 코드를 작성한 앱에서는 전체 파일의 37%에서 신고되지 않은 오픈소스 코드 조각이 발견됨 - AI가 애플리케이션 전체를 작성한 경우에는 이 비율이 56%까지 올라감 - 기존 소프트웨어 구성 분석(SCA) 도구가 실제 존재하는 구성 요소 중 찾아낸 건 약 23%에 그쳤다고 함 - 이유는 단순함. 많은 SCA 도구가 소스코드 자체보다 신고된 매니페스트를 읽는 방식에 기대기 때문임 - 그래서 ‘SBOM 검증’은 문서 리뷰가 아니라 실제 배포물 대조에 가까움 - 문서에 적힌 구성과 실제 컴파일된 소프트웨어 내부 구성이 일치하는지 확인하는 과정임 - 패키지 매니페스트에 없는 라이브러리, 코드베이스에 직접 붙여 넣은 구성 요소, 모호하게 선언된 버전이 여기서 드러남 - 김택완 인사이너리 대표는 이걸 재무감사에 비유함. 회사가 재무제표를 직접 작성해도, 투자자는 독립 감사를 요구한다는 논리임 - 이 이슈는 이제 엔지니어링팀만의 숙제가 아니라 경영진 리스크로 올라가는 중임 - 캐나다의 Bill C-8, 유럽의 사이버복원력법(Cyber Resilience Act) 같은 규제가 나오면서 소프트웨어 무결성이 전사 리스크 관리 영역으로 이동하고 있음 - 제품 안에 무엇이 들어 있는지, 그 출처를 어떻게 증명할 수 있는지가 이사회 레벨 질문이 된다는 얘기임 - 이사회가 정말 물어야 할 질문은 하나로 압축됨 - “우리 인벤토리는 완전합니다”라는 보고를 받았을 때, 다음 질문은 “그걸 어떻게 아나요?”여야 함 - 도구 이름이나 SBOM 작성자가 중요한 게 아니라, 실제 배포물 기준으로 독립적인 증거가 있느냐가 핵심임 --- ## 기술 맥락 - 여기서 선택의 축은 SBOM을 만들 것이냐 말 것이냐가 아니에요. 이미 많은 조직은 SBOM을 만들고 있거든요. 진짜 질문은 그 SBOM이 실제 바이너리와 맞는지 어떻게 증명하느냐예요. - 기존 SCA 도구가 매니페스트 중심으로 동작하면 개발자가 정식 의존성으로 선언한 라이브러리는 잘 잡을 수 있어요. 하지만 복사해 넣은 코드, 레거시에서 물려받은 파일, AI가 생성한 코드 조각은 선언 자체가 없으니 빠질 수밖에 없어요. - 그래서 바이너리 분석이 중요해져요. 개발 과정의 의도나 문서가 아니라 최종 산출물 안에 실제로 어떤 코드와 구성 요소가 들어갔는지를 보자는 접근이거든요. 고객에게 나가는 건 저장소가 아니라 빌드된 제품이니까요. - 특히 AI 코딩 도우미가 들어오면 코드 유입 경로가 훨씬 흐려져요. 사람이 라이브러리를 추가할 때처럼 라이선스 파일과 패키지 기록이 따라오는 게 아니라, 모델이 코드 형태로 바로 뱉어내기 때문이에요. - 운영 관점에서는 취약점 대응 속도도 달라져요. Log4Shell처럼 대형 취약점이 터졌을 때 정확한 인벤토리가 있으면 영향 범위를 바로 좁힐 수 있지만, 없으면 제품 전체를 다시 뒤져야 해요. ## 핵심 포인트 - SBOM은 의도한 구성 목록이고, 바이너리 분석은 실제 배포물 안에 들어간 구성을 확인하는 방식임 - AI가 작성한 애플리케이션에서는 전체 파일의 37%, 전체를 AI가 만든 경우에는 56%에서 신고되지 않은 오픈소스 코드 조각이 발견됨 - 기존 SCA 도구는 매니페스트 중심이라 실제 구성 요소의 약 23%만 잡아낸 사례가 있음 - Log4Shell 같은 취약점 대응에서는 ‘목록에 있느냐’가 곧 대응 속도를 가르는 핵심임 ## 인사이트 AI 코딩 도구가 코드 생산 속도를 확 끌어올린 만큼, 오픈소스 거버넌스도 ‘개발자가 뭘 가져왔나’ 수준에 머물면 안 되는 시점임. 이제는 문서화보다 검증, 특히 실제 바이너리 기준 검증이 공급망 보안의 기본값으로 올라오는 흐름임.