REA 심층 분석: AI 에이전트는 앱을 어디까지 역공학할 수 있나

소스 없는 앱을 AI에게 설명시키려면

오래된 데스크톱 프로그램을 교체해야 하는데 소스가 없다. 사용자는 “월간 보고서를 내보내면 특정 열 순서와 서식이 유지된다”고 말한다. 화면만 비슷하게 만들면 끝일까? 실제 호환성을 맞추려면 버튼이 어떤 함수를 부르는지, 파일 처리는 어느 프로세스가 맡는지, 잘못된 입력에는 무엇을 반환하는지 알아야 한다.

코딩 에이전트에게 스크린샷과 추측만 주면 그럴듯한 구현을 만들 수는 있다. 하지만 기존 동작과 맞는지 판단할 재료가 부족하다. REA(Reverse Engineer Anything)는 그 조사 재료를 얻고 연결하는 문제에 접근한다. 대상에서 문자열·함수·호출 관계를 찾고, 필요하면 다른 분석 도구로 내려가며, 관측한 것과 아직 모르는 것을 함께 남긴다.

공식 저장소는 morluto/rea다. 2026년 10월 13일 20:08 KST 무렵 GitHub API에서 별 184,431개를 확인했다. 이는 그 시점의 관심 규모이며 사용자 수·분석 정확도·최근 증가율을 뜻하지 않는다. 이 글은 10월 11일 공개된 6.4.0, 커밋 a56f7bb668ab23fec8d33f7af353ac7ed2fe1895를 기준으로 한다. 계속 바뀌는 main의 기능을 이 버전에서 실행한 것처럼 섞지 않았다.

글의 질문은 “모든 앱을 복제할 수 있나”보다 구체적이다. 기존 역공학 도구에 무엇이 추가됐고, 그 결과를 어떤 조건에서 개발의 근거로 쓸 수 있을까? 이를 소스 구조, 직접 실행, 공식 사례 순서로 살펴본다.

REA와 Ghidra, MCP, 코딩 에이전트의 역할

역공학은 완성된 결과물에서 구조와 동작을 거슬러 알아내는 일이다. 네이티브 실행 파일에서는 기계어를 읽거나 C와 비슷한 의사 코드로 변환하는 디컴파일을 쓴다. Electron 앱에서는 배포물에 포함된 JavaScript와 프로세스 간 메시지 관계를 읽을 수 있다. 웹이나 실행 중인 프로그램에서는 네트워크·화면·출력 같은 관측도 조사 재료다.

REA는 이 작업들을 코딩 에이전트의 도구 호출과 연결한다. 6.4.0 아키텍처에서 CLI와 MCP 입구는 공통 애플리케이션 계층으로 이어지고, 실제 대상별 작업은 여러 provider가 맡는다. 여기서 provider는 REA가 사용할 분석 도구 또는 기능의 구현체다.

구성 요소	맡는 일	결과를 읽을 때 남는 질문
코딩 에이전트	질문을 좁히고 도구를 선택하며 결과로 후속 조사·코드 작성을 진행	선택한 경로와 해석이 맞는가?
MCP / CLI	에이전트 또는 터미널이 기능을 호출하는 접점	현재 연결에서 그 기능을 사용할 수 있는가?
REA	입력·세션·분석 흐름을 조정하고 관계·근거·한계를 구조화	어느 대상과 도구에서 얻은 결론인가?
Ghidra·Hopper·IDA 등	지원하는 네이티브 대상의 코드·참조·의사 코드 분석	해당 형식·아키텍처에서 얼마나 복원됐는가?
REA의 JavaScript 정적 분석	배포 파일을 읽고 구문·모듈·Electron 경계를 연결	동적 이름이나 실행 시 결정되는 경로는 무엇이 남는가?
개발자의 재구현·테스트	얻은 이해를 자기 제품의 코드와 동작 조건으로 바꿈	실제 입력과 실패 조건에서도 호환되는가?

