인앱 채팅 기획하기
프로젝트 회고
최근 프로젝트 하나를 릴리즈해서, 그 프로젝트에 대한 기록을 남깁니다.
프로젝트에 대해 이야기를 하기 전 서비스에 대한 간략히 설명이 필요할 것 같네요. 제가 다니고 있는 딜리셔스라는 회사는 의류 도매 사업자분들과 소매 사업자분들의 사업을 도와드리는 제품들을 만들고 있습니다. 그 중 가장 대표적인 서비스는 신상마켓인데, 도소매를 잇는 커머스 플랫폼입니다. 간단히 말하면 도매 사업자분들은 상품을 등록하고, 소매 사업자분들이 상품을 탐색하여 주문할 수 있는 서비스 입니다. 그리고 이번에 진행한 프로젝트는 신상마켓 서비스 내에 채팅기능을 구축하는 것이었습니다.
왜 하게 되었나?
의류 도소매 간의 거래는 커뮤니케이션의 비중이 매우 높습니다. 소매사업자도 재고를 많이 두고 사업을 하지 않고 주문량을 보면서 도매에서 상품을 사입하고, 도매사업자도 소매의 반응을 보면서 생산을 소량으로 자주하는 특성이 있기 때문입니다. 덕분에 매우 빠르고 효율적인 대응이 가능하지만, 거래처에 상품이 없는 경우가 잦고 또 금방 단종될 수 있기 때문에 거래 전 꼭 상품이 있는지 확인을 해야하고 만약 없다면 언제 들어오는지도 확인을 하거나, 예약 주문을 해야합니다.
이런 특성으로 인해서 카톡이나 전화같이 커뮤니케이션을 하기 편한 수단으로 주문을 하는 경우가 상당히 많습니다. 그러나 이렇게 산발적이고 비정형화된 주문은 당장 한건 한건은 편할수 있어도, 여러건이 겹치면 수많은 비효율을 발생시킵니다. 단기적으로는 상품만 보고 주문은 다른 곳에서 일어나는 누수를 막기 위해, 장기적으로는 버벌 커뮤니케이션으로 인한 비효율을 개선하기 위해서 프로젝트를 시작하게 되었습니다.
솔루션을 쓰지 않은 이유
워낙 인앱채팅을 지원하는 솔루션이 잘 되어 있어서, 그런 솔루션을 사용하는 것도 고려대상이었습다. 그러나 결국 채팅을 내부적으로 구축하는 것으로 결정했습니다. 사실 그 결정이 상당히 조심스러웠는데 채팅은 성능이 너무나 중요한 서비스이기 때문입니다. 모든 서비스가 성능이 중요하겠지만, 채팅은 특히 대화 경험에서 이질감이 있으면 너무나 강력한 대체제(카톡)가 있기 때문에 유저이탈이 쉽게 발생할 수 있습니다. 게다가 저희의 고객분들은 이미 카톡을 많이 사용하고 계시니까요. 열심히 만들고도 안쓰는 상황을 피하려면 자체 구축으로도 충분히 훌륭한 성능의 채팅서비스를 만들어 좋은 대화 경험을 주어야하는 부담이 있었습니다.
그럼에도 자체 구축으로 방향을 잡은 이유는 단순히 대화만 중계하는 것으로는 승산이 없다고 생각했기 때문입니다. 우리 서비스가 가지고 있는 상품 정보와 마켓에 대한 지식을 활용하여 최적화된 기능들을 구축해야만 시장에서 저희 서비를 사용하실 수 있게 만들 수 있다고 생각했습니다. 외부 솔루션을 사용하면 초기 도입은 빠르지만 커스터마이징에 한계가 있고, 커스터마이징을 할 수록 개선 속도도 늦어질테니까요.
프로젝트 범위 정하기
유저에게 최적화 된 기능을 제공하는 채팅 서비스라는 장기적인 목표를 가지고 있지만, 첫 술에 배부를 순 없죠. 첫 번째 프로젝트는 채팅의 본질인 메시지의 수신과 발신에 집중하기로 했습니다. 메시지를 보내고 받는 것을 많은 유저들에게 안정적으로 제공하는 것만으로도 매우 어려운 일입니다. 세세한 기능들을 더한 버전을 출시하기보다 안정성적인 기본 서비스를 최우선으로 하기로 결정했습니다.
사실 안정성과 성능은 개발자의 일이라고 생각하실 수도 있지만 꼭 그렇지는 않습니다, PM도 무언가를 결정해야할 때 어떤 것이 더 안정적인지를 기준으로 놓고 판단할 수 있습니다.
프로젝트 목표 / 성과
채팅 서비스가 얼마나 효용을 제공하는지를 확인하기 위해 성과 목표는 서비스 내에서 댓글 등으로 산발적으로 진행되는 커뮤니케이션이 채팅으로 얼만큼 이동했는지를 확인하는 것으로 정했습니다. 관련된 지표들을 설정했고 지금도 트래킹 하고 있습니다.
채팅 기본구조 정의하기
새로운 서비스를 만들기 위해서는 그 토대가 되는 기본 구조를 잡아야 합니다. 기능은 수정하고 덧붙일 수 있지만 이 기본 구조는 앞으로는 흔들려서는 안되는 밑바탕입니다. 아래는 제가 이번 프로젝트를 기획하면서, 또 릴리즈 후 놓쳤다고 생각하는 기본 요소들입니다.
1. 프로필 생성 단위
프로필을 생성하는 단위에 대해서 결정이 필요합니다. 개인으로서 채팅을 사용하면 유저 = 프로필이라는 공식이 거의 맞겠지만, 사업자나 브랜드라는 단위가 들어오면 프로필은 꼭 유저가 아닐 수 있습니다. 예를들어 카톡 플러스친구와 대화를 할때, 유저 입장에서는 하나의 브랜드와 대화를 하는 것 같아 보이지만, 사실 그 브랜드 뒤에는 여러 담당자들이 숨어있고, 그분들이 돌아가면서 답변을 하고 있을겁니다.
저희 서비스도 사업자라는 단위가 있습니다. 그리고 프로필 생성도 사업자 단위로 만들었습니다. 사업자가 외부와 대화하는 내용은 소속 유저들 사이에 공유되어야 하는 정보이고, 오히려 개별적으로 진행되면 문제가 발생될 여지가 크기 때문입니다.
또 프로필은 내부의 유저가 될 수도 있습니다. 첫 프로젝트에서는 이 부분이 포함되지 않았지만 앞으로는 신규 프로필 타입으로 내부 서비스를 생성할 수 있도록 할 계획입니다.
2. opt in / opt out
대화방의 시작과 종료에 대한 정의입니다. 언제 대화방을 생성하게 할지, 생성된 대화방은 언제까지 유지될지, 언제 대화방을 종료시킬지 결정해야합니다. 특성에 따라서 누구나 자유롭게 대상을 찾아서 대화할 수도 있고, 먼저 대화를 시작하는 대상을 제한할 수도 있겠죠.
채팅방의 종료도 "나가기"와 같이 명시적인 액션으로 제공하고 기존의 내역을 모두 삭제되도록 할수도 있지만, 종료를 제공하지 않고 유사한 사용성을 위해 리스트에서 "보이지 않기" 정도의 기능으로 대체할 수도 있습니다.
3. 메시지 타입
어떤 컨텐츠를 전송할 수 있게 할 것인지 정해야합니다. 기본적으로는 텍스트 메시지가 되겠지만 그외 이미지, 동영상 등 전송이 필요한 컨텐츠를 정의하고 각 타입은 어떤 정보를 포함하는지 정해야 합니다. 일반 텍스트라면 따로 보여지는 정보를 정리할 필요가 크게 없겠지만 위에 말씀드린대로 저희는 다양하게 커스텀 된 메시지를 전송할 계획이 있으므로 해당 커스텀 메시지 타입을 따로 정하고, 그 안에 세부 커스텀 메시지 타입을 정의했습니다. 이 세부 타입은 기능을 발전시키면서 조금씩 늘어나게 되겠죠.
4. 메시지에 표시되어야 하는 정보
모든 메시지는 타입과 무관하게 기본 정보를 보여주어야 합니다. 보통 누가 보냈는지, 언제 보냈는지 등 입니다. 채팅 서비스들이 발전해 오면서 어느정도 정형화 되어 있어 다른 서비스를 참고하면 어렵지 않게 정리할 수 있습니다. 다만 저희는 프로필의 단위가 유저가 아니기 때문에, 발신한 유저의 정보를 메시지 정보에 같이 보여주기로 했습니다.
5. 메시지 보관 기간 / 보관 장소
메시지의 보관 기간은 보관 장소와 밀접하게 연관이 되어 있습니다. 메시지를 서버에 보관할지 클라이언트에 보관할지에 따라서 보관 기간이 결정됩니다.
메시지를 모두 서버에 보관하면 정의한 기간까지만 조회가 가능합니다. 그렇다면 정상적인 사용성을 위해서는 보관기간이 꽤 길어야겠죠. 그럼 클라이언트 보관보다 리소스가 더 필요해집니다.
메시지를 클라이언트에 보관하면 유저가 앱 설정에서 대화 데이터를 삭제하지 않는 이상 모든 과거 기록을 조회할 수 있습니다. 서버에서 보관하는 기간은 상대적으로 짧아서 리소스는 더 적게 사용한다는 장점이 있지만, 대화가 많아질수록 기기에서 차지하는 용량이 커지고 짧은 서버 보관기간동안 서비스에 접속하지 않으면 해당 기간동안의 메시지가 유실된다는 단점이 있습니다.
어느것이 꼭 좋다고 할수 없고, 개발 리소스와도 연관이 있어 개발팀과 잘 이야기하여 결정해야 합니다.
채팅의 조건과 동작 정의하기
인앱채팅은 스탠드얼론 메신저와는 다르게 다른 페이지와의 이동, 서비스 내의 다른 조건들와의 의존성을 고려해야 합니다. 신상마켓의 경우 대표적으로 주문이라는 유저간의 액션과 채팅관의 관계를 정리해야 했습니다. 예를 들어서 어떤 주문 상세 페이지 안에서 시작되는 채팅은 그 주문에 대한 대화라는 것을 표시해주어야 합니다. 만약 그 주문이 아직 도매 사업자에게 전달되기 이전이라면 (시장 특성에 의한 일반적이지 않은 케이스라 구체적인 상황 설명은 생략합니다...) 해당 주문에 대한 채팅은 할수 없어야합니다.
동작정의도 필요합니다. 채팅방으로 진입할 수 있는 경로가 몇개인지, 각 경로마다 고려해야할 특성과 조건은 없는지 있다면 각 조건에서 어떻게 동작할 것인지 정의 되어야 합니다.
그리하여... 수많은 작은 결정들과 수많은 커뮤니케이션을 통해서 드디어 기능이 출시되었습니다. 개발 과정의 디테일은 다 옮기지 않았습니다. 지면이 부족하다는 핑계를 대봅니다....
엄청난 능력의 개발자분들과 QA분들 덕분에 좋은 성능의 퀄리티 높은 결과물이 나왔습니다. 닫힌 플랫폼이 아니라면 여기저기 자랑하고 싶은데 너무 아쉽습니다. 이번 프로젝트는 기본 기능을 구축하는데 집중했으니 앞으로는 유저에게 맞춘 기능을 추가할 계획입니다. 의류 도소매자들 사이에서는 그 무엇보다도 편한 커뮤니케이션 수단이 되는게 목표입니다. 향후 진행되는 프로젝트들에 대해서도 앞으로 정리를 하겠습니다. 제가 게을러지지 않는다면 말이죠.
