〈소닉 레이싱 크로스월드〉: EOS를 활용한 크로스플레이 구현

이 문서가 원문에 더한 것

발표는 EOS를 이미 아는 청중을 전제로 진행됐습니다. 그래서 이 문서에는 EOS의 서비스 구성, Lobbies와 Sessions의 차이, P2P가 연결을 맺는 순서, 릴레이 모드의 호환성 제약, 스레드 어피니티 API를 에픽게임즈 공식 문서로 확인해 “기초 다지기” 블록으로 덧붙였습니다. 발표를 듣지 않은 사람도 각 판단의 근거를 따라갈 수 있게 하는 것이 목적입니다.

콘솔 팀과 아케이드 팀이 융합된 구성

중요한 것은 EOS 도입과 온라인 콘텐츠 개발을 아케이드 팀이 중심이 되어 시작^[3]했다는 점입니다. 에픽게임즈가 공개한 개발팀 인터뷰에도 같은 맥락이 있습니다 — 이 스튜디오는 레이싱 장르에서 동기화 제어와 실시간 통신에 최적화된 자체 P2P 기반 네트워킹 시스템을 오랫동안 다듬어 왔고, 온라인 기능이 붙은 아케이드 게임을 20년 넘게 운영하며 쌓인 기반 기술이 지금 엔지니어들에게 계승되어 있다고 밝혔습니다.

네 번째 과제 — 동작 실적 부족

기술 과제 3가지만큼 중요한 과제가 하나 더 있었습니다. “동작 실적이 부족하다.” 제품으로 세상에 내놓으려면 이 과제를 해소하는 것도 매우 중요했습니다. 이 네 번째 과제가 이후 3단계 테스트 계획의 직접적인 동기입니다.

기초 다지기

EOS는 하나의 서비스가 아니라 인터페이스 묶음이다

EOS는 크게 EOS Game Services와 EOS Epic Account Services로 나뉩니다. 이 사례가 쓰는 쪽은 대부분 Game Services입니다. 공식 문서 기준으로 이 사례와 맞물리는 인터페이스는 다음과 같습니다.

• Platform — 다른 모든 인터페이스의 핸들을 얻는 진입점입니다. EOS를 쓰려면 반드시 통합해야 합니다.
• Connect — 플레이어를 Game Services에 로그인시킵니다. Epic Games 계정이 없어도 됩니다. Steam·PlayStation 등 외부 아이덴티티 프로바이더의 토큰으로 로그인해 Product User ID(PUID)를 받습니다.
• Auth — Epic Account Services 쪽 인증입니다. 소셜 오버레이나 Epic 친구 목록을 쓰려면 이쪽이 필요하고, 이 경우 외부 프로바이더로 Game Services에 직접 로그인하는 경로는 쓸 수 없습니다.
• Lobby / Sessions — 모임과 매치를 관리합니다. 뒤에서 따로 비교합니다.
• P2P (NAT P2P) — 클라이언트 간 직접 통신. 이 사례의 레이스 중 통신이 여기 올라갑니다.
• Player Data Storage / Title Storage — 플레이어별·타이틀 공용 파일 저장. Sanctions — 제재 정보 조회와 세션 참가 차단.

즉 “EOS를 도입한다”는 말은 이 목록에서 필요한 인터페이스만 골라 붙인다는 뜻입니다. 이 사례가 실제로 손댄 것은 아이덴티티(Connect), 모임(Lobby), 실시간 통신(P2P), 그리고 초기화 옵션(Platform)입니다.

기초 다지기

스토어를 넘는 계정 연결이 실제로 요구하는 것

크로스플레이의 어려움은 통신이 아니라 “같은 사람인지 어떻게 아는가”입니다. EOS 공식 문서는 이렇게 정리합니다. 플레이어는 하나 이상의 외부 계정을 Product User ID(PUID)에 연결할 수 있고, PUID는 같은 조직 안의 각 제품마다 고유합니다. 서로 다른 플랫폼에서 시작한 두 계정이 같은 저장 데이터를 보려면, 두 계정 모두를 Epic Games 계정 같은 공통 아이덴티티 프로바이더(또는 자사 계정 시스템)에 연결해야 합니다.

