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

Unity 6의 그래픽과 AI 기능 깊게 쓰기

2026-05-02Views 81약 11분생성형 AI 활용

3D 공간을 한 번 직접 걸어 보았다면, 이제 다음 질문이 생깁니다. "그래서 요즘 Unity는 뭘 써야 하나요?" 이 질문은 생각보다 중요합니다. 입문자가 구버전 튜토리얼을 따라가다 길을 잃는 가장 큰 이유가 바로 여기 있기 때문입니다. 메뉴 이름이 다르고, 추천 파이프라인이 다르고, 성능을 끌어올리는 방식도 달라졌기 때문입니다.

이번 장은 화려한 기술 자랑을 하려는 장이 아닙니다. 오히려 반대입니다. 어떤 기능이 실제로 내 시간을 아껴 주는지, 무엇을 먼저 켜고 무엇은 나중에 만져야 하는지, AI를 어디에 써야 공부가 빨라지고 어디까지는 내가 직접 판단해야 하는지를 분명하게 잡는 장입니다. 이 기준만 서면, 인터넷에 떠도는 수많은 튜토리얼 앞에서도 덜 흔들리게 됩니다.

Unity 6의 그래픽과 AI 기능 깊게 쓰기

왜 입문자는 URP로 시작하는가

Unity를 처음 열면 렌더 파이프라인부터 살짝 겁이 납니다. Built-in, URP, HDRP. 이름만 보면 셋 다 비슷해 보이지만, 실제로는 시작점이 다릅니다.

요즘의 기본 선택은 대부분 URP라고 생각해도 크게 틀리지 않습니다. Unity가 최근 그래픽 개선의 중심축을 URP에 두고 있고, 멀티플랫폼 대응과 학습 자료의 흐름도 여기에 더 많이 모여 있기 때문입니다.¹ 쉽게 말해, 처음 게임을 만드는 사람에게 URP는 "너무 가볍지도, 너무 무겁지도 않은 운동화"에 가깝습니다. 모바일, PC, 웹까지 넓게 바라보기 좋고, Shader Graph나 최신 최적화 기능과도 궁합이 좋습니다.

반대로 HDRP는 아주 멋진 화면을 만들 수 있지만, 처음 배우는 사람에게는 조금 비싼 카메라 같습니다. 기능은 많고 결과도 강력하지만, 그만큼 이해할 것이 늘어납니다. PC나 콘솔 중심의 하이엔드 비주얼, 시네마틱, 리얼한 조명 실험이 목표라면 훌륭한 선택이지만, "30일 안에 첫 게임 출시"라는 이 책의 목표와는 살짝 결이 다릅니다.

Built-in Render Pipeline은 오래된 자료가 많아서 언뜻 편해 보이기도 합니다. 하지만 바로 그 점이 함정입니다. 검색하면 예전 튜토리얼은 끝없이 나오는데, 막상 따라 하다 보면 지금의 Unity 6 화면과 다르고, 최신 기능과 연결도 잘 되지 않습니다. 그래서 새 프로젝트라면 굳이 옛 길로 돌아갈 이유가 많지 않습니다.

처음 선택할 때는 이렇게 생각하면 쉽습니다.

출시 목표가 모바일, PC, 웹까지 열려 있다면 URP
초고사양 비주얼과 시네마틱이 최우선이라면 HDRP
아주 오래된 프로젝트를 유지 보수하는 상황이 아니라면 새 시작은 URP

이 선택이 중요한 이유는 단순히 화면이 달라져서가 아닙니다. 머티리얼, 셰이더, 성능 최적화 방식, 참고할 샘플 프로젝트까지 한꺼번에 달라지기 때문입니다. 렌더 파이프라인은 벽지 색이 아니라 집의 배관에 더 가깝습니다. 초반에 정하면 그다음이 편해집니다.

Unity 6에서 먼저 체감할 그래픽 기능 세 가지

Unity 6의 그래픽 기능은 이름이 조금 어려워 보입니다. 하지만 입문자 입장에서는 원리를 모두 외울 필요가 없습니다. 먼저 무엇이 체감되는지를 잡으면 됩니다. 이번 장에서는 세 가지만 확실히 기억하면 충분합니다. 빛을 더 자연스럽게 만드는 것, CPU가 숨 좀 돌리게 해 주는 것, 낮은 해상도로 그려도 보기 좋게 보정하는 것입니다.¹

Adaptive Probe Volumes: 빛을 손으로 덜 놓게 해 주는 기능

