REA 사용 가이드: 로컬 앱의 구조를 읽고 근거로 설명하기

앱의 기능을 이해할 때 가장 중요한 것은 그럴듯한 설명보다 어느 파일의 어떤 근거로 내린 결론인지, 무엇을 아직 모르는지 구분하는 일이다. REA는 AI 에이전트와 로컬 분석 도구 사이를 연결하는 MCP 도구다. 작은 소유 예제로 정적 분석부터 시작해 보자.

어떤 REA인가

이 글은 morluto/rea의 REA: Reverse Engineer Anything을 다룬다. 공식 배포 경로는 GitHub 저장소, rea.tools, npm의 rea-agents다. 동명의 Reverse Engineering Assistant나 유사 다운로드 저장소와는 다르다. 2026년 10월 15일 확인한 npm 최신판은 6.5.0이다. main 문서는 배포판보다 앞설 수 있으므로 버전과 도움말을 함께 확인한다.

아래는 공식 README·설치·CLI 문서를 대조한 예제다. 이 글을 위해 REA를 설치하거나 분석 명령을 실제 실행하지 않았으며, 실제 분석 결과나 측정 수치를 재현했다고 주장하지 않는다.

먼저 정할 경계

자신이 작성했거나 분석 허가를 받은 로컬 자료만 사용한다. 이번 실습은 직접 만드는 JavaScript 두 파일이며 악성 샘플이나 타사 앱 실행은 포함하지 않는다. 정적 분석은 파일을 읽는 작업이고 런타임 캡처는 대상 프로그램을 사용자 권한으로 실행하거나 상호작용하는 작업이다. 두 가지를 같은 안전 수준으로 취급하면 안 된다.

정적으로 연결된 경로가 실제 실행됐다는 뜻은 아니다. 복원 코드는 원본 소스와 같다고 보장되지 않으며, 재구현 시에도 라이선스·저작권·계약과 접근 권한을 검토해야 한다.

환경과 설치

Node.js 22.19 이상인 22.x, 24.11 이상인 24.x 또는 26 이상과 npm이 필요하다. 임의의 모든 중간 Node 메이저 버전을 지원한다는 뜻은 아니다. 정적 JavaScript 분석에는 Hopper·Ghidra·IDA가 필요 없다. Linux에서는 프로세스 소유권 확인을 위한 procps 호환 ps가 PATH에 있어야 한다. 네이티브 바이너리 심층 분석의 별도 엔진·호스트 조건은 이번 실습에서 제외한다.

node --version
npm --version
npm view [email protected] version engines repository.url
npm install --global [email protected]
rea --help

마지막 명령에서 명령 목록이 나오면 CLI를 찾은 것이다. 전역 설치 권한 오류가 나면 무조건 관리자 권한으로 재시도하지 말고 사용자 소유 Node 설치나 아래 일회성 실행을 선택한다.

npx -y [email protected] --help

-y는 npm의 패키지 실행 확인을 생략한다. 패키지 이름·저장소·버전을 먼저 검토하자. npx는 전역 설치를 피할 뿐 다운로드나 npm 캐시 사용을 없애지는 않는다.

최소 분석 실습

다음은 macOS·Linux POSIX 셸 예제다. Windows PowerShell에서는 같은 파일을 직접 만들고 해당 환경의 절대 경로로 분석한다. 이 파일은 분석 대상으로만 만들며 실행하지 않는다.

mkdir -p rea-demo/app
cd rea-demo
cat > app/search.js <<'EOF'
export function searchNotes(notes, query) {
  const term = query.trim().toLowerCase();
  return notes.filter(note => note.title.toLowerCase().includes(term));
}
EOF
cat > app/main.js <<'EOF'
import { searchNotes } from "./search.js";
export function findTitles(notes, query) {
  return searchNotes(notes, query).map(note => note.title);
}
EOF
rea analyze-javascript-application "$PWD/app" --json > app-evidence.json

대상은 app 디렉터리이고 결과는 그 바깥 app-evidence.json에 저장한다. 결과 파일을 다시 입력으로 읽는 혼선을 피하기 위해서다. 실제 앱에서는 "$PWD/app"을 허가받은 추출 디렉터리 또는 ASAR의 절대 경로로 바꾸고 공백이 있으면 따옴표를 유지한다.

--json은 REA의 출력 표현을 JSON으로 선택한다. >는 셸의 파일 저장 문법이며 기존 파일을 덮어쓴다. 정적 JavaScript 명령은 Application Graph와 Evidence를 반환한다. 종료 상태와 파일 내용 모두로 성공을 판단하고 비어 있거나 오류만 담긴 파일을 성공 보고서로 취급하지 않는다.

큰 결과는 요약부터

실제 앱의 Evidence는 수백 MB에 이를 수 있다. 전체를 채팅에 붙이는 대신 요약 뷰를 만든다. 다음은 공식 CLI 문서의 저장·투영 방식이며 별도 도구 jq가 필요하다. jq --version이 실패하면 운영체제의 공식 패키지 경로로 먼저 설치한다.

jq --version
jq -e . app-evidence.json > /dev/null
jq -c '{source: {kind: "inline", evidence: .}, view: {kind: "summary"}}' app-evidence.json > app-view.json
rea inspect-analysis-view app-view.json > app-summary.txt

jq -e .는 JSON 문법을 확인할 뿐 분석 완전성을 증명하지 않는다. source.kind의 inline은 저장한 Evidence를 요청 안에 넣는 방식이고 view.kind의 summary는 요약을 선택한다. 새로운 파일 분석이나 프로그램 실행이 아니다. 추가 모듈 페이지는 다음처럼 조회한다.