따라서 REA를 써도 분석 엔진의 제약과 모델의 해석 오류는 남는다. 반대로 “Ghidra 호출 버튼만 붙였다”고 보기에도 부족하다. 서로 다른 관측을 같은 조사에서 재사용하고, 대상과 근거를 추적하며, 큰 결과 중 필요한 부분을 선택하는 일이 별도의 구현으로 들어 있기 때문이다.

이 역할 구분이 낯설다면 MCP와 API의 경계를 함께 보면 좋다. MCP는 연결 방식이고, REA는 그 연결 위에서 역공학 조사 기능을 제공하는 구체적인 프로그램이다.

코드에서 확인한 세 가지 설계

1. 결과에 “무엇을 보고 말하는가”를 붙인다

src/domain/evidence.ts의 Evidence에는 대상의 SHA-256, provider와 버전, 수행한 operation, 결과, 위치, 한계가 함께 들어간다. confidence는 observed, derived, inferred를 구분하고, authority는 배포 산출물·통제된 재실행·과거 참고 자료·분석자 추론 등의 출처를 구분한다.

이 설계가 필요한 상황은 단순하다. 어제 분석한 앱과 오늘 받은 업데이트의 이름은 같아도 바이트가 다를 수 있다. 예전 소스에서 찾은 함수와 현재 배포 파일에서 확인한 함수도 같은 근거로 취급할 수 없다. 대상 해시와 출처가 있어야 어느 결론을 이어 쓰고 무엇을 다시 조사할지 판단할 수 있다.

코드에는 Evidence의 의미 내용을 해시해 식별자를 계산하고, 읽을 때 그 식별자가 내용과 맞는지 검사하는 처리도 있다. 내용이 일관되게 보존됐다는 확인과 내용의 해석이 참이라는 확인은 다르다. 잘못된 추론도 일관된 기록으로 저장할 수 있다. Evidence는 판단의 출발점을 남기는 장치이지 정답 인증서가 아니다.

또한 바깥 Evidence의 confidence와 그래프의 개별 edge가 가진 근거 상태를 구분해야 한다. 파일에서 호출 구문을 관측했다는 사실 안에, 그 구문들 사이의 관계를 추론한 결과가 포함될 수 있다.

2. JavaScript는 텍스트를 읽고, 실행의 증거는 별도로 다룬다

JavaScriptApplicationService.ts는 입력 검증 뒤 배포물 재구성을 호출하고, 그래프를 검증한 다음 Evidence를 만든다. 별도의 분석 worker는 구문 분석 → 정적 사실 추출 → 의미 관계 분석 → 그래프 투영을 진행한다. Babel parser를 비롯한 기존 구성 요소가 이 경로에 쓰인다.

여기서 구문 트리(AST)는 소스의 문법 구조다. ipcRenderer.invoke('report:export', id)를 읽으면 호출 이름과 문자열 인자를 찾을 수 있다. 그러나 invoke(channel, id)에서 channel이 실행 중 무엇이 되는지는 더 많은 추론이나 실행 관측이 필요하다.

Application Graph 문서는 이 차이를 계약으로 명시한다. 정적 관계 추론과 수동적 실행 관측, 둘의 대응 추론이 서로 다른 출처를 유지한다. 그래프에서 경로를 찾았다는 것만으로 그 경로가 실제 실행됐다고 바뀌지 않는다.

큰 파일의 구문 분석은 별도 프로세스의 힙·시간 제한을 받는다. 정적 분석 문서에 설명된 이 경계는 자원 소진을 다루기 위한 것이다. 종료가 성공해도 미해결 항목이나 부분 결과를 읽어야 한다.

3. 분석 엔진을 몰래 바꿔 결과를 섞지 않는다

AnalysisProviderRegistry.ts는 네이티브 분석 provider의 지원 여부와 가용성을 확인하고 선택한다. 자동 선택에서 사용할 수 있는 후보가 여럿이면 명시적 선택을 요구한다. CLI 문서는 세션에 묶인 provider가 실패했다고 다른 도구로 조용히 전환하지 않는다고 설명한다.