예전에는 씬 안에 빛의 분위기를 잘 퍼뜨리려면 라이트 프로브를 꽤 손으로 챙겨야 했습니다. 어디는 너무 어둡고, 어디는 캐릭터가 붕 뜬 것처럼 보이고, 실내와 실외 경계는 부자연스럽기 쉬웠지요. Adaptive Probe Volumes, 줄여서 APV는 이 과정을 더 자동화하고, 장면 구조에 따라 프로브 밀도를 다르게 다루는 데 도움을 줍니다.¹

입문자가 체감하는 장점은 아주 현실적입니다. 캐릭터가 실내로 들어갔을 때 갑자기 색이 뜨거나, 그림자 분위기가 어색하게 끊기는 일이 줄어듭니다. 특히 Unity 6의 최근 URP 흐름에서는 APV 개선 사항이 계속 반영되고 있어, 라이트 프로브를 처음부터 전부 손으로 배치하던 시절보다 진입 장벽이 낮아졌습니다.¹

다만 APV를 "버튼 하나로 영화 같은 조명 완성"으로 이해하면 곤란합니다. APV는 조명을 대신 생각해 주는 기능이 아니라, 조명 작업을 덜 고생스럽게 만들어 주는 기능에 가깝습니다. 태양 방향이 엉망이고, 주요 라이트 배치가 어색하면 APV도 그 어색함을 멋지게 숨겨 주지는 못합니다.

실무 감각으로 말하면 이렇습니다. 작은 프로젝트에서 APV는 빛을 예쁘게 만들기 위한 마지막 화장품이 아니라, 빛이 어색하게 무너지는 걸 막아 주는 좋은 바탕 작업입니다.

GPU Resident Drawer: CPU에게 일을 덜 시키는 기능

게임이 버벅일 때 초보자는 보통 이렇게 생각합니다. "그래픽이 무거워서 GPU가 힘든가 보다." 맞을 때도 있지만, 의외로 CPU가 그리기 명령을 너무 많이 처리하느라 지친 상황도 많습니다. 특히 나무, 바위, 풀, 울타리처럼 비슷한 오브젝트가 한 장면에 많이 반복되면 더 그렇습니다.

GPU Resident Drawer는 이런 상황에서 도움이 됩니다. Unity 공식 설명대로, 이 시스템은 BatchRendererGroup API와 GPU 인스턴싱을 활용해 draw call 수를 줄이고 CPU 부담을 덜어 주는 방향으로 동작합니다.¹² 쉽게 말해, 화면에 비슷한 물건이 잔뜩 있을 때 "이걸 하나하나 CPU가 챙기지 말고, 가능한 한 GPU 쪽으로 넘기자"에 가깝습니다.

숲길, 마을, 창고, 반복 배치된 소품이 많은 맵에서 특히 체감이 큽니다. 장면을 꾸밀수록 프레임이 푹푹 꺼지는 프로젝트라면, 무턱대고 오브젝트를 지우기 전에 이런 현대적인 렌더링 기능을 확인해 볼 가치가 있습니다.

하지만 여기서도 마법처럼 생각하면 안 됩니다. GPU Resident Drawer를 켰다고 해서 엉망인 씬 구조가 갑자기 훌륭해지지는 않습니다. 머티리얼이 제각각이고, 불필요한 실시간 그림자가 많고, 후처리가 과하면 여전히 느립니다. 이 기능은 지저분한 집을 대신 치워 주는 로봇 청소기가 아니라, 정리된 집을 더 빨리 관리하게 해 주는 좋은 도구입니다.

STP: 낮은 해상도로 그리고, 보기 좋게 끌어올리는 기능

입문자가 성능 최적화를 처음 하면 흔히 두 가지 극단으로 갑니다. 하나는 모든 걸 최고 품질로 켜고 프레임이 무너지는 길이고, 다른 하나는 해상도와 효과를 너무 많이 내려서 게임이 흐릿하고 초라해지는 길입니다.

STP(Spatial Temporal Post-Processing)는 그 중간을 노립니다. Unity 공식 문서 기준으로 STP는 낮은 해상도로 렌더링한 프레임을 업스케일해 GPU 성능을 아끼면서도 시각 품질을 높이는 기능입니다.¹ 말하자면 "덜 힘들게 그렸는데도 꽤 괜찮아 보이게 만드는 보정 기술"입니다.

