Unity 개발자가 C++ 게임 엔진 구조를 공부하면서 게임 루프, 객체 관리, 메모리 구조를 더 깊게 이해하는 과정을 표현한 이미지Unity를 활용해 게임을 개발하면 초반에는 대부분의 기능을 빠르게 구현할 수 있습니다.
캐릭터 이동, 충돌 처리, UI, 애니메이션, 오브젝트 생성과 삭제까지 Unity가 이미 많은 기능을 제공해주기 때문입니다.
하지만, 어느 순간 프로젝트 규모가 커질수록 구조가 이해되지 않고, 감당이 되지 않는 순간이 옵니다.
개별 기능들은 잘 동작하는데 구현된 기능을 한데 어울리도록 구성하기가 어렵고, 프레임 드랍이 생겨도 원인을 감으로 추측하게 됩니다.
이럴 때 Unity 개발 경험을 더 많이 쌓는 것도 물론 좋은 답일 수 있습니다.
하지만, 이럴 때 더 필요한 방법은 단순히 Unity API를 더 많이 외우거나 Unity에 특화된 기법을 더 많이 익히는 것보다는
Unity 바깥에서, 게임 엔진이 기본적으로 어떤 구조로 동작하는지를 직접 생각해볼 필요가 있습니다.
그리고 이런 때는 메모리 관리를 직접 해야 하는 C++로 간단한 게임 엔진 구조를 만들어보는 경험이 큰 도움이 됩니다.
결국, Unity 개발자에게 C++ 게임 엔진 공부는 Unity와 동떨어진 공부가 아니라, Unity를 더 깊게 이해하기 위한 구조 공부라고 볼 수 있습니다.
Unity의 Update는 그냥 호출되는 것이 아닙니다
Unity로 게임을 개발할 때 가장 많이 활용하는 함수 중 하나는 Update 입니다.
아래 예시 코드와 같이 Update에서 이동을 처리하는 코드는 익숙하실 겁니다.
void Update()
{
transform.position += Vector3.right * speed * Time.deltaTime;
}
MonoBehaviour를 상속 받은 클래스에서 Update 함수를 배치만 하면 자동으로 호출됩니다.
하지만 엔진 관점에서 보면 Update는 자동으로 실행되는 함수가 아닙니다.
게임 엔진 내부에는 결국 매 프레임 반복 호출되는 함수들이 있습니다.
while (isRunning)
{
ProcessInput();
Update(deltaTime);
Render();
}
이 구조를 직접 만들어보면 Unity의 Update가 다르게 보입니다.
Update는 마법 같은 기능이 아니라, 게임 루프 안에서 매 프레임 호출되는 업데이트 단계라는 것을 이해하게 됩니다.
이것을 이해하고 있는 지의 차이는 생각보다 큽니다.
- 왜 매 프레임 실행되는 코드가 조심스러워야 하는지
- 왜 Update 안에서 불필요한 연산을 줄여야 하는지
- 왜 deltaTime이 필요한지
- 왜 입력 처리와 업데이트 순서가 중요한지
Unity를 활용해서 개발할 때 매뉴얼로만 배웠던 것들을 직접 코드를 작성해보고, 구현해보면서
단순한 규칙이 아니라 구조로 이해되기 시작합니다.
참고로 이와 관련해서 게임 루프와 deltaTime은 아래 글에서 더 자세히 정리했습니다.
C++ 게임 루프 완벽 이해: 게임은 어떻게 계속 움직일까?
C++ deltaTime 완벽 이해: 왜 프레임마다 시간이 다를까?
GameObject도 결국 엔진이 관리하는 객체
Unity에서는 GameObject를 만들고 Component를 붙여서 게임을 구성합니다.
아래 코드는 프래팹을 기반으로 게임 오브젝트를 생성하고, 삭제하는 과정을 단순하게 보여주는 코드입니다.
GameObject enemy = Instantiate(enemyPrefab); Destroy(enemy);
사용하는 입장에서는 간단하지만, 엔진 입장에서는 해야 할 일이 많습니다.
객체를 생성해야 하고, 어딘가에 저장해야 하고, 매 프레임 필요한 객체를 순회해야 하고, 삭제 요청이 들어온 객체를 안전하게 제거해야 합니다.
이 모든 과정을 Unity라는 엔진이 알아서 처리해주기 때문에 엔진 안에서 어떤 처리가 이루어지는지는 고민하지 않을 때가 많습니다.
하지만, 상용 엔진을 사용해 개발을 하더라도 시간이 지남에 따라 엔진의 동작 원리를 이해해야만 하는 순간들이 찾아옵니다.
C++로 간단한 엔진 구조를 만들면 이런 코드를 직접 작성하게 됩니다.
class Level
{
public:
void AddActor(Actor* actor);
void Update(float deltaTime);
private:
std::vector<Actor*> actors;
};
이런 구조를 직접 만들어보면 Unity의 Scene과 GameObject도 다르게 보입니다.
중요한 것은 클래스의 이름이 GameObject인지 Actor인지가 아닙니다.
핵심은 게임 안의 객체들을 엔진이 어떻게 저장하고, 어떤 순서로 업데이트하고, 언제 제거할 것인가?입니다.
이 관점이 생기면 Unity 프로젝트를 설계할 때도 생각이 달라집니다.
- 모든 오브젝트가 스스로 Update를 가져도 되는가?
- Manager가 너무 많은 책임을 가지고 있지는 않은가?
- 객체 생성과 삭제가 한 프레임 안에서 너무 자주 발생하지 않는가?
- 오브젝트 풀링이 필요한 지점은 어디인가?
- 등등
Unity를 게임 엔진의 구조에 맞게 더 잘 활용할 수 있는 능력을 갖출 수 있습니다.
오브젝트 풀링이 왜 필요한지 체감하게 됩니다
Unity 최적화에서 자주 나오는 용어 중 하나가 Object Pooling입니다.
오브젝트 풀링을 학습할 때는 왜 그런지를 명확하게 이해하지 못한 상태에서
Instantiate와 Destroy가 비용이 크기 때문에 미리 만들어두고 재사용하는 것이 성능 측면에서 좋다고 배웁니다.
맞는 말입니다. 하지만 C++에서 직접 객체를 생성하고 삭제해보면 이 문제가 더 구체적으로 보입니다.
게임은 매 프레임 반복되는 프로그램입니다.
그 안에서 객체를 계속 만들고 지우면, 메모리 할당 비용이 발생하고, 캐시 효율이 떨어질 수 있고, 관리해야 할 객체의 생명주기도 복잡해집니다.
Unity에서는 GC까지 연결됩니다.
즉, Object Pooling은 단순한 성능 팁이 아니라 게임 루프 안에서 객체 생명주기를 안정적으로 관리하기 위한 구조입니다.
이 차이를 이해하면 풀링을 적용하는 기준도 달라집니다.
- 자주 생성되고 삭제되는가?
- 프레임 중간에 생성 비용이 튀는가?
- GC Alloc을 유발하는가?
- 같은 형태의 객체가 반복해서 사용되는가?
무지성으로 오브젝트 풀링이 좋다고 하니 적용하는 것이 아니라, 필요한 지점을 명확하게 인지할 수 있는 능력을 갖추게 됩니다.
참고로 오브젝트 풀링에 대한 내용을 더 자세히 정리해두었습니다.
게임 개발자를 위한 메모리 구조 5 – Object Pool을 사용하는 이유
Profiler를 볼 때 숫자가 아니라 구조가 보입니다
Unity Profiler를 열어보면 많은 정보가 나옵니다.
CPU Usage, Rendering, Memory, GC Alloc, Scripts 등 여러 항목이 보입니다.
처음에는 숫자만 보이고, 그 숫자가 왜, 어떻게 나왔는지 해석하기 어렵습니다.
하지만, C++를 활용해서 게임 엔진 구조를 직접 구현하면서 공부하면 Profiler를 보는 관점이 달라집니다.
CPU 시간이 높게 나온다면 단순히 “느리다”가 아니라, 게임 루프 안에서 어느 단계가 오래 걸리는지 생각하게 됩니다.
그리고 다양한 원인을 여러 단계로 나눠서 볼 수 있게 됩니다.
- 입력 처리 문제인가?
- Update에서 너무 많은 객체를 순회하고 있는가?
- 충돌 검사 비용이 큰가?
- 렌더링 준비 단계가 비싼가?
- 메모리 할당 때문에 GC가 개입했는가?
최적화는 감으로 하는 작업이 아닙니다.
프레임이 어떤 단계로 구성되어 있고, 각 단계에서 어떤 비용이 발생하는지 명확히 이해한 상태에서 병목 즉, 문제 원인을 제대로 파악할 수 있어야 합니다.
이 관점이 생기면 Unity Profiler는 단순한 성능 측정 도구가 아니라 엔진 흐름을 확인하는 도구가 됩니다.
유니티 FPS가 떨어지는 이유 (CPU Bound vs GPU Bound 완벽 정리)
유니티 GC 때문에 끊긴다? (프레임 드랍의 숨은 원인)
AI가 만든 Unity 코드도 더 잘 판단할 수 있습니다
요즘은 AI 도구를 활용하면 Unity 코드도 빠르게 만들 수 있습니다.
이동 코드, 인벤토리 코드, 적 AI 코드, UI 코드까지 꽤 그럴듯하게 생성됩니다.
하지만, 이렇게 AI가 빠르게 만들어낸 코드의 품질이 좋은지 나쁜지를 구별해내는 것은 다른 차원의 얘기입니다.
AI가 만든 코드가 지금 당장은 동작할 수 있지만, 게임 개발에서는 지금 동작하는 것만으로 충분하지 않습니다.
- 프레임마다 불필요한 할당을 하고 있지는 않은가?
- Update에 너무 많은 책임이 몰려 있지는 않은가?
- 객체 생명주기가 꼬일 가능성은 없는가?
- 나중에 기능을 추가하기 어려운 구조는 아닌가?
- 입력, 상태, 렌더링, 데이터가 뒤섞여 있지는 않은가?
이런 판단은 단순히 Unity API를 학습해 기능을 구현할 수 있다고 해서 알 수 없습니다.
게임 엔진의 기본 구조를 이해하고 있어야 가능합니다.
AI 시대에는 코드를 빠르게 만드는 능력도 중요하지만,
그 코드가 엔진 구조 안에서 괜찮은 코드인지 판단하는 능력이 더 중요해지고 있습니다.
코드를 AI가 작성할 수 있지만, 판단하는 것은 결국 우리의 몫입니다.
C++을 공부하는 목적은 Unity를 버리기 위함이 아닙니다
여기서 오해하면 안 되는 부분이 있습니다.
Unity 개발자가 C++ 게임 엔진 구조를 공부한다고 해서 Unity를 버리고 자체 엔진을 만들어야 한다는 뜻이 절대로 아닙니다.
오히려 반대에 가깝습니다.
Unity를 더 잘 사용하기 위해 엔진 구조를 공부하는 것입니다.
Unity는 이미 많은 것을 추상화해둔 엔진입니다.
다시 말하면, Unity를 사용하는 개발자 입장에서 많은 부분을 고려하지 않아서 엔진이 알아서 처리해주는 부분이 너무나 많습니다.
하지만 이렇게 추상화된 도구를 잘 사용하려면, 그 아래에 어떤 문제가 숨어 있는지 어느 정도는 알고 있어야 합니다.
그래야 문제가 생겼을 때 단순히 검색 결과를 따라 하는 것이 아니라, 원인을 제대로 추적할 수 있습니다.
- Update가 많아서 느리다 → 게임 루프와 객체 순회 비용을 생각한다
- GC가 튄다 → 프레임 중 메모리 할당과 객체 생명주기를 생각한다
- 오브젝트가 꼬인다 → 생성/삭제 타이밍과 소유 구조를 생각한다
- 입력이 이상하다 → 입력 갱신 시점과 상태 전이를 생각한다
- 렌더링이 느리다 → CPU Bound와 GPU Bound를 구분한다
이렇게 보면 C++ 게임 엔진 공부는 Unity와 별개의 공부가 아닙니다.
C++ 게임 엔진 공부는 Unity 개발을 더 깊게 이해하기 위한 기반이 됩니다.
처음부터 거대한 엔진을 만들 필요는 없습니다
게임 엔진 구조를 공부한다고 해서 처음부터 언리얼 엔진이나 Unity 같은 거대한 엔진을 만들 필요는 없습니다.
오히려 처음에는 작게 시작하는 것이 좋습니다.
아래 정도의 구조만 직접 만들어봐도 충분히 많은 것을 배울 수 있습니다.
- 게임 루프
- deltaTime 계산
- 입력 처리
- Actor / Level 구조
- 객체 생성과 삭제
- 간단한 렌더링 흐름
- 충돌 처리
- RTTI
이 정도만 구현해도 Unity의 많은 기능이 다르게 보이기 시작합니다.
그동안 그냥 사용하던 기능들이 사실은 엔진 내부의 여러 시스템이 연결된 결과라는 것을 이해하게 됩니다.
그리고 나서 Unity를 활용해 다시 개발을 할 때는 Unity 컴포넌트의 코드 뿐만 아니라 엔진 내부의 동작까지 고려해 코드를 작성하는 자신을 발견하게 되실 겁니다.
이런 핵심 구조를 직접 구현해보는 흐름은 C++로 만드는 게임 엔진 프레임워크 강의에서도 단계적으로 다룹니다.
마무리
Unity는 너무 좋은 엔진입니다.
하지만 Unity를 사용하다 보면 단순히 사용법을 익혀 적용하는 것만으로는 부족한 순간이 옵니다.
그때 필요한 것은 더 많은 API를 학습하거나, 단적인 문제를 해결하는 방법을 찾는 것이 아니라, 게임 엔진이 어떤 구조로 동작하는지 이해하는 힘입니다.
C++ 게임 엔진을 공부하면 Unity 개발에서 이런 것들이 좋아집니다.
- Update와 게임 루프를 구조적으로 이해할 수 있습니다
- GameObject와 객체 생명주기를 더 명확하게 볼 수 있습니다
- Profiler 결과를 더 정확히 해석할 수 있습니다
- AI가 만든 코드도 구조 관점에서 판단할 수 있습니다
- Unity를 단순히 사용하는 것이 아니라 더 깊게 활용할 수 있습니다
결국 C++ 게임 엔진을 공부한다는 것은 Unity와 멀어지는 일이 아닙니다.
Unity를 더 잘 이해하기 위해 게임 엔진의 기본 구조를 직접 경험해보는 과정입니다.
👉 게임 엔진 구조를 더 깊이 이해하고 싶다면
아래 강의를 통해 직접 구현해보는 것을 추천드립니다.
👉 C++로 만드는 게임 엔진 프레임워크 강의 바로가기