[npm][보안] org member removal과 team revoke까지 끝냈는데 package settings 2FA 증거가 비어 있을 때 어떤 Settings 화면과 owner 로그를 같이 남기나

IT 리서치 노트

[npm][보안] org member removal과 team revoke까지 끝냈는데 package settings 2FA 증거가 비어 있을 때 어떤 Settings 화면과 owner 로그를 같이 남기나

npm incident에서 org member removal과 team revoke까지 끝냈는데도 close 문장이 자꾸 길어지는 이유는 package settings 2FA 증거가 비어 있는 경우가 많기 때문이다. 2026년 9월 2일 KST 기준 npm 공식 문서를 다시 보면 package publishing뿐 아니라 package settings 수정도 2FA 대상이고, 조직 member removal, team-package revoke, npm owner remove는 각각 다른 층의 권한 회수다. 이 글은 org member removal과 team revoke까지 끝냈는데 package settings 2FA 증거가 비어 있을 때 어떤 Settings 화면과 owner 로그를 같이 남겨야 하는지 정리한다.

목차

1. 개요
2. 어디서 실제로 막히는가
3. 실무에서 적용하는 순서
4. 공식 문서와 예시 화면으로 확인하기
5. 주의사항과 리스크
6. 결론
7. 참고 링크

1. 개요

결론부터 말하면 npm offboarding close에는 조직 멤버 제거와 팀 revoke만으로는 부족할 수 있고, package settings 2FA 화면과 owner remove 로그를 같이 남겨야 종료가 짧아진다. org membership은 조직 접근을 닫고, team revoke는 간접 package access를 닫고, owner remove는 직접 수정 권한을 닫고, package settings 2FA는 이후 publish나 settings 변경 경로를 어떤 방식으로 막는지 설명한다.

이미 residual team membership 종료표 글로 팀 경로를 닫았다면, 이번 글은 패키지 settings 층을 closure evidence에 붙이는 후속편이다. npm의 2026년 8월 package-level 2FA 문서 갱신 이후에는 이 증거가 더 중요해졌다.

2. 어디서 실제로 막히는가

현장에서 먼저 꼬이는 지점은 세 가지다. 첫째, org member removal과 team revoke를 끝낸 뒤 '접근은 다 닫혔다'고 적어 버린다. 둘째, owner remove 로그는 남겼지만 package settings가 아직 bypass-2FA token 허용 상태인지 확인하지 않는다. 셋째, 조직 2FA enforcement와 package settings 2FA를 같은 증거처럼 취급한다.

npm 문서는 package publishing과 package settings modification이 모두 2FA 대상이라고 설명한다. 또 team-package revoke는 팀 차원의 접근을 다루고, npm owner remove는 패키지 직접 권한을 회수한다. 즉 한 증거로 다른 층을 대신할 수 없다. 조직에서 제거되었다고 해서 package settings가 어떤 모드로 남아 있는지까지 자동으로 설명되지는 않는다.

특히 incident close에서 자주 남는 질문은 '지금 이 패키지는 누가 settings를 바꿀 수 있나'와 '토큰으로 publish나 settings change가 가능한가'다. 이 질문은 team revoke 화면만으로 닫히지 않는다. package settings 화면과 owner remove 로그가 없으면, 이후 재오픈 때 다시 확인 순서를 처음부터 설명해야 한다.

• 증상: offboarding을 닫았는데 package settings 쪽 질문이 다시 열린다.
• 실패: 조직 2FA enforcement와 package-level 2FA 상태를 같은 증거처럼 쓴다.
• 막힘: team revoke와 owner remove의 역할을 한 줄로 합친다.
• 누락: package settings의 2FA 모드와 확인 시각을 남기지 않는다.

증상	먼저 남겨야 할 값	판단 기준
조직에서 뺐는데 패키지 질문이 남는다	package settings 2FA mode	패키지 자체가 어떤 2FA 규칙인지 본다
직접 수정 권한이 남았는지 모호하다	npm owner remove 로그	owner 목록에서 빠졌는지 본다
간접 접근이 닫혔는지 모호하다	team-package revoke evidence	팀을 통한 package access가 제거됐는지 본다

3. 실무에서 적용하는 순서

가장 실용적인 종료 순서는 다섯 단계다. 먼저 org member removal 완료를 남긴다. 다음으로 team-package revoke 증거를 저장한다. 세 번째로 npm owner remove 로그를 저장한다. 네 번째로 package settings 화면에서 현재 2FA requirement 모드를 캡처하고 확인 시각을 적는다. 마지막으로 이 네 증거를 같은 closure row에 남기되 서로 다른 필드로 분리한다.

1. org member removal 완료를 기록한다.
2. team-package revoke evidence를 남긴다.
3. npm owner remove 로그를 저장한다.
4. package settings 2FA 모드와 확인 시각을 남긴다.
5. closure row에 네 층을 다른 필드로 유지한다.

이 구조를 잡아 두면 이후 재질문이 줄어든다. 조직 멤버 제거는 billing과 조직 참여를 닫는 증거이고, team revoke는 간접 접근을 닫는 증거이며, owner remove는 직접 패키지 수정 권한을 닫는 증거다. package settings 2FA 화면은 그 뒤에도 어떤 publish와 settings change 경로가 허용되는지 설명한다. 네 값을 같은 문장으로 합치면 질문이 다시 섞인다.

