이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 SLO를 처음으로 직접 설정해보았습니다. 가용성 99.5%, 응답 시간 P95 기준 500ms 이내를 목표로 잡고, 이 기준을 기반으로 알림 임계값을 설정했습니다. 에러 예산 개념을 적용해보았는데, 한 달 허용 다운타임을 계산하고 이를 소진하는 속도를 모니터링하는 방식이 단순 알림보다 운영 판단에 더 유용한 맥락을 제공한다는 것을 배웠습니다.
알림 피로도 경험했는데, 처음에는 임계값을 너무 낮게 설정해 의미 없는 알림이 자주 발생하고 실제 중요한 알림을 놓치는 상황이 생겼습니다. 이후 알림을 심각도로 분류해 즉시 대응이 필요한 것과 다음 날 확인해도 되는 것을 구분했습니다. SRE 수준의 운영 경험은 아직 부족하지만, SLO는 기술 지표보다 서비스 신뢰도에 대한 약속이라는 결을 이 실험에서 얻었습니다.
SLO를 설정하고 나서 Error Budget이 어떻게 쓰이는지 추적하는 것이 가장 어려웠습니다. 단순히 99.5% 달성 여부만 보는 것과 잔여 예산이 얼마나 빠르게 소진되는지를 보는 것은 운영 판단에서 차이가 컸습니다. Burn Rate 알람을 설정해서 예산이 평소보다 빠르게 소진되면 즉시 알림이 오도록 했습니다. 이 지표가 있으니 새 배포 여부를 결정할 때 직관이 아니라 수치 기반으로 판단할 수 있었습니다. 잔여 예산이 충분하면 배포를 진행하고, 소진 속도가 빠르면 안정화에 집중하는 패턴이 팀 내에서 공유됐습니다.
SLO는 측정이 가능할 때 비로소 의미가 생기는 결이라는 것을 이 경험에서 배웠습니다. 목표를 세우는 것보다 목표 달성 여부를 추적하는 구조가 더 어렵다는 것도 함께 느꼈습니다.
SLO를 운영하면서 알람 피로(Alert Fatigue)가 생각보다 큰 문제였습니다. CPU나 메모리 임계값 기반 알람이 자주 울렸는데, 실제 서비스에 영향이 없는 경우도 많아서 알람에 반응하지 않는 습관이 생기기 시작했습니다. 알람 기준을 CPU 사용률에서 사용자가 실제로 느끼는 오류율과 응답 시간으로 바꿨습니다. 원인 기반이 아니라 증상 기반 알람으로 전환하니, 알람이 울렸을 때 실제로 사용자에게 영향이 생긴 경우가 훨씬 많아졌습니다. 알람 수가 줄었고, 울릴 때마다 진지하게 확인하는 결이 생겼습니다.
알람의 신뢰도가 높아야 알람에 반응하는 문화가 생기는 결이 있다는 것을 이 경험에서 배웠습니다. 노이즈가 많은 알람은 없는 것보다 나쁠 수 있다는 결도 함께 남았습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 코빗 인프라/클라우드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.