추천에 먼저 필요했던 것은 모델보다 설명 가능한 규칙이었다

LOVETRIP과 YM Guide를 만들며 추천 기능을 다뤘다. 여행 코스와 청년 정책은 전혀 다른 대상이지만, 초기에는 사용자 행동 데이터가 충분하지 않다는 공통점이 있었다. 이 조건에서 바로 학습 기반 추천으로 시작하기보다 규칙과 점수를 조정하는 방향을 택했다.

조건에 맞는 목록만으로는 부족했다

YM Guide의 기존 기록에는 단순 필터링에서 점수 기반 정렬로 바꾼 경험이 남아 있다. 조건에 맞는 정책을 모두 보여 줘도 사용자는 어디부터 살펴볼지 다시 판단해야 했다. LOVETRIP에서도 장소 후보가 있다는 사실만으로 좋은 동선이 만들어지지는 않았다.

그래서 먼저 후보에서 제외할 조건과 후보 사이의 우선순위를 나눠 봤다. 반드시 지켜야 하는 예산 제약과 선호에 따른 가산점은 역할이 다르다. 반드시 지켜야 할 조건을 낮은 점수로만 표현하면 다른 점수가 높다는 이유로 부적절한 후보가 살아남을 수 있다.

규칙을 택한 이유와 대가

규칙 기반 방식은 왜 결과가 나왔는지 따라가기 쉽다. 사용 중 어색한 코스를 발견하면 어느 조건이나 가중치를 바꿔야 할지 논의할 수 있다. 사용자 반응을 모으며 제품 자체를 수정하던 단계에는 이 점이 유용했다.

반면 규칙을 계속 추가하면 예외가 쌓인다. 특정 사례를 고친 가중치가 다른 사례를 악화시킬 수 있고, 개발자의 선호가 전체 사용자에게 적용될 위험도 있다. 규칙 기반이라는 이유로 객관적인 결과가 되는 것은 아니다. 선택의 단순함과 검증의 충분함은 별개다.

지금이라면 비교할 예시를 남기겠다

추천 로직을 바꿀 때 동일한 입력 묶음으로 전후 결과를 비교하겠다. 예산이 작은 여행, 이동 범위를 좁힌 여행, 조건이 거의 없는 정책 검색처럼 서로 다른 사례를 고정해 두는 것이다. 전체 정답을 만들기 어렵더라도 명백히 나빠진 결과를 발견하는 데 도움이 된다.

이 경험 이후 추천의 첫 목표를 정교한 알고리즘으로 두지 않게 됐다. 사용자가 결과를 이해하고 내가 변경 이유를 설명할 수 있는지가 먼저였다. 더 복잡한 모델로 갈지는 데이터와 검증 기준이 생긴 뒤 결정할 문제로 남겨 두는 편이 초기 제품에는 맞았다.

관련 기록: YM Guide의 추천 설계, LOVETRIP