“데이터는 옮기기만 하면 되죠?” 기업 비즈니스 솔루션의 함정

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

새로운 시스템의 기능 시연은 매끄러웠는데, 개통 첫날부터 고객명이 두 번 표시되고 지난 계약서가 검색되지 않습니다. 담당자는 솔루션 오류라고 말하고 공급사는 원본 데이터 문제라고 답합니다. 하지만 이런 혼란의 시작점은 대개 제품이 아니라 데이터 이전을 단순 복사 작업으로 취급한 결정에 있습니다.

기업 비즈니스 솔루션은 업무 흐름과 데이터를 함께 다루는 서비스입니다. 데이터의 뜻과 품질을 정리하지 않은 채 새 도구로 옮기면 오래된 문제가 더 빠르게 확산됩니다. 아래 실패 사례를 살펴보며 우리 기업이 피해야 할 선택을 짚어보겠습니다.

“엑셀만 넘기면 끝나요”라는 말부터 의심하세요

파일 개수보다 데이터의 의미가 중요합니다

한 유통기업은 거래처 관리 엑셀 18개를 신규 CRM에 올리면 이전이 끝난다고 판단했습니다. 실제로는 같은 거래처가 사업자번호, 상호명, 담당자 휴대전화 중 서로 다른 기준으로 저장돼 있었습니다. ‘서울상사’, ‘(주)서울상사’, ‘서울상사 주식회사’를 별개 고객으로 인식하면서 영업 실적과 미수금이 세 갈래로 나뉘었습니다.

기업 비즈니스 솔루션 도입 전에 해야 할 일은 파일 전송이 아니라 데이터 정의입니다. 고객, 계약, 상품, 프로젝트처럼 핵심 객체가 무엇인지 정하고 각 객체를 구별하는 고유 기준을 합의해야 합니다. 비즈니스라는 용어의 넓은 의미는 네이버 지식백과의 비즈니스 설명에서도 확인할 수 있지만, 실제 기업에서는 그 개념을 자사 업무 단위와 데이터 구조로 구체화해야 합니다.

담당자에게 “엑셀 몇 개입니까?”만 묻지 마세요. 대신 “한 고객을 무엇으로 식별합니까?”, “폐업 거래처도 보존합니까?”, “담당자가 바뀌면 과거 기록은 누구에게 귀속됩니까?”라고 물어야 합니다. 이 질문에 답하지 못하면 이전 일정이 짧아 보여도 개통 후 수정 비용은 커집니다.

• 하지 말아야 할 일: 파일명과 열 제목만 보고 이전 범위를 확정하기
• 먼저 확인할 것: 필수값, 고유키, 중복 기준, 데이터 소유 부서
• 판단 기준: 한 건의 데이터가 생성되고 변경되며 폐기되는 전 과정
• 실무 팁: 전체 자료가 아니라 대표 파일 3~5개를 골라 값의 패턴부터 비교하기

전문가 팁: 이전 견적을 받을 때 레코드 수뿐 아니라 중복 제거, 코드 변환, 첨부파일 연결, 오류 재처리 비용이 포함됐는지 확인해야 합니다.

“오래된 자료도 전부 필요합니다”가 비용을 키웁니다

보관과 운영을 같은 요구로 묶지 마세요

과거 데이터는 중요하지만 모든 기록을 새 시스템의 운영 화면에 넣을 필요는 없습니다. 12년치 상담 이력과 종료된 프로젝트 자료를 한꺼번에 옮긴 제조기업은 검색 속도가 느려졌고, 사용자는 현재 고객과 과거 고객을 매번 필터로 구분해야 했습니다. 보존해야 할 자료와 매일 활용할 자료를 구별하지 않은 결과입니다.

이때 흔히 드는 비용은 단순 저장 용량만이 아닙니다. 오래된 필드의 변환 규칙을 만들고, 깨진 날짜와 퇴사자 계정을 보정하며, 누락된 첨부파일을 대조하는 인건비가 발생합니다. 기업 규모와 데이터 상태에 따라 차이가 크지만, 정제 작업은 전체 이전 일정에서 상당한 비중을 차지할 수 있으므로 무료 이전이라는 문구만으로 비용을 판단해서는 안 됩니다.

자료를 최근 운영 데이터, 조회 전용 이력, 법적 보존 자료, 폐기 검토 대상으로 나누어 보세요. 현재 업무에 필요한 2~3년치는 새 솔루션으로 옮기고 그 이전 자료는 접근권한이 통제된 별도 보관소에 두는 방식도 가능합니다. 단, 보존기간은 계약과 내부 규정, 개인정보 관련 의무를 함께 검토해 기업별로 결정해야 합니다.

