깃허브 별 26만 개 리버스 엔지니어링 도구 REA, 소프트웨어는 정말 끝났나: 공식 사례, 독립 실험, 한국 저작권법으로 확인했습니다

핵심 요약

• REA는 기존 디컴파일러를 코딩 에이전트에 연결하는 도구입니다. Ghidra, Hopper, IDA 같은 분석 엔진과 JS, .NET 분석기를 Claude Code, Codex, Cursor 같은 코딩 에이전트에 MCP로 연결해 주는 도구입니다. 바뀐 것은 기술이 아니라 문턱입니다. 디컴파일러 화면을 읽는 일을 에이전트가 맡고, 사람은 무엇을 알고 싶은지만 묻습니다.
• 별 26만 개는 인기의 숫자이지 성능의 숫자가 아닙니다. 10월 8일 약 1만 3천 개에서 15일 26만 개를 넘었습니다. 해외 독립 실험 세 건과 국내 실험 한 건은 작은 프로그램이라면 REA 없이 Ghidra만 쥐여 준 에이전트도 거의 같은 결과를 낸다고 보고했습니다. 공식 대표 사례도 함수 하나 크기입니다.
• "소프트웨어 값이 0원"이라는 주장은 숫자는 대부분 맞지만 결론은 절반만 맞습니다. 모델 단가 73% 하락, Cloudflare의 1주 Next.js 재구현, 앱 출시 60% 증가는 확인됩니다. 하지만 "REA로 어도비를 베꼈다"는 이야기는 별개 프로젝트를 섞은 것이고, 복제품은 모두 초기 알파입니다.
• 한국 저작권법이 역분석을 명시적으로 허용하는 범위는 좁습니다. 제101조의4는 호환에 필요한 정보를 쉽게 얻을 수 없을 때만 그 부분에 한해 역분석을 허용하고, 그 정보로 표현이 실질적으로 비슷한 프로그램을 만드는 것을 금지합니다. "개인 목적이면 된다"는 설명은 조문 문구로 뒷받침되지 않고, 해석도 갈립니다.
• 설치 경로부터 조심해야 합니다. 공식 배포처를 흉내 낸 가짜 저장소에서 백신 일부가 트로이 목마로 탐지한 압축 파일이 172회 내려받아졌고, REA는 스스로 "샌드박스가 아니다"라고 밝힙니다. 공식 경로는 github.com/morluto/rea, rea.tools, npm rea-agents 세 곳뿐입니다.

목차

• REA는 정확히 무엇인가
• 별 26만 개는 어떻게 쌓였나
• 공식 사례로 본 실력: 대표 사례는 함수 하나 크기
• REA 없이도 될까: 독립 실험 네 건
• "소프트웨어 값이 0원"을 숫자로 확인하면
• "REA로 어도비를 베꼈다"는 틀린 이야기
• 한국에서 써도 되나: 저작권법 조문으로 본 선
• 설치 전에 알아야 할 보안 함정
• 내 제품은 무엇을 지켜야 하나
• 이 글의 한계
• 자주 묻는 질문
• 마치며
• 출처

REA는 정확히 무엇인가

REA(Reverse Engineer Anything)는 코딩 에이전트가 리버스 엔지니어링 도구를 직접 부를 수 있게 해 주는 MIT 라이선스 오픈소스입니다. README의 첫 문장은 "Reverse engineer anything with agents, from app behavior down to native binaries."입니다(GitHub morluto/rea). Claude Code 같은 에이전트가 부르는 CLI이자 MCP 서버이고, npx rea-agents setup 한 줄로 설치합니다. Node.js 22.19 이상(24 계열은 24.11 이상)이 필요하고, 설치 도구가 Claude Code, Codex, Cursor, Gemini CLI, Grok Build 가운데 쓰는 에이전트에 연결을 잡아 줍니다.

분석 대상 표에는 23가지 형식이 있습니다. 네이티브 실행 파일, Go와 Rust 바이너리, WebAssembly, Electron 앱과 JavaScript 번들, .NET 어셈블리, 안드로이드 APK, Flutter 앱, 펌웨어, SQLite 파일, 웹사이트와 네트워크 캡처까지 들어 있습니다. 네이티브 바이너리를 열 때는 Hopper, Ghidra, IDA 중 하나가 필요하고, JavaScript와 .NET은 별도 엔진 없이 정적 분석을 합니다.

이 그림에서 눈여겨볼 곳은 맨 아래 칸입니다. 실제 디컴파일은 REA가 아니라 그 아래 분석 도구가 합니다. 오픈소스 리뷰 사이트 hysenlabs는 "REA does not decompile anything itself"라고 정리했고(hysenlabs), MindStudio도 "a connector, not a new reverse engineering technology"라고 썼습니다(MindStudio, 2026-10-11). Ghidra는 미국 국가안보국(NSA)이 2019년에 공개한 도구라, 기술 자체는 이미 있던 것입니다.

