BlogForest99 개발 회고

9살의 기획자, 48시간의 의사결정

좋은 시스템은 완벽한 기능이 아니라 지속 가능한 구조에서 만들어진다.

문제

개발자로 산다는 것은 만들고 싶은 것과 만들 수 있는 것 사이에서 끊임없이 타협하는 일이다.

내 경우, 이 타협선을 자주 낮춘다. “이 정도면 충분하지 않나”라고 판단하고 다음으로 넘어가는 습관이 생겼다. 그런데 금요일 저녁, 아들이 노트 한 장을 가져왔을 때, 그 타협선을 다시 생각해보게 됐다.

“아빠, 이거 게임 기획했어. 만들 수 있어?”

노트에는 삐뚤빠뚤한 글씨와 알록달록한 그림이 있었다. 문제 정의는 명확했다: 숲에서 99일을 버텨내는 게임. 낮에는 나무를 모으고, 밤이 되면 무서운 것들이 나온다. 캐릭터, 몬스터, 보스까지 전부 그려져 있었다.

더 흥미로운 건, 이건 명확한 비즈니스 요구사항이었다는 점이다. 작은 스케일의 프로젝트지만, 명확한 고객(아들)이 있고, 검증 가능한 목표가 있다.

그 눈빛을 보는 순간, 나는 한 가지를 결정했다: 이 48시간을 어떻게 구조화할 것인가.

기존 접근의 한계

만약 정상적인 개발 방식을 따랐다면?

1️⃣ 완벽함을 추구하는 방식

  • 3D 모델링부터 시작
  • Blender로 캐릭터 제작
  • 물리 엔진 통합
  • 결과: 3개월 후 보여줄 게 없음

2️⃣ 스택 고민

  • 어떤 엔진을 쓸까? (Unity? Unreal? Godot?)
  • 학습 곡선은?
  • 결과: 선택 지옥에 빠짐

3️⃣ 아이의 관심도 고려

  • 게임을 완성하기 전에 아이는 다른 것에 관심 갈 가능성 높음
  • 그럼 작업 동기부여 사라짐
  • 결과: 미완성 프로젝트로 끝남

내가 내린 판단

판단 기준: 시간 제약이 있을 때, 무엇을 우선순위에 둘 것인가

나는 이렇게 결정했다:

✅ 선택한 것

  • 빠른 피드백: 웹 기반 (브라우저에서 즉시 실행)
  • 손에 익은 스택: Three.js + React (새로운 학습 곡선 없음)
  • 아이의 피드백 루프: 매일매일 변화를 보여주기
  • 완벽하지 않아도 되는 것: 캡슐 모양 캐릭터도 “사람”이 될 수 있다

❌ 포기한 것

  • 정교한 3D 모델링
  • 고급 물리 엔진
  • 상용 수준의 애니메이션
  • 게임 개발자들이 “필수”라고 말하는 것들

핵심 아이디어:

“최소 동작 게임(MMG, Minimum Viable Game)을 만들고, 아이의 반응으로 개선 방향을 정한다.”

실행 과정 - 의사결정의 연속

금요일 밤 - 첫 동작 (새벽 2시)

문제: 3D 씬이 보이지 않음 판단: 좌표계 확인, 카메라 위치 조정 결과: 나무 몇 그루가 화면에 떠 있음

이 시점에서 나는 완벽한 나무 모델을 원하지 않았다. **“무엇이 나무로 인식되는가”**를 확인하는 게 목표였다.

토요일 오후 - 캐릭터 모델링

아들: “캐릭터는?”

기술적으로는 Blender를 켜고 8시간을 들여야 한다. 하지만 시간 예산이 있다. 나는 캡슐로 대체했다.

아들: “이게 사람이야?”

나: “지금 이 형태가 중요한 게 아니라, 움직인다는 게 중요해. 나중에 더 좋게 만들 수 있어.”

이 결정은 전형적인 MVP(Minimum Viable Product) 사고다.

토요일 밤 - 몬스터 AI의 트레이드오프

문제: 몬스터가 벽을 뚫고 지나감 선택지:

  1. 정확한 물리 시뮬레이션 (시간: 8시간)
  2. “그럴듯해 보이는” 움직임 (시간: 2시간)

