이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 추론 API를 배포한 후, 처음에는 단순히 에러율만 확인했습니다. 그러나 팀장님께서 p95 레이턴시가 800ms를 넘으면 서비스에 영향이 있다고 말씀하셔서 Grafana에 지표를 추가했습니다.
지표를 추가한 결과, 입력 길이가 긴 요청이 레이턴시 스파이크의 주원인임을 알게 되었습니다. 그래서 입력 토큰 512개 이상 요청을 별도 큐로 분리하였고, 일반 요청의 p95가 300ms로 떨어졌습니다.
고도화 과정에서 팀원이 모델 가중치를 FP16으로 변경하자고 제안했으나, 저는 정확도 저하를 우려하여 반대했습니다. 결국 스테이징에서 2주간 A/B 테스트를 진행하였고, 정확도 차이가 0.3%p 이하라는 것이 확인되어 전환하게 되었습니다. 의견 충돌이 데이터로 해결된 경험이 기억에 남습니다.
팀 프로젝트에서 검색 기능을 만들고 배포했는데, 사용자가 얼마나 쓰는지 전혀 몰랐어요. 코드는 배포됐지만 누가 어떤 검색을 하는지 로그가 없어서, 개선 방향을 잡을 수가 없었습니다.
2주 뒤 간단한 이벤트 로그를 추가해서 검색 키워드, 클릭률, 재검색률을 집계했어요. 재검색률이 45%나 됐는데, 원하는 결과를 못 찾은 사람이 절반 가까이라는 뜻이었습니다. 이 숫자를 보기 전까지는 그냥 검색이 잘 된다고 생각하고 있었어요.
이 지표를 바탕으로 검색 알고리즘에 형태소 분석을 추가했고, 재검색률이 2주 만에 22%로 줄었어요. 팀장님이 이전엔 직관으로 개선 방향을 정했는데, 지표가 생기니 무엇을 먼저 고쳐야 할지 명확해졌다고 했습니다. 배포 후 지표를 심는 게 개발만큼 중요하다는 걸 이때 배웠어요.
아직 실제 프로덕션 제품을 운영해본 경험은 없지만, 캡스톤 프로젝트에서 배포 후 지표를 직접 설계해본 적이 있어요.
에러율, 응답 시간, 일별 요청 수 세 가지를 기본으로 잡았는데, 나중에 보니 이것만으로는 기능이 얼마나 잘 쓰이는지 알 수가 없었어요. 그래서 주요 기능별 사용 횟수도 추가했습니다.
지표를 보면서 한 번도 쓰이지 않은 기능이 전체의 30%라는 걸 발견했어요. 그 기능에 가장 많은 시간을 쏟았는데, 사용자에게는 필요 없었던 거였습니다. 다음엔 배포 전에 어떤 지표로 성과를 확인할지 먼저 정해두고 개발에 들어가야겠다고 생각했어요. 실제 서비스에선 비즈니스 지표까지 연결해서 보는 것이 중요하다고 공부하고 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.