REA 리버스 엔지니어링 도구 — 설치법과 법적 경계

한 개발자가 최근 실험을 하나 했습니다. 자기가 만들어 파는 맥용 앱의 설치 파일 하나만 AI에게 건넸습니다. 소스코드는 한 줄도 주지 않았습니다.

3분 뒤, AI는 그 앱의 내부 설계도를 그려서 내놓았습니다. 화면을 어떤 방식으로 띄우는지, 글을 복사할 때 왜 굳이 별도의 프로그램을 하나 더 띄우는지, 어떤 블로그 서비스들에 맞춰 글을 바꿔주는지까지. 추가로 든 돈은 0원이었습니다.

그가 쓴 도구 이름이 REA(Reverse Engineer Anything) — 직역하면 “무엇이든 역분석한다”입니다. 올해 4월에 올라온 무료 오픈소스(누구나 내려받아 쓰고 고칠 수 있게 코드를 공개한 프로그램)인데, 10월 들어 개발자 세계에서 가장 시끄러운 이름이 됐습니다. 동시에 가장 불편한 이름이기도 합니다.

잠깐, ‘리버스 엔지니어링’이 뭔가요

식당에서 먹은 요리가 너무 맛있어서, 집에 와 맛을 되짚어 레시피를 알아내는 일을 생각하면 됩니다. 완성품만 보고 만드는 방법을 거꾸로 알아내는 것 — 그게 리버스 엔지니어링입니다.

소프트웨어에서 이게 왜 일이 되느냐면, 우리가 쓰는 프로그램은 사람이 읽을 수 있는 형태로 오지 않기 때문입니다. 개발자가 쓴 설계도(소스코드)는 회사 금고에 있고, 우리 컴퓨터에 설치되는 건 기계만 알아보는 암호 같은 덩어리입니다. 그 덩어리를 거꾸로 되짚어 “이 프로그램이 안에서 대체 무슨 일을 하는가”를 알아내는 작업이 소프트웨어 역분석입니다.

이게 불법이냐 하면, 그렇지 않습니다. 오히려 산업을 만든 기술입니다. 1980년대에 IBM 컴퓨터의 동작을 낱낱이 파악해 똑같이 작동하는 호환 컴퓨터를 만든 회사들이 지금의 PC 시장을 열었고, 백신 회사는 악성코드를 뜯어봐야 백신을 만들 수 있으며, 서로 다른 회사 프로그램끼리 파일을 주고받는 것도 상대 형식을 뜯어봤기 때문에 가능합니다. 한국 저작권법에도 이를 허용하는 조항이 따로 있습니다.

문제는 지독하게 어려웠다는 점입니다. 기계어를 읽어내는 훈련을 받은 사람이 드물었고, 그래서 소프트웨어 회사들의 진짜 보호막은 자물쇠가 아니라 “이걸 읽을 줄 아는 사람이 거의 없다”는 희소성이었습니다.

REA가 한 일이 바로 그 희소성을 없앤 것입니다.

세 줄 요약

REA는 새 기술이 아닙니다. 30년 된 분석 도구들을 AI가 쓸 수 있게 묶어준 것뿐입니다. 바뀐 건 기술이 아니라 누구나 할 수 있게 됐다는 사실입니다.
그래서 “남의 앱을 뜯어보는 일”이 전문가의 작업에서 3분짜리 심부름이 됐습니다. 공짜이고, 내 컴퓨터 안에서 돌아가고, 설치는 명령어 한 줄입니다.
합법과 불법을 가르는 선은 ‘기능’이 아니라 ‘표현’에 있습니다. 남의 앱이 뭘 하는지 알아내 내 방식대로 다시 만드는 건 괜찮습니다. 뜯어낸 코드를 가져다 쓰면 그때 걸립니다. 이 차이를 모르고 쓰면 위험합니다.

아래부터는 무엇인가 → 사람들은 이렇게 쓴다 → 어떻게 작동하나 → 직접 설치하는 법 → 앞으로 바뀔 것 순서로 풀어가겠습니다. 직접 써볼 생각이 없으시면 설치 대목은 건너뛰고, ‘넘지 말아야 할 선’과 맨 끝 두 꼭지만 읽으셔도 충분합니다.

기판 위에 마이크로칩을 집어 올리는 핀셋 Photo by Vishnu Mohanan on Unsplash

