기업용 서비스를 처음 도입한 담당자가 개인 이메일로 가입하고 팀원을 초대한다. 몇 달 뒤 그 담당자가 퇴사하면 계약, 결제, 조직 설정, 사용자 초대 권한은 누구에게 남을까? 개인 계정이 조직 그 자체처럼 취급되면 업무 데이터는 살아 있는데 접근할 사람이 없어지는 일이 생긴다. B2B SaaS에서는 사람의 계정과 회사의 작업 공간을 처음부터 다른 객체로 설계해야 한다.
Microsoft의 멀티테넌트 수명주기 안내는 테넌트의 온보딩·변경·비활성화·오프보딩을 별도 단계로 본다. 제품 화면에서는 가입 버튼 하나로 시작하더라도 운영 모델에는 조직과 구성원 각각의 수명주기가 필요하다.
조직, 사용자, 멤버십을 분리한다
사용자는 로그인하는 개인이고, 조직은 데이터·계약·설정의 소유 범위다. 멤버십은 그 사용자가 어느 조직에서 어떤 역할을 갖는지 잇는 관계다. 한 사람이 두 고객사에서 일할 수도 있고, 한 조직에 수십 명이 들어올 수도 있다. 사용자를 삭제한다고 조직 데이터를 삭제하거나, 한 조직에서 내보낸다고 그 사용자의 다른 조직 접근까지 끊어서는 안 된다.
조직 생성 시에는 첫 관리자가 누구인지, 회사 식별을 어떻게 확인할지, 동일 회사가 중복 생성되면 어떻게 처리할지 정한다. 회사 도메인만으로 소유권을 증명하면 공용 메일이나 외주 인력을 다루기 어렵다. 반대로 아무 계정이나 조직을 만들고 회사 이름만 입력하게 하면 사칭된 작업 공간이 생길 수 있다. 회사 검증 수준은 서비스가 취급하는 데이터와 계약 위험에 맞춰 단계적으로 둔다.
초대는 ‘발송’이 아니라 ‘수락’에서 효력이 생긴다
관리자가 이메일 주소를 넣었다고 즉시 멤버십을 활성화하지 않는다. 초대에는 대상 조직, 초대받을 주소, 제안된 역할, 만료 시각, 초대한 관리자와 상태를 기록한다. 수락할 때 로그인한 계정의 이메일과 초대 대상이 맞는지 확인하고, 이미 수락했거나 만료된 링크는 다시 쓰지 못하게 한다. 역할을 미리 지정했다면 그 역할이 수락 시점에도 허용되는지 검증한다.
Auth0의 조직 초대 문서도 초대 수락과 로그인, 이메일 일치, 초대 만료를 별도 흐름으로 다룬다. 특정 인증 제품을 사용하지 않아도 원칙은 같다. 초대 링크가 다른 사람에게 전달되거나 오래된 메일함에 남을 수 있다는 전제로 설계해야 한다. 재전송은 기존 링크를 무제한 살리는 방식보다 이전 초대를 무효화하고 새 상태를 만드는 편이 명확하다.
퇴사 처리에는 로그인 차단보다 넓은 범위가 있다
퇴사자를 조직에서 제거하면 그 조직의 새 요청뿐 아니라 기존 세션, API 토큰, 공유 링크, 자동화 작업 소유권을 점검해야 한다. 어떤 제품에서는 조직 멤버십 제거와 개인 로그인 계정 삭제가 서로 다르다. Auth0의 멤버 제거 안내도 조직에서 제거하는 동작이 전체 사용자 계정 제거와 같지 않음을 분명히 한다. 제품 내부에서는 프로젝트 소유자, 알림 수신자, 예약 작업 실행자 같은 업무 참조도 함께 이전해야 한다.
특히 최고 관리자가 한 명뿐이라면 ‘내 계정 삭제’나 ‘조직 탈퇴’를 바로 허용하면 안 된다. 먼저 다른 관리자를 확인하거나 소유권 이전 절차를 완료하게 한다. 마지막 관리자 보호는 편의 기능이 아니라 조직의 복구 경로다. 반대로 퇴사자가 유일한 관리자여서 승인을 할 수 없는 경우를 위해 계약 책임자 확인, 고객지원 심사, 변경 이력 기록 같은 별도 복구 절차가 필요하다. 단순히 고객지원 직원이 임의로 관리자 권한을 부여하게 해서는 안 된다.
소유권 이전은 한 번의 버튼보다 안전한 절차다
이전 요청자는 현재 권한을 증명하고, 새 소유자는 초대와 수락을 마쳐야 한다. 변경 대상에는 결제 담당자, 청구서 수신자, API 관리자, 보안 알림 수신자 등이 있을 수 있다. 실제 이전 시점과 이전 전후 권한을 기록하고 양쪽에 알린다. 계약상 책임자가 바뀌는 서비스라면 제품 안의 역할 변경과 계약 정보 변경을 혼동하지 않도록 별도 확인을 둔다.
운영 화면에는 ‘누가 초대했는가’, ‘누가 어떤 조직에 속하는가’, ‘어느 관리자가 마지막인가’를 쉽게 볼 수 있어야 한다. 초대받은 사람에게도 조직 이름과 초대자의 정보, 얻을 권한을 명확히 표시한다. 조직 이름이 같은 회사가 여럿이라면 식별에 도움이 되는 정보가 필요하다. 관리자는 미수락 초대를 취소하고 만료된 초대를 정리할 수 있어야 한다.
마지막으로 제품의 데이터 소유권 정책을 점검한다. 작성자가 퇴사해도 조직 문서와 업무 기록은 남아야 하는가? 개인 메모는 다른가? ‘사용자 삭제’가 외래키 제약이나 파일 경로를 통해 문서를 함께 지우지 않는가? 탈퇴·퇴사·조직 폐쇄를 같은 삭제 버튼으로 처리하지 말고 각각의 영향을 보여 준다.
조직 관리 기능은 지원팀의 수동 작업을 줄이는 데도 도움이 된다. 고객이 초대 상태와 관리자 명단을 스스로 확인하고, 잘못 보낸 초대를 취소하며, 소유권 이전 전 필요한 단계를 볼 수 있어야 한다. 다만 지원팀의 긴급 개입 경로는 남겨 두되, 해당 작업은 일반 관리자 작업보다 더 엄격하게 본인·조직 확인과 이중 검토를 거치도록 설계한다. 누가 어느 근거로 권한을 복구했는지 나중에 설명할 수 있어야 한다.
출시 전 체크리스트
- 사용자·조직·멤버십을 별도 객체로 모델링했는가?
- 초대는 주소·조직·역할·만료와 수락 상태를 갖는가?
- 마지막 관리자의 탈퇴를 보호하는가?
- 퇴사 시 세션·토큰·예약 작업·알림 수신자를 점검하는가?
- 소유권 이전에 양쪽 확인과 변경 이력이 남는가?
- 관리자 부재 시 검증 가능한 복구 절차가 있는가?
기업용 서비스의 온보딩은 ‘첫 사람이 로그인했다’에서 끝나지 않는다. 사람은 바뀌어도 조직의 데이터와 책임이 이어지도록 초대, 멤버십, 퇴사, 이전을 한 흐름으로 만들어야 한다.
