본 아티클 내용에 들어가기 앞서, 여러분들께 한 가지 소식을 공유하고자 합니다.

다가오는 11월 21일 코엑스 컨퍼런스센터에서 개최되는 와탭랩스의 2025 WhaTap Observe Summit에서 제가 발표자로 참여하게 되었습니다. 해당 컨퍼런스는 옵저버빌리티와 AI 활용 등에 대한 인사이트를 나누는 다양한 세션들로 구성되어있는데요.

저는 그 중 Business 트랙에서 ‘지속가능한 옵저버빌리티’라는 주제로 발표를 할 예정입니다.

400

옵저버빌리티 및 AI 활용에 관심이 많으시고 일정이 가능하시다면 이번 WhaTap Observe Summit에 참여해보시는 걸 추천드립니다. (참가비 무료입니다!)

2025 WhaTap Observe Summit 링크: https://whatap.short.gy/summit-2025


옵저버빌리티 구축 시 가장 먼저 해야 할 것은?

옵저버빌리티는 최근 점점 더 주목을 받고 있는 키워드입니다. 시스템에 문제가 발생할 때 시스템 상태를 확인하는 모니터링과 달리, 시스템에 발생하는 문제의 근본 원인을 미리 파악하는 것이 옵저버빌리티의 목적이기 때문일 텐데요.

그래서 옵저버빌리티는 모니터링 도구는 물론, 팀 차원의 체계적인 접근이 필수인 영역입니다.

하지만 많은 조직과 팀이 옵저버빌리티 도입 및 운영에 어려움을 겪고있는 것이 현실인데요. 왜 그럴까요? 가장 대표적인 이유는 바로, 체계적인 문제 정의의 부재입니다.

이미 오픈소스나 관리형 서비스 형태로 다양한 모니터링 툴이 등장했고, 많은 팀과 조직에서 모니터링 시스템을 구축했습니다.

하지만 옵저버빌리티는 서비스에서 발생하는 문제를 선제적으로 파악해서 대응하는 활동이기 때문에, 모니터링 툴 도입만으로는 부족합니다.

그 전에 우리 서비스 운영에 필요한 질문을 먼저 정의하는 것이 중요한데요.

  • 지금 우리 서비스가 어떤 상태인가?
  • 앞으로 우리 서비스가 어떤 상태여야 하는가?

이 2가지 질문은 각각 서비스의 현재 품질과 목표 품질을 나타내는 지표로 표현할 수 있습니다. 이렇게 지표로 측정해서 관리하면 우리 서비스가 지금 안정적으로 운영 중인지, 아니면 서비스 상태에 문제가 발생하고 있는지를 빠르고 효율적으로 파악할 수 있죠.

그럼 먼저 서비스의 현재 품질을 보여주는 지표인 SLI(Service Level Indicator)를 살펴보겠습니다.


지금 우리 서비스의 상태를 보여주는 SLI

SLI(Service Level Indicator)는 지금 우리 팀이 제공하는 서비스의 품질을 사용자 관점으로 나타내는 지표입니다. 서비스의 품질이란 어떤 것을 말할까요? 다양한 관점이 있겠지만, SLI로 가장 많이 측정하는 분야는 가용성과 지연시간입니다.

서비스의 가용성과 지연시간

서비스의 가용성이란 요청받은 작업의 성공 여부를, 지연시간은 서비스가 작업을 수행하는 데에 걸리는 시간을 말합니다.

보통 SLI는 4주(28일) 동안의 측정되는 데이터로 계산하는데요.

그래서, 서비스의 가용성 및 지연시간 SLI를 계산하는 법과 예시를 정리하면 아래와 같습니다.

  • 가용성 SLI

    • 4주 동안의 {긍정적인 이벤트의 수 / 총 이벤트 수}를 퍼센티지로 표현
    • 예: 4주 동안 서비스에 대한 총 요청 수 대비 성공한 요청 비율 97.321%
  • 지연시간 SLI

    • 4주 동안의 {X초 이하로 처리된 작업 수 / 총 작업 수}를 퍼센티지로 표현
    • 예: 4주 동안 서비스에 대한 총 요청 수 대비 100ms 이하로 처리된 요청 비율 98.7%

이렇게 SLI를 퍼센티지로 표현하면…

  1. 시스템의 상태를 직관적으로 표현할 수 있고
  2. 앞으로 등장하는 SLO 및 Error Budget 설정도 더 쉬워집니다.

참고로 복잡한 시스템일수록 기능별 또는 서비스별 SLI를 여러 개 정의할 수도 있는데요.

SLI가 너무 많으면 오히려 부담이 되고 혼란이 있을 수 있기에 여러 SLI를 합한 다음 평균을 구해 집계(Aggregate)하는 경우도 있습니다. 단, 비즈니스 임팩트가 월등한 서비스가 있다면 해당 SLI에 가중치를 부과하거나 따로 관리하여 비즈니스 가치를 유지하는 것이 중요합니다.


앞으로 우리 서비스의 목표가 되어주는 SLO

SLO(Service Level Object)란 팀이 설정한 목표 SLI를 말합니다.

