같은 주에 벌어진 두 가지 일
한쪽에서는 Vibe Coding 도구 10종 실전 평가 결과가 쏟아졌다. Cursor가 벤치마크를 독주하고, Claude가 코드 품질에서 최고점을 받고, GitHub Copilot Agent Mode가 단순 반복 작업에서 압도적 속도를 보였다는 내용이다. 개발자들이 자연어로 프로덕션 수준의 코드를 뽑아내는 속도는 이제 논쟁거리가 아니다. 현실이다.
그리고 같은 주, GitHub이 확인했다. 직원 한 명이 악성 VSCode 확장을 설치한 결과 내부 저장소 3,800개가 침해됐다. 제로데이 없이, 익스플로잇 체인 없이, CVE 없이. 확장이 .env, .git/config, ~/.aws/credentials를 읽고 외부 서버로 POST한 것이 전부였다. VSCode 확장은 설치한 사용자의 파일시스템 권한을 그대로 갖는다. 이건 버그가 아니라 설계다.
두 사건을 나란히 놓으면 지금 AI-First 워크플로우가 어디에 서 있는지가 보인다. 도구는 무섭도록 강력해지고 있고, 그 도구가 돌아가는 환경은 무섭도록 구멍이 많다.
AI 코딩 어시스턴트는 이제 프로덕션 의존성이다
dev.to의 분석이 정확히 짚은 지점이다. AI 코딩 도구를 '스웨거 넘치는 자동완성'으로 보는 시각은 이미 틀렸다. 도구는 코드를 읽고, 코드를 쓰고, 의존성을 제안하고, 테스트를 초안 잡고, 실패를 설명한다. 그 과정에서 시크릿, 로그, 아키텍처 문서, 스택 트레이스, 고객 데이터 형태의 정보가 컨텍스트로 흘러 들어간다.
이 말은 AI 코딩 도구가 소프트웨어 공급망의 일부가 됐다는 뜻이다. 어떤 npm 패키지를 신뢰할지 따지듯, 어떤 AI 도구가 어떤 데이터에 접근하는지, 어떤 확장이 어떤 권한을 갖는지를 같은 기준으로 다뤄야 한다. '어떤 모델을 쓸까'는 작은 질문이다. '이 도구가 어떤 경계 안에서 동작하는가'가 진짜 질문이다.
Vibe Coding 실전 평가가 드러낸 것
10종 도구를 3주간 실전 테스트한 결과(dev.to, dextralabs)는 흥미롭다. React 대시보드 생성, Python API 비동기 버그 디버깅, 레거시 코드 리팩토링이라는 세 가지 실무형 태스크 기준으로 보면, Cursor가 전 영역에서 기준점이 됐다. 특히 디버깅 태스크에서 비동기 컨텍스트 매니저 이슈를 로그만 보고 정확히 짚어낸 부분은 '도구'가 아니라 '동료'에 가까운 경험이라는 평이 나왔다.
반면 GitHub Copilot Agent Mode는 단순 작업에서 압도적 속도를 보였지만, 복잡한 디버깅 태스크에서 근본 원인을 빗나간 수정안을 제시했다. 에러 처리 누락, 엣지 케이스 미고려는 공통적으로 보이는 패턴이었다. Claude는 코드 품질과 프로덕션 준비도에서 최고점을 받았으나 IDE 통합 부재로 '복붙 워크플로우'라는 현실적 마찰이 점수를 깎았다.
평가 결과가 말하는 핵심은 하나다. 도구마다 잘 위임할 수 있는 태스크의 종류와 경계가 다르다. 그리고 어떤 도구도 자신이 틀렸을 때 스스로 멈추지 않는다. AI는 확신에 차고, 빠르고, 형식도 완벽하게 틀릴 수 있다.
공격 표면이 된 개발자 워크스테이션
3,800개 저장소 침해 사고(dev.to, layzerzero105)를 'AI 도구 문제'가 아니라 '확장 문제'로 분리해서 보는 시각은 안일하다. Vibe Coding 워크플로우를 쓰는 팀일수록 피해가 컸다. 이유는 단순하다. AI-First 환경에서 개발자 머신에는 Anthropic API 키, OpenAI API 키, Supabase 서비스 롤 키, repo 스코프 GitHub PAT, Stripe 시크릿이 .env 파일 형태로 집약된다. 한 확장이 한 번 실행되면 이 전부가 읽힌다.
VSCode Marketplace는 iOS App Store처럼 큐레이션되지 않는다. 게시 장벽은 무료 Microsoft 계정 하나다. 리뷰는 대부분 자동화다. '결국엔 잡힌다'는 신뢰 모델이 작동한 결과가 이번 사고였다. AI 코딩 붐이 이 리스크를 키웠다. 매주 새로운 'Claude/GPT 파워드 10배 생산성' 확장이 등장하고, 대부분은 괜찮지만 일부는 그렇지 않다. 문제는 설치 전에 구별이 안 된다는 것이다.
AI-First 팀이 지금 당장 바꿔야 할 세 가지 구조
첫째, AI 출력을 낯선 사람의 PR처럼 다뤄라. 자신감 있는 커밋 메시지가 머지 근거가 되지 않듯, 잘 포맷된 AI 출력도 그 자체로 신뢰 근거가 되지 않는다. 기존 설계와의 정합성, 테스트의 실질성, 요청 범위 밖 동작 변경 여부를 사람이 확인하는 것이 프로세스여야 한다. 특별한 경외도, 특별한 공포도 없이.
둘째, 확장 화이트리스트를 팀 인프라 결정으로 격상하라. 어떤 확장을 설치할지는 더 이상 개인 취향이 아니다. 프라이빗 저장소, 토큰, 환경 변수에 접근 가능한 확장은 실행 가능한 공급망 결정이다. 팀 환경에서 허용 목록을 관리하고, 광범위한 파일시스템·네트워크 접근을 요청하는 확장을 정기적으로 감사하는 것이 위생이다. '2026년에 가장 강경한 팀이 할 일은 기본 위생'이라는 지적이 맞다.
셋째, 시크릿을 .env에서 꺼내라.
direnv + 1Password CLI, doppler, aws-vault 같은 시크릿 매니저는 진입장벽이 낮다. 악성 확장이 .env를 읽어도 유효한 값이 없는 구조가 목표다. 이것은 '나중에 할 일'이 아니라 AI-First 워크플로우 셋업의 전제 조건이다.
속도가 빠를수록 거버넌스가 먼저다
지금 팀에서 가장 자주 듣는 질문은 여전히 'AI가 이 태스크를 할 수 있나요?'다. 그 질문의 답은 이미 대부분 '어느 정도는 예스'다. 중요한 질문은 바뀌었다. 'AI가 틀렸을 때 우리 시스템이 잡아낼 수 있는가?' 그리고 'AI 도구가 우리 환경에 접근하는 방식이 감사 가능한가?'
AI 코딩 도구가 개발 속도를 높이는 것은 사실이다. Cursor가 3시간짜리 버그를 한 번의 컨텍스트 입력으로 짚어내는 경험은 실재한다. 하지만 그 속도가 검증 구조 없이 쌓이면, AI는 자신감 있게 틀린 코드를 배포 파이프라인에 밀어 넣는 가장 빠른 경로가 된다. 그리고 그 도구를 돌리는 머신이 공격 표면이 되면, 속도 자체가 침해 규모의 변수가 된다.
팀 리빌딩을 AI-First로 가져가는 지금, 내가 먼저 확인하는 것은 모델 선택이 아니다. AI가 움직이는 경계, 확장이 접근할 수 있는 범위, 출력이 통과해야 하는 검증 레이어다. 도구가 강력해질수록 그 도구가 작동하는 구조가 먼저여야 한다. 공급망 리스크는 도구를 느리게 쓰는 팀이 아니라, 빠르게 쓰면서 구조를 건너뛴 팀에게 먼저 온다.