Offcanvas

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

여전히 흔한 SLA 실수 15가지

2021.01.25 Stephanie Overby  |  CIO
IT 서비스 업체나 클라우드 벤더와 협력하고 있는 IT 조직들에게는 SLA(서비스 수준 협약)가 늘 중요하기 마련이다. 나아가 각종 SLA 지표에 대한 이해가 점점 더 중요해지고 있다. 
 
Image Credit : Getty Images Bank

TCS(Tata Consultancy Services)의 부사장 겸 컨설팅 및 서비스 통합 글로벌 책임자 데이브 조던은 “비즈니스를 아우르는 디지털 트랜스포메이션과 빠듯한 예산으로 인해 IT 지출과 관련하여 예상되는 결과를 사전에 확인해야 한다. 그렇지 않으면 IT 리더들은 결과에 환멸과 실망을 느끼게 될 것”이라고 말했다.

코로나19로 인해 SLA 관리량도 증가했다. 기술 조사 및 자문 기업 ISG의 파트너 클레이 콜하운은 “코로나로 촉발된 현실 속에서 기업들이 비즈니스 성과, 고객의 구매 및 상호작용하는 능력, 생산성 등을 측정하려는 경향이 뚜렷해지고 있다”라고 말했다.

게다가 많은 IT 기능들이 분산된 방식으로 운영되면서 SLA가 주된 성과 지표가 되었다. 웨스트 먼로(West Monroe)의 비즈니스 및 기술 컨설팅 책임자 데이비드 보로우스키는 “얼마나 잘(또는 잘못) 운영되고 있는지 확인하기 위해 신뢰할 수 있는 데이터에 더욱 의존하게 되었다”라고 말했다.

제공자와 IT 부서뿐 아니라 조직의 다른 부서가 SLA를 활용하는 비중도 커지고 있다. HFS리서치의 클라우드 전략 조사 부사장 조엘 마틴은 “이를테면 조달 및 법률팀은 SLA를 이용해 비즈니스 및 재무 위험을 평가할 수 있다”라고 말했다. 그리고 기업들이 더 많은 솔루션을 클라우드로 이전하면서 합의된 서비스 수준을 이해하는 것이 신뢰할 수 있고 의지할 수 있는 관계 개발에 중요해졌다고 그는 덧붙였다. 

게다가 SLA 개발 및 관리는 비즈니스 가치라는 관점에서 최근 크게 발전했다. 웨스트 먼로의 상무이사 마크 타노비츠는 “서비스를 받는 사람들이 SLA를 관리하는 방식이 훨씬 정교해졌다”라며, “SLA의 진정한 가치가 서비스 비용을 절약하기보다는 비즈니스 인사이트와 성과를 유도하는 것이라는 데 대한 공감대가 확산되고 있다”라고 덧붙였다.

그렇기는 하지만 여전히 IT 리더들이 범할 수 있는 보편적이고 잠재적인 비용이 발생하는 SLA 실수가 있다. 특히 유해한 것들을 모아봤다. 

초기에 SLA 합의 및 수립 실패
프로세스 정리 소프트웨어 개발사인 PMG의 수석 겸 CTO 로버트 캐슬은 “양 당사자가 처음에는 기대치가 명확하게 상호 공유되었다고 생각할 것이다. 그러나 명확히 하지 않으면 그렇지 않은 경우가 있다. 양 당사자는 문제가 발생하기 전에 SLA 조건을 협상하는 것이 좋다”라고 말했다.

IT 리더가 범할 수 있는 실수 중 하나는 SLA의 ‘A’를 간과하는 것이라고 뉴타닉스(Nutanix)의 CIO 웬디 M. 파이퍼가 말했다.

그녀는 “합의는 IT 역량에 대한 일방적인 선언이나 비즈니스 요건에 대한 일방적인 요구가 아니다. 원하는 서비스 제공 및 품질에 대한 이해 공유, 기대치와 관련된 비용의 계산, 투자를 위한 교환 결과에 대한 합의가 있어야 한다”라고 말했다.

과도하게 많은 SLA
SLA가 과도하게 많으면 합의된 서비스 위반으로 이어지기 쉬우며, 결과적으로 무의미한 서비스 크레딧으로 귀결될 수 있다고 해켓 그룹(Hackett Group)의 수석 마이크 풀러가 말했다.

예를 들어, 고객에게 65개의 SLA가 있는 상황이고 위험 비용 부담 규모가 월간 청구 요금의 10%뿐인 상황을 가정해보자. 한 가지를 위반했을 때 10%의 1/65에 해당하는 서비스 크레딧을 잃게 될 것이다. 웨스트 먼로의 보로우스키는 “과도하게 많은 SLA를 정의하면 각각의 영향이 (희석되며) 제공자가 우선순위 결정 및 능동적인 관리를 위해 가장 필요한 것이 무엇인지 알 수가 없다”라고 말했다.

