CCAR-P 개념 카드

■ SLA 조항 쓰기

SLA clause : 재는 것 · 위반 기준 · 위반 시 조치 · 임계값 출처 · 재현 가능한 측정6.3 본편

표시가 없는 문장은 공식 문서에서 확인한 내용이에요. 다른 표시는 읽는 법

왜 배우나 — 시험이 요구하는 것

시험 목표 6.3 피드백과 기대 맞추기 · D6 사람·문서 14%
Manage stakeholder feedback loops and expectation alignment (including SLAs)

이 개념으로 푸는 판단 (할 수 있어야 하는 것)

  • 6.3① "AI 답변이 항상 정확하다고 계약서에 넣어 달라" — 무엇을 약속하나? — 기대치 맞추기 (100% 대신 측정된 SLO + 사람 안전망)

한눈에

약속 한 줄은 세 부분으로 쓴다.

  • 무엇을 재나? (대상 요청 · 지표 · 기간)
  • 무엇이 위반인가? (선)
  • 어기면 무엇이 따르나? (구제 · 축소 운영 · 통보 대상)

셋 중 하나가 빠지면 분쟁 때 아무도 답을 못 한다 업계 일반 Anthropic 문서에 SLA 조항 양식 없음

공식 문서에서 가장 가까운 것은 좋은 기준 문장이다. 대상 집합(held-out 평가셋), 지표, 선을 한 문장에 여러 차원으로 쓴다("95% response time < 200ms" 포함). 오류의 뜻도 따로 정의한다 (성공 기준 문장이다. SLA 조항으로 넓힌 것은 해석이다)

무엇을 약속하고 무엇은 안 하나(100% 금지 · 코드 한도 · 사람 안전망)는 ◆ 100% 약속 vs 측정된 SLO + 사람 안전망 에 있다. 여기는 약속 문장을 어떻게 쓰는지 다룬다

비유 클라우드 SLA 한 줄에는 측정 대상(월간 가동률) · 선(99.9%) · 보상(서비스 크레딧)이 있다. "가장 바쁜 주는 측정에서 제외" 같은 조항이 속이는 습관이다

SLA 조항 한 줄은 재는 것·위반 선·어기면 따르는 것 세 부분이 함께 있어야 하고, 클라우드 SLA 의 가동률·99.9%·크레딧과 같은 짜임이다.
그림으로 보기 (AI 생성 · Codex · 누르면 크게)

ELI5

택배 회사와 "이틀 안에 배달, 늦으면 배송비를 돌려준다"는 약속을 쓴다고 해 봐요.

  • 어느 택배를, 며칠 안에 받는지(무엇을 재나)를 적어요.
  • 어디서부터 늦은 건지(선)와, 늦으면 무엇을 해 주는지(구제)도 적어요.
  • 명절처럼 제일 바쁜 때를 빼고 재면, 약속은 지킨 것처럼 보여도 사람들은 화가 나요.
  • 그래서 바쁜 때도 넣고, 누가 다시 재도 같은 숫자가 나오게 써요.

개념 설명

영상 — 폭주 주간을 빼면 보고서만 초록 (약 43초 · 소리 없음 · 자막). 5만 건 · 2만 건(40%) · 4,900건 = 9.8% · 3% 는 설명 '뒤집히는 때 1' 의 계산(초과 비율 20%·3% 는 그림용 가정), 점 1개 = 100건, 장애 점 6개는 그림용 가정 · 조항은 그 계산을 따라 월 단위(지문은 주 단위) · '쇼핑몰 시스템 장애' = 설명의 '고객 쪽 시스템 장애' 작은 화면에서는 전체화면(⛶)으로 보세요.

원리

조항 한 줄의 세 부분 (업계 일반 — Anthropic 문서에 SLA 조항 양식 없음)

  • 무엇을 재나 : 대상 요청(어느 요청 종류) · 지표 · 측정 기간을 적는다.
  • 무엇이 위반인가 : 숫자 선과 무엇을 오류로 세는지 적는다.
  • 어기면 무엇이 따르나 : 크레딧 등 구제 · 미리 합의한 축소 운영 · 통보 대상을 적는다.
  • 하나라도 빠지면 분쟁 때 "위반이냐, 그래서 뭘 하냐" 에 아무도 답을 못 한다.
  • 공식 문서에서 가장 가까운 것은 좋은 성공 기준 문장이다. 대상 집합(held-out 평가셋), 지표, 선을 한 문장에 여러 차원으로 쓴다. "불편 · 심각" 같은 오류의 뜻도 따로 정의한다 (define-success). SLA 로 넓힌 것은 해석이다.