/what — REA는 무엇인가

답부터: AI에게 ‘분석 도구 상자’를 쥐여주는 프로그램입니다. 그 이상도 이하도 아닙니다.

비유하자면 이렇습니다. 자동차를 분해하는 공구는 예전부터 정비소에 다 있었습니다. 없던 것은 그 공구를 쓸 줄 아는 정비사였습니다. REA는 공구를 새로 발명한 게 아니라, AI를 정비사로 앉힌 것입니다.

실제로 뜯는 일은 전부 기존 도구들이 합니다 — 프로그램 덩어리를 해독하는 건 Hopper·Ghidra·IDA가, 안드로이드 앱을 푸는 건 JADX가, 가전제품 펌웨어를 여는 건 Binwalk가 합니다. 다들 10~30년 된 전문가용 도구입니다. REA는 이들과 AI 사이에서 말을 통역해 주는 중개 계층입니다.

기술적으로는 이 통역 규격을 **MCP(Model Context Protocol)**라고 부릅니다. AI가 외부 도구를 불러 쓰는 공용 규약인데, 요즘 AI 도구들이 서로 연결되는 표준이라고 보시면 됩니다. 저장소 설명문도 한 줄입니다 — “Reverse engineer anything with agents, from app behavior down to native binaries”(에이전트로 무엇이든 역분석한다, 앱 동작부터 프로그램 속살까지).

구분	내용
저장소(코드를 올려두는 공개 공간)	morluto/rea · GitHub
생성일	2026년 4월 14일
라이선스	MIT — 공짜로 쓰고 회사 제품에 넣어도 됩니다
최신 버전	rea-agents v6.7.0 (2026년 10월 18일)
공식 사이트	rea.tools
한국어 문서	README_ko.md 제공

출처: GitHub REST API /repos/morluto/rea 및 /releases 조회 (2026-10-18 20:30 KST 기준)

릴리스 속도가 눈에 띕니다. 10월 9일(UTC) 하루에만 v6.1.0·v6.2.0·v6.3.0 세 건이 올라왔고, 10월 18일에도 v6.6.0(03:40 UTC)과 v6.7.0(07:45 UTC)이 네 시간 간격으로 나왔습니다. README도 “REA는 빠르게 바뀌고 새 릴리스에 버그 수정이 자주 포함되니 최신 상태를 유지하라”고 직접 경고합니다. 뒤집어 말하면 아직 안정화된 도구가 아닙니다.

스타 31만 — 이게 진짜인가

이 저장소를 둘러싼 가장 큰 논쟁은 성능이 아니라 인기의 진위입니다.

스타(star): 깃허브에서 “이거 괜찮다”고 눌러두는 표시. SNS의 ‘좋아요’·‘즐겨찾기’에 해당하고, 그 수가 곧 그 프로그램의 평판이자 순위가 됩니다. 그래서 돈을 받고 스타를 눌러주는 업자도 있습니다.

“열흘 만에 1만에서 26만”, “일주일에 10만 증가” 같은 보도가 이어지면서 스타를 돈으로 샀다는 의혹이 제기됐습니다.

직접 계산해 봤습니다. 생성일부터 오늘까지 187일, 누적 평균 하루 1,683개입니다. 비교군과 나란히 놓으면 이렇습니다. 다만 이 평균값은 실제보다 완만하게 보인다는 점을 먼저 밝힙니다 — REA의 스타는 187일에 고르게 쌓인 게 아니라 10월 초순 열흘 남짓에 몰렸습니다.

주의해서 읽어야 할 그래프입니다. REA의 스타는 187일에 고르게 쌓인 것이 아니라 10월 초순 열흘 남짓에 집중됐으므로, 이 막대는 실제 피크 속도를 크게 낮춰 보여줍니다. 반대로 비교군은 수년치 평균이라 애초에 같은 성격의 수치가 아닙니다. '누적 평균으로 환산해도 11배'라는 하한선으로만 읽으십시오. 출처: GitHub REST API 실측(2026-10-18).

