한 줄로 말하면
AI 코딩의 공급망 보안은 에이전트가 만든 코드만 검사하는 일이 아니야. 코드가 불러오는 의존성의 버전, 그 안의 취약점, 라이선스, 배포물의 구성요소를 함께 확인하는 일이야.
비유로 이해하기
AI에게 기능 하나를 만들어 달라고 하는 건 요리사에게 요리를 맡기는 것과 비슷해. 요리사가 직접 만든 소스만 봐서는 충분하지 않아. 어떤 재료를 어디서 가져왔고, 유통기한이 지났는지, 알레르기 표시가 있는지도 봐야 하지.
소프트웨어에서 그 재료가 의존성이야. 프로젝트가 직접 설치한 패키지만이 아니라, 그 패키지가 다시 끌어오는 전이 의존성까지 결과물에 들어와. 이 비유의 한계도 있어. 패키지는 음식처럼 한 번 쓰고 사라지는 재료가 아니라, 버전이 고정된 채 빌드와 배포에 반복해서 들어가는 구성요소야.
정확한 정의
의존성은 프로그램이 기능을 만들기 위해 가져다 쓰는 외부 패키지·라이브러리·컨테이너 이미지 같은 구성요소야. 소프트웨어 공급망 보안은 이 구성요소가 어디서 왔고, 어떤 버전이며, 알려진 취약점이나 라이선스 문제가 있는지 확인하는 작업을 뜻해.
AI 코딩에서는 개발자가 의존성을 하나씩 검토하지 않은 채 에이전트가 manifest 파일을 수정할 수 있어. Red Hat Developer는 AI 코딩을 사용할 때 생산량이 늘어나는 동시에 보안 문제가 더 많이 들어올 수 있다는 자료를 소개하며, AI가 만든 코드와 의존성을 작성 중에 점검하는 흐름을 설명해.1
이 흐름에서 SBOM(Software Bill of Materials)은 소프트웨어에 무엇이 들어 있는지 적은 구성요소 목록이야. SBOM은 코드의 품질을 대신 판정하지 않지만, 문제가 생겼을 때 어떤 패키지와 버전을 찾아야 하는지 출발점을 제공해. 이 글의 원문은 CycloneDX 형식의 SBOM 생성을 예로 들고 있어.1
왜 중요한가
AI 코딩의 위험은 새 코드에만 있지 않아. 에이전트가 오래된 버전을 선택하거나, 직접 추가한 패키지가 다른 패키지를 끌어오거나, 프로젝트와 맞지 않는 라이선스를 가진 패키지를 넣을 수 있어. 겉으로는 기능이 정상 작동해도 배포물의 구성과 책임은 달라지는 거지.
의존성은 두 방향으로 들어와.
flowchart LR A[AI 에이전트가 manifest 수정] --> B[직접 의존성] B --> C[전이 의존성] B --> D[라이선스 조건] C --> E[알려진 취약점] D --> F[프로젝트와의 호환성] E --> G[SBOM과 수정 버전 확인] F --> G
직접 의존성은 개발자가 프로젝트에 명시한 패키지야. 전이 의존성은 그 패키지가 다시 필요로 해서 따라 들어오는 패키지야. 원문은 [email protected]이 [email protected]를 끌어오고, 뒤쪽 버전에 알려진 prototype pollution 취약점이 있는 사례를 들고 있어.1 따라서 manifest의 몇 줄만 훑어서는 실제 배포물의 위험을 다 볼 수 없어.
라이선스도 같은 구조로 따라와. 원문은 Apache-2.0 프로젝트에 GPL-3.0 패키지가 들어오면 라이선스 호환성 문제가 생길 수 있다고 설명해.1 보안 취약점처럼 즉시 실행되는 결함은 아니지만, 배포 조건과 사용 방식에 영향을 주는 공급망의 속성이야.
실제 예시
Red Hat의 Dependency analytics 1.0은 VS Code·Cursor·Windsurf 같은 편집기 확장으로 소개됐어. JavaScript/TypeScript, Python, Java, Go, Rust 프로젝트와 Dockerfile을 지원하고, manifest 파일을 열 때 알려진 취약점을 실시간으로 검사한다고 설명해.1
작업 흐름은 단순해.
- AI 에이전트가 manifest를 수정해.
- 개발자가 manifest를 열면 의존성 검사가 실행돼.
- 취약한 의존성에는 편집기 안에서 진단과 심각도가 표시돼.
- 가능한 경우 안전한 버전으로 가는 수정 경로를 확인해.
RHDA: Generate SBOM명령으로 배포물의 구성요소 목록을 만들어.
원문이 든 예시는 오래된 pandas와 email-validator, 취약점이 알려진 [email protected], 전이 의존성인 [email protected]야. 중요한 건 특정 패키지 이름보다, AI가 추가한 한 줄을 직접 의존성에서 멈추지 않고 전이 의존성과 배포 목록까지 따라가는 검사 순서야.1
헷갈리지 말아야 할 점
- SBOM은 보안 인증서가 아니야. 무엇이 들어 있는지는 보여 주지만, 그 구성요소가 안전하다고 보증하지는 않아.
- 취약점 검사는 코드 검사를 대체하지 않아. 의존성에 알려진 문제가 없는 것과 새로 만든 코드가 안전한 것은 다른 질문이야.
- 직접 의존성만 보면 안 돼. 패키지가 끌어오는 전이 의존성에도 취약점이 생길 수 있어.
- 라이선스 문제는 취약점과 다르지만 가볍지 않아. 실행 오류가 없어도 배포와 사용 조건이 프로젝트와 충돌할 수 있어.
- AI 코딩이 곧 취약하다는 뜻은 아니야. 이 글에서 소개한 비율과 사례는 Red Hat Developer가 인용·설명한 내용이야. 실제 프로젝트의 위험은 사용하는 모델, 검토 과정, 의존성 관리에 따라 따로 확인해야 해.1
관련 문서
- AI 에이전트가 외부 도구를 의존성처럼 다루게 되는 문제는 AI 에이전트는 도구 설명서를 명령으로 읽는다.
- 에이전트가 변경을 만들고 검사 장치가 결과를 확인하는 개발 구조는 소프트웨어 팩토리.
- 에이전트가 도구와 권한을 조합해 행동하는 작업 흐름은 agentic workflow.
남은 질문들
- AI 코딩 도구가 의존성의 안전한 버전을 선택할 때 어떤 출처와 기준을 사용하는지 어떻게 검증할까?
- SBOM을 생성하는 데서 끝나지 않고, 빌드·배포 과정에서 구성요소 변경을 추적하는 방법은 무엇일까?
- 전이 의존성의 취약점과 라이선스 변경을 프로젝트의 승인 절차에 어떻게 연결할까?
댓글