20년 넘게 뉴 에덴을 움직여 온 것은 게이트 점프도 함대전도 아닌, 그 아래 깔린 방대한 파이썬 코드다. EVE 온라인 개발사는 'EVE Evolved' 이니셔티브의 일환으로 이 코드베이스를 파이썬 2에서 파이썬 3로 옮기는 대장정을 공식화했다. 지난 7월 테스트 서버 싱귤래리티(Singularity)에서 플레이어들이 검증한 첫 변경분이 이번에 본 서버 트랭퀼리티(Tranquility)에 배포됐다. 개발사가 정의한 성공의 기준은 역설적이다. 이 마이그레이션은 플레이어에게 '전혀 눈치채이지 않아야' 하며, 가끔 무언가가 조금 더 매끄럽게 돌아간다고 느끼는 순간이 예외의 전부여야 한다.
16년 묵은 언어를 왜 지금 바꾸나
EVE는 2003년 스택리스 파이썬(Stackless Python) 위에서 출발했다. 스택리스는 가벼운 '태스크릿(tasklet)'으로 서버 노드 하나가 수천 명의 파일럿을 동시에 처리하도록 해 주는 파이썬 변형이며, 개발사는 단순 사용자를 넘어 이 프로젝트의 주요 기여자 중 하나가 됐다. 2007년 스택리스 2.5, 2010년 2.7로 올린 것이 마지막 버전 변경이었다. 파이썬 2.7은 2020년 공식 지원 종료(EOL)를 맞았고 소프트웨어 업계 전체가 넘어갔지만, EVE는 그대로 남았다. 16년간 같은 버전에 머물렀다는 사실 자체가 그 조합이 얼마나 안정적이었는지를 방증한다. 위험이 큰 대규모 마이그레이션을 정당화할 이유가 없었던 것이다.
지금 이유가 생긴 근거는 세 가지로 요약된다. 첫째는 성능이다. 최근 파이썬 3 릴리스들은 언어 역사상 손꼽히는 속도 개선을 담아 왔고, 이는 함대전과 마켓 허브처럼 부하가 몰리는 구간을 더 빠르게 만들 여지를 연다. 다만 개발사는 그 개선이 구체적으로 어느 정도일지는 아직 말하기 이르다고 선을 그었다. 둘째는 생태계다. 현대적인 라이브러리·디버거·프로파일러는 모두 파이썬 3 기준으로 만들어지며, 2에 머무는 해가 길어질수록 개발사가 직접 유지보수해야 할 몫이 늘어난다. 셋째는 언어 자체의 정돈이다. 문자열 타입이 하나로 통일돼 현지화가 안정되고, 정수는 크기 제한 없이 자동으로 커지며, 클래스 체계도 레거시 동작이 제거돼 일관성이 높아진다.
240만 줄을 어떻게 옮기나
핵심 과제는 규모다. EVE 코드베이스는 약 240만 줄의 파이썬으로 이뤄져 있고, 상당 부분은 파이썬 2.7 이전, 심지어 2.3~2.5 시절 규격으로 작성돼 파이썬 3가 아예 파싱을 거부한다. 게다가 트랭퀼리티는 23년치 코드뿐 아니라 23년치 실제 플레이어 데이터—모든 캐릭터, 스킬 포인트, 격납고의 자산, 지갑의 ISK—를 그대로 이고 있으며, 하루 24시간 중 23.75시간을 멈추지 않고 돌아가야 한다. 개발사는 목적지가 도달 가능하다는 근거로, 자사 카본(Carbon) 엔진을 현대 파이썬 3 위에서 돌리는 EVE 프론티어(Frontier)를 든다. 프론티어 마이그레이션은 파이썬의 마이너 버전 12개, 즉 16년치 언어 진화를 한 프로젝트에서 넘긴 사례였다.
작업은 단계로 나뉜다. 지금 진행 중인 1단계는 코드가 여전히 파이썬 2.7에서 돌아가는 상태로 '파이썬 3 준비'를 마치는 것이다. 여기에는 파이썬 커뮤니티가 만든 Python-Future 도구가 쓰인다. 이 도구는 파이썬이 이런 마이그레이션을 위해 배포했던 2to3 코드 재작성 엔진 위에 서 있으며, 낡은 패턴 하나하나를 파이썬 2.7과 3가 모두 받아들이는 형태로 자동 변환하는 '픽서(fixer)'를 적용한다.
산이 아니라 측정 가능한 언덕
얼마나 남았는지를 개발사는 추측하지 않고 측정한다. 약 2만 개의 파이썬 파일 각각을 실제 파이썬 2.7 인터프리터와 3 인터프리터로 모두 컴파일해, 컴파일러를 파싱 여부의 '기준 진실'로 삼았다. 첫 스캔 결과는 반가운 편이었다. 95.9%의 파일이 이미 양쪽에서 컴파일됐고, 파이썬 3가 거부하는 문법을 쓴 '차단 라인'은 240만 줄 중 약 3,300줄에 불과했다. 그중에는 EVE가 존재하기도 전에 폐기된 문법의 예외 처리 구문 약 600개, 많은 현역 개발자가 실물로 본 적 없는 '같지 않음' 표기 가 50건 섞여 있었다.
진짜 어려움은 그다음이다. 같은 스캔은 양쪽에서 문제없이 컴파일되지만 '동작이 달라지는' 코드를 약 2만 줄로 집계했다. 교과서적 사례가 나눗셈이다. 파이썬 2에서 1/2는 0이지만 파이썬 3에서는 0.5다. EVE에서 그 숫자가 데미지든 ISK든 좌표든, 이런 라인은 기계적 치환이 아니라 사람의 판단을 요구한다. 이것이 2단계의 몫이며, 1단계가 먼저인 이유이기도 하다. 기계적으로 걷어낼 수 있는 잔해를 먼저 치워, 사람의 주의가 꼭 필요한 곳에만 가도록 만드는 것이다.
한국의 실무자에게 이 사례가 주는 함의는 분명하다. 레거시 언어·런타임 이전은 '큰 산'처럼 보이지만, 컴파일러를 기준으로 전수 스캔해 차단 라인과 의미 변경 라인을 정량화하면 산은 관리 가능한 언덕이 된다. 자동화 도구로 처리할 수 있는 부분과 반드시 사람이 읽어야 하는 부분을 분리하고, 후자를 위해 전자를 먼저 끝낸다는 순서 설계도 참고할 만하다. 다만 개발사 스스로 인정하듯 지금까지는 쉬운 쪽이었다. 한 줄씩 눈으로 읽어야 하는 의미 변경 코드가 남은 진짜 고비이며, EVE는 앞으로도 싱귤래리티 플레이테스트를 통해 실 부하에 가까운 조건에서 검증을 이어 갈 계획이다. 에이전트 미션 백엔드 역시 파이썬 3 준비 대상에 올랐지만, 의도대로라면 플레이어는 아무것도 느끼지 못할 것이다.