REA로 리버스 엔지니어링 실험 2가지를 해보았다

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

REA로 게임 바이너리 분석과 웹 동작 관찰이라는 두 가지 리버스 엔지니어링 실험을 진행하며, 기능 재현과 원본 구현 규명의 차이를 살펴본다.

📌 핵심 요점

1. 첫 번째 실험은 L브레이크아웃 2의 원본 소스 코드를 사용하지 않고 윈도우 EXE를 분석해, 맥에서 실행할 Rust 게임으로 재구현하는 것이다.
2. REA는 새로운 디컴파일러가 아니라 Hopper 같은 기존 분석 도구를 AI 에이전트에 연결하고 분석 과정을 체계화하는 도구로 설명된다. MCP는 도구 호출 통로, 스킬은 작업 지침을 맡는다.
3. 두 번째 실험은 Excalidraw를 브라우저에서 직접 조작해 도형 생성·선택·이동·크기 변경·실행 취소 규칙을 조사하고, 이를 기능 명세로 만들어 웹을 구현하는 것이다.
4. 프로그램이 실행되거나 원본과 비슷하게 반응한다는 사실만으로 내부 알고리즘을 복원했다고 판단할 수 없다. 관찰한 동작, 추론, 실제 코드에서 확인한 근거를 구분해야 한다.
5. 기존 프로그램 분석은 AI 개발에 필요한 요구사항과 설계 원리를 찾아내는 수단이 될 수 있다. 다만 도구의 추가 효과, 외부 모델로의 정보 전송, 라이선스와 공개 조건을 함께 확인해야 한다.

🧩 배경과 문제 정의

이전 REA 소개 영상에는 실제 역공학이 아니라 AI가 비슷한 화면을 만든 것 아니냐는 지적과, REA 없이도 AI가 프로그램을 만들 수 있다는 의견이 나왔다. 발표자는 이를 타당한 문제 제기로 받아들이고, 일반 지식으로 유사한 프로그램을 만드는 일과 원본을 분석해 동작 원리를 알아내는 일을 구분하려 한다.

이를 위해 두 가지 접근을 비교한다. L브레이크아웃 2는 원본 소스 코드를 사용하지 않고 윈도우 실행 파일을 분석해 Rust로 구현한다. Excalidraw는 브라우저에서 직접 조작하며 동작 규칙을 조사하고, 필요하면 웹 내부 단서를 분석해 기능 일부를 재구현한다. 핵심 평가 문제는 결과물이 작동하는지를 넘어, 원본에 관해 무엇을 실제로 확인했는지 설명할 수 있느냐는 것이다.

🕒 시간순 섹션별 상세정리

1. 두 가지 실험으로 역공학의 의미를 묻다

• 오래된 게임의 윈도우 EXE를 AI에게 제공하고, 원본 소스 없이 맥에서 실행되는 Rust 게임으로 다시 만드는 실험을 보여준다. [00:36]
• 이전 영상에 나온 화면 모방 의혹과 REA의 필요성에 대한 질문을 받아들여, 일반 지식에 따른 생성과 원본 분석을 구분한다. [01:31]
• 게임 실행 파일 분석과 Excalidraw 웹 기능 재구현을 서로 다른 접근으로 실험하겠다고 예고한다. [01:54]

2. 실행 파일에 남은 단서와 기존 분석 도구

• 컴파일 과정에서는 변수명·주석·함수명 같은 정보가 상당 부분 사라지지만, 실행에 필요한 기계어 명령은 남는다. 바이너리 역공학은 이를 분석해 내부 동작을 추론한다. [02:25]
• Ghidra는 함수·호출 관계·어셈블리와 의사 코드를 살펴보는 도구로, IDA는 코드 흐름 분석에 강점을 가진 도구로 묶인다. IDA의 라이선스 제약도 언급한다. [03:13]
• Hopper는 맥에서 사용하기 편리한 분석 도구로 소개하며, 이번 실습은 Hopper를 중심으로 진행한다. [03:30]

3. REA의 연결 역할과 관찰·추론의 구분