편의성만 보면 “아무 도구로나 계속 진행”이 더 쉬워 보인다. 하지만 함수 경계나 의사 코드가 도구마다 달라질 수 있다. 어떤 결과에서 어떤 엔진을 썼는지 흐려지면 비교가 어려워진다. 명시적으로 멈추고 선택하게 하는 설계는 조사 이력을 읽을 수 있게 한다. 이는 소스와 문서에서 확인한 동작이며, 이번 글에서 네이티브 provider 장애를 직접 재현한 것은 아니다.

직접 실행: 보고서 내보내기 경로를 어디까지 찾을까

실습은 소유한 작은 입력으로 범위를 좁혔다. 테크독해가 만든 Electron 정적 분석용 fixture 두 개이며, 실제 보고서 프로그램이나 보안이 완성된 앱이 아니다. 두 입력 모두 main.cjs, preload.cjs, renderer.js, index.html, package.json으로 구성했다.

상황은 “내보내기 버튼에서 메인 프로세스의 처리기까지 어떻게 연결되는가”다. Electron의 renderer는 화면 쪽, main은 창과 시스템 기능 등을 담당하는 쪽이다. preload는 화면 코드에 제한된 API를 내놓는 연결 지점으로 사용할 수 있다. 여기서는 두 프로세스 사이의 IPC 메시지 채널을 조사한다.

직접 실행 범위: 2026-10-13, macOS 26.5.2 arm64, Node.js 22.23.1, npm 배포 REA 6.4.0의 CLI. REA를 실행해 파일을 정적으로 분석했다. Electron 앱·Ghidra·Hopper·IDA·모델 API는 실행하지 않았다. 따라서 AI 에이전트의 자율 조사 성공률이나 앱 복원 성능을 측정한 실험은 아니다.

채널명을 직접 쓴 경우와 인자로 넘긴 경우

첫 입력의 preload는 채널명을 직접 넣는다. main에는 ipcMain.handle('report:export', ...) 처리기가 있다.

// literal/preload.cjs
const { contextBridge, ipcRenderer } = require('electron');
contextBridge.exposeInMainWorld('reportApi', {
  exportCsv: (reportId) => ipcRenderer.invoke('report:export', reportId)
});

두 번째 입력은 채널명을 래퍼 함수의 인자로 받는다. 화면 코드는 window.reportApi.call('report:export', 'monthly')를 호출하도록 작성했다. 이 코드의 의도와 실제 앱 실행 결과는 구분한다.

// dynamic/preload.cjs
const { contextBridge, ipcRenderer } = require('electron');
contextBridge.exposeInMainWorld('reportApi', {
  call: (channel, reportId) => ipcRenderer.invoke(channel, reportId)
});

이 차이에 대해 REA가 반환한 값은 다음과 같다. paired_renderer_transmissions는 정적 분석에서 대응 처리기와 짝지어진 전송 수다.

관측 항목	literal 입력	dynamic 입력
읽은 관련 파일	5	5
파싱한 JavaScript 파일	3	3
파싱 실패	0	0
context bridge API	1	1
main 처리기	1	1
동적 채널 연산	0	1
짝지어진 renderer 전송	1	0
그래프 coverage	complete	partial

두 번째 결과에는 채널 표현식이 동적이어서 실행 중 값과 짝을 알 수 없다는 한계가 남았다. 짝 0개는 처리기가 없다는 뜻이 아니다. 같은 결과에서 main 처리기는 1개로 관측됐다. 이 버전의 분석이 두 지점을 연결하지 못했다는 뜻이다.

첫 결과의 complete도 모든 실행 동작을 검증했다는 뜻은 아니다. 그 결과 자체에 실행 시 등록·도달 가능성·강제 여부는 입증되지 않았다는 한계가 포함돼 있다. 이런 표기를 지우고 “앱 동작을 완전히 복원했다”고 요약하면, 도구가 남긴 가장 중요한 정보를 잃는다.

