일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- 카카오 2020 코딩테스트
- 자소서 너무 오래 걸림
- 이더리움 #ethereum
- mac hive 3
- 자소서 빨리 쓰는 법
- mac hadoop 설정
- 카카오 자물쇠와 열쇠
- 백준 18428
- 이더리움
- Resources are low on NN
- 자소서 빨리
- code=0)
- 카카오 2020 코테
- hive beeline 실행
- mac hadoop
- 자소서 시간 줄이기
- is not allowed to impersonate hive (state=08S01
- hive beeline 에러
- hadoop safe mode
- 도커 교과서
- mac hadoop 3
- hadoop safe mode leave
- Failed to connect to localhost:10000
- mac hive
- hive beeline
- Could not open client transport with JDBC Uri: jdbc:hive2://localhost:10000
- mac hadoop 설치
- 기업 조사 빨리 하는 법
- Safe mode is ON
- hive beeline 설정
- Today
- Total
A seeker after truth
게임 개발은 유니티 하나로 끝? 게임 개발의 기술 스택과 구조 이해하기 (feat.MMORPG, 퍼즐) 본문
저는 웹, 앱, 데이터 분야 개발에는 익숙하지만, 게임 개발은 유니티와 언리얼만 알 뿐 구조나 기술 스택은 생소하여 이 글을 쓰게 되었습니다. 간단하게 공부해본 결과, 게임은 클라이언트-서버 아키텍처는 물론 실시간 통신, 인프라, 운영 툴까지 웹/앱 이상으로 복잡한 구조를 갖추고 있었습니다. 이 글에서는 게임 개발의 전체적인 아키텍처와 사용 기술, 엔진의 역할까지 정리했습니다.
🎮 게임 개발의 전체 구조
게임 개발도 웹 서비스처럼 기획 → 개발 → 테스트 → 출시 → 운영이라는 사이클을 따릅니다. 하지만 내부 구조와 요구되는 기술은 꽤 다릅니다.
게임은 무엇보다 실시간성과 높은 사용자 경험(UX)을 요구하기 때문에, 아키텍처도 여기에 맞춰 구성됩니다.
🏗️ 기본 아키텍처: 클라이언트 - 서버 - DB
게임도 기본적으로는 클라이언트와 서버, 그리고 데이터 저장소로 구성됩니다.
[클라이언트(Unity/Unreal)] <--> [게임 서버] <--> [DB, 캐시 등]
│
└── [운영툴 서버, API 게이트웨이 등]
🔹 클라이언트
- Unity (C#), Unreal Engine (C++) 등 게임 엔진을 사용
- 그래픽, 물리 엔진, UI, 애니메이션, 사운드, 입력 처리 등 포함
- WebSocket이나 TCP/UDP 통신 기능 내장 또는 확장 가능
🔹 게임 서버
- 실시간 멀티플레이, 전투 로직, 유저 세션, 매치메이킹 등 처리
- Java, Node.js, Go, C#, C++ 등 다양한 언어로 커스텀 구현
- Redis, MySQL, MongoDB, Cassandra 등 다양한 DB 사용
🧠 게임 서버 구조는 어떻게 생겼을까?
게임의 장르에 따라 서버 구조도 달라집니다.
예를 들어 MMORPG처럼 대규모 유저가 동시에 접속하는 게임은 다음과 같은 마이크로서비스 아키텍처 형태를 가질 수 있습니다.
- Zone 서버 (맵/지역 단위로 분리)
- 매치메이킹 서버
- 채팅 서버
- AI 서버
- 인증 및 과금 서버
- 운영툴 서버
실시간 처리를 위해 TCP/UDP 기반 통신을 주로 사용하고, 일부 시스템은 REST API나 gRPC로도 구성합니다.
그렇다면 퍼즐 게임은 어떨까요? 경우에 따라 다르지만, 여기선 MMORPG에 비하면 비교적 단순한 클라이언트-서버 구조를 갖는 예시로 캐주얼 퍼즐 게임을 들어보겠습니다.
캔디크러쉬사가, 애니팡 같은 캐주얼 퍼즐 게임의 특징은 다음과 같습니다.
- 싱글 플레이 중심
- 실시간성 거의 없음
- 서버는 주로 유저 정보 동기화, 랭킹, 광고, 과금 처리 담당
- 대부분은 비동기 구조 + 클라이언트 중심 설계
따라서 클라이언트가 대부분의 게임 로직을 처리하고, 서버는 기록과 검증만 맡는 구조가 일반적입니다. 이 경우 서버는 주로 다음과 같은 기능을 수행합니다.
- 유저 계정 관리 (게스트, 소셜 로그인 등)
- 스테이지 클리어 기록 저장
- 하트, 아이템 보유량 동기화
- 과금/광고 보상 처리
- 랭킹 (주로 비동기: 일일/주간 등)
이 경우 DB에는 유저 상태, 인벤토리 등이 저장될 것이고, 광고, 결제, 랭킹, 푸시 등의 기능은 내외부 API가 수행할 것입니다.
🧱 유니티/언리얼의 주요 역할
유니티와 언리얼은 주로 클라이언트 개발에 집중된 엔진입니다.
주요 역할:
- 3D/2D 렌더링
- 물리 엔진 처리
- UI 구성
- 애니메이션 시스템
- 오디오 처리
- 일부 네트워크 기능
그렇기 때문에 유니티, 언리얼이 기획자에게 프로토타이핑 툴로도 쓰일 수 있는 것입니다. 반면, 주 역할이 아닌 것은 다음과 같습니다.
- 게임 서버 로직 개발 (멀티플레이 동기화, 매치메이킹 등)
- 데이터베이스 저장/조회
- 인증, 과금, 이벤트 운영
- 대시보드/운영툴 개발
- 로그 수집, 분석
그렇지만 앞서 나왔던 캐주얼 퍼즐 장르처럼 비교적 단순한 게임의 경우, 클라이언트가 게임의 주요 로직을 처리하기도 합니다.
🧰 주요 기술 스택
게임 클라이언트, 서버, 인프라/DevOps 분야의 주요 기술 스택을 정리하면 다음과 같습니다.
🎮 클라이언트
기능 | 기술 스택 |
---|---|
그래픽/물리/애니메이션 | Unity, Unreal Engine |
UI | 엔진 내 UI 시스템, TextMeshPro 등 |
오디오 | FMOD, Wwise 등 |
네트워크 | WebSocket, TCP/UDP, Photon, Mirror 등 |
🧠 서버
기능 | 기술 스택 |
---|---|
게임 로직 | Java, Node.js, C#, C++ 등 |
데이터 저장 | MySQL, MongoDB, Redis, Cassandra 등 |
세션/매치메이킹 | 자체 구현 또는 BaaS (PlayFab, Nakama 등) |
인증/결제 | OAuth, Firebase Auth, AWS Cognito 등 |
🛠 인프라 및 DevOps
- 인프라: Docker, Kubernetes, AWS/GCP
- 배포/CI: GitHub Actions, Jenkins, ArgoCD
- 모니터링/로깅: Prometheus, Grafana, ELK, Sentry
- 콘텐츠 배포: CDN 기반 패치 시스템
✅ 마무리
게임 개발은 처음 접하면 유니티, 언리얼로 모든 걸 다 할 수 있을 것 같지만, 실제로는 복잡한 분산 시스템과 다양한 기술 스택이 함께 움직이는 종합 개발입니다.
웹이나 앱 개발에 익숙한 사람이라면, 서버 아키텍처, 통신 구조, DevOps 등 익숙한 개념들이 게임에서도 적용되지만, 실시간성과 사용자 경험에 훨씬 민감한 환경이라는 점이 차이점입니다.
처음 게임 개발을 알아보시는 다른 분들에게도 이 글이 도움되었길 바라며 마치겠습니다.