책에 포함된 노트AI와 함께 만드는 Unity 6: 코드 한 줄 모르던 사람도 30일 안에 첫 게임을 출시하는 법

출시 이후의 성장 로드맵

2026-05-02Views 21약 10분생성형 AI 활용

게임을 출시한 순간, 많은 사람이 이렇게 생각한다. "드디어 끝났다." 하지만 개발자의 시간으로 보면 그때가 오히려 진짜 시작이다. 출시 전에는 내 머릿속 아이디어와 에디터 화면만 상대하면 됐다. 출시 후에는 완전히 다른 세계가 열린다. 실제 플레이어의 반응, 예상 밖의 버그, 생각보다 낮은 재방문율, 의외로 잘 먹히는 작은 재미가 한꺼번에 밀려온다. 이 파도를 겪고 나면 비로소 게임을 만드는 사람에서 게임을 키우는 사람으로 한 단계 올라서게 된다.

이번 장에서는 첫 출시 이후 무엇을 봐야 하고, 무엇을 배우고, 무엇을 스스로 책임져야 하는지 정리해 보겠다. 이 장을 다 읽고 나면 지금 당장 두 번째 게임을 만들지 않더라도, 적어도 다음 한 걸음을 잃지 않게 된다.

출시 이후의 성장 로드맵

첫 게임은 작품이면서 동시에 교과서다

첫 게임은 대개 완벽하지 않다. 오히려 완벽하지 않아서 가치가 크다. 플레이어가 어디에서 헤매는지, 내가 만든 설명이 얼마나 불친절했는지, 내가 재밌다고 믿었던 요소가 실제로는 얼마나 평범했는지를 아주 솔직하게 보여주기 때문이다.

출시 후 가장 먼저 해야 할 일은 자책이 아니라 관찰이다. 리뷰가 적더라도 괜찮다. 다운로드 수가 많지 않아도 괜찮다. 중요한 것은 작은 신호를 읽는 습관이다. 누군가가 "점프가 조금 뻑뻑해요"라고 말하면, 그것은 비난이 아니라 다음 공부의 방향표다. 누군가가 3분 만에 게임을 종료했다면, 그것은 내 게임의 첫 3분이 충분히 매력적이지 않다는 데이터다.

이때 마음가짐을 하나만 기억하자. 첫 게임의 목표는 대박이 아니라 해석 능력이다. 무엇이 먹히고, 무엇이 안 먹히고, 무엇을 고쳐야 하는지 읽어내는 힘이 쌓이면 두 번째 게임부터 속도가 달라진다.

돈은 따라오는 것이 아니라 설계하는 것이다

많은 초보 개발자가 수익 모델을 너무 늦게 고민한다. 하지만 수익은 출시 버튼을 누른 뒤 하늘에서 떨어지는 선물이 아니다. 게임 구조와 플레이 흐름 안에 미리 심어 둬야 하는 설계다. Unity와 업계의 최근 흐름도 화려한 신기능보다 안정성, 운영, 지속 가능한 개발에 더 무게를 두고 있다.¹²

첫 프로젝트에서 고민할 만한 수익 모델은 크게 네 가지다.

유료 판매형: 게임을 한 번 구매하면 끝나는 방식이다. 구조가 단순하고 플레이어 경험이 깔끔하다. 대신 첫인상이 약하면 구매 자체가 일어나지 않는다.
광고 기반형: 배너, 전면 광고, 보상형 광고로 수익을 얻는다. 캐주얼 모바일 게임과 잘 맞지만, 광고가 재미를 망치면 유지율이 바로 떨어진다.
인앱 결제형: 스킨, 추가 생명, 확장 콘텐츠, 편의 기능 등을 판매한다. 오래 즐길 이유가 있는 게임에 어울린다.
외부 수익 연결형: 게임 자체보다 포트폴리오, 의뢰, 강의, 템플릿 판매, 커뮤니티 유입으로 이어지는 방식이다. 첫 게임에서는 오히려 이쪽이 가장 현실적일 때가 많다.

여기서 중요한 질문은 "어떤 모델이 돈을 가장 많이 벌까?"가 아니다. "내 첫 게임의 크기와 플레이 패턴에 어떤 모델이 덜 무리일까?"다.

