#2 Trading-game-app에 관하여 1편
React-native Future trading game 이야기 1편
현재 가장 많은 시간과 노력을 쏟고 있는 프로젝트이자, 나의 첫 서비스 앱을 소개하려 한다.
아직 정식 출시를 하지 않은 상태이지만, 현재 웹앱 형태로 누구나 직접 접속하여 플레이가 가능한 데모 버전을 배포하였다.
이하 링크에서 이 게임을 플레이해볼 수 있고 스마트폰으로 접속한다는 가정하에 디자인했기 때문에, 스마트폰에서 접속하는 것을 추천한다.
https://devkangminhyeok.github.io/trading-game-app/
이 프로젝트는 무엇인가?
이 프로젝트는 간단히 설명하면, "코인 선물을 경험할 수 있는 게임 앱"이다.
기본적으로, 코인 선물 시장에 존재하는 개념인 공매수/공매도, 레버리지를 차용하여 트레이딩을 경험할 수 있도록 만들어졌다.
이하 데모 이미지를 보면 직관적으로 어떤 게임인지 알 수 있을 것이다.
최대한 직관적으로 유저들이 사용방법을 익히고 게임을 이해하게 하기 위해 UI 구성과 디자인에 대해 많은 고민을 거쳤다. 따로 튜토리얼을 하지 않더라도, 10초 정도 만져보면 게임 플레이를 자연스럽게 할 수 있도록 UI를 구성하려 노력했다.
왜 이 프로젝트를 시작했는가?
먼저 내 이야기를 해야겠다. 이 프로젝트에는 조금 아픈 사연이 있다.
요즘 주식 인구가 5년 전과 비교할 때 정말 늘었다. 사실 지금은 주식 시황이 좋지 않기 때문에, 1-2년 전과 같은 열기는 없지만, 대한민국의 많은 사람들이 주식이나 코인을 경험했다. 폭발적인 인플레이션과 함께 부의 격차가 더 이상 무시할 수 없는 수준으로 치닫으면서 자연스레 발생하는 현상이라 본다.
나 또한 그중 하나로 폭발적으로 상승하는 주식과 코인 시장에 뛰어들었다. 불행히도 나는 끝물에 뛰어들었고, 군 적금을 거의 모두 소진하는 결과를 초래했다. 생각했던 것보다 이 시장은 입문자에게 가혹한 환경이었다.
이 이야기는 조금 뒤에 자세히 다루기로 하고, 나는 그 과정에서 코인 선물에도 발을 들였고 값진 경험을 많이 했다고 생각한다. 그 경험이 없었다면, 이 프로젝트를 시작할 생각도 못했을 것이다.
하지만 제대로 된 교육이나 조사 없이 선물 시장을 경험하다 보니 어려움이 많았다. 기본적인 수수료 체계부터 레버리지의 개념, 롱/숏이 공존하는 세상은 정말 충격적이었다.
이 게임은 부담 없이 코인 선물 시장을 경험하고, 그 위험성을 충분히 인지할 수 있도록 하기 위해서 만들어졌다고 할 수 있다.
진짜?
이제 좀 더 본질적인 맥락을 살펴보자.
내가 정말 처음부터 "코인 선물 시장의 위험성 알리기"라는 대의를 위해서 이 프로젝트를 시작했을까?
솔직히 그렇지는 않다.
처음에는 단순히 지난 프로젝트의 연장선으로, 간단한 trading game을 만드는 것이 목표였다. 이 때는 서비스의 목적과 개발에 있어서의 원칙을 명확히 하지 않았고, 단순히 내가 만든 오픈소스를 활용하고 싶었을 뿐이다.
처음 기획은 Upbit 실시간 시세를 통해 1분봉 차트를 보여주고, 다음 봉이 양봉 일지 음봉 일지 맞추는 아주 간단한 게임을 생각했다. 이 때는 어떻게든 내가 만든 use-upbit-api를 사용해서 프로젝트를 진행하려는 생각이었다.
하지만 내 아이디어를 게임, 주식 두 도메인에 모두 관심 있는 친구들에게 이야기하니 반응이 시큰둥했다. 그다지 재미는 없을 것 같다는 평이었다.
그 이야기를 듣고 다시 생각해보니, 내가 중요한 가치들을 놓치고 있다는 생각을 했다. 그리고 현재 내가 잘못 접근했던 것들을 깨닫고, 이 프로젝트에 임하는 목적과 원칙을 설정했다.
목적
최대한 많은 사용자들이 재밌다고 느낄 수 있는 최초의 트레이딩 게임을 만들자. 게임은 무조건 재미가 있어야 한다. 특히 사람들이 심심풀이로 킬링타임 하기 좋은 가볍고 재밌는 게임을 만들자.
원칙
1. 도구나 기술에 기획을 맞추지 말자. 망치를 든 사람 눈에는 모든 것이 못으로 보이는 법, 이를 경계하라. 기획과 목적에 기술을 맞춰라.
2. 내가 만드는 것이 "게임"이라면, 무조건 "재미"가 최우선 가치여야 한다. 교훈, 학습 등 다른 가치들을 담으려다 "재미"를 놓치는 것은 경계해야 한다.
3. 게임에 있어서는 내가 재밌는 것보다, 유저가 재밌는 것이 중요하다. 단계별로 MVP를 빠르게 만들어 유저 테스트를 진행하는 방식으로 방향을 설정하자.
4. 더 나은 유저 경험을 줄 수 있다면, 구현이 어렵다고 기획에서 타협하는 일은 없어야 한다. 나 자신이 프로라고 생각하고 이 프로젝트에 임한다.
결국 킬링타임용 트레이딩 게임을 만들기 위해 이 프로젝트를 본격적으로 진행하게 되었다고 할 수 있다. 또한 거기에 광고를 붙여 수익을 얻고, 이후 더 큰 프로젝트를 진행하기 위해, 팀원으로 모집할 백엔드 개발자에게 줄 수 있는 돈과 서버 비용을 충당할 수 있는 캐시카우로 성장하면 좋겠다고 생각했다.
어떤 방식으로 진행했는가?
위 원칙들을 설정하고부터는 기획에 있어서 결정이 상대적으로 쉬워졌다. 어떤 결정을 내릴 때, 그 결정이 좋은 결정인지 점검하기 위한 잣대가 생겼기 때문이다. 이때, 명확한 목적과 원칙 설정의 중요성을 제대로 깨닫게 되었다.
하지만 이후 프로젝트를 기획하는 단계에서 내가 가장 크게 느꼈던 것은, 내가 너무도 개발자처럼만 생각한다는 것이었다. 자꾸만 게임의 재미보다는 구현의 난이도나 내가 보유한 스택을 생각해서 기획하게 되고, 게임성보다는 개발 단계에서의 퍼포먼스를 고려하는 습관이 있었다. 이 때문에, 자꾸만 기획을 기술과 타협하여 정하게 되었다.
그리고 결정적으로 나는 진성 헤비 게이머가 아니었다. 그래서 어떻게 하면 게임이 재밌는지 잘 알지 못했다. 이 게임의 기획에는 정말 게임을 사랑하는 사람이 필요했다. 거기에 더불어 주식과 코인이라는 도메인에 관심이 있는 사람이 필요했다.
다행히 그런 사람 하나를 알고 있었다. 대학 동기인 그 친구와 함께, 내 아이디어와 내가 가지고 있는 기술 스택을 설명하며 이야기를 나누었다. 이야기를 나눌수록, 나보다 이 친구가 더 좋은 기획을 만들어줄 것이라 확신했다. 그래서 스프린트 당 1-2시간 정도의 회의 시간을 투자해줄 것을 요구하며, 개발은 내가 혼자 다 할 테니 내 프로젝트의 기획을 도와달라고 말했다. 물론 배포 시 리워드에 대한 이야기도 주고받았다.
나에게는 게임 기획의 방향을 잡아줄 사람이 필요했고, 그 친구는 재밌는 프로젝트가 될 것이라며 흔쾌히 수락했다. 거기에 더불어, 그 친구는 실제 차트를 사용하는 것보다는 시세 변동성과 게임의 난이도 조정 등과 같은 변수를 통제하기 위해서는 게임 내에서 직접 차트 데이터를 생성하는 방식으로 가져가는 것이 게임성에 더 좋을 것이라 말하며, 게임 시스템 자체도 턴제 게임으로 개발하는 것이 사용자에게 부담 없이 다가올 것이라 제안했다.
나는 이 접근이 마음에 들었고, 그렇게 진행하도록 기획을 변경하였다.
기획을 담당하는 팀원과 함께한 선택은 지금 돌아봤을 때, 아주 칭찬할만한 결정이었다. 게임에 대한 지식이나 창의력은 단기간에 만들어지기 어려운 능력이고 이를 팀원과 함께하며 쉽게 해결할 수 있었기 때문이다.
또 가장 좋았던 점은, 기획에 있어 더 이상 나 혼자 결정하지 않다 보니, 더 이상 구현의 난이도나 복잡성에 따라 기획의 범위를 좁히는 "타협"을 하지 않게 되었다는 것이다. 기획자 입장에서는 더 좋은 유저 경험만을 생각하고 구현의 어려움을 개발자만큼 크게 고려하지 않는다. 물론 그 친구도 프로그래머라 어느 정도는 고려해주었지만, 프로그래밍 role을 맡지 않다 보니 본인이 생각하는 좋은 게임에 도달하기 위한 제한 없는 생각들을 가감 없이 이야기해주었다. 사실상 본인이 개발하는 것이 아니기 때문에, 더욱 편하게 이야기할 수 있었을 것이다.
그 기획에는 구현이 어렵거나 귀찮은 부분도 있었지만, 나는 내가 프로라고 생각하고 프로젝트에 임했기 때문에, 기술적으로 가능하고 아예 불가능한 영역이 아니라면 수용했다. 물론 당연하게도 그 친구의 기획이 유저 입장에서 더 재미있는 게임이 될 것이라 생각했기 때문에 "타협"없이 받아들였다.
만약 그 기획이 내가 생각했을 때 유저의 경험을 해친다면, 정중하게 토론을 진행했다. 하지만 의견 충돌이 해소되지 않을 때는 그 친구의 기획을 따랐다. 더 좋은 기획을 만들기 위해 개발자로서 적극적으로 의견을 내면서도, 팀원을 기획자로써 존중해주고 싶었기 때문이다. 그리고 좋은 기획이 떠오르면 내가 먼저 제안하는 일도 많았고, 함께 기획을 논할 수 있는 팀원이 있다는 사실이 매우 든든했다.
거기에 그 친구는 이 프로젝트에 많은 시간을 투자하지 않기 때문에, 나보다 프로젝트에 대한 애정이 덜했고, 그 덕에 더욱 객관적인 유저의 시선으로(사실상 기획자보다는 게이머의 시선으로) 게임을 바라봐줘서 더 고마웠다.
이 과정에서 현재 구현된 대부분의 기획들이 실제로 논의가 이루어지고 결정되었다.
빠르게 실행 후 테스트 하기
개발에 진입하면서, 이전에 세웠던 원칙을 고수하려 노력했다.
게임에 있어서는 내가 재밌는 것보다, 유저가 재밌는 것이 중요하다. 단계별로 MVP를 빠르게 만들어 유저 테스트를 진행하는 방식으로 방향을 설정하자.
만약 내가 아무리 기술이 뛰어나고 "기술적으로" 좋은 제품을 만든다고 해도, 그 제품이 사용자가 원하는 제품이 아니거나, 필요 없는 제품이면 "쓸모가 없다".
특히 게임은 본연의 목적인 "재미"를 담고 있지 않으면, 아무리 열심히 만들어도 소용이 없다.
그래서 나는 개발 속도는 최대한 빠르게 하여, 실제 유저들에게 테스트를 진행시키며 이 아이디어를 검증했다. 이때 개발 단계에서는 기술 부채가 생기기도 했지만, 비즈니스 로직과 목적에 충실히 이 제품을 성장시키고 싶어, 개발에 있어서는 최대한 빠르게 만드는 것을 최우선 목표로 했다.
먼저 디자인은 배제하고 필수적인 기능을 빠르게 구현했다.
1. 차트
2. 주문
3. 보유현황
이 3개의 기능을 최대한 단순하게 구현했다. 차트는 실시간 시세를 타루기 좋은 TradingView의 Lightweight-chart 라이브러리를 사용하여 빠르게 구현하고, 주문은 롱/숏 모두를 구현하지 않고 일단은 롱 주문만 구현했다. 거기에 보유현황은 단순히 현재 평가자산만 보여주는 방식으로 개발했다.
이때는 App이 아닌 Web으로 제작했고, 대상은 PC 유저였다.
이 모두를 개발하는데 2일 정도면 충분했고, 개발이 완료되고 나서는 주변 친구들에게 게임을 플레이해볼 것을 요청했다. 만약 이 단계에서 좋은 호응을 얻는다면, 우리가 기획한 방식으로 그대로 밀고 나갈 수 있었다. 놀랍게도 5명 정도의 친구들에게 테스트를 시켜보면서, 좋은 반응을 얻을 수 있었다. 한 명은 링크를 받은 그 즉시부터 1시간 동안 계속 게임을 플레이하는 모습을 보여주었다.
아직 제대로 구현과 디자인도 안된 게임을 1시간 이상 플레이하는 사람이 존재한다면, 이 게임은 충분히 경쟁력이 있을 것이라는 확신을 가지고 다음 스텝을 진행했다.
이후 단계에서는 롱/숏 주문 모두 구현 후 차트도 더 보기 편하게 여러 정보들을 넣어주고, 청산가와 평단가 정보도 차트에 표시되도록 기능을 추가했다. 보유 현황도 미실현 손익과 수익률을 추가하여 실제 얼마나 수익을 내고 있는지 등에 대한 정보도 함께 표시되도록 만들었다. 하지만 이 단계까지도 디자인 작업은 진행하지 않았다. 아직 더 유연한 상태를 유지하고 싶었고, 변경에 의한 cost를 최소화하고 싶었기 때문이다.
핵심 기능이 모두 제대로 구현되는 데에는 5일 남짓이 걸렸다. 그리고 다시 유저들에게 피드백을 받았다. 여전히 꽤 재밌는 게임이라는 평을 받았고, 누군가는 매크로를 활용해서 새로운 공략도 만들기도 했다. 하지만 공통적인 답변 중 하나는 "굳이 컴퓨터를 붙잡고 할 만한 게임은 아니다"였다. 더 재미있는 게임들이 많은데, 굳이 이 게임을 모니터 앞에서 까지 할 이유는 잘 모르겠다는 의미였다.
이 문제를 가지고 팀원과 토의를 했고, 고민하던 도중, 나는 이 게임을 앱 서비스로 전환하자는 제안을 했다. 제대로 된 앱을 만들어 출시해본 적도 없고 경험도 미약하지만, 유저에게 더 와닿는 방식이 "앱"이라면, 그렇게 해야 한다고 생각했다.
그리고 React-native를 활용하면 기존 코드를 많이 재활용할 수 있기 때문에, 앱으로 전환 시의 cost나 개발 기간도 효율적일 것이라 생각했다. 특히 차라리 진행도가 높지 않은 지금이 오히려 앱으로 전환할 적기라 판단했다. 더 늦어지면, 더 많은 기회비용을 날려야 한다고 판단했기 때문이다.
결과적으로 이 결정은 유저 경험에 훨씬 더 긍정적인 영향을 줄 수 있었고, 이는 유저를 최우선 가치로 생각하지 않았다면 불가능한 결정이었을 것이라 생각한다. 또 빠르게 개발하고 테스트하는 방식을 차용해서 기회비용을 최소한으로 소비할 수 있었다고 생각한다.
이 프로젝트에 대해 하고 싶은 이야기가 많이 남았지만, 너무 글이 길어져 2편에서 계속하려 한다.
