코드 에디터는 개발자가 하루 8시간 이상 켜두는 도구다. 그 도구가 이제 공격의 진입점으로 지목되고 있다. 2025~2026년 여러 보안 매체는 비주얼 스튜디오 코드(Visual Studio Code, 이하 VS Code)의 확장 기능과 프로젝트 설정 파일을 악용한 악성코드를 잇따라 보도했다. Evelyn 스틸러, 글래스웜(GlassWorm), 비버테일(BeaverTail), 그리고 AI 코딩 비서 클로드봇(ClaudeBot)을 사칭한 확장까지 — 이름과 경로는 달라도 표적은 하나로 수렴한다. 바로 ‘개발자’다.
핵심은 개별 악성코드의 이름을 외우는 게 아니라, 왜 지금 개발 도구로 공격이 몰리는지, 어떤 조건에서 감염되고 어떤 경우엔 안전한지, 그리고 무엇부터 손봐야 하는지를 구분하는 것이다. 흩어진 보도를 한자리에 놓고 이 세 질문을 기준으로 정리했다.
왜 일반 PC가 아니라 ‘개발자 IDE’가 표적인가
공격자가 굳이 개발자를 노리는 이유는 단가 때문이다. 일반 사용자 한 명을 감염시키면 브라우저 비밀번호나 카드 정보 정도가 나오지만, 개발자 한 명의 계정에는 GitHub·npm 토큰, 클라우드 API 키(AWS·GCP), 사내 저장소 접근 권한이 함께 묶여 있다. 보도에 따르면 Evelyn 스틸러는 VS Code 확장을 통로로 삼아 이런 개발자 자격증명을 탈취하는 데 초점을 맞췄다. 계정 하나가 뚫리면 그 뒤의 CI/CD 파이프라인과 패키지 배포 권한까지 도미노처럼 넘어간다. 개발자가 배포하는 패키지를 다시 수천 명이 내려받기 때문에, 한 명의 감염이 그가 관리하는 라이브러리 사용자 전체로 번질 수 있다 — 이 확산 구조가 ‘공급망 공격(supply chain attack)’이라 불리는 이유다.
구조적 허점도 크다. VS Code 확장은 브라우저 확장과 결정적으로 다르다. 브라우저 확장은 샌드박스 안에서 제한된 API만 쓰지만, VS Code 확장은 설치되는 순간 사용자와 동일한 권한으로 Node.js 코드를 실행한다. 파일 읽기·쓰기, 셸 명령 실행, 외부 네트워크 연결에 사실상 제한이 없다는 뜻이다. 여기에 마켓플레이스가 ‘사후 심사’ 방식이라는 점이 겹친다. 올릴 때 걸러내는 게 아니라 신고·탐지 후 내리는 구조라, 악성 확장이 제거되기 전까지의 시차 동안 설치가 계속 쌓인다. 그래서 별점·다운로드 수만 보고 ‘많이 깔았으니 안전하겠지’ 하는 판단은 위험하다. 표적형 공격은 애초에 유명 확장의 이름·아이콘을 베낀 사칭 버전으로 그 신뢰를 훔쳐 쓴다.
글래스웜·비버테일·클로드봇: 침투 경로가 제각기 다르다
‘VS Code 악용’이라는 한 문장으로 묶이지만 실제 침투 경로는 셋으로 갈린다. 첫째, 글래스웜(GlassWorm)은 명령·제어(C2) 서버 주소를 블록체인 네트워크 솔라나(Solana)의 트랜잭션에 숨겨둔 점이 특징으로 보도됐다. 통상 방어는 악성 서버 도메인을 차단하는 방식인데, 주소가 블록체인에 박혀 있으면 특정 도메인을 막아도 다음 주소로 갈아타기 쉬워 통제선을 끊기 어렵다. 이름에 ‘웜(worm)’이 붙은 만큼 자기 전파 가능성까지 거론돼, 감염 하나가 끝이 아니라 확산의 시작일 수 있다는 점에서 단발성 스틸러보다 위험도가 높게 평가된다.
둘째, 비버테일(BeaverTail)은 확장이 아니라 프로젝트 폴더 안 설정 파일을 악용하는 방식으로 보도됐다. VS Code는 폴더를 열 때 .vscode/tasks.json에 정의된 작업을 자동으로 트리거할 수 있는데, 이 정상 기능을 역이용하면 사용자가 ‘수상한 파일’을 클릭하지 않아도 저장소를 여는 것만으로 백도어 코드가 돈다. 특히 개발자 채용을 가장해 ‘코딩 과제 저장소를 클론해서 실행해 보라’고 유도하는 수법이 비버테일 계열에서 반복 관측된 전형이다. 셋째, AI 코딩 도구 클로드봇(ClaudeBot)을 사칭한 확장이 마켓플레이스에 유포된 사례가 더해진다. 즉 ①마켓플레이스의 악성·사칭 확장, ②저장소 설정 파일, ③유명 브랜드·AI 도구 사칭이라는 세 갈래가 동시에 관측되는 셈이다. 여기서 초보자가 가장 많이 놓치는 지점은 ‘확장만 안 깔면 안전하다’는 생각이다. 낯선 오픈소스 저장소를 클론해 여는 순간, 확장을 하나도 설치하지 않았어도 ②번 경로에는 그대로 노출된다.
공포와 실제 위협 범위를 분리한다
이런 뉴스는 ‘내 VS Code도 위험한가’라는 막연한 불안을 키우기 쉽지만, 감염 조건을 냉정히 따지면 범위가 좁혀진다. 보도된 사례 대부분은 두 가지 행동 중 하나가 선행됐다 — 사용자가 특정 확장을 직접 설치했거나, 자동 실행 설정이 담긴 신뢰할 수 없는 저장소를 워크스페이스 신뢰 기능을 끈 상태로 열었거나. 다시 말해 VS Code를 쓴다는 사실만으로 자동 감염되는 구조가 아니며, 구인 미끼·코딩 테스트 위장·인기 확장 사칭 같은 소셜 엔지니어링이 방아쇠 역할을 한다. 이 전제를 알면 방어의 초점이 ‘백신’이 아니라 ‘무엇을 열고 무엇을 설치하느냐’라는 행동 통제로 옮겨간다.
반대로 과소평가도 금물이다. 확장이든 설정 파일이든 일단 실행되는 코드는 사용자 계정 권한 전체를 갖기 때문에, 피해가 파일 한둘로 끝나지 않는다. 브라우저 저장 비밀번호, SSH 키(~/.ssh), 클라우드 세션 토큰, 암호화폐 지갑 정보까지 한 번에 수집해 외부로 전송하는 구성이 보고된다. 그래서 설치 여부를 판단하는 기준을 감(感)이 아니라 체크 항목으로 바꿔야 한다. (1) 게시자가 개인·신생 계정인지, (2) 다운로드 수가 동종 확장 대비 비정상적으로 적거나 최근 급증했는지, (3) 소스 저장소 링크가 실제로 존재하고 코드가 공개돼 있는지, (4) 요구 권한이 기능에 비해 과한지 — 이 중 둘 이상 걸리면 설치를 보류한다. ‘유명하니까’가 아니라 ‘검증 가능한가’가 기준이다.
실무자·조직을 위한 점검 순서
개인이 지금 5분 안에 할 수 있는 것부터다. 첫째, 워크스페이스 신뢰(Workspace Trust)를 켠다. 설정에서 security.workspace.trust.enabled 값을 확인하고, 낯선 저장소는 반드시 ‘제한 모드(Restricted Mode)’로 먼저 연 뒤 .vscode/tasks.json과 launch.json을 눈으로 검토하고 나서야 신뢰를 부여한다. 제한 모드에서는 작업 자동 실행과 일부 확장 기능이 차단되므로, 클론 직후 즉시 코드가 도는 ②번 경로를 원천 차단할 수 있다. 둘째, 설치된 확장을 분기마다 한 번씩 감사한다. 게시자 검증 배지, 최근 업데이트 이력, 소스 저장소 링크의 실재 여부를 확인하고, 6개월 이상 안 쓴 확장은 삭제한다. 확장이 많을수록 공격 표면도 넓어진다. 셋째, 자격증명을 IDE에서 분리한다. 클라우드 키를 코드나 워크스페이스 설정에 넣지 말고 환경변수·시크릿 매니저로 관리하며, 토큰에는 최소 권한과 짧은 만료 기간을 걸어 유출 시 피해 창(window)을 줄인다.
조직 차원이라면 ‘탐지’만큼 ‘사후 절차’를 미리 문서화해 둬야 한다. 승인된 확장만 설치되도록 허용목록(allowlist)을 관리하고, EDR로 IDE 하위 프로세스가 비정상적으로 외부에 연결하는 정황을 모니터링한다. 가장 흔한 실수는 침해가 의심될 때 ‘악성 확장만 지우면 끝’이라 여기는 것이다. 스틸러는 이미 빼간 세션 토큰·키로 언제든 재침입할 수 있으므로, 삭제보다 노출됐을 자격증명 전량을 회전(rotate)·무효화하는 것이 먼저다. GitHub·npm 토큰 재발급, 클라우드 키 폐기, SSH 키 교체를 한 세트로 처리해야 한다. 6개월~2년 관점에서 보면 확장·플러그인 생태계를 노린 공급망 공격은 일시적 유행이 아니라 개발 환경의 상시 위협으로 굳어질 가능성이 크다. IDE를 ‘내가 통제하는 도구’가 아니라 ‘외부 코드를 내 권한으로 실행하는 표면’으로 보는 관점 전환이, 개별 대응책보다 오래 남을 방어선이다.
자주 묻는 질문
VS Code를 쓰기만 해도 이 악성코드에 감염되나요?
아닙니다. 보도된 사례는 대부분 사용자가 악성 확장을 직접 설치했거나, 자동 실행 설정이 담긴 신뢰할 수 없는 저장소를 워크스페이스 신뢰 기능이 꺼진 상태로 여는 행위가 먼저 있었습니다. 다만 낯선 프로젝트를 제한 모드 없이 열면 .vscode/tasks.json 같은 설정 파일만으로도 코드가 실행될 수 있어, ‘확장을 안 깔았으니 안전하다’는 생각은 위험합니다.
공식 마켓플레이스에 올라온 확장이면 안전한 것 아닌가요?
그렇게 보기 어렵습니다. VS Code 마켓플레이스는 누구나 게시할 수 있고 심사가 사후 방식이라, 악성·사칭 확장이 제거되기 전까지 설치가 쌓이는 사례가 반복됐습니다. 게다가 표적형 공격은 유명 확장의 이름과 아이콘을 베껴 신뢰를 훔칩니다. 별점·다운로드 수 대신 게시자 검증, 소스 저장소 실재 여부, 요구 권한의 적절성을 확인하세요.
글래스웜, 비버테일, Evelyn 스틸러는 각각 무엇이 다른가요?
글래스웜은 C2 서버 주소를 솔라나 블록체인에 숨겨 도메인 차단을 우회하고 자기 전파 가능성까지 거론된 점, 비버테일은 확장이 아니라 tasks.json 설정 파일을 악용해 저장소를 여는 것만으로 백도어를 심는 점이 특징으로 보도됐습니다. Evelyn 스틸러는 확장을 통로로 개발자 자격증명 탈취에 집중합니다. 경로는 달라도 표적은 모두 개발자입니다.
감염이 의심되면 확장만 삭제하면 되나요?
삭제만으로는 부족합니다. 스틸러는 이미 GitHub·npm 토큰, 클라우드 키, SSH 키, 세션 토큰을 빼갔을 수 있어, 확장을 지워도 그 자격증명으로 재침입이 가능합니다. 따라서 노출됐을 토큰·키를 전량 재발급하고 이전 값을 무효화하는 것이 우선입니다. 조직이라면 IDE 하위 프로세스의 비정상 네트워크 연결도 함께 점검하세요.
채용 과제나 코딩 테스트로 받은 저장소는 어떻게 열어야 안전한가요?
제한 모드(Restricted Mode)로 먼저 열고, .vscode/tasks.json과 launch.json에 자동 실행되거나 외부로 연결하는 명령이 없는지 눈으로 확인한 뒤에 신뢰를 부여하세요. 의심스러우면 격리된 가상머신이나 컨테이너에서 실행하는 것이 안전합니다. 구인·과제를 가장한 유도는 비버테일 계열에서 반복 관측된 전형적 수법입니다.