REA 설치·사용법: Claude Code로 리버스 엔지니어링하기

소스코드가 없는 앱도 AI에게 “이 기능은 어떻게 돌아가?”라고 물어볼 수 있을까요? REA(Reverse Engineer Anything)는 Claude Code 같은 코딩 에이전트에 프로그램 분석 도구를 연결해 주는 오픈소스입니다. 배포된 앱, 실행 파일, 웹페이지에서 단서를 찾고, 기능이 작동하는 이유를 코드와 근거로 설명하도록 돕습니다.

공룡 게임의 속도 증가, Notion의 클립보드 복사, CTF 프로그램의 정답 검사는 서로 다른 분석 방법을 보여줍니다. 이 글에서는 REA 프로젝트가 공개한 세 사례의 원문과 검증 기록을 살펴보고, 직접 따라 할 설치 방법과 실습까지 연결합니다.

REA란 무엇인가요?

REA는 AI 모델이 아니라, 코딩 에이전트가 리버스 엔지니어링 도구를 사용할 수 있게 해 주는 MCP 서버이자 CLI입니다. 리버스 엔지니어링은 완성된 프로그램을 관찰하고 분석해 내부 구조와 작동 규칙을 알아내는 작업입니다. REA 공식 저장소

MCP는 AI가 외부 도구를 호출하는 연결 규격입니다. Claude Code가 질문을 해석하고, REA가 분석 도구를 통해 자료를 얻으면, Claude Code가 그 자료를 읽어 다음 조사와 설명을 이어갑니다. Claude Code의 MCP 공식 문서

예를 들어 “이 앱의 내보내기 버튼을 분석해 줘”라고 요청하면, 버튼이 부르는 함수와 전달되는 메시지, 파일을 쓰는 지점을 차례로 확인할 수 있습니다. 중요한 것은 답변이 그럴듯한지가 아니라 어느 파일의 어떤 코드가 그 설명을 뒷받침하는지입니다.

REA는 왜 필요한가요?

REA가 유용한 순간은 눈에 보이는 동작과 내부 구현을 연결해야 할 때입니다. 이런 작업에서 시작점을 찾는 데 활용할 수 있습니다.

반대로 내가 만든 작은 함수의 원본 소스가 이미 있고 질문도 명확하다면, 그 코드를 바로 읽는 편이 간단할 수 있습니다. REA의 가치는 앱의 여러 파일이나 프로세스에 흩어진 단서를 연결할 때 커집니다.

소스코드를 숨기면 이제 소용없다는 뜻인가요?

배포한 프로그램의 동작을 분석할 수 있다는 뜻이지, 모든 앱의 원본 소스가 완벽하게 복원된다는 뜻은 아닙니다. 네이티브 분석으로 얻는 어셈블리와 의사코드는 개발자가 작성했던 변수명·주석·프로젝트 구조와 다를 수 있습니다. 서버에만 있는 구현은 클라이언트 파일을 읽는 것만으로 확보할 수 없습니다.

따라서 개발자가 얻을 교훈은 “코드를 안 보이게 했으니 안전하다”는 가정에 기대지 않는 것입니다. 웹서비스의 권한 검사는 신뢰할 수 있는 서버에서 수행하고, 요청마다 검증해야 합니다. OWASP 권한 검증 가이드

REA로 무엇을 분석할 수 있나요?

분석 대상에 따라 준비물이 달라집니다. 처음에는 별도 네이티브 분석 도구가 필요 없는 JavaScript 예제로 시작하는 편이 좋습니다.

ASAR는 Electron 앱의 여러 파일을 담은 묶음입니다. “Notion 같은 앱은 바로 된다”는 말은 패키지에 들어 있는 JavaScript를 정적으로 읽을 때 별도 네이티브 엔진이 필요 없다는 의미로 이해하면 정확합니다. 네이티브 모듈이나 실행 중 동작까지 보려면 추가 준비가 필요합니다. REA 분석 대상과 요구사항, 분석 엔진이 필요한 경우

공식 사례 1: 공룡 게임은 왜 달릴수록 빨라지나요?

공식 실험에서는 속도를 6으로 설정한 뒤, 충돌 없는 업데이트에서 속도가 13 미만이면 0.001을 더했습니다. REA가 분석한 대상은 Chrome 내장 chrome://dino가 아니라, wayou가 공개한 Chromium 기반 웹 버전입니다. 로컬 디버깅 연결로 그 페이지에 로드된 index.js와 설정값을 읽었습니다. 코드의 기본 속도도 6입니다. REA 공룡 게임 사례, 분석 대상의 원본 코드

