기업 서비스는 많이 받을수록 손해다, SLA부터 정해야 하는 이유

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

전문 서비스 계약을 앞두고 제공 항목부터 늘리고 있나요? 보고서, 정기회의, 긴급 대응, 교육까지 많이 넣으면 안전해 보이지만, 정작 언제 무엇을 어느 수준으로 제공받는지 정하지 않으면 비용만 커지고 책임은 흐려질 수 있습니다. 처음 기업 서비스를 구매하는 담당자라면 서비스 목록보다 먼저 SLA를 이해해야 합니다.

서비스 목록보다 SLA를 먼저 봐야 하는 까닭

SLA는 약속을 측정 가능한 문장으로 바꾸는 장치입니다

SLA는 Service Level Agreement의 약자로, 우리말로는 서비스 수준 협약이라고 부릅니다. 공급사가 제공할 업무의 범위뿐 아니라 응답 시간, 처리 기준, 운영 시간, 측정 방법, 보고 주기와 예외 조건을 합의한 문서입니다. 단순히 “신속하게 지원한다”라고 쓰는 대신 장애 접수 후 30분 이내에 최초 응답한다처럼 확인 가능한 기준을 적는 것이 핵심입니다.

여기서 서비스는 제품처럼 한 번 넘겨받고 끝나는 대상과 다릅니다. 개념의 기본 배경은 지식백과의 서비스 정의에서도 살펴볼 수 있습니다. 기업 현장에서는 사람의 대응, 업무 절차, 시스템 상태가 함께 결과를 만들기 때문에 제공 항목이 많아도 품질 기준이 모호하면 체감 만족도가 낮아집니다.

예를 들어 월간 보고서를 받기로 했더라도 제출일, 포함 지표, 오류 수정 기한이 없다면 담당자마다 기대하는 결과가 달라집니다. 반대로 보고서가 세 쪽뿐이어도 핵심 지표, 원인 분석, 다음 행동이 정해져 있다면 의사결정에 훨씬 유용합니다. 많은 산출물보다 예측 가능한 서비스가 초보 구매자에게 더 중요한 이유입니다.

• 서비스 범위: 공급사가 수행하는 일과 수행하지 않는 일을 구분합니다.
• 수준 기준: 응답 시간, 처리 시간, 가동률, 정확도처럼 숫자로 확인할 항목을 정합니다.
• 측정 방식: 어떤 시스템의 기록을 기준으로 삼을지 합의합니다.
• 예외 조건: 고객사 지연, 천재지변, 사전 공지된 점검처럼 책임에서 제외되는 상황을 적습니다.
• 미달 대응: 재발 방지 보고, 서비스 크레딧, 개선 회의 등 후속 조치를 정합니다.

초보 담당자에게 가장 유용한 질문은 “무엇을 해주나요?”보다 “잘했다고 판단할 증거는 무엇인가요?”입니다.

처음 계약할 때 숫자는 세 가지만 정해도 됩니다

응답 시간과 해결 시간은 서로 다른 기준입니다

SLA를 처음 작성한다고 모든 업무를 수치화할 필요는 없습니다. 우선 장애나 요청이 접수됐음을 알리는 최초 응답 시간, 정상 상태로 돌려놓는 목표 복구 시간, 약속을 지킨 비율인 준수율부터 정하면 됩니다. 세 지표만 명확해도 공급사의 운영 역량을 비교하기 쉬워집니다.

가장 흔한 실수는 응답 시간을 해결 시간으로 오해하는 것입니다. “1시간 이내 대응”은 담당자가 접수 사실을 알리는 데 한 시간이 걸린다는 뜻일 수 있으며, 문제를 한 시간 안에 해결한다는 약속은 아닙니다. 견적서나 계약서에서 대응, 조치, 복구, 해결이라는 단어가 섞여 있다면 각각의 시작점과 종료점을 질문해야 합니다.

중요도 등급도 너무 복잡하게 나누지 않는 편이 좋습니다. 입문 단계에서는 전사 업무가 멈춘 긴급 장애, 일부 기능이 제한된 주요 장애, 일반 문의의 세 단계면 충분합니다. 모든 요청을 긴급으로 지정하면 실제 위기 때 우선순위가 작동하지 않고, 높은 대응 인력을 상시 확보하느라 서비스 가격도 상승합니다.

