프론트엔드 개발자의 게임 플랫폼 서버 개발 체험기

나는 게임 회사에 웹 프론트엔드 엔지니어로 입사해, 게임 운영을 지원하는 어드민 툴과 사내 공통 UI 라이브러리 개발에 참여했다. 이 일은 꽤 흥미로웠지만, 내가 만든 기능이 실제 게임에 어떤 영향을 미치는지 체감하기는 어려웠다. 그래서 시간이 지나면서 우리가 만드는 게임을 더 깊이 이해하고 싶다는 갈증이 점점 커졌다. 다행히 회사에 타 직군 체험 프로그램이 있어, 이를 통해 플랫폼 서버 개발팀에 지원해 새로운 도전을 시작할 수 있었다. 

나는 기존에 익숙했던 환경과 언어를 떠나 새로운 팀에 적응하기 위해 노력했다. 초기에는 서버 개발팀의 코드 스타일과 작업 방식에 익숙해지고자 팀에서 사용 중인 주요 코드 베이스를 꼼꼼히 분석했다. 모르는 부분은 동료들에게 질문하며 하나씩 학습했고,  매일 새로운 기술과 개념을 메모하며 적응 속도를 높여나갔다. 서버 개발팀을 선택한 이유는 클라이언트와 반대의 입장에서 데이터를 설계, 처리하며, 시스템의 뒷단을 깊이 이해하고 싶었기 때문이다. ‘플랫폼 서버 개발’은 그동안 내가 접하지 못했던 새로운 세계를 보여줬고, 이번 글을 통해 어떤 경험을 했는지 공유하고자 한다.

게임 플랫폼 개발자는 어떤 일을 할까?

많은 사람들이 ‘게임 개발’이라는 말을 들으면, 게임 클라이언트 혹은 게임 서버 개발을 떠올린다. 편의상 ‘인게임 개발’이라는 용어를 사용하겠다. 인게임 개발은 게임 내 캐릭터의 움직임, 배경 요소, 이펙트 및 애니메이션 등을 처리하며, 주로 Unity나 Unreal Engine 같은 게임 엔진 위에서 동작한다. 반면, 플랫폼 개발은 웹 개발에 더 가깝다. 게임 엔진 개발과 플랫폼 개발은 기술적으로 매우 다르다.

이 두 영역은 중요하게 여기는 요소와 최적화의 초점이 크게 다르다. 인게임 개발에서는 초당 60프레임 이상의 성능을 유지하기 위해, GPU와 CPU를 활용한 최적화가 필수적이다. 또한 충돌 판정이나 물리 시뮬레이션 같은 실시간 연산이 요구된다. 예를 들어, 캐릭터가 움직이거나 공격하는 순간의 반응 속도가 몇 밀리초만 지연되어도 사용자 경험이 크게 악화될 수 있다.

반면, 플랫폼 개발은 주로 브라우저 환경에서 동작하며, 렌더링과 비동기 API 처리에 초점이 맞춰져 있다. 대부분의 웹 서비스는 상대적으로 실시간성이 덜 중요하며, 몇 초의 지연도 사용자 경험에 큰 영향을 미치지 않는 경우가 많다. 사용자들이 원하는 니즈가 다르기에, 기술적으로 더 중요하게 다루는 영역이 달라지는 것이다.

물론 인게임이 존재한다면 아웃게임도 있는 법이다. 게임 플랫폼은 바로 이 아웃게임 영역에 해당한다. 게임 플랫폼은 게임 바깥에서 플레이어가 게임을 실행하거나 관리할 수 있도록 지원하며, 소셜, 상점, 결제 같은 기능을 제공한다. 예를 들어, 소셜 기능에서는 친구 목록을 관리하고 실시간 채팅을 지원하며, 상점에서는 유저가 게임 아이템을 구매할 수 있는 직관적인 인터페이스를 제공한다. 

결제 기능은 다양한 결제 수단을 지원하여, 글로벌 유저가 편리하게 결제할 수 있도록 설계된다. 이러한 모든 기능은 게임 바깥에서의 유저 경험을 극대화하는 데 초점을 맞추고 있다.

처음 게임 플랫폼 개발을 접했을 때, 유저가 스토어에서 아이템을 구매하는 과정이 이커머스 서비스와 비슷하다는 인상을 받았다. 소셜 기능 역시 SNS나 메신저 서비스와 닮아 있었다. 즉, 게임 플랫폼은 일반적인 웹 서비스와 닮은 부분이 많았다.