제공자의 관점 이해하지 않기
HFS 리서치의 마틴은 “SLA는 외부 업체가 제공하는 업타임에 집중하는 경우가 많다. 하지만 현업 또는 IT 리더는 애플리케이션이나 서비스의 성과에 더 집중하는 것이 바람직할 수 있다”라고 말했다.

아울러 백업 또는 재난 복구를 위한 SLA의 경우 기업은 합의 시 RPO(Recovery Point Objective) 또는 RTO(Recovery Time Objective)를 명확히 고려해야 한다. 마틴은 “클라우드 네이티브 모델로 전환하고 있는 IT 부문의 경우도 마찬가지이다. 여기에는 서비스 데스크, 서비스 관리, 인프라 관리 등이 포함된다”라고 말했다.

고립된 SLA
개별적인 인프라 및 애플리케이션 구성요소 업타임에 과도하게 집중된 SLA 또한 문제가 된다고 풀러가 말했다. TCS의 조던도 같은 생각이다. 

그는 “오늘날 많은 조직들이 SLA와 관련하여 비즈니스 성과와의 통합을 요구하고 있는 데에는 이유가 있다. 비즈니스 성과에 기초해 관련된 IT 성과 지표를 얻게 되고 생태계에 있는 사람 중 누가 각 비즈니스 결과 지원에 대한 책임이 있는지 명확해질 수 있기 때문이다”라고 말했다.

비즈니스 결과에 더욱 집중하기 위해 SLA는 더욱 통합되고 전체적이어야 하며 비즈니스 사용자가 트랜잭션(Transaction)을 완료할 수 있는지 여부 등 더 광범위한 카테고리나 결과를 다뤄야 한다. 웨스트 먼로의 타노비츠는 포트폴리오 관점에서 프로세스 또는 제공자 범위를 최적화하여 개선을 유도할 수 있는 영역을 확인하라고 조언했다.

탈출 조항의 부재
탈출 조항은 지속적으로 성능이 부족하거나 목표에 달성하지 못하는 상황이 나타날 때 반드시 필요하다. HFS 리서치의 마틴은 “계약서에 이에 대한 명확한 사항이 없으면, SLA는 큰 가치가 없다. 주어진 기간 동안에 ‘x’회를 정의하는 한계를 명시하고 벤더와 함께 정기적으로 검토해야 한다”라고 말했다. 

SLA 계산을 둘러싼 명확성의 부재
마틴은 “고객이 제공자로부터 SLA 보고서를 받고 해당 제공자의 SLA 문서만 정확한 사실로 간주한다는 내용을 계약서에 작성한 경우를 보았다. 제대로 된 리더라면 수용하기 힘든 요건이다”라고 말했다.

측정 불가
IT조직이 목표를 입증할 만한 충분한 데이터 없이 성과 지표를 수립하는 경우가 적지 않다고 ISG의 콜하운이 말했다. 하지만 실제로 SLA를 계산할 수단(명확하고 이해할 수 있으며 사용하기 쉬운 도구와 프로세스)이 없다면 일반적으로 SLA 관리가 힘들거나 간과하게 된다고 풀러가 말했다.

웨스트 먼로의 보로우스키는 “점차 데이터 및 프로세스 발견 도구를 사용하여 SLA를 측정하고 있다. 아직 흔하지는 않지만 이런 도구는 유의미한 지표를 확인하고 성과를 객관적으로 평가할 기회를 제공한다(사이클 시간, 품질, 준법감시 등). 제공사의 도구만 이용해 성과 데이터를 측정하는 상황을 피할 수 있다”라고 말했다.

셰도우(Shadow) 계약 시 IT의 미개입
현업 부문이 자체적으로 기술 서비스 계약을 체결하는 경우가 늘고 있다. 또 IT 리더가 중간 책임자에게 점차 많은 서비스에 대한 계약 체결을 위임하기도 한다. HFS 리서치의 마틴은 이러한 상황에서 SLA 측면에서 위험이 증가한다고 지적했다.

SLA를 일회성 활동으로 간주하기
TCS의 조던은 “적절한 비즈니스 성과를 달성하려면 SLA를 활용해야 하며 서비스 통합은 마라톤과 같다. 이것은 IT의 핵심 역량의 일환이다”라고 말했다. IT 리더는 역할 정의 및 비즈니스 결과 또는 이익과 비교하여 지출하는 예산을 파악함에 있어 ‘머슬 메모리’(Muscle Memory)를 키워야 한다. IT 조직 스스로가 SLA 관리를 중심으로 가치를 실현하는 역량을 육성해야 한다는 의미다.

클라우드에서 SLA가 중요하지 않다고 가정하기
SLA가 클라우드 서비스 및 애플리케이션과 어떻게 교차되는지 이해하지 못하는 것이 문제가 될 수 있다.

