REA AI 역공학 원리와 복제 한계 정리
REA는 AI 에이전트가 기존 분석 도구로 소프트웨어를 조사하도록 연결합니다. 원본 코드 복원이나 완성품 복제를 보장하지 않으며, ArtCraft 사례에서도 기능 구현과 실무 완성도는 구분해야 합니다.
REA는 Ghidra·Hopper·IDA 등과 AI 에이전트를 연결하는 역공학 도구입니다.
디컴파일 결과는 프로그램의 동작을 해석하는 단서이며 원본 소스 코드와 같지 않습니다.
REA의 Evidence 기록은 분석 근거와 한계를 추적하도록 돕지만 정확성을 보장하지 않습니다.
FilmCraft는 2026년 10월 10일 자체 평가에서 기능 범위와 실무 준비도를 별도로 제시했습니다.
CLI와 MCP 지원은 앱의 자동화 경로를 넓히지만 성능·호환성 검증을 대신하지 않습니다.
REA는 AI가 소스 코드 없이 앱을 분석하도록 돕는 역공학 도구입니다. 기존 분석기를 연결해 기능 재구현을 지원합니다. 다만 원본 코드의 완전한 복원은 보장하지 않습니다. 소프트웨어 시대가 끝났다는 결론도 입증하지 못합니다.
아래 완성도 수치는 FilmCraft의 2026년 10월 10일 자체 평가 기준입니다.
REA란 무엇인가요?
REA는 Reverse Engineer Anything의 약자입니다. 역공학은 완성된 프로그램에서 구조와 동작을 조사하는 작업입니다. REA는 AI 에이전트가 이 작업에 필요한 도구를 호출하게 합니다.
연결 방식은 MCP와 CLI입니다. MCP는 AI와 외부 도구를 연결하는 규약입니다. CLI에서는 터미널에 명령을 입력해 조작합니다. 지원 대상은 REA README에서 확인할 수 있습니다.
구성 요소 | 맡는 역할 | 결과를 읽을 때의 기준
AI 에이전트 | 조사 질문 설정과 결과 해석 | 설명에 근거가 붙어 있는지 확인
REA | 도구 호출과 분석 결과 전달 | 분석 범위와 누락 사항 확인
Ghidra·Hopper·IDA | 실행 파일의 내부 구조 분석 | 지원 형식과 분석기별 한계 확인
실행 관찰 도구 | 실제 동작과 출력 관찰 | 시험한 입력과 실행 환경 확인
REA와 ArtCraft는 역할이 다른 프로젝트입니다. REA는 분석 도구를 연결합니다. ArtCraft의 Crafting Apps는 편집 작업을 수행하는 앱입니다. 두 프로젝트의 존재만으로 제작 과정의 연관성을 단정할 수는 없습니다.
실행 파일에서 무엇을 알아낼 수 있나요?
디컴파일은 실행 코드를 사람이 읽기 쉬운 형태로 바꾸는 작업입니다. 그 결과를 원본 소스 코드와 같다고 볼 수는 없습니다. 컴파일 과정에서 원래 이름과 주석이 사라질 수 있기 때문입니다.
Ghidra는 NSA가 개발하고 유지하는 역공학 도구입니다. 디컴파일과 명령어 분석 기능을 제공합니다. 자동화와 스크립트 실행도 지원합니다. 기능 범위는 Ghidra README에 명시되어 있습니다.
분석 대상 | 얻을 수 있는 단서 | 단서만으로 확정할 수 없는 내용
네이티브 실행 파일 | 의사 코드, 명령어, 문자열, 호출 관계 | 원래 작성한 소스 코드 전체
JavaScript·Electron 앱 | 모듈, 가져오기 관계, 앱 내부 연결 | 서버에서만 실행되는 구현
웹사이트 | 화면 구조, 스크립트, 관찰한 통신 | 서버의 전체 코드와 비공개 데이터
실행 중인 프로그램 | 출력, 상호작용, 파일 변화 | 시험하지 않은 모든 입력의 동작
클라이언트에서 관찰한 요청은 서버 분석의 단서가 됩니다. 그 요청만으로 서버 내부를 모두 복원할 수는 없습니다. REA의 대상별 지원 범위도 공식 README에 구분되어 있습니다.
REA는 AI의 분석을 어떻게 돕나요?
REA는 필요한 분석 결과를 골라 전달하고 근거를 보관합니다. 이 구조는 AI가 긴 출력 전체를 반복해서 읽는 부담을 줄입니다. 작업 흐름은 공식 CLI 문서와 MCP 명세에서 확인할 수 있습니다.
필요한 부분만 읽는 구조
REA는 저장한 분석 결과에서 요약이나 일부 항목을 꺼낼 수 있습니다. 함수나 모듈별로 조사 범위를 좁히는 방식입니다. 분량이 많은 결과를 그대로 대화에 넣는 부담을 줄입니다. 사용 방식은 CLI and Evidence 문서에 설명되어 있습니다.
분석 상태와 결과의 재사용
Ghidra 연동은 열린 프로그램에 디컴파일러를 유지합니다. MCP 세션은 분석 근거를 보관할 수 있습니다. 다만 별도의 CLI 실행은 각각 다른 프로세스입니다. 유지 범위는 설치 문서에서 확인할 수 있습니다.
근거를 남기는 Evidence 기록
Evidence는 분석 결과의 근거와 한계를 담은 기록입니다. 관찰하지 못한 항목은 미확인 상태로 남길 수 있습니다. 결과가 비어 있다는 이유만으로 기능이 없다고 단정하지 않습니다. 이 구분은 MCP runtime contracts에 명시되어 있습니다.
Evidence를 영수증에 비유할 수는 있습니다. 다만 영수증이 있다는 사실이 해석의 정확성을 보장하지는 않습니다. 중요한 결론은 원래 근거와 시험 결과를 다시 대조해야 합니다.
ArtCraft 앱은 무엇을 재구현하나요?
ArtCraft는 익숙한 창작 작업을 수행하는 Rust 앱을 공개합니다. 공식 목록에서는 초기 알파나 개발 중인 상태를 표시합니다. 무료 공개 여부와 실무 대체 가능성은 별도로 판단해야 합니다. 목록은 Crafting Apps 페이지에서 확인할 수 있습니다.
앱 | 주요 작업
PhotoCraft | 이미지 편집
VectorCraft | 벡터 일러스트 제작
FilmCraft | 영상 편집
LightCraft | 사진 관리와 RAW 현상
PdfCraft | PDF 열기와 문서 처리
EffectCraft | 모션 그래픽과 시각 효과
DesignCraft | 페이지 배치와 출판 편집
PhotoCraft는 Photoshop 작업의 재구현을 표방합니다. FilmCraft는 Premiere Pro 작업의 재구현을 표방합니다. 이는 개발팀이 설명하는 프로젝트 목표입니다. 완전한 호환성을 독립적으로 입증한 결과는 아닙니다.
기능 구현과 실무 완성도 비교
기능이 존재하는 것과 실무에 투입할 수 있는 것은 다릅니다. FilmCraft는 두 항목을 별도로 평가합니다. 2026년 10월 10일 비교 대상은 Premiere Pro 26.5.2입니다.
FilmCraft 자체 평가 항목 | 공개 수치 | 수치가 설명하는 범위
기능 범위 | 약 86% | 메뉴·효과·패널·형식 등 구현 항목의 범위
실무 준비도 | 약 56% | 실제 프로젝트에서 대체 가능한 수준에 대한 자체 추정
당시 실무 준비도 추정치는 **약 56%**입니다. 두 수치는 평가 기준이 다릅니다. 차이를 오류율이나 남은 개발 기간으로 바꿔 읽으면 안 됩니다. 수치와 한계는 FilmCraft README의 Status 항목에 공개되어 있습니다.
공식 문서는 큰 영상의 처리 속도를 개선 과제로 제시합니다. Premiere 프로젝트 파일 직접 열기도 미지원 항목으로 설명합니다. 플러그인 호스팅에도 제약이 있습니다.
이 때문에 화면이 닮았다는 사실만으로 대체 여부를 정하기 어렵습니다. 저장과 재열기를 포함한 작업 전체를 확인해야 합니다. 영상 편집에서는 내보낸 파일의 동기화도 검증 대상입니다.
다음 기준은 앱을 비교할 때 사용할 수 있는 점검표입니다.
확인 항목 | 직접 확인할 내용
파일 호환성 | 사용 중인 파일을 열고 다시 저장할 수 있는지
재생 품질 | 실제 작업 영상에서 끊김이나 음성 지연이 생기는지
결과물 | 내보낸 영상의 색상·자막·소리가 의도와 맞는지
작업 복구 | 저장한 프로젝트를 다시 열어 작업을 이어갈 수 있는지
기존 작업 환경 | 필요한 플러그인과 교환 형식을 지원하는지
CLI와 MCP가 바꾸는 앱 사용 방식
CLI와 MCP는 화면 클릭 외의 조작 경로를 제공합니다. PhotoCraft의 설명에 따르면 같은 엔진을 여러 인터페이스에서 호출합니다. UI·CLI·JSON 제어 채널·MCP가 그 경로입니다. 구조는 PhotoCraft README에 공개되어 있습니다.
이는 AI가 앱 기능을 작업 단위로 호출할 기반입니다. 자연어 요청을 실제 명령으로 바꾸는 역할은 에이전트가 맡습니다. 결과를 확인하는 절차는 별도로 필요합니다.
조작 경로 | 적합한 작업 | 확인할 부분
화면 UI | 시각적 판단이 필요한 편집 | 미리보기와 최종 결과의 일치
CLI | 반복 작업과 스크립트 실행 | 입력 옵션과 종료 상태
MCP | AI 에이전트가 조합하는 작업 | 호출한 기능과 결과 검증
여기서 UI의 소멸까지 예측할 근거는 부족합니다. 사람은 결과를 눈으로 확인해야 할 수 있습니다. 자동화 경로와 시각적 편집 화면은 함께 쓰일 수 있습니다.
REA를 이해할 때 흔한 실수
REA의 분석 기능을 완성품 복제 능력과 동일시하면 오해가 생깁니다. 도구 개수만으로 분석 품질을 판단하기도 어렵습니다. 다음 주장은 각각 별도의 근거가 필요합니다.
흔한 주장 | 구분해서 확인할 내용
모든 앱을 몇 분 안에 복원합니다 | 대상·분석 범위·환경별 측정 결과
도구는 항상 126개입니다 | 설치한 버전의 실제 도구 목록
Evidence가 환각을 막습니다 | 근거 기록과 해석 정확성의 차이
Rust로 만들면 항상 빠릅니다 | 실제 작업에서 측정한 처리 성능
화면이 같으면 기능도 같습니다 | 저장·호환성·출력까지 포함한 검증
에이전트를 나누면 합법적인 클린룸입니다 | 접근 분리 방식과 적용되는 이용 조건
도구 목록은 설치 버전의 tools/list로 확인할 수 있습니다. 개별 작업의 사용 가능 여부도 확인해야 합니다. 관련 기준은 MCP 명세에 설명되어 있습니다.
GitHub 트렌딩 순위에는 집계 시점과 기간이 필요합니다. 개발 동기도 개발자의 원문 발언으로 확인해야 합니다. 해지 위약금 때문에 시작했다는 주장은 확인된 사실로 채택하지 않았습니다.
Claude Opus 5.5 사용 주장도 별도의 제작 기록이 필요합니다. 앱이 공개되어 있다는 사실만으로 사용 모델을 입증할 수는 없습니다. 해당 주장은 개발자의 작업 기록이나 발표 원문에서 확인하세요.
클린룸 재구현의 조건
클린룸 재구현은 분석과 구현의 정보 접근을 분리하는 방식입니다. 기능 명세를 만드는 역할과 새 코드를 작성하는 역할을 나눕니다. 에이전트를 서로 다른 대화창에 두는 것만으로는 충분하지 않습니다.
REA 설치 문서는 파일과 네트워크 접근 제한을 설명합니다. 구현 환경이 분석 산출물에 접근하지 못하도록 하는 내용입니다. 분리 방법은 Installation and setup 문서에서 확인할 수 있습니다.
REA의 DISCLAIMER는 결과의 정확성을 보장하지 않습니다. 분석 결과를 얻었다고 원본에 대한 권리가 생기지도 않습니다. 프로그램별 권리와 이용 조건은 별도로 확인해야 합니다. 적용 범위는 REA DISCLAIMER에 명시되어 있습니다.
Decompilation, reconstruction, heuristics, and AI-assisted analysis may be incomplete or incorrect. REA DISCLAIMER, Analysis results and generated output
이 문구는 AI 분석이 불완전하거나 틀릴 수 있다는 뜻입니다. 클린룸이라는 명칭도 적법성을 자동으로 보장하지 않습니다. 공개나 상용화를 계획한다면 대상의 이용 조건부터 확인하세요.
로컬 분석과 AI 전송의 차이
로컬 분석이 모든 정보의 외부 전송 차단을 뜻하지는 않습니다. REA는 분석 대상 파일을 로컬에서 처리한다고 설명합니다. 도구 결과를 받는 에이전트에는 모델 제공자의 정책이 적용됩니다. 이 구분은 REA FAQ에 안내되어 있습니다.
분석 결과에는 파일 내부의 문자열이 포함될 수 있습니다. 실행 기록에는 계정 정보가 섞일 수 있습니다. 업무용 앱을 조사한다면 아래 항목을 먼저 확인하세요.
· 분석 결과에 포함될 수 있는 개인정보와 비밀정보
· 에이전트가 모델 제공자에게 보내는 도구 출력
· 모델 서비스의 저장·학습·보존 정책
· 분석 보고서와 로그를 공유할 수 있는 범위
분석 대상에 AI를 속이는 지시문이 들어갈 수도 있습니다. REA 문서는 이를 신뢰하지 않는 데이터로 취급하도록 설명합니다. 파일 속 지시문을 사용자의 명령으로 받아들이면 안 됩니다. 처리 원칙은 MCP 명세에 있습니다.
직접 검증할 때의 순서
검증은 재현하려는 기능을 좁게 정하는 데서 시작하세요. 앱 전체를 이해한다는 목표는 완료 기준이 모호합니다. 입력과 기대 결과를 정하면 분석의 유용성을 판단하기 쉽습니다.
· 분석 권한이 있는 프로그램을 선택하세요.
· 확인할 기능과 시험 입력을 정하세요.
· REA와 분석기의 버전을 기록하세요.
· 근거와 미확인 항목을 구분해 저장하세요.
· 허용된 환경에서 실제 동작과 분석 결과를 대조하세요.
· 재구현했다면 같은 입력으로 결과를 비교하세요.
· 실패한 입력과 지원하지 않는 조건을 남기세요.
보고서에는 대상 파일의 해시값도 기록할 수 있습니다. 해시는 같은 파일인지 구분하는 값입니다. 버전과 시험 조건이 남아 있어야 다른 사람이 결과를 재검증하기 쉽습니다.
소프트웨어의 경쟁력은 어디에 남나요?
재구현 가능성이 커져도 제품의 모든 가치가 복사되지는 않습니다. 클라이언트 분석만으로 서버 데이터가 확보되는 것은 아닙니다. 사용자 관계와 서비스 운영 능력도 별도입니다.
공개 문서를 바탕으로 경쟁 기준이 달라질 것으로 예상할 수 있습니다. 기능을 얼마나 빨리 구현했는지만으로 평가하기 어려워집니다. 검증 가능한 품질과 운영 능력의 비중을 함께 봐야 합니다.
경쟁 요소 | REA와 재구현 사례가 보여주는 점
기능 구현 | 기존 동작을 조사하는 도구 연결이 쉬워짐
제품 완성도 | 기능 존재 여부와 실무 준비도를 나눠 평가해야 함
자동화 접근성 | CLI·MCP 등 호출 가능한 인터페이스가 활용 경로를 넓힘
서비스 운영 | 서버 데이터와 사용자 관계는 별도로 구축해야 함
이 표는 공식 문서에 근거한 해석입니다. 시장 전체의 수익 변화를 측정한 결과는 아닙니다. 기업별 영향은 제품의 품질과 운영 구조에 따라 달라질 수 있습니다.
Injoys
