안녕하세요. 쿡앱스 기술팀에서 DevOps 엔지니어로 일하고 있는 오평석입니다. 저희 팀의 DevOps 파트에서는 2023년부터 쿡앱스의 서버 인프라 환경을 현대화하는 작업을 하고 있습니다. 현대화 이후 출시되는 모든 게임의 서버는 Kubernetes 플랫폼 위에서 운영하는 것을 기조로 삼고 있습니다. 이에 대한 이야기를 Games on AWS 2023에서 발표할 수 있는 기회가 있었는데요. 아무래도 발표는 시간 제한이 있는 만큼 발표 주제에 대해 더 집중하고자 자세히 다루지 못한 이야기가 있습니다. 발표 이후 약 2년 동안 클러스터를 운영하면서 얻은 경험도 공유하고 싶어 아티클로 풀어보고자 합니다.

인프라 현대화의 시작

쿡앱스 기술팀은 각 스튜디오가 더 효율적으로 프로젝트를 개발할 수 있도록 회사 전반의 기술적 의사결정에 깊이 참여하고 있습니다. 저 역시 처음에는 클라이언트 개발자로서 Unity 패키지 레지스트리 구성, 빌드·배포 자동화, 빌드 클러스터 구축 등을 담당하다가 DevOps 엔지니어로 전환하며 업무 범위를 넓히게 되었습니다.

직군을 전환한 뒤 가장 먼저 한 일은 기존 서버 인프라를 점검하고, 서버 개발자들이 어떤 부분에서 어려움을 겪고 있는지 파악하는 것이었습니다. 그 과정에서 <광전사키우기> 엔지니어에게 배포 과정이 번거롭고, 신규 서버 배포 누락 사고가 자주 발생한다는 문제를 공유받았습니다.

당시 게임 서버는 PHP 기반 비동기 웹 애플리케이션으로, 각 EC2 인스턴스에 Nginx와 PHP-FPM을 설치해 운영하고 있었습니다. 문제는 신규 버전 배포 방식이었는데, IDE의 원격 접속 기능으로 인스턴스에 하나씩 접속해 소스 파일을 수동으로 교체하는 방식이라 실수가 잦을 수밖에 없었습니다.

직접 인스턴스에 SSH로 접속하여 배포하던 시절

일정 규모 이상의 서비스에서는 인스턴스를 직접 외부에 노출하지 않고, 로드밸런서를 두어 트래픽을 분산하며 인스턴스를 유연하게 늘리고 줄이는 구조를 사용합니다. <광전사키우기> 서버도 AWS의 ELB + Auto Scaling 그룹을 통해 CPU 사용량에 따라 인스턴스 수가 자동으로 조정되는 방식이었죠.

문제는 배포 과정이었습니다. 배포를 위해서는 Auto Scaling 그룹에 등록된 인스턴스를 IDE의 호스트 리스트와 수동으로 동기화해야 했고, 특히 무중단 배포 시에는 실시간으로 유저 트래픽을 받고 있어 인스턴스 변경이 발생할 수 있는 안정적이지 않은 방식이었습니다. 이 문제를 해결하기 위해 당시에는 AWS의 CodeDeploy를 사용했습니다. 신규 버전 코드를 S3에 업로드하면 Auto Scaling 그룹에 Blue-Green 방식으로 배포되도록 구성했고, 이 배포 과정을 GitHub Actions에서 버튼 한 번으로 트리거할 수 있도록 설정해 팀에 안내했습니다. 작업 자체는 어렵지 않았지만, 기존 인프라가 어떻게 구성되고 사용되고 있는지 전반을 살펴볼 좋은 기회가 되었습니다. 그 과정에서 두 가지 문제가 특히 신경 쓰였는데요.

CodeDeploy를 사용한 Blue-Green 배포

첫 번째는 인프라 구성 방식의 파편화입니다. 그동안 쿡앱스는 프로젝트별 서버 개발자가 각자의 방식대로 인프라를 구축해 왔고, 콘텐츠 개발이 우선이다 보니 인프라를 지속적으로 개선하기 어려웠습니다. 실제로 전수조사 결과, 오래된 인스턴스 세대 사용, 보안적으로 취약한 네트워크 구성 등 개선해야 할 지점이 많았습니다.

