REA: 리버스 엔지니어링을 코딩 에이전트의 근거 수집 도구로

“이 앱의 내보내기 버튼은 파일을 어디에 쓰는가?”
같은 질문에 답하려면 화면 설명만으로는 부족하다.
UI 이벤트, 프로세스 간 메시지, 파일 쓰기 코드와 실제 관찰을 연결해야 한다.
REA(Reverse Engineer Anything)는 이런 조사를 코딩 에이전트가 MCP로 수행하도록 연결하는 오픈소스 분석 도구다.[1]

REA가 새로운 언어 모델이나 만능 디컴파일러를 제공하는 것은 아니다.[1]
에이전트가 기존 분석 엔진과 정적·런타임 관찰 경로를 사용하고, 반환된 근거를 읽어 설명하거나 재구현하도록 돕는다.[1][2]
중요한 구분은 분석 결과를 얻는 것, 그 결과를 해석하는 것, 재구현이 같은 동작을 하는지 검증하는 것이 서로 다른 단계라는 점이다.[4][5]

무엇을 해결하려는가

리버스 엔지니어링은 한 도구에서 끝나지 않는다.
패키지 안의 파일을 찾고, JavaScript 모듈을 추적하고, 필요하면 네이티브 함수를 살펴본 뒤 실행 관찰과 비교해야 한다.
REA는 이 과정의 도구 호출과 결과 전달을 같은 MCP·CLI 인터페이스로 묶는다.[1]

프로젝트의 흥미로운 부분은 “무엇이든 복원한다”는 이름보다 어떤 대상을 어떤 범위에서 관찰했는지 남기는 계약이다.[4]
관찰하지 못한 정보나 분석 한계는 unknown, coverage, limitations 같은 필드로 유지하며, 누락된 자료를 행동의 부재로 해석하지 않도록 한다.[4][5]

분석 도구와 에이전트의 책임을 나눈다

REA는 대상 식별, 분석 도구 호출, 정적 코드·참조·런타임 관찰 반환을 맡고, 에이전트는 그 근거를 이용해 다음 질문이나 설명·구현을 만든다.[1][2]
네이티브 분석에는 Hopper·Ghidra·IDA 같은 별도 엔진이 필요할 수 있으며, 모든 기능이 npm 패키지 하나만으로 동작하는 구조는 아니다.[1][3]

공식 조사 흐름과 Evidence 계약을 한국어로 재구성한 도식.
정적 연결 관계, 실제 실행 관찰, 재구현의 동등성은 서로 다른 주장이다.[1][4][5]

공개 기능은 넓지만 분석 대상마다 전제조건이 다르다.
다음은 전체 기능 목록이 아니라 도입 판단에 필요한 대표 경로다.[1]

운영체제 지원도 기능별로 읽어야 한다.[1][11]
예를 들어 네이티브 UI 관찰은 macOS 권한과 도구 조건을 갖고, 패킷·신호 분석에는 Linux에서 검증된 별도 경로가 있다.[1][11]
하나의 플랫폼에서 MCP 서버가 시작된다는 사실만으로 모든 분석 경로가 검증된 것은 아니다.[3]

Evidence: 답뿐 아니라 답의 범위를 반환한다

현재 MCP 계약은 분석 결과를 정규화된 normalized_result, 식별자인 evidence_id, 필요할 때의 provider 원본 표현인 raw_result 등으로 다룬다.[4]
이 기록은 세션에 보존되며, 비교 작업에 직접 전달하거나 Evidence bundle로 내보낼 수 있다.[4]
세션에 보존된 참조를 재사용하는 것과 다른 연결에서 임의의 ID만 전달하는 것은 같지 않으므로, 이전·재현 시에는 문서가 정한 bundle이나 전체 기록을 사용해야 한다.[4][5]

분석의 빈 결과와 분석 불가능도 다르다.[4]
함수의 호출 관계나 의사 코드가 실제로 관찰되지 않았다면, 해당 항목이 비어 있다는 사실만으로 “호출이 없다”거나 “코드가 없다”고 결론 내릴 수 없다.[4]
두 버전 비교에서도 반대편 입력의 coverage가 충분하지 않으면 단순한 누락을 삭제·추가로 확정하지 않고 미확인 상태로 남긴다.[5]

이 구분은 에이전트가 그럴듯한 설명을 과하게 확정하는 문제와 직접 연결된다.
결과의 출처가 있다는 것만으로 해석이 참이 되는 것은 아니지만, 반례를 찾고 재검증할 경로를 남긴다는 데 의미가 있다.

Electron 조사 예제: 버튼에서 파일 쓰기까지

공식 입문 예제는 여섯 파일로 구성된 작은 Electron Notes 앱이다.[10]
Electron을 설치하거나 앱을 실행하지 않고 코드를 살펴, Export notes 버튼이 notes:export 메시지를 보내고 main process가 CSV formatter를 호출하는 경로를 찾도록 구성되어 있다.[10]

