REA(Reverse Engineer Anything) 리버스 엔지니어링 직접 검증: REA 없이도 될까

GitHub 일간 트렌딩 1위에 오른 REA(Reverse Engineer Anything)는 Claude Code나 Codex 같은 코딩 에이전트가 소스 코드가 없는 앱의 내부 동작까지 조사하게 해주는 오픈소스입니다. 2026년 10월 12일 기준 GitHub 스타가 13만 개를 넘었는데요. 조금 과장하면 이제 거의 모든 앱이 오픈소스가 된 셈 아닌가 싶을 정도죠. 결론부터 말하면, 소스 없는 앱을 에이전트가 분석하는 건 실제로 됩니다. 그런데 제가 직접 만든 앱으로 비교해 보니 REA를 붙이지 않은 에이전트도 같은 결과를 냈습니다.

이 글에서는 REA가 어떤 도구인지, 공개된 사례가 실제로 무엇을 보여주는지부터 정리하고, REA를 붙인 에이전트와 붙이지 않은 에이전트에게 같은 과제를 준 실험 결과를 공개하겠습니다. 마지막으로 리버스 엔지니어링의 저작권 문제와, 기능 복제가 쉬워질 때 소프트웨어의 경쟁력이 어디로 옮겨갈지도 이야기해 보겠습니다.

REA 리버스 엔지니어링 실험 핵심 요약

• REA는 morluto가 공개한 MIT 라이선스 오픈소스입니다. 새로운 분석 엔진이 아니라, Hopper·Ghidra·IDA 같은 기존 리버스 엔지니어링 도구를 MCP·CLI·스킬로 코딩 에이전트에 연결해 줍니다.
• 직접 만든 macOS 노트 앱 NoteVault의 소스를 주지 않고, 앱 전용 .nvlt 파일을 읽는 파이썬 함수를 10분 안에 만들게 했습니다. 양쪽 모두 Codex의 GPT-6.1 Sol(추론 max)을 썼고, REA 쪽은 REA CLI로 분석 도구를 불렀습니다.
• 결과는 동점이었습니다. 미리 숨겨 둔 파일 16개(정상 8개, 손상 8개)를 양쪽 모두 맞혔고, 100점 만점 채점에서도 둘 다 100점이었습니다.
• REA를 붙이지 않은 에이전트도 Ghidra를 직접 실행해서 풀었습니다. 적어도 이번에 쓴 모델은 이런 분석 도구를 직접 다룰 줄 알았습니다.
• REA의 강점은 준비된 도구 호출(MCP, CLI), 함께 설치되는 조사 가이드(스킬), 근거와 한계를 정해진 형식으로 돌려주는 결과에 있습니다. 이번 실험으로 속도나 정확도 우위는 확인하지 못했습니다.
• REA의 MIT 라이선스는 도구 자체에 대한 것이고, 분석 대상 앱의 권리와는 별개입니다.

REA(Reverse Engineer Anything)는 어떤 도구인가

웹페이지를 AI로 따라 만드는 건 이미 익숙한 일이죠. URL을 넣으면 React 앱으로 재현해 주는 Open Lovable이나, 스크린샷을 HTML·React 코드로 바꿔 주는 screenshot-to-code 같은 도구가 있습니다. 웹페이지는 HTML과 자바스크립트가 브라우저로 그대로 내려오니까, 코딩 에이전트도 스크린샷과 코드를 보면서 대략적인 구조를 빠르게 파악할 수 있습니다.

컴파일되거나 패키징된 앱은 사정이 다릅니다. 네이티브 실행 파일, Electron으로 빌드된 데스크톱 앱, 안드로이드 APK, 펌웨어에는 원래 개발자가 쓰던 소스 프로젝트가 그대로 들어 있지 않습니다. 기계어나 바이트코드, 압축된 번들을 의사코드와 구조로 되돌리고, 함수와 호출 관계를 하나씩 따라가는 리버스 엔지니어링이 필요한데, 이건 지금까지 전문가의 영역이었습니다.

REA는 이 작업에 필요한 도구를 코딩 에이전트에 연결해 줍니다. 구조를 한 줄로 정리하면 이렇습니다.

