MindNode 복제 실전과 현실적인 평가 — REA 리버스 엔지니어링 실전 가이드 [3/3]

SERIES REA 리버스 엔지니어링 실전 가이드 3 / 3

• 1 REA 설치와 Claude Code 설정 — REA 리버스 엔지니어링 실전 가이드 [1/3] 2026-10-19
• 2 Hopper·Ghidra와 REA MCP 도구 — REA 리버스 엔지니어링 실전 가이드 [2/3] 2026-10-19
• ▶ MindNode 복제 실전과 현실적인 평가 — REA 리버스 엔지니어링 실전 가이드 [3/3] 2026-10-19

시리즈 전체 보기 →

1편에서 설치와 설정을, 2편에서 분석 엔진과 MCP 도구를 봤습니다. 마지막 편은 영상의 24분 24초부터 끝까지입니다. 맥 마인드맵 앱 MindNode를 REA로 분석해 다시 만드는 실전 과정과, 그 과정에서 드러난 시간·사용량·한계, 그리고 영상 제작자의 솔직한 평가를 정리합니다.

1. 복제 프롬프트와 서브에이전트

영상은 새 Code 세션에서 시작합니다(2편에서 본 대로 REA 도구는 새 세션에서만 로드됩니다). 모델은 Opus 5.5, 추론 강도는 High입니다.

영상에서 입력한 요청을 정리하면 다음과 같습니다(말하면서 입력한 것이라 문장을 다듬었습니다).

REA를 먼저 이해하고, 지금은 Hopper를 쓰자. MindNode를 다시 만들어 줘.
스택은 알아서 고르되, 먼저 아주 깊게 분석한 뒤 처음부터 끝까지 완전히 재현해 줘.
문서를 만들 수 있어야 하고, 실제 MindNode 형식의 파일을 가져올 수 있어야 하며,
노드 추가, 색상, 글꼴 등 모든 기능을 쓸 수 있어야 한다. 완전한 재현을 원한다.
서브에이전트는 최대 8개까지 만들어도 된다. 작업 난이도에 따라 Haiku 5.5나 Opus 5.5를 쓰고,
결과를 해치지 않는 선에서 토큰을 아끼도록 Haiku를 우선 써라.

이 요청에서 배울 점은 두 가지입니다.

• “먼저 깊게 분석한 뒤”라는 순서를 지정했습니다. REA의 조사 루프(1편)를 먼저 돌리게 하는 것입니다.
• 서브에이전트 수와 모델 배분 기준을 줬습니다. 비싼 Opus는 어려운 부분에만, 단순 반복은 Haiku에 맡기라는 것입니다.

Claude가 실제로 짠 구성은 이랬습니다(30분 50초 화면, 아래 3절의 스크린샷 위쪽).

항목	내용
스택	React, TypeScript, Vite, zustand, SVG 캔버스. MindNodeClone/ 폴더. 모든 화면을 헤드리스 브라우저로 확인할 수 있도록 웹으로 선택
Opus 서브에이전트	새 protobuf 파일 형식 읽기·쓰기(서식 있는 제목 포함)
Haiku 서브에이전트	예전 plist 파일 형식 읽기·쓰기
Opus 서브에이전트	레이아웃과 렌더링. MindNode가 문서 안에 저장해 둔 미리보기 이미지(최대 3072px)와 비교해 검증
Haiku 서브에이전트	기능, 메뉴, 키보드 단축키, 테마 색상 목록 정리
Opus 서브에이전트	편집기 본체. 캔버스 편집, 인스펙터, 아웃라인 보기, 가져오기·내보내기, 실행 취소, 종단 간 테스트

작업 도중 Claude는 Computer Use 권한을 요청해 MindNode를 직접 열고 화면을 캡처하며 비교합니다. 1편에서 “Background”로 설정해 두었기 때문에, 이 조작은 사용자의 작업 화면을 빼앗지 않고 뒤에서 진행됩니다.

2. Hopper 데모 만료, Ghidra로 교체

