---
title: "AI와 리버스 엔지니어링의 만남: REA 실습을 따라가며 확인한 것들"
date: 2026-10-13
time: 09:30
model: admin
category: knowhow
author_type: human
summary: "소스 없는 프로그램을 AI 에이전트가 분석해 근거와 함께 풀어내고, 같은 기능을 다시 구현하게 돕는 오픈소스 REA를 공개 실습 중심으로 정리했다. 로컬 분석 구조, 751건 전수 검증, 42초 자동화, 그리고 한계와 윤리까지 함께 다룬다."
tags: "리버스엔지니어링,REA,MCP,AI 에이전트,Ghidra"
---

# AI와 리버스 엔지니어링의 만남: REA 실습을 따라가며 확인한 것들

최근 해외 개발자 커뮤니티에서 화제가 된 오픈소스 프로젝트가 있다. 소스 코드가 없는 프로그램을 AI 에이전트가 직접 들여다보고, 기능이 어떻게 동작하는지 근거와 함께 밝혀낸 뒤, 같은 기능을 자기 프로젝트로 다시 구현하게 돕는 도구다. 이름은 REA, Reverse Engineer Anything이다.

공개된 커버리지에 따르면 이 프로젝트는 등장 직후 폭발적으로 주목받았다. 한 영상은 "40여 개 수준이던 깃허브 스타가 8일 만에 5만 7천 개를 넘었다"고 전했고, 이후 여러 매체가 더 큰 수치를 언급했다. 숫자는 시점에 따라 달라지므로 여기서는 '단기간에 급격히 성장한 프로젝트'로만 기억해 두자.

중요한 건 별점 수가 아니다. 리버스 엔지니어링이라는, 오랫동안 전문가의 손끝에 의존해 온 작업이 AI 에이전트의 작업 흐름 안으로 들어왔다는 점이다.

## 1. REA란 무엇인가

**개념과 작동 방식.** REA는 모델 컨텍스트 프로토콜(MCP) 서버이자 CLI 도구다. MCP는 코딩 에이전트가 외부 도구와 연결되는 표준 방식이다. REA를 설치하면 Claude Code, Codex, Cursor, Gemini CLI 같은 에이전트가 리버스 엔지니어링 도구를 직접 호출할 수 있게 된다.

핵심은 '판단'이 아니라 '연결'에 있다. REA 자체가 새 디컴파일 기술을 발명한 것이 아니다. NSA가 공개한 Ghidra, 상용 도구 Hopper와 IDA Pro, 웹·일렉트론 앱을 위한 Chrome DevTools 같은 기존 분석 엔진을, 에이전트가 다룰 수 있도록 중간에서 번역해 주는 계층이다. 에이전트는 각 도구의 사용법을 몰라도 되고, REA에 분석을 요청하면 알맞은 엔진으로 연결된다.

**로컬 분석과 보안성.** 파일의 디컴파일과 분석은 사용자의 로컬 환경에서 이루어진다. 다만 분석 결과(의사 코드, 근거, 미해결 항목)는 에이전트에게 전달되고, 그 최종 처리는 에이전트가 쓰는 모델 제공자의 정책을 따른다. 즉 "분석은 로컬, 결과 해석은 클라우드 모델"이라는 구조다.

**지원 범위.** 네이티브 바이너리(C/C++ 컴파일 결과물), 일렉트론(Electron) 앱, 자바스크립트, .NET 어셈블리, 웹사이트, 저장된 네트워크 캡처, 안드로이드 APK, 펌웨어까지 대상으로 한다. 네이티브 분석에는 Ghidra·Hopper·IDA 설치가 필요하고, 자바스크립트 정적 분석은 별도 엔진 없이 가능하다.

**무엇을 돌려주는가.** 네이티브 분석은 의사 코드(pseudocode)와 어셈블리를, 자바스크립트·일렉트론 분석은 모듈과 그 관계를 돌려준다. 중요한 점은 결과가 '완성된 소스 코드'가 아니라, 근거와 함께 제시된 해석이라는 것이다. 에이전트는 그 해석을 바탕으로 자기 코드를 작성하고, 원본과 비교 테스트하며, 결과를 다시 분석에 넣는 순환을 반복한다.

설치는 간단하다. Node.js와 npm이 있으면 `npx rea-agents setup` 한 줄로 에이전트 등록과 워크플로 지침 설치가 이루어진다. 기존 설정은 백업되고, 무엇을 바꿀지 검토·승인하는 절차를 거친다.

## 2. 영상 속 실습 과정

여기서부터는 공개된 시연을 따라가며 정리한다.

**① 일렉트론 메모 앱 분석.** 소스 코드가 없는 일렉트론 메모 앱에서 IPC(프로세스 간 통신) 구조를 파악한다. 렌더러 프로세스와 메인 프로세스를 잇는 프리로드 API 구조(예: notes.copy, notes.search)와 각 핸들이 소스 코드 몇 번째 줄에서 정의됐는지까지 짚어낸다. 여기서 그치지 않고 "발신자 검증 코드가 빠진 것으로 보인다"는 식으로, 정적 분석의 한계까지 근거와 함께 제시한다. 리버스 엔지니어링이 보안 점검의 출발점이 될 수 있음을 보여주는 대목이다.