흔히 쓰는 판별법은 ‘스타에 비해 포크(남의 코드를 통째로 복사해 자기 공간으로 가져가는 것)가 너무 적지 않은가’를 보는 것입니다. 스타만 샀다면 실제로 코드를 가져가는 사람은 안 늘 테니까요. 그런데 REA는 그 비율이 다른 인기 프로그램들과 크게 다르지 않았습니다(포크 비율 25.4%로 Next.js 24.6%·VS Code 23.6%와 비슷). 다만 솔직히 말하면 이 비율만으로는 판별이 안 됩니다. 나이도 성격도 다른 저장소를 나란히 놓은 것이니까요.

더 단단한 증거는 다른 데 있었습니다. 실제로 설치한 횟수가 스타와 함께 움직였습니다. npm이라는 프로그램 배포 창고에서 REA 설치 건수를 뽑아 보면, 9월 말 하루 14건이던 것이 10월 9일 약 2만 건, 10월 12일 10만 3천 건이 됩니다.

출처: npm registry API api.npmjs.org/downloads/range/.../rea-agents (2026-10-18 조회)

스타는 돈으로 살 수 있어도, 설치는 그렇지 않습니다. 그래서 제 판단은 이렇습니다 — 속도는 전례 없이 이상하지만 조작의 증거는 아직 없고, 실제로 쓰는 사람이 함께 늘었습니다. ‘스타가 폭증했다’와 ‘스타를 샀다’를 섞어 쓰는 기사는 걸러 읽는 편이 좋습니다.

/use — 사람들은 이렇게 쓴다

답부터: **“남의 앱 구조를 3분 만에 그려내는 용도”**로 쓰입니다.

가장 구체적인 실측 기록은 개발자 shanhan_dev가 DEV Community에 남긴 글입니다. 자기가 만든 맥용 마크다운 앱(FluxMark v1.3.5)의 DMG 설치파일만 REA에 던졌습니다. 소스코드는 한 줄도 주지 않았습니다. 결과는 이랬습니다.

단계	REA가 복원한 것
1. 번들 분석	파일명만으로 지원 플랫폼 식별 — 위챗 공식계정·Medium·Dev.to·Hashnode·Ghost
2. 심볼 추출	클래스명 20여 개 복원 (`FluxMarkAssetSchemeHandler`, `CopyRenderSession`, `PreviewPDFRenderSession`, `PenOverlayNSView` 등)
3. 동작 재구성	에러 문자열(`copy.process.crashed`)에서 프로세스 격리 설계를 추론, 전체 아키텍처 다이어그램 생성

출처: shanhan_dev, “REA Claims It Can ‘Reverse-Engineer Anything’ — and Pulled 120K Stars in a Week. So I Handed It My Own App”, DEV Community

작성자가 기록한 소요 시간은 “설치파일에서 아키텍처 다이어그램까지 3분”, 추가 비용은 **“0달러(로컬 실행)“**입니다. REA는 그 앱이 “Swift 네이티브 셸 ⇅ 양방향 스크립트 브리지 ⇅ WKWebView 렌더링 계층”의 하이브리드 구조라는 것과 번들된 CSS 테마 33개까지 짚어냈습니다.

그런데 같은 글의 결론이 더 중요합니다. 작성자는 REA가 **“왜(why)를 복원하지 못한다”**고 적었습니다. 무엇을 하는지는 복원해도, 왜 그렇게 설계했는지는 못 가져간다는 것입니다. 그의 표현을 그대로 옮기면 — “코드를 갖는 것과 좋은 제품을 만드는 것 사이에는 겪은 모든 함정의 역사가 놓여 있다.”

공식 쇼케이스는 다섯 건입니다. 그런데 이 목록 자체가 REA의 애매한 위치를 그대로 보여줍니다.

쇼케이스	분석 대상	성격
DX-Ball	1996년 윈도우 게임의 사운드 패닝 계산을 C로 복원. 원본 x86 동작 케이스 3,205건 통과, 컴파일된 함수 바이트 63개 전부 재현	소프트웨어 보존
TH04	PC-98 게임의 16비트 명령어에서 탄막 각도 계산을 복원해 당시 컴파일러 출력과 대조	소프트웨어 보존
노션(Notion)	글을 복사할 때 프로그램 안에서 어떤 경로로 처리돼 시스템 클립보드까지 가는지 추적	기능 분석
DownUnderCTF	해킹 경진대회(CTF) 문제의 정답 검사 로직을 분석해 답을 역산	보안 교육
Aegis	인증 앱을 분석해 6자리 일회용 비밀번호(OTP)를 만들어내는 방식을 복원	← 여기가 애매합니다

