“99.9% 보장”을 쓰기 전에 — 작은 디지털 판매자의 SLA 문구 계산법과 예외 설계 (2026년 6월 기준)

SaaS, 유료 멤버십, 다운로드형 자료를 파는 작은 판매자라면 상세페이지에 “99.9% 안정 운영”, “무중단 제공”, “항상 접속 가능” 같은 문구를 넣고 싶어집니다. 결론부터 말씀드리면, 이런 가용성 수치를 쓰기 전에 반드시 세 가지를 먼저 정해야 합니다. 첫째, 그 수치가 실제로 허용하는 다운타임이 한 달에 몇 분인지 환산해 보아야 합니다(99.9%는 30일 기준 한 달에 약 43분, 1년에 약 8.76시간입니다). 둘째, 무엇이 “장애”에 포함되고 무엇이 예외인지 — 측정 범위·측정 기간·제외 시간 — 를 약관에 적어야 합니다. 셋째, 약속을 못 지켰을 때 환불·크레딧·기간 연장 중 무엇으로 어떻게 보상할지 기준을 미리 못 박아야 합니다. 이 세 가지가 없는 “99.9%”는 보장이 아니라 분쟁의 씨앗입니다.

가용성 문구는 한 번 적어 두면 고객의 기대치를 크게 끌어올립니다. 그런데 실제 장애가 발생했을 때 보상 기준과 예외를 정해 두지 않았다면, 고객은 “99.9%라더니 왜 한나절이나 안 됐느냐”고 따지고 판매자는 “그 정도는 정상 범위”라고 맞서게 됩니다. 한국소비자원의 소비자분쟁해결기준은 소비자와 사업자 간 분쟁을 합의·권고로 푸는 기준이고, 전자상거래 등에서의 소비자보호에 관한 법률(전자상거래법) 은 통신판매와 손해배상 관련 분쟁의 틀을 다룹니다. 즉 SLA 문구가 없어도 약속한 서비스를 제공하지 못하면 책임이 생길 수 있습니다. 그러니 작은 판매자일수록 “보장”을 외치기 전에, 가용시간 계산·제외 시간·보상 방식을 숫자와 문장으로 먼저 확정해 두는 편이 안전합니다. 이 글은 그 세 가지를 직접 계산하고 문구로 옮기는 방법을 정리했습니다.

⚠️ 핵심 주의: “99.9%”는 마케팅 단어가 아니라 측정 가능한 약속입니다. 측정 범위(무엇을), 측정 기간(언제를 기준으로), 제외 시간(무엇을 빼고), 보상 기준(어떻게 갚을지)을 함께 적지 않은 가용성 수치는, 사고가 나면 고스란히 판매자에게 불리하게 해석될 수 있습니다. 수치를 쓸 자신이 없다면 차라리 “정기 점검 외 안정적으로 제공하도록 노력합니다”처럼 측정 불가능한 노력 문구로 낮추는 편이 분쟁 위험이 적습니다.

SLA 문구를 쓰기 전 핵심 원칙
가용성 수치를 다운타임으로 환산하기
측정 범위와 측정 기간 정의하기
제외 시간(예외 조항) 설계하기
보상·크레딧 정책 설계하기
위험한 표현과 안전한 대체 표현
신고·감지 기준과 측정 방법
작은 판매자를 위한 SLA 작성 순서
운영 예시와 시뮬레이션
자주 묻는 질문(FAQ)
관련 정보

SLA 문구를 쓰기 전 핵심 원칙

SLA(Service Level Agreement, 서비스 수준 합의)는 원래 기업 간 계약에서 “이 정도 품질을 보장하고, 못 지키면 이렇게 보상한다”를 못 박는 문서입니다. 작은 디지털 판매자에게 정식 SLA 문서까지 필요한 경우는 드물지만, 상세페이지나 약관에 가용성 수치를 한 줄이라도 적는 순간 사실상 SLA를 선언한 것과 같아집니다. 그래서 수치를 쓸지 말지가 아니라, 쓴다면 측정·예외·보상까지 한 묶음으로 쓸 수 있는지가 판단의 기준이 됩니다.

원칙은 단순합니다. 측정할 수 없는 약속은 하지 않는다, 보상할 수 없는 약속은 하지 않는다. “무중단”은 0%의 다운타임을 뜻하는데, 외부 결제사·호스팅·CDN을 빌려 쓰는 작은 판매자가 0%를 보장하는 것은 사실상 불가능합니다. 정기 점검 한 번만 해도 “무중단”은 깨집니다. 반대로 “99.9%”처럼 측정 가능한 수치를 쓰면, 다음 표의 항목을 모두 정의해야 그 수치가 약속으로서 작동합니다.

