이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
학부 프로젝트에서 Prometheus + Grafana 조합으로 서버 상태 모니터링 대시보드를 구축했습니다. Node Exporter로 CPU·메모리·디스크 사용률을 수집하고, 임계값 초과 시 알람이 가도록 AlertManager를 연결했습니다. 처음에는 알람이 너무 자주 발생해 피로감이 쌓이는 문제가 있었고, 임계값을 단순 절댓값이 아닌 이동 평균 기준으로 바꾼 뒤 오탐이 줄었습니다. 서비스 중단 방지를 위해 헬스체크 엔드포인트도 별도로 만들어 5초마다 응답을 확인하는 구조를 추가했습니다. 모니터링은 도구보다 무엇을 봐야 하는지 아는 것이 먼저라는 걸 그때 배웠습니다.
모니터링은 무엇을 봐야 하는지 아는 것이 먼저입니다. 도구는 그 다음이고, 경보 피로 없이 의미 있는 알람만 오는 구조가 진짜 시스템입니다.
모니터링 시스템을 구축한 후 경고 임계값(threshold) 설정이 생각보다 어렵다는 걸 경험에서 배웠습니다. CPU 사용률 90% 초과 시 알람을 설정했더니 정상적인 배치 작업 때마다 알람이 울려서 알람 피로감이 생겼습니다. 어떤 상황이 실제로 대응이 필요한 이상 상태인지를 구분하는 기준이 없으면, 알람 피로(alert fatigue)로 오히려 중요한 경고를 놓치는 역효과가 생깁니다.
임계값을 낮게 설정하면 민감하지만 노이즈가 많고, 높게 설정하면 놓치는 문제가 생기는 트레이드오프를 경험했습니다. 이후에는 단기 스파이크와 지속 상승을 구분해서, 일정 시간 이상 지속될 때만 알람이 울리도록 조건을 바꿨습니다. 모니터링은 수집보다 의미있는 알람을 만드는 것이 더 어렵다는 걸 그 경험에서 이해했습니다.
알람 피로(alert fatigue) 방지가 모니터링 시스템 운영의 핵심 과제입니다.
모니터링 시스템을 설계할 때 무엇을 측정할지가 어떻게 시각화할지보다 먼저라는 걸 배웠습니다. 처음에는 측정할 수 있는 것을 전부 모으려 했는데, 데이터가 많을수록 정작 중요한 것이 묻히는 경우가 생겼습니다. 사용자 경험에 직접 영향을 주는 지표를 먼저 정하고, 그 지표가 변할 때 원인을 추적할 수 있는 내부 지표를 추가하는 방식이 더 합리적이라는 걸 이해했습니다.
문제가 생겼을 때 어디를 먼저 봐야 하는지가 명확한 대시보드가 잘 설계된 모니터링이라고 생각합니다. 메트릭을 수집하고 시각화하는 기술적인 부분보다, 어떤 상태를 정상으로 보고 어떤 상태를 이상으로 보는지를 정의하는 것이 더 중요한 설계 결정입니다. 좋은 모니터링은 이상을 빠르게 찾는 것이 아니라 정상을 잘 정의하는 것에서 시작합니다.
사용자 경험에 직접 영향을 주는 지표가 모니터링 설계의 출발점입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 당근마켓 네트워크 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.