보상을 넣기 전에, 어떤 행동을 늘릴지부터 물었다

업무에서는 콘텐츠와 활동에 따른 포인트 처리를 다뤘고, bubbleBible에서는 읽기와 나눔을 돕는 보상 구조를 고민했다. 같은 포인트라는 이름을 쓰지만 제품이 원하는 행동은 달랐다. 기존 기능을 그대로 옮기는 것이 좋은 설계는 아니라는 점을 느꼈다.

시스템이 세는 행동과 사람에게 남는 가치

클릭과 작성 횟수는 세기 쉽다. 이해하고 읽었는지, 의미 있는 나눔이 있었는지는 그렇게 간단하지 않다. 측정하기 쉬운 행동에 보상을 붙이면 제품이 원래 돕고 싶었던 행동과 어긋날 수 있다. 클릭 수가 많아졌다고 읽기 경험까지 좋아졌다고 말할 수 없는 이유다.

bubbleBible의 초기 회고에서는 보상이 묵상 자체를 대체하지 않도록 절제하는 방향을 남겼다. 돌아보면 포인트의 양을 정하는 것보다 중요한 판단이었다. 기능이 사용자의 관심을 어디로 향하게 하는지 먼저 생각해야 했기 때문이다.

지급 규칙은 운영 규칙이기도 했다

보상을 넣으면 중복 행동, 취소, 삭제, 비공개 전환을 어떻게 처리할지도 정해야 한다. 업무에서 포인트 지급과 차감을 다뤘던 경험이 이 질문과 연결됐다. 정상적으로 한 번 참여하는 경우만 구현하면 나중에 수정된 콘텐츠와 취소된 행동을 설명하기 어려워진다.

지금 다시 설계한다면 보상 대상 행동을 한 문장으로 적고, 반복 가능 횟수와 취소 조건을 함께 적겠다. 악용 사례를 상상해 기능을 복잡하게 만드는 것이 목적은 아니다. 사용자에게 약속한 규칙이 행동이 바뀐 뒤에도 일관적인지 확인하려는 것이다.

효과를 확인하는 방식도 달라야 한다

보상을 켠 뒤 이벤트 수가 늘어도 그것이 좋은 결과인지는 별도로 봐야 한다. 같은 사람이 반복 입력한 것인지, 실제로 읽기를 이어 가는 사람이 늘어난 것인지 구분해야 한다. 현재 회고에서 그런 효과가 측정됐다고 주장하지 않겠다. 구현과 효과 검증은 다른 단계로 남겨 둔다.

이 경험은 게임 요소를 쉽게 붙이기 전에 제품의 목적을 다시 묻게 했다. 다음에 포인트를 도입한다면 “얼마를 줄까?”보다 “이 행동이 늘면 사용자가 정말 원하는 일에 가까워질까?”부터 답하겠다. 계산 로직은 명확한 목적 뒤에 있어야 했다.

관련 기록: bubbleBible의 보상 설계, 포인트 상태 전이