지연 조항이 속기 쉬운 곳

  • 평균으로는 안 된다. 분위수로 건다 (본편 ◆ 100% 약속 vs 측정된 SLO + 사람 안전망).
  • 분위수여도 피크를 빼면 소용없다. 고객지원에 Claude 를 쓰는 이유 자체가 성수기 급증을 인력 없이 받는 것이다(공식). 그 주를 빼면 약속이 가장 필요한 때를 지표에서 지운다.
  • 요청 종류가 섞이면 쉬운 요청(배송 조회)이 어려운 요청(환불)을 가린다. 공식 고객지원 가이드도 deflection 목표·처리 시간이 문의 복잡도에 따라 달라진다고 한다.

숫자는 어디서 오나

  • 공식 출처는 업계 벤치마크 · 이전 실험 · AI 연구 · 전문가 지식이다. 목표는 현재 프런티어 모델 역량에 비춰 현실적으로 잡는다. 지연 선은 앱의 실시간 요구와 사용자 기대에 달렸다.
  • 품질 숫자는 재현 가능해야 한다. 버전 고정 평가셋과 적어 둔 채점법을 쓴다. 자동 eval 은 "Fully reproducible" 이다(공식).

핵심 질문 두 개

  • 분쟁이 나면 이 한 줄만 보고 "위반이다 / 아니다 / 그래서 이렇게 한다" 가 나오나?
  • 사용자가 서비스가 가장 필요한 순간이 이 숫자 안에 들어 있나?

규칙과 판단

지연 조항은 평균 대신 분위수로 재고, 폭주 주간 제외 조항은 빼며, 요청 종류가 섞였으면 종류별로 나눈다. 파일럿 최고 주 값은 선의 출처가 아니다.
그림으로 보기 (AI 생성 · Codex · 누르면 크게)

갈림길

①⑤ 조항 세 부분 [6.3①]

무엇을 재는지 적혔나?대상 요청 · 지표 · 기간
아니오 ("빠르고 정확하게")

재는 것부터 적는다

구체적이고 측정 가능한 지표로 적는다. 자세한 것은 ■ 성공 기준 에 있다

예
위반 기준이 있나?기준 숫자 · 오류의 뜻
아니오

선을 적는다

숫자 선과 무엇을 오류로 세는지 적는다 업계 일반. "불편"·"심각" 의 뜻은 따로 정의한다 (SLA 로 넓힌 것은 해석이다)

예
어기면 무엇이 따르나?
안 적혔다

구제를 적는다

크레딧 등 구제, 미리 합의한 축소 운영, 통보 대상을 적는다 업계 일반

적혔다

↓ 아래 「지연 조항」 갈림길로 이어짐

다음 물음 — 무엇으로 재나?

② 지연 조항 [6.3①] [4.1]

무엇으로 재나?
평균 · 월 전체

분위수로 잰다

예 : "응답 95% 가 200ms 미만". 자세한 것은 ◆ 100% 약속 vs 측정된 SLO + 사람 안전망 에 있다

분위수 (p95 · p99)
피크가 들어가나?연휴 · 프로모션 · 성수기
제외 조항이 있다 (폭주 주간·연휴)

제외 조항을 뺀다

사용자가 서비스를 가장 필요로 하는 때를 지표에서 빼면 보고서만 준수가 된다 업계 일반. 성수기 급증 문의를 추가 인력 없이 처리하는 것이 고객지원 도입 이득 자체다

포함한다
요청 종류가 섞였나?배송 조회 vs 환불
예

종류별로 건다

deflection 목표·처리 시간이 문의 복잡도에 따라 달라진다 (종류별 조항으로 넓힌 것은 해석이다)

아니오

한 줄로 건다

피크를 포함한 기간으로 잰다. 분위수 하나에 선 하나를 둔다 업계 일반

③④ 숫자 출처 [6.3①] [4.1]

