핵심 요약
- REA는 코딩 에이전트가 소스 코드 없이 실행 파일, JavaScript와 Electron 앱, .NET 어셈블리, 웹사이트를 조사하도록 분석 도구를 하나의 MCP 서버와 CLI로 묶은 프로젝트입니다.
- 네이티브 바이너리 분석은 Hopper, Ghidra, IDA 중 하나를 엔진으로 쓰고(Hopper는 설정 중에 설치 가능), JavaScript와 .NET 정적 분석은 별도 엔진 없이 동작합니다.
- 모든 결과는 Evidence ID가 붙은 기록으로 돌아오며, 관찰한 사실과 추론, 확인하지 못한 부분(unknown)을 구분합니다.
npx rea-agents setup한 줄로 Claude Code, Codex, Cursor 등 17개 클라이언트에 등록되고, 설정을 바꾸기 전에 변경 계획을 보여 주고 승인을 받습니다.- 분석은 로컬에서 실행되지만 결과는 에이전트의 모델 제공자에게 전달되며, 분석 권한과 법적 책임은 사용자에게 있습니다.
REA 소개
다른 앱의 기능이 어떻게 동작하는지 알고 싶은데 소스 코드가 없다면, 남는 방법은 리버스 엔지니어링(reverse engineering)입니다. 분석가는 디스어셈블러(disassembler)로 명령어를 읽고, 호출을 따라가고, 상수의 의미를 하나씩 찾아 규칙을 복원합니다. 최근에는 GhidraMCP나 IDA Pro MCP처럼 분석 도구 하나를 MCP(Model Context Protocol) 서버로 열어 AI 에이전트가 직접 호출하게 하는 프로젝트가 늘었습니다. 다만 대상이 네이티브 바이너리인지, Electron 앱인지, 웹 페이지인지에 따라 연결해야 할 도구가 달라집니다. 이번에 소개하는 REA는 이렇게 흩어진 분석 도구를 하나의 MCP 서버로 묶어, 코딩 에이전트가 대상의 종류와 관계없이 같은 방식으로 조사하게 하는 프로젝트입니다.
REA의 이름은 "Reverse Engineer Anything"의 약자입니다. 사용자는 에이전트에게 "메모 앱의 검색 기능이 어떻게 동작하는지 조사하고, 근거를 보여 준 뒤 내 프로젝트에 비슷한 기능을 만들어 달라"처럼 자연어로 요청합니다. 에이전트는 REA의 도구를 호출해 대상을 조사하고, REA는 의사 코드(pseudocode), 어셈블리, 문자열, 호출 관계, 모듈 그래프 같은 결과를 근거와 함께 돌려줍니다. 그 결과를 해석하고 구현과 테스트를 하는 일은 에이전트가 맡습니다.
아래는 REA가 Hopper 안에서 분석 브리지를 실행하며 macOS의 /usr/bin/true를 조사하는 화면입니다:
REA는 TypeScript로 작성되어 npm 패키지 rea-agents로 배포되며, Node.js 22.19 이상의 22.x, 24.11 이상의 24.x, 또는 26 이상이 필요합니다. 네이티브 분석 엔진은 직접 구현하지 않고 Hopper, Ghidra, IDA 같은 기존 도구를 어댑터로 연결합니다. Android APK에는 JADX, 펌웨어에는 Binwalk와 Unblob처럼 대상마다 외부 도구를 따로 씁니다. 저장소에는 한국어 README가 있고 공식 홈페이지의 한국어판도 함께 운영되고 있어, 한국어로 설정과 사례를 확인할 수 있습니다.
REA와 기존 리버스 엔지니어링 MCP 서버 비교
AI 에이전트를 리버스 엔지니어링에 붙이는 프로젝트는 대부분 도구 하나를 MCP로 여는 형태입니다. REA는 그 위에서 여러 도구를 묶는 계층에 가깝고, 실제로 IDA 연동은 mrexodia의 IDA Pro MCP를 재사용합니다. 주요 프로젝트의 범위를 비교하면 다음과 같습니다:
| 항목 | REA | GhidraMCP | IDA Pro MCP | x64dbg-MCP Server | Reverify |
|---|---|---|---|---|---|
| 형태 | MCP 서버 + CLI | Ghidra 플러그인 + MCP 서버 | IDA Pro용 MCP 서버 | x64dbg 플러그인 | CLI + MCP 서버 |
| 분석 대상 | 네이티브, JavaScript/Electron, .NET, APK, 펌웨어, 웹사이트 등 | Ghidra가 여는 바이너리 | IDA가 여는 바이너리 | 실행 중인 프로세스(디버깅) | PE/ELF/Mach-O 바이너리 |
| 분석 엔진 | Hopper, Ghidra, IDA 중 선택 | Ghidra | IDA Pro 8.3 이상(IDA Free 미지원) | x64dbg | 순수 파이썬 핵심부 |
| 결과의 근거 | Evidence ID가 붙은 기록, unknown 명시 | 엔진 출력 | 엔진 출력 | 디버거 출력 | 주장마다 VERIFIED/REFUTED/INCONCLUSIVE 판정 |
비교 대상들은 각자 맡은 엔진 안에서 깊이 들어가는 쪽이고, REA는 대상 종류가 바뀌어도 같은 에이전트 연결과 같은 결과 형식을 유지하는 쪽입니다. 그래서 Ghidra만 쓰는 분석가에게는 GhidraMCP가 더 단순한 선택일 수 있습니다. 참고로 IDA Pro MCP의 저자는 현재 README 첫머리에서 Hex-Rays가 공개한 공식 IDA MCP 서버를 대신 쓰라고 권하고 있습니다. 반면 REA의 IDA 연동 문서는 mrexodia의 서버만 다루며, 그 서버와 IDA는 사용자가 따로 설치해야 합니다.
REA를 사용하면 좋을 사용자
설치된 앱이나 게임의 특정 동작을 이해하고 다시 구현하려는 개발자에게 REA가 잘 맞습니다. CTF와 보안 연구에서 여러 종류의 대상을 하나의 에이전트로 다루려는 분석가에게도 마찬가지입니다. JavaScript와 Electron 앱, .NET 어셈블리는 네이티브 엔진 없이 바로 분석할 수 있어 진입 비용이 낮고, 결과마다 근거와 unknown이 함께 기록되어 있어 에이전트의 설명을 사람이 다시 확인할 수 있습니다.
반대로 분석 결과를 외부 모델 제공자에게 보낼 수 없는 환경이라면, 클라우드 모델 기반 에이전트에 REA를 연결하는 구성은 적절한 선택지가 아닙니다. 분석 자체는 로컬에서 실행되지만, 도구 결과는 에이전트를 거쳐 모델 제공자에게 전달되기 때문입니다. 이때는 에이전트 없이 CLI만 쓰는 방법이 남습니다. 프로젝트는 합법적인 연구와 분석에만 쓰도록 하고, 필요한 권한 확보와 법 준수를 사용자 책임으로 명시하고 있습니다. 또한 네이티브 분석의 깊이는 연결한 엔진에 달려 있으므로, Hopper, Ghidra, IDA 중 하나를 준비해야 하고 Hopper는 데모 모드에 제한이 있는 별도의 상용 소프트웨어입니다. Hopper 연동은 macOS 12 이상과 일부 Linux 배포판을 기준으로 하고 Windows의 Ghidra 연동은 읽기 전용의 실험 단계이므로, Windows 사용자는 지원 범위를 먼저 확인해야 합니다.
REA의 조사 흐름과 결과 형식
REA의 조사 흐름은 4단계로 구성되어 있습니다. 아래 그림은 그 흐름이며, 1단계 Ask, 2단계 Inspect & trace, 3단계 Read the evidence, 4단계 Use what you learn으로 이어지고, 4단계에서 생긴 Follow-up question이 다시 2단계로 돌아갑니다:
에이전트가 로컬 대상에 대해 질문하면 REA는 대상 종류에 맞는 분석 어댑터로 조사하고, 코드와 참조, 그리고 확인하지 못한 부분을 돌려줍니다. 에이전트는 그 결과로 동작을 설명하거나 구현을 작성해 테스트하고, 빈 곳이 남으면 다시 질문합니다. CLI 명령도 같은 워크플로를 쓰므로 에이전트 없이 터미널에서 같은 결과를 받을 수 있습니다.
결과 형식에는 REA의 설계 원칙이 드러납니다. 근거를 만드는 도구는 결과마다 Evidence 기록 전체와 evidence_id를 함께 돌려주고, 이 기록은 세션 묶음(bundle)에도 보관되어 나중에 다시 조회하거나 파일로 내보낼 수 있습니다. 프로젝트의 도구 설계 문서는 관찰한 관계, 유도한 관계, 추론한 관계를 구분하고, 다루지 못한 범위는 "없음"이 아니라 "unknown"으로 보고하도록 정해 두었습니다. 실제 앱의 결과는 수백 MB가 될 수 있어서, 334MB짜리 Obsidian 분석 결과에서 약 10KB의 요약 뷰만 뽑아 보는 방식도 제공합니다.
REA가 지원하는 분석 대상
REA는 대상 종류마다 돌려주는 결과와 필요한 도구가 다릅니다. 주요 대상은 다음과 같습니다:
| 대상 | REA가 돌려주는 결과 | 필요한 도구 |
|---|---|---|
| 네이티브 바이너리 | 의사 코드, 어셈블리, 문자열, 심볼, 호출과 참조 | Hopper, Ghidra, IDA 중 하나 |
| JavaScript/Electron | 모듈, import, 소스맵, 라우트, IPC, 네이티브 애드온 관계 | Node.js와 npm |
| 웹사이트 | 페이지 구조, 스크립트, 네트워크 관찰, 요청한 스크린샷 | Chrome 계열 브라우저 |
| .NET 어셈블리 | 메타데이터, CIL 명령어, 네이티브 의존성, 빌드 간 비교 | 없음(정적 분석만) |
| Android APK | 매니페스트, 클래스, 디컴파일한 메서드, 참조 | 헤드리스 JADX와 JDK |
| 펌웨어 | 영역, 추출 결과, 네이티브 분석으로 넘길 대상 | Linux의 Binwalk/Unblob |
| 프로세스 동작 | 터미널 출력, 상호작용, 종료와 파일 시스템 관찰, 실행 간 비교 | Linux/macOS의 네이티브 PTY |
이 밖에도 ELF 레이아웃, EVM 바이트코드, Linux 크래시 덤프, 저장된 HAR 네트워크 기록을 다룹니다. adb로 연결한 Android 기기, 사용자가 직접 실행한 JEB 클라이언트의 프로젝트, Apktool로 디코딩한 Android 리소스, Apple 앱 번들 같은 패키지도 조사할 수 있습니다. Ghidra를 엔진으로 쓰면 16비트 DOS 실행 파일도 분석할 수 있습니다. 정적 JavaScript와 .NET 분석은 대상 앱을 실행하지 않고 파일만 읽지만, 런타임 캡처는 사용자 권한으로 대상을 실제로 실행하거나 조작합니다.
REA의 분석 사례
REA 홈페이지는 질문 하나에서 시작해 근거까지 이어지는 사례를 공개하고 있습니다. Windows 계산기에서 200 + 10%가 왜 220이 되는지 묻는 예시에서는, REA가 설치된 계산기 DLL에서 % 처리 함수의 명령어를 돌려주고 에이전트가 그 분기를 해석합니다. 연산자가 곱셈이나 나눗셈이면 현재 값을 100으로 나누고, 그 외에는 앞의 숫자를 곱한 뒤 100으로 나누므로 + 뒤의 10%는 200의 10%인 20이 됩니다. 프로젝트는 이 분석을 REA 4.1.0으로 Windows 계산기 11.2508.4.0(x64)에 대해 수행했다고 밝히고 있습니다. 명령어의 0x5c와 0x5b가 곱셈과 나눗셈 연산자 ID라는 점은 Microsoft의 공개 소스와 교차 확인했습니다.
JavaScript 쪽에는 Notion 데스크톱 앱이 클립보드에 쓰는 경로를 추적한 사례가 있습니다. REA 4.1.0의 analyze_javascript_application은 Notion 7.6.1의 app.asar에 든 탭 preload 스크립트에서, 페이지에 노출된 __electronApi와 IPC 요청을 보내는 invoke 호출을 찾아 압축된(minified) 번들 안의 소스 위치와 함께 돌려줍니다. 에이전트는 그 위치에서 notion:clipboard:write 채널 이름을 찾고, 메인 프로세스에서 같은 채널을 받는 핸들러까지 따라갔습니다. 이 핸들러는 요청을 보낸 쪽이 Notion 화면인지 확인한 뒤 Electron의 클립보드 API를 호출합니다. 이 사례에서도 REA가 찾은 것은 읽기 시작할 위치 두 곳이고, 래퍼(wrapper) 함수를 읽어 경로를 잇는 일은 에이전트가 맡았습니다.
디컴파일러 출력만으로는 부족한 경우를 보여 주는 사례도 있습니다. 1996년 Windows 게임 DX-Ball의 사운드 패닝 계산을 복원한 사례에서, Ghidra의 디컴파일 결과는 함수를 인자가 없는 FUN_00406400(void)로 보고하며 스택 입력과 x87 부동소수점 수식을 빠뜨렸습니다. 에이전트는 REA로 명령어 뷰와 호출하는 쪽의 함수를 확인하고, 상수 주소의 바이트를 직접 읽어 1.5625와 500.0이라는 값을 찾은 뒤 C 함수로 복원했습니다. 이렇게 만든 C 함수는 원본 x86과의 비교 3,205건을 통과하고, VC4.0 컴파일러로 다시 컴파일했을 때 함수 63바이트가 원본과 일치했습니다. 이 검증은 REA가 아니라 복원 프로젝트의 테스트가 맡았고, 게임 전체 복원은 2026년 10월 7일 기준 55개 함수를 C로 옮긴 상태에서 계속 진행 중입니다.
같은 방식은 16비트 DOS 게임에도 쓰였습니다. PC-98용 동방 프로젝트 게임 TH04의 사례에서 REA는 원본 MAIN.EXE가 DOS MZ 형식으로 적재되었는지 먼저 확인하고, 탄막 고리의 각도를 정하는 함수의 명령어를 돌려줍니다. 에이전트는 그 명령어에서 탄환 번호에 256을 곱해 탄환 개수로 나누고, 플레이어 방향을 더하는 계산을 읽어 냈습니다. 이 함수를 포함한 탄막 생성 코드는 복원 프로젝트가 Turbo C++ 4.0J로 컴파일해 원본의 2,139바이트 구간과 일치함을 확인했습니다(2026년 10월 3일 기록).
DX-Ball과 TH04 복원 저장소를 만든 N0zoM1z0가 REA 블로그에 쓴 동방 프로젝트 게임 복원 기록(TH08, TH09.5, TH04 순서)은 이런 작업의 다른 면도 보여 줍니다. 저자는 함수 비교 검사기가 참조한 부동소수점 상수의 실제 값은 확인하지 않아, 원본의 128.0 대신 0.0을 쓴 소스가 "정확히 일치"로 통과한 일을 소개했습니다. 이후 1,548개의 부동소수점 상수 참조를 다시 감사해 5개 함수에서 12개의 잘못된 참조를 더 찾았다고 합니다. 같은 글은 기존 수작업 복원 프로젝트인 GensokyoClub이 AI로 주로 만든 기여를 받지 않는다는 점도 다룹니다. 에이전트로 만든 결과를 기존 커뮤니티에 기여하려면 해당 프로젝트의 정책을 먼저 확인해야 합니다.
REA 설치와 사용
Node.js와 npm이 설치되어 있으면 다음 명령으로 설정을 시작합니다:
npx rea-agents setup
설정 도구는 감지한 에이전트 목록을 보여 주고, 사용자가 고른 클라이언트에만 REA의 MCP 서버와 조사 워크플로 스킬을 등록합니다. 지원하는 클라이언트는 Claude Code, Claude Desktop, Codex, Cursor, Gemini CLI, Windsurf, VS Code, GitHub Copilot CLI, Qwen Code 등 17개입니다. 파일을 쓰기 전에 바꿀 경로와 내용을 계획으로 보여 주고 승인을 받으며, 기존 설정은 백업한 뒤 원자적으로 교체합니다. Hopper 설치는 별도의 승인을 다시 받고, 등록한 MCP 서버는 설정을 실행한 REA 버전에 고정됩니다. 설정이 끝나면 에이전트를 다시 시작하고, 다음과 같이 질문합니다:
Understand how search works in the Notes app, show me the evidence, and build a
similar feature for my project.
에이전트 없이 터미널에서 쓸 수도 있습니다. 압축을 푼 JavaScript/Electron 앱 디렉토리나 ASAR 파일은 별도 엔진 없이 다음과 같이 분석합니다:
npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json
네이티브 바이너리는 먼저 엔진을 설정한 뒤 --provider로 고릅니다. 아래는 CLI 문서에 실린 Ghidra 예시입니다:
rea analyze /absolute/path/to/program --provider ghidra --json
rea decompile /absolute/path/to/program 0x1000 --provider ghidra --json
rea xrefs /absolute/path/to/program 0x1000 --provider ghidra --json
REA는 도구 호출마다 별도의 권한 부여나 승인 플래그를 요구하지 않습니다. 승인을 받는 것은 설정 변경과 Hopper 설치뿐이고, 개별 호출의 승인 여부는 MCP 클라이언트의 설정을 따릅니다. 런타임 캡처처럼 대상을 실행하는 도구를 쓸 때는 클라이언트의 승인 정책을 먼저 확인해 두는 것이 좋습니다. 프로젝트는 릴리스가 잦으므로 rea update 또는 npx rea-agents@latest setup으로 최신 버전을 유지하라고 안내합니다. 엔진별 설정은 설치 문서에 정리되어 있습니다. 또한 프로젝트는 REA라는 이름을 쓰는 암호화폐 토큰을 발행하거나 보증한 적이 없다고 밝히고 있으니, 패키지는 npm의 rea-agents로만 설치하는 것이 안전합니다.
REA의 라이선스
REA는 MIT 라이선스로 공개되어 있어 개인 및 상업적 목적으로 자유롭게 사용할 수 있습니다.
단, 연결하는 Hopper와 IDA는 각자의 라이선스를 가진 상용 소프트웨어이므로, 네이티브 분석에 쓰기 전에 해당 엔진의 사용 조건을 따로 확인해야 합니다.
REA 공식 홈페이지
REA 프로젝트 GitHub 저장소
더 읽어보기
-
Reverify: 바이너리를 읽는 AI의 주장을 결정론적 도구가 실제 내용(byte)으로 판정하는 리버스 엔지니어링 도구
-
x64dbg-MCP Server: 런타임 설치 없이 x64dbg를 AI 어시스턴트에 연결하는 Zig 기반 플러그인
이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다. 
파이토치 한국 사용자 모임
이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일
로 보내드립니다! 텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로도 새 글 알림을 받으실 수 있습니다. 
아래
쪽에 좋아요
를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~ 