rea 딥다이브
— 에이전트에게 역공학 도구와 증거 장부를 쥐여주기

CLI·MCP 서버

빠른 판단

무엇

앱 모듈·네이티브 바이너리·웹 동작 분석을 CLI·MCP와 공통 증거 형식으로 연결하는 역공학 작업대

이럴 때

소스가 없는 앱·파일을 조사하며 관찰 근거·추론·미확인 범위를 나눠 분석 결과를 기록할 때

입력

로컬 앱·바이너리·웹 동작과 분석 요청

결과

경로·해시·도구·관찰 위치·한계를 포함한 분석 증거

1프로젝트 한줄 요약

rea는 에이전트와 사람이 함께 사용하는 역공학 도구 연결 계층입니다. JavaScript 앱의 모듈 관계를 살피고, 네이티브 바이너리를 분석 엔진에 보내고, 웹페이지의 동작을 관찰하는 기능을 하나의 CLI와 MCP 서버로 제공합니다.

이 저장소의 핵심은 분석 결과를 얻는 것과 그 결과를 믿을 수 있는 범위를 함께 표현하는 데 있습니다. 코드에는 파일 경로·해시·분석 도구·관찰 위치·한계를 묶은 Evidence가 있고, 관찰한 사실과 추론을 구분하는 필드도 있습니다.

1-1. 질문에서 근거까지 이어지는 짧은 흐름

1. 대상 지정: 조사할 로컬 파일이나 앱, 브라우저 대상을 고릅니다.
2. 기능 선택: 파일 형식과 사용 가능한 도구에 맞는 분석을 요청합니다.
3. 경계 검증: 입력 형식·선택한 대상·도구의 응답을 확인합니다.
4. 결과 해석: 정규화한 결과와 원시 결과, 근거 위치와 미확인을 함께 읽습니다.

이 글에서 따라갈 대표 기능은 로컬 EVM 바이트코드의 인터페이스 후보를 찾는 inspect_evm_interface입니다. 기능 하나가 계약·서비스·제공자·CLI·MCP를 통과하므로, 거대한 저장소를 작은 수직 단면으로 읽기 좋습니다.

2왜 주목받는가

선정 근거는 TrendShift Daily #5(2026-10-23)입니다. 2026-10-23 GitHub 기준 스타 368,189개, 포크 92,254개이며, 생성일은 2026-04-14입니다. 이 숫자는 관심의 규모를 보여주지만, 어떤 기능이 얼마나 정확한지 또는 관심이 왜 늘었는지까지 입증하지는 않습니다.

2-1. 코드에서 읽히는 세 가지 매력

• 에이전트의 질문을 실제 도구로 연결합니다. README는 앱의 기능을 조사해 구현 원리를 이해하는 흐름을 소개합니다. 소스의 src/cli.ts와 src/server/는 사람이 쓰는 명령과 에이전트 도구를 각각 등록합니다.
• 대상의 범위가 넓습니다. src/artifacts/, src/browser/, src/dotnet/, src/android/, src/evm/처럼 형식별 구현이 실제로 분리돼 있습니다. 범위가 넓다는 판단은 디렉토리와 등록 코드를 근거로 합니다.
• 조사 과정도 자료로 만듭니다. EvidenceLedger.record()는 중복을 구분하고 충돌을 거부합니다. 요약을 반환하더라도 원래 근거를 다시 읽는 통로가 있습니다.

에이전트가 도구를 호출하게 만드는 데서 한 걸음 더 나아가, 호출 결과를 검토 가능한 자료로 다룬다는 점이 학습 가치입니다. 이것이 관심을 끌 만한 이유라는 해석은 가능하지만, 유입 경로나 사용자 증가 원인을 측정한 결론은 아닙니다.

2-2. 경쟁·대체 도구와의 역할 비교

접근 방식	잘 맞는 역할	rea가 더하는 점과 대가
Hopper · Ghidra · IDA	각 엔진이 담당하는 네이티브 분석	rea는 이들을 제공자로 연결합니다. 공통 호출과 근거 형식을 얻지만 엔진 설치·지원 범위는 계속 따릅니다.
개별 엔진용 MCP	특정 엔진의 기능을 에이전트에 노출	rea는 네이티브 밖의 앱·웹·파일 분석까지 한 저장소에서 연결합니다. 그만큼 계약과 제공자 수가 많아집니다.
범용 코딩 에이전트	질문 해석, 설명, 구현 작업 진행	rea는 에이전트가 쓸 조사 도구를 제공합니다. 에이전트 자체의 추론 품질이나 모델 비용을 대신 해결하지는 않습니다.
직접 작성한 분석 스크립트	한 파일 형식의 좁은 자동화	공유 검증·취소·정리·근거 보관을 얻습니다. 단순한 일회성 작업에는 이 구조가 오히려 무겁게 느껴질 수 있습니다.

위 표는 README와 제공자 구성에서 읽은 역할 비교입니다. 동일 대상의 정확도·속도·메모리를 비교한 벤치마크 표는 아닙니다. 특히 rea와 Ghidra는 이 구성에서 함께 쓰이므로, 언제나 서로 대체하는 관계라고 보면 곤란합니다.

3기술 스택 전체 지도

최상위 package.json의 패키지 이름은 rea-agents, 버전은 6.7.0입니다. 아래 npm 버전은 선언 파일과 package-lock.json에 기록된 고정 버전입니다.

3-1. 백엔드에 해당하는 로컬 분석 런타임

기술 · 명시된 버전	쓰이는 곳	배울 점
Node.js	^22.23.4 || ^24.22.1 || >=26.12.1. .nvmrc는 24.18.0 고정.	지원 범위와 개발 기준 버전은 다릅니다.
TypeScript 7.0.2	애플리케이션·도메인·어댑터 구현. type: module, NodeNext, ES2023.	타입이 계층 사이의 약속을 표현합니다.
MCP SDK 2.3.1	@modelcontextprotocol/server와 @modelcontextprotocol/client 모두 사용.	도구를 제공하는 쪽과 외부 도구를 연결하는 쪽을 구분합니다.
incur 0.6.1	src/cli.ts의 Cli.create()와 명령 등록.	명령 인자를 업무 로직과 분리합니다.
zod 4.4.3	설정·입력·출력 스키마의 safeParse().	런타임에서 외부 값을 다시 검증합니다.
pino 10.4.0	src/logger.ts의 JSON 로그.	표준 오류로 로그를 보내 결과 출력과 섞이지 않게 합니다.
Babel 8.0.4	@babel/parser·@babel/types로 JavaScript 구문 분석.	문자열 찾기보다 구문 구조를 근거로 관계를 조사합니다.
asar 4.2.0	@electron/asar로 Electron 배포 아카이브 처리.	압축·패키징된 배포물의 경계를 배웁니다.
trace-mapping 0.3.31	src/javascript/sourceMaps/TraceSourceMap.ts.	배포 코드 위치와 원본 소스 위치를 연결합니다.
playwright-core 1.58.2	브라우저 시나리오·Electron 실행 관찰 제공자.	정적 파일 분석과 실제 동작 관찰을 구분합니다.
evmole 0.9.3	별도 워커에서 로컬 EVM 인터페이스 후보 추론.	외부 분석기의 응답을 공통 결과로 변환합니다.
frida 17.23.2	optionalDependencies의 선택 의존성.	특정 기능의 요구 도구를 기본 실행 경로와 분리합니다.

