우리가 실제로 해결하고 있었던 문제

나는 여러 개의 Hytale 서버를 운영하는 팀에서 일하고 있으며, 우리가 직면했던 가장 좌절스러운 문제 중 하나는 보물찾기 엔진(treasure hunt engine)이었습니다. 플레이어들이 완료할 수 있는 보물 지도와 도전 과제를 생성하는 시스템을 만드는 것이라 충분히 간단해 보였습니다. 하지만 현실은 훨씬 더 복잡했습니다. 우리의 초기 구현 방식은 서버 충돌(server crashes)부터 잘못된 보물 위치에 이르기까지 수많은 문제로 고통받았습니다. 가장 최악인 부분은 투명성의 부족이었습니다. 플레이어들은 종종 고장 난 보물찾기에 대해 불만을 제기했지만, 우리는 문제를 빠르게 확인하거나 수정할 방법이 없었습니다. 우리는 높은 수준의 커스터마이징(customization)을 약속하는 Veltrix 설정을 사용했지만, 실제로는 그것이 양날의 검이었습니다. 시스템의 유연성 때문에 문제의 근본 원인을 정확히 짚어내는 것이 어려웠습니다. 나는 무엇이 잘못되고 있는지 이해하기 위해 설정 파일들을 꼼꼼히 살펴보며 수없이 많은 시간을 보냈습니다. 우리의 오류율(error rate)은 약 30%였으며, 이는 모든 보물찾기의 거의 3분의 1이 어떤 방식으로든 실패하고 있음을 의미했습니다.

우리가 처음 시도했던 것 (그리고 왜 실패했는가)

처음에 우리는 Veltrix 설정을 미세 조정함으로써 문제를 해결하려고 시도했습니다. 우리는 시스템이 보물 지도를 생성하는 방식에 문제가 있다고 생각하여 이벤트 생성 설정을 조정했습니다. 하지만 이 접근 방식은 상황을 악화시키기만 하는 것 같았습니다. 오류율은 약간 감소했지만, 서버 충돌은 더 빈번해졌습니다. 우리는 또한 Veltrix 설정 위에 커스텀 솔루션(custom solution)을 구현하려고 시도했지만, 이는 시스템에 새로운 복잡성을 더했습니다. 코드베이스(codebase)는 비대해졌고, 유지보수하거나 디버깅(debug)하기가 어려워졌습니다. 우리는 Java와 Python을 조합하여 사용하고 있었으며, 보물찾기 데이터를 저장하기 위해 MySQL 데이터베이스를 사용하고 있었습니다. 하지만 문제를 해결하려고 노력하면 할수록, 문제는 점점 더 우리의 손을 빠져나가는 것처럼 보였습니다. 가장 최악인 점은 보물찾기 엔진의 궁극적인 목표였던 플레이어들에게 좋은 경험을 제공할 수 없었다는 사실입니다.

아키텍처 결정 (The Architecture Decision)
보물찾기 엔진 (treasure hunt engine)으로 몇 달간 고군분투한 끝에, 우리는 한 걸음 물러나 우리의 접근 방식을 재평가해야 한다는 것을 깨달았습니다. 우리는 커스텀 솔루션 (custom solution)을 포기하고 Veltrix 설정을 최적화하는 데 집중하기로 결정했습니다. 하지만 이번에는 더 구조적인 접근 방식을 취했습니다. 우리는 보물찾기 엔진을 개별 구성 요소로 분해하고 각각을 별도로 분석했습니다. 시스템의 주요 병목 현상 (bottlenecks)을 식별하였고, 그에 따라 최적화 노력을 우선순위에 따라 배치했습니다. 우리가 내린 핵심 결정 중 하나는 관계형 데이터베이스 (relational database)에서 NoSQL 데이터베이스, 구체적으로는 MongoDB로 전환하는 것이었습니다. 이를 통해 보물찾기 엔진에서 생성되는 방대한 양의 데이터를 더 효율적으로 처리할 수 있었습니다. 또한 Redis를 사용하여 캐싱 레이어 (caching layer)를 구현하였는데, 이는 데이터베이스의 부하를 줄이고 성능을 향상시켰습니다. 아키텍처 결정은 단순히 기술에 관한 것이 아니었습니다. 그것은 견고하고(robust), 확장 가능하며(scalable), 유지보수가 용이한(easy to maintain) 시스템을 만드는 것에 관한 것이었습니다.

수치가 말해준 것 (What The Numbers Said)
새로운 아키텍처를 구현한 후, 우리는 보물찾기 엔진의 성능에서 상당한 개선을 확인했습니다. 오류율 (error rate)은 초기 30%에서 대폭 감소한 약 5% 수준으로 떨어졌습니다. 서버 충돌 (server crashes)은 빈도가 낮아졌으며, 문제없이 더 많은 수의 동시 접속 플레이어 (concurrent players)를 처리할 수 있었습니다. 우리는 또한 전반적인 플레이어 경험의 개선도 확인했습니다. 보물찾기는 더욱 몰입감 있게 변했고, 플레이어들은 문제없이 이를 완료할 수 있었습니다. 우리는 새로운 아키텍처의 성공을 측정하기 위해 플레이어 참여도 (player engagement), 오류율 (error rates), 시스템 가동 시간 (system uptime)과 같은 지표 (metrics)를 사용했습니다. 또한 정기적인 코드 리뷰 (code reviews)를 실시하고 시스템이 보안과 확장성을 위한 모범 사례 (best practices)를 따르고 있는지 확인했습니다. 수치들은 마침내 의도한 대로 작동하는 시스템의 이야기를 들려주었습니다. 보물찾기 엔진은 플레이어들에게 도전적이고 즐거운 경험을 생성하고 있었으며, 우리는 이를 용이하게 유지 관리하고 업데이트할 수 있었습니다.

내가 다르게 했을 것들

돌이켜보면, 나는 몇 가지 사항을 다르게 했을 것입니다. 첫째, 처음부터 더 구조적인 접근 방식 (structured approach)을 취했을 것입니다. 문제를 개별 구성 요소로 세분화하고 각각을 별도로 분석했을 것입니다. 또한 시스템의 주요 병목 현상 (bottlenecks)을 기반으로 최적화 노력을 우선순위에 두었을 것입니다. 둘째, Veltrix 설정 위에 커스텀 솔루션 (custom solution)을 구현할 때 더 주의를 기울였을 것입니다. 코드가 깔끔하고, 모듈화 (modular)되어 있으며, 유지보수하기 쉽도록 보장했을 것입니다. 마지막으로, 처음부터 지표 (metrics)와 플레이어 피드백에 더 많은 주의를 기울였을 것입니다. 데이터를 사용하여 의사결정을 내리고 그에 따라 시스템을 조정했을 것입니다. 이 경험은 복잡한 문제에 대해 구조적인 접근 방식을 취하는 것의 중요성과 의사결정을 이끌어내기 위해 데이터를 사용하는 가치를 가르쳐 주었습니다. 또한 때로는 가장 단순한 솔루션이 최선의 솔루션이며, 과도한 엔지니어링 (over-engineering)은 해결하는 것보다 더 많은 문제를 일으킬 수 있다는 점을 보여주었습니다.