서버팀에서 경험한 것들

나는 게임을 좋아해서 게임 회사에 입사한 만큼, 회사의 도메인에 큰 관심이 있었다. 새로운 기능에 대한 기획안이 논의되고, 이를 개발하고 릴리즈되는 과정을 지켜보며, 데이터 로직을 관리하고 개발의 중심을 잡아주는 서버 개발에 호기심이 생겼다. 서버 개발을 경험하면 우리 게임에 대해 더 깊이 이해할 수 있을 것 같았다.

직군 체험 요청이 받아들여지면서 반년간 서버팀에서 일하게 되었고, 이 과정에서 여러 경험을 했다.

아이템 처리 로직 설계

첫 번째로 유저가 아이템을 거래하는 로직을 분석하고, 서버 부하를 늘리지 않으면서 데이터 일관성을 유지하는 방안을 고민했다. 특히 인벤토리 데이터베이스 구조를 전체적으로 재설계하는 업무를 지켜볼 기회가 있었다. 인벤토리 서비스에서 담당하던 작업들을 각각의 역할을 가진 클래스들로 분리해 작업을 할당하고, 상호작용하도록 설계하는 과정이 매우 흥미로웠다.

트랜잭션 설계

두 번째로 데이터 일관성을 유지하기 위한 트랜잭션 설계를 배우며, 분산 환경에서 데이터 처리의 원리를 이해했다. 다소 시간이 걸리더라도 데이터 정합성이 가장 중요한 은행 시스템과는 달리, 게임에서는 기본적으로 실시간성이 보장되어야 하므로, 트레이드오프를 고려하여 트랜잭션 로직을 설계한다는 점에서 차이가 있었다.

큐 서비스 활용

다음으로 대규모 데이터를 안정적으로 처리하기 위해 AWS SQS 서비스를 사용하여 메시지 처리를 경험했다. 특히 서버 장애 상황에서 처리되지 못하는 메시지가 쌓이는 경험을 통해 라이브 서비스의 긴장감을 느낄 수 있었고, 디버깅 및 사후 처리를 통해 데드레터를 해결하며 안도감과 보람을 느낄 수 있었다.

게임 로그 분석

다음은 게임 로그 분석이다. 수집된 게임 로그 데이터를 활용하여 디버깅하고, 문제 상황을 파악하고 해결하는 과정이었다. 효율적으로 구현되어 있는 로그 모듈 코드를 뜯어 볼 수 있었는데, 데이터 저장 공간이 곧 비용으로 이어진다는 것을 깨달았다. 또한 로그 데이터를 저장하는 최적의 기간에 대해서도 생각해 볼 수 있었다. 

데이터 보안

DB 데이터를 암호화 및 복호화하는 과정도 배울 수 있었는데, 기초적인 수준의 보안 설계에 대해 고민해 보았다. 우선 여러 가지 암호화 알고리즘 가운데 현재 우리 상황에 가장 알맞은 알고리즘을 탐색했고, 이후 추상화된 암호화 레이어를 추가했다. 암호화 작업을 하며 성능과 보안 사이의 균형을 유지하는 설계의 중요성을 체감할 수 있었다.

어려웠던 점들

낯선 환경에 적응하기

아무래도 다른 직군의 직무를 체험해 본다는 것은 용기가 필요한 일이었다. 나는 팀의 방해꾼이 되고 싶지 않았고, 가능하면 도움이 되고 싶었다. 그래서 회사 내 위키에 새로 알게 된 것들을 정리하며, 반복적인 실수를 줄이기 위해 노력했다. 특히 C#이라는 새로운 언어와 .NET 환경, 멀티스레드 환경을 고려한 개발 등 낯선 것들이 많았다. 이는 직접 코드를 작성할 때뿐만 아니라, 팀원의 코드를 리뷰할 때도 큰 허들로 작용했다.

이를 극복하기 위해 LINQPad를 활용하여 실습 코드를 작성하며, 익숙해지는 데 많은 시간을 투자했다. 시간이 오래 걸리더라도 정확히 이해하고 숙지하는 데 집중했다. 이 팀에서 내가 할 일은 멋진 기능을 많이 만들고 가는 것이 아니라, 나에게도 학습이 되고 팀에도 도움이 되는 기능이나 개선 사항을 하나라도 잘 적용하고 가는 것이었다. 맨 처음 팀에 합류했을 때 이러한 다짐을 공유했고, 팀원들도 동의해 주어서, 큰 갈등이나 문제없이 팀에 융화될 수 있었다.

