AI가 게임 코드를 역컴파일한다

게임 회사들이 실행 파일을 배포하면 소스 코드는 사라진다고들 생각해왔다. 컴파일이 끝난 코드는 기계만 읽는 형태여서, 사람이 원래 의도를 복원하기는 어렵다는 게 기본 전제였다. 수십 년 동안 그 전제는 사실상 틀린 적이 없었고, 실행 파일 배포는 곧 코드 보호와 동의어처럼 쓰였다. 그런데 AI가 이 전제를 조금씩 흔들기 시작했다. 이 흐름을 알고 나서, 코드 보호가 얼마나 믿을 수 있는 건지 다시 생각하게 됐다.

역컴파일이 막혀 있던 이유

역컴파일은 실행 파일에서 소스 코드에 가까운 형태를 되살리는 작업이다. 컴파일러는 개발자가 작성한 코드를 CPU가 처리할 수 있는 기계어로 바꾼다. 이 과정에서 변수 이름, 함수 이름, 주석은 거의 다 사라지며, 타입 정보나 클래스 구조처럼 고수준 개념들도 함께 소실된다. 최적화까지 거치고 나면 루프가 펼쳐지거나 함수가 인라인으로 합쳐지면서 원본 코드와 구조 자체가 달라지는 경우도 있다. 컴파일 전후의 코드는 기능은 같아도 형태는 완전히 다른 두 가지가 된다.

기존 역컴파일 도구들은 이 기계어를 C처럼 읽히는 형태로 바꿔준다. NSA가 2019년에 무료로 공개한 Ghidra가 대표적인 도구로, 보안 연구자들이 처음 진입점으로 많이 쓴다. 수십 년째 보안 연구 현장에서 쓰여온 IDA Pro는 상용 제품으로 Hex-Rays 디컴파일러까지 포함해 기능이 훨씬 많다. 이 도구들은 어셈블리를 읽히는 형태로 바꿔주지만, 읽힌다고 이해되는 건 아니다. 함수 이름 자리에 sub_14001A230 같은 주소만 수천 개 나열돼 있으면, 어디서 무슨 일이 벌어지는지 파악하기가 어렵다.

실제 소스 코드에서는 getPlayerSpeed() 같은 이름을 쓴다. 컴파일 후에는 그 이름이 주소로 치환되고, 주석이나 개발자 노트도 전부 날아간다. 그 주소들이 서로 호출하고 참조하면서 수천 개씩 얽혀 있을 때, 어떤 게 어떤 기능인지 따라가는 건 전문가도 시간이 오래 걸리는 일이다. 예를 들어 플레이어 이동 속도를 조작하는 함수 하나를 찾으려면, 관련 있어 보이는 함수들을 하나씩 추적하며 며칠을 소비하는 일이 드물지 않았다. 하나씩 뜯어보면서 메모를 달아가는 방식이 사실상 유일한 방법이었다.

게임 쪽에는 분석을 더 어렵게 만드는 기법도 따로 있다. 난독화는 코드 구조를 의도적으로 복잡하게 바꿔서 분석을 방해하는 방식이다. 쓸모없는 명령어를 끼워 넣거나, 조건 분기를 복잡하게 꼬거나, 문자열을 암호화해서 숨기는 방법을 쓰고, 이 중 문자열 암호화는 게임 내 오류 메시지나 서버 주소 같은 단서를 숨기는 데 특히 많이 쓰인다. 게임 클라이언트에 많이 쓰이는 상용 보호 솔루션들은 이 과정을 자동화해서 빌드마다 적용한다.

이 모든 장벽이 합쳐지면 게임 실행 파일 분석은 소수 전문가들만 할 수 있는 영역이 된다. 도구가 있어도 의미 있는 코드를 찾아내려면 함수 하나하나를 수작업으로 들여다봐야 했다. 리버스 엔지니어링 경험이 없는 사람이 처음 Ghidra를 열면 무엇부터 봐야 할지조차 막막한 게 현실이다. 그 속도가 워낙 느려서, 일반적인 치트 개발이나 저작권 침해 경로로는 잘 활용되지 않았다. 높은 진입 장벽이 사실상 보호막 역할을 해온 셈이다.

AI가 파고드는 방식

LLM이 이 분야에 들어온 건 그 특성 때문이다. LLM은 대규모 언어 모델로, 수십억 줄의 코드를 학습해서 코드 패턴을 파악한다. GitHub에 공개된 오픈소스 코드들이 주요 학습 데이터인데, 이 덕분에 실제 개발자들이 짜는 코드 패턴을 상당히 깊이 내재화하고 있다. 기호가 없는 어셈블리를 봐도 반복 구조나 함수 호출 패턴을 보고 그 함수의 역할을 추측할 수 있다. 사람이 맥락으로 의미를 유추하는 방식과 닮아 있다.

