읽기 전에

이 글을 읽는 법

핵심 질문: 혼자서, 미리 다 계획하지 않고 시작한 사이드프로젝트가 6개월 만에 12만 가입자 규모의 서비스가 되려면 — 무엇을 먼저 하고, 무엇은 성장이 강제할 때까지 미뤄도 되는가?
멘탈 모델: "일단 출시 → 유저가 진짜 문제를 드러냄 → 아키텍처는 성장이 강제할 때 재설계." 저자는 5주 만에 익숙한 스택(Next.js + Convex)으로 첫 버전을 내고, 비용 위기가 닥칠 때마다 한 단계씩만 옮겼다(managed Convex → Railway 셀프호스팅 → 매치당 격리 룸 구조의 PartyKit/Durable Objects 재작성). 계획으로 예측한 게 아니라 실사용이 노출한 순서대로 고친 것이 이 글의 뼈대다.
권장 읽기 순서 — 요약만 볼 사람: 01(시작 동기)과 06(6개월 후 수치)만 읽으면 스토리의 앞뒤가 잡힌다. 아키텍처 이전 사례가 궁금한 엔지니어: 03~05의 TECHNICAL NOTE 4개(Convex 비용 폭발 → Railway 셀프호스팅의 한계 → PartyKit 룸 모델 + 패치/체크포인트 복구 설계)를 순서대로 — 각 이전의 "왜"가 앞 단계의 실패에 있다. 사이드프로젝트 시작 고민자: 01~02(아이디어 검증 이틀 만에 첫 커밋, AI 코딩 도구가 바꾼 현실성 감각)를 정독하고 마지막 회고 문단으로 건너뛰어라. 예상 소요: 요약만 3분 / 완독 15분.
  1. 저자가 첫 버전에서 계정·덱빌더·덱 저장을 전부 뺀 이유는 무엇이고, 그 기능들은 언제 어떤 계기로 다시 들어왔나?
  2. Convex 셀프호스팅(Railway)은 비용 문제를 해결했는데도 왜 장기 해법이 못 됐고, 최종 아키텍처에서 Convex는 완전히 사라졌나 아니면 역할이 바뀌었나?
  3. 매치당 격리 룸(Durable Object) 모델에서 "규모가 되면 작은 버그도 비싸진다"의 실제 사례는 무엇이었나? (7월의 idle room 정리 알람 루프)

Executive Summary

한 문장 핵심

기술 컨설팅·스타트업 경력의 개발자 Stefan Görlitz가 "you can just do things" 정신으로 Riot의 TCG 리프트바운드 비공식 팬 시뮬레이터 RiftAtlas를 첫 커밋 5주 만에 릴리즈하고, 이후 6개월간 실사용 압력에 맞춰 스택을 거의 전면 재작성하며 총 가입 119,866명·주간 DB row read 약 10억 규모의 서비스로 키워낸 회고다. 핵심 주장은 두 가지 — AI 코딩 도구(특히 더 독립적으로 일하는 Codex)가 "혼자 이걸 만든다"를 현실적으로 만들었고, 속도는 일을 줄이는 게 아니라 야심을 키우는 데 쓰였다는 것. 그리고 대부분의 문제는 사람들이 쓰기 시작한 뒤에야 보였으므로 v1을 빨리 내놓은 게 옳았다는 것이다.

6개월첫 커밋 → 이 글 게시 (2/10 → 8/10)
5주첫 버전 릴리즈까지
119,8668월 10일 기준 총 가입
~10억최근 한 주 DB row read (write 1.26억)
~50만저장된 덱 수
~18만 LOC앱 3개 + 공유 패키지 4개 (Turborepo)

기원 — 구경꾼에서 만드는 사람으로

왜 지금 가능했나 — AI 도구가 바꾼 현실성

V1 (5주) — 경험 우선, 기능 최소

성장 — 첫 커뮤니티 주도 프로젝트

운영 국면 — 4개 워크스트림과 비용 압박

재작성 — 매치별 격리 룸 아키텍처

스케일과 비용의 교훈

RiftAtlas 계정 성장 그래프 — 8월 10일 기준 총 119,866 가입
8월 3일 주간 13,265 가입·29,419 로그인, 8월 10일 총 119,866 가입.