출처: REA 공식 쇼케이스 (2026-10-18 확인)

앞의 둘은 소프트웨어 보존(software preservation) 영역으로 역사적 가치가 분명하고 법적으로도 가장 안전합니다. 그런데 마지막 Aegis 사례는 배포된 인증 앱의 APK를 뜯어 일회용 비밀번호 생성 규칙을 복원한 것입니다. Aegis가 오픈소스 인증 앱이라는 점에서 악의적 사례로 보긴 어렵지만, “공식 예제는 전부 학술적”이라고 말할 수 있는 구성도 아닙니다.

소셜미디어로 넘어가면 결이 더 분명해집니다. X에서 확산된 게시물 중에는 *“제대로 쓰면 돈 내고 쓰는 기능을 공짜로 다시 만들 수 있다”*고 직접 홍보하는 것이 있습니다(해당 게시물). 이것이 뒤에서 다룰 법적 문제의 핵심입니다.

어두운 화면에 표시된 프로그래밍 코드 Photo by Nemuel Sereti on Pexels

/how — 어떻게 작동하나

답부터: 3단계 순환입니다. ①에이전트가 대상에 대해 질문한다 → ②REA가 분석 도구로 검사·추적한다 → ③에이전트가 돌아온 코드와 근거로 설명하거나 구현한다. 그리고 다시 ①로 돌아가 후속 질문을 던집니다.

여기서 REA의 설계 철학이 드러나는 지점이 **“근거(evidence)“**입니다. 공식 문서는 “결과에는 각 결론의 근거와 한계가 포함된다”고 명시합니다. 즉 “이 부분은 소리의 좌우 방향을 계산한다”로 끝내지 않고, 그렇게 판단한 실제 코드 조각을 함께 내놓습니다. AI가 그럴듯하게 지어내는 것을 막기 위한 장치입니다.

분석 대상은 20종이 넘습니다. 개발자가 아니시면 아래 표는 건너뛰셔도 됩니다 — 요점은 “스마트폰 앱부터 가전제품 펌웨어까지 웬만한 건 다 뜯는다”입니다.

대상	REA가 돌려주는 것	별도 요구사항
PC·맥 프로그램 본체 (바이너리)	사람이 읽을 수 있게 복원한 코드, 내부 문자열, 함수 호출 관계	Hopper·Ghidra·IDA 중 하나 필수
자바스크립트 / 일렉트론 앱	구성 모듈, 내부 통신 경로, 외부 부품 연결 관계	Node.js만 있으면 됨
.NET 프로그램	내부 명령어, 외부 의존 목록	없음 (파일만 읽음)
안드로이드 앱(APK)	권한 설정, 클래스 목록, 복원된 함수 코드	JADX + 자바 개발도구
웹사이트	페이지 구조, 내부 스크립트, 주고받는 통신, 화면 캡처	크롬 계열 브라우저
펌웨어(가전·기기 속 프로그램)	내부 영역 구분, 파일 추출	Binwalk / Unblob (리눅스)
데이터베이스 파일	표 구조, 항목, 저장된 내용 일부	최신 Node.js

출처: REA 공식 문서 “분석 가능 대상” (2026-10-18 확인). 이 밖에 Go·Rust 프로그램, 웹어셈블리, 통신 기록, 안드로이드 실기기 등 24종이 올라 있습니다.

여기서 꼭 알아둬야 할 구분이 하나 있습니다. 파일만 들여다보는 것과, 프로그램을 실제로 실행시켜 보는 것은 위험도가 전혀 다릅니다. 공식 문서도 선을 긋습니다 — 앞의 것은 “프로그램을 실행하지 않고 파일을 읽는” 작업이지만, 뒤의 것은 **“사용자 권한으로 대상을 실행하거나 조작”**합니다. 출처가 의심스러운 프로그램을 실행까지 시키면 내 파일·계정·기기 상태가 바뀔 수 있습니다. 격리된 환경에서 돌리라는 경고가 괜히 붙은 게 아닙니다.

/install — 직접 설치하는 법

답부터: 명령어 한 줄입니다. 터미널(명령어를 직접 입력하는 검은 창. 맥은 ‘터미널’, 윈도우는 ‘PowerShell’)에 npx rea-agents setup을 치고 안내에 따라 승인하면 끝납니다.

