바이럴 루프의 백엔드는 계보다
공유 버튼과 추천 코드만으로는 바이럴 루프가 생기지 않는다. 공개 결과물의 부모·자식 계보와 재생산·세대시간을 Rails 8에서 어떻게 기록할지 살펴본다.
제품에 바이럴 루프를 넣자는 말이 나오면 대개 공유 버튼부터 그린다. 카카오톡, 이메일, 링크 복사 버튼을 붙이고 친구를 데려오면 크레딧을 주는 규칙을 만든다. 리퍼럴 SaaS를 고른 뒤에는 바이럴 기능이 생겼다고 말한다.
이 장치들은 결과를 운반하거나 보상을 정산한다. 그러나 수신자가 왜 링크를 열어야 하는지는 만들지 못한다. 광고 문구가 붙은 추천 링크는 여전히 광고다. 친구가 보냈다는 사실만으로 수신자가 새 소프트웨어를 배워야 할 이유는 생기지 않는다.
이미 완성된 결과물이 제품 안에서 전파 경로를 만든다. Typeform의 응답자는 누군가 만든 설문을 먼저 사용하고, 제출 뒤에야 ‘Create a typeform’을 본다. Figma Community의 방문자는 파일과 프로토타입을 미리 본 뒤 독립된 사본을 만든다. Replit의 방문자는 공개된 앱을 작동시킨 뒤 Remix로 작동하는 독립 사본을 얻고 다시 고칠 수 있다.
세 제품에서는 사용자가 홍보물을 별도로 만들지 않아도 설문, 디자인, 앱이라는 업무 산출물이 다음 사용자의 진입점이 된다. 수신자는 설명을 읽는 대신 결과물을 먼저 사용해 본 다음 자기 결과물을 만들 수 있다.
결과물을 만드는 웹앱에서는 다음 사람도 다시 만들 수 있는 결과물이 전파 단위가 된다.
이 차이는 조회수와 바이럴을 구분한다. Goel과 동료들이 트위터의 10억 건 확산 사건을 분석했을 때 큰 도달은 깊은 사람 간 연쇄보다 한 번의 큰 방송에서 나오는 경우가 많았다. Leskovec와 동료들이 한 온라인 소매업체의 인센티브형 프로그램에서 400만 명의 추천망을 조사했을 때도 평균적인 추천은 구매를 잘 만들지 못했고 멀리 퍼지지 않았다. 많이 공유됐다는 사실만으로 제품 안에 자기증식 회로가 생겼다고 말할 수 없다.
공개 결과물 A를 본 사람이 결과물 B를 만들고, B가 다시 C의 출발점이 될 때 비로소 세대가 생긴다. 그래서 제품은 공유 횟수보다 A와 B의 관계를 알아야 한다. 원본은 무엇이었는지, 누가 새 결과물을 만들었는지, 몇 세대째인지, 새 결과물도 다시 공개됐는지가 남아야 한다.
그렇다면 공유 뒤의 재생산을 관찰하려면 제품은 무엇을 저장해야 할까?