현재 — 6개월 후

팩트체크
종합 신뢰도 A- 외부 검증 가능한 인용·링크는 전부 실물과 일치했다. 다만 이 글은 1인칭 회고라 핵심 수치(가입자·DB 읽기량·LOC·5주 빌드)는 저자 자체 보고이며 외부 검증이 불가능하다는 점을 반영해 등급을 산정했다 — 외부 사실은 A급, 내부 수치는 신뢰 기반 수용.
RiftAtlas는 Riftbound를 온라인으로 플레이하는 비공식 팬 시뮬레이터다 — riftatlas.com 직접 확인: 카드 DB·덱빌더·온라인 매치 시뮬레이터를 제공하며 "Riot Games does not endorse or sponsor" 고지가 실제로 붙어 있다. 참조
Riftbound는 Riot Games의 실물 League of Legends TCG다 — 2024-12 "Project K"로 발표, 2025-10-31 북미·EMEA 등 글로벌 출시, 영어판 퍼블리셔는 UVS Games. 공식 디지털 클라이언트는 아직 없어 팬 시뮬레이터가 존재하는 배경도 일치한다. 참조
제목의 출처 — Aaron Francis의 "you can just do things" — 링크된 영상의 실제 제목이 "You Can Just Do Things | Aaron Francis at Laracon US 2025 in Denver, CO"로 확인됐다. 인용 취지와 정확히 일치. 참조
🟡 2월 8일 Riftbound 커뮤니티에 시뮬레이터 요구사항을 물었다 (Reddit 설문) — reddit.com 직접 페치가 차단되어 스레드 본문은 확인 불가. 다만 URL 슬러그("which_improvements_from_tcgarena_would_you_like")가 주장 내용(TCG Arena 대비 개선점 질문)과 정확히 대응한다. 접근 제한으로 🟡. 참조
🟡 약 5주 뒤 Reddit에 첫 버전을 공개 발표했다 — 같은 이유로 스레드 직접 확인 불가(접근 제한). 슬러그("a_new_way_to_test_and_play_riftbound_online_fan")가 "새로운 온라인 플레이 방법 · 팬 프로젝트" 발표 주장과 일치하고, 검색에서 play.riftatlas.com이 실제 시뮬레이터로 확인된다. 참조
Khasino가 RiftAtlas를 영상으로 다뤘다 — 링크 영상 제목 "Awesome New Riftbound Online Game Client!" 확인 + Khasino 본인 X 계정(@KhasinoTTV)이 같은 영상을 "Rift Atlas, a new online game app for Riftbound" 문구로 직접 공유했다(2026-03 경). 참조
Silent Knight가 리뷰·하우투 영상을 올렸다 — 링크 영상 제목 "New Riftbound Online Client?! | Rift Atlas Review & How to Play"(2026-04-03) 확인. Silent Knight(@The-Silent-Knight)는 Riftbound 전문 유튜브 채널로 실재하며 온라인 플레이 가이드 콘텐츠를 운영한다. 참조
TCG Arena는 브라우저 기반 TCG 플랫폼이며 Riftbound를 지원한다 — tcg-arena.fr 자체는 SPA라 본문 추출이 빈약했으나, 제3자 가이드(riftbound.zone, riftbound.one FAQ)가 "공식 클라이언트 부재 상황에서 Riftbound 온라인 플레이의 사실상 표준 커뮤니티 플랫폼"으로 일관되게 기술한다. 참조
Codex — OpenAI의 에이전틱 코딩 도구 — 링크된 openai.com 페이지 직접 페치는 403이었으나, 검색으로 동일 URL의 "Introducing the Codex app" 페이지 실재와 내용(멀티 에이전트 관리 데스크톱 앱, "command center for agents")을 확인했다. "다른 도구보다 독립적으로 일한다"는 저자 평가와 정합. 참조
PartyKit 룸 = Cloudflare Workers + Durable Objects 위에서 동작 — PartyKit은 2024-04 Cloudflare에 인수됐고, 각 PartyKit 룸이 Durable Object(상태 유지형 Workers 프리미티브) 하나로 백업되는 구조가 공식 블로그·문서로 확인된다. 글의 "매치당 격리된 룸" 아키텍처 서술과 정확히 일치. 참조
Convex는 리얼타임 백엔드+DB이며 셀프호스팅(오픈소스 백엔드)이 가능하다 — get-convex/convex-backend 오픈소스 저장소와 공식 셀프호스팅 문서 확인. Postgres를 스토리지 백엔드로 쓰는 Railway 셀프호스팅 배포 템플릿도 실재해, 글의 "Railway에 Convex 셀프호스팅 + Postgres 운영" 마이그레이션 서사와 정합한다. 참조
두 번째 대형 토너먼트 — Topdeck.gg의 RiftAtlas Convergence 2 — 이벤트 페이지 직접 확인: RiftAtlas 주최 Riftbound 컨스트럭티드 대회, 256명(64명×4그룹 스위스), 상금 최대 $5,500, 정원 마감 상태. "대형"이라는 표현에 부합한다. 참조
Riot "Legal Jibber Jabber" 팬 정책 하에 제작됐다는 고지 — Riot 공식 법무 페이지 직접 확인: 비상업 팬 프로젝트에 한정된 취소 가능 라이선스 + "does not endorse or sponsor" 고지 의무가 실재하며, RiftAtlas 사이트와 이 글 푸터의 고지 문구가 정책 요구와 일치한다. 단, 정책상 Riot은 언제든 프로젝트 중단을 요구할 수 있고 게임/앱에의 IP 사용은 원칙적 금지라 팬 시뮬레이터의 법적 지위는 회색지대다 — 글 자신도 Reddit에서 이 논쟁이 있었다고 인정한다. 참조
⚠️ 내부 수치: 총 가입 119,866명(8/10 기준)·주간 가입 13,265·주간 DB 행 읽기 ~10억·쓰기 1.26억·프로덕션 코드 ~18만 줄·첫 버전 5주 — 전부 저자 자체 보고(자기 대시보드 스크린샷)로, 외부에서 검증할 방법이 없다(자체 보고). 다만 커뮤니티 반응(Khasino·Silent Knight 영상, 256명 정원 마감 토너먼트)이 상당한 사용자 기반의 방증은 된다. 참조

