Offcanvas

CIO / How To / 리더십|조직관리 / 아웃소싱 / 클라우드

요식적 관행도, 징벌 수단도 아니다··· IT 조직을 위한 ‘SLA’ 안내서

2024.06.24 Stephanie Overby, Lynn Greiner, Lauren Gibbons Paul  |  CIO
SLA는 거의 모든 아웃소싱 및 기술 계약의 핵심 요소다. 서비스 유형과 품질에 대한 기대치를 나열하는 한편, 협약 사항이 충족되지 않은 경우에 대한 해법을 제시한다. SLA에 대한 핵심 개념,  효과적인 SLA를 체결하는 방법 등을 살펴본다. 
 
Image Credit : Getty Images Bank


SLA란?
서비스 수준 계약(Service Level Agreement ; SLA)은 고객이 공급업체에 기대하는 서비스 수준을 정의하고, 해당 서비스를 측정하는 지표와 함께 서비스 수준을 달성하지 못할 경우에 대한 구제책 또는 페널티를 명시한 항목이다. 일반적으로 SLA는 회사와 외부 공급업체, 회사와 개인 소비자 사이에 체결되지만 회사 내 부서 사에도 체결될 수 있다. 

예를 들어, 통신 회사의 SLA는 대개 99.999%(연간 약 5.5분의 다운타임에 해당)의 네트워크 가용성을 약속한다. 또 이를 달성하지 못할 경우 고객이 지불한 금액을 일정 비율만큼 감액한다는 내용을 담는다. 일반적으로 위반의 규모에 따라 차등적으로 감액하게 된다.

SLA가 필요한 이유
SLA는 거의 모든 IT 벤더 계약의 필수적인 부분이다. 계약된 모든 서비스에 대한 정보와 합의된 예상 안정성을 하나의 문서에 담는다. 여기에는 지표, 책임 및 기대치가 명확하게 명시되어 있으므로 서비스에 문제가 발생할 경우 어느 쪽도 무지를 주장할 수 없다.SLA가 없다면 중요한 계약임에도 불구하고 고의 또는 부주의로 인한 오해의 소지가 있다. 즉 SLA는 계약의 양 당사자를 보호할 수 있다.

단 적절하게 수립된 SLA여야 한다. 비즈니스 목표, 기술의 종류, 서비스의 범위 등에 대해 제대로 조정하지 않으면 거래 가격, 서비스 제공 품질 및 고객 경험에 부정적인 영향을 미칠 수 있다.

SLA 제공 주체
대부분의 서비스 업체는 다양한 가격대의 다양한 서비스 수준을 반영하는 표준 SLA(때로는 여러 개)를 보유하고 있다. 그러나 이러한 SLA는 일반적으로 공급업체에 유리하게 작성되는 경향을 가지므로 고객 기업이 직접 검토하고 수정해야 한다.

RFP를 제시할 때 고객은 예상 서비스 수준을 포함해 제시할 수 있다. 이는 벤더의 제안과 가격에 영향을 미치는 것이 일반적이다. 예를 들어 특정 시스템에 대해 99.999%의 가용성을 요구하는데 공급업체가 해당 시스템에 대해 이 요구 사항을 수용할 수 없는 경우, 공급업체는 더 강력한 다른 솔루션을 제안할 수 있다.

SLA 조항의 주요 내용
SLA에는 제공될 서비스와 예상 서비스 수준에 대한 설명과 함께 서비스를 측정하는 지표, 각 당사자의 의무와 책임, 위반 시 구제책 또는 처벌, 메트릭 추가 및 제거를 위한 프로토콜도 포함되어야 한다.

특히 지표는 어느 한쪽 당사자의 잘못된 행동이 보상을 받지 못하도록 설계되어야 한다. 예를 들어 고객이 적시에 정보를 제공하지 않아 서비스 수준이 위반된 경우 공급업체가 이를 책임지지 않아야 한다.

SLA의 이점은?
SLA는 다음과 같은 다양한 이점을 제공할 수 있다:

- 책임감: SLA는 관계의 양 당사자에 대한 책임과 의무를 설정하여 책임성을 보장한다.

