리버스 엔지니어링의 산업 혁명

2026년 8월에 달라진 것

이 작업 전에는 수동 리버스 엔지니어링을 많이 했습니다. 함수를 살펴 설명을 도출하고, 실제 프로그램으로 그 설명을 검증하곤 했습니다. 더 나아가려면 다음 함수에도 제 시간을 들여야 했습니다. 머릿속에 담아 두어야 할 전체 구조도 점점 커졌습니다.

제 리버스 엔지니어링 작업은 대부분 게임을 대상으로 합니다. 게임의 동작을 이해하고 궁극적으로 다른 플랫폼으로 이식하거나 모드를 만들 수 있도록 게임을 재구성합니다. 이 글은 그런 경험을 바탕으로 합니다. 이 방법은 다른 분야에도 유용할 수 있지만, 각 분야에서 신뢰할 수 있는 기준과 대조해 무엇을 검증할 수 있는지 정립해야 합니다.

2026년 8월, 에이전트 중심의 리버스 엔지니어링을 본격적으로 탐구하기 시작했습니다. 프로그램과 일반 개발 도구를 제공하면 에이전트가 어디까지 해낼 수 있는지 궁금했습니다. 동방 재구성은 이를 알아볼 만한 규모의 프로젝트였습니다.

초기의 진전은 놀라웠습니다. 제가 모든 단계를 일일이 선택하지 않아도 조사는 계속 진행될 수 있었습니다. 비교가 실패하면 에이전트는 다른 호출 함수를 조사할 수 있었습니다. 작은 진단 코드를 작성하고 그 결과를 바탕으로 다음에 무엇을 시도할지 결정할 수도 있었습니다. 이런 자율성이 차이를 만들었습니다. 저는 프로젝트의 방향과 검사의 신뢰성에 더 집중할 수 있었습니다.

처음에는 속도에 눈길이 갔습니다. 그러다 이번 프로젝트가 끝난 뒤에도 무엇이 남을지 궁금해졌습니다. 방금 배운 것들이 다음 게임에도 도움이 될까요?

TH08: 사람의 작업을 바탕으로

TH08, 동방영야초는 GensokyoClub의 재구성 작업을 이어받아 시작했습니다. 공개된 소스는 탄탄한 토대가 됐습니다. 빌드에 관한 지식과 기여 이력도 함께 있었고, 작업을 이어가며 그 이력을 보존했습니다.

가져온 이력은 공개된 8월 10일 체크포인트까지입니다. 독립적인 후속 작업은 8월 13일에 시작했습니다. 8월 19일에는 식별된 게임 함수 1,107개 모두의 소스가 작업 기록에 남았습니다.

플레이 가능한 Linux 재구성 이식판은 작업을 이어가기 시작한 지 약 11일 뒤인 8월 24일에 커밋되었습니다. 이어서 웹 버전이 나왔습니다. 네이티브 Linux 64비트 버전은 8월 30일에 출시되었습니다.

인상 깊었던 점은 사람들이 실제로 실행할 수 있는 프로그램이 됐다는 것입니다. 그러려면 개별 함수를 넘어선 문제도 추적해야 했습니다. 두 함수가 각각 올바르게 보여도, 공유해야 할 상태를 서로 다른 복사본으로 사용하는 문제가 생길 수 있었습니다.

그래서 기준과의 대조 검증이 작업의 핵심이 됐습니다. 저는 이런 기준을 오라클이라고 부릅니다. 코드 비교는 재구성한 함수가 원래 명령어를 재현하는지 알려줍니다. 런타임 검증은 실행한 경로가 예상 상태에 도달하는지 알려줍니다. 에이전트는 설명을 제안하고 검증하며, 불일치가 나오면 구체적인 조사 대상으로 삼습니다.

잘못된 상수로도 완전 일치 판정

오라클 역시 누군가 작성한 소프트웨어입니다. TH08은 우리가 그 소프트웨어에 얼마나 의존하는지 분명히 보여줬습니다.

9월에 후속 Switch 이식판에서 보고된 버그를 추적하다가 아이템 자동 수집 기능에 도달했습니다. 재구성된 소스는 플레이어의 파워를 0.0과 비교했습니다. 원본은 최대 파워 임계값인 128.0을 사용했습니다.