이 실험이 실무에서 바꾸는 다음 행동은 명확하다. literal 결과에서는 찾은 연결의 코드 위치부터 읽는다. dynamic 결과에서는 래퍼의 호출부와 실제 전달값을 추가 조사한다. 필요하면 허용된 실행 환경에서 해당 동작만 관측한다. 분석이 실패한 자리를 모델의 자신감으로 메우지 않는다.

직접 반복할 수 있는 실행 자료

REA 정적 분석 비교 예제 ZIP에는 두 입력, verify.py, 설명서, 선택한 관측값이 들어 있다. 자체 제작한 파일만 포함하며 REA나 상용 앱 배포물은 넣지 않았다. 예제는 송신자·입력 검증을 생략한 조사 입력이므로 제품 코드로 가져다 쓰는 용도가 아니다.

압축을 푼 폴더에서 아래 명령을 실행한다. 실제로 확인한 재현 명령이며 도구를 해당 폴더에 설치한다. 전역 설치나 REA setup은 필요 없다.

npm install --prefix .rea-tool --ignore-scripts --no-audit --no-fund \
  --save-exact rea-agents@6.4.0
python3 verify.py

배포판의 Node 요구 범위는 ^22.19.0 || ^24.11.0 || >=26.0.0이고, 스크립트에는 Python 3도 필요하다. 검증기는 REA 버전과 위 표의 핵심 관측, 입력 파일의 전후 해시, 없는 경로의 exit 1 / invalid_request를 확인한다. 운영체제 전체의 파일 쓰기나 보안을 감시하는 테스트는 아니다.

원본 Evidence는 results/에 남는다. 로컬 경로도 들어 있으므로 그대로 공개하기 전에 확인한다. 글에서 제시한 선택 관측은 공개 실행 요약 JSON으로 따로 볼 수 있다. 이 요약은 읽기 위한 발췌이며 원본 Evidence를 대체하거나 REA에 다시 입력할 수 있는 인증된 번들이 아니다.

결과를 전부 모델에 넣는 것도 비용이다

직접 만든 literal 입력은 관련 텍스트가 1,172바이트였지만 첫 실행의 Evidence JSON은 262,142바이트였다. inspect-analysis-view로 얻은 요약 뷰는 11,237바이트였다. 절대 크기는 출력 형식·경로·버전에 따라 달라질 수 있으며, 이 수치는 토큰 사용량이나 모델 비용 측정이 아니다.

작은 입력에 비해 결과가 커지는 이유는 원문만 돌려주는 것이 아니기 때문이다. 노드, 관계, 위치, 식별자, 의미 그래프와 근거가 함께 들어간다. 이 구조는 나중에 비교하고 추적하는 데 도움이 되지만, 한 번의 모델 문맥에 모두 넣을 이유는 없다.

CLI의 저장·조회 방식에 따라 원본을 파일에 보존한 뒤 요약 → 관련 모듈 → 필요한 위치 순서로 좁힐 수 있다. 이번 예제의 검증기도 원본 Evidence를 저장한 뒤 같은 자료에서 요약 뷰를 생성했다. 이때 요약은 조사 경로를 정하는 입구이고, 최종 판단에 필요한 한계·코드 위치까지 생략해도 된다는 뜻은 아니다.

이는 필자의 도입 판단이다. REA의 가치는 가져온 정보량보다 “다음에 무엇을 더 확인할지 고르는 비용을 줄이는가”로 평가하는 편이 좋다. 같은 질문을 해결하는 데 반복 호출, 사람이 읽은 코드, 남은 불확실성이 얼마나 생기는지를 함께 기록해야 한다. 이번 작은 CLI 실험만으로 시간 절감률을 제시할 수는 없다.

공식 사례도 성공 범위를 잘라 읽어야 한다

Notion: 동적 래퍼가 남긴 빈칸

