본문으로 건너뛰기
기술 소식을 빠르게 전달드립니다
HYUKHO

AI

REA로 앱을 어디까지 재구현할 수 있을까? 비교 실험의 결과와 한계

REA 비교 실험에서 보고된 성과는 파일 읽기와 오류 처리 기능의 재구현입니다. 16개 테스트와 공식 사례의 검증 범위, Ghidra를 함께 사용한 비교의 해석, 설치 전 준비 조건을 살펴봅니다.

· · 4분 · AI · 수정

핵심 요약

  • NoteVault 실험에서는 REA 사용·비사용 세션 모두 16개 테스트를 통과했지만, 검증 범위는 파일 읽기와 오류 처리 기능입니다.
  • 비사용 세션도 Ghidra를 활용했으므로 REA의 기여는 도구 연결 방식과 조사 지침, 완료 시간·비용·반복 성공률을 함께 살펴봐야 합니다.
  • `npx rea-agents setup`과 별도로 Ghidra와 JDK를 준비해야 합니다.

영상 제작자가 진행한 비교 실험에서는 REA를 쓴 세션과 쓰지 않은 세션이 모두 파일 읽기와 오류 처리 테스트를 통과했다고 보고했습니다. 여기서 확인된 성과는 특정 파일 형식을 읽는 기능을 재구현한 데까지예요. 화면과 편집·저장까지 포함한 앱 전체를 복제했다거나 REA가 성능에서 앞선다는 점을 입증하기에는 검증 범위가 좁습니다.

그래서 결과를 읽을 때는 근거가 어디서 왔는지부터 보시길 권합니다. NoteVault 실험 결과는 소개 영상에서 보여 준 내용에 근거하고, REA의 기능과 활용 사례는 공식 자료에 근거합니다. 독립적인 재현 결과까지 확보됐다고 받아들이기는 어려워요. 무엇을, 어떤 조건에서 구현했는지를 먼저 따져 보는 쪽이 정확합니다.

16개 테스트가 실제로 확인한 것

NoteVault 과제는 소스코드 없이 10분의 제한시간 안에 .nvlt 파일을 읽는 독립 Python 함수를 만드는 작업이었습니다. 원본 앱을 호출하지 않고 노트·태그·우선순위·보관 여부를 읽어 내야 했고, 손상된 입력에 대한 오류 처리도 평가에 들어갔어요. 영상에 따르면 두 세션 모두 16개 테스트를 통과했습니다.

파일을 노트 묶음·태그·우선순위 층·보관함으로 분리하는 장치와 손상 파일용 별도 수거함이 보인다. 시험대 앞에는 초록빛 표시등 16개가 있고, 바깥에는 더 큰 앱 구조의 윤곽이 희미하게 이어진다.
검증된 기능의 경계와 앱 전체의 경계는 다를 수 있다.

가장 흔히 헷갈리는 지점은 '손상 파일 오류 처리'를 '손상 파일 복구'로 넓혀 읽는 것입니다.

테스트를 통과했다는 건 주어진 파일에서 정보를 읽고 잘못된 입력에 대응했다는 뜻이에요. 화면이 원본과 같은지, 편집한 내용을 제대로 저장하는지, 다른 기능까지 일치하는지는 따로 검증해야 할 문제입니다. 10분은 제한시간이라서, 두 세션이 실제로 같은 시간에 끝냈다는 의미도 아닙니다.

공식 사례도 마찬가지로 어떤 기능을 검증했는지부터 확인하는 게 순서입니다. DX-Ball의 3,205건 비교와 63바이트 일치는 특정 소리의 좌우 위치를 계산하는 함수에 관한 결과이고, 바이트 일치에는 고정된 컴파일 환경이라는 조건이 붙어 있어요. Notion 사례는 클립보드 데이터가 앱 내부에서 시스템 클립보드로 넘어가는 경로를 분석한 기록입니다. 이 사례를 앱 전체 복원과 혼동하면 곤란합니다.

REA가 맡는 일, 그리고 공정하게 비교하려면

REA의 공식 명칭은 Reverse Engineer Anything입니다. 기존 분석 도구를 에이전트에 연결하는 MCP 방식과 터미널에서 명령을 실행하는 CLI 방식을 제공해요. MCP는 에이전트가 외부 도구를 호출할 수 있게 이어 주는 인터페이스라고 이해하면 충분합니다. 지원 도구와 연결 방식은 REA 공식 저장소에서 확인할 수 있습니다.