짧게 즐기는 2D 캐주얼 게임이라면 보상형 광고가 비교적 자연스럽다. 실패 후 이어하기, 추가 코인 받기, 스킨 뽑기 같은 장면에 넣기 쉽기 때문이다. 반대로 짧고 완결된 퍼즐이나 감성 어드벤처라면 저가 유료 판매가 더 어울릴 수 있다. 플레이어는 몰입을 돈으로 사는 셈이고, 개발자도 광고 위치를 억지로 만들 필요가 없다.

첫 프로젝트가 작고 업데이트 계획이 약하다면 인앱 결제는 욕심일 수 있다. 살 물건이 계속 생겨야 하고, 결제 설계와 밸런스 조절도 필요하기 때문이다. 반면 업데이트를 3개월 이상 이어갈 생각이 있고, 수집과 성장 요소가 있다면 인앱 결제는 그때부터 진지하게 검토할 수 있다.

결국 수익 모델은 "돈 버는 기술"이 아니라 "플레이어 경험을 해치지 않는 선택"이다. 처음에는 적게 벌어도 괜찮다. 중요한 것은 게임의 성격과 수익 방식이 서로 싸우지 않게 만드는 일이다.

첫 프로젝트에 맞는 선택 기준

처음 수익 모델을 고를 때는 아래 네 가지 질문만 던져도 방향이 선명해진다.

이 게임은 한 번 몰입해서 끝내는 게임인가, 여러 번 돌아오게 만드는 게임인가?
플레이어가 자발적으로 다시 켤 이유가 있는가?
업데이트를 꾸준히 할 체력이 있는가?
돈을 넣는 순간 재미가 깨지지 않는가?

이 질문에 답하면 대개 선택은 이렇게 정리된다.

게임 성격	잘 맞는 모델	조심할 점
짧고 선명한 완결형	유료 판매	첫 10초의 인상이 약하면 구매 전환이 낮다
짧지만 반복 플레이형	보상형 광고	광고 빈도가 높으면 바로 이탈한다
수집과 성장 중심	인앱 결제	콘텐츠 추가가 느리면 금방 고갈된다
포트폴리오용 첫 작품	외부 수익 연결형	게임 자체 수익만 보고 좌절하지 말 것

특히 첫 게임에서는 외부 수익 연결형을 과소평가하지 말자. 작은 게임 하나를 끝까지 만들고 출시했다는 사실은 강력한 증거다. 취업 포트폴리오, 외주 제안, 협업 제의, 유튜브 개발 로그, 에셋 판매, 튜토리얼 제작으로 이어질 수 있다. 첫 게임이 반드시 생활비를 벌어야 한다는 압박에서 벗어나면 오히려 더 현실적인 판단이 가능해진다.

잘 만든 게임은 출시 후에 더 좋아진다

출시 이후의 핵심은 거창한 리뉴얼이 아니라 개선 루프다. 이 루프는 복잡해 보이지만 사실 세 단계면 충분하다.

첫째, 듣는다. 리뷰, 댓글, 친구 피드백, 디스코드 반응을 모은다.
둘째, 본다. 어디서 죽는지, 어디서 나가는지, 어떤 버튼을 안 누르는지 확인한다.
셋째, 고친다. 가장 큰 문제 하나를 해결한 뒤 다시 확인한다.

이 순서를 계속 반복하면 게임은 천천히 좋아진다. 중요한 것은 한 번에 다 고치려 하지 않는 것이다. 첫 업데이트에서 버그 12개, UI 개편, 새 스테이지, 광고 조정, 성능 최적화를 모두 하겠다고 덤비면 금방 지친다. 대신 이렇게 생각하자.

이번 주에는 "게임 오버가 너무 갑작스러운 문제" 하나만 고친다.
다음 주에는 "튜토리얼이 길어서 이탈하는 문제" 하나만 고친다.

이렇게 문제를 하나씩 잡는 습관이 장기적으로 훨씬 강하다.

플레이어 피드백은 세 가지 얼굴로 온다

플레이어의 반응은 보통 세 가지 형태로 들어온다.

말로 오는 피드백: 리뷰, 댓글, 메시지, 메일
행동으로 오는 피드백: 특정 구간에서 포기, 재시작 반복, 보상 광고만 누름
숫자로 오는 피드백: 유지율, 완료율, 평균 플레이 시간, 충돌률

