클라우드 SLA·계약과 규제: 품질 지표, 도입 판단, 계약, 클라우드컴퓨팅법

클라우드 사업자는 "99.99% 가용성"을 내세우지만, 그 숫자가 무엇을 재는지, 못 지키면 무엇을 받는지는 계약서에 있다. 대형 클라우드 장애가 나면 피해는 이용 기업이 입고, 돌려받는 건 대개 요금 일부의 크레딧이다. 그래서 숫자를 읽는 법, 계약 전에 스스로 준비할 것, 그리고 법이 계약과 상관없이 보장하는 이용자 권리를 함께 알아야 한다. 리전 선택, 망 분리, 암호화, 백업 위치 같은 아키텍처 결정이 이 계약과 규정에서 정해지는 경우가 많다.

품질을 재는 세 가지

가용성

가용성(availability) 은 서비스가 장애 없이 정상적으로 요청을 받는 능력이다. 숫자로는 가용률로 잰다.

가용률 = 실제 가동 시간 ÷ 예정된 가동 시간 × 100

"예정된 가동 시간"에서 사전 공지한 점검 시간을 빼는 계약이 많다. 점검을 자주 공지하면 가용률이 높게 나오는 셈이라, 점검을 어떻게 공지하고(언제, 무엇을, 어떻게 대처하고, 얼마나 걸리는지) 이용자의 업무 시간을 피하는지도 함께 정해 둔다.

월 단위로 따지면 99.9%는 약 43분, 99.95%는 약 22분, 99.99%는 약 4분 20초의 중단을 허용한다. 9가 하나 늘 때마다 허용 시간은 10분의 1로 준다(연·일 기준 표는 고가용성 이중화 구조와 장애 감지). 99.99%는 사람이 알림을 받고 노트북을 여는 사이에 다 써 버리는 시간이라, 자동 복구 없이는 지킬 수 없다.

점검할 것:

• 서비스 인스턴스의 접속 주소(IP와 포트)로 꾸준히 접속해 보고, 프로세스가 떠 있는 것만이 아니라 실제로 요청을 받는 상태인지 확인한다.
• 측정한 가용률이 SLA 목표를 만족하는가.
• 운영 상태 대시보드, 장애 알림, 모니터링 로그가 제공되는가. 자동 복구 기능이 있다면 실제로 복구되는가.

응답성

응답성(responsiveness) 은 요청에 얼마나 빨리 반응하느냐다. 응답 시간은 요청한 순간부터 처리가 끝날 때까지 걸린 시간이고, 어떤 사양에서 잰 값인지 함께 적어야 의미가 있다.

평균만 보면 느린 요청이 가려지므로 p95·p99 같은 백분위로 보는 게 좋다(관측 가능성).

확장성

확장성(scalability) 은 요청에 따라 자원 양을 늘리고 줄이는 능력이다.

마지막 항목이 실전에서 중요하다. 새 서버가 "생성됨"이 된 시점과 사용자가 체감하는 "쓸 수 있음" 시점 사이에는 부팅, 앱 기동, 헬스 체크 통과까지의 간격이 있다. 트래픽이 몇 초 만에 몰리는 서비스라면 자동 확장만 믿을 수 없고 미리 늘려 둬야 한다.

SLA와 서비스 크레딧

SLA(Service Level Agreement) 는 사업자가 약속하는 서비스 수준과, 못 지켰을 때의 보상을 적은 계약이다. 보상은 보통 구간별 서비스 크레딧(다음 달 요금 할인)이다.

예시) 월 가용률 99.9% 미만   → 해당 서비스 월 요금의 10%
      99.5% 미만             → 20%
      99.0% 미만             → 30%

읽을 때 볼 것:

• 무엇을 재나: 리전 전체인지, 인스턴스 하나인지. 단일 가용 영역에만 배포하면 SLA 적용 대상이 아닌 경우가 많다.
• 무엇이 빠지나: 사전 공지 점검, 이용자 설정 오류, 천재지변 같은 면책 사유.
• 누가 증명하나: 크레딧은 대개 이용자가 기한 안에 신청해야 한다.
• 보상의 한계: 크레딧은 요금의 일부일 뿐, 매출 손실은 보상하지 않는다. SLA는 사업자의 목표이지 내 서비스의 가용성 보증이 아니다.

