AI 에이전트가 당신의 앱을 리버스 엔지니어링할 수 있을까?

REA — Reverse Engineer Anything — 는 코딩 에이전트가 전문 리버스 엔지니어링 소프트웨어를 조작할 수 있게 해주는 오픈소스 MCP 서버이자 명령줄 도구입니다. 에이전트를 출시된 앱이나 바이너리를 향하게 하면, 실제 디컴파일러로 코드를 검사하고, 어떤 기능이 어떻게 작동하는지를 명세로 작성하고, 그 기능을 다시 구축한 뒤, 재구축 결과를 원본과 대조합니다. 2026년 10월 GitHub에서 가장 빠르게 성장한 프로젝트 중 하나가 되었고, 오래된 사실 하나의 경제학을 바꾸었습니다. 사용자의 컴퓨터에서 실행되는 모든 것은 그 사용자가 읽을 수 있다는 사실입니다. 이 글은 REA가 실제로 무엇인지, REA가 구동하는 도구 스택, 그 출력을 신뢰할 수 있게 만드는 워크플로, 그리고 소프트웨어를 출시하는 개발자가 이에 대해 무엇을 해야 하는지를 설명합니다.

REA란 무엇인가

REA(리포지토리는 morluto/rea, MIT 라이선스, npm에서 rea-agents 로 설치)는 디컴파일러가 아닙니다. 스스로는 아무것도 디컴파일하지 않습니다. Model Context Protocol을 사용하는 오케스트레이션 계층이며 — 이 사이트의 에이전트 준비도 작업이 웹사이트 쪽에서 다루는 바로 그 인터페이스입니다 — 리버스 엔지니어링 작업을 Claude Code, Codex, Cursor 같은 코딩 에이전트가 호출할 수 있는 도구로 노출합니다. 이 바이너리를 디스어셈블하라, 이 함수를 디컴파일하라, 문자열을 나열하라, 상호 참조를 따라가라, 증거를 보여 달라. 무거운 작업은 그 아래의 엔진들이 수행하고, 에이전트는 인간 분석가가 하듯 그 엔진들을 구동하되, 철저하게 파고들 여유를 갖고 있습니다.

이러한 분업이 핵심입니다. 디컴파일러의 출력은 방대하고 대부분 지루합니다. 리버스 엔지니어링에서 희소한 기술은 도구를 실행하는 것이 아니라, 다음에 무엇을 봐야 할지 결정하고 답이 입증된 때를 아는 것이었습니다. REA는 엔진에 워크플로 지침을 짝지어 — 정해진 순서로 조사하고, 모든 주장에 대해 증거를 기록하고, 해결할 수 없었던 것을 명시하게 하여 — 에이전트의 출력이 의사코드의 더미가 아니라 근거가 첨부된 발견들의 집합이 되게 합니다. 네이티브 바이너리에 대해서는 Ghidra, IDA Pro 또는 Hopper를 구동하고, Android 패키지에 대해서는 JADX를 구동하며, 실시간 동작에 대해서는 HAR 및 mitmproxy 캡처를 읽을 수 있습니다. 하나의 인터페이스, 여러 엔진, 그리고 에이전트가 지구력을 제공합니다.

한 장의 지도로 보는 스택

분석 코어. Ghidra 는 NSA의 무료 Apache-2.0 라이선스 디컴파일러로, 대부분의 사람에게 기본 엔진입니다. IDA Pro는 많은 전문가가 여전히 선호하는 상용 강자입니다. 새로운 것은 두 도구 자체가 아니라 그 다리입니다. GhidraMCP 와 ida-pro-mcp 는 실행 중인 Ghidra 또는 IDA 세션을 MCP를 통해 에이전트에게 노출하여, 에이전트가 스크린샷을 읽는 대신 디스어셈블리 데이터베이스를 직접 조회할 수 있게 합니다. REA는 그 한 단계 위에 앉아 엔진을 선택하고 작업의 순서를 정합니다.

모바일과 앱. jadx 는 Android APK를 읽을 수 있는 Java로 다시 디컴파일하고, Apktool 은 APK의 리소스와 smali를 풀고 다시 구축할 수 있으며, Frida 는 실행 중인 앱에 계측을 적용해 함수가 실행되는 대로 후킹합니다 — 정적 디컴파일로는 볼 수 없는 동적인 절반입니다. 그리고 ILSpy는 .NET 어셈블리에 대해 jadx가 APK에 대해 하는 일을 합니다. (코드가 아닌 APK의 선언을 설치 없이 먼저 살펴보려면, 이 사이트의 APK Analyzer 가 브라우저에서 매니페스트, 권한, 서명 인증서를 읽습니다.)

바이너리와 저수준. radare2 와 그 더 친숙한 포크인 rizin 은 스크립트 가능하고 터미널 중심인 리버스 엔지니어링 프레임워크이고, x64dbg 는 대부분의 분석가가 찾는 Windows 디버거이며, ImHex는 파일 형식을 기술하는 패턴 언어를 갖춘 16진수 편집기이고, angr는 한 번의 실행이 아니라 함수를 통과하는 모든 경로에 대해 추론할 수 있는 기호 실행 엔진입니다. 이것들은 디컴파일러가 잘 답하지 못하는 질문을 위한 도구입니다. 패킹된 바이너리, 이상한 파일 형식, “이 입력이 저 분기에 아예 도달할 수 있는가”.

