새 서비스 개발이 끝났다고 해서 고객 전환까지 준비된 것은 아니다. 기존 고객의 계정, 계약 상태, 담당자 권한, 첨부 파일, 진행 중인 업무 기록이 서로 연결돼 있다면 전환일 이후 가장 큰 문제는 “데이터가 옮겨졌는가”보다 “고객이 오늘 해야 할 일을 계속할 수 있는가”가 된다.
이때 선택은 모든 고객을 같은 날 새 서비스로 옮기는 일괄 전환과, 고객군을 나누어 순서대로 옮기는 단계 전환으로 나뉜다. 어느 쪽이 더 빠르거나 안전하다고 정해져 있지는 않다. 핵심은 기존 서비스와 새 서비스가 함께 존재하는 기간을 관리할 수 있는지, 오류가 난 고객만 이전 상태로 되돌릴 수 있는지다.
일괄 전환은 기준 시스템을 한 번에 바꿀 수 있을 때 맞는다
일괄 전환은 짧은 점검 시간 뒤 모든 고객이 새 서비스만 사용하게 만드는 방식이다. 계약 상태나 청구 기준처럼 같은 날짜부터 전 고객에게 동일한 기준을 적용해야 혼선이 적은 서비스라면 검토할 만하다. 지원팀도 “어느 화면을 봐야 하는가”를 따로 판단하지 않아도 된다.
다만 고객별 예외가 적어야 한다. 계약 조건, 권한 구성, 파일 보관 방식, 외부 연동이 고객마다 크게 다르면 같은 전환일을 잡아도 실제 준비는 고객마다 달라진다. 이 경우 일괄 전환은 공지가 하나라는 장점보다, 한 고객의 예외가 전체 일정과 지원 창구를 흔드는 부담이 커질 수 있다.
일괄 전환을 택하려면 전환 직전까지 바뀐 정보의 반영 시점을 먼저 정해야 한다. 예를 들어 전환 전날 고객이 담당자를 바꾸거나 계약을 갱신했다면, 그 변경이 새 서비스에 언제 반영되는지 명확해야 한다. 전환 후 기존 서비스는 읽기 전용으로 남길지, 문제가 생기면 어느 시점의 상태로 복구할지도 함께 정해 두어야 한다.
단계 전환은 고객 업무를 한 시스템 안에 묶을 수 있을 때 효과적이다
단계 전환은 일부 고객군부터 새 서비스로 옮기고, 확인한 뒤 다음 고객군을 전환하는 방식이다. 고객별 설정 차이가 크거나 파일 형식과 업무 이력의 활용 방식이 불명확할 때 유리하다. 문의가 생겨도 영향 범위를 먼저 전환한 고객군으로 제한할 수 있고, 운영팀은 다음 전환 전에 발견한 문제를 반영할 시간을 얻는다.
첫 대상은 “가장 작은 고객”보다 “작지만 실제 복잡성을 가진 고객”이 적합하다. 가상의 예를 들면, 담당자가 여러 명이고 활성 계약이 있으며 첨부 파일과 진행 중인 요청이 함께 있는 고객이라면 계정 생성만 확인하는 시험보다 현실적인 검증이 된다. 반대로 모든 예외가 없는 고객만 먼저 옮기면, 어려운 전환 문제를 뒤로 미룬 채 성공처럼 보일 수 있다.
단계 전환의 약점은 두 시스템을 오래 함께 운영할수록 기준이 흐려진다는 점이다. 계약은 기존 서비스에서 보고 파일은 새 서비스에서 찾는 상황이 길어지면 고객도 지원팀도 혼란스러워진다. 따라서 고객군별로 전환한다면 그 고객의 계정·계약·파일·주요 업무 이력을 가능한 한 한 시스템에서 처리하게 나누는 편이 낫다.
데이터 양보다 고객별 복구 경로를 먼저 확인한다
전환 방식은 레코드 수나 파일 용량만으로 정하기 어렵다. 데이터가 많아도 항목과 권한 규칙이 표준화돼 있고 되돌릴 방법이 분명하면 일괄 전환을 검토할 수 있다. 반대로 데이터가 적어도 계약 상태와 진행 업무가 고객별로 다르고, 잘못 옮긴 고객을 따로 복구할 수 없다면 단계 전환이 더 현실적인 선택일 수 있다.
기획자는 개발 범위를 더 늘리기 전에 아래 질문에 답해 보면 된다.
- 한 고객의 중요한 업무 판단이 두 시스템에 나뉘지 않게 전환 단위를 정할 수 있는가
- 전환 중 기존 서비스에서 바뀌는 계약, 권한, 업무 기록을 언제까지 새 서비스에 반영할 것인가
- 고객별로 계정 접근, 계약 상태, 파일 연결, 진행 중 업무 결과를 어떤 장면에서 확인할 것인가
- 특정 고객에게 오류가 생겼을 때 다른 고객을 멈추지 않고 그 고객만 이전 상태로 돌릴 수 있는가
- 고객과 지원팀이 전환 기간에 어느 서비스를 기준 화면으로 봐야 하는가
개발사나 내부 개발팀에는 기능 목록보다 전환 산출물을 요청하는 편이 낫다. 고객군 구분 기준, 기존 항목과 새 항목의 대응 방식, 사전 이전 결과, 전환 당일 운영 순서, 고객별 복구 조건이 준비돼 있는지 확인해야 한다. “몇 건을 옮길 수 있는가”보다 “어떤 고객을 어떻게 되돌릴 수 있는가”가 전환 계획의 완성도를 더 잘 보여준다.
새 서비스의 공개일을 먼저 고정하기보다, 첫 전환 고객군이 새 환경에서 하루의 업무를 끝까지 처리할 수 있는지부터 확인해 보자. 그 결과가 안정적이면 단계 전환을 이어 갈 근거가 생기고, 예외가 적고 공통 기준일이 필요한 서비스라면 일괄 전환의 조건도 더 분명해진다.
