모든 IT 벤더와의 계약에서 SLA는 중요한 요소다. 서비스 종류와 품질의 기대치를 명시하는 것에 그치지 않고 요건이 충족되지 않을 때 해결책을 제시한다. 여기 SLA에 관한 흔한 질문에 대한 답을 정리했다. 벤더 및 협력업체와 효과적인 SLA를 작성하는 요령도 소개한다.
SLA란?
서비스수준계약(SLA: Service-Level Agreement)이란 간단히 말해 고객이 공급업체에게 기대하는 서비스 수준을 기술한 문서다. 이 문서에는 해당 서비스를 측정할 지표가 규정된다. 또 합의된 수준을 충족하지 못했을 때 해결책이나 불이익이 있으면 역시 명시된다. 통상적으로 SLA는 회사와 외부 공급업체 간에 체결되지만 한 회사에 속한 부서 사이에서도 체결될 수 있다.
예를 들어, 통신회사의 SLA는 99.999퍼센트의 네트워크 가용성을 약속하곤 한다. 풀어서 설명하면, 1년에 발생하는 다운타임이 약 5.25분이라는 뜻이다. 믿어지지 않겠지만 어떤 기업에게는 이것도 너무 긴 시간이다.
만일 이 약속을 지키지 못하면 고객의 결제 금액을 소정 비율 깎아준다. 통상적으로 할인 폭은 위반 정도에 따라 차등 적용된다.
SLA가 필요한 이유는?
SLA는 IT벤더 계약에서 필수적이다. 약정 서비스 일체와 그와 관련해 합의된 기대 신뢰도에 대한 정보를 하나의 문서에 정리하고 측정 지표, 책임, 기대치가 명시되어 있다. 따라서, 서비스에 문제가 발생했을 때 어느 측도 몰랐다는 변명을 할 수 없게 되어 있다. 양측이 요건을 똑같이 이해하도록 보장한다.
중요한 계약에 (변호사의 검토를 거친) 관련 SLA이 없으면 고의적으로 또는 의도치 않게 계약을 잘못 해석하기 쉽다. 따라서 SLA는 계약 쌍방을 보호하는 역할을 한다.
SLA는 업무의 기술 목표 또는 사업 목표와 일치되는 것이 이상적이다. 목표에 어긋나게 작성되면 계약 가격 책정과 서비스 제공 품질, 고객 경험 등에 부정적인 영향을 미칠 수 있다.
SLA는 누가 준비하는가?
대부분의 서비스 공급업체에는 표준 SLA가 구비되어 있다. (가격대에 따라 서비스 수준이 다양하므로 여러 개의 SLA를 구비하는 경우도 있다.) 이러한 표준 SLA는 협상을 시작할 때 좋은 참고 자료가 된다. 그러나 공급업체에게 유리한 방향으로 작성된 경우가 대부분이기 때문에 고객과 고객 측 변호사의 검토와 수정을 거쳐야 한다.
고객은 제안요구서(RFP)를 보낼 때 기대하는 서비스 수준을 명시해야 한다. 요구 수준에 따라 공급업체의 제공 내용과 가격이 달라지기 때문이다.
요구 서비스 수준이 너무 과하면 아예 응답이 없을 수도 있다. 예를 들어, 고객이 시스템 가용성 99.999 퍼센트를 요구했을 때 공급업체 측에서 고객이 지정한 설계로는 이 요건을 충족할 수 없다면 다른 솔루션을 제안하기도 한다.
SLA 내용은?
SLA의 내용 중에는 제공될 서비스와 기대 서비스 수준에 대한 설명이 있어야 한다. 아울러, 서비스 측정 지표, 각 당사자의 의무와 책임, 계약 위반 시 해결책 또는 불이익, 지표를 추가하거나 제거할 때 적용되는 규칙 등의 내용도 있어야 한다.
측정 지표는 각 당사자가 나쁜 행동을 했을 때 이득을 얻지 못하도록 해야 한다. 예를 들어, 고객이 정보를 제때 제공하지 않아서 서비스 수준이 충족되지 못했다면 공급업체가 불이익을 받아서는 안 되는 것이다.
SLA의 핵심 구성요소는?
SLA에는 서비스와 관리라는 두 가지 분야의 구성요소가 들어있어야 한다.
서비스 분야에 포함될 내용은 제공 서비스의 상세 내용(의심의 여지가 있을 경우에는 서비스에서 제외되는 부분도 명시), 서비스 가용성 조건, 각 서비스 수준에 대한 시간 창과 같은 기준(가령, 황금 시간대와 그 이외 시간대의 서비스 수준은 상이할 수 있음), 각 당사자의 책임, 단계적 문제 해결 절차, 비용/서비스 절충 내용 등이다.
관리 분야에 포함될 내용은 측정 표준 및 방식의 정의, 보고 절차, 내용 및 빈도, 분쟁 해결 절차, 서비스 수준 위반으로 인한 제3자 소송으로부터 고객을 보호하는 배상 조항(계약서에 이미 다뤘어야 할 부분이기는 하다), 필요에 따라 계약서를 업데이트할 방법 등이다.
이 마지막 항목이 중요하다. 서비스 요건과 벤더 역량은 변하기 때문에 SLA를 최신 상태로 유지할 방법이 있어야 한다.
배상 조항이란 무엇인가?
배상 조항은 서비스 공급업체가 보증 위반 시 고객 업체에게 배상하기로 합의하는 중요한 조항이다. 배상이란 공급업체가 약속 위반으로 인한 제3자 소송 비용 일체를 고객에게 지급해야 함을 의미한다.
서비스 공급업체에서 제공된 표준 SLA에는 이 조항이 없을 가능성이 높다. 이 내용이 포함된 간단한 조항 작성을 사내 변호사에게 요청해야 한다. 단, 서비스 공급업체는 이 부분에 대한 추가 협상을 원할 수 있다.
SLA는 양도 가능한가?
서비스 공급업체가 다른 회사에게 인수 또는 합병될 경우, 고객은 SLA의 효력이 계속 유지될 것으로 기대하겠지만 사실은 그렇게 되지 않을 수도 있다. 계약 재협상이 필요할 수도 있다. 어떤 가정도 하지 않는 것이 좋다. 단, 새로운 소유자는 기존 고객이 떨어져나가는 것을 원할 리는 없으므로 기존 SLA 존중 결정을 내릴 수 있음을 명심해야 한다.
서비스 수준을 어떻게 확인 가능한가?
대부분의 서비스 공급업체는 온라인 포털을 통해 통계 자료를 공개하는 경우가 많다. 이를 통해 고객들은 SLA의 충족 여부와 SLA에 규정된 서비스 크레딧 등 불이익에 해당되는지 여부를 확인할 수 있다.
통상적으로 이러한 절차와 방법을 파악하는 것은 외주 회사의 몫이다. 해당 절차와 방법이 SLA 계약을 뒷받침할 수 있는지 확인해야 한다. 그러나 고객과 외주 회사는 관리 및 보고 방법뿐만 아니라 지원 절차 및 방법에 대한 오해가 없도록 SLA 계약 협상 중에 협력할 것을 권장한다.
그러나 중요한 서비스의 경우에는 고객은 SLA 이행 자료를 자동으로 캡처하는 타사 도구에 투자하는 것이 좋다. 이를 통해 이행 상황을 객관적으로 측정할 수 있다.
모니터링해야 할 측정 지표는?
필요한 SLA 측정 지표가 무엇인지는 제공되는 서비스에 달려있다. SLA의 일부로 여러 항목을 감시할 수 있다. 단, 감시 방법은 가능한 한 간단하게 해야 양측에 과도한 비용과 오해를 방지할 수 있다.
측정 지표 선택 시에는 운영 상황을 점검하고 가장 중요한 것을 결정해야 한다. 감시 방식(그리고 그와 관련된 해결 방식)이 복잡하면 복잡할수록 효과는 떨어질 공산이 크다. 데이터를 제대로 분석할 여유가 없기 때문이다.
확신이 없을 때에는 데이터 수집이 쉬운 지표를 선택한다. 자동화 시스템이 가장 좋다. 힘들게 수동으로 수집한 지표는 신뢰하기 어렵다. 서비스에 따라 감시해야 할 측정 지표는 다음과 같다.
– 서비스 가용성: 사용 가능한 시간의 양. 타임 슬롯으로 측정한다. 예를 들면, 오전 8시에서 오후 6시 사이에는 99.5%의 가용성이 요구되고 다른 시간 중에는 이보다 더 높거나 낮은 가용성을 명시한다. 전자상거래 운영에 대한 SLA은 대단히 적극적인 요구를 하는 경우가 대부분이다. 한 시간에 수백만 달러를 벌어들이는 사이트의 경우 99.999% 업타임 요구도 드물지 않다.
– 하자 비율: 주요 결과물의 오류 개수 또는 백분율. 불완전한 백업 및 복원과 같은 생산 오류, 코딩 오류/재작업, 놓친 납기일 등이 이 범주에 포함된다.
– 기술 품질: 외주 응용프로그램 개발에서 프로그램 크기 및 코딩 하자와 같은 요소를 점검하는 상용 분석 도구에 의한 기술 품질 측정.
– 보안: 요즘과 같은 초 규칙적인 시대에 응용프로그램과 네트워크 보안에 구멍이 발생하면 엄청난 손해를 입을 수 있다. 사건이 일어났을 때 합리적인 모든 예방 조치를 취했다는 것을 증명함에 있어 백신 업데이트 및 패칭과 같은 통제 가능한 보안 조치를 측정하는 것이 핵심이다.
– 업무 성과: IT고객들이 업무 절차 측정 지표를 SLA에 반영하고자 하는 경향이 점점 커지고 있다. 기존의 핵심성과지표(KPI)를 사용하는 것이 최선인 경우가 대부분이다. 단, 해당 KPI에 대한 벤더의 기여도를 산정 가능할 경우에 한한다.
SLA 측정 지표 선택 시 고려할 점은?
서비스 성과를 유지하고 추가 비용을 방지할 수 있는 베스트 프랙티스와 요건을 포함시키는 게 목적이어야 한다.
– 올바른 행동을 촉진하는 측정 지표를 선택한다. 모든 측정 지표의 첫 번째 목표는 고객과 서비스 공급업체에게 적정 행동을 촉진하는 것이다. 관계의 각 당사자는 측정 지표로 규정된 업무 수행 목표를 달성하기 위한 행동을 최적화하기 위해 노력할 것이다.
– 먼저 촉진하고자 하는 행동에 집중한다. 그 다음에는 상대방 입장에서 측정 지표를 테스트한다. 본인이라면 본인의 업무 수행을 어떻게 최적화하겠는가? 그러한 최적화가 애초에 원했던 결과를 뒷받침하는가?
– 서비스 공급업체의 통제 범위 내에 있는 요소가 반영되도록 한다. 올바른 행동을 촉진하려면 SLA 측정 지표는 외주 업체의 통제 범위 내에 있는 요소를 반영해야 한다. 전형적으로 저지르는 실수는 고객 측의 불이행으로 인해 발생한 지연을 이유로 서비스 공급업체에게 불이익을 주는 것이다.
예를 들어, 고객 측에서 응용프로그램 코드 변경 사향을 몇 주 늦게 제공하면서 사전에 지정된 납기일을 고집하는 것은 서비스 공급업체에게 불공정하고 의욕을 떨어뜨리는 처사다. 상호 의존적인 행동에 대한 고객의 이행 상황을 측정함으로써 SLA를 쌍방 계약으로 만드는 것이 의도한 결과에 집중할 수 있는 좋은 방법이다.
– 쉽게 수집할 수 있는 측정 지표를 선택한다. 원하는 측정 지표의 효과와 수집의 용이함 사이에 균형을 맞춘다. SLA 측정 지표는 최소한의 간접비용을 들여 막후에서 자동으로 캡처하는 것이 이상적이다. 그러나 원하는 측정 지표를 모두 이렇게 수집할 수는 없다.
확신이 없을 때는 효과는 떨어지더라도 수집이 쉬운 쪽을 택하는 것이 좋다. 측정 지표를 직접 수집하는 수고를 자처할 사람은 없기 때문이다.
– 적은 것이 좋은 것이다. 될 수 있는 한 많은 요소를 통제하고 싶은 마음이 들더라도 지표를 지나치게 많이 선택하는 것은 피해야 한다. 너무 많은 양의 데이터가 발생하면 분석할 시간이 없고 간접비용이 과도하게 발생하기 때문이다. 가능성은 낮지만 지표가 너무 적어도 문제다. 하나만 누락되어도 공급업체가 계약을 위반한 셈이 되기 때문이다.
– 적절한 기준선을 설정한다. 적절한 지표를 규정하는 것만으로는 부족하다. 지표가 쓸모 있으려면 합리적이고 달성 가능한 이행 수준에 설정해야 한다. 강력한 과거의 측정 데이터가 존재하지 않는 한, SLA에 명시된 사전 규정 절차를 통해 차후에 설정을 재점검하고 재조정할 각오를 해야 한다.
– 꼼수에 주의한다. 공급업체가 SLA 규정을 충족하기 위해서 꼼수를 부릴 수 있다. 예를 들어, 사고 대응 시간 지표는 공급업체가 사고를 최소한 몇 분 안에 대처하도록 하는 것이 목적인데 어떤 공급업체는 사고 보고서에 자동 응답을 보내는 수법으로 SLA를 100% 충족하기도 한다. 따라서 고객은 서비스 수준의 의도가 제대로 표현되도록 SLA를 명확히 규정해야 한다.
계약서는 제공될 서비스를 규정하는 한편 서비스의 감시 방식도 명시해야 한다. 예를 들면 데이터 캡처 및 보고 방식, 검토 빈도, 검토 참가자 등이다.
클라우드 서비스 공급업체와 SLA를 협상할 여지는?
클라우드 벤더들은 자신의 표준 SLA 수정에 대해 말을 더욱 아끼는 경향이 있다. 여러 구매자에게 상품 서비스를 공급하는 것에 수익이 달려있기 때문이다. 그러나 고객이 클라우드 공급업체와 조건을 협상할 수 있는 경우도 있다.
또 협상의 여지가 있건 없건 클라우드 컴퓨팅 계약의 SLA를 이해하고 면밀히 살펴서 중대한 위험이 있는지 판단하는 것이 중요하다.
복수의 벤더 또는 서비스 공급업체와 공유되는 공동 SLA를 만들어도 되는가?
고객은 복수의 서비스 공급업체에 대한 공동 측정 지표를 만들 수 있다. 공급업체 간 영향을 고려하여 포함시키고 계약 범위에 고려되지 않은 프로세스에 벤더가 미칠 수 있는 영향을 설명하는 지표다.
복수의 서비스 공급업체를 관리하는 IT조직이라면 운영 수준 계약(OLA: Operating Level Agreement)의 시행이 필요할 수 있다. OLA는 IT 서비스 제공 과정에 참가하는 특정 당사자가 서비스 성과 유지를 위해 어떻게 상호 교류하는 지 설명한다.
IT 외주 업체와 결과 기반 가격정책을 선택해도 SLA가 필요한가?
서비스 공급업체가 성취한 업무결과와 연계하여 보수를 받는 IT외주 계약의 인기가 늘어났다. 순수한 시간 및 자재 기반 또는 정규직 기반 가격 모델에서 벗어나고 있는 것이다.
이러한 경우에 결과라 함은 특정 활동, 작업 또는 자원이라기 보다 업무 성과를 말한다. 그러나 결과 기반 계약에서도 SLA는 업무 결과에 대한 중요한 성과 지표 역할을 한다.
이러한 계약에 대한 SLA은 특정 작업에 대한 기술 요건이나 운영 요건 대신 고객의 최종 목적을 명시한다. 이러한 접근 방식이 성공하려면 해당 결과가 모호해서는 안되며 결과의 성취도를 측정할 방법이 있어야 한다.
또한, 역할과 책임이 명확하게 규정되어야 하고, 공급업체는 성과를 내기 위해 필요한 서비스의 처음부터 끝까지 통제권이 있어야 한다.
섀도우 IT용 SLA를 만들어도 되는가?
IT 조직은 서비스 공급업체의 성과 관리를 위해 IT에서 사용하는 것과 똑같은 종류의 SLA를 기업 내 다른 부서의 섀도우 IT에 적용함으로써 관련 위험을 경감할 수 있다. 이를 위해서는 조직 외부에서 제공되는 기술서비스에 대한 SLA체계를 구축해 해당 서비스 성과를 측정, 보고할 수 있어야 한다.
공급업체가 합의된 서비스 수준을 충족시키지 못하면 어떻게 하는가?
SLA에는 합의된 불이익 조창이 포함되어 있다. 서비스 크레딧(service credit)이라고 하는데 벤더가 최소한의 성과 표준에 미달할 경우 시행된다. 공급업체와 고객은 매달 수수료(보통 벤더의 수익)의 일정 비율을 따로 떼어 놓고 SLA가 충족되지 못할 시에 여기에서 서비스 크레딧을 인출한다. 단 이 접근 방식은 처벌보다는 공급업체 성과를 장려하는 것이 목적이다.
최고 수준의 IT조직은 IT협력업체를 벌을 줄 목적으로 SLA조항을 이용하지 않는다. 그 대신, SLA측정 지표를 활용해 성과, 우선 순위, 업무나 관계의 향후 방향 등에 대한 생산적인 대화를 시작한다.
‘환급’(earn backs)이란 무엇인가?
어떤 벤더는 지급된 서비스 크레딧을 환불받을 권리를 주장하기도 한다. 공급업체가 일정한 시간 동안 표준 서비스 수준 이상의 성과를 보이면 SLA 불이행으로 인해 포기했던 서비스 크레딧을 환급 받을 수 있는 조항이다. 공급업체로서는 공정하다고 주장하겠지만 환급 조항이 서비스 크레딧 방식 전체를 약화시킬 수 있으므로 주의해야 한다.
SLA는 얼마나 자주 개정해야 하는가?
업무가 변함에 따라 서비스 요건도 변하기 마련이다. 따라서 SLA를 불변의 문서로 여기면 안 된다. 오히려 SLA에는 계약 기간 중 수정 체계가 명확히 규정되어 있어야 한다. SLA의 주기적인 검토가 특히 필요한 경우는 다음과 같다.
– 고객의 업무적 필요가 변한 경우(예: 전자상거래 사이트를 구축하면 가용성 요건이 늘어남)
– 기술 환경이 변한 경우(예: 장비의 신뢰성이 높아지면 보다 높은 가용성 보장이 가능해짐).
– 작업량이 변경된 경우
– 지표, 측정 도구 및 절차가 개선된 경우
SLA는 어떤 공급 계약에서도 중요한 부분이다. 관계의 시작 단계에서 SLA를 적절히 강구하여 성문화 해두면 장기적으로 이득이다. 양쪽 당사자를 보호해 줄뿐만 아니라 분쟁 발생 시에 해결책을 명시해 주고 오해를 방지해주며 이를 통해 고객과 공급업체 모두 시간과 금전을 크게 아끼도록 해준다. dl-ciokorea@foundryco.com
