이 글은 Sonatype 공식 블로그의 Your Agents Are Choosing Dependencies. DoWI 8430.01 Says You Own the Result.을 에스코어가 공식 파트너로서 한국어로 번역한 콘텐츠입니다.
에스코어 인사이트
원문에 앞서 AI 에이전트를 활용하는 개발 조직이 함께 점검할 만한 사항을 정리했습니다.
•
에이전트가 추가한 의존성의 결정 이력을 남깁니다: 어떤 에이전트가 어떤 의존성을 추가했는지, 왜 선택했는지, 현재 누가 책임지는지를 추적할 수 있어야 이후 검토와 감사가 쉬워집니다.
•
SBOM과 공급망 증적을 빌드 과정에서 자동으로 생성합니다: 에이전트가 의존성을 자주 바꾸는 환경에서는 전이 의존성, 컴포넌트 해시, 생성 시점과 출처 정보를 매 빌드마다 자동으로 기록해야 변화 속도를 따라갈 수 있습니다.
•
폐쇄망에서도 최신 컴포넌트 정보를 확인할 수 있게 합니다: 인터넷 연결이 제한된 환경에서는 취약점·악성코드·라이선스·프로젝트 상태 정보를 내부에서 조회하고 정책에 적용할 수 있는 체계가 필요합니다.
Sonatype 원문 번역
코딩 에이전트는 이제 소프트웨어 개발 과정의 많은 작업을 맡습니다. 변경 계획을 세우고, 파일을 수정하고, 패키지를 추가하고, 테스트를 실행하고, Pull Request를 엽니다. 이 과정에서 에이전트는 임무용 소프트웨어가 어떤 오픈소스 컴포넌트에 의존할지를 결정합니다. 각각의 선택을 사람이 검토하지 않는 경우도 많습니다.
Sonatype은 최근 에이전트를 사용하는 팀이 세 가지 질문에 답할 수 있어야 한다고 설명했습니다. 어떤 에이전트가 의존성을 추가했는지, 왜 그 의존성이 필요한지, 그리고 지금 누가 책임지고 있는지입니다.
미 전쟁부(Department of War, DoW) 프로그램에서는 2026년 9월 8일부터 이 질문들이 정책상 더 중요해졌습니다. 이날은 DoW Instruction(DoWI) 8430.01 ‘Accelerated Mission Software’가 발효된 날입니다. 그보다 6주 앞서 미국 사이버보안 및 인프라 보안국(CISA), 국가안보국(NSA), 연방수사국(FBI)과 15개 국제 파트너는 2026 Minimum Elements for a Software Bill of Materials(SBOM)를 발표했습니다.
DoWI 8430.01은 DoW 구성 조직에 적용되는 의무 정책입니다. CISA 문서는 강제성이 없는 지침이며 DoWI 8430.01이 직접 인용하는 문서도 아닙니다. 하지만 두 문서가 제시하는 방향은 같습니다. 함께 보면 에이전트의 의존성 선택은 단순한 엔지니어링 문제를 넘어 프로그램에 참여하는 모든 역할이 책임을 져야 하는 문제로 확장됩니다.
속도는 의무다. 책임도 마찬가지다
DoWI 8430.01은 AI를 억제해야 할 위험으로만 보지 않습니다. AI 지원 개발을 중요한 전력 증대 수단으로 규정하고, DoW 구성 조직이 역량 제공 속도를 높이기 위해 활용해야 한다고 설명합니다.
같은 절에서는 책임 조건도 분명히 합니다. AI가 생성한 코드는 검증되지 않은 입력으로 간주해야 하며, AI가 만든 결과에 대해서도 개발자와 팀이 전적으로 책임집니다. AI가 작성한 코드, 스크립트, 테스트 역시 사람이 작성한 코드와 같거나 유사한 수준의 검토와 보안 테스트를 거쳐야 하고, 라이선스 의무도 확인해야 합니다.
속도와 책임을 함께 요구한다는 점이 중요합니다. 이 지침은 프로그램의 개발 속도를 높이는 동시에 테스트·스캔·컴플라이언스 점검을 마지막 관문이 아닌 지속적인 활동으로 자동화하도록 요구합니다. 그렇다고 더 빨라지기 위해 책임 기준을 낮추지는 않습니다. 개발 속도만큼 증적도 빠르게 따라와야 한다는 뜻입니다.
에이전트가 오후 동안 의존성 다섯 개를 추가했다면 프로그램이 목록화하고 평가해야 할 컴포넌트도 다섯 개 늘어납니다. 이 지침은 각 의존성을 어떤 에이전트가 선택했고 왜 선택했는지 반드시 기록하라고 명시하지는 않습니다. 다만 어떤 에이전트가 무엇을 왜 선택했는지 기록해 두면 선택 과정을 이해하고 관리하는 데 도움이 됩니다. 대신 승인된 AI 도구는 사용 내역을 감사하고 모니터링할 수 있어야 한다고 요구합니다. 이 감사·모니터링 기록이 의존성 선택 이력을 추적하는 출발점이 될 수 있습니다.
에이전트가 고른 모든 컴포넌트에는 증적이 필요하다
DoWI 8430.01에서 증적은 일이 끝난 뒤 만드는 서류가 아닙니다. DoW 네트워크와 시스템에서 소프트웨어를 운영하기 위한 조건입니다. 운영하는 모든 소프트웨어에는 무엇이 포함돼 있는지, 어떻게 빌드됐는지, 어떻게 보호했는지를 보여주는 기계 판독 가능한 증적이 있어야 합니다.
에이전트가 선택한 의존성이라면 어떤 내용을 입증해야 하는지도 지침에 나와 있습니다. 모든 서드파티 컴포넌트는 다음 여섯 가지 위험 요소를 평가해야 합니다.
•
유지관리 가능성: 프로젝트가 안정적이고 활발하게 유지되며 지원되고 있는가?
•
출처 신뢰성: 배포 출처와 프로비넌스를 신뢰할 수 있는가?
•
의존성: 하위 컴포넌트에는 어떤 보안 및 라이선스 의무가 따라오는가?
•
보안 태세: 개발자가 취약점을 적시에 관리하고 수정하는가?
•
무결성 보호: 릴리스에 서명이 적용되고 빌드를 재현할 수 있는가?
•
외국의 영향력: 적대 세력이 프로젝트를 소유·지원하거나 기여·통제할 가능성이 있는가?
단순한 구성요소가 아닌 오픈소스 컴포넌트는 거버넌스 모델, 커뮤니티 건전성, 라이선스 위험까지 더 자세히 살펴봅니다.
학습 데이터에만 의존하는 모델은 프로젝트가 지난달에 사실상 중단됐는지, 현재 누가 통제하는지 같은 현재 상태에 관한 질문에 안정적으로 답하기 어렵습니다. DoWI 8430.01은 소프트웨어 생성에 사용한 모델, 버전, 주요 데이터셋도 증적에 포함하도록 요구합니다. 이제 에이전트 뒤에서 작동한 모델 자체도 기록 대상입니다.
폐쇄망에서는 위험이 더 커진다
일반 기업의 개발팀은 코딩 에이전트를 클라우드 서비스에 연결해 작업 중에 패키지 상태를 확인하게 할 수 있습니다. 하지만 DoW의 많은 환경에서는 그렇게 할 수 없습니다.
DoWI 8430.01은 DoW 사이버보안 절차를 거쳐 승인된 AI 도구만 사용하도록 하며, DoW 시스템 밖에서 운영되는 생성형 AI 서비스에 비공개 DoW 정보를 입력하는 것을 금지합니다. 또한 기업용 도구가 여러 기밀 등급의 환경에서 동작해야 하며, 연결이 끊긴 환경과 전술 환경도 지원해야 한다고 요구합니다. 군사 또는 우주 분야에 사용되는 SBOM과 빌드 스크립트는 통제기술정보(CTI)로 취급되므로 프로그램의 의존성 목록 자체도 보호 대상이 될 수 있습니다.
격리 환경에서는 모델도 로컬에 설치해야 합니다. Scale AI의 Defense Llama처럼 미세 조정한 오픈 웨이트 모델일 수도 있고, 상용 모델을 인터넷과 분리된 형태로 배포할 수도 있습니다. 어느 쪽이든 에이전트가 작업 중에 외부 서비스에 접속해 패키지 상태를 확인하지 못할 수 있습니다. 학습 데이터만으로는 모델 학습 이후 공개된 취약점을 알 수 없습니다.
모델이 현재 패키지 상태를 정확히 판단하지 못하는 문제는 가정에 그치지 않습니다. 2025년 동료 심사를 거친 연구에서는 576,000개의 코드 샘플을 시험했습니다. 오픈 웨이트 모델에서는 존재하지 않는 패키지 추천 비율이 21.7%, 상용 모델에서는 5.2%였습니다. 공격자가 AI가 만들어 낸 존재하지 않는 패키지 이름을 실제로 등록하고 악성코드를 심는 공격 기법을 슬롭스쿼팅(slopsquatting)이라고 합니다. 최신 모델의 성능은 더 나을 수 있지만, 어떤 모델도 학습이 끝난 뒤 공개된 취약점을 스스로 알 수는 없습니다.
사람이 직접 고르지 않은 컴포넌트도 SBOM에 담아야 한다
2026 SBOM Minimum Elements는 에이전트가 스스로 가져온 컴포넌트를 포함해 모든 컴포넌트에 대해 SBOM이 제공해야 할 정보의 기준을 높였습니다.
에이전트형 개발과 직접 관련된 변경 사항은 다음과 같습니다.
•
Coverage: 전이 의존성을 포함한 모든 컴포넌트를 포함합니다. 완전한 SBOM이 있으면 새로 공개된 취약점이 자사 시스템에 영향을 주지 않는다는 판단도 내릴 수 있습니다.
•
SBOM Author Signature: SBOM이 생성된 뒤 변경되지 않았는지 수신자가 확인할 수 있게 합니다.
•
Component Hash Value / Component Hash Algorithm: 각 항목을 실제 빌드에 사용한 정확한 아티팩트와 연결합니다.
•
SBOM Generation Context: 데이터가 빌드 전, 빌드 중, 빌드 후 어느 시점에 만들어졌는지 기록합니다.
•
Component Producer: 컴포넌트를 만든 주체를 기록하고, 출처를 알 수 없으면 그 사실을 명시합니다.
•
Explicitly Identifying Unknown Information: 알 수 없는 정보는 빈칸으로 두지 않고 확인되지 않았음을 표시해야 합니다.
2026 SBOM Minimum Elements는 빌드나 릴리스마다 새로운 SBOM을 만들도록 권고합니다. 에이전트가 매일 의존성을 바꾸는 환경에서 빌드나 릴리스마다 새 SBOM을 만들려면 SBOM 생성을 파이프라인에서 자동화해야 합니다.
DoWI 8430.01은 의무 요건을 제시합니다. 전이 의존성을 포함한 모든 서드파티 컴포넌트가 시스템 SBOM에 포함돼야 하며, DoWI 8430.01이 정의하는 SBOM 역시 확인하지 못한 정보가 있다면 숨기지 말고 명시하도록 요구합니다.
SBOM은 소프트웨어에 무엇이 들어 있는지를 기록할 뿐, 왜 특정 컴포넌트가 들어왔는지까지 설명하지는 않습니다. 하지만 2026년 기준을 적용하면 검증하지 않은 에이전트 선택 컴포넌트가 마치 확인된 컴포넌트인 것처럼 넘어가기가 훨씬 어려워집니다.
모든 역할이 책임을 나눠 맡는다
개발자 한 명이 에이전트가 내리는 모든 의존성 결정을 추적할 수는 없습니다. DoWI 8430.01은 개발자와 팀의 책임을 유지하는 동시에 프로그램의 다른 역할에도 요구사항을 부여합니다.
•
구성 조직 책임자와 엔지니어링 리더는 검토 경계를 정합니다. 이 지침은 지속적 통합·지속적 배포(CI/CD) 파이프라인을 핵심 인프라로 봅니다. 매니페스트를 수정하고 빌드를 실행하는 에이전트 역시 그 인프라 안에서 작동합니다. 리더는 에이전트가 수행한 변경 중 어떤 항목에 사람의 승인이 필요한지 위험에 따라 정해야 하며, 보안이나 안전에 중요한 변경부터 우선 적용합니다.
•
보안 리더와 승인 담당자는 증적을 책임집니다. 승인 담당자는 상호 인정을 부여할 때 SBOM, 빌드 프로비넌스, 보안 스캔과 같은 표준 기계 판독 증적을 받아들이도록 요구받습니다. 서명된 완전한 SBOM과 사용 모델 기록이 있어야 에이전트 활용으로 빨라진 개발 속도를 승인 체계 안에서 수용할 수 있습니다.
•
DevSecOps와 플랫폼 엔지니어는 안전한 기본 개발 경로를 책임집니다. 개발·보안·운영(DevSecOps) 팀은 안전한 방식이 가장 쉬운 방식이 되도록 해야 합니다. 의존성 스캔은 파이프라인에 포함하고, 모든 빌드에서 프로비넌스를 생성해야 합니다.
•
프로그램 관리자와 조달 담당자는 계약 조건을 책임집니다. 계약업체의 에이전트가 프로그램에서 사용할 컴포넌트를 선택한다면, 앞서 설명한 여섯 가지 위험 요소와 CISA 2026 기준, 사용 모델 기록을 계약에 반영해야 계약상 집행 가능한 의무가 됩니다.
역할은 달라도 공통적으로 필요한 기반은 같습니다. 의존성이 유입될 수 있는 모든 지점에서 최신 컴포넌트 정보를 바탕으로 정책을 적용해야 합니다.
에이전트가 선택하는 순간에 정책을 적용하라
에이전트가 만든 결과를 사람이 일일이 검토하는 방식만으로는 규모가 커질수록 대응하기 어렵습니다. DoWI 8430.01은 보안이나 안전에 중요한 변경에 사람의 승인을 의무화해 사람이 계속 검토 과정에 참여하도록 합니다. 동시에 개발 속도를 따라갈 수 있도록 증적을 지속적으로 자동 생성할 것을 요구합니다.
실무에서는 에이전트가 의존성을 선택하는 시점에 정책이 바로 적용되도록 해야 합니다. 에이전트가 패키지를 추가하기 전에 최신 취약점, 악성코드, 라이선스, 프로젝트 건전성 정보를 확인할 수 있다면 잘못된 의존성을 선택할 위험을 줄일 수 있습니다. 리포지토리 방화벽은 이미 위험이 확인된 컴포넌트가 내부로 들어오기 전에 차단합니다. 파이프라인 정책과 SBOM 생성은 평가와 승인에 필요한 점검 절차와 증적을 추가합니다. 인터넷과 분리된 환경이라면 최신 취약점·악성코드·라이선스·프로젝트 건전성 정보 역시 격리망 안에 있어야 합니다. 에이전트가 외부 서비스에 접속해 정보를 확인할 수 없기 때문입니다.
에이전트형 개발이 DoW 프로그램 전반으로 확산될수록 모든 팀은 증적만으로 세 가지 질문에 답할 수 있어야 합니다. 어떤 에이전트가 이 의존성을 추가했는가? 왜 이 의존성이 들어왔는가? 지금 누가 책임지고 있는가?
에스코어는 Sonatype 공식 파트너로서 소프트웨어 공급망 보안 및 오픈소스 거버넌스 구축을 지원합니다.
도입이나 구축이 필요하시면 언제든 문의해 주세요.
지원 솔루션: Nexus Repository · Repository Firewall · Lifecycle · Sonatype Guide