두 번째는 문서화 부족입니다. 인프라 구성과 배포 방식이 작업자 개인의 기억에 의존하고 있어, 인수인계나 재구성 시 큰 불편이 있었고, 히스토리가 소실된 리소스도 적지 않았습니다. 이러한 환경은 서버에 문제가 생겼을 때 담당자 외의 엔지니어가 도움을 주기 어려운 사일로(silo) 상황을 만들기도 했습니다. 이 문제들을 해결하기 위해, 회사 전체에서 공통적으로 사용할 수 있는 일관된 인프라 환경이 필요하다고 판단했고, 그 결과 쿡앱스는 현재 게임 서버 운영의 기반이 되고 있는 Kubernetes 플랫폼을 도입하게 되었습니다.

Kubernetes의 도입

인프라 현대화를 시작하면서 반드시 도입해야 한다고 판단한 것은 두 가지였습니다. 첫 번째는 코드형 인프라(IaC)입니다. 쿡앱스는 오랜 기간 AWS 기반으로 여러 게임을 운영해 왔지만, 인프라 구성과 배포 방식에 대한 문서가 거의 없었고 대부분의 작업이 AWS 콘솔에서 수동으로 이루어졌습니다. 이는 자동화와 재현성 측면에서 한계가 있었습니다. IaC를 도입하면 인프라를 코드로 관리할 수 있어 문서화 부담을 줄이고, 코드만으로도 리소스 구성을 파악할 수 있다는 장점이 있습니다.

두 번째는 컨테이너 도입입니다. 다양한 언어와 프레임워크로 개발된 여러 게임을 운영하려면 실행 환경을 표준화하는 것이 중요했습니다. 여러 방법을 검토했지만, 엔지니어들에게 익숙하면서도 표준을 잘 따르는 방식은 컨테이너라고 판단했습니다. 문제는 컨테이너를 어떤 플랫폼에서 운영할지였습니다. AWS만 보더라도 EC2 직접 운영, Lambda, ECS 등 다양한 선택지가 있으며 각각 장단점이 존재합니다. 기술팀은 현재와 미래의 운영 환경을 고려해 여러 대안을 검토한 끝에 Kubernetes가 가장 적합한 선택이라고 결론을 내렸습니다.

왜 Kubernetes였는가?

이 질문에 답하려면 먼저 회사 상황을 간단히 짚고 넘어갈 필요가 있습니다. 쿡앱스는 전 세계 유저를 대상으로 100개 이상의 게임을 서비스하고 있습니다. 이렇게 다양한 게임들을 안정적으로 운영하기 위해서는 프로덕션 환경에서 충분히 검증된 컨테이너 오케스트레이션 플랫폼이 필요했습니다. 그렇다면 운영이 더 간편한 AWS ECS를 사용하면 되지 않는가 하는 질문이 나올 수 있습니다. 실제로 <포트리스 사가> 글로벌 버전은 ECS로 운영되고 있고, 관련 경험도 있습니다. 그런데도 Kubernetes를 선택한 이유는 다음과 같습니다.

벤더 종속 피하기
Kubernetes의 높은 안정성
활발한 Kubernetes 생태계

첫째, 벤더 종속을 피하고 싶었습니다. 지금은 AWS를 사용하고 있지만, 향후 다른 클라우드나 온프레미스를 사용할 가능성을 완전히 배제할 수는 없습니다. Kubernetes는 대부분의 클라우드에서 매니지드 서비스로 제공되고, 온프레미스에서도 쉽게 설치해 운영할 수 있어 환경 변화에 유연하게 대응할 수 있습니다.

둘째, Kubernetes는 이미 충분히 검증된 플랫폼입니다. 초기와 달리 지금은 안정성이 높아졌고, 많은 회사들이 프로덕션에서 운영하며 베스트 프랙티스를 공유하고 있습니다. 게임 업계에서도 Kubernetes 도입 사례가 늘고 있어 도입 리스크가 크지 않다고 판단했습니다.

셋째, Kubernetes 생태계가 매우 활발하다는 점입니다. 확장성, 자가 복구, 다양한 배포 전략, 롤백 등 프로덕션 운영에 필요한 기능들의 대부분을 기본 제공하거나 생태계 도구로 쉽게 보완할 수 있습니다. 우리가 직접 모든 기능을 개발하지 않아도 되므로 핵심 비즈니스에 더 집중할 수 있는 환경을 만들 수 있습니다.

