AI가 코드를 대신 써주는 시대, 개발자는 이제 편안하게 필요한 라이브러리를 가져다 쓰기만 하면 되는 듯했다. 하지만 지난 3월 24일, 이 안일한 믿음이 흔들리는 사건이 발생했다. 인기 있는 파이썬 라이브러리인 liteLLM의 PyPI 패키지가 악성 코드에 감염된 것이다. `pip install` 명령 한 줄만으로 사용자 환경의 API 키가 외부로 유출될 수 있는 구조였다. 오픈클로(OpenCLO)와 같이 liteLLM을 사용하던 많은 개발팀은 즉시 점검에 들어갔다. 3시간 남짓한 짧은 노출 시간 동안 하루 340만 건의 다운로드가 발생했고, 보안 기업 Wiz에 따르면 클라우드 환경의 36%에 liteLLM이 설치되어 있었다. 이 사건은 외부 의존성에 기대는 방식 자체가 얼마나 심각한 공격 경로가 될 수 있는지 여실히 보여준다.
공급망 보안의 역설: AI가 촉발한 '제로 디펜던시'
이번 liteLLM 감염 사태는 개발 생태계의 깊숙한 곳을 찌른다. 외부 패키지는 개발 속도를 높이는 핵심 동력이었지만, 이제는 치명적인 보안 취약점으로 작용한다. AI가 코드를 생성하고 보조하는 능력은 역설적으로 이러한 공급망 보안의 부담을 줄이는 새로운 길을 열었다. 과거에는 직접 모든 것을 만드는 비용이 너무 높았지만, AI 덕분에 이제는 '제로 디펜던시(Zero Dependency)' 전략이 현실적인 선택지가 된 것이다.
AI는 단순히 코드를 "빨리" 짜는 것을 넘어 "처음부터" 만드는 과정을 훨씬 효율적으로 만든다. 이로 인해 개발자들은 기존의 모던 스택에 대한 의존도를 줄이고, Rust, Go, Zig 같은 시스템 언어로 전환하는 사례를 늘린다. AI 코딩 도구는 이러한 시스템 언어로의 전환 난이도를 실질적으로 낮춘다. 메모리 안정성과 실행 속도를 확보하면서도 운영 리소스는 줄이는 구조는 매력적이다. 적은 인프라로 같은 기능을 운영할 수 있기에 비용 절감 효과가 즉각적으로 체감된다. 이는 기존 시장의 주류 언어 재편을 가속화할 수도 있다.
결국 이 흐름이 계속된다면, 보안을 이유로 외부 패키지 의존성을 최소화하려는 움직임은 더욱 강해진다. 당장의 편리함을 위해 무분별하게 외부 라이브러리를 추가하는 행위는 큰 리스크를 동반한다는 인식이 확산된다. 대신, AI의 도움을 받아 핵심 기능을 직접 구현하고, 꼭 필요한 최소한의 검증된 의존성만을 사용하는 개발 문화가 자리 잡을 것이다. 이는 보안 비용 절감과 함께 독자적인 기술 스택을 구축하는 기업들에게 경쟁 우위를 제공한다. 반대로 외부 의존성 관리에 소홀하거나 자체 구축 역량이 부족한 기업은 예측 불가능한 보안 위협에 노출될 가능성이 커진다.
AI 에이전트 시대, 코드보다 '스킬'과 '워크플로'가 돈이 된다
AI 개발의 무게중심이 '가져다 쓰기'에서 '직접 만들기'로 이동하는 또 다른 축은 바로 AI 에이전트의 발전이다. 더 이상 AI 코딩 도구에 열광하기보다, 에이전트가 바로 쓸 수 있는 '스킬'과 '워크플로'를 만드는 것에 관심이 쏠린다. 개발자 이일민(Toby Lee)는 AI 동료와 협업하여 자신의 블로그 시스템을 구축했다. 그는 글 작성자를 토비, AI, 토비+AI 세 가지로 구분하며, AI에게 반복적인 글쓰기 작업을 맡기고 자신은 아이디어 구상과 검토에 집중한다. 이는 AI가 단순한 코딩 보조를 넘어 실제 '동료'로서 업무 흐름에 깊숙이 통합되는 현실을 보여준다.
앞서가는 개발자들은 에이전트용 CLI(Command Line Interface)를 직접 만들어 에이전트 스킬과 연결한다. 매번 코드를 생성하는 방식은 토큰 낭비일 뿐만 아니라 결과가 결정론적(deterministic)이지 못해 안정성이 떨어진다. 대신 CLI는 컨텍스트 효율을 높이고 안정적인 실행을 보장한다. 에이전트가 `bash`나 `repl`과 같은 코드 환경, `sandbox`와 같은 격리된 환경에서 동작하기 시작하면서, 잘 정의된 CLI는 필수적인 요소가 된다. 에이전트용 CLI를 설계할 때는 다음과 같은 원칙을 따른다. 모든 입력을 `--flag`로 받아야 한다. 대화형 프롬프트는 에이전트를 멈추게 한다. `--help`에는 설명이 아닌 `mycli deploy --env staging` 같은 구체적인 예시가 필수다. 명령은 멱등(idempotent)하게 만들어야 한다. 에이전트는 끊임없이 재시도하기 때문이다. 파괴적인 작업 전에 검증 단계를 넣기 위해 `--dry-run`과 `--yes`를 분리해야 한다.
이러한 변화는 깃허브(GitHub)의 역할까지 확장한다. 이제 코드를 잘 짜는 것만이 스타를 받는 조건이 아니다. 코드가 아닌 스킬 파일, 즉 에이전트가 바로 쓸 수 있는 워크플로와 설정에 스타가 몰린다. 투자 자료에서 깃허브 스타 지표를 직접 공유하는 사례까지 등장했다. 개발 경험이 없는 마케터나 PM도 자신의 업무 워크플로를 스킬로 정리하여 공개할 수 있는 시대가 온 것이다. 에이전트 시대에는 그 도메인 지식 자체가 곧 가치가 된다.
결국, AI 에이전트의 발전은 소프트웨어 가치의 핵심을 '일반적인 코드 작성'에서 '특정 문제를 해결하는 정교한 워크플로와 스킬 정의'로 옮긴다. 이 흐름 속에서 승자는 자신의 전문 지식을 에이전트가 활용할 수 있는 형태로 구조화하고 자동화할 수 있는 개발자와 비개발자 모두가 될 것이다. 반면, AI가 이미 쉽게 생성할 수 있는 범용적인 코딩 능력에만 머무르는 이들은 경쟁력을 잃을 수 있다. 도구를 만드는 것과 그것을 팔아 돈을 버는 것 사이에는 여전히 간극이 존재하지만, 누군가의 시간을 줄여주거나 돈을 아껴주는 소프트웨어는 이 새로운 기술 위에서 분명히 더 많이 태어난다.
지금 당장 `pip show litellm` 명령어로 설치된 liteLLM 버전을 확인하라. 만약 1.82.7 또는 1.82.8 버전을 사용 중이라면 즉시 다운그레이드하거나 삭제하는 조치를 취해야 한다. 그리고 다음 단계로 나아가, 당신의 핵심 도메인 지식을 AI 에이전트가 활용할 수 있는 '스킬'과 '워크플로'로 정의하는 작업을 시작하라.