객체지향 vs 데이터 지향 설계: 무엇이 다르고 어떻게 고를까

이 글과 연결된 과정게임프로그래밍 과정 알아보기

게임은 사람이 동시에 즐기는 경우가 많아 서버와 네트워크 지식도 중요합니다. 과정 후반에는 여러 명이 접속하는 간단한 멀티플레이 기능을 구현해 보며 클라이언트…

객체지향 설계: 사물 단위로 생각합니다

객체지향 설계에서는 게임 속 사물을 클래스로 표현합니다. 몬스터 클래스 안에 체력, 공격력, 위치 같은 데이터와 이동, 공격, 피격 같은 동작을 함께 넣는 식입니다. 고블린과 오크처럼 비슷한 몬스터는 공통 부분을 부모 클래스에 두고 상속받아 차이만 따로 구현합니다.

이 방식의 장점은 사람이 생각하는 방식과 비슷하다는 것입니다. '몬스터가 공격한다'는 문장을 그대로 코드로 옮길 수 있어 구조를 이해하기 쉽고, 기능을 추가할 때 어디를 고쳐야 하는지 찾기도 쉽습니다. 많은 게임 엔진의 기본 구조와 튜토리얼이 객체지향을 바탕으로 하고 있어 처음 배우기에도 자연스럽습니다.

단점은 프로젝트가 커질수록 상속 구조가 복잡해지기 쉽다는 것입니다. 날아다니는 몬스터, 헤엄치는 몬스터, 날면서 헤엄치는 몬스터가 생기면 상속 관계가 꼬이기 시작합니다. 그래서 실무에서는 상속보다 기능을 부품처럼 붙이는 컴포넌트 방식을 많이 씁니다.

데이터 지향 설계: 데이터의 배치를 먼저 생각합니다

데이터 지향 설계는 '이 데이터를 컴퓨터가 어떻게 읽을까'를 먼저 생각합니다. 컴퓨터는 메모리에서 데이터를 가져올 때 근처 데이터를 한꺼번에 가져오는데, 필요한 데이터가 가까이 붙어 있으면 훨씬 빠르게 처리됩니다. 이 빠른 임시 저장 공간을 캐시라고 부릅니다.

객체지향 방식에서는 몬스터마다 데이터가 따로 흩어져 있어서, 수천 마리의 위치를 갱신하려면 메모리 여기저기를 오가야 합니다. 데이터 지향 방식에서는 모든 몬스터의 위치를 하나의 배열에, 속도를 또 다른 배열에 모아 둡니다. 그러면 위치를 갱신할 때 연속된 데이터를 차례로 읽기만 하면 되어 처리 속도가 크게 좋아집니다.

이 생각을 구조로 만든 대표적인 방식이 ECS입니다. 엔티티는 번호만 가진 빈 개체, 컴포넌트는 순수한 데이터, 시스템은 특정 컴포넌트를 가진 개체들을 한꺼번에 처리하는 로직입니다. 일부 게임 엔진은 이런 방식을 위한 기능을 따로 제공합니다.

같은 기준으로 비교한 두 설계

표의 '잘 맞는 곳'을 보면 두 방식은 경쟁 관계라기보다 역할 분담 관계입니다. 플레이어 캐릭터 하나, 메뉴 화면, 퀘스트 흐름처럼 개수가 적고 로직이 복잡한 부분은 객체지향이 편하고, 화면에 수천 개가 동시에 움직이는 부분은 데이터 지향이 유리합니다.

처음 배울 때 헷갈리는 점

가장 흔한 오해는 데이터 지향이 더 고급 기술이니 처음부터 그렇게 짜야 한다는 생각입니다. 하지만 성능 문제가 없는 곳에 데이터 지향 구조를 쓰면 코드만 복잡해지고 개발 속도는 느려집니다. 성능은 실제로 측정해 보고 문제가 확인된 곳부터 개선하는 것이 원칙입니다.

반대로 객체지향을 '클래스를 많이 만드는 것'으로 오해하는 경우도 있습니다. 객체지향의 핵심은 책임을 잘 나누는 것이지 상속 단계를 깊게 쌓는 것이 아닙니다. 상속이 세 단계 이상 깊어진다면 컴포넌트로 나눌 수 없는지 먼저 고민해 보는 것이 좋습니다.

데이터 지향을 공부할 때는 결과를 직접 측정해 보는 것이 이해에 큰 도움이 됩니다. 같은 기능을 두 방식으로 짜서 개체 수를 늘려 가며 프레임을 비교해 보면, 캐시 효율이라는 말이 무엇을 뜻하는지 몸으로 느낄 수 있습니다.

포트폴리오와 면접에서 어떻게 보여 줄까

1. 객체지향으로 게임 하나를 완성하고, 클래스와 컴포넌트를 어떻게 나눴는지 구조도를 남긴다
2. 대량 개체가 등장하는 장면을 만들어 프로파일러로 병목 지점을 측정한다
3. 그 부분만 데이터 지향 방식으로 바꿔 전후 성능을 비교한다
4. 왜 그 부분을 골랐는지, 무엇을 포기했는지 문서로 정리한다

면접에서는 두 방식의 정의보다 '언제 무엇을 썼고 왜 그랬는가'를 묻는 경우가 많습니다. 측정 결과와 판단 근거를 함께 설명할 수 있다면 설계 감각을 보여 주는 좋은 사례가 됩니다.

자주 나오는 질문으로는 상속과 컴포넌트 중 무엇을 선호하는지, 프레임이 떨어질 때 원인을 어떻게 찾는지, 많은 개체를 처리할 때 메모리를 어떻게 관리하는지 등이 있습니다. 답할 때는 일반론보다 내 프로젝트에서 실제로 겪은 장면을 예로 드는 편이 훨씬 설득력 있습니다.

이런 단계라면 객체지향, 이런 단계라면 데이터 지향

프로그래밍을 시작한 지 얼마 안 되었거나 아직 게임 하나를 끝까지 완성해 보지 못했다면 객체지향 설계와 컴포넌트 구조를 먼저 탄탄히 익히는 것이 맞습니다. 이미 완성 경험이 있고 성능 최적화, 엔진 구조, 대규모 시뮬레이션에 관심이 생겼다면 데이터 지향 설계를 공부할 때입니다. 두 방식을 모두 이해하는 프로그래머가 결국 상황에 맞는 선택을 할 수 있습니다.

내 코드가 지금 어떤 구조로 짜여 있는지, 다음 프로젝트에서 무엇을 개선해야 할지 감이 오지 않는다면 SBS아카데미게임학원 게임프로그래밍 과정 상담에서 작성한 코드를 함께 보며 설계 학습 순서를 정해 드립니다.

자주 묻는 질문

가까운 캠퍼스에서 게임프로그래밍 알아보기

사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.

함께 읽으면 좋은 글