그럼 REA가 하는 일은 무엇일까요. 에이전트가 쓸 수 있는 분석 명령을 미리 정의해 두고, 결과를 "관찰한 것, 추론한 것, 아직 모르는 것"으로 나눠 근거와 함께 돌려주게 합니다. HackerNoon 필자가 REA 6.4.0에서 MCP 도구 목록을 직접 불러 보니 도구가 170개였습니다(HackerNoon, 2026-10-14). 사람이 몇 주 걸려 익히던 디컴파일러 사용법을 에이전트가 이 도구 목록으로 대신 다루는 셈입니다.

README는 분석이 내 컴퓨터에서 돈다("Analysis runs locally")고 쓰면서도, 에이전트가 쓰는 모델 회사의 데이터 정책은 별개라고 밝힙니다. 디컴파일 결과를 읽는 것은 모델이라, 클라우드 모델을 쓰면 회사 바이너리의 분석 내용이 모델 회사로 갑니다. 한국어 README(docs/readme/README_ko.md)와 한국어 사이트(rea.tools/ko/)도 있습니다.

별 26만 개는 어떻게 쌓였나

저장소는 4월에 만들어졌지만 별은 10월 둘째 주에 한꺼번에 붙었습니다. GitHub API로 보면 저장소 생성일은 2026년 4월 14일이고, 첫 커밋 이름은 "betterBinaryMCP"로 Hopper 디스어셈블러 전용 MCP 서버였습니다. npm 패키지는 7월 12일에 처음 올라왔고, 7월 14일의 첫 Show HN은 3점에 그쳤습니다(systemdesign.academy, 2026-10-12).

분위기가 바뀐 것은 10월 10일 Hacker News 글이 805점, 댓글 337개를 받으면서입니다(HN). 그 뒤 별 수는 하루에 수만 개씩 늘었습니다.

2026년 10월 15일 GitHub API 기준 별은 260,833개, 포크는 65,612개입니다. 이 글을 쓰는 동안에도 수백 개씩 늘었으니, 이 숫자는 날짜와 함께 읽어야 합니다. 이번 주 유튜브에 올라온 '소프트웨어는 끝났다'는 취지의 영상들이 21만, 22만을 말한 것도 찍은 날이 달라서입니다(21만 영상, 22만 영상, 2026-10-14).

급등을 의심하는 사람도 있습니다. HN에서는 "약 5일 만에 4.2천에서 5.46만으로 늘었고 포크 비율이 이례적"이라며 별 봇을 의심하는 댓글이 나왔습니다. 일본 개발자 zephel01은 포크가 별의 약 24%로 비슷한 도구들(11~12%)보다 높다고 짚었습니다(note.com, 2026-10-14). GitHub의 가짜 별을 추적한 연구는 2024년에 가짜 별이 급증했고, 수명이 짧은 피싱·악성 저장소와 AI·LLM 저장소 홍보에 주로 쓰였다고 보고했습니다(arXiv 2412.13459). REA의 별이 가짜라는 근거는 없습니다. 다만 별 수는 몇 명이 관심을 보였는지를 말할 뿐, 도구가 얼마나 잘 동작하는지는 말해 주지 않습니다.

공식 사례로 본 실력: 대표 사례는 함수 하나 크기

공식 사이트 rea.tools의 대표 사례는 구체적이고 검증까지 붙어 있지만, 규모는 함수 하나나 기능 하나입니다. 국내 매체 중 가장 꼼꼼하게 다룬 플래텀도 같은 선을 그었습니다(플래텀, 2026-10-15).

가장 많이 인용되는 사례는 1996년 윈도 게임 DX-Ball입니다. 공이 벽돌에 부딪힐 때 효과음을 왼쪽, 오른쪽 스피커 중 어디로 보낼지 정하는 함수를 찾아 C로 다시 썼습니다(rea.tools DX-Ball).

63바이트 일치에는 조건이 붙습니다. 사례 페이지는 검토를 거친 재배치 정보를 적용한 결과라고 밝힙니다. 같은 페이지는 프로젝트 전체로는 33개 함수가 바이트 단위로 일치했다고 적지만, 게임 전체 재작성은 끝나지 않았다고 덧붙입니다. 나머지 사례도 크기가 비슷합니다.

