|| 유저를 한 번 이해하고, 모든 결정이 공유하는 Layer 01편: MATCH란 무엇인가
2편: MATCH Console & MAI
3편: 통합임베딩으로 개인화 푸시
안녕하세요. 무신사 Core-E Personalization 팀에서 개인화 모델을 개발하고 있는 오승모, 방효석입니다. 이 시리즈에서는 MATCH를 중심으로 데이터를 더 나은 결정으로 바꾸는 방법을 이야기해 왔습니다. 운영자가 규칙을 직접 만드는 대신 모델이 유저 단위의 결정을 만들고, 여러 결정의 우선순위를 시스템이 판단하는 과정도 소개했습니다. 그런데 이 모든 이야기에는 하나의 공통된 전제가 깔려 있습니다. “시스템이 유저를 충분히 이해하고 있다”는 전제입니다.
어떤 유저에게 어떤 기획전을 보내야 하는지 결정하려면, 시스템 어딘가에는 그 유저의 취향과 관심사를 표현하는 공통된 표현이 존재해야 합니다. 모델마다 유저를 제각각 이해한다면, 아무리 좋은 의사결정 로직을 만들어도 결국 그 한계를 넘기 어렵습니다.
이 공통된 기반을 만드는 일은 개별 서비스의 모델을 잘 만드는 일과는 성격이 다릅니다. 새 모델의 성과는 지표로 바로 보이지만, 유저에 대한 이해를 쌓는 일은 그 자체로는 눈에 보이는 숫자를 만들지 않습니다. 대신 그 위에 올라서는 모든 결정의 품질을 좌우합니다. 이번 글은 무신사의 모든 모델과 의사결정이 공유하는 유저 표현층, Layer 0(통합임베딩)을 구축하고 이를 개인화 푸시에 처음 적용한 과정을 담았습니다.
왜 통합임베딩이 필요했는가
1편에서는 개별 최적화가 아무리 정교해져도 전체 경험에는 두 가지 갭이 남는다고 이야기했습니다. 하나는 여러 시스템이 서로 다른 결정을 내리면서 생기는 일관성의 격차, 다른 하나는 각 시스템의 학습이 저마다의 사일로(Silo)에 갇혀 서로에게 이어지지 않는 학습의 격차입니다. 통합임베딩이 겨냥한 것은 그중에서도 학습의 격차입니다.
그동안 무신사의 유저 단위 의사결정은 대부분 각자의 전용 모델로 구현되어 왔습니다. 새로운 결정이 하나 생길 때마다 그 서비스만을 위한 로그를 모으고, 피처를 설계하고, 학습 파이프라인을 만들고, 서빙과 모니터링을 붙이는 일이 반복되었습니다. 문제는 모델의 수가 아니라, 같은 유저를 여러 번 배우는 구조였습니다.
추천 모델은 상품 반응을, 푸시 모델은 클릭을, 쿠폰 모델은 구매를 학습합니다. 모두 같은 유저를 대상으로 하지만, 각 모델이 쌓은 유저 이해는 서로 공유되지 않았습니다. 그래서 새 모델을 만들 때마다 유저를 처음부터 다시 배워야 했고, 유저에 대한 이해는 모델 수만큼 조각나 있었습니다.
개인화 푸시는 이런 구조를 가장 잘 보여주는 사례였습니다. 오랫동안 DeepFM 기반 CTR 예측 모델로 운영되며 유저와 기획전 피처를 입력으로 클릭 확률을 예측했습니다. 모델 자체의 성능이 나빴던 것은 아닙니다. 문제는 시간이 지나면서 구조 자체가 유지하기 어려운 형태로 변했다는 점이었습니다.
먼저 운영 지식이 점차 사라졌습니다. 모델의 운영 주체가 여러 차례 바뀌면서 어떤 피처를 왜 넣었는지, 장애가 발생했을 때 무엇을 점검해야 하는지 같은 맥락이 함께 사라졌습니다. 파이프라인은 매일 정상적으로 동작했지만 예측 품질의 변동을 설명할 수 있는 사람은 없었습니다. 시리즈 1편에서 이야기했던 “담당자가 바뀌면 마케팅 자산이 리셋된다”는 현상이 모델 레이어에서도 똑같이 일어나고 있었던 것입니다.
전용 학습 파이프라인을 유지하는 비용도 적지 않았습니다. 개인화 푸시만을 위한 데이터 생성, 피처 가공, 모델 학습 파이프라인을 매일 돌려야 했고, 사이클이 멈추면 그날의 발송 품질도 함께 흔들렸습니다. 세일즈 푸시와 라이브 푸시처럼 같은 앱푸시 채널 안에서도 서로 다른 모델과 파이프라인이 각각 운영되고 있었습니다.
이런 문제들은 모두 같은 원인에서 비롯되었습니다. 유저를 이해하는 책임을 각 모델이 따로 가지고 있었기 때문입니다. 모델이 하나 늘어날 때마다 유저를 이해하기 위한 학습과 운영도 함께 늘어났고, 그 비용 역시 계속 쌓였습니다. 그래서 방향을 바꿨습니다. 결정마다 새로운

