Data Center 지원 종료가 2029년 3월 28일로 정해진 뒤, 많은 조직이 Cloud 이전 계획을 세우기 시작했습니다. 이러한 마이그레이션 계획서의 순서는 대체로 비슷합니다. 앱 호환성 검토, 프로젝트·공간 목록, 커스텀 필드와 워크플로 정리, 일정과 컷오버(최종 전환), 그리고 사용자와 그룹은 대개 뒤쪽에 한 페이지로 붙어 있습니다.
데이터는 도구가 옮겨 주지만, 사용자 정리는 판단이 필요한 작업입니다. 판단에는 사람과 시간이 듭니다. 컷오버 주말에 “이 계정 아직 필요하세요?”를 물어볼 수는 없습니다. 실제 사용하지 않지만 활성화된 계정은 클라우드 마이그레이션 전체 작업에 큰 영향을 끼칠 수 있습니다.
퇴사자, 계약이 끝난 협력사, 종료된 프로젝트의 참여자. 이들 중 상당수는 비활성 처리가 되지 않은 채 DC에서 여전히 활성 상태로 남아 있습니다. 계정 생성은 급했지만 회수는 아무도 급하지 않았기 때문입니다.
이 계정들은 정상적인 활성 사용자와 구분되지 않습니다. 이런 계정은 불필요한 접근 권한까지 Cloud로 이어질 수 있고, 해당 제품 접근 권한이 적용되면 과금 대상에 포함됩니다. 마이그레이션이 문제를 만드는 게 아니라, 그동안 미뤄둔 정리가 청구서에 반영되는 것입니다.
Cloud는 중복 이메일 주소를 지원하지 않습니다. Atlassian은 이 항목을 마이그레이션 필수 준비 단계로 명시하고 있습니다. 선택이 아니라, 정리하지 않으면 진행이 막히는 항목입니다. 그리고 중복 이메일이 생기는 자리는 대체로 정해져 있습니다.
1) 퇴사자 계정 퇴사할 때 계정을 지우지 않고 남겨두는 조직이 많습니다. 이력을 지우지 않기 위해서라면 옳은 선택입니다. 문제는 그 사람이 다시 입사했거나, 계열사로 옮겼다가 돌아온 경우입니다. 새 사번으로 계정이 하나 더 생기고, 이메일 주소는 같습니다. 오래된 인스턴스일수록 이런 데이터는 쌓여 있습니다.
2) 외부 협업 계정 파트너사 담당자, 컨설턴트, 위탁 개발사 인력을 급하게 초대할 때는 회사 계정 발급을 기다리지 않고 개인 이메일이나 협력사 도메인으로 먼저 초대하는 경우가 많습니다. 나중에 정식 계정이 나오면 계정이 하나 더 생기지만, 처음 만든 계정은 지우지 않는 경우가 많습니다. 담당자가 바뀌어도 계정은 그대로 남습니다.
두 경우 모두 “이 두 계정이 같은 사람인가”를 IT 혼자 판단할 수 없습니다. 인사나 현업에 물어봐야 하는 질문이고, 답을 받는 데 며칠이 걸립니다. 외부 협업 계정은 더 어렵습니다. 물어볼 담당자가 이미 회사를 떠났거나, 계약 자체가 끝나서 확인해 줄 사람이 없는 경우가 있습니다.
그래서 이 항목은 컷오버 직전에 손댈 수 없습니다. 중복 이메일 목록을 뽑는 데는 하루면 되지만, 그 목록을 판단하는 데는 몇 주가 걸립니다.
DC와 Cloud에 같은 이름의 그룹이 있으면, 마이그레이션 과정에서 기존 Cloud 그룹과 이름 기준으로 매칭되고 사용자가 해당 그룹에 추가됩니다. 양쪽 그룹의 구성과 권한이 다르면 의도하지 않은 접근 권한이 생길 수 있습니다. 이것도 Atlassian이 필수 준비 단계로 안내하는 항목입니다.
이름 기준으로 매칭되는 것 자체보다, 이후의 구성원과 권한을 확인하지 않는 것이 문제입니다. developers라는 이름의 그룹이 양쪽에 있었고 구성원이 다르면, 결과적으로 원래 어느 쪽도 의도하지 않았던 접근 권한이 생길 수 있습니다. 사전에 이름과 구성원을 맞춰보지 않으면 마이그레이션 후에야 발견합니다.
Atlassian은 활성·비활성 합계 2,000명을 넘는 인스턴스는 사용자와 그룹을 데이터보다 먼저 별도로 이관하라고 권고합니다. 컷오버 시점의 작업량을 줄이기 위한 것입니다. 1,000명을 넘으면 Cloud 전문 파트너와 함께 진행하라고 권장하고 있습니다.
여기서 기준이 되는 숫자가 ‘활성·비활성 합계’라는 점을 눈여겨볼 만합니다. 정리하지 않은 계정은 요금뿐만 아니라 이관 작업량 자체를 늘립니다.
마이그레이션 전 사용자 정리는 한 번의 이벤트입니다. 그리고 이벤트로 끝나면 2~3년 뒤 같은 상태로 돌아갑니다. Cloud에서도 계정 생성은 급하지만 회수는 급하지 않습니다.
차이가 있다면 Cloud에서는 그 격차가 구독 비용과 필요한 사용자 티어에 직접 반영된다는 점입니다.그래서 사용자 정리는 일회성 작업이 아니라 지속적으로 운영되는 프로세스가 되어야 합니다. 이를 위해 필요한 것은 세 가지입니다.
규모가 커질수록 이 세 가지를 관리자 수작업만으로 지속하기는 어렵습니다. 사용 현황을 한눈에 확인하고, 정해진 정책에 따라 비활성 사용자를 지속적으로 관리할 수 있는 라이선스 관리 자동화를 지원하는 마켓플레이스 앱을 활용하는 것도 한 방법입니다.
Flexible User License는 Jira와 Confluence의 사용자 및 라이선스 관리를 자동화하기 위해 만들어진 앱입니다. 마이그레이션 전에는 정리 대상을 파악하고 불필요한 접근 권한을 정리하는 데, 마이그레이션 후에는 동일한 문제가 다시 쌓이지 않도록 지속적으로 관리하는 데 활용할 수 있습니다.
마이그레이션 계획서에서 사용자 항목을 첫 번째 순서로 옮기세요. 데이터 이관은 도구가 하고, 사용자 정리는 사람이 합니다. 사람이 하는 일에는 리드 타임이 필요합니다.
그리고 DC에서 제대로 비활성화된 사용자는 일반적으로 제품 접근 권한 없이 Cloud로 이관됩니다. 위험한 것은 아직 아무도 손대지 않은 계정입니다. 그 목록을 지금 뽑아 보는 것부터가 시작입니다.
👉 Flexible User License Integrations로 완성하는 Jira License 통합 관리 전략
👉 Atlassian Guard(IdP)와 Flexible User License, 역할을 나누면 라이선스 관리가 쉬워집니다
Atlassian Support