이 기능이 특히 반가운 곳은 모바일, 휴대용 기기처럼 성능과 발열이 민감한 환경입니다. 하지만 꼭 저사양에서만 의미가 있는 건 아닙니다. PC에서도 프레임 안정성을 챙기고 싶을 때 유용합니다. 중요한 건 STP를 "최적화를 안 해도 되는 면죄부"로 쓰지 않는 것입니다. STP는 나쁜 습관을 덮는 담요가 아니라, 이미 기본기가 잡힌 프로젝트를 더 부드럽게 만드는 보조 장치에 가깝습니다.

기능을 켜는 순서가 결과를 바꾼다

같은 기능도 언제 켜느냐에 따라 체감이 달라집니다. 초보자는 종종 프로젝트 초반부터 모든 최신 기능을 한꺼번에 켜고, 뭐가 좋아졌는지 나빠졌는지 모른 채 헤맵니다. 그보다는 순서를 정하는 편이 훨씬 좋습니다.

Shader Graph로 머티리얼을 처음 꾸미는 경험

코드를 한 줄도 모르던 사람에게 셰이더는 대개 벽처럼 느껴집니다. 이름부터 어렵고, 수학이 잔뜩 숨어 있을 것 같고, 괜히 건드렸다가 화면이 분홍색으로 터질 것 같습니다. 다행히 Unity 6에서는 Shader Graph 덕분에 셰이더를 노드 기반으로 훨씬 직관적으로 만질 수 있습니다. 입문자에게 이것은 꽤 큰 사건입니다. "그래픽은 아티스트나 고수만 만지는 것"이라는 생각이 처음 깨지기 때문입니다.

첫 경험으로는 거대한 물 셰이더나 복잡한 홀로그램보다, 상호작용 가능한 오브젝트를 살짝 돋보이게 만드는 머티리얼이 좋습니다. 예를 들어 보물상자, 문 손잡이, 중요한 버튼, 회복 아이템 같은 물체를 약하게 빛나게 해 보세요. 그 순간 플레이어의 시선 유도와 그래픽 감각을 동시에 배우게 됩니다.

가장 쉬운 예시는 Fresnel 기반 강조 머티리얼입니다. 오브젝트 가장자리에 은은한 빛을 더해서 "이 물건은 만질 수 있어요"라는 느낌을 주는 방식입니다.

작업 흐름은 단순합니다.

Create > Shader Graph > URP > Lit Shader Graph로 새 그래프를 만듭니다.
Base Color용 색상 프로퍼티 하나와 Glow Color용 HDR 색상 프로퍼티를 만듭니다.
Fresnel Effect 노드를 추가합니다.
Fresnel 값을 Glow Color와 곱합니다.
결과를 Emission에 연결하고, 기본 색은 Base Color에 연결합니다.

이렇게만 해도 오브젝트 가장자리가 살짝 빛나며 존재감이 생깁니다. 숫자를 조금 바꾸면 분위기가 완전히 달라집니다. Fresnel 세기를 키우면 SF 장치처럼 보이고, Glow 색을 따뜻한 노란색으로 바꾸면 판타지 보물처럼 보입니다.

여기서 중요한 건 "내가 셰이더를 완벽히 이해했다"가 아닙니다. 그래픽도 작은 조합으로 충분히 다룰 수 있다는 감각을 얻는 것입니다. 그 감각이 생기면, 다음에는 스크롤하는 에너지 라인, 체력 낮을 때 붉게 번지는 효과, 물체에 닿으면 색이 바뀌는 반응형 머티리얼까지 자연스럽게 이어집니다.

AI에게 묻자
"Shader Graph를 처음 쓰는 입문자다. 내가 만들고 싶은 것은 '중요한 상자만 가장자리가 은은하게 빛나는 효과'다. Fresnel, Emission, Color 프로퍼티만 써서 만들 수 있게 노드 연결 순서를 쉬운 말로 설명해 줘. 각 노드가 왜 필요한지도 한 줄씩 덧붙여 줘."

이 프롬프트의 좋은 점은 결과를 대신 만들게 하는 게 아니라, 노드의 역할을 이해하게 만든다는 데 있습니다.

Assistant와 Generators는 같은 AI가 아니다

이제 AI 이야기로 넘어가 보겠습니다. Unity 안의 AI 기능을 처음 보면 전부 비슷해 보일 수 있습니다. 하지만 실제로는 쓰임새가 꽤 다릅니다. Assistant는 묻고 고치고 설명받는 쪽, Generators는 만들어 보는 쪽, Inference Engine 계열은 게임 안에서 모델을 실행하는 쪽으로 생각하면 훨씬 덜 헷갈립니다.³⁴

