새로운 루다를 지탱하는 모델 서빙 아키텍처 — 1편: A/B 테스트를 위한 구조 설계

이루다 2.0에서 모델 구조 자체를 빈번하게 A/B 테스트하기 위해 서비스 백엔드, 모델 파이프라인, 실험 라우팅을 분리한 설계 과정을 다룬다. 서비스 서버는 모델과 실험을 몰라도 되고, ML 조직은 Kubernetes ConfigMap 하나와 ArgoCD PR만으로 서로 다른 추론 구조와 트래픽 비율을 바꿀 수 있게 됐다.

핵심 포인트

Retrieval과 Generation처럼 필요한 서버 조합이 다른 모델 아키텍처 전체를 실험 대상으로 삼아야 했다.
서비스 백엔드에서 추론 순서를 떼어 모델 파이프라인 서버로 옮겨 모델 변경이 제품 서버 배포로 번지지 않게 했다.
서비스 백엔드와 파이프라인 서버 사이에 A/B Proxy를 두어 실험군 식별과 라우팅 책임도 분리했다.
여러 Proxy가 Kubernetes ConfigMap을 watch하고 변경 이벤트를 즉시 받아 같은 실험 설정으로 전환한다.
공통 모델 서버를 실험군끼리 공유해 GPU·IPU 비용을 줄이고, ConfigMap 변경은 ArgoCD PR 리뷰로 통제한다.

상세 정리

기존 MLOps 기반: Model Registry와 Dataset Registry로 산출물과 재현성을 관리하고, DataHub와 Apache Beam·Airflow로 파이프라인 가시성을 확보했다.
남은 병목: 연구 파이프라인은 자동화됐지만 모델 구조가 자주 바뀌어 엔지니어가 매번 모델을 서버화하고 배포 환경에 맞추는 작업이 남았다.
실험 요구: 모델 변경이 대화 경험 지표에 직접 영향을 주므로 사용자 군별 트래픽과 로그를 분리하고 통계로 비교할 수 있어야 했다.
구조 차이: Retrieval은 임베딩, ANN 후보 검색, reranking 서버가 필요하지만 Generation은 생성과 reranking 서버로 구성된다. 단일 모델 교체뿐 아니라 이 조합 전체를 비교해야 했다.
비용 제약: 설정 하나만 다른 실험마다 동일한 GPU 모델 서버를 복제하면 비용이 커진다. 사용자 대화는 매번 달라 캐시로 추론량을 줄이기도 어렵다.
자동화 제약: 실험마다 Helm 차트를 직접 고치거나 subchart로 분리하면 높은 빈도의 실험이 불가능하다. 간단한 설정으로 실험 수명주기를 제어해야 했다.
1차 분리: 모델 파이프라인 서버가 추론 순서와 모델 인터페이스를 추상화한다. 서비스 백엔드는 고정 endpoint만 호출하며 구조 변경은 파이프라인 서버 롤링 업데이트로 끝난다.
서버 공유: 모델이나 설정만 다른 실험은 파이프라인 서버만 여러 개 띄우고 동일한 모델 서버를 공유해 중복 가속기 비용을 막는다.
2차 분리: A/B Proxy가 요청을 실험군으로 식별하고 적절한 파이프라인 endpoint로 중계한다. 실험 시작·종료 때 서비스 백엔드를 재배포할 필요가 사라졌다.
중앙 설정: 사용자 분할 방법, 군별 비율, 파이프라인 endpoint를 ConfigMap에 기록한다. 모든 Proxy가 Kubernetes watch API로 변경을 받아 라우팅을 동시에 갱신한다.
검증: 다수의 watch가 API 서버 성능에 영향을 줄 가능성을 부하 테스트했으며 유의미한 영향이 없어 이 방식을 채택했다.
운영 통제: 엔지니어는 ConfigMap edit로 실험을 제어할 수 있고, 실제 변경은 ArgoCD와 PR 리뷰를 거쳐 실험 세부 조건을 검증한다.