머신러닝 시스템 설계 프레임워크: 비즈니스·온라인·오프라인 지표와 후보 선별부터 랭킹 파이프라인까지

핵심 메시지

• 알고리즘 선택은 시스템 설계의 마지막이자 가장 덜 중요한 단계이며, 모델은 일단 블랙박스로 두고 그 주변 구조부터 짜야 한다.
• 지표는 비즈니스, 온라인, 오프라인 세 층으로 나뉘는데, 이 셋이 서로 잘 연결된다는 보장이 없다는 점이 설계의 핵심 난제다.
• 일간 10억 명에서 화면에 보일 100명을 뽑으려면 후보 선별, 경량 랭킹, 중량 랭킹, 다양성과 필터링으로 단계를 나눠 좁혀야 한다.
• 실시간과 배치, 스트리밍은 비용과 최신성의 교환 관계가 각각 다르며, 발표자는 배치와 스트리밍을 섞은 하이브리드를 가장 현실적인 답으로 본다.
• 학습 데이터는 사용자 반응에서 나오므로, 어떤 노출을 학습 인스턴스로 삼을지와 초기 데이터가 없는 콜드 스타트를 어떻게 넘길지를 미리 정해야 한다.

쉽게 이해하기

발표자는 비즈니스 아이디어에서 출발해 기술 요구사항을 끌어내는 자신의 설계 플레이북을 소개한다. 순서는 이렇다. 비즈니스 요구를 머신러닝 문제로 다시 정의하고, 비즈니스 지표와 온라인 지표를 정한 뒤, 시스템의 구성 요소를 짜고, 학습 데이터 수집 방법과 오프라인 지표를 결정하고, 피처를 고른 다음, 마지막에 모델을 정한다. 그는 이것이 머신러닝 시스템 디자인 면접에서 요구하는 사고 순서이기도 하다고 말한다.

예제는 페이스북의 친구 추천 기능이다. 발표자가 메타 면접에서 실제로 받았던 문제라고 한다. 비즈니스 목표는 피드 참여를 늘려 광고 클릭 가능성을 높이는 것이고, 제약은 일간 활성 사용자 10억 명과 100밀리초 이내 응답이다. 사용자가 추천된 프로필을 추가하거나 하지 않는 이진 반응이므로 지도학습 문제로 볼 수 있고, 분류 모델이나 순위 학습 알고리즘 중 하나가 될 것이다. 이 단계에서는 그 정도만 정하면 충분하다는 것이 그의 조언이다.

발표의 절반은 지표 이야기에 쓰인다. 비즈니스 지표로는 체류 시간, 이탈률, 클릭과 댓글 같은 참여 행동을 쓸 수 있다. 온라인 지표로는 A/B 테스트에서 비교할 수 있는 세션당 새로 추가된 친구 수 같은 값을 고른다. 오프라인 지표는 과거 데이터로 재는 AUC, 로그 손실, 정밀도-재현율 곡선 아래 면적 같은 값이다. 문제는 이 셋이 반드시 같은 방향을 가리키지 않는다는 데 있다. 발표자는 광고 랭킹 업무에서 오프라인의 로그 손실과 온라인의 매출 점수가 잘 상관되지 않아, 어떤 오프라인 지표를 써야 하는지 연구에 많은 시간을 들여야 했다고 털어놓는다.

구조는 단계적 축소로 설계한다. 사용자당 평균 1,000명의 친구가 있다고 보고 친구의 친구, 즉 2촌 관계를 후보로 삼으면 10억 명이 100만 명 수준으로 줄어든다. 여기에 빠르지만 단순한 경량 랭커, 예컨대 로지스틱 회귀나 간단한 신경망을 붙여 100명에서 1,000명까지 좁힌다. 그다음 느리지만 정확한 복잡한 신경망으로 최종 순위를 매기고, 매번 목록이 조금씩 달라지도록 다양성 모듈로 무작위성을 넣은 뒤, 정책상 노출하면 안 되는 계정을 걸러낸다. 이렇게 해야 100밀리초 제약 안에서 답을 낼 수 있다.

추론 방식은 세 갈래로 비교된다. 실시간 추론은 최신 맥락을 반영하지만 동시 요청을 감당할 서버가 많이 필요해 비싸다. 배치 추론은 구현이 쉽지만 매일 활성 사용자 전체를 랭킹하면 목록을 보지도 않는 사람 몫까지 계산해 버린다. 스트리밍은 요청을 큐에 넣어 나중에 처리하고 다음 방문 때 꺼내 쓰는 지연된 실시간 방식으로, 서버 부담이 적은 대신 순위가 다소 낡을 수 있다. 발표자는 배치와 스트리밍을 섞은 하이브리드가 여기서는 최선일 가능성이 높다고 본다. 마지막으로 그는 사용자, 후보 프로필, 맥락, 사용자 간 상호작용이라는 네 축으로 피처를 정리하되, 가능한 모든 데이터를 넣으려 하지 말고 최소 피처부터 시작하라고 강조한다.

주요 인사이트

• 지표 층 사이의 상관은 검증된 사실이 아니라 설계자가 감수하는 가정이다. 오프라인에서 이긴 모델이 온라인 실험에서 지는 일은 흔하고, 그 반복이 곧 낭비되는 시간이다.
• '가능한 모든 데이터를 넣자'는 충동을 억제하고 최소 피처 집합을 정하는 것이 설계자의 역할이다. 그러려면 풀려는 문제를 먼저 이해해야 한다.
• 학습 데이터는 시스템 구조에 종속된다. 배치나 스트리밍에서는 피처가 계산된 시점과 사용자가 목록을 본 시점이 어긋나므로, 그 지연을 감안해 수집 방식을 설계해야 한다.
• 어떤 노출을 학습 인스턴스로 쓸지도 설계 결정이다. 목록 아래쪽이라 사용자가 보지도 못한 프로필까지 학습에 넣으면 안 되고, 모바일과 데스크톱의 노출 창 차이도 고려 대상이다.
• 100밀리초를 맞추기 위한 서버 증설 비용이 기능이 만들어 내는 이익을 넘지 않는지 먼저 따져야 한다. 캐싱처럼 보수적이고 저렴한 선택지를 먼저 검토하는 편이 대체로 낫다.

자주 묻는 질문

관련 AI 소식