- 기대치의 명확성: SLA는 합의된 서비스, 성능 수준 및 서비스 수준 검증을 위한 메트릭을 명시함으로써 고객이 특정 수준의 서비스를 기대하거나 서비스가 의무를 충족하지 못할 경우 해결 가능성을 보장하고 공급업체에게 기대되는 사항을 명확하게 제공한다.

- 갈등 해결: SLA는 문제 해결을 위한 프레임워크를 제공함으로써 문제 발생 시 당사자 간의 갈등을 피할 수 있는 방식으로 중단을 해결하기 위한 사전 정의된 프로세스를 제공한다.

- 고객 경험: SLA 벤치마크는 고객 만족을 보장하는 데 도움이 된다.

- 법적 보호: SLA의 계약적 특성은 분쟁을 완화하기 위한 조건, 프로세스, 양 당사자에 대한 명확한 책임과 기대치를 명시함으로써 양 당사자를 법적으로 보호한다.

SLA의 여러 유형
고객과 공급업체가 관계를 기반으로 선택할 수 있는 SLA에는 다음과 같은 몇 가지 유형이 있다:

- 고객의 요구 사항과 관련된 지표 등, 특정 고객의 요구 사항을 충족하도록 맞춤화되는 고객 기반 SLA.

- 다양한 고객에게 제공되는 서비스에 중점을 두어 해당 서비스에 대한 서비스 수준을 정의하는 서비스 기반 SLA.

- 가동 시간 및 유지 관리 일정과 같은 일상적인 서비스 운영과 관련된 성능을 정의하는 운영 SLA.

- 고객 기반 측면과 서비스 기반 측면을 혼합하여 고객의 요구 사항을 해결하기 위한 다양한 계층을 포함하는 다단계 SLA.

SLA의 주요 구성 요소
SLA에는 ‘서비스’와 ‘관리’의 두 가지 영역의 구성 요소가 포함되어야 한다.

서비스 요소에는 제공 서비스의 세부 사항, 서비스 가용성 조건, 각 서비스 수준에 대한 시간 대역 등의 표준(예를 들어 프라임 시간과 비프라임 시간은 서비스 수준이 다를 수 있음), 각 당사자의 책임, 에스컬레이션 절차, 비용/서비스 트레이드오프 등이 포함된다.

관리 요소에는 측정 기준 및 방법의 정의, 보고 프로세스, 내용 및 빈도, 분쟁 해결 프로세스, 서비스 수준 위반으로 인한 제3자 소송으로부터 고객을 보호하는 면책 조항(계약서에 이미 포함되어 있어야 함), 필요에 따라 계약을 업데이트하는 메커니즘이 포함되어야 한다.

특히 마지막 항목은 매우 중요한데, 서비스 요구 사항과 공급업체의 역량이 변경되므로 SLA를 최신 상태로 유지할 수 있는 방법이 있어야 하기 때문이다. 

면책 조항이란?
면책 조항(indemnification clause)은 서비스 제공업체의 보증 위반으로 인해 문제가 발생하는 경우 고객 회사의 책임을 면하게 하는 중요한 조항이다. 면책이란 서비스 제공업체가 보증 위반으로 인한 제3자 소송 비용을 고객에게 지불해야 한다는 것을 의미한다. 서비스 제공업체가 제공하는 표준 SLA를 사용하는 경우 이 조항이 없을 가능성이 높다. 따라서 사내 변호사에게 이 조항을 포함할 수 있는 간단한 조항 초안을 마련도록 한다. (서비스 제공업체가 이 점에 대해 추가 협상을 원할 수 있음).

SLA의 양도 가능성
서비스 제공업체가 다른 회사에 인수되거나 합병되는 경우 고객은 SLA가 계속 유효할 것으로 예상할 수 있지만, 늘 그렇지는 않다. 계약을 재협상해야 할 수도 있다. 

서비스 수준 확인 방법
대부분의 서비스 제공업체는 온라인 포털을 통해 통계를 제공한다. 여기에서 고객은 SLA가 충족되고 있는지 여부와 SLA에 명시된 서비스 크레딧 또는 기타 페널티를 받을 자격이 있는지 여부를 확인할 수 있다.

