게임으로 사이드 프로젝트를 한다는 것

지금까지 여러 사이드 프로젝트를 해 왔지만, 그중 게임을 주제로 실제 서비스까지 간 프로젝트가 어느새 3개가 되었습니다. 제 개발 커리어와 함께한 프로젝트도 하나 있고, 상당히 높은 비중을 차지하고 있습니다.
게임을 선택한 이유는 단순히 게임을 많이 즐기기 때문이었습니다. 사이드 프로젝트의 특성상 많이 접하는 활동에서 아이디어를 얻는 게 자연스러웠고, 애정을 가지고 프로젝트를 지속하기도 편했습니다. 그리고 실제로 프로젝트를 진행해 본 입장에서, 게임은 사이드 프로젝트를 하기 좋은 아이템이라고 생각합니다. 진행했던 프로젝트별로 “이 게임은 시스템이 ~해서 ~한 앱을 만들었다” 설명하는 것은 의미 없을 것 같고, 포괄적인 내용만 가볍게 적어 보려고 합니다.

개인의 주관이 많이 들어갈 예정입니다.

게임으로 사이드 프로젝트를 하기 좋은 이유

• 게임을 좋아한다면, 친근하고 프로젝트에 애정을 붙이기 좋습니다.
• 게임에서 정해 놓은 최소한의 규칙이 있습니다. 저는 사이드 프로젝트의 큰 장벽 중 하나가 막연함이라고 생각하기 때문에, 이것은 상당히 큰 장점이라고 보고 있습니다.
• 게임에 따라 양질의 API나 원본 데이터를 제공받을 수도 있습니다.
• 주제가 게임인 이상 부담이 적고, 특히 대한민국은 게임을 상당히 많이 즐기기 때문에 사용자를 찾아 피드백을 받기도 용이합니다.
• 게임 업데이트에 맞추어 프로젝트도 업데이트해야 하기 때문에 기본적인 유지관리 프로세스를 배울 수 있습니다.

무엇이 필요한가?

물론 약간 벗어나는 케이스도 있지만, 일반적으로 서비스를 구성하기 위해서는 데이터와 화면이 필요합니다. 게임도 마찬가지입니다. 게임 데이터와 그에 맞는 화면을 구성하면 됩니다.
화면은 저는 대부분 웹으로 구성했습니다. 앱보다 배포가 자유롭고 업데이트가 편해서 선택했는데 앱을 선택해도 무방합니다. 데이터는 백엔드 서버를 구성할 수 있다면 가장 좋겠지만 필수는 아닙니다. 저도 지금 2개의 서비스는 서버를 두지 않고 따로 Python으로 처리한 JSON 파일을 통으로 넣어서 사용하고 있습니다.

데이터 제공 방식은 선택◦취향의 문제이고 공통적인 문제는 원본 데이터를 얻는 방법입니다. 이 부분은 크게 3가지로 나눌 수 있을 것 같습니다.

1. 게임 회사에서 직접 제공해 주는 데이터를 활용합니다.
   가장 개발도 편하고, 정확성도 보장되고, 사후 문제도 걱정할 필요 없는 최선의 방법입니다. 보통 이 경우 게임사가 API 형태로 데이터를 제공합니다. 라이엇이나 블리자드 등 큰 회사에서 데이터를 제공해 주는 것으로 유명하고, 한국에서도 로스트아크를 비롯한 몇몇 게임이 데이터를 제공하고 있습니다.
   물론, 원본 데이터를 그대로 쓰는 경우는 많지 않고 서비스에 맞는 재가공은 필요합니다. 그리고 가끔씩 정보를 제공하긴 하는데 원하는 정보를 뽑아내는 과정이 번거로운 경우도 있으니, 잘 견적을 내 보는 것이 좋습니다.

로스트아크 API를 제대로 사용하려면 HTML 속에서 데이터를 잘 솎아야 합니다

2. 제삼자가 제공하는 비공식 데이터를 활용합니다.
   보통 회사가 데이터를 제공하지는 않는데, 게임의 규모가 크면 이런 경우가 많습니다. 비공식이고, 보통은 앱이나 클라이언트를 뜯어서 데이터를 수집하는 경우가 많아 리스크가 존재합니다. 불안정성도 조금 높습니다.
3. 직접 맨땅에서 작업합니다. 정말 아무것도 없고, 본인 게임에 대한 애정도가 높다면 최후의 수단입니다. 처음부터 끝까지 전부 스스로 하시면 됩니다(…)

참고로 저는 이 3가지 케이스를 모두 경험해 보았습니다…

대략적인 과정

