TIL - 20260922

juni·2026년 9월 22일

목록 보기

460/468

0922 운영 자동화/AI 워크플로우 심화 (16/N): SLI·SLO, Error Budget과 운영 품질 기준 만들기

✅ 1. 모니터링을 해도 ‘정상 기준’이 없으면 판단하기 어렵다

0921에서 다음 같은 지표를 본다고 했다.

API Error Rate

Queue Pending

Oldest Job Age

UNKNOWN Job

DLQ

알림톡 실패율

Webhook 실패율

그런데 숫자만 있다고 운영 기준이 생기는 것은 아니다.

예를 들어:

API 실패율 0.7%

이 숫자가

정상인지

조금 나쁜 것인지

즉시 대응해야 하는 장애인지

판단하려면 기준이 필요하다.

마찬가지로:

Queue Oldest Job Age = 40초

도 업무에 따라 전혀 의미가 다르다.

실시간 알림톡이라면 40초가 길 수 있지만,

야간 통계 집계 Job이라면 아무 문제가 아닐 수 있다.

결국 운영 시스템에는

무엇을 측정할 것인가와 함께, 어느 수준까지 허용할 것인가

가 필요하다.

✅ 2. SLI란?

SLI는 Service Level Indicator다.

쉽게 말하면:

서비스 상태를 실제로 측정하는 지표

다.

예:

주문 API 성공률

주문 API 응답 속도

알림톡 처리 성공률

Webhook 처리 지연 시간

Export 완료 성공률

즉 SLI는 실제 측정값이다.

예를 들어:

지난 7일 주문 생성 성공률

99.94%

라면 이 99.94%가 SLI 결과다.

✅ 3. SLO란?

SLO는 Service Level Objective다.

즉:

우리가 목표로 하는 서비스 품질 수준

이다.

예:

주문 생성 API

SLI
실제 성공률

SLO
99.9% 이상

실제 결과가:

99.94%

라면 SLO를 만족하고 있는 것이다.

✅ 4. SLA와는 다르다

SLI, SLO와 함께 자주 나오는 것이 SLA다.

개념적으로는:

SLI
실제로 측정한 값

SLO
내부적으로 정한 목표

SLA
고객이나 파트너와 약속한 계약 수준

이라고 보면 된다.

현재 투게더몰 같은 내부 서비스 운영에서는 처음부터 SLA까지 만들 필요는 없다.

우선은

SLI
+
SLO

만 있어도 충분하다.

✅ 5. 모든 API에 SLO를 만들 필요는 없다

초기에는 흔히:

모든 API 99.99%

같은 기준을 만들고 싶어진다.

하지만 이것은 실무적으로 별 의미가 없다.

중요한 것은 비즈니스 핵심 흐름이다.

현재 프로젝트라면 우선 다음 정도가 중요하다.

고객 신청

주문 저장

관리자 주문 상태 변경

알림톡 발송

Webhook 처리

Export

배포

반대로:

관리자 FAQ 조회

배너 목록 조회

내부 통계 화면

같은 기능은 조금 느리거나 잠깐 실패하더라도 비즈니스 영향이 상대적으로 낮다.

✅ 6. 기능을 Criticality로 나누기

기능 중요도를 나누면 SLO를 만들기 편하다.

예:

Tier 1
고객 신청
주문 생성
주문 상태 변경

Tier 2
알림톡
Webhook
상담 등록

Tier 3
Excel Export
통계
운영 리포트

Tier 4
AI 분석
자동 문서 작성
내부 편의 기능

중요한 기능일수록 더 엄격한 기준을 둘 수 있다.

✅ 7. Availability SLI

가장 흔한 SLI 중 하나다.

Availability
=
성공 요청
/
전체 요청

예:

주문 생성

총 요청
10,000건

성공
9,990건

Availability
99.9%

단순 HTTP 200 여부만 보면 안 되는 경우도 있다.

✅ 8. HTTP 200이라고 실제 성공은 아니다

예를 들어 API가 이렇게 응답한다고 하자.

{
  "success": true
}

하지만 실제 DB에는 주문이 생성되지 않았다면 비즈니스 관점에서는 실패다.

따라서 SLI는 가능한 경우:

Technical Success
+
Business Success

를 구분해야 한다.

✅ 9. 주문 생성의 좋은 SLI

단순히:

POST /orders
HTTP 2xx 비율

만 보지 말고

유효한 신청 요청 중
실제로 Order Record 생성에 성공한 비율

처럼 정의하는 것이 더 낫다.

예:

SLI:

valid_order_requests_success_total
/
valid_order_requests_total

✅ 10. Latency SLI

성공했다고 끝이 아니다.

너무 느리면 사실상 장애와 비슷하다.

예:

주문 API

성공률 100%

응답 시간 20초

라면 정상 서비스라고 보기 어렵다.

따라서 응답 속도도 SLI로 본다.

✅ 11. 평균 응답 시간만 보면 안 되는 이유

평균이:

300ms

라고 해도 실제로:

90명
100ms

10명
2초 이상

일 수 있다.

그래서 보통 Percentile을 본다.

✅ 12. p50, p95, p99

예를 들어:

p50 = 180ms

p95 = 700ms

p99 = 2.5s

라는 의미는:

50% 요청은 180ms 이하

