npm 로그인은 되는데 배포가 막혔다면: 복구 코드 사용 뒤 확인할 것

보안상 잠시 작업을 기다리는 상태를 표현한 AI 생성 개념 이미지입니다.

npm 웹사이트에는 로그인할 수 있는데 패키지 발행이나 새 토큰 생성만 막힐 때가 있습니다. 이때 비밀번호가 틀렸다고 생각해 로그인을 반복하거나 패키지 설정부터 바꾸면 원인을 더 헷갈리게 만들 수 있습니다. 최근 복구 코드로 로그인했는지가 먼저 확인할 조건입니다.

npm 로그인 후 배포만 막혔다면 복구 코드로 로그인한 시각과 보류 대상 작업부터 확인하세요.

2026년 9월 9일 npm 발표에 따르면, 복구 코드 로그인 뒤 72시간 동안 적용하는 보안 보류가 모든 npm 계정으로 확대됐습니다. 그전에는 일부 영향력이 큰 계정에 적용되던 보호였습니다. 아래는 이 정책과 공식 계정 복구 문서를 읽는 방법이며, 실제 계정의 보류를 해제하거나 사고 여부를 판정한 기록은 아닙니다.

로그인 성공과 발행 권한을 나눠 봅니다

복구 코드는 두 번째 인증 수단을 사용할 수 없을 때 계정에 접근하기 위한 수단입니다. 로그인이 성공했다는 것은 계정에 들어온 상태를 뜻하지만, 그 직후 모든 중요한 변경까지 허용한다는 뜻은 아닙니다.

npm은 이 시점에 발행 등 민감한 쓰기를 잠시 멈추는 정책을 적용합니다. 복구 코드를 악용한 접근이 곧바로 패키지 변경으로 이어지는 위험을 줄이려는 보호입니다. 따라서 패키지를 읽거나 설치할 수 있는 상태와 새 버전을 발행할 수 있는 상태가 동시에 다르게 나타날 수 있습니다.

이 차이를 구분하면 “npm 전체가 안 된다”는 보고를 더 정확하게 바꿀 수 있습니다. 예를 들어 로그인은 되고 패키지 설치도 되지만 publish가 막힌 것인지, 처음부터 계정에 들어가지 못한 것인지부터 적어봅니다. 두 경우는 같은 문제로 조사하면 안 됩니다.

가능한 작업과 멈추는 작업이 다릅니다

계정 복구 문서는 보류 중에도 가능한 작업과 제한되는 작업을 구체적으로 나눕니다. 로그인, 패키지 열람·다운로드·설치는 계속 가능하며, 비밀번호 변경이나 새 2FA 수단 추가처럼 계정을 보호하는 일부 작업도 안내합니다.

반면 패키지 발행·발행 취소, 액세스 토큰 생성, 패키지 설정과 관리자 변경 등은 제한 대상입니다. 조직·팀 멤버십이나 기존 2FA 수단의 변경도 별도로 제한됩니다. “설정 변경은 모두 가능” 또는 “아무것도 못 함”으로 요약하면 실제 정책과 달라집니다.

중요한 것은 실제로 실패한 행동의 이름입니다. 새 토큰을 만들어 해결하려 했는데 그 작업도 막혔다면, 처음 오류와 별개의 고장이라기보다 같은 보류 정책의 범위일 수 있습니다. 그러므로 실패할 때마다 인증 수단을 새로 만드는 방향으로 움직이기 전에 제한 대상에 포함되는지 대조합니다.

공식 문서에 적히지 않은 기능까지 일괄 허용된다고 추정하지도 않습니다. 사용하는 기능과 계정 화면의 안내를 확인하고, 복구 정책에서 설명하지 않는 오류는 다른 조건으로 조사해야 합니다.

시간을 계산할 때는 보류 시작점을 기록합니다

가상으로 월요일 오전 10시에 복구 코드 로그인이 성공했고 그때 보류가 시작됐다고 해보겠습니다. 같은 시간대 기준으로 72시간 뒤는 목요일 오전 10시입니다. 이것은 기간을 설명하기 위한 계산이며 어떤 실제 계정의 해제 예정 시각은 아닙니다.

실제 기록에는 날짜와 시각뿐 아니라 시간대도 함께 남기는 편이 좋습니다. 로컬 시각으로 기억한 로그인 시간과 서버에서 표시한 시간을 혼합하면 보류가 끝났는지 잘못 판단할 수 있습니다. 서비스에서 확인할 수 있는 보류 시작 상태를 기준으로 대조해야 합니다.

현재 계정 복구 문서는 보류가 시작된 뒤 72시간이 지나면 자동으로 끝나며, 그 기간에 다른 복구 코드를 사용해도 보류 기간이 연장되지는 않는다고 설명합니다. 그렇다고 기간을 확인하려고 남은 복구 코드를 반복해서 사용해야 한다는 뜻은 아닙니다.

복구 코드는 평범한 확인 번호가 아니라 계정 접근 수단입니다. 사용한 여부와 보류 시각을 기록하되 코드의 실제 내용은 문서나 채팅에 남기지 않습니다. 시간 확인을 위해 민감한 값을 다시 노출할 이유가 없습니다.

하나의 복구 상황을 순서대로 읽어봅니다

가상의 패키지 관리자가 인증 장치를 사용할 수 없어 복구 코드로 로그인했다고 하겠습니다. 웹 로그인은 성공했고, 공개 패키지도 열어볼 수 있습니다. 그런데 당일 릴리스 과정에서 발행이 막혔습니다.