에이전트가 질문하면 REA가 대상에 맞는 분석 도구를 실행하고, 결과를 코드 위치·근거·아직 모르는 부분과 함께 돌려줍니다. 에이전트는 그 결과로 동작을 설명하거나 비슷한 기능을 구현합니다.

README 기준으로 REA가 다루는 대상은 꽤 넓습니다.

대상	REA가 돌려주는 것	필요한 도구
네이티브 실행 파일	의사코드, 어셈블리, 문자열, 심볼, 호출 관계	Hopper, Ghidra, IDA 중 하나
자바스크립트·Electron 앱	모듈, import, 소스맵, 라우트, IPC	Node.js와 npm
웹사이트	페이지 구조, 스크립트, 네트워크 관찰	Chrome 계열 브라우저
안드로이드 APK	매니페스트, 클래스, 디컴파일한 메서드	JADX와 JDK
.NET 어셈블리	메타데이터, CIL 명령, 네이티브 의존성	없음(정적 분석)
펌웨어	영역 정보, 추출 결과	Linux의 Binwalk 또는 Unblob

여기서 짚을 점이 있습니다. REA 자체가 새 디컴파일러는 아닙니다. 네이티브 실행 파일은 Ghidra 같은 기존 엔진이 실제 디컴파일을 하고, REA는 그 도구들을 에이전트가 일정한 방식으로 부르고 결과를 받게 연결합니다. 자바스크립트나 .NET 정적 분석처럼 별도 엔진 없이 REA가 직접 읽는 대상도 있습니다.

저장소는 2026년 4월 14일에 만들어졌고 최근 관심이 크게 몰렸습니다. 2026년 10월 12일 20시 42분(한국 시간) 기준 GitHub 스타는 131,156개입니다.

공개된 REA 사례: DX-Ball, Notion, X 반응

REA 공식 사이트의 사례와 X에 올라온 반응을 보면 REA가 어디까지 하는지 감이 옵니다. 다만 앱 전체를 복구한 이야기인지, 기능 하나를 알아낸 이야기인지는 구분해서 봐야 합니다.

DX-Ball: 실행 파일에서 소리 위치 계산 함수 복원

DX-Ball은 1996년에 나온 Windows 벽돌깨기 게임입니다. 공이 왼쪽 벽돌을 맞히면 왼쪽 스피커에서, 오른쪽 벽돌이면 오른쪽 스피커에서 소리가 나잖아요. 이 사례는 그 소리 위치(pan)를 계산하는 함수를 실행 파일에서 찾아 C 함수로 다시 구현한 기록입니다.

에이전트는 REA로 실행 파일의 명령을 읽고, 이 함수를 어디서 호출하는지 따라가고, 계산에 들어가는 상수 값까지 실행 파일에서 직접 꺼내 확인했습니다. 흥미로운 건 검증 방식입니다.

• 원본 x86 함수와 복원한 C 함수에 같은 입력을 넣어 비교한 결과, 3,205개 경우 모두 반환값이 일치했습니다. 화면 위치 0부터 640까지 모든 정수를 다섯 가지 배율로 넣은 것입니다.
• 고정한 VC4.0 컴파일러로 다시 컴파일한 결과가 원본 함수의 63바이트와 일치했습니다.

여기까지는 게임 전체가 아니라 함수 하나에 대한 결과입니다. 프로젝트 전체로는 2026년 10월 7일 기준 C 함수 55개를 복원했고, 원본과의 비교는 45,380회, 컴파일한 바이트까지 일치한 함수는 33개라고 공개돼 있습니다. 게임 전체를 플레이할 수 있게 만드는 작업은 아직 진행 중입니다.

Notion: 복사한 내용이 클립보드까지 가는 경로

Notion에서 내용을 복사해 붙여넣으면 글자뿐 아니라 블록 구조까지 유지되죠. 이 사례는 Notion 데스크톱 앱(7.6.1)의 패키지 안 자바스크립트를 분석한 기록입니다. 복사 요청이 페이지 API에서 출발해 preload, Electron의 프로세스 간 통신(IPC), main 프로세스를 거쳐 시스템 클립보드까지 전달되는 경로를 따라갔습니다.