95% 요청은 700ms 이하

99% 요청은 2.5초 이하

다.

운영에서는 특히:

p95

p99

가 유용하다.

✅ 13. 주문 API Latency SLO 예시

예:

주문 생성 API

99% 이상의 요청이
2초 이내 완료

이런 식으로 정의할 수 있다.

SLI
2초 이내 성공 요청 비율

SLO
99%

✅ 14. Queue 시스템의 SLO는 다르게 봐야 한다

Worker 기반 자동화는 HTTP API와 같은 기준을 적용하기 어렵다.

예:

NotificationJob

은 요청 직후 바로 완료되지 않아도 된다.

대신 다음 같은 지표가 중요하다.

Queue Wait Time

Processing Time

End-to-End Completion Time

✅ 15. NotificationJob SLI 예시

예:

주문 상태 변경 후
알림톡 Provider 요청까지 걸린 시간

을 측정한다.

SLO:

99%의 알림톡 Job이
주문 상태 변경 후 30초 이내 Provider에 전달

처럼 만들 수 있다.

✅ 16. ExportJob은 더 느슨한 기준이 가능하다

예:

Excel Export

95%가 60초 이내 완료

99%가 3분 이내 완료

실시간 요청보다 기준이 느슨해도 된다.

핵심은 모든 기능에 같은 기준을 적용하지 않는 것이다.

✅ 17. Webhook SLO

Webhook은 외부 상태 동기화와 연결된다.

예:

Provider Webhook 수신 후
30초 이내 내부 상태 반영

99%

또는:

정상 Webhook 처리 성공률
99.9%

같은 기준을 만들 수 있다.

✅ 18. Freshness도 중요한 SLI다

데이터 기반 서비스에서는 단순 성공 여부뿐 아니라

얼마나 최신 상태인가?

도 중요하다.

예:

배정 순번 페이지

가 DB상 정상 응답은 하지만 3시간 전 데이터를 보여주면 문제가 된다.

이런 경우:

Data Freshness

를 SLI로 볼 수 있다.

예:

배정 현황 데이터가
5분 이내 최신 상태를 유지하는 비율

✅ 19. Completeness SLI

일부 데이터만 처리되고 누락되는 문제도 있다.

예:

완료 주문 100건

완료 알림톡 Job 생성 96건

HTTP Error는 없을 수도 있다.

그러나 비즈니스상 4건이 누락됐다.

이 경우:

Completeness
=
실제 생성된 후속 작업 수
/
생성되어야 하는 작업 수

같은 SLI를 만들 수 있다.

✅ 20. Correctness SLI

성공했지만 결과가 틀릴 수도 있다.

예:

주문 상태 변경 성공

하지만 잘못된 상태값 저장

또는:

할인 금액 계산 API 성공

계산 결과 오류

Correctness는 측정하기 어려우나 중요한 영역에서는 고려해야 한다.

✅ 21. 현재 프로젝트에서 현실적인 SLI 종류

우선 다음 정도면 충분하다.

영역	추천 SLI
고객 신청	성공률, p95 응답시간
주문 관리	성공률, p95 응답시간
알림톡	발송 성공률, 처리 지연
Webhook	처리 성공률, 반영 지연
Export	완료 성공률, 완료 시간
Queue	Oldest Job Age
AI Run	성공률, 평균 실행 시간
배포	성공률, Health Check 성공 여부

✅ 22. 너무 높은 SLO도 문제가 된다

처음부터:

99.9999%

같은 목표를 잡는 것은 현실적이지 않다.

목표가 너무 높으면:

개발 속도 감소

불필요한 이중화

복잡도 증가

운영 비용 증가

가 발생한다.

특히 1인 개발 환경에서는 더 그렇다.

✅ 23. 99%와 99.9%의 차이

숫자로 보면 작은 차이 같지만 실제 허용 실패량은 크게 달라진다.

예를 들어 월간 기준으로 보면:

99%
약 1% 실패 허용

99.9%
약 0.1% 실패 허용

99.99%
약 0.01% 실패 허용

운영 난이도도 점점 올라간다.

✅ 24. Error Budget이란?

SLO를 100%로 잡지 않는 이유와 연결된다.

예:

SLO = 99.9%

라면

0.1%

는 실패를 허용한다는 뜻이다.

이 허용 가능한 실패량이 Error Budget이다.

✅ 25. Error Budget 예시

월간 주문 요청이:

100,000건

이고 SLO가:

99.9%

라면 허용 가능한 실패량은 대략:

100건

이다.

즉:

Error Budget
=
100건

이다.

✅ 26. 왜 실패를 일부 허용하는가?

목표를

절대 실패 0건

으로 잡으면 기능 개발이 지나치게 느려질 수 있다.

예:

새 기능 배포 못 함

모든 변경 승인 필요

테스트 비용 폭증

복잡한 Failover 필요

그래서 현실적으로는:

일정 수준의 실패를 허용하면서

개발 속도와 안정성 균형을 잡는다.

✅ 27. Error Budget은 개발 속도와 연결된다

예를 들어 월 Error Budget의 10%만 사용했다면:

서비스 안정적

이라고 볼 수 있다.

이때는:

새 기능 배포

리팩터링

실험적인 자동화

를 조금 더 적극적으로 할 수 있다.