Rift Atlas

그냥 하면 된다:
RiftAtlas 만들기

6개월 전, 나는 RiftAtlas를 만들기 시작했다. 처음부터 모든 것을 이해하려 들었다면 지레 겁먹고 시작조차 못 했을지도 모를, 야심 찬 팬 프로젝트였다. 이 글은 그 프로젝트가 어떻게 시작됐고, 사람들이 쓰기 시작한 뒤 무슨 일이 벌어졌으며, 거기서 어떻게 성장해 왔는지에 대한 이야기다.

01 / 보는 것에서 만드는 것으로

나는 이 판들을 지켜보기만 했지, 정말로 참여하지는 않았다.

무언가에 빠지면 나는 그 주변의 콘텐츠를 잔뜩 소비하는 편이다. 게임, 스타트업, 만들기(building)도 다르지 않았다. 팟캐스트, 런칭 포스트, 아키텍처 후기, 창업자 스토리, 그리고 자기 작업을 공개적으로 공유하는 사람들을 따라다녔다. 그 덕에 그 커뮤니티들과 연결되어 있다는 느낌은 받았지만, 나는 대부분 구경꾼이었다. 그 시간이 낭비였다고 생각하지는 않는다. 다만 다른 사람이 무언가를 만드는 걸 지켜보는 것이 내가 직접 무언가를 만드는 것의 대체물은 아니었다. 보는 것에서 하는 것으로의 그 전환이 바로 이 글의 제목이 Aaron Francis에 대한 오마주인 이유이기도 하다. 그는 같은 마인드셋에 대해 많이 이야기해 왔다: 그냥 하면 된다(you can just do things).

여러 트레이딩 카드 게임을 온라인으로 플레이할 수 있는 브라우저 기반 플랫폼인 TCG Arena에서 Riftbound를 플레이하면서 이미 여러 아이디어가 있었다. 2월 8일, 아직 프로젝트를 저울질하던 중에 Riftbound 커뮤니티에 전용 시뮬레이터라면 무엇을 원하겠는지 물었다. 이틀 뒤, 첫 커밋을 했다. 그리고 정확히 6개월 뒤인 오늘 이 글을 발행한다.

