hyperconnect

문제LLM 평가에 LLM 을 쓰는 "LLM-as-a-Judge" 접근에서, 평가자가 일관성 있게 정책을 따르게 만들기가 어렵다.

접근평가 기준을 명확한 정책으로 표현하고, 평가자 LLM 이 그 정책을 따르도록 프롬프트와 few-shot 예시를 구성. 평가 결과를 다시 평가하는 메타-평가까지 적용.

결과도메인 특화 평가에서 일관성과 재현성을 확보. 평가 정책 변경 시에도 빠른 재평가 가능한 운영 체계 구축.

문제도메인 특화 LLM 평가에서는 ground truth 데이터도 없고 정답도 없는 경우가 일반적이다. 기존 ML 평가 방식이 안 맞는다.

접근하이퍼커넥트의 LLM 길들이기 시리즈 1편. ground truth 부재 환경에서 어떻게 LLM 품질을 측정/개선하는지 — LLM-as-a-Judge 도입 배경과 단계별 접근.

결과"정답을 모르는 상태에서 더 나은 모델을 고르는" 평가 framework 도입. 평가 자동화로 모델 개선 사이클을 단축.

문제모바일에서 실시간 얼굴 인식 모델을 돌릴 때 latency / 메모리 / 전력 모두 제약이 심하다.

접근하이퍼커넥트가 모델 경량화, NPU 활용, 멀티 프레임 추론 최적화로 온디바이스 얼굴 식별 파이프라인을 튜닝.

결과모바일 실시간 처리 가능한 수준 달성. on-device ML 의 실전 최적화 사례.

문제장기 매출 극대화 같은 비즈니스 목표는 비볼록·복합 지표라 직접 최적화하기 어렵다. AI 조직은 이 어려운 문제를 푸는 형태로 어떻게 변환할지 결정해야 한다.

접근최적화 이론의 convex relaxation 개념을 차용한다. Lasso 처럼 어려운 비볼록 문제를 풀기 쉬운 볼록 문제로 완화하고, 두 해가 충분히 유사해지기 위한 명시적 가정을 세운 뒤 A/B 테스트로 가정의 타당성을 검증한다.

결과아자르 매칭 시스템 사례로 장기 매출 대신 대화 시간 예측 문제로 완화한 과정을 제시한다. 잘 완화된 문제는 가정 검증이 곧 비즈니스 임팩트로 연결되며, 가정이 깨지면 문제를 재정의해야 한다.

문제ML 모델 성능을 계속 끌어올려도 서비스 KPI 가 움직이지 않는다. 비즈니스 목표와 학습 타겟이 어긋난 채로 잘못된 지표만 최적화하면 모델 배포 효과가 사라진다.

접근매치그룹 데이팅 브랜드 협업 사례를 통해 문제 정의 → 학습 목표 설정 → 데이터셋 구축 → 오프라인 평가 → 온라인 A/B 테스트 → 배포까지 흐름을 설계. 대표 속성(primary attribute) 선택 문제를 multi-armed bandit 대신 예측 모델로 재구성한다.

결과비즈니스 문제를 ML 문제로 정렬하는 전 과정의 체크포인트를 정립했다. 모델 metric 과 비즈니스 metric 의 연결 고리를 명시적으로 관리한다.

문제아자르 추천 알고리즘 A/B 테스트를 새로 시작하려면 매번 로직 코드를 수정·테스트·배포해야 해서 실험 담당자가 엔지니어 일정에 묶인다. 이터레이션 속도가 떨어진다.

접근로우 코드(Low Code) 실험 시스템을 구축. JSON 명세로 실험군을 정의하면 런타임에 사용자가 자동 분할되고 신규 알고리즘이 적용된다. 코드 변경·배포 없이 클릭 한 번으로 실험을 시작할 수 있다.

결과A/B 테스트 셋업 병목을 제거해 추천 실험 이터레이션이 빨라졌다. 실험 담당자가 엔지니어 도움 없이 새 실험을 즉시 시작할 수 있다.

문제아자르 1:1 비디오 채팅의 회귀 테스트는 두 사용자의 실시간 상호작용을 검증해야 한다. 일반 UI 자동화로는 두 단말 간 인터랙션을 다룰 수 없어 매 버전 수동 QA 부담이 컸다.

접근Pytest + Appium 기반으로 테스트를 Non-interaction / Interaction 두 갈래로 나눈다. Interaction 테스트는 하나의 테스트에서 2개의 driver 를 생성·동기화해 두 단말의 행동을 함께 검증. iOS↔Android 크로스 플랫폼 조합까지 커버.

결과1:1 인터랙션이라는 도메인 특성을 자동화 범위에 포함시켰다. 반복 회귀 테스트의 수동 작업 비중을 크게 줄였다.

문제아자르 세션 기반 추천에 필요한 유저 이벤트가 서로 다른 시점에 흩어져 발생한다. 실시간 추천 품질을 유지하려면 파편화된 이벤트를 낮은 지연 + 정확히 한 번(Exactly Once) 으로 조합해야 한다.

접근Spark Streaming, Kafka Streams, Flink 를 비교한 뒤 Apache Flink 기반 스트림 조인 서비스를 구축. Event Time 기반 정밀 제어와 zero-downtime 배포까지 만족하도록 파이프라인을 설계.

결과실시간 추천을 위한 이벤트 조합을 안정적으로 제공한다. 매치 요청·대화 완료 같은 다양한 조합 시나리오를 단일 인프라로 흡수한다.

문제Hyperconnect 의 전사 NoSQL 인 ScyllaDB 클러스터에서 cluster rolling update 시 노드 복구 시간이 지나치게 길었다. ML feature store 등 핵심 서비스의 가용성에 영향을 준다.

접근Write-mostly RAID 인 Super Disk 기능을 도입. write 트래픽을 빠른 디스크 그룹으로 흡수해 복구 I/O 를 단축한다. Kubernetes 환경 관리는 Windmill 기반 자동화로 처리.

결과Rolling update 복구 시간을 기존 대비 최대 10배 단축했다. 운영 자동화로 ScyllaDB 클러스터의 회복탄력성을 높였다.

문제아자르 1:1 매칭을 담당하는 Flink 어플리케이션의 end-to-end latency 가 스와이프 직후 매칭 경험과 직결된다. 그러나 어디가 병목인지 정확히 짚어내기 어렵다.

접근두 단계 진단법을 도입. Application level 에서 Flink operator 단위로 처리 시간 / 처리 외 시간 두 종류 히스토그램을 수집해 비정상 지점을 찾고, Operator level 에서 프로파일링·코드 인스펙션으로 좁힌다.

결과직렬화·네트워크 I/O 같은 처리 외 시간 병목과 어플리케이션 로직 병목을 구분해 진단한다. 성능 튜닝 사이클을 체계화했다.