일반적으로 이러한 프로세스와 방법론에 대한 검증은 외부 업체에 맡기곤 한다. 그러나 고객 기업과 아웃소싱 SLA 계약 협상 과정에서 지원 프로세스 및 방법, 관리 및 보고 방식에 대한 오해를 없애기 위해 함께 노력하는 것이 바람직하다. 단 중요한 서비스의 경우 고객은 객관적인 성과 측정을 제공하는 타사 도구에 투자하여 SLA 성과 데이터를 자동으로 캡처할 필요가 있다.

어떤 종류의 메트릭을 모니터링해야 할까?
필요한 SLA 지표의 유형은 제공 서비스에 따라 다르다. 많은 항목을 SLA의 일부로 모니터링할 수 있지만, 혼란과 과도한 비용을 피하기 위해 가능한 한 단순하게 구성해야 한다. 지표를 선택할 때는 운영을 검토하여 가장 중요한 것이 무엇인지 결정할 필요가 있다. 모니터링(및 관련 해결 방법) 체계가 복잡할수록 데이터를 제대로 분석할 시간이 없기 때문에 효과적일 가능성이 낮아진다. 비용이 많이 드는 수동 지표 수집은 신뢰할 수 없을 가능성이 높으므로 자동화된 시스템을 선택하는 것이 바람직하다.

서비스에 따라 모니터링할 지표 유형에는 다음이 포함될 수 있다:

- 서비스 가용성: 서비스를 사용할 수 있는 시간이다. 예를 들어 오전 8시부터 오후 6시 사이에는 99.5%의 가용성이 필요하고 그 외 시간대에는 가용성이 어느 정도인지 지정하는 등 시간대별로 측정할 수 있다. 이커머스 운영에는 일반적으로 항상 매우 공격적인 SLA가 적용되며, 시간당 수백만 달러의 매출을 올리는 사이트라면, 99.999%의 가동 시간을 요구하기도 한다.

- 결함률: 주요 결과물에서 발생한 오류의 수 또는 백분율입니다. 불완전한 백업 및 복원, 코딩 오류/재작업, 마감일 누락과 같은 생산 실패가 이 범주에 포함될 수 있다.

- 기술 품질: 아웃소싱 애플리케이션 개발에서 프로그램 크기 및 코딩 결함 등의 요소를 조사하는 상용 분석 도구로 기술 품질을 측정한다.

- 보안: 요즘처럼 규제가 심한 시기에는 애플리케이션 및 네트워크 보안 침해로 인해 막대한 비용이 발생할 수 있다. 안티바이러스 업데이트 및 패치와 같은 제어 가능한 보안 조치를 측정하는 것은 사고 발생 시 모든 합리적인 예방 조치를 취했음을 입증하는 데 있어 핵심이다.

- 비즈니스 성과: 점점 더 많은 IT 고객들이 비즈니스 지표를 SLA에 통합하고자 한다. 공급업체의 기여도를 계산할 수 있는 기존 핵심 성과 지표를 사용하는 것이 일반적으로 적절한 접근 방식이다.

SLA에 대한 지표를 선택할 때 고려해야 할 사항
목표는 서비스 성능을 유지하고 추가 비용을 피할 수 있는 모범 사례와 요구 사항을 공평하게 통합하는 것이어야 한다.

- 올바른 행동에 동기를 부여하는 지표를 선택한다. 모든 지표의 첫 번째 목표는 고객과 서비스 제공업체를 대신하여 적절한 행동에 동기를 부여하는 것이다. 계약 당사자들은 모두 정의된 성과 목표를 달성하기 위해 자신의 행동을 최적화하려고 시도하게 된다. 먼저 동기를 부여하고자 하는 행동에 집중하도록 한다. 그런 다음 상대방의 입장이 되어 지표를 테스트한다. 

- 지표가 서비스 제공업체가 통제할 수 있는 요소를 반영하는지 확인한다. 올바른 행동에 동기를 부여하려면 SLA 지표는 아웃소싱 업체가 통제할 수 있는 요소를 반영해야 한다. 일반적인 실수는 클라이언트의 성능 부족으로 인한 지연에 대해 서비스 제공업체에 불이익을 주는 것이다. 

예를 들어 고객이 애플리케이션 코드에 대한 변경 사양을 몇 주 늦게 제공함에도 불구하고 서비스 제공업체에 미리 지정된 납기일을 지키도록 한다면 불공평할 것이다. 상호 의존적인 작업에 대한 클라이언트의 성과를 측정하여 SLA를 양면으로 만드는 것은 의도한 결과에 집중할 수 있는 좋은 방법이다.