공식 Notion 사례의 근거 기록은 Notion Desktop 7.6.1의 preload를 REA 4.1.0으로 조사한 결과를 설명한다. API 노출과 IPC 호출 위치는 찾았지만 동적 래퍼 때문에 해당 채널을 완전한 경로로 연결하지 못했다. 공개된 그림의 연결에는 배포 코드의 별도 읽기가 포함돼 있다.

또 웹 에디터 쪽 분석에는 다른 시점의 캐시와 스텁 환경의 과거 검사가 사용됐다. 같은 버전의 데스크톱 앱에서 실제 복사·붙여넣기를 끝까지 실행한 기록으로 합쳐 읽으면 안 된다. 이것은 공식 사례를 분석한 것이며 테크독해가 Notion을 직접 역공학한 결과가 아니다.

우리의 작은 실험과 연결되는 지점은 “정적 그래프가 놓친 경로를 어떻게 이어 조사할 것인가”다. 실험 입력이 실제 Notion 구조를 재현했다거나 최신 REA도 같은 결과를 낸다는 뜻은 아니다.

DX-Ball: 한 함수의 복원과 전체 게임은 다르다

공식 DX-Ball 기록은 소리의 좌우 위치를 계산하는 한 함수에 집중한다. 의사 코드에서 빠진 입력과 연산을 명령어·호출부·상수로 보완하고, 원래 x86 실행과 재구현을 비교했다는 자료다.

기록된 검증은 위치 0~640과 다섯 배율 조합, 3,205개 입력 및 해당 함수의 63바이트 컴파일 결과 일치다. 이 범위를 전체 게임 복원이나 모든 바이너리에 대한 정확도로 확대할 수 없다. 테크독해는 이 원본 실행·과거 컴파일러 검사를 재수행하지 않았다.

이 사례에서 참고할 것은 큰 성공 숫자보다 검증의 구성이다. “그럴듯한 C 코드가 나왔다”에서 멈추지 않고, 어느 입력과 어느 함수에서 일치하는지 좁혀 확인했다. 재구현에 사용할 결론은 이런 단위로 검증해야 한다.

설치보다 먼저 정할 도입 범위

REA를 에이전트에 연결하려면 공식 setup 절차를 따른다. npx rea-agents@6.4.0 setup은 이 글의 버전에 맞춘 미실행 설정 예시다. 선택한 에이전트의 MCP 등록과 대응 작업 지침을 설정하며, 변경 경로를 보여 주고 확인을 받는다. 설정 후에는 해당 에이전트를 재시작한다.

필요한 도구는 대상마다 다르다. 우리가 실행한 JavaScript 정적 분석에는 네이티브 분석 엔진이 필요 없었다. 네이티브 코드는 지원 형식과 호스트를 확인하고 Ghidra·Hopper·IDA 등의 별도 환경을 준비해야 한다. 엔진을 선택하는 명령과 에이전트가 질문을 풀어 가는 능력은 별개다. 공개 REA 코드의 라이선스가 외부 도구나 분석 대상의 사용 권한까지 제공하지도 않는다.

정보가 이동하는 경계도 구분한다. 공식 README가 설명하듯 REA의 대상 분석은 로컬에서 이루어지지만, 에이전트가 결과를 모델에 전달하면 그 데이터는 모델 제공자의 처리 경로에 들어갈 수 있다. 로컬 분석 도구를 쓴다는 사실만으로 전체 조사가 오프라인이 되지는 않는다. 이 글의 CLI 실험에는 모델 호출이 없었다.

REA 보안 문서는 provider 연결 보호가 샌드박스는 아니라고 명시한다. 실행 파일을 열어 분석하는 엔진은 사용자의 권한으로 그 파일을 처리한다. 프로세스 실행·브라우저 상호작용 같은 기능은 정적 읽기와 효과가 다르다. 회사의 비공개 파일을 다룬다면 대상과 모델로 보내도 되는 출력 범위를 먼저 정하는 것이 실제 작업 설계다.

