기업 비즈니스 서비스 교체를 고민한다면 종료 조건부터 물어보세요

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

계약 기간은 아직 남았는데 현업에서는 “더는 못 쓰겠다”는 말이 나옵니다. 기능 부족보다 느린 응답, 예상 밖의 추가 비용, 다른 시스템과 맞지 않는 데이터 형식이 불만을 키우는 경우가 많습니다. 그런데 급하게 새 기업 솔루션부터 찾으면 기존 데이터를 옮기지 못하거나 두 서비스를 동시에 결제하는 문제가 생깁니다.

SSMO는 기업 서비스 전환을 자문해 온 문해온 컨설턴트에게 도입보다 어려운 ‘잘 떠나는 방법’을 물었습니다. 이번 인터뷰에서는 계약 종료 조건, 데이터 이관, 업무 공백, 공급사 평가까지 실무자가 바로 활용할 수 있는 질문을 중심으로 살펴봅니다.

서비스가 불편하면 바로 교체해도 될까요?

Q. 불만과 교체 사유는 어떻게 구분합니까?

A. 사용자가 불편하다는 사실은 중요한 신호지만, 곧바로 교체해야 한다는 뜻은 아닙니다. 먼저 문제가 제품 기능, 운영 정책, 사내 교육, 공급사의 지원 품질 중 어디에서 발생했는지 분리해야 합니다. 예를 들어 결재가 느린 원인이 솔루션 성능이 아니라 승인 단계를 여섯 번 거치도록 만든 사내 규정이라면 서비스를 바꿔도 체감 속도는 거의 달라지지 않습니다.

교체 판단에는 감상보다 반복 가능한 지표가 필요합니다. 최근 3개월간 장애 시간, 문의 후 첫 답변까지 걸린 시간, 수작업 보정 건수, 월간 활성 사용자 비율을 기록해 보세요. 비즈니스의 기본 개념처럼 기업 활동은 단일 기능이 아니라 여러 이해관계와 운영 과정의 결합입니다. 따라서 한 부서의 불만만으로 전사 서비스를 교체하면 다른 부서가 얻고 있던 효율을 잃을 수 있습니다.

Q. 그래도 교체 검토를 시작해야 하는 명확한 신호가 있나요? 핵심 업무가 멈추는 장애가 반복되거나, 보안 요구를 충족하지 못하거나, 계약 범위 밖의 수작업이 계속 늘어난다면 공식적인 검토가 필요합니다. 특히 공급사가 문제를 인정하면서도 개선 일정과 책임자를 제시하지 못한다면 단순 불편이 아니라 운영 지속성의 위험으로 봐야 합니다.

• 즉시 검토: 중대한 보안 취약점, 법적 보존 의무 미충족, 반복되는 핵심 업무 중단
• 조건부 검토: 지원 지연, 낮은 사용률, 예상보다 큰 추가 비용
• 내부 개선 우선: 교육 부족, 복잡한 사내 승인 규정, 부정확한 기초 데이터
• 관찰 필요: 일회성 장애나 특정 사용자에게만 발생한 설정 문제

“교체의 출발점은 새 제품의 데모가 아니라, 현재 서비스에서 무엇이 왜 실패했는지 한 문장으로 합의하는 일입니다.”

계약서에서 가장 먼저 찾아야 할 문장은 무엇입니까?

Q. 종료일만 확인하면 충분하지 않나요?

A. 계약 만료일은 시작에 불과합니다. 자동 갱신 거절 통보 기한, 중도 해지 위약금, 데이터 추출 비용, 종료 후 기술지원 기간을 함께 확인해야 합니다. 만료 30일 전에 통보하면 된다고 생각했는데 실제 계약서에는 90일 전 서면 통지가 필요하다고 적혀 있다면 원치 않는 1년 계약이 연장될 수 있습니다.

계약 본문뿐 아니라 견적서, 서비스 수준 협약, 개인정보 처리 부속서도 읽어야 합니다. 본문에는 “데이터 반환”이라고만 쓰고 부속 문서에서 반환 형식을 공급사 전용 파일로 제한하는 사례가 있습니다. 이 경우 데이터는 받았지만 새로운 비즈니스 서비스로 불러올 수 없어 별도의 변환 비용이 발생합니다. 담당자가 바뀌었더라도 최초 제안서와 이메일 약속까지 모아 실제 합의 범위를 대조해야 합니다.

Q. 비용은 어떤 항목까지 계산해야 합니까? 월 이용료 차액만 비교하면 전환 비용을 심각하게 낮춰 잡게 됩니다. 기존 계약의 잔여 금액, 데이터 가공, 신규 환경 설정, 임시 인력, 사용자 재교육, 병행 운영 기간의 이중 구독료를 포함해야 합니다. 중견기업 기준으로도 데이터 구조와 연동 수에 따라 전환 작업비가 수백만 원에서 수천만 원까지 달라질 수 있으므로, 숫자를 확정 견적으로 오해하지 말고 범위별 예산으로 관리하는 편이 안전합니다.