여기서 “서버”는 먼저 로컬 MCP 프로세스를 뜻합니다. src/main.ts는 기본적으로 serveStdio를 쓰고, rea mcp --http 경로에서는 별도의 Streamable HTTP 구현을 불러옵니다. 이 코드 구성을 중앙 웹 서비스의 API 서버로 이해하면 출발점이 어긋납니다.

3-2. 프론트엔드와 문서 사이트

website/README.md와 실제 폴더를 보면 제품의 중심 조작 화면은 CLI·에이전트 쪽입니다. 공개 안내 사이트는 website/public/의 HTML·CSS·작은 JavaScript, website/templates/의 공통 조각, website/locales/의 gettext 번역으로 구성됩니다.

사이트 안내의 “npm 의존성 없음”은 이 정적 사이트에 대한 설명입니다. 같은 저장소의 개발 의존성에는 문서용 vitepress 1.6.4가 있습니다. 사이트 생성 보조 도구도 website/requirements.txt에 CairoSVG==2.9.1과 polib==1.2.0을 명시합니다.

3-3. 인프라·빌드·검증

도구 · 설정	확인한 값	소스에서 읽을 내용
npm	npm@11.16.0	packageManager와 잠금 파일로 도구·의존성 기준을 남깁니다.
컴파일러 선택	tsrs 0.18.0-ts7.1.0-dev.20260929	scripts/run-typescript.mjs는 Windows에서 TypeScript, 지원 플랫폼에서 tsrs를 선택합니다.
호환 컴파일러	typescript6 → 6.0.3 typescript-termux → 5.9.3	별칭 패키지가 있으므로 저장소에 컴파일러가 하나뿐이라고 단정하지 않습니다.
빌드·캐시	rolldown 1.2.12 turbo 2.11.7	scripts/bundle-runtime.mjs는 CLI/MCP 진입점을 묶고, 외부 의존성과 동적 로딩 경계를 보존합니다.
테스트·정적 검사	vitest 5.0.3 oxlint 1.87.0 · oxfmt 0.72.0	타입 검사, import 경계 검사, 단위·경계·인수 테스트를 구분합니다.
GitHub Actions	.github/workflows/ci.yml	변경 분류 후 필요한 검증 경로를 고릅니다. EVM 실도구 검증과 SQLite 런타임 호환성은 별도 파일에 있습니다.
정적 배포	GitHub Pages · Cloudflare	.github/workflows/website-pages.yml은 website/_site를 준비하고, website/wrangler.toml은 같은 정적 자산 디렉토리를 지정합니다.

의존성 목록을 읽을 때는 프로그램 실행에 필요한 도구와 특정 분석 기능에만 필요한 도구를 나누어야 합니다. 최상위에 Cargo.toml·pyproject.toml·go.mod·Dockerfile은 없습니다. Rust 기반 컴파일러 의존성이 있다고 rea 본체를 Rust 서비스로 설명하거나, 분석 가능한 Go 파일을 Go 백엔드로 설명하면 안 됩니다.

4아키텍처 심화 분석

2026-10-31: Android 외부 호출과 .NET 필드 상수

고정 SHA d48e472에서 JADX bridge identity는 10입니다. Android method reference는 APK에 직접 관측된 외부 DEX 클래스·메서드 호출을 조회할 수 있고, target_definition=external 및 reference_scope=direct_dex_invokes로 범위를 표시합니다. 전체 framework 메서드 목록·reflection·JNI·런타임 dispatch를 복원한 결과로 읽으면 안 됩니다. 자원 한도 초과는 resource_constraint로 보고하며 호출 위치 coverage도 따로 제공합니다.

.NET 필드 조회는 assembly를 로드하지 않고 Constant 테이블의 선언·원시 바이트·값을 읽습니다. i8/u8은 JSON 정밀도를 잃지 않도록 십진 문자열로 반환합니다. 메타데이터 기본값은 런타임 상태가 아니며 필드 비교가 상수 차이까지 비교한다는 뜻도 아닙니다. 누락·중복·불일치 선언은 unavailable과 제한 근거로 남깁니다.

4-1. 시스템 전체를 한 장으로 보기

실행 파일 입구는 scripts/rea.mjs입니다. src/cli.ts는 일회성 명령을 만들고, src/main.ts는 MCP 실행을 맡습니다. 아래 그림은 docs/architecture.mermaid와 실제 import 관계를 바탕으로 줄인 것입니다.

[사람의 터미널]                       [에이전트 / MCP 클라이언트]
       |                                        |
       v                                        v
 src/cli.ts                               src/main.ts
 명령 등록                                stdio 기본 / HTTP 선택
       |                                        |
       |                               src/server/register*Tools.ts
       +--------------------+-------------------+
                            |
               src/composition/ : 구현 조립
                            |
          +-----------------+-----------------------+
          |                                         |
          v                                         v
 [네이티브 분석 흐름]                       [독립 파일 분석 예: EVM]
 BinarySession                             EvmInterfaceService
          |                                         |
 SessionProviderRouter                     EvmInterfacePort
          |                                         |
 AnalysisProviderRegistry                  EvmoleInterfaceProvider
          |                                         |
 Hopper / Ghidra / IDA                      자원 제한을 둔 Node 워커
          |                                         |
          +-----------------+-----------------------+
                            |
                 도메인 결과 / Evidence
                            |
        MCP 조사 기록: InvestigationRecords / EvidenceLedger
        CLI: 명령별 결과 반환과 해당 자원의 정리

 공통 기반: src/domain/ + src/contracts/
 외부 경계: 파일 읽기 / 프로세스 / 브리지 / 브라우저
 자원 관리: src/process/ + src/artifacts/

그림의 두 갈래가 중요합니다. 모든 분석이 네이티브 세션이나 Hopper를 통과하지 않습니다. EVM은 src/composition/evm.ts에서 별도의 서비스를 조립하는 대상 바이너리 세션과 독립적인 파일 분석 기능입니다.

4-2. 패턴 ① 포트와 어댑터: 업무 규칙과 실행 수단 나누기

