옛 영업관리 시스템 계약을 새 CRM으로 매일 옮길 때 검증하는 법

계약 10,211건 가운데 10,203건이 그대로였습니다.

옛 영업관리 시스템의 장기보험 계약을 새 CRM에 처음 전량 반영해 본 결과입니다. 반영 스위치는 그 전에 시험 실행으로 무변경 비율을 확인하고서야 켰습니다.

새 시스템으로 계약을 옮길 때는 보통 몇 건이 들어왔는지로 확인합니다. 저는 순서를 바꿔 바뀌지 않은 건수부터 셌습니다.

그렇게 센 데는 이유가 있었습니다. 그렇게 세고도 놓친 것도 있었습니다.

버릴 수 없는 옛 시스템

제가 계약관리 시스템 이음을 만들어 드린 곳은 보험대리점(GA) 지사입니다. 계약은 실장 한 분이 대리점 영업관리 시스템에 입력합니다.

한때는 새 CRM에 직접 입력하는 쪽으로 정했습니다. 결국 그 결정을 접고 옛 시스템을 계약 사실의 원본으로 두기로 했습니다.

출발점의 질문은 하나였습니다. 거기에 올린 계약을 매일 이음으로 가져와, 실장이 직접 등록한 것처럼 보이게 할 수 있느냐는 것입니다.

먼저 필드마다 주인을 정했습니다.

항목	원본
보험사·상품·계약일·상태	옛 영업관리 시스템
담당 설계사·연락처·태그·메모	이음

연락처를 이음 쪽에 둔 이유는 옛 시스템의 휴대폰 칸이 몇 해 사이 비어 버렸기 때문입니다. 채움률이 무너진 경위는 연락처 채움률 글에 있습니다.

연락처는 이음 값이 비어 있을 때만 옛 시스템 값으로 채웁니다.

스위치보다 시험 실행이 먼저

동기화 프로그램은 처음부터 두 모드로 만들었습니다. 반영 스위치를 켜지 않으면 끝까지 읽고 비교만 하고, 데이터베이스엔 아무것도 쓰지 않습니다.

전량 시험 실행에서 제가 본 것은 무변경 비율입니다. 기존 계약 대부분이 이음에 있던 값과 달라지지 않는지를 먼저 확인했습니다.

이 비율이 열 매핑을 검증해 줍니다. 열 하나가 밀렸다면 계약 대부분이 변경으로 잡혔을 겁니다.

확인이 끝난 뒤에 스위치를 켰습니다. 첫 전량 반영에서 기존 장기 계약 10,211건 중 10,203건이 그대로였습니다.

같은 반영에서 그전까지 이음에 한 건도 없던 일반보험 465건과 자동차보험 8,041건이 들어왔습니다.

새로 들어오는 건수에는 맞고 틀림을 가를 기준이 없습니다. 이미 있던 데이터가 그대로인지는 가를 수 있습니다.

그래서 저는 기존 데이터의 무변경 비율을 반영의 문으로 삼았습니다.

0건이라는 정상 응답

옛 시스템에서 계약 목록을 받는 길은 엑셀 내려받기 하나였습니다. 화면이 쓰는 조회 폼을 서버에서 그대로 보내 파일을 받는 방식입니다.

실측해 보니 이상한 점이 있었습니다. 2000년부터 2099년까지처럼 넓게 조회하면 '조회 건수가 0건입니다'라는 알림이 정상 응답으로 돌아왔습니다.

장기 계약을 2020년부터로 좁히면 3,970행이 92초 걸려 내려왔습니다. 데이터가 있는데도 0건이라고 답하는 시스템이었던 셈입니다.

파라미터를 잘못 넣어도 마찬가지였습니다. 응답은 정상이고 알림 문구만 '인자값 오류'로 바뀌어 왔습니다.

그래서 조회를 연도별로 나눠 받고, 계열 하나라도 0행이면 실패로 처리했습니다. 이 가드가 없으면 빈 파일 하나가 "계약이 모두 사라졌다"로 읽힐 수 있습니다.

