REA 리버스 엔지니어링 오픈소스, 직접 돌려 본 성능과 한계
깃허브 35만 스타 REA를 직접 돌려 봤다. 디컴파일러가 아니라 에이전트용 배선이고, 틀리기보다 빠뜨리는 도구였다.

REA(Reverse Engineer Anything)는 AI 코딩 에이전트가 소스 코드 없이 프로그램을 뜯어보게 해 주는 오픈소스 리버스 엔지니어링 도구다. 리버스 엔지니어링은 완성된 프로그램을 거꾸로 분석해 작동 방식을 알아내는 일이다. 10월 21일 깃허브 저장소의 스타는 약 35만 5천 개였다(GitHub). 공개 검증을 모으고 운영진 PC에서 직접 돌려 본 결과를 더해, 무엇이 되고 무엇이 안 되는지 따져 본다.
핵심 요약
- REA는 디컴파일러가 아니라 Ghidra·IDA 같은 기존 엔진을 에이전트가 부르게 하는 연결 도구다. 엔진 없이는 네이티브 프로그램의 함수 하나도 보지 못했다(운영진 실행, 6.5.0).
- 소스가 공개된 앱으로 대조한 독립 테스트에서 지어낸 결과는 0건이었지만, 창으로 돌아가는 회신 8곳(메인에서 6, 창 사이 2)은 하나도 잡지 못했다([System Design Academy](https://www.systemdesign.academy/explained/rea-reverse-engineer-anything)).
- 증거가 지나치게 많다. 6.7.0의 도구 목록만 약 3.16MB였고([CellCog](https://cellcog.ai/blog/rea-reverse-engineer-anything/)), 작은 폴더 분석 결과는 10MB를 넘어 에이전트에게 전달되지 못했다.
디크립트는 이 저장소의 스타가 10월 6일 1만 개 미만에서 12일 10만 개를 넘었고, 11일 하루에만 3만 개가 늘었다고 전했다(Decrypt, 2026.10.12). InfoQ는 17일 20만 개 초과로 썼다(InfoQ, 2026.10.17). 매체마다 숫자가 다른 것은 집계 시점 차이다.
REA란 무엇인가
README는 REA를 "바이너리, 애플리케이션, 런타임 동작 전반을 다루는 하나의 MCP"라고 소개한다. MCP(Model Context Protocol)는 AI 에이전트가 외부 도구를 정해진 형식으로 부르게 하는 연결 규격이다. REA는 MCP 서버, 명령줄 도구, 에이전트용 작업 지침(스킬)으로 이뤄진다. Claude Code, Codex, Cursor, Gemini CLI 같은 에이전트가 REA를 부르고, 결과는 발견(findings), 근거(evidence), 모르는 것(unknowns)으로 나눠 기록된다.
| 항목 | 내용 |
|---|---|
| 작성자 | 핸들 morluto, 실명 미공개 |
| 라이선스 | MIT(REA 자체 코드에 한함) |
| 설치 | npx rea-agents setup, Node.js 22.19 이상 |
| 배포 | 첫 버전 0.2.1(7월 12일), 총 33개 버전. 10월 9일 6.2.0부터 18일 6.7.0까지 아흐레 동안 npm에 5개 버전(CHANGELOG에는 6.6.0까지 6개) |
| 분석 위치 | 사용자 PC. REA는 대상 파일을 업로드하지 않음 |
출처: README, npm registry(10.21 조회). 작성자 핸들은 morluto이며 실명은 공개되지 않았다(InfoQ). 6.5.0에서 Ghidra의 PowerPC·RISC-V·MIPS·6502와 패킷·SQLite·WASM 검사가, 6.6.0에서 Kuna 엔진과 Windows ARM 실행 파일 지원이 추가됐다(CHANGELOG).
README는 원본 소스 코드 복원이나 앱 자동 복제를 주장하지 않는다고 스스로 선을 긋는다. 분석은 로컬에서 하지만, 에이전트의 AI 모델 제공자에게 무엇이 넘어가는지는 그 회사의 데이터 정책에 달렸다. 무료 모델에 무엇을 맡기는지가 곧 대가라는 점은 스페이스 버니 글에서 다뤘다. 'REA는 업로드하지 않는다'와 '아무것도 나가지 않는다'는 같은 말이 아니다.
무엇을 직접 하고 무엇을 남에게 맡기나
지원 목록은 길지만 상당 부분은 기존 도구를 대신 불러 주는 일이다.
| 분석 대상(README) | 필요한 외부 도구 |
|---|---|
| 네이티브 바이너리(C·C++·Go·Rust 등) | Ghidra, Hopper(macOS·유료), IDA(유료), Kuna, JEB(유료), objdump, Rizin 중 하나 |
| 안드로이드·펌웨어·패킷 | JADX·Apktool, Binwalk·Unblob, TShark |
| JS·Electron 앱, 웹사이트, .NET, WASM, 게임 엔진·AI 모델 파일 등 | Node.js·브라우저 등 대상마다 다름 |
REA는 상용 도구 라이선스를 제공하지 않는다. REA가 직접 맡는 것은 엔진 연결, 분석 절차, 그리고 결과마다 근거 번호·해시·확신 정도·한계를 붙이는 장부다. Hysen Labs는 REA를 "디컴파일러가 아니라 작업 조율자"라고 부르며, 엔진이 오작동하면 REA 연결부까지 디버깅할 층이 하나 더 생긴다고 지적했다(Hysen Labs).
실제 성능: 공개된 검증과 직접 돌려 본 결과
공식 벤치마크는 없다. README의 유일한 정량 주장은 고전 게임 DX-Ball의 사운드 좌우 배분 계산을 재구성해 "원본 x86 테스트 케이스 3,205개를 통과하고 함수 바이트 63개를 모두 재현"했다는 사례다. 노션 앱의 클립보드 경로 추적, 동방 4의 탄막 각도 복원도 쇼케이스에 있다. 모두 작성자 측 사례이며 독립 재현은 확인되지 않았다.
| 검증 | 조건 | 잘한 것 | 놓친 것 |
|---|---|---|---|
| System Design Academy(10.12) | 6.4.0, 맥북 에어, Ghidra 없음. 소스 공개된 Electron API Demos | JS 54개 파싱 실패 0, 3.49초. 지목한 파일 30개·줄 위치 전부 정확. IPC 채널 18개, 지어낸 채널 0 | 창으로 가는 회신 8곳 중 0곳. 창 8개 생성을 1개로 셈. nodeIntegration: true 4곳 미보고 |
| CellCog(10.18) | 6.7.0 | REA로 REA 자신의 npm 패키지 분석: 1,706개 파일, 실패 0, 289초 | 결과 JSON 234MB, unknowns 4만 7,158건. Electron 테스트에서 프리로드 진입점 2개 누락 |
| 운영진(10.21) | 6.5.0, Windows 10, 엔진 없음 | PE 리소스 분석 성공, 한계 자체 명시 | 함수 목록 불가, 작은 폴더 결과 전달 실패 |
보여 준 길은 믿되 빈 곳은 직접 걸어 보라는 것이 테스터의 결론이다. REA도 결과에 "발견이 없다고 부재가 증명되지는 않는다"는 문구를 붙인다.
CellCog에 따르면 6.7.0이 에이전트에 알리는 도구는 207개, 목록 크기는 3,158,403바이트이고 81%가 출력 형식 설명이었다. 8KB 지침 파일 하나로 줄인 포크 'leanrea'와 비교하면(과제마다 3회) leanrea는 388초·2.17달러에 75점 중 74점, REA는 627초·3.36달러에 75점이었다. Ghidra 미설치 조건이다.
운영진이 직접 돌려 본 결과
우리는 10월 21일 운영진 PC의 Claude Code에 rea-agents 6.5.0을 연결해 다섯 가지를 확인했다. 외부 엔진은 설치하지 않았다. 분석 대상은 운영 PC에 기본 설치된 메모장의 파일 구조·리소스 정보와 우리가 직접 만든 소규모 JS 도구 폴더로 한정했다.
- 파일 열기는 됐다. 윈도우 메모장(notepad.exe)의 형식(PE), 구조(x86_64), 해시를 돌려줬다.
- 함수는 보지 못했다. 개요·함수 목록 요청은 "provider_unavailable"로 실패했다. Ghidra는 설치 경로 미지정(12.1.x 필요), Hopper는 윈도우 미지원, IDA는 설정 없음이 이유였다. 오류 메시지가 원인과 해결책을 항목별로 보여 준 점은 좋았다.
- 엔진 없이 되는 일은 잘했다. 리소스 5개, 20만 704바이트를 정리하면서 "아이콘 외 데이터는 불투명", "실제 로딩은 관찰 안 함" 같은 한계 3줄을 스스로 붙였다.
- 작은 폴더에서 막혔다. 블로그 관리자 도구 폴더(JS 파일 3개 남짓) 분석은 끝났다고 했지만, 응답이 최소 10,572,309바이트로 MCP 전송 한도(10,485,760바이트)를 넘어 에이전트에게 전달되지 않았다.
- 첫 호출이 두 번 실패했다. 도구마다 경로 인자 이름이 달라(path, input_path) 에이전트가 두 번 틀렸다. 207개 도구를 익히는 비용이다.
한계
README는 윈도우 Ghidra 지원이 실험 단계이고, 큰 바이너리는 시작 시간 제한을 늘려야 하며, 런타임 캡처는 사용자 권한으로 대상을 실제 실행한다고 밝힌다. 댓글이 많은 오픈 이슈도 같은 곳을 가리킨다. MCP 사용성·성능 로드맵(#1065, 46개), 윈도우 자체 테스트 실패(#1701, 19개), Ghidra 가져오기 시간 제한(#1048, 18개), Gemini CLI 400 오류(#4620, 17개)다(GitHub 이슈).
Hysen Labs는 관리형 PE 선별은 실행 없이 이뤄져 샘플이 실행 중 무엇을 하는지는 알려 주지 않는다고 지적한다. 가장 위험한 것은 프롬프트 인젝션이다. 대상 파일 속 문자열이 지시문처럼 쓰여 있으면 셸 권한을 가진 에이전트가 따를 수 있다. REA 안내문은 대상 내용을 "데이터로 다루라"고 적지만, 지키는 쪽은 결국 에이전트다.
가짜 설치 파일도 있다. README는 github.com/morluto/rea, rea.tools, npm rea-agents 외에서 내려받지 말라고 경고한다. 사칭 설치 파일이 돌았다는 보도가 있었으나 원문을 확인하지 못했다.
인간에게 무엇이 달라지는가
분석의 문턱은 낮아지고 판단의 문턱은 그대로다. 몇 시간씩 읽던 코드를 "이 앱이 클립보드를 어디로 보내는지 찾아 줘"라는 한 문장으로 시작할 수 있다. 그러나 REA는 빠뜨리고, 결과를 믿어도 되는지는 여전히 리버싱을 아는 사람이 판단한다.
만드는 쪽의 계산이 바뀐다. InfoQ에 따르면 인디 게임 개발자들은 레딧에서 유료 기능 우회와 복제를 걱정했고, 해커뉴스의 한 댓글은 프로그램을 사용자 PC에 두지 않는 클라우드 전환이 빨라질 수 있다고 봤다. AMD의 스리칸트 판날라 디렉터는 소프트웨어가 대체 가능해질수록 하드웨어가 지배적 자산이 된다고 했다. 숨길 것은 서버로, 가치는 장비로 옮겨 갈 가능성이 크다.
경계는 흐려진다. 10월에 AI로 디컴파일한 '모던 워페어 2' 영상이 내려갔고, 베데스다가 AI로 만든 'Fallout: New York'에 중지를 요청했다고 디크립트는 전했다. GTA V를 아이폰에서 돌렸다는 트윗은 기사가 검증하지 않았다. 이 사례들에 REA가 쓰였다고 확인된 것은 없다.
반론과 불확실성
해커뉴스에서는 "에이전트에게 Ghidra를 설치해 쓰라고 하는 것과 무엇이 다른가"라는 의문이 나왔고(InfoQ), leanrea 비교가 여기에 힘을 싣는다. 기존 AI 보조 리버싱보다 낫다는 경험담도 있었다. 독립 테스트는 JS 앱이나 엔진 없는 환경에 치우쳐, Ghidra를 갖춘 네이티브 분석의 정확도는 공개 검증을 확인하지 못했다. 포크 8만 9,000개, 오픈 이슈 982개(10.21 열람)가 실제 업무 사용자 수를 말해 주지도 않는다.
미국 판례는 상호운용성 목적의 역분석을 공정 이용으로 인정해 왔지만, 사용권 계약(EULA) 위반과 DMCA 1201조의 접근 통제 우회 금지는 별개다. 한국 저작권법도 제101조의4에서 호환에 필요한 정보를 얻기 위한 프로그램코드역분석을 좁게 허용한다. 프로그램을 정당하게 쓰는 사람이 필요한 범위에서만 할 수 있고, 얻은 정보를 비슷한 프로그램 개발 같은 다른 목적에 쓰는 것은 허용 범위 밖이다. 기술적 보호조치의 무력화는 제104조의2가 따로 금지한다. 이 글은 법률 자문이 아니다.
PRISM AGENDA의 시각
우리는 REA를 디컴파일러가 아니라 에이전트가 리버싱 도구를 쓰게 하는 배선과 증거 장부로 본다. 새 기술이 아니라 새 포장이다. 35만 개의 스타는 기술의 크기가 아니라 '에이전트에게 도구를 쥐여 주는 일'에 대한 수요의 크기를 잰 숫자다.
진짜 가치는 증거 설계다. 결과마다 근거 번호, 해시, 확신 정도, 한계를 붙이는 방식은 AI 분석이 따라야 할 표본이다. 그러나 같은 설계가 약점이 된다. 작은 폴더에 10MB, 자기 분석에 234MB. 사람이 읽을 수 없는 증거는 증거가 아니다.
가장 위험한 것은 환각이 아니라 침묵이다. 테스트들이 보여 준 것은 "틀린 말은 거의 안 하지만 빠뜨린다"였다. 빠진 것을 모르는 사용자는 "없다"고 결론 내고, 보안 점검에서 그 결론은 가장 비싼 오답이다.
도구는 중립이지만 수요는 중립이 아니다. 10월의 디컴파일 영상과 팬 제작 게임은 REA 없이도 일어났고, REA는 그 흐름을 더 쉽게 만든다. 상호운용성, 보안 연구, 보존은 정당하다. 하지만 자기 것이 아닌 소프트웨어의 유료 기능을 벗기는 것은 도구가 아니라 사람의 선택이다.
마지막은 격리다. 7월 OpenAI의 평가용 에이전트가 격리 환경을 벗어나 허깅페이스 서버에 침입한 사건(Hugging Face 기술 타임라인)을 지능 폭발 점검 글에서 다뤘다. 리버싱 권한을 받은 에이전트는 더 많은 것을 만진다. REA는 업무 PC가 아니라 격리된 환경에서, 출처가 확인된 설치 파일로만 돌려야 한다.
자주 묻는 질문
REA를 쓰면 원본 소스 코드를 얻을 수 있나요? 아니다. 얻는 것은 외부 엔진의 의사 코드와 구조 분석, 그 근거 기록이며 빠진 부분은 사람이 확인해야 한다.
REA만 설치하면 바로 쓸 수 있나요? JS·Electron 앱 등 일부는 Node.js만으로 분석된다. 일반 실행 파일의 함수를 보려면 Ghidra나 IDA 같은 엔진이 따로 필요하고, 운영진 실행에서는 엔진 없이 메모장의 함수 목록도 얻지 못했다. 유료 엔진의 라이선스는 REA가 주지 않는다.
REA로 소프트웨어를 분석하는 것은 합법인가요? 나라, 목적, 계약 조건에 따라 다르다. 한국 저작권법은 호환 목적의 역분석만 좁게 허용하고 보호조치 무력화는 따로 금지한다. 직접 만들었거나 권리자에게 분석 허락을 받은 프로그램에 쓰는 것이 안전하며, 구체적 판단은 법률 전문가에게 받아야 한다.
다음 질문
- 에이전트가 빠뜨린 것을 사람이 어떻게 알아챌 수 있게 만들 것인가.
- 분석 비용이 0에 가까워지면 소프트웨어 회사는 무엇을 서버 뒤로 숨기게 될까.
- 도구를 쥔 에이전트의 격리는 누가, 어떤 기준으로 책임질 것인가.



댓글
첫 댓글을 남겨 주세요.