시작하며
안녕하세요. SRE(Site Reliability Engineer)로 일하고 있는 어다희입니다. 저희 팀은 Media Platform SRE를 비롯해 글로벌 트래픽 관리 업무를 담당하고 있습니다.
그동안 ‘신뢰성 향상을 위한 SLI/SLO 도입’ 시리즈를 통해 SLI/SLO의 개념과 필요성을 살펴보고 플랫폼과 서비스에 적용한 사례를 공유해 왔습니다.
- 신뢰성 향상을 위한 SLI/SLO 도입 1편 - 소개와 필요성
- 신뢰성 향상을 위한 SLI/SLO 도입 2편 - 플랫폼 적용 사례
- 신뢰성 향상을 위한 SLI/SLO 도입 3편 - 서비스 적용 사례(추후 공개 예정)
이번 ‘신뢰성 향상을 위한 SLI/SLO 활용’ 시리즈에서는 SLI(service level indicator)/SLO(service level objective)를 도입한 후 실제 운영에서 어떻게 활용하고 확장해 나갈 수 있을지 고민하며 풀어나간 내용을 다뤄보려고 합니다.
그 시작인 1편에서는 SLI/SLO를 기반으로 SLI/SLO 프레임워크를 구성하고 ‘LINE Status’라는 사내 도구를 만든 배경과 제작 과정에서 했던 고민을 공유해 보고자 합니다. 단순히 하나의 도구를 개발한 경험을 정리한다기보다는 운영을 반복하며 경험을 쌓아가면서 구조를 정리하고 이를 기반으로 자동화해 확장해 나간 과정을 중심으로 이야기해 보겠습니다.
SLI/SLO 작업을 반복하면서 발견한 공통 구조
SRE 팀에서는 주요 서비스와 플랫폼에 SLI/SLO를 적용했고, SLI/SLO를 사내에서 서비스 신뢰성을 이야기할 공통 언어로 사용하기 위해 다른 서비스와 플랫폼에도 확산해 나가기 시작했습니다
이 과정을 서너 번 반복하면서 SLI를 정의하고 SLO를 합의하는 방식에 서비스 특성과는 무관한 공통 패턴이 존재한다는 점을 깨달았습니다. 도입하고 운영 지표로 정착시키기까지 단계는 대부분 유사한 형태로 반복되고 있었습니다.
SLI/SLO 프레임워크
저희는 발견한 공통 흐름을 재사용하기 위해 전체 과정을 보다 명확하게 정리해서 하나의 프레임워크 형태로 구성했습니다. 특정 서비스에 종속되지 않는 공통 기준과 흐름 안에서 SLI/SLO를 정의하고 운영할 수 있도록 하기 위함이었습니다.
SLI/SLO 도입 과정을 하나의 흐름으로 정리하면 다음과 같습니다.
아래 표는 SLI/SLO 프레임워크를 구성하는 다섯 단계의 역할을 보다 구체적으로 정리한 내용입니다.
| 구 분 | 설 명 |
|---|---|
| Define Phase |
|
| Instrument Phase |
|
| Observe Phase |
|
| React Phase |
|
| Improve Phase |
|
SLI/SLO 프레임워크는 현재 Confluence(wiki) 템플릿 형태로 제공하고 있습니다. 각 서비스 팀은 이 템플릿을 복제해 단계별 항목을 채워 넣는 방식으로 SLI/SLO를 설계합니다. 그동안 SRE가 개별로 설명하고 조율해야 했던 내용을 템플릿과 가이드, FAQ 형태로 정리해 제공하면서 초기 논의 과정에서 발생하는 커뮤니케이션 비용을 줄이는 데 도움을 주고 있습니다. 현재 하나의 서비스에만 적용한 초기 단계이지만 향후 더 많은 서비스로 확장하면서 보완해야 할 부분을 찾아 점진적으로 개선해 나갈 예정입니다.
지금 우리 서비스 상태는 어떤가요?
SLI/SLO를 여러 서비스에 도입하고 운영해 오면서 자연스럽게 저희 팀이 직접 담당하지 않는 다른 서비스들의 상태도 궁금해졌습니다.
이미 LINE 서비스와 관련해서 https://api.line-status.info라는 API 상태 확인 페이지가 운영되고 있었지만, 이 페이지는 LINE 메시징과 로그인, LIFF(LINE front-end framework) 등 외부 API 사용자가 API 상태를 확인할 수 있는 방법을 제공하는 것에 초점을 둔 페이지였습니다. 또한 주요 이슈 발생 시 수동으로 정보를 업데이트하는 구조였습니다.
저희는 이와는 다르게 내부 구성원이 서비스 컴포넌트별 상태를 공통 기준으로 파악할 수 있는 도구를 만들고자 했습니다. 또한 이 도구를 SLI/SLO 알림과 장애(outage) 데이터를 기반으로 상태가 자동으로 갱신되는 구조로 설계하고자 했습니다.
이와 관련해 SRE 팀 내에서 상태를 어떤 기준으로 표현할 것인지 세부 논의가 이어졌습니다. 온콜에서 수신하는 알람을 그대로 반영할 것인지 혹은 오류 예산 기반으로 표현할 것인지 등을 검토했는데요. 저희가 SLI/SLO를 정의할 때 기준으로 삼았던 것은 개별 서비스의 장애 발생 여부가 아니라, CUJ 관점에서 사용자가 서비스를 ‘잘 이용하고 있는가(user happiness)’였습니다. 따라서 서비스의 상태 역시 단순 장애 발생 유무가 아니라 CUJ 기반으로 정의한 SLI 메트릭을 측정해 SLO 달성 여부를 판단하는 관점에서 표현하는 것이 일관적인 접근 방식이라고 판단했습니다. 또한 이때 모든 CUJ를 동일하게 노출하는 것이 아니라 서비스의 핵심 경험을 대표할 수 있는 항목 위주로 보여주는 것이 적절하다고 생각했습니다.
저희는 실제 운영 경험을 바탕으로 상태 전환 기준을 다듬으면서 초기 모델을 구체화해 나갔 습니다. 이미 주요 서비스에 SLI/SLO를 도입하는 프로젝트를 진행하면서 CUJ라는 공통 개념이 정의돼 있었기 때문에 이를 기반으로 한 사내용 서비스 상태 확인 도구인 ‘LINE Status’를 만들어 보기로 했습니다.
상태를 자동으로 관리할 수 있는 시스템 구성
LINE Status는 단순히 알람을 나열하는 페이지가 아니라, 수집한 이벤트를 기반으로 서비스의 현재 상태를 일관된 기준으로 보여주고, 이를 통해 현재 사용자 경험에 미치는 영향 여부를 가장 빠르게 인지할 수 있도록 하는 구조를 목표로 했습니다.
이를 위해 가장 먼저 각 서비스에서 운영 중인 SLI/SLO 기반 알림을 웹훅(webhook) 형태로 수집하는 백엔드 서버를 설계했습니다. 수집한 이벤트는 별도 DB에 저장해 이를 기반으로 현재 상태와 변경 이력을 관리할 수 있도록 구성했습니다. 이를 통해 특정 시점의 상태뿐 아니라 이벤트 발생 이력까지 함께 추적할 수 있습니다.
또한 내부 구성원 모두가 직관적으로 이해할 수 있도록 SLI나 SLO와 같은 용어를 그대로 노출하기보다는 기능 중심으로 정의한 상태 이름을 노출하기로 결정했습니다. 메시지 서비스를 예로 들면 “메시지 전송”, “읽음 표시”와 같이 실제 사용자가 인지하고 있는 기능 단위로 상태를 표현했습니다. 즉, 기술적인 세부 지표 대신 ‘사용자 경험에 영향이 있는지’를 중심으로 판단하도록 구성한 것입니다.
저희는 이와 같은 설계 철학 아래 LINE Status가 단순 모니터링 도구가 아니라 조직 관점에서 서비스 상태를 공유할 수 있는 창구가 되기를 기대했습니다.
LINE Status 구현
개발에는 약 한 달 정도 소요됐고, 이후 동료들의 피드백을 반영하며 점진적으로 개선해 나갔 습니다.
사실 저는 프런트앤드 개발과는 거리가 있는 엔지니어였습니다. 그럼에도 불구하고 최근 많이 활용되고 있는 바이브 코딩 방식을 적극 활용해 UI를 구현했습니다. 이 과정에서 느낀 점은, 도구 자체보다도 ‘기획의 명확성’이 훨씬 중요하다는 것이었습니다. 세부 기능을 구현할 때마다 마크다운 형식으로 요구 사항을 정리해 AI에게 전달했는데, 문서가 구체적이고 맥락이 충분할수록 결과물의 완성도 또한 높아졌습니다. 무작정 요청하는 것이 아니라, 어떤 상태를 어떻게 보여줄 것인지 의도를 명확히 정리해 전달해야 원하는 결과를 얻을 수 있었습니다.
이런 과정을 거쳐 완성한 LINE Status의 주요 화면을 소개하겠습니다(내부 전용 도구인 관계로 실제 서비스명과 데이터가 아니라 예시 형태로 가공했습니다).
먼저 메인 페이지는 다음과 같이 전체 서비스의 현재 상태를 한눈에 확인할 수 있게 구성했습니다.
메인 페이지의 특징은 다음과 같습니다.
- AI를 활용한 한 줄 분석 요약 제공
- 서비스 카드별 CUJ 항목 나열로 주요 기능에 대한 확인 가능
- 직관적인 색상 표현(초록 : 정상, 노랑 : 이벤트 발생, 빨강 : 장애 발생)
다음으로 특정 서비스의 CUJ(아이템) 단위 상태를 확인할 수 있는 서비스 상세 페이지입니다.
서비스 상세 페이지의 특징은 다음과 같습니다.
- 단순 내림차순 정렬이 아닌 최근 발생한 이벤트 순으로 상단에 표시
- 타임라인 기반 최근 이벤트 표시
- Past Events 영역에서 이번 달 이벤트 이력 확인 가능
다음은 전체 서비스의 히스토리를 확인할 수 있는 히스토리 페이지입니다.
히스토리 페이지의 특징은 다음과 같습니다.
- 이벤트 상황에서 각 서비스별 영향 범위 확인 가능
- 월 단위 구분을 통한 과거 이력 확인 가능
SLI/SLO 프레임워크와 LINE Status의 연결
LINE Status를 구현하는 과정에서 SLI/SLO 프레임워크와의 연결 구조가 자연스럽게 드러났습니다. SLI/SLO 프레임워크를 이용해 서비스에 SLI/SLO를 도입하고 나면, 해당 서비스를 LINE Status에 등록함으로써 조직 전체가 동일한 기준으로 상태를 확인할 수 있습니다. 즉 SLI/SLO를 정의하는 단계와, 그 결과를 조직 전체가 함께 바라보는 단계가 연결됩니다.
이때 LINE Status의 역할은 단순히 상태를 시각화하는 것에 그치지 않습니다. 개발자와 운영자가 동일한 기준으로 서비스의 상태를 인지할 수 있는 공통 창구를 제공하는 것이 핵심입니다. 각 팀에서 각자의 시각으로 개별적으로 모니터링 대시보드를 보는 대신, CUJ 기반 SLI와 SLO 달성 여부를 중심으로 ‘지금 사용자 경험에 영향이 있는가’를 함께 판단할 수 있어야 하기 때문입니다. 특히 이벤트가 발생했을 때 사용자 경험 기준 으로 상태를 빠르게 인지할 수 있는 구조가 필요합니다.
LINE Status는 위와 같은 사항을 염두에 두고 설계했습니다. 향후 운영 경험을 축적해 CUJ와 SLI/SLO 기준을 더욱 정교하게 다듬어 갈 계획입니다. 이를 통해 사용자는 개별 알람을 해석하는 대신 LINE Status를 기준으로 전체 컴포넌트 관점에서 현재 영향 받고 있는 서비스 경험이 무엇인지 빠르게 파악할 수 있을 것입니다. 이는 단순히 모니터링 편의를 개선하는 것을 넘어 의사 결정 속도와 커뮤니케이션 방식의 변화로 이어질 수 있다고 생각합니다.
아직 초기 단계이지만 장기적으로 SLI/SLO 프레임워크와 LINE Status를 통해 SLI/SLO를 조직 전체가 공유하는 ‘서비스 상태를 기술하는 공통 언어’로 확산시켜 나가고자 합니다. 이를 통해 특정 팀이나 역할에 과도하게 의존하지 않고도 SLI/SLO 기반 운영을 점진적으로 확장할 수 있는 기반을 마련하는 것이 목표입니다.
마치며
SLI/SLO 프레임워크를 구성하고 LINE Status를 제작하는 작업은 혼자였다면 결코 완성할 수 없었을 것입니다. 함께 고민하고 실험하며 다양한 의견을 나눠 주신 많은 분들께 이 자리를 빌려 진심으로 감사의 말씀을 전합니다.
2026년에도 LINE 서비스의 신뢰성을 높이기 위한 SLI/SLO 활용과 확장은 계속 이어질 예정입니다. 그 과정에서 한 고민과 시행 착오, 결과물들을 ‘신뢰성 향상을 위한 SLI/SLO 활용’ 시리즈를 통해 차근차근 공유해 보겠습니다. 많은 기대 부탁드리며 이만 마치겠습니다. 긴 글 읽어주셔서 감사합니다.
