2026 비즈니스 솔루션 구매 전 SLA 점검 가이드

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

기능 시연에서는 완벽했던 솔루션이 실제 장애 상황에서는 담당자와 연결조차 되지 않는다면 어떨까요? 비즈니스 솔루션을 구매할 때 화면과 기능만 비교하면 가동률, 기술지원, 복구 시간, 보상 조건이라는 중요한 운영 비용을 놓치기 쉽습니다. 특히 여러 업무가 클라우드 서비스에 연결된 2026년에는 장애 대응 수준까지 확인해야 실질적인 구매 비교가 가능합니다.

사업 활동의 기본 개념은 네이버 지식백과의 비즈니스 정의에서도 살펴볼 수 있습니다. 조직의 목표를 달성하려면 솔루션 자체보다 서비스가 업무 흐름을 얼마나 안정적으로 뒷받침하는지를 봐야 합니다. 아래 점검표를 제안서 검토, 데모 미팅, 최종 계약 협의에 차례로 활용해 보세요.

1. 구매 전에 우리 회사의 서비스 기준부터 정하기

핵심 업무와 일반 업무를 먼저 구분합니다

SLA는 Service Level Agreement의 약자로, 공급자가 제공할 서비스 수준과 장애 발생 시 책임 범위를 정한 약속입니다. 그러나 모든 시스템에 똑같이 높은 기준을 적용하면 비용만 늘어날 수 있습니다. 먼저 도입하려는 비즈니스 솔루션이 멈췄을 때 어느 업무가 얼마나 영향을 받는지를 파악해야 합니다.

예를 들어 사내 게시판이 한 시간 중단되는 상황과 주문·결제 시스템이 한 시간 중단되는 상황의 손실은 전혀 다릅니다. 영업관리 서비스라면 견적 발송과 고객 이력 조회가 막힐 수 있고, 전자계약 솔루션이라면 계약 체결 일정이 지연될 수 있습니다. 담당자가 단순히 ‘중요하다’고 평가하지 말고 중단 시간당 처리하지 못하는 건수와 영향을 받는 인원을 적어보는 것이 좋습니다.

• 업무 영향도: 중단되면 매출, 고객 응대 또는 법정 기한에 영향을 주는지 확인합니다.
• 허용 중단 시간: 10분, 1시간, 4시간, 하루 중 어느 수준까지 버틸 수 있는지 정합니다.
• 사용 시간대: 평일 업무시간만 필요한지, 야간·주말에도 반드시 운영되어야 하는지 표시합니다.
• 대체 절차: 서비스가 멈췄을 때 엑셀, 전화, 수기 문서 등으로 임시 운영할 수 있는지 점검합니다.
• 연결 시스템: 회계, 그룹웨어, 고객관리, 인증 서비스와 연동되어 장애가 확산될 가능성을 확인합니다.

요구사항을 숫자로 바꾸는 질문

부서별 인터뷰에서는 “안정적이어야 한다”처럼 해석이 달라지는 표현을 피해야 합니다. 대신 “월간 누적 중단을 몇 분까지 허용할 수 있는가?”, “장애 접수 후 최초 답변은 몇 분 안에 필요한가?”라고 질문하세요. 이런 숫자가 있어야 공급사 제안서의 기준과 같은 단위로 비교할 수 있습니다.

실무 팁: 높은 가동률을 무조건 요구하기 전에 예상 손실액과 추가 이용료를 비교하세요. 장애로 인한 월간 예상 손실보다 고가 요금제의 추가 비용이 크다면 대체 업무 절차를 강화하는 편이 합리적일 수 있습니다.

2. 가동률 숫자에서 반드시 확인할 조건

99.9%라는 숫자만 믿으면 안 되는 이유

가동률은 일반적으로 전체 측정 시간 중 서비스를 정상적으로 사용할 수 있었던 시간을 뜻하지만, 공급사마다 ‘정상’과 ‘중단’의 정의가 다릅니다. 로그인은 되지만 핵심 데이터를 저장할 수 없는 상태를 정상으로 볼 수도 있고, 사전 공지한 정기점검 시간을 계산에서 제외할 수도 있습니다. 따라서 가동률 수치보다 산식과 제외 조건을 먼저 읽어야 합니다.

월 30일을 단순 기준으로 보면 99.9% 가동률은 약 43분, 99.5%는 약 3시간 36분의 중단 가능 시간에 해당합니다. 다만 이는 이해를 돕기 위한 계산이며 실제 계약에서는 측정 기간, 계획 점검, 고객 측 네트워크 장애, 외부 연동 서비스 장애 등의 제외 여부에 따라 결과가 달라집니다. 월 단위인지 분기 단위인지도 꼭 비교해야 합니다.

1. 가동률을 월간, 분기 또는 연간 중 어떤 기간으로 산정하는지 확인합니다.
2. 웹 화면, 모바일 앱, API 가운데 어느 기능이 측정 대상인지 적습니다.
3. 속도가 지나치게 느리거나 일부 기능만 실패한 경우 장애로 인정되는지 묻습니다.
4. 정기점검의 허용 시간과 최소 사전 공지 기간을 확인합니다.
5. 클라우드, 통신망, 인증 및 외부 API 장애를 모두 면책하는지 검토합니다.
6. 측정 자료가 공급사 기록만으로 결정되는지, 고객 측 로그도 증빙으로 인정되는지 확인합니다.

