글쓰기를 걷어낸 커뮤니티 설계, 우리 서비스에 옮기기 전에 확인할 세 가지

커뮤니티 개편 사례를 읽을 때 저는 설계보다 먼저 한 가지를 봐요. 손대지 않았는데도 살아 있던 구석이 있었는가. 마이리얼트립 동행매칭 개편기의 출발점이 정확히 그거예요. 여러 주제의 게시판 중에서 동행매칭 카테고리만 오래 손대지 않은 동안에도 여행자들이 스스로 글을 쓰고 서로 답을 달고 있었고, 프로덕트 엔지니어 김경훈 님은 계속 관리해야 콘텐츠가 올라오는 영역은 같은 노력으로 같은 결과를 기대하기 어렵다고 판단해 그 한 곳만 남겼어요. 자유 주제 게시판은 정리하고, 커뮤니티가 다루던 넓은 주제 범위를 포기하고, 동행을 찾는 한 가지 목적으로 좁힌 거죠. 이 개편에서 가져갈 게 많은데, 옮기기 전에 확인할 것도 세 가지예요.

우리에게도 그 구석이 있는가

이 팀이 한 일 중에 설계는 뒤에 있어요. 앞에 있는 건 관찰이었어요. 게시판 하나만 남기고, 분류를 권역·국가·도시로 다시 잡고, 통합검색에서 예전 콘텐츠를 추천하던 자리를 동행 찾기로 바꾼 건 전부 "여기는 사람이 알아서 온다"는 관찰 위에서 나온 결정이에요. 목적지를 검색하는 시점이 동행을 떠올리는 시점과 가장 가깝다는 판단도 그렇고요.

그래서 이 사례를 옮기려는 팀이 먼저 뽑아야 할 데이터는 화면 시안이 아니라 "운영을 멈춘 동안에도 살아 있는 영역"이에요. 그게 없으면 카드든 찾기든 설계를 아무리 잘해도 빈 방에 가구를 놓는 일이 돼요. 있다면 그 한 곳으로 좁히는 게 이 글의 첫 번째 교훈이고, 좁히면서 포기하는 범위를 이 팀처럼 명시적으로 적어두는 게 두 번째예요.

쌓이는 것과 성사되는 것을 따로 재는가

가져갈 장치는 카드예요. 동행 글을 열 개 이상 찾아본 사람 중에서도 대다수가 자기 글을 쓰지 않았다는 관찰에서, 이 팀은 글쓰기를 요구하지 않는 쪽으로 갔어요. 화면의 말을 대부분 '찾기'로 통일하고, 사용자가 조건을 고르면 그 조건이 그대로 남아서 다른 사람이 보는 콘텐츠가 되게 했어요. 글쓰기라는 말을 화면에서 뺐다는 인용이 이 설계의 전부예요. 찾는 행동을 하다 보면 어느새 콘텐츠를 남기는 쪽에 들어와 있는 구조. 눈팅족이 다수인 커뮤니티라면 어디든 적용할 수 있는 원리이고, 저는 이게 이 글에서 제일 값진 대목이라고 봐요.

다만 이 팀이 재는 지표와 우리가 재야 할 지표가 달라요. 글이 세운 기준은 "다른 입력이 없어도 콘텐츠가 생기는가"였고, 카드는 지금 그 기준을 충족하며 매일 쌓이고 있어요. 카드를 남긴 사람이 다시 찾아오는 정도는 게시글을 쓴 사람과 거의 비슷했고, 대화로 이어지는 정도는 오히려 더 나았다고요. 여기까지가 글이 보여준 전부고, 전부 상대적인 표현이에요. 숫자는 하나도 없어요. 그리고 동행매칭의 성공은 콘텐츠가 쌓이는 게 아니라 동행이 성사되는 거예요. 카드는 같은 시기에 같은 도시로 가는 사람이 있어야 의미가 생기는데, 그 밀도는 대도시와 성수기에만 있어요. 소도시나 비수기에는 카드가 쌓여도 상대가 없고, 쌓이는 카드는 그때 성과가 아니라 응답 없는 요청이 돼요. 이 방식을 옮긴다면 성사율과 지역별 밀도를 처음부터 지표에 넣어야 하고, 낯선 사람을 연결하는 서비스라면 신고·차단 같은 안전 장치도 프로필보다 먼저예요. 글에는 그 부분이 없어요.

작게 붙여 확인하는 방식을 그대로 가져갈 수 있는가

이건 조건 없이 가져갈 것. 이 팀은 카드를 독립 서비스로 내지 않고 동행매칭 게시판 상단의 섹션 하나로 먼저 붙였어요. 가정이 틀렸더라도 섹션 하나를 내리는 선에서 정리할 수 있는 규모로요. 조건만 입력하면 되는 방식이 정말 참여 문턱을 낮추는지는 게시판 관찰로는 알 수 없고 화면에 올려봐야 안다는 판단이었고, 확인이 끝난 뒤에야 독립 서브탭으로 분리하면서 동행 프로필을 더하고 기다리는 화면을 찾는 화면으로 바꿨어요. 큰 화면을 먼저 마련하고 안을 채우는 순서를 거부한 게 이 개편의 속도예요. 넉 달에 다섯 가지를 냈다는 게 그 결과고요. 구 게시판 정리, 통합검색 섹션 개선, 게시판 분류 재정리, 같은 상품을 구매한 사람들을 연결하는 동행 서비스, 그리고 조건을 골라 동행을 찾는 방식. 이 주기를 짧게 가져가려고 AI 기반 개발 하네스를 직접 구축했는데, 매번 같은 방식으로 처리되는 작업만 자동화에 넘기고 판단이 필요한 일은 남겨뒀다고 해요. 하네스를 다루는 일의 대부분이 무엇을 넘기고 무엇을 들고 있을지 가르는 일이었다는 대목은, 도구보다 그 기준을 세운 사람의 몫이 컸다는 뜻으로 읽혀요.

한 사람이 무엇을 남길지 정하는 일부터 화면 구현까지 다 했다는 건 이 속도의 원천이면서 옮길 때 가장 재현이 안 되는 부분이에요. 여러 팀이 나눠 맡는 조직에서는 섹션 하나를 붙이는 데도 합의가 필요하니까요. 그러니 이 사례를 옮기는 팀은 설계를 베끼기 전에 "섹션 하나를 붙였다 내릴 권한이 한 사람에게 있는가"부터 확인해야 해요.

조건을 셋으로 놓으면 이래요. 손대지 않아도 사람이 오는 구석이 있고, 그 구석에 시기와 장소가 겹치는 밀도가 있고, 섹션 하나를 붙였다 내릴 수 있는 팀이라면 이 개편은 그대로 옮겨도 돼요. 첫 번째가 없으면 설계부터 다시 봐야 하고, 두 번째가 없으면 카드는 쌓여도 성사가 없고, 세 번째가 없으면 넉 달이 아니라 한 해가 걸려요. 그리고 예약과 예약 사이에 들어올 이유가 정말 생겼는지는 이 팀도 아직 몰라요. 여행 예약 주기를 넉 달로는 못 보니까요. 그 답이 나올 때 이 개편의 진짜 성적표가 나와요.