← 포트폴리오 · 무신사

전사 SLO 체계 수립

무신사·29CM 전 서비스의 SLO를 수립하고, 측정 데이터로 반복 롤백과 리소스 과투자를 구조적으로 해소했습니다.

문제

"서비스가 불안정하다"는 말은 있는데 그것을 논증할 숫자가 없었습니다.

• 반복 롤백이 문제라는 인식은 있었지만, 어느 서비스에서 몇 번인지 아무도 말할 수 없었습니다.
• Staging 환경에 리소스가 과투자돼 있다는 의심이 있었지만, 줄이자고 하면 "장애 나면 책임지냐"는 반문에 막혔습니다.
• 가용성 목표가 조직마다 암묵적으로 달랐습니다.

숫자가 없으면 모든 논의가 목소리 큰 쪽으로 끝납니다.

제약

• 서비스가 수십 개인데 SLO를 중앙에서 다 정해줄 수는 없었습니다. 각 팀이 스스로 정의하되 비교 가능한 형태여야 했습니다.
• 팀마다 메트릭 수집 상태가 달랐습니다. 어떤 팀은 SLI로 쓸 쿼리가 아예 없었습니다.
• SLO를 새로운 평가 지표로 받아들이면 팀들이 목표를 낮게 잡습니다.

설계

1. 수립 가이드를 먼저 만들었다

각 팀이 SLO를 스스로 만들되 결과물이 서로 비교 가능하도록, 수립 가이드를 산출물의 첫 번째로 잡았습니다. 가이드가 없으면 팀마다 다른 단위, 다른 윈도우, 다른 분모를 쓰게 되고 그 순간 전사 집계가 불가능해집니다.

2. CUJ 단위로 핵심 사용자 여정을 정의했다

서비스 단위가 아니라 CUJ(Critical User Journey) 단위로 잘랐습니다. "상품 상세 API"가 아니라 "상품을 보고 장바구니에 담아 결제까지" 가 단위입니다.

서비스 단위로 자르면 각 API는 멀쩡한데 사용자는 구매를 못 하는 상황을 놓칩니다. CUJ 단위는 어떤 여정이 더 중요한가를 먼저 합의하게 만들기 때문에, 복구 우선순위 논의가 자연스럽게 따라옵니다.

3. 팀별 SLI 쿼리를 직접 보정했다

가이드만 주면 안 됩니다. 팀별로 실제 쿼리를 보고 분모·분자·제외 조건을 함께 고쳤습니다. 이 단계를 건너뛰면 숫자는 생기지만 아무도 믿지 않는 숫자가 됩니다.

4. 측정 데이터를 논쟁에 투입했다

TTD(탐지) / TTA(인지) / TTR(복구) · MTTR을 쌓아 두 가지를 규명했습니다.

• 반복 롤백의 원인 — 어떤 변경이, 어떤 조건에서 되돌려지는지가 보이자 발생 자체가 줄었습니다.
• Staging 리소스 과투자 — 과투자를 삭감으로 처리하지 않고 Chaos Engineering 투자로 전환했습니다. "줄이자"가 아니라 "같은 돈으로 실제 장애 내성을 검증하자"로 프레임을 바꾸면 반대가 사라집니다.

5. 주간 리포트로 되먹임을 만들었다

BU별(PBO, Core, MSS, FP, 29CM) 주간 SLO 리포트를 운영해 추세가 보이게 했습니다. 숫자는 한 번 보여주는 것으로는 행동을 바꾸지 못하고, 매주 같은 자리에 있어야 바뀝니다.

결과

• 무신사·29CM 전 서비스 SLO 수립
• 가용성 97.54% → 99.99% 를 목표로 하는 신뢰성 로드맵 수립 (11개 목표, 2026 Q3 – 2027 Q2) — Error Budget Policy, 온콜 건전성, 포스트모템 액션 추적, DORA 지표, 알림 품질, CUJ 단위 SLO 포함
• Staging 리소스 과투자를 Chaos Engineering 투자로 전환
• 반복 롤백 발생 감소

회고

SLO의 효용은 목표 관리가 아니라 논쟁의 종료였습니다. 숫자가 생기고 나서 달라진 건 "얼마나 안정적이어야 하는가"를 두고 회의가 길어지지 않는다는 점입니다.

CUJ로 자른 것이 나중에 더 크게 쓰였습니다. 핵심 사용자 여정과 그 중요도를 합의해 둔 자료는 업무연속성 관점에서 무엇을 먼저 복구해야 하는가에 그대로 쓰입니다. SLO 수립이 사실상 서비스 단위 업무영향분석이었습니다.

관련 케이스 — 전사 장애관리 프레임워크 · 비상대응훈련 프로그램

SLO/SLI CUJ Error Budget TTD/TTA/TTR MTTR DORA Datadog Grafana Confluence