걱정할 시간에 도전을

2만명에 육박한 사용자들이 우리가 빠르게 공수한 프로젝트들을 수행하며 수익을 창출하기 시작했다. 이 과정에서 우린 경쟁사의 사용자들만 뺏어온게 아니라 조건이 까다로워 경쟁사에 들어가지 못했던 사용자들도 대거 유입되었음을 알았다. 프로젝트 마다의 효율을 높이고 속도와 품질을 모두 높여야 했던 운영 책임자들이 어려움을 토로하기 시작했다. 가이드를 제공하거나 FAQ로는 해결이 안되고 있었다.

비슷한 시기에 토스 증권에 커뮤니티 서비스가 등장했다. 허브가 되는 사용자가 여러 사용자들을 데려오고 이들의 글이 다른 사용자들의 제품 결합을 이끌었다. 운영 비용이 증가할 것이라는 우려도 있었지만 지금의 운영 비용과 별반 차이가 없을 것이라는게 내 판단이었다. 마침 제품팀 하나를 온전히 맡아서 운영 중이었고 프로젝트를 운영할 PM 조직이 세팅되면서 BDM과 마케터도 해당 조직으로 배치되었다. 제품팀과의 한번의 이터레이션을 돌며 호흡이 맞춰지자 나는 본격적으로 입을 열었다.

"우리 커뮤니티를 만들어 봐요!"

잠시 침묵이 흐른 뒤 내가 왜 이런 생각을 하게 됐는지 설명하기 시작했다. 장황하지만 우리가 함께 좋은 결과를 만들려면 필요한 설명이었다.

"프로젝트의 효율은 증가하지 않고 우린 프로젝트 운영 인력을 계속 늘려나가야 해요. 공개되지 않은 고객 커뮤니케이션도 문제이지만 우리의 지식이 사용자들 간에 전파가 안된다는 문제가 있어요."

"그럼 커뮤니티의 형식은 어떤 걸로 생각하신건가요? 게시판 같은 걸까요?" 모바일 앱 개발을 하는 동료가 이어폰 너머로 물어왔다.

"네 맞아요! 채팅은 휘발되니까 게시판이 더 적합할 거라고 생각해요!" 나는 자신에 차서 대답했다.

"하지만 악성 게시글이 올라온다거나 과도하게 비난이 섞인 글이 올라오면 어떻게 하죠?" "댓글은 어떻게 처리할 것인지, 지금 하고 있는 일들 보다 이게 우선순위가 높아져야 할 만큼의 임팩트인지 잘 모르겠어요"

팀원들의 질문이 쏟아지기 시작했다. 이럴 때 나는 답변해야 한다는 의무감에서 벗어나 함께 아이디어를 모아보려고 노력한다.

"제 생각은 비난이 섞인 글이 올라올지 아닐지 모르는 상태라 뭘 어떻게 해야 한다는 생각까지 미리 하진 못했어요. 하지만 그정도의 운영이 지금 들어가는 중복된 질문에 답변하는 것보다 효율적일 수 있다는 생각도 들었어요. 댓글은 대댓글 같은 복잡한 구조 생각하지 말고 댓글만 달 수 있어도 된다 생각해요."

"누가 어디에 답변을 남긴건지 정도를 알려면 멘션 정도는 필요하지 않을까요?" "그래도 대댓글은 필요하지 않을까요?"

질문들이 이어졌다.

"대댓글까지 구현하는데에 시간이 얼마나 더 추가되어야 할까요? 둘 중 어떤 방식이 더 효율적일까요? 왜냐면 이게 어떤 임팩트가 있을지 확신할 수 없기 때문에 더 빨리 검증 가능한 방식으로 하고 싶어요."

우린 웹과 앱까지 동시에 진행 중이었기 때문에 기본적인 배포에도 시간이 걸리는 것을 가정해야만 했다. 여러 토론의 과정을 거치며 3일 만에 웹을 시작으로 배포가 시작됐다. 그렇게 많은 사용자들이 커뮤니티탭으로 몰려왔고, 커뮤니티탭에서 주고 받는 대화들을 약 2주 간 모니터링하며 기대했던 효과까지 줄었는지 살펴보았다. 결국 우린 커뮤니티에서 경쟁사들의 프로젝트에 대한 대화까지 오고가는 장을 확인했고 일일 리텐션¹이 40%를 초과하는 성과를 만들었다.

하지만 또 한번 새로운 문제가 나타났다. 사용자를 많이 불러오고 자주 들어오게 하면서 프로젝트 완료 속도가 매우 빠르게 증가했고, 결과적으로 또 다시 프로젝트의 수를 더 빠르게 늘려야 하는 숙제가 생겼다.

Footnotes

1. Daily Retention, 어제 들어온 사용자들 중 오늘 다시 사용하는 사용자 비율 ↩