예시 답변 1
약 86초
모니터링 지표·장애 원인 추적·데이터 기반 판단 중심으로 푸는 결
인턴 기간 동안 ML 모델 서빙 서버를 운영하면서 고가용성을 유지하는 방식을 처음 배웠습니다. 당시 서비스는 FastAPI로 감싼 추론 서버 2대를 nginx로 로드밸런싱하는 구조였는데, 가끔 한 서버가 응답을 멈추는 상황이 반복됐습니다. 멘토님과 함께 지표를 분석하면서 `GPU` 메모리가 특정 배치 사이즈를 넘을 때 OOM이 발생한다는 패턴을 확인했습니다. 이후 배치 사이즈를 64에서 32로 줄이고 추론 요청을 큐에 쌓는 방식으로 개선했고, OOM 재시작이 일주일 기준 5회에서 0회로 줄었습니다. 제 역할은 로그 수집과 지표 시각화 대시보드를 만드는 것이었는데, 실제 장애 원인을 데이터로 찾아내는 과정이 감에 의존하는 것과 얼마나 다른지 직접 느꼈습니다. 이 경험 이후 모니터링 지표를 먼저 설계하고 운영을 시작하는 것이 중요하다는 관점이 생겼습니다.
이 결의 특징
ML 모델 서빙 서버가 FastAPI와 nginx 로드밸런싱 2대 구조에서 자주 멈췄습니다. GPU 메모리가 특정 배치 사이즈를 넘을 때 OOM이 발생하는 패턴을 확인한 후 배치 사이즈를 64에서 32로 줄이고 큐 방식을 개선했습니다. OOM 재시작이 주 5회에서 0회로 감소한 흔적이 있습니다.
이 결이 통하는 자리
메모리 누수를 패턴으로 읽고 실험 가능한 변수를 찾아낸 접근이 분명할 때 통합니다. 본격적 성능 개선 전에 제약 조건을 명확히 한 자리에서 면접관이 프로덕션 안정성 감각으로 평가하는 결이 보입니다.