블록 구조가 유지되는 이유도 나옵니다. 복사한 HTML에 ID를 넣고 같은 ID의 블록 데이터를 앱에 따로 저장해 두었다가, 붙여넣을 때 ID가 맞으면 블록 구조를 되살리는 방식입니다.

Notion의 소스 코드가 공개된 게 아니니까, 이미 배포된 앱 패키지만으로 내부 연결을 확인한 셈입니다. 개발자 입장에서는 자주 쓰는 앱의 기능 뒤에 어떤 연결이 있는지 확인하고, 내 제품에서 비슷한 문제를 풀 때 참고할 수 있다는 점이 흥미롭습니다. 물론 실제로 남의 앱을 분석하려면 아래 법적 조건부터 확인해야 합니다. 이것도 Notion 서비스 전체를 복구한 사례는 아닙니다.

X에 올라온 반응

X에서는 더 과감한 주장이 나왔습니다. 한 사용자는 예전에 구매한 Steam 게임을 Claude Opus 5.5와 REA로 디컴파일해서 30분도 안 돼 Unity에서 실행했다고 올렸고, 다른 사용자는 TradingView를 리버스 엔지니어링해 유료 지표를 무료로 쓰고 있다고 주장했습니다. 둘 다 제가 확인한 결과는 아닙니다. 두 사례 모두 대상 소프트웨어의 약관이나 저작권 문제로 이어질 수 있는 사용이라, 법적인 경계는 아래에서 따로 정리했습니다.

REA 설치 방법

설치 전에 Node.js(22.19 이상의 22.x, 24.11 이상의 24.x, 또는 26 이상)와 npm이 필요합니다. 설치는 명령어 하나로 시작합니다.

npx rea-agents setup

실행하면 REA를 연결할 에이전트를 고르는 화면이 나옵니다. Claude Code, Codex, Cursor, Gemini CLI 같은 에이전트를 선택하고, setup이 제안하는 변경 사항을 확인해 승인한 뒤 에이전트를 다시 시작하면 됩니다. setup은 에이전트에 REA를 등록하면서 같은 버전의 조사 가이드(스킬)도 함께 설치합니다.

네이티브 실행 파일을 분석하려면 분석 엔진이 따로 필요합니다. Ghidra와 IDA는 이미 설치된 것을 연결하고, Hopper는 setup에서 승인하면 함께 설치할 수 있습니다. 저는 무료 오픈소스인 Ghidra를 설치해서 썼습니다. 자바스크립트·Electron 앱의 정적 분석은 엔진 없이도 됩니다.

직접 만든 앱으로 REA 유무를 비교한 방법

상용 앱을 대상으로 하면 법적인 문제가 생길 수 있어서, 실험용 macOS 앱을 직접 만들었습니다. NoteVault라는 노트 앱인데, 노트·태그·우선순위·보관 여부를 앱 전용 .nvlt 파일로 저장하고 불러옵니다. 원래는 NoteVault로만 열 수 있게 만든 파일입니다.

파일 형식은 일부러 까다롭게 만들었습니다. 문자열 사전, 가변 길이 정수, ID 차분 저장, RLE 압축, 바이트 변환, 전체 CRC32와 본문 FNV-1a 체크섬 검증이 들어갑니다. 파일 엔진은 C++17로, 화면은 Objective-C++와 macOS AppKit으로 짰습니다. Apple Silicon용으로 디버그 정보 없이(-g0) 최적화(-O2) 컴파일한 뒤, strip으로 내부 함수 이름 같은 로컬 심볼을 지웠습니다. 화면에 쓰이는 문자열과 Objective-C 메타데이터는 남아 있는 상태입니다.

그리고 앱을 만든 과정을 모르는 새 Codex 에이전트 세션 두 개를 띄웠습니다.

조건	REA 사용	REA 미사용
에이전트	Codex	Codex
모델	GPT-6.1 Sol(추론 max)	GPT-6.1 Sol(추론 max)
받은 자료	같은 앱, 입력 안내, 예시 파일 3개와 정답 JSON	같은 앱, 입력 안내, 예시 파일 3개와 정답 JSON
분석 도구	REA 6.4.0 CLI + Ghidra 12.1.4	Ghidra와 일반 도구를 직접 사용
제한 시간	10분	10분
소스 코드	주지 않음	주지 않음