정상적인 파워는 음수가 아니므로, 재구성한 코드의 파워 조건은 사실상 항상 참이었습니다. 수집선 위에서는 최대 파워가 아니어도 아이템을 끌어올 수 있었습니다. 나머지 예외 조건은 올바르게 구현됐습니다. 상수 하나가 동작을 바꾼 것입니다.

그런데 이 함수는 이미 명령어 완전 일치 검사를 통과한 상태였습니다.

다시 빌드하면 상수의 주소가 달라질 수 있습니다. 비교 도구는 이를 고려해 컴파일된 명령어의 주소를 조정한 뒤 원본과 비교했습니다. 하지만 참조 주소에 저장된 부동소수점 값은 확인하지 않았습니다.

그로 인해 검증에 허점이 생겼습니다. 소스에는 여전히 0.0이 쓰여 있어도, 재구성된 명령어가 원본의 128.0을 가리키도록 바꿀 수 있었습니다. 명령어 바이트는 일치했지만, 소스가 뜻하는 바는 달랐습니다.

9월 2일 수정에서는 소스를 고치고 참조 상수의 실제 바이트까지 비교하도록 했습니다. 이어진 확대 점검에서는 부동소수점 리터럴 참조 1,548개를 조사했습니다. 통과했던 함수 5개에서 잘못된 참조 12개를 추가로 발견했습니다.

이제 비교 도구는 해당 부동소수점 리터럴을 모두 확인합니다. 잘못된 값을 의도적으로 넣어 거부되는지도 테스트합니다. 이전의 불완전한 검사를 통과한 결과도 다시 살펴봐야 했습니다.

오라클 자체도 재구성이 필요했습니다. 검증 도구를 고치는 일도 게임을 고치는 과정의 일부였습니다.

사실상 한 사람이 에이전트들과 일하는 팀에서는 특히 중요합니다. 에이전트가 만든 모든 줄을 직접 살필 수 없으므로, 결과에 대한 신뢰는 검증에 크게 의존합니다. 공통 오라클의 사각지대는 제가 알아채기 전에 여러 조사에 영향을 줄 수 있습니다. 검사기가 실제로 무엇을 검증하는지 이해하고, 실패해야 할 사례로도 테스트해야 합니다.

작업이 이어지면서 그런 검사들이 저장소의 일부가 되었습니다. 소스를 변경한 이유와 이후 세션이 이전 세션에서 멈춘 지점부터 작업을 이어갈 수 있게 하는 메모도 마찬가지였습니다. 저장소는 프로젝트의 작업 메모리가 되어 가고 있었습니다.

한 묶음의 작업이 성공할 때마다 복구된 코드와 함께 다음 작업을 위한 더 나은 환경이 남았습니다.

재구성을 바라보는 두 가지 관점

GensokyoClub의 공개 README는 이런 작업 방식에 반대한다는 입장을 명시합니다. 해당 공지는 작업이 완성될 때까지 추가 개발을 비공개로 진행한다고 알립니다. 한 구절은 다음과 같습니다:

우리 작업을 가져다 쓰는 편승자들(AI 디컴파일 및 이식)의 등장은 앞으로의 디컴파일 노력에 부정적인 이미지를 씌웁니다…

공지에는 유지보수자들이 받는 심리적 부담도 담겨 있습니다. 기여 정책에서는 주로 AI로 작성한 풀 리퀘스트를 받지 않습니다. 이들은 여가를 들여 어려운 작업을 했고, 그 작업 덕분에 저도 후속 작업을 시작할 수 있었습니다. 저는 그 노력을 존중합니다. 여기서 논의하려는 차이는 재구성을 어떻게 진행하고 기여를 어떻게 평가할지에 관한 것입니다.

제가 알던 수동 작업 방식에서는 함수를 이해하고 재구성하는 일을 보통 한 사람이 맡았습니다. 프로젝트는 그 사람의 전문성에 크게 의존했습니다. 많은 추론이 작업 중에 이루어졌기 때문에 기여자에 대한 신뢰가 중요했습니다.