• Aegis 인증 앱: 공식 APK(3.4.3)를 분석해 6자리 일회용 코드가 SHA1, 30초 주기의 TOTP로 만들어진다는 것을 확인하고, 독립 구현과 133개 경우에서 결과를 맞춰 봤습니다(rea.tools Aegis).
• Notion 데스크톱: 7.6.1 버전의 app.asar에서 복사 요청이 notion:clipboard:write라는 IPC 채널을 지나 메인 프로세스에서 송신자를 검사한 뒤 클립보드에 쓰이는 경로를 따라갔습니다. 실제 화면 세션을 캡처한 것은 아니라고 적혀 있습니다(rea.tools Notion).
• 메인 페이지 예시: 크롬 공룡 게임의 속도 규칙(시작 6, 가속 0.001, 최대 13), 윈도 계산기에서 200 + 10%가 220이 되는 분기를 찾았습니다(rea.tools).

모두 "이 기능은 어떻게 동작하나"에 답한 사례이고, 앱 전체를 복제한 사례는 공식 페이지에 없습니다.

REA 없이도 될까: 독립 실험 네 건

지금까지 공개된 독립 실험은 같은 결론을 냅니다. 최신 모델이 작은 프로그램을 볼 때는 REA가 있으나 없으나 결과가 거의 같습니다.

국내 유튜버 실험이 흥미롭습니다. 직접 만든 macOS 노트 앱을 컴파일해 소스 없이 넘기고, 전용 파일 형식을 읽는 파이썬 함수를 만들게 했습니다. 예상과 달리 REA를 붙이지 않은 에이전트도 스스로 Ghidra를 불러 같은 결과를 냈습니다. 그는 REA의 가치를 미리 정의해 둔 도구와 조사 가이드로 분석을 더 빠르고 체계적으로 하게 해 주는 데 있다고 정리했고, 모델과 에이전트가 발전할수록 그 차별점도 줄어들 수 있다고 봤습니다.

퍼진 화제작 중에도 REA 없이 만든 것이 많습니다. Better Stack 영상에서 Space Cadet Pinball을 2시간 25분 만에 Rust 3만 1천 줄로 옮긴 사례는, 진행자가 REA 도구들을 설치하기 싫어서 Opus 5.5 단독으로 했다고 직접 말합니다(Better Stack, 2026-10-12).

그렇다고 쓸모가 없다는 뜻은 아닙니다. HN의 보안 연구자 tptacek은 Ghidra를 중심에 두더라도 "Claude가 즉흥으로 하는 것보다 나은 무언가"가 아직은 필요하다고 했고, 로컬 Qwen 모델로 Ghidra CLI만 줬을 때는 길을 잃다가 REA로는 진척이 있었다는 댓글도 있습니다(HN). 국내에서도 로컬 모델과 opencode로 REA와 Ghidra 12.1.4를 붙여 윈도 그림판을 분석하고 자바스크립트로 다시 만든 사용기가 나왔습니다. 필자는 설정 단계에서 에이전트 선택이 반영되지 않는 버그를 --client opencode로 우회했다고 적었습니다(멍개의 연구소, 2026-10-13).

정리하면 최신 모델과 작은 바이너리에서는 차이가 작고, 약한 모델이나 로컬 모델에서는 도움이 될 수 있습니다. 크거나 난독화된 바이너리로 검증한 공개 자료는 찾지 못했습니다. GitTested도 "We didn't test large or obfuscated binaries"라고 적었습니다. 검증이 빠진 경우도 보고됐습니다. HackerNoon 필자의 Electron 앱 실험에서는 preload 스크립트 2개를 0개로 보고했고, 한계 항목 744건 중 365건은 결과 예산을 넘어 관계를 버린 것이었습니다.

"소프트웨어 값이 0원"을 숫자로 확인하면

이번 주 유튜브에서 가장 많이 퍼진 주장은 "소프트웨어를 만드는 값이 0원으로 간다"였습니다. 영상이 든 숫자를 하나씩 원문과 맞춰 봤습니다.

여기까지는 "만드는 값이 빠르게 떨어진다"는 주장을 뒷받침합니다. 단가를 낮춰 쓰는 방법은 Opus 5.5 잘 쓰는 법에서 따로 정리했습니다. 반대 숫자도 있습니다. Cloudflare는 재구현한 vinext가 "experimental"이고 아직 의미 있는 규모의 트래픽으로 검증되지 않았다고 직접 밝혔습니다. 일부 고객이 프로덕션에서 쓰고 있다고도 했지만, 프로덕션에 쓸 때는 주의하라는 단서를 달았습니다. 컴파일러는 어셈블러와 링커를 GCC에 기대고, Next.js 재구현은 테스트 수(Vitest 1,700개 이상, E2E 380개)는 밝혔지만 모두 통과했다고 쓰지 않았습니다. 주가도 돌아왔습니다. 연합뉴스는 로이터를 인용해 10월 6일 S&P500 소프트웨어·서비스 지수가 1.3% 올라 지난해 11월 이후 최고 수준을 기록했다고 전했습니다(연합뉴스, 2026-10-07).