항목	정해야 할 질문	정하지 않으면 생기는 문제
측정 범위	결제, 로그인, 다운로드, 영상 재생 중 무엇의 가용성인가	일부 기능 장애를 “전체 장애”로 주장당함
측정 기간	월간·연간·결제주기 중 무엇 기준인가	같은 다운타임이 기준에 따라 위반/정상으로 갈림
제외 시간	사전 공지 점검·외부 장애·천재지변을 뺄 것인가	통제 불가 사유까지 위반으로 계산됨
보상 방식	환불·크레딧·기간 연장 중 무엇인가	보상액·방식을 두고 매번 협상·분쟁
신고 기준	고객 신고 시점인가 모니터링 감지 시점인가	다운타임 시작·종료 시각을 두고 다툼

이 표는 “SLA 수치 한 줄”이 실제로는 다섯 개의 결정을 동시에 요구한다는 사실을 보여 줍니다. 다섯 칸을 다 채울 수 없다면, 아직 수치를 쓸 준비가 안 된 것입니다.

가용성 수치를 다운타임으로 환산하기

가용성 보장에서 가장 먼저 해야 할 일은, 쓰려는 퍼센트가 실제로 허용하는 정지 시간을 분 단위로 환산해 보는 것입니다. 환산 공식은 단순합니다.

허용 다운타임 = 측정 기간 × (1 − 가용성 비율)

계산의 기준값만 고정하면 됩니다. 이 글은 1일=1,440분, 1주=10,080분, 30일 월=43,200분, 1년(365일)=525,600분을 기준으로 계산했습니다. 아래 표의 값은 모두 위 환산식으로 직접 산출한 것이며, 업계에서 통용되는 “나인(9)” 환산표와 동일합니다. 예를 들어 99.9%의 연간 다운타임은 525,600분 × 0.001 = 525.6분 = 8.76시간입니다.

가용성 보장	허용 다운타임 비율	연간(365일)	월간(30일 기준)	주간	일간
99% (투 나인)	1%	약 3.65일 (87.6시간)	약 7.2시간 (432분)	약 1.68시간 (100.8분)	약 14.4분
99.5%	0.5%	약 1.83일 (43.8시간)	약 3.6시간 (216분)	약 50.4분	약 7.2분
99.9% (스리 나인)	0.1%	약 8.76시간	약 43.2분	약 10.08분	약 1.44분
99.95%	0.05%	약 4.38시간	약 21.6분	약 5.04분	약 43.2초
99.99% (포 나인)	0.01%	약 52.56분	약 4.32분	약 1.01분 (약 60.5초)	약 8.6초

여기서 작은 판매자가 꼭 짚어야 할 함정이 두 가지 있습니다.

첫째, “월” 기준을 며칠로 잡느냐에 따라 허용치가 달라집니다. 위 표는 계산을 단순하게 하려고 30일(43,200분) 월을 썼지만, 실제 한 달 평균은 365.25 ÷ 12 ≈ 30.44일이고 시간으로는 약 730.5시간(43,830분)입니다. 99.9%를 이 평균 월에 적용하면 허용 다운타임은 43,830분 × 0.001 ≈ 43.83분으로, 30일 기준(43.2분)보다 0.6분쯤 늘어납니다. 큰 차이는 아니지만, 약관에는 “월간(역월 기준)” 또는 “직전 30일 기준”처럼 어느 쪽인지 명시해야 분쟁 때 해석이 갈리지 않습니다. 아래 표로 “월 기준 정의”에 따른 99.9% 허용치를 비교했습니다.

99.9%의 “월” 정의	기준 분	허용 다운타임
30일 고정	43,200분	약 43.2분
31일 역월	44,640분	약 44.64분
28일 역월(2월)	40,320분	약 40.32분
평균 월(30.44일)	43,830분	약 43.83분