문서가 권장하는 흐름은 이렇습니다 — 먼저 EOS_Connect_Login을 시도하고, “유저 없음” 응답으로 받은 EOS_ContinuanceToken을 보관합니다. 다른 플랫폼에서 플레이한 적이 있다면 그 계정 자격 증명으로 다시 로그인시키고, 성공한 뒤 EOS_Connect_LinkAccount를 호출해 두 외부 계정을 하나의 PUID에 묶습니다. 계정을 새로 만들 때는 EOS_Connect_CreateUser를 씁니다.

짚어둘 점

크로스플레이는 코드만으로 끝나지 않는다 — 인증 요건

EOS 공식 문서는 일부 콘솔 플랫폼 제공자가 크로스플레이를 끄는 설정을 제공하며, 그 설정을 따르는 것이 인증(certification) 요건의 일부라고 명시합니다. 플레이어가 크로스플레이를 거부했다면, 그 플레이어는 같은 플랫폼 멤버만 있는 로비/세션에만 들어가야 합니다.

여기서 “플랫폼”은 설치된 기기가 아니라 플레이어가 인증한 온라인 서비스를 가리킵니다 — Xbox 플레이어는 모두 XBL, PlayStation 플레이어는 모두 PSN으로 취급됩니다. 백엔드는 인증 토큰으로 각 멤버의 플랫폼을 식별해 EOS_LobbyDetails_MemberInfo의 Platform 필드로 노출하고, 허용되지 않은 플랫폼의 참가를 EOS_Lobby_JoinLobby 단계에서 막습니다. 다만 제약이 걸려 있지 않은 로비에서는 백엔드가 강제할 수 없으므로, 호스트/서버 쪽에서 추가 검증을 넣어야 한다는 것이 문서의 권고입니다.

더 깊이

콘솔용 EOS SDK는 다운로드 자체가 승인제다

공식 문서 기준으로 콘솔용 EOS SDK는 플랫폼 홀더와 에픽게임즈 양쪽의 승인을 받은 개발자만 내려받을 수 있습니다. 여기서 플랫폼 홀더는 Microsoft(Xbox One, Xbox Series), Sony(PlayStation 4, PlayStation 5), Nintendo(Switch, Switch 2)입니다. 플랫폼 홀더 승인을 먼저 받고, 그 다음 에픽게임즈 승인을 신청하는 순서입니다.

즉 “SDK가 준비되어 있어 바로 검증을 시작할 수 있다”는 이 세션의 첫 번째 채택 이유는 이미 콘솔 개발 승인을 통과한 스튜디오에서만 곧바로 성립합니다. 신규 팀이 같은 판단을 그대로 복사할 수는 없는 조건입니다.

기초 다지기

단계적 부하 테스트의 숫자는 실제로 무엇을 재는가

“다운로드 4만 3천, 플레이 100만 회” 같은 숫자는 홍보용 지표로 보이지만, 네트워크 테스트에서 이 숫자들의 용도는 다릅니다. 동시 접속 규모는 매치메이킹 풀이 실제로 성립하는지 (12인 로비가 대기 없이 차는지)를 결정하고, 플레이 세션 수는 연결 성공/실패 표본 수를 결정합니다. 표본이 적으면 “특정 NAT 환경에서만 터지는 버그” 같은 저빈도 문제가 애초에 관측되지 않습니다.

에픽게임즈가 공개한 개발팀 인터뷰는 CNT에서 실제로 수집한 항목을 명시합니다 — 유저 간 레이턴시, 패킷 로스, 릴레이 서버를 경유한 연결의 비율, 그리고 설문으로 받은 플레이어 피드백입니다. 이 세 가지가 뒤의 세 가지 결정에 각각 대응합니다: 레이턴시는 예측 거동 파라미터, 패킷 로스는 송수신 처리 방식, 릴레이 경유 비율은 Force Relays 전환의 리스크 평가입니다.

기초 다지기

Lobbies와 Sessions는 무엇이 다른가

EOS는 멀티플레이용 모임 서비스를 두 가지 제공합니다. 공식 문서의 비교를 그대로 옮기면 차이는 대체로 “연결을 EOS가 유지해주는가”로 요약됩니다.

짚어둘 점

“분당 레이트 제한”의 실제 숫자

발표가 “1분당 레이트 제한을 고려해 필요한 동기화만 했다”고 말한 부분은 EOS 공식 문서의 로비 사용 제한 표에 근거가 있습니다. 대표적인 값은 다음과 같습니다.