반대로 Budget을 거의 소진했다면:

신규 기능보다 안정화 우선

으로 바꿀 수 있다.

✅ 28. Error Budget Burn

Error Budget이 얼마나 빨리 소모되고 있는지를 볼 수 있다.

예:

한 달 Error Budget
100건

오늘 하루에
60건 실패

라면 심각하다.

단순히

아직 40건 남음

이 아니라

소모 속도가 비정상적으로 빠르다

가 중요하다.

✅ 29. Burn Rate

이를 Burn Rate라고 표현한다.

예를 들어 정상적으로 한 달 동안 천천히 소모해야 할 Budget을 하루 만에 대부분 써버린다면 Burn Rate가 높다.

개념적으로:

Burn Rate > 1

이면 Error Budget을 예상보다 빠르게 소비하고 있다고 이해하면 된다.

✅ 30. 운영 Alert도 Burn Rate 기반으로 만들 수 있다

단순히:

에러 1건 발생
→ Alert

보다:

SLO를 심각하게 깨뜨릴 수준으로
Error Budget이 빠르게 소비되는가?

를 보는 것이 낫다.

이렇게 하면 작은 오류에 지나치게 반응하는 일을 줄일 수 있다.

✅ 31. 하지만 처음부터 복잡한 Burn Rate Alert는 필요 없다

현재 프로젝트에서는 우선 단순 기준으로 시작해도 된다.

예:

5분 동안 주문 API 실패율 > 5%

10분 동안 알림톡 실패율 > 10%

Oldest Job Age > 5분

UNKNOWN Job > 20건

운영 데이터가 쌓인 뒤 Burn Rate 기반으로 발전시키면 된다.

✅ 32. SLO Window

SLO를 계산할 기간도 중요하다.

예:

1시간

24시간

7일

30일

짧은 Window는 최근 장애에 민감하다.

긴 Window는 전체 품질을 보기 좋다.

✅ 33. 같은 SLI를 여러 Window로 볼 수 있다

예:

주문 성공률

최근 1시간
98.3%

최근 24시간
99.8%

최근 30일
99.94%

최근 1시간에 장애가 발생했다는 것을 빠르게 알 수 있다.

✅ 34. Rolling Window

달력 기준:

9월 1일 ~ 9월 30일

대신

최근 30일

처럼 계속 움직이는 Window를 사용할 수 있다.

이렇게 하면 언제든 현재 서비스 품질을 보기 편하다.

✅ 35. SLO는 서비스 단위보다 User Journey 단위가 더 좋을 때도 있다

기술적으로 API 하나하나 기준을 잡는 것보다:

사용자가 신청을 완료할 수 있는가?

같은 Journey 중심 SLO가 더 의미 있을 수 있다.

예:

상품 상세
→ 신청 모달
→ 신청 제출
→ 주문 생성

이 전체가 하나의 중요한 사용자 여정이다.

✅ 36. 신청 Journey SLI

예를 들어:

유효한 신청 제출 중
최종 주문 저장까지 성공한 비율

을 볼 수 있다.

99.5%

같은 목표를 둔다.

중간 API 하나가 성공했는지는 사용자 입장에서는 중요하지 않다.

✅ 37. 고객 관점의 SLO가 중요한 이유

서버 입장에서는:

API 정상

DB 정상

CPU 정상

인데 고객은:

신청 버튼 눌러도 진행 안 됨

을 겪을 수 있다.

따라서:

System-Centric SLI
+
User-Centric SLI

둘 다 필요하다.

✅ 38. Synthetic Check

실제 사용자가 없어도 주기적으로 주요 흐름을 테스트하는 방법이 있다.

예:

5분마다

홈페이지 접속

상품 API 호출

신청 API Health Check

관리자 API 확인

실제 주문을 만들지는 않고 안전한 검사용 Endpoint를 사용할 수 있다.

✅ 39. Health Check도 단계가 있다

단순:

GET /health

200 OK

만으로는 부족할 수 있다.

예:

Application Health

Database Health

Queue Health

External Provider Health

로 나눌 수 있다.

✅ 40. Liveness와 Readiness

운영 환경에서는 이 둘을 구분하기도 한다.

Liveness

프로세스가 살아 있는가?

Readiness

실제 요청을 받을 준비가 되었는가?

예를 들어 서버 프로세스는 살아 있지만 DB 연결이 끊겼다면:

Liveness = OK

Readiness = FAIL

이 될 수 있다.

✅ 41. External Dependency SLO

우리 서버가 정상이어도 외부 Provider가 장애일 수 있다.

예:

알림톡 Provider

SMS API

OIDC Provider

AWS 서비스

이 경우 내부 서비스 SLO에 외부 장애를 어떻게 반영할지 정해야 한다.

✅ 42. 외부 장애를 숨기면 안 된다

예:

우리 API 200

하지만 알림톡 Provider 장애로
실제 메시지 미발송

이면 고객 관점에서는 실패다.

따라서 내부 API 성공률과 별개로

End-to-End Notification SLI

를 보는 것이 좋다.

✅ 43. Dependency 상태도 기록하기

예:

notification_provider_available = 1

s3_available = 1

database_available = 1

같은 별도 지표를 두면 장애 원인을 빠르게 구분할 수 있다.