둘째, 측정 기간이 길수록 한 번의 큰 사고를 흡수하기 어렵습니다. 99.9%를 “연간”으로 보장하면 1년 내내 합쳐 8.76시간까지 멈춰도 위반이 아니지만, 같은 99.9%를 “월간”으로 보장하면 한 달에 43분만 넘겨도 위반입니다. 작은 판매자에게는 흔히 월간 기준이 더 가혹합니다. 한 번의 호스팅 장애(예: 2~3시간)가 그 달의 한도를 즉시 초과시키기 때문입니다. 그래서 수치를 정할 때는 “몇 %”만이 아니라 “어느 기간 기준 몇 %”까지 한 세트로 결정해야 합니다.

측정 범위와 측정 기간 정의하기

가용성은 “서비스가 살아 있었는가”를 잰 값인데, 무엇을 ‘서비스가 살아 있다’로 볼지가 핵심입니다. 결제는 되는데 영상 재생만 안 되는 상황, 로그인은 되는데 다운로드만 막힌 상황을 각각 어떻게 셀지 정하지 않으면, 같은 사건을 두고 고객은 “전면 장애”, 판매자는 “부분 장애”라고 주장하게 됩니다.

권장하는 방식은 핵심 기능 단위로 측정 대상을 쪼개는 것입니다. 예를 들어 “결제·로그인은 가용성 측정 대상, 영상 재생 품질·다운로드 속도는 측정 대상에서 제외(별도 안내)”처럼 구분하면, 어떤 기능이 멈췄을 때 위반인지 명확해집니다. 측정 대상이 아닌 기능은 “보장 수치에는 포함하지 않지만 장애 시 공지·대체 제공으로 대응한다”고 따로 적어 두면 됩니다.

측정 기간도 함께 못 박아야 합니다. 결제주기 기준(예: 월 구독자는 그 사람의 결제일~~다음 결제일)으로 측정하면 고객마다 기준 구간이 달라 관리가 복잡하지만 공정하게 느껴지고, 역월 기준(매월 1일~~말일)으로 측정하면 관리가 단순합니다. 작은 판매자는 보통 역월 기준이 운영하기 쉽습니다. 어느 쪽이든 “월간(역월 기준) 가용성” 같은 식으로 약관에 한 줄 적어 두는 것이 핵심입니다.

제외 시간(예외 조항) 설계하기

가용성 100%가 불가능한 이유의 대부분은 판매자가 통제할 수 없는 시간입니다. 정기 점검, 외부 결제사·호스팅·CDN 장애, 천재지변, 고객 측 네트워크 문제 등이 그렇습니다. 이런 시간을 다운타임 계산에서 빼는 것이 “제외 시간(예외 조항)”입니다. 다만 예외를 너무 넓게 잡으면 보장이 사실상 무의미해지고 신뢰가 떨어지므로, “무엇을 어떤 조건에서 제외하는지”를 구체적으로 적는 것이 중요합니다.

제외 후보	제외해도 되는가	함께 적어야 할 조건
사전 공지한 정기 점검	일반적으로 제외 가능	며칠 전·몇 시간 전 공지, 점검 시간대(예: 새벽), 월 최대 점검 시간 상한
긴급 보안 점검	제외 가능하나 한도 필요	사후 공지 허용 여부, 연간 허용 횟수·시간
외부 SaaS·결제사·호스팅 장애	제외 가능하나 책임 일부 남음	영향 범위 공지 의무, 대체 수단(대체 링크·기간 연장) 제공
천재지변·통신사 광역 장애	제외 가능	불가항력 정의, 복구 노력·공지 의무
고객 측 기기·네트워크 문제	제외 가능	판매자 측 정상 작동 입증 가능 시
판매자 코드 배포 실수·서버 설정 오류	제외 불가	이는 판매자 통제 영역 → 다운타임에 포함

핵심은, “외부 장애라 제외”가 곧 “책임 없음”은 아니라는 점입니다. 외부 SaaS가 멈춰 다운로드가 안 되더라도, 고객에게는 “지금 외부 장애로 다운로드가 지연되며, 복구 시 기간을 연장해 드린다” 같은 공지와 대체 제공의 책임이 남습니다. 예외 조항은 “보상 의무를 줄이는 장치”이지 “고객을 방치해도 되는 면죄부”가 아닙니다. 너무 넓은 면책은 전자상거래법상 소비자에게 부당하게 불리한 조항으로 다퉈질 여지도 있으니, 예외는 구체적이고 합리적인 범위로 좁혀 적는 편이 안전합니다.

보상·크레딧 정책 설계하기

