--- title: "AI 코딩 시대, 패키지 공급망은 ‘검증 카탈로그’로 막자는 액티브스테이트" published: 2026-05-02T16:05:03.201Z canonical: https://jeff.news/article/2075 --- # AI 코딩 시대, 패키지 공급망은 ‘검증 카탈로그’로 막자는 액티브스테이트 액티브스테이트가 AI 코딩 도구가 가져오는 오픈소스 의존성 위험을 줄이기 위해 큐레이티드 카탈로그 지원을 확대했다. 커서, 클로드 코드, 깃랩 듀오 같은 도구별 플러그인을 붙이는 대신, 패키지를 가져오는 경로 자체를 검증된 저장소로 돌리는 접근이다. ## AI 코딩 도구보다 의존성 경로가 더 위험해짐 - 액티브스테이트가 생성AI 코드와 오픈소스 공급망 위험을 줄이기 위한 큐레이티드 카탈로그 지원을 확대함 - 대상은 커서(Cursor), 클로드 코드(Claude Code), 깃랩 듀오(GitLab Duo), 탭나인(Tabnine), 윈드서프(Windsurf), 젯브레인스 AI(JetBrains AI) 같은 AI 코딩 도구들임 - 핵심은 AI 도구별 보안 플러그인을 붙이는 게 아니라, 패키지를 가져오는 경로 자체를 기업이 통제하는 구조임 - 문제는 AI 코딩 도구가 코드를 만들면서 공개 레지스트리의 패키지와 의존성을 자동으로 끌고 온다는 점임 - 프롬프트 하나가 새 의존성 요청으로 이어질 수 있음 - 그 요청이 기업 보안 기준을 거치지 않은 공개 저장소를 통과하면, 공격 표면이 기계 속도로 늘어남 - 액티브스테이트의 주장은 꽤 현실적임. 개발자는 하나의 AI 코딩 도구만 쓰지 않음 - 지금은 커서를 쓰다가, 나중엔 클로드 코드나 다른 도구로 넘어갈 수 있음 - 그래서 보안 계층은 특정 AI 도구가 아니라 의존성 소비 지점에 붙어야 한다는 논리임 > [!WARNING] > AI 코딩 도구가 만든 코드 자체만 보는 건 늦을 수 있음. 그 코드가 어떤 패키지를 어디서 가져왔는지 통제하지 못하면 공급망 리스크가 계속 새로 들어옴. ## 검증 카탈로그가 하는 일 - 큐레이티드 카탈로그는 AI 코딩 도우미가 패키지를 요청할 때 공개 레지스트리 대신 기업 정책으로 관리되는 검증 카탈로그에서 가져오게 만듦 - 보안 거버넌스를 코드 작성 후 스캔 단계가 아니라 의존성 소비 단계에 배치하는 방식임 - 개발자가 어떤 AI 도구를 쓰든, 실제 패키지 유입 경로를 공통 통제 지점으로 잡는 셈 - 규모도 작지 않음. 액티브스테이트는 12개 언어, 7900만 개 이상 구성 요소를 제공한다고 밝힘 - 각 구성 요소는 SLSA 레벨 3을 준수하는 인프라 안에서 소스 코드 기반으로 빌드됨 - 공개 레지스트리에서 이미 만들어진 패키지를 그대로 가져오는 방식과 다르게, 출처와 빌드 절차, 변경 이력을 남기는 구조임 - 기존 기업 개발 환경과의 호환성도 강조함 - JFrog Artifactory, Sonatype Nexus, GitHub Packages, AWS CodeArtifact, GitLab Package Registry, Google Artifact Registry, Azure Artifacts 등과 함께 쓸 수 있음 - 새 개발 도구나 CI/CD 환경을 통째로 바꾸지 않고도 검증된 구성 요소를 공급할 수 있다는 얘기임 ```mermaid sequenceDiagram participant 개발자 participant AI코딩도구 participant 패키지관리자 participant 검증카탈로그 participant 기업저장소 개발자->>AI코딩도구: 기능 구현 요청 AI코딩도구->>패키지관리자: 필요한 의존성 요청 패키지관리자->>검증카탈로그: 기업 정책에 맞는 패키지 확인 검증카탈로그->>기업저장소: 검증된 아티팩트 제공 기업저장소-->>패키지관리자: 승인된 패키지 반환 패키지관리자-->>개발자: 통제된 의존성 설치 ``` ## CVE 대응을 SLA로 묶는 게 포인트 - 액티브스테이트는 취약점 대응 시간을 계약상 서비스수준협약(SLA)으로 제시함 - 중요 CVE는 5영업일 이내 - 심각도 높음 CVE는 10일 이내 - 그 외 모든 CVE는 30일 이내 해결한다고 밝힘 - 기사에서는 업계 평균 해결 시간이 60일 이상으로 지연되는 상황과 비교함 - 이건 단순히 취약점 목록을 보여주는 것과 다름 - 오픈소스 커뮤니티에서 수정 사항이 나오면 액티브스테이트가 업데이트된 구성 요소를 자동으로 빌드하고 게시하는 구조임 - 보안팀이 CVE 백로그를 들고 개발팀을 쫓아다니는 부담을 줄이겠다는 방향임 > [!IMPORTANT] > 중요 CVE 5영업일, 높음 CVE 10일, 기타 CVE 30일이라는 SLA는 공급망 보안을 ‘탐지’가 아니라 ‘운영 책임’으로 보겠다는 메시지에 가까움. ## 국내 기업에도 바로 꽂히는 이유 - 국내 기업도 AI 코딩 도구 도입은 빠르게 늘고 있지만, 오픈소스 의존성 관리 수준은 조직마다 차이가 큼 - 금융, 공공, 제조, 플랫폼 기업은 개발 속도와 보안 검증, 규제 대응을 동시에 요구받음 - AI가 코드를 빨리 만들어도 패키지 출처와 취약점 대응을 설명하지 못하면 보안팀과 감사팀에서 막힐 수 있음 - 이 사례가 주는 메시지는 생성AI 코드 보안을 ‘AI 도구 보안’으로만 보면 안 된다는 것임 - 중요한 건 개발자가 어떤 도구를 쓰든 승인된 패키지와 감사 가능한 빌드 체계를 적용하는 것임 - SBOM, 출처 증명, 감사 추적, 취약점 해결 SLA가 앞으로 기업 개발 환경의 기본 체크리스트가 될 가능성이 큼 - 결국 보안 통제의 초점이 코드 작성 도구에서 의존성 공급망으로 이동하고 있음 - AI가 만든 코드의 품질도 중요하지만, 그 코드가 호출하는 오픈소스 구성 요소가 더 큰 리스크가 될 수 있음 - “AI 코딩 허용할 거냐”보다 “AI가 가져오는 의존성을 어디서 통제할 거냐”가 더 실전적인 질문이 됨 --- ## 기술 맥락 - 이 기사에서 중요한 선택은 AI 코딩 도구를 직접 통제하려 하지 않고, 패키지가 들어오는 길목을 통제하는 거예요. 왜냐하면 개발자가 쓰는 도구는 계속 바뀌지만, 의존성은 결국 패키지 관리자와 아티팩트 저장소를 통해 들어오거든요. - SLSA 레벨 3 기반 소스 빌드를 강조하는 이유는 패키지 출처를 설명해야 하기 때문이에요. 공개 레지스트리에서 받아온 바이너리를 그대로 믿는 대신, 어떤 소스에서 어떤 절차로 빌드됐는지 추적할 수 있어야 공급망 사고 때 방어 논리가 생겨요. - CVE SLA가 중요한 건 보안팀의 병목을 줄이기 위해서예요. AI 코딩 도구가 의존성을 빠르게 늘리면 취약점 목록도 같이 늘어나는데, 사람이 매번 우선순위를 정하고 패치 요청을 돌리는 방식은 속도를 못 따라가요. - 기존 Artifactory나 Nexus 같은 저장소와 붙는다는 점도 현실적인 선택이에요. 기업 입장에서는 보안 때문에 개발 파이프라인 전체를 갈아엎기 어렵고, 이미 쓰는 저장소 흐름 안에서 정책을 강제하는 쪽이 도입 저항이 낮거든요. - 국내 기업에선 이 접근이 특히 감사와 규제 대응에 연결돼요. 생성AI가 만든 코드가 실제 서비스에 들어갈수록, 코드 자체뿐 아니라 그 코드가 끌어온 오픈소스의 출처와 패치 상태까지 설명해야 하는 상황이 늘어날 수 있어요. ## 핵심 포인트 - 큐레이티드 카탈로그는 AI 코딩 도구가 공개 레지스트리 대신 기업 정책에 맞는 검증 패키지를 쓰도록 유도함 - 12개 언어, 7900만 개 이상 구성 요소를 제공하고 SLSA 레벨 3 준수 인프라에서 소스 기반 빌드를 수행함 - 중요 CVE는 5영업일, 심각도 높음 CVE는 10일, 그 외 CVE는 30일 이내 해결한다는 SLA를 제시함 - JFrog Artifactory, Sonatype Nexus, GitHub Packages, AWS CodeArtifact 등 기존 아티팩트 저장소와 호환됨 ## 인사이트 AI 코딩 보안의 핵심이 ‘AI가 무슨 코드를 썼나’에서 ‘그 코드가 어떤 의존성을 끌고 왔나’로 이동하는 중임. 국내 기업도 코딩 도구 도입만 볼 게 아니라 패키지 소비 지점과 감사 추적을 통제해야 할 타이밍임.