1. 자동 갱신 여부와 해지 통보 마감일을 달력에 등록합니다.
2. 원본 데이터와 첨부파일의 반환 형식을 확인합니다.
3. 종료 지원 시간과 시간당 추가 비용을 묻습니다.
4. 계정 폐쇄 후 데이터 보관·파기 시점을 문서로 받습니다.
5. 위약금과 병행 운영비를 포함한 총전환비용을 산정합니다.

데이터를 받는 것과 옮기는 것은 왜 다른가요?

Q. 엑셀이나 CSV로 내려받으면 끝 아닌가요?

A. 표 형식의 데이터만 보면 그렇게 생각하기 쉽습니다. 하지만 실제 기업 데이터에는 사용자 ID, 거래처 코드, 결재 이력, 댓글, 첨부파일, 변경 기록처럼 서로 연결된 정보가 포함됩니다. 고객 목록은 내려받았어도 상담 기록의 작성자와 첨부파일 경로가 끊기면 새 시스템에서 업무 맥락을 복원할 수 없습니다.

추출 전에 데이터 명세서를 먼저 작성해야 합니다. 필드 이름, 데이터 유형, 필수 여부, 코드값, 연결 키, 보존 기간을 적고 신규 공급사와 함께 매핑합니다. 디지털 환경에서 거래와 업무가 연결되는 구조는 이비즈니스의 개념에서도 확인할 수 있습니다. 데이터 이관을 단순 파일 복사로 보면 시스템 사이의 관계와 업무 규칙을 놓치게 됩니다.

Q. 이관 테스트는 어떻게 진행합니까? 전체 자료를 한 번에 옮기지 말고 대표 표본을 선택합니다. 정상 거래 20건뿐 아니라 취소된 주문, 퇴사자 승인 기록, 이름이 같은 거래처, 대용량 첨부파일처럼 실패 가능성이 높은 예외를 포함해야 합니다. 테스트 후에는 건수만 맞추지 말고 금액 합계, 날짜, 권한, 검색 결과까지 대조해야 합니다.

• 필수 필드가 빈 값으로 들어간 레코드를 별도로 집계합니다.
• 주민등록번호와 계좌번호 같은 민감정보는 암호화 상태를 점검합니다.
• 원본과 신규 시스템의 시간대 설정이 같은지 확인합니다.
• 실패 데이터를 재처리하는 절차와 담당자를 미리 지정합니다.

업무를 멈추지 않고 전환하려면 무엇을 겹쳐 운영합니까?

Q. 병행 운영은 오래 할수록 안전합니까?

A. 병행 기간이 길다고 무조건 안전한 것은 아닙니다. 두 시스템에 같은 내용을 입력하면 현업의 업무량이 늘고 어느 쪽이 최신 정보인지 다투게 됩니다. 핵심은 기간보다 기준 시스템을 명확히 정하는 것입니다. 전환 전날까지 기존 서비스를 원본으로 삼고, 전환 시각 이후에는 신규 솔루션만 수정하도록 규칙을 만들어야 합니다.

업무 중요도에 따라 병행 범위를 다르게 잡는 것이 현실적입니다. 사내 공지처럼 복구가 쉬운 기능은 짧게 시험해도 되지만, 급여·결제·고객 주문처럼 오류 비용이 큰 업무는 최소 한 번의 완전한 업무 주기를 검증해야 합니다. 월말 정산 서비스라면 며칠 사용해 보고 안정적이라고 판단할 것이 아니라 실제 월말 처리와 보고서 마감까지 통과해야 합니다.

Q. 전환 당일에는 누가 무엇을 결정합니까? 공급사 엔지니어만으로는 부족합니다. 업무 중단 여부를 판단할 현업 책임자, 개인정보 사고를 살필 보안 담당자, 직원에게 공지할 커뮤니케이션 담당자가 필요합니다. 오류가 발견됐을 때 계속 진행할지 기존 환경으로 되돌릴지를 결정하는 기준도 수치로 정해야 현장에서 논쟁이 길어지지 않습니다.

1. D-30: 최종 이관 범위와 제외 데이터를 승인합니다.
2. D-14: 표본 이관, 연동, 권한 테스트를 완료합니다.
3. D-3: 사용자 공지와 비상 연락망을 배포합니다.
4. D-day: 변경을 동결하고 최종 데이터를 추출·검증합니다.
5. D+7: 오류 목록을 닫고 기존 시스템을 읽기 전용으로 전환합니다.

“롤백은 실패를 인정하는 절차가 아닙니다. 고객 주문이나 급여 처리를 지키기 위해 미리 설계하는 정상적인 안전장치입니다.”

새 공급사 인터뷰에서는 어떤 답을 경계해야 하나요?

Q. 데모가 훌륭하면 기능 검증은 끝난 것 아닙니까?

A. 데모는 가장 잘 준비된 경로를 보여주는 자리입니다. 실제 업무에는 승인 반려, 중복 고객, 외부 협력자, 퇴사자 계정처럼 깔끔하지 않은 상황이 훨씬 많습니다. “가능합니다”라는 답을 들었다면 기본 제공인지, 별도 개발인지, 추가 요금이 있는지, 언제 제공되는지를 다시 물어야 합니다. 화면이 예쁜 것보다 예외 상황을 어떻게 처리하는지가 운영 품질을 좌우합니다.

