왜 방어만으로는 충분하지 않은가

이 과목의 앞선 레슨들은 부정 수취를 어떻게 관찰·탐지·제재하는지에 집중했습니다. 이런 방어 장치는 프로그램의 손실을 줄이는 데는 필수적이지만, 그 자체로 좋은 추천을 늘려주지는 않습니다. 아무리 탐지 로직이 정교해도, 애초에 진짜로 제품을 좋아해서 추천하는 고객이 적다면 프로그램 전체의 성과는 낮은 수준에 머무릅니다. 방어는 새는 것을 막는 일이고, 설계는 애초에 좋은 것을 더 많이 만들어내는 일이라는 점에서 둘은 구분해서 봐야 합니다.

좋은 리퍼럴 프로그램은 이 두 축을 함께 갖춥니다. 진짜 추천 동기를 유도하는 설계가 있으면 애초에 부정 수취를 시도할 유인 자체가 상대적으로 줄어들고, 방어 장치가 있으면 그럼에도 발생하는 부정행위로부터 프로그램을 보호할 수 있습니다.

현금 대신 제품 가치를 보상으로 설계하는 이유

앞선 레슨에서 다룬 것처럼 현금성 보상은 부정행위자와 리워드 헌터를 더 많이 끌어들이는 경향이 있습니다. 반대로 스토어 크레딧, 서비스 내 기능 업그레이드, 다음 결제 할인처럼 제품 안에서만 가치를 갖는 보상은 애초에 그 서비스를 계속 쓸 생각이 있는 사람에게만 매력적입니다. 이런 보상 형태는 결과적으로 진짜 팬에 가까운 유저를 더 많이 끌어들이는 자연스러운 필터 역할을 합니다.

물론 크레딧형 보상이 만능은 아닙니다. 초기 사용자 기반이 작은 서비스는 현금성 보상으로 우선 절대적인 가입자 수를 확보해야 할 수도 있습니다. 다만 서비스가 일정 규모에 도달한 뒤에도 계속 현금성 보상에 의존한다면, 그 시점부터는 유저 품질 저하라는 대가를 치르고 있을 가능성을 점검해야 합니다.

추천받는 사람에게도 가치를 줘야 하는 이유

많은 리퍼럴 프로그램이 추천하는 사람의 보상에만 집중하고, 추천받는 사람이 얻는 가치는 소홀히 설계합니다. 이렇게 되면 추천 메시지는 받는 사람 입장에서 "이 사람이 자기 보상을 위해 나에게 보낸 스팸"처럼 느껴지기 쉽습니다. 신규 가입자에게도 실질적인 혜택(첫 결제 할인, 체험 기간 연장 등)을 함께 제공하면, 추천 메시지가 스팸이 아니라 실제로 받는 사람에게 이득이 되는 제안으로 인식될 가능성이 커집니다.

이 설계는 앞서 다룬 정보통신망법상 광고성 정보 전송 규제와도 맞물립니다. 받는 사람 입장에서 실질적 가치가 없는 메시지를 대량으로 유도하는 구조는 법적 리스크와 별개로도 스팸으로 인식돼 서비스 평판에 부정적 영향을 줄 수 있습니다.

만족한 고객을 골라 추천을 요청하는 타이밍

추천 요청을 모든 고객에게 무차별적으로 노출하는 대신, 서비스 이용 경험이 만족스러웠던 시점(목표를 달성했을 때, 긍정적인 피드백을 남겼을 때)을 포착해 그 순간에 추천을 요청하면 진성 추천의 비율이 높아지는 경향이 있습니다. 아직 제품 가치를 제대로 경험하지 못한 신규 가입 직후에 추천을 요청하면, 정작 그 고객 자신도 확신이 없는 상태에서 지인에게 서비스를 권하게 되어 추천의 질이 떨어질 수 있습니다.

이런 타이밍 설계는 NPS(순추천지수) 설문이나 특정 마일스톤 달성 이벤트와 리퍼럴 유도를 연결하는 방식으로 구현할 수 있습니다. 만족도가 높다고 응답한 고객에게만 추천 요청을 노출하는 것도 진성 추천 비율을 높이는 실무적인 방법으로 꼽힙니다.

방어와 설계를 함께 적용해야 하는 이유

이 과목이 다룬 관찰 기준, 지표, 약관, 리포트는 모두 방어 장치입니다. 이번 레슨이 다룬 보상 형태, 추천받는 사람의 가치, 요청 타이밍은 설계 장치입니다. 두 장치는 서로 배타적이지 않고, 오히려 함께 있을 때 각자의 효과가 커집니다. 설계가 좋아 진성 추천 비율이 높아지면 방어 장치가 걸러내야 할 부정행위의 절대량 자체가 줄어들고, 방어 장치가 튼튼하면 설계 단계에서 보상을 조금 더 과감하게 실험해볼 여유가 생깁니다.

결국 리퍼럴 프로그램을 감사하는 관점에서 중요한 질문은 "부정행위를 얼마나 잘 막았는가"뿐 아니라 "애초에 얼마나 좋은 추천을 만들어내고 있는가"입니다. 이 두 질문에 대한 답을 함께 추적할 때 리퍼럴 프로그램의 전체적인 건강도를 제대로 평가할 수 있습니다.

설계 변경도 방어 지표로 검증해야 하는 이유

보상 형태를 현금에서 크레딧으로 바꾸거나, 추천 요청 타이밍을 만족도 높은 순간으로 옮기는 설계 변경을 적용했다면, 그 효과 역시 이 과목에서 다룬 방어 지표(IP·기기 중복률, 검토 기간 중 취소·환불률, 채널별 리텐션)로 검증해야 합니다. 설계를 바꿨다고 해서 부정 수취가 저절로 사라지는 것은 아니며, 오히려 새로운 보상 형태가 예상치 못한 방식으로 악용될 가능성도 열려 있기 때문입니다.

예를 들어 크레딧형 보상으로 바꾼 뒤에도 여전히 계정 사이클링이 발생한다면, 크레딧을 다른 사람에게 양도하거나 되파는 2차 시장이 형성됐을 가능성을 점검해야 합니다. 설계 변경 이후 한두 달은 특히 방어 지표를 더 자주 확인하며, 새 설계가 기존에 없던 부정행위 유형을 만들어내지 않는지 살펴보는 것이 안전합니다.