여기서 중요한 것은 “멤버 속성 갱신이 분당 100회”라는 점입니다. 60fps 게임에서 프레임마다 로비 속성을 갱신하면 1초 만에 한도를 넘습니다. 그래서 레이스 중 상태는 로비가 아니라 P2P로 흐르고, 로비는 매치 성립과 멤버 구성 같은 저빈도 정보만 담당하는 분담이 강제됩니다. 발표의 “필요한 동기화만 수행”은 취향이 아니라 이 한도의 결과입니다.

사전 준비 3가지 — “개선을 계속한다”를 전제로

1. 넷코드 설계 — 지연 상황을 3단계로 나눠 조정 가능하게 만들어 뒀습니다. 플레이 중 불안감이 적은 동기화 조정이 가능하도록 하는 것이 목표였습니다.
2. 플랫폼 대응 — 복수의 프레임레이트가 존재하는 것을 전제로 설계·구현했습니다. 구체적으로 30fps와 60fps 구현을 분리했습니다.
3. 에픽게임즈와의 연계 — CNT 참가 예정 인원을 사전 공유하고, 테스트 기간 중 모니터링 협력을 요청했습니다. 개발팀 인터뷰에도 “예상 플레이어 수를 에픽과 공유해 서버 스케일링과 모니터링 지원을 받았다”고 기록되어 있습니다.

숫자보다 중요했던 것

개발팀은 측정 결과가 과거 아케이드 타이틀의 온라인 운영 데이터에서 세운 예측과 일치했다는 점을 성과로 꼽았습니다. 예측이 맞았다는 확인은 이후 판단에 그 예측 모델을 계속 써도 된다는 뜻이고, 마지막 Force Relays 결단의 근거가 여기서 만들어집니다.

기초 다지기

예측 거동(Prediction)이 왜 필요한가

네트워크 대전에서 상대의 위치를 “도착한 패킷대로만” 그리면, 패킷 간격만큼 상대가 순간이동하거나 멈춰 보입니다. 그래서 실시간 게임은 다음 위치를 미리 계산해 먼저 그리고, 이후 실제 데이터가 도착하면 그 차이를 보정합니다. 이 게임은 수신한 플레이어 조작과 예측 처리를 함께 써서 온라인 플레이어의 거동을 재현합니다.

핵심은 트레이드오프입니다. 개발팀 인터뷰의 표현이 정확합니다 — “예측을 강하게 하면 더 높은 지연에 대응할 수 있지만, 상대의 실제 거동과의 차이도 커진다.” 그래서 예측 강도를 하나로 고정할 수 없고, 저지연·중지연·고지연 세 구간으로 나눠 조정하는 설계가 나옵니다. 앞서 사전 준비 1번의 “지연 상황 3단계”가 바로 이것입니다.

문제

• 이 구조는 네트워크 지연의 영향을 직접 받으므로 고지연 환경에서는 추가 조정이 필수입니다.
• CNT 계측 데이터를 분석한 결과 예상보다 약 100ms 큰 지연^[8]이 발생하고 있음을 확인했습니다.
• ONT는 훨씬 다양한 네트워크 환경에서의 참가가 예상되므로, 그대로 두면 게임 체험이 저하될 수 있었습니다.

대응

• CNT 실측 데이터를 근거로 예측 거동 파라미터를 재조정하고, 플레이테스트를 반복하며 최적화했습니다.
• 상대방이 멈춘 것처럼 보이지 않고 계속 움직이는 것처럼 보이게 만들어 UX를 개선했습니다.

기초 다지기

왜 프레임레이트에 통신을 묶으면 깨지는가

송수신을 게임 프레임에 태우면 전송 빈도가 곧 프레임레이트가 됩니다. 60fps 클라이언트는 초당 60번 보내고, 30fps 클라이언트는 초당 30번 처리합니다. 개발팀 인터뷰의 설명이 그대로 이 상황입니다 — “게임 프레임레이트를 기준으로 패킷을 주고받으면, 프레임레이트가 낮은 쪽이 패킷 처리를 따라가지 못한다.”

여기에 12인 풀 메시가 곱해집니다. 각 클라이언트가 나머지 11명과 직접 연결을 유지하므로 수신량은 인원 수에 비례합니다. 30fps 쪽은 프레임당 처리해야 할 패킷이 두 배로 쌓이고, 밀린 패킷은 결국 버려지거나 늦게 반영되어 예측 보정의 입력 자체를 망칩니다. 과제 1과 과제 2가 별개 문제가 아니라 같은 곳에서 만나는 이유입니다.

