[npm][보안] org member removal 뒤 residual team membership 확인과 team-package revoke 확인을 어떤 종료표 두 칸으로 나누나

IT 리서치 노트

[npm][보안] org member removal 뒤 residual team membership 확인과 team-package revoke 확인을 어떤 종료표 두 칸으로 나누나

npm incident에서 org member removal을 끝낸 뒤에도 운영 메모가 다시 길어지는 이유는 대부분 residual team membership 확인과 team-package revoke 확인을 같은 칸에 넣기 때문이다. 하지만 2026년 8월 26일 기준 npm 공식 문서를 다시 보면 team membership 정리와 package access revoke는 대상이 다르고, 나중에 다시 묻는 질문도 다르다. 이 글은 org member removal 뒤 어떤 종료표 두 칸을 따로 두면 offboarding close가 더 짧아지는지 정리한다.

목차

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

1. 개요

결론부터 말하면 org member removal 뒤 후속 정리는 residual team membership 확인 칸과 team-package revoke 확인 칸으로 따로 적는 편이 좋다. 첫 칸은 사람이 아직 team 목록에 남아 있는지 보는 칸이고, 두 번째 칸은 team이 package permission을 아직 갖고 있는지 보는 칸이다.

이미 member offboarding 기록과 team access revoke evidence 글에서 사람·팀·패키지 세 층을 나눴다면, 이번 글은 그중 team 후속 정리만 더 좁혀 보는 단계다. org member removal과 team cleanup을 분리한 뒤에는 residual teams와 team-package relation을 다시 한 번 다른 칸으로 갈라야 질문이 줄어든다.

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

현장에서 가장 흔한 실패는 'team access 정리 완료' 한 줄로 끝내는 것이다. 이렇게 적으면 나중에 묻는 질문이 두 갈래로 갈라진다. 실제로 member가 release, security, billing team 같은 목록에서 모두 빠졌는지 묻는 질문과, 특정 team이 어떤 package write 또는 read 권한을 아직 갖는지 묻는 질문이 서로 다르기 때문이다.

두 번째 실패는 사람-팀 관계와 team-패키지 관계를 같은 actor가 같은 순간에 끝냈다고 가정하는 것이다. owner가 org member removal을 눌렀더라도 team admin이 residual team membership을 확인해야 할 수 있고, package maintainer가 revoke 기록을 남겨야 할 수 있다.

세 번째 실패는 exception을 별도 칸으로 안 남기는 것이다. incident 직후에는 특정 team membership을 남겨 두지 않았더라도, package revoke를 늦추는 임시 예외가 생길 수 있다. 이 예외를 residual teams 쪽에 섞어 적으면 실제 남은 membership이 있는지 오해하기 쉽다.

• 증상: 사람은 제거됐는데 어떤 team을 다시 확인했는지 메모가 없다.
• 실패: residual teams 확인과 package revoke 확인을 같은 완료 문장으로 적는다.
• 막힘: actor가 서로 다른데 한 사람이 모두 끝냈다고 적는다.
• 누락: temporary exception이 membership 칸과 revoke 칸 사이에 섞인다.

겉으로 비슷한 문장	실제 질문	따로 적어야 하는 이유
team access 정리 완료	member가 팀 목록에서 모두 빠졌나	사람-팀 관계를 증명하는 칸이 필요하다
권한 정리 완료	team이 package permission을 아직 갖고 있나	team-패키지 relation은 별도 경계다
incident close	예외가 있는지, 누가 확인했는지	exception을 분리해야 재검토가 쉬워진다

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

가장 짧은 정리 순서는 다섯 단계다. 먼저 org member removal 완료 시각을 메모에 적는다. 다음으로 각 team 화면에서 residual membership을 확인해 none인지 남은 team이 있는지 기록한다. 세 번째로 package access 화면이나 npm access revoke 기록을 열어 team-package relation을 별도 확인한다. 네 번째로 예외가 있으면 expiry와 owner를 분리해 적는다. 마지막으로 두 칸이 모두 채워졌는지 보고 incident를 닫는다.

1. org member removal 완료 시각을 저장한다.
2. team 목록을 열어 residual teams를 확인한다.
3. package permission을 team 기준으로 다시 확인한다.
4. 예외가 있으면 expiry와 owner를 별도 필드로 적는다.
5. 두 칸이 모두 채워졌을 때 incident close를 선언한다.

실행할 때는 먼저 organization members 화면에서 member 제거 자체가 끝났는지 확인한다. 그다음 teams 화면을 열어 member 검색 결과가 더 남지 않는지 보고 residual_team_membership_checked_at을 저장한다. 이어서 package access 화면이나 CLI 기록에서 특정 team이 어떤 package permission을 아직 갖는지 다시 확인하고, revoke했다면 actor와 시각을 적는다.

체크할 때는 teams 메뉴, package access 메뉴, revoke 결과, checked at 필드, exception 필드를 한 번에 보고 저장하는 편이 좋다. 버튼을 클릭해 확인한 결과와 CLI 실행 결과를 같이 적어 두면 나중에 로그 없이도 어떤 경로를 본 것인지 설명하기 쉽다.

follow-up check example

1. organization members 화면을 확인한다
2. teams 메뉴에서 residual member 결과를 저장한다
3. package access 화면 또는 npm access revoke 기록을 확인한다
4. checked at, revoke actor, exception 필드를 입력한다

실무 메모는 최소한 residual_teams, residual_team_membership_checked_at, team_package_revoke_checked_at, revoke_actor, exception_note를 포함하는 편이 좋다. 이 다섯 필드가 있으면 사람 제거 뒤 team 후속 확인이 어디까지 끝났는지 짧게 설명할 수 있다.