예를 들어, 네트워크 서비스 제공자는 트래픽이 퍼블릭 클라우드 제공자에게 전달될 때까지 데이터 전송을 책임진다. “하지만 대부분의 네트워크 서비스 제공자는 클라우드 SLA 수준의 SLA를 제공하지 않는다”라고 소프트웨어 정의 네트워크 및 클라우드 플랫폼 매서지(Masergy)의 CTO 테리 트레이나는 지적했다. 그는 이어 “모든 서비스가 SLA 대상이다. 영역 전체를 다루어야 한다”라고 말했다.

보안을 간과하기
재난 복구, 암호화, 사고 대응, 취약성 평가 등을 중심으로 제공사가 어떤 지속적인 노력을 기울이는지 생각해볼 필요가 있다. “가능하면 고객은 서비스 제공자로 하여금 보안에 유의하도록 해야 한다”라고 CSA(Cloud Security Alliance)의 선임연구위원 겸 제품 관리자 앨레인 파네트랫이 말했다.

SLA를 분쟁 해결 도구로 사용하기
문제를 해결하기 위한 수단으로 계약에만 의존하는 것은 실수이기 쉽다. PMG의 캐슬은 “분쟁 시 첫 번째 단계는 계약상 누구에게 잘못이 있고 어떤 불이익을 부과해야 하는지에 집중하기 보다는 영향을 파악하고 피해를 해결하는 것이어야 한다”라고 말했다. 

에센타이어(eSentire)의 CTO 더스틴 힐리어드는 “처음에 분쟁으로 이어졌을 수 있는 기술 또는 운영상 오해에 대해 소송을 제기하기보다는 고객 관계와 성과를 우선시하는 것이 더 중요하다”라고 덧붙였다.

 

패널티에 집중하기
SLA를 성과 개선을 유도하기 위한 도구가 아니라 비용 절감책으로 보면 분쟁이 발생한다. “고객은 손실 회복에 집중해서는 안 된다”라고 메서지의 트레이나가 말했다. IT 리더는 대신에 제공자에게 처음부터 최고 수준의 서비스 책임을 지우는 SLA에 집중해야 한다.

불필요하게(그리고 비현실적인 경우가 많은) 높은 성과 목표를 설정하면 제공자 비용이 증가하면서 해당 비즈니스 이점이 반드시 제공되지는 않는다고 웨스트 먼로의 보로우스키가 말했다. 프로티비티(Protivity)의 재무 서비스 기술 그룹 상무이사 알리 야신 또한 “불이행으로 인해 수익 회수가 발생하는 경우 서비스 제공사는 SLA에 대한 과잉 수행 시 수익 인센티브를 받으려 들기 마련이다”라고 말했다.

내부 책임의 부재
IT 조직 또한 역할을 담당해야 한다. 서비스 파트너와 대부분의 생산적인 관계를 구축하는 사람들은 이 사실을 알고 있다. 웨스트 먼로의 타노비츠는 “서비스가 제공자가 기대했던 대로 수행하도록 하는 데 있어서 서비스 수용자의 역할을 인지하지 못하는 실수를 범한다”라고 말했다. 

야신은 “따라서 조직은 내부 프로세스의 성숙도를 높여 벤더에게 기대하는 유형의 SLA를 구성할 수 있는지 고려해야 한다”라고 말했다

변화하지 않는 SLA
IT 서비스 계약에 역사적 트렌드를 기준으로 SLA 목표를 자동으로 업데이트하거나 상향 조정해야 한다고 풀러가 조언했다. 예를 들어, 많은 IT 조직이 팬데믹 초기에 파트너들의 SLA를 완화시켰다. 

웨스트 먼로의 타노비츠는 “재택 운영 환경이 안정화되고 ‘뉴 노멀’이 되면서 이런 완화조치가 여전히 필요한지 재검토하고 SLA 지표와 우선순위를 검토하여 비즈니스 니즈와 여전히 일맥상통하고 있는지 확인해야 한다”라고 말했다.

마인드트리(Mindtree)의 서비스 라인 시장 책임자 스리람쿠마르 쿠마르잔은 비즈니스 및 기술 변화의 속도에 맞출 수 있는 동적 BPLA(Business Process Level Agreement)를 지지하는 입장이다. 그는 “동적이며 포괄적인 BPLA를 통해 기업은 비즈니스 성과에 맞춰 IT를 맵핑 할 수 있다”라고 말했다. 

IT 리더는 또한 효율성 증가를 고려해야 한다. 야신은 “시간이 지남에 따라 SLA 주요 위험 지표를 점진적으로 좁히는 것이 중요하다. 이를 통해 벤더는 관계를 지속적으로 개선하고 강화할 수 있다”라고 말했다.

또한 지속적인 문서 검토를 포함하여 IT 조직이 추후 제공자를 변경하고 싶은 경우 주요 프로세스에 액세스할 수 있도록 해야 한다고 그는 덧붙였다. ciokr@idg.co.kr
CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
추천 테크라이브러리

회사명:한국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.