선을 무엇으로 정했나?기대 · 벤치마크 · 평가셋 · 현장 평점 · 그럴싸한 값
사용자 기대·실시간 요구 (지연 선)

사용자 기대에 달렸다

지연 선은 앱의 실시간 요구와 사용자 기대에 달렸다

업계 벤치마크

공식 출처다

내 요청 분포로 한 번 재 본 뒤 쓴다 업계 일반. 공식 출처는 업계 벤치마크 · 이전 실험 · AI 연구 · 전문가 지식이다

버전 고정 평가셋 + 채점법 (품질 선)

약속 근거가 된다

자동 eval 은 완전히 재현 가능하다. 고정 과제 묶음에서 기준선을 잰다

현장 평점 · 매번 다른 표본

근거가 못 된다

분쟁 때 근거가 못 된다 업계 일반. 운영 모니터링에는 채점할 정답이 없다

파일럿 최고 주 · 그럴싸한 숫자

출처가 아니다

파일럿에서 제일 좋던 주의 값이나 "지금보다 조금 위" 같은 그럴싸한 숫자는 출처가 아니다 업계 일반. 공식 출처는 4가지다

흐름

그림 속 이름·금액·시간·토큰 수는 예시예요. 공식 한도·동작은 카드 본문 값이 기준.

장면 글로 보기

칸 : 고객 불만 → SLA 조항 → 측정 로그 → 판정

규칙 (SLA 조항) : 재는 것 · 위반 기준 · 위반 시 조치

질문 : 이 불만은 위반일까?

① 피크 포함 · 세 부분 ✓

  1. 시작 : 고객 불만 — 말 : “연휴 다음 주 내내 환불 답이 늦었어요.”
  2. 조회 : 고객 불만 → SLA 조항 : 무엇을 재나 — 쪽지 : 환불 문의 / 첫 답 p95 ≤ 5초 / 주 단위 / 피크 포함
  3. 재기 : SLA 조항 → 측정 로그 : 무엇이 위반인가 — 쪽지 : 연휴 다음 주 / p95 7.6초 / 선 5초 넘음
  4. 판정 : 측정 로그 → 판정 : 어기면 무엇이 따르나 — 쪽지 : 위반 / 크레딧 10% / 환불 문의는 / 상담원으로
  5. 끝 : 셋이 다 있으면 분쟁 때 바로 답이 나온다

② 폭주 주간 제외 ≠

  1. 시작 : 고객 불만 — 말 : “연휴 다음 주 내내 환불 답이 늦었어요.”
  2. 조회 : 고객 불만 → SLA 조항 : 제외 조항 — 쪽지 : 첫 답 p95 ≤ 5초 / 연휴 폭주 주간 / 측정 제외
  3. 재기 : SLA 조항 → 측정 로그 : 서비스가 가장 필요한 주가 빠진다 — 쪽지 : 제외 뒤 / p95 3.1초
  4. 판정 : 측정 로그 → 판정 : 보고서만 준수다 ≠ — 쪽지 : 준수 / 현장: 상담원에 / 직접 전화
  5. 끝 : 사용자가 서비스를 가장 필요로 하는 때를 지표에서 빼면 보고서만 준수가 된다

③ 위반 시 조치가 없다 ≠

  1. 시작 : 고객 불만 — 말 : “연휴 다음 주 내내 환불 답이 늦었어요.”
  2. 조회 : 고객 불만 → SLA 조항 : 구제 칸이 비어 있다 — 쪽지 : 첫 답 p95 ≤ 5초 / 피크 포함 / 어기면: (없음)
  3. 재기 : SLA 조항 → 측정 로그 : 무엇이 위반인가 — 쪽지 : p95 7.6초 / 선 5초 넘음
  4. 판정 : 측정 로그 → 판정 : 다음 행동이 없다 ≠ — 쪽지 : 위반은 맞음 / 그다음은? / 협상 새로
  5. 끝 : 셋 중 하나가 빠지면 분쟁 때 아무도 답을 못 한다
