오늘은 내가 OverProtocol의 디스코드 서버를 만들었던 과정을 바탕으로 기획 단계에서 참고하거나 고려할 부분들에 대해 이야기 해볼거야.

다양한 서버 경험해보기

다양한 서버들을 경험해보면 우리 서버의 모습을 상상하거나 개선할 때 도움되는 부분들이 많아.

나는 Layer 1 블록체인 프로젝트의 서버를 기획하고 있어서 당시 초기 단계인 Aptos, Sui, Sei, 출시 후 시간이 조금 지난 Near, Avalanche, Klaytn, 노드를 운영하는 멤버가 많은 Shardeum이나 Havah의 서버를 주로 들여다 봤어.

Optimism이나 Arbitrum의 경우 Layer 2 블록체인이지만, 생태계도 활발하고 파트너십 등이 많았기에 차이점을 확인하고자 많이 보았던 것 같아.

어떤 서버를 봐야 할 지 잘 모르겠다면 많은 서버에 들어가보고 채널/카테고리 구성과 역할, 온보딩, 멤버의 대화 주제 등을 확인해보고 며칠 활동하면서 분위기를 경험해 보는 것도 도움이 될 수 있어.

DeFi나 NFT 프로젝트도 마찬가지로 비슷한 유형의 서버를 확인해보면 좋겠지?

Layer 1 블록체인 서버도 특성이나 목적에 따라 구성이 달라질 수 있다.(출처 : 좌 Sei,우 OverProtocol)

하지만 나는 블록체인 프로젝트의 서버를 들어갈 때마다 불편한 점들이 많았어. 익숙하지 않은 언어로 된 안내, 봇 방지를 위한 불편한 필터링, 카테고리/채널 가시성 부족 등.

개인적으로 가장 불편해하는 캡챠 봇(좌)과 대안으로 선택했던 온보딩 기능(우) (출처 : Sei, LCK Legendaries)

“디스코드는 진입 장벽이 너무 높다”라는 말이 많은데, 플랫폼의 폐쇄성도 있지만, 이런 불편함도 한 몫 했던 것 같아.

나는 이런 문제를 줄이기 위해 블록체인이라는 틀에 갇히지 않고 다른 주제의 서버도 많이 경험해봐야 한다고 생각해.

로스트아크나 마인크래프트, 발로란트, 원신 등 게임 관련 서버, K-PoP 아티스트의 팬 서버, 미드저니 등 다양한 서버의 진입 과정이나 구성 등을 확인해보면 주제가 다르니 당연히 멤버의 구성이나 서버의 목적도 다르고, 기존에는 생각하지 못했던 방식으로 문제를 해결할 수 있는 길들이 보일 수 있어. 구체적인 내용은 심화 편에서 더 자세히 다룰 예정이야.

프로젝트의 서버 운영 목적 및 KPI 설정하기

커뮤니티는 관성적으로 만들게 되는 경우가 많아. 준비할 시간이 부족해서 깊은 고민이나 생각을 하지 않고 비슷한 서버를 참고해서 만들게 되는 경우도 많지.

이렇게 만든 서버는 당연하게도 프로젝트의 목적이나 멤버의 특성이 잘 반영될 수 없어.

프로젝트도 멤버의 행동을 유도하거나 전달하려는 정보를 제대로 전달하기 어렵고, 멤버도 지루하거나 필요하지 않아서, 정보를 효율적으로 얻기 어려워서 서버를 떠나게 되기도 해.

서버 운영은 비용이 들어가는 일이고, 만든 서버는 폐쇄하거나 변경하기 어렵기 때문에 만들기 전에 미리 운영 목적과 KPI를 명확히 하는 것이 좋아.

OverProtocol은 OverWallet과 OverNode가 초기 생태계의 중심이고, 이 프로덕트들을 사용하는 사람들이 서버의 주요 초기 멤버가 될 것이라고 생각했어.

