우리가 실제로 해결하려 했던 문제
돌이켜보면, 우리는 두 가지 문제를 동시에 해결하려 했습니다. 즉, 대규모의 동시 접속자 (concurrent players)를 처리할 수 있는 확장 가능한 엔진의 필요성과, 전략적 사고에 보상을 주는 복잡한 로직 기반 게임의 요구사항이었습니다. 우리는 이 두 가지를 모두 처리할 수 있는 단일 시스템을 구축하기만 하면 모든 것이 해결될 것이라고 생각했습니다. 하지만 결과적으로 이는 재앙을 초래하는 레시피가 되었습니다.

우리가 처음 시도했던 것 (그리고 실패한 이유)
우리는 게임 로직과 확장성을 동시에 다루려는 거대한 모놀리식 코드베이스 (monolithic codebase)를 구축하는 것으로 시작했습니다. 우리는 게임의 각기 다른 측면을 처리하는 마이크로서비스 (microservices)의 복잡한 혼합물을 사용했고, 트래픽을 분산하기 위해 맞춤형 로드 밸런서 (load balancer)를 사용했습니다. 우리는 이것이 쉽게 확장하고 새로운 기능을 빠르게 추가할 수 있게 해줄 것이라고 생각했습니다. 하지만 실제로는 관리하기가 악몽처럼 변했습니다. 각 마이크로서비스는 자신만의 데이터베이스를 가졌고, 데이터 불일치 (data inconsistencies)가 쌓이기 시작했습니다. 플레이어들이 서로 다른 보물 위치를 보는 현상이 발생했고, 시스템 전체가 불안정해지기 시작했습니다.

아키텍처 결정
시스템을 계속 가동하기 위해 고군분투하던 중, 우리는 과감한 결정을 내렸습니다. 다른 아키텍처에 집중하여 엔진 전체를 처음부터 다시 구축하기로 한 것입니다. 우리는 관심사 분리 (separation of concerns)가 명확한 서비스 지향 아키텍처 (SOA)를 채택하기로 결정했습니다. 모든 게임 상태 (game state)를 처리하는 데이터 스토어 (data store)와 게임 로직을 처리하는 단일 마이크로서비스를 생성했습니다. 서비스 간의 통신을 처리하기 위해 메시지 브로커 (message broker)를 사용했고, 장애를 처리하기 위해 서킷 브레이커 (circuit breaker) 패턴을 구현했습니다. 또한 남용을 방지하기 위한 속도 제한 (rate limiting) 메커니즘과 전체 시스템을 모니터링하기 위한 강력한 로깅 (logging) 시스템을 구현했습니다.

수치가 말해주는 것
새로운 시스템은 놀라운 결과였습니다. 지연 시간 (lag)이 90% 감소했고, "보물을 찾을 수 없음" 오류의 수가 거의 제로에 가깝게 떨어졌습니다. 우리는 아무런 문제 없이 동시 접속자 수가 500% 증가하는 상황을 처리할 수 있었습니다.

시스템은 안정적이었으며, 엔지니어링 팀은 새로운 기능을 추가하고 게임 경험을 개선하는 데 집중할 수 있었습니다. 만약 제가 이 모든 과정을 처음부터 다시 해야 한다면 다르게 할 점: 만약 제가 모든 과정을 다시 수행해야 한다면, 처음부터 훨씬 더 단순한 아키텍처 (Architecture)에 집중했을 것입니다. 게임 로직 (Game logic)의 관심사를 확장성 (Scalability) 및 데이터 저장 (Data storage) 관련 관심사와 분리했을 것입니다. 단일한 모놀리식 코드베이스 (Monolithic codebase)로 시작하여, 필요에 따라 점진적으로 더 작은 서비스들로 리팩터링 (Refactor)했을 것입니다. 또한 개발 주기 (Development cycle) 초기 단계에서 문제를 감지할 수 있는 견고한 테스트 프레임워크 (Testing framework)를 구축하는 데 집중했을 것입니다. 한꺼번에 너무 많은 문제를 해결하려 하기보다는, 시스템을 더 유연하고 관리하기 쉽게 만들었을 것입니다. Veltrix에서의 경험을 되돌아보며, 우리는 게임을 거의 망칠 뻔했던 몇 가지 근본적인 실수들을 저질렀음을 깨닫습니다. 하지만 결국, 이는 우리에게 단순함, 유연성, 그리고 세심한 계획의 중요성을 가르쳐 준 가치 있는 학습 경험이었습니다.