✅ 44. SLO 위반과 Incident는 같은 말이 아니다

SLO를 잠깐 넘겼다고 무조건 긴급 장애는 아니다.

예:

Export 완료 p95

목표 60초

현재 68초

라면 운영 개선 대상일 수는 있지만 즉각적인 Critical Incident는 아닐 수 있다.

반대로:

주문 생성 완전 실패

는 짧게 발생해도 매우 중요하다.

✅ 45. Severity와 SLO는 같이 보되 분리해야 한다

예:

P0
주문 생성 전체 실패

P1
주문 생성 실패율 급증

P2
알림톡 지연

P3
Export 느림

SLO는 서비스 품질 기준이고,

Severity는 사건의 대응 우선순위다.

✅ 46. 운영 우선순위는 고객 영향으로 판단

문제가 발생했을 때:

CPU 90%

라는 숫자보다

고객 신청 실패율 증가

가 더 중요할 수 있다.

항상:

Infrastructure Metric
↓
Application Metric
↓
Business Metric
↓
Customer Impact

순으로 연결해서 보는 것이 좋다.

✅ 47. SLO를 너무 자주 바꾸지 않는다

장애가 발생할 때마다:

SLO가 너무 높네
→ 낮추자

하면 기준의 의미가 없어진다.

SLO는 실제 사용자 기대와 비즈니스 영향에 맞춰 정하고 일정 기간 유지해야 한다.

✅ 48. 반대로 처음 정한 SLO를 영원히 유지할 필요도 없다

서비스 규모가 바뀌면 기준도 바뀔 수 있다.

예:

초기

주문 100건/일

에서

성장 후

10,000건/일

이 되면 더 엄격한 품질 기준이나 별도 시스템이 필요할 수 있다.

✅ 49. 내부 관리자 기능은 SLO를 낮게 잡아도 된다

예:

관리자 Excel Export

99.9%

까지 요구할 필요는 없을 수 있다.

오히려:

95%가 2분 이내 완료

실패 시 재실행 가능

정도로 운영할 수 있다.

왜냐하면 실패하더라도 즉시 재처리할 수 있기 때문이다.

✅ 50. Recoverability도 품질 기준이다

무조건 실패하지 않는 시스템보다:

실패하더라도 빠르게 복구 가능한 시스템

이 더 현실적일 수 있다.

따라서 다음도 운영 지표가 될 수 있다.

MTTR

Auto Recovery Rate

Reconciliation Success Rate

✅ 51. Reconciliation SLO

0917 내용과 연결하면:

UNKNOWN 상태가 된 Job 중

95%가 5분 이내
SUCCESS / RETRY / MANUAL_REQUIRED
중 하나로 정리

같은 SLO도 만들 수 있다.

즉 시스템이 애매한 상태를 얼마나 빨리 해소하는지도 품질이다.

✅ 52. MTTR SLO

예:

P1 Incident

평균 30분 이내 복구

또는:

Stale Worker Job

10분 이내 자동 복구

같은 기준을 만들 수 있다.

✅ 53. Automation SLO 예시

현재 자동화 구조라면:

NotificationJob

성공률
99.5%

p95 처리 시간
30초 이하

UNKNOWN
0.1% 이하

DLQ
0.05% 이하

처럼 볼 수 있다.

처음부터 정확한 수치를 확정하기보다는 운영 데이터 수집 후 조정한다.

✅ 54. AI Workflow SLO는 일반 API와 다르게 잡아야 한다

AI 자동화는 확률적인 특성이 있다.

예:

AI Report 생성 성공률

을 무조건 99.9%로 만들 필요는 없다.

특히 내부 생산성 자동화라면:

90~95% 성공
+
실패 시 사람이 재실행

정도도 충분할 수 있다.

✅ 55. AI 자동화에서 볼 수 있는 SLI

예:

Run Success Rate

Tool Failure Rate

Test Pass Rate

Manual Approval Rate

Retry Rate

Average Run Duration

Token Usage

Resume Success Rate

✅ 56. AI 결과 품질도 측정할 수 있다

단순 실행 성공과 실제 결과 품질은 다르다.

예:

AI Run SUCCESS

여도 코드가 별로일 수 있다.

따라서:

Test 통과

Lint 통과

Build 통과

Human Review 승인

Rollback 여부

같은 Proxy Metric을 활용한다.

✅ 57. AI Workflow의 좋은 목표

예:

AI 코드 변경 Run 중

95% 이상 Build 성공

90% 이상 Test 통과

Production 직접 배포 0%

고위험 작업 승인 없는 실행 0건

이런 식으로 안전성과 품질을 함께 본다.

✅ 58. Safety SLO라는 관점도 가능하다

AI 자동화에서는:

실패를 얼마나 적게 하느냐

뿐 아니라

위험한 행동을 얼마나 막느냐

도 중요하다.

예:

승인 없이 Production 수정
0건

Secret 로그 노출
0건

Forbidden Tool 실행
0건

이런 항목은 100% 목표를 가져도 된다.

✅ 59. 모든 SLO가 99.x% 형태일 필요는 없다

예:

DLQ Job
15분 이내 운영자에게 노출

Critical Alert
5분 이내 감지

Production Deploy
배포 후 2분 이내 Health Verification

