에이전트용 역공학 도구 REA, 설치부터 앱 구조 분석까지
REA는 앱의 구조를 AI 에이전트가 읽어 주는 역공학 도구로, GitHub 별이 17만 4천 개입니다. 화면은 따로 없고 에이전트와 대화하며 씁니다. Electron 샘플 앱을 직접 분석한 과정과 주의점을 정리했습니다.
다른 사람이 만든 앱이 어떻게 돌아가는지 궁금한데, 소스 코드가 없으면 막막합니다. REA(Reverse Engineer Anything)는 이 일을 에게 맡기는 도구입니다. 앱을 열어 보고, 근거를 붙여 설명하고, 비슷한 기능을 만드는 데까지 이어 가는 것. 저장소가 내세운 목표입니다.
GitHub에서 별 17만 4천 개를 받았고, 저장소는 2026년 4월 14일에 만들어졌습니다. 이 글은 2026년 10월 13일에 직접 받아 설치하고 실행한 결과를 바탕으로 썼습니다.
먼저 알아둘 말
- reverse engineering(역공학) — 완성된 프로그램을 뜯어 보며 어떻게 만들어졌는지 알아내는 일.
- (Model Context Protocol) — 가 바깥 도구를 불러 쓰게 하는 연결 규약입니다. REA는 이 규약으로 에이전트에 붙습니다.
- Electron — 웹 기술로 데스크톱 앱을 만드는 틀. Notion, Obsidian 같은 앱이 이 틀로 만들어졌습니다.
- — Electron 앱의 소스 파일을 하나로 묶어 둔 보관 형식.
- (inter-process communication, 프로세스 간 통신) — 앱의 화면 쪽과 본체 쪽이 메시지를 주고받는 통로입니다. 통로마다 이름이 붙습니다.
- (정적 분석) — 프로그램을 실행하지 않고 코드만 읽어서 알아내는 방식.
분석할 수 있는 것
REA는 앱 종류마다 알아낼 수 있는 내용과 미리 준비할 것이 다릅니다. 저장소 설명서의 표에서 일부만 옮겼습니다.
분석 대상 | 알아낼 수 있는 것 | 미리 준비할 것 |
|---|---|---|
네이티브 실행 파일(컴파일된 프로그램) | 프로그램이 하는 일을 사람이 읽을 수 있는 코드 형태로 풀어 보여 줍니다. 문자열과 함수 호출 관계도 나옵니다. | 역공학 전용 프로그램(Hopper, Ghidra, IDA) 중 하나를 따로 설치 |
JavaScript / Electron 앱 | 코드 조각이 서로 어떻게 이어지는지, 화면과 본체가 어떤 메시지를 주고받는지 알 수 있습니다. | Node.js와 npm |
웹사이트 | 페이지 구조, 불러오는 스크립트, 오가는 통신, 화면 캡처를 얻습니다. | Chrome 계열 브라우저 |
저장해 둔 네트워크 기록 | 어떤 요청과 응답이 오갔는지 확인합니다. | HAR 또는 Fiddler SAZ 기록 파일 |
.NET 프로그램 | 내부 구조와 명령 목록을 읽습니다. | 없음 |
SQLite 데이터베이스 파일 | 어떤 표와 열이 있는지, 일부 내용이 무엇인지 봅니다. | Node.js 24.15 이상 또는 26 이상 |
네이티브 실행 파일을 자세히 들여다보려면 Hopper, Ghidra, IDA 가운데 하나를 따로 설치해야 합니다. 이 글이 다루는 것은 따로 설치할 것이 없는 Electron 앱뿐. 설명서가 요구하는 Node.js는 22.19 이상, 24.11 이상, 26 이상 중 하나입니다.
가장 쉬운 방법: 에이전트에게 말로 시키기
REA 자체에는 화면이 없습니다. 저장소를 확인했지만 별도의 웹 화면이나 데스크톱 앱은 찾지 못했습니다. 화면 역할은 연결한 의 대화창이 맡습니다. 설명서가 지원하는 에이전트는 Claude Code, Claude Desktop, Codex, Cursor, Gemini CLI 등입니다.
연결은 터미널에서 한 줄. 어느 에이전트에 붙일지 고르고, 바뀔 내용을 확인해 승인하면 됩니다.
npx rea-agents setup
설명서에 따르면 이 명령은 REA를 에이전트에 등록하고 기존 설정은 백업해 둡니다. 사용자 폴더의 에이전트 설정 파일을 고치는 작업이라 직접 해 보지는 않았습니다. 대신 프로젝트 폴더 안에 연결 설정 파일 하나를 두고 Claude Code를 실행하는 방법으로 같은 효과를 냈습니다.
{"mcpServers":{"rea":{"command":"node","args":["node_modules/rea-agents/scripts/rea.mjs","mcp"]}}}
이렇게 연결한 Claude Code에 한국어로 물었습니다. 앱 코드는 열지 못하게 막고 REA 결과만 근거로 쓰게 했습니다.
sample-app 폴더는 Electron 앱입니다. REA 도구로 분석해서, 이 앱에 어떤 기능이 있고 화면과 본체가 어떤 통로로 통신하는지 쉬운 한국어로 설명해 주세요.
답이 나오기까지 걸린 시간은 2분 28초. 에이전트는 파일 다섯 개 중 JavaScript가 세 개라는 것부터 밝힌 뒤 이렇게 정리했습니다. 아래는 답의 일부입니다.
화면에서 부르는 이름 | 통로 이름 | 에이전트가 짐작한 기능 |
|---|---|---|
|
| 메모 검색 |
|
| 메모를 클립보드에 복사 |
|
| 메모 동기화 |
에이전트는 통신 방식도 설명했습니다. 화면이 memo.search(...)를 부르면 중간 파일(preload.js)이 notes:search 통로로 본체에 요청을 보내고, 본체(main.js)가 같은 이름의 통로에서 기다리다 처리해 답을 돌려준다는 내용입니다. 요청을 보내는 쪽 3개와 받는 쪽 3개가 모두 짝이 맞았습니다.
보안 쪽으로는 두 가지를 지적했습니다. 화면과 본체를 분리하는 설정(contextIsolation)은 켜져 있었고, 본체가 요청을 보낸 쪽을 확인하는 코드는 하나도 없었다는 것입니다. 창이 하나뿐인 앱이라 당장은 문제가 아니지만, 외부 웹페이지를 띄울 때는 점검할 자리라는 설명이 붙었습니다.
에이전트는 알아내지 못한 것도 밝혔습니다. 본체가 요청마다 실제로 무슨 일을 하는지는 확인하지 못했다고 했습니다. 큰 분석 결과 파일 두 개를 읽을 도구를 제가 막아 두었기 때문입니다. 파일 읽기를 허용하면 그 부분을 채울 수 있습니다. Claude Desktop 같은 화면 앱에서 같은 요청을 하는 것은 해 보지 않았습니다.
명령으로 직접 실행하기
없이 명령만으로도 같은 분석을 할 수 있습니다. 결과가 사람이 읽기에 어려워서, 원리를 보고 싶은 분께만 권합니다.
프로젝트 폴더 안에 설치하면 지울 때도 폴더 하나만 지우면 됩니다.
mkdir rea-lab && cd rea-labnpm init -ynpm install rea-agentsnpx rea --help
받은 버전은 6.4.0(10월 11일 배포). 설치에 20초가량 걸렸고 폴더 용량은 약 100MB였습니다.
분석 대상은 직접 만든 메모 앱, 파일 5개짜리 작은 Electron 앱입니다. 실제 서비스 중인 앱은 아닙니다. 검색, 클립보드 복사, 서버 동기화 세 기능이 들어 있으며 본체 쪽 코드는 아래와 같습니다.
ipcMain.handle('notes:search', (_e, keyword) => searchNotes(app.getPath('documents'), keyword));ipcMain.handle('clipboard:copy-note', (_e, text) => { clipboard.writeText(text.trim()); return true;});ipcMain.handle('notes:sync', async (_e, note) => { const res = await fetch(SYNC_URL, { method: 'POST', body: JSON.stringify(note) }); return res.status;});
1단계: 전체 분석
폴더든 이든 명령은 같습니다.
npx rea analyze-javascript-application sample-app --json > evidence.json
소요 시간은 9초쯤, 결과 파일은 610KB입니다. 소스가 5개뿐인데도 이만큼 나옵니다. 설명서는 실제 앱에서 수백 MB까지 커진다고 경고하며 Obsidian의 결과가 334MB라는 예를 듭니다. 이 파일을 에게 통째로 읽히는 것은 피해야 합니다. 같은 앱을 ASAR로 묶어 분석했을 때도 파일 수와 개수가 폴더 결과와 똑같았습니다.
2단계: 요약만 꺼내기
큰 결과에서 요약만 뽑는 명령은 따로 있습니다.
jq -c '{source:{kind:"inline",evidence:.},view:{kind:"summary"}}' evidence.json > view.jsonnpx rea inspect-analysis-view view.json
결과는 약 10KB로 줄었고, 핵심은 다음과 같습니다.
browser_windows: 1 # 창 1개preload_entrypoints: 1 # preload 파일 1개exposed_api_members: 3 # 화면에 열어 둔 기능 3개ipc: literal_channels: 3 # 이름이 확인된 통로 3개 main_handlers: 3 # 본체 쪽 처리 함수 3개 paired_renderer_transmissions: 3 # 화면 쪽 요청과 짝이 맞은 것 3개sender_validation_observations: 0 # 보낸 쪽을 확인하는 코드 0건
코드를 한 줄도 읽지 않고도 창 하나에 통로 세 개가 있고 통로마다 처리 함수가 짝지어 있다는 것을 알 수 있습니다.
3단계: 기능 하나 따라가기
"클립보드 복사"가 어디서 어디로 이어지는지 통로 이름으로 추적합니다. 분석 결과와 찾을 대상을 한 파일에 담아 명령에 넘깁니다.
node -e 'const fs = require("fs");const application = JSON.parse(fs.readFileSync("evidence.json", "utf8"));fs.writeFileSync("trace-input.json", JSON.stringify({ application, seed: { kind: "channel", value: "clipboard:copy-note", match: "exact" }, direction: "both"}));'npx rea trace-application-feature trace-input.json --format json
처음에는 seed.kind를 ipc-channel로 적었다가 입력 오류가 났습니다. 오류 메시지가 쓸 수 있는 값(route, string, api, channel, module, native-export)을 알려 줘서 channel로 고쳤습니다.
결과에서 기능 흐름만 추린 내용:
창(main.js 24~26행) → preload.js를 불러옴preload.js → 화면에 memo 기능 3개(copyNote, search, sync) 제공preload.js → clipboard:copy-note 통로로 요청main.js 14행의 처리 함수 → 그 요청을 받아 처리
화면의 버튼이 본체의 몇 번째 줄에 닿는지 줄 번호까지 나옵니다. 복사 기능만 물었는데 나머지 두 기능까지 함께 나오는데, 세 기능이 모두 preload.js 한 파일을 거쳐 본체로 가기 때문입니다.
직접 해 보고 알게 된 점
Node 버전
이 PC의 Node는 24.10.0이라 설명서가 요구한 24.11보다 낮았습니다. npx rea doctor는 이 점을 문제로 표시했지만 JavaScript 분석은 오류 없이 끝났습니다. 공식 지원 범위 밖이라는 점은 알아 둘 일.
정적 분석의 한계
REA는 코드를 실행하지 않고 읽기만 합니다. 결과에도 "은 이 연결이 실행 때 일어난다는 증거가 아니다"라는 단서가 붙어 있습니다. 해석하지 못한 부분은 unknown(알 수 없음)으로 남기는데, 샘플 앱의 의미 분석에는 118개가 남았습니다. 찾는 방식에 따라 결과가 달라지는 경우도 있었습니다. 서버 주소를 문자열로 찾으면 0건이었고, 의미 흐름을 따라가는 명령에서 literal로 찾으면 1건이 나왔습니다. 0건이 나오면 없다는 뜻이 아니라 찾는 방식을 바꿔 볼 신호.
깊은 분석은 준비물이 더 필요합니다
rea doctor는 Hopper, Ghidra, IDA가 모두 없다고 알려 줬습니다. 네이티브 실행 파일 분석, 웹사이트 분석, .NET 분석은 직접 실행해 보지 않았습니다.
저장소 규모
2026년 10월 13일 기준 커밋 2,661개, 열린 이슈 303건, 열린 풀 리퀘스트 206건입니다. 설명서도 REA가 빠르게 바뀌니 최신 버전을 쓰라고 안내합니다. 쓰기 전에 버전부터 확인하십시오. 이 글의 명령은 모두 6.4.0 기준.
만드는 쪽에는 무엇이 달라질까
여기부터는 사실이 아니라 제 판단입니다. 역공학 도구 자체는 새롭지 않습니다. Ghidra(미국 국가안보국 NSA가 만들어 공개), IDA, Hopper가 오래전부터 있었고, REA가 바꾸는 것은 해석을 가 대신해 주어 시작하기가 쉬워졌다는 점.
앱을 내려받은 사람은 그 앱의 코드를 손에 쥔 셈입니다. 이번 실습에서도 샘플 앱의 서버 주소와, 화면과 본체가 주고받는 통로가 분석 결과에 그대로 드러났습니다. Electron 문서도 묶음이 소스를 "대충 훑어보는 것으로는 보이지 않게" 가릴 뿐이라고 설명합니다. 앱 안에 넣은 것은 누군가 읽을 수 있다고 보고 만드는 편이 안전합니다. 지켜야 할 규칙과 중요한 처리는 서버에 두라는 뜻.
반대로 서버 안은 앱을 분석해도 보이지 않습니다. 이번 분석이 보여 준 것은 코드의 연결 구조까지였고, 서버에서 일어나는 일이나 계정, 실시간 데이터는 볼 수 없었습니다. 그래서 REA 한 가지로 서비스를 통째로 복제할 수 있다는 식의 말은 직접 확인한 능력과 맞지 않습니다. 실제로 복제 피해가 얼마나 생길지는 아직 근거가 없는 상태.
쓰기 전에 지킬 것
역공학은 법과 약관의 영향을 받는 일입니다. 본인이 만든 앱, 소유한 앱, 보안 점검을 허락받은 앱처럼 분석해도 되는 범위 안에서만 쓰십시오. 상용 앱의 이용약관은 역공학을 금지하는 경우가 많다는 점도 기억하십시오.
데이터가 어디로 가는지도 알아 둬야 합니다. 설명서는 REA가 대상을 이 컴퓨터에서 분석한다고 밝힙니다. 다만 가 분석 결과를 받아 읽으므로, 그 결과는 에이전트를 운영하는 모델 사업자의 데이터 정책을 따릅니다. 민감한 앱을 분석한다면 이 점부터 따져 보십시오.
