기업 비즈니스 서비스 SLA는 복잡하게 만들 필요 없다

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

장애가 발생했는데 공급사는 “계약된 가동률을 지켰다”고 말하고, 현업은 “업무가 멈췄는데 무엇을 지켰다는 것이냐”고 반문합니다. 이런 충돌은 서비스 수준 협약서가 없어서라기보다 기업의 실제 업무와 관계없는 지표를 잔뜩 넣었기 때문에 생깁니다.

SSMO는 기업 서비스 품질을 설계해 온 전문가 차은결에게 실무자가 이해하고 운영할 수 있는 SLA 작성법을 물었습니다. 복잡한 산식보다 중요한 기준, 비용과 보상 조건, 장애 대응 시간을 실제 계약에 연결하는 방법을 Q&A 형식으로 짚어봅니다.

Q. SLA 항목이 많을수록 안전한 계약 아닌가요?

A. 측정할 수 없는 약속은 많아도 보호 장치가 되지 않습니다

질문: 기업용 비즈니스 서비스를 계약할 때 공급사가 수십 개의 SLA 지표를 제시합니다. 지표가 많으면 서비스 품질을 더 촘촘하게 관리할 수 있는 것 아닌가요?

답변: 반드시 그렇지는 않습니다. 지표가 많아질수록 안전해지는 것이 아니라, 발주사와 공급사가 같은 방식으로 측정하고 해석할 수 있는 지표가 있을 때 안전해집니다. 예를 들어 ‘신속한 장애 처리’, ‘안정적인 운영’, ‘최상의 지원’은 그럴듯하지만 시작 시점과 완료 조건이 없으므로 위반 여부를 판정할 수 없습니다. 반면 ‘업무 중단 등급의 신고 접수 후 15분 이내 담당자 배정’은 로그와 티켓 기록으로 확인할 수 있습니다.

비즈니스 서비스의 범위부터 합의할 필요도 있습니다. 비즈니스의 개념처럼 기업 활동은 단순한 시스템 사용을 넘어 생산, 판매, 고객 대응과 가치 창출을 포함합니다. 따라서 SLA 역시 서버 상태만 보는 문서가 아니라 서비스가 핵심 업무를 어느 수준으로 지탱해야 하는지를 정의하는 문서여야 합니다.

• 업무 영향: 이 지표가 무너지면 매출, 생산, 고객 응대 중 무엇이 멈추는지 연결합니다.
• 측정 가능성: 티켓, 모니터링 로그, 통화 기록 등 양측이 확인할 원천 데이터를 정합니다.
• 통제 가능성: 공급사가 실제로 관리할 수 없는 통신사 장애나 고객사 내부 문제는 별도로 분리합니다.
• 판정 주기: 월간 평균인지, 장애 건별 기준인지 명시해 평균값 뒤에 심각한 사고가 숨지 않게 합니다.
• 후속 조치: 위반 시 보고서, 개선 계획, 서비스 크레딧 가운데 무엇이 실행되는지 적습니다.

“좋은 SLA는 두꺼운 문서가 아니라 장애가 발생한 밤에도 담당자들이 같은 판단을 내리게 하는 짧고 명확한 운영 규칙입니다.”

Q. 가동률 99.9%만 넣으면 충분하지 않나요?

A. 가동률보다 먼저 업무 중단의 경계를 정해야 합니다

질문: 클라우드나 기업 솔루션 계약에서 가동률 99.9%가 가장 흔한 핵심 수치로 보입니다. 이 숫자 하나만 관리해도 서비스 수준을 판단할 수 있지 않을까요?

답변: 가동률은 필요하지만 단독으로는 부족합니다. 로그인 화면은 열리지만 주문 저장이 되지 않는 상황, 관리자만 접속할 수 있고 고객은 결제하지 못하는 상황, API 응답은 성공으로 기록되지만 데이터가 몇 시간 늦게 동기화되는 상황을 생각해 보세요. 기술 시스템은 살아 있어도 기업 업무는 중단될 수 있습니다. 먼저 ‘사용 가능’의 의미를 핵심 거래가 처음부터 끝까지 정상 완료되는 상태로 정의해야 합니다.