기술 컨설팅과 소프트웨어 개발로 보낸 세월, 그리고 스타트업 창업 경험 덕에, 첫 버전조차 보통은 얼마나 많은 작업량이 드는지에 대한 감은 어느 정도 있었다. AI 코딩 도구가 그 '현실적으로 가능한 것'의 기준을 바꿔 놓았다. 이미 많이 써 보긴 했지만, Codex는 진짜 한 단계 도약처럼 느껴졌다. 그전에 써 본 도구들보다 훨씬 독립적으로 일할 수 있었기 때문이다. 덕분에 과정이 한결 매끄러워졌고, 시뮬레이터를 직접 만들어 보겠다는 자신감도 생겼다.

내가 훨씬 덜 생각해 본 것은 첫 버전 이후에 따라올 모든 것들이었다. 마케팅과 운영부터 스케일링, 그리고 들어갈 총 시간과 돈까지. 처음의 나는 그저 내가 쓰고 싶은 제품을 만드는 데만 집중했다. 만약 모든 것을 미리 계산하려 들었다면, 아예 시작하지 못했을지도 모른다.

완성된 Sivir 덱이 로드된 현재의 RiftAtlas 로비
Riftbound는 Riot Games의 실물 리그 오브 레전드 트레이딩 카드 게임이다. RiftAtlas는 이를 온라인으로 플레이하기 위한 비공식 팬 프로젝트다. 플레이어는 이 로비에서 덱을 고르고 매치를 시작하거나 참가한다.
체인에 Hextech Ray가 올라가 있고 전장의 상대 Mech를 가리키는 파란 화살표가 표시된 Stefan의 현재 RiftAtlas 보드
매치 안에서 RiftAtlas는 공유 디지털 테이블을 제공한다. 플레이어들은 각자의 덱을 가져와 보드 위에서 카드를 움직이며 브라우저에서 서로 대전한다.
02 / 첫 버전 만들기

내가 만들고 싶은 경험이 무엇인지는 알고 있었다.

RiftAtlas에서의 플레이는 매끄럽고, 명확하고, 따라가기 쉬워야 했다. 나는 온라인 플레이를 어색하게 만드는 작은 순간들에 집중했다. 실수를 되돌리는 것, 반복되는 루틴 액션을 처리하는 것, 상대에게 내가 무엇을 하려는지 보여주는 것 같은 순간들이다.

첫 릴리즈는 거의 전적으로 그 경험에만 집중했다. 계정도, 덱 빌더도, 저장된 덱도 없었다. 플레이어는 가입 없이 쓸 수 있었고, 플레이하고 싶을 때마다 그때그때 덱을 임포트했다.

초기 기술 결정은 빠르게 내렸지만, 그 5주의 대부분은 첫 버전의 사용감을 다듬는 데 쏟아부었다. AI 코딩 도구에 등장하기 시작한 더 에이전틱한 능력들 덕분에, 길고 여러 단계짜리 작업을 스스로도 놀랄 만한 속도로 쳐낼 수 있었다. 모델은 일의 어떤 부분에서는 다른 부분보다 훨씬 뛰어났지만, 여전히 밀착 지휘와 충분한 반복이 필요했다. 특히 UI가 그랬다. 첫 릴리즈가 미완성처럼 느껴지는 것만은 원치 않았기 때문이다. 그 속도가 일의 총량을 줄여 주지는 않았다. 나는 남는 여력을 RiftAtlas를 더 야심 차게 만드는 데 썼다. 작업은 격렬했고, 아주 재미있었다.

시작하고 약 5주 뒤, 첫 버전을 릴리즈하고 Reddit에 공개를 알렸다.

03 / 유저에게 배우기

사람들이 나타나기 시작했다.