REA는 보통 MCP로 연결해 쓰지만, 이번 비교에서는 같은 기능을 명령줄로 부르는 REA CLI를 썼습니다.

두 세션에 준 과제는 같았고, REA 사용 여부만 달랐습니다. 과제 요청을 요약하면 이렇습니다.

이 앱의 소스 없이 .nvlt 파일을 읽는 독립 Python 함수를 만들어줘.
함수 이름은 decode_archive(data: bytes) -> dict야.
노트·태그·우선순위·보관 여부와 손상 파일의 오류를 복원해줘.
조사에는 앱 실행과 허용된 분석 도구를 쓸 수 있지만,
완성 함수는 원본 앱 호출 없이 파일 바이트만 처리해야 해.
실제 함수 주소와 분석 근거, 아직 확인하지 못한 부분도 남겨줘.

채점용 파일 16개(정상 8개, 손상 8개)는 분석을 시작하기 전에 정해 두고 에이전트에게 보여주지 않았습니다. 빈 배열, 한글과 다국어, 큰 ID, 긴 문자열, 태그 32개 같은 경계 입력과, 헤더·버전·길이·체크섬이 잘못되거나 잘린 손상 파일이 섞여 있습니다.

점수는 출력 정확도 64점, 파일 형식 이해 24점, 분석 근거 12점으로 나눴습니다. 출력은 같은 실행기로 대조했고, 형식 이해와 분석 근거는 원본 소스와 고정된 자료를 맞춰 보며 판정했습니다. 코드와 분석 자료는 각 세션이 시작한 지 10분이 되는 시점에 외부 감시 프로그램이 그대로 고정했습니다.

결과: REA를 붙인 쪽과 안 붙인 쪽 모두 16개를 맞혔다

먼저 숨겨 둔 파일 중 하나(H02)를 열어 보니 원본 앱과 두 에이전트가 만든 함수 모두 같은 노트로 읽어냈습니다. 그다음 16개 파일 전체를 넣었는데, 여기서도 결과가 같았습니다.

항목	REA 미사용	REA 사용
정상 파일	8/8	8/8
손상 파일 오류 판정	8/8	8/8
출력 정확도	64/64	64/64
파일 형식 이해	24/24	24/24
분석 근거	12/12	12/12
10분 시점 점수	100/100	100/100

표는 2026년 10월 12일 실험 결과입니다.

솔직히 저는 REA를 붙이지 않은 쪽은 실패하지 않을까 생각했습니다. 그런데 결과는 동점이었고, 두 에이전트가 찾아낸 핵심 함수의 주소(파일 해석, 압축 복원, CRC32 검증, 본문 체크섬 등)까지 같았습니다.

다만 이 결과로 속도를 비교할 수는 없습니다. 두 세션 모두 10분 안에 스스로 완료를 선언하지 않아서, 같은 10분 시점의 결과만 채점했기 때문입니다. 또 각 조건을 한 번씩만 돌린 작은 자체 앱 하나의 결과이고, 16개를 맞혔다고 모든 정상·손상 파일을 완벽히 처리한다는 뜻도 아닙니다.

REA 없이도 리버스 엔지니어링이 된 이유

REA를 붙이지 않은 에이전트가 어떻게 풀었는지 살펴보니, 이 에이전트도 Ghidra를 직접 썼습니다. otool과 문자열로 실행 파일을 훑은 다음 Ghidra를 헤드리스 모드로 실행하고, 분석 결과를 파일로 뽑는 스크립트를 스스로 작성해서 핵심 함수의 의사코드를 꺼냈습니다. 그리고 원본 앱을 실행해 보면서, 직접 만든 오류 파일로 해석이 맞는지 대조했습니다.

REA를 붙인 에이전트는 REA CLI로 분석과 핵심 함수 5개의 디컴파일을 호출했고, 결과마다 분석 도구, 근거 ID, 신뢰도, 한계가 정해진 형식(JSON)으로 돌아왔습니다. 하지만 그 밑에서 실제로 의사코드를 만든 엔진은 똑같이 Ghidra였습니다. 같은 엔진을 썼으니 비슷한 결과가 나오는 게 자연스럽죠.