나는 2번을 선택했다. “진실성(authenticity)“과 “완벽성(perfection)“은 다르다.

// 완벽한 물리 대신, 충분히 작동하는 방식
monster.moveTowards(player, SPEED);
if (distance < ATTACK_RANGE) {
  monster.attack();
}

일요일 오후 - QA와 밸런싱

아들: “곰이 너무 약해.” 내: “체력 100에서 200으로 올릴까?” 아들: “300!” 내: “너무 센데…” 아들: “아빠가 못해서 그래.”

조직 확장성의 관점에서 본 게임 밸런싱.

아이는 실은 최고의 QA 리더였다. 완벽한 문서 작성보다 실제 플레이를 통한 피드백이 더 정확했다. 이것이 애자일의 본질이다.

최종 곰 체력: 250 (타협의 결과)

결과: 배운 것들

1️⃣ 시스템 관점에서 본 성공

성공의 정의가 중요하다.

  • “완벽한 게임을 만들었는가?” → NO
  • “아이가 플레이했는가?” → YES
  • “아이가 재미를 느꼈는가?” → YES

나는 요구사항(아이의 노트)을 충족했다. 그것이 성공의 정의였다.

2️⃣ 의사결정 구조

이 48시간 동안 수백 개의 선택을 했다. 하지만 모두 같은 기준으로 판단했다:

각 선택 시점마다:
"완벽함"과 "충분함" 중 어디에 무게를 둘 것인가?

대부분의 경우, “충분함”을 선택했고, 그것이 배포까지 이르게 했다.

3️⃣ 조직의 동기부여

혼자였다면 토요일 밤 11시쯤 포기했을 거다. 하지만 아이의 “아빠 언제 돼?”가 매번 동기부여가 됐다.

좋은 팀은 완벽한 개발자 때문이 아니라, 명확한 목표와 피드백 루프 때문에 만들어진다.

4️⃣ 기술 선택의 기준

Three.js를 선택한 이유는 “가장 좋아서”가 아니라 “이미 알고 있어서”다.

이 판단이 얼마나 중요한지 48시간이 지나서야 알았다. 새로운 기술을 배울 시간이 없었다.

플레이어 피드백

월요일 아침, 아들이 게임을 플레이했을 때:

  • “버그는 있어?” → “있어.”
  • “플레이할 수 있어?” → “응!”
  • “재미있어?” → “진짜 재미있어!”
  • “내가 만든 거 맞아?” → “너의 기획, 아빠의 코드. 함께 만든 거야.”

마지막 대사가 전부였다.

생각해볼 질문

당신의 프로젝트에서:

  1. “완벽함”의 정의가 무엇인가?

    • 그것이 정말 고객의 요구사항인가, 아니면 개발자의 욕심인가?

  2. 의사결정 속도는 충분한가?

    • 각 선택에서 “충분함”을 인정하고 넘어갈 수 있는가?

  3. 피드백 루프는 얼마나 짧은가?

    • 주 단위? 일 단위? 시간 단위?
    • 더 짧아질 수 있을까?

  4. 스택 선택 시, 학습 곡선을 고려했는가?

    • “최고의 기술”과 “지금 할 수 있는 기술” 중 어느 것을 선택했고, 왜 그랬는가?

  5. 당신의 팀(또는 고객)은 “불완전함”을 수용할 준비가 되어 있는가?

    • 버그가 있어도 배포할 수 있는가?
    • 그렇지 않다면, 그것이 팀 문제인가 조직 문화 문제인가?

마지막 생각

이 프로젝트를 통해 깨달은 가장 큰 것은:

“개발자의 경쟁력은 구현 속도가 아니라, 무엇을 포기할 것인지 판단하는 능력이다.”

완벽한 게임을 만드는 개발자는 많다. 하지만 48시간 안에 제약 조건 속에서 동작하는 게임을 만들고, 고객의 피드백을 받고, 함께 기뻐할 수 있는 개발자는 드물다.

AI 시대, 더욱 그렇다.

플레이 링크

게임을 직접 해보시고 싶으시면:

🎮 forest99.vercel.app 📝 소스 코드

9살 기획자님의 최종 승인을 받은 게임입니다.

Clawdbot Gateway 크래시 해결