여기서 “업데이트 한 번”은 게임의 상태를 계산하는 한 번의 호출입니다. 1초나 점수 1점을 뜻하지 않습니다.

공식 팀은 별도 브라우저 제어로 장애물 생성과 자동 업데이트 예약을 끄고, 원래 게임의 업데이트 함수를 반복 호출했습니다. 상세 기록은 다음과 같습니다.

쇼츠의 “10,000번이면 13”은 소수 첫째 자리로 반올림한 설명입니다. 실제 기록은 약 13.000999999997896입니다. 더하기 전에 한도를 검사하고 소수 계산 오차도 누적되므로, 정확히 13으로 값을 고정하는 코드와는 다릅니다. 공식 실험 조건과 원시 수치

아래는 이 규칙만 따로 확인하는 학습용 코드입니다. speed-check.cjs로 저장하세요. 원래 게임 전체를 실행하는 코드는 아닙니다.

function replaySpeed(updateCount) {
  let value = 6;
  for (let step = 0; step < updateCount; step += 1) {
    if (value < 13) value += 0.001;
  }
  return value;
}

for (const count of [0, 1000, 4000, 7000, 10000]) {
  console.log(`${count}회: ${replaySpeed(count).toFixed(3)}`);
}

터미널에서 실행하면 위 표와 같은 결과를 확인할 수 있습니다.

node speed-check.cjs

이 사례에서 배울 점은 상수만 찾지 말고, 언제 더하는지와 어디서 멈추는지까지 확인해야 한다는 것입니다.

공식 사례 2: Notion에서 복사한 글은 어떻게 클립보드로 가나요?

REA 팀이 분석한 Windows용 Notion Desktop 7.6.1 코드에서는 앱이 화면에 노출한 API가 IPC 요청을 보내고, 메인 프로세스가 보낸 쪽을 검사한 뒤 시스템 클립보드에 씁니다. IPC는 서로 다른 프로세스가 메시지를 주고받는 방식입니다. 이는 해당 배포물에서 확인한 경로이며, 이후 모든 Notion 버전의 구현을 보장하지는 않습니다.

분석 기록에서 연결한 경로를 간단히 그리면 다음과 같습니다.

페이지에서 앱의 clipboard.write API 호출
  → preload의 ipcRenderer.invoke
  → notion:clipboard:write 채널
  → 메인 프로세스의 ipcMain.handle
  → isNotionWebContents로 보낸 쪽 검사
  → Electron clipboard.write(data)

이 경로의 clipboard.write는 앱이 노출한 API를 가리키며, 웹 표준 navigator.clipboard.write()와 구분해야 합니다. preload는 웹 화면과 데스크톱 앱의 기능을 연결하는 중간 코드입니다. 압축된 코드에서도 API가 노출되는 위치와 메시지를 보내는 위치를 찾으면, 이어서 읽을 범위를 좁힐 수 있습니다. REA Notion 사례

다만 이 사례를 “REA가 실행 중인 Notion의 복사 과정을 모두 자동 추적했다”고 설명하면 범위를 넘습니다. 공식 기록상 REA가 먼저 찾아낸 것은 정적 코드의 API·IPC 위치입니다. 실제 채널명과 수신 함수를 연결하는 데에는 래퍼 코드를 추가로 읽는 과정이 있었고, 데스크톱 화면의 복사 동작을 실시간으로 녹화한 결과는 아닙니다. Notion 사례의 검증 범위

개발자에게는 좋은 설계 학습 자료이기도 합니다. “메시지를 받았다”와 “그 요청을 처리해도 된다”는 별개이기 때문입니다. Electron도 IPC 메시지를 처리할 때 보낸 쪽을 검증하라고 안내합니다. 이 경로가 발견됐다는 사실만으로 앱 전체가 안전하다고 결론 내릴 수는 없습니다. Electron 보안 가이드

공식 사례 3: 함수 이름이 없는 CTF 프로그램은 어떻게 풀었나요?