처럼 시간 기반 목표도 SLO다.

✅ 60. SLO Dashboard

운영 화면에서는 다음 정도를 보여줄 수 있다.

주문 생성

SLO
99.9%

최근 30일
99.94%

상태
정상

알림톡 처리

SLO
99.5%

최근 30일
99.1%

상태
주의

이런 식이다.

✅ 61. Error Budget 표시

예:

주문 API Error Budget

Monthly Budget
100

Used
27

Remaining
73%

Status
Healthy

이렇게 보여주면 안정성 상태를 한눈에 볼 수 있다.

✅ 62. Release와 Error Budget 연결

배포 정책에도 활용할 수 있다.

예:

Error Budget Remaining > 50%

일반 배포 가능

Remaining < 20%

위험한 변경 자제
안정화 우선

Budget Exhausted

긴급 수정 외 신규 기능 배포 중단

이런 정책을 둘 수 있다.

현재 프로젝트에서 자동 차단까지 할 필요는 없고 판단 기준으로만 사용해도 된다.

✅ 63. AI Deployment Agent에도 활용 가능하다

AI가 배포를 제안할 때 다음을 확인하게 할 수 있다.

현재 Error Budget

최근 Error Rate

Critical Incident 존재 여부

최근 배포 실패 여부

그리고:

현재 서비스가 불안정하므로
배포 승인 필요

같은 판단 자료를 제공하도록 할 수 있다.

✅ 64. 하지만 AI가 SLO만 보고 독단적으로 배포를 막으면 안 된다

예:

SLO 미달
→ 무조건 배포 금지

는 지나치게 단순하다.

왜냐하면 해당 배포가 바로 장애 수정일 수도 있기 때문이다.

따라서:

SLO
+
변경 목적
+
위험도
+
Rollback 가능성

을 같이 본다.

✅ 65. SLO를 코드로 관리하는 것도 가능하다

규모가 커지면:

service: order-api

slos:
  availability:
    target: 99.9
    window: 30d

  latency:
    percentile: 95
    threshold: 1000ms

처럼 설정으로 관리할 수도 있다.

현재는 문서나 관리자 설정만으로 충분하다.

✅ 66. 운영 Runbook에도 SLO를 연결한다

예:

Notification Failure Rate

정상
< 1%

Warning
1~5%

Critical
> 5%

그리고 Runbook:

Warning

1. Provider 상태 확인
2. Retry 증가 여부 확인
3. Queue Lag 확인


Critical

1. 신규 Retry 제한 검토
2. Provider 장애 여부 확인
3. 대체 발송 경로 검토
4. Incident 생성

✅ 67. Alert Threshold는 SLO에서 파생시키는 것이 좋다

Alert를 제각각 만들지 말고:

우리의 품질 목표는 무엇인가?

를 먼저 정한다.

그리고:

SLO를 깨뜨릴 가능성이 높은 신호

에 Alert를 만든다.

그래야 의미 없는 알림이 줄어든다.

✅ 68. 초기에는 실제 운영 데이터를 먼저 모으는 것이 중요하다

아직 기준 데이터가 없다면:

주문 API p95 1초

가 적절한지 판단하기 어렵다.

처음 2~4주 정도:

현재 실제 성공률

p95 / p99

Retry Rate

Queue Lag

Webhook 처리 시간

을 수집한다.

그 후 현실적인 기준을 만든다.

✅ 69. 현재 값보다 살짝 나은 수준으로 시작하기

예:

현재 주문 성공률
99.4%

인데 바로

99.99%

를 목표로 잡기보다는:

초기 SLO
99.5%

이후
99.7%

장기
99.9%

처럼 발전시키는 것도 현실적이다.

✅ 70. 하지만 심각한 안전 항목은 타협하지 않는다

다음은 단계적으로 개선하는 영역이 아니다.

Secret 노출

고객 개인정보 외부 로그 기록

중복 결제

승인 없는 Production 데이터 삭제

이런 문제는:

허용 Error Budget = 0

으로 보는 것이 맞다.

✅ 71. 투게더몰 기준 초기 SLO 초안

현재 구조에서 시작한다면 예를 들어 다음 정도로 볼 수 있다.

고객 신청

Success Rate
99.5% 이상

p95
2초 이하

관리자 주문 변경

Success Rate
99.9%

p95
1초 이하

알림톡

Job 성공률
99%

p95 Queue-to-Provider
30초 이하

Webhook

처리 성공률
99%

p95 내부 반영
30초 이하

Export

성공률
98%

p95
2분 이하

이는 확정 기준이라기보다 측정을 시작하기 위한 초기값으로 두는 편이 낫다.

✅ 72. 실제 수치보다 중요한 것은 정의다

예를 들어:

알림톡 성공률 99%

이라고 해놓고

Queue 생성 성공

을 성공으로 칠 것인지,

Provider 접수 성공

을 성공으로 칠 것인지,

최종 고객 전달 성공

을 성공으로 칠 것인지에 따라 완전히 다른 지표가 된다.

따라서 SLI Definition이 매우 중요하다.

✅ 73. SLI Definition 문서 예시

SLI Name
Notification Provider Submission Success

Description
NotificationJob이 Provider API에 정상 접수된 비율

Numerator
Provider API 성공 응답 수