처음에는 Hopper로 MindNode 바이너리를 엽니다. 그런데 26분 35초쯤 Hopper 데모 시간이 만료됩니다. 2편의 비교표대로 데모는 세션당 약 30분입니다. 그래서 Ghidra로 바꿉니다.

이 장면의 진행 보고가 Ghidra를 직접 붙일 때 그대로 참고가 됩니다.

1. Ghidra 다운로드가 458MB에서 멈춰 다시 시작했습니다. Ghidra는 크기가 커서 설치가 오래 걸립니다.
2. Ghidra 12.1.4와 OpenJDK 21을 설치했습니다. 공식 문서의 요구 사항(Ghidra 12.1.x, JDK 21 이상)과 맞습니다.
3. REA는 MCP 서버 환경 변수 GHIDRA_INSTALL_DIR에서 Ghidra 위치를 읽습니다. 그래서 이 값과 JAVA_HOME을 ~/.claude.json의 rea 항목에 넣고 백업을 남겼습니다.
4. 설정 변경은 REA 서버가 다시 시작돼야 반영되는데, 이것은 사용자만 할 수 있습니다. 그래서 그동안은 Ghidra 환경 변수를 준 REA CLI를 직접 실행했습니다.
5. MindNode 바이너리(123MB) 전체 분석을 백그라운드로 시작했습니다.

3. 타임아웃과 시간 한도

큰 바이너리에서는 바로 벽에 부딪힙니다. Ghidra 분석이 330초 만에 시간 초과됐습니다. 영상 속 Claude는 이것을 “REA의 작업당 기본 한도”라고 설명하고, REA_GHIDRA_STARTUP_TIMEOUT_MS로 2시간 한도를 주어 다시 실행합니다. 공식 README도 “큰 바이너리를 분석할 때는 REA_GHIDRA_STARTUP_TIMEOUT_MS 또는 REA_HOPPER_STARTUP_TIMEOUT_MS로 제공자의 시작 제한 시간을 늘리라”고 안내합니다.

# 예: Ghidra 시작 한도를 2시간(7,200,000ms)으로
export REA_GHIDRA_STARTUP_TIMEOUT_MS=7200000

영상 제작자의 조언은 처음부터 AI에게 시간 한도를 알려 주라는 것입니다. “제한이 없으니 2~3시간 걸려도 된다”고 미리 말해 두면 중간에 시간 초과로 멈추는 일을 줄일 수 있습니다.

그리고 이 시점에서 영상은 중요한 결론을 내립니다.

앱 전체를 복사하는 건 인터넷에서 말하는 것만큼 쉽지 않다. 하려면 기능 하나씩 하라. 전체 코드를 보면 너무 크고 이해하기 어렵고, 한도에도 걸린다.

4. 결과: 분석 엔진보다 실제 파일이 더 믿을 만했다

33분 50초쯤 Claude가 근거를 어디서 얻었는지 정리한 표가 흥미롭습니다. 예를 들어 테마 색상은 앱 번들 안의 기본 테마 파일 7개에서, 외형은 사용자 문서 안에 저장된 MindNode 미리보기 이미지(최대 3072px)에서, 키보드 단축키는 MindNode 공식 단축키 페이지에서 가져왔습니다. 단축키는 원래 Ghidra로만 닿을 수 있는 코드 안에 있기 때문입니다.

그리고 Claude는 “지금까지는 파일 형식에 대해 바이너리와 실제 파일에서 얻은 데이터가 디컴파일한 코드보다 더 믿을 만했다. Ghidra는 남은 빈틈을 위한 것”이라고 정리합니다. Ghidra가 더 보태 줄 것으로 꼽은 것은 세 가지입니다.

• 정확한 레이아웃 알고리즘(간격, 단계별 거리). 지금은 저장된 노드 위치와 미리보기 이미지로 재고 있음
• 파일에 한 번도 나오지 않는 열거값(일부 도형·점선 코드)
• 여러 기기의 동시 편집을 텍스트 형식이 어떻게 해결하는지