규칙 원문 ①②③④⑤ (갈림길로 그린 규칙)
  1. 조항 한 줄 : 재는 것, 위반 기준, 위반 시 조치를 한 줄에 쓴다 업계 일반 [6.3①]

    재는 것은 대상 요청(어느 요청 종류) · 지표 · 측정 기간이다. 위반 기준은 기준 숫자와 무엇을 오류로 세는지다 업계 일반

    숫자 없는 말("빠르고 정확하게")은 재는 것이 아니다. 구체적이고 측정 가능한 지표로 쓴다. 자세한 것은 ■ 성공 기준 에 있다

    공식 기준 문장도 대상 집합, 지표, 선을 한 문장에 쓴다. 대부분 여러 차원으로 쓴다

    공식 예는 "오류의 90% 는 불편 수준" 이라고 쓴다. 그리고 "불편"·"심각" 의 뜻은 따로 정의하라고 한다 (성공 기준 문장이다. SLA 로 넓힌 것은 해석이다)

    기준 쓰는 법은 ■ 성공 기준 에 있다

    셋이 다 있으면 분쟁 때 바로 답이 나온다. 셋 중 하나가 빠지면 분쟁 때 아무도 답을 못 한다 업계 일반

  2. 지연 조항 : 분위수로 재고, 피크를 포함하고, 요청 종류별로 건다 [6.3①] [4.1]

    분위수로 거는 것은 본편 ◆ 100% 약속 vs 측정된 SLO + 사람 안전망 에 있다. 지연(latency)은 공식 운영 지표다(response time · uptime)

    피크 포함 : 사용자가 서비스를 가장 필요로 하는 때를 지표에서 빼면 보고서만 준수가 된다. 현장은 도구를 버린다 업계 일반

    공식 근거 : 성수기 급증 문의를 추가 인력 없이 처리하는 것이 고객지원 도입 이득 자체다

    짧은 폭주도 rate limit(속도 제한) 오류를 낸다. 자세한 것은 ■ rate limit 에 있다

    Priority Tier 도 "피크 때에도" 과부하 오류를 줄이려는 장치다 (피크에서 재라로 넓힌 것은 해석이다)

    기준선도 피크를 포함한 기간으로 잰 뒤 선을 정한다. 분위수 하나에 선 하나를 둔다 업계 일반. 잰 뒤 거는 순서는 ◆ 100% 약속 vs 측정된 SLO + 사람 안전망 에 있다

    요청 종류별 : 공식 고객지원 가이드는 deflection(사람 없이 해결) 목표가 문의 복잡도에 따라 달라진다고 한다. 처리 시간도 문제 복잡도에 따라 크게 달라진다고 한다

    그래서 배송 조회와 환불을 한 분위수로 섞으면 쉬운 요청이 어려운 요청을 가린다 (종류별 조항으로 넓힌 것은 해석이다)

  3. 임계값 출처 [6.3①] [4.1]

    공식 문서는 목표를 업계 벤치마크 · 이전 실험 · AI 연구 · 전문가 지식에 근거하라고 한다. 현재 프런티어 모델 역량에 비춰 비현실적이면 안 된다

    지연 선은 앱의 실시간 요구와 사용자 기대에 달렸다. 성공을 정의하기 가장 좋은 사람은 제품 요구·사용자에 가장 가까운 사람이다

    파일럿에서 제일 좋던 주의 값이나 "지금보다 조금 위" 같은 그럴싸한 숫자는 출처가 아니다 업계 일반. 업계 벤치마크를 쓰더라도 내 요청 분포로 한 번 재 본 뒤 쓴다 업계 일반

  4. 품질 조항은 재현 가능하게 [6.3①] [4.1]

    버전 고정 held-out 평가셋과 적어 둔 채점법을 쓰면 누가 다시 돌려도 같은 숫자가 나온다. 자동 eval 은 완전히 재현 가능하다

    고정 과제 묶음에서 지연·토큰·과제당 비용·오류율 기준선을 잰다

    평가셋은 실제 과제 분포를 닮게 만들고 엣지 케이스를 넣는다

    현장 평점이나 매번 다른 표본 채점은 분쟁 때 근거가 못 된다 업계 일반. 운영 모니터링에는 채점할 정답이 없다

    LLM 채점을 쓰면 사람 정기 보정(calibration)까지 한다. 자세한 것은 ■ LLM-as-judge 설계 에 있다

    조항에 평가셋 버전을 적는다. 평가셋이 바뀌면 숫자도 바뀐다 업계 일반

  5. 위반 시 조치 : 크레딧 등 구제, 미리 합의한 축소 운영, 통보 대상을 적는다 업계 일반 [6.3①] [6.3②]

    error budget(허용 오류 예산)이 바닥나면 그 요청 종류만 미리 합의한 축소 운영(예 사람 경로)으로 보낸다. 그리고 담당자에게 바로 알린다. 전체를 끄거나 모델을 올려 버티지 않는다 업계 일반

    사람 경로도 재는 지표다. 에스컬레이션 정확도 95% 이상을 목표로 한다. 자세한 것은 ◆ 100% 약속 vs 측정된 SLO + 사람 안전망 에 있다

    위반 신호가 오면 누가 무엇을 하나(담당자 · 넘으면 이해관계자 검토로 올리는 선)는 ■ feedback loop 책임 표 에 있다