산식의 분모와 제외 시간도 확인해야 합니다. 월 전체 시간을 기준으로 하는지 영업시간만 보는지, 사전 공지된 점검은 모두 제외되는지, 부분 장애는 몇 퍼센트로 계산하는지가 달라지면 같은 사고도 결과가 달라집니다. 디지털 환경에서 거래와 업무가 연결되는 방식은 이비즈니스의 설명을 참고할 수 있으며, 실제 SLA에서는 그 연결 중 어느 단계가 끊기면 실패로 볼지를 기업별로 구체화해야 합니다.

1. 핵심 사용자 여정 선정: 로그인, 주문 등록, 결제 승인, 출고 요청처럼 매출이나 운영에 직접 영향을 주는 흐름을 고릅니다.
2. 성공 조건 정의: 단순 HTTP 응답이 아니라 저장 완료, 승인 번호 생성, 데이터 반영까지 포함할지 결정합니다.
3. 측정 지점 지정: 공급사 서버 내부가 아닌 실제 사용자와 가까운 외부 지점에서도 상태를 측정합니다.
4. 제외 조건 제한: 정기 점검의 사전 통보 기한, 월간 허용 횟수, 최대 지속 시간을 함께 둡니다.
5. 부분 장애 환산: 전체 사용자 중 영향을 받은 비율과 핵심 기능의 중요도를 반영합니다.

A. 평균 응답시간은 느린 사용자를 숨길 수 있습니다

응답속도 역시 월평균만 보면 안 됩니다. 대부분의 요청이 0.5초이고 일부 고객의 요청이 20초여도 평균치는 양호해 보일 수 있습니다. 그래서 실무에서는 ‘전체 요청의 95%가 2초 이내’처럼 백분위 기준을 활용하고, 지점·사용자 유형·핵심 기능별로 나누어 관찰합니다. 모든 화면을 동일하게 관리하기보다 주문 확정이나 고객 조회처럼 업무 손실과 연결되는 기능부터 기준을 두는 편이 비용 효율적입니다.

• 단순 조회 화면은 응답속도 중심으로 측정합니다.
• 데이터 입력 기능은 처리 완료율과 중복 저장 여부를 함께 봅니다.
• 배치 작업은 시작 시간이 아니라 완료 시각과 누락 건수를 관리합니다.
• 외부 API는 성공률뿐 아니라 타임아웃과 재처리 성공률을 기록합니다.

Q. 장애 대응시간은 짧게 잡을수록 좋은가요?

A. 최초 응답과 복구 완료를 분리해야 현실적인 약속이 됩니다

질문: 공급사 비교표를 보면 ‘장애 대응 30분’처럼 짧은 시간이 강조됩니다. 가장 짧은 업체를 선택하면 되는 것인가요?

답변: 먼저 그 30분이 무엇을 의미하는지 물어야 합니다. 자동 회신 메일이 도착하는 시간인지, 기술 담당자가 배정되는 시간인지, 임시 우회책이 제공되는 시간인지, 완전 복구가 끝나는 시간인지에 따라 가치가 완전히 다릅니다. SLA에는 접수, 확인, 담당자 배정, 임시 복구, 정상화, 원인 보고를 별도의 시계로 정의하는 것이 좋습니다.

무조건 짧은 목표를 요구하면 비용이 급격히 높아지거나, 공급사가 실질적 의미가 없는 ‘최초 응답’만 짧게 설계할 수 있습니다. 야간 15분 출동을 보장하려면 상시 인력과 교대 체계가 필요하기 때문입니다. 월 이용료가 300만 원인 서비스에 24시간 전담 대응을 억지로 요구하기보다, 핵심 장애에만 높은 등급을 적용하고 일반 문의는 영업시간 기준으로 운영하는 편이 합리적입니다. 아래 금액은 시장 표준 가격이 아니라 예산 설계를 돕기 위한 가상 사례입니다.

• 심각도 선언권: 고객사가 등급을 제안하고 공급사가 근거와 함께 조정하도록 절차를 둡니다.
• 시계 시작: 전화, 이메일, 포털 중 공식 접수 채널과 접수 완료 시점을 지정합니다.
• 시계 정지: 고객의 자료 제공을 기다리는 동안 멈출 수 있는 조건과 증빙을 정합니다.
• 임시 복구: 수작업 우회가 가능한 것과 정상 복구된 것을 동일하게 보지 않습니다.
• 상향 보고: 목표 시간의 절반이 지나면 누구에게 자동 보고되는지 결정합니다.

A. 심각도는 기술 증상이 아니라 사업 영향으로 판정합니다

