엑셀 고객관리의 한계, 같은 고객이 두 줄이 될 때가 신호입니다

고객 목록에 같은 이름이 두 번 나왔습니다. 생년월일 여섯 자리도 같았습니다.

그런데 한 줄은 1925년생, 다른 한 줄은 2025년생이었습니다. 백 살 어르신과 갓난아기가 같은 사람이었던 겁니다.

계약은 둘로 나뉘어 붙어 있었습니다. 어느 화면도 경고를 띄우지 않았습니다.

원장 엑셀에는 두 줄 모두 250314로 똑같이 적혀 있었습니다. 갈라진 건 그 엑셀을 시스템으로 옮긴 다음이었습니다.

보험대리점(GA) 지사에 계약관리 시스템 이음을 만들어 드리던 중에 본 장면입니다. 그 한 사람을 다시 한 명으로 합치기까지 한 일을 적습니다.

엑셀 원장을 언제 시스템으로 옮겨야 하는지, 제 판단 기준도 끝에 붙였습니다.

경고 없이 두 사람이 된 고객

이름이 흔하면 생년까지 겹치는 동명이인도 있습니다.

이 두 줄은 달랐습니다. 여섯 자리는 똑같고 앞에 붙은 세기만 달랐습니다.

같은 기준으로 전체를 조회하니 이런 경우가 한둘이 아니었습니다. 생년 해석이 뒤집힌 인물이 112건 나왔습니다.

데이터 몇 줄을 고치고 끝낼 일로 보이지 않았습니다. 같은 원인이 여러 사람의 계약에 반복해서 걸려 있었습니다.

두 자리 생년이 갈라지는 구조

원장에는 생년월일이 여섯 자리로 적혀 있었습니다. 250314라고 쓰면 1925년인지 2025년인지는 적혀 있지 않습니다.

엑셀을 시스템에 들일 때 제 변환 코드가 세기를 추론했습니다. 계약연도를 보고 나이가 말이 되는 쪽을 고르는 식이었습니다.

문제는 이 추론을 계약마다 따로 했다는 점입니다. 2025년에 든 계약은 백 살과 0살이 둘 다 가능해 보였고, 코드는 그럴 때 1900년대로 기울었습니다.

다음 해 계약은 백 살을 넘기니 2000년대가 됐습니다. 같은 아기가 첫 계약에선 1925년생, 다음 계약에선 2025년생이 된 겁니다.

시스템은 이름과 여덟 자리 생년을 묶어 사람을 구분했습니다. 생년이 다르니 묶음 키가 달라지고, 한 명이 두 명으로 쪼개졌습니다.

따져 보니 헷갈릴 수 있는 경우는 좁았습니다. 계약연도가 2000에 생년 두 자리를 더한 해와 같을 때, 곧 태어난 해에 가입한 계약뿐이었습니다.

태어난 해에 아기 이름으로 드는 계약이 바로 그 자리에 걸립니다. 좁은 경계였지만 한 사람의 계약 여러 건에 걸쳐 반복됐습니다.

원장은 계약 한 줄마다 이름과 두 자리 생년을 다시 적는 구조였습니다. 사람에게 붙는 번호는 따로 없었습니다.

그래서 데이터를 옮기는 순간 줄마다 해석이 갈릴 틈이 생깁니다. 사람 단위 원장이었다면 생년 해석은 한 사람에 한 번이면 됩니다.

같은 사람이 계약 네 건이면 이름과 생년도 네 번 적힙니다. 네 줄 중 하나만 다르게 읽혀도 시스템에는 고객이 두 명 생깁니다.

흩어진 줄이 보내는 신호

제가 이번에 본 것은 한 사람이 몇 줄에 흩어져 있는 상태였습니다. 그 줄들이 같은 사람이라는 사실은 아무도 보장하지 않았습니다.

이름 띄어쓰기, 옛 이름과 새 이름, 휴대폰 번호 한 자리 차이도 같은 일을 만듭니다.

이런 중복은 보험료 합계를 틀리게 하지 않아서 늦게 발견됩니다. 계약 줄은 그대로고 사람만 갈라지기 때문입니다.

대신 고객 수가 실제보다 많아 보이고, 한 사람에게 갈 안내가 두 갈래로 나뉠 수 있습니다.

손으로 쓰던 원장

같은 무렵 그 엑셀이 손으로 쓰던 파일이라는 걸 알게 됐습니다. 저는 회사 전산에서 내려받은 파일인 줄 알았습니다.

내려받은 파일이면 원천 전산이 정본입니다. 손으로 쓴 파일은 그 엑셀 자체가 정본입니다.

그래서 엑셀을 매번 올리는 방식을 그만두기로 했습니다. 이음 안에 같은 양식의 입력 화면을 만들고 신규·편집·상태변경·삭제를 거기서 하게 했습니다.

입력 화면에서는 이름과 생년이 같은 기존 고객이 있으면 그 사람을 다시 씁니다.

주민번호가 들어오면 생년과 성별은 번호에서 끌어냅니다. 사람이 고르는 칸을 줄인 것입니다.

엑셀 업로드 화면은 은퇴시켰습니다. 그 뒤 원장의 원본을 어디에 둘지는 한 번 더 바뀌었습니다. 그 뒷이야기는 옛 영업관리 시스템에서 매일 계약을 옮기는 글에 적었습니다.