더 깊이 : 판단 규칙 · 상황 변수 (설명)

판단 규칙

조건답등급근거
조항에 선만 있고 어기면 무엇이 따르는지 없다구제 · 축소 운영 · 통보 대상을 적는다업계 일반Anthropic 문서에 SLA 조항 양식이 없다 (미해결 1)
선은 있는데 "오류" 의 뜻이 없다무엇을 오류로 세는지 정의한다define-success en-full "In reality, you would also define what "inconvenience" and "egregious" mean."
지연을 평균으로 걸었다분위수로 건다define-success en-full "95% response time < 200ms" (본편 ◆ 100% 약속 vs 측정된 SLO + 사람 안전망)
분위수인데 연휴·폭주 주간을 제외한다제외 조항을 뺀다. 피크를 포함한 기간으로 재고 선을 정한다업계 일반 (공식 근거은 확인)customer-support-chat-full "Claude can handle sudden increases in query volume" · rate-limits "Short bursts of requests can exceed the limit" · service-tiers "even during peak times"
배송 조회·환불을 한 분위수로 묶는다요청 종류별로 선을 둔다(복잡도에 따라 목표가 다름) · 해석(종류별 조항)customer-support-chat-full "depending on the complexity of inquiries" · "varies widely based on the complexity of issues"
선을 어디서 가져오나?업계 벤치마크 · 이전 실험 · AI 연구 · 전문가 지식에서 가져온다. 현재 모델 역량에 비춰 현실적으로 잡는다define-success en-full
지연 선을 정한다앱의 실시간 요구와 사용자 기대에 달렸다define-success en-full
누가 성공을 정의하나?제품 요구·사용자에 가장 가까운 사람이 정의한다demystifying-evals
품질 선을 잰다버전 고정 held-out 평가셋과 채점법으로 잰다. 평가셋은 실제 과제 분포를 닮게 만든다demystifying-evals · define-success en-full
품질을 현장 평점·매번 다른 표본으로 잰다약속 근거로는 약하다(운영 신호엔 채점할 정답 없음) · 업계 일반(분쟁 판단)demystifying-evals "Lacks ground truth for grading"
LLM 채점으로 품질을 잰다사람 정기 보정까지 한다demystifying-evals
error budget 이 바닥났다그 요청 종류만 미리 합의한 축소 운영으로 보낸다. 담당자에게 바로 알린다업계 일반—
사람 경로(에스컬레이션)도 약속에 들어간다에스컬레이션 정확도 95% 이상을 목표로 한다customer-support-chat-full

상황 변수

변수값답 쪽등급근거
측정 기간피크를 뺀 기간이다보고서만 준수가 된다. 제외 조항을 뺀다계산 · 업계 일반뒤집히는 때 1
제외 대상시간대다(연휴·프로모션)빼지 않는다업계 일반뒤집히는 때 2
제외 대상내가 통제 못 하는 원인이다(윗단(API) 장애 · 고객 쪽 시스템 장애)흔한 제외 형태다. 단 윗단 장애는 대비책과 같이 본다업계 일반 · 확인(Standard = best-effort)뒤집히는 때 2 · service-tiers
요청 종류복잡도가 크게 다르다종류별로 선을 둔다해석판단 규칙 5
요청 종류너무 잘게 쪼개 종류당 표본이 작다묶거나 기간을 늘린다계산 · 업계 일반뒤집히는 때 3
품질 지표고정 평가셋과 채점법이다약속 근거가 된다판단 규칙 9
품질 지표CSAT(만족도)다사업 지표로는 공식이다. 구제가 걸린 선으로는 약하다업계 일반뒤집히는 때 4
기다리는 사람없다(야간 일괄 처리)분위수 지연보다 "마감 안에 전부 완료" 로 건다(Batch 조건) · 업계 일반뒤집히는 때 5

