REA AI 역공학 작동 원리와 성능 한계 정리
REA는 AI 에이전트와 역공학 도구를 연결해 소프트웨어의 동작을 조사하는 도구입니다. 공개 사례의 검증 범위와 서버 분석의 한계를 구분하고, 보안·저작권·분석 결과의 재현성을 설명합니다.
REA는 MCP를 통해 AI 에이전트가 역공학 도구를 호출하도록 연결합니다.
실행 파일의 동작을 이해하는 것과 원래 소스 코드를 복원하는 것은 다릅니다.
공개된 DX-Ball 사례는 특정 함수의 검증 결과이며 게임 전체의 복원 완료를 뜻하지 않습니다.
앱에 포함되지 않은 서버 코드나 비공개 모델은 앱 분석만으로 확보할 수 없습니다.
분석 결과에는 근거와 미확인 범위를 남기고 원본과의 동작 비교를 거쳐야 합니다.
REA는 AI가 역공학 도구를 호출해 앱의 동작을 조사하도록 연결합니다. 공개 사례는 특정 기능의 분석과 재구현 가능성을 보여줍니다. 이를 소프트웨어 산업의 종말이나 서비스 전체 복제의 증거로 보기는 어렵습니다.
DX-Ball 검증 수치는 공식 사례의 2026년 10월 7일 진행 기록 기준입니다.
REA는 무엇인가요
REA는 Reverse Engineer Anything의 약자입니다. AI 에이전트에 소프트웨어 분석 도구를 연결하는 프로젝트입니다. 자체적으로 모든 분석을 수행하는 단일 AI 모델은 아닙니다.
리버스 엔지니어링은 완성된 소프트웨어에서 구조와 동작을 추적하는 작업입니다. 한국어로는 역공학이라고 합니다. 목표는 기능을 설명하거나 호환성을 확보하는 데 필요한 내용을 파악하는 것입니다.
컴파일은 사람이 작성한 코드를 실행 가능한 형태로 바꾸는 과정입니다. 이때 주석과 일부 이름 정보가 사라질 수 있습니다. 최적화 과정에서 함수나 계산식의 모습도 달라집니다.
다만 모든 앱이 이름 없는 기계어만 남기는 것은 아닙니다. JavaScript 코드나 디버깅 정보가 포함된 배포물도 있습니다. 따라서 분석 방법은 파일 형식과 남아 있는 정보에 따라 달라집니다.
용어 | 쉬운 설명 | 결과를 읽을 때의 주의점
디스어셈블 | 기계어를 어셈블리 명령으로 표현 | 명령의 목적은 추가 해석이 필요
디컴파일 | 실행 코드를 소스와 비슷한 형태로 표현 | 원래 소스와 동일하다는 보장 없음
정적 분석 | 프로그램을 실행하지 않고 파일 조사 | 실제 실행 경로와 구분 필요
동적 분석 | 프로그램을 실행하며 동작 관찰 | 관찰한 조건 밖의 동작은 미확인
재구현 | 파악한 동작을 새 코드로 작성 | 원본과의 비교 검증 필요
AI와 Ghidra는 어떻게 연결되나요
REA는 MCP를 통해 에이전트의 분석 요청을 도구로 전달합니다. MCP는 AI와 외부 도구가 요청과 결과를 주고받는 연결 규격입니다. Ghidra는 실행 파일을 조사하는 역공학 도구입니다.
공식 README는 Ghidra 외에 Hopper와 IDA 연동도 안내합니다. JavaScript 정적 분석에는 네이티브 분석 엔진이 필요하지 않습니다. 따라서 REA의 기능을 Ghidra 자동 조작만으로 설명하면 범위가 좁아집니다.
분석은 보통 다음 순서로 진행합니다.
· 조사할 앱과 기능을 정합니다.
· 문자열이나 함수 호출에서 관련 위치를 찾습니다.
· 명령과 데이터 흐름을 따라 동작을 해석합니다.
· 부족한 근거를 추가 도구 호출로 확인합니다.
· 재구현한 결과를 원본의 동작과 비교합니다.
Ghidra에도 기존부터 자동 분석 기능이 있습니다. REA는 에이전트가 분석 요청을 이어 가도록 연결합니다. 실제 정확도는 대상과 분석 엔진, 모델, 검증 방식에 좌우됩니다.
조건별 분석 범위
REA로 확인할 수 있는 범위는 접근 가능한 파일과 실행 환경에 달려 있습니다. 로컬 앱에는 서버와 통신하는 코드가 포함될 수 있습니다. 그 코드가 서버 내부 구현까지 담고 있다는 뜻은 아닙니다.
분석 대상 | 확인할 수 있는 내용 | 분석만으로 단정할 수 없는 내용
로컬 실행 파일 | 계산식, 문자열, 함수 호출 관계 | 원래 주석과 설계 의도 전체
JavaScript·Electron 앱 | 모듈 구조, 화면과 내부 처리의 연결 | 서버에만 있는 처리 로직
웹페이지와 통신 기록 | 내려받은 스크립트, 관찰한 요청과 응답 | 서버 소스와 데이터베이스 전체
로컬에 포함된 모델 파일 | 접근 가능한 파일의 구조와 정보 | 서버에서만 사용하는 비공개 모델
실행 중 관찰한 기능 | 해당 입력과 환경에서의 동작 | 모든 입력과 장애 상황의 동작
서비스 재구현에는 관찰한 기능 밖의 요구사항도 필요합니다. 계정 권한이나 오류 처리 같은 동작이 대표적입니다. 화면이 비슷하게 작동해도 서비스 전체가 같다고 판단할 수 없습니다.
8분 41초 계산기 실험의 검증 범위
8분 41초라는 수치는 원본 기록이 확인되지 않은 시연 주장입니다. 함께 제시된 도구 호출 횟수는 17회입니다. 계산 규칙 4개를 찾았다는 주장도 독립적으로 확인하지 못했습니다.
원본 영상과 실행 기록에서 시험 조건을 확인해야 합니다. 모델과 프로그램 크기에 따라 걸리는 시간은 달라집니다. 한 번의 성공만으로 일반적인 분석 속도나 정확도를 판단할 수는 없습니다.
계산기 분석에서는 수식을 읽는 것만으로 검증이 끝나지 않습니다. 할인과 쿠폰의 적용 순서가 결과를 바꿀 수 있습니다. 정수 나눗셈의 버림 처리도 별도로 확인해야 합니다.
· 할인과 쿠폰을 적용하는 순서
· 세금을 계산하는 기준 금액
· 중간 계산의 반올림 또는 버림 위치
· 조건이 바뀌는 경계값에서의 출력
· 원본과 재구현 코드에 같은 입력을 넣은 비교 기록
빠른 분석을 입증하려면 성공한 답변 외의 기록도 필요합니다. 실패한 실행과 재시도 횟수가 비교에 영향을 줍니다. 현재 확인한 근거만으로 사람보다 우수하다는 일반 평가는 어렵습니다.
공개 사례에서 확인된 성과
공식 사례는 Notion의 클립보드 경로와 DX-Ball의 계산 함수를 보여줍니다. 두 사례 모두 조사한 기능의 범위를 명시합니다. REA 프로젝트가 공개한 기록이라는 점도 구분해야 합니다.
사례 | 공개 문서에서 확인한 작업 | 확대 해석하면 안 되는 내용
Notion Desktop 7.6.1 | 앱 내부 호출에서 시스템 클립보드까지 경로 추적 | Notion 전체 서비스 복제
DX-Ball 1.07 | 화면 위치를 좌우 음향 값으로 바꾸는 함수 재구현 | 게임 전체 복원 완료
Razer Synapse 경량 대체 앱 | 이번 확인에서는 구체적인 원본 검증 기록 미확인 | 공식 검증을 마친 REA 성과로 단정
Claude 관련 슬라이드 편집기 | 이번 확인에서는 대상과 재구현 범위 미확인 | Claude의 비공개 모델 복원으로 해석
Notion 사례는 화면 쪽 호출이 내부 통신을 거치는 과정을 추적합니다. 마지막에는 Electron의 클립보드 쓰기 기능으로 연결됩니다. 이는 특정 기능의 처리 경로를 설명하는 사례입니다.
DX-Ball 사례는 함수 입력과 계산 상수를 실행 파일에서 확인했습니다. 해당 함수의 비교 시험은 3,205건입니다. 검토된 재배치 처리를 반영한 컴파일 결과는 63바이트가 일치했습니다.
이 기록은 특정 함수의 재구현을 뒷받침합니다. 공식 문서는 게임 전체의 실행 가능한 복원을 진행 중이라고 설명합니다. 일부 함수의 검증과 제품 전체의 완성은 구분해야 합니다.
관찰과 추론 표시는 무엇을 보장하나요
근거 표시는 결론이 어디에서 나왔는지 구분하는 장치입니다. REA 문서는 관찰과 추론, 미확인 정보를 구별합니다. 다만 모든 도구가 동일한 네 가지 꼬리표를 쓰는 것은 아닙니다.
공식 문서에는 분석 종류별로 다른 상태와 신뢰도 표현이 나옵니다. 이를 읽을 때는 아래처럼 의미를 나누면 도움이 됩니다. 표의 구분은 이해를 돕기 위한 설명입니다.
구분 | 의미 | 검토할 내용
관찰 | 파일이나 실행 결과에서 직접 확인 | 대상 버전과 근거 위치
도출 | 관찰한 값과 관계에서 계산한 결론 | 계산 과정과 전제
추정 | 추가 확인이 필요한 해석 | 다른 설명의 가능성
미확인 | 근거를 확보하지 못한 부분 | 조사 범위와 확인 실패 이유
공식 DISCLAIMER.md는 분석 결과의 한계를 명시합니다.
Decompilation, reconstruction, heuristics, and AI-assisted analysis may be incomplete or incorrect. 출처: REA DISCLAIMER.md
이는 디컴파일과 AI 분석이 불완전하거나 틀릴 수 있다는 뜻입니다. 관찰 표시가 붙어도 도구 오류 가능성이 사라지지는 않습니다. 근거 표시의 가치는 재검토할 위치를 남기는 데 있습니다.
흔한 실수
가장 흔한 오해는 설명 가능한 결과를 검증 완료로 받아들이는 것입니다. 읽기 좋은 코드는 원본과 다른 동작을 할 수 있습니다. 조사하지 않은 경로는 별도로 남겨야 합니다.
오해 | 더 정확한 해석
디컴파일하면 원래 소스가 돌아옵니다 | 소스와 비슷한 표현을 얻는 경우가 많습니다
코드에 경로가 있으므로 실제로 실행됐습니다 | 정적 연결과 실행 관찰은 다릅니다
찾지 못했으므로 그 기능은 없습니다 | 조사 범위나 도구 지원이 부족할 수 있습니다
도구가 성공 종료했으므로 분석이 완전합니다 | 성공 결과에도 미확인 항목이 남을 수 있습니다
결과에 근거가 있으므로 환각이 없습니다 | 근거와 해석을 함께 검토해야 합니다
REA의 CLI 문서도 성공 종료와 분석 완전성을 구분합니다. 작업이 끝나도 일부 근거나 질문은 미해결로 남을 수 있습니다. 완료 메시지보다 결과의 제한사항을 확인해야 합니다.
분석 결과를 다시 검증할 수 있는 기록
재현 가능한 분석에는 결론을 얻은 조건이 함께 남아야 합니다. 같은 앱 이름이라도 업데이트에 따라 코드가 바뀔 수 있습니다. 함수 주소만 적어 두면 다른 버전에서 대상을 찾기 어렵습니다.
REA의 Evidence 기록은 대상 식별 정보와 근거 위치를 보존합니다. 스냅샷은 조건이 맞는 분석 결과를 재사용하는 기능입니다. 저장된 결과가 최신 버전까지 검증했다는 뜻은 아닙니다.
검증 기록을 남기려면 다음 순서를 따르세요.
· 대상 파일의 버전과 해시를 기록하세요.
· REA와 분석 엔진의 버전을 남기세요.
· 각 결론에 파일 위치나 함수 주소를 연결하세요.
· 원본과 재구현 코드의 입력·출력을 함께 보관하세요.
· 조사하지 못한 조건과 실패한 시험을 따로 적으세요.
해시는 파일이 같은지 비교하는 식별값입니다. 이를 남기면 설명이 어느 배포물을 대상으로 했는지 추적할 수 있습니다. AI가 나중에 결과를 인용할 때도 적용 범위를 구분할 수 있습니다.
로컬 분석과 데이터 외부 전송
로컬에서 분석한다는 말이 전체 작업의 외부 전송을 배제하지는 않습니다. 공식 README에 따르면 REA의 대상 분석은 로컬에서 진행됩니다. 도구 결과는 연결한 AI 에이전트가 받습니다.
외부 모델을 쓰면 분석 결과가 모델 제공자에게 전달될 수 있습니다. 적용되는 데이터 정책은 연결한 서비스에 따라 달라집니다. 회사 앱이나 비공개 파일은 전송 경로부터 확인하세요.
· 모델에 전달되는 코드와 문자열의 범위
· 로그에 포함된 계정 정보와 접근 토큰
· 통신 기록에 담긴 개인정보
· 분석 결과의 저장 위치와 보관 정책
정적 파일 조사와 프로그램 실행도 구분해야 합니다. 실행 관찰은 파일이나 계정 상태에 영향을 줄 수 있습니다. 신뢰하지 않는 프로그램은 분리된 시험 환경에서 다루세요.
개발자가 확인할 보안과 권리
앱에 넣은 비밀정보는 역공학으로 노출될 수 있습니다. OWASP는 배포 패키지에 민감한 정보를 넣는 문제를 설명합니다. 이 위험은 REA가 등장하기 전부터 존재했습니다.
특히 서버 권한을 가진 비밀 API 키를 앱에 포함하면 안 됩니다. OWASP는 정적 비밀값을 서버 쪽에 두는 방식을 안내합니다. 난독화는 추출을 어렵게 해도 비밀 유지를 보장하지 않습니다.
· 배포 파일에 포함된 비밀번호와 비밀 키를 점검하세요.
· 인증 토큰의 권한과 유효기간을 제한하세요.
· 서버에서 요청자의 권한을 검증하세요.
· 노출된 인증정보는 교체하세요.
역공학의 허용 범위는 국가와 계약, 작업 내용에 따라 달라집니다. 호환성 목적이면 모든 행위가 허용된다고 단정할 수 없습니다. 분석과 코드·이미지의 재배포는 별도로 검토해야 합니다.
REA의 MIT 라이선스가 분석 대상의 권리까지 부여하지는 않습니다. 공식 DISCLAIMER.md에서 프로젝트의 이용 원칙을 확인할 수 있습니다. 실제 허용 범위는 적용 법률과 대상 소프트웨어의 약관에서 확인하세요.
소프트웨어 산업에는 어떤 변화가 있나요
REA는 기존 기능을 이해하는 작업의 비용을 낮출 가능성을 보여줍니다. 이는 공개된 분석 사례에서 도출할 수 있는 전망입니다. 산업 전체의 비용 절감 규모는 확인된 수치가 없습니다.
일부 기능의 구현 방식을 알아도 서비스 운영 능력은 별개입니다. 데이터 품질과 장애 대응은 실행 파일 분석만으로 복제되지 않습니다. 따라서 기능 모방의 용이성과 사업 경쟁력을 나누어 평가해야 합니다.
사업 요소 | REA의 분석 범위에서 도출한 시사점
앱 내부의 단일 기능 | 구현 방식 조사와 재구현의 부담이 줄어들 가능성
서버 전용 처리 | 클라이언트 분석만으로 확보하기 어려움
데이터와 접근 권한 | 코드 이해와 별도로 확보·관리 필요
안정성과 운영 신뢰 | 시험, 유지보수, 장애 대응이 계속 필요
기존 소프트웨어 보존 | 작은 기능부터 근거를 남기며 복원 가능
REA의 공개 사례는 소프트웨어 이해 방식의 변화를 보여줍니다. 개발 수요의 소멸을 입증하는 자료는 아닙니다. 기능을 재구현한 뒤에도 호환성과 운영 품질을 검증하는 일은 남습니다.
Injoys