주요 업무에서의 어려움

내가 주도적으로 진행한 업무는 AWS SQS 서비스를 통해 서버 장애 상황에서 쌓이는 데드레터를 처리하는 것과 DB 데이터 암호화 레이어를 추가하는 작업이었다. 처리되지 못한 메시지가 데드레터로 남는 것 자체는 큰 문제가 아니다. 장애가 해소된 후에 재처리를 요청하면 대부분 해결되고, 그래도 안 된다면 서비스 로직에 문제가 있는 것이므로, 버그를 수정해서 배포한 후 재처리를 요청하면 해결되기 때문이다.

하지만 이번 경우에는 결론적으로 외부 협력사와의 API 통신 과정에서 문제가 생겼다. 해당 장애가 빠르게 해소되기 어려운 상황이었기 때문에 데드레터 재처리가 불가능했다. 그렇게 많은 양의 요청이 처리되지 못하는 것은 정말 당황스러웠다. 원인을 파악하기 위해 하나씩 살펴보는 과정도 쉽지 않았고, 데드레터 큐가 과부하되지 않도록, 주기적으로 추려두는 작업도 처음에는 어려웠다. 나름 자바스크립트와 타입스크립트를 많이 사용해 봤다고 생각했는데, 일괄작업을 위한 스크립트를 짜는 과정에서 이런저런 실수를 했다. 그동안 단지 익숙한 패턴의 코딩만을 해왔다는 사실도 깨닫게 되었다.

DB 암호화 작업에서는 유연한 설계와 추상화를 많이 고민해야 했다. 암호화할 도큐먼트를 제외하고 다른 도큐먼트들은 영향을 받지 않아야 했다. 혹시라도 추후에 암호화를 적용할 도큐먼트가 추가된다면, 손쉽게 추가할 수 있어야 한다는 목적을 두고 작업했다. 이 작업을 하면서 특히 우리 서비스 스펙에 대한 이해도가 넓어졌다. 기존 서비스 코드들을 많이 읽어보면서 라이프사이클 관리 방식을 살펴보았다. 테스트 환경을 세팅해서 각각의 서비스들을 띄워 데이터를 주고받는 과정을 테스트해 보면서 업무에 대한 해상도가 높아지는 기분을 느꼈다.

그리고 여러 예외 상황을 맞닥뜨려 디버깅하면서, 서버 개발은 단순히 데이터를 핸들링해서 전달하는 역할을 넘어, 시스템의 여러 디테일한 요소들은 물론, 버그 상황에서의 최종 판단까지 담당하고 있다는 것을 알게 되었다.

마치며: 풀스택 개발자가 되려는 건 아니지만

이번 직무 체험은 플랫폼 서버 개발을 통해 시스템의 뒷단을 깊이 이해하는 계기가 되었다. 이 과정에서 나는 데이터 설계와 처리의 중요성을 배우고, 실시간성과 데이터 일관성 사이에서 균형을 유지하는 방법을 깨달았다. 이러한 경험은 개발자로서의 사고 방식을 확장시켰으며, 시스템의 핵심을 이해하는 중요한 전환점이 되었다. 서버 개발은 프론트 개발과는 확실히 달랐다. 평소와 반대의 입장에서 데이터를 설계하고 처리하며, 더 나은 의사소통과 협업 방식을 배울 수 있었다. 

나는 풀스택 개발자를 꿈꾸고 있지는 않지만, 이번에 서버 개발을 경험한 게 큰 자산이 될 거라는 확신이 들었다. 상대의 입장을 이해하기 위해서는 직접 그 입장이 되어보는 것만큼 좋은 것은 없기 때문이다. 그리고 게임 플랫폼 서버의 업무에 직간접적으로 참여하는 과정을 통해 우리 게임의 전반적인 스펙을 더 깊이 이해할 수 있었다. 앞으로도 이러한 경험을 바탕으로 개발자로서의 성장을 이어가고 싶다.

무엇보다 이번 경험은 단순히 기술적 성장을 넘어, 나를 더 넓은 시야를 가진 개발자로 만들어 주었으며, 새로운 도전에 대한 자신감도 키울 수 있었다. 앞으로도 이 경험을 바탕으로 나만의 개발 철학을 정립하고, 더 나은 결과물을 만들어낼 수 있도록 노력해 볼 것이다.

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.