물론 고민도 많았습니다. 특히 우리 조직이 DevOps 문화를 받아들일 수 있을지 확신하기 어려웠습니다. 당시에도 명확한 답을 내리긴 어려웠지만, 기존 인프라 운영의 문제점에 모두 공감했고, 팀의 역량을 믿고 Kubernetes 도입을 결정하게 되었습니다.

GitOps 그리고 서비스 배포의 자동화

플랫폼을 정한 뒤 가장 먼저 진행한 일은 EKS 클러스터와 필요한 인프라 리소스를 프로비저닝하고, 서비스 배포 파이프라인을 구축하는 것이었습니다. 인프라 구성은 Terraform을 이용해 비교적 수월하게 마쳤지만, 문제는 구축된 EKS 클러스터에 어떤 방식으로 배포를 자동화할 것인가였습니다. 자연스럽게 GitOps 방식이 후보로 떠올랐습니다. GitOps는 Git을 단일 진실의 원천으로 사용해 배포를 관리하므로, 변경 이력 추적이 쉽고 휴먼 에러를 줄이며 일관성과 재현성을 높일 수 있습니다.

엔지니어들이 Git에 익숙하다는 점도 도입에 유리했습니다. 하지만 GitOps를 어떻게 구현할지가 새로운 고민이었습니다. 단순히 환경별 매니페스트를 저장하고 스크립트로 배포하는 방식은 아쉬웠습니다. 엔지니어가 플랫폼을 전부 알 필요는 없지만, Kubernetes 리소스가 어떤 의미를 갖는지는 이해할 수 있어야 한다고 생각했기 때문입니다.

이들을 과도하게 추상화하지 않고, 가능한 한 Kubernetes의 개념이 자연스럽게 드러나도록 하고 싶었습니다. 이를 위해 여러 GitOps 구현체와 Kubernetes IDE 등을 검토했고, 결국 비교적 보편적인 CD 도구를 도입해 제공되는 웹 UI로 리소스를 시각화하고 상태를 확인하는 방식으로 결정했습니다.

각종 리소스를 한 눈에 알아볼 수 있는 ArgoCD Web UI

이렇게 해서 Kubernetes용 GitOps 구현체인 ArgoCD를 도입하게 되었습니다. 엔지니어가 애플리케이션을 수정해 Git에 커밋하면, 이를 기반으로 이미지를 빌드해 레지스트리에 업로드합니다. 새로운 이미지가 푸시되면 해당 태그로 애플리케이션을 배포하는 PR이 자동으로 생성되고, 엔지니어가 이를 확인해 메인에 병합하면 ArgoCD가 변경 사항을 감지해 EKS에 새 버전을 자동으로 배포하도록 구성했습니다. 이후 세부적인 방식이나 병합 규칙은 일부 조정되었지만, ArgoCD를 중심으로 한 배포 방식은 지금까지 그대로 유지되고 있습니다.

ArgoCD를 활용한 서비스 배포

마치며

구축한 Kubernetes 플랫폼은 2022년 하반기에 회사에 도입되었습니다. 초기에는 사내 Unity 패키지 레지스트리 같은 내부 서비스 위주로 운영했지만, 2023년 상반기 <테일드 데몬 슬레이어: 라이즈> 출시를 통해 프로덕션 운영 경험을 쌓을 수 있었습니다. 이를 계기로 현재 개발 중인 게임들도 기존보다 더 안정적으로 서비스할 수 있다는 확신이 생겼고, 이후 쿡앱스의 모든 신규 게임 서버는 Kubernetes 위에서 운영하는 것을 원칙으로 삼게 되었습니다. 물론 이 과정이 순탄하지만은 않았습니다. 짧은 기간 동안 새로운 개념과 도구들이 한꺼번에 도입되었고, 인프라 관리 방식과 DevOps 문화를 정착시키기 위해 많은 노력이 필요했습니다.

그럼에도 지금까지 안정적으로 운영해 올 수 있었던 것은 문제를 함께 공감하고 해결해 나가려는 분위기, 그리고 서로의 경험을 적극적으로 공유하는 문화 덕분이었다고 생각합니다. 다음 2부에서는 Kubernetes 플랫폼을 운영하며 얻은 경험, 변화된 점들, 그리고 앞으로의 로드맵에 대한 이야기를 전달드리겠습니다.