예시 답변 1
약 90초
K8s 위 LLM 서빙 배포 파이프라인 구축
Kubernetes 환경에서 LLM 모델 서빙을 위한 DevOps 파이프라인을 처음부터 구축한 경험이 있습니다. 매번 수동으로 모델을 배포하다 보니 배포 실수와 버전 관리 혼란이 반복됐고, 자동화가 절실했습니다. Helm Chart로 LLM 서빙 워크로드를 패키징하고, ArgoCD로 GitOps 기반 배포를 구성했습니다.
GPU 리소스 요청은 nvidia.com/gpu: 1 형태로 명시하고, Node Affinity로 GPU 노드에만 스케줄링되도록 제어했습니다. 배포 중 가장 어려웠던 부분은 모델 파일 로딩 시간이 길어 Liveness Probe가 조기 실패하는 문제였고, initialDelaySeconds를 모델 크기 기반으로 동적 계산하는 방식으로 해결했습니다.
팀과 함께 배포 표준화를 진행했고, 결과적으로 배포 시간이 45분에서 8분으로 단축됐습니다. 이 경험으로 LLM 특화 K8s 운영 패턴을 실전에서 익혔습니다.
이 결의 특징
매번 수동 배포로 인한 실수와 버전 혼란이라는 구체적 고통이 배포 파이프라인 구축의 이유로 등장합니다. Helm+ArgoCD GitOps 구성, GPU Node Affinity, initialDelaySeconds 동적 계산이라는 세 기술 결정이 각각 문제에 대응하는 형태로 서술돼 있어 선택 이유가 흔적으로 남습니다. 배포 시간 45→8분 단축이라는 수치가 팀 표준화와 연결됩니다.
면접관이 다음에 할 행동
initialDelaySeconds를 모델 크기 기반으로 동적 계산했다는 언급이 나왔을 때 면접관이 '어떻게 크기를 측정해 delay를 계산했는가'를 파고들 가능성이 있습니다. 모델 파일 크기와 로딩 시간의 경험적 관계를 측정해 수식화했다는 과정이 준비돼 있으면 운영 경험의 깊이가 드러나는 흐름이 나타납니다.