• 사용 빈도와 보존 의무를 별도로 표시합니다.
• 이전하지 않은 자료의 검색 방법과 담당자를 정합니다.
• 원본 백업의 보관 위치와 복구 책임자를 문서화합니다.
• 개인정보가 포함된 열은 최소 수집 원칙에 맞는지 재검토합니다.

“샘플이 맞았으니 전체도 맞겠죠?”를 믿지 마세요

성공 건보다 실패하기 쉬운 경계값을 시험합니다

샘플 100건을 문제없이 옮겼다고 해서 50만 건도 안전하다는 뜻은 아닙니다. 샘플이 최근 정상 데이터로만 구성됐다면 글자 수가 긴 주소, 빈 사업자번호, 윤년 날짜, 특수문자가 포함된 상품명, 여러 계약에 연결된 고객처럼 까다로운 사례가 빠질 수 있습니다. 실제 장애는 평범한 데이터보다 이런 경계값에서 시작합니다.

어느 서비스기업은 고객 기본정보 샘플만 검증하고 전체 이전을 승인했습니다. 개통 후 상담 메모의 줄바꿈이 사라졌고, ‘처리 보류’ 상태가 모두 ‘처리 완료’로 바뀌었습니다. 건수는 일치했지만 데이터가 가진 업무 의미는 달라진 것입니다. 숫자 합계만 맞추는 검수로는 이런 오류를 찾기 어렵습니다.

테스트는 최소 두 번 진행하는 편이 안전합니다. 1차에서는 변환 규칙과 오류 유형을 발견하고, 2차에서는 수정된 규칙으로 실제 개통과 유사한 물량을 옮겨 소요 시간과 재처리 절차를 확인합니다. 솔루션 서비스의 기술적 가능성뿐 아니라 조직이 새 데이터로 주문, 승인, 정산을 끝까지 수행할 수 있는지도 시험해야 합니다.

1. 건수 검증: 원본과 대상 시스템의 총건수 및 제외 건수를 비교합니다.
2. 값 검증: 금액 합계, 날짜, 상태 코드, 한글·영문·특수문자를 대조합니다.
3. 관계 검증: 고객과 계약, 주문과 상품, 프로젝트와 담당자 연결을 확인합니다.
4. 업무 검증: 이전된 데이터로 조회, 수정, 승인, 보고서 생성을 수행합니다.
5. 예외 검증: 오류 건을 수정한 뒤 재업로드해 중복 생성 여부를 살핍니다.

검수표에 ‘정상’만 적지 말고 원본 값, 변환 값, 예상 결과, 실제 결과, 판정자를 남기세요. 그래야 공급사와 기업 담당자가 같은 기준으로 오류를 논의할 수 있습니다.

“개통일에 한 번에 바꾸죠?”가 현장을 멈춥니다

전환 당일의 빈 시간을 계산해야 합니다

데이터 이전에는 원본을 추출한 뒤 새 시스템에 적재하기까지 업무가 계속되는 문제가 있습니다. 금요일 오후에 데이터를 뽑고 월요일 아침에 개통한다면 그 사이 접수된 주문과 수정된 고객정보를 어떻게 반영할까요? 이 기간의 변경분을 처리할 계획이 없으면 최신 정보가 사라지거나 두 시스템에 서로 다른 값이 남습니다.

또 다른 실수는 복구 계획 없이 기존 시스템을 즉시 닫는 것입니다. 신규 솔루션에서 세금계산서 연동이나 권한 설정 문제가 발생했는데 원래 시스템에 접속할 수 없다면 영업과 회계 업무가 동시에 멈출 수 있습니다. 전환 계획에는 성공 절차뿐 아니라 중단 기준과 되돌림 조건이 포함되어야 합니다.

기술 중심 기업의 사업 선정 사례를 다룬 딥테크 기업 관련 네이버 뉴스처럼 기술 경쟁력은 중요한 평가 요소입니다. 그러나 사내 솔루션 전환에서는 화려한 기술 소개와 별개로 업무 연속성, 담당자 대응 시간, 장애 시 복구 가능성을 구체적으로 검증해야 합니다. 공급사의 성공 사례만 듣지 말고 실패 상황에서 누가 무엇을 하는지 물어보세요.

• 변경 동결 시간: 기존 시스템 입력을 멈추는 정확한 시각을 공지합니다.
• 증분 이전: 1차 추출 이후 새로 생기거나 수정된 데이터만 다시 옮깁니다.
• 개통 판정: 필수 업무 시나리오가 통과해야 사용할 수 있도록 기준을 세웁니다.
• 되돌림 조건: 중대한 오류의 범위와 결정권자를 사전에 지정합니다.
• 비상 기록: 장애 중 접수되는 주문과 요청을 임시 양식에 남겨 누락을 막습니다.