실제로 쓰이는 방법 중 하나는 Ghidra에 GPT를 연결하는 방식이다. 함수에 자동으로 이름을 붙이는 플러그인들이 이미 오픈소스로 공개돼 있으며, 스크립트 한 줄로 수백 개의 함수 이름을 한꺼번에 추측해 붙일 수 있다. 다른 방법은 어셈블리 블록을 잘라서 GPT-4 같은 모델에 직접 넣고 묻는 것이다. 완전한 소스 복원이 목적이 아니라, 수천 개의 익명 함수 중에서 어디를 먼저 볼지 추려내는 데 효과적이다. 우선순위를 빠르게 정할 수 있다는 것만으로도 수작업과 비교해 체감 속도가 크게 달라진다.

Avast가 오픈소스로 공개한 역컴파일러 RetDec처럼 정적 분석에 특화된 도구들도 있다. 이런 기존 역컴파일러에 LLM을 결합한 파이프라인들이 연구자들 사이에서 계속 발표되고 있다. 예를 들어 RetDec로 먼저 C 형태로 변환하고, 그 결과물을 다시 GPT-4에 넘겨 변수명과 함수명을 자연스럽게 복원하는 두 단계 방식이 효과적이라는 보고가 나오고 있다. 아직 하나의 완성된 도구로 정착하지는 않았고, 여러 도구를 단계별로 엮어서 쓰는 방식이 대부분이다. 표준 워크플로가 없다는 건 진입 장벽이 여전히 있다는 뜻이기도 하다.

AI가 특히 잘하는 건 유사한 패턴을 인식하는 일이다. 체력 계산, 충돌 감지, 네트워크 패킷 처리 같은 기능은 게임마다 구조가 비슷하다. 예를 들어 체력바가 0이 됐을 때 캐릭터를 사망 상태로 전환하는 로직은 게임마다 세부 구현이 다르지만, 전반적인 조건 분기 구조는 상당히 일관된 패턴을 갖는다. LLM은 이런 공통 패턴을 수없이 학습했기 때문에, 비슷한 구조가 나오면 추측이 꽤 잘 맞는다. 알려진 패턴 안에 있는 코드일수록 정확도가 올라간다.

반대로 게임 특유의 커스텀 알고리즘이나 독자적인 최적화 코드에서는 정확도가 눈에 띄게 떨어진다. 학습 데이터에 없는 패턴이면 모델도 엉뚱한 이름을 붙이거나 잘못된 추측을 낸다. 특히 독자적인 물리 엔진이나 렌더링 파이프라인처럼 외부에 공개된 레퍼런스가 적은 코드는 AI도 자신 없는 답변을 내놓는 경우가 많다. AI를 완전히 믿기보다는 초기 탐색에서 방향을 잡는 용도로 쓰는 게 현실적이라는 평가가 많다. 그 한계를 알고 쓰는 사람과 모르고 쓰는 사람의 결과물 차이는 상당하다.

직접 해본 결과

이 분야에서 공개된 사례들을 보면 결과가 일정하지 않다. 게임 실행 파일을 Ghidra로 열고 GPT 플러그인을 붙인 시도들이 여럿 기록돼 있다. 함수의 역할이 거의 맞아떨어진 경우도 있고, 아무리 시도해도 쓸 만한 결과가 나오지 않은 구역도 있었다는 보고가 많다. 같은 실행 파일 안에서도 쉽게 읽히는 영역과 전혀 안 읽히는 영역이 공존하기 때문에, 도구가 만능이라는 인상을 섣불리 갖기 어렵다. 읽히는 것과 읽히지 않는 것이 뒤섞여 있는 게 솔직한 그림이다.

잘 읽히는 쪽은 단순 연산 위주의 기능들이다. 화면 렌더링, 입력 처리, 세이브 파일 읽기처럼 구조가 비교적 뚜렷한 코드들이 여기 해당한다. 특히 파일 입출력 관련 코드는 표준 라이브러리 호출 패턴이 명확해서 AI가 함수 경계와 역할을 빠르게 파악하는 경향이 있다. 반면 안티치트 코드나 서버 통신 암호화 부분은 훨씬 더 어렵다는 보고가 많다. 보호 레이어가 두꺼울수록 AI 추측의 정확도도 낮아지는 경향이 뚜렷하다.

AI가 붙인 이름이 맞는지 검증하는 과정도 만만치 않다. 틀린 추측을 사실처럼 따라가다 보면 분석 전체가 엉뚱한 방향으로 흘러간다. 예를 들어 AI가 어떤 함수를 충돌 감지로 추측했지만 실제로는 히트박스 크기를 계산하는 함수였다면, 그 추측을 기반으로 세운 가설 전체가 흔들리게 된다. 그래서 AI가 제안한 이름을 임시 라벨로만 달아두고, 나중에 따로 검증하는 방식을 쓰는 경우가 많다고 한다. 신뢰도를 관리하는 습관이 없으면 잘못된 분석을 오래 끌고 가게 된다.

