서버 비용 0원, 300만 조회수 게임 만들기 : 집단지성 오목 게임 Kibitz bugs

2024년 2월 27일부 트위치가 한국 시장을 철수한 기념으로,
Kibitz bugs 프로젝트를 돌아보며 회고 글을 써보고자 합니다.

Kibitz bugs

https://kibitz-bugs.xyz

Kibitz bugs는 스트리밍 플랫폼 트위치의 댓글 API를 활용하여 스트리머와 시청자 집단지성 간 오목 대결을 펼치는 게임입니다.
방송을 진행하는 스트리머는 일반적인 오목 게임을 하듯 수를 두고, 시청자 모두가 댓글로 좌표를 입력해 집단지성으로 좌표를 '선택'합니다.

침착맨, 우왁굳, 우주하마, 풍월량, 우정잉 등 유명 트위치 스트리머를 포함한 약 4,300명 이상의 트위치 스트리머가 약 6,300회 이상의 오목 게임을 플레이했고,

한 방송에서는 19,000명이 동시에 접속해도 안정적으로 게임을 플레이했습니다.

방송 영상은 각 스트리머의 유튜브 채널에도 업로드되어 총합 300만 명에 가까운 조회수 또한 기록했습니다.

🔗YouTube 재생목록 링크(195개의 영상)

기획부터 개발까지

'쓸만한' 프로젝트 만들기

프로젝트는 백엔드 친구 한 명과 저, 이렇게 두 명이 진행했습니다. 프로젝트를 기획하며 가장 중요하게 생각한 목표는 '누군가 사용할 프로젝트를 만들자' 였습니다. 아무리 사이드 프로젝트의 목적이 다양하다고 해도, 사용자가 없다는 전제로 시작한다면 개발하는 과정이 매우 길고 지루할 것입니다. 반대로 기껏 만들었는데 아무도 사용하지 않는다면 그동안 들인 시간과 정성이 너무 아깝겠지요.

사이드 프로젝트를 이미 경험해 보신 분들께서는 잘 아시겠지만, 내가 만든 프로젝트를 누군가 한 명이라도 사용한다는 것은 매우 설레고 특별한 경험입니다. 아무 금전적 이익이 없더라도 누군가 내가 기획하고 개발한 서비스를 사용한다는 것 자체가 행복한 일이지요.

그런 의미에서 스트리머의 컨텐츠 전용 게임개발은 처음부터 전략적이었습니다.

수요와 공급의 기본적인 원리를 이용해 펜을 판매하는, 영화 <울프 오브 월스트리트>에서의 인상깊은 장면이 있는데요,
당연하게 프로젝트도 마찬가지로 필요에 의한 개발로 탄생한 제품은 누군가 사용할 수 밖에 없다고 생각했습니다. 물론 기존에 없는 서비스이거나, 기존에 있었어도 기존 제품보다 훨씬 좋아야 하는 것은 당연합니다.
(비상한 아이디어가 아니더라도 더 나은 사용자 경험이나, 디자인으로도 가능하다고 생각하긴 합니다)

그런 의미에서 Kibitz bugs는 스트리머, 시청자 모두에게 필요한 서비스였습니다.
스트리머는 콘텐츠가 필요합니다. 하루하루 어떤 콘텐츠로 방송할지 고민을 하는 분들이기 때문입니다. 재밌어보이는 콘텐츠가 있다면 당연히 사용하는 스트리머가 있을 것이라고 생각했습니다.

시청자는 스트리머와 소통을 원합니다. 기존 오목 게임으로 시청자와 스트리머가 오목 게임을 하는 것을 유튜브에서 몇 번 본적이 있는데요, 길어야 두세 시간 하는 방송 중 많아 봤자 기껏 해야 몇 명이 참여할 수 있을까요?

여기서 Kibitz bugs의 아이디어를 얻었는데요, 채팅에 참여한 시청자 모두가 한 번에 게임에 참여한다면 어떤 일이 일어날까? 라는 생각이었습니다. 간단한 좌표를 입력해서 지루하지 않게 한 판을 끝내기에도 매우 적절했고요. 시청자 참여 콘텐츠라는 특성상 시청자에 의해 자연스럽게 홍보되고, 자연스럽게 많은 사용자를 모을 수 있었습니다.

• 스트리머, 시청자 모두의 니즈에 맞았다.
• 모두가 룰을 알고 있고, 잠깐 재밌게 할 게임으로 오목이 매우 적절했다.
• 투표로 좌표를 정하는 방식도 오목판이라는 공간이 너무 딱 맞았다.

