2부: 정책을 따르는 평가자, LLM-as-a-Judge
LLM 평가에 LLM 을 쓰는 "LLM-as-a-Judge" 접근에서, 평가자가 일관성 있게 정책을 따르게 만들기가 어렵다.
LLM 평가에 LLM 을 쓰는 "LLM-as-a-Judge" 접근에서, 평가자가 일관성 있게 정책을 따르게 만들기가 어렵다.
도메인 특화 LLM 평가에서는 ground truth 데이터도 없고 정답도 없는 경우가 일반적이다. 기존 ML 평가 방식이 안 맞는다.
모바일에서 실시간 얼굴 인식 모델을 돌릴 때 latency / 메모리 / 전력 모두 제약이 심하다.
장기 매출 극대화 같은 비즈니스 목표는 비볼록·복합 지표라 직접 최적화하기 어렵다. AI 조직은 이 어려운 문제를 푸는 형태로 어떻게 변환할지 결정해야 한다.
ML 모델 성능을 계속 끌어올려도 서비스 KPI 가 움직이지 않는다. 비즈니스 목표와 학습 타겟이 어긋난 채로 잘못된 지표만 최적화하면 모델 배포 효과가 사라진다.
아자르 추천 알고리즘 A/B 테스트를 새로 시작하려면 매번 로직 코드를 수정·테스트·배포해야 해서 실험 담당자가 엔지니어 일정에 묶인다. 이터레이션 속도가 떨어진다.
아자르 1:1 비디오 채팅의 회귀 테스트는 두 사용자의 실시간 상호작용을 검증해야 한다. 일반 UI 자동화로는 두 단말 간 인터랙션을 다룰 수 없어 매 버전 수동 QA 부담이 컸다.
아자르 세션 기반 추천에 필요한 유저 이벤트가 서로 다른 시점에 흩어져 발생한다. 실시간 추천 품질을 유지하려면 파편화된 이벤트를 낮은 지연 + 정확히 한 번(Exactly Once) 으로 조합해야 한다.
Hyperconnect 의 전사 NoSQL 인 ScyllaDB 클러스터에서 cluster rolling update 시 노드 복구 시간이 지나치게 길었다. ML feature store 등 핵심 서비스의 가용성에 영향을 준다.
아자르 1:1 매칭을 담당하는 Flink 어플리케이션의 end-to-end latency 가 스와이프 직후 매칭 경험과 직결된다. 그러나 어디가 병목인지 정확히 짚어내기 어렵다.