소스가 없거나 낯선 데스크톱 앱의 동작을 조사할 때 REA로 기능과 내부 코드의 연결을 찾아볼 수 있습니다. 코딩 에이전트가 바이너리와 Electron 앱의 내부 관계를 조사하고, 결론의 근거를 받아 다음 질문이나 구현으로 이어가게 합니다. 이미 소스와 테스트로 원인을 찾을 수 있다면 기존 코드 탐색부터 시작할 수 있습니다. 2026년 10월 9일 확인한 문서와 v6.0.0 릴리스를 기준으로 설명합니다. 공식 저장소
한눈에 보기
| 궁금한 점 | 확인한 내용 |
|---|---|
| 무엇을 연결합니까? | Codex·Claude Code 등에 로컬 분석 도구를 MCP로 연결합니다. |
| 어떤 입력을 다룹니까? | 네이티브 실행 파일, JavaScript·Electron 앱, .NET 어셈블리, 웹 등을 다룹니다. |
| 첫 시도에 맞는 작업은 무엇입니까? | 분석 권한이 있는 작은 Electron 앱에서 기능 한 개의 모듈·IPC 경로를 찾습니다. |
| 최소 준비는 무엇입니까? | 지원되는 Node.js와 npm을 준비합니다. 네이티브 분석 엔진은 별도입니다. |
| 설치가 무엇을 바꿉니까? | 선택한 에이전트의 MCP 등록과 기본 포함 워크플로 지침을 씁니다. |
| 비용은 어디서 생깁니까? | 연결한 에이전트·모델 요금과 선택한 외부 분석 엔진에서 생깁니다. |
| 무엇을 검증했습니까? | 공개 문서를 대조했습니다. 앱 분석을 직접 실행한 결과는 없습니다. |
이 표의 기능은 프로젝트 문서가 설명하는 범위입니다. 실제 사용 가능 여부는 설치한 패키지 버전, 분석 대상, OS와 분석 엔진의 조합으로 결정합니다. 특히 Windows 네이티브 분석은 실험적 범위를 별도로 안내합니다. README, Windows Ghidra P0
어떤 작업에 도움이 됩니까?
REA는 Reverse Engineer Anything의 약자로, 프로그램의 내부 구조와 동작을 조사하는 도구를 코딩 에이전트에 제공하는 공개 프로젝트입니다. MCP는 에이전트가 외부 도구를 호출하고 결과를 받는 연결 방식입니다. REA는 독립된 새 코딩 모델을 제공하기보다 기존 에이전트의 조사 수단을 늘립니다. 프로젝트 소개
예를 들어 Electron으로 만든 메모 앱에서 검색이나 복사 기능이 어느 코드로 이어지는지 이해하고 싶을 때 사용할 수 있습니다. Electron은 웹 기술로 데스크톱 앱을 만드는 틀이며, 화면 쪽 코드와 운영체제 기능을 처리하는 메인 프로세스가 나뉩니다. 이 둘 사이의 IPC, 즉 프로세스 간 통신을 따라가면 화면에서 보이는 버튼과 실제 처리 코드의 관계를 좁힐 수 있습니다. REA의 JavaScript 분석은 모듈, import, 소스맵, IPC와 네이티브 애드온의 관계를 반환한다고 설명합니다. 분석 대상과 결과
공식 Notion 사례는 이 차이를 보여 줍니다. Notion Desktop 7.6.1의 복사 기능에서 페이지 API, preload의 요청 전달, 메인 프로세스의 수신 처리, Electron 클립보드 호출을 잇습니다. 페이지에 노출된 메서드 이름만으로 결론을 내리기보다 IPC 채널 notion:clipboard:write와 래퍼 구현을 따라 연결을 설명합니다. 다만 역할은 나뉩니다. REA 4.1.0은 저장된 preload에서 노출 API와 요청 전달 호출을 소스 위치와 함께 찾았고, 그 채널을 메인 프로세스의 수신 처리와 잇는 부분은 작성자가 래퍼 코드를 직접 읽어 확인했습니다. 또 추출한 모듈과 작은 시험 코드로 확인한 기록이라 전체 데스크톱 UI를 조작한 체험과도 구분합니다. 공식 Notion 사례
네이티브 실행 파일에서는 문자열, 심볼, 호출 관계, 어셈블리와 의사코드가 조사 단서가 됩니다. 의사코드는 기계어를 사람이 읽기 쉬운 형태로 표현한 것이므로 원래 소스를 그대로 복구한 결과와 다를 수 있습니다. .NET 분석은 메타데이터와 CIL 명령을 정적으로 읽습니다. 웹 분석은 페이지·스크립트·네트워크 관찰을 다룹니다. 대상에 따라 얻는 증거가 달라지므로 “이 기능이 어디서 시작해 어느 처리로 이어지는가”처럼 질문을 좁히는 접근이 맞습니다. 대상별 결과 안내
기존 도구와 무엇이 다릅니까?
Codex나 Claude Code가 이미 접근할 수 있는 소스를 읽고 검색하는 작업과 비교하면, REA는 앱 패키지와 바이너리를 분석하는 도구의 결과를 추가로 전달합니다. 분석 결과를 설명하고 새 코드를 작성하는 주체는 연결한 에이전트입니다. REA가 반환한 단서를 에이전트가 더 조사하거나 자신의 프로젝트에서 구현·테스트하는 흐름입니다. 작동 방식
| 접근 | 적합한 상황 | 맡아야 할 일 |
|---|---|---|
| 기존 에이전트의 코드 탐색 | 소스와 실행 가능한 테스트가 있습니다. | 코드 검색·편집·테스트로 원인을 좁힙니다. |
| REA와 코딩 에이전트 | 패키지·실행 파일의 구조를 이해해야 합니다. | 분석 도구를 연결하고 반환된 증거와 해석을 대조합니다. |
| 분석 엔진 직접 사용 | 분석가가 네이티브 코드를 세밀하게 조사합니다. | Ghidra·Hopper·IDA 등에서 직접 탐색하고 해석합니다. |
| 브라우저 개발자 도구 | 관심 대상이 웹의 화면과 요청입니다. | 페이지·네트워크를 수동 관찰하는 것으로 목적을 달성할지 판단합니다. |
이 비교는 도입 선택을 위한 판단입니다. REA는 분석 엔진과 브라우저를 활용하는 연결 계층이므로, 기존에 충분한 조사 경로가 있는 작업에서는 추가 설정의 효용이 작을 수 있습니다. 반대로 화면을 보고 에이전트가 추측하던 작업에 모듈과 호출 관계를 더하면, 구현 방향을 검토할 구체적인 자료가 생깁니다. 다른 앱 전체를 복제하기보다 필요한 기능의 원리를 이해하고 자신의 요구사항으로 구현하는 범위부터 정할 수 있습니다.
어떻게 사용합니까?
다음은 README의 메모 앱 검색 기능 조사 입력을 한국어로 풀어 쓴 문서상 사용 예입니다. 검색 알고리즘이나 실제 결과 파일을 관찰한 체험은 아닙니다. 분석 권한이 있는 대상 앱의 위치와, 새 기능을 구현할 자신의 프로젝트를 에이전트에 구분해 알려 주는 방식으로 시작합니다. 공식 시작 예시
- 분석할 기능을 지정합니다. “메모 앱의 검색 기능이 어떻게 동작하는지 조사하고 근거를 제시한 뒤, 내 프로젝트에 비슷한 기능을 구현합니다”라고 요청합니다. 처음에는 조사 결과까지만 받도록 범위를 줄일 수도 있습니다.
- 대상의 구조를 읽습니다. Electron 앱이라면 추출된 디렉터리나 ASAR를 입력으로 삼습니다. ASAR는 Electron 앱의 파일을 묶는 아카이브입니다. REA가 반환하는 모듈·import·Electron 경계 정보로 관련 코드를 좁히는 흐름을 기대합니다.
- 근거와 해석을 대조합니다. 검색 요청을 보내는 코드, 요청을 받는 처리, 참조하는 모듈을 에이전트가 연결하도록 합니다. 정적 구조만으로 실행 중 데이터와 모든 분기를 알 수는 없으므로, 확인된 경로와 추가 관찰할 부분을 결과에서 나누어 읽습니다.
- 자신의 프로젝트에 구현하고 검증합니다. 조사 결과를 바탕으로 요구사항에 맞는 코드를 만들고 기존 테스트 경로로 확인합니다. 이 단계는 프로젝트 파일을 쓰고 명령을 실행할 수 있어, 분석 요청과 구현 범위를 구분해 전달합니다.
에이전트 연결 전에 CLI로 정적 분석만 할 수도 있습니다. README가 제시한 명령은 다음과 같습니다. /absolute/path/to/app은 실제 대상 디렉터리 또는 ASAR의 절대 경로로 바꿉니다. Windows 예시로는 README가 D:/apps/example을 안내합니다. 공식 CLI 예시
npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json
rea-agents가 패키지명이고 @latest는 실행 시점의 npm 최신 배포본을 선택합니다. -y는 npm 패키지 다운로드 확인을 생략하며, --json은 분석 결과를 JSON으로 받습니다. 이 명령의 기대 결과는 모듈·import·Electron 경계와 근거입니다. 시작부터 새 구현이 자동으로 생기는 명령과는 용도가 다릅니다. 정적 JavaScript·.NET 분석은 입력 파일을 읽으며 앱 코드를 실행하지 않는다고 README가 설명합니다. 런타임 캡처를 선택하면 대상 실행이나 상호작용이 사용자 권한으로 이루어집니다. 입력과 실행 영향
설치와 이용 조건
패키지 승인과 설정 승인은 나뉩니다
공식 최소 시작 명령은 다음과 같습니다. 지원되는 Node.js는 22.x의 22.19 이상, 24.x의 24.11 이상, 26 이상입니다. 문서는 Node.js 23·25와 프리릴리스를 지원 범위에서 제외합니다. npm은 해당 런타임과 함께 준비합니다. 설치 문서
npx rea-agents setup
짧은 명령은 현재 프로젝트에 설치된 REA 버전을 선택할 수 있습니다. 최신 배포본을 명시하려면 npx rea-agents@latest setup을 사용합니다. 설치 문서는 npm의 다운로드 승인과 REA의 설정 변경 승인을 구분합니다. 연결할 에이전트를 고르고, 파일 변경 계획을 검토·승인한 뒤 에이전트를 재시작합니다. 기존 설정의 백업도 만들며, 지속되는 MCP 등록은 setup을 실행한 패키지의 정확한 버전에 고정합니다. 버전과 승인 구분
setup은 선택한 에이전트의 MCP 등록과 일치하는 워크플로 지침을 기본으로 설치합니다. 기존 REA 등록은 기본 선택되고, 새로 발견한 클라이언트는 선택 가능한 상태로 남습니다. 지침 설치를 빼려면 --skill=false를 사용합니다. 변경 전 미리보기에는 --dry-run을 사용하며, Codex 클라이언트 값은 codex입니다. 설치 문서가 안내한 선택적 스킬 설치만으로는 MCP 등록이나 분석 엔진이 생기지 않으므로, 지침만 추가했을 때 도구 호출이 가능한지는 따로 확인합니다. 설정 변경과 스킬 범위
분석 대상마다 OS와 엔진 조건이 다릅니다
정적 JavaScript 분석에는 Hopper나 Ghidra가 필요하지 않습니다. 깊은 네이티브 분석에는 기존 Hopper·Ghidra·IDA 설치 중 필요한 엔진을 연결합니다. Hopper 설치는 별도 승인 대상으로 안내하며, 자동으로 유료 라이선스를 구매하는 절차로 설명하지 않습니다. Ghidra는 필요한 배포본과 JDK를 별도로 준비합니다. 엔진 준비, Hopper 설치 조건
Windows Ghidra P0 문서는 Windows 10 이상 x64, 대상과 임시 볼륨의 고정 로컬 NTFS, Ghidra 12.1.x와 호환되는 64비트 full JDK를 요구합니다. 대상은 네이티브 x86·x86-64 PE 앱으로 제한하며, DLL·managed PE와 다른 형식은 이 경계에서 제외합니다. 32비트 x86 PE는 main 기준 지원이고, 문서는 5.0.0까지의 npm 배포본이 x86-64 PE만 받는다고 적습니다. 문서는 제한된 읽기 전용 분석을 실험적으로 지원한다고 설명합니다. 따라서 Windows 에이전트 등록이 가능하다는 사실만으로 모든 분석 기능의 Windows 지원을 판단하기는 어렵습니다. Windows 범위와 의존성
README는 Android 분석에 Linux/macOS의 headless JADX와 full JDK, 펌웨어 분석에 Linux의 Binwalk·Unblob, 프로세스 캡처에 Linux/macOS의 native PTY를 안내합니다. Hopper에도 별도 호스트 기준이 있습니다. 필요한 작업의 가이드를 먼저 고르면 불필요한 엔진을 설치하는 일을 줄일 수 있습니다. 대상별 준비 사항
로컬 분석과 모델 전송을 함께 봅니다
프로젝트는 대상 분석이 로컬에서 이루어지고, 결과를 받는 에이전트의 모델 제공자 정책은 별도라고 설명합니다. 확인한 시작 절차는 특정 유료 모델을 새 기본값으로 지정하기보다 사용 중인 에이전트를 연결합니다. REA의 결과에 앱 코드나 문자열이 포함될 수 있어, 연결한 에이전트가 도구 결과를 외부 모델에 전달하는 설정과 데이터 정책을 함께 검토합니다. 데이터 처리 FAQ
검토한 자료에서 REA 자체의 통계 전송 기본값·비활성화 설정은 미확인입니다. 이를 근거로 모든 전송이 꺼져 있다고 단정하지 않습니다. 분석 대상의 사용·조사 권한은 별도로 확보합니다. 프로젝트의 MIT 허가는 타사 앱을 분석하거나 그 코드를 재배포할 권한까지 대신하는 조건으로 읽지 않습니다. 프로젝트의 사용 범위 안내
비용과 라이선스
REA 코드의 MIT 라이선스는 사용·수정·배포·판매를 허용하고, 복사본이나 상당 부분에 저작권·허가 고지를 포함하는 조건을 둡니다. 따라서 REA 자체를 상업 프로젝트에 활용할 때 이 고지 조건을 확인합니다. 분석 대상과 연결된 외부 도구는 각각의 이용 조건을 따릅니다. MIT 원문
확인한 자료에서 REA 자체의 별도 유료 이용 가격표는 미확인입니다. 코딩 에이전트의 구독이나 모델 API 비용은 연결한 계정과 사용량에 따라 계산합니다. 여러 번 조사하고 구현을 요청하면 해당 에이전트의 호출도 누적될 수 있으므로, “로컬 분석”만으로 모델 비용까지 무료라고 계산하지 않습니다.
Hopper는 별도 상용 소프트웨어입니다. 설치 문서는 공급자가 제한을 정하는 무료 데모와 선택적인 유료 라이선스를 안내합니다. 데모 제한·현재 가격의 세부 조건은 이번 조사에서 미확인으로 남깁니다. 한국 전용 제공 조건이나 한국어 분석 품질도 직접 확인한 자료가 없어, 실제 계정 접근과 입력 품질은 도입 시험 항목으로 둡니다. Hopper 조건
한계와 유지보수
2026년 10월 8일의 v6.0.0 릴리스는 커밋 6fee426을 가리킵니다. 호환성 변경으로 MCP의 파일시스템 입력에 호스트 절대 경로를 요구합니다. 대상·스냅샷·근거 묶음 등의 상대 경로를 넘기던 호출은 수정 대상이며, CLI의 작업자 기준 상대 경로는 계속 지원한다고 설명합니다. 에이전트에 전달할 경로와 CLI에서 쓰는 경로를 같은 규칙으로 가정하면 호출이 실패할 수 있습니다. v6.0.0 릴리스
같은 릴리스에는 대형 ASAR 분석과 JSON 출력, 입력 검증 등의 수정이 기록돼 있습니다. 다만 알고리즘의 분석 완료와 MCP가 결과를 에이전트에 전달하는 성공은 별도 단계입니다. 10월 8일 작성된 이슈 #1053은 개발 빌드에서 Notion 7.6.1의 app.asar(8,903,750바이트) 분석이 성공으로 끝난 뒤 Invalid string length로 응답 직렬화가 실패한 사례를 보고합니다. 10월 9일 확인한 원문은 Closed 상태입니다. 이슈가 언급한 PR #1055는 대형 ASAR 분석 성능 수정이며, 이슈 본문은 그 PR이 이 직렬화 문제를 해결한다고 적지 않습니다. 따라서 v6.0.0 배포본에서 해결됐는지는 미확인으로 남기고, 큰 대상의 결과 수신을 별도 시험 항목으로 봅니다. 관련 이슈 #1053
이슈 #1048은 Ghidra 가져오기와 자동 분석이 시작 제한 시간(보고 기준 330,000ms)을 넘을 때 부분 결과 없이 같은 비용을 반복하는 문제를 제기하고(64MB x86-64 PE에서 provider_timeout 사례), 미리 분석한 프로젝트를 읽기 전용으로 여는 기능을 요청합니다. 확인한 웹 원문은 Open 상태입니다. README는 큰 바이너리의 시작 제한을 조정하는 REA_GHIDRA_STARTUP_TIMEOUT_MS를 안내하지만, 기다리는 시간을 늘리는 것과 사전 분석 결과를 재사용하는 것은 다른 해결책입니다. 이슈의 제안을 이미 제공되는 기능처럼 사용 절차에 넣지 않습니다. 기능 요청 #1048, 현재 시작 제한 안내
유지보수 근거는 최신 릴리스와 수정 내역에서 확인했습니다. 문서의 main은 npm 배포본보다 앞설 수 있고, 스킬만 새로 받으면 실행 중인 서버와 등록 버전은 그대로일 수 있습니다. 업데이트할 때 setup 변경 계획을 다시 검토하고 재시작한 뒤, 연결된 서버의 실제 도구 목록과 입력 스키마를 기준으로 기능을 선택합니다. 릴리스와 등록의 구분
확인한 범위
문서 확인: 공식 README, 설치 문서, v6.0.0 릴리스와 커밋 6fee426, Windows Ghidra P0, Notion 사례, 관련 이슈 #1053·#1048, MIT 라이선스를 대조했습니다. 릴리스 기준과 현재 main의 문서를 구분했습니다. 계획의 스타 수치는 화면별 차이가 있어 도입 판단에서 제외했습니다. OS별 실제 성공, 설치 시점의 npm 최신 버전, 한국 계정 접근과 한국어 품질, REA 자체 통계 설정은 미확인입니다.
메모 앱 사례는 README를 따라 구성한 예상 절차입니다. 설치와 앱 분석은 직접 실행하지 않았습니다.
도입 판단
특정 상황에 유용합니다. 소스 탐색만으로 이해하기 어려운 앱 기능을 조사해야 하고, 대상에 대한 분석 권한과 엔진 준비 부담을 감수할 수 있는 개발자에게 맞습니다. 특히 작은 JavaScript·Electron 대상은 네이티브 엔진 없이 정적 구조부터 살필 수 있어 첫 시험 범위를 줄이기 좋습니다.
다음 행동은 권한이 있는 작은 앱에서 기능 하나를 고르고, 모듈 위치·IPC 경로·설명 근거가 실제 코드와 맞는지 대조하는 것입니다. 구현은 그 조사 결과를 검토한 뒤 자신의 프로젝트에 좁은 범위로 적용합니다. 대형 바이너리와 ASAR를 주로 다루는 팀은 시작 시간과 결과 전송을 먼저 확인하고, Windows 사용자는 P0의 대상·파일시스템 조건부터 맞춥니다. 이미 소스·테스트 또는 수동 분석 도구로 목적을 달성하고 있다면 추가 연결의 필요성을 다시 비교할 수 있습니다.
참고한 자료
2026년 10월 9일 확인했습니다. README·설치·릴리스·#1053은 실행기가 제공한 원문 사본을 먼저 읽었고, 빠진 공식 문서와 상태를 웹에서 보충했습니다.
- morluto/rea 공식 저장소: 대상·결과·최소 시작·데이터 처리·사용 범위를 확인했습니다.
- 설치와 설정: Node.js 조건, 설정 승인, 등록 버전과 스킬 설치의 차이를 확인했습니다.
- rea-agents v6.0.0: 기준 커밋, 절대 경로 변경과 수정 내역을 확인했습니다.
- Windows Ghidra P0: 실험적 지원 대상·OS·파일시스템·의존성을 확인했습니다.
- Notion 클립보드 사례: 기능 한 개를 preload와 메인 프로세스 사이에서 추적하는 공개 사례를 확인했습니다.
- 이슈 #1053: 대형 ASAR의 분석 완료와 결과 전송 실패를 구분했습니다.
- 이슈 #1048: Ghidra 사전 가져오기·재사용 요청을 현재 기능과 구분했습니다.
- MIT 라이선스: 상업 사용과 배포 고지 조건을 확인했습니다.
