REA

REA(Reverse Engineer Anything)는 AI가 프로그램의 작동 원리를 조사하도록 돕는 역공학 도구입니다. 역공학은 완성된 물건을 살펴보고 안쪽 구조를 알아내는 일입니다. 앱의 설치 파일, 실행 파일, JavaScript 묶음, 웹 화면 등을 대상으로 삼고, 분석 결과에 근거와 한계를 붙여 AI에게 돌려줍니다.

이번에는 저장소의 구현을 읽고 두 가지 정적 시험을 했습니다. 하나는 Windows의 실제 whoami.exe, 다른 하나는 직접 만든 작은 JavaScript 표본입니다. 파일을 분석했으며, 대상 프로그램을 실행하거나 통신을 관찰하지는 않았습니다. 이 구분이 REA를 읽는 출발점입니다.

완성된 프로그램에서 작동 원리를 찾아갑니다

예를 들어 어떤 앱의 검색 기능이 어떻게 연결되는지 알고 싶다고 하겠습니다. 화면만 보면 검색 결과가 나온다는 사실만 압니다. 파일을 조사하면 어떤 코드가 입력을 받고, 어느 모듈을 부르며, 어떤 주소가 적혀 있는지까지 따라갈 수 있습니다.

하지만 거기에도 선이 있습니다. 코드에 주소가 적혀 있다는 사실과 그 주소로 실제 요청이 나갔다는 사실은 다릅니다. 앞의 질문은 파일 분석으로 좁힐 수 있고, 뒤의 질문에는 실행 중에 얻은 관찰이 필요합니다. REA는 그런 조사 경로를 여러 종류의 대상에 제공합니다.

대상이 바뀌면 필요한 분석기도 바뀝니다

REA라는 이름 하나로 연결하지만, 안쪽에는 서로 다른 전문 도구가 있습니다. 실행 파일을 읽는 도구와 JavaScript 문장을 읽는 도구의 준비물부터 다릅니다.

조사 대상	문서가 안내하는 결과와 준비물
네이티브 실행 파일	어셈블리·의사 코드·참조 관계, Ghidra 등 필요
JavaScript·Electron 앱	모듈·가져오기·정적 관계, 네이티브 분석기 없이 가능
웹 화면과 실행 상태	페이지·스크립트·네트워크 관찰, 브라우저 연결 필요
.NET 파일	메타데이터와 중간 명령어를 정적으로 조사
Android APK	선언·클래스·메서드 조사, JADX와 JDK 등 필요

이 표는 저장소가 설명하는 경로입니다. 이번에 직접 시험한 것은 첫째와 둘째뿐입니다. 도구 목록이 길다는 이유로 모든 운영체제에서 모든 기능이 된다고 읽으면 안 됩니다.

답에 붙은 출처표가 분석 결과만큼 중요합니다

REA는 결과에 Evidence라는 기록을 붙입니다. 어느 파일을 봤고, 누가 분석했으며, 어떤 방법으로 얻은 답이고, 무엇을 아직 모르는지 담는 봉투라고 생각하면 됩니다.

좋은 점은 다음 질문을 구체적으로 만들 수 있다는 것입니다. 「그럴 것 같다」로 끝내는 대신 어느 파일의 어느 위치가 근거인지, 추론에 어떤 빈칸이 남았는지를 물을 수 있습니다. 다만 봉투가 있다고 답이 자동으로 참이 되지는 않습니다. 내용은 사람이 다시 읽어야 합니다.

작은 표본에서도 모르는 부분이 남았습니다

JavaScript 시험에는 파일을 세 개만 넣었습니다. 한 함수에는 고정된 주소가 적혀 있고, 다른 함수는 주소를 외부 입력으로 받습니다. REA는 고정 주소를 코드 위치와 함께 찾아냈습니다. 입력으로 정해지는 요청은 일부가 불명확하다고 남겼습니다.

더 흥미로운 것은 완료 표시였습니다. 파일과 관계를 담는 그래프는 complete였는데, 더 깊은 의미 분석의 전체 상태는 unknown이었습니다. 두 표시가 서로 다른 것을 세고 있었기 때문입니다. 읽기를 끝냈다는 말로 프로그램을 전부 이해했다는 결론을 내릴 수는 없습니다.

실행 파일에서는 함수 이름 다음으로 참조를 따라갔습니다