기존 프로젝트도 소스와 빌드 도구에 지식을 보존합니다. 제게 달라진 점은 에이전트가 그 지식을 활용해 다음 조사를 스스로 진행할 수 있다는 것이었습니다.

제가 이어가는 작업에서는 목표와 결과의 수용 기준을 제가 정합니다. 에이전트는 폭넓은 자유를 갖고 조사합니다. 제안한 재구성은 관련 검사를 통과해야 합니다. 대부분을 에이전트가 수행했더라도, 다른 사람이 왜 그 구현을 선택했는지 검토할 수 있기를 바랍니다.

이런 전환은 어려울 수 있습니다. 수년간의 세심한 작업이 훨씬 빠르게 진행되는 후속 작업의 기반이 될 수 있습니다. 이는 공로를 어떻게 인정할 것인가라는 실제 문제를 제기합니다. 또한 유지 관리자가 기여를 받아들이기 전에 알아야 할 사항도 달라집니다.

산업에 빗대면 이 변화를 이해하기 쉽습니다. 수공업에서는 과정의 많은 부분이 작업자의 숙련도에 달려 있습니다. 기계가 도입되면 그 숙련도가 필요한 지점이 달라집니다. 여전히 누군가는 공정을 설계하고 결과가 잘못됐을 때 알아봐야 합니다. 각 커뮤니티는 이 변화를 어느 정도 받아들일지 선택할 수 있습니다.

저는 앞선 작업의 공로를 인정하고 이력을 보존하며 공개적으로 이어가기로 했습니다. 새 작업도 검토할 수 있게 만들고 싶습니다. 그래야 이 방식으로 어디까지 갈 수 있는지 살펴보고, 도중에 생기는 실패에서도 배울 수 있습니다.

출처: 2026년 10월 10일에 확인한 GensokyoClub의 README 공지와 기여 정책. 인용문은 일부를 줄여 발췌했습니다. TH08의 공로 및 출처 기록에는 후속 작업이 시작된 경계가 기록되어 있습니다.

TH095: 경험의 축적이 효과를 내기 시작하다

TH095, Shoot the Bullet에서는 그런 경험의 가치를 훨씬 쉽게 확인할 수 있었습니다. 저장소는 8월 29일에 시작되었고, 당시 기록 대장에는 확인된 게임 함수가 하나도 없었습니다. 게임 자체는 여전히 배워야 했습니다. 하지만 재구성을 어떻게 시작하고 계속 진행할지에 대해서는 이미 훨씬 많은 것을 알고 있었습니다.

9월 7일까지 확인된 게임 함수 697개 모두의 소스가 마련되었습니다. 9월 8일까지 696개가 정확한 일치 비교를 통과했습니다. 전체 프로그램은 9월 9일에 링크되었습니다. Windows i386 재구성판은 초기화 후 약 12일이 지난 9월 10일에 플레이 가능한 것으로 기록되었습니다.

저는 첫 프로젝트의 속도보다 이 점이 더 흥미로웠습니다. 새로운 대상이 다른 게임에서 한 작업의 도움을 받을 수 있었습니다. 그 경험은 이미 도구와 프로젝트 구성 방식에 녹아 있었습니다.

예를 들어 TH08에서는 일찍부터 전체 프로그램을 살펴봐야 한다는 것을 배웠습니다. 복구된 여러 함수가 같은 상태에 의존한다면, 각각의 비교만으로는 중요한 의문이 남습니다. 함께 작동하는 모습을 확인해야 합니다. 이 교훈은 TH095의 전체 프로그램 빌드에 접근하는 방식을 정하는 데 도움이 됐습니다.

제 머릿속에만 남아 있는 교훈은 제가 그 작업에 참여하는 동안에는 유용합니다. 하지만 다른 세션에서도 실행할 수 있는 검사가 되면 제가 다음 작업으로 넘어간 뒤에도 계속 도움이 됩니다. 다음 에이전트는 그 결과에 이르게 한 조사를 반복하지 않고도 결과를 활용할 수 있습니다.

부동소수점 리터럴 버그도 그 기억에 포함됩니다. 참조를 확인할 때 그 뒤에 있는 데이터까지 살펴야 하는 이유를 알려줍니다. 수정 사항을 코드와 함께 남기면 후속 프로젝트가 이전 검사의 사각지대까지 물려받는 일을 막을 수 있습니다.

