REA로 앱 구조를 쉽게 분석하기

완성된 앱의 기능이 어떻게 이어지는지 파악하고 AI 에이전트가 참고할 분석 근거로 추출하는 원리를 살펴봅니다.

무료 공개 · 최근 수정 2026-10-18

남이 만든 앱의 내부 구조를 파악하기 어려울 때

다른 사람이 빌드해 둔 자바스크립트 앱이나 패키지 묶음을 살펴볼 때, 파일이 수십 개 이상으로 쪼개져 있으면 어떤 파일이 진입점이고 함수가 어떻게 연결되는지 한눈에 알기 어렵습니다. 파일을 하나씩 열어 찾아보기에는 시간이 오래 걸리고, AI 모델에게 전체 프로젝트 텍스트를 무작정 넘기면 토큰 한도에 걸리거나 실제와 다른 내용을 지어내기 쉽습니다.

역공학(Reverse Engineering)은 완성된 프로그램을 거꾸로 짚어가며 내부 구성과 동작 방식을 확인하는 일입니다. 복잡한 도구를 다루지 않더라도 정적 분석 도구와 AI 에이전트를 함께 쓰면 파일들 사이의 호출 관계를 훨씬 쉽게 정리할 수 있습니다. 이 글에서는 REA 도구가 완성된 앱에서 어떻게 모듈 연결 관계를 추출하고, AI 에이전트가 이를 어떤 한계 속에서 활용하는지 핵심 개념과 실제 사례를 중심으로 살펴봅니다.

REA의 등장 배경과 주목받는 지점

REA 프로젝트는 2026년 4월 14일 GitHub에 최초 커밋이 등록되며 공개 개발 기록이 시작되었습니다. 프로젝트를 만든 개발자의 GitHub 식별자는 morluto이며 여러 기여자가 함께 개발에 참여하고 있습니다. 초기 커밋 당시에는 맥용 역공학 도구인 Hopper Disassembler 6의 공식 기능을 감싸고 분석을 돕는 보조 도구로 출발했습니다.

2026년 10월 18일 조회 기준 공식 저장소의 관심 지표인 GitHub 별(Stars)은 약 31만 2천 개를 기록하고 있습니다. REA가 주목받는 지점은 코딩 에이전트가 기존 역공학 도구를 직접 호출해 완성된 프로그램의 특정 동작을 조사하고, 추출된 근거를 바탕으로 별도 구현과 검증으로 연결할 수 있다는 기능적 특성에 있습니다.

REA와 분석 근거의 개념

REA(Reverse Engineer Anything)는 완성된 애플리케이션의 번들이나 바이너리를 분석해 체계적인 결과물을 만들어 주는 명령줄(CLI) 도구입니다. REA 자체가 생각하는 AI 모델은 아니며, 파일들을 정해진 규칙대로 읽어서 사람이 분석하거나 AI 에이전트가 참고할 수 있는 중간 자료를 만들어 주는 분석 도구입니다.

REA가 만들어 내는 핵심 산출물은 바로 분석 근거(Evidence)입니다. 분석 근거는 앱을 대충 훑어보고 추측한 설명이 아니라, 어느 파일에서 어떤 모듈을 불러오는지 관찰한 내용, 정적 추론 결과, 발견 위치, 그리고 판단의 한계와 미확인 사항을 구분해 기록한 구조화된 데이터입니다. 즉, 모든 판단을 확정된 사실로 단정하지 않고 어떤 근거와 한계 속에서 도출했는지를 남깁니다.

AI 에이전트와 REA, 그리고 분석 대상 앱은 다음과 같은 흐름으로 연결됩니다.

AI 에이전트가 REA 도구를 호출하고 대상 앱에서 분석 근거를 받아오는 세 단계 구조

그림: AI 에이전트가 REA를 거쳐 대상 앱의 분석 근거를 전달받는 흐름

