6개월, 3개의 게임 프로젝트, 출시 0개
full-time job을 유지하면서 6개월 동안 game developer가 되려고 했어요. 세 개의 프로젝트를 만들고, 684 commits를 썼고, 실제로 출시한 게임은 정확히 0개였습니다. 무슨 일이 있었는지, 무엇을 배웠는지, 그리고 왜 아무것도 출시하지 못했는지에 대한 이야기입니다.
이 글은 몇 주 전에 쓰려고 했어요. 그런데 막상 앉아서 쓸 때쯤이면, 만들고 있던 세 개의 게임 중 하나쯤은 끝나 있지 않을까 하고 기대했던 것 같습니다.
아무것도 끝나지 않았습니다.
그래서 지금 상황은 이렇습니다. 6개월 동안 세 개의 프로젝트, 684 commits. 하지만 다운로드해서 플레이하거나 친구에게 보낼 수 있는 것은 없습니다. full-time job 밖에서 정말 새로운 것을, 그것도 이미 잘하는 분야가 아닌 어려운 것을 배워본 적이 있다면 이 느낌을 꽤 잘 아실 것 같아요.
그래도 이 글을 쓰는 이유는, 왜 아무것도 출시하지 못했는지에 대한 이야기가 완성된 무언가의 예쁜 발표보다 더 유용하다고 생각하기 때문입니다.
시작점
저는 18년 동안 advertising에서 일했습니다. 좋은 일이기도 하고, 어렵기도 하지만, 저는 그 일을 할 줄 압니다. Campaign을 출시했고, team을 만들었고, 책을 썼고, 무대에도 섰습니다. 그 세계에서는 "done"이 어떤 모습인지 알고 있습니다.
그런데 2025년 말, 게임 개발을 배우고 싶어졌습니다. Game marketing도 아니고, game strategy도 아니고, 진짜로 게임을 만드는 일입니다. 코드, 아트, 시스템, 그리고 화면 위에서 캐릭터가 움직일 때의 감각까지요.
저는 게임 엔진 경험이 없었습니다. 3D model을 rigging해본 적도 없었습니다. Animation 맥락에서 state machine이 무엇을 의미하는지도 몰랐습니다. 몇 년 동안 코딩을 해왔고, 주로 web apps와 AI products를 만들었지만, 게임은 완전히 다른 분야였습니다. (혹시 이 중 틀린 부분이 있으면 알려주세요. 아직 배우는 중입니다.)
처음 배운 것은 이것입니다. 게임을 출시하는 것은 어렵습니다. 두 번째로 배운 것은 이것입니다. 문서만으로 좋은 게임 루프를 추론해낼 수는 없습니다.
움직이는 것을 봐야 합니다. 직접 플레이해야 합니다. 최소한 Godot 런타임에 올려서 캐릭터, 카메라, 조작, 피드백이 실제로 어떤 감각을 만드는지 봐야 합니다. 그리고 무언가 재미있는 것이 나올 때까지 만들고, 지우고, 덜어내고, 다시 만들 준비가 되어 있어야 합니다.
무슨 일이 있었는지 적어보겠습니다.
Project 1: The AI Pet Sanctuary (288 commits)
2025년 12월 – 2026년 2월
첫 번째 프로젝트는 단순한 아이디어에서 시작했습니다. 내 컴퓨터 안에 살면서 AI로 나와 대화하는 pet이 있다면 어떨까? pet avatar가 붙은 chatbot이 아니라, behavior, habitat, personality가 있는 실제 pet 같은 존재입니다.
저는 full-stack web application을 만들었습니다. Frontend는 React, backend는 FastAPI, database는 Supabase였습니다. Conversation에는 Gemini를, video에는 Cloudflare Stream을 사용했습니다.
가장 ambitious했던 부분은 animation system이었습니다. 저는 dogs, cats, birds, small animals, fish, reptiles라는 여섯 개 큰 category에 걸쳐 18 pet types를 만들고 싶었습니다. 각각 움직이고, 눈을 깜박이고, 살아 있는 느낌이 나야 했습니다.
처음에는 Rive animations로 시작했습니다. 이 use case에는 맞지 않았습니다. 그래서 CSS와 JavaScript pet animations로 바꿨습니다. 그다음 Google Veo 3.1을 사용해서 animation content를 생성하는 pipeline을 만들었습니다. pet movements를 위한 AI video generation이었습니다. 작동은 했지만 brittle했습니다. API가 실패하고, lighting이 일정하지 않고, generation마다 scale이 달라졌습니다. 실제 pet experience를 design하는 시간보다 generation pipeline과 싸우는 시간이 더 많았습니다.
Full-screen immersive environments가 있는 habitat system도 만들었습니다. pet이 사는 방은 "The Study"라고 불렀습니다. Care screens. Memory screens. Conversation integration. 중간에는 "Quiet Luxury" redesign도 통째로 했습니다. 첫 version이 prototype처럼 보였기 때문입니다. (실제로 prototype이었고요.)
그리고 pivot했습니다.
288 commits 이후, web app이 잘못된 platform이라고 판단하고 native iOS version을 계획하기 시작했습니다. 아직도 그것이 맞는 결정이었는지, 아니면 boredom이 strategy처럼 보였던 것인지 잘 모르겠습니다. 제 일부는 phone에 있는 pet이 browser에 있는 pet보다 더 intimate하다고 믿습니다. 또 다른 일부는 그냥 React에 지쳤던 것 같다고 생각합니다.
하지만 솔직히 말하면, 제가 그것을 never shipped한 진짜 이유는 더 단순했습니다. 재미가 없었습니다. Habitat, animation system, conversation integration을 모두 만들었지만, 실제로 앉아서 pet과 interact했을 때 2분 만에 흥미를 잃었습니다. 제 attention을 붙잡을 만큼 compelling한 것이 없었습니다. 저는 secondary school 때부터 games를 해왔기 때문에, 그 첫 반응을 믿습니다. 아직 항상 어떻게 고쳐야 하는지는 모르지만요. 지금도 가족과 Mobile Legends를 하고, 보통 Mystic까지 올라갑니다. 그것은 passive comfort를 위해 하는 game이 아닙니다. skill과 attention을 요구합니다. 이 pet sanctuary는 둘 다 요구하지 않았습니다.
저는 계속 platform이 문제라고 스스로에게 말했습니다. Web app은 제가 원하는 immersive experience를 줄 수 없다고요. iOS라면 다를지도 모른다고요. 하지만 마음속 깊은 곳에서는 React가 문제가 아니라 design이 문제라는 것을 알고 있었습니다. Platform을 바꾼다고 uninteresting game loop가 갑자기 exciting해지지는 않습니다.
무엇이 잘못됐나
Repo를 돌아보면, 올바른 교훈은 "288 commits without release는 나쁘다"가 아니라고 생각합니다. core loop가 충분히 끌리지 않는다면, 더 일찍 출시한다는 것은 재미없는 것을 더 일찍 출시하는 것일 뿐입니다.
진짜 문제는 loop를 prove하기 전에 container를 계속 바꿨다는 점이었습니다. Project는 merge/order mechanics에서 pure companion으로, immersive habitats로, iOS로 갔습니다. 각 pivot에는 이유가 있었습니다. 하지만 제가 충분히 명확하게 답하지 않은 질문은 더 단순했습니다. 내가 이것을 매일 열고 싶을까?
그것은 한 마리의 pet, 하나의 room, 하나의 conversation, 하나의 care/play interaction으로 검증할 수 있었습니다. 대신 저는 가장 중요한 질문에 대한 런타임의 답을 얻기 전에 6개의 animal categories에 걸쳐 18 pet types와 full habitat system을 만들었습니다. 이 pet은 다시 돌아오고 싶을 만큼 재미있는가?
AI-generated animation은 강력하지만 brittle합니다. 작동하면 놀랍습니다. 작동하지 않으면 product가 아니라 prompts와 API failures를 debugging하게 됩니다. fallback pipeline이 필요했고, 저는 충분히 일찍 만들지 않았습니다.
배운 것
첫 번째 일은 scope를 줄이는 것이 아닙니다. 첫 번째 일은 재미있는 부분을 찾는 것입니다. 때로는 더 만들어야 합니다. 때로는 방금 만든 것을 지워야 합니다. Exploration이 실수였던 것은 아닙니다. core experience에 생명이 있는지 알려주는, 실제로 플레이 가능한 증거 없이 너무 오래 explore한 것이 실수였습니다.
Project 2: 디딤돌이 된 fox (35 commits)
2026년 4월 17일 – 5월 12일
Pet sanctuary가 iOS로 pivot한 뒤, 저는 Godot 4.6에서 새 프로젝트를 시작했습니다. 이번에는 game인 척하는 web app이 아니라, 진짜 game engine에서 scratch부터 game을 만들고 싶었습니다.
Initial concept는 Spirit Fox Kit Sanctuary Sim이었습니다. 작은 fox가 cozy room에 살고, player가 돌봐주는 게임입니다. Simple하고 warm하고 contained한 아이디어였습니다.
Godot project를 setup했습니다. Hidden tense silhouettes, 더 빠른 twitch animations, stillness를 위한 micro-signals를 가진 fox character를 design하려고 했습니다.
하지만 그 문장은 prototype을 실제보다 훨씬 legible하게 들리게 합니다. 화면에서는 fox가 fox처럼 읽히지 않았습니다. 작은 mass 덩어리처럼 보였습니다. usable shape를 볼 수 없었고, 그 주변 room visuals를 판단하는 것은 더더욱 불가능했습니다.
GUT test coverage가 있는 draft room loop를 만들었습니다. Placeholder audio. Interactables를 위한 hover cues. Room scene layout. 실제로 플레이할 수 있도록 cold-start playtest harness도 만들었습니다.
그리고 플레이했습니다.
솔직한 truth는 철학적이라기보다 visual했습니다. fox는 first read에서 실패했습니다. Room prototype에는 mechanically verified path가 있었고, repo에는 placeholder-art build에 대한 abbreviated solo gate pass도 기록되어 있습니다. Stillness, emergence beat, touch distinction, room problem은 그 stage에서는 acceptable했습니다.
하지만 작은 authored beat에 acceptable하다는 것과 full game을 떠받칠 만큼 visually strong하다는 것은 다릅니다. 이 project는 fox가 experience를 carry해야 했습니다. shape, posture, appeal이 보이지 않는다면 sanctuary loop에는 아직 chance가 없었습니다.
그래서 4월 20일, 시작한 지 3일 만에 full pivot spec을 썼습니다. Fox sanctuary sim은 완전히 다른 것이 되었습니다. warm safehouse와 explore할 hostile territory가 있는 landscape action-adventure였습니다. fox-first plans를 pause하고 새로운 direction을 design하기 시작했습니다.
35 commits. 하나의 validated beat. 하나의 pivot. shipped된 것은 없음.
무엇이 잘못됐나
진짜 문제는 animation signals가 unreadable base shape를 보완할 수 있다고 생각했다는 점입니다. 그럴 수 없었습니다. 아래 body에 silhouette가 없다면 twitch는 의미가 없습니다.
Pivot은 첫 work가 wasted였다는 proof가 아니었습니다. 오히려 첫 work를 foundation으로 만들었습니다. 하지만 제게 아직 없었던 것은 larger Hearthkeeper direction이 작동한다는 evidence, 또는 core character를 care할 만큼 readable하게 만들 수 있다는 evidence였습니다.
배운 것
Early playtesting은 prototype이 실제로 무엇을 prove하는지 보여줍니다. Room prototype은 tone, pacing, relationship beat를 prove했습니다. Full game을 prove하지는 않았고, visual readability problem을 즉시 드러냈습니다. 이것은 useful information이지만, 다른 next step을 가리킵니다. fox를 다시 polish하기 전에 character read를 해결하고 가장 작은 safehouse -> run -> return loop를 만드는 것입니다.
Game 1은 technically complete한 loop도 boring할 수 있다는 것을 가르쳐주었습니다. Game 2는 documented되고 tested된 character concept도 몇 초 만에 visually fail할 수 있다는 것을 가르쳐주었습니다. 이 두 실패 덕분에 Game 3에서 더 real progress가 나왔습니다. 저는 readability, motion, weapon feel, 그리고 playable slice가 화면에서 작동하는지에 훨씬 더 주의를 기울이고 있습니다.
Evidence에서 pivot하는 것은 drifting과 다릅니다. fox는 runtime에서 readable하지 않았습니다. 그래서 direction을 바꾸는 것이 자동으로 discipline failure는 아니었습니다. 개선해야 할 부분은 feedback loop입니다. 가장 risky한 visual 또는 gameplay question을 더 빨리 screen에 올리고, concept mode에 머무르지 말고 evidence로 결정하는 것입니다.
Project 3: 파이프라인이 작동하기 시작한 project (361 commits)
2026년 4월 21일 – 5월 13일
이것은 제가 아직 작업 중인 project입니다. 동시에 처음 두 project에서 배운 것들이 finally compound되기 시작한 project이기도 합니다.
Mech tactics game입니다. Player는 combat에서 mech squad를 control하고, battle이 끝나면 LLM이 무슨 일이 있었는지 analyze해서 debrief를 줍니다. Post-match analysis라고 생각하시면 됩니다. 다만 전체 game state에 access할 수 있는 AI가 작성하는 것입니다.
Repo에는 세 개의 tracks가 있지만, 이제 모두 같은 weight는 아닙니다.
Track A — The LLM Debrief System: 초기 AI validation track이었습니다. structured debriefs를 test하는 데 도움이 되었지만, 이제 main product path는 아닙니다.
Track B — The 2D Phone Prototype: 여기서 저는 비교적 몰입감 있는 2D 플레이어 경험을 위한, 실제로 굴러가는 파이프라인을 처음 찾았습니다. 실제 Godot 런타임에는 lane-match combat loop, touch joystick, shop/modules, hero XP, ability cooldowns, phone-readable VFX motifs, enemy punish zones, neutral relay objective, HUD feedback, iOS export/testing flow가 있습니다. Art pipeline도 작동하기 시작했습니다. Nano Banana 2 (Gemini 3.1 Flash Image)가 쓸 만한 초기 hero와 character images를 생성했고, MCP-based pixel cleanup workflow와 Aseprite가 curated candidates를 cleaned sprites, animation frames, Godot-ready sheets로 바꾸었습니다. 완성된 게임은 아니고 phone acceptance도 아직 pending이지만, 처음 두 project보다 훨씬 더 "이건 game처럼 느껴진다"에 가까워졌습니다.
Track C — The Campaign and 3D Path: 현재 제품 방향입니다. Track B의 유용한 교훈을 유지하고, campaign memory loop를 추가하며, production combat을 3D/2.5D로 옮기고 있습니다. 이것은 2D 파이프라인보다 훨씬 어려운 문제입니다. 2D에서는 sprite sheets, HUD tuning, procedural VFX, phone captures로 시각적 판독성을 제어할 수 있습니다. 3D에서는 모든 결정이 modeling, rigging, animation, camera, lighting, GLB export, weapon sockets, hit anchors, action timing, runtime performance를 건드립니다.
저는 custom rigging work를 위해 Blender를 integrate했고, locomotion을 위해 Rokoko mocap data를 가져왔고, full rig, animation tree, weapon socket integration이 있는 hero mech character를 만들었습니다.
3주 동안 361 commits. 실제 2D 파이프라인. 훨씬 어려운 3D 실험. 아직 프로토타입 단계입니다.
무엇이 잘못됐나
인정해야 할 부분이 있습니다. 2D pipeline은 작동하기 시작했지만, 3D pipeline은 제가 방치하면 project 전체를 삼켜버릴 수 있습니다.
Track B에서 파이프라인 작업은 가짜 진전이 아니었습니다. Nano Banana 2 -> Aseprite workflow, touch controls, HUD, 읽기 쉬운 ability motifs, module feedback, phone captures, export loop는 product를 더 플레이 가능한 것으로 만들고 있었습니다. 그 작업은 플레이어가 매 순간 무엇을 보고 느껴야 하는지 알려주었습니다.
지금 리스크는 다릅니다. Track C에서 3D는 무언가처럼 느껴지기 전에 많은 파이프라인이 필요합니다. model import, rig quality, animation names, weapon attachment, muzzle position, hit center, camera angle, lighting, movement, jump timing, attack timing, VFX, runtime inspection. 이것들은 선택 사항이 아닙니다. Character가 읽히지 않으면 whole scene은 몇 초 안에 실패합니다.
하지만 플레이 가능한 encounter가 계속 앞서가야 합니다. 그렇지 않으면 hero mech의 weapon fit, jump compression, left-hand IK, mocap cleanup을 몇 주 동안 개선하면서도 가장 단순한 플레이어 질문에 답하지 못할 수 있습니다. 이것을 조종하는 게 재미있는가?
배운 것
파이프라인 작업은 플레이 가능한 slice를 계속 섬길 때만 유용합니다. Track B는 올바른 파이프라인이 더 몰입감 있는 2D experience를 만들 수 있다는 것을 가르쳐주었습니다. Track C는 3D가 모든 개선의 비용을 높인다는 것을 가르치고 있습니다. Acceptance gate는 구체적이어야 합니다. Player가 hero mech를 읽을 수 있는가, 움직일 수 있는가, aim하고 fire할 수 있는가, hit를 이해하고 다시 하고 싶어 하는가.
Track에는 gate가 필요합니다. Track A는 자기 일을 했습니다. Track B는 재사용할 수 있는 2D game feel과 presentation lessons를 남겼습니다. Track C가 현재의 bet입니다. 문제는 여러 path를 explore한 것이 아닙니다. 명확한 런타임 질문과 판단 기준 없이 그 path들을 다시 여는 것입니다.
3D game development는 거대한 skill gap입니다. Rigging, animation, mocap data, asset budgets, weapon sockets, camera framing, 읽기 쉬운 motion은 제가 professional experience가 전혀 없는 분야입니다. 저는 이것들을 Godot, game design, campaign architecture와 동시에 배우고 있습니다. Learning curve는 가파른 정도가 아니라 거의 수직입니다. 이 부분이 가장 놀라웠던 것 같습니다. Web development에서는 하루 만에 작동하는 것을 만들 수 있습니다. 3D game dev에서는 character의 arm을 제대로 bend시키는 데 저녁 전체를 썼습니다. (6개월 전이라면 이 문장이 무슨 뜻인지 이해하지 못했을 겁니다.)
세 프로젝트의 공통점
제가 제 자신에게 솔직하다면 — 그리고 이 post는 제가 솔직해야만 작동합니다 — pattern은 "scope creep"이 아닙니다. 그것은 너무 쉬운 설명이고, 이 경우에는 틀렸다고 생각합니다.
게임은 business decks처럼 작동하지 않는다고 생각합니다. 적어도 이 세 project가 저에게 그렇게 가르쳤습니다. 전제가 좋아 보인다고 idea가 작동하는 것은 아닙니다. 플레이할 수 있을 때, 또는 최소한 engine에서 실행되는 것을 보고 character, camera, interaction, feedback이 무언가를 하고 있는지 느낄 때 알 수 있습니다.
1. 런타임이 진실입니다
Pet sanctuary는 pet과 interact하고 지루해지기 전까지는 좋아 보였습니다. Fox는 Godot에서 보고 shape를 읽을 수 없기 전까지는 좋아 보였습니다. Track B는 loop가 phone-like runtime에 들어가면서 작동하기 시작했습니다. touch controls, HUD, VFX, shop, XP, readable motifs, capture feedback.
그것이 진짜 pattern입니다. 유용한 진실은 idea가 눈에 보이고 플레이 가능한 형태가 되었을 때만 도착했습니다.
2. 탐색은 필요하지만 evidence가 필요합니다
저는 올바른 lesson이 "그만 추가해라"라고 생각하지 않습니다. Game development에는 exploration이 필요합니다. 만들고, 시도하고, 지우고, 덜어내고, 다시 만들고, 다시 시도합니다. 재미있는 부분을 찾는 과정이기 때문입니다.
Discipline이 필요한 부분은 work의 양이 아닙니다. Evidence loop입니다. 각 piece of work는 질문에 답해야 합니다. 이것이 game을 더 읽기 쉽게 만드는가, 더 몰입하게 만드는가, 더 조작하기 쉽게 만드는가, replay할 가치가 있게 만드는가?
3. 파이프라인은 game을 더 playable하게 만들 때 좋습니다
Nano Banana 2 -> MCP cleanup -> Aseprite workflow는 산만한 우회가 아니었습니다. 더 나은 2D characters와 animation을 game에 넣는 데 도움이 되었습니다. Track B의 HUD와 VFX work도 가짜 진전이 아니었습니다. Runtime을 더 명확하게 만들었습니다.
Risk는 pipeline이 player-facing question에 답하지 않을 때 생깁니다. Track C에서 3D tooling은 필요하지만, 계속 한 가지로 돌아와야 합니다. Player가 hero mech를 read하고, move하고, weapon을 fire하고, hit를 이해하고, 다시 하고 싶어 하는가?
4. Gap은 coding skill이 아닙니다. 플레이 가능한지를 판단하는 감각입니다.
저는 Supabase, FastAPI, React로 full-stack application을 만들 수 있습니다. 3D model을 rig하고, GUT tests를 쓰고, custom debugging tools를 만들 수 있습니다. 아직 배우고 있는 것은 어떤 것이 game으로서 정말 interesting한지 판단하는 일입니다. Track B는 2D에서 저를 더 가깝게 데려갔습니다. Track C는 motion, camera, lighting, weapons, animation이 함께 작동해야 할 때 이것이 얼마나 더 어려워지는지 보여주고 있습니다.
이것이 제가 배운 가장 중요한 것이라고 생각합니다. Code는 제가 잘하는 부분입니다. 어려운 부분은 game이 실제로 무엇인지 결정하고, 그것을 재미있게 만들고, 출시할 가치가 생길 때까지 runtime evidence로 계속 돌아가는 discipline을 갖는 것입니다.
전체적으로 배운 것
여섯 달을 저에게, 또는 같은 위치에 있는 누군가에게 useful한 것으로 정리해본다면, 저는 December에는 몰랐지만 지금은 안다고 생각하는 것들이 있습니다.
-
첫 version은 runtime에서 가장 risky한 question에 답해야 합니다. 제 pet sanctuary에는 제가 다시 돌아오고 싶게 만드는 one pet interaction이 필요했습니다. Fox game에는 micro-signals를 고민하기 전에 blank room에서 readable한 silhouette가 필요했습니다. Mech game은 Track B를 통해 가까워졌습니다. 화면에서 loop를 보고 느낄 수 있었기 때문입니다.
-
Playtesting은 선택 사항이 아니고, runtime review도 포함됩니다. Fox가 형태 없는 덩어리처럼 보이는 순간, project가 아직 작동하지 않는다는 것을 알았습니다. 그 30분은 전체 project에서 가장 valuable했습니다. 그 visual truth에 더 빨리 도달했어야 했습니다.
-
배움은 계획했던 outcome이 아니더라도 유효한 결과입니다. 저는 games를 만들려고 했습니다. Games를 ship하지는 못했습니다. 하지만 Godot, LLM prompt engineering, Nano Banana 2 for character ideation, Aseprite animation cleanup, 2D phone readability, HUD and VFX feedback, animation pipelines, 3D rigging, mocap data, game feel, camera systems, visual readability, 그리고 tools를 만드는 것과 products를 만드는 것의 차이를 배웠습니다. 그것은 아무것도 아닌 것이 아닙니다. Game 3가 아직 출시되지 않았어도 Game 1과 Game 2보다 나은 이유이기도 합니다.
-
아직 honest한 finish line을 정의해야 합니다. 제 일부는 이 project를 completion까지 밀어붙여서 game을 출시했다고 말하고 싶어 합니다. 다른 일부는 learning이 product였고 그것을 받아들여야 한다고 생각합니다. 둘 다 honest한 답입니다. 진실은 그 사이 어딘가에 있는 것 같습니다. 다시 zero에서 시작하는 대신, 배운 것을 존중하는 focused slice를 출시하는 것입니다.
다음은 무엇인가
저는 아직 mech tactics project를 작업 중입니다. LLM debrief concept는 interesting하고, tactics game을 위한 AI-powered post-match analysis에는 genuinely novel한 무언가가 있다고 생각합니다.
하지만 접근 방식을 바꾸려고 합니다. runtime proof 먼저, polish는 나중에, playable slice가 존재할 이유가 생긴 뒤에만 출시하기. 처음 두 project는 낭비가 아니었습니다. 그들은 Game 3에서 제가 보는 것을 바꿨습니다. character가 읽히는가, motion feel이 좋은가, weapon feel이 맞는가, architecture를 설명하지 않아도 누군가 encounter를 이해할 수 있는가.
오늘 새 game을 시작한다면, 큰 architecture plan으로 시작하지 않을 것입니다. 제가 진짜 care하는 question에 답할 수 있는 가장 빠른 runtime proof로 시작할 것입니다. Game 3에서는 이제 같은 discipline이 project 안에서 일어나야 합니다. one character, one weapon, one encounter, one clear acceptance test.
제가 이 중 하나를 completion까지 push할지, 아니면 learning이 product였다고 받아들일지는 아직 모르겠습니다. Timeline에 대해 제가 틀릴 수도 있지만, pattern은 어떤 single project보다 중요하다고 생각합니다.
질문 하나
진심으로 묻고 싶습니다. rhetorical question이 아닙니다. 여기 와본 적이 있나요? (우리가 보통 인정하는 것보다 더 많은 builders가 이곳에 와봤을 것 같습니다.)
몇 달 동안 무언가를 만들었지만 결국 ship하지 못한 적이 있나요? 결국 끝냈나요, 아니면 떠났나요? 그리고 떠났다면, 그것은 올바른 결정이었나요, 아니면 아직도 생각하나요?
저는 career에서 여러 가지를 ship해왔습니다. Campaigns, platforms, products. 하지만 그것들은 제가 18년의 experience를 가진 domain이었습니다. Game development는 새롭고, "technically 만들 수 있다"와 "좋은 game이다" 사이의 gap은 제가 예상한 것보다 훨씬 넓었습니다.
그 gap을 건너본 적이 있다면, 무엇이 다시 pivot away하지 않게 했는지 듣고 싶습니다. LinkedIn으로 reply해도 되고, 직접 note를 보내도 됩니다. 정말 궁금합니다.
여기까지입니다. 특히 비슷한 일을 겪어본 적이 있다면, 생각을 듣고 싶습니다. LinkedIn으로 연락하거나 직접 메시지를 보내주세요.
감사합니다,
Chandler