Reddit 발표는 빠르게 주목을 받았다. 팬이 만든 시뮬레이터가 Riot의 규정 안에 어떻게 들어맞는지에 대한 논쟁도 좀 일었다. 놀라웠던 건 그 관심이 포스트 이후에도 이어졌다는 점이다. 사람들이 웹사이트를 찾아오고, Discord 서버에 들어오고, 내가 다른 데서 딱히 홍보하지 않는데도 RiftAtlas를 남들에게 공유했다. 사이트는 하루 방문자 수백 명에서 금세 1천 명 안팎이 되었다. 그것만으로도 이미 굉장히 많은 사람처럼 느껴졌다.

비슷한 시기에 Khasino가 영상에서 RiftAtlas를 소개했고, 곧이어 Silent Knight가 리뷰와 사용법 영상으로 뒤를 이었다. 내 발표 바깥에서 입소문이 퍼지는 것을, 그리고 사람들이 RiftAtlas를 쓰고 즐기는 것을 지켜보는 건 정말 근사한 기분이었다.

유저가 늘어나자 제안과 버그 리포트도 늘었다. 나는 응답하고, 고치고, 사람들이 다음으로 무엇을 원하는지 들을 수 있었다. 활발한 커뮤니티가 붙어 있는 프로젝트를 만들어 본 건 처음이었다. B2B 맥락에서 피드백을 모으고 유저를 위해 만드는 일에는 익숙했지만, 보통 훨씬 작은 그룹이 대상이었다. 공개 커뮤니티가 RiftAtlas를 논의하고, 문제를 보고하고, 내가 다음에 무엇을 작업할지에 영향을 주는 건 아주 다른 경험이었다.

커뮤니티의 반응은 즉각적이었지만, 운영상의 문제들은 좀 더 서서히 드러났다. 트래픽이 늘면서 스케일링 이슈와 운영 비용이 일상 업무의 일부가 되었다.

04 / 성장 따라잡기

더 많은 사람이 RiftAtlas를 쓰면서, 일이 늘어났다.

이제 지탱해야 할 매치가 더 많아졌고, 응답해야 할 리포트와 제안이 더 많아졌으며, 관리해야 할 인프라 비용도 올라갔다. 시뮬레이터를 개선하는 일은 여전히 중요했지만, 더 이상 일의 전부가 아니었다.

Discord 서버가 커지면서 모더레이터를 찾기 시작했다. Brandon은 그렇게 나서 준 사람 중 하나였고, 시간이 지나며 RiftAtlas 운영에 훨씬 깊이 관여하게 되었다.

PRODUCT

시뮬레이터 개선

새 기능과 다듬기는 여전히 중요했지만, 이제 버그 하나하나가 점점 늘어나는 유저들에게 영향을 미쳤다.

OPERATIONS

매치를 계속 굴리기

매치 볼륨이 커지면서 신뢰성과 성능이 일상 업무의 일부가 되었다.

COMMUNITY

커뮤니티 지원

피드백, 버그 리포트, 모더레이션, 다음에 무엇을 작업할지 정하는 일 모두에 손이 필요했다.

SUSTAINABILITY

성장을 지속 가능하게

인프라 비용이 빠르게 올라, 다른 셋업이 필요해졌다.

비용은 가장 시급한 운영 문제가 되었다. 읽기와 쓰기를 줄이는 것만으로는 부족해지자, 백엔드를 매니지드 서비스에서 내가 직접 운영하는 인프라로 옮겼다. 처음에는 비용이 크게 떨어졌지만, 사용량이 늘면서 신뢰성이 나빠졌고 인프라 비용도 다시 올라갔다. 이것이 장기적 해법이 아니라는 것이 곧 분명해졌다.

05 / RiftAtlas 재설계

RiftAtlas는 첫 버전을 훨씬 넘어서 성장해 있었다.

그 이전(migration)은 시간을 벌어 줬지만, 성장은 계속해서 그 한계를 드러냈다. 장기 문제를 풀려면 또 한 번의 자잘한 개선 이상의 것이 필요했다.

가장 큰 변화는 라이브 매치가 돌아가는 방식이었다. 새 아키텍처는 각 매치에 격리된 자기만의 룸을 부여해서, 하나의 중앙 게임 프로세스를 공유하는 대신 매치들이 독립적으로 스케일할 수 있게 한다.

