이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
개인 프로젝트에 Grafana를 연결하여 응답 시간과 에러율을 대시보드로 보고 있었는데, 어느 날 에러율이 갑자기 5%에서 30%로 상승하는 것을 발견했습니다. 사용자 민원이 오기 전에 제가 먼저 알게 되었습니다.
에러 로그를 확인하니 외부 API 호출 부분에서 타임아웃이 반복되고 있었습니다. 외부 서비스 상태 페이지를 보니 장애가 발생하였고, 제 서비스는 그 응답을 기다리다가 전체가 느려지는 상황이었습니다. 서킷 브레이커를 추가하여 외부 API 실패 시 폴백 처리하도록 변경한 후 에러율이 정상으로 돌아왔습니다.
그 경험에서 모니터링이 있으면 문제를 사용자보다 제가 먼저 알 수 있다는 것을 직접 느꼈습니다. 데이터가 있어야 빠르게 원인도 좁힐 수 있습니다. 그 경험이 모니터링을 서비스의 일부로 생각하게 해주었습니다.
팀 프로젝트 배포 후 특정 API 응답이 3~5초 걸린다는 피드백이 들어왔는데, 로컬에서는 빠른 이유를 몰랐어요.
DB 슬로우 쿼리 로그를 활성화해서 수집했더니 특정 조회 쿼리가 매번 전체 테이블을 스캔하고 있었어요. 자주 조회하는 컬럼에 인덱스를 추가하니 응답시간이 4초에서 0.2초로 줄었습니다. 로그가 없었으면 어느 쿼리가 문제인지 알 방법이 없었을 거예요.
그 경험에서 성능 문제는 직관이 아니라 로그로 찾아야 한다는 걸 배웠어요. 빠를 것 같은 쿼리도 데이터가 쌓이면 느려진다는 것도요. 이후로는 배포 전에 슬로우 쿼리 로그를 활성화해두는 걸 기본으로 합니다. 그 경험이 성능 진단 방법을 바꿔줬어요.
서비스를 운영하다가 에러 로그를 주기적으로 보던 중 특정 API에서 타임아웃이 하루 5건에서 20건으로 늘어나는 패턴을 발견했어요. 아직 사용자 민원은 없었지만 추세가 이상했습니다.
해당 API 코드를 보니 캐시 만료와 DB 조회가 겹치는 구간에서 부하가 몰리는 구조가 있었어요. 트래픽이 적을 때는 괜찮았는데 사용자가 늘면서 드러난 문제였습니다. 캐시 갱신 로직을 비동기로 바꾸고 나서 타임아웃이 사라졌어요. 민원이 터지기 전에 잡아서 다행이었어요.
모니터링의 진짜 가치는 장애가 났을 때 빠르게 아는 것이 아니라 나기 전에 아는 것이라는 걸 그 경험에서 느꼈어요. 절대값보다 추세를 보는 게 중요하다는 걸 배웠습니다. 그 경험이 로그를 정기적으로 보는 습관을 만들어줬어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.