이번 주에는 Stage-only Token을 최종 배포 자격 증명으로 주지 말고, Agent 임시 배포·관리자 2FA 승인·격리된 빌드 환경의 세 단계로 먼저 검수해야 합니다.
이 글은 AI Coding Agent가 코드 수정과 패키지 생성을 맡는 오픈 소스 유지 관리자, GitHub Actions를 운영하는 플랫폼 엔지니어, 그리고 원격 맥에서 네이티브 의존성을 빌드하는 팀을 위한 내용입니다. 단순히 npm publish가 막혔다는 이유만으로 패키지 계정 전체가 안전해졌다고 판단하면 안 됩니다.
마지막 업데이트: 2026년 9월 19일. npm staged publishing, 접근 토큰, Trusted Publishing 문서와 GitHub 공식 변경 기록을 기준으로 내용을 확인했습니다.
1먼저 구분할 것: 임시 제출과 공개 배포는 같은 단계가 아닙니다
Stage-only Token이 AI Agent의 직접 배포를 막을 수 있나요?
공식 변경 기록에 따르면 Read and write (stage only) 토큰은 자동화가 검토 대기 상태의 버전을 제출하도록 설계되었습니다. 이 토큰으로 직접 npm publish를 실행하면 공개 버전 배포가 거부됩니다. 최종 공개에는 유지 관리자가 별도로 2FA 승인을 완료해야 합니다. 자세한 권한 변화는 GitHub의 Stage-only Token 변경 기록에서 확인할 수 있습니다.
그러나 여기서 멈추면 안 됩니다. npm은 Stage-only Token에 일부 패키지 쓰기 권한이 남아 있다고 설명합니다. 예를 들어 배포 태그를 이동하거나 버전을 폐기하는 작업이 별도로 가능한지 확인해야 합니다. 따라서 이 토큰은 “새 버전의 직접 공개를 제한하는 장치”이지 “패키지 관리 권한을 읽기 전용으로 바꾸는 장치”가 아닙니다.
npm의 접근 토큰 권한 문서와 토큰 생성 문서를 기준으로 실제 계정과 패키지에서 남은 동작을 따로 검증해야 합니다.
AI Coding Agent에도 최종 2FA 승인이 필요한가요?
필요합니다. Agent가 코드 작성, 테스트, 패키지 생성, 임시 제출까지 맡더라도 유지 관리자가 버전 번호, 포함 파일, 의존성, 저장소 커밋, 변경 범위를 확인한 뒤 자신의 2FA로 승인하는 구조가 되어야 합니다. Agent의 출력 보고서만 보고 승인하면 임시 제출 단계가 형식적인 통과 절차로 전락합니다.
2역할별 경계: Agent의 자동화 범위와 사람의 승인 범위
AI Coding 팀은 Agent가 할 수 있는 일을 코드 수정, 테스트 실행, 패키지 생성, 임시 제출로 제한해야 합니다. 프롬프트와 스크립트에서 배포 태그 이동, 버전 폐기, 다른 패키지 조회가 가능한지 확인하십시오. 도구 설명에 “배포 완료”라고 적혀 있어도 실제로는 임시 제출만 끝난 상태일 수 있습니다.
각 작업은 독립된 작업 공간과 저장소 커밋에 연결해야 합니다. 임시 제출 기록에는 패키지 이름, 버전, 커밋 식별자, 생성된 압축 파일, 테스트 결과를 함께 보관하십시오. 이 연결이 끊기면 나중에 패키지 내용이 어느 코드에서 나왔는지 재현하기 어렵습니다.
다음 표는 팀이 권한을 나눌 때의 기준입니다.
| 역할 | 허용할 작업 | 저장할 증거 | 통과하지 못할 때 |
|---|---|---|---|
| AI Agent | 코드 수정, 테스트, 패키지 생성, 임시 제출 | 커밋, 테스트 로그, 임시 제출 기록 | 작업 중지 및 작업 공간 폐기 |
| 유지 관리자 | 내용 검토, 버전 확인, 2FA 승인 | 승인자, 시각, 검토 범위 | 공개 배포 보류 |
| 플랫폼 팀 | 토큰 또는 OIDC 연결, 실행기 격리 | 작업 흐름 설정, 권한 기록 | 자격 증명 재발급 |
| 보안 팀 | 남은 쓰기 권한과 로그 노출 점검 | 거부·허용 시험 결과 | 제한 범위 확대 금지 |
AI Agent의 토큰 노출 경계와 작업 분리를 더 넓게 점검하려면 AI Agent 자격 증명 격리 안내를 함께 확인하십시오. npm 권한만 줄여도 프롬프트, 캐시, 하위 작업자가 같은 비밀값을 읽을 수 있다면 전체 경계는 완성되지 않습니다.
3첫 번째 단계: 직접 공개가 정말 거부되는지 재현합니다
테스트 패키지 또는 영향이 제한된 패키지에서 Stage-only Token으로 직접 공개를 시도하십시오. 실패 결과는 단순한 화면 캡처가 아니라 명령, 실행 주체, 패키지 이름, 시각이 포함된 로그로 보관해야 합니다. 성공했다면 해당 토큰을 즉시 폐기하고, 자동화 흐름에서 제거하기 전까지 공개 배포를 중지해야 합니다.
그다음 임시 제출 흐름을 별도로 확인하십시오. npm의 staged publishing 절차는 임시 버전을 검토한 뒤 최종 승인하는 흐름을 설명합니다. 임시 저장 성공은 패키지 내용이 안전하다는 뜻이 아니므로, 압축 파일을 내려받아 파일 목록과 생성 결과를 다시 비교해야 합니다.
4두 번째 단계: npm staged publishing과 Trusted Publishing을 조건으로 비교합니다
npm staged publishing과 Trusted Publishing 중 무엇을 선택해야 하나요?
선택 기준은 “어느 쪽이 더 안전해 보이는가”가 아니라 현재 실행 환경에서 장기 쓰기 토큰을 없앨 수 있는가입니다. Stage-only Token은 OIDC를 아직 적용하기 어려운 자동화에서 임시 제출과 사람의 승인을 분리하는 데 적합합니다. 반면 지원되는 CI/CD 조합과 권한 설정을 갖춘 팀이라면 Trusted Publishing을 우선 검토하는 편이 좋습니다.
npm의 Trusted Publishing 지원 조건은 OIDC 기반 작업 흐름, 실행 환경, 패키지 연결 설정을 별도로 요구합니다. GitHub Actions를 사용하는 팀은 여러 Trusted Publishing 설정에 관한 공식 변경 기록도 함께 확인해야 합니다. OIDC는 장기 토큰을 줄이지만, 승인 절차나 작업 공간 격리를 자동으로 만들어 주지는 않습니다.
| 조건 | Stage-only Token | Trusted Publishing |
|---|---|---|
| 장기 비밀 토큰 | 필요할 수 있음 | 줄이거나 없앨 수 있음 |
| 직접 공개 | 제한됨 | 작업 흐름 권한에 따름 |
| 최종 검토 | 별도 2FA 승인 필요 | 별도 승인 정책을 설계해야 함 |
| 적합한 환경 | OIDC 적용 전 자동화 | 지원되는 GitHub Actions 기반 CI/CD |
| 핵심 위험 | 남은 패키지 쓰기 권한 | 잘못 연결된 작업 흐름 권한 |
따라서 지원되는 GitHub Actions 환경이고 패키지별 OIDC 권한을 정확히 관리할 수 있다면 Trusted Publishing으로 옮기는 계획을 세우십시오. 그렇지 않다면 Stage-only Token을 임시 제출 전용으로 유지하고, 최종 승인 자격 증명은 Agent와 분리하십시오. 두 방식을 함께 운영할 경우에는 어떤 경로가 실제 공개 권한을 갖는지 문서화해야 합니다.
GitHub Actions 자동 발행을 운영 중이라면 자동 발행 권한 검수 자료를 기준으로 실행기, 작업 흐름, 패키지 권한을 한 번에 대조하는 것이 좋습니다.
5세 번째 단계: 보안 팀은 남은 쓰기 권한을 따로 시험합니다
Stage-only Token의 검수는 직접 공개 거부 하나로 끝나지 않습니다. 다음 작업을 각각 실행해 허용 여부를 기록하십시오.
- 배포 태그를 안정 버전에서 다른 버전으로 이동하기
- 특정 버전 폐기 또는 사용 중지 처리하기
- 대상 패키지 외의 패키지 정보에 접근하거나 변경하기
- 토큰을 잘못된 패키지 이름과 작업 흐름에서 사용하기
- 실행 로그, 캐시, 작업 공간 스냅숏, 하위 Agent 문맥에 토큰이 남는지 확인하기
허용되지 않아야 할 작업이 성공하면 Agent에 맡길 수 있는 범위를 다시 줄여야 합니다. 토큰이 로그나 캐시에 노출되었다면 단순 삭제로 끝내지 말고 폐기와 재발급 기록을 남기십시오. npm 토큰의 생성과 확인 방법은 공식 토큰 관리 안내에 맞춰 점검하십시오.
6네 번째 단계: 원격 맥에서는 빌드 주체와 승인 주체를 분리합니다
원격 맥에서 npm 패키지를 만들 때 토큰은 어디에 둬야 하나요?
최종 승인 토큰과 유지 관리자의 2FA 수단은 원격 맥의 자동화 작업 공간에 두지 않는 것이 기준입니다. 원격 맥은 macOS 네이티브 의존성, 교차 플랫폼 바이너리, 애플 도구 체인의 빌드와 검증만 담당하게 하십시오. 임시 제출에 필요한 제한된 자격 증명도 작업 단위로 주입하고, 작업 종료 뒤 제거 여부를 확인해야 합니다.
원격 환경에서는 다음 연결을 남겨야 합니다.
- 소스 저장소 커밋과 빌드 작업 식별자
- 사용한 패키지 매니페스트와 잠금 파일
- 생성된 임시 압축 파일의 파일 목록
- 테스트와 서명 결과
- 작업 종료 후 토큰 삭제와 작업 공간 정리 기록
원격 맥 운영 절차를 정리할 때는 원격 맥 격리 운영 자료를 참고해 빌드 환경과 승인 환경의 접근 권한을 따로 기록하십시오. 원격 실행 환경을 분리했다고 해서 npm 계정 권한이나 2FA 승인 책임까지 분리되는 것은 아닙니다.
7다섯 번째 단계: 릴리스 책임자는 단계별 도입 여부를 결정합니다
낮은 영향도의 패키지는 Agent 임시 제출과 관리자 승인으로 제한된 시범 운영을 시작할 수 있습니다. 사용자 수가 많거나 다른 패키지와 연쇄적으로 연결된 패키지는 독립 재검수와 두 명의 검토자를 추가하는 편이 안전합니다. 자격 증명을 작업 공간에서 분리할 수 없거나, 임시 산출물의 출처를 커밋까지 되돌릴 수 없다면 도입을 미루십시오.
다음 항목을 모두 확인한 뒤에만 제한된 공개를 허용하십시오.
- [ ] Stage-only Token으로 직접 공개가 거부되는 로그를 보관했습니다.
- [ ] 임시 패키지를 내려받아 파일 목록과 빌드 결과를 비교했습니다.
- [ ] 배포 태그와 폐기 상태처럼 남은 쓰기 권한을 별도로 시험했습니다.
- [ ] Agent, 빌드 실행기, 2FA 승인자의 계정을 분리했습니다.
- [ ] 토큰이 로그, 캐시, 스냅숏, 하위 Agent 문맥에 남지 않음을 확인했습니다.
- [ ] 커밋, 임시 산출물, 테스트 결과, 승인자를 하나의 기록으로 묶었습니다.
- [ ] 실패 시 토큰 폐기, 임시 버전 차단, 재검수 절차를 실행해 보았습니다.
판정은 세 가지로 나누면 됩니다. 모든 항목을 통과한 낮은 위험 패키지는 제한적으로 열 수 있습니다. OIDC를 적용할 수 있는 GitHub Actions 작업은 Trusted Publishing으로 옮기는 이중 운영을 검토하십시오. 반대로 권한 시험이나 출처 추적에서 실패한 팀은 계속 수동 배포를 유지해야 합니다.
npm은 bypass-2FA 토큰의 직접 공개 기능을 2027년 1월에 제거하는 목표를 제시했지만, 이는 공식 계획이지 변경되지 않는 약속은 아닙니다. 권한 이름과 지원 범위, OIDC 실행기 조건, 제거 일정은 npm 문서와 공식 변경 기록을 다시 확인해야 합니다. 특히 npm 권한 정책이 바뀌거나 지원되는 실행기가 확대될 때 재검수하십시오.
현재 수동 방식은 승인자가 매번 직접 패키지를 확인해야 하고, 빌드와 배포를 한 환경에 몰아넣으면 자격 증명 노출과 출처 추적 실패가 생기며, 원격 맥 작업은 작업 공간 정리를 별도로 관리해야 한다는 단점이 있습니다. 그렇다고 모든 권한을 Agent에 넘기는 것이 답은 아닙니다. macOS 네이티브 빌드나 임시 자동화가 필요하다면, 빌드 환경은 분리하고 승인 권한은 사람에게 남기는 방식으로 vpstix의 원격 맥 환경을 검토하는 편이 실제 운영에 더 맞습니다. 필요한 경우 원격 맥 격리 조건을 확인한 뒤 작은 영향도의 패키지부터 시험하십시오.
vpstix M4 원격 노드
인공지능 에이전트를 위한 안전한 맥 배포 환경을 준비하세요
vpstix의 원격 맥에서 패키지 준비와 배포 작업을 분리해 안전하게 운영할 수 있습니다.