이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 서비스 관측가능성(Observability) 체계를 처음 구성해봤습니다. Prometheus로 메트릭을 수집하고 Grafana로 시각화하는 스택을 설정했는데, 메트릭·로그·트레이스 세 가지를 모두 확보해야 장애 원인을 빠르게 추적할 수 있다는 걸 실제 대응 과정에서 배웠습니다. 로그만 있을 때는 어느 서비스에서 지연이 시작됐는지 추적하는 데 시간이 오래 걸렸는데, 분산 트레이싱을 추가하니 호출 경로가 한눈에 보였습니다.
도구 선택의 기준은 개별 기능보다 세 가지 신호가 서로 연결되는가였는데, 메트릭에서 이상 징후를 발견하고 바로 관련 트레이스로 드릴다운할 수 있는 구조가 장애 해결 시간을 줄여줬습니다. 지금도 새 서비스를 배포할 때 관측 신호를 먼저 설계하는 방향을 따릅니다.
관측가능성 체계를 구축하면서 도구를 세팅하는 것보다 유지하는 것이 더 어렵다는 것을 배웠습니다. 처음에 알림을 여러 지표에 설정했는데, 기준을 잘못 잡으면 사소한 변화에도 알림이 와서 실제 문제를 구분하기 어려워졌습니다. 알림이 너무 많아지면 무시하게 되고, 무시하게 되면 관측가능성 체계가 있으나 마나 해지는 문제를 경험했습니다. 메트릭을 많이 수집할수록 저장 비용이 늘어나는 것도 고려해야 했는데, 처음에 모든 것을 수집하려다가 비용이 예상보다 커서 보존 기간과 수집 빈도를 조정해야 했습니다. 분산 트레이싱은 유용했지만 모든 요청을 추적하면 성능 오버헤드가 생겨서 샘플링 비율을 설정하는 것이 필요했습니다. 관측가능성 체계는 처음 세팅보다 노이즈를 줄이고 실제 신호에 집중하도록 지속적으로 조정하는 과정이 더 중요하다는 것을 이 경험에서 배웠습니다.
관측가능성 체계가 실제로 유용하다는 것을 처음 확신하게 된 것은 응답 지연 장애를 처리하면서였습니다. 메트릭 대시보드에서 특정 서비스의 응답 시간이 급격히 늘어난 것을 발견했는데, 메트릭만으로는 어느 구간에서 지연이 시작됐는지 알 수 없었습니다. 해당 시간대의 트레이스를 조회하니 외부 서비스 호출 구간에서 대부분의 시간이 소요되고 있다는 것이 시각적으로 보였습니다. 그 구간의 로그를 확인하니 외부 서비스에서 응답 지연이 시작된 정확한 시점을 확인할 수 있었습니다. 메트릭으로 이상 징후를 발견하고, 트레이스로 어느 구간인지 좁히고, 로그로 정확한 원인을 확인하는 흐름이 자연스럽게 작동하는 것을 경험했습니다. 세 가지 신호가 서로 연결되어 드릴다운할 수 있는 구조가 장애 대응 시간을 실질적으로 줄인다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 올거나이즈 인프라/클라우드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.