만약 팀이 SLO를 처음 정의한다면, 현재 SLI의 수치를 관리하기 용이한 단위로 내림해서 시작하는 것을 추천하는데요.

예를 들면 아래와 같습니다.

  • 가용성 SLI에 대한 요청 성공률이 97.321%인 경우 최초 SLO는 97%
  • 지연시간 SLI에 대한 100ms 이하로 처리된 요청 비율이 98.7%인 경우 최초 SLO는 98.5%

SLO를 설정할 때 최소/최대 범위를 함께 지정하는 것도 권장되는 방법 중 하나입니다. 아까 지연시간 SLO의 예시를 다시 가져오면, ‘100ms 미만으로 처리되는 서비스의 비중은 98.5%~99%‘처럼 설정하는 것인데요.

SLO는 개발자에게 성능 향상의 목표가 될 수 있습니다. 하지만 성능 향상에만 몰입해 정작 개발해야 하는 다른 기능에 집중하지 못하는 경우가 생길 수 있으므로, 이렇게 최소/최대 범위를 정해 유연함을 더하는 것이죠.

또한 SLO는 팀의 역량이나 비즈니스 상황에 따라 주기적으로 조정해야 합니다. 처음부터 우리 팀의 역량을 훨씬 뛰어넘는 수준으로 설정하는 것은 바람직하지 않습니다.
팀원의 사기가 저하되고 팀의 성장을 가시화하기 어렵기 때문인데요.

그래서 SLO는 주기적으로 사용자 관점에서 검토 후, 필요하다면 조금씩 조정해나가는 것이 좋습니다.

예를 들면, 팀이 주기적으로 아래 2가지 질문에 답하면서 SLO를 업데이트하는 것이죠.

  • 기존에 설정된 SLO 중에 현재 시장이나 사용자가 기대하는 성능에 못 미치는 것이 있을까?
  • 기존 SLO 중에 너무 엄격해서 지키기 어렵거나 너무 느슨해서 의미가 없는 것은 없을까?

우리 서비스의 여유 공간이 되어주는 Error Budget

SLO를 100%로 설정하는 경우는 없습니다. 모든 시스템은 완벽하지 않고 언제나 변수가 생기기 마련이기 때문인데요.

아까 위에서 예시로 들었던 가용성 SLO는 97%였죠. 그렇다면 나머지 3%는 무엇을 의미할까요? 우리는 이렇게 SLO를 충족하지 않아도 괜찮은 여유 공간을 Error Budget이라고 합니다.

이때 3%의 요청 실패는 실수가 아닌 여유 공간이라는 관점이 중요합니다. 그래야 Error Budget을 개발 관련 의사 결정에 활용할 수 있기 때문인데요.

지금 서비스에 대해 남아있는 Error Budget이 아직 여유롭다면 신규 기능을 개발하거나 신규 버전을 배포하는 방향으로 갈 수 있을 겁니다.

하지만 Error Budget이 소진이 되고 있다면 이야기는 달라지겠죠.

만약 Error Budget이 꾸준히 소진되고 있다면 우리가 가져야 할 전략은 아래와 같습니다.

  • 신규 기능 개발 및 신규 버전 배포 중단
  • SLO 관련 안정화 작업(버그 수정, 성능 최적화) 수행

그리고 Error Budget이 급격히 소진되고 있는 경우에는 아래와 같이 행동해야겠죠.

  • 신규 기능 개발 및 신규 버전 배포 중단 (필요하다면 이전 버전으로 롤백)
  • Error Budget이 소진된 Root Cause 분석 및 문제 해결
    1. 모니터링 중인 Trace 데이터를 통해 요청 경로 중 어디서 문제가 발생하는지 확인
    2. 문제가 발생한 서비스의 Log 데이터를 통해 원인 파악 및 문제 해결

이렇게 Error Budget은 우리가 앞으로 어떤 전략을 가져야 할지 판단하는 데에 큰 도움이 됩니다.


마무리

(OpenTelemetry와 Grafana로 직접 구현한 SLO 대시보드입니다.)

SLI와 SLO, Error Budget은 등장 이후로 꾸준히 관심을 받고 프로덕션에도 활용되고 있는 지표들입니다. 만약 이제 막 옵저버빌리티를 도입하거나 옵저버빌리티의 방향성을 잡고 싶다면 이번 아티클에서 소개해드린 지표들을 활용해보세요. 분명 도움이 될 겁니다.

제가 2025 WhaTap Observe Summit에서 발표하는 주제도 이 지표들과 큰 연관이 있는데요. 발표를 통해 이 지표들과 함께 사용할 수 있는 다양한 방법들과 지속가능한 옵저버빌리티 도입 기대효과를 함께 소개할 예정입니다.

그럼 다음 아티클에서 더 유익하고 흥미로운 주제로 찾아오겠습니다.

감사합니다.😸


참고 자료


이번 아티클은 어떠셨나요?

이번 글의 주제에 대해 어떻게 생각하는지 알려주세요! 더 나은 아티클을 전달해드리기 위해 아래 폼에서 짧은 피드백을 받고 있어요.

👉 피드백 보내기 (1~2분 소요)

여러분들의 소중한 의견은 Aiden’s Lab에 큰 힘이 됩니다!