여기서 나온 교훈

실시간 통신에서는 통신 빈도를 올리는 것만이 답이 아니라, 처리 부하의 밸런스를 고려한 최적화가 중요합니다. 저스펙 쪽 처리 여력이 상한이라면, 빈도를 올리는 개선은 그 상한에서 역효과가 됩니다.

기초 다지기

EOS SDK의 스레드 어피니티는 공식 조정 지점이다

EOS 공식 문서는 이렇게 설명합니다 — “EOS SDK는 스레드를 특정 CPU 코어 집합에 바인딩한다. 이를 스레드 어피니티라고 한다. 플랫폼마다 기본 어피니티가 있고, 이는 데드락을 방지하는 데 도움이 된다.” 그리고 다른 어피니티를 쓰고 싶다면 SDK 초기화 시점에 기본값을 덮어쓸 수 있다고 명시합니다.

EOS_Initialize_ThreadAffinity ThreadAffinity = {};
ThreadAffinity.ApiVersion  = EOS_INITIALIZE_THREADAFFINITY_API_LATEST;
ThreadAffinity.NetworkWork = MyNetworkAffinity;    // IO가 아닌 네트워크 관리 스레드
ThreadAffinity.P2PIo       = MyP2PIoAffinity;      // P2P 트래픽 IO
ThreadAffinity.WebSocketIo = MyWebSocketAffinity;  // 로비 상시 연결 등
ThreadAffinity.StorageIo   = MyStorageIoAffinity;  // 스토리지 장치 접근
ThreadAffinity.HttpRequestIo = MyHttpRequestIoAffinity;

EOS_InitializeOptions SDKOptions = {};
SDKOptions.ApiVersion             = EOS_INITIALIZE_API_LATEST;
SDKOptions.OverrideThreadAffinity = &ThreadAffinity;  // nullptr이면 플랫폼 기본값
EOS_Initialize(&SDKOptions);

구조체가 카테고리를 이렇게 쪼개 놓은 것 자체가 이 조정의 의도를 보여줍니다. NetworkWork(IO가 아닌 네트워크 관리), P2PIo(P2P 트래픽 IO), WebSocketIo, StorageIo, HttpRequestIo, RTCIo, CryptographyWork가 각각 별도 마스크를 받습니다. 즉 “P2P IO만 게임 스레드가 붐비는 코어에서 떼어낸다”는 식의 국소적 조정이 가능합니다. 각 값을 0으로 두면 플랫폼별 기본값이 쓰입니다.

짚어둘 점

어피니티를 건드릴 때의 두 가지 함정

첫째, 기본값이 데드락 방지를 위해 정해져 있다는 문서의 표현을 가볍게 넘기면 안 됩니다. 임의로 좁게 몰아넣으면 통신 에러 대신 정지(hang)를 얻을 수 있습니다.

둘째, 이 구조체는 SDK 버전에 따라 멤버가 늘어납니다. 릴리스 노트 기준으로 EOS SDK 1.16.4에서 콘솔 전용으로 EmbeddedOverlayMainThread와 EmbeddedOverlayWorkerThreads가 추가됐고, 이는 브레이킹 체인지로 공지됐습니다. 이미 EOS_Initialize_ThreadAffinity를 쓰고 있던 게임은 업그레이드 시 새 멤버를 반드시 초기화해야 합니다. 어피니티 튜닝은 SDK 업데이트마다 재확인이 필요한 영역입니다.

발표가 이 항목에서 강조한 것은 개선 폭이 아니라 “EOS에 이런 조정 수단이 준비되어 있다”는 사실이었습니다. 서드파티 통신 기반을 쓰면서도 플랫폼별 성능 문제에 손을 넣을 여지가 있는지가 채택 가능성을 좌우합니다.

CNT 대비 다운로드 약 23배, 플레이 약 10배 규모입니다. 감시 대응은 계속 실시했으며, 이번에는 CNT 경험을 통해 예상한 대로 운용할 수 있었습니다.

문제 — 원인 특정 실패

• ONT 계측 데이터 분석 결과 일부 고객에게서 통신 에러가 빈발하는 경향이 발견됐습니다.
• 개발팀 내부 검증으로는 원인 특정에 실패했습니다. 오피스 네트워크에서는 재현이 되지 않았습니다.
• 이대로 아무것도 하지 않고 발매하면 고객의 게임 체험을 손상시킬 리스크가 높은 상태였습니다.