여기부터는 실제로 써보려는 분을 위한 대목입니다. 직접 설치할 생각이 없으시면 다음 소제목(‘넘지 말아야 할 선’)으로 건너뛰셔도 됩니다 — 다만 그 소제목은 쓰든 안 쓰든 읽어두실 가치가 있습니다.

사전 요구사항

Node.js — 22.x(>=22.19), 24.x(>=24.11), 또는 26+. npm 포함
지원 에이전트 — 클로드 코드, Codex, Cursor, Gemini CLI, Grok Build 등 로컬 MCP 서버를 지원하는 에이전트면 됩니다
네이티브 분석용 엔진(선택) — Hopper·Ghidra·IDA 중 하나. 자바스크립트·.NET 정적 분석만 할 거면 없어도 됩니다
리눅스 사용자 — Ghidra·JADX·펌웨어 도구 실행과 정적 JS 분석에는 procps 호환 ps가 PATH에 있어야 합니다

설치

npx rea-agents setup

에이전트를 고르고, 제안된 변경사항을 검토한 뒤 승인하면 됩니다. 셋업은 REA의 MCP 서버와 워크플로 지침을 등록하고 기존 설정은 백업합니다. 끝나면 에이전트를 재시작해야 합니다.

CLI만 써보기 — 에이전트 연동 없이 터미널에서 바로 확인할 수도 있습니다.

npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json

상시 사용하려면 전역 설치

npm install --global rea-agents
rea --help

업데이트 — 릴리스가 매우 잦으므로 중요합니다.

rea update

npx로 쓴다면 npx rea-agents@latest setup으로 에이전트 등록을 갱신하고 재시작합니다.

⚠️ 설치 전 반드시 확인. README가 이례적으로 강한 경고를 답니다 — “비슷한 저장소 이름이나 복제된 README는 그 다운로드가 공식이라는 근거가 되지 않는다.” 공식 경로는 morluto/rea, rea.tools, npm의 rea-agents 세 곳뿐입니다. 화제가 된 도구에는 이름을 베낀 악성 패키지가 반드시 따라붙습니다.

넘지 말아야 할 선 — 한국 저작권법

법 이야기를 길게 할 생각은 없습니다. 딱 두 가지만 기억하시면 됩니다.

첫째, 선은 ‘기능’이 아니라 ‘표현’에 있습니다. 저작권법은 겉으로 드러난 표현(실제 코드)을 보호하지, 아이디어나 기능 자체는 보호하지 않습니다. 그래서 남의 앱이 무슨 일을 하는지 알아낸 뒤 내 방식대로 새로 만드는 것은 괜찮고, 뜯어낸 코드를 베껴 넣는 것은 걸립니다. 한국 저작권법 제101조의4가 금지하는 것도 “유사한 프로그램”이 아니라 **“표현이 실질적으로 유사한 프로그램”**을 만드는 경우입니다. 이 한 단어가 합법과 불법을 가릅니다.

둘째, 어떻게 손에 넣었는지가 그만큼 중요합니다. 같은 조문은 역분석을 할 수 있는 사람을 **“정당한 권한에 의하여 프로그램을 이용하는 자”**로 한정합니다. 정식으로 산 앱을 뜯어보는 것과, 유출본이나 크랙본을 뜯어보는 것은 출발점부터 다릅니다. 뒤에서 보겠지만 실제 재판에서도 이것 때문에 승패가 갈렸습니다.

저작권법 제101조의4(프로그램코드역분석) ① 정당한 권한에 의하여 프로그램을 이용하는 자 … 는 호환에 필요한 부분에 한정하여 … 프로그램코드역분석을 할 수 있다. ② … 얻은 정보는 … 표현이 실질적으로 유사한 프로그램을 개발·제작·판매하거나 … 저작권을 침해하는 행위에 이용하는 경우 … 이를 이용할 수 없다.

(발췌. 전문은 국가법령정보센터 참조)