연습 문제

쇼핑몰이 고객지원 Agent 의 SLA 초안을 받았다. "환불 문의 첫 답 p95 5초 이내 · 주 단위 · 연휴 폭주 주간은 측정에서 제외폭주 제외". 이 쇼핑몰은 반품·환불 문의의 40% 가 연휴 다음 주에 몰린다피크에 몰림. 영업은 "제외 조항이 있어야 SLA 준수로 나온다"고 한다. 조항에서 무엇을 먼저 고쳐야 하나?

시험 대비

함정

  • "월 평균 3초 이내" 는 함정이다. 분위수로 건다 (본편 ◆ 100% 약속 vs 측정된 SLO + 사람 안전망)
  • "연휴 폭주 주간은 측정 제외" 는 함정이다. 사용자가 서비스를 가장 필요로 하는 때를 빼면 보고서만 준수가 된다 업계 일반
  • 배송 조회·환불을 한 분위수로 묶는 것은 함정이다. 쉬운 요청이 어려운 요청을 가린다 (해석). 목표는 복잡도에 따라 다르다
  • 기준만 있고 위반 시 조치가 없는 것은 함정이다. 분쟁 때 아무도 답을 못 한다 업계 일반
  • "파일럿에서 제일 좋던 주의 값을 선으로" 는 함정이다. 그 값은 출처가 아니다 업계 일반. 공식 출처는 4가지다
  • "품질 = 현장 평점 · 매주 새 표본을 즉석 채점" 은 함정이다. 재현되지 않는다 업계 일반. 운영 모니터링에는 채점할 정답이 없다
  • "위반이면 모델을 한 단계 올려 버틴다 · 전체를 끈다" 는 함정이다. 그 요청 종류만 미리 합의한 축소 운영으로 보낸다 업계 일반
  • 반대쪽 함정도 있다. "업계 벤치마크는 출처가 못 된다" 는 함정이다. 내 분포로 재 보는 것은 덧붙임이다 업계 일반. 업계 벤치마크는 공식 출처 목록에 있다

신호

"Operational: Response time (ms), uptime (%)"

"What is the acceptable response time for the model? This depends on your application's real-time requirements and user expectations."

"Achievable: Base your targets on industry benchmarks, prior experiments, AI research, or expert knowledge."

"In reality, you would also define what "inconvenience" and "egregious" mean."

"Design evals that mirror your real-world task distribution."

"Fully reproducible" (자동 eval 의 장점)

"latency, token usage, cost per task, and error rates can be tracked on a static bank of tasks."

"The people closest to product requirements and users are best positioned to define success."

"Claude can handle sudden increases in query volume without the need for hiring and training additional staff."

"Typically aim for 70-80% deflection rate, depending on the complexity of inquiries."

"Short bursts of requests can exceed the limit and trigger rate limit errors."

"Manage stakeholder feedback loops and expectation alignment (including SLAs)" (가이드 목표 6.3)

SLA 는 보통 종류별 분위수로 폭주 주간까지 재지만, 통제 밖 원인은 뺄 수 있고, 표본이 작은 종류는 묶으며, 기다리는 사람이 없으면 완료 시각으로 건다.
그림으로 보기 (AI 생성 · Codex · 누르면 크게) — 자세한 조건은 아래 '더 깊이'에 있어요
더 깊이 : 뒤집히는 때 · 오답 재료 (설명)

뒤집히는 때

