기업은 왜 DOS를 끄지 못할까: 오래된 화면 뒤에 숨은 교체 비용
핵심 요약
- DOS 프로그램을 교체할 때는 화면뿐 아니라 업무 규칙과 연결 장비까지 손봐야 할 수 있습니다.
- 오래된 시스템을 옮길 때는 예외 처리와 담당자의 경험도 함께 확인해야 합니다.
- 지금 정상 작동하는 시스템도 고장 후 복구할 수 있는지는 따로 점검해야 합니다.
- 현대화는 기존 업무의 결과를 확인하면서 기능별로 나누어 진행할 수 있습니다.
업무 시스템을 클라우드로 옮기려는데 DOS 프로그램이 여전히 중요한 일을 맡고 있다면 당황스러울 수 있습니다. 그 프로그램으로 주문을 처리하고 출하 서류를 뽑고 있다면 쉽게 바꾸기도 어렵습니다. 새 시스템을 고를 때부터 매일 하던 업무를 어떻게 이어갈지 함께 생각해야 합니다.
화면이 오래돼도 계속 쓰는 이유가 있습니다
가상의 부품 유통업체를 예로 들어 보겠습니다. 직원은 DOS 프로그램에 품목 번호를 입력하고, 재고를 확인한 뒤 거래명세서를 출력합니다. 화면은 투박하지만 담당자는 단축키를 외우고 있고, 필요한 서류도 정해진 양식으로 나옵니다.
이런 곳에서는 디자인만으로 새 시스템이 더 낫다고 설명하기 어렵습니다. 기존보다 입력이 번거로워지거나 출력 양식이 달라지면 직원이 해야 할 일도 늘어납니다. 관리자는 데이터 분석 기능을 원하고, 현장 직원은 주문을 빨리 처리하는 데 더 무게를 둘 수 있습니다. 같은 시스템을 두고도 평가 기준이 다른 셈입니다.
정해진 업무를 반복하는 프로그램은 기능이 적어서 쓰기 편할 때도 있습니다. 사용자가 익혀야 할 것이 적고 처리 절차도 일정하기 때문입니다. 다만 이런 업무상의 익숙함만으로 시스템 전체가 안전하다고 볼 수는 없습니다.
코드와 함께 옮겨야 할 업무 규칙
같은 업체에서 특정 거래처의 반품을 처리한다고 가정해 보겠습니다. 프로그램이 재고는 즉시 늘리되 정산 금액은 다음 달에 반영하도록 만들어져 있을 수 있습니다. 거래처마다 품목 코드를 다르게 쓰는 규칙이 들어 있을 수도 있습니다.
이런 조건을 빠뜨리면 새 프로그램이 정상적으로 실행돼도 잘못된 결과가 나올 수 있습니다. 주문 화면이 열리고 저장 버튼이 작동한다고 해서 교체가 끝났다고 보기 어려운 이유입니다.
문서에 없는 규칙도 확인해야 합니다. 담당자가 특정 상황에서 입력 순서를 바꾸거나, 출력물을 확인한 뒤 수작업으로 값을 보정해 왔다면 그 절차까지 알아야 합니다. 프로그램이 처리하는 일과 사람이 따로 하는 일을 함께 봐야 실제 업무를 파악할 수 있습니다.
그래서 교체 비용을 따질 때는 개발비 외에도 업무 규칙을 확인하는 시간을 고려해야 합니다. 기존 데이터를 새 구조에 맞추고 직원을 교육하는 데도 시간이 듭니다. 처리 결과를 대조하고, 전환 중에 오류가 생기면 어떻게 대응할지도 준비해야 합니다. 작은 프로그램처럼 보여도 업무에서 맡은 역할에 따라 옮기는 일이 커질 수 있습니다.
잘 돌아가는 것과 복구할 수 있는 것은 다릅니다
“어제도 문제없이 썼습니다.”
운영 담당자에게는 중요한 말입니다. 하지만 이 말만으로 내일 고장이 나도 업무를 이어갈 수 있을지는 알 수 없습니다. 지금 쓰는 컴퓨터가 멈췄을 때 다른 장비에서 다시 실행할 수 있는지, 필요한 설치 파일과 설정이 남아 있는지도 확인해야 합니다.
백업도 파일이 있다는 것만으로는 충분하지 않습니다. 복원한 데이터로 프로그램을 실행해 필요한 내용을 조회하고 출력할 수 있어야 업무를 다시 시작할 수 있습니다.
주변 장비가 연결돼 있다면 살펴볼 곳이 더 늘어납니다. 특정 프린터나 직렬 포트 장비를 쓰는 프로그램은 실행 환경을 바꾸는 과정에서 연결 문제가 생길 수 있습니다. 가상머신이나 에뮬레이터에서 프로그램이 실행되더라도 실제 장비와 그대로 통신할 수 있는지는 따로 확인해야 합니다.
계속 쓸지 판단할 때는 평소에 얼마나 편리한지와 함께 복구 가능성을 봐야 합니다. 문제를 아는 사람이 한 명뿐인지, 대신 쓸 장비가 있는지에 따라 같은 프로그램을 유지하는 부담도 달라집니다.
현대화는 업무를 확인하면서 나눠 진행할 수 있습니다
처음부터 모든 기능을 새로 만들 필요는 없습니다. 우선 프로그램에 무엇을 입력하고 어떤 결과를 받는지 정리할 수 있습니다. 연결된 장비와 사람이 따로 처리하는 절차도 함께 살펴봅니다. 이렇게 정리하면 무엇을 유지하고 무엇을 바꿀지 판단하기가 수월해집니다.
예를 들어 주문 처리는 기존 프로그램에 맡기고, 외부에서 필요한 보고서는 내보낸 데이터로 만들 수 있습니다. 다만 이 방식을 쓸 수 있는지는 데이터 추출 기능이나 안정적인 연결 방법이 있는지에 따라 달라집니다.
기능을 옮길 때는 같은 값을 입력해 기존 시스템과 새 시스템의 결과를 비교할 수 있습니다. 정상 주문 외에 반품이나 취소도 확인하고, 월말 마감처럼 조건이 달라지는 사례도 포함해야 합니다. 결과에 차이가 있다면 새로 만든 프로그램의 오류 때문인지, 기존 규칙을 의도적으로 바꿨기 때문인지 구분해야 합니다.
실제 거래를 확정하는 기능은 더 주의해서 다뤄야 합니다. 결과를 비교하려고 두 시스템에서 같은 주문을 처리하다가 중복 출하나 중복 청구가 생겨서는 안 됩니다. 시험 환경과 실제로 처리할 범위를 정하고, 문제가 생겼을 때 기존 방식으로 돌아갈 절차도 준비해야 합니다.
익숙한 업무 방식을 지키려고 DOS를 계속 쓸 수 있습니다. 다만 교체를 미루는 사이 복구 수단이나 유지보수에 필요한 지식이 사라지고 있지는 않은지 살펴야 합니다. 우리 회사의 오래된 시스템이 고장 나도 다시 업무를 시작할 수 있는 상태인지 지금 확인해야 합니다.
댓글
댓글을 불러오는 중...