- 쉽게 수집할 수 있는 지표를 선택한다. 원하는 지표의 힘과 수집의 용이성을 균형 있게 고려한다. SLA 지표가 백그라운드에서 최소한의 오버헤드로 자동으로 캡처되는 것이 이상적이지만, 원하는 모든 지표에 대해 이 목표가 가능하지 않을 수도 있다. 확실하지 않은 경우에는 쉬운 수집을 위해 타협할 필요도 있다. 아무도 수동으로 메트릭을 수집하는 데 노력을 기울이지 않을 것이다.

- 측정 지표의 종류가 적절해야 한다. 가급적 많은 요소를 관리하고 싶은 유혹이 있더라도, 분석할 시간이 없을 정도로 많은 양의 데이터를 생성하거나 과도한 오버헤드를 유발하는 과도한 수의 지표를 선택하지 말아야 한다. 

- 적절한 기준선을 설정한다. 올바른 지표의 정의는 시작에 불과하다. 메트릭이 유용하려면 합리적이고 달성 가능한 성과 수준으로 설정되어야 한다. 강력한 과거 측정 데이터를 사용할 수 없는 경우 SLA에 지정된 사전 정의된 프로세스를 통해 향후에 설정을 재검토하고 재조정하도록 한다.

- 신중하게 정의한다. 서비스 제공업체가 SLA 정의를 부적절하게 왜곡할 수 있다. 예를 들어 인시던트 대응 시간 지표는 제공업체가 최소 몇 분 이내에 인시던트를 해결하도록 보장해야 한다. 하지만 일부 제공업체는 인시던트 보고서에 자동 응답을 제공함으로써 SLA를 100% 충족한 것처럼 보이게 만들 수 있다. 고객은 서비스 수준의 의도를 나타낼 수 있도록 SLA를 명확하게 정의해야 한다.

계약서에는 제공될 서비스를 정의하는 것 외에도 데이터 캡처 및 보고 방법, 검토 빈도, 검토에 참여하는 사람 등 서비스 모니터링 방법도 문서화해야 한다.

고객 기업이 흔히 저지르는 SLA 실수
IT 리더들이 흔히 저지르는, 그리고 잠재적으로 많은 비용을 초래할 수 있는 SLA 실수에는 다음과 같은 것들이 있다:

- SLA를 미리 합의하고 수립하지 않음
- 지나치게 많은 SLA
- 공급자의 관점을 이해하지 못함
- SLA 계산에 대한 명확성 부족
- SLA를 일회성 행사로 보는 경우

이러한 실수 및 기타 실수에 대한 자세한 내용은 '여전히 흔한 SLA 실수 15가지'를 참조한다.

클라우드 업체와의 SLA 협상 가능성
일반적으로 클라우드 공급업체는 표준 SLA를 수정하는 데 소극적이다. 그러나 경우에 따라 고객이 클라우드 공급업체와 조건을 협상할 수 있는 경우도 있다. 협상 여지가 있든 없든, 클라우드 컴퓨팅 계약의 SLA를 이해하고 면밀히 검토하여 중대한 위험을 초래하는지 여부를 판단하는 것이 중요하다.

-> 상호신뢰와 노련함의 교차점 ··· 클라우드 SLA 협상 가이드

여러 공급업체 또는 서비스 제공업체 간에 공유되는 공동 SLA를 만들 수 있을까?
때에 따라 가능하다. 고객은 공급업체 간 영향을 고려하고 공급업체가 계약 범위에 포함되지 않은 프로세스에 미칠 수 있는 영향을 설명하는 여러 서비스 공급업체에 대한 공동 지표를 만들 수 있다.

여러 서비스 공급업체를 관리하는 IT 조직은 IT 서비스 제공 프로세스에 관련된 특정 당사자가 성과를 유지하기 위해 서로 상호 작용하는 방식을 설명하는 운영 수준 계약(OLA)을 마련할 수 있다.