또한 스트리밍된 영상은 트위치에서만 그치지 않습니다. 그 분야 전문가들에 의해 유튜브에도 재밌게 편집되어 올라가 프로젝트가 널리 널리 퍼질 수 있었습니다. 덕분의 프로젝트의 인지도 측면에서도 유리했습니다.

서버 비용 0원으로 게임 만들기

사이드프로젝트에서 어쩌면 개발보다 더 중요한 부분은 현실적으로 발생하는 비용에 관한 문제입니다. 사용자가 많을수록, 또는 AI처럼 서버가 하는 일이 많아질수록 비용이 만만치 않기 때문입니다.

트위치의 유명 스트리머 몇 명만 동시에 방송해도 수만 명의 동시 시청자가 들어오고, 최악의 상황을 가정하면 1초에 수만 명의 투표를 집계해야 하는 문제가 있었습니다. 과연 백수 두 명의 얇은 지갑으로, 어떻게 트래픽을 감당할 수 있었을까요?

물론 이 문제는 아이디어가 처음 떠올랐을 때 부터 예상한 문제였는데요, Kibitz bugs의 모든 게임 로직은 전부 클라이언트 브라우저에서 처리됩니다.

게임에 접속한 스트리머의 브라우저에서 트위치의 채팅 API로 받아온 채팅 메시지들을 정제하고, 좌표를 종합합니다. 종합된 좌표별 득표수는 부드러운 애니메이션을 위해 0.5초에 한번 쓰로틀링되어 브라우저 화면에 표시됩니다.

제일 많이 득표된 좌표에 마치 마우스를 올린 것 처럼 표시해 실제로 모니터 너머에 하나 지성을 가진 사람이 있는 것 같은 모습을 보여줍니다.
게임을 플레이하는 스트리머로부터 '시청자들이 마치 알파고가 계산하듯이 오목을 둔다' 라는 말을 정말 많이 들었는데요, 정확히 의도된 인상이었습니다.

게임의 주요 로직을 담당하는 코드들(특히 오목의 승패, 금수 판정 알고리즘) 또한 스트리머의 브라우저에서 전부 돌아갈 수 있도록 자바스크립트로 작성되었습니다.
서버의 비용을 줄이는 것과 동시에 스트리머 특성상 매우 좋은 PC로 게임을 플레이할 것을 가정할 때 성능면에서 부족함이 없을 것이라고 생각했기 때문입니다. 시청자 수가 많을수록 더더욱 좋은 사양의 컴퓨터로 게임을 할테니 계산상 게임 플레이에 성능상 문제가 발생할 일은 없었습니다.

서버 부담을 줄이는 데에는 이미지와 빌드 용량 최적화도 한몫 했습니다. 0.1.0-alpha버전에서 유저가 처음 접속하면 약 11.4MB의 리소스를 다운로드했는데요, 최적화 이후 1/10수준인 1.3MB로 줄였습니다.

반년동안 수십만 명의 시청자 투표를 감당한 서버는 AWS의 Free Tier, 서버 비용은 0원입니다. 게임을 운영하며 서버 비용이 전혀 들지 않았어요. 때문에 지저분한 광고를 게임 좌우에 붙이는 일도 없었고, 사용자들은 더 쾌적한 환경에서 게임을 즐길 수 있었습니다.

배포!

애초에 짧은 기간 집중해서 개발하려고 했던 프로젝트이기 때문에 기본적인 Twitch OAuth 인증과 댓글 수집, 오목 알고리즘과 주요 게임 엔진 개발이 완료되자마자 일단 빠르게 배포를 했습니다.

배포를 한 이후 트위치 시청자의 활동이 매우 활발한 침착맨 커뮤니티(침하하)에 글을 작성해 홍보했고, 좋은 반응으로 단숨에 베스트 게시물에 오르면서 세상에 알려지게 되었습니다.
특히 스트리머 방송에 참여하는 형식의 게임이다보니 시청자분들의 적극적인 홍보와 추천이 큰 힘이 되었습니다.

전혀 예상하지 못했던 것은, 배포가 된 바로 다음날 새벽, 우왁굳님이 방송에서 게임을 했다는 점입니다. 아깝게도 잠을 자느라 생방송을 시청하지 못했는데요, 아침에 일어나 보니 우왁굳 팬카페가 오목 관련 글로 뜨거웠습니다. 그 다음날 한번 더 연속으로 게임을 플레이한 덕분에 아직 정식 버전이 개발되기도 전에 게임의 접속자 수가 폭증했습니다.