서버 한 대가 멈춰도 이중화로 업무가 정상이라면 최고 등급일 필요가 없습니다. 반대로 서버는 정상이어도 세금계산서가 발행되지 않아 월말 업무가 멈췄다면 높은 등급이 필요합니다. 사용자 수, 손실 예상액, 법정 기한, 대체 절차 유무를 판정 요소로 두면 ‘우리에게는 심각하다’와 ‘기술적으로는 경미하다’는 소모적인 논쟁을 줄일 수 있습니다.

1. 영향받은 사용자와 사업장을 숫자로 확인합니다.
2. 매출, 생산, 고객 약속, 규제 기한 중 손상되는 항목을 표시합니다.
3. 수기 입력이나 다른 채널 등 우회 절차가 실제로 작동하는지 시험합니다.
4. 영향이 확대되면 장애 등급과 대응 목표 시간을 즉시 상향합니다.

Q. 위약금이 크면 서비스 품질도 좋아지지 않나요?

A. 보상금보다 반복 장애를 멈추는 권리가 더 중요합니다

질문: SLA 위반 시 큰 위약금을 걸어 두면 공급사가 더 긴장해서 품질을 관리하지 않을까요?

답변: 금전적 책임은 필요하지만 위약금만으로 품질이 자동 개선되지는 않습니다. 공급사는 위험 비용을 서비스 가격에 미리 반영하거나 배상 한도를 낮추려고 할 수 있습니다. 고객사도 장애로 발생한 실제 영업 손실에 비하면 다음 달 이용료의 5%나 10%에 해당하는 크레딧이 충분하지 않을 수 있습니다. 더 중요한 것은 반복 위반을 발견하고 원인을 제거하며 필요하면 계약을 종료할 수 있는 권리입니다.

기업이 서비스를 구매하는 목적은 보상금을 받는 것이 아니라 업무 성과를 안정적으로 만드는 데 있습니다. 영문 용례와 경제적 맥락은 business의 용어 설명에서도 살펴볼 수 있습니다. 계약에서는 단순한 시스템 납품을 넘어, 서비스 실패가 고객·매출·운영에 미치는 영향을 기준으로 책임 구조를 설계해야 합니다.

• 1회 위반: 원인, 영향 범위, 임시 조치가 포함된 장애 보고서를 제출합니다.
• 반복 위반: 일정 기간 안에 개선 계획과 검증 결과를 제출하도록 합니다.
• 중대한 위반: 제3자 점검이나 고객사의 운영 감사 권한을 활성화합니다.
• 상습 위반: 최소 이용 기간이나 중도해지 수수료 없이 전환할 권리를 둡니다.
• 데이터 반환: 종료 시 데이터 형식, 제공 기한, 삭제 확인서와 전환 지원 범위를 정합니다.

“서비스 크레딧은 실패의 가격표일 뿐입니다. 기업을 보호하는 조항은 같은 실패가 반복될 때 원인을 공개시키고 안전하게 떠날 수 있게 하는 조항입니다.”

A. 공급사만 평가하지 말고 고객사의 협조 조건도 기록해야 합니다

공급사가 모든 결과를 통제할 수 있는 것은 아닙니다. 고객사가 계정 권한을 늦게 승인하거나 필수 자료를 제공하지 않은 경우, 혹은 사내 네트워크 변경을 알리지 않은 경우에는 복구 시간이 늘어날 수 있습니다. 다만 ‘고객 책임’이라는 포괄적 문구를 허용하면 거의 모든 장애가 제외될 수 있으므로, 필요한 협조 항목과 요청 방식, 응답 기한을 구체적으로 적어야 합니다.

예를 들어 공급사가 로그를 요청할 때 필수 필드가 포함된 양식을 사용하고, 고객 담당자가 30분 안에 제공해야 한다고 정할 수 있습니다. 고객 응답이 없으면 SLA 시계를 멈추되 그 시각과 사유를 티켓에 자동 기록합니다. 이처럼 양측의 의무가 대칭적으로 보이면 책임 공방보다 복구 행동에 집중할 수 있습니다.

1. 고객사 담당자와 대체 연락자를 부서별로 지정합니다.
2. 원격 접속 승인, 로그 제공, 현장 출입에 필요한 시간을 사전에 합의합니다.
3. SLA 제외를 주장하는 쪽이 증빙 자료를 제시하도록 합니다.
4. 월간 회의에서 제외 처리된 장애의 적정성을 표본 점검합니다.
5. 성과 보고서 원본을 내려받을 수 있는 기간과 파일 형식을 지정합니다.

