Why Game Development

게임개발자를 목표로 삼게 된 이유

어릴 때부터 저는 무언가를 직접 만들고, 관찰하고, 하나의 결과물로 완성해가는 과정에 오래 머무는 편이었습니다.

클레이로 모형을 만들고, 레고를 조립하고, 그림을 그리면서 시간을 보내는 일이 자연스러웠습니다.

처음에는 흩어져 있던 조각들이 하나의 형태로 맞춰지고, 머릿속에만 있던 생각이 눈앞의 결과물로 바뀌는 과정이 좋았습니다.

그때는 이런 성향이 게임개발이라는 진로로 이어질 수 있다는 생각까지는 하지 못했습니다.

하지만 지금 돌아보면 저는 오래전부터

“무언가를 만드는 일”

그리고

“그것이 어떤 구조로 이루어져 있는지 이해하는 일”

두 가지를 모두 좋아했던 것 같습니다.

어릴 때의 저는 게임을 만드는 사람이라기보다 게임을 좋아하고 즐기는 평범한 학생이었습니다.

메이플스토리의 리스항구, 엘리니아, 슬리피우드에서 들었던 몽환적인 음악은 지금도 들으면, 어렸을 때 아무 걱정 없이 게임을 즐기던 제 모습이 떠오르는 추억과 향수 같은 음악입니다.

전사를 키우던 시절에는 호기심이 많아 낮은 레벨인데도 고레벨 몬스터가 있는 슬리피우드 던전 깊숙한 곳까지 들어갔다가 빠져나오지 못한 적도 있습니다. 지금도 메이플스토리를 함께 했던 친한 친구들에게 이 이야기를 꺼내면 다 같이 웃게 되는 재미있는 추억입니다.

카스온라인에서는 친구들과 좀비 모드를 많이 했습니다.

같이 도망치다가 친구 한 명이 좀비가 되면 서로 잡겠다고 쫓아다니던 상황 자체가 즐거웠습니다.

당시에는 왜 그런 경험들이 오래 기억에 남는지 생각하지 않았습니다.

그냥 재미있어서 게임을 했습니다.

게임을 조금 다르게 바라보게 된 계기는 군 복무 중이었습니다.

고된 일과가 끝난 뒤 군부대 동기·후임·선임들과 브롤스타즈를 플레이하던 짧은 시간은 다시 웃고 하루의 피로를 내려놓을 수 있는 시간이었습니다.

당시에는 크게 의식하지 못했지만, 돌이켜보면 게임은 단순한 오락을 넘어 같은 목표에 함께 몰입하고 사람 사이에 기억을 남기는 경험이었습니다.

그때부터 게임은 제가 소비하고 즐기는 콘텐츠를 넘어, 누군가의 하루에 긍정적인 장면을 남길 수 있는 매체로 다가오기 시작했습니다.

게임은 제게 가장 매력적인 문화 중 하나입니다.

누군가에게는 여가와 취미가 되고,

누군가에게는 친구들과 함께 머무는 놀이터가 되며,

또 누군가에게는 프로그래머, 아티스트, 기획자, 프로게이머처럼 삶의 방향이 되기도 합니다.

저는 게임을 플레이하는 시간도, 게임을 만들기 위해 고민하는 시간도 제 삶에서 충분히 가치 있는 시간이라고 느꼈습니다.

제가 오래 좋아해온 창작, 구조, 몰입, 그리고 사람 사이의 경험이 게임 안에 함께 들어 있었습니다.

그래서 제가 좋아하던 “무언가를 만드는 일”을 게임이라는 형태로 이어가보고 싶다는 생각이 구체적으로 들기 시작했습니다.

제가 상상한 규칙과 시스템, 세계를 실제로 구현하고, 그 결과물이 누군가에게 즐거운 시간과 오래 기억되는 경험이 될 수 있다면 게임개발은 제가 가장 깊게 몰입할 수 있는 일이 될 것 같았습니다.

게임개발자라는 목표는 어느 날 갑자기 생긴 동경이라기보다, 제가 가지고 있던 창작 성향과 구조를 이해하고 싶어 하는 성향이 가장 자연스럽게 만난 방향이었습니다.

확신을 실제 학습과 구현으로 옮겼습니다