Claude는 MindNode에 내장된 MCP 서버(MindNode → Settings에서 켬)를 켜 주면 만든 파일을 실제 앱이 받아들이는지, 앱이 그린 PNG와 픽셀 단위로 비교할 수 있다고 제안했지만, 영상에서는 켜지 않고 넘어갑니다.

완성된 기능 요약

41분 30초쯤 Claude가 보고한 완성 범위입니다.

영역	상태
편집기	문서 브라우저, 여러 탭, 공식 키보드 단축키를 쓰는 캔버스, 탭 다섯 개짜리 인스펙터, 아웃라인 보기, 노트, 테마, 내보내기·가져오기, 실행 취소
파일 형식	두 형식 모두 읽기·쓰기
스티커	앱에서 추출한 253개 모두 렌더링
테스트	단위 테스트 178개 통과, 24단계 브라우저 테스트 통과
진행 중	Ghidra 분석 약 45분째, 레이아웃 에이전트 두 번째 정확도 점검

그리고 42분 49초에 Ghidra 분석이 끝납니다. MindNode에서 함수 210,605개, 문자열 238,824개를 찾았습니다. 다만 새 문제가 나옵니다. REA CLI는 호출 사이에 분석 결과를 유지하지 않아서, 디컴파일할 때마다 43분짜리 스캔을 다시 하게 됩니다. 그래서 Claude는 오래 유지되는 REA MCP 서버와 로컬 브리지를 띄워 분석 한 번으로 모든 디컴파일 질의에 답하도록 바꿉니다. 이 첫 분석에 다시 약 45분이 걸린다고 합니다.

큰 앱을 다룰 때는 CLI로 매번 부르지 말고, MCP 세션 하나에서 분석을 유지하는 방식이 맞다는 실전 교훈입니다.

5. 결과물 시험

39분 20초부터 영상 제작자가 브라우저(localhost:5190)에서 복제본을 직접 써 봅니다.

시험한 것	결과
새 문서 만들기, 노드 입력	됨
노드 추가	됨. 다만 Enter로 형제 노드를 만드는 동작이 원본과 다르고, Add node 버튼으로 추가해야 하는 경우가 있음
굵게, 기울임, 밑줄, 취소선, 형광펜	됨
테마, 아웃라인 보기	됨
새로고침 후 저장	유지됨. “Creativity”, “Dinner Party” 같은 예제 문서도 만들어져 있음
PNG로 내보내기	됨
여러 문서 열기(옆 패널), 단축키 표시	됨

제작자는 “완전히 끝나지도 않았는데 꽤 좋다. 이렇게까지 잘 할 줄은 몰랐다”고 평가합니다. 다만 Opus 5.5를 쓴 덕도 크다고 덧붙입니다. 그리고 영상이 끝날 때까지도 작업은 다 끝나지 않았습니다.

6. 사용량: Max 요금제에서도 부담

영상 제작자는 Max 요금제를 쓰는데, 작업 도중 현재 세션 한도의 약 13%, 영상 끝에는 약 19%를 쓴 상태였습니다. 그리고 요금제가 낮으면 같은 작업으로 세션 한도를 다 써 버려 기다렸다가 다시 해야 한다고 경고합니다. 앱 전체를 맡기면 토큰을 많이 쓰고, Hopper 데모 대신 $99 라이선스를 쓰면 더 빠르고 낫다는 말도 합니다.

7. 영상 제작자의 대안: 화면 녹화 방식

34분 18초부터 제작자는 자신이 평소 쓰는 다른 방법을 소개합니다. 소스 코드를 뜯지 않고, 앱을 쓰는 화면을 녹화해 AI에게 분석시키는 것입니다.

1. 따라 만들고 싶은 앱을 직접 쓰면서 화면을 녹화합니다. 기능을 열고 조작하며 말로 설명도 합니다.
2. Claude에게 녹화 파일을 줍니다. Claude는 소리를 분리해 whisper로 받아 적고, 시간에 맞춰 화면을 캡처해 대조합니다.
3. 볼 프레임 수를 구체적으로 지시합니다(영상에서는 구간마다 10~20장). 한 장이 아니라 여러 장을 모아 봐야 동작을 이해합니다.
4. 비용을 아끼려면 서브에이전트를 Haiku로 돌립니다.