Denominator
전체 유효한 NotificationJob 처리 시도 수

Exclusion
사용자 전화번호 Validation 실패

Window
Rolling 30 days

이 정도만 문서화해도 나중에 혼란이 많이 줄어든다.

✅ 74. Exclusion Rule도 중요하다

사용자가 잘못된 데이터를 입력해서 실패한 요청까지 시스템 장애로 포함하면 SLO가 왜곡될 수 있다.

예:

Validation Error

는 Availability SLI에서 제외할 수 있다.

반대로:

DB Error

Timeout

Internal Exception

은 포함한다.

✅ 75. 단 외부 Provider 오류를 무조건 제외하면 안 된다

고객 관점 SLI에서는 외부 장애도 실제 실패다.

따라서 두 가지를 나눌 수 있다.

Internal Reliability

End-to-End Reliability

내부 원인 분석과 고객 체감 품질을 동시에 볼 수 있다.

✅ 76. Error Budget 기록 모델 예시

굳이 DB 모델을 만들어야 하는 것은 아니지만 개념적으로는:

interface SloSnapshot {
  service: string;
  sli: string;

  target: number;
  actual: number;

  budgetTotal: number;
  budgetUsed: number;

  windowStart: Date;
  windowEnd: Date;
}

형태로 볼 수 있다.

✅ 77. SLO 계산을 매 Request마다 DB에 저장할 필요는 없다

이런 지표는 보통 로그/Metric 시스템에서 집계한다.

즉:

Request
→ Metric 증가

Dashboard
→ 집계

형태가 낫다.

애플리케이션 DB에 모든 Metric을 직접 저장하면 부담이 커질 수 있다.

✅ 78. Business SLO도 고려 가능하다

예:

신청 완료율

주문 누락률

상담 응답 누락

상품 가격 데이터 최신성

다만 이것은 기술 SLO와 마케팅 KPI를 명확히 구분해야 한다.

예:

신청 전환율

이 낮다고 서버 장애는 아니다.

✅ 79. 기술 지표와 비즈니스 KPI 구분

예:

신청 API 성공률
→ Reliability

신청 전환율
→ Business KPI

둘을 섞으면 원인 판단이 어려워진다.

✅ 80. SLO 위반 시 자동 Incident 생성

나중에는:

주문 API SLO 위반

이 감지되면 자동으로:

Incident 생성

Correlation Sample 수집

최근 Deploy 연결

Error Code Top N 수집

Runbook 연결

까지 만들 수 있다.

이게 운영 자동화의 다음 단계다.

✅ 81. 최근 Deploy와 SLO를 연결하면 매우 유용하다

예:

14:03
Release abc123

14:10
주문 Error Rate 상승

이 정보를 같이 보여주면:

최근 변경으로 인해 발생했을 가능성

을 빠르게 확인할 수 있다.

단 자동으로 원인이라고 단정하지는 않는다.

✅ 82. Deploy Marker

Observability Dashboard에:

Deploy
v2026.09.22.2

시점을 표시해두면 좋다.

그러면 그래프상:

Error Rate 상승

Latency 상승

과 배포 시점을 쉽게 비교할 수 있다.

✅ 83. AI가 SLO 분석을 도와줄 수 있다

Read-Only Agent에게 다음처럼 맡길 수 있다.

최근 24시간 SLO 위반 요약

Error Budget 소비 원인 분석

가장 많이 발생한 Error Code

최근 Deploy와 지표 변화 비교

개선 우선순위 제안

운영자가 직접 여러 Dashboard를 뒤지는 시간을 줄일 수 있다.

✅ 84. AI에게 제공할 Context는 요약된 Metric 중심

전체 로그를 던지기보다는:

{
  "service": "notification",
  "slo": 99.5,
  "actual": 98.8,
  "errorBudgetRemaining": 12,
  "topErrors": [
    "PROVIDER_TIMEOUT",
    "RATE_LIMIT"
  ]
}

같은 구조화된 데이터를 제공하는 것이 낫다.

✅ 85. AI가 내릴 수 있는 안전한 분석

예:

현재 Notification SLO가 미달입니다.

주요 실패 원인:
1. PROVIDER_TIMEOUT
2. RATE_LIMIT

최근 Retry 횟수가 평소 대비 4배 증가했습니다.

권장 확인:
- Provider 상태
- Queue Lag
- Rate Limit 설정

여기까지는 안전하다.

✅ 86. AI에게 즉시 장애 조치를 맡기는 것은 별도 문제다

분석과 실행은 분리한다.

Observe
→ AI Analyse
→ Recommendation
→ Policy
→ Approval
→ Action

0915에서 다룬 Permission 구조와 연결된다.

✅ 87. 현재 구조에서 추천하는 운영 Scorecard

하루 한 번 다음 정도를 보면 된다.

주문 API

Success
99.98%

p95
420ms


Notification

Success
99.4%

Retry
18

UNKNOWN
2


Queue

Pending
3

Oldest
12s


Webhook

Success
100%


DLQ
0

지나치게 많은 숫자를 보는 것보다 중요 지표를 고정하는 편이 낫다.

✅ 88. 주간 운영 리뷰에 포함할 내용

예:

이번 주 SLO

주문
정상

알림톡
1회 미달

Webhook
정상


Error Budget

