IT소식

내가 짜지도 않은 코드가 내 컴퓨터를 텁니다 — 2026년, 여섯 번 뚫린 공급망

PANCO_IT
#보안#오픈소스#공급망공격#npm#개발

내가 쓴 코드 아래에 라이브러리가 줄줄이 딸려오고, 그중 하나가 감염되면 전체가 감염된다는 구조도

요즘 프로그램은 대부분 남이 만든 코드로 이뤄져 있습니다.

8월 4일 오전, 전 세계 개발자들의 컴퓨터에서 조용히 같은 일이 벌어졌습니다. 평소처럼 명령어 한 줄을 쳐서 프로그램에 필요한 부품을 내려받았을 뿐인데, 그 부품 안에 클라우드 열쇠와 개인 인증 키를 훔쳐 가는 코드가 들어 있었습니다.

훔쳐 간 쪽이 노린 것은 개발자 개인이 아닙니다. 그 개발자가 만드는 서비스입니다. 이런 방식을 공급망 공격이라고 부릅니다. 그리고 2026년은 이 공격이 유난히 잦았던 해로 기록될 참입니다. 오늘은 지금까지 벌어진 일을 한 줄로 꿰어 보겠습니다.

프로그램의 90%는 남이 만든 것입니다

먼저 왜 이런 일이 가능한지부터 짚어야 합니다.

요즘 프로그램은 처음부터 끝까지 직접 만들지 않습니다. 날짜 계산, 서버와 통신, 암호화 같은 기능은 이미 잘 만들어진 것을 가져다 씁니다. 이렇게 가져다 쓰는 남의 코드 묶음을 라이브러리라고 하고, 자바스크립트 세계에서는 이 묶음들을 모아 둔 창고를 npm이라고 부릅니다.

문제는 이게 한 겹이 아니라는 점입니다. 내가 라이브러리 하나를 부르면, 그 라이브러리가 또 다른 라이브러리를 부르고, 그것이 또 다른 것을 부릅니다. 직접 고른 것은 열 개인데 실제로 내려받는 것은 수백 개가 되는 일이 흔합니다. 이 딸려오는 것들을 의존성이라고 합니다.

그러니 이 수백 개 중 단 하나만 바꿔치기돼도 내 프로그램은 감염됩니다. 내가 그 코드를 읽어 본 적이 없다는 점이 핵심입니다. 사실 읽을 수도 없습니다. 수백 개니까요.

2026년, 여섯 번 반복됐습니다

올해 벌어진 일을 시간순으로 늘어놓으면 패턴이 보입니다.

2026년 npm 공급망 공격 타임라인 — 3월 axios부터 8월 keyv까지

그림 1. 공통점은 코드가 아니라 사람이 뚫렸다는 것입니다.

3월 31일, axios. 서버와 통신할 때 쓰는 아주 흔한 라이브러리로, 주간 내려받기가 약 1억 회에 이릅니다. 이 꾸러미의 두 버전(1.14.1과 0.30.4)에 악성코드가 심겨 배포됐습니다. 다행히 3시간 만에 걷혔지만, 보안업체 헌트리스는 그 사이 최소 135대의 기기가 공격자 서버와 통신한 것을 확인했습니다.

4월, 스스로 퍼지는 방식. 22일과 29일 두 차례에 걸쳐 감염된 꾸러미가 다른 꾸러미로 번지는 형태의 공격이 있었습니다. 사람이 하나씩 심는 대신, 감염된 개발자의 권한을 이용해 자동으로 퍼뜨리는 방식입니다.

5월 14일, node-ipc. 악성 버전이 배포됐습니다.

6월 1일, 레드햇. 한 회사 이름으로 묶인 꾸러미 32개가 한꺼번에 손을 탔습니다.

7월 14일, AsyncAPI. 이번에는 개인 계정이 아니라 자동 배포 통로가 뚫렸습니다. 저장소 네 곳의 배포 자동화가 장악돼 다섯 개 꾸러미가 변조된 채 올라갔습니다.

