게임 운영 패러다임의 전환
지금까지 우리는 클라우드가 IaaS, PaaS, SaaS로 나뉘며, '직접 구축'에서 '위임과 조립'으로 게임 운영이 변화하는 과정을 살펴봤습니다.
이제 이런 질문이 생길 수도 있을 것입니다.
“서버리스(Serverless)는 그다음 단계인가요?”
“정말 서버가 사라진다는 뜻인가요?”
결론부터 말하면, 서버리스는 서버가 없다는 뜻이 아닙니다.
서버리스란 서버를 직접 관리하지 않아도 되는 구조,
즉 운영의 주체가 '사람'에서 '클라우드'로 옮겨간 개념입니다.
예전에는 서버를 띄우고, 네트워크를 구성하고, 배포·모니터링·확장·복구까지 모두 사람이 담당했습니다.
서버리스에서는 이 모든 과정이 자동화된 환경에서 실행됩니다.
운영자는 "언제 어떤 작업을 실행할지"만 정의하면 됩니다.
서버는 여전히 존재하지만, 직접 관리하지 않습니다.
운영이 사라진 것이 아니라, 운영의 주체가 클라우드로 바뀐 것입니다.
그 결과 게임사는 인프라 관리보다, 플레이어 경험과 콘텐츠 품질에 집중할 수 있게 되었습니다.
서버리스는 '이벤트가 발생할 때만 실행되는 구조(Event-driven)'입니다.
예를 들어,
• 플레이어가 로그인할 때
• 결제가 완료될 때
• 이벤트 보상이 지급될 때
즉, 서버의 입장에서 새로운 동작이 필요할 때마다 발생하는 특정 상황이 생기면,
이 순간에만 함수(Function)가 실행되고, 작업이 끝나면 즉시 종료됩니다.
따라서 사용량이 없을 때는 과금도 발생하지 않습니다.
이 덕분에 서버리스는 "비용 효율적이고, 변동 트래픽에 강한 운영 구조"로 평가받고 있습니다.
서버리스는 특히 단기 트래픽이나 이벤트형 기능에서 강점을 가집니다.
즉, 서버리스는 “필요할 때만 작동하는 스마트한 인프라"입니다.
운영 효율뿐 아니라, 시장 변화에 맞춰 빠르게 실험할 수 있는 환경을 제공합니다.
EA의 Apex Legends는 전 세계 수천만 명이 동시에 접속하는 대규모 멀티플레이어 게임입니다.
초기에는 직접 서버를 운영했지만,
글로벌 이벤트나 시즌 업데이트 때마다 급격히 늘어나는 트래픽이 큰 부담으로 작용했습니다.
개발 스튜디오인 Respawn은 이러한 한계를 해결하기 위해 Amazon GameLift 로 이전을 선택했습니다.
Amazon GameLift는 완전한 서버리스는 아니지만, 자동 확장(Auto Scaling)과 복구 기능이 내장된 관리형 인프라(Managed Infrastructure)로 분류됩니다.
AWS와 파트너사는 Respawn과 함께 단계적이며 위험을 최소화한 마이그레이션 계획을 설계했습니다.
기존 코드 변경을 최소화했고,
서비스 중단이나 대규모 QA 없이도 안정적으로 전환할 수 있는 환경을 마련했습니다.
작은 지역부터 순차적으로 트래픽을 이동시키며 안정성을 검증했고,
결국 단 10일 만에 수백만 명 규모의 플레이어를 새로운 인프라로 이전했습니다.
전환 이후 효과는 매우 명확했습니다.
전 세계 평균 지연 시간은 30% 감소했고, 일부 지역에서는 최대 50%까지 개선되었습니다.
패킷 손실률도 글로벌 평균 5% 줄어 전반적인 품질이 향상되었습니다.
기존에 15종으로 나뉘어 있던 하드웨어 구성은 두 가지 유형으로 통합되었고,
이 과정에서 매치메이킹 로직과 운영 효율성도 크게 개선되었습니다.
반복적으로 겪어온 러버밴딩과 히트 판정 문제 역시 눈에 띄게 줄었습니다.
Respawn은 작업 완료 후 “이제 우리는 서버가 아니라 플레이어 경험에 집중한다”라고 밝혔습니다.
서버를 완전히 제거한 구조는 아니지만,
'서버를 직접 관리하지 않는(Serverless Approach)' 운영 방식이
서비스 안정성, 비용 효율성, 운영 속도를 모두 개선했다는 점을 분명히 보여줍니다.
* 러버밴딩 현상? 게임 내에서 캐릭터가 움직이다가 마치 고무줄처럼 이전 위치로 되돌아오는 현상입니다. 주로 네트워크 지연으로 인해 발생하며, 서버와 클라이언트 간 데이터 교환에 문제가 생겼을 때 나타납니다
Riot Games는 리그 오브 레전드와 발로란트를
전 세계에서 동시에 서비스하며, 대규모 실시간 트래픽을 처리해야 하는 대표적인 사례입니다.
Riot은 매치 데이터 분석과 리플레이 처리, 글로벌 이벤트 대응을 위해
AWS Lambda 등을 적용한 서버리스 아키텍처를 도입했습니다.
특정 리전에 유저가 몰리면 필요한 순간에만 함수가 작동하고,
트래픽이 줄면 즉시 종료되는 구조로 설계되어 있습니다.
"우리는 더 이상 서버 증설을 고민하지 않습니다. 운영의 목표는 오직 플레이어 경험의 품질 유지입니다."
— Riot Engineering Blog
이처럼 Riot은 서버리스적 운영 철학(Serverless Mindset)을 통해
자동화·확장·분석 중심의 운영으로 민첩성을 확보하고 있습니다.
서버리스 철학을 가장 먼저 실현한 곳은 Supercell입니다.
"우리는 서버를 관리하지 않는다. 우리는 게임에만 집중한다."
— Supercell Tech Talk (AWS re:Invent)
지금의 EA, Riot 등이 이 철학을 대규모로 확장하고 있을 뿐입니다.
잠깐! 관리형 인프라와 관리형 서비스는
사용자가 직접 시스템을 관리하지 않고, 전문 플랫폼이 대신 운영해 주는 형태를 말합니다.
• 관리형 인프라(Managed Infrastructure):
서버나 네트워크를 대신 관리해 주는 구조 (예: RDS, EC2 Auto Scaling)
→ 정수기 필터를 정기 교체해 주는 서비스와 유사
• 관리형 서비스(Managed Service):
특정 기능을 자동으로 처리해 주는 구조 (예: Lambda, Firebase Functions)
→ 주문이 들어오면 자동으로 조리 시작하는 주방 시스템과 비슷
서버리스는 모든 게임에 정답이 되지는 않습니다.
비즈니스 담당자라면 다음 질문을 통해 "우리 서비스에 적합한 구조인가?"를 판단할 수 있습니다.
• 우리 게임의 트래픽은 일정한가, 변동이 큰가?
→ 변동이 크다면 서버리스가 효율적입니다.
• 운영팀의 핵심 역량은 인프라 관리인가, 콘텐츠 운영인가?
→ 후자라면 관리형 또는 서버리스 구조가 적합합니다.
• 개발과 배포 주기는 얼마나 짧은가?
→ 빠른 릴리즈와 테스트 환경에는 자동 확장이 필수입니다.
• 비용 구조는 고정비 중심인가, 사용량 기반인가?
→ 서버리스는 "OPEX 중심의 유연한 구조"를 만듭니다.
이 질문들은 "서버를 없앨까?"가 아니라, "운영의 주체를 누구로 둘까?"를 묻는 대화입니다.
서버리스는 서버를 없애는 기술이 아니라,
운영을 자동화하고 실행 중심으로 전환하는 사고방식입니다.
게임 운영의 초점이 '얼마나 안정적으로 유지되는가'에서 '얼마나 빠르게 대응할 수 있는가'로 바뀐 지금,
서버리스는 기술을 넘어 게임 비즈니스의 민첩성을 실현하는 구조적 혁신입니다.
다음 글에서는,
클라우드 위에서 데이터를 다루는 구조,
즉 데이터 파이프라인과 실시간 분석이 게임 비즈니스의 의사결정을 어떻게 바꾸는지 살펴보겠습니다.
* 위 내용은 저자의 개인적인 의견이며, 본문에서 언급된 기업의 공식적인 입장과는 무관합니다