On this page
낮엔 직장인 밤엔 인디 게임 개발자
개발 초기 6개월간 퇴근 후의 시간과 주말을 쪼개어 개발해 온 사이드 프로젝트, 화투 카드로 족보를 맞추는 로그라이크 덱빌딩 게임 블로샤퍼: 꽃들의전쟁(Blosharper: Battle of Blossoms)이 마침내 스팀(Steam) 상점 등록을 거쳐 출시 예정작 상위권에 노출되기 시작했습니다. 이후 얼리 액세스를 거쳐 2026년 10월 8일 정식 출시했습니다.
퇴근 후 시간을 활용하기 위해 코딩, 이미지 생성, 배포 작업을 전문 분야가 다른 AI 에이전트들과 나눠 진행했습니다. 제가 '에이전틱 AI 패밀리'라고 부르는 구성입니다.
익숙한 웹 기술로 시작하기
프론트엔드 개발자인 저에게는 웹 기술이 익숙했습니다. 새로운 게임 엔진을 배우는 데 쓸 시간도 고려해야 했기 때문에, 브라우저 런타임을 기반으로 돌아가는 웹 게임 아키텍처를 선택했습니다.
- Core Logic: Vanilla JS/TS를 사용한 상태 관리 및 화투 족보 판정 로직 구축
- Styling: Vanilla CSS를 활용한 고해상도 그래픽 필터링 및 하드웨어 가속 최적화
- Desktop App: Electron을 활용한 네이티브 윈도우 패키징 및 스팀 API(Steamworks SDK) 연동
코드를 수정하고 바로 화면에서 결과를 볼 수 있다는 점이 퇴근 후 2~3시간을 활용하는 데 도움이 됐습니다.
퇴근 후의 시간을 함께 쓰는 방법
익숙한 기술을 택해도 혼자 해야 할 일이 줄어드는 것은 아니었습니다. 코드와 그래픽, 인프라를 함께 진행하기 위해 에이전트마다 역할과 페르소나를 나눴습니다.
- 개발 파트너(지니): 코드베이스 전반의 아키텍처 설계와 비즈니스 로직, UI 레이아웃 구현을 총괄하며 피드백을 주고받는 핵심 파트너.
- 인프라·배포 관리 에이전트(루나): M1 Mac Mini를 기반으로 빌드 파이프라인, RTMP 실시간 송출 서버 운영, 모니터링 등 인프라 전반을 담당.
- GPU 연산·이미지 생성 담당(노바): 고사양 GPU 서버를 바탕으로 ComfyUI 기반의 그래픽 애셋 및 일러스트레이션을 신속하게 뽑아주는 그래픽 지원군.
- 리서치·문서 조사 담당(제제): 화투 족보 규칙, 스팀 오버레이 가이드, 외부 API 연동 등 리서치가 필요할 때 집중 투입되어 문서를 정밀 조사해 주는 연구원.
작업을 나누니 여러 영역을 동시에 진행할 수 있었습니다. 코드를 바꿀 때는 먼저 에이전트가 기존 구조와 설계 패턴을 확인하고 리팩토링 안을 제안하게 했습니다. 그 내용을 보고 어디를 어떻게 고칠지 논의했습니다. 이렇게 작업하는 데 익숙해질 무렵, 게임 바깥의 일에서도 도움이 필요해졌습니다.
개발보다 낯설었던 스팀 등록
게임은 어떻게든 만들겠는데, 스팀에는 어떻게 등록하는 걸까요. 행정부터 막혔습니다. 개발 화면 밖으로 나오니 어디서부터 손을 대야 할지 모르겠더군요.
에이전트에게 등록 절차와 다른 개발자들의 사례를 찾아 가이드를 만들어 달라고 했습니다. 실제 화면을 마주하면 또 헷갈렸습니다. 화면을 하나씩 캡처해서 보내고, 이렇게 진행하는 것이 맞는지 물어보고, 잘못 이해한 부분을 고쳤습니다.
정보 몇 가지를 입력하면 끝날 줄 알았는데, 상점 이미지와 소개글, 트레일러까지 준비할 것이 계속 나왔습니다. 개발하는 것만큼이나 할 일이 많았습니다. 이것도 에이전트들과 나눠 진행했습니다.
특히 행정 업무에서는 설명만 해 주는 데서 그치지 않고 직접 폼을 작성해 주기도 했습니다. 혼자 항목의 의미부터 찾아봤다면 몇 시간은 썼을 일을 5분 정도에 처리한 적도 있습니다. 무엇을 해야 하는지 알고, 실제 처리까지 빠르게 해 주니 처음 해 보는 일의 부담이 크게 줄었습니다.
그런데 최종 제출 직전에는 멈추더군요. 마지막은 본인이 직접 하라고 했습니다. 다 해 놓고 마지막 버튼은 제 몫으로 남겨 주는 게 조금 웃겼습니다.
처음 해 보는 일인데도 경험이 있는 동료와 함께 진행하는 느낌이었습니다. 새로운 일을 시작한다고 해서, 그 일에 필요한 모든 지식을 혼자 처음부터 익혀야 하는 것은 아니라는 걸 실감했습니다.
상점 등록을 마친 뒤에도 할 일이 남았습니다. 스팀 상점 라이브 스트리밍 중 모바일 기기에서 화면이 검게 나오는 문제가 생겼습니다. 인프라 담당 에이전트(루나)와 모바일 디코더 제약을 확인하고, 송출 설정을 720p 30fps로 바꾼 뒤 프로세스를 원격으로 재시작했습니다. 게임을 만드는 일과 플레이어에게 제대로 보여 주는 일을 함께 챙겨야 했습니다.
이렇게 하나씩 준비해 스팀 등록을 마쳤고, 상점 페이지와 게임 빌드 모두 첫 심사에 통과했습니다. 블로샤퍼는 6월 24일 스팀에 얼리 액세스로 출시했습니다. 이후 게임을 다듬어 2026년 10월 8일 정식 출시했습니다.
출시 이후에도 계속된 개발
출시를 마치고 나니 거의 완성했다고 생각한 게임에서 다시 코어를 손볼 일이 생겼습니다. 지원 언어와 기기가 늘어난 만큼 확인할 것도 많아졌습니다. 에이전트들의 도움을 받아 출시까지 왔지만, 함께 풀어야 할 일은 계속 남아 있었습니다.
직접 플레이할 시간을 대신하는 도구들
언어별 화면을 확인하는 일도 버거웠지만, 더 근본적인 문제는 정작 제 게임을 직접 플레이할 시간이 부족하다는 것이었습니다. 코드를 고칠 때마다 처음부터 진행하고, 여러 조합을 시도하고, 기기를 바꿔 다시 확인하는 일을 혼자 감당하기는 어려웠습니다. 이 문제를 줄이려고 개발 초기부터 게임 안에 자동 플레이 AI인 소희를 만들고 계속 다듬어 왔습니다.
소희는 플레이어가 사용하는 화면과 버튼을 거쳐 게임을 진행합니다. 내부 상태를 바꿔 원하는 장면으로 건너뛰는 방식으로는 놓치는 문제가 있기 때문입니다. 실제로 판을 진행하고 화면이 전환되는 과정을 반복해서 지나가게 했습니다. PC와 스팀덱에서 긴 시간 플레이를 맡겼고, iOS·iPad와 Android 기기에서도 제가 직접 소희를 호출해 플레이하게 합니다. 모바일이라고 제가 일일이 직접 플레이하는 것은 아닙니다. 그럴 시간이 없어서 만든 기능이니까요.
자동 플레이를 돌린다고 검수가 모두 끝나지는 않았습니다. 화면이 읽기 편한지, 버튼 배치가 어색하지 않은지는 제가 봐야 했습니다. 기계적인 검사를 통과한 화면도 사람이 보면 이상한 경우가 있었습니다. 오래 실행했을 때의 상태를 살피기 위해 스팀덱에서는 메모리 사용량을 기록했고, 내부 테스트용 윈도우 빌드의 플레이 기록은 따로 모아 살폈습니다.
밸런스를 살피는 일은 별도 시뮬레이터로 나눴습니다. 스킬 조합과 점수, 게임 안의 경제를 실제 화면 없이 계산해 볼 수 있게 했습니다. 다만 자동 플레이의 결과는 소희가 어떤 선택을 하느냐에 따라서도 달라졌습니다. 많은 판을 돌렸다는 이유만으로 사람도 똑같이 플레이할 것이라 생각하면 안 됐습니다. 숫자를 모으는 도구가 생긴 뒤에도, 그 숫자가 무엇을 보여 주는지 판단하는 일은 남았습니다.
필요한 도구는 계속 늘었습니다. 일러스트의 깊이와 움직임, 표정을 조절하는 캐릭터 스튜디오를 만들고, 캐릭터에 붙일 짧은 음성을 후보별로 들어 보는 화면도 만들었습니다. 컨트롤러는 진동과 트리거 저항을 따로 시험할 수 있는 패널을 마련했습니다. 예를 들어 화면에서 이미 알려 주는 위험을 트리거가 무거워지는 감각으로도 전달하려면, 실제 손에 쥐고 강도와 해제를 확인해야 했습니다.
게임을 만들면서 그 게임을 계속 확인하고 고칠 수 있는 환경도 함께 만들어 온 셈입니다. 에이전트와 도구에 반복 작업을 맡기고, 저는 결과를 보며 수정 방향을 정했습니다. 스팀 등록처럼 처음 해 보는 일을 진행하고, 점수 코어처럼 큰 부분을 다시 고치고, 여러 언어와 기기를 지원할 수 있었던 것도 이 과정 덕분이었습니다.
일곱 언어로 늘어난 검수
언어 지원 자체는 출시 전인 5월에 준비했습니다. AI 번역을 활용해 한국어, 영어, 일본어, 중국어 간체와 번체, 독일어, 러시아어까지 일곱 언어를 추가하는 데 일주일 정도가 걸렸습니다. 제 입장에서는 번역 결과도 만족스러워, 언어를 늘리는 일이 생각보다 수월하다고 느꼈습니다.
문제는 그 문장들을 실제 화면에 넣었을 때였습니다. 한국어로는 잘 들어가던 설명이 러시아어나 독일어에서는 버튼과 카드 밖으로 튀어나왔습니다. 번역 파일에 문장이 들어 있다는 것과, 플레이어가 화면에서 제대로 읽을 수 있다는 것은 다른 문제였습니다. 화면 배치를 바꿀 때마다 언어별로 다시 확인해야 했습니다.
출시 후 9월 말부터 10월 초에 UI를 개편하면서 이 문제가 크게 드러났습니다. 러시아어 문구가 길어 패널이 다른 버튼을 가리자, 에이전트가 패널과 버튼을 넓히는 쪽으로 수정했습니다. 테스트는 통과했는데 한국어 화면까지 달라져 있었습니다. 한 언어를 수용하려다 잘 쓰고 있던 화면을 바꿔 버린 셈입니다. 결국 되돌렸습니다.
러시아어의 일부 행동 버튼은 짧은 영어 표기로 바꿨습니다. 나머지는 특정 언어마다 예외를 쌓기보다 긴 문구가 들어오면 자연스럽게 줄을 바꾸도록 배치 규칙을 정리했습니다. 언어별 화면을 캡처해 넘침과 가독성을 확인하는 작업도 필요했습니다. 번역이 빨라진 만큼 지원 언어를 쉽게 늘렸지만, 그 뒤에 따라오는 검수와 유지보수까지 가벼워진 것은 아니었습니다.
번역 자체도 한 번 만들고 끝내지는 않았습니다. AI에게 별도 검수를 맡겨 어색한 표현과 게임 규칙을 잘못 설명한 문장을 고쳤습니다. 한국어 원문부터 수정해야 하는 경우도 있었습니다. 번역 품질에 만족했다는 제 경험과 별개로, 이 과정을 생략할 수는 없었습니다.
일곱 언어의 파일을 안전하게 수정하는 도구도 만들었습니다. 에이전트가 큰 JSON 파일을 직접 고치다가 항목을 빠뜨리거나 구조를 깨뜨리지 않도록, 키를 검색하고 수정하며 누락을 검사하는 명령을 제공했습니다. 5월부터 게임 안에서 쓰던 이 도구는 l10n-c라는 공개 프로젝트로 분리했습니다. 번역 리소스를 관리하는 일은 이 도구가 맡고, 화면이 깨지는 문제는 실제 화면 검수와 레이아웃 수정으로 해결했습니다. 현지화에 필요한 작업은 여기서 끝나지 않았습니다.
거의 완성한 점수 코어를 뒤집은 이유
화투로 게임을 만들었지만, 사실 저는 고스톱 규칙을 잘 알지 못했습니다. 고도리가 어떤 그림의 조합인지도 몰랐고, 그림만 보고 1월부터 12월까지 구분하는 것부터 어려웠습니다. 규칙을 조사하면서 족보 판정과 점수 시스템을 만들어 갔습니다.
그러다 뒤늦게 한국과 일본의 차이를 알게 됐습니다. 한국 화투에서 12월인 ‘비’가 일본에서는 11월이고, 오동은 반대였습니다. 족보 구성도 달랐습니다. 한국 고스톱의 고도리와 별개로, 일본 코이코이에는 멧돼지·사슴·나비를 모으는 이노시카초 같은 족보가 있었습니다.
일본도 출시 지역에 넣어 둔 상태였습니다. 게임은 거의 완성됐는데, 기본적인 고증부터 놓쳤다는 생각에 등골이 서늘했습니다. 번역 몇 줄을 고칠 문제가 아니었습니다. 어떤 패를 조합으로 인정하고 점수를 줄 것인지, 게임의 중심에 있는 로직을 다시 만들어야 했습니다.
일본 시장을 포기해야 하나 싶었습니다. 그래도 함께 작업해 온 에이전트들이 있으니, 완성해 가던 프로젝트를 뒤집어 보기로 했습니다.
테스트부터 작성하고 점수 시스템의 코어를 갈아엎었습니다. 한국식과 일본식 규칙을 전환할 수 있도록 나누고, 처음 실행할 때 일본어를 선택하면 코이코이 규칙과 하나후다 테마가 기본으로 설정되도록 마무리했습니다. 이 일본식 규칙 지원은 얼리 액세스 출시 이후 v0.6 업데이트에 반영했습니다. 예상에 없던 작업에 약 2주가 더 들어갔습니다. 지금 돌아봐도 아찔합니다.
이 작업을 함께한 건 7월 초에 새로 합류한 Claude 에이전트(로아)였습니다. 합류한 지 일주일쯤 된 신입에게 거의 완성된 게임의 코어를 맡긴 셈입니다. 로아는 카드의 내부 식별은 그대로 두고, 화면에 표시하는 월과 점수를 계산하는 규칙을 분리했습니다. 덕분에 기존 세이브를 바꾸지 않으면서 한국식과 일본식을 함께 지원할 수 있었습니다.
그 과정을 옆에서 지켜보며 실력을 인정하게 됐습니다. 어려운 문제를 맡겼더니 기존 게임을 망가뜨리지 않고 풀어내는 모습을 보고, 엘리트 신입이 들어왔다고 생각했습니다. 이 일이 로아에게 메인 개발을 맡기게 된 계기였습니다.
처음부터 제대로 조사했다면 피할 수 있었던 일입니다. 그래도 함께 해결할 에이전트들이 있었기에, 범위를 줄이는 대신 이미 만든 것을 고치는 쪽을 선택할 수 있었습니다.
다시 찾은 개발의 재미
집계 시점의 코드 규모를 대략 나눠 보면 아래와 같습니다. 줄 수는 항목별로 반올림했고, 비율은 반올림 전 항목별 줄 수의 합계를 기준으로 계산한 근사치입니다.
구분 | 코드 줄 수 | 비율 |
게임 본체 + 플랫폼 지원 | 약 15.8만 줄 | 약 38.4% |
Unit, E2E 테스트 | 약 13.9만 줄 | 약 33.7% |
도구·빌드·가드·스크립트·기타 | 약 11.5만 줄 | 약 27.9% |
합계 | 약 41.3만 줄 | 100% |
문서도 따로 세어 보니 약 14만 8천 줄, 1,100만 자 정도였습니다. 장편소설 한 권을 20만 자로 가정하면 글자 수만으로는 약 55권 분량입니다. 문서 분량은 위 코드 합계에 포함하지 않았습니다.
프론트엔드 개발을 업으로 삼으면서도, 제가 가진 기술로 게임 하나를 만들어 보고 싶다는 꿈이 있었습니다. 막상 혼자 해보려니 불가능에 가까워 보였습니다. 블로샤퍼는 그 꿈에 도전한 프로젝트였습니다. 익숙한 웹 기술로 시작했지만, 스팀 등록부터 낯선 규칙과 여러 언어를 다루는 일까지 혼자서는 엄두를 내기 어려웠던 과정들을 에이전트들과 함께 지나왔습니다.
아이를 키우며 지내는 동안, 바쁘다는 이유로 무언가를 만들어 보고 싶었던 마음을 오래 미뤄 두었습니다. 개발은 계속 제 일이었지만, 제 아이디어를 직접 만들어 보는 열정에는 소홀했던 것 같습니다. 블로샤퍼를 만들면서 다시 개발이 재미있어졌습니다. 제게는 잃어버렸다고 느꼈던 10년을 조금씩 되찾는 시간이기도 했습니다.
함께 다듬어 주신 분들께
이렇게 만든 검수 환경으로도 제가 보지 못하는 부분은 있었습니다. 데모부터 얼리 액세스까지 직접 플레이하고 의견을 보내 주신 분들께 감사드립니다. 초기부터 테스트에 함께해 주신 kokokoo님, 놓친 문제를 꾸준히 찾아 주신 즐회장님, 넥스트 페스트 데모를 소개하고 피드백을 주신 김나성님 덕분에 제가 미처 보지 못한 부분을 고칠 수 있었습니다. 리뷰와 토론장, 디스코드에 남겨 주신 의견들도 게임을 개선하는 데 큰 도움이 됐습니다. 혼자 개발한 게임이지만, 여기까지 다듬는 과정에는 많은 분의 도움이 있었습니다.
마지막으로, 응원해 주신 여러 지인분들 그리고 제 가족에게도 진심으로 고맙다는 말을 남깁니다.
개발 과정에서 파생된 프로젝트
출시 이후에도 블로샤퍼를 개발하면서 게임 바깥의 도구들이 하나둘 생겼습니다. 배포 파일의 코드와 이미지를 그대로 꺼내 보기 어렵게 만드는 작업, 스토어 SDK 연동, 여러 언어의 번역 파일 관리도 필요했기 때문입니다.
이 과정에서 만든 도구 네 개를 독립된 오픈소스 프로젝트로 분리하고, Blosharper GitHub 조직에 모아 공개했습니다. 조직 소개 페이지에서는 게임 소개와 플레이 가이드, 개발에 사용한 도구를 함께 볼 수 있습니다. 게임 자체의 소스 코드는 비공개로 유지합니다.
- byteguard: 배포한 JavaScript 번들을 파일만 열어 바로 읽을 수 없도록 바이너리 형식으로 변환하는 도구입니다. 실행에 필요한 코드까지 완전히 숨길 수는 없지만, 소스를 들여다보는 데 드는 수고를 늘립니다.
- headerless: 이미지 파일을 그대로 추출해 열어 보는 일을 어렵게 하려고 만들었습니다. 빌드할 때 이미지 형식을 해석하는 데 필요한 헤더 일부를 분리하고, 실행할 때 메모리에서 복원하며, 화면에 표시된 이미지의 추출까지 막는 DRM은 아닙니다.
- stovesdk.js: Electron 게임에서 STOVE PC SDK를 연결하기 위한 비공식 Node.js 바인딩입니다. Windows x64에서 게임 소유 여부, 업적과 통계, 로그인 정보 등을 다룰 수 있으며, STOVE SDK는 별도로 준비해야 합니다.
- l10n-c: 블로샤퍼의 번역 파일 관리 도구를 분리한 프로젝트입니다. 사람과 코딩 에이전트가 CLI로 여러 언어의 키를 검색·수정하고 누락이나 중복을 점검할 수 있고, Vite 개발 서버에서 쓰는 웹 편집 화면도 제공합니다.
게임 하나를 만들기 위해 해결했던 문제들이 다른 프로젝트에서도 꺼내 쓸 수 있는 도구로 남았습니다. 블로샤퍼를 계속 만들면서 얻은 결과물에 이 네 프로젝트도 추가하게 됐습니다.