주의

team membership이 none이라고 해서 package relation audit까지 끝난 것은 아니다. 반대로 package revoke를 끝냈더라도 residual team membership 확인 칸이 비어 있으면 사람-팀 관계를 다시 설명해야 한다.

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

첫 공식 화면은 organization member removal이 좌석과 private package 접근에 영향을 준다는 문장이다. 이 단계가 끝났다고 해서 residual team membership 확인과 team-package revoke 확인까지 자동으로 닫히는 것은 아니다.

npm은 org member removal이 subscription seat와 private package 접근에 영향을 준다고 설명한다.

즉 사람 제거는 사람 기준의 종료 신호다. incident note에서 여기까지 끝났다는 문장과, 남아 있는 team membership 또는 team-package relation 정리 문장을 같은 칸에 넣으면 후속 감사에서 질문이 길어진다.

두 번째 자료는 team membership cleanup 자체를 다루는 문서다. 이 페이지가 따로 존재한다는 사실만으로도 사람-팀 관계를 org removal과 별도 evidence로 남겨야 할 이유가 충분하다.

npm은 organization members를 team에서 제거하는 절차를 별도 문서로 다룬다.

실무 메모에서는 여기서 residual teams가 none인지, 특정 team만 남았는지, 누가 정리했는지를 적는 편이 좋다. 이 칸은 사람이 팀 목록에서 실제로 빠졌는지를 보여 주는 종료표다.

세 번째 문구는 team removal과 organization membership이 같은 동작이 아니라는 점을 더 직접적으로 보여 준다. team에서 빼도 org 자체에서는 남아 있을 수 있다는 뜻이다.

npm은 team에서 제거해도 organization membership이 자동으로 제거되지는 않는다고 설명한다.

반대로도 생각해야 한다. org member removal을 먼저 끝냈더라도, residual team membership 확인 기록은 따로 남겨야 어떤 team 리스트를 다시 열어 봤는지 설명할 수 있다.

네 번째 화면은 team-package relation을 끊는 CLI 경로다. 이것은 사람-팀 관계가 아니라 team-패키지 관계를 끊는 기록이므로 residual team membership 칸과 분리돼야 한다.

npm access revoke는 team과 package 사이의 접근 관계를 끊는 별도 명령이다.

특히 incident 이후 release team 이름은 남아 있는데 특정 package write만 막아야 할 때 이 칸이 필요하다. 사람이 팀에서 빠졌는지와 package permission이 어떻게 바뀌었는지는 다른 질문이다.

실무에서는 offboarding 후반부를 두 칸으로 자르는 편이 가장 짧다. 하나는 residual team membership 확인 칸이고, 다른 하나는 team-package revoke 확인 칸이다.

residual team membership 확인과 team-package revoke 확인을 두 칸으로 나눈 종료표 예시다.

이미 member offboarding 기록과 team access revoke evidence 글이 사람·팀·패키지 세 층을 나눴다면, 이번 표는 그중 team 후속 확인 두 칸만 더 좁혀 보는 후속편이다. 앞단 맥락은 owner 2FA와 staged approval resume 글에서 이어진다.

마지막 자료는 incident note 예시다. 두 칸을 따로 채우면 사람이 빠졌는데 package relation은 남아 있는 상황과, 반대로 team은 남겼지만 package write만 끊은 상황을 짧게 구분할 수 있다.

org member removal 뒤 residual team membership과 team-package revoke를 분리한 메모 예시다.

이 정도 구조만 있어도 offboarding close와 release rollback review가 훨씬 명확해진다. '권한 정리 완료' 한 줄보다, 어떤 칸이 채워졌고 어떤 칸이 아직 pending인지가 운영에서 더 중요하다.

5. 주의사항과 리스크

첫 번째 리스크는 residual team membership 칸을 비워 두는 것이다. 두 번째는 team-package revoke를 package owner memo 없이 끝내는 것이다. 세 번째는 temporary maintainer grant 같은 예외를 membership 칸에만 적는 것이다.

운영 문서에는 사람-팀 관계와 team-패키지 관계를 따로 묻는 질문이 실제로 들어온다고 가정하는 편이 맞다. 특히 릴리스 사고 뒤 재초대나 재권한 부여가 생기면, 어떤 team을 다시 열어 봤는지와 어떤 package permission을 끊었는지가 서로 다른 증거가 된다.

• residual teams 칸은 사람-팀 관계 종료 신호다.
• team-package revoke 칸은 팀-패키지 경계 종료 신호다.
• 예외 메모는 두 칸과 별도로 남겨야 오해가 줄어든다.

6. 결론

org member removal 뒤 후속 정리를 한 줄로 쓰면 residual team membership 확인과 team-package revoke 확인이 다시 섞인다. 두 칸으로 나누면 어떤 team 리스트를 닫았는지와 어떤 package permission을 끊었는지를 각각 설명할 수 있다.

여기서 incident close 증거를 더 보강해야 한다면, package settings의 2FA 상태 화면과 owner 로그를 같이 남기는 후속 점검 글까지 이어서 보는 편이 실무에 맞다.

• residual team membership 확인 칸과 team-package revoke 확인 칸을 분리한다.
• 각 칸의 actor와 checked at 시각을 같이 남긴다.
• 예외는 두 칸과 분리해 incident close 직전까지 추적한다.

7. 참고 링크

1. https://docs.npmjs.com/removing-members-from-your-organization/
2. https://docs.npmjs.com/removing-organization-members-from-teams/
3. https://docs.npmjs.com/managing-team-access-to-organization-packages/
4. https://docs.npmjs.com/organization-roles-and-permissions/
5. https://docs.npmjs.com/cli/v12/commands/npm-access/