8월 4일, keyv와 cacheable. 올해 가장 넓게 번진 건입니다. keyv는 주간 내려받기가 약 1억 2,700만 회인 꾸러미인데, 관리자의 깃허브 계정이 뚫려 악성 파일이 저장소에 직접 들어갔습니다. 처음 확인된 것은 11개였지만, 조사가 진행되면서 **최소 444개 꾸러미(1,381개 버전)**로 늘었습니다.

뚫린 것은 코드가 아니라 사람이었습니다

여섯 건을 나란히 놓으면 공통점이 뚜렷합니다. 누구도 라이브러리의 코드 자체를 해킹하지 않았습니다. 그 코드를 관리하는 사람의 계정을 가져갔을 뿐입니다.

axios 사례가 특히 그렇습니다. 공격자는 취약점을 찾는 대신 관리자에게 접근했습니다. 어느 회사 담당자를 사칭해 연락하고, 그럴듯하게 꾸민 업무용 채팅방을 만들고, 화상회의를 잡았습니다. 그리고 회의 중에 "시스템 업데이트가 필요하다"며 프로그램을 설치하게 했습니다. 그 프로그램이 원격 조종 도구였습니다. 이 공격은 북한과 연계된 조직의 소행으로 지목됐습니다.

들이는 노력을 생각하면 합리적인 선택입니다. 널리 쓰이는 꾸러미 하나의 관리자 계정을 얻으면, 그 꾸러미를 쓰는 수십만 개 프로젝트에 한 번에 코드를 넣을 수 있으니까요. 회사 한 곳을 뚫는 것보다 훨씬 효율이 좋습니다.

저는 이 대목이 이번 흐름에서 가장 중요하다고 봅니다. 방어를 코드 검사에만 걸어 두면 이 공격은 걸리지 않습니다. 사람의 계정과 배포 권한이 진짜 방어선이라는 뜻입니다.

무엇을 훔쳐 갔나 — 그리고 새로 생긴 지점

8월 사건에서 악성코드가 노린 목록을 보면 요즘 개발 환경이 그대로 드러납니다. 클라우드 접근 열쇠, 저장소 인증 토큰, 결제·메신저 연동 키, 서버 접속용 개인 키, 그리고 설정 파일에 적어 둔 비밀값들입니다. 암호화폐 지갑도 포함됐습니다.

여기에 2026년에 새로 등장한 지점이 하나 있습니다. 악성코드가 개발 도구의 설정 파일에 자기 실행 고리를 심어 두었다는 것입니다. 코드 편집기와 AI 코딩 도구의 설정 파일이 대상이었습니다. 감염된 꾸러미를 지워도 편집기를 열 때마다 다시 실행되도록 만든 것이죠.

이게 왜 성가시냐면, 보통 이런 사고가 나면 "그 버전을 지우고 다시 설치하라"는 안내가 나가는데 그것만으로는 끝나지 않기 때문입니다. 개발 도구 설정까지 확인해야 합니다. 방어하는 쪽이 봐야 할 자리가 한 겹 늘어난 셈입니다.

자주 하는 오해 세 가지

"오픈소스라서 위험한 것 아닌가?" 방향이 반대입니다. 이번 사건들이 며칠 만에 밝혀지고 목록이 공개된 것은 누구나 코드와 변경 이력을 볼 수 있었기 때문입니다. 닫힌 소프트웨어에서 같은 일이 벌어지면 밖에서는 알 방법이 없습니다. 위험한 것은 공개 자체가 아니라, 아무도 확인하지 않고 가져다 쓰는 습관입니다.

"유명한 라이브러리를 쓰면 안전하다?" 이번에 뚫린 것이 전부 유명한 것들이었습니다. 오히려 널리 쓰일수록 표적이 됩니다. 파급이 크니까요.

