이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 로그인, 상품 조회, 주문 처리를 각각 분리된 서비스로 만들었는데, 프론트엔드가 3개 서비스에 직접 요청을 날리니까 CORS 설정이 서비스마다 달라 혼란이 생겼습니다.
FastAPI로 Gateway를 만들어 인증 토큰 검증과 라우팅을 한 곳에서 처리하도록 바꿨습니다. httpx로 내부 서비스에 프록시 요청을 보내는 방식이었습니다.
처음에는 async 처리를 제대로 하지 않아서 동시 요청 30개 이상 들어오면 레이턴시가 튀는 문제가 생겼습니다. httpx.AsyncClient를 싱글턴으로 공유하도록 바꾸고 나서 안정되었습니다. Gateway 하나로 인증을 모으니 개별 서비스에서 인증 코드가 사라져서 유지보수가 편해졌습니다.
인턴 때 외부에 노출된 API에 특정 IP가 1분에 수백 번 요청을 보내는 문제가 생겼어요. 각 서비스에서 개별로 막으려면 코드가 분산되니, FastAPI Gateway에 Redis 기반 Rate Limit 미들웨어를 추가하는 작업을 맡았습니다.
sliding window 방식으로 구현했는데, Redis에 키가 너무 많이 쌓이면서 메모리 사용량이 급증하는 문제가 생겼어요. TTL을 빠뜨렸던 게 원인이었고, 키마다 expire를 60초로 걸어서 해결했습니다.
배포 후 비정상 트래픽이 90% 이상 차단됐어요. 다만 Rate Limit 응답이 500으로 떨어지는 버그가 초반에 있었는데, 429 Too Many Requests로 바꾸는 걸 뒤늦게 고쳤습니다. 표준 상태코드를 처음부터 챙겨야 한다는 걸 배웠어요.
직접 운영 환경에 배포한 경험은 많지 않지만, 개인 프로젝트에서 FastAPI Gateway를 만들고 locust로 부하 테스트를 해봤어요.
동시 사용자 50명 기준으로 p99 레이턴시가 800ms를 넘어가는 문제를 발견했는데, 추적해보니 Gateway가 내부 서비스로 요청을 보낼 때 매번 새 커넥션을 여는 게 원인이었어요.
httpx.AsyncClient를 앱 시작 시 생성해서 lifespan으로 관리하도록 바꾸니 p99가 200ms 아래로 떨어졌습니다. Gateway는 단순한 라우팅처럼 보여도 커넥션 재사용과 비동기 처리를 챙기지 않으면 병목이 의외로 Gateway 자체에서 생긴다는 걸 이때 알았어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넥스트증권 ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.