그래서 "소프트웨어가 0원이 된다"보다 **"기능 하나를 다시 만드는 값이 빠르게 0에 가까워진다"**가 숫자에 맞는 표현입니다. 화면 하나, 내보내기 하나, 파일 형식 하나를 알아내고 다시 짜는 비용이 떨어지고 있습니다. 회사가 쌓아 온 데이터와 고객, 결과에 대한 책임까지 같이 떨어지는 것은 아닙니다.

"REA로 어도비를 베꼈다"는 틀린 이야기

지난주부터 가장 많이 퍼진 장면은 포토샵을 닮은 무료 앱 PhotoCraft였지만, 이 앱은 REA로 만든 것이 아닙니다. ArtCraft 팀의 Brandon Thomas가 Claude Opus 5.5로 PhotoCraft, VectorCraft, FilmCraft 등 어도비 제품을 닮은 앱 7개를 Rust로 만들었고(VISUALOUNGE, 2026-10-08), 같은 시기에 REA가 떠서 두 이야기가 한데 묶였습니다.

PhotoCraft README는 "public specs and observed behaviour only", 즉 공개 명세와 겉으로 관찰한 동작만 썼다고 밝힙니다(storytold/photocraft). ArtCraft 개발자는 REA 스레드에 Ghidra는 일부러 건드리지 않는다고 썼습니다(HN 댓글). 반론도 있습니다. GeekNews에 소개된 Lobste.rs 의견처럼, 커밋에 Claude가 공동 작성자로 찍혀 있으면 모델이 학습한 코드가 섞였을 수 있어 깨끗한 클린룸이라 보기 어렵다는 지적입니다(GeekNews).

국내에서도 AI타임스가 인터페이스와 제품군을 전면 모방한 특성상 저작권 침해 경고나 법적 대응 가능성이 크다는 전문가 지적을 전했습니다(AI타임스, 2026-10-12). 완성도도 아직 멀었습니다. README는 "early alpha"이며 "not yet a Photoshop replacement for daily professional work"라고 적고, 개발자도 HN에서 "still super early alpha"라고 했습니다. 국내 블로그 일부가 ArtCraft를 REA 활용 사례처럼 소개했는데, 두 프로젝트는 따로 봐야 합니다.

한국에서 써도 되나: 저작권법 조문으로 본 선

REA를 설치하는 것은 문제가 아닙니다. 무엇을, 왜 뜯느냐가 문제입니다. REA README도 용도를 "lawful research, education, interoperability, software preservation, and analysis of software you own or are authorized to examine"로 한정합니다. 내가 만든 앱, 분석을 허락받은 앱, 오픈소스는 괜찮습니다. 남의 상용 앱을 뜯어 같은 기능을 내 제품에 넣는 일이 문제입니다.

REA를 검증한 국내 유튜브 영상 가운데에는 저작권법 조문을 화면에 띄우고, 개인적인 목적이면 해당되고 영리 목적으로 복제하면 법에 위반될 수 있다는 취지로 설명한 것도 있습니다(영상). 국가법령정보센터의 현행 조문(2026년 8월 11일 시행)과 맞춰 보면 이렇습니다.

"개인 목적이면 역분석해도 된다"는 문장은 조문 문구로 뒷받침되지 않습니다. 역분석을 직접 다루는 조항은 제101조의4이고, 목적은 호환으로 한정됩니다. 마음에 드는 기능을 이해해서 내 제품에 비슷하게 넣는 것은 호환이 아닙니다. 법제처 찾기쉬운 생활법령정보에 게시된 저작권 공정이용 가이드라인 해설(2016년 수정본)도 "역분석의 대상이 되는 프로그램과 유사한 기능의 프로그램을 만들기 위한 목적은 이 규정에 의한 허용범위에 포함되지 아니한다"고 설명합니다(찾기쉬운 생활법령정보 PDF). 다만 해석이 하나로 정리된 것은 아닙니다. 아래 판결은 제101조의3 제1항을 역분석에도 적용되는 일반 규정으로 봤고, 원리 확인용 조사(제6호)가 코드 역분석까지 덮는지는 판결과 해설의 설명이 다릅니다.

실제 판결도 있습니다. 서울중앙지방법원 2013가합23162 판결(2014년 1월 23일, 확정)은 지도 엔진 라이선스를 산 업체가 역분석으로 라이선스 확인과 미인증 단말 차단 기능을 지운 것을 기술적 보호조치 무력화로 봤습니다. 홈페이지 주소와 패키지명을 지운 것은 권리관리정보 제거로 인정했습니다. 원고에게 기술 지원을 요청하면 쉽게 해결할 수 있었다며 역분석이 불가피했다는 주장(보충성)도 받아들이지 않았고, 공정이용의 일반론으로 역분석을 허용할 수는 없다고 밝혔습니다. 판결은 역분석이 목적 코드의 복제를 필연적으로 수반한다고 봤지만, 라이선스 대금을 다 낸 점을 들어 이용허락 범위를 넘었다는 이유의 복제권 침해 주장은 받아들이지 않았습니다(한국저작권위원회 판례 요약). 플래텀의 표현대로 정당하게 구입한 것과 역분석 권한은 별개이고, 막히면 먼저 권리자에게 묻는 것이 실무적으로도 맞는 순서입니다.