**② C 프로그램 디컴파일과 컴파일러 최적화 추적.** 입력값을 특정 범위(0~639)로 자르고 연산한 뒤 돌려주는 간단한 C 실행 파일이 대상이다. 흥미로운 지점은 소스에 있던 나눗셈 연산이 컴파일 과정에서 곱셈과 비트 시프트로 바뀐 원리를 의사 코드 분석으로 파헤친다는 것이다. 나눗셈은 CPU에서 상대적으로 느리기에, 컴파일러가 상수 곱셈과 시프트 조합으로 바꿔 두는 경우가 있다. 컴파일러 최적화를 사람이 감각적으로 이해하기 어려운 영역인데, REA가 그 흔적을 짚어낸 셈이다.

**③ 원본과 복원본의 전수 검증 - 그리고 42초.** 가장 눈에 띄는 장면은 검증이다. 의사 코드만 보고 다시 쓴 코드와 원본 실행 파일에 -50부터 700까지 다양한 입력을 넣어 출력을 맞춰 봤다. 결과는 751건 전부 일치, 불일치 0건이었다. "그럴듯해 보이는 코드"를 넘어 "동일하게 작동함"을 수치로 확인한 것이다. 그리고 분석·복원·테스트 스크립트 작성·검증의 전 과정을 Claude Code 에이전트에 맡겼을 때, 그것이 42초 만에 끝났다는 점을 시연한다.

여기서 주목할 것은 42초라는 속도보다 절차다. REA는 "그럴듯한 답"을 내는 데서 멈추지 않고, 검증 가능한 증거와 테스트를 함께 내놓는다. 결국 이 도구의 신뢰는 얼마나 빨리 짓는가가 아니라, 얼마나 정직하게 검증하는가에 달려 있다.

## 3. 실제 사례와 한계

**사례.** 한 매체의 실사용 후기에 따르면, 맥의 미리보기(Preview) 앱을 대상으로 확대·축소, 주석, 그리기, 회전, 저장 기능을 상당히 충실하게 재현했다고 한다. 또 다른 시연에서는 음성-텍스트 앱의 기능을 참고해 단축키, 메모, 로컬 전사 기능을 갖춘 프로그램을 만들었다는 사례도 공개됐다.

**한계.** REA가 만능은 아니다.

- **공개된 비교에서는 일반 코딩 에이전트도 비슷한 결과를 냈다.** 어떤 테스트에서는 REA가 오히려 약 2.5배의 토큰을 사용했다. 작은 프로그램일수록 REA의 이점이 크지 않다는 뜻이다.
- **난이도 차이.** 작은 프로그램의 특정 기능 재현과, 대규모·난독화된 상용 프로그램 전체의 복제는 차원이 다르다. 큰 바이너리나 난독화된 대상은 아직 검증 사례가 부족하다.
- **모델의 안전장치.** 한 사용자 후기에 따르면 공격적 대상(예: 공유기 펌웨어)에서는 일부 상위 모델이 안전 정책으로 작업을 거부하기도 했다. 반면 정책이 느슨한 모델은 그대로 수행했다. 즉 결과는 REA만이 아니라 '어떤 모델을 쓰는가'에 크게 좌우된다.

## 4. 총평과 실무적 시사점

**생산성.** 레거시 프로그램의 동작 원리를 파악하거나, 소스가 유실된 코드를 재구현해야 할 때, REA와 같은 도구는 분석 공수를 크게 줄일 수 있다. 다만 그 이점은 대상이 클수록, 그리고 사람이 감당하기 어려운 저수준 분석일수록 커진다는 점을 기억해야 한다.

**본질은 새 기술이 아니다.** REA는 수십 년 된 분석 엔진(Ghidra 2019년 공개, Hopper 2011년, IDA 1990년대)에 에이전트를 연결한 '인터페이스'다. 새로운 것은 디컴파일 기법이 아니라, 그 결과를 해석하고 검증하고 구현하는 과정을 에이전트가 자율적으로 돈다는 점이다.

**윤리와 법적 책임.** 시연은 거듭 강조한다. 분석 대상은 반드시 본인이 만든 것이거나, 라이선스·이용 약관상 분석 권한이 명확한 프로그램으로 한정해야 한다. 경쟁 제품의 UI나 기능을 그대로 복제하는 것은, 그것이 AI로 만들어졌든 아니든 지식재산권과 법적 위험을 동반한다. 도구가 문턱을 낮췄다고 해서 책임까지 낮아지지는 않는다.

**데이터 정책 확인.** 분석 자체는 로컬에서 이루어지지만, 그 결과는 에이전트가 사용하는 모델 제공자에게 전송될 수 있다. 민감한 기업 코드를 다룰 때는 모델 제공자의 데이터 정책을 먼저 확인해야 한다.

**검증은 사람의 몫.** "AI가 프로그램을 복제했다"는 이야기를 접하면, 무엇을 얼마나 재현했고 무엇으로 검증했는지를 함께 봐야 한다. 751건 전수 일치 같은 근거가 있는지가 핵심이다.

## 마무리

REA는 리버스 엔지니어링을 "전문가만의 기술"에서 "에이전트가 참여하는 워크플로"로 옮겨 놓았다. 소프트웨어 개발이 끝났다는 주장은 여전히 과장이다. 사용자의 요구를 파악하고, 예외를 처리하고, 보안과 안정성을 확보하는 일은 AI가 대신 해 주지 않는다.

다만 한 가지는 분명히 바뀌었다. 이제 우리는 "이 기능이 어떻게 동작하지?"라고 묻는 순간, 그 답을 근거와 함께 가져다주고 자기 코드로 다시 써 보는 도우미를 옆에 둘 수 있게 됐다. 도구는 문턱을 낮추고, 책임은 여전히 도구를 쓴 사람에게 남는다.