결국 내 서비스의 가용성은 내가 설계한다. 여러 가용 영역에 나눠 두고, 의존하는 서비스들의 SLA를 곱해 보면(99.9% 서비스 세 개에 직렬로 기대면 약 99.7%) 목표가 현실적인지 알 수 있다(고가용성과 재해 복구 설계).

사업자 쪽에서는 가용률을 지키기 위한 정책(장애 관리 절차, 이중화, 증설·유지보수 계획), 담당 조직과 책임, 서버·VM 단위 모니터링, 가용률 분석과 예측을 갖춰야 한다. 이용자는 계약 전에 이걸 갖췄는지 묻는다.

무엇을 클라우드로 옮길까

현재 수준부터 평가

목표는 "클라우드 도입" 자체가 아니라 현재 IT 수준을 어디까지 끌어올리느냐다. 네 가지 관점에서 지금을 진단한다.

클라우드가 유리한 경우

• AI·빅데이터처럼 짧은 기간에 큰 계산 자원이 필요하다
• 신규·시범 서비스라 사용량을 미리 알 수 없다
• 사용량 변동이 크다(월말 정산, 이벤트)
• 빨리 만들어야 하거나 기술 변화에 민첩하게 대응해야 한다
• 테스트처럼 잠깐 큰 시스템이 필요하다
• 전환 비용보다 운영비 절감이 더 크다
• 자체 시스템을 안전하게 운영할 역량은 부족하지만, 클라우드를 다룰 역량은 있다

반대로 사용량이 일정하고 오래 돌 시스템은 자체 운영이 더 쌀 수 있다. 핵심 업무는 효율만이 아니라 업무 중요도, 다루는 정보의 민감도, 경영 전략까지 함께 따진다.

대상 시스템 고르기

1. 현업에서 IT를 많이 쓰는 사람들에게 요구사항을 모은다(VOC). "외부에서 결재하고 싶다", "테스트 서버를 받는 데 2주 걸린다", "월말 분석용 저장 공간이 부족하다" 같은 것.
2. 요구사항을 관련 시스템별로 분류하고, 자주 언급되는 시스템의 현황을 파악한다.
3. 선정 기준(유지 관리 부담 감소, 대용량 처리, 개발·테스트 효율, 비정기 이벤트 대응)으로 평가표를 만들어 점수가 높은 것부터 옮긴다.

중요도 평가

옮기기 전에 업무마다 중요도를 매긴다. 고유식별정보(주민등록번호, 여권번호 등)나 개인신용정보를 처리하면 중요 업무로 본다. 직접 다루지 않더라도 다음을 따져 중요 업무로 분류할 수 있다.

• 정보가 위·변조·유출되면 회사와 고객에게 미칠 영향
• 업무가 멈추면 생기는 운영·법적·평판 리스크와 수익 손실
• 다른 시스템과의 연계(장애가 번지는 정도)
• 목표 복구 시간, 운영·개발·테스트 중 어떤 용도인지, 이용자 수

중요도가 높을수록 아래의 준비를 더 촘촘하게 한다.

계약 전에 준비할 것

업무 연속성 계획

사업자 쪽 재해나 사고가 내 업무를 얼마나 멈추게 할지 파악하고 대비한다.

• 백업: 백업할 데이터를 고르고, 중요도에 따라 이중화나 다른 장소 보관(소산)을 한다. 복원 테스트와 무결성 검사를 정기적으로 하고, 백업에도 접근 통제와 암호화를 건다.
• 재해 복구 훈련: 비상 대응 매뉴얼을 만들고 정기적으로 훈련한다. 필요하면 사업자와 합동으로 한다. 사업자의 자체 훈련 계획도 확인한다.
• 역할과 연락: 사고 시 사업자와 우리의 역할 분담과 절차를 문서로 남기고, 핫라인을 미리 확보한다. 업무별 RTO(복구 목표 시간)와 RPO(복구 목표 시점)를 정해 사업자와 합의한다. RTO·RPO에 맞는 DR 전략은 고가용성과 재해 복구 설계에 있다.

출구 전략

사업자의 파산, 서비스 종료, 품질 저하, 규제 변화, 단순한 사정 변경. 언젠가 나올 수도 있다고 보고 미리 정해 둔다.

