REA는 클로드 코드·코덱스 같은 코딩 에이전트를 Ghidra·IDA 같은 리버스 엔지니어링 도구에 이어 주는 오픈소스 MCP 서버이자 CLI다. 소스 코드가 없는 앱의 기능이 어떻게 돌아가는지 에이전트가 추측하지 않고 실행 파일을 뜯어 본 근거로 분석하게 하고, 필요하면 비슷한 기능을 다시 구현하게 할 때 쓴다. 새 분석 기술이 아니라 이미 있는 도구를 이어 주는 연결 도구다.
| 구분 | 에이전트만 쓸 때 | REA를 붙였을 때 |
|---|---|---|
| 분석 방법 | 기억과 추측에 의존 | 디컴파일러를 직접 호출 |
| 결과 | 그럴듯한 설명 | 발견 내용 + 근거 위치 |
| 모르는 부분 | 잘 드러나지 않음 | 따로 표시해 줌 |
터미널에서 npx rea-agents setup을 실행하고 쓸 에이전트(클로드 코드, 코덱스, 커서 등)를 고르면 등록이 끝난다. 네이티브 실행 파일을 분석하려면 Ghidra 같은 엔진을 직접 설치해야 하며, Ghidra는 GHIDRA_INSTALL_DIR와 JAVA_HOME 환경 변수를 잡아 줘야 한다. REA는 엔진을 대신 설치하거나 상용 엔진 라이선스를 주지 않는다.
| 분석 대상 | 필요한 것 | 방식 |
|---|---|---|
| 네이티브 실행 파일 | Ghidra·IDA·Hopper 중 하나 | 디컴파일 |
| JavaScript·Electron 앱 | 별도 엔진 불필요 | 파일만 읽는 정적 분석 |
| .NET 어셈블리 | 별도 엔진 불필요 | 정적 분석 |
| 실행 중인 앱·웹사이트 | 내 사용자 권한 | 실제로 실행하며 동작 수집 |
사용법은 평소처럼 에이전트에게 말로 묻는 것이다. 에이전트가 MCP로 REA를 부르면 REA가 대상 종류를 판별해 내 PC에서 맞는 엔진을 돌리고, 결과를 본 것(Seen)·추론한 것(Inferred)·모르는 것(Unknown)으로 나눠 돌려준다. 에이전트는 이를 바탕으로 설명하거나 코드를 짜고 테스트한 뒤, 모르는 부분은 다시 묻는다.
예를 들어 윈도우 그림판을 분석해 동작 방식을 정리한 뒤 의존성 없는 JS 캔버스 앱으로 다시 구현할 수 있다. 개발사가 사라져 실행 파일만 남은 오래된 설비 프로그램의 통신 방식을 파악하는 데도 쓸 수 있다.
REA가 주는 것은 의사 코드, 어셈블리, 함수 간 호출 관계처럼 컴파일된 프로그램을 읽은 결과다. 개발자가 쓴 원본 소스를 복원하지 않는다. 찾아낸 내용은 근거가 붙어 믿을 만하지만, 못 찾았다고 해서 그 기능이 없다는 뜻은 아니다. 최신 에이전트는 REA 없이도 어느 정도 분석을 하므로, REA의 가치는 미리 정리된 도구와 절차로 더 빠르고 체계적으로 하게 해 주는 데 있다.
MIT 라이선스지만 프로젝트는 연구·교육·상호운용·보존, 그리고 내가 소유했거나 분석 권한이 있는 소프트웨어에만 쓰라고 명시한다. 상용 앱을 분석해 똑같이 만들어 파는 것은 불법이 될 수 있다. 또 분석 엔진은 로컬에서 돌지만 결과는 에이전트를 거쳐 AI 회사 서버로 전송되므로 기밀 파일은 조심해야 한다.
가장 흔한 건 소스는 없고 실행 파일만 남은 프로그램을 코딩 에이전트에게 맡겨 동작 방식을 정리하게 하는 것이다. 정리한 결과를 바탕으로 같은 에이전트가 대체 코드를 짜고 테스트까지 이어 간다.
| 어디서 | 어떻게 쓰나 |
|---|---|
| 오래된 사내·설비 프로그램 유지보수 | 개발사가 사라진 실행 파일의 통신 방식·파일 형식을 파악해 새 시스템과 연동 |
| 기능 재구현 | 권한 있는 앱의 기능을 분석한 뒤 의존성 없는 새 코드로 다시 만들기 |
| JS·Electron·.NET 앱 점검 | 별도 엔진 없이 파일을 읽어 특정 기능이 어디서 어떻게 처리되는지 확인 |
| 리버스 엔지니어링 학습·연구 | 본 것·추론한 것·모르는 것 구분을 보며 디컴파일 결과 읽는 법 익히기 |