이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
백엔드 서비스 모니터링을 위해 Prometheus와 Grafana를 직접 구성한 경험이 있습니다. 처음에는 서버가 다운됐는지 여부만 확인했는데, 실제로 중요한 것은 응답 시간 증가나 오류율 상승 같은 선행 신호라는 것을 장애 경험 이후 깨달았습니다.
커스텀 메트릭을 애플리케이션 코드에 직접 추가해 큐 적체 같은 비즈니스 레벨 지표도 수집하도록 설정했습니다. Grafana 대시보드에서 알림 임계값을 설정해 특정 조건이 5분 이상 지속되면 슬랙으로 알림이 오도록 구성했고, 실제로 트래픽 급증 시 미리 알림을 받고 대응한 경험이 있습니다. 운영 자동화 측면에서는 Ansible로 서버 초기 설정 스크립트를 만들어 반복 수작업을 줄였습니다. 모니터링은 문제가 생긴 후 보는 것이 아니라 이상 징후를 먼저 잡는 것이 목적이라는 결을 얻었습니다.
모니터링에서 메트릭만으로는 원인을 좁히기 어려운 순간이 있었습니다. 특정 엔드포인트에서 간헐적으로 5xx가 발생했는데, 지표에서는 에러율만 보이고 어떤 요청이 왜 실패했는지를 파악하려면 로그를 봐야 했습니다. ELK 스택을 서비스에 붙이고 구조화된 JSON 로그를 남기도록 바꿨습니다. 이후 에러 발생 시 Kibana에서 request_id로 한 요청의 전체 흐름을 추적할 수 있게 됐고, 원인이 특정 페이로드 크기 초과였다는 것을 10분 안에 확인했습니다. 처음에는 로그 형식이 서비스마다 달라 집계가 어려웠는데, 로그 스키마를 팀에서 표준화하고 나서 검색이 훨씬 빨라졌습니다. 메트릭과 로그는 서로 다른 결의 신호를 담고 있어서 함께 봐야 장애를 제대로 이해하는 결이 있습니다.
모니터링 알람을 처음 설정했을 때 더 민감하면 더 빨리 잡는다는 생각에 임계값을 낮게 잡았습니다. 결과적으로 슬랙 알람이 하루에 수십 건 쏟아졌고, 팀원들이 알람을 무시하기 시작했습니다. 실제 장애 알람이 왔을 때도 노이즈에 묻혀 늦게 확인한 적이 있었습니다. 이후 알람 기준을 이 알람이 오면 반드시 확인이 필요한가를 기준으로 재검토했습니다.
5분 이상 지속되는 조건을 추가했더니 순간 스파이크는 걸러지고 지속적인 이상 징후만 알람이 오게 됐습니다. 알람 수가 줄어들자 팀이 다시 알람을 진지하게 보기 시작했고, 실제 장애 대응 속도가 오히려 빨라졌습니다. 모니터링은 많이 감지하는 것이 아니라 의미 있는 것을 감지하는 결이라는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 올거나이즈 인프라/클라우드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.