• REA는 기존 역공학 도구를 AI 에이전트에 연결한다. Claude Code가 MCP로 도구를 호출하고, 함수·호출 관계·의사 코드 분석 결과를 받아 작동 원리를 추론하는 흐름이다. [04:10]
• 충돌 함수를 실제로 발견한 경우와 일반적인 게임 개발 지식으로 알고리즘을 작성한 경우를 구분해야 역공학의 성과를 평가할 수 있다. [04:40]
• 프로그램을 실행하며 입력과 출력을 조사하는 블랙박스 접근도 보여준다. 관찰만으로 내부 구현을 모두 알 수 없으므로 필요하면 자바스크립트나 네트워크 같은 단서를 추가 조사한다. [05:24]

4. 분석 환경 설치와 실제 연결 확인

• Ghidra의 JDK 준비, IDA의 제품·연결 조건, Hopper의 라이선스와 데모 제한 등 도구별 설치 시 확인할 사항을 보여준다. [06:16]
• Node.js를 준비하고 REA 설치 과정에서 Claude Code를 선택한다. 스킬은 작업 지침이고 MCP는 분석 도구 호출 통로라는 차이를 보여준다. [06:50]
• 환경 진단 뒤 Claude Code를 다시 실행해 실제 바이너리를 열 수 있는지 확인해야 한다. 로컬에서 분석하더라도 결과가 외부 AI 모델로 전송될 수 있다고 덧붙인다. [07:25]

5. 실습 대상과 분석 범위를 정하다

• 설치가 어려우면 Claude Code에 REA 저장소를 전달해 설치를 요청하는 방법을 언급한다. 회사 프로그램이나 고객 정보가 있는 시스템을 허가 없이 분석해서는 안 된다고 보여준다. [07:47]
• 공개 프로그램과 별도 실습 환경을 사용하며, 오픈소스 벽돌깨기 게임 L브레이크아웃 2의 원본 소스 대신 배포된 윈도우 실행 파일을 분석 대상으로 삼는다. [08:09]
• 배포 파일에는 EXE와 여러 리소스가 함께 있으며, 이미지·사운드가 실행 파일 안에 모두 포함돼 있지는 않을 수 있다. [08:32]

6. 게임 기능을 함수와 명령어로 추적하다

• 바이너리 형식과 내부 구조, 함수와 연결 관계를 조사하며 공 이동·막대 조작·벽돌 충돌·점수 계산을 핵심 분석 대상으로 정한다. [09:03]
• AI가 붙인 함수 이름보다 실제로 실행하는 명령과 해당 기능이라고 판단한 근거를 확인해야 한다고 강조한다. [09:15]
• 위치 계산 함수를 찾았다면 좌표·속도 처리 방식을 조사할 수 있지만, 찾지 못했다면 미확인으로 표시해야 한다. 일반 알고리즘을 가져오는 것과 원본에서 발견하는 것은 다르다. [09:47]

7. Rust 게임 구현과 세 단계 검증

• 분석 결과를 바탕으로 라이브러리·화면·입력을 구현한다. 전체 게임의 완벽한 복원보다 기본 실행과 분석한 동작의 반영 여부를 먼저 확인한다. [10:12]
• 공 이동·막대 조작·충돌 반응을 점검하고, 원본의 이동 속도·충돌 방향·점수 계산과 비교하는 검증 절차를 보여준다. [10:36]
• 실행 성공만으로 역공학 성공을 주장할 수는 없다. 알고리즘 복원을 주장하려면 바이너리의 어떤 함수에서 어떤 정보를 찾았는지 설명해야 한다. [10:56]

8. Excalidraw의 동작 규칙을 분석 대상으로 삼다

• 두 번째 대상은 손으로 그린 듯한 다이어그램을 만드는 오픈소스 웹 Excalidraw다. 도형 생성과 선택·이동·크기 변경 기능을 보여준다. [11:25]
• 드래그로 도형을 만들고 크기를 바꾸며 실행 취소와 복구를 지원하려면, 화면 외형뿐 아니라 상태 관리와 동작 규칙을 이해해야 한다. [11:57]
• 공개된 원본 소스를 직접 읽는 대신 프로그램을 실행하고 사용자의 입장에서 조작하며 규칙을 추론하는 블랙박스 접근을 택한다. [12:18]

9. 브라우저 조작으로 기능 명세를 만들다

• 어사이드 CLI를 AI 에이전트가 브라우저를 제어하고 클릭·마우스 이동·화면 캡처를 수행할 수 있도록 돕는 도구로 보여준다. [12:36]
• 사각형 생성·선택·이동·크기 변경·실행 취소를 반복하며, 마우스를 누른 좌표와 이동량, 손을 뗀 뒤의 결과를 관찰한다. [13:21]
• 관찰을 기능 명세로 정리할 수 있지만, 이 단계만으로 원본이 사용한 코드나 자료 구조까지 밝혀낸 것은 아니라고 구분한다. [13:42]