말은 친절하지만 부정확할 수 있다. 행동은 정직하지만 이유를 말해 주지 않는다. 숫자는 넓게 보여 주지만 맥락이 없다. 그래서 셋 중 하나만 믿으면 흔들린다. 세 가지를 같이 봐야 한다.

예를 들어 리뷰에는 "좀 지루해요"라고 적혀 있을 수 있다. 이 말만 보면 무엇을 고쳐야 할지 막막하다. 그런데 데이터를 보니 1분 30초 안에 절반이 이탈하고, 플레이 영상을 보니 처음 1분 동안 점프 외에 아무 변화가 없다면 답이 보인다. 지루한 게 아니라 처음 1분의 정보 밀도가 낮았던 것이다.

숫자를 무서워하지 않는 개발자가 오래 간다

데이터 분석이라고 하면 갑자기 어려워 보인다. 하지만 처음에는 거창한 대시보드가 필요 없다. 딱 다섯 가지만 봐도 충분하다.

튜토리얼 완료율: 시작한 사람 중 몇 명이 기본 조작을 끝까지 배웠는가
첫 10분 생존율: 초반 난이도가 너무 높거나 설명이 부족하지 않은가
재방문율: 다음 날 다시 오는 사람이 있는가
충돌률: 게임이 튕기거나 멈추는 문제가 얼마나 있는가
스토어 전환율: 스토어 페이지를 본 사람이 실제 설치로 이어지는가

여기서 가장 먼저 챙길 것은 대개 화려한 매출 지표가 아니라 충돌률과 초반 이탈률이다. 왜냐하면 아무리 좋은 게임도 튕기면 끝이고, 첫 5분이 심심하면 두 번째 기회가 오지 않기 때문이다.

첫 프로젝트에서는 이렇게 단순하게 생각하면 된다.
"사람들이 들어왔는가?" → "조작을 이해했는가?" → "첫 재미를 느꼈는가?" → "다시 돌아왔는가?"

이 네 단계 중 어디가 막히는지만 알아도 다음 업데이트 방향이 잡힌다.

다음 공부는 유행이 아니라 병목에서 고른다

출시를 마치고 나면 공부 욕심이 폭발한다. 셰이더도 해 보고 싶고, 네트워킹도 궁금하고, ECS도 멋져 보이고, XR도 신기하고, ML-Agents도 미래 같아 보인다. 문제는 이걸 한꺼번에 잡으면 거의 반드시 흐지부지된다는 점이다.

다음 공부는 "멋있어 보이는 기술"이 아니라 내가 자주 부딪히는 병목에서 골라야 한다. Unity의 공식 로드맵도 렌더링, 멀티플레이, UI, XR, 성능, AI 같은 축으로 기술 지형을 보여 준다.³ 이 지도를 따라가되, 내 현재 위치를 먼저 확인해야 한다.

셰이더를 먼저 배워야 하는 사람

게임의 재미는 괜찮은데 화면이 밋밋해서 손해 보는 경우가 있다. 2D 게임인데 물, 피격, 반짝임, 낮과 밤 변화 같은 시각 효과가 부족하다면 셰이더 공부의 효율이 높다. 셰이더는 처음 보면 겁나지만, 입문자는 코드부터 파지 않아도 된다. Shader Graph처럼 노드 기반 도구로 "어떤 입력이 들어오면 화면이 어떻게 바뀌는가"만 이해해도 큰 차이가 난다.

셰이더를 먼저 배우면 좋은 사람은 이런 경우다. 게임 플레이보다 표현력이 아쉬운 사람, 작은 연출로 완성도를 끌어올리고 싶은 사람, 2D와 3D 모두에서 시각 차별화를 만들고 싶은 사람이다.

네트워킹을 배워야 하는 사람

혼자 만드는 게임도 언젠가 멀티플레이 욕심이 생긴다. 하지만 네트워킹은 단순히 "두 명이 같이 움직인다"에서 끝나지 않는다. 동기화, 지연 시간, 상태 불일치, 매치메이킹, 서버 비용까지 따라온다.