예상치 못한 새벽 방송에서 약 17,000명의 동시 시청자가 플레이하며 게임의 안정성을 검증했습니다. 게임 방송을 전문으로 하는 스트리머의 피드백도 매우 긍정적이었는데요, 딜레이가 매우 적고 댓글 반영이 매우 빠릿빠릿하다, 게임을 잘 만들었다는 긍정적인 코멘트를 받았습니다.

👉우왁굳 1차 방송 유튜브
👉우왁굳 2차 방송 유튜브

구독자 약 180만 게임 전문 유튜버이자 트위치 스트리머인 우주하마님의 팬카페에도 한 번 홍보 게시글을 작성했습니다. 정말 재밌는 방송이었는데요,

특히 선(흑돌)은 육목을 하지 못하는 점을 기회로 살려 승리하는 재미있는 상황도 연출되었는데요, 렌주룰이 완벽히 적용된 오목 룰 판정 알고리즘, 그리고 우주하마님의 높은 오목에 대한 이해도가 돋보이는 장면이었습니다.

해당 영상은 유튜브 업로드 이후 뜨거운 반응으로 인기 급상승 동영상에도 올랐고, 오늘 기준 약 110만 조회수를 달성했습니다.

👉우주하마 방송 유튜브

모니터링과 피드백

스트리머가 Twitch 계정으로 로그인할 때 Telegram bot을 이용해 방송 알림을 받을 수 있도록 모니터링 시스템을 구축했습니다. Telegram bot을 통해 방송 알림이 오면, 웬만하면 거의 모든 방송을 다 챙겨봤습니다.
실시간 스트리밍으로 방송되는 게임이다 보니 스트리머와 시청자의 생생한 피드백도 얻을 수 있었습니다. 게임 기능에 대한 피드백부터 테마 변경, 다른 게임의 추가 개발 등 부가적인 피드백도 받았습니다.

또한 사용자 수 수집을 위해 Google Analytics도 사용했습니다. 아쉬운 점은 첫 배포 당시에 GA 없이 배포해서 가장 사용자가 많았던 배포 이후 약 3주 동안의 데이터가 없다는 점입니다.

프로젝트 배포 전 GA는 필수입니다.

스트리머 한 명만 접속해 플레이하는 게임 특성상 실제 사용자보다 GA에 기록되는 사용자는 매우 적지만, 사용자 추세 정도는 파악할 수 있었습니다.
특히 주목한 점은 재사용자인데요, 게임 스트리머의 방송 특성상 메인 콘텐츠로 게임을 하면 보통 다시 접속하지 않을 것으로 생각했지만 오히려 자주 방문해 주시는 스트리머분들이 꽤 많았습니다. GA에서도 확인할 수 있듯이 재방문율이 예상보다 높았습니다.

후회하며 배우기

배포 전 기본은 지켰어야 했다.

핵심적인 게임 기능만 테스트하고 배포를 했기 때문에 첫 배포에서 빠져버린 중요한 기능들이 많았습니다.
게임 플레이에 문제가 될 정도의 문제도 있었는데요, 제한시간 초읽기나 경고가 적극적이지 않아서 시간초과로 싱겁게 게임이 끝나버린다거나, OAuth 인증 과정을 프론트에서 전부 처리해 브라우저 창을 새로고침하면 토큰이 날아가 로그아웃이 되는 등의 문제가 있었습니다.
기본적인 기능이 제대로 개발이 되지 않은 상태에서 너무 많은 사용자가 방문해 곤란해져버린 흔치 않은 경험이었습니다.

물론 이후 업데이트를 통해서 백엔드에서의 Authorization Code Grant로 OAuth 표준 인증 절차를 진행하고, JWT로 발급된 Refresh Token과 Access Token을 이용해 보안 측면에서 안전한 로그인 유지 기능을 구현했습니다.

GA를 적용하지 않아 처음부터 제대로 된 이용자 수 모니터링을 하지 못했고, 트위치 게임 카테고리에 게임 등록도 되지 않아 많은 시청자가 시청할 때 트위치 메인 화면에 게임이 노출될 기회도 여러번 놓쳤습니다.

최대한 많은 데이터를 모았어야 했다.