책임자를 한 사람으로 몰아세우지 않습니다

IT 담당자 한 명에게 추출, 정제, 사용자 안내, 장애 접수까지 맡기면 병목이 생깁니다. 데이터 내용을 아는 현업 책임자, 이전 작업을 수행하는 공급사, 보안과 보존 기준을 확인하는 관리자, 최종 개통을 승인하는 의사결정자의 역할을 나누어야 합니다. 책임을 나눈다는 것은 책임을 흐리는 일이 아니라 판단 지점을 명확히 만드는 일입니다.

• 현업 부서장은 데이터 의미와 업무 결과를 승인합니다.
• 솔루션 공급사는 변환 규칙, 오류 목록, 재처리 결과를 제공합니다.
• 보안 담당자는 계정, 접근권한, 전송 및 백업 방식을 확인합니다.
• 총괄 책임자는 개통 또는 연기 결정을 내리고 전 부서에 알립니다.

한빛유통의 72시간, 주문 누락을 막은 실제 전환 과정

실패 직전 발견한 고객 코드 충돌

직원 46명의 가상 기업 한빛유통은 영업·재고·고객관리를 묶는 기업 비즈니스 솔루션으로 전환하려 했습니다. 처음 계획은 금요일 저녁에 엑셀과 기존 프로그램 데이터를 모두 추출하고 월요일에 바로 개통하는 것이었습니다. 하지만 사전 검증에서 같은 고객 코드가 온라인몰과 도매 관리 파일에 각각 다른 거래처로 쓰이고 있다는 사실이 발견됐습니다.

팀은 개통을 무작정 미루는 대신 고객 식별 기준을 사업자번호와 내부 보조키의 조합으로 바꿨습니다. 사업자번호가 없는 개인 고객에는 신규 고유번호를 부여하고, 거래 이력이 없는 중복 고객은 자동 합치지 않고 영업팀이 검토하도록 분리했습니다. 이름이 같다는 이유만으로 합쳤다면 서로 다른 고객의 주소와 미수금이 섞일 수 있었기 때문입니다.

금요일 오후 6시에는 기존 시스템의 일반 입력을 멈추고 긴급 주문만 별도 양식에 기록했습니다. 토요일 오전 1차 적재 후 고객 수, 미수금 합계, 재고 수량을 비교했고, 일요일에는 영업 담당자 세 명이 실제 고객 조회부터 주문 승인까지 수행했습니다. 이때 반품 상태 코드 두 개가 신규 솔루션의 하나의 코드로 합쳐지는 문제가 발견되어 변환 규칙을 추가했습니다.

1. 금요일 18시: 입력 동결과 원본 백업을 완료하고 파일별 해시값과 추출 건수를 기록했습니다.
2. 토요일 10시: 1차 적재에서 고객 코드 충돌 37건과 빈 담당자 64건을 오류 목록으로 분리했습니다.
3. 토요일 16시: 영업팀이 충돌 고객을 확인하고 공급사가 수정 규칙을 반영했습니다.
4. 일요일 14시: 주문·반품·정산 시나리오를 실행하고 재고 합계 차이 8건을 수정했습니다.
5. 월요일 08시: 동결 기간 긴급 주문을 증분 반영한 뒤 총괄 책임자가 개통을 승인했습니다.

월요일 오전 한 직원이 과거 반품을 검색하지 못했지만, 팀은 즉시 장애로 단정하지 않았습니다. 조회 전용 보관소로 분류된 5년 전 자료임을 확인하고 접근 경로를 안내했습니다. 반면 토요일에 발견한 재고 차이는 개통을 막는 중대 오류로 분류했습니다. 모든 문제를 같은 심각도로 다루지 않은 기준이 빠른 대응을 가능하게 한 셈입니다.

한빛유통은 이전 후 2주 동안 기존 시스템을 읽기 전용으로 유지하고 매일 오전 오류 현황을 공유했습니다. 영업팀은 고객 연결 오류를, 물류팀은 재고와 반품 상태를, 회계팀은 미수금 합계를 확인했습니다. 마지막 남은 중복 고객 한 건까지 소유 부서의 승인을 받아 병합하면서 전환은 끝났습니다. 성공을 만든 것은 “한 번에 완벽하게 옮긴다”는 자신감이 아니라, 어디에서 틀릴 수 있는지 예상하고 멈춤·수정·재개 절차를 준비한 운영 방식이었습니다.