네트워크와 런타임. mitmproxy 는 앱과 그 서버 사이에 앉아 대화를 기록합니다 — 많은 앱에서는 API 트래픽이 코드보다 더 많은 것을 설명하고, 이는 REA가 기본으로 읽는 캡처 형식입니다. dnSpy는 .NET 애플리케이션을 실시간으로 디버깅하고 편집하며, raddebugger는 Epic의 Windows용 현대적 그래픽 디버거입니다. 그 모든 것의 주변에는 지도가 있습니다. 두 개의 엄선된 목록, awesome-ai-reverse-engineering (에이전트 시대 리포지토리 122개, 각각 읽고 점수를 매김)와 REA 저자 자신의 awesome-reverse-engineering 가 아래 출처에 링크되어 있습니다.

클린룸 루프: 명세, 재구축, 검증

REA가 권장하는 워크플로는 AI보다 오래되었습니다. 바로 클린룸 엔지니어링, 한때 BIOS를 복사하지 않고 클론하는 데 사용된 규율입니다. 에이전트는 대상을 조사하고 SPEC.md 를 작성합니다 — 소프트웨어가 무엇을 하는지를 평이한 언어로 쓴 명세로, 각 동작에 대한 증거가 첨부되어 있습니다. 그 후에야 디컴파일된 코드가 아니라 명세로부터 재구축이 시작되고, 재구축은 인수 기준으로 판단됩니다. 같은 입력, 같은 출력, 같은 경계 사례. 판정자가 아니라고 말하는 지점에서, 루프는 추측이 아니라 증거로 돌아가 다시 조사합니다.

이것이 흥미로운 산출물이 의사코드가 아니라 명세인 이유입니다. 증거가 있는 명세는 두 번째 에이전트, 테스트 스위트, 또는 인간이 검사할 수 있습니다. 원시 디컴파일 결과는 그 어느 것도 아닙니다. 이는 법적으로도 중요한 단계입니다. 동작 명세로부터의 재구축은 구현을 복사하는 것과는 다른 행위이며, 그래서 이 루프는 느낌이 아니라 증거와 기준을 고집합니다. 에이전트 도구를 평가하는 사람이라면 — 리버스 엔지니어링용이든 그 무엇이든 — 이 패턴을 훔쳐야 합니다. 결과물은 자신감 있는 답이 아니라 검증된 주장입니다.

소프트웨어를 출시한다면 이것이 갖는 의미

이 중 어느 것도 클라이언트 측 코드를 비밀로 만들지 않습니다. 애초에 비밀인 적이 없었습니다. 그저 읽는 비용을 저렴하게 만들 뿐입니다. Ghidra에 능숙한 분석가는 언제나 당신의 앱에서 API 엔드포인트, 기능 플래그, 라이선스 로직을 뽑아낼 수 있었습니다 — REA급 도구는 에이전트 구독이 있는 주니어가 오후 한나절에 첫 번째 패스를 해낼 수 있음을 의미합니다. 실질적인 결과는 예전과 같되, 이제 마감 기한이 짧아졌습니다. 출시된 바이너리에 내장된 비밀 — API 키, 비공개 엔드포인트, 유일하고 진정한 할인 규칙 — 은 사실상 공개된 것이나 다름없습니다. 난독화는 읽는 비용을 높이지만 장벽이 아니라 지연일 뿐입니다. 그리고 당신의 사업이 그 비밀성에 의존하는 모든 것은 앱 안이 아니라, 인증 뒤에 있는 당신의 서버에 있어야 합니다.

방어책도 똑같이 화려하지 않고, 효과가 있습니다. 비밀과 가격/라이선스 결정을 서버 측에 유지하고, 영구 키 대신 수명이 짧고 범위가 제한된 토큰을 발급하며, 위험이 정당화하는 곳에서는 플랫폼 증명(Play Integrity, App Attest)을 사용하고, 남용 방지책을 설계할 때는 클라이언트의 동작이 완전히 관찰 가능하다고 가정하는 것입니다. 이는 이 사이트의 에이전트 준비도 교훈의 거울상입니다. 거기서 요점은 에이전트가 당신이 설계했든 아니든 당신의 웹사이트의 기계 대면 표면을 읽는다는 것이었습니다. 여기서 에이전트는 당신의 앱 바이너리를 같은 방식으로 읽습니다. 두 경우 모두, 이기는 수는 기계 대면 표면이 무엇을 말할지를 신중하게 결정하는 것입니다.

합법적 사용 — 그리고 경계