그래서 네트워킹은 게임의 중심 재미가 사람과 사람의 상호작용일 때만 우선순위를 높이는 것이 좋다. 숨바꼭질, 협동 생존, 대전 퍼즐, 실시간 레이싱처럼 멀티가 게임의 정체성이라면 빠르게 들어가야 한다. 반대로 싱글 플레이의 손맛을 먼저 다듬어야 하는 단계라면, 멀티는 너무 이른 확장일 수 있다.

ECS를 배워야 하는 사람

ECS는 처음엔 추상적으로 들린다. 쉽게 말해, 많은 오브젝트를 더 체계적이고 효율적으로 다루기 위한 데이터 중심 방식이다. 적이 수백 마리 나오고, 탄막이 화면을 메우고, 시뮬레이션 대상이 엄청 많아질수록 매력이 커진다. Unity도 ECS를 엔진의 더 중심적인 축으로 가져오려는 방향을 꾸준히 보여 주고 있다.¹

하지만 첫 번째나 두 번째 작은 게임을 만드는 단계에서는 ECS가 너무 앞선 공부일 수 있다. 아직 MonoBehaviour 구조도 충분히 다루지 못했다면, ECS는 "해결해야 할 문제"보다 "새로 생긴 공부거리"가 되기 쉽다. 즉, 성능이 실제로 병목일 때 들어가면 된다.

XR을 배워야 하는 사람

XR은 VR, AR, 혼합현실을 포함하는 넓은 분야다. Unity는 XR 플랫폼 지원과 입력, 월드 스페이스 UI 등 관련 축을 계속 강화하고 있다.³ 다만 XR은 카메라, 입력, 인터페이스, 멀미 방지, 성능 기준이 일반 게임과 꽤 다르다.

그래서 XR은 기술 호기심만으로 들어가기보다, 정말 만들고 싶은 경험이 있을 때 강하다. 예를 들어 "모바일 3D 퍼즐"보다 "손으로 직접 만지는 공간 퍼즐"이 핵심이라면 XR을 배울 이유가 분명하다. 반대로 기존 게임을 억지로 VR로 옮기는 발상은 대개 고생만 많다.

ML-Agents를 배워야 하는 사람

ML-Agents는 적이 스스로 학습하게 만들거나, 복잡한 행동을 강화학습 방식으로 실험할 때 빛난다. 다만 많은 입문자가 여기서 착각한다. "적 AI가 필요하니 ML-Agents를 써야겠다"는 생각이다. 사실 대부분의 첫 게임 적은 상태 머신, 간단한 규칙, 경로 이동만으로도 충분하다.

ML-Agents는 행동 규칙을 사람이 직접 짜기 어렵거나, 학습 실험 자체가 목표일 때 배우는 것이 좋다. 즉, 똑똑해 보이기 위해 쓰는 기술이 아니라 실험 가치가 있을 때 쓰는 기술이다.

지금 내게 맞는 다음 공부를 고르는 간단한 지도

아래 기준으로 고르면 훨씬 덜 헤맨다.

내가 자주 겪는 문제	먼저 볼 주제
게임은 재밌는데 화면이 심심하다	셰이더, 라이팅, VFX
사람과 함께할 때 재미가 완성된다	네트워킹
오브젝트가 많아지면 성능이 무너진다	ECS, 프로파일링
공간 경험 자체가 핵심이다	XR
규칙 기반 적 AI가 금방 한계에 닿는다	ML-Agents

이 표의 요점은 단순하다. 공부 주제는 내 게임이 요구하는 순서대로 고른다. 멋져 보여서 고르면 오래 못 간다. 내 문제를 해결해 주기 때문에 고르면 끝까지 간다.

AI 시대일수록 사람이 직접 책임져야 하는 것

이 책의 처음부터 끝까지 우리는 AI를 학습 동반자로 사용했다. 막힐 때 질문하고, 초안을 만들고, 설명을 다시 듣고, 코드 방향을 잡는 데 AI는 정말 강력하다. 하지만 출시 이후에는 더 분명해지는 사실이 있다. AI가 많이 도와줄수록, 최종 책임은 더 선명하게 사람에게 돌아온다.

특히 네 가지는 절대 넘기면 안 된다.