src/application/evm/EvmInterfacePort.ts는 inspect()와 선택적 close()를 약속합니다. EvmInterfaceService의 생성자는 이 포트만 받습니다. 실제 EVMole 구현을 고르는 곳은 createEvmInterfaceService()입니다.

// src/domain/result.ts — 실제 타입 정의 발췌
export type Result<T, E> =
  | { readonly ok: true; readonly value: T }
  | { readonly ok: false; readonly error: E };

// src/composition/evm.ts — 조립 부분 발췌
new EvmInterfaceService(new EvmoleInterfaceProvider(environment));

서비스의 inspect()는 입력을 Zod로 검증하고 제공자를 호출한 뒤, 출력도 다시 검증합니다. 응답의 경로·인코딩·파일 형식·SHA-256이 선택한 입력 및 대상 식별과 맞지 않으면 AnalysisOutputError를 돌려줍니다. 제공자가 응답했다는 이유만으로 올바른 대상의 응답이라고 믿지 않는 것입니다.

src/server/registerEvmTools.ts와 src/cli/evmCommands.ts는 이 서비스를 공유합니다. 다만 두 어댑터의 입출력 기능이 완전히 같지는 않습니다. EVM의 detail: "summary" 처리는 MCP 등록 코드에서 제공하며, CLI 명령에는 해당 옵션이 없습니다.

4-3. 패턴 ② 일관된 제공자 선택: 모호함을 오류로 남기기

src/application/binary/AnalysisProviderRegistry.ts의 생성자는 제공자 ID를 compareUnicodeCodePoints()로 정렬합니다. 등록 순서를 바꿨다고 표시 순서나 자동 선택 결과가 우연히 달라지지 않게 하려는 설계입니다.

select()로 시작하는 자동 선택 경로에서는 사용 가능한 프로필이 하나일 때 auto-single-candidate로 선택합니다. 여럿이면 ambiguous 오류를 반환합니다. 사용 가능한 후보가 없으면 binding: null을 반환할 수 있으며, 이 상태에서 실제 작업 가능 여부는 요청한 기능에 따라 달라집니다.

// AnalysisProviderRegistry.ts — 분기를 설명용으로 축약
if (usable.length === 0) return unboundSelection;
if (usable.length > 1) return ambiguousSelectionError;
return bindSingleProvider(usable[0]);
// 위 세 반환 이름은 설명용이며 실제 함수명이 아닙니다.

src/application/binary/SessionProviderRouter.ts는 선택된 심층 분석 제공자와 서로 겹치지 않는 보조 기능을 묶어 대상별 경로를 만듭니다. 이 선택을 조사 중 임의로 다른 엔진으로 바꾸면 앞뒤 결과의 의미가 달라질 수 있으므로, 대상·제공자·분석 프로필의 결합을 유지합니다.

4-4. 패턴 ③ 불변 근거 장부: 결과와 출처를 함께 보관하기

src/domain/evidence.ts의 스키마에는 subject, provider, operation, parameters, raw_result, normalized_result, confidence, locations, limitations 등이 있습니다. 원시 결과와 공통 형식으로 바꾼 결과를 함께 표현합니다.

구분	쉬운 뜻	EVM 사례에서의 주의점
observed	직접 읽거나 관찰한 사실	어떤 파일 바이트를 읽었는지가 기준입니다.
derived	사실에 규칙·계산을 적용해 얻은 결과	계산 방법과 입력이 있어야 검토할 수 있습니다.
inferred	분석으로 추정한 해석	EVM 인터페이스 후보의 근거 레코드는 이 값으로 생성됩니다.
unknown	아직 확인하지 못한 상태	confidence의 네 번째 값이 아닙니다. 결과 필드와 별도 Unknown 기록 체계에서 표현합니다.

src/application/investigation/EvidenceLedger.ts의 record()는 스키마와 무결성을 검증한 근거의 ID가 새로 들어오면 added, 의미상 같은 내용이면 duplicate를 반환합니다. 같은 ID의 의미상 내용이 다르면 EvidenceIntegrityError입니다. 단, 대상의 표시 이름과 로컬 경로 차이는 중복 판정에서 제외합니다. import()는 충돌과 Unknown 관계를 검증한 뒤 장부를 합칩니다.

InvestigationRecords는 이 장부를 감싼 조사 단위 소유자입니다. recordEvidence(), evidenceById(), exportEvidenceBundle()처럼 소비자가 필요한 기능만 제공합니다. 내보내기는 묶음 객체를 반환하며, Map 장부를 자동으로 파일에 쓰지는 않습니다. 세션 기록이 언제나 자동으로 디스크에 영구 저장된다고 읽어서는 안 됩니다.

MCP EVM 도구에서 요약을 요청하면 requireAnalysisViewRetention()으로 보관 가능 여부를 확인하고, summarizeRetainedAnalysis()로 원본에 연결된 보기 결과를 만듭니다. 응답을 짧게 만드는 것과 원래 근거를 버리는 것은 다른 작업입니다.

4-5. 패턴 ④ 자원 소유권: 실행이 끝난 뒤의 정리까지 책임지기

src/evm/EvmoleInterfaceProvider.ts의 inspect()는 #tail로 같은 제공자 인스턴스의 작업을 순서대로 이어 붙입니다. 내부에서는 readStableArtifact()로 입력을 읽고 전용 작업 디렉토리에 복사한 뒤, runOwnedCommand()로 별도 Node 워커를 실행합니다.

실제 실행 인자는 prlimit의 주소 공간·파일 크기·CPU 제한과 Node의 --max-old-space-size=256을 포함합니다. NODE_OPTIONS는 이 워커의 환경에서 제외합니다. 호출자가 물려준 더 작은 제한은 selectEvmWorkerLimits()에서 보존합니다.

// src/evm/EvmoleRelease.ts — 고정 예산 발췌
inputBytes: 4 * 1024 * 1024,
outputBytes: 16 * 1024 * 1024,
diagnosticBytes: 1024 * 1024,
addressSpaceBytes: 3 * 1024 * 1024 * 1024,
// CPU 상한은 별도 상수 EVM_CPU_SECONDS = 30
// 워커 명령의 기본 기한은 DEFAULT_EVM_TIMEOUT_MS = 30_000

close()는 진행 중인 순서를 기다린 뒤 워커 관련 정리와 파일 자원 해제를 확인합니다. 실패하면 ProviderCleanupError에 남은 자원을 연결하고, 실패한 #closePromise를 비워 다시 정리할 통로를 남깁니다. 성공 결과를 얻었다고 자원 정리까지 성공한 것은 아닙니다.

안정적인 도구 연결 코드는 성공 경로뿐 아니라 취소·부분 결과·정리 실패를 결과 모델의 일부로 다룹니다.

4-6. HEAD의 수정으로 읽는 오류 설계