리버스 엔지니어링에는 명예롭고 확립된 용도가 있으며, REA 자체 문서도 같은 목록을 명시합니다. 자신의 소프트웨어 분석(소스를 잃어버린 사본 포함), 보안 연구와 취약점 분석, 악성코드와 사고 조사, 상호운용성 — 당신의 제품을 다른 제품과 함께 작동하게 만드는 것 —, CTF 대회, 그리고 교육입니다. 많은 관할권에서는 이 중 일부가 이를 금지한다고 주장하는 라이선스 조항에 대해서도 보호받는데, 특히 상호운용성과 선의의 보안 연구가 그렇습니다. 다만 세부 사항은 다양하고, 이 글은 법률 자문이 아닙니다.

경계도 마찬가지로 분명합니다. 도구에 대한 MIT 라이선스는 대상에 대한 라이선스가 아닙니다. 경쟁사의 바이너리로부터 그 제품을 클론하거나, DRM이나 라이선스 집행을 무력화하거나, 추출한 것을 배포할 권한을 부여하지 않습니다. 앞 절의 클린룸 루프는 재구축을 그 선의 올바른 쪽에 유지하기 위해 정확히 존재합니다 — 복사된 구현이 아니라 동작과 증거입니다. 이 사이트 자체의 분석 도구도 축소판으로 같은 선을 따릅니다. 정적, 로컬, 읽기 전용, 실행 없음, 우회 없음 — 첫 번째 살펴보기이며, 무겁고 법적으로 민감한 작업은 그에 대한 책임을 질 수 있는 도구와 사람들에게 맡깁니다.

직접 사용해 보기

REA는 Node.js 22 이상이 필요합니다. 하나의 명령 — npx rea-agents setup — 으로 찾은 코딩 에이전트에 그 MCP 서버를 등록하고 어울리는 워크플로 지침을 설치하며, REA 자체의 doctor 명령이 각 엔진을 점검합니다(네이티브 바이너리에는 Ghidra 같은 네이티브 엔진이 설치되어 있어야 하고, JADX는 APK를 다룹니다). 당신이 소유한 소프트웨어나 검사할 권한이 있는 샘플을 향하게 하고 — 당신이 작성한 작은 유틸리티가 완벽한 첫 대상입니다 — 한 기능이 어떻게 작동하는지 물어보세요. 어떤 의사코드보다도 먼저, 그것이 만들어 내는 명세를 읽으세요. 증거 링크가 진실이 있는 곳입니다.

첫 단계의 무설치 버전을 원한다면, 그것이 바로 이 사이트의 Binary File Inspector 의 용도입니다. PE, ELF 또는 Mach-O 파일을 페이지에 놓으면 브라우저에서 그 헤더, 섹션, 가져오기, 문자열을 읽을 수 있습니다 — 업로드 없음, 실행 없음, 도구 체인 없음. 아무것도 디컴파일하지 않으며, 그 점도 명시합니다. 전체 REA 처리를 설정할 가치가 있는지, 그리고 어떤 엔진을 위한 것인지를 알려 주는 5분짜리 분류(triage)입니다.

출처와 추가 읽기

자주 묻는 질문

REA가 원본 소스 코드를 복구합니까?

아니요. 바이너리에서 원본 소스 코드를 복구하는 것은 아무것도 없습니다 — 작성자가 쓴 변수 이름, 주석, 구조는 컴파일 시점에 사라집니다. 디컴파일러가 만들어 내는 것은 의사코드, 즉 기계 코드가 무엇을 하는지에 대한 읽을 수 있는 근사치입니다. REA의 기여는 그 증거로부터 체계적으로 작업하고 동작의 명세를 작성하는 것이며, 그것이 충실한 재구축에 실제로 필요한 것입니다.

앱을 리버스 엔지니어링하는 것은 합법입니까?

그것은 누구의 앱인지, 왜인지, 어디인지에 달려 있습니다. 자신의 소프트웨어에 대한 리버스 엔지니어링, 선의의 보안 연구, 상호운용성을 달성하기 위해 수행된 작업은 널리 받아들여지며 일부 관할권에서는 법적으로 보호받습니다. 제품의 라이선스는 그 이상을 제한할 수 있고, DRM이나 접근 제어를 우회하는 것은 의도와 관계없이 많은 곳에서 금지됩니다. REA 자체 문서도 이를 승인된 합법적 연구로 제한합니다 — 당신도 그래야 합니다. 답이 상업적으로 중요할 때는, 도구가 아니라 당신의 관할권에 있는 변호사에게 물을 질문입니다.

REA를 사용하려면 여전히 Ghidra를 설치해야 합니까?

네이티브 바이너리의 경우, 그렇습니다 — REA는 엔진이 아니라 오케스트레이션 계층입니다. 설치된 분석 엔진(Ghidra, IDA Pro 또는 Hopper)을 구동하고, doctor 명령으로 각각을 점검합니다. APK는 JADX를 거치고, 일부 대상 — JavaScript 및 Electron 앱, 웹사이트, 네트워크 캡처 — 은 네이티브 엔진이 전혀 필요 없습니다. 설치는 한 번, 오후 한나절이면 됩니다. 에이전트의 지구력이 당신이 고용할 수 없었던 부분입니다.