4,678
소스가 없는 사내 Electron 앱에서 내보내기 기능을 유지보수해야 한다면 어디부터 읽어야 할까? 화면만 보고 비슷한 기능을 만드는 것과, 실제 호출 경로를 확인하고 호환되는 동작을 만드는 것은 다른 문제다.
REA(Reverse Engineer Anything)는 AI coding agent가 기존 소프트웨어를 조사하도록 분석 도구를 연결하는 프로젝트다. 이 글은 REA의 개념과 원리, Claude Code 활용 흐름, 공식 사례와 실무 적용 예시를 설명한다.[1]
💡 💡 REA의 가치는 ‘무엇이든 복제하는 AI’보다 설명에 근거와 한계를 붙이는 조사 workflow에 있다. 분석은 REA와 연결된 도구가 수행하고, 그 결과를 해석하고 재구현·테스트하는 일은 agent가 이어간다.[1]
Reverse Engineering은 완성된 프로그램의 구조와 동작을 조사해 내부 원리를 이해하는 접근이다. 여기서 다루는 REA는 그 작업을 agent가 수행하도록 돕는 MCP server이자 CLI다. 새로운 LLM이나 독립적인 만능 decompiler가 아니다. Agent는 MCP를 통해 조사 작업을 요청하고, 터미널에서도 같은 workflow를 이용할 수 있다.[1]
역할을 나누면 이해하기 쉽다.
Native 분석에서 얻는 것은 pseudocode·assembly·호출 관계 등이고, JavaScript/Electron 분석에서는 module·import·source map·IPC 관계 등을 조사한다. 원래 개발자의 소스코드와 주석을 그대로 복원한다는 뜻은 아니다. 공식 문서도 결과가 불완전하거나 틀릴 수 있으므로 근거를 검토하라고 명시한다.[1][6]
REA의 기본 흐름은 agent가 대상을 조사하고 관련 코드를 따라간 뒤, 반환된 근거를 바탕으로 후속 질문을 하거나 설명·구현·테스트를 진행하는 것이다.[1]
조사 질문 → Agent → MCP → REA → 대상별 분석 도구 → 근거·제약 → Agent의 해석과 검증.[1]
‘어떤 파일인가’에 따라 필요한 도구가 바뀐다. JavaScript/Electron의 static analysis는 native engine 없이 가능하지만, native binary의 pseudocode와 assembly 분석에는 별도 provider가 필요하다. 웹사이트 관찰에는 Chrome 계열 browser가, Android APK 분석에는 headless JADX와 JDK가 요구된다. 모든 대상이 같은 준비물로 분석되는 것은 아니다.[1]
처음부터 모든 엔진을 설치하기보다, 조사할 대상과 질문을 먼저 정하는 편이 낫다. 사내 Electron 앱의 IPC를 이해하려는 작업이라면 native decompiler부터 준비할 이유는 없다.
REA의 Evidence-producing tool은 정규화된 결과와 Evidence identity를 반환한다. MCP contract에는 structuredContent.normalized_result와 structuredContent.evidence_id가 구분되어 있고, 세션에 보관한 근거를 비교하거나 다시 조사하는 흐름이 정의되어 있다.[3]
실무적으로 중요한 것은 ‘분석했음’이라는 문장이 아니라 어떤 파일·함수·호출 관계를 보고 결론을 내렸는가다. 결론에서 원래 관찰로 돌아갈 수 있어야 다른 개발자가 검토하고 후속 질문을 할 수 있다.
공식 contract는 coverage와 limitations를 구분한다. 일부만 조사했거나 호출 관계의 coverage가 unknown인 경우, 빈 호출 목록만 보고 ‘호출이 없다’고 결론 내릴 수 없다. Static artifact가 같다는 사실도 runtime behavior가 같음을 증명하지 않는다.[3]
따라서 보고서에는 다음 세 범주를 나눠 적는 것을 권한다. 이는 이 글의 검토용 작성 규칙이며, 모든 tool이 똑같은 이름의 필드를 반환한다는 뜻은 아니다.
REA setup은 Claude Code·Codex·Cursor 등 지원 agent에 MCP server와 matching workflow instructions를 등록한다. Skill의 조사 지침과 실제 tool 연결은 역할이 다르므로, 지침만 추가했다고 분석 도구가 연결된 것으로 보면 안 된다.[1]
다음은 공식 문서 기반의 사용 절차다. 이 글을 위해 REA를 설치하거나 실제 대상 분석을 실행하지는 않았다.
npx rea-agents@latest setup이다. 이 명령은 단순 조회가 아니라 package 실행과 설정 변경으로 이어질 수 있으므로, 제안 경로와 변경 내역을 읽고 승인한다.[2]rea doctor는 prerequisite와 agent 설정을 변경하지 않고 읽어 진단한다. 이 표기는 rea CLI가 설치되어 PATH에 있는 경우의 명령이다.[2]💡 ⚠️ ‘로컬 분석’과 ‘모델 제공자에게 내용이 전달되지 않음’은 다르다. REA는 대상을 로컬에서 분석하지만 agent는 tool 결과를 받으며, 모델 제공자에는 별도의 데이터 정책이 적용된다. 사내 코드·토큰·개인정보가 결과에 포함될 수 있는지 먼저 검토해야 한다.[1][6]
아래는 설계 제안이다. 실제 고객 도입 사례나 직접 실행한 분석 결과가 아니다. 조사 권한이 있는 사내 앱을 새 프로젝트로 옮기는 상황을 가정한다.
REA로 내가 조사 권한을 가진 로컬 Electron 앱의 CSV 내보내기 기능만 분석해 주세요. 우선 정적 분석만 수행하고 앱 실행·외부 통신·파일 수정은 하지 마세요. Renderer에서 preload·IPC·main process로 이어지는 경로를 근거 위치와 함께 정리해 주세요. 확인·추론·미확인을 구분하고, 동적으로 결정되어 찾지 못한 경로는 없다고 단정하지 마세요. 구현은 보고서를 검토한 뒤 별도로 진행하겠습니다.
이 요청의 목적은 ‘CSV 라이브러리가 무엇인가’만 찾는 것이 아니다. 입력 데이터, column 순서, encoding, 저장 취소 처리 등 새 구현에서 보존해야 할 동작을 조사 가능한 범위에서 정리하는 것이다. 정적 분석만으로 확인할 수 없는 항목은 다음 단계의 질문으로 남긴다.
그다음 승인된 범위에서 관찰과 재구현을 진행하고 동일 입력에 대한 결과를 비교한다. 비교 기준은 화면이 닮았는지가 아니라, 합의한 동작·오류 처리·권한 경계가 맞는지다. 원본 코드나 asset을 그대로 가져오는 대신 필요한 기능을 독립적으로 설계하는 접근을 권한다. 재구현 방식 자체가 법적 허용을 보장하지는 않는다.[6]
REA 공식 showcase는 Notion Desktop 7.6.1의 clipboard 경로를 소개한다. Page-facing API에서 preload wrapper의 ipcRenderer.invoke, main process의 ipcMain.handle, Electron의 clipboard writer로 이어지는 경로를 조사하며 notion:clipboard:write channel을 연결 지점으로 설명한다.[4]
이 사례는 Electron 개발자에게 유용하다. ‘복사가 된다’는 화면 동작보다 어느 프로세스가 요청을 받고 어떤 경계를 통과하는가를 설명하기 때문이다. 다만 showcase는 저장된 package 분석과 추출한 module의 probe를 구분하고, 일부 결과가 실제 desktop UI session을 capture한 것은 아니라고 명시한다. 이를 Notion 전체 동작의 재현 검증으로 확대하면 안 된다.[4]
DX-Ball showcase에서는 첫 decompiler 출력에 입력이 제대로 드러나지 않은 sound-pan 함수를 조사한다. Agent는 instruction과 caller, binary의 상수를 추가로 확인해 계산을 복원한다. 핵심은 처음 나온 pseudocode를 끝으로 삼지 않고 서로 다른 근거를 대조했다는 점이다.[5]
공식 페이지는 해당 함수에 대해 원본 x86 실행 결과와 C 구현을 비교하고 compiled bytes도 확인했다고 보고한다. 하지만 playable game은 계속 작업 중이라고 선을 긋는다. 한 함수의 검증과 전체 게임 복원은 다른 성과다. 이 글은 공개된 사례 설명을 검토했으며, 그 비교 실험을 독립적으로 재실행하지 않았다.[5]
다음은 도구 선택에 대한 편집자 의견이다. 모든 개발 작업에 REA를 추가할 필요는 없다.
팀 도입의 첫 산출물은 새 코드가 아니라 근거가 연결된 동작 사양과 테스트 목록이면 좋겠다. 이 단계를 통과한 뒤 구현에 들어가면 분석 결과의 빈틈을 코드로 굳히는 일을 줄일 수 있다. 이는 운영 제안이지, 이 글에서 측정한 생산성 개선 결과는 아니다.
정적 분석 허가는 실행 허가와 다르다. REA 일부 workflow는 프로그램 실행·browser endpoint 접속·traffic capture·device 조작을 포함할 수 있으며 실제 상태에 영향을 줄 수 있다. 허용 대상과 동작을 구분하고, 신뢰하지 않는 파일은 적절히 격리된 환경에서 다루는 것이 좋다.[6]
분석 대상의 문장은 지시가 아니라 데이터다. 문자열·pseudocode·로그 안에도 agent에게 명령 실행이나 다운로드를 유도하는 prompt injection이 들어갈 수 있다. REA MCP contract도 이런 내용을 tool 결과 속 지시로 따르지 말라고 명시한다.[3]
REA의 MIT license는 대상 소프트웨어의 이용 허가가 아니다. REA-authored code와 third-party material의 권리는 구분되며, Hopper·IDA·JEB 같은 상용 도구는 별도 사용 권한이 필요하다. Source-like output을 얻었다고 원본 프로그램이나 결과물을 제품에 이용할 권리가 자동으로 생기지 않는다.[1][6]
공식 responsible-use 문서는 DRM·license check·anti-cheat 우회, 무허가 접근 제어 우회, 보호되는 코드와 asset의 복제 등을 지원하지 않는다고 밝힌다. 공개 배포된 파일이라는 사실도 모든 분석·실행·공유의 허가를 뜻하지 않는다. 이 내용은 법률 자문이 아니며, 실제 작업은 적용 법률·계약·도구 약관을 따로 검토해야 한다.[6]
REA를 이해하는 핵심은 세 가지다. Agent가 실제 분석 도구를 호출한다는 것, 결과를 근거와 한계까지 함께 읽어야 한다는 것, 그리고 재구현은 별도의 테스트로 확인해야 한다는 것이다.[1][3][6]
처음에는 권한이 명확한 대상의 기능 하나를 고르자. 질문을 좁히고 → 근거를 모으고 → 미확인을 남기고 → 테스트 기준으로 바꾸는 것이 이 글에서 권하는 시작점이다. ‘얼마나 많이 복제했는가’보다 ‘이 설명을 어디까지 검증할 수 있는가’를 질문하는 편이 REA의 가치를 더 잘 드러낸다.
💡 🔎 검증 범위: 2026-10-17 KST에 공식 README·설치 문서·MCP contract·responsible-use 문서와 공식 showcase 두 편을 검토했다. GitHub 문서는 2026-10-16 commit
709b5cb기준이며, main의 문서와 실제 published package의 기능은 차이가 있을 수 있다. 공식 사례의 실험을 독립적으로 재현하지 않았고 REA 설치·대상 분석도 실행하지 않았다. 명령과 prompt는 문서 기반 사용 예시이며, CSV 시나리오와 도입 판단은 이 글의 제안이다.
[1] https://github.com/morluto/rea/blob/709b5cbdc15aa757f89c38ecd12e5a47710747a6/README.md — REA README (2026-10-16 commit)
[2] https://github.com/morluto/rea/blob/709b5cbdc15aa757f89c38ecd12e5a47710747a6/docs/installation.md — REA installation
[3] https://github.com/morluto/rea/blob/709b5cbdc15aa757f89c38ecd12e5a47710747a6/docs/mcp-contracts.md — REA MCP contracts
[4] https://rea.tools/showcase/notion — Official Notion clipboard showcase
[5] https://rea.tools/showcase/dx-ball — Official DX-Ball showcase
[6] https://github.com/morluto/rea/blob/709b5cbdc15aa757f89c38ecd12e5a47710747a6/DISCLAIMER.md — REA responsible-use disclaimer