REA는 모델 컨텍스트 프로토콜(MCP)을 지원합니다. MCP는 AI 에이전트가 외부 프로그램을 부르는 연결 규약입니다. 사용자가 "이 프로그램에서 가격 계산 함수가 어디서 불리는지 찾아줘"라고 물으면, 에이전트가 REA 도구를 호출해 대상 폴더의 연결 구조를 읽고 돌려받은 분석 근거를 바탕으로 설명합니다.

정적 분석 명령과 실제 검증 결과

REA는 네이티브 바이너리, 자바스크립트, 일렉트론, 닷넷, 웹 환경 등 다양한 대상을 다루며 런타임 조사 연결도 지원하는 도구입니다. 다만 이 글에서 다루는 직접 실행 검증은 대상을 실행하지 않고 파일 텍스트만 읽어 구조를 파악하는 자바스크립트 정적 분석에 한정됩니다.

[참고] 실행 환경 요구사항

자바스크립트 정적 분석에는 별도 외부 역공학 엔진이나 유료 API 키가 필요하지 않으며 Node.js 환경(22.19 이상인 22.x LTS 또는 24.11 이상인 24.x LTS)과 리눅스 기준 procps 호환 ps 명령어가 있으면 충분합니다.

이미 보유하고 있는 자바스크립트 프로젝트 폴더의 연결 구조를 분석할 때는 터미널에서 다음 한 줄 명령을 실행합니다. /absolute/path/to/app 자리는 독자가 분석하려는 실제 프로젝트 폴더나 ASAR 파일의 절대 경로로 바꾸어 입력합니다.

npx -y rea-agents@6.5.0 analyze-javascript-application /absolute/path/to/app --json > rea-evidence.json

실제 검증 환경(Linux, Node.js v22.22.2)에서 main.js가 price.js의 total 함수를 불러오는 작은 자작 데모 프로젝트를 대상으로 위 6.5.0 명령을 실행해 분석 결과를 확인했습니다. 생성된 JSON 결과를 확인한 관찰 내용은 다음과 같습니다.

확인 항목	관찰 값	의미와 한계
읽은 자바스크립트 파일	2개	디렉터리 내 두 파일(`main.js`, `price.js`)의 텍스트 파싱을 완료했습니다.
문법 분석 실패 파일	0건	구문 분석에 실패한 파일이 없다는 뜻이며, 프로그램의 런타임 동작이 완전함을 증명하지는 않습니다.
모듈 연결 관계	imports (`./price.js`)	`main.js`가 `price.js`를 가져다 쓰고 있다는 정적 연결을 확인했습니다.

문법 분석 실패가 0건이라는 점은 파일 텍스트를 문법 규칙에 맞게 읽었다는 뜻일 뿐, 실행 시 오류가 없다거나 모든 동적 관계가 완전하게 포함되었다는 의미는 아닙니다.

공개 사례로 보는 기능 추적과 대안 구현

공식 프로젝트와 개발자 커뮤니티에서는 실제 완성된 소프트웨어를 REA로 분석하고 특정 기능을 추적하거나 대안 프로그램을 만든 사례들을 공개하고 있습니다.

노션 클립보드 복사 경로 추적

노션 데스크톱 앱 분석 기록(Notion 7.6.1, REA 4.1.0)에서는 사용자가 텍스트와 HTML을 복사할 때 데이터가 흐르는 경로를 추적했습니다. 웹 화면 쪽 API에서 시작하여 화면과 네이티브 기능을 이어주는 preload 스크립트, 프로세스 간 통신(IPC) 채널인 notion:clipboard:write, 그리고 메인 프로세스의 시스템 클립보드 함수(clipboard.write)로 이어지는 호출 흐름을 파악했습니다. REA가 패키지 안에서 시작 위치와 연결 함수들을 찾아주었고 분석자가 전체 복사 경로를 정리한 사례이며, 노션 앱 전체를 복원한 것은 아닙니다.