데모 미팅에서 요청할 증빙

판매 담당자의 구두 설명만으로 안정성을 판단하지 마세요. 최근 6개월 또는 12개월의 월별 가동률, 주요 장애 이력, 장애 후 개선 보고서의 익명화 예시를 요청하는 편이 좋습니다. 상태 페이지가 있다면 장애 발생 시점과 공지 시점 사이의 차이도 살펴보세요. 반복 장애가 있었더라도 원인과 재발 방지 조치가 투명하면 오히려 운영 역량을 판단하는 근거가 됩니다.

• 최근 실제 가동률 보고서가 제공되는가?
• 고객이 직접 확인할 수 있는 상태 페이지가 있는가?
• 장애 시작·복구 시각과 영향받은 기능이 기록되는가?
• 중대 장애 후 원인분석 보고서를 받을 수 있는가?
• 고객별 사용 환경을 구분한 모니터링 자료가 제공되는가?

3. 기술지원과 장애 대응 체계를 검증하는 체크리스트

응답 시간과 해결 시간은 서로 다릅니다

‘30분 이내 대응’이라는 문구는 문제가 30분 안에 해결된다는 뜻이 아닐 수 있습니다. 자동 접수 메일이나 담당자의 최초 확인만으로 응답 조건을 충족하는 계약도 있기 때문입니다. 최초 응답 시간, 임시 복구 시간, 최종 해결 목표를 구분하고 각각의 측정 시작점과 종료점을 확인해야 합니다.

장애 등급도 공급사가 일방적으로 판단하도록 두면 실제 업무 피해와 다르게 분류될 수 있습니다. 전사 로그인이 불가능한 상태는 긴급 등급으로 쉽게 합의할 수 있지만, 특정 부서의 데이터 내보내기 실패는 해석이 갈릴 수 있습니다. 핵심 기능과 사용자 범위를 기준으로 등급 예시를 계약 부속 문서에 남기면 분쟁을 줄일 수 있습니다.

지원 품질을 직접 시험하는 방법

무료 체험이나 검증 기간에는 기능만 눌러보지 말고 실제 문의도 접수해 보세요. 연동 오류, 사용자 추가, 데이터 복원처럼 난도가 다른 질문을 보내 응답 속도와 답변의 구체성을 비교합니다. 상담원이 매번 설명을 처음부터 요구하는지, 이전 문의 이력이 다음 담당자에게 전달되는지도 중요한 평가 요소입니다.

• 긴급 장애를 가정한 모의 접수 절차를 실행합니다.
• 담당자가 부재할 때 대체 담당자에게 자동으로 넘어가는지 확인합니다.
• 한국어 기술지원의 실제 운영 시간과 해외 본사 이관 여부를 묻습니다.
• 전담 매니저 제공 여부와 포함되는 요금제를 확인합니다.
• 월별 문의 통계와 반복 문제 개선안을 받을 수 있는지 점검합니다.

전문가 조언: 지원 인력이 있다는 답변만으로는 부족합니다. 긴급 상황에서 누가, 어떤 채널로, 몇 분 안에 의사결정을 내리는지 연락망 형태로 받아 두세요.

4. 가격표 밖에서 발생하는 비용과 보상 조건 확인

저렴한 월 이용료가 총비용을 뜻하지 않습니다

비즈니스 서비스 견적은 사용자당 월 요금만 보면 간단해 보이지만 초기 설정, 데이터 이관, 관리자 교육, API 호출, 저장 용량, 프리미엄 지원 비용이 별도로 붙을 수 있습니다. 인원이 늘거나 업무량이 증가했을 때 단가가 어떻게 달라지는지도 중요합니다. 구매 전에는 최소 1년과 3년 기준의 총소유비용을 각각 계산해 보세요.

구축형 서비스라면 컨설팅 인력의 작업 범위와 추가 작업 단가를 확인해야 합니다. SaaS라도 원하는 리포트 제작이나 연동 설정을 유료 개발로 처리하는 사례가 있습니다. 견적서에 ‘별도 협의’라고 표시된 항목은 예상 수량과 단가를 넣어 다시 받아야 예산 초과를 방지할 수 있습니다. 영문 용어가 혼재된 제안서를 검토한다면 business 용어 설명처럼 기본 정의를 함께 확인하는 것도 문맥을 맞추는 데 도움이 됩니다.

• 초기 비용: 환경 설정, 데이터 정제·이관, 연동 개발, 교육 비용
• 반복 비용: 사용자 라이선스, 저장 공간, API 사용량, 기술지원 요금
• 확장 비용: 조직 추가, 해외 지사 지원, 고급 보안 및 감사 기능
• 변경 비용: 업무 프로세스 수정, 보고서 추가, 재교육 및 테스트
• 종료 비용: 데이터 추출, 보관 연장, 전환 지원, 조기 해지 수수료