org_member_removed=true
team_package_revoke_checked=true
owner_removed=true
package_settings_2fa=require-2fa-and-disallow-tokens
settings_checked_at=2026-09-02T09:34:00+09:00
closure_rule=do-not-collapse-these-fields

특히 trusted publisher를 이미 도입한 패키지라면 package settings 2FA 모드를 더 명시적으로 남기는 편이 좋다. token-free publish를 쓰는 패키지라도 package settings 변경 경로는 여전히 다른 증거와 질문을 남길 수 있기 때문이다.

4. 공식 문서와 예시 화면으로 확인하기

첫 자료는 npm package settings 2FA 문서다. 조직 정리와 별개로 package settings 자체가 2FA 대상이라는 전제를 먼저 잡아야 한다.

npm 문서는 package publishing뿐 아니라 package settings 변경에도 2FA가 필요하다고 설명한다.

즉 offboarding close를 적을 때 org member removal과 team revoke만 적으면 부족할 수 있다. 패키지 settings가 어떤 2FA 모드로 남아 있는지도 종료 근거에 포함돼야 한다.

두 번째 자료는 team-package revoke 문서다. 팀 차원의 package access 제거는 member removal과는 다른 작업이라 별도 증거가 필요하다.

팀에서 package access를 제거하는 단계는 member removal과 분리된 증거로 남겨야 한다.

하지만 이것만으로는 아직 부족하다. 팀 접근을 끊어도 package settings가 토큰 허용 상태인지, interactive 2FA를 강제하는지까지는 이 화면이 말해 주지 않는다.

세 번째 자료는 npm owner 문서다. owner 제거 로그는 패키지 직접 수정 권한을 누가 잃었는지 증명하는 가장 짧은 흔적이다.

npm owner remove 기록은 패키지 직접 권한 회수를 증명하는 핵심 로그다.

따라서 offboarding close를 짧게 만들려면 org membership, team-package revoke, owner removal, package settings 2FA 네 증거를 서로 다른 층으로 남기는 편이 좋다.

운영 메모에서는 무엇이 조직 레벨이고 무엇이 패키지 레벨인지 자주 섞인다. 아래 표는 종료표에서 네 층을 어떻게 나누면 되는지 정리한 예시다.

offboarding 종료표는 조직, 팀, owner, package settings 2FA를 다른 칸으로 두는 편이 좋다.

이미 member offboarding과 team revoke 글과 residual team membership 글을 봤다면, 이번 글은 그 다음 종료 조건인 package settings 2FA 증거를 붙이는 단계다.

마지막 자료는 종료 메모 JSON 예시다. package settings 2FA evidence가 비어 있으면 close 문장이 다시 길어지기 쉽다.

offboarding closure note에는 package settings 2FA proof를 별도 필드로 두는 편이 좋다.

이 구조가 있으면 owner 제거와 package settings 강제 상태를 같은 close 문장으로 합치지 않고, 각 증거가 어떤 질문을 닫는지 명확하게 설명할 수 있다.

5. 주의사항과 리스크

첫 번째 리스크는 조직 2FA enforcement만 보고 package-level 2FA 상태를 추정하는 것이다. 두 번째 리스크는 team revoke와 owner remove를 같은 의미로 적어 직접 권한 회수 여부를 모호하게 만드는 것이다. 세 번째 리스크는 package settings 확인 시각을 남기지 않아 이후 정책 변경과 구분하지 못하는 것이다.

운영 종료표에는 최소한 org member removed, team package revoke checked, owner remove log, package settings 2FA mode, settings checked at 다섯 칸을 두는 편이 좋다. 그래야 offboarding close가 package governance까지 닫았는지 한 번에 보인다.

• 조직 2FA와 package settings 2FA를 같은 증거로 쓰지 않는다.
• owner remove 로그는 별도 필드로 남긴다.
• package settings 확인 시각을 항상 같이 적는다.

6. 결론

npm offboarding을 짧게 닫으려면 org member removal과 team revoke 뒤에 package settings 2FA 증거를 붙여야 한다. owner remove 로그와 package settings 화면을 같이 남기면 조직, 팀, 직접 owner, 이후 publish/settings 경로를 서로 다른 층으로 설명할 수 있다.

여기까지 정리한 뒤에도 남은 maintainer가 실제로 무엇을 바꿀 수 있는지 마지막 확인이 필요하면 후속 글인 owner ls와 settings 화면으로 끝내는 검증 정리를 이어서 보면 된다. 그 글에서는 offboarding closure 뒤에 남은 owner 목록, settings 2FA 모드, 복구 경로를 어떤 순서로 확인할지 묶어 둔다.

• member removal, team revoke, owner remove, package settings 2FA를 네 층으로 나눈다.
• owner 로그와 settings 화면을 함께 남긴다.
• closure row에서는 네 증거를 한 문장으로 뭉개지 않는다.

7. 참고 링크

1. https://docs.npmjs.com/requiring-2fa-for-package-publishing-and-settings-modification/
2. https://docs.npmjs.com/removing-members-from-your-organization/
3. https://docs.npmjs.com/managing-team-access-to-organization-packages/
4. https://docs.npmjs.com/cli/v12/commands/npm-owner/
5. https://docs.npmjs.com/requiring-two-factor-authentication-in-your-organization/