사라진 75건의 행방

주간 전량 동기화는 옛 시스템에 없는 계약을 찾아 '사라짐' 표시를 붙입니다. 옛 시스템에서 지워진 계약을 놓치지 않으려는 장치입니다.

주간 전량 범위로 돌렸을 때 2001~2004년 계약 75건에 사라짐 표시가 붙었습니다. 원인은 제 조회 범위였습니다.

시작 연도를 2005년으로 잡아 그 네 해는 아예 물어보지 않았던 것입니다. 2000년부터로 넓혀 다시 반영하자 75건의 표시는 걷혔습니다.

물어보지 않은 해의 계약을 없다고 판정한 셈입니다. 사라짐을 가리는 조회 범위는 기존 데이터의 가장 오래된 계약일에서 출발하세요.

같은 보험사, 다른 이름

중복은 엉뚱한 곳에서 생겼습니다. 이음에 직접 입력된 계약은 보험사를 정식명으로, 옛 시스템은 약칭으로 적고 있었습니다.

'△△손해보험'과 '△△손보'가 다른 회사로 읽혀 같은 계약이 두 줄이 된 것이 2건이었습니다. 보험사명 표기를 하나로 맞추는 정규화를 넣고 다시 매칭해 정리했습니다.

자동차보험은 더 까다로웠습니다. 옛 시스템의 자동차 계약은 증권번호가 전부 비어 있었습니다.

대신 차량번호와 보험 개시일을 묶어 키로 썼습니다. 이 선택의 대가는 5주 뒤에 드러났습니다.

점검에서 '중복 1,076건'이 보고됐는데 그중 1,074건이 자동차였습니다. 대부분 같은 차의 연도별 갱신 계약이었습니다.

개시일이 키에 들어 있으니 해마다 새 줄이 생기는 게 당연했습니다.

진짜 문제는 상태 쪽에 있었습니다. 동기화는 해지·취소·철회만 해지로 바꾸고 나머지는 전부 유지로 두고 있었습니다.

그 바람에 만기가 지난 자동차 계약 7,217건이 유지로 남아 있었습니다.

만기일이 지나면 만기로 넘기는 판정을 따로 만들고, 동기화도 같은 판정을 쓰게 바꿨습니다. 그 뒤 주간 시험 실행은 무변경 20,830건, 상태 전이 0건이었습니다.

키를 고를 때는 그 키로 한 줄이 무엇을 뜻하는지까지 정해 두세요. 갱신 계약 한 건이 한 줄인지, 차 한 대가 한 줄인지에 따라 중복의 정의가 달라집니다.

줄어들면 멈추는 장치

일정은 두 겹입니다. 업무시간에는 2시간마다 최근 400일 계약일 창과 향후 1년 만기 창을 받습니다.

일요일 새벽에는 전 연도를 훑는 주간 전량을 돌립니다.

400일은 입력 지연을 재 보고 정했습니다. 생명보험은 입력일과 계약일 차이가 중앙값 0일이었지만 상위 1% 끝은 606일이었습니다.

400일 창으로도 그 끝까지는 닿지 않습니다. 나머지 꼬리는 주간 전량이 맡습니다.

주간 전량에는 급감 가드를 붙였습니다. 받아 온 건수가 기존의 80% 미만이면 반영하지 않고 멈춥니다.

0건을 정상 응답으로 돌려주는 시스템이었습니다. 절반만 내려온 파일이 절반이 해지됐다는 기록으로 바뀌는 일을 막으려는 장치입니다.

실장이 방금 입력한 계약을 바로 보고 싶을 때를 위해 즉시 반영 버튼도 붙였습니다. 요청을 넣으면 5초 안에 회차가 시작돼 38초에 끝났습니다.

완료라는 출력을 그대로 믿지 않는 습관도 이때 생겼습니다. 배포 스크립트 출력은 성공처럼 보였는데, 반영 스위치를 켜는 줄은 실행되지 않은 채였습니다.