원인 규명 — 일반 가정 회선에서 재현 테스트

해법은 특별한 도구가 아니라 환경의 다양성이었습니다. 재택 근무 사원들을 동원해^[11] 일반 인터넷 회선에서 추가 테스트를 실시했고, 이 테스트가 주효해서 문제를 발견했습니다.

기초 다지기

EOS P2P는 어떤 순서로 연결을 맺는가

공식 문서 기준으로 사설 IP는 홈 네트워크 밖의 피어에서 도달할 수 없으므로, EOS SDK는 ICE로 NAT 트래버설을 수행합니다. STUN으로 내부망 게임 클라이언트의 공개 IP를 알아내 시그널링 채널을 통해 피어와 공유하고, 그래도 방화벽이 지나치게 제한적이면 TURN 릴레이를 씁니다. 릴레이는 한쪽이 보낸 데이터를 서버가 받아 다른 쪽으로 전달하는 방식이므로 추가 지연이 붙고, 그 크기는 양쪽이 서버에서 얼마나 가까운지에 달려 있습니다.

공식 문서는 릴레이 연결이 성립하려면 플레이어의 방화벽이 UDP 패킷을 허용해야 한다고 명시합니다. 대부분의 방화벽은 UDP를 허용하지만, 제한적인 환경에서는 UDP가 차단되거나 특정 포트 허용이 필요할 수 있고 그 경우 릴레이도 실패합니다.

세 가지 릴레이 모드

EOS_P2P_SetRelayControlOptions Options = {};
Options.ApiVersion   = EOS_P2P_SETRELAYCONTROL_API_LATEST;
Options.RelayControl = EOS_RC_ForceRelays;   // 기본값은 EOS_RC_AllowRelays

EOS_P2P_SetRelayControl(P2PHandle, &Options);

공식 API 문서의 주의사항: 이 설정은 기존 연결에 즉시 적용되지 않습니다. 다만 연결이 재협상을 필요로 하는 경우에는 기존 연결에도 적용될 수 있습니다.

짚어둘 점

릴레이 모드는 클라이언트끼리 호환되어야 한다

공식 API 문서는 서로 다른 설정을 가진 클라이언트 간 호환성 표를 함께 제공합니다. 여기서 호환되지 않는 조합의 연결은 “일부 상황에서 성공할 수도 있지만, 일관되게 실패할 것으로 취급해야 한다”고 명시합니다.

이 표가 “발매 직전에 전환해도 안전한가”에 대한 기술적 근거입니다. 만약 이 게임이 어딘가에서 NoRelays를 쓰고 있었다면 전면 전환은 매칭을 쪼개는 결정이 됩니다. 또 하나 유의할 점은 공식 문서가 Xbox를 예외로 명시한다는 것입니다 — Xbox를 제외한 각 게임 클라이언트 플랫폼에서 세 가지 릴레이 모드를 쓸 수 있고, Xbox의 P2P 요건은 별도 문서를 봐야 합니다.

Force Relays로 변경 — 판단 근거 3가지

그리고 이 교환이 가능했던 이유가 근거 2입니다. 릴레이 이용률과 그 조건에서의 만족도를 이미 숫자로 갖고 있었기 때문에, “전원 릴레이”가 만족도를 어디까지 떨어뜨리는지 추정할 수 있었습니다. 측정이 없었다면 이 결정은 발매 직전의 도박이 됩니다.

Metascore·유저 스코어·판매량·26% 수치는 모두 에픽게임즈가 공개한 개발팀 인터뷰에 명시된 값입니다.

마지막 26%가 이 프로젝트의 실질적인 성과 지표입니다. 크로스플레이는 켜두기만 하면 되는 기능이 아니라 실제로 쓰이는지가 투자 회수의 기준인데, 2인 팀의 4분의 1 이상이 플랫폼을 넘어 함께 플레이했다는 것은 이 기능이 유휴 기능이 아니었다는 증거입니다.

P2P를 쓰면 치트·해킹 리스크는 어떻게 다루나

• P2P만으로는 판정이 불가능합니다. AWS를 사용한 별도 서버^[14]가 있어서 이쪽에서 이상을 감지하고 사후 대응하는 방식입니다.
• 치트 행위는 실제로 존재하며, 운영 측에서 경고 또는 최악의 경우 밴 대응을 합니다.
• “P2P에 리스크가 있느냐”에 대한 답은 “있다”는 것이 발표자의 정리였습니다.