예시로 자신의 영상 편집 시스템을 보여 주는데, 참고 영상을 프레임 단위(이 장면에서는 16장)로 분석해 편집 스타일을 따라 하는 방식입니다. 제작자는 “이 방식이 더 효율적이고, 화면 녹화와 스크린샷으로도 안 풀리는 것이 있을 때 REA를 쓰라”고 권합니다.

8. REA는 과대평가됐나

37분 29초의 평가는 꽤 냉정합니다.

• REA가 하는 일은 에이전트의 조사 과정을 체계적으로 정리해 주는 것이다. 브라우저 제어, 분석 도구 실행 같은 것을 초보자도 할 수 있는 형식으로 묶어 준다.
• 경험 있는 사람들은 이미 비슷한 방식으로 해 왔다. 별 20만 개만큼의 과장은 아니지만, 대단히 새로운 것도 아니다.
• 개인적으로 많이 쓰지는 않을 것 같다.

이 시리즈를 마치며: 직접 써 본다면

영상과 공식 문서를 함께 보고 정리한 실전 순서입니다.

1. 전용 폴더를 만들고 npx rea-agents@latest setup으로 설치합니다. 변경 계획을 꼭 읽고 승인합니다.
2. 새 Code 세션에서 시작합니다.
3. 첫 대상은 Electron 앱이나 웹사이트로 고릅니다. 분석 엔진 없이도 됩니다.
4. 네이티브 앱이 필요하면 Ghidra 12.1.x + JDK 21을 준비하고, 큰 바이너리라면 REA_GHIDRA_STARTUP_TIMEOUT_MS를 넉넉히 줍니다. 빠른 확인만 할 거라면 Hopper 데모도 괜찮지만 30분 제한을 기억합니다.
5. 앱 전체가 아니라 기능 하나(“메모 검색은 어떻게 동작하나?”)를 질문합니다. 공식 README의 예시 프롬프트도 이런 식입니다.

Notes 앱의 검색 기능이 어떻게 작동하는지 조사하고, 근거를 보여 준 다음,
내 프로젝트에 비슷한 기능을 구현해 줘.

1. 시간 한도, 서브에이전트 수, 모델 배분(어려운 일은 Opus, 반복은 Haiku)을 처음부터 알려 줍니다.
2. 분석 대상의 이용약관과 저작권을 확인합니다. REA는 학습, 연구, 상호운용성, 그리고 본인에게 권한이 있는 소프트웨어 분석을 위한 도구입니다.

영상은 결과만 보여 주는 다른 영상들과 달리, 데모 만료, 다운로드 멈춤, 시간 초과, 끝나지 않는 작업까지 그대로 보여 줍니다. “한 줄 프롬프트로 앱 복제”라는 기대를 내려놓고 기능 단위 조사 도구로 쓰면 충분히 쓸모 있다는 것이 이 영상과 이 시리즈의 결론입니다.

---

이 글의 확인 방법과 한계: 영상이 힌디어여서 로컬 음성 인식(whisper.cpp medium, 힌디어 → 영어 번역)으로 받아 적었습니다. 31분 이후 구간은 처음 변환에서 같은 문장이 반복되는 오류가 나 그 구간만 다시 변환했습니다. 숫자와 경로(170개 도구, 330초, 210,605개 함수, 환경 변수 이름 등)는 대사가 아니라 영상 화면의 글자를 1080p로 확대해 옮겼고, 설치 절차와 요구 사항은 REA 공식 README와 설치 문서로 확인했습니다. 영상 속 REA 버전은 이 글을 쓰는 시점의 최신 버전보다 낮으므로, 세부 동작은 공식 문서를 기준으로 삼으세요.

// reading compass

이 글과 이어지는 경로

시리즈, 카테고리, 태그 겹침, 최신도를 점수화해 가까운 글일수록 중심에 배치합니다.

hover nodes or cards · click a node to pin

Next reads 0