월요일 주문 장애는 어떻게 SLA 문장으로 바뀌었나

한 유통기업의 신고부터 재발 방지 검증까지

직원 180명이 사용하는 가상의 유통기업 ‘가온상사’는 월요일 오전 9시 12분, 주문관리 솔루션에서 저장 버튼을 누르면 화면이 멈추는 현상을 발견했습니다. 모니터링 화면의 서버 가동률은 100%였고 공급사는 시스템이 살아 있다고 판단했습니다. 하지만 영업팀 42명은 주문을 등록하지 못했고, 오전 출고 마감인 11시를 넘기면 당일 배송 약속을 지키기 어려운 상황이었습니다.

가온상사는 기존 계약에 ‘중대한 장애는 신속히 지원한다’는 표현만 있어 즉시 대응을 강제하지 못했습니다. 이후 SSMO와 업무 흐름을 다시 살펴 주문 저장, 재고 할당, 출고 전송을 핵심 거래로 지정했습니다. 그리고 ‘전체 영업 사용자의 20% 이상이 주문 저장에 실패하거나, 출고 마감 전 30분 이상 핵심 거래가 중단되면 심각 등급’이라는 문장으로 바꿨습니다. 기술 증상이 아닌 배송 약속과 매출 처리 가능성이 장애 판정 기준이 된 것입니다.

개정된 SLA가 적용된 뒤 비슷한 장애가 다시 발생했습니다. 오전 9시 08분에 외부 거래 모니터가 주문 저장 실패를 감지했고, 9시 10분에 자동 티켓이 생성됐습니다. 공급사는 9시 19분에 기술 담당자를 배정해 최초 대응 15분 목표를 충족했습니다. 9시 47분에는 주문을 임시 대기열에 저장하는 우회 기능을 열었고, 10시 26분에 데이터베이스 연결 설정을 교체해 정상화했습니다. 출고 마감 전 주문 386건이 모두 처리되면서 배송 지연은 발생하지 않았습니다.

1. 9시 08분: 사용자 관점의 주문 저장 시험이 실패해 장애를 자동 감지했습니다.
2. 9시 10분: 심각 등급 티켓이 생성되고 고객사와 공급사 책임자에게 동시에 알림이 발송됐습니다.
3. 9시 19분: 담당 엔지니어가 배정돼 최초 대응 목표를 충족했습니다.
4. 9시 47분: 주문 임시 저장 기능을 제공해 영업팀의 입력 작업을 재개했습니다.
5. 10시 26분: 설정 변경과 거래 검증을 마쳐 정상 서비스로 전환했습니다.
6. 다음 영업일: 장애 시간표, 영향 주문, 원인과 재발 방지 조치를 담은 보고서를 공유했습니다.

월간 숫자 한 줄 대신 재발 여부를 확인했습니다

가온상사는 공급사가 제출한 월간 가동률 99.95%만 확인하지 않았습니다. 장애 후 10영업일 안에 연결 설정의 변경 검토 절차를 만들고, 테스트 환경에서 동일 조건을 재현하며, 외부 주문 시험의 경보가 담당자 호출까지 이어지는지 검증하도록 했습니다. 개선 작업이 끝나지 않으면 서비스 크레딧과 별도로 경영진 보고가 자동 실행되도록 정했습니다.

이 사례에서 계약 문서는 길어지지 않았습니다. 핵심 거래 세 가지, 장애 등급 네 단계, 시간 목표 여섯 개, 반복 위반 시 조치 세 가지로 줄었습니다. 대신 각 문장에는 측정 데이터와 담당자, 시작 시각과 종료 조건이 붙었습니다. 여러분의 기업에서도 “시스템이 켜져 있는가”보다 “고객과 직원이 약속된 업무를 끝낼 수 있는가”를 질문하면, 복잡하지 않으면서도 실제로 작동하는 기업 비즈니스 서비스 SLA를 설계할 수 있습니다.

• 첫 달에는 핵심 거래 3개만 외부에서 측정합니다.
• 매월 가장 영향이 컸던 장애 한 건을 골라 시간표를 복기합니다.
• 분기마다 현업 담당자가 장애 등급 기준을 실제 업무와 대조합니다.
• 반복 원인이 발견되면 보상 계산 전에 개선 완료일과 검증 방법을 확정합니다.
• 서비스 범위가 바뀌면 계약 갱신일까지 기다리지 않고 SLA 부속서를 수정합니다.