에스코어 인사이트
원문에 앞서 AI 에이전트가 소프트웨어 의존성을 선택하는 환경에서 개발·보안·플랫폼 조직이 함께 점검할 사항을 정리했습니다.
•
의존성 선택 시점에 최신 인텔리전스와 정책을 적용: AI 에이전트가 패키지를 설치하거나 빌드 파일을 바꾸기 전에 버전, 취약점, 악성코드, 라이선스, 프로젝트 상태, 내부 정책을 확인하도록 해야 합니다.
•
AI의 선택 과정을 추적할 수 있는 기록을 남김: 어떤 에이전트나 워크플로가 어떤 정보와 정책을 근거로 컴포넌트를 선택했는지, 사람의 승인이 있었는지를 함께 기록하면 이후 검토와 운영 책임이 더 명확해집니다.
•
에이전트의 자율 범위와 권한을 사전에 제한: 에이전트별 접근 권한, 다른 에이전트나 외부 도구를 호출할 수 있는 범위, 사람이 반드시 승인해야 하는 고위험 작업을 명확히 정해야 합니다.
Sonatype 원문 번역
AI 덕분에 아이디어를 실제로 동작하는 소프트웨어로 구현하는 데 걸리는 시간이 크게 줄었습니다. 개발자가 기능, 연동 방식, 서비스를 설명하면 몇 분 안에 구현 결과를 받을 수 있습니다. 코딩 에이전트는 한 단계 더 나아가 파일을 수정하고, 테스트를 실행하고, 오류를 해결하고, 검토할 변경 사항까지 준비합니다.
하지만 코드를 만드는 일은 소프트웨어를 배포하고 유지하는 과정의 일부일 뿐입니다. 생성된 코드는 이해하고 테스트하고 보안을 점검하고 업데이트해야 하며, 언젠가는 사용을 종료해야 합니다. AI가 선택한 모든 컴포넌트도 결국 조직이 책임지고 관리해야 할 대상이 됩니다.
여기서 잘 드러나지 않던 새로운 엔지니어링 문제가 생깁니다. AI는 단순히 코드 양만 늘리는 것이 아닙니다. 코드가 의존할 패키지와 버전부터 프레임워크, API, 모델, 서비스, 설정까지 AI가 결정하는 대상도 늘어납니다. 개발 환경에 접근 권한을 받은 코딩 에이전트는 개발자가 모든 변경을 사전에 검토하지 않아도 의존성과 구성에 관한 판단을 실행에 옮겨 의존성을 선택하고 설치하거나 빌드 파일을 수정할 수 있습니다.
결국 소프트웨어가 늘어나는 데서 그치지 않습니다. 조직이 관리해야 할 의존성은 더 빠르게 증가하고, 많은 의존성이 왜 개발 환경에 들어왔는지는 오히려 파악하기 어려워집니다.
병목은 개발 이후 단계로 이동한다
AI는 아이디어를 초기 구현물로 만드는 데 걸리는 시간을 줄일 수 있습니다. 하지만 그 이후에 필요한 작업까지 없애 주지는 않습니다. 오히려 후속 작업을 늘립니다.
에이전트가 선택한 모든 패키지는 조직이 다음과 같이 관리해야 합니다.
•
유지보수 상태, 호환성, 보안, 라이선스, 내부 정책을 평가합니다.
•
위험과 프로젝트 상황이 어떻게 변하는지 지속적으로 모니터링합니다.
•
더 이상 요구사항을 충족하지 못하면 업데이트하거나 다른 컴포넌트로 교체합니다.
애플리케이션, 릴리스, AI가 만든 변경 사항이 많아질수록 관리 작업도 함께 늘어나고 병목의 위치도 달라집니다. 코드를 작성하는 일은 쉬워지는 반면, 만들어진 소프트웨어를 이해하고 유지하는 일은 더 어려워집니다.
모든 프롬프트가 의존성 결정으로 이어질 수 있다
간단해 보이는 요청을 하나 생각해 보겠습니다. 고객 데이터를 받아 검증하고 저장한 뒤 알림을 보내는 서비스를 만들어 달라는 요청입니다.
AI 어시스턴트나 에이전트는 이 요청을 구현하면서 다음과 같은 기술과 구성 요소를 선택할 수 있습니다.
•
웹 프레임워크, 검증 라이브러리, 데이터베이스 클라이언트
•
인증, 로깅, 메시징, 테스트 패키지
•
컨테이너 이미지, 인프라 설정, 외부 서비스
개발자가 요청한 기능은 하나지만 실제 구현에는 수십 개의 직접·전이 의존성이 추가될 수 있습니다. 선택한 패키지와 구성은 유지보수성, 호환성, 라이선스, 보안뿐 아니라 나중에 애플리케이션을 업그레이드할 수 있는지에도 영향을 줍니다.
AI 모델에는 의존성과 구성 요소를 제대로 선택하는 데 필요한 최신 정보가 기본적으로 내장되어 있지 않습니다. 학습 데이터만으로는 패키지 레지스트리의 현재 상태, 새로 공개된 취약점, 최근 발견된 악성코드, 프로젝트 유지 상태, 조직 내부 정책을 안정적으로 반영하기 어렵습니다.
에이전트가 추천한 패키지를 직접 설치하고, 빌드를 수정하고, 사람의 확인 없이 계속 작업할 수 있게 되면 위험은 더 커집니다. 잘못된 추천이 채팅창 안의 문장으로 끝나지 않고 실제 애플리케이션의 일부가 될 수 있기 때문입니다.
에이전트 간 개발은 위험을 더 키운다
에이전트가 다른 에이전트에게 작업을 맡기기 시작하면 문제는 더 복잡해집니다. 주 에이전트가 전문 에이전트 한 명에게 구현 방식을 조사하게 하고, 다른 에이전트에게 코드를 생성하거나 리팩터링하게 한 뒤, 또 다른 에이전트에게 테스트와 문제 해결을 맡길 수 있습니다.
각 위임 단계마다 서로 다른 도구와 정보 출처, 전제, 선호 패키지가 영향을 미칠 수 있습니다. 한 에이전트는 온라인 예제를 참고해 라이브러리를 고르고, 다른 에이전트는 테스트 도구를 추가하고, 또 다른 에이전트는 빌드를 통과시키려고 배포 설정을 바꿀 수 있습니다. 개발자가 결과물을 검토할 때쯤이면 어떤 의존성과 설정이 어떤 과정을 거쳐 선택됐는지 전체 경위를 한 사람이 모두 파악하기 어려울 수 있습니다.
에이전트 간 개발은 별도로 더 깊이 다뤄야 할 주제입니다. 의사결정이 여러 에이전트로 분산될수록 의사결정 과정의 기록도 더 오래 보존할 수 있어야 합니다.
컴포넌트 목록에서 의사결정 기록으로
에이전트형 개발에서는 소프트웨어 관련 결정이 여러 에이전트, 도구, 워크플로로 분산됩니다. 따라서 기존처럼 어떤 컴포넌트가 쓰였는지만 파악해서는 충분하지 않습니다.
소프트웨어 자재 명세서(SBOM)는 개발자가 직접 선택하지 않은 의존성을 포함해 어떤 컴포넌트가 사용됐는지 식별할 수 있습니다. 저장소 통제로 컴포넌트의 공급 출처를 관리할 수 있고, 소프트웨어 구성 분석(SCA)은 알려진 취약점과 라이선스 문제를 찾아낼 수 있습니다.
하지만 목록만으로는 해당 컴포넌트가 왜 선택됐는지까지 설명하기 어렵습니다. 에이전트가 컴포넌트를 추가했다면 엔지니어링 조직은 경우에 따라 다음 정보까지 파악해야 합니다.
•
어떤 에이전트 또는 워크플로가 선택했는가?
•
어떤 정보 출처와 버전 정보를 근거로 판단했는가?
•
어떤 대안을 검토했는가?
•
당시 어떤 조직 정책이 적용됐는가?
•
사람이 승인했는가, 아니면 자동으로 허용됐는가?
의사결정 주체와 근거, 검토한 대안, 적용 정책, 승인 여부에 관한 정보는 소프트웨어를 만드는 데 관여한 에이전트, 지시사항, 도구, 데이터 소스, 권한, 이전 단계의 선택으로 구성되는 새로운 '에이전트 공급망'의 일부가 됩니다.
다만 에이전트 자체가 소프트웨어 의존성인 것은 아닙니다. 에이전트는 의존성을 만들어 내는 의사결정과 실행의 연결 고리에 참여합니다. 의사결정과 실행의 연결 고리를 관리하려면 최종 산출물뿐 아니라 산출물을 만든 과정까지 확인할 수 있어야 합니다.
기존 검토 프로세스로는 전체 부담을 감당할 수 없다
코드 리뷰는 여전히 중요하지만, 기계가 내린 모든 의존성 결정을 역추적하도록 설계된 절차는 아닙니다. 리뷰어는 패키지가 추가된 사실은 볼 수 있어도 더 안전한 버전이 있었는지, 프로젝트가 활발히 유지보수되고 있는지, 에이전트가 승인된 대안 대신 해당 패키지를 선택한 이유까지는 알기 어렵습니다.
SCA는 컴포넌트를 식별하고 소프트웨어 개발 수명주기(SDLC) 전반에서 오픈소스 위험을 지속적으로 모니터링하는 데 여전히 필수적입니다. 한계는 취약점과 라이선스 등 SCA 정보를 의존성이 이미 선택된 뒤에야 적용할 때 생깁니다. 선택이 끝난 시점에는 해당 컴포넌트가 이미 구현 방식에 영향을 줬을 가능성이 있고, 교체하려면 코드, 테스트, 연동, 설정 전반을 다시 손봐야 할 수도 있습니다.
에이전트가 결정을 내리는 속도에 맞춰 개발자에게 모든 결정을 일일이 조사하라고 요구해서는 안 됩니다. 지속 가능한 방식으로 운영하려면 의존성을 선택하는 시점에 신뢰할 수 있는 최신 정보와 실제로 강제 적용할 수 있는 정책을 함께 제공해야 합니다.
에이전트형 워크플로에 가드레일을 내장하라
조직은 다음 역량을 갖춰야 합니다.
•
최신 의존성 인텔리전스: 에이전트가 사용 가능한 버전, 취약점, 악성코드, 라이선스, 프로젝트 품질, 더 안전한 대안을 실시간에 가깝게 확인할 수 있어야 합니다.
•
실행 전 정책 적용: 승인된 출처, 컴포넌트 표준, 위험 기준을 패키지가 설치되거나 해당 패키지를 전제로 코드가 만들어지기 전에 적용해야 합니다.
•
에이전트 식별 및 권한 범위 제한: 어떤 에이전트가 작업을 수행했는지 식별할 수 있어야 하며, 필요한 도구, 저장소, 자격 증명, 환경에만 접근하도록 권한을 제한해야 합니다.
•
의사결정 이력: 중요한 결정마다 의사결정 주체, 사용한 정보, 사람의 승인 필요 여부를 기록해야 합니다.
•
위임 제한: 에이전트가 다른 에이전트나 외부 도구를 호출할 수 있는 조건과, 반복적인 위임을 중단하고 사람이 검토해야 하는 지점을 워크플로에 정의해야 합니다.
•
지속적인 모니터링: 선택 당시에는 허용할 수 있었던 컴포넌트도 이후 취약해지거나 악성으로 판명되거나 유지보수가 중단되거나 정책과 맞지 않게 될 수 있습니다.
통제 강도는 예상되는 영향에 맞춰야 합니다. 위험이 낮은 제안과 운영 서비스를 새로 도입하거나 외부로 데이터를 공유하거나 권한을 변경하는 작업을 같은 방식으로 다룰 수는 없습니다. 영향이 크고 되돌리기 어려운 작업일수록 더 강한 근거와 명시적인 승인이 필요합니다.
선택 시점에 인텔리전스를 제공하라
에이전트가 구현과 유지보수 업무를 더 많이 맡게 되면 한 명의 개발자가 자율형 워크플로 전반에서 만들어지는 모든 의존성 결정을 책임지기는 어렵습니다. 이제 운영 체계에서도 책임을 나눠야 합니다. 경영진은 자율 범위를 정하고, 플랫폼 엔지니어링 조직은 표준화된 개발 경로와 통제 수단을 만들고, 보안 조직은 위험 정책을 자동화하며, 구매·법무 조직은 서드파티 도구 사용 범위를 정해야 합니다.
공통 목표는 사람이 AI 결과물을 더 많이 수동 검토하는 것이 아닙니다. 허용 가능한 선택은 일상적인 절차로 처리하고, 의심스러운 선택은 쉽게 드러나게 하며, 영향이 큰 선택은 신중하게 판단하도록 해야 합니다.
허용 가능한 선택은 일상적으로 처리하고 영향이 큰 선택은 신중하게 판단하려면, 에이전트형 개발을 하나의 운영 시스템으로 관리해야 합니다. 각 의사결정을 추적하고, 정해진 경계를 강제하며, 책임자를 명확히 할 수 있어야 합니다. 각 워크플로가 모델의 기억에만 의존해 의존성을 선택하고 나중에 문제를 고치게 하기보다, 최신 소프트웨어 공급망 인텔리전스를 개발자와 에이전트가 실제로 사용하는 도구에 직접 제공할 수 있습니다.
관리 책임 없이 속도만 높이면 결국 기술 부채로 돌아옵니다. 에이전트형 개발이 확대될수록 조직은 세 가지 질문에 답할 수 있어야 합니다. 이 의존성을 어떤 에이전트가 추가했는가? 왜 이 의존성이 필요한가? 지금은 누가 책임지고 있는가?
Sonatype Guide가 선택 시점에 최신 소프트웨어 인텔리전스를 제공해 AI의 의존성 결정을 관리하는 데 어떻게 도움을 주는지 확인해 보세요.
에스코어는 Sonatype 공식 파트너로서 소프트웨어 공급망 보안 및 오픈소스 거버넌스 구축을 지원합니다.
도입이나 구축이 필요하시면 언제든 문의해 주세요.
지원 솔루션: Nexus Repository · Repository Firewall · Lifecycle · Sonatype Guide