네이티브 프로그램을 분석할 때는 Ghidra 같은 도구가 의사코드와 어셈블리를 내놓고, 에이전트가 이를 바탕으로 기능을 구현하고 테스트합니다. 의사코드는 프로그램의 동작을 이해하기 위한 코드 표현이에요. 분석 결과로 같은 기능을 만드는 일과 개발자가 작성했던 원본 소스코드를 그대로 되찾는 일은 구분해서 봐야 합니다.

이번 비교에서 가장 먼저 짚어야 할 부분은 비사용 세션도 Ghidra를 활용했다는 점입니다. 그렇다면 비교의 핵심은 분석 엔진이 있느냐 없느냐가 아니라, REA의 도구 연결 방식과 조사 지침이 얼마나 도움이 됐느냐가 돼요. 거꾸로 양쪽 다 성공했으니 설치할 가치가 없다고 결론 내리기도 이릅니다. 완료 시간과 비용, 반복했을 때의 성공률까지 같았는지는 확인되지 않았거든요.

REA의 기여를 더 분명하게 가려내려면 추가 실험을 이런 순서로 설계해 볼 수 있습니다.

  1. 모델과 추론 설정, REA·Ghidra 버전, 앱과 입력 파일을 맞춥니다.
  2. 허용 도구와 사전 설치 상태를 기록하고, 설치 시간을 제한시간에 포함할지 정합니다.
  3. 에이전트에 공개하지 않은 테스트로 반복 평가하며 통과율·완료 시간·비용·사람의 개입을 함께 기록합니다.

이 순서는 추가 검증을 위한 제안이에요. 영상 실험에서 이 조건들이 모두 통제됐다는 뜻은 아닙니다.

설치하기 전에 갖춰야 할 것

설치를 검토 중이라면 실행 명령보다 분석 도구가 준비됐는지를 먼저 보시는 게 좋습니다. 2026년 10월 16일에 열람한 공식 설치 문서에 따르면 npx rea-agents setup과 별개로 Ghidra와 JDK를 준비해야 해요. 설정 명령이 구성하는 건 에이전트 연동과 조사 지침입니다. 명령 한 번으로 분석 환경 전체가 설치된다고 생각하면 준비 시간을 잘못 잡기 쉽습니다.

회로를 살피는 확대경 모듈과 톱니바퀴가 든 실행 환경 모듈 위로 연결판과 작은 작업대가 층층이 떠 있다. 정렬선은 두 기반 모듈이 위쪽 작업대를 받치는 조립 관계를 보여 준다.
연결 설정은 준비된 분석 환경 위에서 작동한다.

문서는 바뀔 수 있으니 영상 당시의 기능을 판단하려면 당시 버전을 봐야 합니다. GitHub Trending 1위였다는 이야기와 영상 시점의 스타 수도 확인되지 않은 주장으로 남아 있어요. 이런 숫자를 성능 근거로 삼기보다는 내 과제에서 기능을 얼마나 정확하게 구현하는지, 작업 부담을 얼마나 덜어 주는지를 살펴보는 편이 훨씬 쓸모 있습니다.

라이선스도 헷갈리기 쉬운 부분이에요. REA의 MIT 라이선스는 REA 코드에 대한 허가일 뿐이어서, 분석 대상 앱을 복제할 권한은 대상·권한·목적·이용 방식에 따라 따로 검토해야 합니다. 국내에서는 저작권법 제101조의4의 역분석 조건과 획득 정보의 이용 제한을 함께 확인해야 합니다.

자주 묻는 질문

REA로 원본 소스코드를 그대로 되찾을 수 있나요?
Ghidra가 제공하는 의사코드와 어셈블리를 바탕으로 같은 기능을 구현하는 작업과 원본 소스코드를 그대로 회수하는 작업은 구분해야 합니다. 소개된 실험은 파일 읽기 기능의 재구현을 검증했습니다.
NoteVault 실험은 손상된 파일 복구도 검증했나요?
평가에 포함된 것은 손상된 입력에 대한 오류 처리입니다. 이를 손상 파일 복구 성과로 해석해서는 안 됩니다.

출처

  1. REA 공식 저장소
  2. REA Installation and setup
  3. DX-Ball Reverse Engineering: Sound Panning
  4. Notion Electron Reverse Engineering: Clipboard
  5. REA MIT License
  6. 국가법령정보센터 — 저작권법 제101조의4
  1. AI가 발견한 PHP 취약점: ‘인터넷 70% 해킹’의 의미와 대응 방법
  2. Decodo Web Data API 무료 플랜: 수집 한도 계산과 자동화 검증 방법
  3. Apple Silicon 로컬 LLM 벤치마크, Uzu 수치와 측정 조건 읽는 법

댓글

Giscus를 연결하면 댓글이 열립니다.