이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
개인 서버를 운영하면서 문제가 생길 때 항상 SSH로 들어가 top을 보던 게 불편해서, 스터디에서 배운 Prometheus와 Grafana를 직접 설치해봤습니다. Node Exporter로 CPU, 메모리, 디스크 사용량을 수집하고 Grafana 대시보드에서 시각화했습니다. 처음에 Prometheus의 스크랩 간격을 5초로 설정했더니 서버 자체에 부하가 생겼고, 30초로 조정하니 안정됐습니다. 또 알림 설정을 빠뜨려서 디스크가 90%를 넘어도 모르고 있는 일이 한 번 있었고, 이후 Alertmanager를 연결했습니다. 작은 규모였지만 어떤 지표를 왜 봐야 하는지 생각해보는 계기가 됐습니다.
인프라 스터디에서 도커로 Prometheus와 Grafana를 띄우고 간단한 웹 앱의 메트릭을 수집하는 실습을 4주 동안 했습니다. 앱에 Prometheus 클라이언트 라이브러리를 붙여 요청 수, 응답 시간, 오류율을 수집했습니다. Grafana에서 대시보드를 만들 때 어떤 지표를 배치할지 고민하면서, 운영자가 즉시 상황을 파악할 수 있는 핵심 지표 3~4개를 먼저 넣고 세부 지표는 별도 패널에 두는 방식이 읽기 좋다는 걸 경험으로 배웠습니다. 실무 규모 운영 경험은 없지만, 모니터링 도구의 기본 흐름은 이해했습니다.
처음에 Grafana를 써봤을 때 데이터 소스 없이 그냥 설치만 하고 뭘 봐야 하는지 몰랐습니다. Prometheus가 메트릭을 수집하는 역할이고 Grafana는 그걸 시각화하는 역할이라는 구조를 스터디에서 배우고 나서야 제대로 연결했습니다. 이후 Prometheus + Grafana 조합으로 개인 서버 기본 지표를 시각화했는데, 대시보드를 만들면서 지표 이름 문법이 헷갈려서 PromQL 쿼리를 여러 번 틀렸습니다. 그 과정에서 PromQL 기초를 익혔습니다. 실무에서는 어떤 지표가 실제로 중요한지 판단하는 경험이 더 필요하다는 걸 알고 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 인프라/클라우드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.