1. 긴급: 핵심 업무가 중단되고 우회 방법이 없는 상태입니다. 24시간 접수가 필요한지 함께 판단합니다.
2. 주요: 업무 영향은 크지만 임시 우회가 가능한 상태입니다. 영업시간 기준과 휴일 기준을 분리합니다.
3. 일반: 사용법 문의, 계정 변경, 개선 요청 등을 포함합니다. 처리 기한보다 접수 순서와 진행 상태 공개가 중요합니다.

가동률은 소수점보다 계산 범위가 중요합니다

월 가동률 99.9%라는 문구는 좋아 보이지만 계산 범위를 확인해야 의미가 생깁니다. 24시간 전체를 기준으로 하는지, 평일 업무시간만 포함하는지, 정기 점검과 외부 클라우드 장애를 제외하는지에 따라 실제 허용 중단 시간이 달라집니다. 높은 숫자 하나보다 산식과 제외 조건을 계약서에 남기는 편이 안전합니다.

• 측정 기간은 월간인지 분기인지 확인합니다.
• 장애 시작 시각을 고객 신고 시점과 모니터링 감지 시점 중 무엇으로 볼지 정합니다.
• 계획 점검을 제외한다면 최소 사전 통지 시간을 설정합니다.
• 외부 연동 장애가 반복될 때 공급사가 수행할 우회 조치도 적습니다.

비용을 낮추려면 서비스 범위에 경계선을 그어야 합니다

월정액에 포함된 업무부터 한 문장씩 확인합니다

기업 컨설팅이나 운영 솔루션의 가격은 업종, 사용자 수, 시스템 복잡도, 대응 시간에 따라 크게 달라 단일 시세로 판단하기 어렵습니다. 대신 견적을 초기 구축비, 정기 운영비, 건별 추가비로 나눠 보면 비교가 쉬워집니다. 월정액이 저렴해도 데이터 수정, 현장 방문, 야간 대응이 모두 별도라면 실제 연간 비용은 더 높을 수 있습니다.

가상의 예로 A사는 월 150만 원에 월 20시간 지원을 제공하고, B사는 월 210만 원에 시간 제한 없이 표준 요청을 처리한다고 가정해 보겠습니다. 요청이 적은 회사에는 A사가 유리하지만 매주 데이터 정비와 사용자 교육이 필요한 회사에는 B사가 예측 가능한 선택일 수 있습니다. 따라서 가격표를 볼 때는 “얼마인가요?”와 함께 “우리의 평범한 한 달을 대입하면 얼마인가요?”라고 물어야 합니다.

서비스 제공자의 역량도 기술 자격증 하나로만 판단하기 어렵습니다. 디지털 서비스는 기술, 업무 이해, 커뮤니케이션이 함께 작동하며, 융합형 인재 교육 사례를 다룬 기사처럼 여러 분야를 연결하는 역량이 강조돼 왔습니다. 공급사 인터뷰에서는 개발 인력 수뿐 아니라 장애 설명 방식, 담당자 교체 절차, 산업 이해 경험도 확인하는 편이 좋습니다.

• 포함 범위: 계정 관리, 설정 변경, 정기 보고, 교육, 데이터 보정이 기본료에 들어가는지 묻습니다.
• 제외 범위: 신규 기능 개발, 타 시스템 연동, 출장, 야간 작업의 별도 단가를 확인합니다.
• 요청 단위: 한 건의 정의와 최소 청구 시간을 확인해 작은 요청이 과금되는 방식을 파악합니다.
• 인상 조건: 사용자 수나 데이터량 증가에 따른 요금 구간을 미리 받습니다.
• 종료 비용: 데이터 반출, 문서 인계, 계정 이전에 추가 비용이 발생하는지 확인합니다.

첫 상담에서는 우리 회사의 상황을 숫자로 보여줍니다

공급사가 정확한 제안을 만들려면 고객도 기본 정보를 준비해야 합니다. 사용자 수, 월평균 문의 건수, 핵심 업무시간, 현재 장애 빈도, 연결할 시스템 수를 한 장에 적어 전달해 보세요. 요구사항이 완벽하지 않아도 현재 상태가 숫자로 보이면 과도한 사양과 누락된 업무를 동시에 줄일 수 있습니다.