IT 아웃소싱업체와 성과 기반 요금제를 선택하는 경우에도 SLA가 필요한가?
달성한 비즈니스 성과에 따라 서비스 업체에게 보상하는 IT 아웃소싱 계약이 부상하고 있다. 특정 활동, 작업 또는 투입 리소스가 아닌 비즈니스 성과를 기준 삼는 것이다. 그러나 성과 기반 계약에서도 SLA는 이러한 비즈니스 결과에 대한 성과를 나타내는 중요한 지표로 사용된다. 

이러한 거래에 대한 SLA는 주어진 작업에 대한 기술 또는 운영 요구 사항을 설명하는 것이 아니라 최종 고객의 목표를 명시한다. 이 접근 방식이 제대로 작동하려면 이러한 결과가 모호하지 않아야 하고, 결과의 달성을 측정할 수 있는 방법이 있어야 한다. 또 역할과 책임이 명확하게 정의되어야 하고, 공급업체가 결과 제공에 필요한 엔드투엔드 서비스를 제어할 수 있어야 한다.

섀도 IT에 대해서도 SLA를 만들 수 있을까?
IT 조직은 IT 서비스 공급업체의 성능을 관리하는 데 사용하는 것과 동일한 유형의 SLA를 섀도 IT에 적용할 수 있다. IT 조직 외부에서 제공되는 기술 서비스에 대해 여러 단계의 SLA 프레임워크를 구축하고 그 성과를 측정하는 방식이 일반적으로 적용된다.

공급업체가 합의된 서비스 수준을 충족하지 못하면 어떻게 되는가?
SLA에는 서비스 크레딧이라고 하는 합의된 페널티가 포함되어 있으며, 다음과 같은 경우에 적용될 수 있다.

공급업체가 최소 성능 기준을 충족하지 못하는 경우. 공급업체와 고객은 월 사용료의 일정 비율(일반적으로 공급업체의 이익률과 동일)을 '위험 부담'으로 설정하여 SLA 기준에 미달했을 때 이러한 크레딧이 인출되는 데 동의한다. 이 접근 방식은 지나치게 징벌적이지 않으면서 공급업체의 성과에 인센티브를 제공하기 위한 것이다.

SLA 조항을 IT 파트너에 대한 처벌 수단으로 사용하지 않고 성과, 우선순위, 향후 계약 또는 관계의 방향에 대한 생산적인 대화의 장으로 활용한다는 원칙을 기억하는 것이 좋다.

'수익 환수'(earn backs)란 무엇인가?
일부 공급업체는 유료 서비스 크레딧을 '환급'받을 수 있는 권리를 요청할 수 있다. 이러한 조항을 통해 공급업체는 일정 기간 동안 표준 서비스 수준 이상을 달성하여 SLA 불이행으로 인해 포기한 서비스 크레딧을 다시 받을 수 있다. 서비스 제공업체는 환급 조항이 필요하다고 주장할 수 있지만, 이는 서비스 크레딧 접근 방식을 완전히 훼손할 수 있기에 주의가 필요하다.

SLA는 얼마나 자주 수정해야 할까?
비즈니스가 변화함에 따라 서비스 요구 사항도 변화한다. SLA를 정적인 문서로 간주해서는 안 된다. 실제로 SLA에는 계약 기간 중 수정을 위한 명확하게 정의된 프레임워크가 포함되어야 한다. 특히 다음과 같은 경우에는 SLA를 주기적으로 검토해야 한다:

- 고객의 비즈니스 요구 사항이 변경된 경우(예: 전자상거래 사이트를 구축하여 가용성 요구 사항이 증가한 경우).
- 기술 환경이 변경된 경우(예: 더 안정적인 장비로 인해 더 높은 가용성을 보장할 수 있게 된 경우).
- 워크로드가 변경된 경우.
- 지표, 측정 도구 및 프로세스가 개선된 경우.

SLA는 모든 공급업체 계약의 중요한 부분이다. 관계를 시작할 때 SLA를 적절히 고려하고 성문화하는 작업의 중요성을 간과해서 안 된다. 양 당사자를 보호하고 분쟁이 발생할 경우 구제책을 명시하고 오해를 피할 수 있다. 이를 통해 고객과 공급업체 모두 상당한 시간과 비용을 절약할 수 있다. ciokr@idg.co.kr
 
CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
Sponsored
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

발행인 : 박형미 편집인 : 천신응 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.