SLA의 마지막 한 칸은 “못 지켰을 때 어떻게 갚을 것인가”입니다. 보상 방식은 보통 이용기간 연장(크레딧), 부분 환불, 대체 제공 세 가지로 정리됩니다. 작은 판매자에게는 현금 환불보다 기간 연장·크레딧이 운영 부담이 적고, 고객도 서비스를 계속 쓰는 경우가 많아 합리적인 1차 보상이 됩니다. 다만 다운로드형 단품처럼 “기간”이 없는 상품은 연장이 의미 없으므로 환불·대체 제공이 기본이 됩니다.

보상 정책은 다운타임 길이에 따라 단계(티어)로 설계하는 것이 분쟁을 줄입니다. “얼마 이상 멈추면 무엇을 준다”를 표로 못 박으면, 사고 때마다 보상액을 협상할 필요가 없어집니다. 아래는 “월간 99.9% 목표”를 가정한 보상 티어 예시입니다.

월간 누적 다운타임(제외 시간 제외)	보상
측정 가능 한도 이내(99.9% = 약 43분 이내)	보상 없음(약속 준수)
한도 초과 ~ 4시간	이용기간 1일 연장(또는 그에 상응하는 크레딧)
4시간 초과 ~ 24시간	이용기간 3일 연장 또는 해당 월 요금의 일부 크레딧
24시간 초과	해당 월 부분 환불 또는 대체 제공 중 고객 선택

보상 정책에는 상한과 신청 절차도 함께 적는 것이 좋습니다. 예를 들어 “월 보상 총액은 해당 월 결제액을 넘지 않는다”, “보상은 사유 발생 후 30일 이내 신청분에 한한다”처럼 한도를 두면 예측 가능성이 높아집니다. 동시에 “판매자 측 장애로 인한 보상 신청을 부당하게 어렵게 만드는 조항”은 피해야 합니다. 보상 기준을 표시하지 않고 “환불 불가”만 적어 두면, 판매자 귀책 장애 상황에서 그 조항은 소비자에게 불리하게 해석될 수 있으니 “판매자 장애 시 보상 기준은 별도”라고 분명히 구분해 두는 것이 안전합니다.

위험한 표현과 안전한 대체 표현

상세페이지 카피는 측정·보상 설계와 어긋나면 안 됩니다. 측정·예외·보상을 정하지 않은 채 강한 단어부터 쓰면, 그 단어가 그대로 약속으로 굳어 버립니다. 아래는 자주 쓰이는 위험 표현과, 같은 메시지를 더 안전하게 바꾼 대체 방향입니다.

위험한 표현	왜 위험한가	안전한 대체 방향
무중단 제공	0% 다운타임 약속 → 점검 한 번에 위반	“정기 점검(사전 공지) 외 안정적으로 제공”
99.9% 보장	측정·예외·보상 없으면 일방적 약속	“월간(역월) 99.9% 목표, 제외 시간·보상 기준은 약관 참조”
항상 다운로드 가능	외부 장애 시 즉시 거짓이 됨	“장애 시 대체 링크·기간 연장 제공”
환불 불가	판매자 귀책 장애에도 적용되면 부당	“판매자 장애 시 보상 기준 별도 표시”
평생 이용 보장	‘평생’의 종료 시점·승계 불명확	“서비스 운영 기간 동안 이용 가능, 종료 시 ○개월 전 공지”

대체 표현의 공통 원칙은 “보장(guarantee)”을 “목표(target)+보상(remedy)”으로 바꾸는 것입니다. “보장”은 0과 1의 약속이라 한 번의 사고로 깨지지만, “목표 + 미달 시 보상”은 사고가 나도 약속 구조 안에서 처리됩니다. 작은 판매자일수록 이 구조가 훨씬 방어적이고 정직합니다.

신고·감지 기준과 측정 방법

다운타임을 계산하려면 시작 시각과 종료 시각이 있어야 합니다. 그런데 “언제부터 멈춘 것으로 보느냐”가 모호하면 같은 사건의 길이가 달라집니다. 기준은 보통 두 가지입니다. 모니터링 감지 시점(판매자가 외형 점검 도구로 장애를 인지한 시각)과 고객 신고 시점(고객이 처음 신고한 시각)입니다.

