먼저 볼 포인트
- 이번 사건은 npm 패키지 하나가 오염되면 개발자 PC, CI 환경, 저장소 비밀값까지 한 번에 흔들릴 수 있다는 걸 아주 선명하게 보여줬다.
- 특히 axios처럼 팀 거의 모두가 알고 있는 패키지가 공격 표면이 됐다는 점이 크다. 낯선 라이브러리 문제가 아니라는 얘기다.
- 핵심은 공포감이 아니다. 버전 고정, 액션 핀 고정, 캐시 정리, 비밀값 회전 같은 기본기를 다시 운영 수준으로 끌어올리는 쪽이 더 중요하다.
1. 이번 사고는 ‘패키지 하나 잘못 올랐다’로 끝날 일이 아니다
핵심 체크: 오픈AI가 공식 incident 공지를 올렸다는 사실만 봐도, 이 사건은 특정 팀의 실수가 아니라 개발 생태계 전체의 경고에 가깝다.
보안 이슈는 자주 나오지만, 다 같은 무게로 다가오진 않는다. 이번 axios 사고가 유난히 크게 읽히는 이유는 단순하다. 너무 많은 팀이 이미 쓰고 있는 패키지였고, 그 패키지가 개발자 도구와 CI 파이프라인 안쪽까지 자연스럽게 들어가 있었기 때문이다.
오픈AI는 2026년 4월 둘째 주에 ‘Axios developer tool compromise’라는 제목의 공식 incident 공지를 올렸다. 이 한 줄이 주는 의미가 꽤 크다. 보안 회사나 오픈소스 커뮤니티만 떠드는 사건이 아니라, 실제 제품과 개발도구를 운영하는 회사도 자기 일로 받아들였다는 뜻이다.
이런 공급망 사고는 겉으로 보기엔 조용하다. 앱 화면이 갑자기 깨지는 것도 아니고, 서버가 바로 멈추는 것도 아니다. 대신 설치 단계, postinstall, 캐시, 비밀값, 개발자 워크스테이션처럼 평소 잘 안 보던 구간에서 문제를 만든다. 그래서 더 늦게 발견되기 쉽다.
이번 글은 누가 더 놀랐는지 이야기하려는 게 아니다. 공식 출처를 기준으로 이번 사고의 구조를 짚고, 팀이 당장 바꿔야 할 운영 습관을 정리해보려 한다.
- 공격 대상이 생소한 패키지가 아니라 널리 쓰이는 axios였음
- 문제 지점이 실행 중이 아니라 설치·캐시·비밀값 관리 구간이었음
- 실제 제품팀도 incident 공지로 대응할 정도로 파급력이 컸음
2. Google 분석을 보면 공격 경로가 꽤 노골적이다
핵심 체크: 이번 사고는 추상적인 ‘공급망 위험’이 아니다. 어떤 버전에 어떤 악성 의존성이 들어갔고, 설치 뒤 무슨 동작이 실행됐는지까지 공개됐다.
Google Threat Intelligence Group은 2026년 4월 1일 공개한 분석에서, 3월 31일 짧은 시간 동안 axios 1.14.1과 0.30.4에 악성 의존성 plain-crypto-js가 주입됐다고 설명했다. 여기서 중요한 건 공격자가 패키지 생태계의 익숙함을 이용했다는 점이다. 이름도, 설치 흐름도, 사용하는 방식도 너무 평범해서 방심하기 쉬웠다.
Google 쪽 설명에 따르면 이 악성 의존성은 postinstall 훅을 통해 설치 직후 코드를 조용히 실행했다. 그리고 운영체제를 확인한 뒤 Windows, macOS, Linux에 맞는 추가 페이로드를 내려보냈다. 말 그대로 ‘설치했을 뿐인데 이미 한 단계 늦은 상태’가 될 수 있었다는 얘기다.
여기서 개발팀이 꼭 봐야 할 대목은 화려한 악성코드 이름이 아니다. 설치 시점 자동 실행, 캐시 재감염 가능성, 워크스테이션과 빌드 서버 동시 노출, 그리고 비밀값 회전 필요성이다. 공격이 성공한 뒤에는 코드 수정 하나로 끝나지 않는다. 환경 정리까지 같이 따라온다.
특히 macOS 경로까지 별도로 준비됐다는 점은 의미가 있다. 개발팀 상당수가 맥북을 쓰는 현실을 정확히 겨냥한 셈이라서, ‘우리 팀은 서버만 리눅스라 괜찮다’ 같은 안일한 생각은 여기선 통하지 않는다.
- 문제 버전은 axios 1.14.1, 0.30.4로 공개됨
- 악성 의존성 plain-crypto-js가 postinstall로 실행됨
- Windows·macOS·Linux별 페이로드가 따로 준비됨
3. 그래서 이건 프론트엔드 뉴스가 아니라 팀 운영 뉴스에 가깝다
핵심 체크: 패키지 하나가 오염됐을 때 가장 먼저 흔들리는 건 앱 코드보다 팀의 운영 습관이다.
실무에서 이런 사고를 맞닥뜨리면 보통 제일 먼저 ‘어느 서비스가 axios를 쓰지?’부터 찾게 된다. 그런데 거기서 멈추면 조금 부족하다. 진짜로 봐야 하는 건 설치가 일어난 지점이다. 누가 로컬에서 받았는지, CI가 자동으로 끌어왔는지, 사내 프록시 저장소가 캐시를 남겼는지, 빌드 시점에 어떤 토큰이 노출됐는지까지 이어서 봐야 한다.
이번 사건이 무서운 이유도 여기에 있다. 설치 순간 실행되는 코드는 개발자 개인 노트북과 자동화 환경을 동시에 건드릴 수 있다. 앱 서버가 멀쩡해 보여도 이미 빌드 머신이 더럽혀졌을 수 있고, 반대로 빌드가 멀쩡해 보여도 로컬 키체인이나 환경 변수는 털렸을 가능성이 있다.
전문 블로그 관점에서 보면 포인트는 꽤 명확하다. 공급망 사고는 특정 언어 생태계의 해프닝이 아니라, 개발팀 전체 운영 모델을 시험하는 사건이다. 버전 정책, 캐시 정책, 비밀값 정책, 승인 없는 최신 버전 반영 관행이 한 번에 드러난다.
그래서 이번 사고를 보고 ‘axios가 문제였네’로 정리하면 아쉽다. 더 정확한 표현은 이렇다. axios가 계기가 됐고, 우리가 평소 얼마나 느슨하게 업데이트를 받아들이는지가 함께 드러난 사건이었다.
- 영향 범위를 서비스 목록이 아니라 설치 지점 기준으로 봐야 함
- 로컬 워크스테이션과 CI 환경을 따로 조사해야 함
- 버전·캐시·비밀값 운영이 허술하면 사고가 커짐
4. GitHub 문서를 같이 보면 왜 ‘핀 고정’ 얘기가 반복되는지 이해된다
핵심 체크: GitHub는 이미 공식 보안 가이드에서 third-party actions는 전체 SHA로 고정하는 게 사실상 유일한 불변 릴리스 사용법이라고 적고 있다.
이쯤 되면 늘 나오는 말이 있다. ‘버전 좀 잘 고정하면 되지 않나?’ 맞다. 그런데 그 말을 운영 규칙으로 만들기가 생각보다 어렵다. 그래서 GitHub 공식 문서는 이 부분을 꽤 직설적으로 쓴다. third-party actions는 전체 커밋 SHA로 고정하라고 하고, 그게 immutable release를 쓰는 사실상 유일한 방법이라고 설명한다.
이 문장을 이번 사건에 그대로 겹쳐보면 이해가 빨라진다. 태그나 latest에 기대면 편하지만, 공격자가 그 편의를 먼저 노린다. 패키지든 액션이든 ‘알아서 최신 상태 유지’는 평소엔 효율 같아 보여도 사고가 나면 가장 비싼 습관이 된다.
물론 현실적으로 모든 걸 하루아침에 바꾸긴 어렵다. 그래서 우선순위가 필요하다. CI에서 내려받는 외부 액션, 빌드 시점에 설치되는 핵심 라이브러리, 배포 직전 사용하는 도구부터 고정하면 된다. 전부가 아니어도, 영향력이 큰 구간부터 잠그는 편이 훨씬 현실적이다.
여기서 한 걸음 더 가면 관리 포인트도 보인다. 핀 고정은 보안팀만의 일이 아니다. 개발 리더, 플랫폼팀, 저장소 관리자, 리뷰어가 같이 보는 운영 정책이어야 효과가 난다.
- GitHub는 전체 SHA 고정을 가장 안전한 방식으로 설명함
- latest, 이동 가능한 태그, 느슨한 범위 버전은 사고 시 비용이 큼
- 핵심 라이브러리와 CI 액션부터 우선 잠그는 게 현실적임
5. 지금 개발팀이 바로 해야 할 건 화려한 대응이 아니라 정리 작업이다
핵심 체크: 속도보다 순서가 중요하다. 이번 유형의 사고는 조사와 청소를 같이 해야 다시 밟지 않는다.
우선 영향 범위를 좁혀야 한다. lockfile, 빌드 로그, 사내 패키지 프록시, 캐시 서버를 기준으로 문제 버전이 언제 어디서 설치됐는지 확인하는 단계가 먼저다. 이 작업이 되면 ‘이 환경은 안전하다’고 말할 수 있는 범위가 생긴다.
그다음은 비밀값과 캐시다. Google은 노출 가능성이 있는 비밀값 회전과 npm, yarn, pnpm 캐시 정리를 같이 권고했다. 이건 번거롭지만 꼭 해야 한다. 악성 패키지는 삭제했는데 캐시가 남아서 다음 배포 때 다시 끌려오는 장면이 실제 운영에선 더 자주 나온다.
마지막으로 규칙을 남겨야 한다. 외부 패키지는 어떤 범위까지 자동 업데이트를 허용할지, CI 액션은 어떤 수준으로 핀 고정할지, postinstall이 있는 의존성은 어떤 기준으로 볼지, 비밀값은 노출 의심 시 누가 회전 결정을 내릴지까지 문서로 남겨야 한다.
조금 딱딱하게 들릴 수 있지만, 이런 문서는 사고 뒤에 쓰는 게 아니라 사고 직후에 써야 한다. 시간이 지나면 다들 바빠지고, 다시 예전 습관으로 돌아가기 쉽다.
- 문제 버전 설치 이력부터 lockfile·로그·프록시 저장소 기준으로 확인하기
- 토큰과 API 키 회전, npm·yarn·pnpm 캐시 정리 같이 하기
- 자동 업데이트와 postinstall 관련 운영 규칙을 문서화하기
6. 이번 사건이 남긴 교훈은 생각보다 단순하다
핵심 체크: 신뢰는 없애는 게 아니라 분해해서 관리해야 한다. 패키지를 믿지 말자는 얘기가 아니라, 무엇을 어디까지 자동으로 믿을지 정해야 한다는 뜻이다.
개발팀은 결국 외부 생태계와 함께 움직일 수밖에 없다. 오픈소스 패키지, GitHub Actions, 클라우드 이미지, 빌드 플러그인을 전부 끊고 일할 수는 없다. 그래서 현실적인 답은 불신이 아니라 통제다. 어떤 업데이트는 바로 받지 않고, 어떤 설치는 격리된 환경에서 먼저 검증하고, 어떤 토큰은 짧게 살게 만드는 식으로 신뢰 범위를 나눠야 한다.
이번 axios 사고는 그 기본을 아주 비싼 방식으로 다시 보여줬다. 오픈AI가 incident를 올렸고, Google은 공격 구조를 분석했고, GitHub는 이미 문서에 적어둔 기본기를 다시 떠올리게 만든다. 세 출처를 나란히 놓고 보면 메시지는 거의 같다. 자동으로 편해지는 구간은 늘 공격자에게도 매력적이다.
그래서 이번 주 안에 하나만 하라면, 팀 저장소에서 최신 태그나 넓은 semver 범위를 따라가는 핵심 의존성과 액션부터 점검해보면 좋겠다. 생각보다 많이 보일 거다. 그리고 그 목록이 바로 다음 사고를 줄이는 첫 번째 문서가 된다.
이런 글은 보통 마지막에 무거운 경고로 끝나기 쉽다. 그런데 이번 건은 조금 다르게 보고 싶다. 지금이라도 운영 습관을 손보면, 다음 비슷한 사고가 왔을 때 팀이 훨씬 덜 흔들릴 수 있다. 그 차이가 꽤 크다.
- 외부 생태계를 끊는 대신 신뢰 범위를 나눠 관리해야 함
- 자동 업데이트 구간이 공격자에게도 가장 매력적임
- 핵심 의존성과 액션 목록을 뽑는 작업이 첫 대응 문서가 됨
공급망 사고 직후 개발팀 체크리스트
| 오늘 바로 할 일 | 이번 주 안에 정리할 일 |
|---|---|
| 문제 버전 설치 이력과 lockfile 변경분 확인 | 핵심 의존성과 GitHub Actions 핀 고정 정책 문서화 |
| 노출 가능성이 있는 토큰·API 키 회전 | 사내 패키지 프록시와 캐시 정리 절차 정착 |
| CI가 latest나 넓은 버전 범위를 쓰는지 점검 | postinstall 의존성과 고위험 패키지 검토 루틴 만들기 |
FAQ
이번 axios 사고는 이미 끝난 일이라 봐도 되나?
공개된 문제 버전 자체는 피하면 되지만, 설치 이력과 캐시, 비밀값 노출 여부까지 점검하지 않으면 대응이 끝났다고 보기 어렵다.
개발자 로컬 PC도 조사 대상에 들어가야 하나?
그렇다. 이번 유형은 설치 시점 실행이 핵심이라서, 서버보다 먼저 개발자 워크스테이션이 영향을 받았을 가능성도 충분히 봐야 한다.
가장 먼저 바꿔야 할 습관 하나만 꼽으면 무엇인가?
핵심 의존성과 외부 GitHub Actions를 느슨한 버전이나 이동 가능한 태그에 맡기지 않는 것이다. 버전 고정과 검토 기준을 먼저 세우는 편이 효과가 크다.
같이 보면 좋은 글
- 코딩 에이전트, 어디까지 믿고 맡길까자동화 도구를 어디까지 신뢰해야 하는지 더 넓게 보고 싶다면 이 글이 이어서 읽기 좋다.
- MCP가 왜 갑자기 다들 말하나개발도구 생태계가 왜 빠르게 넓어지는지 배경을 함께 보고 싶다면 이 글도 도움이 된다.
“오픈AI도 피하지 못한 axios 사고, 개발팀은 뭘 바꿔야 할까”에 대한 1개의 생각