디지털 전환, 낡은 시스템을 먼저 버리면 실패한다
새 디지털 솔루션을 도입했는데 업무 속도는 오히려 느려지고, 직원들은 엑셀과 메신저로 돌아갑니다. 이런 상황에서 경영진은 흔히 기존 시스템을 빨리 폐기하자고 말하지만, 현장에서는 그 결정이 더 큰 장애를 만들 수 있습니다. 디지아톰이 기업 시스템 전환을 설계해 온 레거시 현대화 전문가 강하람과 함께, 낡은 IT 시스템을 안전하게 바꾸는 순서를 Q&A로 짚었습니다.
Q. 낡은 시스템을 그대로 두는 것이 왜 디지털 전환인가요?
A. 보존이 아니라 업무 규칙을 발견하는 기간입니다
강하람: 오래된 시스템 자체를 지키자는 뜻은 아닙니다. 먼저 보존해야 할 것은 그 안에 축적된 주문 예외 처리, 거래처별 정산 방식, 승인 권한, 법정 보관 기준 같은 업무 규칙입니다. 화면이 불편하고 기술이 오래됐다는 이유로 시스템부터 제거하면, 문서화되지 않은 규칙까지 함께 사라집니다.
예를 들어 제조기업이 15년 된 발주 시스템을 새 ERP로 교체했다고 가정해 보겠습니다. 기존 시스템에는 긴급 발주 시 품질팀을 자동으로 참조하는 조건과 특정 원자재의 최소 주문 수량이 숨어 있을 수 있습니다. 이 조건을 빠뜨리면 새 시스템은 정상 작동해도 불량 자재가 승인되거나 구매비가 늘어납니다. 디지털의 기본 개념처럼 정보를 일정한 형식으로 표현하는 일과, 기업의 업무 맥락을 옮기는 일은 서로 다른 문제입니다.
따라서 첫 단계는 교체가 아니라 관찰입니다. 현업 담당자가 실제로 어떤 순서로 화면을 이동하는지, 시스템 밖에서 어떤 파일을 만드는지, 오류가 났을 때 누구에게 연락하는지를 확인해야 합니다. 여러분의 회사에도 매뉴얼에는 없지만 특정 직원만 알고 있는 처리법이 있지 않습니까?
- 화면 흐름: 자주 쓰는 메뉴와 반복 입력 항목을 기록합니다.
- 숨은 규칙: 구두 승인, 예외 할인, 수기 보정 조건을 찾습니다.
- 외부 의존성: 엑셀, 이메일, 장비, 거래처 시스템 연결을 표시합니다.
- 폐기 후보: 최근 1년간 사용되지 않은 기능과 중복 보고서를 구분합니다.
“레거시 시스템을 읽지 않고 교체하는 것은 설계도 없이 건물을 철거하는 것과 같습니다. 낡은 코드를 모두 보존할 필요는 없지만, 그 코드가 지키던 업무 규칙은 먼저 찾아야 합니다.”
Q. 전면 교체와 단계적 현대화는 무엇으로 판단합니까?
A. 시스템 연식보다 변경 실패의 영향도를 봅니다
강하람: 구축한 지 오래됐다는 사실만으로 전면 교체를 결정하면 안 됩니다. 장애가 나도 수기로 처리할 수 있는 사내 예약 시스템과, 한 시간만 멈춰도 출고가 중단되는 물류 시스템은 같은 기준으로 평가할 수 없습니다. 핵심은 기술의 나이가 아니라 중단 허용 시간, 데이터 복구 난도, 다른 시스템과의 연결 수입니다.
전면 교체는 기능이 단순하고 데이터 구조가 명확하며, 전환 시점을 한 번에 통제할 수 있을 때 유리합니다. 반면 고객·주문·재고처럼 여러 부서가 공유하는 시스템은 기능을 잘게 나눠 옮기는 편이 안전합니다. 기존 시스템 앞에 API 계층을 두고, 조회 기능부터 새 서비스로 분리한 뒤 입력과 승인 기능을 순차 이전하는 방식이 대표적입니다.
비용도 소프트웨어 구매액만 비교해서는 안 됩니다. 중소 규모 조직의 사전 진단은 범위에 따라 수백만 원에서 수천만 원까지 달라질 수 있고, 실제 구축비는 사용자 수·데이터 품질·연동 개수에 따라 훨씬 크게 벌어집니다. 견적서에는 라이선스뿐 아니라 데이터 정제, 사용자 교육, 병행 운영, 장애 대응 인력과 계약 종료 시 데이터 반출 비용까지 포함해야 합니다.
- 전면 교체가 유리한 경우: 연동이 적고 표준 기능으로 업무를 수용할 수 있습니다.
- 단계 전환이 유리한 경우: 핵심 업무가 24시간 이어지고 연결 시스템이 많습니다.
- 유지 보수가 우선인 경우: 현재 장애 원인이 서버 용량이나 운영 절차에 한정됩니다.
- 재구축이 시급한 경우: 보안 패치를 받을 수 없고 데이터 손상 위험이 반복됩니다.
전환 방식은 점수로 비교할 수 있습니다
각 후보 시스템에 업무 중요도, 보안 노출, 변경 빈도, 연동 복잡도, 공급사 지원 종료 여부를 1~5점으로 매겨 보십시오. 총점만 보는 것이 아니라 보안 노출과 지원 종료 중 하나라도 최고 위험이라면 우선 검토 대상으로 올리는 방식이 실용적입니다. 이 평가는 IT 부서 단독이 아니라 실제 업무 중단 비용을 아는 현업 책임자와 함께 진행해야 합니다.
Q. 새 디지털 솔루션은 어떤 순서로 연결해야 하나요?
A. 읽기 전용 기능에서 시작해 쓰기 권한을 늦게 엽니다
강하람: 첫 연결부터 주문 생성이나 결제 승인처럼 데이터를 바꾸는 기능을 선택하면 작은 오류도 실제 손실로 이어집니다. 초기에는 재고 조회, 진행 상태 확인, 경영 지표 조회처럼 읽기 전용 기능을 새 디지털 솔루션으로 분리하는 편이 좋습니다. 데이터가 다르게 보이더라도 원본을 훼손하지 않아 원인 분석과 복구가 쉽습니다.
다음에는 영향이 제한된 쓰기 기능을 옮깁니다. 사내 공지 등록이나 임시 저장처럼 되돌리기 쉬운 업무가 적합합니다. 이후 주문 변경, 재고 차감, 회계 반영 순으로 범위를 넓히되, 각 단계에서 기존 시스템과 새 시스템의 결과를 대조하는 이중 검증 기간을 둬야 합니다. 단순히 화면 숫자가 같은지 보지 말고 날짜 형식, 반올림, 중복 처리, 취소 후 재처리까지 시험해야 합니다.
정보를 디지털 방식으로 바꾼다는 의미는 디지털 관련 용어 설명에서도 살펴볼 수 있지만, 기업 IT 전환에서는 표현 형식보다 데이터의 책임 주체가 더 중요합니다. 고객 주소는 CRM과 ERP 중 어디가 원본인지, 수정 권한은 어느 부서에 있는지, 충돌하면 무엇을 우선하는지를 명시해야 API 연동이 늘어나도 데이터가 어긋나지 않습니다.
- 1단계 관찰: 로그와 사용자 동선을 수집해 실제 사용 기능을 확인합니다.
- 2단계 조회 분리: 원본 변경이 없는 화면과 보고서를 이전합니다.
- 3단계 제한 쓰기: 되돌릴 수 있는 입력 기능부터 시험합니다.
- 4단계 핵심 거래: 주문·재고·정산을 업무 단위로 순차 이전합니다.
- 5단계 폐쇄: 조회 보관 기간과 감사 요구를 충족한 뒤 구 시스템을 종료합니다.
“새 시스템이 한 번 성공한 것보다 실패했을 때 자동으로 멈추고 이전 상태로 돌아가는지가 더 중요합니다. 좋은 디지털 솔루션은 정상 경로뿐 아니라 복구 경로까지 설계돼 있습니다.”
Q. 성공 여부를 사용자 만족도로만 평가해도 될까요?
A. 체감 개선과 운영 지표를 함께 측정해야 합니다
강하람: 만족도는 필요하지만 그것만으로는 부족합니다. 새 화면이 세련돼 보여도 직원이 같은 정보를 세 번 입력하거나, 월말마다 데이터를 수동 보정한다면 전환 효과가 낮습니다. 반대로 초기에는 익숙하지 않아 불만이 있어도 처리 시간과 오류율이 줄었다면 교육과 화면 개선으로 해결할 여지가 있습니다.
도입 전 4주와 도입 후 4~8주의 기준값을 비교해 보십시오. 주문 한 건을 처리하는 시간, 승인 반려율, 중복 입력 건수, 장애 평균 복구 시간, 시스템 밖 엑셀 파일 수가 대표적인 지표입니다. 특히 수작업 우회 비율은 시스템이 현장에 정착했는지를 잘 보여 줍니다. 사용자는 솔루션이 불편하면 공식적인 오류 신고보다 개인 파일과 메신저를 먼저 선택하기 때문입니다.
경영진에게는 비용 절감액만 보고하지 않는 것이 좋습니다. 업무 리드타임, 데이터 신뢰도, 보안 사고 가능성, 신규 서비스 출시 속도를 함께 보여 주면 디지털 전환의 가치를 균형 있게 판단할 수 있습니다. 디지털 기술이 산업과 생활에 미치는 폭넓은 맥락은 디지털 개념 자료를 참고하되, 사내 평가는 반드시 조직의 실제 업무 데이터로 설계해야 합니다.
- 속도 지표: 접수부터 완료까지 걸린 시간과 대기 시간을 분리합니다.
- 품질 지표: 재처리율, 누락률, 데이터 불일치 건수를 측정합니다.
- 운영 지표: 장애 빈도, 복구 시간, 야간 대응 횟수를 확인합니다.
- 정착 지표: 활성 사용자 비율과 수기 우회 업무를 추적합니다.
- 사업 지표: 신규 상품 등록이나 정책 변경에 필요한 기간을 비교합니다.
숫자가 나빠졌을 때 바로 실패로 단정하지 마십시오
전환 직후에는 교육과 데이터 검증 때문에 처리 시간이 일시적으로 늘 수 있습니다. 이때는 목표치를 낮추기보다 원인을 교육 부족, 화면 설계, 데이터 오류, 권한 승인 지연으로 나눠야 합니다. 2주 단위로 개선 항목과 담당자를 지정하면 솔루션 교체가 필요한 문제와 설정 변경으로 해결할 문제를 구분할 수 있습니다.
Q. 기존 시스템은 언제 꺼야 가장 안전한가요?
A. 새 시스템 가동일이 아니라 되돌아갈 필요가 없어진 날입니다
강하람: 실무자가 가장 자주 묻는 질문입니다. 새 디지털 솔루션을 열었다고 기존 시스템을 바로 종료하면 안 됩니다. 최소한 월말 마감, 분기 정산, 반품이나 계약 갱신처럼 주기가 긴 업무를 새 시스템에서 한 번 이상 통과시켜야 숨어 있던 예외를 확인할 수 있습니다. 병행 운영 기간은 무조건 몇 개월이라고 정하기보다 업무 주기와 법정 보관 의무를 기준으로 결정해야 합니다.
다만 병행 운영이 길수록 안전하다는 생각도 위험합니다. 두 시스템에 동시에 입력하면 원본이 둘로 나뉘고, 직원마다 편한 화면을 선택해 데이터가 갈라집니다. 병행 기간에는 기존 시스템을 가능한 한 조회 전용으로 전환하고, 신규 입력은 새 시스템 한 곳에서만 받는 원칙이 필요합니다. 불가피하게 기존 시스템에 입력해야 한다면 대상 업무, 승인자, 사후 동기화 시간을 명확히 남겨야 합니다.
종료 직전에는 데이터 건수만 맞추지 말고 표본 거래의 전체 이력을 추적하십시오. 주문 생성부터 수정, 취소, 환불, 회계 반영까지 연결되는지 확인하고 백업 파일을 실제로 복원해 조회할 수 있어야 합니다. 공급사 계약 해지 전에 데이터 추출 형식, 첨부파일 포함 여부, 관리자 계정 폐기, 연동 키 회수와 로그 보관 위치도 확정해야 합니다.
- 종료 승인 조건을 문서화합니다. 핵심 업무 완료율과 허용 오류 수준을 숫자로 정합니다.
- 최종 동기화 시간을 고정합니다. 변경을 멈추는 시점과 책임자를 공지합니다.
- 복원 시험을 수행합니다. 백업을 별도 환경에 복원해 검색과 출력까지 확인합니다.
- 접근 권한을 단계적으로 닫습니다. 일반 사용자, 운영자, 공급사 계정 순으로 회수합니다.
- 비상 복귀 조건을 남깁니다. 어떤 장애에서 누가 복귀를 승인하는지 정합니다.
가장 현실적인 종료 기준은 “새 시스템이 잘 돌아간다”가 아닙니다. 구 시스템 없이도 다음 정산 주기를 처리하고, 오류가 발생해도 정해진 시간 안에 복구할 수 있다는 증거가 확보됐는지가 기준입니다. 이 조건이 충족되면 오래된 시스템을 붙잡는 비용을 줄이면서도, 성급한 폐기로 생길 수 있는 업무 공백을 피할 수 있습니다.
- 다음글기업 데이터 백업은 복구 테스트까지 해야 완성된다 26.08.16
등록된 댓글이 없습니다.