DownUnderCTF 2023의 masked squares flag checker는 입력 36개의 문자 코드를 정해진 방식으로 더하고, 26개의 목표값과 비교하는 문제입니다. REA 사례는 함수 이름이 제거된 Linux x86-64 실행 파일을 Ghidra로 분석했습니다.

조사는 화면에 출력할 문자열에서 시작합니다. What is the flag?를 찾고, 그 문자열을 참조하는 코드로 이동한 다음, 입력 검사 함수와 보조 함수를 읽습니다. 여기서 xref는 특정 문자열이나 주소를 참조하는 코드 위치를 뜻합니다. REA CTF 사례

검사 규칙은 다음처럼 이해할 수 있습니다.

입력 36개를 6×6 칸에 배치
각 검사에서 마스크가 지정한 칸만 선택
선택한 문자의 숫자 코드를 합산
저장된 목표값과 비교
이 과정을 26개 검사에 적용

REA가 읽어 온 검사식에 DUCTF{...} 형식과 허용 문자에 대한 분석자의 가정을 더하고, Z3라는 제약식 해결 도구로 후보를 구했습니다. 그 후보를 원래 프로그램에 넣자 Correct!가 나왔고, 선택된 문자 하나를 바꾼 입력은 Incorrect!가 나왔습니다. 주최 측 소스와 정답은 그 뒤에 대조했습니다. 상세 증거 기록, DownUnderCTF 원본 검사 코드

여기서 확인한 것은 통과하는 후보를 찾았다는 사실입니다. 모든 프로그램을 자동으로 풀 수 있다는 증거나, 이 조건의 해가 유일하다는 증명은 아닙니다.

더 공부하고 싶다면 공식 전체 풀이 스크립트를 확인하세요. 원본 실행 파일을 직접 실행하려면 Linux x86-64 환경이 필요합니다. 입문 실습은 아래 Notes 예제가 더 간단합니다.

REA를 Claude Code에 설치하는 방법

Node.js와 npm을 준비한 뒤 setup을 실행하고, Claude Code 연결을 승인한 다음 세션을 다시 시작합니다. 설치 과정은 MCP 연결과 조사용 스킬을 함께 구성합니다. 공식 패키지 이름은 rea-agents입니다. REA 설치 가이드

node -v
npm -v

npx rea-agents@latest setup --client claude_code

npx rea-agents@latest setup --client claude_code --dry-run

npx -y rea-agents@latest doctor --client claude_code --json

REA 연결을 확인해 줘.
현재 사용할 수 있는 REA 도구와 필요한 추가 준비물을 알려줘.
분석 대상은 로컬 JavaScript 폴더로 시작할 거야.

Windows PowerShell에서 실행 정책 오류가 나오면 npx 대신 npx.cmd로 같은 명령을 실행해 보세요. REA Windows 설치 안내

첫 실습: Notes 앱의 CSV 내보내기 분석하기

처음부터 큰 상용 앱을 조사하면 결과를 검증하기 어렵습니다. 파일 6개짜리 공식 Notes 예제로 “어느 코드가 어느 코드로 연결되는가”를 먼저 확인해 보세요. 정적 분석에는 Electron 설치나 앱 실행이 필요 없습니다. 공식 JavaScript·Electron 실습

이 예제는 연결 구조를 배우기 위한 최소 코드입니다. main.js의 IPC 처리 함수에는 요청을 보낸 쪽의 검증이 없으므로, 실제 서비스 코드에 적용할 때는 앞서 본 Electron 보안 지침을 함께 반영해야 합니다.

1. 예제 폴더 준비하기

Notes 예제 ZIP을 내려받아 압축을 풉니다. 다운로드가 어려우면 공식 저장소의 예제 파일 6개를 같은 폴더에 저장해도 됩니다.

notes-example/
  package.json
  index.html
  renderer.js
  preload.js
  main.js
  csv.js

2. Claude Code에 기능 하나만 질문하기

아래 경로를 자신의 예제 폴더 전체 경로로 바꿔서 복사하세요.

REA로 /내/전체/경로/notes-example 폴더를 정적 분석해 줘.
질문은 하나야. Export notes 버튼을 누르면 CSV가 어디에서 만들어지고 저장돼?

다음 순서로 답해 줘.
1. 버튼 → 페이지 API → IPC 채널 → 처리 함수 → CSV 생성 함수
2. 각 단계의 파일명과 줄 번호
3. CSV 열 이름과 저장 위치
4. 코드에서 확인한 사실, 추론한 연결, 아직 모르는 점