전역 후에는 그 생각을 행동으로 옮겼습니다.

직접 물류센터 아르바이트를 하며 모은 돈으로 여러 게임개발 교육 과정을 알아봤습니다.

단순히 게임개발을 배울 수 있다는 이유만으로 선택하기보다, 실제 취업생들의 포트폴리오 수준과 커리큘럼, 취업 자료를 비교했습니다.

직접 월별 결제를 하며 게임개발 교육 과정을 경험해본 뒤, 제 기준과 맞지 않는다고 판단한 과정은 정리하고 다시 다른 선택지를 찾아보기도 했습니다.

그 과정을 거쳐 쥬신게임아카데미를 선택했고, 당시 거주하던 수원에서 서울 가산디지털단지에 있는 학원까지 통학하며 C++ 기반 게임 클라이언트 개발을 배우기 시작했습니다.

쥬신게임아카데미에서는 다음 순서로 프로젝트를 진행했습니다.

WinAPI
→ MFC
→ DirectX 9
→ DirectX 11

WinAPI에서는 게임 루프와 입력, 객체가 움직이는 기본 구조를 경험했고, MFC 팀 프로젝트에서는 다른 사람이 만든 Tool을 실제 제작 과정에서 사용해봤습니다.

DirectX9과 DirectX11에서는 C++ 코드로 게임 오브젝트와 충돌, 렌더링, UI, Resource, Tooling을 직접 다뤘습니다.

이후 Unreal Engine 학습은 내일배움캠프의 Unreal 기반 3D 게임 개발자 양성과정을 통해 이어갔습니다.

이 과정은 서울로 통학한 교육이 아니라, 집에서 온라인으로 참여한 교육 과정이었습니다.

온라인 과정에서는 Unreal C++, Gameplay Ability System, Gameplay Framework와 팀 프로젝트를 중심으로 학습하며, DirectX에서 쌓은 C++ 게임 클라이언트 경험을 Unreal Gameplay 개발로 확장했습니다.

그래서 제가 지나온 전체 학습 흐름을 교육 방식까지 함께 정리하면 다음과 같습니다.

쥬신게임아카데미

WinAPI → MFC → DirectX 9 → DirectX 11

(수원 → 서울 가산디지털단지 통학)

↓

내일배움캠프 Unreal Engine 게임개발 과정

Unreal Engine → C++ → Gameplay System

(집에서 온라인 참여)

처음부터 Unreal Engine의 기능을 사용하는 방법만 배운 것은 아닙니다.

C++ 코드로 게임이 움직이고 화면에 결과가 만들어지는 기초부터 경험한 뒤, Unreal Engine에서는 이미 존재하는 큰 Framework 안에서 각 시스템의 State와 책임이 어떻게 연결되는지를 공부했습니다.

이 과정은 단순히 교육 과정을 수료하기 위한 시간이 아니었습니다.

게임개발자가 되겠다고 선택한 뒤, 그 선택을 매일의 학습과 구현으로 증명해가던 시간이었습니다.

C++ 게임 클라이언트의 Runtime부터 따라가 보기 시작했습니다

DirectX11 프로젝트를 진행하면서부터는 화면에 결과가 보인다는 이유만으로 기능을 이해했다고 생각하지 않게 됐습니다.

프로젝트에는 이미 학습용 Custom DirectX11 Framework가 있었기 때문에, Framework 전체를 제가 처음부터 설계했다고 설명하지 않습니다. 대신 기존 Source를 따라가며 Object가 실제 Runtime에서 언제 만들어지고, 어떤 Component와 Layer를 거쳐 Update와 Render까지 이어지는지를 확인했습니다.

Map Tool을 만들 때도 화면에 Object가 배치되는 것보다, 저장한 값이 다음 실행에서 실제 게임 상태로 다시 복원되는지를 더 중요하게 봤습니다.

화면에 Object가 잘 보인다고 해서, 그 Object가 어떤 과정을 거쳐 만들어지고 화면까지 나온 것인지 모두 확인한 것은 아니라고 생각했습니다.

저장 기능도 마찬가지였습니다. 파일이 만들어졌다는 것만으로 끝내지 않고, 다음 실행에서 저장했던 값이 실제 게임 상태로 다시 돌아오는지까지 확인해야 제대로 동작한다고 볼 수 있었습니다.

