# 2026년 SRE 원칙: 신뢰성 엔지니어링, SLO와 면접 질문

> SRE 원칙을 실무 관점에서 정리합니다. SLI 선택, SLO와 에러 버짓 계산, Prometheus 번 레이트 알림, 에러 버짓 정책, 그리고 자주 나오는 SRE 면접 질문과 예상 답변까지 다룹니다.

- Published: 2026-11-07
- Updated: 2026-11-07
- Author: Anthony Fillion-Maillet
- Tags: devops, sre, slo, error-budget, prometheus, observability
- Reading time: 13 min

---

SRE 원칙은 "안정성을 높인다"는 막연한 목표를 개발 조직과 프로덕트 조직이 함께 합의할 수 있는 숫자로 바꾸고, 그 숫자를 근거로 배포를 계속할지 멈출지를 결정하는 방법론입니다. Google이 정립한 사이트 신뢰성 엔지니어링(Site Reliability Engineering)은 이제 대부분의 플랫폼 팀에서 실천되고 있으며, 그 핵심은 몇 가지 개념으로 정리됩니다. 사용자가 실제로 겪는 품질을 측정하고(SLI), 100%보다 낮은 목표를 정하고(SLO), 그 차이를 에러 버짓으로 사용하며, 시스템을 유지하기 위한 수작업에 상한을 두는 것입니다. 2026년 SRE 면접 질문도 바로 이 개념들을 검증하며, 보통 실제 서비스에 대한 SLO를 정의하고 이를 지키기 위한 알림 규칙을 작성하게 하는 방식으로 진행됩니다.

> **SLI, SLO, SLA를 한 문장씩**
>
> SLI는 측정값으로, 성공한 요청 수를 전체 요청 수로 나눈 것처럼 좋은 이벤트와 유효한 이벤트의 비율로 표현합니다. SLO는 그 비율에 대한 내부 목표로, "30일 동안 99.9%"처럼 기간과 함께 정합니다. SLA는 고객과 맺는 계약상의 약속으로 위약 조건이 따르며, 항상 SLO보다 느슨하게 설정됩니다.

## 사이트 신뢰성 엔지니어링을 떠받치는 핵심 SRE 원칙

