이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
소스 코드가 없는 실행 파일이나 상용 패키지의 내부 동작을 파악해야 할 때가 있습니다. 원래라면 Ghidra나 Hopper 같은 디컴파일러를 직접 열고 복잡한 어셈블리 명령과 함수 호출 관계를 일일이 분석해야 했어요. 최근에는 AI 코딩 에이전트에 분석을 맡기려는 시도가 늘고 있는데, 모델이 존재하지 않는 코드를 그럴듯하게 상상해서 답하는 환각이 가장 큰 걸림돌이었습니다. 이런 한계를 극복하고 에이전트에게 실제 리버스 엔지니어링 도구를 쥐여주기 위해 등장한 오픈소스 실행 계층이 바로 REA Reverse Engineer Anything입니다.
REA Reverse Engineer Anything란? 에이전트와 분석 도구를 잇는 실행 계층
REA Reverse Engineer Anything은 새로운 디컴파일러 엔진을 자체 개발한 도구가 아닙니다. Claude Code, Cursor, Codex 같은 AI 코딩 에이전트와 전문 리버스 엔지니어링 분석 도구들을 Model Context Protocol(MCP)로 매끄럽게 연결해 주는 실행 계층(Execution Layer)이에요. GitHub 개발자 morluto가 MIT 라이선스로 공개했고, npm에서는 rea-agents 패키지로 공식 배포되고 있습니다.
기존 리버스 엔지니어링 작업은 디컴파일을 위한 Ghidra, 어셈블리 분석을 위한 Hopper, 런타임 관찰을 위한 트레이서 등 여러 도구를 넘나들어야 했어요. 도구마다 고유한 CLI 명령어와 세션 관리 방식이 달라서 사람이 직접 다루기도 까다로웠습니다. REA는 이 복잡한 도구 호출 과정을 단일 로컬 MCP 서버 규격 뒤로 깔끔하게 숨겨줍니다. 에이전트는 도구별 세부 API를 몰라도 표준화된 요청을 보내고 구조화된 결과를 받아볼 수 있어요.
이전에 초보자를 위한 AI Agent 실무 구축 가이드에서 정리했듯이, AI 에이전트가 실제 업무에서 신뢰할 수 있는 결과물을 내려면 기억에만 의존하지 않고 명확한 도구 인터페이스를 호출해야 합니다. REA가 역공학 분야에서 바로 그 도구 인터페이스 역할을 해주는 셈이에요. 스크립팅을 선호하는 개발자를 위해 터미널 CLI 명령(rea)으로도 동일한 워크플로를 제공하므로 특정 에이전트에 종속되지도 않습니다.
분석 대상별 지원 도구와 분석 방식 차이
REA가 다룰 수 있는 대상은 생각보다 넓습니다. 다만 대상 형식에 따라 Node.js 환경만으로 즉시 정적 분석이 가능한 형식과, 별도의 외부 분석 엔진을 미리 준비해야 하는 형식으로 나뉘어요.
| 분석 대상 | 추출 내용 | 필요한 도구 | 분석 방식 |
|---|---|---|---|
| 네이티브 바이너리 (C/C++, Mach-O, ELF, PE) | 의사코드(Pseudocode), 어셈블리, 문자열, 심볼, 호출·참조 관계 | Hopper, Ghidra (12.1+), IDA Pro 중 하나 | 외부 디컴파일러 엔진 연계 |
| JavaScript / Electron 앱 (폴더, ASAR) | 모듈 구조, import 관계, 소스맵, 라우트, IPC 채널, 네이티브 바인딩 | Node.js 환경만 필요 | 정적 분석 (파일 비실행) |
| .NET 어셈블리 | 메타데이터, CIL 바이트코드, 선언된 네이티브 의존성 | 추가 도구 불필요 | 정적 분석 |
| Android APK | 매니페스트 권한 선언, 클래스 구조, 디컴파일된 메서드 및 참조 | 헤드리스 JADX 및 JDK 21+ | 정적 디컴파일 |
| 웹사이트 및 웹앱 | DOM 트리 구조, 스크립트 모듈, 네트워크 요청 흐름, 스크린샷 | Chrome 계열 브라우저 | 브라우저 기반 관찰 |
여기서 꼭 기억해야 할 점은 정적 분석과 동적 관찰의 차이입니다. JavaScript, .NET, Go 분석은 코드를 직접 구동하지 않고 파일 내용을 읽어 구조를 파악하므로 안전해요. 반면에 프로세스 런타임 추적이나 브라우저 연결 기능은 사용자의 로컬 권한으로 대상 프로그램을 실제로 실행합니다. 검증되지 않은 외부 바이너리를 다룰 때는 이 차이를 명확히 구분해야 해요.
공식 npm 패키지로 안전하게 시작하는 실행 방법
REA를 설치하고 에이전트에 연결하는 방법은 매우 간단합니다. Node.js 22.19 이상(22.x), 24.11 이상(24.x), 또는 26 이상 환경과 npm이 준비되어 있다면 터미널에서 다음 명령 한 줄로 시작할 수 있어요.
npx rea-agents@latest setup전역 CLI 도구로 자주 사용한다면 패키지를 직접 설치한 뒤 상태 점검을 진행해보세요.
npm install --global rea-agents
rea doctorsetup 명령어가 실행되면 연결할 코딩 에이전트(Claude Code, Cursor, Codex, Gemini CLI 등)를 선택하게 됩니다. 이때 REA는 바꿀 설정 파일 경로, 설치할 도구, 접속 주소를 터미널에 먼저 계획으로 보여줘요. 사용자가 꼼꼼히 확인하고 승인하기 전까지는 설정을 일절 바꾸지 않으며, 기존 설정 파일도 자동으로 백업해 둡니다. 실제 변경 없이 계획만 확인하고 싶다면 --dry-run 옵션을 붙여서 실행하면 됩니다.
설치 과정에서 반드시 주의해야 할 점이 있습니다. 공식 저장소와 공식 사이트에는 rea.exe나 별도 GUI 설치 파일 배포 안내가 전혀 없어요. 최근 GitHub 등에 출처가 불분명한 rea.exe 다운로드를 유도하는 비공식 저장소가 있으니, 출처를 알 수 없는 독립 실행 파일은 절대로 내려받지 마시고 공식 npm 패키지(rea-agents)를 통해서만 안전하게 설치해야 합니다.
디컴파일부터 추적까지: Evidence 구조와 작동 방식
에이전트에게 분석을 요청하면 디컴파일(Decompile), 이해(Understand), 재구성(Reconstruct)으로 이어지는 3단계 워크플로가 순서대로 동작합니다.
에이전트에게 “이 앱에서 특정 기능이 어떻게 동작하는지 설명해줘”라고 요청하면, REA는 대상 파일에서 해당 로직을 찾아내고 그 결과를 단순한 텍스트 답변이 아니라 Evidence(근거) 데이터 형태로 돌려줍니다. REA Reverse Engineer Anything의 핵심 가치는 모델의 분석 능력을 마법처럼 올리는 데 있는 것이 아니라, 모든 결론에 검증 가능한 근거를 붙여주는 데 있어요.
Evidence 데이터에는 다음과 같은 핵심 정보가 담깁니다.
- SHA-256 해시값: 분석한 바이너리와 파일의 무결성을 보장합니다.
- 소스 파일 경로와 줄(line) 위치: 에이전트가 인용한 코드가 실제로 어디에 있는지 사람이 직접 열어 확인할 수 있어요.
- 명확한 상태 분류:
- 관찰(observed): 코드에 명시적으로 선언되어 직접 확인된 사실 (예: 하드코딩된 IPC 채널 이름이나 브리지 API)
- 추론(inferred): 호출 경로와 설정 관계를 바탕으로 연결한 내용 (예: 진입점 설정을 통해 추론한 메인 스크립트)
- 미확인(unknown): 전역 객체의 동적 호출처럼 정적 분석만으로는 확정할 수 없는 부분
- 확실성(confidence)과 한계(limitations) 문장: 정적 분석이 보장하지 못하는 범위를 명확히 짚어줍니다.
실무에서 활용할 때 유용한 팁이 있습니다. 1KB 남짓한 작은 앱도 전체 Evidence를 뽑으면 수백 KB가 넘고, Obsidian 같은 실제 배포 앱은 수백 MB에 달해요. 이 원시 JSON 데이터를 에이전트 대화창에 통째로 넘기면 컨텍스트 토큰이 순식간에 차버립니다. 따라서 inspect-analysis-view 도구를 활용해 요약 뷰나 필요한 모듈 단위 페이지만 넘겨주는 방식으로 컨텍스트를 아껴야 대화를 원활하게 이어갈 수 있어요.
실무 도입 전 짚어둘 보안·비교 잡음·저작권 기준
REA를 업무나 연구에 도입하기 전에는 몇 가지 실무 기준을 점검해 두는 편이 좋습니다.
첫째, 데이터 처리 정책입니다. 분석 작업 자체는 로컬 컴퓨터에서 돌지만, 에이전트가 읽어 들인 디컴파일 코드 조각과 구조 요약문은 연결된 AI 모델 제공사(Anthropic, OpenAI, Google 등)의 API 서버로 전달됩니다. 사내 기밀 코드나 고객 정보가 포함된 프로그램이라면 모델 제공사의 데이터 처리 및 학습 정책을 사전에 꼼꼼히 확인해야 해요.
둘째, 버전 비교 시 발생하는 잡음 필터링입니다. compare-application-versions 명령으로 두 버전을 비교할 때, 상단에 코드 한 줄이 추가되면 아래쪽 줄 번호가 전부 밀리면서 수십 개의 무의미한 변경(줄 이동 잡음)이 감지될 수 있어요. 이때는 ipc-channel, ipc-handler, context-bridge-api처럼 의미 있는 노드 종류로 걸러서 봐야 실제 바뀐 기능이 보입니다. 또한 REA는 변경 사실을 알려줄 뿐 그 코드가 보안상 안전한지까지 스스로 판정하지 않으므로, 에이전트에게 “발신자 origin 검증 여부” 같은 구체적인 보안 판단 기준을 프롬프트로 함께 쥐여주는 편이 좋아요.
셋째, 국내 저작권법 준수입니다. 대한민국 저작권법 제101조의3(기능의 조사·연구·시험)은 정당한 권한을 가진 이용자가 프로그램의 기초 아이디어와 원리를 파악하기 위해 기능을 조사하는 행위를 허용하고 있어요. 또 제101조의4(프로그램코드역분석)는 다른 소프트웨어와의 호환성을 위해 필수적인 정보를 쉽게 구할 수 없을 때 필요한 범위에서 역분석을 인정합니다. 하지만 그렇게 얻은 정보를 호환 외 목적으로 쓰거나, 원래 프로그램과 표현이 실질적으로 유사한 복제 프로그램을 만드는 것은 법적으로 엄격히 금지돼요. DRM 우회나 비인가 인증 무력화 시도 역시 법적 보호를 받지 못하므로 방어적 연구와 정당한 호환 목적에 한해 활용해야 합니다.