앱을 실행하지 말고 먼저 소스 근거로 설명해 줘.
동적 확인이 필요한 부분은 이유와 확인 방법을 제안해 줘.

정상적으로 조사했다면 notes.exportCsv(), notes:export, main.js, csv.js를 연결하고, Downloads 폴더의 notes.csv에 id와 title을 쓴다는 설명이 나와야 합니다.

3. CLI 결과와 비교하기

AI의 설명과 별개로, REA가 반환한 자료를 파일로 남길 수도 있습니다. 아래 예시는 터미널에서 실행하며, 경로는 실제 값으로 바꾸세요.

npx -y rea-agents@6.5.0 analyze-javascript-application "/내/전체/경로/notes-example" --json > rea-result.json

이 글을 준비하면서 공식 저장소의 예제 파일을 REA 6.5.0으로 분석했습니다. normalized_result.summary.ipc에서 다음 값을 확인했습니다.

{
  "literal_channels": 1,
  "renderer_transmissions": 1,
  "main_handlers": 1,
  "paired_renderer_transmissions": 1,
  "ambiguous_renderer_transmissions": 0
}

뜻은 명확한 이름의 채널 1개, 보내는 호출 1개, 받는 처리 함수 1개를 찾아 연결했다는 것입니다. 정적 코드의 연결이므로 버튼을 실제로 눌렀다는 증거는 아닙니다. 관련 소스 위치도 함께 읽어야 합니다.

4. 입력을 바꿔 CSV 규칙 확인하기

분석을 읽고 끝내지 말고, 결과 하나를 예측해 보세요. 제목에 쉼표나 큰따옴표가 들어가면 CSV는 어떻게 될까요?

notes-example 폴더에 check-csv.cjs를 만들고 다음 코드를 저장합니다. 예제의 변환 함수만 호출하므로 Electron은 필요하지 않습니다.

const assert = require("node:assert/strict");
const { toCsv } = require("./csv.js");

const sample = [{ id: 7, title: 'REA, "첫 실습"' }];
const actual = toCsv(sample);
const expected = 'id,title\n7,"REA, ""첫 실습"""\n';

assert.equal(actual, expected);
assert.equal(toCsv([]), "id,title\n");
console.log(actual);
console.log("쉼표·큰따옴표·빈 목록 검사 통과");

node check-csv.cjs

이 테스트에서는 제목 전체가 큰따옴표로 감싸지고, 제목 안의 큰따옴표가 두 번 기록됩니다. 빈 목록은 헤더만 남깁니다. 여기까지 확인하면 “내보내기 경로를 설명한다”에서 “그 설명으로 결과를 예측하고 확인한다”까지 나아간 것입니다.

웹 실습: 공룡 게임을 REA에 연결하기

웹페이지를 분석하려면 디버깅 연결을 연 별도 브라우저를 준비하고, 페이지 URL과 연결 주소를 Claude Code에 알려줍니다. 아래는 공식 사례와 같은 공룡 게임 웹 버전을 여는 예시입니다.

Chrome 136부터 기본 사용자 데이터 폴더에 대해서는 관련 원격 디버깅 옵션이 적용되지 않습니다. 따라서 아래의 별도 --user-data-dir 지정이 필요합니다. Chrome 공식 변경 안내

"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
  --remote-debugging-port=9222 \
  --user-data-dir="$HOME/rea-dino-profile" \
  "https://wayou.github.io/t-rex-runner/"