HEAD 제목은 fix(evm): report the carrier input allowance as a file-size constraint (#6414)입니다. 현재 src/evm/EvmoleFailures.ts의 evmInterfaceFailure()는 파일 읽기 단계의 limit 오류 중 boundary === "file-size"를 AnalysisResourceConstraintError의 file-size로 변환합니다.

오류에는 maximum_input_bytes, retryable: false, 복구 안내가 붙습니다. 이 릴리스에 런타임 재정의가 없고 timeout_ms가 입력 허용량을 늘리지 않는다는 점도 명시합니다. 4 MiB는 디코딩 전 원본 파일의 제한이므로, 같은 바이트코드를 hex 텍스트로 담으면 바이트당 두 글자와 접두사·바깥 공백까지 파일 크기에 포함됩니다.

여기서 배울 것은 상수를 외우는 일이 아닙니다. “다시 시도하면 나아지는 오류인가?”, “시간·입력·출력 중 어느 경계를 넘었는가?”를 구분해야 호출자와 에이전트가 적절히 대응할 수 있습니다.

2026-10-28 재검토: 6.8.0과 MCP 스키마의 크기 경계

고정 소스는 6fa48f201f932c6c12b540ee9799895a0a436d00이며 package.json 버전은 6.8.0입니다. Node 엔진 조건은 ^22.23.4 || ^24.22.1 || >=26.12.1로 높아졌습니다. 기존의 Node 22.19/24.11 조건으로 새 소스를 설치할 수 있다고 가정하지 않습니다.

MCP의 입력 스키마는 기본 compact, 출력 스키마는 기본 full입니다. REA_MCP_INPUT_SCHEMA_PROFILE=full은 세부 입력 안내를 모두 광고합니다. 클라이언트가 도구 목록 프레임 크기를 제한한다면 출력 프로필 compact로 스키마별 4096바이트 예산을 적용하거나 off로 광고를 생략할 수 있습니다.

createServer.ts는 이 설정을 각각 정규화합니다. 광고되는 스키마를 줄여도 정식 서버 검증과 전체 structured result를 유지한다는 계약이므로, 출력 생략을 분석 검증 생략으로 이해하면 안 됩니다.

# MCP 등록 환경 설정의 예시
REA_MCP_INPUT_SCHEMA_PROFILE=compact
REA_MCP_OUTPUT_SCHEMA_PROFILE=compact

첫 실습은 두 프로필 정규화 함수의 기본값과 잘못된 값의 오류 처리를 읽고, 자기 클라이언트의 크기 제약에 어느 설정이 대응되는지 표로 정리합니다. 분석 대상 실행·설치·모델 호출은 수행하지 않았습니다.

근거: 런타임 조건 · 출력 스키마 계약. 아래 초판 코드 예시는 5d81363 당시의 구조 설명으로 남깁니다.

2026-10-29 소스 개정 — ESP 이미지와 Kuna 제공자

ESP32 계열 펌웨어를 inspect-artifact·extract-artifact 경로에서 정적으로 읽는 어댑터가 추가됐다. 기기 연결·플래시 접근·esptool 실행 없이 헤더, 세그먼트, 체크섬과 추가 SHA-256, Secure Boot v2 서명 블록의 정보를 구분한다. 체크섬 불일치는 한계로 보고하며 세그먼트를 읽는 것 자체를 일괄 차단하지 않는다. ESP8266은 지원하지 않고, 암호화돼 매직 바이트가 없는 파일은 미인식으로 남긴다.

EspImageArtifactReader는 원본의 SHA와 파일 정체성을 묶고, 목록에 속하지 않는 항목을 거부한다. 추출 스트림이 끝날 때 읽은 바이트 수와 원본 정체성을 다시 검사한다. loaded라는 세그먼트 분류는 실제 부트로더가 주소·RAM 범위를 승인한다는 뜻이 아니므로 부팅 가능성까지 추론하면 안 된다.

# 문서의 명령 형식 예시 — 이 검토에서는 실행하지 않음
rea inspect-artifact ./firmware.bin --detail summary --json
rea extract-artifact ./firmware.bin --json

Kuna는 사용자가 준비한 실행 파일을 연결하는 추가 네이티브 분석 제공자다. REA가 내려받거나 설치하지 않는다. 공식 문서는 Kuna 1.833으로 검증했으며 다른 버전은 미검증으로 표시한다고 설명한다. REA_KUNA_COMMAND에 절대 경로를 주고 --provider kuna로 선택한다. 다른 제공자와 함께 가능한 대상에서 auto는 임의 선택하지 않고 ambiguous를 반환한다.

Kuna 제공자는 Windows를 아직 지원하지 않으며 대상은 x86-64·AArch64·ARM의 ELF와 thin Mach-O 실행 파일이다. PE·universal Mach-O는 거부한다. 의사코드·어셈블리·호출 관계와 형식화된 참조·기본 블록·주석·타입 복구의 지원 범위는 서로 다르다. 후자의 기능은 이 제공자에서 이용할 수 없다.

Bun 실행파일과 .NET 단일 파일의 내부 자산

2026-10-30 기준 317bf3fe235e655b2d752d3be261cc0da7d00f2b는 Bun standalone과 .NET single-file bundle을 inspect-artifact·extract-artifact의 공통 흐름으로 연결합니다. 실행파일을 실행하지 않고 저장된 멤버·경로·크기·해시를 조사하며, 추출은 REA가 소유한 새 출력 트리에 기록합니다. 기존 출력 루트를 덮어쓰지 않습니다.

Bun은 Mach-O·PE·ELF section과 appended trailer의 모듈 그래프를 읽습니다. 지원 레코드 구조는 Bun 1.3.3 계열의 36바이트와 1.3.9 계열의 52바이트이며, 구조가 맞는다고 정확한 컴파일러 버전을 판정한 것은 아닙니다. bytecode는 증거로 보존할 뿐 디컴파일하지 않습니다.

.NET reader는 bundle header 1.0·2.0·6.0과 v6 raw DEFLATE 멤버를 지원합니다. .NET 런타임 없이 조사·추출할 수 있지만 DLL 확장자만으로 유효한 assembly라고 결론 내리지 않습니다. 알 수 없는 버전·잘린 범위·위험한 경로·상충하는 크기 등은 성공한 빈 결과로 바꾸지 않고 거부합니다.

DotnetBundleArtifactReader.prepareContainer는 원본 전체 SHA-256을 inventory와 묶고, 추출 전 같은 host인지 다시 확인합니다. 범위 기반 읽기·압축 해제 한도·취소 시 자원 정리도 reader 책임입니다. 문서의 자원 상한은 REA의 정책이며 .NET 형식 자체의 한도는 아닙니다.

# 독자가 소유한 시험 파일로 선택할 예시
rea inspect-artifact ./sample-host --json
rea extract-artifact ./sample-host --json

2026-10-30 후속 대조: Apple 번들과 웹 분석 경계

고정 커밋 8f920bb는 네이티브 입력으로 .app 외에 .appex·.framework·.xpc·.systemextension·.bundle·.plugin 디렉터리를 선언된 실행파일로 해석합니다. 반면 .dext·.kext·.qlgenerator·.mdimporter는 이 열기 경로에서 거부합니다. 번들 목록에서 발견하는 것과 네이티브 실행파일로 여는 것은 구분해야 합니다.

HAR 가져오기는 기존 RFC 3986 검증 외에 WHATWG URL 직렬화가 원문을 바꾸지 않는 브라우저 URL도 받습니다. 질의의 이스케이프되지 않은 |·{ 같은 사례를 수용하되, 두 검증에 모두 맞지 않는 공백·탭·역슬래시 표기는 거부합니다. Electron의 미해결 채널 handler 옆에 있는 literal send는 무조건 unpaired가 아니라 ambiguous로 남깁니다. Node http.get("/api/items")처럼 URL 파싱 단계에서 실패하는 문자열은 실제 요청으로 보고하지 않는 테스트도 추가되었습니다. 브라우저 fetch의 상대 경로에 이 Node 전용 조건을 일반화하지 않습니다.

5디렉토리 구조 해부

rea/                              저장소 루트
+-- package.json / package-lock.json
+-- tsconfig.json / turbo.json
+-- src/                          TypeScript 분석 본체
|   +-- cli.ts / cli/             사람이 쓰는 명령 어댑터
|   +-- main.ts / main/           MCP 시작·종료·실행 경로
|   +-- server/                   MCP 도구 등록·응답·HTTP
|   +-- composition/              제공자와 서비스를 실제로 조립
|   +-- contracts/                호출자에게 공개하는 계약
|   +-- domain/                   사실·식별·근거·형식 의미
|   +-- application/              기능별 공유 작업 흐름
|   |   +-- binary/               세션·제공자 선택·라우팅
|   |   +-- investigation/        근거 장부·Unknown 기록
|   |   +-- analysisView/          보관된 근거의 보기·요약
|   |   +-- javascript/           앱·모듈 관계 분석 흐름
|   |   +-- evm/                  EVM 서비스·포트
|   +-- evm/                      EVMole 어댑터·워커
|   +-- hopper/ ghidra/ ida/       네이티브 분석 제공자
|   +-- browser/ javascript/      브라우저·JS 분석 연결
|   +-- artifacts/ filesystem/    파일 읽기·임시 자원·식별
|   +-- process/ windows/         프로세스 소유권·운영체제 경계
+-- bridge/                       Python·Java·Swift 브리지
+-- native/windows/src/           Node-API용 C/C++ 구현
+-- tests/                        경계·인수·적합성·픽스처
+-- scripts/                      빌드·메타데이터·검증·배포 도구
+-- docs/                         설치·형식별 분석·설계 문서
+-- website/                      정적 공개 사이트·번역·템플릿
+-- .agents/skills/               저장소의 에이전트 작업 안내 원본
+-- .github/workflows/            일반 CI·실도구별 검증
+-- experiments/                  분석 효율 등 별도 실험
+-- third_party/ licenses/        외부 구성요소 안내·라이선스

5-1. 같은 이름의 폴더가 두 곳에 있는 이유

src/application/evm/는 “무엇을 검증하고 어떤 결과로 내보낼까”를 맡습니다. src/evm/는 “EVMole을 어떤 프로세스로 실행하고 어떻게 응답을 읽을까”를 맡습니다. 같은 주제라도 정책과 실행 수단이 다르기 때문에 두 위치에 나뉩니다.

src/contracts/는 외부에서 호출하는 도구의 이름·설명·입출력 형식을 다룹니다. src/domain/는 그 형식이 표현하는 의미를 다룹니다. 예를 들어 EVM 결과의 bytecode_offset이 바이트코드 범위를 벗어나지 않아야 한다는 규칙은 src/domain/evm/evmInterface.ts의 추가 검증에 있습니다.

5-2. 처음 읽을 때의 추천 순서

지금 궁금한 것	먼저 열 파일	다음 연결점
어떻게 호출하나?	src/contracts/evm/evmToolContracts.ts	명령은 src/cli/evmCommands.ts.
어떤 값을 거부하나?	src/domain/evm/evmInterface.ts	EvmInterfaceService.inspect()의 입출력 검사.
진짜 엔진은 무엇인가?	src/composition/evm.ts	EvmoleInterfaceProvider.inspect().
왜 결과를 믿을 수 있나?	src/domain/evm/evmInterfaceEvidence.ts	EvidenceLedger.record()와 한계 필드.
어떤 실패를 예상했나?	src/application/evm/EvmInterfaceService.test.ts	잘못된 입력·대상 불일치·취소 사례.

작은 기능 하나를 계약부터 테스트까지 세로로 읽으면, 수천 파일의 저장소도 이해할 수 있는 크기로 줄어듭니다. src/server/createServer.ts부터 모든 import를 따라가려 하면 기능 등록의 양에 먼저 압도되기 쉽습니다.

5-3. 코드 규모를 직접 세어 보기

아래 수치는 저장소 전체에서 .git·node_modules·dist·_site· third_party 디렉토리를 제외한 확장자별 파일 수와 줄바꿈 바이트 수입니다. 주석·빈 줄·테스트·픽스처·저장소에 들어 있는 생성 파일은 포함합니다. 따라서 아래 값은 실행 코드만의 크기나 논리적 코드 줄 수가 아닙니다.

언어	파일 수	물리적 줄 수
TypeScript	4,199	1,099,783
JavaScript	481	95,569
Python	96	19,055
HTML	23	14,196
Java	23	8,261
C/C++	36	3,412
CSS	1	2,998
Swift	19	1,571

TypeScript 중 경로에 tests가 있거나 이름에 .test.·.spec.가 있는 파일은 2,267개, 656,465줄입니다. 나머지는 1,932개, 443,318줄입니다. 나머지에도 설정·픽스처 등이 있을 수 있으므로 “제품 코드 44만 줄”이라고 단정하지 않습니다.

# 저장소 루트 기준 읽기 전용 집계 예시
from pathlib import Path
skip = {'.git', 'node_modules', 'dist', '_site', 'third_party'}
files = [p for p in Path('.').rglob('*.ts')
         if p.is_file() and not (set(p.parts) & skip)]
print(len(files), sum(p.read_bytes().count(b'\n') for p in files))
# 커밋 5d81363 기준 .ts 집계: 4199 1099783

6학습 포인트 (기술별)

6-1. TypeScript: 실패도 타입의 가지로 표현하기

Result<T, E>의 ok는 단순한 상태 표시를 넘어 타입을 좁히는 기준입니다. 성공이면 value, 실패이면 error를 읽도록 구조가 갈립니다. tsconfig.json의 strict, noUncheckedIndexedAccess, exactOptionalPropertyTypes도 각각 켜져 있습니다.

// Result 사용법을 보여주는 독립적인 설명 예시
type Result<T, E> =
  | { ok: true; value: T }
  | { ok: false; error: E };

function describe(result: Result<number, string>): string {
  if (!result.ok) return `실패: ${result.error}`;
  return `성공: ${result.value}`;
}

작은 실습: 위 예시에서 실패 가지에 result.value를 읽는 줄을 적어 보고, 왜 타입 검사기가 거부해야 하는지 설명해 보세요. 그다음 서비스의 조기 반환을 읽으면 “예외를 잡았나?”뿐 아니라 “어떤 실패가 전달되나?”를 볼 수 있습니다.

6-2. Zod: 입력 검증과 출력 검증은 서로 다른 방어선

inspectEvmInterfaceInputSchema는 절대 경로와 명시적 raw·hex 인코딩을 요구합니다. z.strictObject()이므로 선언하지 않은 속성도 거부합니다. 출력 스키마는 hex 길이가 바이트 수의 두 배인지, 함수 오프셋이 범위 안인지까지 확인합니다.

작은 실습: timeout_ms: 0, encoding: "auto", 상대 경로, 알 수 없는 속성, 결과 해시 불일치를 각각 입력 오류와 출력 오류로 분류해 보세요. src/application/evm/EvmInterfaceService.test.ts에서 비슷한 사례를 찾아 근거를 적습니다.

6-3. 파서와 AST: 실행되는 문법과 지워지는 문법 구분하기

src/domain/javascript/javascriptSourceParser.ts의 parserPluginsForPath()는 확장자에 따라 TypeScript·JSX 모드를 고릅니다. javaScriptRuntimeContext()는 파서가 보관한 런타임 맥락을 반환합니다. 타입 전용 import/export가 있다는 사실만으로 실행 시 모듈 선언이 있다고 판정하지 않는 점이 흥미롭습니다.

// 읽고 비교하는 학습용 소스 조각
import type { User } from './types';
import { createUser } from './runtime';
// 첫 줄은 타입 정보, 둘째 줄은 실행 코드의 연결입니다.

작은 실습: 같은 문자열을 .ts, .tsx, .js에서 읽을 때 문법 설정이 왜 달라져야 하는지 함수의 분기를 표로 정리합니다. 이 차이는 단순한 정규식으로 import를 세는 도구가 놓치기 쉬운 의미입니다.

6-4. MCP: 도구 이름보다 계약과 전달량 읽기

INSPECT_EVM_INTERFACE_CONTRACT는 도구 이름과 설명, 입력·출력 스키마를 함께 묶습니다. src/server/registerEvmTools.ts는 그 이름에 실제 핸들러를 연결합니다. 이름이 비슷한 함수를 아무렇게나 실행하는 구조가 아닙니다.

작은 실습: detail: "summary"가 결과에서 줄이는 부분과 보관하는 원본을 구분해 그려 보세요. 함수 후보는 요약으로 읽고 큰 바이트코드 본문은 나중에 읽는 흐름이 에이전트의 문맥을 어떻게 절약하는지도 설명합니다. 실제 토큰 절감량은 측정 전에는 숫자로 쓰지 않습니다.

6-5. 운영체제와 테스트: 종료를 요청한 뒤 무엇이 남는가

제공자의 close()와 src/process/를 함께 읽으면 프로세스 ID만으로 소유권을 판단하지 않는 설계를 만납니다. 임시 파일·자식 프로세스·작업 대기열은 서로 다른 자원입니다. 취소 신호를 보냈다는 사실만으로 이들이 모두 사라졌다고 가정할 수 없습니다.

작은 실습: 서비스 테스트의 “실행 후 취소” 사례에서 AnalysisCancelledError 안에 partialObservation과 진단 출력이 남는 이유를 적어 보세요. 이미 관찰한 사실을 취소 때문에 모두 잃지 않으려는 처리입니다.

좋은 소스 학습은 함수 이름을 외우는 것보다, 그 함수가 지키려는 불변 조건을 찾아내는 연습입니다.

7하드웨어 / 시스템 요구사항

현재 공식 설치 문서는 Cortex-M 전용 검증 lane이 없음을 명시합니다. Ghidra language override의 Cortex·v8-m 제안도 미검증 임시 경로이며 다른 아키텍처 import에도 전역 적용될 수 있습니다. 목표별로 설정을 분리하고 이 값을 일반적인 자동 감지 지원으로 소개하지 않습니다.

설치 문서는 저장소 전체에 적용되는 CPU 코어 수·RAM·디스크의 단일 최소값을 명시하지 않습니다. 분석 대상의 크기, 선택한 엔진, 브라우저 사용 여부에 따라 달라집니다. 아래는 의존성 선언·소스 상수·설치 문서에 명시된 조건입니다.

작업	확인한 시스템 조건	해석할 때의 주의점
자료 읽기	텍스트 편집기와 로컬 소스	분석 엔진·GPU·모델 다운로드 없이 구조를 공부할 수 있습니다.
REA 런타임	Node.js ^22.23.4 || ^24.22.1 || >=26.12.1, npm	저장소의 개발 기준은 Node 24.22.1·npm 11.16.0입니다. 모든 기능의 조건을 이 한 줄이 보장하지는 않습니다.
Linux 자식 실행	일부 엔진·정적 JS 분석에 procps 호환 ps	설치 문서가 프로세스 소유권 확인의 전제 조건으로 명시합니다.
정적 JS / Electron	README 기준 Node.js·npm; Linux의 위 프로세스 조건	정적 배포물 조사와 실제 Electron 실행 관찰은 구분합니다.
웹 동작 관찰	README 기준 Chrome 계열 브라우저	playwright-core 의존성만으로 필요한 브라우저 실행 환경까지 준비됐다고 가정하지 않습니다.
Ghidra	설치 문서 기준 Ghidra 12.1.x, 호스트에 맞는 64비트 전체 JDK와 네이티브 디컴파일러	문서는 12.1.4·JDK 21 조합의 검증을 설명합니다. 설치별 Java 허용 범위를 확인해야 합니다.
Ghidra 호스트	문서 기준 Linux·macOS x64/arm64, 실험적 Windows x64 P0	Windows의 대상·파일시스템·권한 조건은 별도입니다. Linux ARM64는 네이티브 구성요소를 따로 준비해야 할 수 있습니다.
Hopper / IDA	별도 분석 도구와 해당 제공자의 호스트 조건	REA의 MIT 라이선스가 상용 엔진의 라이선스를 대신하지 않습니다.
오프라인 EVM	evmHostSupported(): Linux x64; 호출자 제공 util-linux prlimit	기본 경로는 /usr/bin/prlimit. REA_EVM_PRLIMIT_COMMAND는 절대 실행 경로여야 합니다.
SQLite 조사	README 기준 Node 24.x의 24.15 이상 또는 26 이상, 필요한 네이티브 제한 기능	Node 22에서 본체가 실행 가능하다는 사실과 SQLite 기능이 사용 가능하다는 사실은 다릅니다.
GPU 코드 파일 조사	README 기준 ELF·PE·fatbin·CUBIN·PTX의 정적 정보 읽기	코드 파일을 분석하는 것과 GPU에서 커널을 실행하는 것은 다른 작업입니다.

7-1. 메모리 숫자 네 개를 같은 뜻으로 읽지 않기

• Ghidra Java 힙: 설치 문서는 GHIDRA_HEADLESS_MAXMEM, GHIDRA_MAXMEM, 기본 2G 순의 선택을 설명합니다. 이 값은 JVM의 -Xmx이며 컴퓨터 전체 RAM의 최소값이 아닙니다.
• EVM 워커 JavaScript 힙: 실행 인자의 --max-old-space-size=256은 V8의 오래된 객체 영역 상한입니다. 프로세스 전체 메모리와 같지 않습니다.
• EVM 주소 공간: 코드의 3 GiB는 제한 설정의 상한입니다. 물리 RAM을 항상 3 GiB 사용한다는 뜻이 아니며, 상속된 제한이 더 작을 수 있습니다.
• 빌드 검사기: scripts/run-typescript.mjs는 tsrs 경로에 기본 --checkers 최대 2, --maxMemory 3G를 넣습니다. 명시한 옵션은 보존합니다. 이 값은 제품 실행 사양이 아닙니다.

7-2. 시간·파일·출력 예산도 독립적입니다

EVM 워커 명령의 기본 기한은 30,000ms이고 CPU 상한은 별도로 30초입니다. timeout_ms는 1부터 2,147,483,647까지의 정수지만, 입력 4 MiB·응답 16 MiB·진단 1 MiB·CPU 상한을 늘리지 않습니다. 또한 이 기한은 파일 확보와 마지막 응답 읽기까지 포괄하는 전체 호출 기한이 아닙니다.

8직접 해볼 수 있는 실습 과제

아래 과제는 원본 저장소를 수정하거나 프로그램·설치 스크립트를 실행하지 않고 수행할 수 있습니다. 읽은 근거를 별도 학습 노트에 적고, 구현 아이디어는 독립적인 예시로 설계합니다. 각 과제의 예상 결과는 소스의 분기와 검증 규칙을 기준으로 합니다.

// MCP 도구의 인자 예시입니다. 전체 JSON-RPC 요청이나 실행 결과가 아닙니다.
{
  "path": "/artifacts/runtime.hex",
  "encoding": "hex",
  "timeout_ms": 30000,
  "detail": "summary"
}

실습의 완성은 명령 실행 자체보다, 어떤 결과를 왜 허용하거나 거부하는지 근거 파일로 설명하는 데 있습니다.

9관련 기술 심화 학습 로드맵

주차는 진도를 강제하는 일정이 아니라 의존 관계를 나타냅니다. JavaScript 함수·객체·배열에 익숙하지 않다면 1주차를 더 길게 잡아도 됩니다. 매주 “읽은 파일 → 찾은 규칙 → 반례 → 설명” 네 칸의 노트를 남깁니다.

주차	집중 기술	소스와 학습 결과물
1주차	TypeScript 기본·유니언·제네릭	src/domain/result.ts를 읽고 성공·실패 가지를 그림으로 설명합니다. 속성 누락과 undefined도 구분합니다.
2주차	스키마·검증·바이트 표현	src/domain/evm/evmInterface.ts와 src/evm/EvmBytecodeCarrier.ts에서 허용·거부 사례 10개를 만듭니다.
3주차	계층 분리·포트·의존성 주입	EvmInterfacePort → 서비스 → 조립 코드를 연결합니다. 엔진 없이 검사할 수 있는 조건과 없는 조건을 나눕니다.
4주차	CLI·MCP·직렬화	같은 기능의 명령 등록과 도구 등록을 비교합니다. 요약·원본 보관·페이지 읽기의 관계도를 만듭니다.
5주차	운영체제·취소·자원 소유권	EvmoleInterfaceProvider.close()와 오류 변환을 읽습니다. 실행 전·중·후 취소와 정리 실패의 상태표를 만듭니다.
6주차	근거 모델·검증 전략·다른 형식	EvidenceLedger와 테스트를 읽고, JS 파서 또는 소스맵 흐름 하나를 추가 조사해 같은 설계가 어디서 재사용되는지 찾습니다.

새 기술을 하나 더 아는 것보다, 입력에서 근거까지 이어지는 한 경로를 끝까지 설명하는 능력을 먼저 기르세요. 그 뒤 네이티브 브리지·브라우저 관찰·다른 파일 형식으로 범위를 넓히면 공통 구조와 예외를 함께 볼 수 있습니다.

9-1. 테스트를 읽는 순서도 깊이에 맞추기

처음에는 src/evm/EvmBytecodeCarrier.test.ts처럼 입력과 결과가 짧은 테스트를 읽습니다. 다음은 서비스의 가짜 제공자 테스트, 그다음 tests/boundary/의 CLI/MCP 경계, 마지막은 실제 도구를 요구하는 검증 설정 순입니다.

.github/workflows/real-evm-interface.yml은 Ubuntu 24.04에서 별도 저장공간에 solc@0.8.30을 준비하고 공개 CLI·MCP 검증 명령을 호출하도록 되어 있습니다. .github/workflows/sqlite-runtime.yml의 Node 버전 조합은 22.x·24.15.0· 24.x·26.x입니다. 지원되지 않는 환경의 진단도 호환성 검증의 일부입니다.

10핵심 키워드 사전

용어	쉬운 설명
역공학	완성된 파일이나 동작을 조사해 내부 구조·구현 원리를 알아내는 작업.
정적 분석	대상 프로그램을 실행하지 않고 바이트·구문·메타데이터 등을 읽는 분석. 분석기 자체의 프로세스가 실행되지 않는다는 뜻은 아닙니다.
동적 관찰	실행 중인 대상의 이벤트·화면·네트워크·프로세스 상태 등을 조사하는 작업.
바이트코드	특정 실행 환경이 해석하는 명령의 바이트 표현. EVM은 스마트 계약 실행 환경의 한 예입니다.
캐리어	조사할 바이트코드를 담고 있는 원본 파일. raw 바이트 또는 hex 텍스트 등 표현 방식이 있습니다.
hex	바이트 하나를 16진수 두 글자로 적는 표현. 0xff는 255를 나타냅니다.
디컴파일	기계어 등에서 사람이 읽기 쉬운 코드 형태를 재구성하는 분석. 원래 소스와 완전히 같다고 보장하지 않습니다.
AST	구문을 나무 모양으로 표현한 구조. import·함수·조건문을 단순 문자열보다 정확한 단위로 다룹니다.
소스맵	변환·번들링된 코드의 위치와 원본 소스 위치를 이어 주는 정보.
MCP	에이전트와 도구 서버가 기능 목록·입력·결과를 주고받기 위한 연결 규약.
stdio	표준 입력·표준 출력으로 데이터를 주고받는 방식. 진단 로그를 같은 출력에 섞으면 규약을 깨뜨릴 수 있습니다.
계약 · 스키마	어떤 이름으로 어떤 값을 받아 어떤 형식으로 돌려주는지 적은 약속과 그 값을 검사하는 구조.
포트 · 어댑터	필요한 기능의 규격과 그 규격에 실제 도구를 맞추는 구현.
의존성 주입	객체가 사용할 구현을 밖에서 전달하는 방법. 엔진 교체와 작은 테스트를 돕습니다.
Result	예상 가능한 성공·실패를 명시적인 두 가지 타입으로 반환하는 방법.
판별 유니언	ok: true처럼 공통 표식의 값에 따라 읽을 수 있는 속성이 달라지는 타입.
Evidence	분석 대상·도구·요청·결과·위치·한계를 함께 담은 검토 가능한 근거 레코드.
출처 추적	어떤 파일과 도구, 어떤 관찰에서 결과가 나왔는지 되짚을 수 있게 정보를 남기는 일.
SHA-256	바이트에서 고정 길이 지문을 계산하는 해시 함수. 같은 지문이라는 사실만으로 출처의 진위를 보증하지는 않습니다.
멱등성	같은 요청을 반복해도 중복 추가 등 불필요한 변화가 생기지 않는 성질. 장부의 중복 기록 처리에서 만납니다.
원자적 반영	묶음 전체가 검증되면 반영하고, 충돌하면 중간까지만 바뀐 상태를 남기지 않는 방식.
Unknown	아직 답하지 못한 질문을 명시적으로 남긴 기록. 미확인을 부재나 안전함으로 바꾸지 않는 데 도움이 됩니다.
요약 보기	원본을 보관한 채 필요한 부분을 작게 보여주는 결과. 요약에서 빠졌다고 원본에도 없다는 뜻은 아닙니다.
프로세스 소유권	종료·정리하려는 프로세스가 정말 내가 시작하고 관리하는 자원인지 증명하는 문제.
자원 예산	파일 크기·출력·시간·CPU·메모리 등에 설정한 경계. 각각 다른 한계이므로 따로 해석합니다.
픽스처	테스트에서 반복해서 쓰는 작은 파일·가짜 응답·준비 데이터.
경계 테스트	CLI·MCP·파일시스템·프로세스처럼 구성요소가 맞닿는 지점의 동작을 확인하는 테스트.
shallow clone	일부 최근 이력만 내려받은 Git 복제본. 현재 파일은 읽을 수 있지만 전체 역사까지 갖고 있지는 않습니다.

11참고 링크

추가 근거: Bun 지원 경계 · .NET bundle 계약 · reader 소스. 설치·실행파일 실행·모델 호출 없이 소스만 대조했습니다.

11-1. 공식 저장소·문서·관련 기술

• morluto/rea 공식 저장소 · 분석 커밋의 README · 공식 웹사이트
• 설치와 제공자별 조건 · 오프라인 EVM 분석 안내 · JavaScript 앱 분석 안내
• 공식 아키텍처 그림 원본 · 테스트 설계 안내 · 외부 구성요소 고지
• Node.js 공식 API 문서 · TypeScript 공식 문서 · Zod 공식 문서
• MCP 공식 문서 · Babel parser 공식 문서 · Vitest 공식 안내
• Ghidra 공식 저장소 · Playwright 공식 API 문서 · TrendShift

외부 기술 링크는 후속 학습의 출발점입니다. 버전과 구현 동작의 근거는 커밋 5d81363에 고정한 아래 저장소 파일입니다.

11-2. 핵심 주장별 소스 읽기

확인할 주장	커밋에 고정한 근거
실제 의존성·버전	package.json · package-lock.json · tsconfig.json
CLI·MCP의 공유 서비스	evmCommands.ts · registerEvmTools.ts · EvmInterfaceService.ts
계약과 대상 검증	evmToolContracts.ts · evmInterface.ts · EvmInterfacePort.ts
명시적 제공자 선택	AnalysisProviderRegistry.ts · SessionProviderRouter.ts
근거 장부와 요약	evidence.ts · EvidenceLedger.ts · AnalysisViewService.ts
EVM 자원 제한·정리	EvmoleInterfaceProvider.ts · EvmoleRelease.ts · EvmoleFailures.ts
실행 가능한 문법 구분	javascriptSourceParser.ts · TraceSourceMap.ts
빌드·사이트의 분리	bundle-runtime.mjs · run-typescript.mjs · website/README.md
검증하도록 설계한 범위	ci.yml · real-evm-interface.yml · sqlite-runtime.yml

초판 관측표 (2026-10-23, 현재 수치 아님)

항목	확인 내용과 출처
선정	TrendShift Daily #5(2026-10-23).
스타 / 포크	368,189 / 92,254. 2026-10-23 GitHub 기준.
생성일	2026-04-14. 2026-10-23 GitHub 기준.
최근 push	2026-10-23. 2026-10-23 GitHub 기준.
주 언어	TypeScript. 2026-10-23 GitHub 기준이며, 소스 구성도 TypeScript가 중심입니다.
최신 릴리스	rea-agents-6.7.0, 2026-10-18. 2026-10-23 GitHub 기준이며, 기준 커밋의 패키지 버전도 6.7.0입니다.
기준 커밋	5d81363, 커밋 날짜 2026-10-23.
커밋 주제	EVM 캐리어 입력 허용량 초과를 파일 크기 자원 제약으로 보고하는 수정, #6414.
코드 규모	지정한 제외 범위에서 TypeScript 약 110만 줄, JavaScript 약 9.6만 줄, Python 약 1.9만 줄. 테스트·빈 줄·주석 포함이며 상세는 5절에 있습니다.
라이선스	MIT. 2026-10-23 GitHub 기준이며 package.json·LICENSE도 MIT를 명시합니다. 외부 도구·구성요소는 각각의 조건을 따릅니다.
저장소 설명	Reverse engineer anything with agents, from app behavior down to native binaries. (2026-10-23 GitHub 기준)