작은 판매자는 자동 모니터링이 없는 경우가 많아 현실적으로 고객 신고 시점을 기준으로 삼게 되는데, 이때는 “신고 채널과 접수 시각 기록 방법”을 정해 두어야 합니다. 예를 들어 “장애 신고는 고객센터 메일·채팅으로 접수하며, 접수 시각을 다운타임 시작으로 본다. 단, 판매자가 그 전에 인지·공지한 경우 인지 시각을 시작으로 본다”처럼 적으면 양쪽 기준을 합리적으로 묶을 수 있습니다. 가능하면 외형 모니터링(uptime 체크) 도구를 함께 두어, 신고가 없어도 장애를 자동 기록하게 하면 분쟁 때 객관적 근거가 됩니다.

종료 시각도 “고객이 재이용을 확인한 시각”이 아니라 “서비스가 정상 복구된 시각”으로 통일하고, 복구 공지로 그 시각을 기록해 두면 됩니다. 요컨대 측정 방법 자체를 약관에 한두 문장으로 적어 두는 것이, 나중에 “몇 분 멈췄는지”를 두고 싸우지 않는 가장 확실한 방법입니다.

작은 판매자를 위한 SLA 작성 순서

지금까지의 내용을 실제 문구로 옮기는 순서입니다. 위에서부터 차례대로 결정하면, 마지막에 카피 한 줄이 자연스럽게 정해집니다.

측정 대상을 고른다. 결제·로그인·다운로드·재생 중 무엇의 가용성을 보장 대상으로 할지 정하고, 나머지는 “측정 제외, 장애 시 공지·대체”로 분리합니다.
측정 기간을 정한다. 월간(역월) / 결제주기 / 연간 중 하나를 고르고, “월”의 일수 기준(30일 고정 vs 역월)을 명시합니다.
목표 수치를 환산해 본다. 쓰려는 %를 환산표로 분 단위로 바꿔, 한 달에 그 다운타임을 실제로 지킬 수 있는지 점검합니다. 못 지킬 것 같으면 수치를 낮춥니다(예: 99.9% → 99.5%).
제외 시간을 구체적으로 적는다. 정기 점검 공지 시점·시간대·상한, 외부 장애 대체 의무, 불가항력 정의를 넣습니다. 단, 판매자 귀책(배포 실수 등)은 제외하지 않습니다.
보상 티어를 표로 만든다. 다운타임 길이별로 연장·크레딧·환불·대체를 단계로 정하고, 보상 상한과 신청 기한을 적습니다.
신고·측정 방법을 한 문장으로 적는다. 신고 채널, 다운타임 시작·종료 시각 기준을 명시합니다.
카피를 보수적으로 쓴다. “보장”을 “목표 + 미달 시 보상”으로 바꾸고, 상세페이지 문구가 약관과 어긋나지 않는지 대조합니다.

작성 후 저장 전 점검 체크리스트:

쓰려는 %를 분 단위 다운타임으로 환산해 보았다(월/연 기준 모두).
측정 대상 기능과 측정 제외 기능을 구분해 적었다.
측정 기간(월간/결제주기/연간)과 “월”의 일수 기준을 명시했다.
제외 시간을 구체 조건과 함께 적었고, 판매자 귀책은 제외하지 않았다.
보상 방식·티어·상한·신청 기한을 표로 정했다.
다운타임 시작·종료 시각 기준과 신고 채널을 적었다.
상세페이지 카피가 약관의 측정·예외·보상과 일치한다.
“환불 불가”가 판매자 귀책 장애에도 적용되지 않도록 예외를 분리했다.

운영 예시와 시뮬레이션

다음은 “월간(역월) 99.9% 목표 + 단계별 보상”을 채택한 작은 멤버십 판매자의 가상 운영 예시입니다. 같은 다운타임이라도 사전 공지 여부·귀책 주체에 따라 보상이 어떻게 갈리는지 보여 줍니다.

상황	다운타임 계산	보상
사전 공지한 새벽 점검 2시간	제외 시간 → 다운타임 0분	보상 없음(사전 공지)
예고 없는 서버 설정 오류 6시간	판매자 귀책 → 360분, 월 한도(약 43분) 초과	이용기간 1일 연장(4시간 이하 티어)
외부 CDN 장애로 다운로드 24시간 초과	외부 장애지만 영향 큼 → 공지·대체 후 24시간 초과 티어	환불 또는 대체 제공 중 고객 선택
외부 결제사 장애 1시간	제외 가능하나 결제 불가 영향 공지	영향 범위 공지 + 결제 재시도 안내

