KisakCOD, Hacker News에 등장했지만 공개된 Call of Duty 코드가 새로운 위험을 낳다
- Sophie Larsen

- 2시간 전
- 12분 분량
KisakCOD가 강렬한 제안과 함께 hacker news에 등장했다. 독점 소프트웨어라는 출발점에도 불구하고, Call of Duty 4 멀티플레이어를 공개적으로 컴파일 가능한 코드로 재구축하겠다는 것이다. 검토 당시 이 프로젝트에는 640개의 커밋이 있었으며, 일회성 기술 시연이 아닌 지속적인 엔지니어링 작업임을 시사한다. 그러나 공개된 코드는 보존, 보안, 라이선스, 통제를 둘러싼 더 복잡한 갈등도 드러낸다.
KisakCOD repository는 이 소프트웨어를 모드 개발자와 Call of Duty 4 애호가를 위한 완전 빌드 가능 오픈 소스 재구현이라고 설명한다. 멀티플레이어, 전용 서버, 싱글플레이어 빌드 타깃을 포함한다. 다만 이 타깃들을 실행하려면 정식 Call of Duty 4 설치본의 게임 파일이 여전히 필요하다.
이 구분은 KisakCOD를 무료 대체 게임과 구별한다. 이 프로젝트는 실행 파일 기술을 재구성하는 한편 Activision의 상업용 에셋은 저장소 밖에 둔다. 이 접근 방식은 개발자에게 기존 모드 도구보다 더 깊은 접근 권한을 제공하지만, 원본 소프트웨어를 둘러싼 소유권 문제를 없애지는 않는다.
이 프로젝트는 출시된 지 거의 20년이 된 게임에서 알려진 익스플로잇에 대한 직접적인 경고도 담고 있다. 유지보수자들은 바이너리 익스플로잇 가능성을 배제할 수 없으므로 온라인 플레이를 샌드박스 환경에서 실행할 것을 권장한다. 공개 개발은 수정 작업을 뒷받침할 수 있지만, 읽을 수 있는 코드는 공격자에게 오래된 네트워크 동작에 대한 상세한 지도를 제공할 수도 있다.
바로 이 긴장 관계가 주목의 핵심이다. KisakCOD는 고전 멀티플레이어 시스템의 커뮤니티 유지보수를 약속하는 동시에, 일반적인 모드가 좀처럼 마주하지 않는 법적·보안적 불확실성을 물려받는다.
KisakCOD가 Hacker News에 등장한 이유
KisakCOD는 오래된 상용 실행 파일을 애호가들이 컴파일하고, 검사하고, 수정할 수 있는 개발 기반으로 바꾼다.
이 프로젝트는 기사 개요에 연결된 hacker news discussion에 등장했다. 제공된 스냅샷에서 해당 게시물은 33포인트와 댓글 3개를 기록했다. 이는 큰 규모의 메인 페이지 수치는 아니지만, 주제는 소프트웨어 보존과 리버스 엔지니어링에 대한 Hacker News의 오랜 관심사와 맞닿아 있다.
저장소는 추출된 스크립트나 Activision 실행 파일을 감싼 런처 이상의 것을 제공한다. 소스 트리에는 엔진 시스템, 게임 로직, 스크립트, 의존성, CMake 구성이 포함되어 있다. 개발자는 여러 빌드 유형에 맞는 Visual Studio 프로젝트를 생성할 수 있다.
현재 빌드 지침에는 Windows, Visual Studio 2022, CMake 3.16 이상, Microsoft의 구형 DirectX SDK가 필요하다. 또한 Steam과 Call of Duty 4 사본도 요구된다. 사용자는 원본 게임 파일과 여러 런타임 라이브러리를 생성된 빌드 디렉터리로 복사해야 한다.
이 요구 사항은 실제로 무엇이 바뀌었는지를 보여준다. KisakCOD는 하나의 자체 완결형 다운로드로서 완전한 Call of Duty 4 대체품을 배포하지 않는다. 대신 플레이어가 이미 보유해야 하는 파일에 의존하는 재빌드 가능한 구현을 제공한다.
이 구조는 모드 개발자에게 중요하다. 기존 수정 작업은 대개 원본 게임이 노출한 인터페이스 안에서 이뤄진다. 소스 수준 재구현은 기여자가 더 낮은 엔진 계층을 바꾸고, 오류를 추적하며, 진단 기능을 추가하고, 시스템을 다른 플랫폼으로 이식할 수 있게 한다.
개발자는 작업이 2025년 3월 4일경 시작됐으며, Avail과 “Destructive Interface”로 확인된 두 명의 협력자가 있었다고 말한다. 2026년 8월까지 공개 저장소에는 수백 개의 커밋과 수십 개의 포크가 표시됐다. 이 이력은 Hacker News 등장이 프로젝트의 출발일이 아니라 발견의 계기였음을 보여준다.
KisakCOD는 같은 그룹의 이전 프로젝트도 잇는다. Kisak-Strike는 수정 가능한 Counter-Strike: Global Offensive 코드베이스에 집중했고, kisak-thug는 Tony Hawk's Underground를 대상으로 했다. 개발자는 KisakCOD를 처음에는 비어 있던 소스 트리에서 완성한 이 그룹의 첫 디컴파일 프로젝트라고 설명한다.
디컴파일은 기계 명령을 사람이 읽을 수 있는 소스 코드의 근사치로 변환한다. 원본 주석, 이름 지정 방식, 혹은 모든 고수준 구조를 자동으로 복원하지는 않는다. 개발자는 불완전한 출력을 해석하고, 타입을 복구하며, 파일을 재구성하고, 컴파일된 게임의 동작과 대조해 테스트해야 한다.
디컴파일과 단순 디스어셈블의 차이는 이 프로젝트의 매력을 설명하는 데 도움이 된다. 디스어셈블은 저수준 프로세서 명령을 보여줄 수 있다. KisakCOD는 개발자가 빌드하고, 디버그하고, 수정할 수 있는 유지보수 가능한 C 및 C++를 만들려 한다.
GPL-3.0 라이선스는 카피레프트 조건 아래 수정과 재배포를 허용한다. 그러나 재구성된 코드에 라이선스를 부여한다고 해서 원본 게임과 관련된 모든 권리가 독립적으로 해결되는 것은 아니다. 이 미해결 경계는 프로젝트가 기여자와 가시성을 얻을수록 더욱 중요해진다.
디버그 심볼이 재구현을 가능하게 했다
KisakCOD는 유난히 상세한 개발 산출물이 방대한 리버스 엔지니어링 문제를 어렵지만 관리 가능한 과제로 좁혔기에 존재할 수 있었다.
프로젝트의 development account에 따르면 Call of Duty 출시본에는 방대한 디버깅 정보가 남아 있었다. 이 자료에는 최소 두 개의 Windows Program Database 파일, 여섯 개의 Xbox 360 PDB 또는 맵 파일, 그리고 ELF 심볼이 포함된 Macintosh 바이너리가 있었다.
PDB 파일은 개발자가 컴파일된 Windows 소프트웨어를 디버그하는 데 도움이 되는 정보를 저장한다. 빌드에 따라 함수 이름, 지역 변수, 파일 경로, 타입, 소스 구성 등을 드러낼 수 있다. 맵 파일은 컴파일된 함수를 오브젝트 파일 및 주소와 연결할 수 있다.
이 산출물들은 원본 소스 코드를 제공하지 않는다. 하지만 일반적으로 스트립 처리된 소매용 바이너리가 숨기는 레이블과 구조적 단서를 복원해 준다. 이 이점은 재구성 과정에서 필요한 맹목적 추론의 양을 줄였다.
한 Windows 빌드에는 이름이 있는 지역 변수와 어설션이 포함돼 있었다고 전해진다. 어설션은 개발자가 테스트 중 잘못된 프로그램 상태를 포착하기 위해 삽입하는 검사다. 그 메시지는 내부 파일 경로, 예상 값, 개발자가 의도한 제어 흐름을 드러낼 수 있다.
Xbox 360 맵 파일은 또 다른 중요한 계층을 제공했다. 개발 계정에 따르면, 이 파일은 어떤 함수가 특정 컴파일된 오브젝트 파일에 속하는지를 식별했다. 팀은 이러한 연결 관계를 활용해 그럴듯한 소스 디렉터리와 파일 레이아웃을 재현했다.
재구성에는 여전히 상당한 수작업이 필요했다. 초기 단계에서 개발자들은 리버스 엔지니어링 애플리케이션인 IDA가 생성한 함수 그룹을 처리하기 위해 IDAPython 스크립트를 사용했다. 이후 잘못된 출력을 제거하고, 정의를 복원하며, 파일별로 컴파일 오류를 수정했다.
팀은 이 과정을 여러 단계로 나눴다. 먼저 추정되는 소스 구조를 매핑한 뒤 재구성된 함수로 파일을 채웠다. 이후 단계에서는 타입 오류, 컴파일러 실패, 링커 문제, 런타임 결함을 처리했다.
이 워크플로는 디버그 심볼이 과정을 자동화하지 못한 이유를 설명한다. 디컴파일된 출력은 데이터 타입, 함수 시그니처, 구조체 레이아웃, 컴파일러 최적화를 잘못 판단할 수 있다. 단 하나의 잘못된 가정만으로도 빌드에는 성공하지만 잘못 동작하는 프로그램이 만들어질 수 있다.
한 버그는 Boolean 반환값을 완전한 정수로 취급하면서 발생했다. 또 다른 문제는 디컴파일러가 도입한 누락된 캐스트와 관련됐다. 팀은 렌더링 실패, 잘못된 조명, 망가진 래그돌, 물리 오류, 데이터베이스 로딩 결함, 팀 선택 중 발생하는 충돌도 겪었다.
Call of Duty 4의 엔진 계보는 추가적인 참조 지점을 제공했다. 개발자들은 프레임워크 일부를 위해 공개된 Jedi Academy 코드를 참고했다. 다만 그들은 해당 코드를 Call of Duty 빌드로 수정한 것이 아니라, 비어 있는 파일에서 KisakCOD를 시작했다고 말한다.
프로젝트는 서드파티 구성 요소도 조율해야 했다. Call of Duty 4는 물리 처리에 수정된 Open Dynamics Engine 버전을 사용한다. 팀은 게임 동작을 구형 ODE 릴리스와 비교한 뒤 Infinity Ward가 변경한 것으로 보이는 부분을 복원했다.
오디오와 비디오는 다른 문제를 만들었다. Call of Duty 4는 RAD Game Tools의 독점 Bink 및 Miles 기술을 사용했다. 팀은 호환 가능한 개발 구성 요소를 찾았고, Miles 7.2e를 중심으로 오디오 재구성을 조정한 것으로 전해진다.
이러한 의존성은 “오픈 소스 Call of Duty”라는 단순한 표현을 복잡하게 만든다. 재구성된 엔진 코드는 상용 에셋, 과거 SDK 요구 사항, 독점 런타임 구성 요소와 나란히 존재한다. 저장소는 프로그램의 많은 부분을 드러낼 수 있지만, 모든 의존성을 각각 자유롭게 만들지는 않는다.
그럼에도 이 방법은 의미가 크다. 디버그 심볼, 크로스 플랫폼 빌드, 참조 엔진, 반복 테스트는 기계 코드에서 작동하는 멀티플레이어 클라이언트에 이르는 경로를 만들었다. 이는 잊힌 개발 산출물이 보존이 이론에 머무를지 실행 가능한 결과물이 될지를 어떻게 결정할 수 있는지 보여준다.
공개된 Call of Duty 코드가 폐쇄형 엔진 모델에 압력을 가하다
핵심 갈등은 원래 개발 주기보다 오래 살아남은 멀티플레이어 엔진에 대한 커뮤니티 보존과 퍼블리셔 통제 사이의 대립이다.
Call of Duty 4는 2007년에 모드 지원과 전용 서버 소프트웨어를 갖추고 출시됐다. GSC 게임플레이 스크립트는 커뮤니티가 커스텀 모드와 야심 찬 컨버전을 만들 수 있을 만큼 접근 가능했다. 이후 ProMod는 더 빠른 이동과 더 엄격한 게임플레이 선택을 중심으로 경쟁형 멀티플레이어를 다듬었다.
이 도구들은 플레이어에게 상당한 자유를 줬지만, 엔진 자체는 폐쇄된 상태로 남았다. 모더들은 모든 렌더러, 네트워킹 기능, 물리 처리 경로를 자유롭게 검사하지 못한 채 노출된 스크립팅 및 에셋 시스템을 통해 작업할 수 있었다. KisakCOD는 이 기술적 한계를 제거하려 한다.
압력은 직접적인 상업 경쟁에서 비롯되지 않는다. KisakCOD는 여전히 원본 사본을 요구하며, 현재의 Call of Duty 시장이 아니라 애호가를 겨냥한다. 도전의 성격은 구조적이다. 이제 커뮤니티는 퍼블리셔를 기다리지 않고도 엔진 변경을 제안할 수 있다.
이 역량은 공식 유지보수가 둔화된 이후 가장 중요해진다. 기존 모드는 지원되는 인터페이스 아래에 묻힌 취약점이나 구조적 한계를 항상 고칠 수 있는 것은 아니다. 빌드 가능한 코드베이스를 통해 유지보수자는 네트워크 패킷에서 서버와 게임 시스템을 거치는 데이터 흐름을 추적할 수 있다.
이는 원본 퍼블리셔가 우선순위를 두지 않았던 플랫폼 작업도 지원한다. 한 커뮤니티 개발자는 창 관리와 입력에 SDL3를 활용하는 Arm 기반 macOS 포트를 실험 중이라고 보고했다. 이 작업에는 32비트 포인터에 묶인 fast-file 로딩 가정을 다시 작성하는 일이 필요했다.
Fast file은 메모리에 로드되고 런타임에 복구되는 패키징된 게임 데이터베이스다. 직렬화된 포인터와 아키텍처 종속 레이아웃은 엔진을 원래의 32비트 환경 밖으로 옮길 때 장애물이 된다. 소스 접근권은 이러한 가정을 교체할 수 있을 만큼 가시화한다.
성공적인 포트는 단순히 운영체제를 하나 더 추가하는 데 그치지 않는다. 이는 KisakCOD가 최초 재구성에 사용된 제한적인 툴체인에서 독립했는지를 시험하게 된다. 이식성은 프로젝트가 유지보수 가능한 소프트웨어를 만들어 냈는지 판단하는 가장 명확한 척도 중 하나다.
같은 원칙은 멀티플레이어 인프라에도 적용된다. 전용 서버 운영자는 연결 처리, 인증 경로, 성능 병목, 서버 규칙을 검사할 수 있다. 모드 제작자는 원하는 변경이 네이티브 엔진 동작에 의존할 때 스크립팅 계층 아래에서 작업할 수 있다.
퍼블리셔의 통제력은 여전히 중요하다. Activision은 Call of Duty 프랜차이즈와 보호되는 게임 자료를 소유하고 있다. Microsoft는 2023년에 Activision Blizzard를 인수했고, 이에 따라 주요 개발자 및 게임 플랫폼도 운영하는 기업이 해당 카탈로그의 관리 책임을 맡게 됐다.
KisakCOD는 Microsoft나 Activision이 승인해 공개한 소스 릴리스를 의미하지 않는다. GPL 라이선스는 원래 퍼블리셔가 Call of Duty 4 엔진을 공개하기로 내린 결정이 아니라 저장소 유지 관리자가 부여한 것이다.
이 차이는 KisakCOD를 소유자가 의도적으로 소스 코드를 공개한 게임들과 구분한다. 공식 릴리스는 어떤 코드가 라이선스 대상인지 정의하고, 제외되는 상표, 에셋, 미들웨어, 네트워크 서비스를 명확히 할 수 있다. 리버스 엔지니어링 저장소는 이에 상응하는 승인을 받지 못한 상태에서 그러한 경계를 설정해야 한다.
그럼에도 이 프로젝트는 폐쇄적인 보존 전략의 실질적인 약점을 드러낸다. 플레이어는 오래된 게임 사본을 합법적으로 보유할 수 있지만, 호환되는 운영체제, 서버, 드라이버, 보안 지원은 잃을 수 있다. 디스크나 다운로드판의 소유가 작동하는 멀티플레이 환경을 보장하지는 않는다.
KisakCOD는 소스 수준의 유지보수로 이 문제에 대응한다. 퍼블리셔 모델은 중앙집중식 소유권을 보호하는 반면, 보존 모델은 기술적 통제권을 분산한다. 어느 쪽도 노후화된 독점 게임이 제기하는 모든 문제를 해결하지는 못한다.
프로젝트의 영향력은 Hacker News의 관심보다 기여자들의 행동에 더 크게 좌우될 것이다. 신중한 포팅, 테스트, 취약점 수리는 보존의 당위성을 뒷받침할 수 있다. 통제되지 않은 재배포나 안전하지 않은 공개 서버는 이 접근법에 대한 반론을 강화할 것이다.
보안 및 소유권 문제는 여전히 미해결이다
읽을 수 있는 소스는 방어자가 Call of Duty 4를 수정하는 데 도움이 될 수 있지만, KisakCOD는 온라인 플레이가 안전하거나 법적으로 다툼의 여지가 없다는 점을 입증하지 못했다.
저장소에는 이례적으로 직접적인 보안 경고가 포함돼 있다. Call of Duty 4는 알려진 익스플로잇이 존재하는 오래된 게임이며, 온라인에서 바이너리 익스플로잇이 발생할 가능성이 0이 아니라는 점을 인정한다. 유지 관리자는 추가 격리를 위해 샌드박스 사용을 권장한다.
이 경고는 애호가들이 프로젝트를 평가하는 방식에 영향을 미쳐야 한다. 빌드에 성공했다고 해서 보안이 강화된 멀티플레이 클라이언트라는 뜻은 아니다. 호환성 테스트는 예상한 기능이 작동하는지 묻는 반면, 보안 테스트는 악의적인 입력에 프로그램이 어떻게 동작하는지 묻는다.
오래된 네트워크 코드는 현재와 매우 다른 위협 환경을 전제로 하는 경우가 많다. 범위 검사, 패킷 파싱, 인증, 의존성 로딩, 메모리 관리는 모두 검토할 가치가 있다. 재구성된 코드는 소매용 실행 파일에는 없었던 결함을 새로 도입할 수도 있다.
공개 개발은 이러한 검토에 이점을 제공한다. 기여자는 테스트 중 잘못된 메모리 접근을 감지하는 컴파일러 기능인 AddressSanitizer를 추가할 수 있다. 개발 계정에 따르면 팀은 충돌과 손상된 메모리 동작을 조사하는 동안 이를 사용했다.
방어자는 취약한 경로를 검사하고, 회귀 테스트를 만들며, 패치를 공개적으로 검토할 수 있다. 서버 운영자는 빌드를 비교하고 개별 코드 변경 사항을 추적할 수 있다. 이러한 이점은 폐쇄형 실행 파일에서 얻을 수 있는 제한적인 가시성보다 크다.
공격자도 같은 가시성을 얻는다. 모든 관련 기능을 직접 재구성하지 않고도 검사되지 않은 입력이나 취약한 가정을 식별할 수 있다. 따라서 공개 소스는 취약점 발견과 익스플로잇 양쪽의 경제성을 바꾼다.
균형은 유지보수 품질에 달려 있다. 대응이 빠른 프로젝트는 공개를 패치와 더 안전한 기본 설정으로 전환할 수 있다. 인력이 부족한 프로젝트는 발견된 약점을 해결하는 속도보다 공격 표면을 공개하는 속도가 더 빠를 수 있다.
검토 당시 저장소에는 열린 이슈가 23개 있었고, 표시된 열린 풀 리퀘스트는 없었다. 이 스냅샷은 코드 품질을 측정하지 않으며 이슈 수는 자주 변한다. 다만 KisakCOD가 완성된 호환성 계층이 아니라 여전히 활발히 개발 중인 엔지니어링 프로젝트임을 보여준다.
라이선스는 또 다른 불확실성을 만든다. 저장소는 코드를 GPL-3.0으로 표기하고 있으며, 일반적으로 이는 수령자가 정해진 조건 아래 대상 코드를 사용, 연구, 수정, 재배포할 수 있게 한다. 하지만 저장소 라이선스는 이를 적용하는 사람이 보유한 권리에만 미친다.
리버스 엔지니어링은 일부 상황에서, 특히 상호운용성을 위해 필요한 경우 합법적일 수 있다. Electronic Frontier Foundation이 설명한 리버스 엔지니어링 프레임워크는 저작권, 영업비밀, 계약, 우회 방지, 통신 관련 법률을 관련 영역으로 제시한다.
EFF는 법원이 상호운용성을 위한 일부 중간 복제를 공정 이용으로 인정해 왔다고 지적한다. 또한 결과는 사실관계, 라이선스, 관할권에 따라 달라진다고 강조한다. KisakCOD는 재구성된 모든 구성 요소가 그러한 논리에 따라 보호된다는 점을 확립하는 공개적인 법적 판단을 받은 적이 없다.
따라서 구현 방식이 중요하다. 클린룸 재구현은 보통 원본 동작을 연구하는 사람과 문서화된 명세를 바탕으로 대체 코드를 작성하는 사람을 분리한다. 반면 KisakCOD의 공개 개발 계정은 심볼, 맵 파일, 바이너리 비교의 도움을 받은 직접 디컴파일을 설명한다.
이 설명만으로 합법성이 자동으로 결정되지는 않는다. 다만 독자들은 이 프로젝트를 Call of Duty 4의 승인된 오픈소스 에디션으로 가볍게 소개하지 않아야 한다는 뜻이다. 이는 유지 관리자가 선택한 라이선스를 적용한 제3자 재구성 프로젝트다.
상용 미들웨어는 배포를 더 복잡하게 만든다. 빌드 지침은 외부 DLL과 원본 게임 파일을 요구한다. 이런 요구 사항은 저장소가 완전한 대체재로 작동하는 것을 막는 데 도움이 되지만, 사용자는 여전히 의존성을 적절하게 확보하고 사용할 책임이 있다.
상표와 게임 에셋은 별도의 보호층을 더한다. 맵, 텍스처, 사운드, 스토리 콘텐츠, 캐릭터 디자인, Call of Duty라는 명칭은 엔진 동작이 독립적으로 재현됐더라도 여전히 보호될 수 있다. 컴파일 가능한 소스가 이런 자료를 퍼블릭 도메인으로 만들지는 않는다.
기여자에게는 기능만큼 출처가 중요하다. 패치는 관찰, 공개된 참조 코드, 독자 구현, 디컴파일러 출력 중 어디에서 비롯됐는지 설명해야 한다. 명확한 기록은 기술 검토를 쉽게 만들고 새 기여물에 관한 모호함을 줄일 것이다.
사용자가 내려야 할 판단은 더 단순하다. 실험적인 온라인 빌드는 신뢰할 수 없는 소프트웨어로 취급하고, 가능한 경우 격리하며, 호환성이 안전을 뜻한다고 가정하지 말아야 한다. 프로젝트가 보안 검토와 수정된 취약점 범주를 문서화하기 전까지는 특히 공개 서버에 주의할 필요가 있다.
보존의 트레이드오프를 통해 본 KisakCOD
KisakCOD는 내부 구조를 드러내어 동작을 보존하지만, 그 충실성은 기술 부채와 독점 자료에 대한 의존성도 함께 보존한다.
게임 보존은 흔히 에셋과 실행 파일에서 시작한다. 이런 산출물은 호환성 계층, 가상 머신, 에뮬레이터를 통해 계속 작동할 수 있다. 그러나 각 접근법은 운영체제, 프로세서 동작, 그래픽 API, 온라인 서비스에 대한 가정에 의존한다.
소스 수준 재구현은 보존의 대상을 옮긴다. 고정된 실행 파일만 보존하는 대신, 새 실행 파일을 생성할 만큼 이해된 로직을 보존한다. 개발자는 게임플레이 동작을 유지하면서 폐기된 인터페이스를 교체할 수 있다.
KisakCOD의 현재 Windows 요구 사항은 이러한 전환이 아직 불완전함을 보여준다. Visual Studio, DirectX SDK, 원본 런타임 구성 요소는 프로젝트를 오래된 Microsoft 소프트웨어 환경에 묶어 둔다. 코드는 공개돼 있지만, 전체 빌드 체인은 아직 널리 이식 가능하지 않다.
이 프로젝트는 현대적인 엔진을 처음 원리부터 설계하기보다 특이한 동작까지 재구성한다. 이 선택은 원본 맵과 게임플레이의 호환성을 유지하는 데 도움이 된다. 동시에 현대 소프트웨어라면 버릴 가정까지 유지할 수 있다.
물리는 이러한 트레이드오프를 보여준다. 보도에 따르면 팀은 솔버와 할당 동작을 포함해 Infinity Ward가 Open Dynamics Engine에 가한 변경 사항을 재현해야 했다. 모든 것을 최신 물리 스택으로 교체하면 유지보수는 단순해질 수 있지만, 이동, 충돌, 멀티플레이 동기화가 달라질 수 있다.
렌더링도 비슷한 문제를 제기한다. 현대적인 그래픽 계층은 이식성을 개선할 수 있지만, 미세한 차이가 조명과 에셋 동작을 바꿀 수 있다. 개발 이력은 작은 재구성 오류로 인해 검은 모델, 잘못된 라이트 그리드, 누락된 셰이더 등 여러 문제가 발생했다고 설명한다.
네트워크 호환성에는 훨씬 더 높은 정밀도가 필요하다. 멀티플레이 클라이언트와 서버는 상태, 타이밍, 메시지 레이아웃, 예측 방식에 대해 일치해야 한다. 더 깔끔한 구현도 원본 프로토콜이 기대하는 동작을 바꾸면 실패할 수 있다.
이 때문에 KisakCOD는 실행 여부만으로 평가해서는 안 된다. 더 중요한 시험은 독립 개발자가 한 하위 시스템을 수정하면서 관련 없는 동작을 반복적으로 망가뜨리지 않을 수 있는지다. 문서화, 테스트, 재현 가능한 빌드, 코드 검토가 그 결과를 결정할 것이다.
비슷한 프로젝트는 여러 가능한 경로를 보여준다. 일부는 사용자가 원본 에셋을 제공하도록 요구하면서 게임 엔진을 재구현한다. 다른 프로젝트는 클린룸 개발을 통해 동작을 재현한다. 공식 소스 릴리스는 더 명확한 허가에서 시작하지만, 여전히 상용 미들웨어를 제외하는 경우가 많다.
KisakCOD는 상업적으로 통제되는 엔진을 직접 재구성하기 때문에 더 불확정적인 위치에 있다. 이 선택은 풍부한 디버그 심볼의 도움을 받아 충실도와 속도를 제공했다. 동시에 완전히 독립적인 대체 엔진보다 더 큰 출처 입증 부담을 만들었다.
저장소의 GPL 라이선스는 기여자들이 그 부담을 받아들인다면 공동 유지보수 기반을 뒷받침할 수 있다. 대상 코드가 배포될 때 개선 사항은 라이선스에 따라 계속 이용 가능해야 한다. 이는 개인 포크가 커뮤니티의 수정 사항을 흡수하면서 이에 대응하는 소스를 돌려주지 않는 일을 막을 수 있다.
그러나 라이선스가 건전한 커뮤니티를 보장하지는 않는다. 공개 저장소에는 패치를 검토하고, 범위를 정의하며, 아키텍처를 문서화하고, 보안 보고에 대응하는 유지 관리자가 필요하다. 이런 작업이 없으면 코드 공개는 지속 가능한 프로젝트가 아니라 보관용 증거가 된다.
Hacker News의 관심은 이 지점에서 도움이 될 수 있다. 경험 많은 시스템 개발자들은 소규모 팀이 놓친 컴파일러 산출물, 네트워킹 오류, 오래된 그래픽 가정을 알아볼 수 있다. 또한 프로젝트의 주장과 라이선스 선택을 더 날카롭게 검토할 수 있다.
가장 좋은 결과는 제한 없는 향수형 서버가 하룻밤 사이에 등장하는 것이 아니다. Call of Duty 4 소유자가 현대 시스템에서 합법적인 사본을 계속 작동시킬 수 있도록 하는, 문서화되고 테스트 가능한 엔진이 되는 것이다. 이 목표에는 기술적 야망과 함께 절제가 필요하다.
Hacker News의 순간이 다음으로 검증해야 할 것
세 가지 신호가 KisakCOD가 지속 가능한 보존 인프라가 될지, 아니면 인상적이지만 위험한 재구성으로 남을지를 보여줄 것이다.
첫 번째 신호는 원래 유지 관리자의 환경 밖에서 재현 가능한 빌드다. 다른 개발자가 저장소를 클론하고, 합법적인 게임 파일을 제공하며, 문서화된 단계를 따라 동일하게 작동하는 대상 파일을 생성할 수 있어야 한다. 자동화된 검사는 컴파일과 핵심 동작을 다뤄야 한다.
이 신호는 재현성이 개인의 전문성을 이전 가능한 유지보수 역량으로 바꾸기 때문에 프로젝트를 강화할 것이다. 반복되는 설정 실패는 KisakCOD가 의도한 사용자층을 위해 완전히 빌드 가능하다는 주장을 약화시킬 것이다.
크로스플랫폼 진전은 이 첫 번째 테스트에 포함된다. 보고된 Arm macOS 실험은 이미 fast-file 시스템의 32비트 가정을 드러냈다. 작동하는 독립 포트는 기여자들이 플랫폼 의존성을 안전하게 교체할 만큼 엔진을 잘 이해하고 있음을 보여줄 것이다.
두 번째 신호는 공개적인 보안 프로세스다. 프로젝트에는 명확한 제보 경로, 알려진 취약점 유형에 대한 문서화된 수정 사항, 악의적인 네트워크 입력을 대상으로 한 회귀 테스트가 필요하다. 보안 권고문은 기존 Call of Duty 결함과 재구성 과정에서 발생한 오류를 구분해야 한다.
이 분야에서 의미 있는 진전이 이뤄진다면 공개 유지보수의 정당성이 강화될 것이다. 소스 공개가 공격자의 연구 비용을 낮추는 데 그치지 않고 방어자에게 도움이 된다는 점을 보여줄 수 있다. 패치되지 않은 제보나 허술하게 운영되는 공개 서버는 그 주장을 약화시킬 수 있다.
기존 경고는 책임감 있는 조치지만, 출발점일 뿐이다. 사용자에게 샌드박스를 실행하라고 권고하는 것은 위험을 개인에게 전가한다. 보존 프로젝트는 결국 강화된 기본 설정과 노출된 시스템을 어떻게 검토했는지에 대한 기록이 필요하다.
세 번째 신호는 권리 보유자와 인프라 플랫폼의 대응이다. Microsoft 또는 Activision은 리포지터리를 묵인하거나, 변경을 요청하거나, 허용 가능한 경계를 명확히 하거나, 삭제를 추진할 수 있다. GitHub 역시 서비스 제공 여부에 영향을 줄 수 있는 법적 민원을 받을 수 있다.
계속 공개되어 있다고 해서 공식 승인을 의미하는 것은 아니다. 그럼에도 원본 에셋, 미들웨어, 브랜딩, 재구성된 코드에 관한 명확한 경계는 불확실성을 줄일 수 있다. 삭제 요청이나 대대적인 리포지터리 재작성은 프로젝트의 현재 보존 경로를 직접적으로 약화시킬 것이다.
권리 보유자의 대응과 함께 기여자의 출처도 주시해야 한다. 유지관리자는 재구성된 함수의 출처를 문서화하고, 기원이 불분명한 자료를 거부함으로써 입지를 강화할 수 있다. 모호한 추가 사항은 라이선스 주장을 평가하기 더 어렵게 만들 것이다.
당장의 Hacker News 논의는 이런 결과를 예측하기에는 너무 작다. 스타와 포크는 관심도를 측정할 뿐, 호환성이나 안전성, 법적 지속 가능성을 보여주지는 않는다. 리포지터리의 다음 기술적 이정표가 더 나은 근거를 제공할 것이다.
KisakCOD는 오래된 디버그 아티팩트가 독점 멀티플레이어 엔진에 대한 깊은 접근을 가능하게 할 수 있음을 이미 보여줬다. 하지만 그 결과물인 코드가 안전하고 이식 가능하며 제도적으로 안정적인 커뮤니티를 뒷받침할 수 있는지는 아직 입증하지 못했다.
프로젝트에 관심 있는 개발자는 공개 서버에 연결하기 전에 빌드 요구 사항과 보안 경고를 읽고, 이슈 이력을 검토해야 한다. 보존을 지지하는 이들은 재현 가능한 포팅, 보안 수정, 권리 보유자의 반응을 추적해야 한다. 이러한 신호가 이 Hacker News 발견이 Call of Duty 4 멀티플레이어의 지속적인 보금자리가 될지, 아니면 일반 플레이어에게는 여전히 불확실성이 큰 인상적인 코드베이스로 남을지를 결정할 것이다.