저스펙 플랫폼까지 대응할 때 어려웠던 점

• 가장 큰 것은 스펙 차였습니다. 이번 작품은 Switch 1부터 PC까지 폭넓게 대응했습니다.
• 저스펙 플랫폼에서도 같은 게임 체험을 어떻게 제공할지가 핵심 — 통신 빈도를 낮추는 등의 트레이드오프에서 게임 체험과의 밸런스에 특히 주의했습니다.
• 보정 알고리즘 자체는 기본적으로 동일하고, 게임 프레임레이트 30 / 60 두 패턴을 기준으로 보간 횟수 같은 세부를 조정했습니다. 저스펙 쪽은 계산량이 그대로 부하로 되돌아오기 때문에 솎아내며 세밀하게 맞췄습니다.

EOS를 써보고 특히 좋았던 점

아케이드 팀이 네이티브 구현을 해왔기에 넷코드는 기본적으로 C++로 구현되어 있습니다. EOS는 C++에서도 사용하기 쉬운 API/SDK이므로, 기존에 독자적으로 구현해둔 부분에 조합해 넣기 쉬웠다는 것이 답이었습니다. 그래서 예측 알고리즘 같은 독자 처리와 EOS를 조합하는 것이 수월했고, 독자 구현을 유지하는 팀에게 이 점이 메리트라고 정리했습니다.

공식 문서 기준으로도 EOS 인터페이스는 C와 C#으로 제공되며, 언리얼 엔진이나 유니티용 플러그인은 인터페이스를 직접 쓰는 것에 대한 선택적 대안입니다. 자체 넷코드를 가진 팀이 플러그인을 우회해 SDK를 직접 호출하는 구성이 공식적으로 지원되는 경로입니다.

EOS 외의 대안은 검토했나

• 자사 제작과 타사 서비스 이용이라는 대안도 당연히 있었습니다.
• 다만 앞서 정리한 3가지 기술 과제 해소에 이 팀이 가장 적합했던 것이 EOS였고, P2P 기반 구현이 아케이드 팀에게 익숙한 영역이라 비교적 만들기 쉬웠던 점이 컸습니다.
• 새로운 기술이라는 사실 자체는 변하지 않으므로, 개선 계획을 사전에 세우고 실적으로 불안을 해소해가는 사이클로 만든 것이 채택의 또 다른 큰 요인이었습니다.

두 반성이 같은 뿌리입니다. NAT 전환 환경을 사내에서 재현할 수 없었기 때문에 사람을 동원했고, 24시간 감시도 사람으로 메웠습니다. 네트워크 다양성을 설계에 넣지 못한 결과가 인력 의존으로 나타난 구조입니다.

각주