Map 전환 과정에서도 목적지 화면은 정상적으로 바뀌었지만 Player, Camera, Navigation이 예상대로 복원되지 않는 문제가 있었습니다. 마지막에 보이는 Camera부터 수정하기보다 앞 단계부터 하나씩 확인했고, Player Spawn을 결정하는 흐름에서 처음 예상과 실제가 달라지는 지점을 좁혔습니다.

이후에는 문제가 생기면 다음 순서를 자주 사용하고 있습니다.

Expected
→ Actual
→ 마지막 정상 지점
→ 처음 달라지는 지점

어려운 디버깅 기법을 많이 안다고 말하기보다, 어디까지 정상인지 먼저 확인하고 처음 달라지는 지점부터 보는 습관을 가지려고 합니다.

Unreal에서는 더 큰 Framework 안에서 책임을 읽기 시작했습니다

DirectX 기반 프로젝트를 경험한 뒤에는 Unreal Engine으로 학습 범위를 넓혔습니다.

Unreal에서는 직접 모든 구조를 만드는 것보다, 이미 존재하는 큰 Framework 안에서 각 시스템이 어떤 책임을 가지고 연결되는지를 읽는 일이 더 중요하다고 느꼈습니다.

그래서 새로운 기능을 볼 때도 먼저 다음을 확인합니다.

이 State는 누가 가지고 있는가?
누가 바꾸는가?
다음에 누가 읽는가?
언제 만들어지고 사라지는가?

RiteSeekers에서는 Lyra Starter Game Reference의 Gameplay Framework를 따라가며 이런 기준으로 구조를 분석했습니다. Lyra 전체를 제가 설계했다고 설명하지 않고, 기존 책임을 이해한 뒤 필요한 Combat Runtime 영역을 확장했습니다.

대표적으로 Blood와 Execution 같은 추가 전투 규칙을 Melee 안에 계속 넣지 않고, 실제 공격이 적중했다는 HitConfirmed Event를 기준으로 각 Rule이 자기 조건만 처리하도록 나눴습니다.

구조만 나눈 것이 아니라 실행돼야 할 때와 실행되면 안 될 때를 함께 확인했습니다. Execution은 체력 조건에 따라 Skip과 Trigger를 확인했고, Rule 제거 뒤에는 기본 공격만 남는 Negative Test와 Dead Target Guard도 확인했습니다.

이 경험 이후에는 “한 번 잘 됐다”보다 언제 들어오고, 언제 빠지며, 잘못된 조건에서는 정말 실행되지 않는가까지 보려고 합니다.

성능도 비슷하게 생각합니다. 느려 보인다는 이유만으로 최적화했다고 말하지 않고, 실제 측정과 같은 조건의 Before / After가 있을 때만 개선이라고 설명하려고 합니다.

팀에서는 내 기능만 잘 만드는 것으로 끝나지 않았습니다

개인 프로젝트와 팀 프로젝트는 많이 달랐습니다.

혼자 개발할 때는 제가 구조와 일정을 대부분 결정할 수 있지만, 팀에서는 이미 다른 사람이 만든 Code와 Data, 규칙 위에서 제 기능을 연결해야 했습니다.

ImitationTrigger에서는 6인 팀으로 멀티플레이 프로젝트를 진행했고, 저는 C++ Camera Runtime과 팀 Gameplay State를 실제 Camera View로 연결하는 부분을 중심으로 맡았습니다.

플레이어에게는 단순히 우클릭을 누르면 TPS에서 ADS 화면으로 바뀌는 기능이지만, 내부에서는 여러 단계가 연결됩니다.

Input
→ Ability
→ ADS State
→ CameraMode
→ Camera Runtime
→ Player View

제가 중요하게 본 것은 제 Camera 코드만 보는 것이 아니라, 앞 단계의 State가 어디에서 만들어지고 어떤 경로로 Camera까지 넘어오는지를 함께 이해하는 것이었습니다.

멀티플레이에서는 같은 함수라도 Server에서 실행됐는지 Client에서 실행됐는지, 어떤 Role인지에 따라 의미가 달라질 수 있었습니다. 그래서 이런 실행 위치를 로그에서 빠르게 구분할 수 있는 작은 Network Debug Utility도 만들었습니다.