방법론 자체가 다음 게임을 시작하는 토대가 됩니다. 다음 프로젝트에서는 새 대상만의 특성에 더 많은 노력을 쏟을 수 있습니다.

나중에 합류하는 사람도 같은 도움을 받습니다. 작업을 이어가기 전에 결정을 살펴보고 검증을 다시 실행할 수 있습니다. 소스가 왜 그렇게 작성됐는지 알기 위해 프로젝트의 전체 이력을 되짚을 필요는 없습니다.

TH04: 다른 아키텍처에서도 이어지는 작업 방식

TH04, Lotus Land Story는 이 작업의 범위를 PC-98 DOS 시대로 넓혔습니다. 이제 대상은 네 개의 프로그램이 협력하는 16비트 환경이었습니다. 하드웨어 동작을 이해하려면 Windows 게임과는 다른 증거가 필요했습니다. 기존의 ReC98 작업도 여기서 귀중한 지식과 소스 자료를 제공했습니다.

DOS 재구성판은 이제 작동합니다. 수동 테스트에서는 Normal 난이도의 경로를 엔딩까지 플레이하고 저장 기능도 확인했습니다. 현재는 네이티브 64비트 이식판을 작업하고 있습니다. 작동하는 DOS 버전을 먼저 확보해 두면 이식판을 검증할 기준으로 삼을 수 있습니다.

아키텍처가 달라지자 조사할 내용도 달라졌습니다. 결과를 검증하는 컴파일러와 실행 환경도 바뀌었습니다. 그래도 에이전트는 질문을 따라 결과에 도달하고, 그 결과로 다음 실험의 방향을 정할 수 있었습니다.

게임 플레이에서 엔딩으로 넘어가는 상황을 생각해 보세요. 어떤 상태가 그 경계를 넘어 유지되고, 어떤 프로그램이 이를 담당하는지 알아야 합니다. 이는 DOS 제품과 대조하여 조사할 수 있습니다. 증거와 검사가 준비되면 에이전트는 Windows 게임에서와 비슷하게 이 질문을 해결해 나갈 수 있습니다.

이것이 이 논의에서 TH04가 중요한 이유입니다. 플랫폼이 크게 바뀌어도 새로운 작업 방식을 처음부터 마련할 필요는 없었습니다. 아키텍처가 문제를 정했다면, 기존 작업 흐름은 여전히 해결 방법을 제공했습니다.

64비트 이식판에서는 이제 새 구현을 DOS에서 이미 복원한 동작과 대조해 검토할 수 있습니다. 재구성 과정에서 얻은 지식이 이식판의 기반이 됩니다.

2026년 10월 10일 기준 프로젝트 상태: DOS 재구성과 수동 테스트 · 64비트 이식판. 이식판은 아직 개발 중입니다.

정확한 코드에서 읽기 쉬운 코드로

재구성한 프로그램이 작동하면, 다른 사람도 그 코드를 이해할 수 있기를 바랍니다.

제게 어셈블리와 원시 오프셋은 오랜 친구처럼 익숙합니다. 물론 이를 “읽기 쉽다”고 부르는 건 조금 특이한 기준임을 압니다. 대부분의 사람은 실행 파일의 메모리 구조를 외우지 않고도 게임 로직을 이해하고 싶을 것입니다.

여기서 의미 재구성이 필요합니다. 복구한 필드는 아직 오프셋으로만 구분될 수 있습니다. 게임이 그 필드를 사용하는 방식을 추적해 역할을 설명할 수 있게 합니다. 그런 다음 증거에 맞는 이름과 타입을 붙입니다. 다음 사람이 해석의 근거를 알 수 있도록 판단 과정도 소스와 함께 남깁니다.

이것은 특히 이식판에서 중요합니다. 절대 주소는 이전 실행 파일에서 무언가가 어디에 있었는지 알려줍니다. 하지만 그 정보는 64비트 구현에서 어떤 객체가 해당 상태를 소유해야 하는지 결정하는 데 거의 도움이 되지 않습니다. 동작을 안전하게 옮기려면 기존 메모리 접근 뒤에 있는 관계를 복원해야 합니다.

