이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 24시간 운영되는 사내 알림 서비스에서 야간에 장애가 반복되는 문제가 있었습니다. 로그를 보면 매일 새벽 2~3시 사이에 연결이 끊기는데 원인을 못 찾고 있었습니다.
제가 맡은 건 로그를 시간대별로 분석하는 작업이었습니다. 처음에는 무작정 grep으로 에러 메시지만 찾았는데, 패턴이 안 보였습니다. DB 커넥션 수를 시간별로 시각화해봤더니 새벽에 커넥션 풀이 소진되는 게 보였습니다. 알고 보니 배치 작업이 밤마다 돌면서 커넥션을 반환하지 않고 있었습니다.
그 분석 결과를 선임 개발자에게 공유했고, 배치 작업 코드에서 커넥션 반환 누락을 수정했더니 이후 2주 동안 같은 장애가 사라졌습니다. 로그만 읽어서는 안 되고 지표를 시각화해야 패턴이 보인다는 걸 그때 배웠습니다.
졸업 프로젝트로 만든 서비스를 실제로 배포했을 때, 처음에는 문제가 생겨도 사용자가 알려주기 전에는 몰랐습니다. 그게 불안해서 간단한 헬스 체크 엔드포인트를 만들고, 무료 모니터링 도구로 5분 간격으로 상태를 확인하도록 설정했습니다.
한 번은 EC2가 예고 없이 멈췄는데, 알림을 받고 10분 안에 재시작할 수 있었습니다. 그 전에는 몇 시간씩 서비스가 죽어 있어도 몰랐을 텐데, 직접 경험해보니 모니터링이 선택이 아니라는 걸 실감했습니다.
이후에는 응답 시간 지표도 추가했는데, 특정 엔드포인트가 3초 이상 걸리는 걸 발견하고 쿼리를 개선했습니다. 모니터링이 없었으면 그냥 넘어갔을 문제였습니다. 대규모 시스템에서는 이게 더 정밀해야 하겠지만, 개념은 같다고 생각합니다.
학교 동아리 서버를 관리할 때, 가끔 서버가 느려진다는 제보가 들어왔는데 이유를 알 수 없었습니다. 처음에는 제보가 올 때마다 직접 접속해서 top 명령어로 자원 사용률을 봤는데, 그때는 이미 정상 상태로 돌아와 있었습니다.
그래서 5분 간격으로 CPU·메모리·디스크 사용률을 로그 파일에 기록하는 스크립트를 cron으로 돌렸습니다. 일주일 뒤 보니 특정 시간대에 PHP 프로세스가 급증하는 패턴이 보였습니다. 동아리 게시판에 파일 첨부가 많은 시간대와 겹쳤고, 임시 파일이 정리되지 않아 디스크가 차는 문제였습니다.
정리 스크립트를 추가하고 나서 불만 제보가 없어졌습니다. 대규모 시스템과 비교하면 초라한 경험이지만, "문제는 발생하는 순간이 아니라 기록된 패턴에서 보인다"는 감각은 그때 생겼습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.