이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 AI 추천 기능을 기존 서비스에 붙이는 작업의 일부를 맡았습니다. 추천 모델 팀과 프론트엔드 팀 사이에서 인터페이스를 조율하는 역할이었습니다. 처음엔 추천 결과가 나오는 데 평균 2초 이상 걸려서 사용자 경험이 나빠지는 문제가 있었습니다. 모델 팀은 추론 속도를 더 줄이기 어렵다고 했고, 프론트엔드 팀은 로딩 표시를 추가하면 된다는 입장이었습니다. 저는 화면이 먼저 뜨고 추천 결과만 나중에 채워지는 구조를 제안했습니다. 두 팀 모두 가능하다고 해서 구현 방향을 정리해 공유했는데, API 응답 형식을 맞추는 과정에서 필드 명칭 불일치가 나왔습니다. 조율 단계에서 놓쳤던 부분이었습니다. 이후 인터페이스 명세를 먼저 문서로 정리하고 양쪽이 확인하는 순서를 추가했습니다. AI 기능을 서비스에 붙일 때 기술보다 인터페이스 합의가 먼저라는 걸 배웠습니다.
학교 프로젝트에서 AI 기반 식단 추천 기능을 앱에 넣는 팀 과제를 진행했습니다. AI 모델을 맡은 저와 앱 개발을 맡은 팀원 사이에서 추천 결과를 어떻게 보여줄지를 두고 의견이 갈렸습니다. 저는 모델 신뢰도 점수를 같이 보여주면 사용자에게 더 정직하다고 생각했는데, 팀원은 숫자가 화면에 있으면 오히려 신뢰를 깎는다고 했습니다. 둘 다 설득력이 있어서 쉽게 결론이 나지 않았습니다. 결국 5명에게 두 가지 버전을 보여주고 어느 쪽이 더 편한지 물어보는 방식으로 결정했습니다.
3명이 점수 없는 버전을 선호했고, 그 피드백을 근거로 앱 버전을 확정했습니다. 의견이 갈릴 때 사용자 반응을 근거로 쓰는 게 팀 안에서 설득력 있다는 걸 이 경험으로 배웠습니다. 지금도 의견이 갈리면 작게 확인하는 쪽을 먼저 떠올립니다.
부트캠프 팀 프로젝트에서 텍스트 분류 AI 기능을 서비스 플로우에 연결하는 작업을 맡았습니다. AI가 분류를 틀렸을 때 서비스에서 어떻게 처리할지가 처음엔 정해지지 않아서, 틀린 분류가 그대로 사용자에게 전달되는 상황이 생겼습니다. 서비스 팀원과 논의해보니 AI 정확도가 몇 퍼센트 이하이면 사람이 직접 처리한다는 기준이 없었습니다. 저는 모델 신뢰도가 일정 임계값 이하이면 미분류로 표시하고 수동 검토 목록에 넣는 방식을 제안했습니다. 처음엔 임계값을 어디로 잡을지 의견이 갈렸습니다.
100건의 샘플로 정확도와 수동 검토 비율을 측정해 근거를 만들었고, 그 수치를 바탕으로 기준을 정했습니다. AI 기능을 붙일 때 정확도가 100%가 아닌 상황에서 서비스가 어떻게 움직일지를 먼저 합의하는 게 중요하다는 걸 이 과정에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.