첫 단계는 복구 코드 로그인과 보류 안내가 같은 계정에 해당하는지 확인하는 것입니다. 브라우저의 계정과 CI에서 사용한 인증 경로가 다를 수 있으므로, “웹에서 로그인한 사람”과 “발행을 시도한 주체”를 무조건 같다고 생각하지 않습니다.

두 번째는 실패한 작업을 구분하는 것입니다. 패키지 다운로드가 아니라 발행이 실패했고, 최근 복구 코드 로그인도 확인됐다면 발표된 보류 정책과 맞는 상황인지 읽어봅니다. 정확한 오류 내용과 발생 시각을 함께 남기면 다른 담당자도 조건을 비교할 수 있습니다.

세 번째는 이미 진행된 작업의 상태를 확인하는 것입니다. 릴리스 업무에는 빌드, 산출물 준비, 스테이징, 승인, 공개 같은 여러 단계가 있을 수 있습니다. 발행 시도에서 오류가 보였다는 이유로 다른 단계도 모두 실패했거나 반대로 버전이 공개됐다고 단정하지 않습니다.

네 번째는 가능한 보호 작업과 릴리스 일정을 분리하는 것입니다. 계정을 안전하게 다시 사용할 준비는 공식 복구 안내에 따라 진행하고, 공개 일정은 현재 제약을 반영해 담당자와 조정합니다. 자동 재시도를 계속 돌리는 것만으로 보류가 해제되는 것은 아닙니다.

복구 코드를 쓰지 않았는데 보류라면 기다리기만 하지 않습니다

npm의 발표와 복구 문서는 본인이 복구 코드를 사용하지 않았는데 이 보류가 나타난 경우 즉시 npm Support에 연락하도록 안내합니다. 정상적인 대기 상태라고 임의로 결론 내리지 않는 것이 중요합니다.

그렇다고 오류 하나만으로 계정이 탈취됐다고 단정하는 것도 정확하지 않습니다. 어떤 계정에서 어떤 안내가 보였는지, 본인이 수행한 로그인 과정이 무엇이었는지, 다른 인증 주체가 관련되는지를 사실대로 정리합니다. 계정 침해 가능성에 관한 판단과 필요한 조치는 지원 절차와 보안 담당자의 확인에 따라 진행해야 합니다.

문의에 사용할 정보는 계정과 패키지를 식별하는 데 필요한 최소한의 내용, 오류 문구, 발생 시각, 수행한 행동입니다. 실제 복구 코드, 비밀번호, 토큰을 그대로 공개 이슈나 채팅에 붙여넣지 않습니다. 안내된 공식 지원 경로인지도 확인해야 합니다.

본인이 복구 코드를 사용한 뒤 정상적으로 보류가 시작됐다면, 해제를 앞당기려고 지원 요청을 보낼 필요는 없습니다. 현재 문서는 이 보류를 일찍 해제할 수 없으며 기간이 지나면 자동 종료된다고 설명합니다. 정상 만료를 기다리는 상황과 본인이 모르는 복구 로그인 상황을 같은 대응으로 처리하지 마세요.

보류가 끝난 뒤에도 발행 실패 원인은 남을 수 있습니다

72시간이 지났다고 모든 발행 오류가 없어지는 것은 아닙니다. 해당 보류가 풀리는 것과 패키지에 필요한 발행 권한, 인증 설정, 버전 조건이 모두 맞는 것은 별개입니다.

예를 들어 명령을 실행한 계정이 예상과 다르거나, 사용한 registry가 다른 경우에는 이번 정책과 다른 문제를 보고 있을 수 있습니다. 이미 사용한 버전이나 CI의 인증 구성 때문에 실패할 수도 있습니다. 보류가 있었다는 과거 사실 하나로 이후의 모든 오류를 설명하지 않습니다.

2FA를 사용하는 npm 접근 안내와 사용하는 발행 경로의 문서를 확인하며, 지금 실패한 행동과 요구되는 인증을 맞춰 봅니다. 이미 설정을 여러 번 바꿨다면 무엇을 바꿨는지부터 정리해야 비교할 기준이 남습니다.

릴리스를 다시 시도할 때는 현재 계정 상태와 발행 대상, 준비한 버전을 확인하고 팀의 정상 절차로 진행하세요. 버전이 실제로 공개됐는지도 별도로 확인해야 합니다. 보류 만료 시각을 지났다는 사실을 발행 성공으로 바꿔 보고하지 않습니다.

다음 복구를 위해 남길 것은 코드 내용이 아닙니다

이번 일을 정리할 때는 어떤 인증 수단을 사용할 수 없었는지, 복구 로그인과 보류의 시작 시각, 제한된 작업, 정상 접근을 다시 확인한 범위를 남깁니다. 2FA 설정 안내를 참고해 복구 수단의 보관과 계정 접근 계획도 점검할 수 있습니다.

복구 코드를 다시 생성하면 기존 코드가 무효화되는 조건처럼 관리상 주의점이 있으므로, 코드를 단순히 여러 곳에 복사하는 방식보다 현재 유효한 복구 수단을 구별해 보관하는 것이 필요합니다. 실제 코드를 문서에 넣지 않아도 어떤 절차로 관리하는지는 기록할 수 있습니다.

이 정책을 읽는 핵심은 로그인과 발행을 같은 권한으로 보지 않는 것입니다. 복구 코드 사용 여부와 보류 시각, 실패한 작업을 연결하고, 본인이 모르는 복구 활동은 즉시 공식 지원으로 확인하세요. 그 구분이 되어야 정상적인 보호 기간을 다른 오류나 보안 사고와 섞지 않고 대응할 수 있습니다.