이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 추론 서버에 Prometheus를 붙이고 Grafana로 대시보드를 만들었습니다. 처음에는 단순히 메트릭이 보이는 것 자체에 만족했으나, 어느 날 p95 레이턴시가 30분 넘게 500ms를 초과하고 있었는데 아무도 몰랐던 사건이 발생했습니다.
알람 규칙이 없었던 것이 원인이었고, 이후에 AlertManager로 p95가 200ms를 2분 이상 초과하면 슬랙 알림이 오도록 설정했습니다. 알람을 너무 예민하게 잡으면 알림 피로가 생긴다고 들어서, 5분 평균 기준으로 조정했습니다.
Grafana 대시보드에는 요청 수, 오류율, p50/p95/p99 레이턴시, GPU 메모리 사용률을 한 화면에 배치했습니다. 그 결과 이상 징후를 10분 내로 파악할 수 있게 되었고, 팀장님께서 이제 모니터링다운 모니터링이 되었다고 말씀하셨습니다.
졸업 프로젝트에서 LLM 서빙 서버를 운영할 때, Prometheus가 기본 제공하는 CPU/메모리 메트릭만으론 왜 가끔 응답이 오래 걸리는지 원인을 못 찾겠는 문제가 있었어요.
의심한 건 입력 토큰 길이였어요. 그래서 prometheus_client 라이브러리로 요청별 입력 토큰 수를 히스토그램으로 직접 수집했습니다. Grafana에서 보니 토큰 500개 이상 구간이 전체 레이턴시 스파이크의 80%와 겹쳤어요.
이후 토큰 1,000개 이상 요청은 별도 큐로 분리하는 로직을 추가했고, 일반 요청 레이턴시가 안정됐습니다. 모델 서빙은 인프라 메트릭만 보면 안 되고 입력 특성도 같이 모니터링해야 한다는 걸 이 경험에서 배웠어요.
실제 모델 서빙 모니터링 경험은 많지 않지만, 개인 프로젝트에서 FastAPI 서버에 Prometheus를 붙이고 Grafana로 시각화해봤어요.
prometheus_fastapi_instrumentator를 쓰니 코드 몇 줄로 기본 메트릭이 수집됐는데, 처음엔 어떤 메트릭이 의미 있는지 몰라서 대시보드에 50개 가까운 패널을 넣었어요. 보다보니 대부분 노이즈였고, 결국 요청 수, 오류율, 레이턴시 세 가지만 남겼습니다.
모니터링에서 제일 어려운 건 무엇을 볼 것인가를 결정하는 것이라는 걸 그때 느꼈어요. 모델 서빙이라면 추가로 GPU 메모리 사용률과 모델 로드 시간은 기본으로 봐야 한다고 생각합니다. 실제 운영 환경에서 더 의미 있는 지표를 찾아가는 경험을 쌓고 싶어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 라인 DBA 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.