Windows의 whoami.exe는 현재 사용자 정보를 표시하는 작은 프로그램입니다. REA에서 파일을 열고 계정 관련 API를 찾은 뒤, 그 API를 참조하는 함수와 의사 코드를 조회했습니다.

의사 코드는 기계어를 사람이 읽기 좋은 모양으로 바꾼 것입니다. 개발자가 처음 쓴 소스가 그대로 복구된 것은 아닙니다. 읽은 함수에는 타입 추정 경고도 있었습니다. 그래서 이번 기록은 「이런 호출과 코드 형태가 보였다」까지이고, Windows 내부 서비스나 실제 계정 조회 과정을 실행 관찰한 기록은 아닙니다.

제 QA에서는 원인을 좁히는 조사 단계에 쓸 수 있습니다

테스트에서 이상한 결과를 발견하면, 그다음에는 왜 그런지 알아봐야 합니다. 파일에 남은 코드와 설정, 실행 중의 관찰을 함께 놓는 도구는 그 단계에 도움이 될 수 있습니다.

현재 수확은 근거를 남기면서 원인 후보를 좁히는 작업 방식입니다. 이번 시험으로 게임 테스트가 늘거나 판정기가 개선되지는 않았습니다. 실제 업무에 붙일 때는 문제 하나를 고르고, 필요한 증거를 얻는지부터 확인할 생각입니다.

여기부터는 자세한 기록입니다

소스 분석은 2026-10-19의 커밋 e4c3d72396bf925a45724ce8b18b238b0d23d787을 기준으로 했습니다. 그 저장소의 패키지 버전은 6.7.0입니다. 실제 시험에 쓴 연결 서버는 rea-agents 6.5.0이었고, 자신이 등록한 MCP 도구를 207개로 보고했습니다. 두 버전을 같은 대상으로 취급하지 않았습니다.

CLI와 MCP는 공통 조사 코드를 부릅니다

이 도구에는 터미널용 CLI와 에이전트용 MCP 입구가 있습니다. 기능 추적 경로를 읽어 보니 양쪽이 같은 application 서비스를 부르고, 그 아래의 domain 코드가 관계를 계산한 뒤 Evidence를 만들었습니다. 인터페이스가 둘이라고 분석엔진이 둘인 구조는 아닙니다. 공통 서비스

그래서 제가 가져갈 설계는 결과의 해석 규칙을 한곳에 두는 것입니다. 같은 파일을 CLI에서 읽을 때와 에이전트에서 읽을 때 근거의 의미가 달라지면, 나중에 두 결과를 비교할 기준이 사라집니다. 전체 구현의 모든 경로가 동등한지 시험한 것은 아니며, 여기서는 읽은 기능 추적 경로를 근거로 삼았습니다.

Evidence의 무결성과 결론의 진실성은 별개입니다

Evidence 스키마는 대상 digest, 분석기, 작업, 입력, 원시·정규화 결과, confidence, authority, limitations 등을 검사합니다. 생성·파싱 코드는 내용에 따른 식별자도 계산하고 확인합니다. 그러나 틀린 추론을 담은 기록도 내부적으로는 일관될 수 있습니다.

구현에서 confidence의 기본값은 observed이고 한계 배열은 비어 있어도 됩니다. 따라서 필드가 있다는 사실만으로 보고서를 신뢰하면 안 됩니다. 실제 기능 추적 생산자는 inferred와 analyst-inference를 지정하고 원본 Evidence 링크를 넣습니다. 봉투의 형식과 생산자가 넣은 의미를 함께 읽어야 합니다. Evidence 계약, 파생 결과 생산자

네이티브 시험은 파일을 바꾸지 않고 끝냈습니다

시험 환경은 Windows x64, 연결된 REA 6.5.0, Ghidra 12.1.4입니다. 대상은 로컬 whoami.exe의 x86-64 PE 파일이며 크기는 98,304바이트였습니다. 파일을 실행하지 않고 열기 → 개요 → API 검색 → 호출자 조회 → 의사 코드 조회 → 닫기 순서로 진행했습니다.

관찰	결과
개요의 프로시저·문자열 목록	341개·308개 — 이 분석기의 인식 결과
계정 관련 API 검색	OpenProcessToken, GetTokenInformation, LookupAccountSidW, GetUserNameExW
참조 조회	토큰·SID 관련 API를 참조하는 주소 반환
의사 코드	0x140003bc0, 0x140005e1c 두 함수 조회
대상 보존	전후 SHA-256 일치, 세션 닫기 완료