Unity AI는 대체로 최근 Unity 6 계열 에디터와 Unity Cloud 프로젝트 연결, 조직 설정 같은 조건이 맞아야 제대로 보입니다.³⁴ 즉, 버튼 하나만 누르면 끝나는 마법 버튼이라기보다, 프로젝트 환경을 갖춘 뒤 들어오는 도구 상자에 가깝습니다.

Assistant: 학습용과 문제 해결용

Assistant의 가장 큰 장점은 프로젝트 맥락을 가진 설명자라는 점입니다. 단순한 일반 챗봇이 아니라, 에디터 안에서 프로젝트와 연결된 질문을 받고 답합니다. 공식 소개에서도 Assistant는 프로젝트 관련 질문에 답하고, 코드를 생성하며, 파일 이름 변경이나 씬 안 오브젝트 배치 같은 작업을 수행하는 도구로 설명됩니다.³⁴

입문자에게 Assistant가 특히 좋은 순간은 이런 때입니다.

Inspector의 옵션 이름은 보이는데 무슨 뜻인지 모르겠을 때
콘솔 에러는 떴는데 내가 무엇을 잘못했는지 감이 없을 때
프로파일러 숫자를 봐도 어디가 병목인지 해석이 안 될 때
긴 코드를 주석과 함께 설명받고 싶을 때

Assistant는 학습용 돋보기로 쓸 때 가장 강합니다. 처음부터 게임 전체를 맡기기보다, 내가 지금 보고 있는 기능 하나를 더 빨리 이해하게 하는 용도로 쓰면 만족도가 높습니다.

Generators: 프로토타입과 빈칸 메우기용

Generators는 텍스트 프롬프트나 참고 입력을 바탕으로 스프라이트, 텍스처, 사운드, 머티리얼, 애니메이션, 터레인 레이어 같은 자산을 생성하는 계열입니다.³⁴ 여기서 핵심은 "완성 아트를 전부 대신한다"가 아니라, 빈칸을 빠르게 채운다는 데 있습니다.

예를 들어 아직 디자이너가 없는데 게임 규칙을 빨리 테스트해야 한다면, 적 아이콘, 임시 배경, 버튼용 질감, 간단한 효과음을 빠르게 만들어 흐름을 확인할 수 있습니다. 이건 엄청난 장점입니다. 입문자는 종종 아트가 없어서 멈추는데, Generators는 그 멈춤을 줄여 줍니다.

하지만 여기에도 선이 있습니다. 생성된 결과는 프로젝트의 세계관, 해상도, 톤앤매너와 자주 어긋납니다. 그래서 Generators는 최종 그림을 결정하는 도구라기보다, 게임이 굴러가게 만드는 임시 다리로 생각하는 편이 안전합니다.

반복 작업에는 Assistant를, 스타일 탐색에는 Generators를

두 도구를 가장 실무적으로 나누는 방법은 이것입니다.

상황	더 잘 맞는 도구	이유
기능 설명이 필요하다	Assistant	프로젝트 맥락을 바탕으로 설명하고 제안한다
에러 원인을 좁히고 싶다	Assistant	코드, 설정, 워크플로를 함께 보며 질문하기 좋다
씬 배치를 자동화하고 싶다	Assistant	배치 규칙과 폴더 정리를 지시하기 좋다
임시 텍스처나 아이콘이 급하다	Generators	빈 아트 자리를 빠르게 채운다
여러 비주얼 스타일을 빠르게 비교하고 싶다	Generators	같은 기능을 다른 모양으로 반복 실험하기 쉽다
반복 이름 변경이나 정리 작업이 귀찮다	Assistant	규칙 기반 지시가 잘 먹힌다

정리하면 이렇습니다. Assistant는 생각을 정리하고 막힌 곳을 뚫는 도구, Generators는 눈앞의 빈칸을 채워 프로토타입 속도를 올리는 도구입니다.

AI를 잘 쓰는 사람은 질문을 작게 자른다

AI를 잘 못 쓰는 가장 흔한 방식은 이런 것입니다. "내 게임 다 만들어 줘." 이건 부탁이라기보다 투척에 가깝습니다. 반대로 잘 되는 방식은 질문을 작게 자르는 것입니다.

예를 들어 이렇게 나누면 훨씬 좋습니다.