서비스 크레딧의 실효성 점검

SLA 미달 보상은 현금 환불보다 다음 청구액에서 차감하는 서비스 크레딧 형태가 흔합니다. 보상 비율이 충분한지뿐 아니라 고객이 정해진 기간 안에 직접 신청해야 하는지 확인하세요. 공급사가 자동으로 계산하지 않고 장애 후 7일 또는 30일 안에 증빙을 제출하도록 요구한다면 내부 담당자를 미리 지정해야 합니다.

1. 보상이 자동 적용되는지 별도 청구가 필요한지 확인합니다.
2. 청구 기한, 필요 로그, 제출 채널을 계약서에 표시합니다.
3. 월 이용료 중 어느 항목을 기준으로 보상액을 계산하는지 묻습니다.
4. 반복적인 SLA 미달 시 위약금 없이 해지할 권리가 있는지 검토합니다.
5. 크레딧이 유일한 구제 수단인지, 중대한 과실에는 별도 책임이 적용되는지 확인합니다.

5. 최종 승인 전 실행하는 단계별 구매 점검표

제안서부터 계약 부속서까지 같은 내용인지 대조합니다

좋은 조건을 제안서에서 확인했더라도 최종 계약서에 반영되지 않으면 실제 권리로 인정받기 어렵습니다. 영업 미팅 자료, 견적서, 보안 답변서, SLA 문서의 표현을 한 줄씩 대조하세요. 특히 “지원 가능”이라는 설명이 계약서에서는 “상업적으로 합리적인 범위에서 노력”으로 바뀌지 않았는지 살펴볼 필요가 있습니다.

승인 담당자는 구매팀에만 한정하지 않는 편이 안전합니다. 현업은 기능 적합성, IT 부서는 연동과 복구, 보안 담당자는 접근 통제, 재무팀은 총비용, 법무 담당자는 책임과 해지 조건을 확인해야 합니다. 작은 조직이라 담당자가 겹치더라도 평가 관점은 분리해 기록하세요. 질문에 답하지 못한 항목은 ‘추후 확인’으로 넘기지 말고 계약 전 미해결 목록으로 관리합니다.

1. 1단계 요구 정의: 핵심 업무, 허용 중단 시간, 필수 지원 시간을 한 장으로 작성합니다.
2. 2단계 후보 비교: 동일한 질문지를 모든 공급사에 보내 답변 형식을 통일합니다.
3. 3단계 검증 운영: 실제 데이터 일부와 대표 업무 시나리오로 체험 또는 개념검증을 진행합니다.
4. 4단계 장애 시험: 문의 접수, 백업 확인, 복구 요청, 상태 공지 절차를 모의 실행합니다.
5. 5단계 비용 계산: 도입·운영·확장·종료 비용을 1년 및 3년 기준으로 합산합니다.
6. 6단계 문서 반영: 구두 약속과 제안 조건을 계약 본문 또는 부속서에 명시합니다.
7. 7단계 책임 지정: 가동률 확인, 장애 청구, 갱신 검토를 맡을 내부 관리자를 정합니다.

계약 직전 예·아니요로 답할 12문항

아래 항목 중 ‘아니요’가 하나라도 핵심 업무와 관련된다면 구매 승인을 잠시 보류하고 보완 조건을 요청하세요. 모든 요구를 최고 수준으로 맞출 필요는 없지만, 수용한 위험과 대응책은 기록해야 합니다. 이 문서는 갱신 시점에 공급사의 약속과 실제 성과를 비교하는 기준으로도 활용할 수 있습니다.

• 가동률의 측정 대상과 계산식이 문서에 명시되어 있는가?
• 정기점검과 면책되는 장애의 범위가 합리적인가?
• 핵심 기능의 부분 장애도 중단 시간에 포함되는가?
• 긴급 장애의 최초 응답 및 복구 목표 시간이 구분되어 있는가?
• 야간과 주말에 사용할 공식 긴급 연락 채널이 있는가?
• 장애 등급을 고객 업무 영향에 따라 조정할 수 있는가?
• 백업 주기와 실제 복원 시험 결과를 확인했는가?
• 서비스 미달 보상의 신청 절차와 기한을 알고 있는가?
• 반복 장애가 발생할 때 해지하거나 조건을 재협상할 수 있는가?
• 숨은 비용을 포함한 3년 총소유비용을 계산했는가?
• 계약 종료 시 데이터를 표준 형식으로 돌려받을 수 있는가?
• 영업 담당자의 주요 약속이 최종 계약 문서에 반영되었는가?

USJ 비즈니스 솔루션 구매 점검표의 목적은 가장 많은 기능을 가진 제품을 찾는 데 있지 않습니다. 회사가 감당할 수 있는 비용 안에서 필요한 서비스 수준을 명확하게 확보하는 것이 핵심입니다. 체크 결과와 예외 승인 사유를 한 문서로 보관하면 신규 구매뿐 아니라 연간 갱신, 공급사 평가, 장애 후 개선 협의에도 일관된 기준을 적용할 수 있습니다.