REA: 자율 에이전트로 모든 것을 리버스 엔지니어링, 앱 동작부터 네이티브 바이너리까지

훌륭한 기능을 발견했지만 그것이 어떻게 만들어졌는지 알 길이 없는 답답함은 모든 개발자가 아는 경험이다. 소스 코드는 공개되지 않았고, 바이너리는 심볼이 제거되어 있으며, Electron 앱은 하나의 ASAR 아카이브로 배포된다. 전통적인 해법은 리버스 엔지니어에게 맡겨 디스어셈블러를 며칠에서 몇 주 동안 한 줄씩 읽게 하는 것이었다. GitHub의 오픈소스 프로젝트 REA(Reverse Engineer Anything)는 이 작업 방식을 바꾸려 한다. 핵심은 단순하다. 네이티브 바이너리, 애플리케이션, 런타임 동작에 걸친 리버스 엔지니어링 도구를 에이전트에게 제공하는 하나의 MCP 서버다. 라이선스는 MIT이고 npm 패키지 rea-agents로 배포되며, README에 따르면 GitHub 스타가 6만 개를 넘었고 열아홉 개 언어로 문서가 제공된다. 보안 연구와 일상적인 소프트웨어 개발의 경계에 있는 도구가 이만한 관심을 받는다는 것은 실제 수요가 크다는 뜻이다.

REA의 작동 방식은 어렵지 않다. npx rea-agents setup을 실행하고, 사용하는 에이전트를 고르고, 제안된 변경 사항을 검토한 뒤 승인한다. 설치 과정은 REA의 MCP 서버를 등록하고, 이에 맞는 워크플로 지침을 설치하며, 기존 설정을 백업한다. README는 Claude Code, Codex, Cursor, Gemini CLI, Grok Build를 지원 대상으로 들고, 로컬 MCP 서버를 지원하는 에이전트라면 사용할 수 있다고 설명한다. 재시작한 뒤에는 자연어로 요청하면 된다. 특정 앱의 검색 기능이 어떻게 동작하는지 파악하고, 근거를 보여 주고, 내 프로젝트에 비슷한 기능을 만들어 달라는 식이다. 에이전트는 MCP를 통해 REA를 호출해 대상을 검사하고 관련 코드를 추적한다. REA는 코드, 참조 관계, 아직 모르는 부분을 포함해 근거가 붙은 발견 사항을 돌려준다. 에이전트는 이를 바탕으로 추가 질문을 하고, 동작을 설명하거나, 구현을 작성해 테스트한다. 같은 흐름을 터미널 명령으로도 실행할 수 있어서 사람이 에이전트의 작업을 그대로 재현할 수 있다.

이 프로젝트에 무게를 더하는 것은 지원하는 대상의 폭이다. README의 표에 따르면 REA는 네이티브 바이너리에 대해 의사 코드, 어셈블리, 문자열, 심볼, 호출과 참조를 반환하며 내부적으로 Hopper, Ghidra, IDA 중 하나를 사용한다. JavaScript와 Electron 앱에서는 모듈, 임포트, 소스 맵, 라우트, IPC, 네이티브 애드온과의 관계를 복원하는데, 이 부분은 Node.js만 있으면 되고 네이티브 분석 엔진이 필요 없다. 그 밖에 웹사이트, 저장된 HAR 네트워크 캡처, 메타데이터와 CIL 명령까지 포함한 .NET 어셈블리, Android APK와 기기, 펌웨어, EVM 바이트코드, 오프라인 ELF 레이아웃, 기록된 Linux 크래시도 다룬다. 프로세스 동작 모드는 터미널 출력, 상호작용, 종료 상태, 파일 시스템 관찰을 기록하고 실행 간 차이를 비교한다. 실제로 하나의 에이전트 세션이 Electron 기능을 렌더러에서 메인 프로세스까지 따라간 뒤 네이티브 애드온의 어셈블리까지 내려갈 수 있다. 서로 연결되지 않은 다섯, 여섯 개의 도구를 오가야 했던 일이 하나의 도구 카탈로그로 모인 셈이다.

README의 세 가지 사례는 이 접근의 범위를 잘 보여 준다. DX-Ball 사례에서는 사운드 호출에서 출발해 위치를 패닝 값으로 바꾸는 보조 함수를 따라가고, 명령어를 검사해 불완전한 의사 코드를 C 코드로 바꾼다. README에 따르면 재구성한 코드는 원본 x86의 3,205개 사례를 통과했고 컴파일된 함수의 63바이트를 모두 재현했다. Notion 사례에서는 렌더러의 클립보드 API를 찾아 preload와 IPC를 거쳐 메인 프로세스까지 추적하고 풍부한 클립보드 형식을 살펴본다. TH04 사례에서는 원작 PC-98 게임의 16비트 명령어를 읽어 고정탄과 자기 조준탄의 각도 계산을 복원하고, 재구성한 C++를 당시 컴파일러의 출력과 비교한다. 난이도는 서로 다르지만 패턴은 같다. 결론은 코드가 아마 이렇게 동작할 것이라는 모델의 인상에서 나오지 않는다. 사람이 다시 확인할 수 있는 명령어 수준의 증거와, 결과를 확인하는 테스트에 근거한다. 이것이 프로젝트가 가장 자주 강조하는 원칙, 즉 모든 결론에 증거와 한계를 함께 제시한다는 원칙이다.

업계 관점에서 REA는 눈여겨볼 흐름을 잘 보여 준다. 전문 도구의 기능을 에이전트가 호출할 수 있는 프로토콜로 감싸고, 계획과 설명은 언어 모델이 맡고, 증거 수집은 결정론적인 분석 엔진이 맡는 구조다. README는 로컬 실행에 대해 분명하게 밝힌다. 분석은 내 컴퓨터에서 실행되고, 에이전트는 도구 결과를 받으며, 그 결과를 모델 제공자가 어떻게 다루는지는 제공자의 데이터 정책에 달려 있다. 이런 역할 분담은 모델이 바이너리의 동작을 추측으로 말할 위험을 줄이고, 보안 팀이 전체 과정을 감사하기 쉽게 한다. 그래도 신중함은 필요하다. 런타임 캡처는 사용자 권한으로 대상을 실행하거나 조작하므로 사용 전에 해당 가이드를 읽어야 한다. 프로젝트는 합법적인 리버스 엔지니어링 연구용이라고 밝히고, 필요한 허가와 법 준수는 사용자의 책임이며, 암호화폐나 토큰을 발행한 적이 없다고 명시한다. 개발자와 보안 팀에게 권할 만한 순서는, 먼저 자신이 권리를 가진 소프트웨어에서 한 번 써 보고, 증거의 연쇄가 직접 검토해도 버티는지 확인한 다음, 일상 업무에 넣을지 결정하는 것이다.