"URP 프로젝트에서 APV를 적용하기 전에 내가 먼저 확인할 조명 설정 5가지만 알려 줘."
"현재 이 머티리얼이 왜 플라스틱처럼 보이는지 추측 가능한 원인을 세 가지로 좁혀 줘."
"이 C# 스크립트가 매 프레임 할당을 만들 가능성이 있는 부분만 찾아 쉬운 말로 설명해 줘."
"2D UI 버튼용 임시 텍스처를 만들 건데, 귀엽고 과하지 않은 카툰 스타일 프롬프트를 3개만 추천해 줘."

좋은 질문은 보통 세 가지를 갖고 있습니다. 맥락, 목표, 제한 조건입니다. 이 셋이 들어가면 AI의 답도 훨씬 쓸모 있어집니다.

Inference Engine과 ONNX: 이름이 많아 보여도 겁먹지 말자

이제 가장 어렵게 보이는 주제로 가 보겠습니다. Inference Engine입니다. 이름부터 벌써 전문가 회의실 냄새가 납니다. 그런데 핵심은 생각보다 단순합니다. 이미 학습된 AI 모델을 내 게임 안에서 실행하는 기술입니다.⁵

예전 자료를 찾다 보면 Sentis라는 이름도 자주 보입니다. 실제로 Unity AI 소개 페이지에서는 아직 Sentis라는 이름을 쓰는 문서도 있고, 패키지와 최신 문서에서는 Inference Engine이라는 이름을 쓰는 경우도 있습니다.³⁵ 초보자 입장에서는 세부 브랜딩보다 "Unity 안에서 ONNX 같은 모델을 가져와 실행하는 런타임 추론 계열 도구"라고 이해하면 충분합니다.

ONNX는 무엇인가

ONNX는 다양한 머신러닝 프레임워크에서 만든 모델을 옮겨 다니기 쉽게 해 주는 표준 형식입니다. 쉽게 말해 AI 모델의 공용 포장 상자쯤 됩니다. PyTorch나 다른 도구에서 학습한 모델을 .onnx 파일로 내보내고, Unity 쪽에서 그 모델을 가져와 실행하는 흐름을 많이 씁니다. Unity의 추론 시스템은 ONNX 모델 다수를 지원하며, CPU나 GPU 같은 기기 자원으로 실시간 실행할 수 있도록 설계되어 있습니다.⁵

초보자에게 중요한 점은 "내가 직접 모델을 학습해야만 AI를 넣을 수 있다"가 아니라는 사실입니다. 이미 공개된 분류 모델, 감지 모델, 음성 인식 모델, 키워드 인식 모델을 가져와 활용할 수 있습니다. 즉, AI를 쓰기 위해 꼭 박사 과정에 들어갈 필요는 없습니다.

추론이란 무엇인가

학습과 추론을 구분하면 훨씬 쉬워집니다.

학습: 모델을 가르치는 과정
추론: 이미 배운 모델에게 새 입력을 넣고 답을 받는 과정

게임에서 우리가 자주 쓰는 건 대부분 추론입니다. 예를 들어 플레이어의 음성을 듣고 "점프"인지 아닌지 판별하거나, 카메라 이미지에서 특정 물체를 감지하거나, 손글씨 숫자를 읽는 일들이 여기에 속합니다.

즉, Unity 안에서 Inference Engine을 쓴다는 말은 대개 게임 실행 중에 모델에게 질문하고 답을 받는다는 뜻입니다.

꼭 알아야 할 네 가지 단어

이 분야는 용어가 낯설어서 어렵게 느껴집니다. 하지만 네 단어만 익히면 길이 보입니다.

Model: 이미 학습된 뇌
Input: 모델에게 넣는 데이터
Tensor: 입력과 출력을 담는 다차원 배열 상자
Backend: CPU로 돌릴지 GPU로 돌릴지 선택하는 실행 방식

처음엔 텐서라는 말이 무섭게 느껴져도, 사실은 "모델이 먹는 데이터 통" 정도로 이해해도 시작에는 충분합니다. 이미지 한 장도 텐서로 바뀌고, 오디오 조각도 텐서로 바뀌고, 모델의 결과도 텐서로 나옵니다.

온디바이스 실행이 왜 좋은가

Unity의 추론 시스템이 반가운 이유는 클라우드 서버를 거치지 않고, 사용자 기기에서 직접 모델을 돌릴 수 있다는 점입니다.⁵ 이걸 온디바이스 실행이라고 부릅니다.

온디바이스의 장점은 아주 현실적입니다.

반응이 빠르다. 서버 왕복 시간이 없어 입력과 결과 사이가 짧습니다.
오프라인에서도 동작할 수 있다. 네트워크가 약해도 기능이 남습니다.
서버 비용이 줄어든다. 작은 프로젝트에 특히 중요합니다.
민감한 입력을 기기 안에서 처리하기 쉽다. 모든 데이터를 외부로 보내지 않아도 됩니다.