어떤 업무에서 먼저 써볼 만한가

다음은 제품의 성능 보증이 아니라, 이번 코드 분석과 실행에서 도출한 적용 기준이다.

독자 상황	첫 조사 질문	재사용 가능한 결과	별도로 확인할 것
소스가 없는 내부 Electron 앱 교체	내보내기 요청은 어느 IPC와 처리기로 가는가?	코드 위치·프로세스 경계·미해결 래퍼 목록	입력 검증, 파일 결과, 오류·취소 동작
오래된 네이티브 계산 기능 이식	특정 입력을 받아 어떤 계산을 하는가?	함수·호출부·상수·의사 코드의 근거 묶음	원본과 재구현의 차등 테스트, 경계값
앱 업데이트 전후 호환성 조사	연동에 쓰는 특정 경로가 바뀌었는가?	버전·대상 해시가 붙은 비교 근거	누락과 실제 삭제의 구분, 해당 버전 실행
처음 보는 앱의 기능 파악	화면의 한 기능이 어느 구성 요소에 걸치는가?	조사할 파일·엔진·실행 관측의 우선순위	서버 쪽 로직·계정 상태 등 배포물 밖의 부분

소스와 테스트가 이미 충분한 프로젝트라면 코드 검색과 기존 디버거로 바로 답을 얻는 편이 빠를 수 있다. 서비스의 핵심 동작이 원격 서버에만 있다면 클라이언트 파일 분석으로 그 구현을 복원할 수 없다. “이 앱 전체를 똑같이 만들어 줘”처럼 완료 조건이 없는 요청은 조사 범위와 확인 비용부터 커진다.

처음 적용할 때는 아래처럼 하나의 기능과 완료 조건을 함께 적어 볼 수 있다. 이는 이 글의 미실행 요청 템플릿이다.

대상: 내가 소유하거나 분석이 허용된 앱의 특정 버전
질문: 보고서 내보내기 버튼에서 파일 생성까지의 경로를 설명해 줘.
시작: 배포 파일을 정적으로 조사하고 대상 해시와 코드 위치를 남겨 줘.
구분: 직접 관측한 사실, 관계 추론, 미해결 동적 경로를 나눠 줘.
다음: 실행 관측이 필요하면 대상·행동·부작용을 먼저 제시해 줘.
완료: 내보내기 형식과 실패 조건의 근거를 정리하고,
      내 제품에 구현할 부분과 별도 검증할 입력을 제안해 줘.

REA가 바꾸는 것은 조사와 개발의 연결

REA가 주목받는 이유를 기술적으로 해석하면, 코딩 에이전트가 다룰 수 있는 입력이 소스 저장소에서 배포물과 실행 관측으로 넓어진다는 점이다. “무엇을 만드는가”에 앞서 “이미 있는 프로그램은 어떤 근거로 그렇게 동작한다고 말할 수 있는가”를 같은 작업 흐름에 넣는다. 이것은 필자의 분석이며 별 수가 그 생산성 효과를 입증하는 것은 아니다.

직접 실행한 결과는 이 가능성과 남는 작업을 함께 보여 줬다. 단순한 연결은 찾았고, 동적 인자 전달은 부분 결과로 남았다. 유용한 다음 단계는 그 빈칸을 숨기는 일이 아니라 어디를 추가 조사할지 정하는 일이다. 이후 재구현이 원본과 맞는지는 실제 입력·오류·경계값에서 확인해야 한다.

REA를 도입한다면 첫 목표를 “앱 복제”보다 한 기능에 대해 검토 가능한 설명과 재현 조건을 얻기로 잡는 편이 낫다. 그렇게 얻은 자료를 개발에 쓰고, 해결한 질문과 남은 질문을 다음 세션으로 넘긴다. 그 인수인계 방식은 Claude Code Mods의 실무 사례, 도입 효과의 평가는 에이전트의 완료 비용 비교와 이어서 볼 수 있다.