"개발자가 아니면 상관없다?" 직접적인 대상은 개발자가 맞습니다. 다만 그 개발자가 만드는 서비스를 우리가 씁니다. 훔친 클라우드 열쇠로 서비스 서버에 들어가면 그다음은 이용자 데이터입니다. 개인이 할 일이 따로 있는 건 아니지만, 내가 쓰는 서비스가 이런 위험 위에 서 있다는 것 정도는 알아 둘 만합니다.

그래서 지금 무엇을 하면 되나

개발을 하신다면 순서가 있습니다.

  1. 버전을 고정합니다. 자동으로 최신 버전을 받아 오게 두면 악성 버전이 올라온 그 시간에 내려받게 됩니다. 잠금 파일을 저장소에 함께 두고, 자동 갱신을 켜 두지 않는 것이 기본입니다.
  2. 설치할 때 실행되는 스크립트를 막습니다. 이번 공격들은 대부분 설치 직후 자동 실행되는 단계를 이용했습니다. 이 자동 실행을 꺼 두면 상당수가 걸러집니다.
  3. 관리자 계정에 2단계 인증을 겁니다. 꾸러미를 배포하는 계정이라면 필수입니다. 뚫린 지점이 전부 여기였습니다.
  4. 토큰을 정기적으로 갈아 끼웁니다. 유출됐을 때 쓸 수 있는 기간을 짧게 만드는 것이 핵심입니다.
  5. 사고 소식이 들리면 목록을 확인합니다. 각 보안업체가 영향받은 버전 목록을 공개합니다. 내 프로젝트가 그 버전을 쓰고 있는지 확인하고, 맞다면 자격증명부터 전부 새로 발급합니다.

개발을 하지 않으신다면 할 일은 단순합니다. 쓰는 서비스에 2단계 인증을 켜 두고, 비밀번호를 서비스마다 다르게 쓰는 것. 이번처럼 서비스 쪽이 뚫렸을 때 피해가 내 계정 하나로 멈추게 하는 방법입니다. 2단계 인증비밀번호 관리자 편에서 다룬 내용이 그대로 적용됩니다.

한 장 정리

질문
공급망 공격이란내가 가져다 쓰는 남의 코드에 악성코드를 심어 퍼뜨리는 방식
왜 통하나프로그램 하나가 수백 개의 남의 코드에 기대고, 그걸 다 읽을 수는 없어서
2026년 규모3월 axios부터 8월 keyv까지 여섯 차례, 8월 건만 최소 444개 꾸러미
어디가 뚫렸나코드가 아니라 관리자 계정과 배포 통로
무엇을 노렸나클라우드 열쇠·인증 토큰·개인 키, 그리고 개발 도구 설정에 심는 실행 고리
개발자 대응버전 고정 · 설치 스크립트 차단 · 2단계 인증 · 토큰 교체
일반 이용자2단계 인증과 비밀번호 재사용 금지

이것만 기억하면 됩니다. 요즘 소프트웨어는 남의 코드를 겹겹이 쌓아 만듭니다. 그래서 공격자는 어려운 취약점을 찾는 대신 그 코드를 관리하는 사람 한 명을 노립니다. 2026년에 여섯 번 반복된 것이 정확히 그 방식이었고, 방어도 같은 자리에서 시작해야 합니다.


기준 시점: 2026년 8월. 피해 범위와 영향받은 버전 목록은 조사가 진행되며 계속 갱신되고 있으므로, 실제 대응이 필요하시면 아래 출처의 최신 안내를 확인하시기 바랍니다.

참고 자료

이 글의 날짜·수치는 아래 자료를 교차 확인해 작성했습니다.

이 글은 위 자료를 바탕으로 직접 작성한 해설이며, 특정 기사·이미지를 복제하지 않았습니다. 공격 수법은 방어에 필요한 범위에서만 설명했고, 재현에 쓰일 수 있는 세부는 담지 않았습니다.

PANCO_IT

IT 지식을 정리하는 개발자

관련 글