예를 들어 음성 명령으로 손전등을 켜는 기능을 만든다고 해 봅시다. 이때 매번 서버에 오디오를 보내고 답을 기다리면 작은 기능이 갑자기 무거운 서비스가 됩니다. 반면 기기 안에서 바로 처리하면 훨씬 게임답게 느껴집니다.

물론 단점도 있습니다. 기기 성능의 한계를 그대로 받기 때문에, 모델이 너무 크거나 연산이 복잡하면 모바일에서 버거울 수 있습니다. 또한 모든 ONNX 모델이 아무 수정 없이 바로 잘 돌아가는 것도 아닙니다. 공식 문서에서도 지원되는 모델 형식과 연산자 범위를 확인할 필요가 있다고 안내합니다.⁵

그래서 입문자에게 추천하는 첫 목표는 거대한 생성형 모델이 아니라, 작고 분명한 입력-출력 관계를 가진 모델입니다. 예를 들면 다음과 같습니다.

키워드 음성 인식
간단한 이미지 분류
손글씨 숫자 판별
작은 오브젝트 감지

이런 작업은 성공 경험을 주기 좋고, 게임 안에서 역할도 분명합니다.

ONNX 모델을 붙일 때 초보자가 꼭 체크할 것

실무 감각으로 보면, ONNX를 붙이는 일은 "파일 넣고 끝"이 아닙니다. 초보자는 특히 아래 다섯 가지를 꼭 확인해야 합니다.

입력 형식이 무엇인가
모델이 이미지 크기 224x224를 기대하는지, 흑백인지 컬러인지, 오디오 길이를 얼마나 요구하는지 먼저 알아야 합니다.
출력 형식이 무엇을 뜻하는가
숫자 배열이 나오는데, 그중 어느 값이 정답 확률인지 해석할 수 있어야 합니다.
CPU와 GPU 중 무엇으로 돌릴 것인가
기기와 모델 크기에 따라 다릅니다. 무조건 GPU가 정답은 아닙니다.⁵
실행 빈도는 얼마나 되는가
매 프레임 돌릴지, 0.2초마다 돌릴지, 버튼을 눌렀을 때만 돌릴지에 따라 성능 부담이 크게 달라집니다.
실패했을 때 대체 흐름이 있는가
모델이 오판해도 게임이 멈추지 않게 해야 합니다.

이 다섯 가지를 먼저 생각하면, AI 기능이 "우와, 멋있다"에서 끝나지 않고 실제 게임 기능으로 자리를 잡습니다.

AI에게 묻자
"이 ONNX 모델의 입력 크기, 출력 의미, 예상 실행 빈도, 모바일에서의 부담 요소를 입문자 눈높이로 정리해 줘. 특히 내가 Unity에서 붙이기 전에 무엇을 먼저 테스트해야 하는지 체크리스트 형태로 알려 줘."

이 질문은 정말 강력합니다. 모델을 이해하지 못한 채 붙였다가 며칠을 잃는 일을 크게 줄여 줍니다.

이 장에서 배운 것

새 프로젝트에서 왜 URP가 가장 무난하고 강력한 출발점인지 이해했다.
APV, GPU Resident Drawer, STP가 각각 조명, CPU 부담, 업스케일링 품질에 어떤 식으로 도움을 주는지 감을 잡았다.
Shader Graph로 코드 없이도 중요한 오브젝트를 돋보이게 만드는 첫 머티리얼을 설계해 봤다.
Assistant는 설명과 문제 해결, Generators는 프로토타이핑과 빈칸 메우기에 더 잘 맞는다는 점을 구분했다.
Inference Engine과 ONNX의 관계를 정리하고, 온디바이스 추론의 장점과 한계를 이해했다.
최신 기능은 모두 쓰는 것이 아니라, 내 프로젝트에 맞게 꺼내 쓰는 판단력이 중요하다는 점을 확인했다.

다음 장에서 만들 것

다음 장에서는 게임을 만들고 출시한 뒤, 그다음에 무엇을 공부하고 어떻게 살아남을지를 이야기합니다. 수익화, 마케팅, 학습 로드맵, 그리고 AI 시대에 개발자가 어떤 태도를 가져야 오래 가는지까지 이어집니다. 첫 게임을 만든 사람에서, 계속 만드는 사람으로 넘어가는 장입니다.