1. 최대 4인 스쿼드 — 온라인 최대 12인은 SEGA 공식 사이트와 스토어 표기로 확인됩니다. 스쿼드 정원은 공식 자료에서 단일 수치로 명시된 것을 찾지 못했습니다. Steam 스토어 설명은 Race Park 모드를 “2~4인 팀”으로, 에픽게임즈의 개발팀 Q&A는 분석 대상을 “2인 스쿼드”로 언급합니다. “최대 4인”이라는 표현 자체는 미확인입니다. ↩
2. 시리즈 최초 크로스플레이 — 이 작품이 크로스플레이를 지원하는 것은 공식 확인됩니다. 다만 “소닉 레이싱 시리즈 최초”라는 서열 표현은 공식 자료에서 확인하지 못했습니다. 에픽게임즈의 개발팀 Q&A는 “PC와 콘솔 간 크로스 플랫폼 멀티플레이 경험을 제공한 또 하나의 마일스톤”이라고만 표현합니다. ↩
3. 팀 구성 비율과 “아케이드 팀이 EOS 도입을 시작” — 개발팀이 아케이드 개발 기반을 계승했다는 점은 에픽게임즈의 개발팀 Q&A로 확인됩니다(레이싱 장르에서 자체 P2P 기반 네트워킹을 다듬어 왔고, 온라인 아케이드 운영 경험이 20년 이상 계승되어 있다는 서술). 다만 콘솔 팀과 아케이드 팀의 약 1:1 비율, 그리고 EOS 도입 착수 주체가 아케이드 팀이었다는 조직 내부 서술은 공식 자료로 확인되지 않습니다. ↩
4. 온라인 로비에 EOS Lobbies를 사용 — 에픽게임즈의 개발팀 Q&A는 P2P 통신과 릴레이 모드만 명시하며, Lobbies 인터페이스 채택 여부는 언급하지 않습니다. 발표 내용을 옮긴 것이며, 본문에 인용한 분당 레이트 제한 수치는 EOS 공식 로비 문서에서 확인한 값입니다. ↩
5. CNT 실시 일자 — 발표 기준으로는 2025년 2월 하순으로 언급됐습니다. SEGA 공식 CNT 안내 페이지는 2025-02-22 08:00부터 2025-02-24 08:00(GMT+8)까지로 표기하며, 이는 “연 2일”이라는 발표 내용과 일치합니다. 본문은 공식 일자를 따랐습니다. ↩
6. CNT 플레이 지역 “세계 50개국 이상” — 에픽게임즈의 개발팀 Q&A는 다운로드 수와 플레이 세션 수를 명시하지만 국가 수는 언급하지 않습니다. 슬라이드에만 존재하는 수치로 보이며 미확인입니다. ↩
7. 기간 중 교대제 24시간 감시 — 에픽게임즈의 개발팀 Q&A는 CNT 기간 중 에픽으로부터 모니터링 지원을 받았다는 사실은 확인해주지만, 개발팀 내부의 24시간 교대 감시 체제와 그 부담에 대한 서술은 공식 자료에 없습니다. ↩
8. “예상보다 약 100ms 큰 지연” — 에픽게임즈의 개발팀 Q&A는 CNT에서 유저 간 레이턴시를 측정했고 그 데이터로 예측 강도를 저·중·고 3구간으로 조정했다는 사실까지 확인해줍니다. 그러나 구체적인 100ms라는 편차 값과 발표 현장에서 언급된 “최대 300ms” 수치는 공개 자료에서 확인되지 않습니다. ↩
9. 어피니티 마스크 조정으로 통신 에러율 개선 — EOS_Initialize_ThreadAffinity로 카테고리별 어피니티를 덮어쓸 수 있다는 것은 EOS 공식 문서로 확인됩니다. 다만 이 게임이 실제로 어떤 플랫폼에서 어떤 마스크를 적용했고 에러율이 얼마나 개선됐는지는 공개되지 않았습니다. 발표에서도 수치는 제시되지 않았습니다. ↩
10. ONT 플레이 지역 “200개 이상의 국가·지역” — 에픽게임즈의 개발팀 Q&A는 ONT의 다운로드 100만·플레이 1000만을 명시하지만 국가·지역 수는 언급하지 않습니다. 미확인입니다. ↩
11. 재현 테스트 동원 인원 “사내 300명” — 에픽게임즈의 개발팀 Q&A는 “원격 근무 사원들이 일반 인터넷 회선으로 추가 테스트를 수행했다”고만 서술하며 인원 수는 밝히지 않습니다. 300명이라는 규모는 발표에서 언급된 값이며 공개 자료로 확인되지 않습니다. ↩
12. “최대 10% 정도 에러율 저하” — ForceRelays로 전환했다는 사실과 그 이유(NAT 타입 전환 환경에서의 접속 문제), 그리고 지연 최적화와의 트레이드오프는 에픽게임즈의 개발팀 Q&A로 확인됩니다. 그러나 개선 폭 10%라는 수치는 공개 자료에 없습니다. ↩
13. Steam 평가 — 에픽게임즈의 개발팀 Q&A는 “Steam 리뷰가 압도적으로 긍정적(overwhelmingly positive)이었다”고만 서술합니다. 발표에서 언급된 “95% 긍정”이라는 구체적 비율은 확인되지 않으며, Steam 스토어의 리뷰 비율은 시점에 따라 변동하는 값이므로 본문에는 공식 표현만 남겼습니다. ↩
14. AWS 기반 별도 서버에서의 치트 사후 탐지 — Q&A에서 발표자가 답한 내용이며, 공개된 공식 자료에서는 확인되지 않습니다. 서버가 감시·사후 제재만 담당하는지, 아니면 통신 경로 중간에서 검증까지 수행하는지도 발표에서 명확히 언급되지 않았습니다. 답변의 맥락상 전자(감시·사후 대응)에 가깝습니다. ↩