이 결과에서 눈여겨볼 점은, 적어도 이번에 쓴 고성능 코딩 에이전트는 Ghidra 같은 리버스 엔지니어링 엔진을 직접 다룰 줄 안다는 겁니다. 리버스 엔지니어링의 문턱을 낮춘 건 REA 하나라기보다 모델과 에이전트 자체의 발전에 가깝다고 봅니다.

REA가 실제로 돕는 부분

그럼 REA는 쓸모가 없을까요? 그렇지는 않습니다. REA가 주는 건 크게 세 가지입니다.

역할	REA가 주는 것
도구 호출	에이전트가 분석 기능을 MCP나 CLI로 바로 부릅니다. 분석 스크립트를 매번 직접 짤 필요가 없습니다
조사 가이드	함께 설치되는 스킬과 워크플로가 분석 대상을 분류하고, 특정 함수를 좁혀 조사하는 순서를 안내합니다
결과 형식	코드 위치, 근거, 신뢰도, 아직 모르는 부분을 정해진 형식으로 돌려줍니다

이번 실험(CLI 경로)에서는 이 장점이 점수 차이로 나타나지 않았고, 스킬의 효과는 따로 재지 않았습니다. 양쪽 모두 GPT-6.1 Sol이라는 고성능 모델을 썼고, 같은 Ghidra 엔진에 과제도 작았다는 점이 영향을 줬을 수 있습니다. 분석 도구를 스스로 다루는 능력이 약한 모델이었다면 REA를 붙이지 않은 쪽의 결과가 달라졌을 수도 있다고 생각합니다. 다만 이건 아직 확인하지 않은 가설입니다.

REA로 상용 앱을 분석해도 될까: 저작권법 확인

이런 도구를 쓸 수 있다는 것과, 다른 회사 앱을 마음대로 분석하고 따라 만들어도 된다는 건 별개의 문제입니다.

먼저 REA의 MIT 라이선스는 REA 도구 자체에 대한 것입니다. REA를 자유롭게 쓰고 고칠 수 있다는 뜻이지, 분석 대상 앱의 권리까지 풀어주는 게 아닙니다. REA README도 합법적인 연구·교육·호환·보존과, 본인 소유이거나 분석 권한을 받은 소프트웨어 분석에 쓰라고 안내합니다.

국내 저작권법은 컴퓨터 프로그램을 저작권자 허락 없이 이용할 수 있는 경우를 목적과 조건을 붙여 정해 두고 있습니다. 그중 이번 주제와 가까운 조항을 법제처 찾기쉬운 생활법령정보(2026년 9월 15일 기준 작성, 10월 12일 확인)로 정리하면 이렇습니다.

조항	내용
제101조의3 제1항	공표된 프로그램을 목적에 필요한 범위에서 이용할 수 있습니다. 재판·수사, 분쟁조정 감정, 교과용 도서 게재, 가정 같은 한정된 장소의 비영리 개인 목적은 복제만, 교육기관의 수업 제공과 비영리 시험·검정은 배포까지 됩니다. 정당한 이용자가 아이디어와 원리를 확인하려고 기능을 조사·연구·시험하는 경우도 복제만 됩니다. 저작재산권자의 이익을 부당하게 해치면 안 됩니다
제101조의4 제1항	정당한 이용자가 호환에 필요한 정보를 쉽게 얻을 수 없고 그 획득이 불가피하면, 호환에 필요한 부분에 한정해 프로그램코드를 역분석할 수 있습니다
제101조의4 제2항	역분석으로 얻은 정보를 호환 목적 밖에 쓰거나 제3자에게 제공하면 안 되고, 표현이 실질적으로 비슷한 프로그램을 개발·제작·판매하거나 그 밖에 저작권을 침해하는 데 써도 안 됩니다

