이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
모니터링 시스템을 구축하면서 가장 어려웠던 건 알림 피로(alert fatigue) 문제였습니다. 처음에 임계치를 낮게 잡았더니 하루에 수십 건의 알림이 오면서 정작 중요한 이슈를 놓치는 상황이 생겼습니다. 이를 해결하기 위해 알림을 심각도 기준으로 3단계로 나누고, 긴급 이슈만 즉시 알림으로 처리하고 나머지는 배치 요약으로 전환했습니다.
노이즈가 줄자 실제 대응 속도가 올라갔습니다. 임계치 설정은 한 번 정하면 끝이 아니라 운영 패턴 변화에 따라 주기적으로 재검토해야 한다는 것도 그때 배웠습니다. 앞으로도 알림 심각도를 나누고 노이즈를 줄이는 방식을 유지하겠습니다. 알림이 많으면 오히려 중요한 이슈를 놓치는 구조가 됩니다. 임계치는 한 번 설정하면 끝이 아니라 운영 패턴 변화에 따라 주기적으로 재검토해야 합니다. 노이즈가 줄어야 실제 대응 속도가 올라갑니다.
알림 설계는 처음부터 심각도 기준을 나눠서 구조화해야 운영할수록 관리가 쉬워집니다.
가장 어려웠던 건 처음에 어떤 지표를 모니터링해야 하는지 파악 자체가 안 됐던 것입니다. 이슈가 생기면 사후에 확인하는 방식으로 대응했는데, 원인을 추적할 수 있는 지표가 쌓여 있지 않아 디버깅이 어려운 상황이 반복됐습니다.
이를 해결하기 위해 서비스의 요청~응답 전체 경로를 단계별로 적어보고, 각 단계에서 무엇이 잘못될 수 있는지를 먼저 정의했습니다. 그런 다음 그 실패 유형별로 측정 가능한 지표를 하나씩 매핑했습니다.
처음 설계한 대시보드는 지표가 30개가 넘었는데, 실제로는 핵심 지표 5~7개만 실시간으로 보고 나머지는 이상 발생 시에만 드릴다운하는 구조로 줄였습니다. 무엇을 보여줄지보다 무엇을 보이지 않게 할지가 모니터링 설계의 절반이라는 걸 그때 배웠습니다.
모니터링 시스템을 여러 팀에 확장하면서 생긴 도전은 팀마다 자체 대시보드를 만들다 보니 같은 지표를 다르게 집계하는 문제였습니다. 같은 에러율이라도 어떤 팀은 5xx만 포함하고 어떤 팀은 4xx까지 포함하는 방식이라, 장애 발생 시 두 팀이 서로 다른 수치를 보고 논쟁이 생기는 상황이 반복됐습니다.
해결을 위해 핵심 지표 이름과 집계 방식을 문서화한 지표 사전을 작성했고, 팀 간 합의를 거쳐 중앙 집계 쿼리를 공통으로 관리하는 방식으로 전환했습니다. 이 과정이 생각보다 오래 걸린 이유는 기술적 결정이 아니라 팀 간 합의가 필요한 문제였기 때문입니다.
지표 정의가 통일된 이후에는 장애 원인 분석 회의 시간이 크게 줄었습니다. 모니터링은 도구 이전에 팀 간 언어를 맞추는 작업이라는 걸 그 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 SRE 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.