속도 면에서는 분명히 달라진 점이 있다. 수동으로 하면 며칠이 걸릴 초기 탐색이 AI 조합으로는 몇 시간 안에 끝난다는 보고들이 나오고 있다. 완전한 분석이 빨라진다기보다는, 어디를 집중해서 볼지 추려내는 속도가 빨라진다는 표현이 더 정확하다. 방향 설정 속도가 달라지면 전체 작업량도 따라서 달라지고, 전에는 포기했을 규모의 프로젝트도 시도해볼 수 있게 된다. 이 속도 차이가 진입 장벽을 어느 정도 낮추는 요인이 된다는 점에서 게임사에게는 의미 있는 변화다.

게임 엔진마다 분석 난이도도 다르다는 점도 보인다. 언리얼 엔진처럼 널리 알려진 엔진 기반 코드는 학습 데이터가 풍부해서 AI가 더 정확하게 추측하고, 실제로 언리얼 엔진 내부 구조를 이미 알고 있는 AI가 관련 함수를 꽤 높은 확률로 식별했다는 사례도 있다. 반면 자체 제작 엔진을 쓰는 게임은 패턴이 낯설어서 AI도 헤매는 경향이 있다. 코드가 독자적일수록 AI 분석의 이점이 줄어드는 셈이다. 역설적으로 독자 엔진이 가장 강력한 보호 방식 중 하나가 될 수 있다는 뜻이기도 하다.

저작권과 보안 갈림길

이 기술이 퍼지면서 게임사 입장에서는 새로운 고민이 생겼다. 역컴파일의 문턱이 낮아지면 저작권이 있는 코드를 분석하거나 치트 도구를 만드는 일이 쉬워질 수 있다. 실제로 온라인 사격 게임을 대상으로 AI 역컴파일을 활용해 에임봇 관련 함수를 빠르게 식별했다는 보고가 해외 커뮤니티에서 간헐적으로 올라오고 있다. 특히 멀티플레이어 게임에서는 핵 개발자들이 이 방식을 이미 활용하고 있다는 정황들이 보인다. 기술 자체의 발전이 의도치 않게 악용 경로를 넓히는 상황이다.

법적 경계는 아직 선명하지 않다. 미국 DMCA는 소프트웨어의 기술적 보호 조치를 우회하는 행위를 금지하고 있다. DMCA는 디지털 밀레니엄 저작권법으로, 복제 방지 장치나 보안 기술을 뚫는 것도 이 법의 적용 대상이 된다. 다만 보안 연구, 상호운용성, 접근성 목적에 대해서는 예외 조항을 두고 있어 해석의 여지가 남는다. 어떤 목적으로 쓰였느냐를 어떻게 입증하느냐가 핵심이 되며, AI 도구를 매개로 한 역컴파일이 이 범주 어디에 해당하는지는 아직 법원의 판단이 충분히 쌓이지 않은 영역이다.

보안 연구자들은 방어 목적이라는 논리를 내세운다. 게임의 취약점을 찾아서 패치하려면 역컴파일이 필요하다는 주장이다. 실제로 많은 버그 바운티 프로그램이 이 방식으로 발견된 취약점 보고를 받아들이고 있다. 같은 도구가 악용될 수 있다는 사실은 부정하기 어렵지만, 그 논리가 현장에서 통해온 게 현실이다. 게임사 스스로도 역컴파일 기술을 보안팀 내부에서 쓰면서 연구자들의 공개 활동을 마냥 막기 어려운 모순적인 위치에 있다.

게임사들도 가만히 있지는 않는다. 커널 레벨 안티치트처럼 더 깊은 보호 레이어를 쌓거나, 핵심 로직을 서버에만 두는 방식으로 대응하고 있다. 서버 사이드 검증을 강화하면 클라이언트 코드를 아무리 분석해도 실질적으로 조작할 수 있는 부분이 줄어든다는 논리다. AI 기반 역컴파일이 강해질수록, 방어 쪽에서도 AI를 써서 코드를 더 복잡하게 만드는 경쟁이 생길 수 있다. 도구가 강해지면 그 도구를 막는 도구도 함께 강해지는 구조다.

지금 단계에서 AI가 역컴파일을 완전히 바꿔놓은 건 아니다. 하지만 예전이라면 전문가만 할 수 있었던 초기 탐색을 더 많은 사람이 더 빠르게 할 수 있게 된 건 사실이다. 법적 정비가 기술을 따라가지 못하는 격차는 당분간 계속될 것 같다. 그 격차 안에서 어떤 관행이 자리를 잡느냐가 앞으로 중요해질 것이고, AI 도구를 둘러싼 법적 기준이 어떻게 정립되느냐에 따라 이 분야 전체의 지형이 달라질 수 있다.