이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
Kong API Gateway를 활용한 트래픽 제어 경험은 사이드 프로젝트에서 Kong의 Rate Limiting 플러그인으로 서비스별 초당 요청 수를 제한한 것입니다. 트래픽이 특정 서비스에 집중될 때 다운스트림 서비스가 과부하되는 것을 방지하고, 공정한 리소스 분배를 적용했습니다.
라우팅 최적화에서는 서비스별 경로와 업스트림 설정을 관리했습니다. 요청 경로와 헤더 조건을 기반으로 적절한 백엔드 서비스로 분기하고, 카나리 배포를 위한 트래픽 가중치 설정도 적용했습니다.
Kong 사용 경험에서 배운 것은 API 게이트웨이는 성능 최적화보다 관측 가능성이 더 중요하다는 점입니다. 요청·응답 로그와 지표를 수집하는 플러그인이 있어야 트래픽 이상을 빠르게 감지하고 설정을 조정하는 근거가 됩니다.
Kong API Gateway 경험에서 본인 사례로 닫힌 경험은 Rate Limiting 설정을 조정하면서 서비스별 적절한 임계값을 찾은 케이스였습니다. 처음에는 모든 서비스에 같은 Rate Limit을 적용했는데, 일부 서비스에서 정상적인 트래픽이 막히는 경우가 생겼습니다.
각 서비스의 예상 요청량을 분석하고 서비스별로 다른 임계값을 설정하는 방식으로 바꿨습니다. API Gateway에서 설정 값은 일관성보다 서비스 특성에 맞게 조정되는 것이 더 실질적이라는 결이 생겼습니다.
Kong API Gateway 경험에서 측정 결로 이어진 경험은 Rate Limiting 도입 전후 서비스 안정성을 확인한 케이스였습니다. 제한 없이 운영하다가 특정 서비스에서 갑작스러운 트래픽 증가로 응답이 느려지는 경우가 있었습니다. Rate Limiting 도입 후 같은 트래픽 패턴에서 서비스 응답 시간이 어떻게 변화했는지를 모니터링했습니다.
급격한 트래픽 증가 구간에서 응답 시간 변화가 줄어든 것을 확인했습니다. 트래픽 제어의 효과는 평상시가 아니라 트래픽이 급증하는 상황에서 확인된다는 결이 남아 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 부스터즈 인프라/클라우드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.