안녕하세요, 모릭월드입니다. 오늘 저녁 IT 이야기는 조금 낯선 단어로 시작해 볼게요. ‘패키지 방화벽(package firewall)’입니다. 깃허브(GitHub)가 10월 20일 공개 미리보기(퍼블릭 프리뷰)로 내놓았고, 10월 29일 보안 매체들이 다시 크게 다루면서 개발자들 사이에서 화제가 됐어요.
한 줄로 요약하면 이렇습니다. “프로그램 부품(패키지)을 내 컴퓨터에 설치하기 직전에, 수상한 부품인지 한 번 더 검사하고 막아 주는 관문”이에요. 개발을 하지 않는 분도 쉽게 이해할 수 있도록 택배 검수대에 비유해서 차근차근 풀어 볼게요.
1. 먼저, ‘패키지’와 ‘npm’이 뭔가요?
요즘 앱이나 웹사이트는 처음부터 끝까지 혼자 만들지 않아요. 날짜 계산, 이미지 압축, 로그인 처리처럼 흔한 기능은 남이 만들어 공개해 둔 부품(패키지)을 가져다 씁니다. 레고 블록을 사 와서 조립하는 것과 비슷해요.
자바스크립트(JavaScript) 세계에서 이런 부품을 모아 둔 가장 큰 창고가 npm이에요. 개발자가 npm install 부품이름 한 줄을 치면 창고에서 부품이 내려와 컴퓨터에 설치됩니다.
| 용어 | 쉬운 비유 | 실제 의미 |
|---|---|---|
| 패키지(package) | 레고 블록 한 봉지 | 다른 사람이 만들어 공개한 코드 묶음 |
| npm 레지스트리 | 블록을 파는 거대한 창고 | 자바스크립트 패키지를 모아 둔 공개 저장소 |
| 의존성(dependency) | 블록 안에 또 들어 있는 블록 | 내 프로젝트가 쓰는 패키지, 그 패키지가 또 쓰는 패키지 |
| 설치 스크립트 | 상자를 여는 순간 저절로 켜지는 장치 | 설치할 때 자동으로 실행되는 명령(preinstall·postinstall) |
| CI 서버 | 밤새 자동으로 조립하는 공장 로봇 | 코드가 바뀔 때마다 자동으로 빌드·테스트하는 컴퓨터 |
2. 왜 이런 관문이 필요해졌나요?
문제는 이 창고에 가끔 독이 든 블록이 섞인다는 거예요. 인기 패키지 만든 사람의 계정이 털리면, 공격자가 진짜 이름 그대로 ‘오염된 새 버전’을 올릴 수 있어요. 그러면 이 패키지를 쓰는 수많은 프로젝트가 업데이트하는 순간 악성 코드를 함께 받아 가게 됩니다. 이런 걸 공급망 공격이라고 불러요. 모릭월드에서도 최근 LiteLLM 2시간 오염 사건, 워드프레스 플러그인 업데이트 공급망 공격을 다룬 적이 있죠.
깃허브는 이번 발표에서 특히 AI 코딩 에이전트와 CI 서버를 콕 집었어요. 이 둘은 사람이 옆에서 지켜보지 않아도 작업을 끝내려고 필요한 패키지를 알아서 설치하거든요. 사람이라면 “어, 이상한데?” 하고 멈출 순간에도, 자동화된 기계는 그냥 설치해 버릴 수 있다는 거예요.
| 누가 설치하나 | 사람이 확인하나 | 위험 포인트 |
|---|---|---|
| 개발자 본인(내 PC) | 가끔 확인 | 바빠서 버전을 꼼꼼히 안 봄 |
| CI 서버(자동 빌드) | 거의 안 함 | 배포용 비밀 키가 있는 곳에서 자동 설치 |
| AI 코딩 에이전트 | 거의 안 함 | 작업을 끝내려고 스스로 패키지를 추가·설치 |
3. 깃허브 패키지 방화벽, 한눈에 보기
깃허브 공식 변경 기록(Changelog)과 설명서에 나온 내용을 표로 정리하면 이렇습니다.
| 항목 | 내용 |
|---|---|
| 공개일 | 2026년 10월 20일(공개 미리보기), 21일 설명 보강 |
| 대상 | GitHub Enterprise Cloud 고객(데이터 상주형 포함) |
| 지원 범위 | 현재는 npm 패키지만 |
| 위치 | 개발자 PC·CI·에이전트 ↔ 공개 저장소 사이(또는 사내 저장소 ↔ 공개 저장소 사이) |
| 검사 대상 | 패키지 목록 조회(메타데이터) 요청 + 실제 다운로드 둘 다 |
| 요금 | 미리보기 기간 무료, 정식 출시 후엔 사용량 기반 과금(Actions 요금 방식과 비슷) 예정 |
| 잘못 막혔을 때 | 차단 메시지에 나온 링크로 ‘예외 요청’ → 관리자가 승인 |
4. 택배 검수대처럼 작동하는 원리
평소엔 내 컴퓨터가 npm 창고에 직접 가서 부품을 받아 와요. 패키지 방화벽을 쓰면 중간에 검수대가 생깁니다. 내 컴퓨터는 이제 창고 대신 검수대 주소로 주문을 넣고, 검수대가 창고에서 부품을 받아 회사 규칙에 맞는지 확인한 뒤 통과한 것만 넘겨 줘요.
| 단계 | 택배 비유 | 실제 동작 |
|---|---|---|
| ① 규칙 정하기 | “위험물·미검증 상품 반입 금지” 공지 | 회사 관리자가 깃허브 Enterprise 설정에서 정책 켜기 |
| ② 주소 바꾸기 | 택배를 검수실로 받게 주소 변경 | npm 설정의 registry를 방화벽 주소로 변경 |
| ③ 주문 | 평소처럼 물건 주문 | npm install 그대로 실행 |
| ④ 검사 | 검수원이 상자 확인 | 정책 5가지와 대조 |
| ⑤ 결과 | 통과 또는 반송 | 설치되거나, 차단 메시지 + 예외 요청 링크 표시 |
실제 설정은 이렇게 생겼어요(ENTERPRISE 자리에 회사 고유 이름이 들어가요). 토큰은 절대 코드 저장소에 올리지 말고 CI 비밀값으로 보관하라고 설명서에 적혀 있어요.
registry=https://package-firewall.githubapp.com/npm/enterprises/ENTERPRISE
//package-firewall.githubapp.com/npm/enterprises/ENTERPRISE/:_authToken=${GITHUB_TOKEN}5. 검수원이 확인하는 다섯 가지
| 검사 항목 | 무엇을 보나 | 기본값 | 쉬운 설명 |
|---|---|---|---|
| 알려진 악성코드 차단 | GitHub 보안 권고 DB의 악성코드 경보 | 켜짐 | “수배 전단에 있는 상자”는 무조건 반송 |
| 취약점 권고 차단 | 해당 버전에 알려진 취약점이 있는지 | ‘치명적(Critical)만’ | 위험도 기준을 높음·중간·전체로 더 엄격하게 바꿀 수 있음 |
| 증명(attestation) 퇴보 차단 | 예전 버전엔 있던 SLSA 출처 증명이 새 버전엔 없는지 | 켜짐 | 늘 붙어 오던 정품 인증 스티커가 갑자기 없으면 의심 |
| 새로 생긴 설치 스크립트 차단 | 최근 버전에 preinstall·postinstall이 새로 추가됐는지 | 켜짐 | 안 그러던 상자가 갑자기 ‘열자마자 작동’하면 의심 |
| 최소 패키지 나이(숙성 기간) | 게시된 지 얼마나 됐는지 | 1일(0~365일 설정, 0이면 끔) | 갓 나온 버전은 하루 정도 지켜본 뒤 받기 |
특히 세 번째와 네 번째가 재미있어요. 공격자가 정상 개발자 계정을 훔쳐 몰래 버전을 올리면, 평소 자동 배포 과정에서 붙던 출처 증명이 빠지거나, 정보를 훔치려고 설치 스크립트가 갑자기 생기는 경우가 많거든요. ‘평소와 다른 모습’ 자체를 경고 신호로 보는 셈이에요.
6. ‘하루 숙성’ 규칙은 왜 효과가 있을까?
오염된 버전은 보통 올라온 지 몇 시간 안에 보안 연구자나 저장소 운영진에게 발견돼 삭제되는 경우가 많아요. pnpm 공식 문서도 “대부분의 악성 릴리스는 한 시간 안에 발견·삭제된다”고 설명하고 있죠. 그러니 새 버전이 나와도 하루쯤 기다렸다 받으면, 그 사이 걸러지는 위험을 상당 부분 피할 수 있다는 아이디어예요. (위 그림의 2시간은 이해를 돕기 위한 예시예요.)
| 구분 | 장점 | 단점 |
|---|---|---|
| 숙성 기간 없음 | 새 기능·수정판을 바로 사용 | 오염 버전이 나오자마자 같이 받아 버릴 수 있음 |
| 1일 숙성 | 짧은 오염 사고 대부분을 비켜 감 | 급한 보안 수정판도 하루 기다려야 함 → 예외 요청 필요 |
| 7일 이상 숙성 | 더 넉넉한 안전 여유 | 업데이트가 많이 늦어지고, 오래 숨은 악성 코드는 못 막음 |
보안 기업 소켓(Socket)의 지적처럼, 악성 코드가 시간이 지난다고 저절로 무해해지지는 않아요. 숙성 기간은 ‘발견할 시간을 버는 장치’이지 만능 해독제는 아니라는 점, 꼭 기억해 두세요.
7. 비슷한 흐름: 다른 도구들도 ‘숙성 기간’을 넣고 있어요
이번 깃허브 발표는 혼자 튀는 움직임이 아니에요. 지난 1년 사이 여러 패키지 관리 도구가 비슷한 기능을 넣었고, 러스트(Rust)도 11월 12일 예정인 1.100 버전에서 카고(cargo)에 최소 게시 기간 설정을 추가할 준비를 하고 있다고 보도됐어요.
| 도구 | 설정 이름 | 시간 단위 | 참고 |
|---|---|---|---|
| npm | min-release-age |
일 | npm CLI 11.10.0(2026년 2월)부터 |
| pnpm | minimumReleaseAge |
분 | 10.16부터, 11.0부터는 기본 1440분(1일)으로 켜짐 |
| Yarn(Berry) | npmMinimalAgeGate |
분(새 버전은 ‘7d’ 같은 표기도) | 4.10부터 |
| Bun | minimumReleaseAge |
초(‘3d’ 같은 표기도) | 1.3부터 |
| Rust cargo | global-min-publish-age |
일·주 | 1.100(11월 12일 예정)에 추가 준비, 기본 7일로 보도 |
8. 회사가 아니어도 오늘 해 볼 수 있는 것
깃허브 패키지 방화벽은 기업용(Enterprise Cloud) 기능이라 개인 계정으로는 바로 쓸 수 없어요. 하지만 핵심 아이디어인 ‘숙성 기간’은 개인 개발자도 내 도구 설정만으로 흉내 낼 수 있어요. 예를 들어 npm이라면 사용자 설정 파일(.npmrc)에 한 줄만 넣으면 됩니다.
# npm (일 단위) — 게시된 지 1일 지난 버전만
min-release-age=1
# pnpm (분 단위) — pnpm-workspace.yaml
minimumReleaseAge: 1440
# Bun (초 단위) — bunfig.toml
[install]
minimumReleaseAge = 86400| 나는 어떤 사람? | 추천 행동 |
|---|---|
| 개발을 전혀 안 함 | 당장 할 일은 없어요. 다만 “자동 업데이트 = 무조건 안전”은 아니라는 점만 기억 |
| 취미로 웹·앱 개발 | 내 패키지 관리 도구 버전 확인 → 숙성 기간 1일 이상 설정 |
| AI 코딩 에이전트 사용자 | 에이전트가 새 패키지를 추가하면 커밋 전에 목록 확인, 가능하면 숙성 기간 설정 |
| 회사 CI 담당자 | Enterprise Cloud라면 미리보기 무료 기간에 시험 적용, 공개 저장소로 우회하는 경로 차단 |
| 보안 담당자 | 취약점 차단 기준(치명적만 → 높음 이상) 조정과 예외 승인 절차 마련 |
9. 꼭 알아 둘 한계
좋은 기능이지만 만능은 아니에요. 공식 설명서와 여러 보도를 종합하면 이런 점을 주의해야 해요.
| 한계 | 왜 문제인가 | 어떻게 보완하나 |
|---|---|---|
| npm만 지원 | 파이썬(PyPI)·러스트 등 다른 생태계는 아직 대상 아님 | 각 도구의 숙성 기간 설정을 따로 켜기 |
| 우회하면 무용지물 | 방화벽을 거치지 않고 공개 저장소로 바로 가면 검사를 안 받음 | 사내 저장소(Artifactory 등)에서 공개 저장소 직통 경로 제거 |
| 오래 숨은 악성 코드 | 숙성 기간을 넘겨도 발견 안 되면 통과 | 잠금 파일(lockfile)·코드 검토·권한 최소화 병행 |
| 급한 수정판 지연 | 보안 패치도 숙성 기간에 걸림 | 예외 요청·승인 절차를 미리 정해 두기 |
| 정식 출시 후 과금 | 사용량 기반 요금이 생길 예정(금액 미공개) | 미리보기 기간에 트래픽 규모 미리 파악 |
10. 오늘 내용 3줄 요약
| # | 핵심 |
|---|---|
| 1 | 깃허브가 npm 패키지를 설치 직전에 검사·차단하는 ‘패키지 방화벽’을 기업 고객 대상 무료 미리보기로 공개했어요. |
| 2 | 악성코드·취약점·증명 퇴보·새 설치 스크립트·숙성 기간 5가지 규칙으로 사람 없이 돌아가는 CI와 AI 에이전트를 지켜요. |
| 3 | 개인도 npm·pnpm·Yarn·Bun의 숙성 기간 설정으로 같은 아이디어를 오늘 바로 적용할 수 있어요. 단, 만능은 아니에요. |
부품을 가져다 쓰는 게 당연해진 시대에는, “무엇을 받느냐”만큼 “언제, 어떤 검사를 거쳐 받느냐”도 중요해지고 있어요. 특히 AI 에이전트가 우리 대신 설치 버튼을 누르는 일이 많아질수록 이런 자동 검수대의 역할은 더 커질 거예요. 오늘도 읽어 주셔서 고맙습니다. 모릭월드였습니다!