REA 클린룸 실험 — 지시문, 규칙, 채점 기준과 결과
유튜브 영상 「리버스 엔지니어링 도구, REA! 20분 만에 앱 복사 완료」에서 쓴 실험 자료를 모았습니다. 에이전트에게 보낸 과제 원문, 지켜야 했던 규칙, 평가 기준, 그리고 채점 결과와 체크리스트입니다. 같은 실험을 직접 해보실 때 그대로 가져다 쓰셔도 됩니다.
실험은 이렇습니다. 제가 소스를 가진 자료 관리 앱을 패키징해서, 원본 소스와 웹 검색, GitHub 조회를 모두 막은 에이전트에게 주고, REA만으로 분석해서 같은 기능을 하는 앱을 다시 만들게 했습니다. 그다음 다른 에이전트가 원본 소스와 클론을 둘 다 열어 채점했습니다.
모든 수치는 2026년 10월 12일에 한 번 실행한 결과입니다. 같은 도구와 같은 앱이어도 다시 돌리면 결과가 달라질 수 있습니다.
관련 링크
- REA(Reverse Engineer Anything) 저장소: https://github.com/morluto/rea
- REA 공식 사이트: https://rea.tools
- 실험 대상 앱의 바탕이 된 오픈소스 Serpent(MIT 라이선스): https://github.com/dolag233/Serpent
- 실험에 쓴 Serpent 포크: https://github.com/dandacompany/Serpent
REA는 코딩 에이전트가 역공학 도구를 쓸 수 있게 연결해 주는 오픈소스입니다. 이번 실험에서는 npm 패키지 rea-agents 6.4.0 버전을 썼습니다.
실험 설계 — 에이전트 세 명
| 역할 | 하는 일 | 볼 수 있는 것 |
|---|---|---|
| 준비 에이전트 | 대상 앱을 패키징해 설치하고, 샘플 자료 폴더와 안내 문서(handoff)를 만든다 | 원본 소스. 단, 안내 문서에는 앱 이름·저장소 주소·라이선스·빌드 방법을 적지 않는다 |
| 분석 에이전트 | REA만으로 앱을 분석하고 클론을 만든다 | 설치된 앱과 안내 문서, 자기 작업 폴더뿐 |
| 평가 에이전트 | 원본 소스와 클론을 둘 다 열어 루브릭대로 채점하고 규칙 위반을 감사한다 | 원본 소스, 클론 스냅샷 |
세 에이전트는 서로 소통하지 않았습니다. 분석 에이전트는 REA를 MCP 서버로 연결한 Claude Code 세션이었습니다.
분석 에이전트에게 보낸 과제 (원문)
로컬 경로만 일반 이름으로 바꿨습니다.
클린룸 역공학 실험의 분석 에이전트(rea-dev) 과제입니다. 시간 상한 75분.
## 과제
target/handoff.md 가 안내하는 데스크톱 앱을 REA(Reverse Engineer Anything) 방법론만으로 분석해, 같은 사용자 기능을 하는 앱을 당신의 방식대로 다시 설계·구현하세요. 알아낸 사실마다 근거(Evidence)를 남깁니다.
## 절대 금지 (어기면 실험 무효)
- clone/ 과 target/ 밖의 어떤 프로젝트·소스 디렉터리도 열지 않습니다.
- 웹 검색·WebFetch·curl/wget 외부 조회·gh·npm 레지스트리 검색으로 앱의 정체를 추적하지 않습니다. 번들 안에서 이름 문자열을 보더라도 그 이름을 검색하지 않습니다.
- 번들 안의 코드를 그대로 복사해 클론에 붙이지 않습니다. REA 가 돌려준 출력과 실행 관찰로 알아낸 사실을 적고, 그것으로 새 코드를 씁니다.
- target/ 안의 파일을 수정·삭제하지 않습니다. 다른 에이전트·사람과 소통하지 않습니다.
## 남길 것
TIMELINE.md(시각·명령·소요·결과), EVIDENCE.md(출처·확신도 확인됨/추정·반영), DESIGN.md, RUN.md, screens/, STATS.md
클린룸 규칙 (RULES.md 전문)
분석 에이전트의 작업 폴더에 같이 넣어 둔 규칙 문서입니다. 로컬 경로만 일반 이름으로 바꿨습니다.
# 클린룸 규칙 — 분석 에이전트(rea-dev)
## 과제
target/handoff.md 가 가리키는 데스크톱 앱을 REA(Reverse Engineer Anything) 방법론만으로 분석해, 같은 사용자 기능을 하는 앱을 당신의 방식대로 다시 설계·구현한다. 알아낸 사실마다 근거(Evidence)를 남긴다.
## 금지 (하나라도 어기면 실험이 무효가 된다)
1. 이 작업 폴더(clone/)와 대상 폴더(target/) 밖의 어떤 프로젝트·소스 디렉터리도 열지 않는다. 특히 소스 코드 폴더와 평가용 폴더(judge/)는 금지.
2. 외부 조회 금지: WebSearch, WebFetch, curl/wget 으로 외부 사이트 조회, gh 명령, npm 레지스트리 검색(npm search / npm view)으로 앱 정체 추적. 패키지 설치(npm install)는 클론 구현에 필요한 일반 라이브러리에 한해 허용.
3. 앱 이름·제작자·출처를 추측해 검색으로 확인하려 하지 않는다. 번들 안에서 이름 문자열을 보더라도 그 이름으로 외부를 찾지 않는다.
4. 다른 에이전트·사람과 소통하지 않는다. target/ 안의 파일을 수정·삭제하지 않는다.
5. 번들 안의 코드를 그대로 복사해 클론에 붙이지 않는다. REA 도구가 돌려준 출력과 실행 관찰로 알아낸 사실을 Evidence 로 적고, 그 사실로부터 당신의 코드를 새로 쓴다.
## 허용
- REA CLI 전부: npx -y [email protected] <command> (--help, doctor --target, analyze, analyze-javascript-application, capture-process, capture-electron-scenario, decompile, evidence-export 등). REA 스킬 문서와 그 references 읽기.
- 앱 실행·조작(open, osascript, 키보드·마우스 자동화), 창 스크린샷(screencapture -x), 앱이 디스크에 남기는 라이브러리 폴더·설정 파일 관찰, 프로세스·파일·네트워크 관찰.
- REA 가 반환한 Evidence 안의 코드 발췌를 읽고 해석하기.
- 로컬 도구 도움말, Node/npm/Python 표준 문서.
## 기록 (모두 clone/ 안)
- TIMELINE.md: 단계마다 HH:MM:SS 시각, 실행한 명령, 걸린 시간, 한 줄 결과. 막힌 곳·되돌아간 곳도 적는다.
- EVIDENCE.md: 알아낸 사실 목록. 각 항목에 (a) 어떤 REA 명령/관찰에서 나왔는지 (b) 확신도(확인됨/추정) (c) 클론 설계에 어떻게 반영했는지. 추정은 추정이라고 쓴다.
- DESIGN.md: 화면 구조, 데이터 모델, 주요 동작, 예외 처리 — 당신이 이해한 원본의 설계와 클론의 설계.
- RUN.md: 클론 실행 방법 한 줄 명령, 스택, 포트.
- screens/: 원본 관찰 스크린샷과 클론 스크린샷(파일명에 시각).
- STATS.md: 총 소요 시간, REA 명령 호출 수(명령별), Evidence 항목 수, 생성한 파일 수·코드 줄 수.
## 범위와 시간
- 시간 상한 75분. 상한에 닿으면 멈추고 현재 상태를 STATS.md 에 적는다. 완벽한 복제보다 핵심 사용자 흐름이 실제로 돌아가는 클론이 우선이다: 라이브러리 열기/가져오기 → 격자 보기 → 태그 → 검색·필터 → 상세 보기 → 저장/재시작 후 유지.
- 클론 스택은 당신이 고른다. 조건은 RUN.md 의 한 줄 명령으로 이 맥에서 바로 실행되고 브라우저나 창으로 보일 것(예: Vite + React 웹앱, 또는 Electron). 외부 유료 API 금지.
- 샘플 자료는 target/sample-library/ 를 그대로 써도 된다(복사해서 사용).
기능 추가 요청 (원문)
클론이 나온 뒤, 같은 규칙 아래에서 기능 하나를 더 요청했습니다.
같은 규칙(RULES.md) 아래에서 기능 하나를 더해 주세요. 시간 상한 30분.
요청: "대본 문단을 붙여 넣으면, 태그와 파일명, 메모(Description)를 대조해서 관련 자료를 순위로 보여주는 패널"
외부 API 없이 로컬에서. FEATURE.md 에 설계·재사용한 모듈·걸린 시간·테스트한 문단과 결과(1~3순위·점수)를 남겨 주세요.
평가 루브릭 (RUBRIC.md)
평가 에이전트가 쓴 채점 기준입니다.
| 항목 | 배점 | 보는 것 |
|---|---|---|
| 화면 구조 | 20 | 주요 화면·패널·탐색 구조가 원본과 대응하는가(격자, 사이드바, 상세, 태그 UI, 검색) |
| 데이터 모델 | 20 | 자료·태그·컬렉션·메타데이터·저장 방식을 어떻게 이해했고 클론이 그 구조를 재현하는가 |
| 주요 동작 | 30 | 가져오기, 격자 표시, 태그 부여·필터, 검색, 상세 보기, 재시작 후 유지 — 각 동작을 직접 실행해 확인 |
| 예외 상황 | 15 | 빈 라이브러리, 지원하지 않는 파일, 중복 가져오기, 긴 파일명, 삭제 복원 등 |
| 코드 구조 유사도 | 15 | 원본의 설계 결정을 알아내고 같은 선택을 했는지. 코드 베낌이 아니라 이해의 깊이를 본다 |
추가로 세 가지를 쟀습니다.
- Evidence 정확도: 분석 에이전트가 “확인됨”으로 적은 근거를 하나씩 원본 소스와 대조해 맞음·틀림·확인 불가로 나눈다.
- 규칙 감사: 소스 폴더 접근, 웹 검색, gh, 이름 검색, 번들 코드 복사 흔적이 있는지 본다.
- 시간·호출 수: 분석 에이전트가 적은 값과 평가 에이전트가 확인한 값을 함께 적는다.
결과
걸린 시간과 규모
- 클론 완성까지 약 23분입니다(01:21:09 → 01:44:30, 시간 상한 75분).
- REA 호출은 9회였습니다(MCP 7회, CLI 2회).
- 클론은 코드 949줄, 외부 패키지 0개로 만들어졌습니다.
- 기능 추가는 약 5분 걸렸습니다(요청 01:45:40 → 완료 01:50:48). 새로 쓴 코드는 73줄짜리 모듈 하나였고, 나머지는 1차 때 만든 코드를 다시 썼습니다.
채점표 (100점 만점에 74점)
| 항목 | 점수 | 평가 요지 |
|---|---|---|
| 화면 구조 | 16 / 20 | 사이드바·격자·정보 패널의 3열 화면, 탭, 필터, 뷰어, 태그 관리 창까지 대응했습니다. 일부 필터와 목록 보기, 다중 탭은 없습니다 |
| 데이터 모델 | 16 / 20 | 라이브러리 폴더 구성과 자료·태그·메타데이터를 저장하는 방식을 디스크 관찰만으로 재현했습니다. 폴더·컬렉션·되돌리기 기록은 빠졌습니다 |
| 주요 동작 | 25 / 30 | 가져오기, 격자, 태그, 검색, 상세 보기, 휴지통, 재시작 후 유지를 평가 에이전트가 직접 실행해 확인했습니다. 되돌리기와 다중 탭은 없습니다 |
| 예외 상황 | 8 / 15 | 빈 라이브러리, 긴 파일명, 휴지통 복원은 처리했습니다. 원본이 받지 않는 zip 파일을 자료로 받아들였고, 내용이 같은 파일의 중복도 감지하지 못했습니다 |
| 코드 구조 유사도 | 9 / 15 | 화면에서 저장소를 직접 건드리지 않게 한 큰 구조는 원본과 같았습니다. 코드 안에만 있는 설계 결정은 상당 부분 놓쳤습니다 |
잘된 것
화면과 디스크에서 볼 수 있는 것은 정확도가 높았습니다. 검색 방식, 데이터를 저장하는 뼈대, 정보 패널의 항목 순서와 알림 문구까지 원본과 같았고, 열기부터 재시작 후 유지까지 사용자 흐름 전체가 실제로 돌아갔습니다.
분석 에이전트가 “확인됨”으로 적은 근거 24건 중 22건이 원본 소스와 맞았습니다. 1건은 틀렸고, 1건은 확인할 수 없었습니다.
부족했던 것
코드 안에만 있는 설계 결정과 예외 처리가 약했습니다. 가져오기에서 중복 파일과 이름 충돌, 지원하지 않는 형식을 걸러 내지 못했고, 작업을 뒤에서 처리하는 구조나 되돌리기 기능도 단순하게 줄어들었습니다.
틀린 근거 1건이 클론의 서버 설계 방향을 바꿨습니다. 맞은 근거가 많더라도, 에이전트가 추론한 항목은 따로 검증해야 한다는 뜻입니다.
이 글에는 채점 결과의 요지만 싣고, 에이전트가 복원한 내부 구조의 세부는 싣지 않았습니다.
규칙 감사
평가 에이전트의 감사에서 위반은 나오지 않았습니다. 분석 에이전트의 기록 전체가 허용된 범위 안이었고, 소스 폴더 접근이나 웹 검색, gh 사용 흔적이 없었으며, 원본과 같은 구문을 복사한 곳도 없었습니다.
기능 추가 결과 — 대본 문단으로 자료 찾기
테스트 문단은 “오늘은 인트로 썸네일 후보 세 장을 비교해보고, 도시 야경 B롤 위에 로고를 얹어보겠습니다.”였습니다. 샘플 자료 폴더에서 8건이 걸렸습니다.
| 순위 | 파일 | 점수 | 근거 |
|---|---|---|---|
| 1 | thumb-candidate-01.png | 8 | 인트로·썸네일(태그), 후보(파일명) |
| 2 | broll-city-01.jpg | 7 | 도시·야경(파일명), B롤(태그) |
| 3 | broll-city-02.jpg | 7 | 2위와 같은 근거 |
점수는 정규화하지 않은 값이라 문단이 길어질수록 낱말이 많이 걸리는 자료가 유리해집니다. 결과를 순위대로 격자에 고정해 보여주는 기능도 없었습니다.
체크리스트 — 이런 실험을 해보기 전에
- 분석할 권한이 있는 앱인가요?
- 쓰는 도구의 라이선스는 괜찮은가요?
- 원본의 코드와 디자인 자산을 쓰지 않았나요?
- 분석 로그에 개인정보가 들어가지 않았나요?
- 영상이나 글에 보여주는 화면 자료를 쓸 근거가 있나요?
- 결과물을 공개할 때 라이선스는 어떻게 할 건가요?
- REA가 관찰해서 찾아낸 사실과 에이전트가 추론한 내용을 구분했나요?
저작권법과 약관
저는 변호사가 아닙니다. 아래는 조문과 약관 원문을 읽고 정리한 내용이니, 실제로 상용 앱을 분석할 계획이 있다면 전문가에게 확인하시는 게 좋겠습니다.
우리 저작권법에는 관련 조문이 두 개 있습니다(국가법령정보센터, 2026년 10월 12일 확인).
- 제101조의3 제1항 제6호는 정당한 권한으로 프로그램을 이용하는 사람이, 이용하는 동안 그 프로그램의 기초가 되는 아이디어와 원리를 확인하려고 기능을 조사·연구·시험할 목적으로 복제하는 것을 허용합니다. 저작권자의 이익을 부당하게 해치면 안 된다는 단서가 붙습니다.
- 제101조의4는 프로그램코드역분석을 다룹니다. 다른 프로그램과의 호환에 필요한 정보를 쉽게 얻을 수 없고 역분석이 불가피할 때, 호환에 필요한 부분에 한해 허락 없이 할 수 있습니다. 그렇게 얻은 정보를 호환 외의 목적에 쓰거나, 원본과 실질적으로 비슷한 프로그램을 만드는 데 쓰는 것은 금지됩니다.
기능의 원리를 보여주려는 코드 분석은 호환 목적이 아니라서, 제101조의4가 허용하는 경우로 보기 어렵습니다. 이번 실험을 제가 소스를 가진 앱으로 한 이유입니다.
약관도 봐야 합니다. 2026년 10월 12일에 네 앱의 약관을 읽었는데, 모두 리버스 엔지니어링을 금지하는 조항이 있었습니다.
| 앱 | 약관 | 역분석 관련 문구 |
|---|---|---|
| Eagle | https://en.eagle.cool/eula | “Any copying / plagiarism / disassembling / reverse-engineering of Eagle is prohibited.” |
| Raycast | https://raycast.com/terms-of-service | 서비스의 복제·파생물 제작·역분석 금지 조항(VI장) |
| CleanShot X | https://cleanshot.com/eula | “modify, make derivative works of, disassemble, decrypt, reverse compile or reverse engineer any part of the Application.” |
| Paste | https://pasteapp.io/terms | “disassemble, make alterations, decompile, reverse engineer” 금지 |
REA가 오픈소스라고 해서 분석 대상 앱의 약관이 풀리는 건 아닙니다. 직접 만든 앱이나 분석과 활용이 허용된 오픈소스, 제작사 허락을 받은 앱으로 시작하시는 걸 권합니다. 오픈소스라도 원저작자의 라이선스 조건은 지켜야 합니다.
출처
- REA: https://github.com/morluto/rea · https://rea.tools
- Serpent 원본: https://github.com/dolag233/Serpent (MIT) · 실험용 포크: https://github.com/dandacompany/Serpent
- 저작권법 제101조의3·제101조의4: 국가법령정보센터 https://www.law.go.kr (2026년 10월 12일 확인)
- 약관: 위 표의 각 주소(2026년 10월 12일 확인)