GitHub에서 약 35만 9천 개의 스타를 받은 AI 역공학 도구, REA를 아시나요? 2026년 10월 22일 공식 저장소에서 확인한 표시는 Star 359k였어요. 공식 README에는 30만 스타 달성을 기념하는 내용도 올라와 있어요.
스타는 개발자들이 프로젝트에 관심을 표시하거나 다시 찾아보기 위해 남기는 지표예요. 실제 사용자 수나 성능 점수와 같지는 않아요. 여기서는 확인 가능한 누적 스타 수를 소개하며, GitHub Trending의 특정 날짜 순위를 뜻하지는 않습니다.
많은 관심을 받는 만큼, 실제로 무엇을 할 수 있는지가 더 궁금해지죠. 마음에 드는 앱을 쓰다가 “이 기능은 어떻게 만들었을까?” 하고 궁금했던 적 있나요? 화면은 따라 그릴 수 있어도, 버튼 뒤에서 어떤 계산과 데이터 처리가 일어나는지 알아내기는 쉽지 않죠.
REA는 그 궁금증을 AI와 함께 파고들게 해주는 도구예요. 코딩 에이전트가 실행 파일이나 앱 패키지를 살펴보고, 찾은 근거를 바탕으로 기능을 설명하거나 새로운 구현을 만드는 데 활용해요. 완성된 프로그램을 관찰하고 구조를 거슬러 이해하는 ‘리버스 엔지니어링’, 즉 역공학을 돕는 프로젝트입니다.
최근 REA 관련 소개를 보면 가능성이 아주 크게 느껴져요. 그렇다면 실제로 공개된 결과물은 어디까지 왔을까요? REA를 활용하는 앱 Eleven부터 오래된 게임의 기능 복원까지, 확인 가능한 사례로 살펴볼게요.
2026년 10월 22일 공식 GitHub와 프로젝트 공개 자료.
REA란? AI에게 소프트웨어 분석 도구를 연결하는 방법
REA는 Reverse Engineer Anything의 약자예요. 쉽게 비유하면, AI가 정비사라면 REA는 정비사가 엔진 내부를 살펴볼 수 있도록 계측기와 분석 장비를 연결해주는 역할이에요.
앱 이름만 보고 AI가 작동 원리를 추측하는 것과, 실제 파일에서 함수·문자열·호출 관계를 찾아 설명하는 것은 달라요. REA는 후자의 작업을 도와요. 어떤 코드를 봤는지, 어디에서 근거를 찾았는지, 아직 알 수 없는 부분은 무엇인지 함께 다루는 구조예요.
연결에는 MCP라는 방식을 사용해요. MCP는 AI가 외부 도구를 호출할 수 있도록 연결하는 공통 규격으로 이해하면 됩니다. Claude Code·Codex·Gemini CLI 같은 에이전트는 질문을 해석하고 작업을 이어가며, REA는 분석 도구를 통해 관찰 결과를 제공해요. 터미널에서 직접 사용하는 CLI 방식도 있어요.
REA로 무엇을 할 수 있을까요?
| 관심 있는 작업 | REA가 도와주는 부분 | 알아둘 범위 |
|---|---|---|
| Electron 앱의 저장·복사 기능 이해 | JavaScript 모듈과 프로세스 간 호출 추적 | 정적 분석은 앱을 실행하지 않고도 가능 |
| 실행 파일의 계산 규칙 분석 | 함수, 기계어 명령, 의사코드, 호출 관계 확인 | Hopper·Ghidra·IDA 같은 분석 도구 필요 |
| 웹사이트의 특정 동작 이해 | 페이지 구조, 스크립트, 브라우저 통신 관찰 | 관찰 가능한 클라이언트 영역 중심 |
| Android 앱 구조 파악 | APK의 선언 정보와 클래스·메서드 분석 | JADX·JDK 등 별도 준비 필요 |
| 오래된 기능을 새 프로젝트에 구현 | 근거를 정리하고 재구현·검증을 위한 정보 제공 | 구현과 테스트는 별도 작업 |
예를 들어 업무용 프로그램에서 내보낸 CSV가 특정 입력에서 깨진다면, 내보내기 기능이 데이터를 어떤 순서로 읽고 변환하는지 추적해볼 수 있어요. 웹 서비스를 운영한다면 직접 관리하는 페이지의 버튼과 요청 흐름을 분석하는 데 관심이 갈 수 있고요. 이런 예시는 가능한 활용 시나리오이며, 아래에 소개하는 공개 성과와는 구분해서 보면 좋아요.
처음부터 “앱 전체를 똑같이 만들어줘”라고 요청하기보다는 “이 버튼을 누르면 어떤 데이터가 저장되는지 근거와 함께 알려줘”처럼 범위를 좁히는 것이 출발점으로 적합해요.
REA를 활용한 소프트웨어: Eleven은 어떤 앱일까요?
Eleven은 에이전트와 함께 바이너리를 분석하는 작업 화면을 제공하는 오픈소스 앱이에요. 프로젝트 README는 네이티브 코드 분석에서 Ghidra를 REA를 통해 사용한다고 명시해요. 다른 분석 경로로 Rizin도 안내하고 있어, 모든 기능이 REA 하나로 동작한다고 이해하면 안 돼요.
사용자는 함수와 코드, 참조 관계를 보면서 AI에게 설명을 요청할 수 있어요. 함수 이름을 이해하기 쉽게 바꾸거나 메모를 남기고, 수정 제안을 검토하는 흐름도 제공합니다. 분석 작업과 AI 대화를 같은 화면에서 연결한다는 점이 흥미로워요.
현재 README에는 macOS·Windows·Linux 설치 경로가 안내돼 있어요. macOS 안내는 Apple Silicon과 macOS 14 이상, Windows는 x64 기준입니다.
Eleven은 REA를 이용하는 소프트웨어 사례예요. “REA가 사람의 개입 없이 Eleven 전체를 만들었다”는 뜻은 아닙니다. 이 차이를 알아두면 AI 개발 도구 관련 소식을 더 정확하게 읽을 수 있어요.
출처: Eleven 공식 GitHub
공개 사례에서 확인한 REA의 실제 성과
DX-Ball: 공의 위치가 좌우 소리로 바뀌는 계산을 복원
벽돌 깨기 게임에서 왼쪽의 벽돌이 부서지면 소리도 왼쪽에서 들리는 느낌이 나죠. REA 공식 사례는 1996년 Windows 게임 DX-Ball의 이런 소리 위치 계산을 살펴봐요.
공개된 분석에서는 실행 파일의 명령어와 호출 관계, 상수를 확인해 작은 C 함수로 재구성했어요. 해당 함수는 원본 x86 동작과 3,205개 사례를 대조하고, 컴파일 결과 63바이트가 일치하는지 확인했다고 보고돼 있어요.
이 숫자는 REA 전체의 정확도 점수가 아니라 특정 함수의 검증 결과예요. 공식 사례의 2026년 10월 7일 진행 현황에는 게임 플레이 구현이 계속 진행 중이라고 적혀 있어요. 완성된 게임 전체의 복원과 함수 단위 성과를 구분해서 읽어야 합니다.
출처: DX-Ball 분석·검증 사례 · 복원 프로젝트
Notion: 복사한 문서의 서식은 어떻게 유지될까요?
Notion에서 내용을 복사하면 글자뿐 아니라 서식과 블록 관련 정보도 함께 다뤄져요. 공식 사례는 Notion Desktop 7.6.1의 패키지에서 복사 요청이 시스템 클립보드까지 전달되는 경로를 추적해요.
화면 쪽 API에서 시작한 요청이 중간 연결 코드를 거쳐 Electron의 클립보드 쓰기로 이어지는 구조예요. IPC는 서로 다른 프로세스가 메시지를 주고받는 통로라고 생각하면 쉬워요.
이 사례의 결과는 Notion 복사 기능에 대한 분석이에요. Notion 전체를 복제한 새 앱이 나온 사례는 아닙니다. 앱 개발자라면 화면과 데스크톱 기능이 어떻게 이어지는지 이해하는 관점에서 흥미롭게 볼 만해요.
TH04: 오래된 게임의 탄막을 수식과 C++로 이해하기
PC-98용 동방 프로젝트 TH04 사례에서는 원형으로 퍼지는 탄환의 방향 계산을 다뤄요. 게임은 한 바퀴를 256단위로 표현하고, 탄환 16개를 배치할 때 각도를 16단위씩 나누는 식이에요. 여기에 플레이어 방향을 더하면 원형 패턴 전체가 회전해요.
REA로 원래의 16비트 명령을 살펴보고, 복원 프로젝트의 C++ 구현과 연결해 확인하는 사례입니다. 옛 게임의 독특한 움직임을 느낌으로 흉내 내는 데서 한 걸음 더 들어가, 실제 계산을 이해하려는 접근이에요.
출처: TH04 탄막 계산 사례 · TH04 복원 프로젝트
코드가 낯설다면 먼저 공식 사례의 그림과 데모를 보세요. 무엇을 입력으로 받고 어떤 결과가 달라지는지 확인한 뒤 분석 설명을 읽으면 훨씬 이해하기 쉬워요.
맥미니에서 SSH·SFTP·FTP 앱 Harbor 만들기
설치가 끝나면 이런 궁금증이 생겨요. “내가 쓰는 앱의 구조를 살펴보고, 필요한 기능을 가진 작은 프로그램을 직접 만들 수 있을까?” 제 맥미니에서 진행한 Harbor 개발 사례가 그 다음 단계를 보여줘요. 목표는 서버 정보를 관리하고, SSH로 접속하고, SFTP·FTP로 파일을 주고받는 macOS 앱을 만드는 것이었어요.
REA로 확인한 것과 Codex로 구현한 것
먼저 설치된 Termius 10.1.3의 app.asar를 REA로 살펴봤어요. ASAR는 Electron 앱의 파일을 한데 묶은 포장 상자라고 생각하면 쉬워요. 이번에는 그 상자의 파일 목록과 package.json을 확인해 main-process, preload, ui-process, SSH·PTY 관련 모듈의 존재를 파악했어요.
여기서 분석 범위가 중요해요. 선택한 소스는 package.json이었고, 전체 기능의 내부 동작이나 소스 간 연결까지 분석한 것은 아니에요. 이후 Codex에 “SSH 및 SFTP, FTP 구현”을 요청해 SwiftUI와 macOS의 OpenSSH·curl로 Harbor를 별도 구현했어요. 프로젝트에는 Termius 코드나 리소스를 포함하지 않았다고 사용 안내에 명시돼 있습니다.
이번 REA 활용은 패키지 구조 확인 → 필요한 기능 지정 → 별도 앱 구현 → 동작 검증의 흐름이었어요. REA의 분석 결과만으로 원본과 같은 기능이나 품질이 보장되는 것은 아니며, 실제 전송 코드는 별도로 만들고 시험해야 했어요.
Harbor에서 구현한 기능
| 기능 | 구현 방식과 범위 |
|---|---|
| 서버 관리 | 서버 추가·선택·저장·삭제. 암호는 저장하지 않음 |
| SSH 접속 | macOS Terminal에서 SSH 세션을 여는 방식. 내장 터미널은 구현하지 않음 |
| SFTP 파일 전송 | OpenSSH 기반 목록 조회, 단일 파일 업로드·다운로드, SSH 키 선택 |
| FTP 파일 전송 | curl 기반 수동 모드 전송. 일반 FTP이며 FTPS는 미구현 |
| 사용 화면 | SwiftUI 기반 한국어 다크 모드, 연결 정보와 원격 파일 작업 영역 |
SSH가 원격 컴퓨터에서 명령을 내리는 통로라면, SFTP는 그 보안 연결을 이용해 파일을 주고받는 창구예요. 일반 FTP는 암호화되지 않으므로 프로토콜 이름이 비슷하다고 같은 보안 특성으로 보면 안 돼요.
실제로 어디까지 테스트했을까?
개발 기록에는 Swift 빌드와 앱 화면 실행 성공이 남아 있어요. 로컬 FTP 테스트 서버에서는 목록 조회, 공백이 들어간 파일명, 업로드 후 다운로드한 파일의 바이트 일치, 없는 파일 요청의 오류 처리를 확인했습니다. 호스트 입력 검증과 셸 인자 따옴표 처리도 테스트했어요.
PASS: FTP list, upload/download byte equality, missing-file failure, input validation, shell quoting위 문장은 당시 테스트의 실제 출력이에요. 다만 실제 SSH·SFTP 서버의 인증과 전송은 접속 대상이 제공되지 않아 미검증으로 남아 있습니다. 이번 글 보강 작업에서도 기존 Harbor.app을 맥미니에서 다시 실행해 프로세스와 창 생성을 확인했으며, 외부 서버 연결 테스트를 추가로 수행한 것은 아니에요.
폴더 전체 전송, 전송 취소·재개, 동기화, 내장 터미널은 아직 구현 범위에 없어요. Apple Silicon용으로 빌드한 개인용 초기 버전이고, 다른 맥에 배포하기 위한 공증도 포함하지 않았습니다. 따라서 이 사례는 필요한 기능을 가진 앱을 실제로 구현한 기록으로 읽어주세요.
직접 따라 할 때 남겨두면 좋은 기록
이번 프로젝트는 Harbor.app, Source/Harbor.swift, build.sh, README.md, REA-summary.json을 함께 남겼어요. 실행 파일만 보관하기보다 무엇을 분석했고, 무엇을 구현했고, 무엇을 시험했는지를 묶어두면 나중에 글을 쓰거나 기능을 개선할 때 확인하기 쉬워요.
REA 결과에는 unpacked 파일 17개의 선언된 해시와 실제 해시가 다르다는 기록도 있었습니다. 당시 분석은 그 차이를 기록하는 record-and-continue로 진행됐고, 분석 범위가 제한됐다는 설명을 함께 남겼어요. 이 기록만으로 변조 여부를 판단하거나 원본과의 기능 동등성을 주장할 수는 없습니다.
처음 시도한다면 “앱 전체를 똑같이 만들어줘”보다 “서버 정보를 입력하고, 파일 목록을 조회하고, 작은 파일 하나를 왕복 전송하자”처럼 확인 가능한 작업으로 나누어보세요. 이 사례에서도 구현된 기능과 검증된 기능을 나눠 기록한 것이 다음 개발 단계를 정하는 기준이 됐어요.
어떤 사람에게 특히 흥미로운 도구일까요?
작은 앱을 만드는 개발자라면 저장·검색·내보내기 같은 기능의 구조를 연구할 수 있어요. 레거시 시스템을 관리하는 사람이라면 문서가 부족한 기능의 동작을 확인할 때 도움이 될 수 있고요. 게임과 소프트웨어 보존에 관심 있는 사람에게는 오래된 실행 파일의 규칙을 기록하는 접근이 매력적이에요.
코딩을 배우는 사람에게도 질문의 출발점이 생깁니다. “이 앱은 어떤 기술로 만들어졌을까?”에서 시작해 “버튼의 이벤트는 어느 함수로 전달될까?”로 질문을 구체화해볼 수 있어요. 다만 분석 결과를 검증하려면 파일 구조와 기본적인 코드 읽기 능력을 함께 익히는 편이 좋아요.
REA를 설치하기 전에 알아둘 현실적인 범위
실행 파일을 분석한다고 원래 개발자가 작성한 주석과 변수명, 프로젝트 구조가 모두 돌아오는 것은 아니에요. 네이티브 분석에서 얻는 의사코드는 기계어를 사람이 읽기 쉽게 재구성한 결과여서, 실제 명령과 입력·출력으로 확인하는 과정이 필요해요.
브라우저에서 보이는 화면과 통신을 살펴볼 수 있어도, 접근할 수 없는 서버 내부의 코드를 자동으로 가져오는 것은 아니에요. 또한 REA 자체의 로컬 분석과 AI 서비스의 데이터 처리는 구분해야 합니다. 도구 결과는 연결한 에이전트에 전달되므로 자료를 맡기기 전에 해당 에이전트의 처리 방식을 확인하세요.
REA의 코드는 MIT 라이선스이며, AI 서비스 사용료와 Hopper·IDA 등 외부 도구의 조건은 별개예요. 학습은 직접 만든 샘플이나 분석 권한이 있는 소프트웨어로 시작하면 범위를 정하기 편합니다.
REA가 궁금하다면 첫 목표는 작아도 충분해요. “메모 내보내기 버튼이 CSV를 만드는 과정을 설명해줘.” 이 질문에 파일 위치와 코드 근거가 붙은 답변을 얻는 것부터 시작해보세요. 설치와 연결, 맥·윈도우에서의 첫 실습은 별도의 설치 가이드에서 확인
기본 기능·요구 조건 참고: REA README · 설치 문서