동기화 실행 기록을 조회하고서야 알았습니다. 그 뒤로는 기록 테이블에 회차가 남았는지로 완료를 판단합니다.

행 수는 맞았던 알림

같은 날 계약 동기화 위에 실효예상·미납 알림을 얹었습니다. 첫 회차 매칭률이 99.9%였고, 저는 그 숫자만 보고 넘어갔습니다.

5주 뒤 다른 점검에서 드러났습니다. 장기·생명의 미납·실효예상 목록은 확인일이 전부 2013년에 멈춘 정지 스냅샷이었습니다.

그 목록으로 실효예상 184건, 미납 약 355건의 알림을 만들고 있었습니다. 확인일 180일 이내 행만 쓰게 고치자 실효예상 알림은 0건이 됐습니다.

자동차 쪽도 비슷했습니다. '분납 미납'이라는 이름의 내려받기 파일은 실제로는 분납월 창에 걸친 자동차 계약을 납입 방식과 상관없이 주고 있었습니다.

그 결과 일시납 계약 96건이 6주 동안 미납 알림으로 설계사 화면에 올라갔습니다.

수집 단계와 알림 단계 양쪽에서 일시납 행과 분납보험료 0원 행을 거르도록 고쳤습니다.

두 번 다 저는 행 수와 매칭률만 봤습니다. 외부 목록을 들일 때는 표본 몇 건을 계약 원장과 직접 맞대 보고, 날짜 열의 분포를 한 번 그려 보세요.

아래는 동기화를 돌리면서 실제로 마주친 숫자와, 그때 먼저 봐야 했던 곳입니다.

이런 숫자가 보이면	먼저 볼 곳
시험 실행 무변경 비율이 낮다	열 매핑이 밀렸는지
어떤 계열이 0행이다	조회 기간을 좁혀 다시 받아 보기
오래된 계약이 무더기로 사라졌다	조회 시작 연도와 기존 데이터 최솟값
같은 계약이 두 줄이다	키 문자열의 표기(정식명·약칭)
같은 차가 해마다 한 줄씩 늘었다	키가 한 줄에 부여하는 뜻
주간 건수가 크게 줄었다	원본 응답이 잘렸는지
매칭률은 높은데 알림이 많다	목록의 확인일 분포와 실제 내용

렌털·유지보수 계약이라면

업종이 달라도 뼈대는 같습니다. 원본 시스템을 정하고, 필드마다 주인을 나누고, 시험 실행의 무변경 비율을 반영의 문으로 삼는 순서입니다.

렌털 계약이면 키가 계약번호일지 장비 일련번호일지가, 유지보수 계약이면 갱신 한 건을 한 줄로 볼지가 첫 결정이 됩니다. 앞의 자동차 사례와 같은 종류의 질문입니다.

GA 지사에서 이 구조가 어떤 화면이 되는지는 이음 데모를 열어 보면 감이 옵니다. 계약 카드와 고객 검색이 익명 데이터로 들어 있습니다.

지금 쓰는 프로그램에서 엑셀이나 목록 화면을 받을 수 있다면 대부분 붙일 수 있습니다. 어디까지 자동으로 가져올지는 옛 프로그램 화면 몇 장이면 가늠이 됩니다. 캡처를 업무 시스템 상담에 붙여 주세요.

붙이기 전에 스스로 물어볼 것

• 전량 시험 실행에서 기존 데이터의 무변경 비율이 몇 %로 나옵니까? 그 숫자를 보기 전에 반영 스위치를 켜지 않을 수 있습니까?
• 원본 시스템이 0건이라고 답할 때, 진짜 0건과 조회 실패를 구분할 수 있습니까?
• '사라짐' 판정의 조회 범위가 기존 데이터의 가장 오래된 날짜부터 시작합니까?
• 회사명·상품명처럼 키에 들어가는 문자열이 양쪽 시스템에서 같은 표기입니까? 한 줄이 무엇을 뜻하는지 정해 두셨습니까?
• 받아 온 건수가 갑자기 줄면 반영을 멈추고 사람에게 알립니까?