헤이조이스 웨비나 시스템을 2주 만에 만든 방법

컬리 자회사 플래너리가 코로나로 오프라인 강연을 온라인으로 전환하며 2주 만에 자체 웨비나 시스템을 개발한 이야기다. 초소형 조직이 AWS IVS·Sendbird 같은 외부 솔루션과 서버리스 MSA를 적극 활용해 라이브 스트리밍·실시간 채팅·참석자 관리를 빠르게 구현했고, 3년간 200회 넘는 웨비나를 무장애로 운영 중이다.

핵심 포인트

줌·이벤터스 등 외부 솔루션은 별도 사이트 접속·운영 리소스 과다·데이터 수집 불가 문제가 있어 자체 웨비나를 결정했다.
라이브 스트리밍은 AWS IVS, 채팅은 Sendbird Open Channel(기본 1000명, 초과 시 Dynamic partitioning)로 빠르게 구성했다.
데이터는 GraphQL과 DynamoDB, AWS AppSync·EventBridge 기반 서버리스 MSA로 구현했다.
크롬 자동재생 정책(음소거 필수)과 새로고침 시 재음소거 문제를 안내 UI로 우회했다.
DynamoDB 항목당 400KB 한계 때문에 웨비나 정보와 참석자 데이터를 테이블 분리해 1000명 이상을 수용했다.

상세 정리

요구사항: 사용자에겐 이메일·카톡으로 시청 URL 발송과 스트리밍/채팅/강연정보 UI, 운영자에겐 결제-웨비나 연결로 참가자 관리, 데이터엔 참가·시청 정보 수집이 필요했다.
AWS IVS: ivsClient SDK로 채널을 생성해 channel·streamKey를 받고, playback_url을 Video.js 플레이어 src에 연결했다. controls·inline 재생·자동재생·replay off 등을 설정해 채팅과 영상을 동시 화면으로 제공했다.
Sendbird: 웨비나 생성 시 Open Channel을 함께 만들고, 유저 접속 시 id·닉네임으로 connect해 헤이조이스 유저 정보를 채팅에 그대로 썼다. 이후 meta counter로 리액션, user list로 참석자·실시간 시청자 수 기능을 추가했다.
서버리스 구성: 외주로 개발된 강연 리스트·결제를 제외한 신규 서비스는 MSA로 만들고, 기존 RDB의 주문 정보에서 참석자를 뽑아 웨비나 DynamoDB에 적재하는 작업을 Lambda로 정의해 EventBridge로 매시간 배치했다.
자동재생 개선: 강연 전 미리 접속해 검은 화면을 보는 사용자가 많아 "시작했나요?" CS가 잦았다. 크롬 정책상 자동재생은 음소거가 필요하고 새로고침 시 재음소거되므로, 시작 전엔 남은 시간, 시작 후엔 음소거 안내를 노출해 문의를 줄였다.
데이터 스키마 개편: 초기엔 하나의 웨비나 item에 URL·제목·공지·연사·참석자 리스트를 모두 저장했는데, 사용자 1명이 약 200바이트라 1000명이면 400KB 한계를 넘었다. 참석자 테이블을 분리해 웨비나 id와 사용자 세트로 접속·출석 정보까지 보관하게 했다.
성과: 2020년 8월 2주 만에 론칭해 200회 이상 강연을 소화했고, 무료 웨비나 오픈·참석자 일괄 등록 등으로 운영 부담을 지속적으로 줄이고 있다.

왜 읽나소규모 팀이 AWS 관리형 서비스와 서버리스로 라이브 스트리밍 서비스를 빠르게 만들려는 개발자에게 IVS·Sendbird 연동과 DynamoDB 스키마 설계 함정을 보여주는 사례.

마켓컬리 Hello World 블로그

원문은 여기서 이어서 읽을 수 있어요

원문 읽기

읽음 (0)

·takedown 요청