지금은 다음 순서로 작업합니다.

1. 원본과 정확히 일치하는 기준 버전을 복구합니다. 재구성한 부분을 당시 컴파일러로 컴파일합니다. 관련 코드와 데이터를 원본 실행 파일과 비교합니다. 다음 단계의 출발점이 명확하도록 해결하지 못한 차이도 기록합니다.
2. 원래 플랫폼에서 빌드하고 플레이합니다. 원래 아키텍처와 컴파일러로 각 부분을 실제 프로그램으로 링크합니다. 주요 게임 진행 경로를 실행합니다. 개별 함수 비교에서 놓친 공유 상태나 초기화 문제를 이 단계에서 찾을 수 있습니다.
3. 두 기준을 대조하며 의미를 재구성합니다. 게임에서 연관된 부분을 하나씩 골라 복구한 소스의 의미를 밝힙니다. 완전 일치 검사와 플레이 가능한 원래 플랫폼 빌드를 유지하면서 코드 표현을 개선합니다.
4. 현대 환경으로 이식합니다. 확인된 동작을 네이티브 64비트 빌드 같은 새 환경으로 옮깁니다. 원래 플랫폼의 재구성판은 이식판의 동작을 비교하는 기준으로 남깁니다.

두 번째 단계에서 만든 플레이 가능한 빌드는 세 번째 단계의 두 번째 오라클이 됩니다. 첫 오라클은 수정한 소스가 원본의 관련 코드와 데이터를 여전히 재현하는지 확인합니다. 두 번째 오라클은 재구성판이 계속 빌드되고, 실행한 경로에서 올바르게 동작하는지 확인합니다.

두 검사는 서로 다른 실수를 잡아냅니다. 타입을 바꾸면 생성되는 명령어가 달라질 수 있습니다. 소유권을 바꾸면 게임의 두 부분이 서로 다른 상태 복사본을 사용하게 될 수 있습니다. 두 검사를 모두 유지하면 에이전트가 리팩터링을 더 진행하기 전에 조사할 구체적인 실패 사례를 얻을 수 있습니다.

이름에도 근거가 필요합니다. 완전 일치 검사만으로 어떤 필드가 실제로 “무적 시간”을 뜻하는지는 알 수 없습니다. 게임이 그 값을 쓰고 사용하는 방식으로 확인해야 합니다. 의미가 불확실하다면 자신 있게 추측한 이름보다 중립적인 이름이 다음 독자에게 유용합니다.

이 순서는 프로젝트를 거치며 배웠습니다. TH08은 원래 플랫폼에 대한 후속 점검보다 플레이 가능한 이식판이 먼저 나왔습니다. 그 탓에 일부 결함을 알아보기 어려웠습니다. Factory의 현재 작업 흐름은 원래 플랫폼의 빌드를 먼저 만들어, 이식 전에 의미 재구성의 기준으로 활용합니다.

정확한 재구성은 비교 기준을 제공합니다. 의미 재구성은 복구한 지식을 활용할 수 있게 합니다. 이식은 그 두 가지를 토대로 진행할 수 있습니다.

산업적 전환이라 부르는 이유

이 프로젝트들은 제가 집중하는 지점을 바꿨습니다. 에이전트가 조사의 많은 부분을 진행할 수 있게 되자, 작업 환경을 개선하는 일이 제가 할 수 있는 가장 유용한 일 중 하나가 됐습니다. 도구 하나를 개선하면 이후 그 도구가 필요한 모든 함수의 작업에 도움이 됩니다.

여기서 자율성이 중요합니다. 다음에 무엇을 해야 할지는 실험이 실패한 뒤에야 분명해지곤 합니다. 에이전트에게는 예상 밖의 방향으로 결과를 추적할 자유가 필요합니다. 매번 제 지시를 기다려야 한다면 많은 작업이 여전히 제 관심과 시간에 묶입니다.