그래서 REA 공식 안내문의 예시 명령이 미묘합니다. **“비슷한 기능을 만들어줘”**까지는 합법인데, 뜯어낸 코드를 눈앞에 띄워 놓고 작업하는 AI에게 ‘비슷한 기능’과 ‘비슷한 표현’ 사이의 거리는 매우 얇습니다. 정작 같은 프로젝트의 면책 문서는 “독점 소프트웨어를 복제하거나 보호되는 코드를 재현하는 것”을 지원하지 않는다고 못 박아 뒀습니다. 공식 문서 안에서 예시와 경고가 서로 다른 방향을 가리키는 셈이라, 선은 쓰는 사람이 그어야 합니다.

참고로 프로젝트가 대놓고 거부하는 용도도 있습니다 — 복제방지 장치나 라이선스 검증 우회, 게임 치트 제작, 로그인·보안 장치 우회, 독점 소프트웨어 복제 등입니다. 이런 요청은 답변 없이 닫히고 커뮤니티에서 제명될 수 있다고 적혀 있습니다.

/next — 앞으로 바뀔 것

답부터: 기술이 아니라 ‘클린룸’이라는 40여 년 된 입증 장치가 무너집니다.

이 대목은 역사를 알면 훨씬 또렷해집니다. 역분석이 합법의 영역으로 들어온 것은 판결과 관행이 함께 만든 결과였습니다.

시점	사건	남긴 것
1982~83	컴팩, IBM PC를 따라잡다	IBM은 컴퓨터를 켜는 핵심 프로그램(바이오스)의 설계도를 매뉴얼 부록에 인쇄해 공개해 둔 상태였습니다. 그래서 숙제는 ‘해독’이 아니라 ‘보지 않고 같은 기능을 다시 쓰기’였고, 컴팩은 약 100만 달러를 들여 처음부터 새로 썼습니다
1984	피닉스, ‘클린룸’을 만들다	오늘날 말하는 클린룸(두 팀 격리) 방식의 원형입니다. 1팀이 IBM 설계도를 읽고 ‘무슨 기능인지’만 적은 문서를 만들고, 그 설계도를 본 적 없는 2팀이 그 문서만 보고 새로 구현했습니다. 두 팀이 주고받은 것도 전부 기록에 남겼습니다. 이 바이오스를 다른 제조사들에 팔면서 PC 호환기종 산업이 규모를 얻었습니다
1992	세가 대 어콜레이드 (미국)	호환을 위해 다른 방법이 없을 때 남의 프로그램을 뜯어보는 것은 정당한 이용으로 인정
1992	아타리 대 닌텐도 (미국)	같은 해, 뜯어본 쪽이 졌습니다. 미국 저작권청에 “소송에 필요하다”고 거짓말을 해서 원본을 받아냈기 때문입니다
2000	소니 대 커넥틱스 (미국)	플레이스테이션 게임을 PC에서 돌리는 프로그램을 만들며 소니 내부 코드를 복제한 것을 정당한 이용으로 인정
2021	구글 대 오라클 (미 연방대법원)	안드로이드가 자바의 코드 약 1만 1,500줄을 그대로 베낀 것을 정당한 이용으로 인정

이 중 1992년 두 사건을 나란히 보는 게 가장 유익합니다. 어콜레이드는 이기고 아타리는 졌는데, 갈린 것은 분석 실력이 아니라 원본을 어떻게 손에 넣었는가였습니다. 법원은 아타리에게도 “뜯어보는 행위 자체는 정당한 이용”이라고 분명히 말했습니다. 다만 그 원본을 거짓말로 받아냈다는 사실이 전부를 뒤집었습니다.

REA를 쓰는 사람에게 가장 직접적인 교훈이 여기 있습니다. 정식으로 산 앱을 뜯어보는 사람은 어콜레이드의 자리에 있고, 유출본·크랙본을 던지는 사람은 분석 방법이 아무리 깨끗해도 아타리의 자리에 있습니다. 앞서 본 한국 조문이 주체를 “정당한 권한에 의하여 프로그램을 이용하는 자”로 못 박아 둔 것도 같은 이야기입니다.

REA의 진짜 변화는 성능이 아니라 구조입니다. 한 에이전트가 '본 것'과 '쓴 것'을 모두 담당하는 순간, 40여 년간 침해 주장을 방어해 온 입증 장치가 사라집니다. 불법이 된다는 뜻은 아닙니다 — 분쟁이 생겼을 때 내밀 카드가 없어진다는 뜻입니다.

