AI 코딩 에이전트가 패키지를 추천하거나 설치할 때 가장 위험한 순간은 이름이 틀렸을 때만이 아닙니다. 실제로 존재하는 패키지라도 오래된 버전이나 알려진 취약점이 포함된 버전을 선택할 수 있습니다. DepTrust는 이런 상황에서 패키지명과 버전을 공개 레지스트리 및 취약점 데이터와 대조해, 설치하거나 추천하기 전에 한 번 더 판단할 수 있도록 만든 명령줄 도구입니다.
핵심은 새로운 취약점 데이터베이스를 운영하는 서비스가 아니라는 점입니다. 도구는 로컬에서 실행되지만 npm, PyPI 같은 패키지 레지스트리와 OSV, GitHub Advisory Database 등 외부 API를 직접 조회합니다. 따라서 로컬 실행은 오프라인 실행을 의미하지 않으며, 네트워크 상태와 외부 API의 응답 범위가 결과에 영향을 줍니다. 별도의 호스팅형 DepTrust 서비스나 계정을 설정하는 구조는 아니지만, 지원 범위와 API 제한까지 포함해 도입 여부를 판단해야 합니다.
어떤 문제를 줄이려는 도구인가
생성형 AI는 학습 시점이나 검색 결과에 따라 현재 권장 버전보다 오래된 버전을 제안할 수 있습니다. 에이전트가 package.json, requirements.txt, Cargo.toml 같은 의존성 파일을 직접 수정하는 환경에서는 잘못된 추천이 곧 설치로 이어질 가능성도 있습니다. 사람이 모든 패키지와 버전을 매번 검색하는 대신, 에이전트가 설치 직전에 확인 명령을 호출하도록 만들면 반복 검증 부담을 줄일 수 있습니다.
다만 DepTrust가 반환하는 허용 결과를 안전 인증으로 받아들여서는 안 됩니다. 이 도구의 허용 판정은 공개 데이터에서 설치를 막을 만한 알려진 취약점을 발견하지 못했다는 의미입니다. 아직 공개되지 않은 취약점, 악성 유지보수자, 타이포스쿼팅, 소스 코드 품질, 라이선스 문제, 공급망 탈취까지 모두 검증했다는 뜻은 아닙니다.
지원하는 패키지 생태계
저장소에 제시된 지원 범위는 일반적인 애플리케이션 의존성뿐 아니라 GitHub Actions 같은 자동화 구성요소까지 포함합니다. Maven은 groupId:artifactId, Packagist는 vendor/package, GitHub Actions는 owner/repo 형식처럼 생태계별 식별 규칙이 다르므로 실제 자동화에 연결할 때 입력 형식을 맞춰야 합니다.
| 생태계 | 레지스트리 메타데이터 | OSV | GitHub Advisory Database |
|---|---|---|---|
| npm | 지원 | 지원 | 지원 |
| PyPI | 지원 | 지원 | 지원 |
| Cargo / crates.io | 지원 | 지원 | 지원 |
| Go modules | 지원 | 지원 | 지원 |
| RubyGems | 지원 | 지원 | 지원 |
| NuGet | 지원 | 지원 | 지원 |
| Maven | 지원 | 지원 | 지원 |
| Packagist / Composer | 지원 | 지원 | 지원 |
| pub.dev | 지원 | 지원 | 지원 |
| CocoaPods | 지원 | 미지원 | 지원 |
| Hex.pm | 지원 | 지원 | 지원 |
| Hackage | 지원 | 지원 | 미지원 |
| GitHub Actions | 지원 | 지원 | 지원 |
표에서 중요한 부분은 생태계를 지원한다는 사실과 모든 취약점 제공자가 해당 생태계를 지원한다는 사실이 서로 다르다는 점입니다. 예를 들어 CocoaPods는 OSV 지원이 없고, Hackage는 GitHub Advisory Database 지원이 없습니다. DepTrust는 레지스트리 정보는 확인할 수 있지만 설정된 취약점 제공자가 지원하지 않는 생태계라면 이를 안전으로 처리하지 않고 알 수 없음으로 반환합니다.
판정 결과를 읽는 기준
기본 추천은 확인된 취약점 가운데 가장 높은 심각도를 기준으로 나뉩니다. 치명적 또는 높음은 차단, 중간 또는 심각도를 알 수 없는 경우는 검토, 낮음과 발견되지 않음은 허용으로 분류됩니다. 이 구분은 설치 자동화를 설계할 때 출발점으로 사용할 수 있지만, 프로젝트의 위험 수준에 맞춰 별도 정책을 두는 편이 안전합니다.
| 최고 심각도 | 기본 추천 | 적용할 때의 해석 |
|---|---|---|
| 치명적 | 차단 | 설치를 멈추고 수정 버전이나 대체 패키지를 확인 |
| 높음 | 차단 | 자동 병합이나 자동 설치 대상으로 사용하지 않음 |
| 중간 | 검토 | 취약한 기능의 실제 사용 여부와 노출 경로를 확인 |
| 알 수 없음 | 검토 | 데이터 부족이나 조회 실패 원인을 먼저 확인 |
| 낮음 | 허용 | 프로젝트 정책과 실행 환경에 따라 추가 검토 |
| 발견되지 않음 | 허용 | 공개 데이터에서 차단 사유를 찾지 못했다는 의미 |
취약점 외의 위험 신호도 확인합니다. 예를 들어 공개된 지 72시간이 지나지 않은 버전은 에이전트가 새 릴리스를 무조건 설치하지 않도록 검토 대상으로 표시됩니다. 새 버전이 곧 위험하다는 뜻은 아니지만, 배포 직후의 회귀 오류나 공급망 이상이 충분히 관찰되지 않았을 가능성을 고려하는 장치입니다.
개인 사용자와 학생이 확인할 부분
개인 프로젝트에서는 전면적인 자동화보다 새 의존성을 추가할 때 정확한 버전을 한 번 검사하는 방식이 적합합니다. 과제나 실습 환경이라면 결과가 허용으로 나왔다는 이유만으로 최신 버전으로 즉시 바꾸기보다, 강의 자료나 실행 환경이 요구하는 버전과 호환되는지도 함께 확인해야 합니다.
- AI가 제안한 패키지명과 버전이 실제 레지스트리에 존재하는지 확인합니다.
- 발견된 취약점이 현재 작성하는 코드의 사용 경로와 관련 있는지 살펴봅니다.
- 수정 버전으로 올렸을 때 런타임, 프레임워크, 과제 채점 환경이 깨지지 않는지 테스트합니다.
- 허용 결과를 패키지의 품질이나 유지보수 상태에 대한 보증으로 해석하지 않습니다.
연구자와 개발팀의 적용 기준
연구 코드는 재현성이 중요하므로 단순히 최신 버전으로 교체하는 것만이 답은 아닙니다. 기존 실험에 사용한 버전을 먼저 정확히 검사하고, 취약점이 발견되면 원래 환경과 수정 환경을 구분해 기록해야 합니다. 논문이나 데이터 처리 파이프라인을 재현해야 한다면 버전 변경이 결과에 영향을 주는지도 확인할 필요가 있습니다.
개발팀에서는 MCP 서버 형태로 연결해 AI 에이전트가 도구를 호출하게 만들 수 있습니다. 저장소에는 에이전트용 스킬과 훅도 포함돼 있습니다. 그러나 설치만으로 모든 의존성 추천이 자동 검증된다고 가정해서는 안 됩니다. 에이전트가 어느 시점에 검사를 호출하는지, 검사 실패 시 설치를 중단하는지, 검토 결과를 사람이 볼 수 있는지까지 실제 작업 흐름에서 확인해야 합니다.
- 새 패키지를 추가하는 작은 저장소나 비핵심 브랜치에서 시작합니다.
- 정상 버전, 알려진 취약 버전, 존재하지 않는 버전을 각각 입력해 결과를 비교합니다.
- 네트워크 차단이나 API 제한 상황에서 허용으로 잘못 통과하지 않는지 확인합니다.
- 에이전트가 차단 결과를 무시하고 설치 명령을 계속 실행하지 않는지 시험합니다.
- 오탐이나 데이터 부족이 발생했을 때 사람이 예외를 승인하는 절차를 정합니다.
조회 실패와 불완전한 결과를 다루는 방식
JSON 결과에는 실제로 조회한 제공자, 지원되지 않아 건너뛴 제공자, 취약점 정보의 전체·부분·없음·오류 상태, 레지스트리 검증 여부와 그 사유가 포함됩니다. CI나 에이전트 자동화에서는 최종 추천 한 항목만 읽지 말고 이 필드들도 함께 보관하는 편이 좋습니다. 같은 알 수 없음 결과라도 생태계 미지원, API 오류, 권한 문제는 대응 방법이 다르기 때문입니다.
정확한 버전을 검사할 때 레지스트리 조회가 일시적으로 실패하면 취약점 제공자 조회는 계속될 수 있습니다. 다만 이 경우 결과는 설치 가능한 상태로 취급되지 않으며 허용 추천도 나오지 않습니다. 최신 버전 조회, 알 수 없는 패키지, 존재하지 않는 버전 판별은 성공적인 레지스트리 확인이 필요합니다.
외부 API가 429, 502, 503, 504 응답을 반환하면 최대 세 번까지 시도하며 짧은 지수형 지연을 사용합니다. Retry-After 값은 최대 2초까지 따르고, 그보다 긴 대기를 요청받으면 명령이 장시간 멈추지 않도록 빠르게 실패합니다. 재시도가 모두 실패한 취약점 조회는 불완전한 결과가 되며 허용으로 처리되지 않습니다. CI에서는 이런 실패를 곧바로 취약점 발견과 동일하게 볼지, 별도 재시도 작업으로 보낼지 정책을 정해야 합니다.
권한과 데이터 흐름
GitHub Advisory Database와 GitHub Actions API 조회에는 선택적으로 수명이 짧고 권한이 제한된 GitHub App 토큰을 사용할 수 있습니다. 인증 정보가 없으면 비인증 상태로 계속 조회하지만, API 사용량 제한이나 권한 오류가 발생할 가능성을 고려해야 합니다. GitHub API의 제한 또는 권한 실패는 OSV 조회만 성공했다는 이유로 정상 통과하지 않고 진단 정보와 함께 알 수 없음으로 처리됩니다.
저장소 설명에 따르면 토큰은 저장, 번들 포함, 캐시, 로그, 원격 측정 결과에 포함하지 않으며 인증 헤더는 GitHub API 주소에만 전송합니다. 그래도 조직 환경에서는 실행 파일과 설정을 직접 검토하고, 최소 권한 토큰을 별도로 발급하며, CI 로그에 환경 변수가 노출되지 않는지 확인해야 합니다. 토큰을 쓰지 않는 개인 사용자도 조회 대상인 패키지명과 버전이 외부 레지스트리 및 취약점 API로 전송된다는 점은 알아둘 필요가 있습니다.
설치 방법보다 먼저 볼 운영 조건
제시된 설치 경로는 pnpx를 이용한 설치, Homebrew의 clidey/tap/deptrust, Go의 go install 방식입니다. 어떤 경로를 선택하든 최신 버전을 바로 운영 자동화에 고정하는 것보다는 검증한 도구 버전을 기록하는 편이 재현성과 변경 관리에 유리합니다. 업데이트 후에는 지원 생태계, 출력 형식, 추천 규칙이 달라지지 않았는지 다시 확인해야 합니다.
- 로컬 단발 검사: 새 의존성을 가끔 추가하는 개인 프로젝트에 적합합니다.
- CI 검사: 의존성 변경 요청을 반복적으로 검토하는 저장소에 적합하지만 API 제한과 실패 정책이 필요합니다.
- MCP 연동: AI 에이전트가 패키지를 자주 추천하거나 직접 수정하는 환경에서 유용합니다.
- 스킬 또는 훅 연동: 실제 설치 전에 항상 호출되는지와 실패 시 중단되는지를 별도로 검증해야 합니다.
기존 도구와 비교할 때 볼 차이
DepTrust의 강점은 여러 패키지 생태계에 대해 단일 패키지와 버전을 빠르게 조회하고, 그 결과를 AI 에이전트가 소비하기 쉬운 형태로 제공한다는 데 있습니다. 반면 이미 생성된 전체 잠금 파일이나 저장소의 의존성 그래프를 지속적으로 관리하는 기능이 필요한 경우에는 기존 생태계 감사 명령, 저장소 보안 알림, 의존성 업데이트 도구와 역할이 다를 수 있습니다.
따라서 기존 보안 검사를 교체할 도구로 보기보다 에이전트가 의존성을 추천하거나 설치하기 직전의 사전 확인 단계로 평가하는 편이 현실적입니다. 기존 파이프라인이 잠금 파일 전체를 검사하고 있다면 중복되는 결과보다, AI가 제안한 단일 버전을 변경 전에 차단하는 기능이 실제로 검토 시간을 줄이는지 측정해야 합니다.
실사용 전 체크리스트
- 프로젝트에서 사용하는 모든 패키지 생태계가 지원 목록에 포함되는가?
- 각 생태계에서 OSV와 GitHub Advisory Database의 범위가 전체인지 부분인지 확인했는가?
- 알 수 없음, 부분 조회, API 오류를 허용으로 간주하지 않도록 구성했는가?
- 허용 판정 뒤에도 라이선스, 유지보수 상태, 소스 신뢰성, 호환성을 별도로 확인하는가?
- 에이전트가 검사 결과를 무시하고 설치를 계속하지 않는지 실제로 시험했는가?
- GitHub 토큰을 사용한다면 최소 권한, 만료 시간, 로그 노출 여부를 점검했는가?
- 도구 버전과 JSON 출력 형식을 고정해 자동화가 예기치 않게 깨지지 않도록 했는가?
- 기존 감사 도구와 함께 실행했을 때 추가로 줄어드는 검토 시간이나 오류가 있는가?
출처와 검증
기능 범위, 지원 생태계, 판정 규칙과 설치 방법은 DepTrust 공식 GitHub 저장소에서 확인할 수 있습니다. 저장소의 구현과 문서는 업데이트될 수 있으므로 적용 전 README의 지원 표, 인증 방식, 출력 필드, 최신 릴리스 변경 사항을 다시 확인하는 것이 좋습니다.