에이전트가 틀린 가설을 세우리라는 건 예상합니다. 중요한 것은 그 가설을 검증하고 결과에서 배울 수 있느냐입니다. 검증 실패는 실수를 이해하고 다시 시도하는 데 도움이 되어야 합니다. 쌓인 증거가 프로젝트의 이정표를 뒷받침하는지는 여전히 제가 판단해야 합니다.

REA는 에이전트에게 분석 도구를 제공합니다. 어떤 함수를 누가 호출하는지 묻다가 곧바로 그 호출 함수를 살펴볼 수 있습니다. 재구성 프로젝트는 컴파일러와 자체 대조 검사를 제공합니다. 에이전트는 이를 이용해 제안한 소스를 테스트하고 설명이 어디까지 맞는지 확인합니다.

TH08 버그는 검증 도구 자체에도 공학적 노력이 필요한 이유를 보여줍니다. 수백 개의 함수에 같은 비교를 적용하면, 검사의 허점은 개별 구현 오류보다 훨씬 넓게 영향을 줍니다. 검사기를 테스트하면 이후의 모든 작업이 더 나은 피드백을 받습니다.

산업에 빗댄 설명에는 좋은 역사적 사례가 있습니다. 볼턴과 와트는 밸브 조정을 돕기 위해 1796년 증기기관 지압계를 도입했습니다. 기록형 지압계는 피스톤 행정에 따른 압력을 그려 냈습니다. 덕분에 엔진의 내부 동작을 살펴볼 수 있었습니다. 비교 도구도 비슷한 역할을 합니다. 도구를 개선하며 그 기계가 실제로 무엇을 하는지 확인하게 해줍니다.

우리는 이 산업적 전환의 초기 단계에 있습니다. 기반 시설의 상당 부분은 아직 미숙합니다. 에이전트는 기존 검사들이 지원하도록 설계된 속도보다 더 빠르게 작업할 수 있으므로, 작업 과정도 에이전트의 발전에 맞춰 개선되어야 합니다. 공유 도구에서 결함을 발견하면 도구를 고치고 그 결함의 영향을 받은 결과도 다시 검토해야 합니다. 그러면 다음 프로젝트는 더 강력한 도구를 물려받을 수 있습니다.

한 대화에는 현실적인 한계도 있습니다. 큰 재구성 작업이 끝나기 전에 대화가 끝납니다. 저장소는 마지막 결정의 이유를 잃지 않고 다음 세션에서 이어갈 수 있게 해야 합니다.

Touhou Reconstruction Factory는 이런 필요에서 출발했습니다. 검증과 교훈을 다음 작업으로 전달하는 공통 방식을 제공합니다. 한 게임에서 한 작업이 다른 게임의 출발점을 개선할 수 있습니다.

제게 산업 비유가 의미 있는 이유입니다. 경험이 다른 사람도 쓸 수 있는 도구에 담기기 시작합니다. 도구가 나아지면 다음 사람이나 다음 에이전트가 해낼 수 있는 일도 늘어납니다.

이제 시도할 수 있는 프로젝트

속도는 시작 여부를 바꾸기에 중요합니다. 분석하고 싶은 게임이라도 현실적으로 제가 들일 수 있는 것보다 더 많은 시간을 요구할 수 있었습니다. 많은 프로젝트는 구상으로만 남곤 했습니다.

이제는 반복적인 조사를 통해 그런 프로젝트를 꾸준히 진행할 방법이 보입니다. 작동하는 재구성판이 있으면 이식도 현실적인 목표가 됩니다. 의미를 읽기 쉽게 복구하면 다른 사람이 모드를 만들기도 쉬워집니다. 게임을 이해하는 데 들인 노력은 첫 버전이 실행된 후에도 계속 결실을 맺습니다.

이제 낯선 프로그램을 보면 이렇게 묻습니다. 에이전트가 이 작업을 믿고 맡길 만하게 수행하려면 어떤 접근 수단, 피드백, 축적된 지식이 필요할까?

이 질문 덕분에 예전에는 손대지 않았을 프로젝트도 생각하게 됩니다. 각 프로젝트는 다음 작업에 접근하는 방식을 개선할 수 있습니다. 이 방식으로 어디까지 갈 수 있을지 계속 탐구하고 싶습니다.

다른 글 보기 · TH04 분석 살펴보기