이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
저는 서빙 API 개발 시 FastAPI + PostgreSQL 조합을 선호합니다. FastAPI는 타입 힌트 기반 자동 스키마 생성이 강점이라, 팀원들이 API 문서를 별도로 유지할 필요 없이 코드와 문서가 항상 동기화됩니다. 실제 인턴 프로젝트에서 이 스택으로 추론 서버를 구축했고, 응답 스키마 불일치로 인한 클라이언트 오류가 배포 후 0건이었습니다. 단, 트래픽이 폭증하는 고동시 환경에서는 Python GIL 한계로 성능 ceiling이 낮아, 그 경우엔 Go 기반 서버로 전환하는 것도 합리적이라고 봅니다. 스택 선택은 팀 친숙도와 서비스 특성에 따라 달라지기 때문에, 선택 이유를 항상 트레이드오프와 함께 설명하는 편입니다.
서빙 API를 개발할 때 팀이 익숙한 스택과 다른 기술을 선택했다가 예상보다 통합 비용이 든 경험이 있습니다. 성능 측면에서 더 적합하다고 판단해서 팀 내 주요 스택이 아닌 방식을 선택했는데, 모니터링 설정이나 배포 파이프라인이 기존 서비스와 달라서 함께 운영하는 데 추가 작업이 필요했습니다. 기술 선택에서 성능이나 기능만 보고 팀의 기존 운영 환경과 얼마나 잘 맞는지를 충분히 고려하지 않았던 것이 원인이었습니다. 통합 비용을 치르고 나서 이후에는 기술 선택 시 팀이 운영할 수 있는 역량과 기존 인프라와의 호환성을 먼저 확인하는 방식으로 바꿨습니다. 서빙 API 기술 스택은 기술 자체의 특성만큼이나 팀의 운영 맥락에서 얼마나 잘 작동하는지가 실제 선택에서 중요한 기준이 된다는 것을 이 경험에서 배웠습니다.
FastAPI를 선택해서 서빙 API를 구현했는데, 비동기 처리 방식을 충분히 이해하지 못한 상태에서 작성한 코드가 기대한 성능을 내지 못한 경험이 있습니다. 비동기로 처리되면 요청을 더 많이 받을 수 있을 것이라고 생각했는데, 실제로는 동기 방식으로 작성된 함수를 async로 선언했을 때 이벤트 루프를 블록하는 문제가 생겼습니다. CPU 집약적인 작업을 이벤트 루프에서 직접 실행하면 다른 요청이 대기해야 하는 상황이 됐는데, 비동기의 장점이 I/O 대기 시간을 효율적으로 사용하는 것이라는 것을 제대로 이해하지 않고 적용했던 것이 원인이었습니다. 이후에는 CPU 집약적인 작업을 별도 스레드 풀에서 처리하는 방식으로 구조를 바꿨습니다. 기술 스택을 선택하는 것과 그 기술의 동작 방식을 이해하고 올바르게 사용하는 것은 다른 문제이고, 스택 선택 후에 그 기술의 특성을 제대로 이해하는 과정이 반드시 필요하다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.