전직 당근마켓 엔지니어가 폭로하는 '모델 성능표'의 거짓말과 IPS 공식 공개

전직 당근마켓 엔지니어가 폭로하는 '모델 성능표'의 거짓말과 IPS 공식 공개

박지민·2026년 2월 3일·3

전직 당근마켓 엔지니어가 밝히는 추천 시스템 성능의 진실. 오프라인 평가 지표의 함정과 이를 해결하기 위한 반사실적 평가(IPS) 기법의 핵심을 공개합니다.

"CTO님, 이번 모델 Recall이랑 NDCG가 기존보다 15%나 올랐습니다. 바로 배포하시죠."

저는 이런 말을 하는 주니어 개발자에게 대답 대신 AWS 청구서를 던져줍니다.

"그 15% 상승이 우리 회사 매출 15% 상승을 보장합니까? 아니면 그냥 학습 데이터에 과적합(Overfitting)된 겁니다?"

많은 엔지니어들이 착각합니다. 추천 시스템(Recommendation System)을 단순한 분류 문제(Classification)로 접근하니까요. 이미지넷(ImageNet) 대회 나가는 게 아닙니다.

[팩트] 여러분이 로컬에서 돌린 오프라인 평가(Offline Evaluation) 지표는 대부분 거짓말입니다.

왜냐하면 여러분은 '관찰(Observational)' 문제를 풀고 있다고 착각하지만, 실제 비즈니스에서의 추천은 '개입(Interventional)' 문제이기 때문입니다.

이 차이를 모르면 GPU 비용만 태우는 '디지털 난로'를 만드는 꼴이 됩니다.

기존 데이터는 '과거의 추천 모델'이 보여준 결과물(Biased Data)일 뿐입니다. 유저는 화면에 노출된 것만 클릭할 수 있습니다.

그런데 여러분은 새 모델이 "과거 모델이 보여줬던 그 아이템을 얼마나 잘 맞추는지"만 채점하고 있습니다.

이건 마치 내일 주가를 맞추라니까, 어제 신문을 얼마나 잘 외웠는지 테스트하는 것과 같습니다.

우리가 진짜 알고 싶은 건 P(view=iphone | prev_model) 따위가 아닙니다.P(click=True | recommend=iphone) 즉, 우리가 개입(Interventional)했을 때 고객의 행동이 변하느냐는 겁니다.

가장 확실한 건 A/B 테스트입니다. 하지만 이건 돈과 시간이 듭니다. 엉망인 모델을 라이브에 올리면 매출은 박살 나고 PM들은 저를 죽이려 들 겁니다.

그래서 내부적으로만 공유하는 '반사실적 평가(Counterfactual Evaluation)' 기법을 소개합니다.

"만약 우리가 A 대신 B를 보여줬다면 어땠을까?"를 수학적으로 추정하는 겁니다.

핵심은 IPS(Inverse Propensity Scoring)입니다.

직관은 간단합니다. 과거 모델(π0)보다 새 모델(πe)이 특정 아이템을 더 자주 추천한다고 가정해 봅시다.

이때 발생한 클릭(Reward)에 가중치(Importance Weight)를 더 주는 겁니다.

공식은 대략 이렇습니다: Weight = 새 모델의 추천 확률 / 구 모델의 추천 확률

예를 들어, 과거 모델이 아이폰을 추천할 확률이 40%였는데, 새 모델은 60%라고 칩시다. Weight = 0.6 / 0.4 = 1.5.

이 경우 발생한 클릭은 평소보다 1.5배의 가치를 가집니다. 반대로 새 모델이 추천을 덜 하는 아이템에서의 클릭은 가치를 낮춥니다.

이렇게 데이터의 분포(Distribution) 차이를 보정(Reweighting)해야 비로소 '진짜 성능'이 보입니다.

물론, 이것도 만능은 아닙니다.

IPS에는 치명적인 약점이 있습니다. 구 모델이 추천 확률을 0으로 뒀던 아이템(아예 노출 안 시킨 아이템)은 분모가 0이 되어 계산이 불가능합니다.

이걸 '불충분한 지지(Insufficient Support)'라고 부릅니다.

이 문제를 해결하겠다고 일부 트래픽에 랜덤 아이템을 노출해서 데이터를 쌓겠다고 하면? PM들이 당장 쫓아와서 "유저 경험 망친다"며 따질 겁니다.

또 다른 문제는 '분산(Variance)' 폭발입니다. 구 모델의 확률이 0.001인데 새 모델이 0.1이라면 가중치가 100배로 뻥튀기됩니다. 클릭 한 번에 지표가 요동칩니다.

그래서 현업에서는 SNIPS(Self-Normalized IPS)나 CIPS(Clipped IPS)를 씁니다.

CIPS는 가중치가 10을 넘어가면 강제로 10으로 잘라버리는(Clipping) 식이고, SNIPS는 전체 가중치 합으로 나눠서 정규화(Normalize)하는 방식입니다.

복잡해 보인다면 이것만 기억하십시오.

  1. Recall/Precision만 보고 배포하지 마십시오. 그건 과거의 망령입니다.
  2. 추천은 유저의 행동을 '바꾸는' 행위입니다. 인과관계(Causality)를 고민하십시오.
  3. IPS 같은 반사실적 추정기를 도입해서, A/B 테스트 전에 오프라인에서 최대한 리스크를 걸러내십시오.

주니어 여러분, 밤새워 모델 아키텍처 튜닝할 시간에 로그 데이터에 action_prob(추천 확률)이 남고 있는지부터 확인하세요.

그게 없으면 IPS고 뭐고 아무것도 못 합니다. 데이터 엔지니어링 없는 AI는 허상입니다.

오늘도 삽질하는 여러분을 위해, 제가 작성한 SNIPS 파이썬 코드 스니펫은 슬랙에 남겨두겠습니다.

제발 이번 배포 때는 롤백하는 일이 없기를 바랍니다.

박지민
박지민AI 솔루션 기업 CTO

논문 속의 정확도(Accuracy)보다 통장 잔고를 지키는 추론 비용(Inference Cost)을 중시하는 생존형 기술 리더입니다. 화려한 데모 뒤에 숨겨진 엔지니어링의 고통과 비즈니스 가치를 냉철하게 분석합니다.

박지민님의 다른 글

댓글 0

첫 번째 댓글을 남겨보세요!