취향 노트 몇 분마다 고치는 카페 사장님, 정체 까 보니 바이트댄스 추천 AI였어요

이런 카페가 있다고 쳐 볼게요

결론부터 말하면, 이 후기는 '취향을 몇 분 만에 고쳐 적는 법' 얘기예요.

먼저 말씀드리면, 아래 카페는 실제로 있는 곳이 아니에요. 비유용 가상 카페예요.

손님 취향을 기가 막히게 기억하는 카페예요.
사장님은 손님마다 취향 노트를 한 권씩 만들어서 커다란 사물함에 넣어 둬요.
"라떼파, 시럽 빼고, 밤에 옴, 고양이 그림 컵 좋아함" 이런 식으로요.

소름 돋는 건 속도예요.
오늘 처음 바닐라라떼를 시키면, 주말에 몰아서 정리하는 게 아니라 몇 분 안에 노트에 반영돼요.

여기까지만 들으면 그냥 친절한 카페잖아요.
근데 이 사장님, 남모르는 고민이 두 개 있어요.

첫째, 손님이 너무 많아요. 사물함 칸이 모자라서 노트 두 권을 한 칸에 같이 넣기 시작했어요.
그랬더니 고양이 덕후 노트에 캠핑 마니아 메모가 섞여서, 고양이 컵 대신 텐트 그림 컵이 나와요.

둘째, 노트가 수만 권이라 매번 통째로 복사하면 사장님이 쓰러져요.

이 두 고민을 어떻게 풀었는지가 오늘 후기 내용이에요.

그리고 눈치채셨겠지만, 카페 얘기가 아니에요.
틱톡(TikTok)의 모회사로 알려진 바이트댄스(ByteDance) 연구진이 쓴 추천 시스템 논문 Monolith 얘기예요.

(※ 논문에는 '틱톡'이라는 이름이 안 나와요. 논문은 숏폼 영상 순위 매기기나 온라인 광고처럼 "사용자 반응에 시간이 생명"인 서비스를 겨냥하고, 바이트댄스의 기업용 추천 서비스(BytePlus Recommend)에 적용됐다고 밝혀요. 틱톡 앱이 이 시스템으로 돌아간다는 뜻은 아니에요.)

카페를 논문 말로 바꾸면 이래요

• 손님 = 사용자, 메뉴 = 영상·광고 같은 콘텐츠
• 취향 노트 = 임베딩. 취향을 숫자 묶음으로 바꿔 기억하는 방식이에요.
• 사물함 = 임베딩 테이블. ID마다 한 칸씩 숫자 묶음을 보관하는 곳이에요.
• 노트 두 권이 한 칸에 = 해싱 충돌
• 주말에 몰아서 정리 = 배치 학습, 몇 분 안에 바로 고치기 = 온라인 학습

비유랑 다른 점도 짚을게요.
실제로는 사용자뿐 아니라 영상 ID도 각자 칸을 가져요. 노트 내용은 문장이 아니라 숫자 묶음이고요. 그리고 사장님 한 명이 아니라, 학습하는 서버와 실제로 추천을 내보내는 서버가 따로 있어요. 이 차이가 뒤에서 중요해져요.

사물함이 모자란 이유

논문은 언어 모델이 다루는 단어 조각 수는 한정돼 있지만, 추천 시스템의 사용자·콘텐츠 수는 자릿수가 다르게 많고 계속 늘어난다고 지적해요. 컴퓨터 한 대 메모리에 다 들어가지도 않아요.

그래서 많은 시스템이 쓰는 꼼수가 해싱이에요. ID를 계산식에 넣어 정해진 개수의 칸 번호로 바꾸는 건데, 칸이 ID보다 적으니 서로 다른 ID가 같은 칸을 쓰는 충돌이 생겨요. 카페의 노트 섞임이 바로 이거예요.

"충돌은 드물고 별 피해 없다"는 가정이 흔하지만, 논문은 현실에선 소수의 인기 ID가 압도적으로 자주 등장해서 이 가정이 거의 안 맞고, 테이블이 커질수록 품질이 떨어진다고 봐요.

연구진이 영화 평점 공개 데이터(MovieLens, 평점 2,500만 개)에 해싱을 적용했더니 사용자 ID 162,541개가 149,970칸으로 줄어 7.73%가, 영화 ID 59,047개가 57,361칸으로 줄어 2.86%가 충돌했어요.

해법 ①: 뻐꾸기처럼 밀어내는 사물함

첫 번째 해법은 충돌 없는 사물함이에요. 기법 이름이 귀여워요. 뻐꾸기 해싱.

뻐꾸기는 남의 둥지에 알을 낳고, 새끼가 원래 있던 알을 밀어내는 걸로 유명하죠. 사물함 벽이 두 개(T0, T1) 있고, ID마다 벽 하나에 한 자리씩 '갈 수 있는 자리'가 있어요.

1. 새 ID A가 T0의 자기 자리에 가려는데 B가 앉아 있으면?
2. A가 B를 밀어내고 앉아요.
3. 쫓겨난 B는 T1의 자기 다른 자리로 가요. 거기 누가 있으면 또 밀어내요.
4. 다 자리를 찾을 때까지 반복하고, 빙빙 돌면 배치를 새로 짜요.

