이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
실시간 모니터링 경험에서 가장 많이 사용한 도구는 `ELK` 스택이었습니다. Elasticsearch에 로그를 수집하고 Kibana 대시보드로 시각화해, 특정 에러 패턴이 늘어나는 시점을 빠르게 파악할 수 있었습니다.
시스템 메트릭은 Prometheus와 Grafana로 관리했습니다. CPU·메모리·응답 시간 그래프를 배포 이력과 겹쳐보면 어떤 변경이 성능 변화를 일으켰는지 추적하기 수월했습니다. 임계치 초과 시 Slack 알림이 오는 구조를 만들어 야간 장애도 빠르게 감지했습니다.
로그 분석에서 인상적이었던 경험은 단일 에러 로그보다 패턴을 보는 것이 더 유용하다는 점이었습니다. 같은 에러가 특정 시간대에 몰리거나 특정 사용자 행동과 연결된 것을 발견하면 근본 원인을 훨씬 빠르게 찾을 수 있었습니다.
모니터링을 처음 설정할 때 알람이 너무 많이 오는 문제를 경험했습니다. 여러 지표에 임계치를 설정했는데, 일시적인 스파이크에도 알람이 울리니 처음에는 확인하다가 나중에는 무시하게 됐습니다. 알람이 무시되기 시작하면 진짜 장애도 늦게 발견된다는 것을 실제로 경험했습니다. 이후에는 알람 임계치를 상위 1퍼센트 응답 시간 기준으로 재설정하고, 5분 이상 지속되는 경우에만 알림이 오도록 조건을 추가했습니다. 로그 레벨도 처음에 정리하지 않으면 대부분이 오류 레벨로 찍혀서 실제 문제가 노이즈에 묻히는 경험을 했습니다. 또한 디버깅 목적으로 요청 파라미터를 그대로 로그에 찍다가 사용자 개인정보가 남는 것을 뒤늦게 발견했는데, 민감한 값은 처음부터 마스킹하는 것이 표준이라는 것을 배웠습니다. 모니터링은 많이 설정하는 것보다 노이즈를 줄이고 신호를 명확히 하는 것이 더 중요하다는 것을 이 경험에서 배웠습니다.
실시간 모니터링에서 단일 서비스 로그만으로는 원인을 찾기 어려운 경우를 경험했습니다. 사용자 요청이 여러 서비스를 거치는 구조에서 응답이 느려졌는데, 어느 서비스에서 지연이 생긴 건지 각 서비스 로그를 따로 보면서 시간을 맞춰야 했습니다. 요청마다 고유한 추적 아이디를 붙여서 서비스 간에 전달하는 방식을 적용했더니, 하나의 요청이 어느 서비스를 거쳤고 각 단계에서 얼마나 걸렸는지 하나의 흐름으로 볼 수 있었습니다. 지연이 생긴 구간이 외부 API 호출에서 발생한 것인지 데이터베이스 조회에서 발생한 것인지 명확히 보이니, 최적화 대상을 찾는 시간이 줄었습니다. 처음에는 추적 아이디를 일부 서비스에만 전파했는데, 전파가 끊기면 그 이후 흐름이 보이지 않아서 모든 서비스에서 일관되게 전달하는 것이 중요하다는 것을 배웠습니다. 분산 시스템에서 문제 원인을 빠르게 찾으려면 로그와 메트릭만으로는 부족하고 서비스 간 흐름을 추적하는 구조가 필요하다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 누아 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.