첫 배포 버전부터 게임 플레이 데이터를 일부 백엔드에 전송하긴 했습니다. 하지만 언제 어떻게 게임 플레이 데이터가 쓰일지 모른다는 점에서 최대한 많은 정보를 DB에 저장을 해뒀어야 했다는 아쉬움이 있습니다.(개인정보와 관련된 민감한 정보를 제외하고)

특히 현재 시청자 수가 몇 명인지, 한 게임에서 실제 채팅으로 참여하는 시청자의 수 또는 비율은 얼마나 되는지, 투표의 의견이 어떤 상황에서 얼마나 많이 갈리는지 등...
재밌게 활용될 수 있는 통계 데이터를 하나도 저장하지 않은 것을 후회하고 있습니다.

처음부터 데이터 수집에 잘 신경 썼다면 <참여형 오목 게임을 통해 알아본 집단 지성 심리 연구> 같은 논문이라도 한 편 쓸 수 있지 않았을까요? 데이터 수집과 분석의 중요성을 느꼈습니다.

나중에도 볼 수 있는 코드를 작성했어야 했다.

이건 매우 부끄러운 고해성사인데요,
짧은 프로젝트 기간, 친구인 백엔드 개발자 한 명과 저 두 명이 개발을 하다보니 큰 실수를 했습니다. 프론트엔드 개발을 혼자 진행한다는 점에서 유지보수를 고려하지 않은 코드들을 작성했기 때문입니다.

물론 덕분에 빠른 개발이 가능했다는 장점도 있긴 했습니다. 또 어차피 프론트엔드 개발을 혼자 진행했기 때문에 저만 알아볼 수 있는 코드를 작성하면 문제가 되지 않을 것이라고 생각했고요. 하지만 매우 큰 오산이었습니다. 프로젝트가 끝나고 단 몇 주가 지났는데도 제가 제 코드를 알아보기 힘들었습니다. 덕분에 리팩토링과 추가 기능 개발에서 크게 애를 먹었습니다.

특히 비즈니스 로직의 모듈화(Hook과 Util Function 등)와 구조 설계의 중요성을 느꼈습니다. 로직의 분리 없이 화면과 관련된(View) 코드와 여기저기 엉켜있다 보니 하나의 정교한 톱니바퀴 같은 코드가 되어버렸습니다. 추가 개발을 하려고 한 줄만 코드를 건드려도 모래성처럼 와르르 무너져 버릴 것 같았습니다.

단일 책임 원칙과도 결이 닿는 이야기일텐데요, 개인적으로 모든 상황에서 하나의 함수가 한 가지 동작만을 해야한다고 생각하지는 않습니다. 하지만 나중을 고려한 개발은 반드시 필요하다는 것을 느꼈습니다. 특히 추가 개발이 수시로 발생하거나, 공동 작업이 활발하게 진행되는 프로젝트라면 더욱 말이죠.

앞으로의 계획과 목표

지금도 사이드 프로젝트를 하나 하고 있는데, 이번엔 크기가 좀 커서 장기간 기획과 디자인을 하는 중입니다. 게임과 관련된 건 아닙니다.

물론 게임 관련된 아이디어도 몇 개 있습니다. 기획하다가 포기한 아이디어도 여러 개 되고요. 프로젝트를 여러 개 병행할 수 없다 보니 시간이 없어서 못한다는 핑계를 대는 중입니다.

장기적인 목표라고 한다면,
기획자, 디자이너와 말이 잘 통하는 개발자가 되는 것이 목표입니다.

개인적으로 프론트엔드 개발의 가장 큰 매력은 사용자와 아주 가깝다는 점인데요, 사용자와 가깝기 위해서는 그 어떤 분야의 개발자보다 기획과 디자인을 잘 알아야 한다고 생각합니다.
조금 오바하면 지금 당장 이직을 해도 기획자 또는 디자이너 일을 할 수 있을 정도로요. 물론 직업은 개발자이다보니 이런 분야에 전문적이진 않겠지만, 그만큼 많이 알고 관심을 가져야 한다는 뜻입니다.

그런 의미에서 사이드 프로젝트는 매우 필요합니다!

회사 일은 내 맘대로 못하지만, 내가 기획하고 내가 디자인한 사이드 프로젝트는 내 맘대로 할 수 있거든요! 사소한 것 하나에 디테일한 고민을 하는 경험을 매일매일 할 수 있습니다.

---

정민우
minu.j.dev@gmail.com
@minu-j