[Google SRE 북](https://sre.google/sre-book/service-level-objectives/)은 안정성을 비용이 드는 하나의 기능으로 바라봅니다. 9를 하나 더 붙일 때마다 엔지니어링 시간이 늘고 배포 속도는 느려집니다. 반면 사용자의 네트워크, 기기, 통신사는 그보다 불안정하기 때문에 사용자는 99.99%와 99.999%의 차이를 거의 체감하지 못합니다. 목표는 최대한의 안정성이 아니라 적정한 수준의 안정성입니다.

이 출발점에서 몇 가지 원칙이 도출됩니다.

- **안정성은 사용자 관점에서 측정합니다.** CPU 사용률이나 파드 재시작은 원인에 불과합니다. 사용자가 경험하는 것은 결제 실패와 느린 페이지 로딩이며, SLI가 포착해야 하는 것도 바로 이것입니다.
- **100%는 잘못된 목표입니다.** 모든 배포에는 위험이 따르므로 100% SLO는 모든 변경을 금지하는 것과 같습니다. 100%와의 차이가 에러 버짓이며, 이는 배포, 실험, 마이그레이션에 쓰라고 존재하는 것입니다.
- **토일(toil)에는 상한을 둡니다.** Google은 [토일 제거 챕터](https://sre.google/sre-book/eliminating-toil/)에서 운영 업무를 SRE 근무 시간의 50% 미만으로 유지하라는 가이드라인을 제시합니다. 토일은 수작업이고, 반복적이며, 자동화가 가능하고, 서비스 규모에 비례해 늘어나는 작업입니다. 나머지 시간은 그 토일을 없애는 엔지니어링에 투입합니다.
- **포스트모템은 비난하지 않습니다(블레임리스).** 장애 리뷰에서 묻는 것은 누가 명령어를 입력했는가가 아니라 시스템의 어떤 부분이 장애를 허용했는가입니다. 비난받는 엔지니어는 정보를 숨기고, 비난 없는 리뷰는 정보를 끌어냅니다.
- **모니터링은 증상에 대해 알림을 보냅니다.** 페이지(호출)는 사용자가 피해를 입고 있거나 곧 입을 상황에서 발생해야 하며, 단일 노드가 평소와 다르게 보인다는 이유만으로 발생해서는 안 됩니다.

면접에서 실무 경험이 있는 SRE와 책만 읽은 지원자를 가르는 것은 두 번째 원칙입니다. 주니어 수준의 답변은 에러 버짓을 장애에 대한 허용치로 설명합니다. 시니어 수준의 답변은 이를 릴리스 관리 도구로 설명합니다. 즉, 프로덕트와 안정성 사이의 논쟁을 의견이 아닌 데이터로 진행하게 해 주는 장치라는 점을 짚어 낼 수 있어야 합니다.

## 사용자 경험을 반영하는 SLI 선택

좋은 SLI는 0과 1 사이의 비율이며, 사용자가 인지할 수 있는 이벤트로부터 계산됩니다. [SRE 워크북](https://sre.google/workbook/implementing-slos/)은 서비스 유형별로 다음과 같은 후보를 제시합니다.

| 서비스 유형 | 대표적인 SLI | 측정 위치 |
|---|---|---|
| 요청 기반 API | 가용성, 지연 시간 | 로드 밸런서 또는 인그레스 로그, 서버 메트릭 |
| 데이터 파이프라인 | 신선도, 정확성, 커버리지 | 파이프라인 출력 타임스탬프, 검증 작업 |
| 스토리지 시스템 | 내구성, 읽기 및 쓰기 지연 시간 | 스토리지 계층, 합성 프로브 |
| 프런트엔드 | 페이지 로딩 시간, 브라우저에서 관측된 에러율 | 실사용자 모니터링(RUM) |

로드 밸런서에서 측정하면 크래시된 파드가 아무 응답도 하지 않는 경우처럼 애플리케이션이 스스로 인지하지 못하는 장애까지 잡아낼 수 있습니다. 브라우저에서 측정하면 CDN과 DNS 문제까지 포착할 수 있지만, 불안정한 모바일 연결로 인한 노이즈가 섞입니다. 대부분의 팀은 이미 데이터가 쌓여 있는 로드 밸런서나 인그레스에서 시작합니다.

Prometheus를 사용할 경우 HTTP 서비스의 대표적인 SLI는 가용성 비율과 지연 시간 비율 두 가지입니다. 지연 시간 SLI는 임계값보다 빠른 요청을 좋은 이벤트로 집계하므로, 백분위수가 아닌 다른 SLI와 동일한 비율 형태가 됩니다.

```promql
# checkout-sli.promql
# Availability SLI: share of requests that did not fail with a 5xx
sum(rate(http_requests_total{job="checkout-api", code!~"5.."}[5m]))
/
sum(rate(http_requests_total{job="checkout-api"}[5m]))

# Latency SLI: share of requests served in under 300 ms
# Uses the histogram bucket with le="0.3", so 0.3 must be a configured bucket boundary
sum(rate(http_request_duration_seconds_bucket{job="checkout-api", le="0.3"}[5m]))
/
sum(rate(http_request_duration_seconds_count{job="checkout-api"}[5m]))
```

면접에서는 두 가지 세부 사항이 자주 등장합니다. 첫째, 4xx 응답은 일반적으로 유효하면서 좋은 이벤트로 분류합니다. 404나 유효성 검사 오류는 클라이언트의 실수이므로, 이를 실패로 집계하면 오작동하는 클라이언트 하나가 버짓을 모두 소진할 수 있습니다. 둘째, 지연 시간 임계값은 히스토그램 버킷 경계와 일치해야 합니다. 그렇지 않으면 쿼리가 아무것도 반환하지 않거나 엉뚱한 버킷을 조용히 사용하게 됩니다. 최신 Prometheus는 네이티브 히스토그램을 지원해 고정 버킷의 제약을 없애 주지만, 스크레이프 측에서 별도로 활성화해야 합니다.

## SLO 목표 설정과 에러 버짓 계산

SLO는 SLI, 목표값, 기간으로 구성됩니다. 기간은 보통 28일 또는 30일의 롤링 윈도우를 사용하며, 매월 1일에 초기화되는 대신 버짓이 점진적으로 회복됩니다. 목표값은 과거 실적과 사용자 기대치를 바탕으로 정해야 하며, 발표 자료에서 그럴듯해 보이는 숫자로 정해서는 안 됩니다.

아래 표는 30일 윈도우에서 각 목표값이 허용하는 범위를 보여 줍니다. 계산은 단순하며, 버짓은 `(1 - SLO) × 30일`입니다.

| SLO 목표 | 에러 버짓 | 30일 동안 허용되는 전체 중단 시간 |
|---|---|---|
| 99% | 1% | 7시간 12분 |
| 99.5% | 0.5% | 3시간 36분 |
| 99.9% | 0.1% | 43분 12초 |
| 99.95% | 0.05% | 21분 36초 |
| 99.99% | 0.01% | 4분 19초 |

요청 기반 SLO에서는 버짓을 시간이 아닌 요청 수로 표현합니다. 99.9% 목표에 윈도우 내 요청이 1,200만 건이라면 실패가 허용되는 요청은 12,000건입니다. 트래픽 편차가 큰 서비스에서는 요청 기반 버짓이 더 공정합니다. 새벽 3시의 장애는 같은 길이의 피크 시간 장애보다 버짓을 적게 소모하기 때문입니다.

면접에서 흔히 출제되는 과제는 남은 버짓과 소진 속도를 계산하는 것입니다. 코드로 답하라는 요구가 있을 때 기대되는 답변은 다음과 같은 스크립트입니다.

```python
# error_budget.py
from dataclasses import dataclass

@dataclass
class SloWindow:
    objective: float      # 0.999 for a 99.9% SLO
    window_days: int      # rolling window, usually 28 or 30
    total_requests: int   # valid events seen in the window so far
    failed_requests: int  # bad events seen in the window so far

    @property
    def budget_fraction(self) -> float:
        return 1 - self.objective  # 0.001 for 99.9%

    def budget_remaining(self) -> float:
        """1.0 means untouched, 0 means spent, negative means SLO breached."""
        allowed_failures = self.budget_fraction * self.total_requests
        return 1 - self.failed_requests / allowed_failures

    def burn_rate(self, recent_errors: int, recent_total: int) -> float:
        """1.0 means the budget lasts exactly the window; 10 means ten times too fast."""
        return (recent_errors / recent_total) / self.budget_fraction

    def hours_to_exhaustion(self, burn: float) -> float:
        # Remaining share of budget, consumed at `burn` times the sustainable pace
        return self.budget_remaining() * self.window_days * 24 / burn

slo = SloWindow(objective=0.999, window_days=30, total_requests=12_000_000, failed_requests=7_800)
burn = slo.burn_rate(recent_errors=240, recent_total=16_000)
print(f"budget left: {slo.budget_remaining():.0%}")             # 35%
print(f"burn rate: {burn:.1f}")                                 # 15.0
print(f"exhausted in: {slo.hours_to_exhaustion(burn):.1f} h")   # 16.8 h
```

번 레이트 15는 SLO가 0.1%의 실패만 허용하는데 실제로는 요청의 1.5%가 실패하고 있다는 뜻입니다. 이 속도라면 남은 35%의 버짓은 17시간 안에 바닥나므로, 한밤중에 담당자를 호출할 충분한 근거가 됩니다.

## 다중 윈도우 기반 번 레이트 알림

SLI에 직접 알림을 거는 방식("에러율이 0.1%를 넘으면 알림")은 짧은 스파이크마다 페이지를 보내면서도 서서히 진행되는 성능 저하는 놓칩니다. [SRE 워크북의 SLO 기반 알림 챕터](https://sre.google/workbook/alerting-on-slos/)가 권장하는 것은 다중 윈도우, 다중 번 레이트 알림입니다. 각 알림은 하나의 질문에 답합니다. 누군가 확인하기 전에 버짓이 바닥날 만큼 빠르게 소진되고 있는가 하는 질문입니다.

30일 윈도우 기준의 참고 임계값은 다음과 같습니다.

| 심각도 | 긴 윈도우 | 짧은 윈도우 | 번 레이트 | 알림 발생 시점의 버짓 소진량 |
|---|---|---|---|---|
| 페이지 | 1시간 | 5분 | 14.4 | 2% |
| 페이지 | 6시간 | 30분 | 6 | 5% |
| 티켓 | 3일 | 6시간 | 1 | 10% |

긴 윈도우는 유의성을 확보해 주므로, 1분 동안의 이상만으로는 페이지가 발생하지 않습니다. 긴 윈도우의 12분의 1 길이인 짧은 윈도우는 장애가 끝난 뒤 알림이 빠르게 해제되도록 해, 수정 이후에도 한 시간 동안 페이지가 계속 울리는 상황을 막아 줍니다. 두 조건이 동시에 참이어야 알림이 발생합니다.

첫 번째 블록은 알림 표현식을 가볍게 유지하기 위해 각 윈도우의 에러 비율을 레코딩 규칙으로 기록합니다. 두 번째 블록은 버짓 비율이 0.001인 99.9% SLO에 대해 두 개의 페이지 알림을 정의합니다.

```yaml
# checkout-slo-recording.rules.yml
groups:
  - name: checkout-slo-recording
    interval: 30s
    rules:
      - record: slo:sli_error:ratio_rate5m
        expr: |
          sum(rate(http_requests_total{job="checkout-api", code=~"5.."}[5m]))
          / sum(rate(http_requests_total{job="checkout-api"}[5m]))
      - record: slo:sli_error:ratio_rate1h
        expr: |
          sum(rate(http_requests_total{job="checkout-api", code=~"5.."}[1h]))
          / sum(rate(http_requests_total{job="checkout-api"}[1h]))
      # Same pattern for 30m and 6h, omitted for brevity
```

```yaml
# checkout-slo-alerts.rules.yml
groups:
  - name: checkout-slo-alerts
    rules:
      - alert: CheckoutErrorBudgetFastBurn
        # 2% of the monthly budget spent in one hour
        expr: |
          slo:sli_error:ratio_rate1h > (14.4 * 0.001)
          and slo:sli_error:ratio_rate5m > (14.4 * 0.001)
        labels:
          severity: page
        annotations:
          summary: "checkout-api burns its error budget 14x too fast"
      - alert: CheckoutErrorBudgetSlowBurn
        # 5% of the monthly budget spent in six hours
        expr: |
          slo:sli_error:ratio_rate6h > (6 * 0.001)
          and slo:sli_error:ratio_rate30m > (6 * 0.001)
        labels:
          severity: page
```

서비스마다 이런 규칙을 직접 작성하다 보면 반복 작업이 늘어납니다. 오픈소스 SLO 생성기인 [Sloth](https://github.com/slok/sloth)는 짧은 명세 파일을 받아 위와 같은 레코딩 규칙과 다중 번 레이트 알림을 생성합니다. `{{.window}}` 플레이스홀더는 Sloth가 필요로 하는 각 윈도우 값으로 치환됩니다.

```yaml
# checkout-slo.sloth.yml
version: "prometheus/v1"
service: "checkout-api"
labels:
  owner: "payments-team"
slos:
  - name: "requests-availability"
    objective: 99.9
    description: "Checkout requests that do not fail with a 5xx"
    sli:
      events:
        error_query: sum(rate(http_requests_total{job="checkout-api",code=~"5.."}[{{.window}}]))
        total_query: sum(rate(http_requests_total{job="checkout-api"}[{{.window}}]))
    alerting:
      name: CheckoutHighErrorRate
      page_alert:
        labels:
          severity: page
      ticket_alert:
        labels:
          severity: ticket
```

특정 벤더에 종속되지 않는 형식을 원하는 팀은 모니터링 백엔드와 무관하게 SLO를 YAML로 기술하는 [OpenSLO 명세](https://github.com/OpenSLO/OpenSLO)도 검토합니다.

## 에러 버짓 정책과 릴리스 의사결정

정책이 없는 에러 버짓은 아무도 행동으로 옮기지 않는 대시보드일 뿐입니다. SRE 워크북의 [에러 버짓 정책 예시](https://sre.google/workbook/error-budget-policy/)는 버짓이 소진되었을 때 무슨 일이 일어나는지, 그리고 누가 이를 사전에 승인했는지를 명문화합니다.

일반적인 정책에는 다음 항목이 포함됩니다.

- **발동 조건.** 롤링 윈도우 동안 서비스가 에러 버짓을 초과한 경우입니다.
- **조치.** 서비스가 SLO 범위로 돌아올 때까지 보안 패치와 안정성 개선 변경을 제외한 기능 릴리스를 중단합니다.
- **예외 절차.** 팀이 통제할 수 없는 외부 의존성 장애로 인한 단발성 사고는 판단 근거를 문서화한 뒤 제외할 수 있습니다.
- **에스컬레이션.** 이견이 생기면 목소리가 큰 사람이 아니라 CTO처럼 사전에 지정된 역할이 결정합니다.

이 정책은 첫 번째 초과가 발생하기 전에 프로덕트와 엔지니어링 양측이 서명해 두는 것이 핵심입니다. 그래야 릴리스 동결이 장애 상황에서의 다툼이 아니라 미리 합의된 규칙이 됩니다. 면접관은 버짓이 늘 거의 소진되지 않는다면 어떻게 하겠느냐고 자주 묻습니다. 기대되는 답변은 SLO가 너무 느슨하거나 팀이 지나치게 조심스럽게 배포하고 있을 가능성이 있으며, 그 버짓을 더 빠른 릴리스나 위험도 높은 마이그레이션에 써야 한다는 것입니다.

> **면접에서 빠지기 쉬운 SLA 함정**
>
> 내부 SLO를 고객 SLA와 같은 값으로 설정하면 여유가 전혀 남지 않습니다. SLO를 처음 위반하는 순간 이미 계약상 위약금이 발생하기 때문입니다. SLO는 SLA보다 엄격해야 하며, 그래야 계약이 아직 지켜지고 있는 시점에 알림이 발생하고 동결이 시작됩니다.

## 토일 감소, 온콜, 블레임리스 포스트모템

SRE의 업무 시간은 운영과 엔지니어링으로 나뉩니다. 운영에는 온콜, 티켓 처리, 수동 개입이 포함되고, 엔지니어링에는 자동화, 용량 계획, 안정성 관련 기능 개발이 포함됩니다. 토일이 50% 가이드라인을 넘어서면 SRE 팀은 업무를 개발 팀으로 되돌리거나 자동화에 투자합니다. 그렇지 않으면 SRE 팀은 이름만 바뀐 운영 팀이 되어 버립니다.

온콜의 건전성은 짐작이 아니라 측정으로 판단합니다. 유용한 지표로는 근무 교대당 페이지 수, 실제 조치가 필요했던 페이지의 비율, 확인(ack)까지 걸린 시간이 있습니다. 아무 조치도 필요 없었던 페이지는 알림 설정의 버그이므로 수정하거나 삭제합니다. 앞서 살펴본 규칙처럼 SLO 번 레이트에 기반한 증상 중심 알림은 CPU, 메모리, 개별 파드 재시작에 대한 알림에 비해 페이지 양을 크게 줄여 줍니다.

장애가 발생한 뒤의 리뷰 과정은 SRE 북의 [포스트모템 문화 챕터](https://sre.google/sre-book/postmortem-culture/)에 자세히 설명되어 있습니다. 포스트모템에는 SLO 관점의 영향(버짓을 얼마나 소진했는지), 타임라인, 기여 요인, 담당자와 기한이 지정된 액션 아이템을 기록합니다. 특정 개인을 원인으로 지목하지 않습니다. 면접에서는 두 가지 후속 질문이 자주 나옵니다. 하나는 액션 아이템이 실제로 완료되도록 하는 방법입니다(기능 개발과 같은 백로그에서 관리하고 정기 회의에서 점검합니다). 다른 하나는 포스트모템이 필수인 경우입니다(버짓의 상당 부분을 소진한 장애, 누군가를 잠에서 깨운 페이지, 데이터 손실이 발생한 모든 경우).

SRE 북에서 소개하는 네 가지 골든 시그널, 즉 지연 시간, 트래픽, 에러, 포화도가 모니터링의 전체 그림을 완성합니다. 지연 시간과 에러는 보통 SLI가 되고, 트래픽과 포화도는 페이지보다는 용량 계획과 대시보드에 활용됩니다.

## 예상 답변과 함께 보는 SRE 면접 질문

SRE 및 시니어 DevOps 채용 과정에서 반복적으로 등장하는 질문과, 좋은 평가를 받는 답변의 핵심을 정리합니다. [SRE 원칙 면접 모듈](/technologies/devops/interview-questions/sre-principles)에서 같은 주제를 집중적으로 연습할 수 있으며, 온콜 관련 내용은 [알림 및 장애 대응 모듈](/technologies/devops/interview-questions/alerting-incident-response)에서 다룹니다.

**Q: SLI, SLO, SLA의 차이는 무엇입니까?**

SLI는 측정된 비율이고, SLO는 일정 기간에 대한 내부 목표이며, SLA는 위약 조건이 붙은 외부 계약입니다. 금전적 손실이 발생하기 전에 팀이 대응할 수 있도록 SLO는 SLA보다 엄격하게 설정합니다.

**Q: 왜 SLO를 100%로 정하지 않습니까?**

모든 변경에는 위험이 따르므로 100% 목표는 배포 자체를 금지하는 셈이기 때문입니다. 또한 사용자는 자신의 네트워크보다 높은 수준의 안정성을 체감할 수 없습니다. 100%와의 차이가 에러 버짓이며, 이것이 릴리스의 재원이 됩니다.

**Q: 결제 API의 SLO를 정의해 보십시오.**

좋은 답변은 두 가지 SLI(4xx를 제외한 가용성, 로드 밸런서에서 측정한 임계값 이하의 지연 시간), 30일 롤링 윈도우, 직전 분기 데이터에 근거한 목표값을 고르고, 여기서 알림 규칙과 에러 버짓 정책이 어떻게 이어지는지까지 설명합니다. 무엇을 측정하는지 언급하지 않고 "가동률 99.99%"라고만 답하는 것은 전형적인 약한 답변입니다.

**Q: p99 지연 시간 백분위수에 대한 알림이 SLO 알림으로 부적절한 이유는 무엇입니까?**

짧은 윈도우에서의 p99는 노이즈가 많고 인스턴스 간에 합산할 수도 없습니다. 지연 시간을 임계값 이하 요청의 비율로 바꾸면 합산이 가능해지고, 가용성 SLI와 비교할 수 있으며, 번 레이트 알림에도 그대로 적용할 수 있습니다.

**Q: 번 레이트가 무엇이며, 왜 알림에 두 개의 윈도우를 사용하는지 설명해 주십시오.**

번 레이트는 관측된 에러 비율을 버짓 비율로 나눈 값입니다. 1이면 버짓이 정확히 윈도우 기간 동안 소진됩니다. 긴 윈도우는 짧은 스파이크를 걸러 내고, 짧은 윈도우는 복구 후 알림이 빠르게 해제되도록 합니다.

**Q: 토일이란 무엇이며, 어떻게 통제합니까?**

수작업이고 반복적이며 자동화가 가능하고, 지속적인 가치를 남기지 않으면서 서비스 규모에 비례해 늘어나는 작업입니다. 이를 측정하고 상한을 정하며(Google은 50%), 자동화하거나 해당 서비스를 소유한 팀으로 업무를 되돌려 줄여 나갑니다.

**Q: 포스트모템을 블레임리스하게 만드는 요소는 무엇입니까?**

장애를 허용한 시스템 조건에 초점을 맞추고, 관련자들이 당시 가진 정보 안에서 합리적으로 행동했다고 전제하며, 추적 가능한 액션 아이템을 도출하는 것입니다. 판단 기준은 해당 엔지니어가 두려움 없이 모든 세부 사항을 공유할 수 있는가입니다.

같은 면접에서 SLO 질문 다음에 모니터링 질문이 이어지는 경우도 많습니다. [Prometheus 면접 질문 가이드](/blog/devops/prometheus-vs-grafana-vs-datadog-monitoring-devops-interview)는 PromQL, 메트릭 유형, 카디널리티를 다루며, 더 폭넓은 준비를 위해서는 [DevOps 기술 페이지](/technologies/devops)에 정리된 모든 모듈을 활용할 수 있습니다.

## 실무에서의 SLO와 에러 버짓: 꼭 기억할 점

- 각 SLI는 좋은 이벤트와 유효한 이벤트의 비율로 정의하고, 데이터가 허락하는 한 사용자에 가까운 지점에서 측정하며, 대부분의 API에서는 4xx를 실패에서 제외합니다
- SLO는 과거 데이터와 28일 또는 30일 롤링 윈도우를 바탕으로 정하고, 어떤 고객 SLA보다도 엄격하게 유지합니다
- 목표값을 분 단위 또는 요청 수 단위의 버짓으로 환산하고, 주요 수치를 암기해 둡니다. 30일 기준 99.9%는 43분입니다
- 원시 에러율이나 CPU가 아니라 짝을 이룬 윈도우(1시간과 5분에서 14.4, 6시간과 30분에서 6)를 사용한 번 레이트로 알림을 보냅니다
- SLO를 가진 서비스가 몇 개를 넘어서면 Sloth 같은 도구로 규칙을 생성해 임계값의 일관성을 유지합니다
- 첫 번째 초과가 발생하기 전에 동결 규칙과 에스컬레이션 경로를 포함한 에러 버짓 정책을 작성하고 서명해 둡니다
- 토일, 페이지 양, 포스트모템 액션 아이템을 기능 개발과 같은 수준의 엄격함으로 추적합니다

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/ko/blog/devops/sre-principles-2026-slos-error-budgets-interview-questions