파일 SHA-256은 23240ef9f8b0a9a324110b1c2331de31dc1b0e08f5359cb707e51a939af56cd3입니다. 개요 Evidence는 ev_e2a77bec26ce4055d8c40d4469bfff07516e243d2ddc236abd15218219a1444c였습니다. 프로시저 수에는 분석기가 목록화한 항목이 들어가므로, 완전한 원본 함수 개수로 바꿔 말하지 않습니다.

의사 코드의 observed 표시는 분석기에서 해당 코드를 얻었다는 관찰입니다. 그 함수가 실행됐다는 뜻이 아닙니다. 이 시험으로 DLL 내부 구현이나 레지스트리·네트워크 접근을 확인했다고 할 수도 없습니다. Windows Ghidra 지원 경계

JavaScript 시험에서 complete와 unknown이 동시에 나왔습니다

직접 만든 표본은 package.json, main.js, store.js입니다. JavaScript 두 파일에는 고정 주소의 fetch, 입력 주소의 fetch, 파일 저장 함수 호출을 넣었습니다. 분석은 텍스트 586바이트를 읽었고 파싱 실패는 0개였습니다.

REA는 고정된 https://example.invalid/health를 main.js 11행의 정적 endpoint로 반환했습니다. 입력으로 받는 fetch(endpoint)는 main.js 4행의 요청 해석이 부분적이라는 unknown을 남겼습니다. 이 주소로 요청하지 않았으며 저장 함수도 실행하지 않았습니다.

서로 다른 판정 대상	반환 상태	제가 읽은 의미
application graph	complete, 누락 0	해당 그래프가 보고한 범위의 완료
semantic graph	unknown, unknown 기록 22개	세부 의미·호출·값 관계에는 빈칸 존재
실제 실행·통신	미시험	코드가 보였다는 사실로 대신할 수 없음

unknown 22개는 오류 22개가 아닙니다. 입력값, 동적 호출, 외부 함수 등 정적 분석으로 해석하지 못한 관계의 기록입니다. 일부 동작은 작은 표본에서도 정적으로 확정할 수 없었습니다. 시험 Evidence는 ev_5db40f819569c3d83934d078a0d0ce1e8b6251c62cc8e4113addc5bd8f59bfc5이고, 최상위 confidence는 derived였습니다. 그래프의 증거 규칙

설치 지침과 현재 사용 가능한 도구를 구분해야 합니다

공식 시작 명령은 npx rea-agents setup입니다. 설정안을 검토한 뒤 MCP와 대응 스킬을 등록하고 에이전트를 다시 연결하는 절차입니다. 스킬 파일만 설치해 둔 상태는 서버가 연결된 상태와 다릅니다. 네이티브 분석에는 별도의 엔진 준비도 필요합니다. 설치 안내

이번 조사에서는 기존 연결을 사용했고 설정을 바꾸거나 도구를 업그레이드하지 않았습니다. 연결 서버의 실제 스키마를 기준으로 호출했습니다. 저장소의 최신 지침이 설치된 구버전에 없는 기능을 설명할 수 있다는 경고도 그대로 적용됩니다. 스킬의 버전 경계

이번 수확은 근거를 유지하는 조사 방식입니다

소스가 충분한 일반 저장소는 보통의 파일 검색과 코드 읽기로 조사하면 됩니다. REA가 필요한 자리는 배포된 파일의 내부, 코드와 실행 관찰의 연결처럼 지금 가진 자료만으로 답하기 어려운 질문입니다.

현재 판정은 원인 조사와 정적 탐색에 쓸 수 있는 도구입니다. 두 표본에서 그 경로가 작동하는 것은 확인했습니다. 반면 브라우저·Electron 실행 관찰, APK·펌웨어 분석, 다른 네이티브 엔진, 저장소 전체 테스트, 실제 게임 QA 연결은 시험하지 않았습니다. 조사 시간 단축이나 정확도 향상도 비교 측정하지 않았습니다.

가져갈 규칙은 답마다 대상·방법·모르는 범위를 같이 남기는 것입니다. 이번에 끝낸 것은 그 규칙을 소스와 두 시험에서 확인한 분석이지, 모든 기능의 검증이나 QA 파이프라인 통합은 아닙니다.