10. 웹 내부 단서를 추가로 조사하다

• 브라우저가 내려받는 HTML·CSS·자바스크립트와 페이지 구조·네트워크 요청·저장 데이터를 내부 동작의 단서로 제시한다. 화면의 도형이 개별 HTML 요소인지도 직접 조사해야 한다. [14:25]
• 캔버스 사용 여부보다 좌표 처리, 선택 상태 관리, 크기 변경 시 데이터 변화, 실행 취소의 상태 복구 방식이 구체적인 분석 문제다. 일부는 조작으로, 일부는 스크립트 분석으로 확인해야 한다. [15:07]
• 브라우저 조작 도구와 REA의 웹 분석 기능은 별개다. 수집한 근거를 전달하고, 내부 구현을 발견한 경우와 관찰한 동작만 재현한 경우를 구분해 기록한다. [16:00]

11. 기능 명세로 구현하고 동일 조작으로 비교하다

• React나 Canvas API 같은 웹 기술을 활용해 조사한 기능 명세를 기준으로 구현한다. 가능하면 자바스크립트 분석에서 찾은 정보도 반영한다. [16:53]
• 원본과 새 웹에 도형 생성·이동·크기 변경 등 같은 조작을 적용하고, 선택 표시·최종 위치·실행 취소 결과가 같은지 비교한다. 차이가 발견되면 다시 분석한다. [17:41]
• 결과물은 Excalidraw의 모든 기능을 복제한 것이 아니라 일부 기능을 분석해 재구현한 것이라고 범위를 한정한다. [18:06]

12. 두 접근을 관통하는 증거의 기준

• 게임에서는 기계어와 함수 호출 관계를 조사했고, 웹에서는 직접 조작한 동작과 필요에 따른 브라우저 내부 정보를 분석했다고 정리한다. [18:36]
• 두 접근 모두 완성된 프로그램에서 출발해 작동 원리를 거꾸로 이해하려는 시도다. 다만 같은 입출력은 서로 다른 알고리즘으로도 만들 수 있다. [18:58]
• 관찰한 사실·내부 구현에 대한 추론·실제 코드의 근거를 구분해야 한다. 발표자는 REA의 의미를 AI와 함께 기존 프로그램을 분석하고 이해하는 과정에서 찾는다. [19:23]

13. 기존 프로그램에서 요구사항과 설계 원리를 찾다

• 발표자는 오랜 개발 경험과 비교하며, 이제 AI가 코드 작성과 테스트를 상당 부분 돕는다고 드러낸다. 이번 실험도 기존 프로그램의 분석과 새 구현을 연결한 사례로 보여준다. [19:56]
• 도형 하나를 그리는 기능에도 좌표 계산·선택 상태·화면 갱신·실행 취소 등 여러 설계 결정이 담겨 있으며, 역공학은 그 결정을 이해하려는 작업이다. [20:47]
• 원하는 기능을 명확히 정의하기 어려울 때 기존 프로그램을 참고 자료로 삼아 요구사항을 찾을 수 있다. 이를 업무에 맞는 개발과 연결하는 지점을 역공학과 바이브 코딩의 만남으로 보여준다. [21:41]

14. 도구의 추가 효과와 소프트웨어 산업의 변화

• REA 없이도 같은 결과를 얻을 수 있다는 의견을 평가 질문으로 받아들인다. 분석 도구의 근거가 더 정확한 구현에 도움이 되는지, 사용하지 않아도 같은 결과가 나오는지 살펴봐야 한다. [22:29]
• 기능이 명확한 작은 프로그램이나 큰 프로그램의 필요한 부분을 사용자가 직접 만드는 선택지가 늘어날 수 있다고 전망한다. [23:02]
• 복잡한 서비스의 서버·데이터베이스·보안·동시 사용 운영은 별도 문제다. 일부 동작을 이식해도 서버 내부 데이터나 비공개 소스 코드까지 확보하는 것은 아니다. [23:22]

15. 라이선스와 이해의 중요성으로 마무리하다

