바이럴 루프의 백엔드는 계보다

제품에 바이럴 루프를 넣자는 말이 나오면 대개 공유 버튼부터 그린다. 카카오톡, 이메일, 링크 복사 버튼을 붙이고 친구를 데려오면 크레딧을 주는 규칙을 만든다. 리퍼럴 SaaS를 고른 뒤에는 바이럴 기능이 생겼다고 말한다.

이 장치들은 결과를 운반하거나 보상을 정산한다. 그러나 수신자가 왜 링크를 열어야 하는지는 만들지 못한다. 광고 문구가 붙은 추천 링크는 여전히 광고다. 친구가 보냈다는 사실만으로 수신자가 새 소프트웨어를 배워야 할 이유는 생기지 않는다.

이미 완성된 결과물이 제품 안에서 전파 경로를 만든다. Typeform의 응답자는 누군가 만든 설문을 먼저 사용하고, 제출 뒤에야 ‘Create a typeform’을 본다. Figma Community의 방문자는 파일과 프로토타입을 미리 본 뒤 독립된 사본을 만든다. Replit의 방문자는 공개된 앱을 작동시킨 뒤 Remix로 작동하는 독립 사본을 얻고 다시 고칠 수 있다.

세 제품에서는 사용자가 홍보물을 별도로 만들지 않아도 설문, 디자인, 앱이라는 업무 산출물이 다음 사용자의 진입점이 된다. 수신자는 설명을 읽는 대신 결과물을 먼저 사용해 본 다음 자기 결과물을 만들 수 있다.

결과물을 만드는 웹앱에서는 다음 사람도 다시 만들 수 있는 결과물이 전파 단위가 된다.

이 차이는 조회수와 바이럴을 구분한다. Goel과 동료들이 트위터의 10억 건 확산 사건을 분석했을 때 큰 도달은 깊은 사람 간 연쇄보다 한 번의 큰 방송에서 나오는 경우가 많았다. Leskovec와 동료들이 한 온라인 소매업체의 인센티브형 프로그램에서 400만 명의 추천망을 조사했을 때도 평균적인 추천은 구매를 잘 만들지 못했고 멀리 퍼지지 않았다. 많이 공유됐다는 사실만으로 제품 안에 자기증식 회로가 생겼다고 말할 수 없다.

공개 결과물 A를 본 사람이 결과물 B를 만들고, B가 다시 C의 출발점이 될 때 비로소 세대가 생긴다. 그래서 제품은 공유 횟수보다 A와 B의 관계를 알아야 한다. 원본은 무엇이었는지, 누가 새 결과물을 만들었는지, 몇 세대째인지, 새 결과물도 다시 공개됐는지가 남아야 한다.

그렇다면 공유 뒤의 재생산을 관찰하려면 제품은 무엇을 저장해야 할까?

먼저 부모와 자식을 저장해야 한다. public_token과 공개·회수 상태는 링크의 수명주기를 다룬다. parent_id는 직접 파생을 귀속하고, root_id와 generation은 전체 계보와 세대별 확산을 빠르게 분석한다. 이 기록으로 명시적 파생은 관찰할 수 있지만 바이럴 기능의 증분 효과를 알려면 홀드아웃이나 무작위 실험이 필요하다.

공개 결과물과 원본 기록은 다른 객체다

공유를 위해 내부 결과를 그대로 공개하면 루프보다 사고가 먼저 난다. 진단 보고서라면 원본 입력, 이메일, 내부 권고, 모델의 원문 응답을 공개 객체에 넣지 않는다. 외부인이 봐도 되는 작은 스냅샷을 별도로 만들고, 사용자가 내용을 확인한 뒤 명시적으로 공개하게 해야 한다. 공개 링크는 회수할 수 있어야 하며 기본 상태는 비공개여야 한다.

게시된 스냅샷은 가능한 한 고정한다. 결과를 고치고 싶다면 조용히 내용을 바꾸기보다 새 버전을 발행해 무엇을 보고 파생됐는지 남기는 편이 낫다. 계보에는 어떤 결과가 새 사용을 만들었는지가 남는다.

Rails 8에는 이 구조를 만들 부품이 이미 있다

이 정도의 루프에는 별도 성장 프레임워크가 필요하지 않다. Active Record의 자기참조 관계로 부모와 뿌리를 저장하고, has_secure_token으로 공개 URL을 만든다. 만료되는 미리보기나 관리 링크에는 목적과 만료시간을 붙인 signed_id를 쓸 수 있지만, signed ID는 암호화가 아니므로 고객 정보나 진단 내용을 담아서는 안 된다.