기획 책임: 왜 이 기능이 필요한지, 어떤 감정을 주고 싶은지 결정하는 일
검수 책임: 생성된 코드와 에셋이 실제로 맞는지, 버그와 부작용은 없는지 확인하는 일
저작권 책임: 사용한 에셋, 사운드, 모델, 텍스트의 출처와 사용 권한을 점검하는 일
출시 책임: 개인정보, 플랫폼 정책, 연령 등급, 결제 유도 방식, 표현 수위까지 최종 판단하는 일

이 원칙은 점점 더 중요해지고 있다. Unity가 준비 중인 에디터 내 AI 에이전트도 코드 변경은 사람이 직접 승인하는 방식으로 설계되고 있다.⁴ 다시 말해, 도구가 아무리 똑똑해져도 "마지막 도장"은 여전히 개발자의 몫이다.

AI가 생성한 코드가 돌아간다는 사실과, 그 코드가 내 게임에 맞는 코드라는 사실은 다르다. AI가 만든 그림이 예쁘다는 사실과, 그 그림을 상업적으로 써도 안전한지는 또 다른 문제다. 그래서 앞으로 실력이란 단순 암기보다 질문하는 힘, 고르는 힘, 거절하는 힘에 가까워진다.

AI에게 일을 맡기기 전에 확인할 것

AI를 더 잘 쓰려면 오히려 더 엄격해야 한다. 적어도 아래 세 가지는 습관처럼 체크하자.

이 결과물이 내 게임의 목표와 정말 맞는가
내가 직접 설명할 수 있을 만큼 이해했는가
출처와 사용 조건을 추적할 수 있는가

이 세 질문에 답하지 못하면, 아직 가져다 쓰면 안 된다.

공식 문서를 읽는 사람이 결국 멀리 간다

책을 덮은 뒤 가장 중요한 습관은 공식 문서를 무서워하지 않는 것이다. 처음에는 영어가 부담스럽고, 용어가 딱딱하고, 예제가 낯설다. 그런데 놀랍게도 문서를 읽는 힘은 어느 순간 게임 개발 전체의 속도를 바꾼다.

문서를 잘 읽는 사람은 검색 결과에 휘둘리지 않는다. 오래된 블로그 글과 최신 Unity 6 정보가 뒤섞여 있어도 덜 흔들린다. 지금 엔진이 어떤 방향으로 가는지도 더 잘 보인다. Unity의 로드맵을 보는 습관만 가져도 "지금 파고드는 기술이 앞으로도 커질 분야인지" 감이 생긴다.³

문서를 읽을 때는 이렇게 해 보자.

먼저 공식 문서나 공식 로드맵에서 한 페이지를 고른다.
모르는 문장을 AI에게 "초등학생에게 설명하듯 풀어 달라"고 요청한다.
다시 원문으로 돌아와 용어를 체크한다.
아주 작은 샘플 프로젝트에서 직접 확인한다.
마지막으로 한 줄 메모를 남긴다.

이 다섯 단계를 반복하면 문서 읽기는 더 이상 고문이 아니다. 오히려 새로운 기능을 남보다 빨리 내 것으로 만드는 가장 안정적인 루트가 된다.

AI에게 묻자
"Unity 공식 문서의 아래 문단을 초보자 눈높이로 다시 설명해 줘. 핵심 용어 3개를 뽑고, 각 용어를 게임 예시와 함께 풀어 줘. 마지막에는 내가 지금 당장 에디터에서 확인할 수 있는 체크 포인트 3개를 적어 줘."

이 프롬프트의 좋은 점은 단순 번역이 아니라 이해 → 용어 정리 → 실습 연결까지 한 번에 묶어 준다는 데 있다.

출시 후 30일, 이렇게 움직이면 된다

첫 게임을 출시한 뒤 멍하니 다음 아이디어만 찾지 말고, 다음 30일을 이렇게 써 보자.

1주차: 정리한다

출시 직후에는 감정이 크다. 신난다, 부끄럽다, 아쉽다, 들뜬다. 이 상태에서 바로 큰 판단을 하면 흔들리기 쉽다. 1주차에는 사실만 모으자. 다운로드 수, 리뷰, 충돌 여부, 초반 이탈 구간, 가장 많이 칭찬받은 요소를 적는다.

2주차: 한 번 고친다