1. 최근 3개월의 반복 문의와 장애를 모읍니다.
2. 업무 중단 시 손실이 큰 기능을 세 개만 고릅니다.
3. 반드시 필요한 운영 시간과 있으면 좋은 운영 시간을 구분합니다.
4. 같은 조건표를 최소 두 곳에 전달해 제안 범위를 비교합니다.
5. 계약 전 실제 보고서나 장애 보고서의 익명화된 예시를 요청합니다.

SLA의 목적은 공급사를 벌주는 데 있지 않습니다. 문제가 생겼을 때 고객과 공급사가 같은 순서로 움직이게 만드는 운영 설계도에 가깝습니다.

“작은 회사도 SLA가 필요한가요?”에 대한 현실적인 답

직원이 적을수록 짧은 SLA가 더 효과적입니다

작은 회사에는 복잡한 수십 쪽짜리 SLA가 필요하지 않습니다. 그러나 담당자가 한두 명뿐이라면 장애 발생 시 대신 판단해 줄 사람이 적기 때문에 최소한의 기준은 오히려 더 중요합니다. 핵심 업무 한두 개와 연락 체계, 응답 시간, 데이터 반환 방식만 정한 1~2쪽짜리 문서로도 충분히 시작할 수 있습니다.

예를 들어 온라인 주문을 처리하는 소규모 기업이라면 모든 기능에 높은 가동률을 요구할 필요가 없습니다. 주문 접수와 결제 연동은 긴급 등급으로 두고, 통계 화면의 글자 오류는 일반 등급으로 분류하면 됩니다. 야간 매출 비중이 낮다면 비싼 24시간 지원 대신 오전 영업 시작 전 복구를 목표로 설정하는 방식이 비용 효율적입니다.

계약 첫 달부터 강한 배상 조항을 넣기보다 4~8주의 측정 기간을 두는 것도 실용적입니다. 이 기간에는 실제 문의량과 해결 시간을 기록하고, 이후 기준이 지나치게 높거나 낮은지 조정합니다. 단, 개인정보 유출이나 데이터 영구 손실처럼 회복하기 어려운 위험은 시험 기간과 무관하게 통지 절차와 책임 범위를 처음부터 명확히 해야 합니다.

• 한 명을 창구로 지정: 직원마다 다른 경로로 요청해 기록이 흩어지는 일을 막습니다.
• 공용 티켓 사용: 이메일이나 메신저 요청도 하나의 관리 목록에 모읍니다.
• 월 1회 지표 확인: 접수 건수, 최초 응답, 미해결 건, 반복 장애만 살펴봅니다.
• 분기별 기준 조정: 실제 업무 영향과 비용을 보고 등급 및 시간을 바꿉니다.
• 종료 시 데이터 확보: 파일 형식, 제공 기한, 삭제 확인서 발급 여부를 문서화합니다.

처음부터 넣을 문장은 네 줄이면 됩니다

첫째, 어떤 상황을 긴급 장애로 볼지 적습니다. 둘째, 긴급 장애의 접수 채널과 최초 응답 시간을 씁니다. 셋째, 해결이 늦어질 때 보고 주기와 임시 우회 방법을 정합니다. 넷째, 계약 종료 후 며칠 안에 어떤 형식으로 데이터를 받을지 명시합니다.

이 네 줄은 화려한 기능 설명보다 실제 운영에서 자주 쓰입니다. 이후 문의가 늘면 중요도별 복구 목표를 추가하고, 서비스가 안정되면 준수율과 개선 목표를 붙이면 됩니다. 작은 회사의 SLA는 대기업 문서를 축소 복사한 계약서가 아니라 우리 팀이 곤란해지는 순간을 기준으로 만든 짧은 약속이어야 합니다.

1. 우리 회사가 멈추면 가장 먼저 확인할 업무를 하나 선택합니다.
2. 그 업무를 담당할 고객사와 공급사 연락처를 각각 지정합니다.
3. 응답, 중간 보고, 임시 복구의 목표 시간을 구분합니다.
4. 한 달간 기록한 뒤 지키기 어려운 기준과 느슨한 기준을 다시 협의합니다.