결과적으로 아무도 칸을 같이 안 써요. 찾기와 삭제는 최악의 경우에도 일정한 시간 안에 끝나고요.

대신 모든 ID에 칸을 주면 메모리가 금방 바닥나서 규칙을 두 개 둬요.

• 입장 심사: 몇 번 안 나온 ID는 칸을 안 줘요. 인기 ID는 수백만 번 나오지만 비인기 ID는 열 번도 안 나오는데, 이런 ID는 학습 데이터가 부족해 결과에 영향을 거의 못 준대요.
• 유효기간: 오래 활동이 없는 ID의 칸은 일정 시간이 지나면 비워요.

해법 ②: 밤샘 공부 말고 실시간 복습

이 논문의 진짜 주인공은 온라인 학습이에요. 논문 표현이 인상적이에요. 시각이나 언어의 패턴은 수백 년 단위로도 거의 안 변하지만, 같은 사용자의 관심사는 바로 다음 순간에도 바뀔 수 있다고요.

흐름은 이래요.

1. 클릭, '좋아요', 구매 같은 행동이 실시간으로 기록돼요.
2. 그 행동을 "그때 어떤 추천을 보여 줬는지"와 짝지어 학습 자료로 만들어요. (며칠 뒤 사는 사람도 있어서, 오래 기다리는 자료는 디스크에 따로 둬요.)
3. 학습 서버가 곧바로 모델을 고쳐요.
4. 고친 내용을 추천 서버로 주기적으로 옮겨요.

여기서 카페의 두 번째 문제가 풀려요. 실제 모델은 수 테라바이트라 통째로 복사하면 네트워크와 메모리가 못 버텨요. 그래서 지난번 이후 바뀐 칸만 골라 보내요. 논문 계산으로는 1분에 10만 개 ID가 바뀌고 묶음 하나가 1,024개 숫자라면 1분에 약 400MB만 옮기면 돼요.

신경망 본체(덜 자주 변하는 부분)는 하루에 한 번, 이용자가 가장 적은 시간대(예: 자정)에 옮겨요. 취향 노트는 분 단위, 본체는 하루 단위로 나눈 거예요.

그래서 얼마나 좋아졌냐면요

성능은 AUC로 쟀어요. 반응할 것과 안 할 것을 하나씩 골랐을 때 반응할 쪽에 더 높은 점수를 줄 확률에 가까운 지표고, 1에 가까울수록 좋아요.

충돌 없는 사물함: MovieLens와 실제 서비스 모델 실험 모두에서 충돌 없는 쪽이 일관되게 좋았어요. 첫 학습부터 높았고, 날이 지나도 우위가 유지됐어요.

실시간 학습: 광고 클릭 공개 데이터(Criteo, 7일치)로 5일은 배치, 2일은 실시간 학습을 흉내 냈어요(AUC×100).

차이는 작아 보여도 방향은 분명해요. 자주 고칠수록 좋아졌어요. 실제 광고 모델 A/B 테스트에서도 실시간 학습이 매일 AUC 개선을 보였고, 논문 표에는 7일간 개선 수치가 14.443~18.081%로 적혀 있어요. 연구진은 사물함 업데이트를 현재 분 단위로 하고 있다고 밝혔어요.

제일 의외였던 대목: 백업은 하루 한 번

실시간으로 고치면 백업(스냅샷)도 자주 떠야 할 것 같죠. 그런데 백업 주기를 하루로 늘려도 품질이 거의 안 떨어졌대요.

논문의 계산은 이래요. 모델이 서버 1,000대에 나뉘어 있고 고장률이 하루 0.01%라면 10일에 한 대꼴로 고장 나요. 일일 사용자 1,500만 명을 가정하면, 10일에 한 번 1만5천 명의 하루치 반응을 잃는 셈이에요. 전체의 아주 작은 일부라 감수할 만하다는 판단이고, 덕분에 백업 비용을 크게 줄였어요. (서버 수와 사용자 수는 논문이 든 가정이에요.)

다 읽고 남은 것

1. 추천은 반응 속도가 경쟁력이에요. 최근 행동을 얼마나 빨리 반영하느냐가 성능을 갈라요.
2. "대충 나눠 쓰기"에도 대가가 있어요. 칸 공유라는 작은 타협이 품질을 실제로 떨어뜨렸어요.
3. 완벽함보다 균형이에요. 자주 바뀌는 건 자주, 느리게 바뀌는 건 가끔. 백업도 필요한 만큼만요.

그래서 처음 질문, "몇 분 걸릴까?"에 대한 답은 이래요. 이 논문의 시스템 기준으로는 개인 취향 칸이 분 단위로 서비스에 반영돼요. 내가 쓰는 앱이 정확히 그런지는 이 논문만으로는 알 수 없어요.

다음 글은 취향 대신 얼굴을 숫자로 바꾸는 얘기예요. 얼굴 하나가 숫자 512개가 되고, 그 숫자에서 얼굴이 다시 그려지는 실험까지 있어요. '다음에 읽을 글'에서 이어져요.