가장 큰 문제 하나만 잡아 패치한다. 조작감, 튜토리얼, UI 가독성, 사운드 밸런스 중 무엇이든 좋다. 핵심은 "많이"가 아니라 "정확히" 고치는 것이다.

3주차: 한 번 더 보여 준다

업데이트 후 다시 공유한다. 친구, 커뮤니티, 디스코드, 스레드, 유튜브 쇼츠 어디든 좋다. 중요한 것은 개선 사실을 알리고, 반응을 다시 받는 것이다. 개발자는 숨어서 실력 느는 직업이 아니다. 보여 주고, 듣고, 고치는 직업이다.

4주차: 다음 공부 하나를 고른다

이제야 다음 기술 주제를 선택한다. 게임이 밋밋했으면 셰이더, 멀티 재미가 필요했으면 네트워킹, 성능이 무너졌으면 ECS, 공간 경험이 중요하면 XR, 행동 실험이 목표면 ML-Agents를 고른다. 이렇게 해야 공부가 공중에 뜨지 않는다.

AI에게 묻자
"내가 출시한 게임의 정보를 줄게. 장르, 플레이 시간, 플랫폼, 플레이어 반응, 가장 큰 문제 3개를 바탕으로 다음 30일 학습 계획을 짜 줘. 단, 하루 1시간 기준으로 현실적으로 구성하고, 지금은 하지 않아도 되는 공부도 함께 적어 줘."

이 프롬프트는 특히 좋다. AI가 계획을 '늘리는' 대신 '덜어내게' 만들기 때문이다. 초보자는 대개 뭘 더 해야 할지보다, 뭘 지금 안 해도 되는지 정해 줄 때 훨씬 빨리 전진한다.

오래 가는 개발자는 성장 속도를 관리한다

개발은 스프린트 같지만, 실제로는 마라톤에 가깝다. 첫 게임을 낸 직후에는 두 가지 위험이 동시에 온다. 하나는 "나는 이제 뭐든 할 수 있다"는 과열이다. 다른 하나는 "이 정도 반응이면 나는 재능이 없나 보다"라는 냉각이다. 둘 다 오래 못 간다.

오래 가는 개발자는 성장 속도를 관리한다. 한 번에 거대한 세계관과 멀티플레이와 오픈월드와 생성형 AI를 다 넣으려 하지 않는다. 대신 한 작품마다 하나씩 분명한 학습 목표를 둔다. 예를 들어 두 번째 게임의 목표가 "더 좋은 조작감"이면 거기에 집중한다. 세 번째는 "가독성 좋은 UI", 네 번째는 "작은 라이브 운영", 다섯 번째는 "셰이더와 연출"처럼 쌓아 간다.

이 방식의 장점은 분명하다. 실패해도 무엇을 배웠는지 남고, 성공해도 왜 성공했는지 설명할 수 있다. 결국 실력은 결과물 개수보다 학습 단위가 쪼개져 있는가로 더 크게 갈린다.

이제 당신은 초보가 아니라 출시해 본 사람이다

이 책의 목표는 Unity 기능을 전부 가르치는 것이 아니었다. 더 중요한 목표는 혼자서도 다음 공부를 이어 갈 수 있는 사람으로 바꾸는 것이었다. 첫 게임을 출시했다면 이미 큰 벽 하나를 넘은 것이다. 메뉴를 아는 사람, 코드를 조금 읽는 사람, AI에게 질문할 수 있는 사람, 빌드를 해 본 사람, 그리고 무엇보다 끝까지 완주한 사람은 출발선에 선 초보와 다르다.

앞으로도 막히는 날은 계속 온다. 버그는 또 생길 것이고, 새 기능은 또 나오고, AI는 때로 엄청 유용했다가 때로 엉뚱한 답을 줄 것이다. 그래도 방향만 잃지 않으면 괜찮다. 출시 이후의 성장 로드맵은 생각보다 단순하다.

더 잘 팔리는 게임을 만들기 전에, 더 잘 고치는 개발자가 된다.
더 어려운 기술을 배우기 전에, 더 정확히 선택하는 사람이 된다.
더 많은 AI를 쓰기 전에, 더 분명히 책임지는 개발자가 된다.

그러면 다음 게임은 훨씬 덜 막히고, 훨씬 덜 무섭고, 훨씬 더 멀리 간다.