23년 된 EVE Online은 왜 2026년에야 Python 3로 움직였나

2003년에 서비스를 시작한 게임이 2026년에도 운영되고 있습니다. 그것만으로도 놀라운 일입니다. EVE Online의 Python 3 전환은 운영 중인 소프트웨어를 바꾸는 일이 왜 어려운지 잘 보여주는 사례입니다.

Python 3는 이미 17년 전에 나왔습니다

Python 3의 첫 정식 버전은 2008년에 공개됐습니다. Python 2의 공식 지원도 2020년에 끝났습니다.

달력만 놓고 보면 의문이 생깁니다. EVE Online은 왜 이렇게 늦게 움직였을까요.

개발팀이 게을러서였다고 단순하게 보기는 어렵습니다. EVE Online은 2003년에 출시된 온라인 게임입니다. Python 3가 세상에 나오기 전부터 실제 이용자를 받고 있었습니다.

차이는 여기서 생깁니다. 새 프로젝트라면 Python 3를 선택하면 그만입니다. 하지만 기존 서비스에서는 수년간 쌓인 코드와 도구를 하나하나 확인해야 합니다.

EVE Online의 연식은 23년입니다. 지금까지 남아 있는 코드는 낡아서 살아남은 것이 아닙니다. 수많은 장애와 업데이트를 견디면서 실제로 작동해 왔기에 남은 코드입니다.

언어를 바꾸는 일이 코드 번역으로 끝나지 않는 이유

Python 2와 Python 3는 이름만 비슷할 뿐, 동작 방식까지 같지는 않습니다. 대표적인 예가 문자열입니다.

Python 2에서는 문자와 바이트의 경계가 비교적 느슨했습니다. 반면 Python 3에서는 두 개념을 명확히 구분합니다. 채팅 메시지나 캐릭터 이름처럼 사람이 읽는 정보는 문자열입니다. 네트워크로 보내거나 파일에 저장하는 값은 바이트일 수 있습니다.

둘을 잘못 섞어도 평소에는 멀쩡해 보일 수 있습니다. 그러다 특정 언어가 포함되거나 오래된 데이터가 들어오는 순간 오류가 발생합니다.

나눗셈 결과나 사전 자료형을 다루는 방식도 달라졌습니다. 예전 코드가 숫자 5를 기대하던 자리에서 5.0을 받을 수 있습니다. 반복 중인 데이터를 변경할 때도 과거와 다르게 작동할 수 있습니다.

일반적인 웹사이트라면 오류를 고친 뒤 다시 배포하면 그만입니다. 하지만 MMO에서는 작은 차이가 전투 계산이나 아이템 처리, 거래 기록처럼 서로 얽힌 시스템으로 번질 수 있습니다. 문법을 고치는 것보다 동일한 결과가 나오는지 증명하는 일이 더 어렵습니다.

가장 큰 장애물은 코드가 아니라 운영입니다

오래된 자동차의 엔진을 교체한다고 생각해 봅시다. 정비소에 세워 놓고 작업하면 그나마 수월합니다. EVE Online의 상황은 이용자가 타고 달리는 자동차의 엔진을 바꾸는 데 가깝습니다.

온라인 게임에는 캐릭터와 아이템만 있는 게 아닙니다. 전투, 경제, 길드, 임무, 결제, 운영 도구가 서로 얽혀 있습니다. 과거에 만든 외부 라이브러리와 사내 개발 도구도 영향을 받습니다.

한 번에 전환하면 작업 속도는 빠를 수 있습니다. 대신 문제가 생겼을 때 어디서 비롯됐는지 찾기가 어렵습니다. 기존 환경과 새 환경을 오랫동안 함께 유지하면 위험은 줄어듭니다. 그 대신 개발팀은 같은 기능을 두 환경에서 관리해야 합니다.

테스트도 쉽지 않습니다. 자동 테스트가 통과했다고 해서 실제 우주에서도 문제가 없으리라는 보장은 없습니다. 20년 이상 축적된 이용자 행동은 개발팀이 작성한 테스트 시나리오보다 훨씬 복잡하기 때문입니다.

결국 마이그레이션의 핵심은 최신 문법이 아닙니다. 서비스가 계속 돌아가는 동안 변경 범위를 관리하고, 이상이 생겼을 때 되돌릴 수 있는 운영 능력입니다.

기술 부채는 빚보다 임대료에 가깝습니다

기술 부채는 흔히 갚아야 할 빚에 비유됩니다. 하지만 저는 오래된 온라인 서비스에서는 임대료에 더 가깝다고 봅니다.

구형 환경을 유지하는 동안에도 계속 비용이 들기 때문입니다. 최신 개발 도구를 적용하기는 점점 어려워집니다. 보안 업데이트와 라이브러리 선택의 폭도 좁아집니다. 새로 합류한 개발자는 오래된 방식부터 익혀야 합니다.

그렇다고 무조건 빨리 청산하는 게 정답은 아닙니다. 전환 작업에 투입된 개발자는 그동안 새로운 콘텐츠를 만들기 어렵습니다. 이용자 눈에는 그래픽이나 게임 기능은 그대로인데 개발 비용만 늘어난 것처럼 보일 수도 있습니다.

그래서 기업은 대개 기술 부채가 있다는 이유만으로 움직이지 않습니다. 기존 환경을 유지하는 비용과 전환 위험의 크기가 어느 순간 역전될 때 비로소 움직입니다.

EVE Online의 Python 3 전환이 늦어진 배경도 이런 관점에서 볼 필요가 있습니다. 왜 이제야 했느냐보다 어떻게 23년 동안 변경을 미루면서도 서비스를 유지했느냐가 더 흥미로운 질문입니다.

조용한 전환이 오히려 좋은 신호입니다

최근 한 달 동안 확인할 수 있는 관련 커뮤니티 논의는 매우 제한적입니다. 그래서 이용자 반응이나 댓글을 근거 없이 꾸며내 인용할 수는 없습니다.

다만 기반 기술의 전환은 원래 화제가 되지 않는 편이 낫습니다. 이용자가 언어 버전의 차이를 체감했다면 대개 장애가 생겼거나 성능이 떨어졌다는 뜻이기 때문입니다.

성공적인 마이그레이션의 결과가 화려한 신기능일 필요는 없습니다. 개발 속도가 조금 빨라지고 보안 위험이 줄어드는 것만으로도 의미가 있습니다. 여기에 다음 10년을 준비할 기반까지 마련됩니다. 이용자에게 아무 일도 일어나지 않는 상태가 개발팀에는 가장 큰 성과일 수 있습니다.

EVE Online의 사례를 보면 오래됐다는 이유만으로 나쁜 소프트웨어라고 할 수는 없습니다. 진짜 문제는 연식이 아니라 변경할 수 없는 구조입니다. 결국 살펴봐야 할 것은 지금 사용하는 서비스가 다음 세대 기술로 옮겨갈 준비를 했는지, 아니면 여전히 달리는 자동차 안에서 엔진 교체 시점만 고민하고 있는지입니다.