• 아이디어를 구합니다. 직접 게임을 하면서 아이디어를 생각할 수도 있고, 다른 유저들이 “이런 게 불편한데 누가 해결 좀 안 해주나” 하는 것에서 모티브를 얻어도 됩니다.
• 원본 데이터를 구합니다. 큰 흐름은 위에서 설명해 두었습니다.
• 화면을 어떻게 구성할지, 데이터는 어떻게 화면에 표시할지 등 대략적인 기획을 합니다.
  여기서 모든 세부 사항을 빡빡하게 기획할 필요는 없습니다. 어차피 다른 사람에게 보고할 것도 아니고, 개발 과정에서 정했던 게 바뀌는 경우도 많습니다.
• 실제 개발을 진행합니다.
• (선택) 만든 서비스를 실제로 누구나 사용할 수 있도록 배포합니다.
• (선택) 사용자에게 피드백을 얻으며 유지보수와 개선 작업도 해 봅니다.
• (선택) 게임이 업데이트되면, 프로젝트도 맞추어 업데이트하고 변경사항도 배포합니다.

단순히 공부가 목적이고 결과물을 남에게 보여 주고 싶지 않다면 선택이라고 쓰여 있는 부분은 생략해도 됩니다. 하지만 개인적으로 저 과정에서도 많은 도움을 얻었기 때문에, 가능하다면 모든 과정을 경험해 보는 것을 추천합니다.

프로젝트를 하는 마음가짐

• 보통 프로젝트 출시 이후 추가 작업은 2가지 부류로 나뉘는데, 크게 오류◦장애, 또는 개선사항◦업데이트 정도로 나눌 수 있습니다. 이 중 본인의 실수로 인한 오류는 반드시 해결하는 것이 좋습니다. 실력적으로도 도움이 되고, 꼭 IT가 아니어도 내 잘못을 고치는 것은 기본 소양입니다.
• 다만 사이드 프로젝트 특성상 개인 환경에서 고치기 힘든 오류가 있을 수 있습니다.
  이 경우 깔끔하게 인정하고 “이건 ~해서 고치기 힘들 것 같다” 말을 해도 됩니다. 어쩔 수 없습니다. 예를 들어 저는 사이트에 넣은 이미지 다운로드 기능이 iOS에서 작동하지 않는 문제가 있었는데, 제가 iOS 기기가 하나도 없어서 이걸 테스트하고 고칠 수 없었습니다. 결국 최근에 맥북을 사서 고치기는 했는데, 그전에는 다운로드가 안 되면 스크린 캡처 기능을 이용해 달라고 고지했었습니다.
• 개선사항◦업데이트는 고려할 게 많습니다.
  어지간하면 받아서 구현해 보는 것이 좋기는 합니다. 사용자가 내가 생각했던 것과 다른 의견을 냈는데 그게 맞을 수도 있고, 실제로 프로젝트 발전에 큰 도움이 되는 경우도 있습니다. 실력을 늘리기도 괜찮습니다. 하지만 사이드 프로젝트의 대전제는 내가 만족하는 것이라고 생각합니다. 어떤 서비스도 모두를 만족시킬 수는 없습니다. 그렇다면, 적어도 만족하는 사람에 나는 포함되어야 합니다. 개선사항을 받는 것은 좋은데, 이것이 과도해지면 “이건 내 생각과 너무 다르다”, “너무 억지 요구사항이다”라는 생각이 들 때가 있습니다. 사이드 프로젝트가 돈 받고 고객한테 다 맞춰야 하는 성격의 작업도 아니고, 다 받아 주다 보면 프로젝트가 산으로 가고 오래 지속할 수 없습니다. 이 때는 어느 정도 요구사항을 자르는 것도 좋은 방법입니다.
• 처음부터 “내 서비스를 메이저◦간판으로 만들겠다” 이런 생각은 하지 않는 것이 좋습니다. 물론 진짜 내가 만든 서비스가 매우 유용해서, 사용자가 꽤나 많아지는 경우도 있습니다. 그러면 그때 가서 생각해도 충분합니다.
  특히 규모가 큰 게임이라면 기대치를 더 줄이는 게 좋은데, 게임이 큰 만큼 관련 서비스를 만들려는 사람도 많기 때문에 나보다 실력이 좋거나, 더 빠르게 서비스를 선점했거나, 심지어 팀 단위로 움직이며 서비스를 개발하는 경우도 많습니다. 물론 이 쪽도 같이 전략적으로 움직인다면 모르겠습니다만 개인 프로젝트라면 본인의 실력 상승 + 경험이 우선이기 때문에 주객전도는 피하는 것이 좋습니다.
• 가장 중요한 점 중 하나는 스트레스, 부담을 가지지 않는 것이라고 생각합니다. 막말로 사이드 프로젝트 하라고 누가 칼 들고 협박하지는 않습니다. 그리고 내가 좋아서, 편안한 마음으로 해야 진도도 잘 나가고 프로젝트 유지도 잘 됩니다. 진짜 말도 안 되는 요구사항은 쳐내도 되고, 내가 노력으로 해결할 수 없는 것은 솔직하게 말해도 되고, 사용자가 적어도 상관없습니다. 편하게 사이드 프로젝트를 하셨으면 좋겠습니다.