관심 지점은 “코드를 읽어 설명했다”에서 멈추지 않는다는 것이다.[10]
예제는 제목에 쉼표와 따옴표가 들어간 입력의 CSV를 예측한 뒤, formatter를 Node.js로 직접 실행해 비교하도록 안내한다.[10]
이는 한 입력에서 formatter 동작을 확인하는 절차이지, Electron UI 전체나 모든 오류 경로를 검증한 결과는 아니다.[10]

JavaScript workflow 문서도 이 경계를 명시한다.[5]
정적 그래프에서 유일하게 해석된 호출 대상을 찾았다는 것은 그 경로가 실행되었다는 뜻이 아니며, 동적 호출·계산된 속성·지원하지 않는 변이는 미확인으로 남을 수 있다.[5]
실제 행동이 중요한 질문은 해당 앱 버전과 환경에서 별도의 관찰·probe로 확인해야 한다.[5]

설치와 공개 상태

2026년 10월 16일 확인한 GitHub 최신 릴리스는 rea-agents-6.5.0이며 npm 배포 버전도 6.5.0이다.[8]
릴리스에는 선택한 JavaScript 범위 분석, 보존된 Evidence의 요약·페이지 조회, 여러 오프라인 분석 경로 확장과 검증 범위가 기록되어 있다.[8]
다만 저장소 main은 배포 이후에도 바뀌므로 현재 문서의 모든 세부 기능을 6.5.0 패키지의 보장으로 읽어서는 안 된다.[3][8]

공식 설치 진입점은 다음과 같다.[3]

npx rea-agents@latest setup

setup은 연결할 에이전트를 선택하고 설정 변경 계획을 검토·승인하는 흐름이다.[3]
기존 설정의 백업을 만들며, 완료 후 대상 에이전트를 재시작하도록 안내한다.[3] npm의 패키지 다운로드 승인과 REA가 설정을 바꾸는 승인은 별개이고, Hopper 설치도 별도의 선택·승인 대상이다.[3]

지원 Node.js 범위는 22.x의 22.19 이상, 24.x의 24.11 이상, 또는 26 이상이다.[3]
개별 기능은 더 강한 runtime·provider 요구사항을 가질 수 있으므로, 지원 버전의 Node가 있다는 것과 원하는 분석 기능이 준비되었다는 것은 구별해야 한다.[3][8]
REA는 Ghidra나 Java를 자동으로 설치·업그레이드하지 않으며, 해당 경로는 사용자가 준비한 설치를 전제로 한다.[6]

공식 설치 안내에는 설정을 바꾸지 않고 계획만 보는 --dry-run 경로도 있다.[3]
처음에는 필요한 클라이언트와 분석 경로만 좁혀 계획을 검토하는 편이 낫다.
이 글의 내용은 공개 문서·릴리스 조사에 근거하며, 로컬 에이전트 설정 변경이나 REA 분석 엔진의 재현 실행 결과를 제시하는 것은 아니다.

보안 경계: 인증된 연결은 sandbox가 아니다

REA의 Hopper·Ghidra bridge는 세션별 capability token과 비공개 런타임 경로를 이용한다.[6]
그러나 공식 보안 문서는 이것이 sandbox가 아니며, 같은 OS 사용자 권한으로 실행되는 악성 프로세스를 막아 주지 않는다고 명시한다.[6]
신뢰하지 않는 바이너리를 여는 일은 선택한 분석 엔진에 그 사용자 권한으로 파일 해석을 맡기는 일이다.[6]

실행·브라우저 연결·네트워크 캡처·UI 조작은 정적 파일 열람보다 넓은 권한을 요구한다.[7]
대상 분석을 허가받았다고 해서 실행이나 외부 서비스 조작까지 자동으로 허가되는 것은 아니며, 로그·캡처·분석 산출물에 민감 정보가 포함될 수 있다.[6][7]
에이전트의 조사 환경과 대상 범위, 보존·공유할 자료를 먼저 정하는 것이 필요하다.

라이선스는 REA 자체 기준 MIT다.[9]
이 라이선스는 분석 대상의 코드·자산에 대한 복제 권리나 상용 분석 도구의 이용권을 주지 않는다.[7]
프로젝트 역시 무단 접근·인증 우회·라이선스 보호 우회·보호된 코드와 자산의 무단 복제를 지원하지 않는다고 명시한다.[7]

실무 관점에서의 해석

REA는 에이전트에게 “소스가 없는 앱도 대충 설명해 보라”고 시키는 대신, 구체적인 코드·참조·관찰 기록을 공급하는 조사 인터페이스로 보는 편이 정확하다.[1][4]
제품의 한 기능을 이해하거나, 소유한 패키지의 변경을 비교하거나, 호환성 조사에서 가설을 검증할 때 유용한 접근이다.[1][7]

다만 기능 목록의 폭과 분석의 완전성을 혼동하면 안 된다.
좋은 사용 흐름은 권한 있는 대상의 작은 질문 → 근거와 미확인 사항 확인 → 별도 동작 검증이다.
REA의 차별점은 모든 미지수를 없앤다는 약속보다, 미지수가 남아 있다는 사실을 에이전트의 다음 판단까지 가져가려는 설계에 있다.