이것은 대규모 재작성이었고, 내가 출발했던 것과는 근본적으로 다른 모델이었다. 전환 초기에는 문제가 꽤 많았지만, 훨씬 나은 기반을 얻었다. 더 많은 작업과 반복 끝에 새 모델은 안정적이고 신뢰할 수 있게 되었다.

🌍 (원문에서는 실시간 애니메이션 지도)
전 세계에서 발생한 실제 RiftAtlas 리얼타임 트래픽 — 발행 전 일주일 동안 캡처한 것.

RiftAtlas의 나머지 부분에서도 개발은 계속되었다. 원래 애플리케이션의 거의 모든 부분이 결국 교체되거나 대대적으로 재작업되었다. 계정, 덱 빌더, 저장된 덱처럼 첫 릴리즈에서 빠져 있던 조각을 채워 넣는 변화도 있었고, 기존 기능을 재설계하거나 보이지 않는 곳의 동작 방식을 바꾸는 변화도 있었다.

비용을 감당 가능하게 유지하려면 다른 곳의 변화도 필요했다. 웹사이트가 콘텐츠를 로드하는 방식과 에셋을 전달하는 방식이 여기에 포함됐다.

프로젝트는 더 넓은 Riftbound 커뮤니티와도 점점 더 연결되어 갔다. Brandon의 역할은 계속 커졌고, 이 판에서 크리에이터들과 다른 프로젝트를 운영하는 사람들이 협업 방안을 놓고 연락해 오기 시작했다.

그 모든 재작업에도 불구하고, 첫 버전을 빠르게 릴리즈한 것이 옳은 결정이었다고 지금도 생각한다. 쓸 만해지자마자 RiftAtlas를 플레이어들 앞에 내놓은 것이 이 프로젝트가 계속할 가치가 있음을 보여줬고, 실제 사용이 무엇을 바꿔야 하는지를 더 분명하게 만들어 줬다.

06 / 6개월 후

오늘의 RiftAtlas.

만들기 시작한 지 6개월, RiftAtlas는 12만 명에 가까운 가입자를 기록했고, 플레이어들은 50만 개에 육박하는 덱을 저장했다.

8월 3일 주간 가입 13,265건·로그인 29,419건, 8월 10일 기준 총 가입 119,866건을 보여주는 RiftAtlas 계정 성장 그래프
8월 10일까지 RiftAtlas는 총 119,866건의 가입을 기록했다. 8월 3일 주간에는 13,265건의 가입과 29,419건의 로그인을 기록했다.

우리는 지금 두 번째 대형 토너먼트를 준비하고 있다. RiftAtlas는 Riftbound 커뮤니티의 온라인 플레이에서 큰 비중을 차지하게 되었고, 사람들이 얼마나 즐겁게 쓰고 있는지 종종 내게 직접 이야기해 준다. 그 말을 듣는 건 여전히 정말 기분 좋은 일이다.

플레이해 준 모든 분들, RiftAtlas를 공유해 준 분들, 버그를 보고하고 개선을 제안해 준 분들, 커뮤니티가 굴러가게 도와준 분들, 콘텐츠를 만들어 준 분들, 우리와 협업해 준 분들 모두에게 감사드린다. 내가 만든 것을 사람들이 쓰는 걸 지켜보고, Riftbound 판의 다른 이들과 함께 일하는 것이 정말 즐거웠다. 그 모든 지원이 없었다면 이 프로젝트는 지금 이 자리에 있지 못했을 것이다.

이 글을 쓰면서 다음 문제로부터 한 발 물러나 프로젝트 전체를 바라보게 되었다. RiftAtlas가 6개월 만에 이렇게 되었다는 게 나로서는 아직도 좀 얼떨떨하다.

이 대부분은 처음부터 계획할 수 없었던 것들이다. 사람들이 RiftAtlas를 쓰기 시작한 뒤에야 비로소 보였기 때문이다. 나는 내가 쓰고 싶은 제품을 만드는 데서 시작했고, 그다음에 벌어지는 일들로부터 계속 배워 나갔다. 6개월이 지난 지금, 프로젝트가 잘못될 수 있는 온갖 경우의 수를 곱씹는 대신 그냥 저질렀던 것이 다행이라고 생각한다.



기타

용어 · 고지