문제는 AI가 틀린다는 게 아니다
AI 코딩 도구를 팀에 도입할 때 대부분의 리드가 먼저 묻는 건 "이게 얼마나 빠른가"다. 그 다음이 "생성된 코드 품질은 어떤가". 그런데 내가 실제로 팀 워크플로우를 AI-First로 전환하면서 더 자주 맞닥뜨린 질문은 따로 있었다. "이 도구가 조용히 만드는 리스크는 무엇인가."
속도와 가드레일 이야기는 이미 많이 했다. 이번은 다른 각도다. AI 도구가 팀 안에 서서히 스며들면서 생기는, 눈에 잘 안 띄는 세 가지 의존성 리스크를 짚는다.
리스크 1: AI가 없는 패키지를 설치하게 만든다
pip install fastapi-turbo. 이 명령어를 그냥 실행하면 어떻게 될까.
보안 연구 프로젝트인 DepScope가 공개한 데이터에 따르면, AI 코딩 에이전트(Claude, GPT, Cursor, Copilot 등)가 생성한 코드에는 실제로 존재하지 않는 패키지 이름이 포함되는 경우가 있다. JFrog와 Lasso Security의 2024년 연구는 AI가 생성한 의존성 중 3~25%가 hallucination이라고 추정했다. 이걸 '슬롭스쿼팅(slopsquatting)'이라 부른다.
더 무서운 건 패턴이 예측 가능하다는 점이다. LLM은 패키지 이름을 무작위로 지어내지 않는다. -turbo, -pro, -easy, -ultra 같은 그럴듯한 접미사를 붙여 실제 패키지의 변형처럼 보이는 이름을 만든다. DepScope가 수집한 161개의 검증된 hallucination 사례 중 상위 항목을 보면 fastapi-turbo(17회), torch-lightning-easy(25회), typescript-utility-pack-pro(17회) 같은 이름들이 반복해서 등장한다.
결정적인 신호는 이거다. torch-lightning-easy라는 존재하지 않는 패키지 이름을 7개의 서로 다른 AI 에이전트가 독립적으로 만들어냈다. 즉, 이 이름은 신경망 구조상 '그럴듯하게' 보이는 이름이다. 공격자 입장에서는 AI가 높은 확률로 생성할 이름을 예측해서 미리 레지스트리에 등록해두면 된다. 이게 공급망 공격이 된다.
팀에서 AI가 생성한 코드를 리뷰 없이 바로 실행하는 문화가 있다면, 이 리스크는 지금 당장 실재한다.
실용 대응: DepScope는 MCP 서버 방식으로 AI 에이전트가 패키지를 설치하기 전에 레지스트리 존재 여부와 취약점을 검증하는 인프라를 무료로 제공한다. Cursor, Claude Desktop, Windsurf 설정에 mcp.depscope.dev/mcp 엔드포인트를 추가하면 된다. check_package, check_typosquat, find_alternatives 같은 22개 툴이 인증 없이 동작한다. 내일 당장 팀 워크플로우에 붙일 수 있는 수준이다.
리스크 2: 빠른 코드가 느린 디버깅을 숨긴다
OpenAI Codex가 ChatGPT에서 무료로 풀렸다. 수천 명의 개발자가 이미 일상적으로 쓰고 있다. 개발자 커뮤니티에서 공통적으로 언급되는 평가는 하나로 수렴한다. 빠르다. 그런데 품질은?
Claude와 Codex를 비교하는 논의가 반복해서 나오는 이유가 있다. Codex는 속도, Claude는 출력 품질. 문제는 '속도'가 즉각적으로 느껴지고, '품질 차이'는 나중에야 드러난다는 거다. 스프린트 속도는 올라가고, 오전 2시 디버깅 세션도 늘어난다.
AI가 생성한 코드가 테스트를 통과하고 배포됐는데, 한 달 뒤 예상치 못한 엣지 케이스에서 터지는 경험을 팀에서 해봤다면 이게 낯설지 않을 거다. AI가 로직 자체를 잘못 이해한 게 아니라, 코드가 특정 컨텍스트에서만 맞고 일반적으로는 틀린 경우가 많다. 빠른 완성이 이 패턴을 가린다.
팀 리드 입장에서 이건 단순 코드 품질 문제가 아니다. AI 생성 코드를 기준으로 PR 리뷰 기준이 암묵적으로 낮아지거나, "어차피 AI가 짠 거니까"라는 심리가 생기면 팀 전체의 품질 기준이 표류하기 시작한다.
리스크 3: 무료는 의존성을 파는 전략이다
세 번째 리스크는 가장 구조적이다. Codex 무료 제공 전략을 분석한 글이 dev.to에서 공유되며 반향을 일으켰다. 핵심 논지는 단순하다. 무료는 락인(lock-in)을 만드는 가장 오래된 성장 전략이다.
Slack, Figma, AWS 프리 티어가 모두 같은 패턴으로 작동했다. 스타트업이 AWS 크레딧으로 시작해 마이그레이션 비용이 감당 안 될 때쯤 크레딧이 소진되는 구조. OpenAI Codex는 이걸 실제 코드베이스와 인터페이스하는 도구로 실행하고 있다.
진짜 스위칭 비용은 구독료가 아니다. 팀 전체가 특정 도구의 프롬프트 패턴에 익숙해지고, 신규 입사자가 그 도구로 온보딩되고, 스프린트 속도 추정이 그 도구의 가속을 전제로 짜이고 나면—도구를 바꾸는 건 워크플로우를 처음부터 다시 짜는 것과 같다. 인지 부하, 새 습관 형성, 일시적 생산성 저하. 이게 실제 비용이다.
지금 무료로 쓰는 건 합리적이다. 그러나 팀의 워크플로우 자체가 특정 도구에 종속되는 구조는 피해야 한다. 프롬프트를 모델 중립적으로 작성하고, AI가 생성한 코드를 팀원이 직접 설명할 수 있어야 한다는 최소 기준은 지금 당장 세워두는 게 맞다.
세 리스크의 공통점
슬롭스쿼팅, 품질 표류, 도구 종속성. 이 세 가지는 모두 조용히 누적된다는 점에서 같다. 코드가 잘못 컴파일되거나 에러가 터지는 게 아니다. 표면상 멀쩡하게 돌아가는 것처럼 보이면서 팀의 공급망 보안 수준, 코드 품질 기준, 도구 선택 자유도가 천천히 잠식된다.
AI-First 전환의 속도를 올리는 것만큼이나, 이 세 가지 리스크를 팀 워크플로우 설계 단계에서 명시적으로 다루는 것이 지금 시점에서 더 중요한 일이라고 생각한다.
당장 할 수 있는 것: - AI 에이전트 설정에 DepScope MCP 서버 연결—패키지 설치 전 hallucination 검증을 워크플로우에 내재화한다 - AI 생성 코드 PR 리뷰 기준을 명문화한다—"설명 못 하면 머지 안 한다"는 최소 기준 하나면 충분하다 - 지금 팀이 쓰는 AI 도구 목록을 점검하고, 어떤 도구가 없어졌을 때 가장 타격이 큰지 가늠해본다
세 가지 모두 내일 당장 팀 미팅 안건으로 올릴 수 있는 수준이다.