해외는 조금 다릅니다. 미국은 정당한 이유가 있고 다른 방법이 없을 때 디스어셈블리를 공정이용으로 본 판례가 있고(Sega v. Accolade, 1992), 저작권법 제1201조(f)는 상호운용성 목적의 보호조치 우회를 예외로 둡니다(17 U.S.C. §1201). 하지만 소프트웨어 사용권 계약(EULA)의 역설계 금지 조항을 어긴 것을 계약 위반으로 인정한 판결도 있습니다(Bowers v. Baystate, 2003). EU 소프트웨어 지침 제6조는 디컴파일을 상호운용성 정보에 한정하고 표현이 실질적으로 비슷한 프로그램을 만드는 데 쓰는 것을 금지하며(Directive 2009/24/EC Art. 6), 제8조는 이 허용 범위를 계약으로 막는 조항을 무효로 봅니다(Art. 8). 어느 쪽이든 "남의 코드를 읽고 표현까지 비슷하게 다시 만드는 것"을 허용하는 곳은 없습니다.

국내 사용자가 직접 선을 그은 사례도 있습니다. AI매터스에 칼럼을 쓰는 김탄휴 씨는 REA로 한글과 워드 문서를 함께 여는 앱을 Rust로 다시 만들었지만, 파일을 달라는 요청에도 "한컴의 지적재산권을 존중하고 솔직히 한컴이 무서워서" 배포하지 않았다고 썼습니다. 그는 REA가 남기는 증거 기록이 오히려 베낀 사람에게 불리한 증거가 된다고도 지적했습니다(AI매터스, 2026-10-15). 공개 명세가 있는 형식이라면 역분석보다 명세를 보고 만드는 편이 안전합니다.

AI 서비스 약관도 따로 봐야 합니다. HN 스레드에는 OpenAI 계정이 영구 정지됐다는 댓글이 2건 있고, 그중 하나는 "RE 작업을 너무 많이 해서"라고 이유를 적었습니다(HN 댓글). 일부 영상은 이를 REA 때문이라고 소개했지만, 댓글에는 REA를 썼다는 말이 없습니다. 그래도 모델 회사가 리버스 엔지니어링 요청을 민감하게 본다는 신호로는 읽을 만합니다. REA의 면책 문서도 DRM과 라이선스 검사 우회, 독점 소프트웨어 복제, AI 회사의 이용 정책을 피하는 용도, 게임 치트, 인증과 봇 방어 우회를 돕지 않는다고 밝힙니다(DISCLAIMER.md).

이 절은 법률 자문이 아닙니다. 상용 제품에 쓸 계획이라면 변호사와 먼저 상의하세요.

설치 전에 알아야 할 보안 함정

가장 먼저 확인할 것은 설치 경로입니다. 10월 13일 REA 저장소에 올라온 이슈 #2424에 따르면, rea-tools/rea라는 가짜 저장소가 공식 README를 그대로 복사하고 "Windows Standalone .exe" 릴리스를 붙여 압축 파일을 배포했습니다. 이 파일은 172회 내려받아졌고, Microsoft Defender는 Trojan:Win32/Wacatac.B!ml로, VirusTotal에서는 45개 엔진 중 8개가 트로이 목마나 드로퍼로 탐지했습니다. 이 조직은 10월 10일에 만들어졌고, 이름부터 공식 사이트 rea.tools를 흉내 냈습니다(GitHub 이슈 #2424).

지금 이 저장소는 사라졌고, 공식 README 첫머리에는 공식 배포처가 morluto/rea, rea.tools, npm rea-agents 세 곳뿐이라는 안내가 붙었습니다. README는 "A similar repository name or copied README does not establish that a download is official."이라고 적습니다. "공식 무료 다운로드", "윈도 설치 파일"을 내건 저장소는 의심하세요. 10월 15일에도 "Official free download"를 내건 다른 유사 저장소(rea-githu/REA)가 남아 있습니다. 이 저장소의 악성 여부는 확인되지 않았습니다.

그다음은 권한입니다. REA의 보안 문서는 스스로 샌드박스가 아니라고 밝힙니다(SECURITY.md). 내 사용자 권한으로 돌아가는 도구에 출처를 모르는 바이너리를 넣는 것이니, 분석은 따로 만든 폴더나 가상 머신에서 하는 편이 낫습니다. HN에서는 에이전트에 붙여 넣는 설치 프롬프트가 curl | bash와 다를 바 없다는 비판도 나왔습니다. GitTested가 권장한 대로 npx -y rea-agents@latest setup --dry-run --json으로 바뀔 내용을 먼저 보고 승인하는 방법이 있습니다(GitTested).

