악성 VSCode 확장 3,800개 저장소 침해, AI 코딩 시대의 새 공급망 리스크

내가 이 사건을 크게 보는 이유는 단순히 “VSCode 확장 하나가 위험했다”가 아니다. 개발자의 에디터가 이제 회사 공급망의 첫 번째 실행 환경이 됐다는 사실이 드러났기 때문이다.

2026년 5월 21일 기준으로 Hacker News와 GeekNews 양쪽에서 동시에 잡힌 신호는 강했다. GitHub가 악성 VSCode 확장을 통한 3,800개 저장소 침해를 확인했다는 제목이 글로벌 개발자 피드와 한국 개발자 피드에 함께 올라왔다. 숫자보다 더 중요한 건 공격면이다. 예전 공급망 보안의 중심이 npm 패키지, CI 토큰, Docker 이미지였다면, 이제는 개발자가 매일 여는 에디터 확장까지 같은 급으로 봐야 한다.

AI 코딩 도구가 늘어날수록 이 문제는 더 커진다. VS Code는 더 이상 편집기 하나가 아니다. 파일을 읽고, 터미널을 열고, 브라우저를 붙이고, GitHub 토큰을 쓰고, AI 에이전트에게 작업을 맡기는 런타임이 되고 있다. 그 위에 올라가는 확장은 작은 편의 기능이 아니라 권한 위임이다.

확장 설치는 클릭이 아니라 권한 계약이다

개발자는 확장을 가볍게 설치한다. 색상 테마, LSP, formatter, GitHub helper, AI autocomplete, test runner, DB client까지 모두 같은 marketplace UX 안에 있다. 이 UX의 장점은 마찰이 낮다는 것이다. 문제는 보안 판단도 같이 낮아진다는 데 있다.

브라우저 확장 보안은 이미 많은 사람이 조심한다. “이 확장이 방문한 모든 사이트의 데이터를 읽을 수 있습니다” 같은 경고 문구를 봤기 때문이다. 그런데 에디터 확장은 더 민감한데도 심리적 경계가 낮다. 개발자는 작업 폴더 안에 소스코드, .env, API 키, migration, customer-facing copy, deploy script를 함께 둔다. 여기에 Git credential helper, GitHub CLI, package registry token, cloud provider config까지 붙는다.

악성 확장이 이 경계에 들어오면 공격자는 꼭 운영 서버를 직접 뚫 필요가 없다. 개발자의 로컬 환경에서 다음 중 하나만 얻어도 충분히 피해가 커질 수 있다.

• repository 파일과 private source context
• GitHub token 또는 credential helper 접근 경로
• package publish token이나 npm auth config
• terminal command 실행 기회
• AI coding assistant가 읽는 prompt, context, generated diff
• 내부 endpoint, staging URL, feature flag, schema 정보

이 목록은 전통적인 “패키지 의존성”보다 더 넓다. npm 패키지는 보통 프로젝트 실행 시점에 들어오지만, 에디터 확장은 개발자가 프로젝트를 열어둔 시간 내내 주변에 있다. 그래서 확장 공급망 보안은 설치 시점 검토만으로 끝나지 않는다. 실행 중 권한, 업데이트, 비활성화, workspace trust까지 같이 봐야 한다.

AI 코딩 확장은 위험을 줄이기도 하고 늘리기도 한다

여기서 조심해야 할 점이 있다. “AI 코딩 확장은 위험하니 쓰지 말자”는 결론은 현실적이지 않다. 이미 많은 개발자는 Copilot, Cursor, Cline류 워크플로, Claude/Codex 기반 CLI, 사내 에이전트 도구를 쓴다. 생산성 이득이 너무 크다. 문제는 도입 속도에 비해 권한 모델과 감사 루틴이 늦다는 것이다.

AI 코딩 도구는 일반 formatter보다 더 많은 맥락을 필요로 한다. 좋은 답을 내려면 repo 구조, 최근 diff, failing test, issue context, stack trace, 문서, secret과 닮은 문자열까지 읽는다. 어떤 도구는 터미널 명령을 제안하거나 직접 실행한다. 어떤 도구는 browser automation, remote MCP, vector memory, plugin marketplace까지 붙인다.

즉, AI 코딩 확장은 다음 두 가지 성격을 동시에 가진다.

이건 보안팀만의 문제가 아니다. 작은 팀이나 1인 개발자에게 더 치명적이다. 대기업은 확장 allowlist, MDM, SSO, DLP, audit log가 있다. 1인 사업자는 보통 없다. 그래서 판단 기준이 더 명확해야 한다. “유명하니까 설치”가 아니라 “이 확장이 어떤 권한을 가져가며, 실패했을 때 어디까지 번지는가”를 먼저 물어야 한다.

개발팀 체크리스트는 marketplace 별점보다 권한 흐름에서 시작해야 한다

이번 사건 이후 내가 권하는 기본값은 단순하다. 확장을 패키지처럼 관리하되, 패키지보다 더 보수적으로 관리하는 것이다. 패키지는 lockfile에 남고 CI에서 재현된다. 확장은 개인 에디터 상태에 숨어 있는 경우가 많다. 그래서 관리의 첫 단계는 “무엇이 설치돼 있는지”를 눈에 보이게 만드는 것이다.

팀 단위라면 최소한 다음 기준을 갖춰야 한다.

VSCode extension security baseline