정리하면, 호환이 아닌 목적으로 다른 회사 앱을 역분석하거나, 얻은 정보로 표현이 비슷한 프로그램을 만들어 파는 일은 이 예외에 들기 어렵습니다. 이용 약관에서 리버스 엔지니어링을 금지하는 앱도 많고요. 그래서 이번 실험은 제가 직접 만든 앱으로만 했습니다. 법제처 안내 페이지에도 2026년 10월 29일 시행되는 개정 사항을 반영할 예정이라고 적혀 있으니, 실제로 분석하기 전에는 최신 조문과 약관을 꼭 확인하세요. 이 내용은 일반적인 정보이고 법률 자문이 아닙니다.

기능 복제가 쉬워지면 소프트웨어 경쟁력은 어디로 갈까

이번 실험에서 복원한 건 파일 읽기 규칙 하나입니다. 원래 소스 프로젝트가 그대로 돌아오는 것도 아니고, 클라이언트에 없는 서버 코드나 데이터까지 얻는 것도 아닙니다. 그래도 이런 조사 도구를 일반 코딩 에이전트가 쓰게 됐다는 변화는 꽤 크다고 봅니다.

화면을 비슷하게 따라 만드는 건 이미 쉬워졌고, 이제 화면 뒤에 숨은 기능의 규칙까지 조사하기 쉬워지고 있습니다. 그러면 UI 하나, 기능 하나를 잘 만드는 것만으로는 소프트웨어의 강점을 지키기 어려워진다고 봅니다.

이건 AI 래퍼 제품을 만들 때 특히 생각해 볼 부분입니다. 프론티어 모델 위에 화면을 붙여 특정 작업을 더 편하게 해 주는 서비스가 많은데, 모델이나 에이전트가 업데이트되면 그런 서비스가 하루아침에 의미를 잃는 일도 자주 일어나죠. 같은 모델에 비슷한 화면을 붙였다면, 고객이 계속 우리 서비스를 골라야 할 이유를 따로 만들어야 합니다.

예를 들어 문서 요약 기능을 제공한다면, 요약 자체보다 특정 회사의 데이터와 승인 흐름에 직접 연결하고, 결과를 확인해 다음 업무까지 처리해 주는 흐름을 설계할 수 있어야 차별점이 생깁니다.

리버스 엔지니어링으로 어떤 앱의 파일 읽기 규칙을 알아낼 수는 있어도, 그 앱이 쌓아 온 사용자의 신뢰까지 가져올 수는 없습니다. 제가 더 중요하게 보는 건 제품의 본질과 백엔드입니다. 기능 구현이 쉬워질수록 우리 서비스만 가진 데이터와 도메인 이해, 결과물의 품질, 고객과의 신뢰가 더 큰 차이를 만들 거라고 봅니다.

마무리: REA에 쏟아지는 관심은 조금 과장된 면이 있다

저는 지금 REA에 쏟아지는 관심이 조금 과장된 면이 있다고 생각합니다. REA는 새로운 리버스 엔지니어링 기술이라기보다, 기존 도구를 잘 조합해서 에이전트가 쓰기 좋게 만든 프로젝트에 가깝습니다. 직접 비교해 보니 이번에 쓴 에이전트는 REA 없이도 리버스 엔지니어링을 해냈고요.

물론 정해진 도구와 조사 가이드가 준비돼 있다는 건 분명한 장점입니다. 다만 모델과 에이전트가 이런 연동과 가이드를 스스로 더 잘하게 될수록 그 차별점도 줄어들 수 있습니다. 어떻게 보면 REA도 앞에서 이야기한 AI 래퍼처럼, 별도 도구로서 얼마나 가치를 유지할지 지켜봐야 할 프로젝트라고 봅니다. 모델이 좋아지면서 덜어내야 할 도구와 규칙이 생기는 흐름은 AI 코딩 하네스 리팩토링 글에서도 다뤘습니다.

GitHub 트렌딩 도구를 내 환경에서 직접 재본 다른 사례로는 Graft 토큰 42% 절감 실측이 있습니다. 화제가 된 숫자보다 내 환경에서 잰 숫자가 중요하다는 점에서 같은 결론이었죠. 코딩 에이전트 관련 글은 AI 코딩 에이전트 태그에 모아 두었습니다.

여러분도 다음 제품을 기획할 때는 기능 목록과 함께, 우리가 어떤 데이터와 경험을 쌓아 갈지도 생각해 보세요.