분석 대상이 에이전트를 공격할 수도 있습니다. 실행에는 아무 영향이 없는 문자열을 바이너리에 심어 두면, 디컴파일 결과를 읽는 모델에게 거짓 지시를 넣을 수 있다는 연구가 5월에 나왔습니다(arXiv 2605.30667). 프랑스 블로거 Korben은 이를 들어 수상한 샘플을 AI 에이전트에 그냥 넘기지 말라고 경고했습니다. 앞서 말했듯 클라우드 모델을 쓰면 분석 결과가 모델 회사로 가므로, 회사 내부 바이너리나 고객 데이터가 든 파일은 넣지 않는 것이 원칙입니다. AI 도구를 쓴 공격이 실제로 어떻게 벌어졌는지는 금융사 7곳 연쇄 해킹과 ARTEX를 다룬 글에서 정리했습니다. 에이전트에 확장을 붙일 때 그 확장이 내 권한으로 돈다는 점은 Claude Code Mods 글에서도 다뤘습니다.

내 제품은 무엇을 지켜야 하나

REA가 개발자에게 주는 진짜 숙제는 "내 앱도 이렇게 읽힌다"는 사실입니다. 클라이언트로 배포한 코드는 원래부터 읽을 수 있었습니다. 다만 디컴파일러를 다룰 줄 아는 사람이 드물었을 뿐인데, 이제 그 일을 에이전트가 합니다. REA를 검증한 국내 유튜브 영상에는 트레이딩 차트 서비스의 프리미엄 지표를 역분석해 무료로 쓰고 있다는 SNS 게시물까지 소개됐습니다(영상). 그 주장이 사실인지는 확인되지 않았지만, 사실이라면 유료 기능을 판정하는 로직이 클라이언트에 있었다는 뜻입니다.

당장 점검할 것은 네 가지입니다.

1. 유료 기능과 권한 판정은 서버에서 합니다. 앱이 "이 사용자는 프리미엄"이라고 스스로 판단하면, 그 분기는 찾아서 바꿀 수 있습니다. 결과를 계산하는 로직 자체를 서버에 두면 앱을 뜯어도 얻을 것이 없습니다.
2. API 키와 비밀 규칙을 앱에 넣지 않습니다. Electron 앱의 app.asar, 안드로이드 APK, 자바스크립트 번들은 REA의 기본 분석 대상입니다. 키는 서버에 두고, 앱에는 짧게 만료되는 토큰만 줍니다.
3. 내 앱을 먼저 뜯어 봅니다. 배포 빌드에 REA나 Ghidra를 붙여 "이 앱에서 결제 확인이 어떻게 동작하는지 증거와 함께 보여 줘"라고 물어보세요. 저작권법 제104조의2가 보안성 검사를 예외로 둔 것처럼, 내 제품의 빈틈을 찾는 것은 정당한 용도입니다.
4. 난독화는 시간을 버는 것일 뿐입니다. 막는 장치가 아니라 늦추는 장치로 보고, 중요한 것은 처음부터 클라이언트에 두지 않는 설계로 지킵니다.

그리고 해자를 다시 정의해야 합니다. 화제가 된 글 "Your Moat Is Dead"는 기능, 익숙한 UX, 독점 파일 형식, 연동, 좌석당 과금이라는 방어선이 약해지고, 방어력이 책임, 계속 쌓이는 독점 데이터, 유통과 신뢰, 물리적 운영으로 옮겨 간다고 봤습니다(Tech Founder Stack, 2026-10-07). 국내 커뮤니티에서도 "소프트웨어의 해자는 데이터"라는 반응이 이어졌습니다(에펨코리아, EOND).

제 제품에 대입해 보면 질문이 바뀝니다. "이 기능을 남이 만들 수 있나"는 이제 답이 대부분 "그렇다"입니다. 대신 **"남이 이 기능을 똑같이 만들어도 고객이 왜 계속 내 것을 쓰나"**에 한 줄로 답할 수 있어야 합니다. 그 답이 쌓인 데이터인지, 결과에 대한 책임인지, 이미 업무에 박힌 연동인지 적어 보세요. 한 줄이 나오지 않는다면, 그 기능은 지금 0원 쪽으로 가고 있는 것입니다.

이 글의 한계