1. 폭주 주간을 빼면 판정이 통째로 뒤집힘

  • 조건 : 월 단위로 모아 재는 조항이다. 한 달 환불 문의 5만 건 중 2만 건(40%)이 연휴 다음 주에 온다. 선은 첫 답 5초다. p95 ≤ 5초는 요청의 95% 가 5초 안에 답한다는 뜻이다. 5초를 넘는 요청이 5% 를 넘으면 위반이다.
  • 가정 : 연휴 주 요청의 20% 가 5초를 넘고, 나머지 주는 3% 만 넘는다고 본다 (그림용 가정이다. 측정값이 아니다).
  • 계산 : 전체 초과는 2만 × 0.20 + 3만 × 0.03 = 4,000 + 900 = 4,900건이다. 이것은 9.8% 로 5% 보다 많다. 그래서 월 p95 가 5초를 넘는다. 위반이다. 연휴 주를 빼면 3% 다. 그러면 p95 가 5초 안이다. 준수다.
  • 뜻 : 같은 서비스, 같은 달인데 제외 조항 한 줄로 위반이 준수로 바뀐다. 고객이 가장 많이 겪은 주가 통째로 빠진다.
  • 등급 : 계산 (비율은 가정)

2. 제외 조항이 맞는 때 — "그 시간대" 가 아니라 "그 원인"

  • 조건 : 제외 대상이 내가 통제 못 하는 원인이다(윗단 API 장애 · 고객 쪽 시스템 장애).
  • 판단 : 원인 제외는 흔한 형태다 (업계 일반). 단 윗단 장애를 빼든 넣든 먼저 윗단이 무엇을 약속하는지 본다. Standard 티어는 best-effort 가용성이다 (공식). 대비책(재시도 · 대체 경로) 없이 넣으면 지키지 못한다. 빼면 고객이 떠안는다. 자세한 것은 ◆ 100% 약속 vs 측정된 SLO + 사람 안전망 의 "뒤집히는 때 3" 에 있다.
  • 가르는 말 : 빼는 것이 "사용자가 서비스를 가장 필요로 하는 시간대" 인가, "내 통제 밖 원인" 인가?
  • 등급 : 업계 일반 (best-effort 는 확인)
  • 근거 : service-tiers

3. 요청 종류를 너무 잘게 쪼갤 때

  • 조건 : 종류를 12개로 쪼갰더니 "부분 환불 + 해외 배송" 종류는 주 60건이다.
  • 계산 : p95 는 느린 쪽 5%(= 3건)가 정한다. 한두 건만 느려져도 분위수가 크게 흔들린다. p99 면 0.6건이다. 그러면 사실상 최댓값을 약속하는 셈이다.
  • 처방 : 표본이 작은 종류는 묶거나 기간을 주에서 월로 늘린다 (업계 일반).
  • 등급 : 계산 · 업계 일반

4. 품질 선에 CSAT 를 쓰고 싶을 때

  • 조건 : 고객사가 "만족도 4점 이상" 을 품질 SLA 로 원한다.
  • 판단 : 공식 고객지원 가이드는 CSAT 4/5 이상을 사업 영향 지표로 든다. 그래서 추적은 맞다. 다만 설문 응답자·표본이 매번 달라 누가 다시 재도 같은 숫자가 안 나온다. 그래서 구제가 걸린 선은 고정 평가셋 쪽에 둔다. CSAT 는 함께 보고하는 지표로 둔다 (업계 일반).
  • 등급 : (CSAT 는 공식 사업 지표) · 업계 일반(약속 근거로는 약하다)
  • 근거 : customer-support-chat-full

5. 평균·마감이 맞는 조항 — 기다리는 사람이 없을 때

  • 조건 : 조항 대상이 야간 일괄 요약처럼 사람이 화면 앞에서 기다리지 않는 일이다. 또는 월 비용이다.
  • 판단 : 분위수 지연보다 "몇 시까지 전부 완료" 가 맞는 모양이다. 공식 Batch 는 24시간까지 기다릴 수 있는 일에 50% 할인한다. 자세한 것은 ◆ Batch API vs 동기 호출 에 있다. 비용 조항은 월 합계가 자연스럽다 (업계 일반).
  • 등급 : (Batch 조건) · 업계 일반
  • 근거 : optimizing-cost-intelligence

오답 재료