정보 전달 채널로는 트위터와 미디엄도 있지만, 궁금한 부분들을 질문하고 답변 받을 수 있는 공간도 필요했지.

나는 OverProtocol 서버의 초기 주제를 두 가지로 설정했어.

1. OverProtocol 생태계 관련 정보 교류
2. OverWallet과 OverNode의 CS(Customer Service)

초기 블록체인 커뮤니티는 에어드랍을 기대하고 모이는 사람이 많아. 이들은 자연스레 프로젝트에 관심을 가지게 되고, 여러 궁금증들이 생길 수 있지.

그리고 초기 프로덕트 내 CS 채널 생성이나 이메일/스토어 댓글을 통한 개별 응대 지원은 개발, 운영, 관리 리소스가 많이 소요되는 일이기에 디스코드를 CS 채널로 활용하는 경우가 많아.

나는 누군가의 도움을 받는 경험은 좋은 기억으로 남는다고 생각해. 특정 사람이나 집단에 대한 좋은 경험들은 신뢰와 호감으로 이어지는 경우도 많지.

이런 메세지들을 더 자주 볼 수 있도록 만드는 것이 하나의 목표이다.

궁금증을 친절하게 해소해주거나 이슈가 발생했을 때 적극적으로 해결하는 모습을 보여주면, 자연스레 프로젝트와 멤버들 사이에 라포가 형성되고 원활한 소통이 가능해질 수 있어.

따라서 내가 생각한 OverProtocol 서버의 목적은 프로젝트와 커뮤니티 멤버, 혹은 멤버들 사이에 라포를 형성하는 것을 도와 단단한 커뮤니티를 만드는 것이고, 위 2 가지 초기 주제는 이런 목적을 위한 좋은 수단이었어.

내가 생각한 서버의 KPI는? (예시)

1. 서버/채널 재방문률
2. 공개 문의에 대한 모더레이터 응답 비율
3. 공개 문의에 FAQ를 기반으로 답변한 메세지 수(운영 리소스 절감)
4. 비공개 문의 티켓 생성 수/처리 비율
5. 비공개 문의 종료 이후 고객 만족도 조사 지표

문의 Ticket을 Notion에 Tag를 지정하여 기록하면 통계 및 이슈 파악에 활용할 수 있다.

보통 서버의 KPI를 멤버 유입, 메세지 전달 수 등 서버의 활성도를 기반으로 측정하는 경우가 많은데, 이런 지표들은 프로젝트 이슈의 영향을 더 크게 받는 지표이기에 다른 지표들도 필요하다고 생각했어.

신규 회원 유입이 변화하더라도 리텐션은 비교적 일정하게 유지된다.

서버의 목적 또한 2 가지 초기 주제를 중심으로 라포 형성을 돕는 것이기에, KPI도 서버에 방문하면 궁금증이나 이슈를 원활하게 해결할 수 있다는 경험을 제공하는 것에 초점이 맞춰져 있지.

OverProtocol 서버도 아직 부족한 부분이 많지만, 목적과 방향성이 명확하기에 지속적인 개선을 통해 이러한 KPI를 향상시키기 위해 노력하고 있어.
오늘은 서버를 기획하는 단계에서 도움이 될 만한 방법들이나, 기획 단계에서 중요하게 생각해야 하는 부분들을 정리해봤어.

다음 글에서는 디스코드 계정의 보안 설정과 서버의 기본적인 설정들, 서버 멤버의 페르소나를 정의하여 설계에 반영하는 과정에 대해 다룰 예정이야.

출처: 루디움(https://ludium.world),
디애셋 프로(https://contents.premium.naver.com/digitalasset/digitalassetpro)

Arang | Community Manager of OverProtocol

Lives in Metaverse Community

📍더 알아보기 : https://t.me/coiniseasy

📍코인이지 앱 : 

IOS- https://apps.apple.com/us/app/coineasy/id6463145391

Andoid - https://play.google.com/store/apps/details?id=com.coineasy.coineasy