이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
대표 프로젝트는 대용량 로그 수집 파이프라인입니다. 본인은 수집 단의 설계와 구현을 맡았습니다.
기술은 메시지 큐 기반 비동기 수집으로 갔습니다. 동기 수집도 가능했지만, 수집량이 시간대별로 크게 출렁이는 자리라 피크에서 데이터가 유실되지 않게 버퍼링이 필요하다고 봤기 때문입니다.
가장 큰 트러블은 피크 때 일부 메시지가 중복 처리되는 자리였습니다. 처음엔 큐 설정 문제로 봤지만, 추측을 멈추고 재처리 로그를 따로 모아보니 원인은 컨슈머가 처리 완료를 늦게 알리는 구간이었습니다. 처리 완료 신호 시점을 앞당기고 멱등 처리를 더해, 중복률이 사실상 사라졌습니다.
이 자리에서 배운 건 분산 처리의 버그는 보통 설정이 아니라 시점의 문제에서 나온다는 부분이었습니다.
대표 프로젝트는 학부 졸업작품인 영상 분류 서비스입니다. 4명 팀이었고, 본인은 모델 서빙과 API 자리를 맡았습니다.
팀이 만든 모델을 실제 요청에 응답하는 형태로 올리는 일이 본인 몫이었습니다. 기술은 경량 추론 서버 + 캐시로 갔는데, 같은 이미지 요청이 자주 반복되는 자리라 캐시가 응답을 크게 줄일 거라 봤기 때문입니다.
가장 큰 트러블은 간헐적으로 추론 결과가 뒤섞여 응답되는 자리였습니다. 로그를 좁혀보니 동시 요청 시 캐시 키가 충돌하는 구간이었습니다. 키에 입력 해시를 더해 분리하자 문제가 사라졌습니다. 평균 응답 시간도 절반 이하가 됐습니다.
팀 프로젝트지만 이 자리는 본인이 설계부터 디버깅까지 끝낸 자리였습니다.
대표 프로젝트는 사이드로 만든 일정 공유 서비스입니다. 혼자 기획·구현을 다 했습니다.
기술은 익숙한 서버리스 구성으로 갔습니다. 빠르게 배포할 수 있다는 점이 컸는데, 솔직히 그 선택이 나중에 발목을 잡은 자리도 있었습니다. 동시 사용자가 늘자 콜드 스타트로 응답이 들쭉날쭉한 자리가 생겼습니다.
그 자리에서 측정으로 콜드 스타트 구간을 확인하고, 자주 쓰이는 함수만 웜 상태로 유지하는 방식으로 완화했습니다. 완전히 없애진 못했고, 트래픽이 더 커지면 구성을 바꿔야 한다는 한계까지 정리해 기록으로 남겼습니다.
이 자리에서 배운 건 처음의 빠른 선택이 항상 옳진 않으며, 그 한계를 정확히 남기는 일이 다음 선택의 자산이 된다는 부분이었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 네이버 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.