2021년 출시 이후 대한민국 MMORPG(Massively Multiplayer Online Role-Playing Game) 역사의 한 획을 그은 라이온하트 스튜디오 개발, 카카오게임즈 퍼블리싱의 **'오딘: 발할라 라이징(Odin: Valhalla Rising)'**은 단순한 흥행작을 넘어 클라우드 네이티브 게임 개발의 모범 사례로 꼽혀왔습니다. 출시 초기부터 아마존 웹 서비스(AWS)의 관리형 서비스(Managed Service)를 적극적으로 활용하여 동시 접속자 수 수십만 명에 달하는 트래픽을 안정적으로 처리해냈으며, 이는 '심리스(Seamless) 오픈월드'라는 게임의 정체성을 유지하는 핵심 기반이었습니다.
그러나 2024년 하반기부터 2025년에 걸쳐 카카오게임즈는 전사적인 인프라 비용 효율화 및 계열사 간 시너지 강화를 목적으로, 오딘의 핵심 백엔드 인프라를 AWS에서 자사의 클라우드 서비스인 **카카오클라우드(Kakao Cloud, 구 Kakao i Cloud)**로 이전하는 대규모 마이그레이션을 단행했습니다. 이 프로젝트는 표면적으로 약 40%에 달하는 인프라 운영 비용 절감과 최신 AMD EPYC 프로세서 도입이라는 성과를 달성했으나 2, 실제 서비스 환경에서는 심각한 성능 저하를 초래했습니다.
사용자들은 서버 이전 직후부터 간헐적인 연결 끊김(Disconnection), 캐릭터 위치 동기화 오류(Rubber-banding), 로딩 시간 지연(Loading Stalls), 그리고 대규모 전투 시 발생하는 극심한 입력 지연(Input Lag)을 호소했습니다.3 본 보고서는 이러한 현상이 단순한 초기 안정화 단계의 시행착오가 아니라, 클라우드 서비스 제공자(CSP) 간의 아키텍처 성숙도 차이와 관리형 서비스의 부재에서 기인한 구조적 문제임을 기술적으로 입증하고자 합니다. 특히 데이터베이스 I/O 처리량, 네트워크 토폴로지, 그리고 컴퓨팅 가상화 기술의 차이를 중심으로 오딘의 성능 저하 원인을 심층 분석합니다.
2. AWS 기반 레거시 아키텍처 분석: 고성능의 기준점
오딘이 AWS 환경에서 보여준 안정적인 퍼포먼스는 단순한 서버 호스팅의 결과가 아니었습니다. 이는 AWS가 수십 년간 축적해 온 게임 특화 솔루션과 글로벌 인프라의 유기적인 결합 덕분이었습니다. 카카오클라우드로의 이전 후 발생한 문제를 정확히 진단하기 위해서는, 먼저 AWS 환경에서 오딘이 어떤 기술적 혜택을 누리고 있었는지 '베이스라인(Baseline)'을 확립해야 합니다.
2.1. 데이터베이스 계층: Amazon Aurora의 독보적 아키텍처
MMORPG의 심장은 데이터베이스(DB)입니다. 수만 명의 유저가 동시에 아이템을 획득하고, 경험치를 얻고, 재화를 거래하는 모든 행위는 DB의 트랜잭션(Transaction)으로 기록됩니다. 오딘은 AWS의 Amazon Aurora를 메인 DB로 채택하여 극한의 쓰기(Write) 부하를 견뎌냈습니다.
Amazon Aurora는 기존 MySQL 대비 최대 5배의 처리량(Throughput)을 제공하는 것으로 알려져 있습니다.5 이러한 성능 차이는 근본적인 아키텍처의 차이에서 비롯됩니다.
로그 구조화 스토리지(Log-Structured Storage): 일반적인 데이터베이스가 데이터를 디스크에 쓸 때 데이터 페이지와 로그를 모두 기록하며 I/O 병목을 유발하는 반면, Aurora는 로그 레코드만을 스토리지 노드로 전송합니다. 이는 네트워크 트래픽을 획기적으로 줄이고, DB 엔진이 스토리지 I/O 대기 시간(Wait Time) 없이 트랜잭션을 처리할 수 있게 합니다.
쿼럼(Quorum) 쓰기 방식: Aurora는 데이터를 3개의 가용 영역(AZ)에 6개의 사본으로 분산 저장합니다. 6개 중 4개의 노드에서 쓰기 확인이 되면 트랜잭션이 완료된 것으로 간주하므로, 단일 스토리지 노드의 성능 저하가 전체 DB 성능에 영향을 미치지 않습니다.
즉각적인 읽기 복제본(Read Replica) 확장: 대규모 공성전이나 이벤트 발생 시 읽기 부하가 급증할 경우, Aurora는 최대 15개의 읽기 복제본을 밀리초(ms) 단위의 지연 시간으로 동기화하여 부하를 분산합니다.
이러한 기술적 특성 덕분에 오딘은 AWS 환경에서 '서버 렉'이라 불리는 DB 처리 지연 없이 대규모 트래픽을 소화할 수 있었습니다.
2.2. 네트워크 계층: AWS Global Accelerator와 엣지 컴퓨팅
게임 클라이언트와 서버 간의 통신 속도는 물리적 거리에 비례하지만, 네트워크의 품질(Jitter, Packet Loss)은 라우팅 경로에 따라 결정됩니다. AWS는 전 세계에 수백 개의 엣지 로케이션(PoP)과 사설 광케이블 백본망을 보유하고 있습니다.
오딘은 AWS Global Accelerator를 활용하여 사용자의 트래픽을 공용 인터넷망이 아닌 AWS의 사설망으로 전송했습니다.7 사용자가 게임에 접속하면 가장 가까운 AWS 엣지 로케이션으로 연결되고, 이후 서버까지는 혼잡 없는 AWS 백본망을 통해 데이터가 전송됩니다. 이는 인터넷 서비스 제공자(ISP)의 라우팅 정책 변경이나 공용망의 혼잡도와 관계없이 일정한 핑(Ping)과 낮은 패킷 손실률을 보장했습니다.
2.3. 컴퓨팅 계층: Nitro System의 최적화
오딘의 게임 서버는 윈도우(Windows) 운영체제 기반으로 구동됩니다.1 윈도우 서버는 리눅스 대비 무겁고 오버헤드가 크기 때문에 가상화 환경에서의 최적화가 필수적입니다. AWS의 Nitro System은 하이퍼바이저 기능을 전용 하드웨어 칩으로 오프로드(Offload)하여, 가상 머신(EC2)이 호스트 CPU 성능의 거의 100%를 사용할 수 있게 합니다. 이는 1ms의 지연도 허용되지 않는 실시간 게임 로직 처리에 있어 결정적인 안정성을 제공했습니다.
3. 카카오클라우드 마이그레이션의 전략적 배경과 실행
2024년 말부터 본격화된 카카오클라우드로의 이전은 기술적 필요보다는 비즈니스 논리에 의해 주도되었습니다.
3.1. 비용 절감과 내재화의 유혹
카카오게임즈는 오딘의 인프라를 카카오클라우드로 이전함으로써 약 40%의 비용 절감 효과를 기대했습니다.2 AWS와 같은 글로벌 CSP는 데이터 전송료(Egress Fee)와 관리형 서비스(RDS, Aurora 등) 이용료에 높은 마진을 부과합니다. 반면, 계열사인 카카오엔터프라이즈의 인프라를 사용할 경우 이러한 비용 구조를 내부 거래로 전환하여 획기적으로 낮출 수 있습니다.
또한, 카카오엔터프라이즈 입장에서는 자사의 클라우드 기술력을 입증할 강력한 레퍼런스가 필요했습니다. 오딘과 같은 초대형 트래픽을 처리하는 게임을 자사 클라우드에서 성공적으로 구동한다면, 이는 기술적 성숙도를 시장에 증명하는 결정적인 계기가 될 것이기 때문입니다.
3.2. 하드웨어의 업그레이드: AMD EPYC Genoa 도입
카카오클라우드는 마이그레이션의 핵심 이점으로 최신 하드웨어의 도입을 내세웠습니다. 특히 AMD의 4세대 EPYC 프로세서인 Genoa를 탑재한 BCS m3az 인스턴스를 제공했습니다.2 이 프로세서는 기존 AWS에서 사용하던 구형 인스턴스 대비 높은 클럭 속도와 코어 밀도를 제공하며, 단일 스레드 성능이 중요한 게임 서버 로직 처리에 유리할 것으로 판단되었습니다.
그러나 이러한 하드웨어 스펙의 우위는 소프트웨어 스택과 네트워크 아키텍처의 열세를 상쇄하지 못했습니다. 인프라의 성능은 단순히 CPU의 속도(Clock Speed)만으로 결정되지 않으며, I/O 처리량과 네트워크 안정성이 결합된 종합적인 결과물이기 때문입니다.
4. 성능 저하의 기술적 근본 원인 분석 (Root Cause Analysis)
사용자들이 경험하고 있는 "렉(Lag)"은 단일 원인에 의한 것이 아닙니다. 이는 데이터베이스 처리량의 한계, 네트워크 라우팅의 비효율성, 그리고 가상화 환경의 튜닝 부재가 복합적으로 작용한 결과입니다.
4.1. 'Aurora Void' 현상: 데이터베이스 I/O 병목
가장 치명적인 문제는 AWS Amazon Aurora를 대체할 만한 고성능 DB 엔진의 부재입니다. 카카오클라우드로 이전하면서 오딘의 데이터베이스는 표준형 MySQL(또는 MariaDB) 기반으로 재구축되었을 가능성이 높습니다. 이 과정에서 'Aurora Void(오로라의 부재)' 현상이 발생했습니다.
4.1.1. 공유 스토리지 아키텍처의 상실
Amazon Aurora는 컴퓨팅과 스토리지가 분리된 아키텍처를 통해 스토리지 I/O 병목을 해결했습니다. 그러나 카카오클라우드의 일반적인 DB 인스턴스는 블록 스토리지(EBS 형태)에 데이터를 기록하는 방식입니다.
문제점: 대규모 공성전이나 필드 보스 레이드 시, 초당 수만 건의 쓰기 요청(Write Ops)이 발생합니다. 표준 MySQL은 이러한 요청을 처리하기 위해 디스크에 데이터 페이지를 동기식으로 기록해야 합니다. 이때 디스크의 IOPS(초당 입출력 횟수) 한계에 도달하면, DB는 더 이상 트랜잭션을 처리하지 못하고 대기 상태(Lock)에 빠집니다.
현상: 게임 서버는 DB의 응답을 기다리느라 멈추게 되고, 유저는 캐릭터가 움직이지 않거나 스킬이 나가지 않는 현상을 겪습니다. 이는 네트워크 지연이 아닌 **서버 사이드 렉(Server-side Lag)**입니다.
4.1.2. 복제 지연(Replication Lag)의 증가
오딘은 읽기 부하를 분산하기 위해 다수의 읽기 전용 DB(Slave DB)를 사용합니다. Aurora는 물리적 스토리지를 공유하므로 복제 지연이 거의 없지만(10ms 미만), 표준 MySQL의 복제 방식(Binlog Replication)은 네트워크를 통해 로그를 전송하고 재실행하는 과정을 거칩니다.
문제점: 트래픽이 폭주할 때 복제 지연이 수 초(seconds) 단위까지 늘어날 수 있습니다.
현상: 유저가 인벤토리를 열거나 거래소를 조회할 때, 이미 획득한 아이템이 보이지 않거나 몬스터의 체력이 잘못 표시되는 등의 데이터 불일치 현상이 발생합니다.
4.2. 네트워크 토폴로지의 퇴보: 공용망 의존도 증가
AWS는 전 세계를 연결하는 사설 백본망을 보유하고 있어, 인터넷의 불안정성을 최소화할 수 있습니다. 반면, 카카오클라우드는 국내 ISP(KT, SKT, LGU+)와의 피어링(Peering) 및 공용 인터넷망에 의존합니다.
4.2.1. 엣지 가속의 부재
AWS Global Accelerator의 부재는 치명적입니다. AWS 환경에서는 사용자의 트래픽이 집 근처의 AWS 엣지 노드로 진입하여 최단 경로로 서버에 도달했습니다. 그러나 카카오클라우드 환경에서는 사용자의 트래픽이 각 ISP의 라우터를 거쳐 카카오의 데이터센터(판교 또는 가산 등)로 이동해야 합니다.
홉(Hop) 수 증가: 중간 경유지가 많아질수록 패킷 손실(Packet Loss)과 지터(Jitter) 발생 확률이 높아집니다.
BGP 라우팅 불안정: ISP 간의 트래픽 교환 지점에서 병목이 발생하거나, 최적 경로가 아닌 우회 경로로 트래픽이 전송될 경우 핑(Ping)이 급격히 튀는 현상이 발생합니다.
4.2.2. 로컬 피어링의 한계
카카오클라우드가 국내 ISP 3사와 직접 연동(Direct Peering)을 맺고 있다 하더라도 13, 이는 AWS의 글로벌 백본망이 제공하는 대역폭과 다중화 수준에는 미치지 못합니다. 특히 특정 시간대(저녁 8시~11시)에 트래픽이 몰릴 경우, ISP와 데이터센터 간의 연결 구간(Interconnection)에서 대역폭 포화가 발생할 수 있습니다. 이는 "핑은 낮은데 반응이 느린" 전형적인 혼잡 현상을 유발합니다.
4.3. 컴퓨팅 가상화와 윈도우 스케줄러의 부조화
AMD EPYC Genoa 프로세서의 도입은 원가 절감에는 유리했지만, 윈도우 기반 게임 서버에는 최적화 과제를 안겨주었습니다.
4.3.1. 칩렛(Chiplet) 구조와 NUMA 이슈
AMD 프로세서는 여러 개의 작은 칩(CCD)을 하나로 묶은 칩렛 구조를 가집니다. 코어 간 통신이 칩 내부에서 이루어질 때는 빠르지만, 칩 간 통신이 필요할 때는 지연 시간이 발생합니다.
문제점: 윈도우 스케줄러가 게임 서버의 스레드를 이 칩 저 칩으로 옮겨가며 실행할 경우(Context Switching), 캐시 적중률이 떨어지고 미세한 처리 지연이 발생합니다.
현상: 평균 프레임(FPS)은 높게 나오더라도 하위 1%의 프레임(1% Low)이 급락하는 마이크로 스터터링(Micro-stuttering) 현상이 발생합니다. 유저는 이를 "툭툭 끊기는 느낌"으로 받아들입니다.
4.3.2. 하이퍼바이저 오버헤드
AWS의 Nitro System은 가상화 오버헤드를 거의 '0'으로 만들었지만, 카카오클라우드의 KVM 기반 가상화는 여전히 호스트 OS의 자원을 일부 소모합니다. 실시간성이 극도로 중요한 MMORPG 서버에서는 이러한 미세한 오버헤드 차이가 전체적인 반응 속도 저하로 이어질 수 있습니다.
5. 비교 분석: AWS vs. 카카오클라우드 게이밍 성능 지표
다음은 오딘의 인프라 이전에 따른 주요 기술 지표의 변화를 비교 분석한 표입니다.
기술 요소 (Technical Component)
AWS 아키텍처 (이전 전)
카카오클라우드 아키텍처 (이전 후)
성능 영향 (Performance Impact)
데이터베이스 엔진
Amazon Aurora (Cloud-Native)
MySQL / MariaDB (IaaS/PaaS)
치명적 (Critical): I/O 병목으로 인한 트랜잭션 락 발생, 서버 멈춤 현상 주원인.
복합적 (Mixed): 절대 성능은 우수하나, 윈도우 스케줄러 및 NUMA 최적화 난이도 상승.
엣지 로케이션
글로벌 수백 개 PoP (CloudFront)
국내 데이터센터 중심 (Centralized)
높음 (High): 라스트 마일(Last Mile) 구간의 품질 보장 불가.
운영 비용 (OPEX)
고비용 구조 (관리형 서비스 프리미엄)
약 40% 절감 (저비용 구조)
트레이드 오프 (Trade-off): 비용 효율성은 달성했으나 서비스 품질 희생.
이 표에서 확인할 수 있듯이, 카카오클라우드로의 이전은 컴퓨팅 파워(CPU) 부문에서는 일부 스펙 상승이 있었으나, 데이터베이스 처리량과 네트워크 안정성이라는 MMORPG의 핵심 성능 지표에서는 명확한 아키텍처적 후퇴(Regression)가 발생했습니다.
6. 사용자 경험(UX)과 현상학적 분석
기술적 원인들은 실제 게임 플레이에서 구체적인 불편함으로 발현됩니다. 오딘 유저들이 겪고 있는 대표적인 현상들을 기술적 관점에서 재해석합니다.
6.1. "로딩 지옥"과 텔레포트 지연
서버 이전 후 가장 빈번하게 보고된 문제는 맵 이동 시 로딩이 멈추거나, 텔레포트를 탔는데 화면이 검게 변한 뒤 한참 후에야 이동되는 현상입니다.
원인 분석: 맵 이동은 DB에 대한 '읽기(Read)' 요청이 집중되는 작업입니다. 캐릭터의 좌표 정보를 저장하고, 이동할 맵의 데이터를 불러오고, 주변의 다른 유저 정보를 동기화해야 합니다. DB의 I/O가 포화 상태이거나 복제 지연이 발생하고 있다면, 게임 서버는 DB로부터 데이터를 받아올 때까지 클라이언트에게 "기다리라"는 신호를 보냅니다. 이것이 바로 무한 로딩의 정체입니다
6.2. "고무줄 현상" (Rubber-banding)
캐릭터가 앞으로 이동했다가 다시 제자리로 돌아오는 현상입니다.
원인 분석: 이는 클라이언트와 서버 간의 위치 동기화 실패입니다. 클라이언트는 유저의 입력을 받아 캐릭터를 앞으로 이동시켰지만(예측 이동), 서버는 네트워크 패킷 손실이나 처리 지연으로 인해 해당 이동 명령을 제때 받지 못했거나 처리하지 못했습니다. 서버는 "너는 아직 거기에 있다"라고 판단하고, 클라이언트에게 강제로 위치 수정 명령을 내립니다. 카카오클라우드의 네트워크 경로상에서 발생한 패킷 손실(Packet Loss)이나 서버 로직의 처리 지연(Tick Rate Drop)이 주원인입니다.
6.3. 대규모 전투 시의 스킬 씹힘
공성전 등 다대다 전투에서 스킬 버튼을 눌러도 반응이 없는 현상입니다.
원인 분석: 이는 전형적인 DB 쓰기 병목(Write Bottleneck) 현상입니다. 공격 판정, 데미지 계산, HP 차감 등의 과정은 모두 트랜잭션으로 처리되어야 합니다. Aurora가 아닌 일반 DB 환경에서는 수천 명의 동시 타격을 실시간으로 커밋(Commit)할 수 있는 IOPS를 확보하기 어렵습니다. DB가 락(Lock)을 걸면, 게임 서버의 로직도 멈추게 되어 입력이 무시됩니다.
7. 대응 및 안정화: 사후약방문의 한계와 노력
카카오게임즈와 라이온하트 스튜디오는 사태의 심각성을 인지하고 2024년 말부터 2025년 상반기에 걸쳐 지속적인 "서버 안정화" 작업을 진행했습니다.
7.1. 데이터베이스 샤딩(Sharding)과 쿼리 최적화
Aurora의 성능 부재를 메우기 위해 개발팀은 데이터베이스 샤딩을 도입했을 가능성이 높습니다. 이는 거대한 하나의 DB를 여러 개의 작은 DB로 쪼개어 부하를 분산시키는 기술입니다. 또한, 불필요한 DB 쓰기 작업을 줄이기 위해 게임 로그 기록 방식을 배치(Batch) 형태로 변경하거나, 캐싱(Caching) 레이어(Redis 등)를 강화하여 DB 접근을 최소화하는 애플리케이션 레벨의 최적화가 수행되었습니다.
7.2. 네트워크 경로 튜닝
초기의 라우팅 불안정을 해결하기 위해 ISP와의 협력을 통해 오딘 트래픽에 대한 우선순위 처리(QoS)를 요청하거나, 라우팅 경로를 수동으로 최적화하는 작업이 병행되었을 것입니다.
7.3. 보상 정책과 유저 달래기
기술적 해결이 지연됨에 따라, 카카오게임즈는 잦은 점검에 대한 보상으로 인게임 아이템을 지급하며 민심을 달래는 데 주력했습니다.3 그러나 이는 근본적인 해결책이 될 수 없으며, 유저들의 신뢰를 회복하기에는 역부족이었습니다.
8. 결론 및 시사점: 인프라는 비용이 아닌 경쟁력이다
오딘: 발할라 라이징의 카카오클라우드 마이그레이션 사태는 클라우드 인프라가 단순한 '서버 임대'가 아님을 극명하게 보여주는 사례입니다. 40%의 비용 절감이라는 재무적 성과는 달성했으나, 그 대가로 게임의 핵심 가치인 **플레이 경험(User Experience)**을 훼손했습니다.
이번 분석을 통해 도출된 핵심 결론은 다음과 같습니다.
관리형 서비스의 중요성: AWS Amazon Aurora와 같은 클라우드 네이티브 DB 서비스는 단순한 편의 기능이 아니라, 극한의 트래픽을 처리하기 위한 필수적인 아키텍처 요소입니다. 이를 일반적인 IaaS 환경으로 대체하는 것은 기술적 퇴보를 의미합니다.
네트워크 품질의 격차: 글로벌 CSP의 사설 백본망과 로컬 CSP의 피어링 기반 네트워크는 안정성 면에서 체급 차이가 존재합니다. 특히 0.1초의 반응속도가 중요한 게임에서는 이 차이가 명확하게 드러납니다.
최적화의 난이도: 하드웨어 스펙(CPU 성능)이 좋다고 해서 무조건 성능이 향상되는 것은 아닙니다. 운영체제, 하이퍼바이저, DB 엔진 간의 정교한 튜닝 없이는 최신 하드웨어의 성능을 100% 끌어낼 수 없습니다.
결국, 오딘의 사례는 **"클라우드 회귀(Cloud Repatriation)"**가 비용 절감의 만병통치약이 될 수 없음을 시사합니다. 특히 고성능을 요구하는 게이밍 워크로드의 경우, 인프라의 안정성이 곧 게임의 품질이자 경쟁력임을 명심해야 합니다. 향후 카카오클라우드가 진정한 엔터프라이즈급 클라우드로 도약하기 위해서는, 단순히 하드웨어를 제공하는 것을 넘어 AWS Aurora나 Global Accelerator에 준하는 고성능 관리형 서비스를 자체적으로 개발하고 확보해야 할 것입니다.
P.S . AI로 검색한 내용입니다. 여러가지 검증된 기사 등의 내용으로 작성한 것이라 거짓은 없을 겁니다. 카카오게임즈 / 라이온하트스튜디오의 책임자 누구든 수많은 버그와 렉현상에 대해 유저들이 알아듣고 이해할 수 있도록 정중하게 해명을 요구하는 바 입니다. 2탄을 기대해 주세요.
첫댓글 개추
글 맨 밑 라디오 틀으시고 같이 봐보세요!
모기님 내용이 어려운 듯 하여 상단으로 AI 음성 개요를 올렸습니다. 영상 잘 보고 있습니다.
라디오처럼된거 들으니깐 바로이해되네