jq -c '{source: {kind: "inline", evidence: .}, view: {kind: "page", collection: "modules", offset: 0, limit: 32}}' app-evidence.json > modules-view.json
rea inspect-analysis-view modules-view.json > modules-page.txt

offset과 limit은 저장된 모듈 목록의 페이지 범위다. 분석 정확도나 관계 추적 깊이를 조정하는 옵션이 아니다. 다른 trace 명령에도 같은 옵션이 있다고 추측해 붙이지 않는다.

결과를 읽는 순서

먼저 입력과 분석 범위가 맞는지 확인한다. 모듈·import 관계에서 main.js와 search.js, 두 파일 사이 연결을 찾는다. 이번 예제의 설명 기준은 findTitles가 searchNotes를 사용하고 검색어를 trim·소문자화한 뒤 제목을 필터링한다는 소스 사실이다. 이는 위 예제 코드의 해설이며 REA 실제 출력 인용이 아니다.

이후 각 결론에 붙은 근거 위치와 authority, coverage, unknown 또는 limitations를 읽는다. 원시 필드 이름·중첩 구조는 버전별 Evidence 계약을 따른다. 존재하지 않는 필드를 가정한 추출 스크립트보다 공식 요약 뷰부터 쓰는 편이 안전하다.

호출 대상이 정적으로 하나로 식별돼도 해당 경로가 실행됐다는 뜻은 아니다. 동적 import나 계산된 속성처럼 해석할 수 없는 부분은 미확인으로 남는다. 관계가 보이지 않는다는 이유로 기능이 없다고 결론 내리지 말자. 재구현 후에는 별도의 입력·출력 테스트로 동작을 검증한다.

에이전트에 연결

필요할 때만 MCP 연결을 진행한다. 이 단계는 에이전트 설정과 REA 워크플로 지침을 바꾸므로 제안된 변경 내용을 읽고 승인한다. 기존 설정 백업이 모든 충돌의 자동 해결을 뜻하지는 않는다.

npx [email protected] setup

지원 클라이언트를 선택하고 반영한 뒤 에이전트를 다시 시작한다. 다음처럼 범위와 중단 조건을 전달하자.

내가 작성한 rea-demo/app만 정적으로 분석해 줘.
findTitles에서 searchNotes로 이어지는 관계와 검색어 정규화 과정을
파일 위치와 근거로 설명해 줘. 앱 실행, 브라우저 열기, 외부 전송은
추가 승인 없이 하지 말고, 확정할 수 없는 관계는 미확인으로 남겨 줘.

프롬프트는 접근통제 장치의 대체물이 아니다. 에이전트의 도구 권한·승인 정책도 제한해야 한다. 네이티브 분석이 필요해질 때만 공식 provider 문서에 따라 엔진을 준비하고 라이선스·지원 호스트를 확인한다.

비용과 데이터

REA 자체는 MIT 라이선스지만 모델 API·구독료와 상용 분석 엔진 비용은 별개다. 정적 JavaScript 실습에는 네이티브 엔진이 필요 없다. npm 설치·npx 실행에는 패키지 다운로드를 위한 네트워크 접근이 있을 수 있다.

로컬 분석이라는 말은 에이전트가 읽은 코드·문자열·결과가 외부 모델로 절대 전달되지 않는다는 뜻이 아니다. MCP 응답을 모델에 보내는지는 클라이언트·공급자 설정에 달려 있다. 비밀키·개인정보·고객 코드는 제외하고 반출 금지 자료에는 승인된 로컬 모델 경로를 별도로 마련한다. Evidence 자체에도 원문 일부나 민감 문자열이 담길 수 있으므로 접근 권한·보관기간·삭제 정책을 정한다.

오류를 좁히는 법

• Node 엔진 오류: node --version과 지원 범위를 비교한다. 같은 메이저라도 최소 버전보다 낮으면 지원 밖이다.
• rea를 못 찾음: 전역 npm 실행 경로와 PATH를 확인하거나 버전 고정 npx 방식을 쓴다.
• Linux 프로세스 검사 실패: command -v ps와 procps 호환 여부·PATH를 점검한다. 대상 앱 실행으로 해결하려 하지 않는다.
• 결과가 너무 큼: 원본을 파일로 보존하고 summary 또는 modules 페이지로 투영한다.
• MCP 도구가 안 보임: setup에서 선택한 클라이언트를 확인하고 다시 시작한다. rea doctor --json은 읽기 전용 진단이다.
• 문서 명령이 없음: 설치 버전의 rea --help와 npm 버전을 확인한다. main에만 추가된 기능이면 릴리스 여부부터 확인한다.
• unknown이 많음: 동적 관계·난독화·누락 자료 때문일 수 있다. 자동으로 실행이나 추가 권한을 허용하지 않는다.

제거와 되돌리기

등록했다면 먼저 REA 소유 등록·스킬을 제거한다. 필요한 경우에만 캐시·상태도 삭제하고, purging 전 보관할 자료를 확인한다.

rea uninstall
# REA 캐시와 상태도 지울 때만 선택
rea uninstall --purge-data
npm uninstall --global rea-agents

rea uninstall은 다른 MCP 서버나 Hopper·Node.js를 제거하지 않는다. Evidence·캡처 파일도 자동 삭제하지 않으므로 실습 디렉터리는 내용을 확인한 뒤 별도로 정리한다. npx만 썼다면 전역 패키지 제거는 필요 없다. 다른 클라이언트 등록까지 영향을 줄 수 있는 범위를 고려하고, 설정 충돌은 백업과 현재 설정을 비교해 REA 관련 변경만 되돌린다.

REA의 가치는 조사 질문을 로컬 자료·분석 근거·미확인 사항으로 쪼개는 데 있다. 작은 소유 예제로 결과 읽기를 익힌 뒤 권한과 데이터 경계를 확인하며 범위를 넓히자.

출처