이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 검색 기능이 느리다는 피드백이 왔습니다. 처음에는 코드를 보면서 감으로 캐시가 문제일 것이라고 생각했습니다. 그러나 캐시를 추가해도 상황이 나아지지 않았습니다.
결국 요청 로그를 수집하여 분석하기로 결정했습니다. 검색 키워드별 응답 시간을 집계하니, 특정 키워드 패턴에서만 응답이 5배 이상 느린 것을 발견했습니다. 알고 보니 한글 키워드에서만 풀스캔이 발생하고 있었으며, 이는 인덱스가 한글 형태소 분석을 지원하지 않아서였습니다.
형태소 분석 인덱스를 추가하니 해당 케이스의 응답 시간이 200ms 이하로 떨어졌습니다. 감으로 먼저 덤비지 않고 데이터로 좁혀서 원인을 찾는 것이 훨씬 빠르다는 것을 그때 배웠습니다.
캡스톤 프로젝트 배포 후 1주일 뒤에 전체 사용자의 40%가 회원가입 화면에서 이탈한다는 걸 이벤트 로그로 발견했어요. 처음엔 UI가 별로라 그렇겠거니 했는데, 데이터를 더 보니 모바일에서만 이탈이 집중되고 있었습니다.
모바일로 직접 접속해보니 이메일 입력 필드를 탭하면 키보드가 올라오면서 '다음' 버튼이 가려지는 문제가 있었어요. 데이터를 안 봤으면 모르고 지나쳤을 버그였습니다. PC 환경에서는 전혀 재현이 안 됐는데, 기기별로 나눠서 데이터를 보지 않으면 이런 패턴은 발견하기 어렵다고 느꼈어요.
버튼 위치를 수정하고 나서 모바일 회원가입 완료율이 38%에서 71%로 올라갔어요. 데이터 기반 접근은 어디를 봐야 할지 좁혀준다는 게 제일 큰 장점이라고 느꼈습니다.
인턴 때 배포 후 Grafana 대시보드에서 5xx 에러율이 갑자기 3%를 넘는 것을 보고 조사를 시작했어요. 처음엔 서버 문제인지 코드 문제인지 몰라서 막막했습니다.
에러 로그를 보니 특정 엔드포인트 하나에서만 에러가 집중되고 있었어요. 해당 코드를 보니 이번 배포에서 바뀐 쿼리에서 null 처리가 빠진 게 원인이었습니다.
10분 안에 원인을 찾고 핫픽스를 배포했어요. 에러가 분산되어 있었다면 찾는 데 훨씬 오래 걸렸을 텐데, 로그에 충분한 컨텍스트가 있어서 격리가 빨랐습니다. 데이터 기반 디버깅은 먼저 범위를 좁히는 것부터 시작해야 한다는 걸 이때 배웠어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 누아 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.