원본 파일이 사라진 날

교정하려고 보니 원본 xls가 어디에도 없었습니다. 전날 원본을 다른 곳으로 격리하면서 PC와 저장소 양쪽에서 지워졌던 겁니다.

원본이 있으면 고친 코드로 처음부터 다시 적재해 보고 결과를 맞춰 볼 수 있습니다. 그 길이 막혔습니다.

결국 데이터베이스 안에서 직접 SQL로 분석하고 고치는 쪽으로 돌아갔습니다. 손이 훨씬 많이 가고 실수할 자리도 늘어나는 방식입니다.

이 일로 원칙 하나를 세웠습니다. 원본 파일은 재현 자산이니 적어도 한 벌은 손닿는 곳에 남깁니다.

고치는 순서와 되감기

데이터를 고칠 때는 이 순서를 지켰습니다.

1. 고칠 표 전체를 백업 표로 떠 둡니다.
2. 교정 스크립트를 트랜잭션 안에서 돌린 뒤 되감아(ROLLBACK) 결과만 확인합니다.
3. 숫자가 맞으면 같은 스크립트를 그대로 확정(COMMIT)합니다.

되감기 단계에서 먼저 막혔습니다. 지우려던 중복 인물을 알림과 상담기록이 붙잡고 있어서 삭제가 거부됐습니다.

저는 이 연결을 미리 몰랐습니다. 되감기 없이 확정부터 했다면 중간에 멈춘 반쪽 상태를 수습해야 했을 겁니다.

둘은 성격이 달라 다르게 처리했습니다. 상담기록은 사람이 쓴 기록이라 남는 쪽 인물로 옮겼고, 알림은 다시 계산하면 되는 값이라 지운 뒤 새로 만들었습니다.

생년만 고치고 묶음 키를 그대로 두면 다음 적재 때 다시 쪼개집니다. 그래서 키도 같은 교정 스크립트에서 함께 고쳤습니다.

항목	결과 (2026-08-20 교정 기준)
생년 해석을 바로잡은 인물	112건
짝을 찾아 하나로 합침	22건
합칠 짝 없이 생년·키만 수정	90건
전체 인물 수	7,044명 → 7,022명
남은 경계 사례·주인 없는 계약	0건

인물 수가 22명 줄었습니다. 병합 22건만큼 줄어든 숫자입니다.

엑셀 한 장에 담기지 않는 것

같은 시스템에 고객과 계약을 잇는 장치도 들어갔습니다. 고객 상세에서 계약 이름을 누르면 그 계약 상세로 바로 넘어갑니다.

권한도 사람 단위로 걸었습니다. 설계사는 본인이 담당한 계약만 봅니다.

담당자는 처음 계약을 받은 설계사로 고정했습니다. 설계사 계정으로 직접 로그인해 남의 계약이 보이지 않는 것까지 확인했습니다.

주민번호는 화면에 가려서 보여 주고, 전체 번호는 관리자만 열 수 있습니다. 누가 열었는지는 기록에 남습니다.

엑셀에서 이걸 흉내 내려면 파일을 사람 수만큼 나누고 암호를 걸어야 합니다. 그러면 한 고객의 줄이 여러 파일에 나뉘어 적힙니다.

같은 구조를 직접 눌러 보고 싶으면 이음 체험판이 있습니다. 고객 검색에서 계약 상세로 넘어가는 흐름이 실제와 같은 화면이고, 데이터는 전부 가상입니다.

넘어갈 시점을 가르는 문항

엑셀을 계속 쓸지 시스템으로 옮길지는 아래 질문으로 가늠해 보세요. 지금 원장을 옆에 띄워 놓고 답하시면 됩니다.

• 같은 사람이 표기나 생년 차이로 두 줄 이상 있습니까? 이름으로 정렬해 바로 아래 줄과 비교해 보세요.
• 원본 파일이 누구 PC에 있는지, 어제 판이 어디 남아 있는지 바로 답할 수 있습니까?
• 사람마다 보면 안 되는 열이나 줄이 있습니까? 주민번호 열이나 다른 담당자의 계약 줄 같은 것입니다.
• 누가 언제 이 줄을 열고 고쳤는지 물으면 답할 수 있습니까?
• 잘못 고쳤을 때 되돌릴 방법이 '어제 파일 다시 열기'뿐입니까?

두 개 이상에 걸린다면 시스템을 검토할 때입니다. 하나뿐이면 엑셀 안에서 입력 규칙을 다듬는 쪽이 먼저일 수 있습니다.

걸린 질문 수	제가 권하는 다음 걸음
0~1개	엑셀 유지, 입력 양식과 중복 검사 정비
2~3개	사람 단위 원장과 권한부터 시스템으로
4개 이상	원본 백업부터 확보한 뒤 이전 계획 수립

보험대리점이라면 보험GA 실무 교육의 계약관리 과정이 이 판단에 가깝습니다. 고객 한 명에 계약 여러 건이 붙는 구조와 중복이 생기는 자리를 짚고, 옮기기 전에 쓰는 계약 데이터 점검표를 만듭니다.

지금 원장을 이름순으로 정렬하면, 같은 사람으로 보이는 두 줄이 몇 쌍이나 나올까요?