• 저는 이 글을 쓰며 REA를 제 제품에 직접 붙여 실험하지 않았습니다. REA 유무 비교는 GitTested, Korben, MindStudio, 국내 유튜버가 공개한 결과에 기댔습니다. 큰 앱이나 난독화된 앱에서 어떻게 동작하는지는 공개된 검증이 없어 다루지 못했습니다.
• 별 수와 버전은 하루에도 바뀝니다. 이 글의 숫자는 2026년 10월 15일 기준입니다(최신 버전 6.5.0).
• 저작권법 해석은 학설과 판례가 갈리는 부분이 있습니다. 서울중앙지법 판결은 제101조의3 제1항을 역분석에도 적용되는 일반 규정으로 봤습니다. 이 논리대로라면 개인 목적 복제(제4호)도 이론상 적용될 여지는 있지만, 판결이 이를 직접 판단하지는 않았습니다. 이 글은 법률 자문이 아닙니다.
• "REA 때문에 계정이 정지됐다"는 후기는 확인하지 못했습니다. 확인된 것은 리버스 엔지니어링 작업 일반으로 정지됐다는 댓글입니다.

자주 묻는 질문

REA를 설치하기만 해도 불법인가요?

아닙니다. REA는 MIT 라이선스 오픈소스이고, 내가 만든 앱이나 허락받은 앱, 오픈소스를 분석하는 데 쓰는 것은 문제가 없습니다. 역분석으로 얻은 정보로 표현이 비슷한 프로그램을 만들거나, 호환 목적 밖에서 남의 프로그램을 역분석하거나, DRM이나 라이선스 확인을 우회할 때 문제가 될 수 있습니다.

개인적으로만 쓰면 남의 앱을 뜯어도 되나요?

조문 문구로는 그렇게 단정할 수 없습니다. 저작권법 제101조의3 제1항 제4호가 허용하는 것은 가정 같은 한정된 장소에서 비영리로 하는 "복제"이고, 역분석을 명시하지 않습니다. 역분석을 직접 허용하는 제101조의4는 호환 목적에 한정되고, 얻은 정보로 표현이 실질적으로 비슷한 프로그램을 만드는 것은 금지됩니다. 판결 중에는 제101조의3을 역분석에도 적용한 것이 있어 해석이 완전히 정리되지는 않았습니다.

REA 없이 Claude Code에 Ghidra만 연결해도 되나요?

작은 프로그램이라면 결과가 거의 같다는 실험이 여럿 있습니다. GitTested 실험에서는 일반 도구 74점, REA 73점이었고 REA 쪽 토큰이 약 2.5배였습니다. 로컬 모델처럼 약한 모델을 쓰거나 분석 절차를 표준화하고 싶다면 REA가 도움이 될 수 있습니다.

어디서 내려받아야 안전한가요?

공식 경로는 github.com/morluto/rea, rea.tools, npm 패키지 rea-agents 세 곳뿐입니다. 윈도 설치 파일이나 압축 파일을 따로 배포하는 저장소는 가짜일 가능성이 높습니다. 실제로 이런 가짜 저장소에서 백신 일부가 트로이 목마로 탐지한 압축 파일이 172회 내려받아졌습니다.

내 앱을 REA로부터 지키려면 무엇부터 하나요?

유료 기능 판정과 핵심 계산을 서버로 옮기고, API 키를 앱에서 빼는 것이 먼저입니다. 그다음 배포 빌드를 직접 분석해 보면서 클라이언트에 남은 비밀이 없는지 확인하세요.

마치며

REA는 리버스 엔지니어링을 발명하지 않았습니다. Ghidra는 2019년부터 공개돼 있었고, 최신 모델은 REA 없이도 Ghidra를 불러 씁니다. REA가 한 일은 그 문턱을 "npx 한 줄"로 낮추고, 결과를 근거와 함께 정리해 주는 것입니다. 별 26만 개는 그 문턱이 낮아졌다는 사실에 개발자들이 얼마나 놀랐는지를 보여 줍니다.

• 공식 대표 사례는 함수 하나, 기능 하나 수준이고, 독립 실험은 작은 프로그램에서 REA 유무의 차이가 작다고 봤습니다. 앱 전체를 베꼈다는 이야기는 대부분 REA와 무관하거나 과장입니다.
• "소프트웨어 0원"은 정확히는 "기능 하나를 다시 만드는 값이 0에 가까워진다"입니다. 데이터, 책임, 신뢰는 그만큼 싸지지 않습니다.
• 한국법에서 역분석을 직접 허용하는 조항은 호환 목적에 한정되고, 원리 확인용 조사가 어디까지 덮는지는 판결과 해설이 갈립니다. 남의 기능을 이해해 비슷하게 만드는 용도라면 공개 명세를 보고 직접 짜는 쪽이 안전합니다.
• 설치는 공식 경로 세 곳에서만 하고, 분석은 격리된 환경에서 하세요.

가장 실용적인 사용법은 남의 앱이 아니라 내 앱을 먼저 뜯어 보는 것입니다. 그 결과가 불편하다면, 고칠 곳이 거기에 있습니다.