결과 생성은 Active Job과 Solid Queue에 맡긴다. Rails 8.1의 ActiveJob::Continuable은 긴 작업을 단계로 나누고 재시작 뒤 마지막 완료 지점에서 이어갈 수 있다. 생성 요청은 controller의 rate_limit과 일일 사용량으로 막는다. 공개 페이지는 Rails가 서버 렌더링하고, 생성 상태를 갱신할 때 Turbo Frame이나 Turbo Stream을 쓴다. 공유 버튼은 Stimulus에서 Web Share API를 호출하고 지원하지 않는 환경에서는 Clipboard로 내려가면 된다.

여기서 Web Share의 Promise가 성공했다는 사실도 전환은 아니다. 브라우저와 운영체제에 따라 공유 창을 띄운 시점이나 데이터를 대상 앱에 넘긴 시점에 완료될 수 있다. 소유자 제외, 봇 필터, 중복 제거를 통과한 열람과 자식 결과물 생성은 서버 이벤트로 관찰한다. 익명 링크만으로 의도한 수신자였는지는 알 수 없다.

라이브러리도 같은 기준으로 고른다. 방문과 UTM 귀속이 필요해지면 Ahoy를 붙일 수 있고, 비교 실험을 할 만큼 트래픽이 쌓이면 Field Test를 검토할 수 있다. 공개 카드 이미지는 기존 image_processing과 libvips로 만들 수 있다. Tailwind CSS 4는 공식 문서에서 Sass와 함께 쓰도록 설계되지 않았다고 밝힌다. 바이럴 루프와 관계없는 CSS 전처리기를 관성적으로 추가하면 빌드 경로만 하나 더 생긴다.

SaaS는 남용 방지·관찰·정산을 대신한다

Cloudflare Turnstile은 자동화된 생성 요청을 걸러낸다. 과다 사용은 rate_limit과 사용량 할당으로 제한한다. PostHog는 반복되는 cohort와 retention 질문을 풀고, Resend나 Postmark는 이메일 전달을 맡는다. 이런 서비스는 이미 생긴 흐름을 방어하거나 관찰한다. 결과물이 파생될 이유를 대신 만들지는 않는다.

리퍼럴 SaaS는 보상, 파트너 귀속, 지급 같은 운영이 실제 병목이 됐을 때 가치가 생긴다. 아직 한 사람의 결과물이 다음 사람의 결과물을 만드는지 확인하지 못한 단계에서 붙이면 검증하지 않은 루프 위에 정산 시스템부터 올리는 셈이다.

박수 대신 번식을 센다

최소 이벤트는 많지 않다. 결과물 생성, 명시적 공개, 소유자를 제외하고 봇·중복을 걸러낸 외부 열람, 파생 시작, 자식 결과물 생성, 자식 결과물 공개를 서버에서 기록하면 된다. 공유 버튼 클릭은 share_intent라는 보조지표로 남길 수 있지만 성공 판정에 쓰지 않는다.

첫 번째 지표는 공개된 부모 하나가 일정 기간 안에 몇 개의 공개된 자식을 만들었는가다. 두 번째는 부모가 공개된 시점부터 자식이 공개될 때까지 걸린 시간이다. 반복 사용이 있는 제품이라면 자식 사용자가 다음 주기에도 핵심 행동을 했는지까지 봐야 한다. 가입이나 클릭만 세면 싸고 질 낮은 유입이 좋은 루프처럼 보인다.

처음부터 생성 과정을 전부 자동화할 필요도 없다. 사람이 만든 유료 원본은 비공개로 두고, 외부인이 즉시 이해할 수 있는 작은 공개 스냅샷만 수작업으로 만들어도 루프는 시험할 수 있다. 수신자가 “내 것도 만들어 보기”를 눌러 자식 결과물을 만들고 다시 공개하는 흐름이 확인된 뒤 생성 작업을 자동화하면 된다.

Rails 8은 제품을 바이럴하게 만들지 않는다. 다만 바이럴이라는 말을 공유 버튼과 추천 코드에서 꺼내, 결과물의 부모와 자식이라는 검증 가능한 데이터로 옮기게 해준다. 첫 번째로 추가할 표는 추천인 순위표가 아니라 parent_id가 있는 결과물 표다.

주요 출처: Replit, Remix an app; Figma, Duplicate Community files; Typeform, Remove Typeform branding; Sinan Aral·Dylan Walker, Creating Social Contagion Through Viral Product Design; Sharad Goel 외, The Structural Virality of Online Diffusion; Jure Leskovec 외, The Dynamics of Viral Marketing; Ruby on Rails, Rails 8.1 Release Notes, Signed ID, Rate Limiting API; MDN, Web Share API; Tailwind CSS, Compatibility. ‘전파 가능한 결과물’, parent/root/generation 계보, reproduction rate와 cycle time의 제품 적용은 위 사례·연구·공식 문서를 연결한 이 글의 해석이다. Rails 문서는 구현 가능성을 설명할 뿐 바이럴 성장을 보장하지 않는다.