또 Git Branch, Commit, PR·Merge, Code Convention 같은 작업 기준을 Notion에 정리해 공유했고, 공용 대용량 Asset은 별도 ZIP 배포와 적용 절차를 정리했습니다.

팀 프로젝트를 거치면서 협업은 의견이 항상 같은 상태가 아니라는 것도 배웠습니다. 의견이 다를 때 누가 맞는지를 먼저 정하기보다, 남은 일정과 위험도, 기존 작업을 함께 보고 팀이 다시 같은 기준으로 일할 수 있게 만드는 과정이 더 중요하다고 생각합니다.

왜 개발 블로그를 만들었는가

이 블로그는 단순히 프로젝트 결과를 보여주기 위해 만든 공간은 아닙니다.

팀 프로젝트를 경험하면서 구현 실력만큼이나 왜 이렇게 만들었는지 설명하고, 변경 내용을 다른 사람과 공유하는 능력이 중요하다고 느꼈습니다.

Git Commit과 PR, 공통 규칙, Runtime Flow, Debug 결과처럼 코드 밖에서 함께 공유해야 하는 정보도 많았습니다. 이런 내용이 제대로 정리되지 않으면 작은 오해도 Merge 실수나 역할 충돌로 이어질 수 있었습니다.

그래서 프로젝트를 정리할 때 가장 많이 답하려는 질문은 하나입니다.

왜 이렇게 만들었는가?

어떤 문제를 보고 있었는지, 왜 이 구조를 선택했는지, 어디까지 직접 확인했는지를 남기려고 합니다.

저에게 이 블로그는 공부한 내용을 쌓아두는 공간이기도 하지만, 제가 만든 프로젝트를 다시 이해하고 다른 사람에게 더 정확하게 설명하기 위한 도구이기도 합니다.

넥슨 판교 본사 앞에서

게임개발자라는 목표가 조금씩 구체화되면서, 대형 게임개발사는 실제로 어떤 곳일까 직접 보고 싶다는 생각도 들었습니다.

넥슨은 어릴 때부터 제 게임 경험에 익숙하게 있던 회사였습니다. 메이플스토리의 지역과 음악, 친구들과 즐겼던 카스온라인 좀비 모드처럼 지금도 기억나는 장면들이 있습니다.

게임개발을 공부하고 난 뒤에는 예전에 그냥 재미있게 했던 게임도 조금 다르게 보이기 시작했습니다. 플레이어가 오래 기억하는 한 장면 뒤에는 여러 개발자의 선택과 시스템이 연결되어 있다는 것을 알게 됐습니다.

넥슨 판교 본사 앞에서 사진을 남긴 것도 그런 시기의 기록입니다. 실제 개발 공간 내부를 본 것은 아니지만, 공부하면서 목표로만 생각하던 게임회사를 직접 마주하니 게임개발자라는 목표가 조금 더 현실적으로 느껴졌습니다.

함께 취업을 준비하던 동기와 그곳을 바라보며, 언젠가 저도 충분한 실력을 쌓아 실제 개발팀 안에서 제 몫을 해내고 싶다는 마음을 다시 다잡았습니다.

Unreal Engine Festival

언리얼엔진 페스티벌에 참여했을 때는 내일배움캠프의 Unreal 기반 3D 게임 개발자 양성과정을 집에서 온라인으로 수강하며 Unreal Engine을 본격적으로 공부하고 있었습니다.

그 전에는 쥬신게임아카데미에서 수원에서 서울 가산디지털단지까지 통학하며 WinAPI, MFC, DirectX9, DirectX11을 배웠고, 이후 Unreal Engine과 C++ Gameplay 개발로 학습 범위를 넓혔습니다.

페스티벌에서는 Unreal Engine과 실제 게임개발 현장에서 어떤 기술과 방향성을 중요하게 보는지 직접 듣고 싶었습니다.

현장 세션을 보면서 Unreal Engine을 단순히 기능이 많은 제작 도구라기보다, Input, Ability, Animation, Combat, Camera, UI 같은 여러 시스템이 서로 다른 책임으로 연결되는 큰 개발 환경으로 더 진지하게 보게 됐습니다.