주문
82% 남음

알림톡
31% 남음


Top Issues

Provider Timeout

Slow Query


Action

Notification Retry 정책 조정
DB Index 추가

이런 식으로 정리하면 작업 성과 문서로도 활용하기 좋다.

✅ 89. Local LLM Work Report와 연결

현재 일일 보고서 자동화에:

Git Commit

작업 요약

Troubleshooting

뿐만 아니라:

Daily Reliability Summary

Error Count

Retry Count

SLO Status

Incident

를 추가할 수 있다.

예:

### 운영 상태

- 주문 API SLO: 정상
- 알림톡 성공률: 99.7%
- Retry: 4건
- DLQ: 0건
- Incident: 없음

✅ 90. 이것이 포트폴리오에도 가치가 있는 이유

단순히:

NestJS API 개발

보다

운영 지표를 정의하고
Queue/Worker/Error Budget 기반으로
서비스 신뢰성을 관리했다

는 훨씬 실제 운영 경험에 가까운 이야기다.

특히 1인 개발자로 운영까지 맡고 있다면 좋은 차별점이 될 수 있다.

✅ 91. 다만 실제 하지 않은 것을 과장하면 안 된다

예:

SRE 체계를 구축했다

보다 실제로:

핵심 주문/알림 기능에 대해
성공률·처리시간·Retry·Queue Lag을 측정하고
내부 운영 기준을 정의했다

라고 쓰는 편이 더 정확하다.

✅ 92. NestJS Metric 구조 예시

개념적으로:

metrics.increment(
  'order_create_total',
);

metrics.increment(
  'order_create_success_total',
);

metrics.observe(
  'order_create_duration_ms',
  duration,
);

이런 식으로 애플리케이션 이벤트를 측정한다.

✅ 93. Notification Metric 예시

metrics.increment(
  'notification_job_total',
);

if (success) {
  metrics.increment(
    'notification_job_success_total',
  );
}

metrics.observe(
  'notification_queue_delay_ms',
  queueDelay,
);

✅ 94. 실제 Metric 이름은 일관성이 중요하다

예:

order_requests_total

order_requests_failed_total

order_request_duration_ms

notification_jobs_total

notification_jobs_failed_total

notification_queue_delay_ms

automation_unknown_jobs

automation_dlq_jobs

형식이 일정해야 검색과 Dashboard 구성이 편하다.

✅ 95. Label은 너무 많이 만들지 않는다

Metric에:

orderId

userId

phone

같은 값을 Label로 넣으면 안 된다.

값 종류가 너무 많아져 Metric 시스템에 부담이 생긴다.

이를 High Cardinality 문제라고 한다.

✅ 96. Metric Label로 적절한 값

예:

environment

service

provider

result

errorCode

처럼 종류가 제한된 값이 좋다.

✅ 97. Log와 Metric 역할을 다시 구분

Metric:

알림톡 실패가 32건 발생했다

를 빠르게 본다.

Log:

그중 job_392가 왜 실패했는가?

를 확인한다.

Trace:

그 Job이 어떤 주문 요청에서 시작됐는가?

를 확인한다.

서로 대체 관계가 아니다.

✅ 98. SLO와 Observability 흐름

0921과 0922를 연결하면:

Logs / Metrics / Traces
↓
SLI 측정
↓
SLO 비교
↓
Error Budget 계산
↓
Alert
↓
Incident / Reconciliation
↓
Recovery

형태가 된다.

✅ 99. 현재 프로젝트에서 도입 순서

1단계

핵심 Workflow 3개 선정

주문
알림톡
Webhook

2단계

각각:

Success Rate

Latency

Queue Delay

중 필요한 SLI 정의

3단계

2~4주 실제 데이터 수집

4단계

초기 SLO 정의

5단계

Dashboard / Warning Threshold 구성

6단계

Error Budget과 Deploy 판단 연결

이 순서가 현실적이다.

✅ 100. 처음에는 이것만 해도 충분하다

현재 투게더몰이라면 일단:

주문 생성 성공률

주문 API p95

알림톡 성공률

알림톡 Queue Delay

Webhook 성공률

UNKNOWN Job

DLQ

이 7개 정도부터 측정하면 된다.

나머지는 필요할 때 늘린다.

✅ 101. Codex 구현 프롬프트

현재 NestJS + Prisma 기반 프로젝트의
운영 신뢰성을 측정하기 위한
기본 SLI / SLO Metric 구조를 추가해줘.

현재는 1인 개발 환경이므로
복잡한 SRE 플랫폼을 만들지 말고,
핵심 Workflow의 성공률과 처리 시간을
측정할 수 있는 최소 구조를 목표로 한다.

대상 Workflow는 우선:

1. 주문 생성
2. 알림톡 NotificationJob
3. Webhook 처리

요구사항:

1. 공통 MetricsService 인터페이스를 만든다.

최소 지원 기능:
- increment counter
- set gauge
- observe duration

2. 주문 생성에 다음 Metric을 추가한다.
- order_requests_total
- order_requests_success_total
- order_requests_failed_total
- order_request_duration_ms

3. NotificationJob에 다음 Metric을 추가한다.
- notification_jobs_total
- notification_jobs_success_total
- notification_jobs_failed_total
- notification_retry_total
- notification_queue_delay_ms
- notification_processing_duration_ms

