npm 첫 배포가 안 된다면? Trusted Publishing 설정의 48시간 제한
npm Trusted Publishing 설정을 저장해 두고 며칠 뒤 첫 릴리스를 돌렸더니 인증에서 막혔다. 설정 파일은 그대로인데 무엇이 만료된 걸까?

- Trusted Publishing을 등록만 해둔 채 48시간이 지나면, 첫 배포부터 인증이 막힐 수 있다.
- 만료된 설정은 삭제하고 다시 만든 뒤, 새로 등록한 시점부터 48시간 안에 배포에 성공해야 한다.
- 이미 같은 설정으로 배포에 성공했다면 이번 만료 규칙의 대상이 아니다. 배포가 실패했다면 다른 인증 조건을 확인해야 한다.
등록만 해두면 48시간 뒤 설정이 만료된다
CI 배포용 trusted publisher를 미리 등록해 두고 며칠 뒤 처음 쓰려 하면 설정이 만료돼 있을 수 있다. npm은 10월 2일 변경 공지에서 미검증 설정에 생성 후 48시간의 기한을 적용한다고 밝혔다. 첫 배포에 성공하면 검증된 상태가 돼 이 만료에서 제외된다.
이 기한은 작업마다 발급되는 OIDC 인증 토큰의 수명과 다르다. GitHub의 OIDC 설명에서 워크플로는 자기 신원을 증명하는 토큰을 제시하고, 이를 검증한 외부 서비스가 단기 자격증명을 발급한다. 저장해 둔 장기 비밀값을 매번 재사용하는 방식과 구별된다.
따라서 ‘48시간마다 새 버전을 내야 한다’는 뜻이 아니다. 초기 설정을 검증하는 시간과 개별 작업이 인증을 받는 시간을 나눠 봐야 한다.
만료된 설정은 삭제하고 다시 만든다
npm 문서의 만료 안내는 만료된 설정을 삭제하고 새로 생성한 뒤 기한 안에 첫 배포를 성공시키도록 설명한다. 설정을 저장했다는 사실만으로 검증이 끝나지 않으며, 일반적인 수정도 기한을 다시 시작하지 않는다.
| 설정 상태 | 48시간 규칙의 의미 |
|---|---|
| 새로 만들었고 아직 성공한 배포가 없다. | 생성 시점부터 초기 검증 기한이 진행된다. |
| 해당 설정으로 첫 배포에 성공했다. | 이 초기 미검증 만료에서 제외된다. |
| 검증 전에 기한이 지났다. | 만료 설정을 새 설정으로 교체해야 한다. |
실제 릴리스 준비와 설정 시점을 맞추는 편이 낫다. 배포할 내용이 없는 상태에서 기한만 맞추려고 불필요한 버전을 내기보다, 사용할 배포 경로가 준비됐을 때 설정하고 정상 릴리스의 성공으로 검증하는 방식이다.
댓글로 실행한 GitHub Actions 배포는 인증이 거부된다
같은 공지는 issue_comment 이벤트에서 나온 trusted publishing 토큰을 거부한다고 밝혔다. 기존 pull_request_target 제한에 추가된 변화다. 설정이 만료되지 않았더라도 이 이벤트로 실행하는 배포는 인증 단계에서 막힐 수 있다.
허용되는 대안에는 push, release, workflow_dispatch가 있다. 수동 실행으로 옮긴다면 GitHub 이벤트 문서의 조건도 맞춰야 한다. 워크플로 파일이 기본 브랜치에 있어야 하며, 수동 실행 이벤트를 설정해야 한다. 댓글 워크플로 자체가 없어지는 것이 아니라 npm이 받아들이는 배포 인증의 범위가 달라진 것이다.
저장소·워크플로 이름이 틀려도 설정은 저장된다
npm은 trusted publisher 설정을 저장할 때 내용의 정확성을 검증하지 않는다. GitHub Actions에서는 저장소와 워크플로 파일명, 대소문자를 정확히 맞추고 id-token: write 권한을 설정해야 한다. GitHub 호스팅 러너를 사용해야 하며, 현재 자체 호스팅 러너는 지원하지 않는다.
이 점검은 새 설정을 만들었다는 사실과 별개다. 워크플로 신원을 나타내는 정보가 등록된 조건과 맞아야 인증을 받을 수 있다. 초기 검증 기한, 실행 이벤트, 워크플로 설정을 따로 확인해야 실패 원인을 좁힐 수 있다.
자주 묻는 질문
이미 배포에 성공한 설정도 48시간마다 만료되는가?
아니다. 첫 성공으로 검증된 설정은 이번 초기 만료 규칙에서 제외된다.
설정을 다시 저장하면 기한이 늘어나는가?
아니다. 일반 수정은 기한을 다시 시작하지 않는다. 만료된 설정은 삭제 후 재생성해야 한다.