DX-Ball 고전 게임 사운드 함수 복원

1996년 윈도우 게임 DX-Ball 1.07 분석에서는 공이 벽돌에 닿는 가로 위치에 따라 소리의 좌우 균형을 계산하는 사운드 팬(sound pan) 함수를 대상으로 했습니다. REA로 원본 실행 파일의 명령어와 데이터 참조를 읽고, 이를 바탕으로 C 언어로 함수를 재구성했습니다. 공식 문서에 따르면 3,205가지 입력 조합을 원본 x86 동작과 대조해 일치함을 확인하고 당시 컴파일러로 빌드해 바이트 일치를 검증했습니다. 이 역시 복원 팀이 도구의 분석 정보를 바탕으로 코드를 작성하고 별도 검증을 수행한 사례이며, 게임 전체가 복원된 것은 아닙니다.

레이저 시냅스 설정 대안 도구 개발

Reddit 사용 후기에서 한 개발자는 REA를 사용해 레이저 시냅스(Razer Synapse) 소프트웨어를 분석하고 필요한 설정 기능을 파악했다고 밝혔습니다. 개발자는 이를 바탕으로 마우스와 키보드의 감도(DPI), 조명, 버튼 프로필을 제어하는 경량 대안 프로그램인 Secretarybird(secbird) 프로젝트를 공개했습니다. 저장소 설명에 따르면 이 프로젝트는 베타 상태이며 일부 장치만 검증된 상태라고 명시되어 있어, 완성 프로그램의 특정 제어 기능을 분석해 대안 구현으로 연결한 커뮤니티 사례로 볼 수 있습니다.

AI 에이전트와 도구를 연결할 때 주의할 점

REA로 뽑아낸 분석 근거는 AI 에이전트 루프에서 도구 실행 결과로 모델에게 전달될 때 유용합니다. 모델이 코드를 어림짐작하는 대신 REA가 정리해 준 파일 연결 관계와 위치 정보를 토대로 질문에 답하거나 재작성할 수 있기 때문입니다. 패키지에는 에이전트 설정을 돕는 setup 명령이 제공되어 대화형 안내에 따라 MCP 도구로 등록할 수 있습니다.

하지만 도구를 활용할 때 다음 한계를 명확히 인지해야 합니다.

서버 자원 복원의 한계: 클라이언트 앱 패키지에 포함되지 않은 서버 측 백엔드 코드, 운영 데이터베이스, 비공개 클라우드 모델은 로컬 앱 파일만 분석해서 복구할 수 없습니다. 따라서 완성된 서비스 전체를 자동으로 복제할 수는 없습니다.
분석 범위의 한계: 자바스크립트나 일렉트론 앱의 텍스트 구조는 내장 기능만으로 분석할 수 있지만, C·C++ 등으로 빌드된 네이티브 바이너리의 어셈블리어나 의사코드를 깊이 있게 분석하려면 Ghidra나 Hopper 같은 별도의 전문 역공학 엔진이 설치되어 있어야 합니다.
원본 코드 복원의 한계: 이미 변환되거나 난독화된 코드의 주석이나 원본 변수명을 완벽하게 되돌려 주지는 못합니다.
AI 해석 오류의 가능성: REA가 정밀한 분석 근거를 전달하더라도, 이를 해석하는 LLM이 맥락을 오판하거나 잘못된 코드를 생성할 수 있습니다. 모델이 작성한 코드는 반드시 사람이 별도의 단위 테스트나 동작 검증을 거쳐야 합니다.
로컬 분석과 데이터 전송의 구분: REA의 파일 분석 자체는 로컬 컴퓨터에서 실행되지만, 에이전트가 외부 상용 AI 모델을 호출한다면 분석 근거 텍스트가 외부 네트워크로 전송된다는 점을 고려해야 합니다.

참고 문서

설명이 어렵거나 잘못된 부분을 발견하셨나요?

문서 수정 의견 보내기