4. Webhook에 다음 Metric을 추가한다.
- webhook_received_total
- webhook_processed_total
- webhook_failed_total
- webhook_processing_duration_ms

5. Automation 공통 Gauge 또는 조회 Metric을 지원한다.
- UNKNOWN Job 수
- DEAD_LETTER Job 수
- Pending Job 수
- Oldest Job Age

6. Metric Label은 제한적으로 사용한다.

사용 가능 예:
- environment
- provider
- result
- errorCode

다음 값은 Label로 사용하지 않는다.
- orderId
- userId
- phone
- email
- jobId

7. 각 Workflow의 시작/성공/실패 시점에서
Metric이 정확하게 기록되도록 한다.

8. Duration 측정은 공통 helper를 만들어
중복 코드를 줄인다.

9. 기존 Structured Logging과
Correlation ID 구조는 유지한다.

10. Metric과 Log의 책임을 분리한다.
개별 실패 상세 정보는 Log,
전체 성공률과 지연은 Metric으로 처리한다.

11. 초기 SLI를 계산할 수 있도록 한다.

예:
- 주문 성공률
- 알림톡 성공률
- Webhook 성공률
- p95 처리시간

12. SLO 값 자체를 비즈니스 로직에
하드코딩하지 않는다.

별도 config 또는 운영 설정으로 관리할 수 있게 한다.

13. 초기 SLO 예시는 다음처럼 둘 수 있다.

order:
availability: 99.5
p95LatencyMs: 2000

notification:
successRate: 99.0
p95QueueDelayMs: 30000

webhook:
successRate: 99.0
p95ProcessingMs: 30000

단 실제 운영 데이터 수집 후
쉽게 변경 가능하도록 한다.

14. 개인정보나 Secret은
Metric과 Log에 포함하지 않는다.

15. 테스트를 작성한다.
- 성공 Counter 증가
- 실패 Counter 증가
- Duration 기록
- Retry Counter 기록
- 개인정보 Label 미사용

✅ 102. 실무 체크리스트

SLI

실제 사용자 경험과 연결되는가?
성공의 정의가 명확한가?
실패의 정의가 명확한가?
제외 조건이 있는가?
측정 가능한가?

SLO

너무 과도하게 높지 않은가?
비즈니스 중요도와 맞는가?
기능별로 다른 기준을 사용하는가?
Window가 정의되어 있는가?
실제 운영 데이터에 근거하는가?

Error Budget

허용 가능한 실패량을 알고 있는가?
Budget 소모량을 확인할 수 있는가?
Budget이 빠르게 감소할 때 알 수 있는가?
배포 판단에 참고하는가?

Metrics

Alert

Error 한 건마다 울리지 않는가?
고객 영향과 연결되어 있는가?
Severity가 나뉘어 있는가?
SLO 위반 가능성을 기준으로 하는가?

AI

AI Run 성공률을 측정하는가?
Tool 실패율을 확인할 수 있는가?
Test Pass Rate를 보는가?
위험한 Action 0건 기준이 있는가?
실행 성공과 결과 품질을 구분하는가?

📌 요약

0921에서 만든 Observability 구조가

무슨 일이 발생했는지

를 보여준다면,

0922의 SLI와 SLO는

그 상태가 정상인지 아닌지

를 판단할 기준을 만든다.

핵심 관계는 다음과 같다.

SLI
실제 측정값

SLO
목표 수준

Error Budget
허용 가능한 실패량

예를 들어:

주문 성공률

SLI
99.94%

SLO
99.9%

결과
목표 만족

이런 형태다.

중요한 것은 모든 서비스에:

99.99%

를 강요하는 것이 아니다.

각 기능의 비즈니스 중요도에 따라:

주문
엄격하게

알림톡
중간

Export
상대적으로 느슨하게

내부 AI 자동화
실패 후 복구 가능하게

기준을 다르게 잡아야 한다.

또한 Error Budget은 단순히 실패를 허용한다는 개념이 아니라

안정성
vs
개발 속도

사이의 균형을 잡기 위한 도구다.

서비스가 안정적이고 Budget이 충분하다면 새로운 기능이나 자동화를 적극적으로 시도할 수 있고,

반대로 Budget을 빠르게 소진하고 있다면:

신규 기능보다

안정화
Retry 개선
Slow Query 수정
Provider 장애 대응

을 우선한다.

현재 프로젝트에서는 처음부터 거대한 SRE 시스템을 만들 필요가 없다.

우선:

주문 성공률

주문 p95

알림톡 성공률

Queue Delay

Webhook 성공률

UNKNOWN

DLQ

정도만 측정하고 실제 운영 데이터를 쌓는 것이 좋다.

전체 흐름을 연결하면:

Observe
↓
Measure
↓
SLI
↓
Compare with SLO
↓
Error Budget
↓
Alert
↓
Diagnose
↓
Reconcile
↓
Recover

가 된다.

결국 SLO의 목적은 숫자 자체가 아니라,

“지금 우리 서비스가 어느 정도까지 정상이고, 언제 개발을 멈추고 안정화에 집중해야 하는지 판단할 수 있는 공통 기준을 만드는 것”

이다.

juni

이전 포스트

TIL - 20260921

다음 포스트