Lyra Starter Game 같은 공식 Reference도 같은 이유로 공부했습니다. 구조를 제 설계처럼 말하기보다, 왜 이런 책임 분리가 필요한지와 실제 Runtime에서 어떻게 연결되는지를 이해하는 데 집중했습니다.

이후 관심도 “게임을 만들고 싶다”에서 조금 더 구체적으로 바뀌었습니다.

이 기능은 어디에 있어야 하는가?
누가 이 State를 가지고 있어야 하는가?
기능을 추가할 때 기존 코드를 얼마나 건드리는가?
문제가 생기면 어디부터 확인해야 하는가?

언리얼엔진 페스티벌은 새로운 기능을 구경한 행사라기보다, 앞으로 어떤 기준으로 Unreal Gameplay 개발을 공부할 것인지 더 구체적으로 생각하게 된 계기였습니다.

지금 제가 가장 중요하게 생각하는 개발 방식

여러 프로젝트를 거치면서 지금은 다음 순서를 가장 중요하게 생각하고 있습니다.

기존 구조를 먼저 읽는다.
↓
State의 Owner를 찾는다.
↓
누가 바꾸고 누가 읽는지 확인한다.
↓
필요한 부분만 확장한다.
↓
Runtime에서 결과를 확인한다.
↓
확인한 범위까지만 설명한다.

DX11에서는 Runtime Object와 Tool Data가 실제 게임 상태로 이어지는 흐름을 따라갔고, RiteSeekers에서는 기존 Gameplay Framework를 읽은 뒤 필요한 Combat 영역을 확장했습니다. ImitationTrigger에서는 팀의 Input / GAS / PawnData 구조를 다시 만들기보다 제가 구현한 Camera Runtime과 연결되는 경계를 찾았습니다.

세 프로젝트의 기술은 서로 다르지만, 제가 문제를 보는 방식은 점점 비슷해졌습니다.

단순히 “동작한다”에서 끝내지 않고,

왜 동작하는가?
어떤 State가 바뀌었는가?
그 State의 책임은 누구에게 있는가?
어디까지 실제로 확인했는가?

를 함께 보려고 합니다.

마무리

제가 게임개발자를 목표로 삼게 된 과정은 하나의 사건으로 설명되지는 않습니다.

어릴 때부터 좋아했던 만들기,

친구들과 함께했던 게임의 기억,

군 복무 중 브롤스타즈를 하며 느꼈던 게임의 긍정적인 경험,

전역 후 직접 교육 과정을 찾아 시작한 C++ 게임 클라이언트 학습,

WinAPI와 MFC, DirectX9, DirectX11 프로젝트,

Unreal Engine과 Gameplay System 학습,

팀 프로젝트에서 경험한 협업과 문서화,

그리고 State, Owner, Lifetime과 Runtime을 중심으로 구조를 이해하려는 개발 방식이 하나씩 이어졌습니다.

처음에는 단순히 게임을 만들어보고 싶었습니다.

지금은 플레이어에게 좋은 경험을 전달하면서도, 그 기능이 어떤 구조와 책임 위에서 동작하는지를 설명할 수 있는 개발자가 되고 싶습니다.

그리고 새로운 팀에 들어가게 된다면 제 방식부터 적용하기보다 먼저 그 팀의 기존 코드와 규칙을 이해하고 싶습니다.

제가 맡은 기능이 어느 구조에 들어가야 하는지 확인하고, 수정한 결과가 실제 게임 실행에서 어떻게 달라졌는지 끝까지 확인하고 싶습니다.

모르는 것을 아는 것처럼 말하기보다, 제가 무엇을 확인했고 무엇은 아직 확인하지 못했는지 구분해 설명할 수 있는 사람이 되고 싶습니다.

제가 지향하는 방향은 분명합니다.

C++ 기반 게임 클라이언트의 Runtime을 이해하고, Unreal Engine의 기존 Gameplay Framework를 읽고, 필요한 시스템을 정확한 책임 위치에 연결하고 확장하며, 팀과 함께 유지할 수 있는 형태로 만드는 게임 클라이언트 / Gameplay Programmer로 성장하는 것입니다.