공급사의 설명을 비교하려면 모든 후보에게 같은 시나리오를 제시하세요. 예를 들어 “퇴사한 영업 담당자의 미완료 계약 300건을 팀장에게 넘기고 감사 기록은 보존해 달라”고 요청합니다. 후보별 답변이 표준 기능, 설정 변경, 개발 필요로 갈리면 비용과 일정의 차이가 선명해집니다. 계약서에는 제안 단계의 핵심 답변을 요구사항과 검수 기준으로 옮겨야 합니다.

Q. 지원 체계는 무엇을 물어야 합니까? ‘전담 지원’이라는 표현만 믿지 말고 담당 인원, 운영 시간, 긴급 장애 접수 채널, 목표 응답 시간, 에스컬레이션 단계를 확인합니다. 담당자의 휴가나 퇴사 때 대체 인력이 있는지도 중요합니다. 해외 본사의 승인 없이는 오류를 고칠 수 없는 구조라면 국내 담당자가 친절해도 복구가 늦어질 수 있습니다.

• 데이터 추출 기능을 고객이 직접 사용할 수 있는지 묻습니다.
• API 호출량 제한과 초과 요금이 얼마인지 확인합니다.
• 최근 장애 사례의 원인과 재발 방지 조치를 요청합니다.
• 맞춤 개발 결과물의 소유권과 유지보수 범위를 확인합니다.
• 계약 종료 시 지원 절차를 제안 단계에서 시연하게 합니다.

답변을 점수로 바꾸는 간단한 방법

기능 30점, 데이터 이동성 25점, 지원 20점, 보안 15점, 비용 예측 가능성 10점처럼 평가 항목을 정할 수 있습니다. 회사마다 비중은 달라도 좋지만 평가 전에 배점을 확정해야 유명 공급사나 화려한 발표에 점수가 쏠리지 않습니다. 탈퇴와 데이터 반환이 쉬운 서비스는 공급사가 고객 유지에 자신 있다는 간접 신호이기도 합니다.

빠른 교체와 단계적 전환, 우리 회사에는 어느 쪽이 맞습니까?

Q. 한 번에 바꿀지 부서별로 바꿀지 결정하는 기준은 무엇입니까?

A. 데이터 구조가 단순하고 사용자 수가 적으며 업무 중단 시 수기 대체가 가능한 회사라면 짧고 집중적인 전환이 유리합니다. 두 환경을 오래 유지하는 비용을 줄일 수 있고 사용자에게 하나의 운영 기준을 제시하기 쉽습니다. 다만 전환 직전에 전체 백업을 확보하고, 치명적 오류가 발생했을 때 기존 서비스로 돌아갈 수 있는 시간 제한을 정해야 합니다.

반대로 여러 지점과 외부 파트너가 같은 시스템을 쓰거나 ERP·회계·물류 연동이 복잡한 기업이라면 단계적 전환이 적합합니다. 한 지점이나 한 업무를 먼저 옮겨 실제 부하와 지원 품질을 확인하고, 발견한 오류를 다음 단계에 반영할 수 있습니다. 대신 구형 시스템과 신규 기업 비즈니스 서비스 사이에서 데이터가 갈라지지 않도록 임시 동기화 규칙과 최종 책임 시스템을 지정해야 합니다.

Q. 최종 선택 전에 대표가 확인할 숫자는 무엇입니까? 계약 금액보다 업무 복구 목표 시간, 허용 가능한 데이터 손실량, 전환 기간의 생산성 저하를 보아야 합니다. 전환비가 저렴해도 주문 처리 중단이 하루 발생하면 절감액보다 손실이 커질 수 있습니다. 각 부서는 ‘불편하다’는 표현 대신 시간과 건수로 영향을 제출하고, 의사결정자는 이를 동일한 기준으로 비교해야 합니다.

• 직원 50명 안팎이고 연동이 적다면: 주말 또는 비수기에 집중 전환하고 다음 영업일에 지원 인력을 배치하세요.
• 다지점·다법인이고 핵심 연동이 많다면: 대표 조직을 먼저 전환한 뒤 업무 주기별 검증을 거쳐 순차 확대하세요.
• 서비스 불만은 크지만 원인이 불명확하다면: 교체 계약보다 4주간의 문제 진단과 데이터 표본 추출을 먼저 진행하세요.
• 계약 갱신일이 임박했다면: 성급히 신규 장기계약을 맺지 말고 단기 연장 또는 전환 지원 조건을 협상하세요.

따라서 소규모 조직에서 자료 구조가 단순하고 의사결정자가 현장에 가까운 독자라면 짧은 집중 전환을 권합니다. 반면 고객 거래가 실시간으로 쌓이고 여러 시스템이 맞물린 기업의 독자라면 비용이 조금 더 들더라도 단계적 전환과 업무 주기별 검증을 선택하는 편이 안전합니다.