이 표의 핵심은, “6시간 멈췄다”는 사실 자체가 아니라 ‘사전 공지였는지·누구 귀책인지·측정 대상 기능인지’가 보상을 가른다는 점입니다. 그래서 앞 단계에서 측정·예외·보상을 미리 정해 두면, 사고가 나도 표 한 장으로 처리할 수 있습니다.

한 가지 더, 99.9%를 월간으로 보장한 위 판매자는 “예고 없는 6시간 장애” 한 번으로 그 달의 한도(약 43분)를 8배 넘게 초과합니다(360분 ÷ 43.2분 ≈ 8.3배). 만약 같은 99.9%를 연간 기준으로 보장했다면 1년 합산 8.76시간 한도 안에서 “아직 위반 아님”이 될 수도 있습니다. 이처럼 같은 수치라도 측정 기간 하나로 위반 여부가 완전히 달라지므로, 환산과 기간 설정을 가장 먼저 끝내는 것이 중요합니다.

자주 묻는 질문(FAQ)

Q. SLA 문구를 아예 안 쓰면 책임도 없나요?

아닙니다. 가용성 수치를 적지 않았더라도, 약속한 서비스를 제공하지 못하면 소비자분쟁해결기준·전자상거래법의 틀 안에서 분쟁이 생길 수 있습니다. SLA 문구를 생략하는 것은 “책임 회피”가 아니라 “과도한 보장 표현을 피하는” 효과일 뿐입니다. 수치를 안 쓰더라도 장애·점검·보상에 대한 최소한의 안내는 두는 편이 좋습니다.

Q. 99.9%는 한 달에 얼마나 멈춰도 되는 건가요?

30일(43,200분) 월 기준으로 약 43.2분, 평균 월(30.44일) 기준으로는 약 43.8분입니다. 연간으로는 약 8.76시간입니다(525,600분 × 0.001). 이 값은 “허용 다운타임 = 측정 기간 × (1 − 가용성)” 공식으로 직접 계산한 값이며, 자세한 등급별 환산은 본문 환산표를 참고하시기 바랍니다.

Q. 외부 SaaS(결제사·호스팅) 장애는 SLA에서 빼도 되나요?

약관에 예외(제외 시간)로 둘 수는 있습니다. 다만 외부 장애라도 고객에게 영향 범위를 공지하고 대체 수단(대체 링크·기간 연장 등)을 제공할 책임은 남습니다. 또 면책 범위를 지나치게 넓게 잡으면 소비자에게 부당하게 불리한 조항으로 다퉈질 수 있고 신뢰도 떨어지므로, 예외는 구체적이고 합리적인 범위로 좁혀 적는 것이 좋습니다.

Q. 월 1만 원짜리 멤버십에도 정식 SLA가 필요한가요?

정식 SLA 문서까지는 보통 필요 없습니다. 다만 장애·점검·보상 기준 정도는 약관이나 안내에 적어 두는 것이 안전합니다. 금액이 작아도 분쟁은 생기고, “보상 기준이 미리 적혀 있는지”가 분쟁 해결의 속도를 좌우합니다. 수치 보장 대신 “정기 점검 외 안정적으로 제공하도록 노력하며, 장애 시 기간 연장으로 보상”처럼 가벼운 문구도 한 방법입니다.

Q. “보장” 대신 어떤 단어를 쓰는 게 안전한가요?

“보장(guarantee)”은 0과 1의 약속이라 한 번의 사고로 깨집니다. 대신 “목표(target) + 미달 시 보상(remedy)” 구조를 권합니다. 예: “월간 99.5%를 목표로 하며, 미달 시 본 약관의 보상 기준에 따라 이용기간을 연장합니다.” 이렇게 쓰면 사고가 나도 약속 구조 안에서 처리되어, “보장한다더니 왜 깨졌느냐”는 분쟁을 줄일 수 있습니다.

Q. 다운타임의 시작·종료 시각은 어떻게 정하나요?

기준을 약관에 미리 적어 두는 것이 핵심입니다. 자동 모니터링이 있으면 “감지 시각~~복구 시각”을, 없으면 “고객 신고 접수 시각~~정상 복구 공지 시각”을 기준으로 삼고, 판매자가 먼저 인지·공지한 경우 그 인지 시각을 시작으로 본다고 적으면 됩니다. 가능하면 외형 uptime 체크 도구를 함께 두어 객관적 기록을 남기는 것을 권합니다.

작은 디지털 판매자의 SLA 문구 — “99.9% 보장”을 쓰기 전에 계산과 예외를 정하기