오답왜 끌리나왜 틀리나등급근거
"연휴 폭주 주간은 측정에서 제외해야 SLA 준수로 나온다"숫자가 안정돼 보인다사용자가 서비스를 가장 필요로 하는 때를 지표에서 지운다. 성수기 급증 처리가 도입 이유 자체다업계 일반 · 확인(도입 이유)customer-support-chat-full · 뒤집히는 때 1
"월 평균 응답 3초"평균이 익숙하다공식 예는 분위수다define-success en-full
"지연 p95 는 전체 요청 한 줄로"조항이 짧아진다쉬운 요청이 어려운 요청을 가린다(복잡도별 목표) · 해석customer-support-chat-full
"선만 적으면 충분 — 위반 뒤는 그때 협상"계약이 빨리 끝난다분쟁 때 아무도 답을 못 한다업계 일반—
"파일럿에서 제일 좋던 주 값을 선으로"달성한 적이 있는 숫자다대표 값이 아니다. 공식 출처는 벤치마크 · 이전 실험 · 연구 · 전문가 지식이다(출처 목록) · 업계 일반(최고 주 반박)define-success en-full
"업계 벤치마크는 우리 서비스와 달라 출처가 못 된다" (반대)신중해 보인다공식 출처 목록에 있다. 내 분포로 한 번 재 보면 된다업계 일반define-success en-full
"품질 = 매주 새 표본을 LLM 이 즉석 채점"자동이고 최신이다표본이 매번 달라 재현되지 않는다. LLM 채점은 사람 보정까지 해야 한다(보정) · 업계 일반(재현성)demystifying-evals
"error budget 을 다 쓰면 모델을 한 단계 올려 버틴다 · 서비스 전체를 끈다"품질을 지키는 것 같다미리 합의한 축소 운영을 그 요청 종류에만 쓴다업계 일반—
"'빠르고 정확함' 을 조항으로"부드럽고 무난하다숫자 없는 말이다. 재는 것이 아니다define-success en-full (■ 성공 기준)

참고

더 깊이 : 출처 · 상태 · 미해결 (참고)

출처

상태

  • 업계 일반 11줄(조항 세 부분 · 분쟁 · 피크 제외 함정 · 기준선 순서 · 그럴싸한 숫자 · 내 분포로 재기 · 현장 평점 · 평가셋 버전 · 구제 · error budget·축소 운영 · 한 줄로)
  • 해석 4곳(SLA 로 넓힘 · 피크에서 재라 · 종류별 조항 · 종류 섞임 함정)

미해결

  1. SLA 조항 양식(재는 것 · 선 · 구제), 서비스 크레딧, error budget, 축소 운영은 Anthropic 공식 문장이 없다. 그래서 카드에서는 업계 일반으로 둔다. 검색 대상은 ccarp/raw/official-docs/en-*.md 이다(제외 = ko 판 · 받지 않은 문서). 검색어는 percentile · p95 · p99 · tail latency · error budget · service credit · SLA 다. 무관한 예만 나왔다.
    • advanced-tool-use sla_hours 예시
    • optimizing-cost-intelligence 90th-percentile 토큰 예산
  2. "피크를 포함해 재라" 는 공식 문장이 없다. 가까운 것은 성수기 급증(customer-support-chat-full) · 짧은 폭주(rate-limits) · Priority Tier "even during peak times"(service-tiers)다. 그래서 카드는 "넓힌 것은 해석이다" 로 표기했다. 검색어는 peak · surge · sudden 이다.
  3. 요청 종류별 조항에 대해 공식 문서는 목표·처리 시간이 복잡도에 따라 달라진다는 것까지만 말한다. 검색어 query class · per category 는 0건이다.
  4. 후보 절 규칙 3 의 "다른 배포에서 빌린 값은 출처가 아니다" 는 공식과 어긋난다. 공식은 업계 벤치마크를 목표 근거로 든다(define-success en-full). 카드는 "업계 벤치마크도 공식 출처, 내 분포로 재 보는 건 덧붙임" 으로 고쳤다.
  5. 후보 절 규칙 4 에 "즉석 LLM judge 는 아님" 이 있다. 공식은 LLM 채점과 사람 정기 보정 조합을 인정한다(demystifying-evals). 그래서 카드는 "LLM 채점이면 보정까지" 로 고쳤다. "재현 가능 = 제3자가" 에 대해 공식은 "Fully reproducible"(자동 eval 장점)까지만 말한다. 제3자·분쟁 문맥은 업계 일반이다.
  6. Priority Tier 99.5% 는 "목표(targets)" 다. 보상 조건 같은 계약 세부는 받은 문서에 없다 (◆ 100% 약속 vs 측정된 SLO + 사람 안전망 미해결 4 와 같다).