이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 서비스 모니터링 대시보드를 처음 구성해보면서 관찰 가능성이 운영에서 얼마나 중요한지 직접 느꼈습니다. Prometheus로 메트릭을 수집하고 Grafana로 시각화하는 스택을 셋업했는데, 단순 CPU·메모리 사용률만 보는 것보다 서비스 레벨 지표인 오류율과 응답 분위수를 함께 보는 게 장애 징후를 훨씬 빨리 감지하는 데 도움이 됐습니다.
알림 임계값 설정이 결국 팀의 피로도를 결정한다는 것도 배웠는데, 처음엔 너무 촘촘하게 잡아서 노이즈 알림이 많았고 나중에 기준을 조정했습니다. NewRelic은 별도 프로젝트에서 APM 트레이싱용으로 써봤는데, 어느 서비스에서 지연이 발생하는지 한 화면에서 파악할 수 있어 유용했습니다.
관찰 가능성 도구를 처음 설정할 때 Prometheus에 커스텀 메트릭과 레이블을 추가하는 작업을 직접 했습니다. 요청마다 고유한 ID를 레이블에 추가했더니, 시간이 지나면서 Prometheus 메모리 사용량이 계속 늘어나는 문제가 생겼습니다. 레이블 값의 종류가 너무 많아지는 고카디널리티 문제였습니다. 요청 ID처럼 값이 계속 늘어나는 것은 레이블에 넣으면 안 된다는 것을 그때 처음 배웠습니다. 레이블은 사용자 역할·엔드포인트·상태 코드처럼 값의 종류가 제한된 것만 쓰도록 정리했습니다.
도구를 직접 설정해봐야 왜 그런 제약이 있는지 체득되는 결이 있다는 것을 이 경험에서 배웠습니다. 매뉴얼만 읽을 때는 몰랐던 실제 운영의 제약이 직접 장애를 경험하면서 명확해졌습니다.
모니터링 도구를 NewRelic에서 Prometheus+Grafana로 전환하는 작업에 참여했습니다. 처음에는 도구가 바뀌면 처음부터 다시 설정해야 한다고 생각했는데, 메트릭 설계 원칙 자체는 도구와 무관하게 유지됐습니다. 어떤 지표를 볼 것인지, 알람 기준을 어디서 잡을 것인지, 대시보드에서 무엇을 먼저 보여줄 것인지 — 이 결정들은 NewRelic에서도 Prometheus에서도 같은 사고 과정이었습니다. 다른 점은 Prometheus가 세부 설정을 직접 제어할 수 있어 더 유연하지만 설정 부담이 크다는 것이었습니다.
도구를 바꿔도 살아남는 능력은 특정 도구 사용법이 아니라 무엇을 봐야 하는지를 아는 결이라는 것을 이 전환 경험에서 배웠습니다. 다음 도구가 뭐가 되어도 메트릭 설계 원칙이 먼저라는 결이 남았습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 코빗 인프라/클라우드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.