REA는 이 분리를 구조적으로 없앱니다. 같은 에이전트가 원본의 표현을 읽고, 그 맥락이 남아 있는 상태에서 곧바로 구현 코드를 씁니다. 격리벽을 세울 자리가 없습니다.

다만 한 가지는 정확히 짚고 가야 합니다. 클린룸은 법이 요구하는 절차가 아닙니다. 앞의 표에 나온 커넥틱스는 클린룸을 쓰지 않았습니다. 기술자들이 소니 내부 코드를 자기 컴퓨터에 띄워 들여다보고, 작업하면서 그 코드를 반복해서 뜯어본 다음, 같은 사람들이 자기네 코드를 썼습니다. 그런데도 이겼습니다. 법원은 “복제를 덜 하는 방식을 택했어야 한다”는 소니의 주장을 **“아이디어에 대한 사회의 접근을 가로막는 인위적 장벽”**이라며 물리쳤습니다. 판단의 기준은 과정을 어떻게 나눴는지가 아니라 최종 결과물에 남의 코드가 남아 있는지였습니다. 21년 뒤 구글이 자바 코드를 그대로 베끼고도 이긴 것도 같은 기준입니다.

그러니 REA가 무너뜨리는 것은 ‘합법성의 요건’이 아니라 **‘합법성을 입증하는 비용 구조’**입니다. 클린룸은 분쟁이 터졌을 때 “우리 구현팀은 원본을 본 적이 없다”를 감사 기록으로 증명하는 보험이었습니다. 한 에이전트가 보는 쪽과 쓰는 쪽을 겸하면 그 보험을 들 방법이 없습니다. 법이 금지해서가 아니라, 분쟁에서 내밀 카드가 없는 상태가 되는 것 — 실무적으로는 이쪽이 더 무섭습니다.

그래서 앞으로 바뀔 것을 셋으로 정리하면 이렇습니다.

방어의 무게중심이 ‘코드 은닉’에서 ‘속도와 신뢰’로 옮겨갑니다. 앞서 자기 앱을 던져본 개발자의 결론이 이것이었습니다. 심볼 난독화·문자열 암호화는 여전히 유효한 실무 대책이지만, 3분이 30분이 될 뿐 막지는 못합니다. 남는 해자는 반복 속도, 도메인 이해, 사용자 신뢰입니다
도구가 아니라 로그가 중요해집니다. REA가 ‘근거’를 함께 내놓는 설계는 역설적으로 무엇을 어디까지 봤는지가 기록으로 남는다는 뜻입니다. 분쟁이 생기면 그 기록이 양날의 검이 됩니다

세 번째는 추측이 아니라 반복된 패턴입니다. 기술이 전문가의 희소성을 없앴을 때 사회는 두 번 다 같은 방식으로 반응했습니다. 복사기가 기관 복사를 폭발시키자 1976년 저작권법은 대량 복사를 감당하지 못했고, 의회의 요청으로 **1978년 저작권정산센터(CCC)**가 생겨 포괄 라이선스를 팔기 시작했습니다. 샘플러가 등장했을 때도 “Thou shalt not steal”(1991년 Grand Upright 판결)과 “Get a license or do not sample”(2005년 Bridgeport 판결)을 거쳐 남은 것은 샘플링의 소멸이 아니라 샘플 클리어런스 산업이었습니다. 두 번 다 기술은 남고, 그 위에 정산과 증명의 계층이 얹혔습니다. REA가 모든 결론에 근거를 붙이는 설계는 그래서 우연이 아니라 그 계층의 1세대로 보입니다.

So What — 장벽이 사라진 자리에 남는 것

REA가 증명한 것은 **“닫힌 소스는 생각보다 훨씬 얕은 보호였다”**는 사실입니다. 디스어셈블러는 30년 전에도 있었습니다. 없던 것은 그것을 능숙하게 다룰 사람이었고, 그 희소성이 사실상의 보호막이었습니다. AI 에이전트가 그 희소성을 없앴습니다.