출처

1. GitHub morluto/rea: github.com/morluto/rea
2. hysenlabs: hysenlabs.com/projects/morluto-rea
3. MindStudio, 2026-10-11: mindstudio.ai/blog/reverse-engineer-anything-mcp
4. HackerNoon, 2026-10-14: hackernoon.com/i-tested-rea-githubs-viral-reverse-engineering-tool-on-a…
5. systemdesign.academy, 2026-10-12: systemdesign.academy/explained/rea-reverse-engineer-anything
6. HN: news.ycombinator.com/item?id=50028275
7. Qiita: qiita.com/hisashi-ito/items/b2ec2262f0b26489ae38
8. GitHub API: api.github.com/repos/morluto/rea
9. 21만 영상: youtube.com/watch?v=VZB5S_gk830
10. 22만 영상, 2026-10-14: youtube.com/shorts/93rOnit-i_U
11. note.com, 2026-10-14: note.com/zephel01/n/n9d2ed82dcd4d
12. arXiv 2412.13459: arxiv.org/abs/2412.13459
13. 플래텀, 2026-10-15: platum.kr/archives/296378
14. rea.tools showcase: rea.tools/showcase/dx-ball
15. rea.tools Aegis: rea.tools/showcase/aegis
16. rea.tools Notion: rea.tools/showcase/notion
17. rea.tools: rea.tools
18. GitTested: gittested.com/reviews/morluto-rea
19. Korben: korben.info/en/rea-ai-agent-reverse-engineering-test.html
20. 국내 유튜버 실험: youtube.com/watch?v=rwCDPZP_Zk4
21. Better Stack, 2026-10-12: youtube.com/watch?v=jtfpCGsbSJU
22. 멍개의 연구소, 2026-10-13: m.blog.naver.com/PostView.naver?blogId=pjt3591oo&logNo=224440156330
23. Reuters: finance.yahoo.com/news/anthropics-ai-tools-deepen-selloff-054551832.html
24. Anthropic 가격표: platform.claude.com/docs/en/about-claude/pricing
25. Cloudflare, 2026-02-24: blog.cloudflare.com/vinext
26. Anthropic, 2026-02-05: anthropic.com/engineering/building-c-compiler
27. TechCrunch, 2026-04-18: techcrunch.com/2026/04/18/the-app-store-is-booming-again-and-ai-may-be-…
28. storytold/artcraft: github.com/storytold/artcraft
29. storytold/photocraft: github.com/storytold/photocraft
30. 연합뉴스, 2026-10-07: yna.co.kr/view/AKR20261007068600009
31. VISUALOUNGE, 2026-10-08: visualounge.com/dispatch/artcraft-seven-adobe-apps-rebuilt-in-rust
32. HN 댓글: news.ycombinator.com/item?id=50029182
33. GeekNews: news.hada.io/topic?id=34995
34. AI타임스, 2026-10-12: aitimes.com/news/articleView.html?idxno=216149
35. 국가법령정보센터의 현행 조문: law.go.kr/법령/저작권법
36. 제101조의3: law.go.kr/법령/저작권법/제101조의3
37. 제101조의4: law.go.kr/법령/저작권법/제101조의4
38. 제104조의2: law.go.kr/법령/저작권법/제104조의2
39. 찾기쉬운 생활법령정보 PDF: easylaw.go.kr/CSP/FlDownload.laf?flSeq=341063
40. 한국저작권위원회 판례 요약: copyright.or.kr/information-materials/law-precedent/view.do?brdctsno=16…
41. Sega v. Accolade: copyright.gov/fair-use/summaries/segaenters-accolade-9thcir1992.pdf
42. 17 U.S.C. §1201: law.cornell.edu/uscode/text/17/1201
43. Bowers v. Baystate: law.resource.org/pub/us/case/reporter/F3/320/320.F3d.1317.01-1109.01-11…
44. Directive 2009/24/EC Art. 6: legislation.gov.uk/eudr/2009/24/article/6
45. Art. 8: legislation.gov.uk/eudr/2009/24/article/8
46. AI매터스, 2026-10-15: aimatters.co.kr/news-report/55416
47. HN 댓글: news.ycombinator.com/item?id=50031271
48. DISCLAIMER.md: github.com/morluto/rea/blob/main/DISCLAIMER.md
49. GitHub 이슈 #2424: github.com/morluto/rea/issues/2424
50. SECURITY.md: github.com/morluto/rea/blob/main/SECURITY.md
51. arXiv 2605.30667: arxiv.org/abs/2605.30667
52. Tech Founder Stack, 2026-10-07: techfounderstack.com/p/your-moat-is-dead-anyone-can-rebuild
53. 에펨코리아: fmkorea.com/10447564227
54. EOND: eond.com/threads/493775