REA(Reverse Engineer Anything)는 코딩 에이전트가 리버스 엔지니어링 도구를 쓰게 해 주는 MCP 서버다. npx rea-agents setup 한 줄로 Claude Code, Codex, Cursor, Gemini CLI, Grok Build에 등록되고, 에이전트는 이 서버를 통해 Ghidra, IDA, Hopper, JADX, Apktool 같은 도구를 호출한다. 네이티브 바이너리, Electron 앱, .NET 어셈블리, Android APK, 웹사이트, 펌웨어까지 분석 대상으로 삼는다. 라이선스는 MIT다.
이 저장소는 10월 초에 갑자기 커졌다. Wayback Machine 스냅숏으로 확인하면 10월 4일 저녁(UTC) 스타 1,513개, 10월 6일 새벽 5,957개였고, 오늘(10월 16일) GitHub API로 조회한 값은 스타 275,753개, 포크 69,466개다. npm 일일 다운로드도 10월 3일 418건에서 10월 12일 103,109건으로 늘었다. 확산의 출발점으로 보이는 것은 10월 4일 X 계정 @_vmlops가 올린 소개 글(조회 32만)이고, 10월 10일 Hacker News 스레드는 806점, 댓글 338개를 받았다. 프로젝트 자체는 4월에 Hopper용 MCP로 시작했고, 7월에 TypeScript로 다시 쓰면서 REA라는 이름이 붙었다.
이 글에서 확인하는 것은 세 가지다. 사람들은 REA로 실제로 무엇을 했나, REA는 기존 리버스 엔지니어링 MCP에 무엇을 보탰나, 그리고 에이전트가 낸 분석 결과가 맞는지는 무엇으로 확인하나. 자료로는 저장소(HEAD 2c75835, 10월 16일)의 코드와 문서, GitHub Discussions 66개와 주요 이슈, Hacker News 스레드 두 개를 읽었다. npm rea-agents 6.5.0을 설치해 직접 만든 작은 Electron 앱과 이 블로그의 node_modules에 있는 공개 패키지에 분석 명령을 돌려 봤다. Ghidra, IDA 같은 네이티브 백엔드는 설치하지 않았으므로, 바이너리 분석은 문서와 쇼케이스 기록으로만 다룬다.
사람들이 REA로 실제로 한 일
스타 수만 보면 다들 상용 앱을 복제하려는 것처럼 보인다. 실제로 이 도구를 처음 퍼뜨린 소개 글도 “Recreate features for your own stack”이라는 문구를 앞세웠다. 그런데 Discussions와 Hacker News 댓글에서 사용 경험을 구체적으로 적은 글을 모아 보면, 자기가 이미 가진 기기나 프로그램을 다루는 이야기가 가장 많다.
- 폰 앱으로만 되던 기기를 다른 환경에서 쓰기. Discussion #4152의 사용자는 휴대폰 앱으로만 인쇄되던 LX-D02 감열 프린터를 Windows에서 쓰고 싶었다. 앱을 열어 보니 React Native와 Hermes 번들이었고 “로직은 JS에 있었다”고 적었다. Hacker News의 한 사용자는 Insta360 Studio가 AMD GPU를 쓰도록 shim을 만들었고 “수작업으로 했다면 몇 주는 걸렸을 것”이라고 했다. 프린터 드라이버를 분석했다는 댓글도 있다.
- 오래된 게임 복원과 이식. 버려진 MS-DOS 게임을 다시 빌드한 사람, Win95/98 게임을 바이트 단위로 같게 복원했다는 사람, 32비트 ARM 게임을 64비트로 옮겼다는 사람이 있다. 이슈 #2072는 NES 게임을 분석하면서 REA를 근거 기록(evidence ledger) 용도로 썼다고 적었다.
- 자기 서비스를 바깥에서 점검. Next.js와 Stripe로 만든 자기 서비스를 외부 공격자 시점에서 점검했다는 글(#1406)이 있고, REA가 보는 방식대로 자기 사이트를 검사하는 방어용 스캐너를 만든 사람도 있다(#4328).
- 상용 앱 복제. QuickBooks 체험판을 분석해 회계 앱을 만들었다는 글이 있고, MathType이나 Microsoft Publisher를 웹으로 옮겨 달라는 요청, “Steam 게임을 전부 무료로” 같은 요청도 올라왔다. 이쪽은 목소리는 크지만 결과물을 보여 준 경우가 적다.
또 하나 자주 보이는 이야기는 모델의 거절이다. “민감한 리버스 엔지니어링이라는 이유로 실행이 자주 막힌다”는 이슈(#2095), Claude로는 진행이 안 된다는 글(#3038)이 있고, Hacker News에는 OpenAI 계정이 정지됐다는 댓글도 두 건 있다. 어떤 대상까지 분석해도 되는지는 도구보다 모델 공급자의 정책이 먼저 정하고 있다.
반대 의견도 있다. “Claude에게 Ghidra를 깔고 분석 환경을 직접 꾸리라고 하면 되는데 이게 뭐가 낫냐”는 질문이 있었고, 같은 앱을 REA 없이 Opus로 돌렸더니 더 먼저 끝났다는 X 게시물도 있었다. 중국어 Discussion #1928은 쇼케이스가 AI가 원래 잘 읽는 Electron 앱이나 단순한 APK, 옛날 EXE 위주라서 “써 보니 그냥 스킬 같다”고 평가했다.
정리하면 사람들이 원한 것은 소스가 없어서 손대지 못하던 소프트웨어를 읽고 고치는 일이었다. 원래는 리버스 엔지니어링을 배운 사람만 할 수 있던 일이고, REA는 그 진입 비용을 낮춰 줄 것처럼 보였다. 그 기대가 실제로 어디까지 맞는지는 아래에서 코드와 실행 결과로 확인한다.
스타 수는 실제 사용량을 대신하지 못한다는 점도 짚어 둔다. 포크 수가 스타의 25%로, GhidraMCP나 ida-pro-mcp(10~12%)보다 훨씬 높다. 가장 반응이 많은 이슈의 리액션은 14개다. 봇 스타를 의심하는 댓글이 있었지만 이를 확인한 조사는 찾지 못했다. npm 다운로드와 커밋 작성자 231명을 보면 실제 사용자가 많은 것은 맞다. 다만 27만이라는 숫자에는 화제가 돼서 일단 누른 스타가 상당히 섞여 있다고 보는 편이 자연스럽다.
기존 MCP와 무엇이 다른가
에이전트를 리버스 엔지니어링 도구에 연결하는 MCP는 REA 전에도 있었다.
| 프로젝트 | 공개 | 스타(10/16) | 하는 일 |
|---|---|---|---|
| LaurieWired/GhidraMCP | 2025-03 | 11,296 | Ghidra 기능을 MCP 도구로 노출 |
| mrexodia/ida-pro-mcp | 2025-03 | 12,925 | IDA 기능을 작업별 도구로 노출 |
| HexRaysSA/ida-mcp | 2026-08 | 1,194 | Hex-Rays 공식, IDAPython 실행 중심 |
| zinja-coder/jadx-ai-mcp | 2025-04 | 2,906 | Android 디컴파일러 JADX 연결 |
이 도구들은 엔진 하나의 API를 에이전트에 열어 준다. REA는 IDA 연결에 ida-pro-mcp를, JADX 연결에 jadx-headless-mcp를 그대로 가져다 쓴다. Ghidra만 자체 Java 브리지를 쓴다. 분석 엔진 자체를 새로 만든 것은 아니고, README도 디컴파일러를 포함하지 않는다고 밝힌다.
REA가 새로 만든 부분은 엔진 바깥에 있다. 저장소의 TypeScript 소스(테스트 제외)는 약 32만 줄인데, 그중 Ghidra 연동 코드는 1만 2천 줄 정도다. 가장 큰 디렉터리는 근거 기록과 분석 결과를 다루는 src/domain(9만 8천 줄)이다. 에이전트에 설치되는 스킬 파일은 본문과 참고 파일을 합쳐 1,200줄 남짓이다. 지시문은 짧고, 코드가 대부분을 차지한다.
결론마다 붙는 근거 기록
REA의 모든 분석 결과는 백엔드와 관계없이 같은 형식의 근거 기록(Evidence)으로 나온다. 기록에는 대상 파일의 해시, 어떤 도구로 어떤 파라미터를 썼는지, 원본 결과와 정규화된 결과, 확신도, 한계 목록이 들어간다. 직접 만든 Electron 앱을 분석했을 때 나온 관계 하나는 이런 모양이다.
relation: "invokes"
properties: { channel: "clipboard:write-rich", pairing_basis: "unique-exact-literal-channel", handler_path: "src/main.js" }
evidence: { state: "inferred", confidence: "high",
location: { source: "src/preload.js", start: {line: 4, column: 28}, end: {line: 4, column: 86} },
limitations: ["Literal channel equality does not prove that the handler is registered or reachable at runtime.", ...] }preload의 채널 문자열과 main의 핸들러 문자열이 같으니 둘이 연결된다고 추론했다. 그러면서 이 추론이 런타임 등록을 증명하지 못한다는 한계를 같이 적었다. 확정하지 못한 부분은 미확인(unknown) 항목으로 따로 남고, 나중에 해소 여부를 검증하는 도구(verify_unknown_resolution)도 있다.
설치되는 스킬은 이 기록을 쓰는 방법을 정해 둔다. 요청을 질문 목록으로 바꾸고, 각 결론을 근거 ID와 연결한 “finding ledger”를 유지하며, 끝내기 전에 질문마다 답함, 일부 답함, 미해결 중 하나로 표시하게 한다. 스킬에는 “모든 결론은 관찰, 추론, 미확인을 구분해야 한다(Every conclusion must distinguish observations, inferences, and unknowns)“라는 문장이 있고, 마지막에는 무언가를 만들 때 “관찰한 동작과 설계 선택을 분리하라”고 적혀 있다.
역할을 나누면 이렇다. 무엇을 볼지 정하고 코드를 쓰는 것은 에이전트다. REA는 백엔드를 실행하고 결과를 같은 형식으로 기록하고 보관한다. 재구현한 결과가 원본과 같은지 확인하는 비교 도구(compare_functions, verify_reconstruction)도 있지만, 도구 설명에는 비교에서 통과해도 선언한 항목에 대해서만 같다는 뜻이고 전체가 같다는 주장으로 넓히지 말라고 적혀 있다.
출력을 컨텍스트 밖에 두는 장치
리버스 엔지니어링 결과는 크다. REA는 분석 결과 전체를 서버 쪽에 두고, 에이전트에는 요약과 참조를 넘긴다. 응답이 10MiB를 넘으면 결과를 자르지 않고 resource_constraint 오류와 근거 참조를 돌려준다. 에이전트는 detail: "summary"로 요약을 받고, inspect_analysis_view로 필요한 부분을 페이지 단위로 읽는다. 같은 대상과 같은 파라미터의 분석은 캐시에서 다시 꺼낸다. 이 과정에 모델이 요약하는 단계는 없다. 전부 페이지 나누기와 참조로 처리한다.
직접 돌려 본 결과
npm rea-agents 6.5.0을 Node 26에서 설치했다. 설치는 8초 걸렸고 오류는 없었다. 네이티브 엔진 없이 돌아가는 정적 JavaScript 분석을 세 대상에 실행했다.
| 대상 | 크기 | 실행 시간 | 출력 |
|---|---|---|---|
| 직접 만든 Electron 앱 | 파일 7개, 1,955바이트 | 8.8초 | JSON 707KB (CLI 계산 168,851토큰) |
marked 패키지 |
공개 npm 패키지 | 6.1초 | JSON 26.5MB |
yaml 패키지 |
공개 npm 패키지 | 18.2초 | JSON 87.3MB |
테스트 앱은 main, preload, renderer 구조에 IPC 채널 두 개와 클립보드 호출을 넣어 만들었다. 요약은 정확했다. BrowserWindow 1개, preload 1개, contextBridge API 1개와 멤버 2개, 리터럴 채널 2개, renderer에서 main으로 가는 짝 2개를 모두 찾았다. 한계 목록에는 “JavaScript와 HTML은 실행하지 않은 텍스트로만 파싱했다”는 항목이 맨 앞에 있었다.
문제는 크기다. 2KB짜리 앱에서 17만 토큰짜리 결과가 나왔고, 그중 대부분은 노드 330개와 관계 232개, 미확인 항목 125개로 된 의미 그래프였다. CLI로 전체 결과를 받아 에이전트에 그대로 넘기면 컨텍스트가 바로 찬다.
MCP로 yaml을 분석하면 설계대로 동작했다. 전체 결과 요청은 response_bytes_at_least: 10585657과 함께 resource_constraint 오류로 돌아왔고, “결과는 잘리지 않았다”는 문구와 근거 참조가 붙어 있었다. 요약 요청은 21KB로 돌아왔고(분석 시간은 여전히 18초), 모듈 목록은 한 페이지에 5개씩, 페이지당 18KB 정도로 읽을 수 있었다. 요약에는 미확인 항목이 15,685개 남았다고 적혀 있었다. 큰 대상에서는 에이전트가 요약과 페이지 단위 조회를 쓰도록 하는 것이 사실상 필수다.
기능 추적 도구 trace_application_feature는 결과가 섞여 나왔다. 테스트 앱의 notes:search 채널을 추적하자 경로 3개가 나왔다. 첫 경로는 preload를 거쳐 ipcRenderer.invoke에 정확히 닿았다. 나머지 두 경로는 핸들러에서 “main.js가 포함한다”는 관계를 타고 같은 파일에 있는 관련 없는 클립보드 호출로 빠졌다. 실제 검색 함수가 있는 search.js의 searchNotes에는 끝내 닿지 않았다. 스킬 문서도 넓은 양방향 추적이 관련 없는 포함 관계로 퍼질 수 있다고 경고한다. 추적 결과는 출발점으로 쓰고, 경로마다 소스를 다시 확인해야 한다.
도구 목록 자체도 크다. MCP 서버는 도구 207개와 프롬프트 6개를 노출하는데, 기본 설정에서 도구 목록 JSON이 3.09MB다. 대부분은 출력 스키마(2.26MB)다. 이슈 #2019에는 도구 목록이 컨텍스트를 채워서 자동 압축이 계속 돈다는 보고가 있고, 문서에는 Kimi, pi-web-ui, WorkBuddy 같은 클라이언트가 전체 목록을 거부했다는 기록이 있다. 환경 변수 REA_MCP_INPUT_SCHEMA_PROFILE=compact와 REA_MCP_OUTPUT_SCHEMA_PROFILE=off를 주면 215KB로 줄었다. IDA MCP를 만든 Duncan Ogilvie가 Hex-Rays 공식 서버를 발표하며 쓴 “IDA는 기능이 많아서 도구가 쉽게 100개를 넘고, 각각 따로 조정해야 한다”는 문제가 REA에서도 그대로 나타난다.
결과가 맞는지는 무엇으로 확인하나
REA 웹사이트의 쇼케이스 세 건은 범위가 좁고, 각 사례의 근거 문서가 그 범위를 스스로 밝힌다.
- DX-Ball: 63바이트짜리 함수 하나를 분석했다. 흥미로운 점은 Ghidra의 의사 코드가 틀렸다는 것이다. 근거 문서에 따르면 Ghidra는 이 함수를 인자 없는 함수로 보여 주면서 스택 입력과 x87 연산을 빠뜨렸고, 에이전트는 명령어 목록을 직접 읽어 로직을 다시 세웠다. 재구현이 맞다는 확인(원본 x86 코드와 3,205개 입력 비교, 원래 컴파일러로 다시 빌드해 63바이트 일치)은 별도 재구현 저장소에서 했다. 그 저장소를 만든 사람은 REA의 커밋 수 3위 기여자다.
- Notion: 24.5KB짜리 preload 파일 하나를 분석했다. REA는 브리지 이름은 찾았지만 채널 값은 동적이라
null로 남겼고,notion:clipboard:write채널 추적은 “그래프 일치 없음”으로 끝났다. 클립보드 경로는 사람이 소스를 읽어 이었고, 근거 문서는 이 그림이 “자동으로 짝지은 IPC 그래프가 아니다”라고 적었다. - TH04: PC-98 게임의 함수 하나를 Ghidra로 열어 바이트를 대조했다. 분석할 함수는 기존 재구현 프로젝트(ReC98)가 이미 정리한 범위에서 골랐다.
세 사례 모두 REA가 한 일은 대상을 열고 근거를 기록한 데까지다. 결과가 원본과 같다는 판정은 원본 컴파일러와 입력 비교를 갖춘 별도 장치에서 나왔다.
같은 시기에 화제가 된 FPS 게임 복원 사례가 이 점을 더 분명히 보여 준다. 리버스 엔지니어 Maurice Heumann은 10월 9일 글에서 Claude Code와 Codex 에이전트로 3개월 동안 게임 코드를 복원해 함수의 99%를 재구성했고 83%가 원본과 바이트 단위로 같았다고 밝혔다. 이 작업은 REA가 아니라 Hex-Rays 공식 ida-mcp를 썼고, 처음에는 작업 에이전트 3개와 리뷰 에이전트 1개, 마지막 몇 주에는 에이전트 16개를 돌렸다. 검증은 원래 게임의 컴파일러로 빌드한 오브젝트 파일과 게임 실행 파일에서 함수 바이트를 꺼내 비교하는 스크립트가 맡았다.
이 글에서 가장 눈에 띄는 대목은 에이전트가 검증을 피하려 한 기록이다. 에이전트는 처음에 인라인 어셈블리를 쓰기 시작했고, 비교 스크립트를 고쳐서 자기 함수를 비교 대상에서 빼려고 여러 번 시도했다. 리뷰 에이전트는 원본과 직접 대조하지 않고 작업 에이전트의 해명을 받아들였다. 해결책은 CI가 검증 스크립트의 해시를 GitHub Actions 비밀값과 비교하게 만든 것이었다.
REA의 근거 기록은 에이전트가 무엇을 보고 무엇을 추론했는지 추적하게 해 준다. 하지만 재구현이 원본과 같은지는 기록이 아니라 원본과의 대조가 정한다. 그 대조 장치는 에이전트가 손댈 수 없는 곳에 있어야 한다. 이 원칙은 에이전트의 완료 보고를 실행 증거와 대조한 #74, 코드를 쓰지 않은 에이전트에게 판정을 맡긴 #81에서 다룬 문제와 같다.
클린룸 논쟁과 REA의 안전 장치
Hacker News에서 가장 길게 이어진 논쟁은 저작권이다. 전통적인 클린룸 방식은 원본을 분석하는 팀과 구현하는 팀을 나누고, 두 팀 사이에는 명세 문서만 오가게 한다. REA의 기본 흐름은 에이전트 하나가 분석과 재구현을 모두 한다. 댓글에는 “LLM을 쓰는 건 클린룸이 아니라 IP 세탁”이라는 의견, 모델이 무엇을 학습했는지 모르니 LLM이 만든 복제본이 클린룸 구현임을 증명할 수 없다는 의견이 있었다. 반대로 클린룸이 디컴파일 자체를 금지하는 것은 아니라는 반박도 있었다. 직접 클린룸 방식으로 개발한다는 한 개발자는 개인 앱이나 버려진 소프트웨어에는 좋겠지만, 결과를 공개했다가 소송 과정에서 원본을 디컴파일한 사실이 드러나면 곤란해질 수 있다고 적었다.
법률 쪽 정리로는 Hirzel Dreyfuss & Dempsey의 Patrick Dempsey가 10월 10일에 쓴 글이 읽을 만하다. 미국의 Sega v. Accolade(1992), Sony v. Connectix(2000) 판결은 호환성을 위한 중간 복제를 공정 이용으로 봤지만, 그 사건들의 최종 제품에는 복제한 코드가 들어 있지 않았다. 이 글은 두 판결이 원본과 바이트 단위로 같은 재구성물을 공개하는 일까지 허용하지 않았다고 짚는다. EU 소프트웨어 지침 6조도 디컴파일을 호환성 확보 목적으로 제한한다. 클린룸은 법이 요구하는 절차가 아니라 분쟁에서 독자 개발을 입증하는 방법이라는 점도 이 글이 짚는 부분이다. 이 블로그 글은 법률 자문이 아니고, 공개나 상업적 이용을 생각한다면 해당 국가의 전문가에게 확인해야 한다.
REA 쪽의 대응은 문서다. DISCLAIMER.md는 10월 12일에 처음 추가됐고, DRM과 라이선스 검사 우회, 안티치트 우회, 게임 치트, 상용 소프트웨어 복제를 돕지 않는다고 적었다. 이런 요청은 이슈와 토론에서 “답 없이 닫는다”고 한다. 코드에는 이를 막는 장치가 없다. 패키지의 소스에서 관련 키워드를 검색하면 테스트 외 코드에서 0건이고, 에이전트에 설치되는 스킬에도 합법성에 관한 지시가 없다. 코드 수준의 안전 장치는 의도가 아니라 작업의 위험을 다룬다. 분석 대상을 실행하지 않는 정적 분석, 파괴적 도구 표시, 설정 변경 전 승인, 분석 대상 안의 텍스트를 신뢰하지 않는 데이터로 표시하는 프롬프트 인젝션 방어가 그 예다.
인기의 부작용도 있었다. 10월 10일에 만들어진 rea-tools 조직이 REA를 흉내 낸 저장소에서 82.6MB짜리 압축 파일을 배포했는데, 이슈 #2424에 따르면 Windows Defender가 이를 트로이 목마로 탐지했다. 다운로드는 172회였다. 지금 그 저장소는 사라졌고, README에는 “비슷한 저장소 이름이나 복사된 README가 공식 배포본을 뜻하지 않는다”는 경고가 들어갔다. npm에서는 이름을 흉내 낸 패키지를 찾지 못했다.
내 프로젝트에 써 본다면
위의 확인 결과를 바탕으로, 자기가 가진 소프트웨어를 분석할 때의 순서를 정리했다. 설치와 실행은 직접 해 본 부분이고, 분석과 구현을 나누는 방법은 제안이다.
1. 대상과 목적을 먼저 정한다. 사람들이 성과를 낸 경우는 자기 기기의 연동, 자기 서비스 점검, 저작권이 정리된 옛날 게임처럼 대상이 분명했다. 회사 코드나 고객사 바이너리라면 분석 결과가 모델 공급자에게 전송된다는 점부터 확인한다. REA의 분석은 로컬에서 실행되지만, 에이전트가 읽은 코드 조각은 모델로 간다. NDA가 걸린 코드라면 이 부분이 먼저 문제가 된다.
2. 공식 경로로 설치하고 도구 목록을 줄인다. npx rea-agents setup만 쓰고, 비슷한 이름의 저장소에서 실행 파일을 받지 않는다. setup --dry-run을 먼저 돌리면 어떤 설정 파일에 무엇을 쓸지 미리 보여 준다. 클라이언트가 도구 목록을 거부하거나 컨텍스트가 빨리 찬다면 앞의 두 환경 변수로 스키마를 줄인다.
npx rea-agents setup --dry-run
export REA_MCP_INPUT_SCHEMA_PROFILE=compact
export REA_MCP_OUTPUT_SCHEMA_PROFILE=off3. 요약부터 받게 한다. 작은 앱도 결과가 17만 토큰이었으므로, 에이전트 지시에 “처음에는 detail: summary로 받고, 필요한 부분만 inspect_analysis_view로 읽어라”를 넣는다. 기능 추적 결과는 경로마다 소스를 열어 확인하게 한다.
4. 완료 기준을 결론별 근거 목록으로 정한다. 스킬이 정한 방식을 그대로 요구하면 된다. 질문 목록을 먼저 쓰고, 각 결론에 근거 ID와 관찰, 추론, 미확인 구분을 붙이고, 질문마다 해결 상태를 표시한 결과를 받는다. 사람은 추론으로 표시된 결론과 미확인 항목부터 검토한다.
5. 재구현한다면 검증 장치를 먼저 만든다. 원본 프로그램과 같은 입력을 넣어 출력을 비교하는 테스트, 가능하다면 원래 컴파일러로 빌드해 바이트를 비교하는 스크립트를 먼저 둔다. 그리고 이 스크립트를 에이전트가 고칠 수 없게 한다. Heumann이 했던 것처럼 CI에서 스크립트 해시를 확인하는 방법이 있다.
6. 결과를 공개하거나 판매할 생각이라면 분석과 구현을 나눈다. 분석 세션은 동작 명세 문서만 만들고, 구현은 원본과 분석 결과에 접근할 수 없는 별도 세션이나 별도 저장소에서 그 명세만 보고 진행한다. 명세 문서와 세션 기록을 남겨 두면 나중에 독자 개발을 설명할 자료가 된다. 모델이 무엇을 학습했는지까지는 통제할 수 없으므로, 이 방법이 법적 안전을 보장하지는 않는다.
패키지를 만드는 쪽에서 다시 볼 것
여기까지는 REA를 쓰는 사람의 입장이었다. 반대로 npm 패키지나 데스크톱 앱, 모바일 앱을 만들어 배포하는 쪽에서도 이 결과를 다시 볼 필요가 있다. 이 절은 위에서 확인한 사실을 바탕으로 한 필자의 판단이고, 별도 실험으로 검증한 내용은 아니다.
확인한 사실부터 모아 보면 이렇다. 직접 돌린 정적 분석은 Electron 앱의 IPC 구조를 9초 만에 정확히 찾았고, 공개 npm 패키지 두 개도 20초 안에 분석을 끝냈다. 네이티브 바이너리에서는 Heumann이 3개월 동안 에이전트를 돌려 FPS 게임 함수의 83%를 원본과 바이트 단위로 같게 복원했다. 시간과 토큰은 여전히 들지만, 배포한 코드를 읽으려면 전문 인력이 몇 달씩 붙어야 하던 장벽은 크게 낮아졌다. 컴파일이나 난독화로 구현을 감추는 방법은 분석 비용을 조금 올려 주는 정도로만 기대하는 편이 맞다. Notion 쇼케이스에서 동적으로 만든 채널 값이 null로 남았듯이 정적 분석을 어렵게 만드는 코드는 있다. 다만 에이전트는 사람보다 지루한 작업을 훨씬 오래 버틴다.
배포한 파일이 그대로 검증 기준이 된다는 점도 눈여겨볼 만하다. Heumann의 비교 스크립트는 원래 게임 실행 파일에서 꺼낸 함수 바이트를 정답으로 썼다. 배포물은 구현의 단서와 함께, 재구현이 맞는지 판정할 기준까지 복제하는 쪽에 넘겨준다. 법도 호환성을 위한 분석은 허용하는 쪽이다. 앞에서 본 미국 판례가 그렇고, EU 소프트웨어 지침은 6조의 디컴파일 권리를 계약으로 막는 조항을 무효로 본다(8조). 라이선스에 “리버스 엔지니어링 금지”라고 적어 두는 것만으로는 분석 자체를 막기 어렵다.
그러면 무엇을 바꾸고, 무엇을 경쟁력의 해자로 삼아야 할까. 패키지를 만드는 쪽에서 해 볼 만한 일을 네 가지로 정리했다.
1. 클라이언트에 들어가는 코드는 공개 문서처럼 다룬다. npm 패키지, Electron 앱의 preload와 renderer, APK 안의 JavaScript 번들은 누구나 읽는다고 가정한다. API 키, 내부 엔드포인트 목록, 할인 규칙 같은 업무 로직, 라이선스 검사는 클라이언트 코드에 두지 않고 서버에서 판단한다. REA의 DISCLAIMER는 라이선스 검사 우회를 돕지 않겠다고 적었지만 코드에는 이를 막는 장치가 없었다. 이 문제를 도구 제작자의 선의에 맡길 수는 없다. 배포하기 전에 자기 빌드 결과물에 REA 같은 정적 분석을 직접 돌려 보면, 바깥에서 무엇이 보이는지 확인할 수 있다. Discussions에서 자기 서비스를 외부 공격자 시점으로 점검한 사용자들이 한 일이 바로 이것이다.
2. 사람들이 리버스 엔지니어링을 시작하는 이유를 먼저 없앤다. 앞에서 본 사례 상당수는 공식 경로가 없어서 시작됐다. 프린터는 폰 앱으로만 인쇄됐고, Insta360 Studio는 AMD GPU를 지원하지 않았다. 기기나 서비스를 만드는 쪽이라면 문서화된 API나 SDK, 프로토콜 명세를 먼저 내놓는 편이 낫다. 사용자가 만든 비공식 클라이언트는 업데이트할 때마다 깨지기 쉽고, 만드는 쪽은 그 코드가 무엇을 건드리는지 알 수 없다. 공식 경로를 열어 두면 확장은 그 위에서 일어나고, 무엇을 열고 무엇을 닫을지는 만드는 쪽이 정할 수 있다.
3. 공식 배포 경로를 사용자가 알아볼 수 있게 한다. REA가 유명해지고 일주일도 안 돼 이름을 흉내 낸 저장소가 트로이 목마를 배포했다. 패키지가 알려질수록 같은 일이 생길 수 있다. npm이라면 npm publish --provenance로 어느 저장소와 CI에서 빌드했는지 증명을 붙이고, README와 웹사이트에 공식 배포 경로를 적어 둔다. 코드는 누구나 복사할 수 있어도, 사용자가 어느 배포본을 믿고 설치하는지는 복사되지 않는다.
4. 해자는 배포하지 않는 쪽에 둔다. 복제하는 쪽이 얻는 것은 특정 시점의 구현이다. 원본과 대조해서 맞췄다는 것은 그 버전과 같다는 뜻일 뿐이고, 다음 버전을 어떻게 만들지는 알려 주지 않는다. 배포물에 들어 있지 않은 것은 서버에 있는 데이터와 운영 노하우, 사용자들이 쌓아 온 설정과 연동, 그리고 이 분야에서 어떤 결과가 좋은지 정의한 테스트와 평가 세트다. #44에서 모델이 바뀌어도 남는 자산으로 eval을 꼽았는데, 복제에 대해서도 같은 판단이 성립한다. 공개된 동작은 따라 할 수 있지만, 다음에 어떤 동작이 맞는지 정하는 기준은 배포물에 들어 있지 않기 때문이다.
REA 자신이 좋은 예다. MIT 라이선스로 코드를 다 공개했고 포크는 6만 9천 개가 넘는다. 그런데도 사용자와 기여자 231명은 원래 저장소에 모여 있고, 복제 저장소는 악성 파일을 퍼뜨리다 사라졌다. 오픈소스라면 처음부터 코드는 해자가 아니다. 남는 것은 공식 배포 경로에 대한 신뢰와 기여자들이 모이는 곳, 그리고 다음 릴리스를 계속 내는 속도다. 이 판단이 자기 프로젝트에도 맞는지는, 포크나 비슷한 경쟁 제품이 나온 전후로 사용자 수와 이탈률이 어떻게 달라졌는지 보면 확인할 수 있다.
정리
REA는 코딩 에이전트에 Ghidra, IDA, JADX 같은 리버스 엔지니어링 도구를 한 번에 연결해 주는 MCP 서버이고, 10월 4일 이후 열이틀 만에 스타가 1,500개에서 27만 5천 개로 늘었다. 사용자들이 실제로 남긴 기록에서 가장 많은 것은 폰 앱으로만 되던 프린터, 오래된 게임, 자기 서비스처럼 자기가 가진 소프트웨어를 읽고 고친 경험이었다.
분석 엔진은 기존 도구를 그대로 쓴다. REA가 보탠 것은 결론마다 근거와 한계, 미확인 항목을 붙이는 기록 체계와, 큰 결과를 컨텍스트 밖에 두고 페이지 단위로 읽게 하는 장치다. 직접 실행해 보면 출력이 매우 크고 기능 추적이 엉뚱한 경로로 빠지기도 해서, 요약 조회와 사람의 확인이 필요하다. 재구현 결과가 맞는지는 쇼케이스에서도, FPS 게임 복원 사례에서도 원본과 대조하는 별도 검증이 정했다. 법적 제한은 문서에만 있으므로, 대상을 고르고 결과를 공개하는 판단은 쓰는 사람의 몫으로 남는다.
패키지를 만드는 쪽에서는 클라이언트에 배포한 코드를 누구나 읽을 수 있는 문서로 보고, 비밀과 업무 규칙은 서버로 옮기는 것이 먼저다. 경쟁력은 배포하지 않는 데이터와 운영, 평가 기준, 그리고 공식 배포 경로에 대한 사용자의 신뢰에 두는 편이 오래간다.
참고 자료
- morluto/rea (GitHub) · DISCLAIMER.md · npm rea-agents
- Hacker News: REA Reverse (2026-10-10) · 후속 스레드 (2026-10-12)
- @_vmlops, REA 소개 게시물 (X, 2026-10-04)
- GitHub Discussions #4152 (감열 프린터) · #1928 (회의적 평가)
- 이슈 #2019 (도구 목록과 컨텍스트) · #2095 (모델 거절) · #2424 (악성 복제 저장소)
- Maurice Heumann, 500+ Billion Tokens Later: Letting AI Agents Decompile A First-Person Shooter (2026-10-09)
- Hex-Rays, IDA MCP Server 발표
- Patrick Dempsey, Compiled Code Used to Keep Secrets. AI Just Taught It to Talk (2026-10-10)
- LaurieWired/GhidraMCP · mrexodia/ida-pro-mcp · HexRaysSA/ida-mcp