• 오픈소스에도 수정·재배포 조건이 있으며, 원리 학습과 코드·디자인·브랜드의 무단 이용은 구분해야 한다. 상용 소프트웨어 분석이나 결과 공개 시 법률과 계약을 확인해야 하고, AI가 새로 코딩했다고 문제가 자동 해소되지는 않는다. [24:04]
• 이번 작업을 완성된 소프트웨어의 원리를 이해하고 새 개발에 활용할 수 있는지 확인하는 실험으로 정리한다. 게임 바이너리의 Rust 구현과 Excalidraw 일부 기능의 웹 재구현을 되짚어 본다. [24:32]
• AI가 코딩을 맡아도 결과를 판단하려면 더 깊은 이해가 필요할 수 있다고 강조한다. 역공학이 개발 방식을 어떻게 바꿀지, 다음에는 어떤 프로그램을 분석할지 질문하며 끝맺는다. [24:58]

🧾 결론

• 두 실험의 공통점은 완성된 프로그램에서 출발해 작동 원리를 거꾸로 이해하고, 그 이해를 새로운 구현에 활용한다는 것이다.
• 바이너리 분석은 명령어와 함수 호출 관계를 조사하고, 블랙박스 분석은 입력과 출력으로 동작 규칙을 추론한다. 웹에서는 스크립트·네트워크·저장 데이터가 추가 단서가 된다.
• 역공학의 성과는 실행 여부, 원본과의 동작 유사성, 내부 구현에 대한 증거를 각각 확인해야 평가할 수 있다.
• 발표자는 AI가 코딩과 테스트를 돕는 환경에서도 결과를 판단하려면 프로그램에 대한 이해가 필요하다고 강조한다.

📈 투자·시사 포인트

• 기능이 명확한 작은 소프트웨어는 사용자가 필요한 부분을 분석해 직접 만드는 선택지가 늘어날 수 있다는 전망이 제시된다. 이는 소프트웨어의 기능 제공 방식과 구매 판단에 변화를 줄 수 있다.
• 복잡한 서비스의 서버·데이터베이스·보안·동시 사용 운영은 일부 화면 기능을 재현하는 일과 구분된다. 기능 복제 가능성만으로 서비스 전체의 대체 가능성을 판단하기는 어렵다.
• REA 같은 도구의 가치는 사용 여부 자체보다 분석 근거가 구현 정확도를 얼마나 높이는지에 달려 있다. 도구 없이도 같은 결과를 얻는지 비교하는 것이 평가 기준이 된다.
• 영상은 소프트웨어 산업의 변화 가능성을 논하지만, 특정 기업의 실적이나 투자수익을 추정할 수 있는 수치는 제시하지 않는다.

⚠️ 불확실하거나 확인이 필요한 부분

• 대본에는 구체적인 함수 주소, 의사 코드, 알고리즘 비교 결과가 제시되지 않는다. 어떤 게임 기능이 실제 바이너리 근거로 복원됐는지 독립적으로 확인하기 어렵다.
• 웹 재구현에 대해서도 기능별 통과 결과나 원본과의 차이 목록이 제시되지 않는다. 일부 기능을 재구현했다는 설명을 전체 기능의 동등성으로 확대하면 안 된다.
• REA를 사용한 경우와 사용하지 않은 경우의 비교 결과는 없다. 구현 정확도나 작업 시간에서 REA가 제공한 추가 효과는 확인이 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 분석 대상과 자료의 이용 권한을 확인하고, 공개 프로그램과 별도 실습 환경으로 실험 범위를 정한다.
• REA·MCP·분석 엔진을 연결한 뒤 진단 결과뿐 아니라 실제 바이너리 열기와 분석 도구 호출까지 확인한다.
• 분석 기록을 관찰한 사실, 내부 구현에 대한 추론, 코드에서 확인한 근거, 미확인 사항으로 나눈다.
• 게임의 이동·충돌·점수 계산과 웹의 도형 생성·선택·이동·크기 변경·실행 취소를 비교 항목으로 정한다.

❓ 열린 질문

• 게임의 어떤 함수와 명령어가 Rust 구현의 이동·충돌·점수 계산에 실제로 반영됐는가?
• Excalidraw 재구현에서 직접 확인한 내부 자료 구조와 관찰만으로 재현한 동작은 각각 무엇인가?
• 같은 과제에서 REA를 사용하면 일반적인 AI 코딩만 사용했을 때보다 정확도나 검증 가능성이 얼마나 높아지는가?