저는 스크립트 기반의 행동이 아닌, 학습된(learned) 정책이 브라우징, 유혹, 장바구니 포기, 그리고 소셜 그래프를 통한 다른 쇼퍼에게 미치는 영향 등 현실적인 이커머스 쇼퍼 세션을 생성할 수 있는지 확인하고 싶었습니다. 이것이 바로 FunnelForge입니다. 실제 리뷰 데이터를 기반으로 학습된 50개의 RL (강화학습) 에이전트가 쇼핑 인구 전체를 엔드 투 엔드(end-to-end)로 시뮬레이션합니다.

문제 (The problem)

대부분의 쇼퍼 시뮬레이션은 스크립트 방식이거나 규칙 기반(rule-based)입니다. 저는 에이전트가 단순히 요청에 따라 전환(conversion)되는 것이 아니라, 대부분의 경우 장바구니를 포기하는 것과 같은 현실적인 부분을 포함하여 실제 쇼퍼처럼 행동하도록 학습되는 방식을 원했습니다.

아키텍처 (Architecture)

의도적으로 분리된 두 개의 평면(plane)이 존재합니다:

데이터 평면 (Data plane) (행동 생성):

• 고정된 타임스텝(fixed timesteps) 대신 min-heap 이벤트 스케줄러를 사용합니다. 에이전트들은 락스텝(lockstep) 틱이 아닌 자신만의 연속 시간(continuous-time) 스케줄에 따라 행동합니다. 이는 틱 루프(tick loop)보다 더 현실적이고 복잡합니다.
• BFS(너비 우선 탐색) 영향력 전파(1/2^depth 감쇠)를 갖는 Erdős–Rényi 소셜 그래프를 사용합니다. 한 에이전트의 구매는 그래프 거리에 따라 감쇠하며 이웃에게 영향을 줄 수 있습니다.
• **위상적 퍼널 게이트 (topological funnel gate)**를 사용합니다. 에이전트는 browse → product_detail → cart → checkout 단계를 거치며, 단계를 건너뛸 수 없도록 게이트가 설정되어 있습니다.
• 이 세 가지 모두 pybind11을 통해 C++로 컴파일되어 기본적으로 사용되며, 컴파일된 모듈이 없는 경우 자동으로 순수 Python 폴백(fallback)이 작동합니다.

제어 평면 (Control plane) (이동 및 관찰):

• 모든 액션은 Redis와 Kafka에 게시되며, FastAPI WebSocket을 통해 라이브 대시보드로 스트리밍됩니다.

학습 (Training)

먼저 실제 이커머스 리뷰 데이터에 대해 행동 복제(Behavioral cloning, BC)를 수행한 다음, 그 위에 PPO (Proximal Policy Optimization) 미세 조정(fine-tuning)을 진행합니다. 처음부터 순수 RL로 학습하는 것은 이 사례에서 비현실적이었습니다. 거대한 이산 액션 공간(수천 개 중 어떤 제품을 선택할 것인가)에서 희소한 보상(sparse reward)은 좋은 사전 정보(prior) 없이는 잘 수렴하지 않기 때문입니다. BC는 정책에 현실적인 시작점을 제공하고, PPO는 이를 정교화합니다.

검증 — 그리고 솔직한 부분 (Validation — and the honest part)

시뮬레이션은 약 50개의 에이전트에 대해 확률적(stochastic)으로 작동하므로, 라이브 대시보드 피드가 아닌 시드(seed)가 설정된 재현 가능한 배치 실행(FF_SEED=42)을 통해 검증합니다.

네 가지 지표 중 세 가지가 실제 산업 범위 내에 들어왔습니다. 네 번째 지표인 사회적 영향력 집중도 (social-influence concentration)는 범위 밖에 있었는데, 이 부분에 대해 특별히 이야기하고 싶습니다. 모든 지표를 통과시키는 것보다 실패한 지표를 어떻게 다루느냐가 더 중요하다고 생각하기 때문입니다.

원인을 추적해 보니, 제품 카탈로그 (product catalog)의 폴백 경로 (fallback path)가 해당 지표가 의존하는 분포를 희석시켜 측정된 전염 효과 (contagion effect)를 약화시키고 있었습니다. 숫자가 맞을 때까지 파라미터 (parameter)를 튜닝하는 대신, 저는 진단 내용을 기록하고 실제 수정 사항은 미결 과제 (open problem)로 남겨두었습니다. 단, 한 가지 제약 조건을 걸었습니다. 수정을 하더라도 이미 통과한 나머지 세 가지 지표가 퇴보 (regress)해서는 안 된다는 것입니다. 이는 숫자 자체보다 훨씬 더 흥미로운 문제가 되었습니다. 쉬운 "해결책"(사회적 부스트 파라미터를 높이는 것)은 그 과정에서 전환율 (conversion)과 이탈률 (abandonment)을 망가뜨렸기 때문입니다.

다음에 더 일찍 확인했을 사항들

다음에는 더 일찍 잡아낼 수 있었던 두 가지 사항이 뒤늦게 드러났습니다:

1. 사용되지 않고 조용히 방치된 컴파일된 컴포넌트 (compiled component). C++ pybind11 모듈이 존재했고 컴파일도 잘 되었지만, 라이브 시뮬레이션은 내내 Python 구현체를 임포트 (import)하고 있었습니다. 아무런 충돌도, 경고도 없었습니다.

코드 + 전체 README: github.com/ojas4414/FunnelForge

자유롭게 실행하고 학습할 수 있습니다 — PolyForm Perimeter 라이선스 하에 소스 코드가 공개되어 있습니다. docker compose up 명령어를 통해 라이브 대시보드를 포함한 전체 스택을 실행할 수 있습니다. 또한, 보다 구조화된 학습 경로를 원하는 분들을 위해 유료 문서 번들(아키텍처 심층 분석, 가이드 워크스루, 단계별 연습 문제, 인터뷰 준비)도 제공되며, 이는 README에 링크되어 있습니다.

고정된 타임스텝(fixed-timesteps) 기반의 최소 힙(min-heap) 방식 결정에 대해 사람들이 어떻게 생각하는지, 혹은 Erdős–Rényi 모델이 처음에 선택하기에 잘못된 사회적 그래프 (social graph) 모델이었는지 궁금합니다. 두 결정 모두 잘못된 선택이었다는 피드백을 환영합니다.