& "C:\Program Files\Google\Chrome\Application\chrome.exe" `
  --remote-debugging-port=9222 `
  --user-data-dir="$env:TEMP\rea-dino-profile" `
  "https://wayou.github.io/t-rex-runner/"

google-chrome \
  --remote-debugging-port=9222 \
  --user-data-dir=/tmp/rea-dino-profile \
  "https://wayou.github.io/t-rex-runner/"

브라우저를 띄운 뒤, 다른 터미널에서 대상 목록을 확인합니다.

npx -y rea-agents@latest list-browser-targets http://127.0.0.1:9222 --json

그다음 Claude Code에 아래 프롬프트를 보냅니다.

REA로 공룡 게임의 속도 증가 규칙을 분석해 줘.

페이지: https://wayou.github.io/t-rex-runner/
디버깅 연결: http://127.0.0.1:9222

이 페이지의 대상 ID를 찾고, 로드된 스크립트 소스를 확인해 줘.
시작 속도, 가속량, 한도 검사 조건을 실제 코드 위치와 함께 설명해 줘.
13으로 값을 고정하는지, 13 미만일 때 더하는지 구분해 줘.
정적 분석 결과와 실제 실행으로 확인한 결과를 분리해 줘.
읽기 전용 분석부터 진행하고, 별도 실행 실험은 계획을 먼저 보여줘.

CDP는 Chrome DevTools Protocol의 약자이며, 브라우저의 디버깅 기능에 연결하는 규격입니다. 여기서 사용하는 REA의 읽기 전용 관찰 도구는 이미 열린 페이지에 연결합니다. 공식 공룡 사례도 REA의 관찰과 별도 Playwright 제어로 수행한 반복 업데이트 실험을 구분해 기록했습니다. REA 브라우저 가이드, CDP 분석 범위

분석용 프로필에는 개인 계정으로 로그인하지 말고, 디버깅 포트를 외부에 공개하지 마세요. 작업이 끝나면 직접 분석용 브라우저를 종료하면 됩니다.

REA 분석의 품질을 높이는 복사용 프롬프트

좋은 요청에는 대상·기능·근거·검증이 들어갑니다. “앱을 전부 분석해 줘”보다 하나의 질문을 해결한 뒤 범위를 넓히면 결과를 확인하기 쉽습니다.

내 앱의 특정 기능 조사하기

대상: [분석 권한이 있는 앱 폴더 또는 파일의 전체 경로]
질문: [예: 설정을 저장하면 어느 파일의 어떤 값이 바뀌는가?]

REA로 이 기능과 관련된 코드부터 찾아줘.
설명마다 파일·줄 번호 또는 함수 주소를 연결해 줘.
호출하는 쪽, 실제 처리 함수, 입력값, 출력값을 정리해 줘.
정적 코드에서 보이는 경로와 실행 중 관찰한 경로를 구분해 줘.
알 수 없는 연결은 추측으로 채우지 말고 미확인으로 표시해 줘.
마지막에는 결과를 검증할 입력 2개와 예상 결과를 제안해 줘.

분석 결과를 개발 문서로 정리하기

지금까지 확보한 REA 결과만 사용해 이 기능의 동작 문서를 작성해 줘.

- 한 문장 결론
- 입력 → 처리 → 출력
- 핵심 조건과 상수
- 각 결론을 뒷받침하는 코드 위치
- 관찰한 사실 / 추론 / 미확인 사항
- 재현에 필요한 버전과 환경
- 통과 사례와 실패 사례의 확인 방법

실행하지 않은 검사는 통과했다고 쓰지 마.
코드 예제를 새로 만들면 원본 코드와 설명용 구현을 구분해 줘.

허가받은 CTF 파일 조사하기

대상은 학습용 CTF 실행 파일 [전체 경로]야.
연결된 네이티브 분석 도구로 입력 검사 구조를 조사해 줘.

입력 안내 문자열 → 참조 위치 → 검사 함수 → 상수 순서로 읽어줘.
코드에서 확인한 조건과 문제 형식에 대한 가정을 분리해 줘.
후보를 구했다면 원본 프로그램으로 확인할 방법을 제시해 줘.
정상 후보뿐 아니라 문자 하나를 바꾼 실패 사례도 비교해 줘.

자주 묻는 질문

첫 목표는 앱 전체보다 기능 하나입니다

공룡 게임에서는 숫자와 분기 조건, Notion에서는 프로세스 사이의 연결, CTF에서는 검사식과 원본 실행 결과가 핵심이었습니다. REA를 잘 쓰려면 이처럼 답을 확인할 수 있는 작은 질문부터 시작하는 것이 좋습니다.

먼저 Notes 예제를 열고 “CSV는 어디서 만들어지나요?”를 질문해 보세요. 설명에 코드 위치가 붙었는지 확인하고, 제목에 큰따옴표 하나를 넣어 예측한 결과가 나오는지 검사하세요. 이 과정을 익히면 자신의 앱에서도 조사할 범위와 검증할 기준을 스스로 정할 수 있습니다.

Claude Code를 다른 도구와 연결하는 흐름도 궁금하다면 MarkItDown 설치·MCP 연결 가이드를 함께 읽어보세요.