이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
AI 워크로드를 위한 로드 밸런싱을 설계할 때 가장 먼저 고민한 건 워크로드 특성의 불균일함이었습니다. 일반 웹 요청과 달리 추론 요청은 모델 크기와 입력 길이에 따라 처리 시간이 수십 배씩 달라집니다. 인턴 프로젝트에서 추론 서버를 운영하면서, 긴 컨텍스트 요청이 몰릴 때 GPU 메모리 OOM이 발생하는 걸 겪었습니다. 그래서 단순 라운드로빈보다는 요청 큐 길이와 GPU 메모리 잔여량을 함께 보는 방식이 더 적합하다고 봤습니다. 성능 최적화를 위해 배치 처리 가능한 요청을 묶는 동적 배칭도 고려해야 하고, 장애 대응으로는 헬스체크 주기를 짧게 가져가 이상 노드를 빠르게 격리하는 구조가 안정적이었습니다. 완성된 시스템을 만든 건 아니지만, 이 경험이 실제 설계 결정의 기준점이 됐습니다.
AI 워크로드 로드 밸런싱에서 첫 번째로 고민한 건 요청마다 처리 비용이 다르다는 점이었습니다. 일반 웹 요청은 크기가 거의 균일하지만, 추론 요청은 입력 토큰 수·컨텍스트 길이·배치 여부에 따라 GPU 메모리 점유량과 처리 시간이 크게 달라집니다. 단순 라운드로빈 방식은 이 불균일함을 전혀 반영하지 못하기 때문에, GPU 사용률과 큐 깊이(Queue Depth)를 실시간으로 보는 동적 가중치 라우팅이 더 적합하다고 봤습니다. 두 번째는 콜드스타트 지연입니다. 모델이 메모리에 올라오기 전 첫 요청의 레이턴시가 수 초에 달할 수 있어, 사전 워밍이나 최소 대기 인스턴스 유지 전략이 필요합니다. 마지막으로 레이턴시 SLO와 GPU 활용율 사이의 트레이드오프를 설계 초기에 명시해야 합니다. 활용율을 높이면 배칭 지연이 생기고 SLO를 낮추면 자원이 남는데, 어느 쪽을 우선할지 기준이 없으면 운영 단계에서 계속 충돌이 생깁니다.
설계 전 먼저 물어봐야 할 것은 레이턴시를 더 중요하게 볼지, GPU 활용율을 더 중요하게 볼지입니다. 그 기준 없이 알고리즘을 고르면 운영 단계에서 방향이 흔들립니다. AI 추론 서버는 배치 크기를 키울수록 처리량은 늘지만 개별 요청 응답 시간이 길어지는 비선형 특성이 있어서, 트래픽 패턴을 먼저 분석하는 게 선행돼야 합니다. 알고리즘 선택은 요청별 예상 처리 비용을 기반으로 한 동적 가중치 최소연결 방식이 현실적입니다. 여기에 GPU 메모리 잔여량을 헬스체크에 포함해서 OOM 직전 노드에 요청이 몰리지 않게 막는 구조를 추가했습니다. 장애 대응은 헬스체크 주기를 짧게 가져가고, 이상 노드를 자동으로 격리한 뒤 트래픽을 재분배하는 흐름이 기본입니다. 완성된 시스템을 만든 경험은 없지만, 이 판단들이 설계 초기에 정해지지 않으면 운영 단계에서 임시방편이 계속 쌓이는 패턴을 관찰했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 ML 인프라 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.