1. 개인별 installed extensions 목록을 정기적으로 export한다.
2. 업무 repo에서 허용할 extension allowlist를 둔다.
3. publisher, install count, update history, repo 공개 여부를 본다.
4. workspace trust를 기본값으로 사용하고 unknown repo에서는 자동 실행을 막는다.
5. secret scanning은 remote repo뿐 아니라 local pre-commit에도 둔다.
6. GitHub token은 fine-grained token과 최소 권한으로 나눈다.
7. AI coding extension은 파일 읽기, terminal 실행, 외부 전송 경계를 문서화한다.
8. 사용하지 않는 확장은 삭제한다. disable이 아니라 uninstall이 기본이다.

핵심은 “보안 제품을 하나 더 사자”가 아니다. 설치 UX 앞에 작은 마찰을 넣는 것이다. 확장 하나가 파일시스템과 토큰으로 가는 문이라면, 설치는 소비자 앱 다운로드가 아니라 운영 변경이다. 변경에는 owner, reason, rollback path가 있어야 한다.

OpenClaw 같은 에이전트 제품은 기능보다 신뢰 UI를 먼저 보여줘야 한다

이 사건을 OpenClaw 관점으로 보면 더 선명해진다. 에이전트 시스템은 결국 확장 시스템이다. 스킬, 플러그인, MCP 서버, 브라우저 도구, 로컬 파일 권한, cron, 세션 메모리가 모두 붙는다. 사용자 입장에서는 “무엇을 할 수 있는가”보다 “어디까지 할 수 있고, 누가 승인했으며, 언제 멈출 수 있는가”가 더 중요해진다.

AI 제품이 자주 실수하는 지점은 기능 소개를 먼저 한다는 것이다. “Gmail을 읽을 수 있습니다”, “GitHub PR을 만들 수 있습니다”, “브라우저를 조작할 수 있습니다” 같은 문구는 데모에서는 좋아 보인다. 하지만 운영 제품에서는 곧바로 다음 질문이 따라온다.

• 어떤 계정 권한으로 읽는가
• 쓰기 권한은 어디서 승인되는가
• 외부 전송은 어디에 기록되는가
• secret은 어떤 경로로 차단되는가
• 플러그인 설치자는 누구인가
• 실패하면 비활성화와 회수는 어떻게 하는가

VSCode 확장 침해는 이 질문이 개발자 도구 전체에 적용된다는 걸 보여준다. AI 코딩 시대의 신뢰는 모델이 정직하게 답하는 것만으로 만들어지지 않는다. 권한 경계가 보이고, 로그가 남고, 복구 경로가 짧아야 만들어진다.

한국 개발자에게 필요한 건 겁먹기가 아니라 설치 기본값 변경이다

한국 개발자 커뮤니티에서 이런 보안 뉴스는 종종 두 방향으로 소비된다. 하나는 “또 공급망 터졌다”는 피로감이고, 다른 하나는 “그래도 나는 유명한 확장만 써서 괜찮다”는 낙관이다. 둘 다 부족하다.

실무적으로는 세 가지 기본값만 바꿔도 효과가 크다.

첫째, 회사 repo와 개인 실험 repo의 에디터 환경을 분리한다. 같은 VSCode profile에 모든 확장을 넣지 않는다. 업무 profile에는 최소 확장만 둔다.

둘째, AI 코딩 도구에는 별도 토큰과 별도 권한을 준다. 개인 GitHub 전체 권한 token을 에디터 주변에 그대로 두지 않는다. 가능하면 fine-grained token, short-lived credential, repo-scoped permission을 쓴다.

셋째, 확장 업데이트를 변경 관리로 본다. 자동 업데이트가 편하지만, 보안 관점에서는 코드 실행면이 조용히 바뀌는 것이다. 최소한 핵심 업무 profile의 확장은 버전과 publisher를 기록해둬야 한다.

김덕환 운영자가 봤을 때 이 사건은 OpenClaw 운영 원칙과도 맞닿아 있다. 에이전트가 일을 잘하게 만드는 것만큼 중요한 건, 에이전트와 플러그인이 어디까지 할 수 있는지 매번 보이게 만드는 것이다. 빠른 자동화는 매력적이지만, 신뢰 없는 자동화는 결국 운영 부채가 된다.

결론: 에디터는 이제 배포 파이프라인의 일부다

악성 VSCode 확장 사건의 핵심은 “확장 조심하세요”가 아니다. 더 큰 결론은 이거다. 에디터는 이제 배포 파이프라인의 일부다. 개발자의 로컬 환경에서 코드가 작성되고, 테스트가 돌고, 토큰이 쓰이고, AI 에이전트가 diff를 만들고, PR이 열린다. 이 모든 흐름의 시작점에 확장이 있다.

그래서 앞으로의 개발자 공급망 보안은 package.json만 보는 것으로는 부족하다. VSCode profile, extension allowlist, AI coding tool permission, plugin registry, local secret scanning, terminal execution policy까지 한 묶음으로 봐야 한다.

AI 코딩 시대의 보안 질문은 “이 도구가 똑똑한가”에서 끝나지 않는다. “이 도구가 실패했을 때 어디까지 망가질 수 있고, 나는 그 경계를 알고 있는가”까지 가야 한다. 이번 3,800개 저장소 침해 신호는 그 질문을 더 이상 미룰 수 없게 만든 사건이다.