역사는 더 날카로운 말을 허락합니다. IBM은 1981년에 BIOS 소스를 아예 공개했습니다. 난독화도 암호화도 비밀주의도 없이, 어셈블리 전문을 기술 참조 매뉴얼 부록에 인쇄해 팔았습니다. 그런데도 10년 가까이 시장을 지켰습니다. **희소했던 것은 코드가 아니라 “그 코드를 보지 않고 같은 기능을 다시 쓸 수 있는 조직적 규율”**이었습니다. 컴팩에게는 100만 달러였고, 피닉스에게는 8088을 만져 본 적 없는 엔지니어를 따로 앉혀 두는 비용이었습니다. 해자는 처음부터 비밀이 아니라 ‘합법적으로 베끼는 데 드는 비용’이었습니다. REA가 무너뜨리는 것도 비밀이 아니라 정확히 그 비용입니다.

그리고 1984년 피닉스가 그 비용을 라이선스 한 건 값으로 떨어뜨렸을 때, IBM의 대응은 소송이 아니라 폐쇄적인 상위 레이어로의 후퇴였습니다 — PS/2와 독자 버스 마이크로 채널(1987). 그 시도는 실패했고 시장은 호환기종 쪽에 남았습니다. “더 닫아서 막겠다”는 대응은 이미 한 번 실패한 적이 있습니다.

그래서 제가 보는 핵심 메시지는 하나입니다. REA는 공격 도구이기 전에 진단 도구입니다. 내 제품을 남이 3분 만에 해부할 수 있다면, 그 3분 뒤에도 내게 남아 있는 것이 무엇인지가 사업의 실체입니다. 코드가 전부였던 제품이라면 원래부터 위태로웠던 것이고, 축적된 판단·데이터·사용자 관계가 있는 제품이라면 해부당해도 복제되지 않습니다.

실무적으로 권하는 순서는 이렇습니다.

내 것부터 돌려보십시오. 자기 앱을 분석해 무엇이 그대로 드러나는지 확인하는 것은 법적으로 완전히 안전하면서 가장 많은 것을 알려줍니다
남의 것을 분석할 때는 두 가지를 먼저 확인하십시오. 첫째는 입수 경로 — 정당하게 구매·라이선스한 빌드여야 합니다(Atari가 진 이유가 이것입니다). 둘째는 산출물 — 기능을 보고 내 코드로 새로 쓰는 것은 괜찮지만, 디컴파일된 표현을 가져다 쓰면 제101조의4 ②항 2호에 걸립니다. 선은 ‘기능’이 아니라 **‘표현’**에 있습니다
런타임 분석은 격리 환경에서. 정적 분석과 달리 실제로 프로그램을 실행하고 기기 상태를 바꿉니다

기술은 중립이지만 사용은 그렇지 않습니다. REA 문서가 “공개돼 있다는 사실, 파일을 갖고 있다는 사실만으로 모든 작업에 대한 권한이 생기지는 않는다”고 적은 문장이, 이 도구를 쓰는 사람이 가장 오래 기억해야 할 한 줄이라고 생각합니다.

함께 보면 좋은 글

출처

morluto/rea GitHub 저장소 — README, 설치 명령, 분석 대상 표, 공식 배포 경로 경고
REA DISCLAIMER.md — 허용·거부 용도, 사용자 책임, 런타임 작업 경고
GitHub REST API /repos/morluto/rea, /releases — 스타·포크·watchers·생성일·릴리스 이력 (2026-10-18 실측)
npm registry API api.npmjs.org/downloads/range/.../rea-agents — 일간 다운로드 추이 (2026-10-18 실측)
REA 공식 쇼케이스 — DX-Ball·TH04·Notion·DownUnderCTF·Aegis 5개 사례
shanhan_dev, “REA Claims It Can ‘Reverse-Engineer Anything’… So I Handed It My Own App”, DEV Community — FluxMark 실측 기록
Sega v. Accolade (1992) · Atari Games v. Nintendo (1992) · Sony v. Connectix (2000) · Google v. Oracle (2021) — 역분석·공정이용 법리의 전개
Phoenix Technologies · Clean-room design · IBM PC 5150 BIOS 소스 공개본 — 클린룸의 기원과 IBM의 BIOS 공개
Copyright Clearance Center · Bridgeport v. Dimension Films — 복사기·샘플러 이후 정산 계층의 형성

※ 이 글은 특정 소프트웨어의 역분석을 권유하지 않습니다. 법적 판단이 필요한 사안은 변호사와 상담하십시오. 수치는 2026년 10월 18일 기준이며 저장소 지표는 빠르게 변합니다.