나가기 쉬우려면 처음부터 특정 사업자 전용 기능에 덜 기대는 게 유리하다. 표준 SQL을 쓰는 관리형 DB는 옮기기 쉽고, 사업자 고유의 메시징·워크플로 서비스에 깊이 묶이면 어렵다. 이건 편의와 이식성의 교환이다. 중요한 시스템일수록 출구 전략을 촘촘히 세우고, 계약서에 사업자의 협조 의무를 넣는다.

안전성 확보 조치

위협과 대응은 클라우드의 보안 위협에서 더 다룬다.

계약서에 넣을 것

정부가 공개한 클라우드 표준계약서(B2B, B2C)를 출발점으로 삼아 빠진 항목을 더하는 것이 현실적이다. 계약서가 아래 「이용자의 권리」를 빼거나 약하게 만들지 않았는지도 함께 본다. 침해사고 통지를 「유료 부가서비스」로 넣는 식으로 법이 정한 의무를 이용자 부담으로 돌리는 조항은 문제가 될 수 있다.

클라우드컴퓨팅법

국내 클라우드 이용의 기본법은 「클라우드컴퓨팅 발전 및 이용자 보호에 관한 법률」(2015년 3월 제정)이고, 이름 그대로 산업 진흥과 이용자 보호 두 축이다. 법령과 가이드라인은 자주 개정되므로 도입·계약 전에는 국가법령정보센터의 현행 조문과 소관 기관의 최신 가이드를 확인한다. 이 정리는 구조를 잡는 용도이고 법률 자문을 대신하지 않는다.

정보보호 기준은 KISA가 운영하는 클라우드 보안인증(CSAP)으로 이어진다. 공공기관이 쓰는 민간 클라우드는 이 인증을 요구받는 경우가 많고, 2023년부터 시스템 중요도에 따라 상·중·하 등급으로 나뉘었다. 등급별 세부 요건은 KISA 공지로 확인한다.

누가 이용자인가

법은 클라우드 서비스를 이용하는 자 모두를 이용자로 본다. 유료·무료를 가리지 않고, 자기 정보를 처리하려고 쓰는 회사와 다른 회사의 위탁을 받아 처리하는 회사(B2B), 국가·공공기관(B2G), 클라우드 드라이브를 쓰는 개인·개인사업자(B2C)가 모두 같은 지위다.

헷갈리기 쉬운 것이 최종 이용자다. 쇼핑몰이 AWS 위에서 돌아간다면 쇼핑몰 회사가 이 법의 이용자이고, 쇼핑몰 회원은 「이용자의 고객」이다. 회원은 클라우드 사업자에게 직접 권리를 행사하지 못하고 쇼핑몰 회사를 상대로 해야 하며, 회원의 개인정보 보호는 개인정보 보호법이 다룬다.

이용자의 권리

분야별 규정

클라우드컴퓨팅법은 기본법이고, 업종마다 따로 지켜야 할 규정이 있다.

규정을 설계로 옮기면

정리

• 품질은 가용성(가용률), 응답성(프로비저닝·응답 시간·TPS), 확장성(확장 기능과 처리 시간)으로 잰다.
• SLA의 숫자는 측정 범위와 면책 사유까지 읽는다. 크레딧은 손실을 메우지 못한다. 내 가용성은 내 설계가 정한다.
• 옮길 대상은 현재 수준 진단과 요구사항, 평가표로 고르고, 업무마다 중요도를 매긴다.
• 계약 전에 업무 연속성 계획, 출구 전략, 여덟 가지 보안 통제를 준비하고, 계약서에 위치·감사권·재위탁·정보 소유·파기를 넣는다.
• 클라우드컴퓨팅법(2015)은 진흥과 이용자 보호의 두 축이다. 제21조로 클라우드 계약이 전산 설비 요건을 대신하고, 이용자(최종 이용자는 제외)는 사고 통지·저장 국가 공개·반환·파기·임치·입증 책임 전환의 권리를 갖는다.
• 공공은 보안성 검토와 인증, 금융은 감독규정과 금융보안원 가이드, 의료는 국내 보관과 이중화가 핵심이다. 현행 조문은 반드시 다시 확인한다.

관련 노트: 고가용성과 재해 복구 설계, DevSecOps와 클라우드 보안, 클라우드 기초와 AWS, DevOps, SRE, 플랫폼 엔지니어링과 클라우드 거버넌스, 고가용성 이중화 구조와 장애 감지, 서비스 운영 준비 체크리스트, 관측 가능성