이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 프로젝트에서 처음에는 익숙한 Python FastAPI로 API 서버를 만들었습니다. 기능 구현은 빠르게 진행되었으나, 동시 요청 100개가 넘어가면 레이턴시가 급격히 늘어나는 문제가 발생했습니다.
원인을 분석해보니 GIL 때문에 CPU 바운드 작업이 병렬로 실행되지 않고 있었습니다. 그래서 고민 끝에 Go로 핵심 엔드포인트 2개를 다시 작성하였고, 같은 부하에서 p95 레이턴시가 300ms에서 60ms로 줄어들었습니다.
그러나 Go로 옮기면서 에러 처리 패턴이 낯설어서 nil 포인터 패닉이 두 번 발생하였습니다. 팀원들도 Go 경험이 없어서 코드 리뷰가 제대로 이루어지지 않은 점이 문제였습니다. 이 경험을 통해 언어 전환은 성능뿐만 아니라 팀 전체의 학습 비용도 함께 고려해야 한다는 것을 배웠습니다.
인턴 때 ML 모델 추론 결과를 API로 내려주는 서버를 담당했는데, 팀에서 Go 또는 Python 중 선택을 논의했어요.
저는 Python을 주장했는데, 이유는 모델 코드가 전부 Python이라 언어를 분리하면 내부 인터페이스를 따로 만들어야 하는 오버헤드가 생겼기 때문이에요. 성능이 중요하긴 했지만, 추론 자체가 GPU 바운드라 API 서버 레이어의 언어 선택이 전체 레이턴시에 미치는 영향이 크지 않다고 판단했습니다.
결국 Python FastAPI로 유지했고, 응답 직렬화 부분만 `orjson`으로 바꿔서 약 15% 속도 개선을 했어요. 언어 선택이 항상 성능 최적화만의 문제는 아니고, 기존 코드베이스와의 통합 비용도 중요한 기준이 된다는 걸 느꼈습니다.
저는 아직 프로덕션 API 서버를 처음부터 언어를 골라 설계한 경험은 없지만, 팀 프로젝트에서 언어 선택을 논의한 적이 있어요.
당시 팀원 4명 중 3명이 TypeScript에 익숙해서 팀 숙련도를 최우선으로 해서 NestJS를 쓰기로 했습니다. 저는 Python을 선호했지만, 처음에 생산성을 위해서라면 팀 공통 언어가 맞다고 수긍했어요. 익숙한 생태계에서 시작하는 게 초반 속도에 유리했습니다.
프로젝트 후반에 ORM 쿼리 최적화가 필요한 구간이 있었는데, TypeScript 생태계가 Python에 비해 DB 도구가 덜 익숙해서 시간이 좀 걸렸습니다. 언어 선택 시 팀 생산성, 기존 생태계, 성능 요건을 같이 놓고 봐야 한다는 걸 느꼈고, 다음엔 더 의식적으로 트레이드오프를 따져보고 싶어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.