Replica 스킬 직접 돌려본 기록: Claude Code 앱 클론 11단계와 REA와의 차이
Replica 스킬(앱 클론용 Claude Code 스킬 11개)을 설치해 Linktree를 대상으로 recon과 리뷰 분석을 직접 돌렸습니다. 결과물과 시간·비용, 파이썬 도구 실측, REA와의 차이까지 정리했습니다.
요즘 인스타그램 릴스로 Replica라는 깃허브 레포를 소개하는 영상을 만들고 있습니다. 매달 이용료를 내고 쓰던 앱을 내 버전으로 직접 만들 수 있다는 내용입니다. 그런데 1분이 안 되는 영상으로는 "정말 링크만 넘기면 되나?", "흔히 말하는 리버스 엔지니어링이랑 뭐가 다르지?" 같은 질문에 답을 다 할 수가 없습니다.
이번 글에서는 Replica 스킬 11개가 각각 무엇을 하는지 정리하고, 제 PC에 직접 설치해서 Linktree(인스타 프로필에 거는 링크 모음 서비스)를 대상으로 첫 단계인 recon과 리뷰 분석 단계인 entrepreneur를 돌려 본 결과를 보여드리겠습니다. 같이 들어 있는 파이썬 도구 6개도 제가 만든 테스트 페이지로 하나씩 돌려 봤습니다. 마지막으로, 앱을 뜯어본다는 점에서 같이 언급되는 REA(Reverse Engineer Anything)와 무엇이 다른지 비교해 보겠습니다.
(작성일 기준 2026-10-27입니다. Windows 11, Claude Code 2.1.311, Python 3.11, 기본 모델 Opus 5.5에서 확인했습니다. 앱을 실제로 짓고 배포하는 build 이후 단계는 이번에 돌리지 않았고, 이유는 본문에서 설명하겠습니다.)
사용 도구 및 준비물
Replica 구성과 설치
Replica는 Jake Schincariol(opusjake.ai)이 2026년 10월 3일에 공개한 Claude 스킬 묶음입니다. 작성일 기준 깃허브 별 5,869개, 포크 1,032개이고 라이선스는 MIT입니다. 커밋은 공개 당시의 v1.0 하나뿐입니다. README(레포 첫 화면에 나오는 설명서) 첫 줄이 "Eleven Claude skills that clone any app"인데, 말 그대로 앱을 복제하는 스킬 11개입니다.
여기서 스킬(skill)은 Claude Code가 특정 작업을 할 때 꺼내 읽는 작업 설명서입니다. 폴더 하나에 SKILL.md라는 지시서와 보조 스크립트가 들어 있고 /replica-recon처럼 이름으로 부르면 Claude가 그 지시서대로 일합니다. 요리로 치면 레시피 카드 11장을 순서대로 꽂아 둔 셈입니다.
Replica에서 꼭 알아야 할 단어가 하나 더 있습니다. 클린룸(clean-room) 방식입니다. 원본의 소스코드를 보지 않고 겉으로 드러난 기능과 화면 흐름만 보고 처음부터 새로 짓는 방식을 말합니다. 남의 가게 레시피를 훔치는 게 아니라, 메뉴판과 손님 후기를 보고 내 가게 메뉴를 새로 짜는 쪽에 가깝습니다. README도 "앱이 하는 일은 다시 짓지만, 앱이 가진 것은 가져가지 않는다"는 취지로 선을 긋고 코드·로고·문구·콘텐츠는 손대지 않는다고 적어 두었습니다.
11개는 아래 순서로 이어집니다. 각 스킬은 프로젝트 안의 replica/ 폴더에 결과를 남기고 다음 스킬이 그 파일을 읽어서 일을 이어 갑니다.
| 순서 | 명령어 | 하는 일 | 남기는 것 |
|---|---|---|---|
| 1 | /replica-recon | 공개 페이지·스토어 목록·도움말·내 계정으로 화면, 흐름, 데이터 구조 지도를 그림 | recon.md, features.csv |
| 2 | /replica-architect | 기술 스택, DB 스키마, API, 만드는 순서를 정함 (기본값 Next.js·Postgres·Stripe) | architecture.md, schema.sql |
| 3 | /replica-design | 색·글자 크기·간격을 재서 디자인 토큰으로 정리, 아이콘·폰트는 공개 라이선스로 | tokens.json, components.md |
| 4 | /replica-build | recon 지도를 보고 화면을 하나씩 새로 짬 | 화면 코드, 기능표 갱신 |
| 5 | /replica-backend | 로그인, DB, 결제(테스트 모드), 메일, 외부 연동 | backend.md, .env.example |
| 6 | /replica-test | 모든 흐름을 눌러 보며 버그 테스트 (Playwright) | test-plan.md, bugs.md |
| 7 | /replica-diff | 원본 대비 기능 일치 점수와 빠진 목록, 색은 무시하는 레이아웃 비교 | parity.md, 차이 이미지 |
| 8 | /replica-entrepreneur | 원본 사용자들의 공개 리뷰에서 불만 순위를 뽑아 수정 계획과 포지셔닝으로 | feedback.md, fixes.md |
| 9 | /replica-brand | 새 이름 후보와 상표 확인 목록, 새 팔레트, 로고 브리프, 원본 흔적 검사 | brand.md, brand.json |
| 10 | /replica-launch | 랜딩 페이지, 가격, 앱스토어 문구 | replica/launch/ |
| 11 | /replica-deploy | 최종 점검 후 내 도메인에 배포 (흔적 검사가 깨끗해야만) | deploy.md, 라이브 URL |
여기에 표준 라이브러리만 쓰는 파이썬 도구 6개(imgdiff.py, parity.py, reviews.py, contrast.py, sweep.py, listing.py)가 붙어 있습니다. README 설명으로는 6개 모두 인터넷에 접속하지 않습니다. 따로 설치할 패키지도 없고 Python 3.8 이상이면 됩니다.
개인적으로 이 표에서 눈에 띈 건 8번 entrepreneur의 위치입니다. 다 지은 다음에 리뷰를 읽는 순서인데, README는 이 스킬만 따로 떼어 "만들지 말지 정하기 전에 먼저 돌려 보라"고도 권합니다. 저도 이번에 recon 다음으로 이 단계를 바로 돌렸습니다.
설치 방법은 세 가지입니다.
-
Claude에게 붙여 넣기: 레포 주소와 "install skill"을 대화창에 붙여 넣으면 Claude가 알아서 설치합니다.
-
플러그인으로 설치: Claude Code에서 아래 두 줄을 입력합니다. 이 경우 명령어 이름이
/replica-skill:replica-recon처럼 앞에 묶음 이름이 붙습니다.
/plugin marketplace add Jakeschincariol/replica-skill
/plugin install replica-skill@replica-skill
- 폴더 복사: 레포를 받아
replica-*폴더 11개를~/.claude/skills/(모든 프로젝트) 또는 프로젝트의.claude/skills/(그 프로젝트만)에 복사합니다. 명령어가/replica-recon처럼 짧게 유지됩니다.
저는 실험용 빈 프로젝트를 하나 만들고 3번 방식으로 프로젝트 안에만 넣었습니다. 남의 스킬을 전역에 바로 까는 건 아직 조심스러워서입니다. 넣은 뒤 레포에 같이 들어 있는 테스트를 돌려 봤습니다.
테스트 57개가 0.727초 만에 모두 통과했습니다. 이 테스트는 파이썬 도구 6개가 제대로 계산하는지 보는 것이고 스킬 지시서의 품질까지 보장하지는 않습니다. 참고로 SKILL.md 안의 예시 명령은 python3로 적혀 있는데, Windows에서는 보통 python으로 바꿔 쳐야 합니다. Claude Code가 알아서 바꿔 실행하긴 했지만 직접 따라 하실 때는 이 부분만 기억해 두시면 됩니다.
recon: 링크 하나로 받은 지도
첫 단계는 /replica-recon입니다. 릴스 대본에 "앱 주소 링크만 넘기면 돼요"라고 썼는데, 실제로는 스킬이 시작하자마자 세 가지를 묻습니다. 어떤 앱의 어떤 플랫폼인지, 앱 전체 중 어느 부분(slice)을 만들 건지, 누구를 위한 버전인지입니다. "Notion 전체"는 프로젝트가 아니라는 게 스킬의 입장입니다.
저는 질문에 대한 답을 프롬프트에 미리 넣고 claude -p(대화창 없이 한 번 실행하는 모드)로 돌렸습니다. 실제로 넣은 프롬프트는 다음과 같습니다.
/replica-recon https://linktr.ee
범위 질문은 아래 답으로 확정하고 질문 없이 진행해 주세요.
- 앱·플랫폼: Linktree 웹 (링크인바이오 서비스)
- 슬라이스: 핵심 루프: 가입 → 링크 추가 → 페이지 꾸미기 → 공유 → 방문 분석 → 유료 업그레이드
- 대상: 한국 1인 크리에이터용 내 버전 저는 Linktree 계정이 없습니다. 공개 페이지(도움말 센터, 요금 페이지, 앱스토어 목록, 마케팅 사이트)만 쓰고, 스크린샷 저장은 생략해도 됩니다.
(원문 그대로이고, 대시 기호 하나만 콜론으로 바꿔 옮겼습니다.)
Linktree를 고른 이유는 단순합니다. 릴스에서 예시로 쓴 앱이고 제 인스타 프로필에도 링크 모음이 필요해서 평소에 요금표를 들여다본 적이 있습니다. (작성일 기준 미국 요금 페이지에서 Pro 플랜은 월 결제 17달러, 연 결제 시 월 14달러입니다.)
실행 결과는 다음과 같습니다.
| 항목 | 값 |
|---|---|
| 걸린 시간 | 5분 26초 (326초) |
| 대화 턴 수 | 48턴 |
| 비용 | API 정가 환산 약 1.47달러 (Opus 5.5가 대부분, 웹 페이지 요약은 Haiku 5.5) |
recon.md | 27KB, 화면 27개(S01~S27), 흐름 9개(F01~F09), 데이터 엔티티 16개 |
features.csv | 87행: must 38, should 23, could 17, skip(만들 수 없거나 안 만들 것) 9 |
| 크기 판정 | M (혼자 핵심 루프만 만들면 4~6주) |
화면 표를 보면 화면마다 "이 화면이 푸는 문제(purpose)"와 "확인한 상태(states seen)"가 붙어 있습니다. 예를 들어 S09 링크 편집 화면에는 링크가 0개인 빈 상태, 저장 중 상태, 모바일 상태가 적혀 있습니다. 스킬 지시서에 "기록하지 않은 빈 상태는 만들지 않게 된다"는 문장이 있는데, 실제 결과물에도 그게 반영되어 있었습니다.
흐름(flow)마다 "행복한 경로(happy path)"의 클릭 수를 세어 두는 것도 좋았습니다. 가입부터 첫 페이지 게시까지 약 8번입니다. 스킬은 이 숫자를 "내 버전이 이겨야 할 숫자"로 쓰라고 합니다. 어려운 부분으로는 방문·클릭 집계(봇과 카카오톡 미리보기 크롤러 걸러내기), 원화 정기결제와 해지, 테마 편집기와 실시간 미리보기 세 가지를 꼽았습니다. "한국 1인 크리에이터용"이라고 한 줄 넣었을 뿐인데 카카오·네이버 로그인, 카카오톡 공유 미리보기 같은 원본에 없는 기능 6개를 따로 표시해 둔 것도 신기했습니다.
아쉬운 점도 분명히 있었습니다.
- 화면은 전부 추정입니다. 계정도 스크린샷도 없이 도움말 문서의 단계 설명만 읽었기 때문에, 결과물 스스로 "실제 UI와 다를 수 있다"고 적어 두었습니다. 스킬은 내 계정으로 직접 눌러 보며 같이 하는 걸 전제로 만들어져 있습니다.
- 가격을 공식 페이지에서 못 읽었습니다. 요금 페이지가 가격을 늦게 그리는 구조라, 경쟁사 블로그의 숫자를 대신 적고 "가격을 정하기 전에 브라우저로 직접 확인하라"고 남겼습니다. 위 17달러는 릴스 작업 때 브라우저로 요금 페이지를 직접 열어 확인한 값입니다.
- 폴더에 먼저 있던 파일을 읽어 갔습니다. 저는 recon 전에 리뷰 파일을
replica/에 넣어 두었는데, recon이 그 분석 결과를 보고 "갱신 전 알림·쉬운 해지"를 must로 올렸습니다. 스킬끼리 파일을 이어 읽는 설계라 당연한 동작이지만 순서를 지키지 않으면 결과가 섞일 수 있다는 점은 알아 두시면 좋겠습니다.
entrepreneur: Linktree 리뷰 54건
다음은 릴스에서 제일 공들여 설명한 단계입니다. "사람들이 뭘 싫어하는지 알아야 내 버전에서 뭘 고칠지 정해진다"는 부분입니다.
entrepreneur 스킬의 규칙은 꽤 엄격합니다. 리뷰를 지어내지 않고, 모든 인용은 원문 그대로에 링크가 붙어야 하고, 링크 없는 리뷰는 도구가 아예 버립니다. 리뷰가 3건 미만이거나 출처가 한 곳뿐인 주제는 "thin(근거가 얇음)"으로 표시합니다. 원본 리뷰어의 말을 내 랜딩 페이지 후기로 쓰지 말라는 문장도 있습니다.
입력으로는 릴스 작업 중에 모아 둔 리뷰 원장을 그대로 썼습니다. 2026-10-27에 Trustpilot에서 2025년 이후 1~2점 리뷰 51건, App Store 리뷰 페이지에서 3건을 원문 발췌와 링크째 모은 것입니다. 일부러 낮은 별점만 모은 표본이라 Linktree 전체 만족도와는 다릅니다. 레딧(Reddit)은 제 작업 환경에서 접속이 막혀 0건입니다. 이 54건을 Replica 형식의 CSV(source,url,date,rating,text)로 바꿔 reviews.py에 넣었습니다.
1위는 결제·해지·환불(14건, 26%)이었습니다. 해지했는데 계속 청구됐다, 갱신 전에 알림이 없었다는 내용이 대부분입니다. 그다음이 로그인 인증코드 문제와 가격·유료 벽입니다.
여기서 재밌는 게 두 가지 있었습니다.
첫째, 모든 주제에 thin이 붙었습니다. 54건 중 51건이 Trustpilot이라 출처가 사실상 한 곳이기 때문입니다. 숫자가 그럴듯해 보여도 출처가 한 곳이면 경향이라고 부르지 말라는 규칙이 그대로 작동한 것입니다. 저는 이 부분이 Replica에서 제일 마음에 들었습니다.
둘째, 절반 넘게 자동 분류에 안 걸렸습니다. reviews.py는 정해진 단어 패턴(themes.json)으로 리뷰를 주제에 나눕니다. 그런데 54건 중 28건이 어떤 주제에도 걸리지 않고 "Read these by hand(직접 읽어 보라)" 목록으로 넘어갔습니다. (feedback.md 화면에는 그중 15건까지만 나오고, 전체는 --json 옵션으로 봐야 합니다.) 릴스 작업 때 제가 54건을 하나씩 읽고 주제를 붙여 둔 기록이 있어서, 둘을 나란히 놓아 봤습니다.
제가 직접 읽었을 때 결제·해지·갱신 불만은 29건이었는데, 도구는 그중 18건만 어떤 주제로든 잡았고 "결제" 주제로 센 건 14건이었습니다. "제 계좌에서 그만 빼 가라", "연 24파운드가 78파운드가 됐다" 같은 리뷰는 결제 불만이 분명한데도 패턴에 없는 표현이라 빠졌습니다. 계정 정지(4건)와 링크 끊김(3건)은 기본 주제 목록에 아예 없어서 전부 수작업 목록으로 갔습니다.
그렇다고 도구가 틀렸다고 보기는 어려운 것 같습니다. 스킬 지시서가 처음부터 "그 목록은 손으로 읽어라. 거기가 제일 쓸모 있을 때가 많다"고 적어 두었고 themes.json도 앱 분야에 맞게 고쳐 쓰라고 합니다. 자동 분류는 1차 정리이고, 마지막 판단은 사람 몫이라는 걸 도구가 숨기지 않는다는 점이 오히려 믿음이 갔습니다.
이제 스킬 본체를 돌릴 차례입니다. "이 파일만 쓰고 리뷰를 새로 모으지 말라, 일부러 낮은 별점만 모은 표본이다"라고 알려 주고 /replica-entrepreneur를 claude -p로 실행했습니다. 5분 24초, 18턴, API 정가 환산 약 1.41달러가 들었습니다.
결과에서 가장 인상적이었던 건 스킬이 도구의 한계를 스스로 잡아냈다는 점입니다. feedback.md의 직접 읽기 목록은 화면에 15건까지만 나오는데, 스킬이 이걸 알아채고 --json 옵션으로 나머지 13건까지 꺼내서 54건 전부를 다시 분류했습니다. 자동 분류의 "가격·유료 벽" 5건이 실제로는 대부분 해지 불만이었다는 것(subscription이라는 단어에 걸린 것)도 짚었습니다. 또 "HEX 색상 입력이 없다"는 불만은 recon 결과를 보니 원본에 이미 있는 기능이라 수정 계획에서 뺐습니다. 스킬끼리 파일을 이어 읽는 구조가 여기서는 제대로 쓰였습니다.
fixes.md에는 세 목록(싫어하는 것, 없는 것, 아무도 해결하지 않은 것), 수정 계획 F1~F8, 포지셔닝 3안이 들어 있습니다. 인용 57개를 reviews.csv 원문·링크와 다시 대조해 불일치가 0건이라는 보고도 붙어 있었습니다. "아무도 해결하지 않은 것" 목록에 스크린리더 사용자가 앱을 아예 쓸 수 없다는 리뷰 1건을 thin으로 올려 둔 것도 기억에 남습니다. features.csv에는 원본에 없는 기능 9행이 추가되어 87행이 96행이 됐습니다.
추천안은 A안 "정직한 결제"였습니다. 갱신 7일 전에 알려 주고, 버튼 하나로 바로 해지되고, 안 쓴 기간은 돌려준다는 방향입니다. 근거가 가장 많고(54건 중 30건), 결제사 연동과 메일만으로 만들 수 있어 가장 싸다는 이유입니다. 릴스에서 "원본 사용자들이 갈아탈 이유"라고 표현한 게 바로 이런 문장입니다.
그런데 저는 스킬이 자기 추천에 단 단서가 더 좋았습니다. 요약하면 이 표본은 "화가 난 사람은 대부분 결제 때문에 화가 났다"는 증거이지 "모든 사용자가 결제에 화가 나 있다"는 증거가 아니고, 결제를 제대로 만드는 건 원래 해야 할 일이라 그것만으로는 갈아탈 이유가 약할 수 있다는 내용입니다. 그래서 히어로 문구로 정하기 전에 App Store·Google Play·Reddit에서도 같은 주제가 나오는지 확인하라고 권합니다. 처음에 알려 준 표본의 성격을 끝까지 기억하고 결론의 강도를 조절한 셈입니다. 한국 출시라면 정기결제 갱신 고지에 법적 의무가 있을 수 있으니 문구는 법률 확인이 필요하다는 메모도 있었습니다.
diff·brand 도구 실측
build 단계를 돌리지 않았기 때문에 Linktree와 제 클론을 비교할 수는 없었습니다. 대신 나머지 도구가 정말 설명대로 동작하는지 보려고, 제 링크 페이지 모양의 테스트 페이지를 HTML 한 장으로 만들어 실험했습니다. (Linktree 코드나 디자인은 쓰지 않았고 버튼 다섯 개짜리 제 프로필 페이지입니다.)
1. imgdiff.py: 색은 무시하고 배치만 비교
릴스에 "마지막엔 새 이름과 디자인을 입혀요"라고 썼는데, 그러면 원본과 비교 점수가 떨어지지 않을까 궁금했습니다. imgdiff.py는 두 스크린샷을 윤곽선 지도로 바꾼 뒤 격자로 잘라 "어디에 무엇이 있는지"만 비교한다고 합니다. 그래서 같은 페이지를 세 가지로 찍었습니다. A는 기준, B는 색만 바꾼 것, C는 색은 그대로 두고 버튼을 2열 타일로 바꾼 것입니다. 모두 390×844(모바일) 크기입니다.
결과는 설명 그대로였습니다.
| 비교 | 모드 | 점수 | 판정 |
|---|---|---|---|
| A ↔ B (색만 바꿈) | layout | 97.1 | MATCHES |
| A ↔ B (색만 바꿈) | pixel | 0.0 | DIFFERENT |
| A ↔ C (배치를 바꿈) | layout | 49.2 | DIFFERENT |
색을 통째로 바꿔도 레이아웃 점수는 97.1이고, 버튼 배치를 바꾸면 49.2로 떨어집니다. 같은 A와 B를 픽셀 모드로 비교하면 0점이 나옵니다. 리브랜딩으로 색이 바뀌는 건 감점하지 않고 사용자가 익숙해할 "정보의 위치"만 본다는 뜻입니다. 차이 이미지의 빨간 칸도 버튼이 움직인 자리와 정확히 겹쳤습니다.
2. sweep.py: 원본 흔적 검사
/replica-deploy는 이 검사가 깨끗하지 않으면 배포를 거부합니다. 일부러 원본 이름이 들어간 컴포넌트 파일 LinktreeButton.tsx와 원본 도메인이 들어간 문구, 원본 색으로 등록한 hex 값을 넣어 두고 돌렸습니다.
4건이 잡혔고 종료 코드는 1(실패)이었습니다. 파일 이름과 LinktreeButton 같은 함수 이름 안에 숨은 원본 이름까지 찾아냈습니다. 이름을 LinkButton으로, 문구와 색을 제 것으로 바꾸고 다시 돌리니 "Clean"과 함께 0(통과)이 나왔습니다. 개발하면서 무심코 붙인 이름이 출시 직전까지 남는 경우가 생각보다 많은데, 이런 검사가 배포 관문에 걸려 있다는 게 실용적이었습니다.
3. contrast.py와 listing.py: 걸린 것 두 개
이 두 도구는 짧게만 적겠습니다. contrast.py는 글자색과 배경색의 명도 대비(WCAG 기준)를 계산합니다. 제 테스트 페이지의 남색 글자는 크림 배경 위에서 12.69:1(AAA)로 넉넉했는데, 포인트로 쓴 주황(#E8762C)은 같은 배경에서 2.64:1로 AA 기준(4.5:1)에 못 미쳤습니다. 주황은 테두리 장식에만 쓰고 글자에는 쓰면 안 된다는 뜻입니다.
listing.py는 앱스토어·구글플레이 문구의 글자 수 제한과 금지 표현을 검사합니다. 레포에 들어 있는 예시 문구를 그대로 돌렸더니 오류 0, 경고 1이 나왔는데, 경고 내용이 재밌었습니다. "a time you are actually free(실제로 시간이 비는 때)"의 free를 "무료"라는 가격 주장으로 보고 경고한 것입니다. 단어만 보고 판단하니 생기는 오탐(잘못 잡음)이라, 경고가 뜨면 맥락은 직접 확인하셔야 합니다.
4. parity.py: 지금 몇 점인가
마지막으로 recon이 만든 features.csv를 그대로 parity.py에 넣어 봤습니다. 아직 아무것도 안 만들었으니 0점이 당연한데, 궁금했던 건 0점일 때 무엇을 보여 주느냐였습니다.
87행 중 skip 9개와 원본에 없는 기능 6개를 빼고 72개를 셌고, must 33개가 남아 있어서 "아직 출시 불가(Not shippable yet)"라고 못 박습니다. 그 아래로 빠진 기능이 만들 순서대로 쭉 나옵니다. 결국 이 점수표가 build 단계의 할 일 목록 역할을 하는 셈입니다. 스킬 설명에 "62%면 62%라고 말하라"는 문장이 있는데, 점수를 후하게 주지 않는 쪽으로 설계된 것 같습니다.
REA와의 차이
Replica를 소개하면 "그거 리버스 엔지니어링 도구 아니냐"는 반응이 꼭 나옵니다. 앱을 뜯어보는 도구로 요즘 가장 많이 언급되는 게 REA(Reverse Engineer Anything, morluto/rea)입니다. 작성일 기준 별 393,542개, 포크 98,645개라 규모부터 다릅니다. 이름만 보면 둘이 같은 일을 하는 것처럼 보이지만 문서를 읽어 보면 보는 방향이 정반대입니다.
REA는 MCP 서버입니다. MCP(Model Context Protocol)는 AI 에이전트가 외부 도구를 불러 쓰게 해 주는 연결 규격인데, REA를 등록하면 Claude Code·Codex·Cursor·Gemini CLI 같은 에이전트가 REA의 분석 도구를 직접 호출합니다. 분석 대상은 README 표 기준으로 30종이 넘습니다. 네이티브 실행 파일(Hopper·Ghidra·IDA 연동), 자바스크립트·Electron 앱, .NET 어셈블리, 안드로이드 APK, 크롬 계열 브라우저에 연결한 웹페이지, 저장해 둔 네트워크 캡처 등이 있습니다. 결과는 의사코드(pseudocode), 모듈과 IPC 관계, 라우트 후보 같은 것들이고 결론마다 근거와 한계를 같이 붙여 준다고 합니다. 분석은 내 컴퓨터에서 돌아갑니다.
대표 사례도 결이 다릅니다. 고전 게임 DX-Ball의 사운드 좌우 배치 계산을 디컴파일해서 C로 다시 짠 사례는 원본 x86 동작과 비교한 3,205개 케이스를 통과했다고 하고, Notion 데스크톱 앱의 클립보드 기능이 Electron 내부에서 어떤 경로로 오가는지 추적한 사례도 있습니다. 둘 다 "이 기능이 안에서 어떻게 돌아가는가"를 묻는 작업입니다.
반대로 Replica의 recon 지시서에는 자바스크립트 번들을 읽거나 저장하지 말 것, 바이너리를 디컴파일하지 말 것, 네트워크 호출을 기록해서 엔드포인트를 베끼지 말 것이 명시되어 있습니다. REA가 잘하는 일이 Replica에서는 하지 말라는 목록에 들어 있는 셈입니다.
| 구분 | Replica | REA |
|---|---|---|
| 묻는 질문 | 이 앱은 무엇을 하고, 사용자는 뭘 싫어하나 | 이 기능은 안에서 어떻게 돌아가나 |
| 형태 | Claude 스킬 11개 (마크다운 지시서 + 파이썬 도구 6개) | MCP 서버 + CLI (npm rea-agents, 작성일 기준 6.8.0) |
| 입력 | 앱 주소, 도움말·요금 페이지, 스토어 목록, 공개 리뷰, 내 계정 | 내가 가졌거나 분석 허락을 받은 실행 파일·앱 묶음·APK·웹페이지 |
| 안 보는 것 / 돕지 않는 것 | 원본 코드, 번들, 디컴파일, 네트워크 호출, 로그인 뒤 스크래핑 | DRM·라이선스 우회, 게임 치트, 독점 소프트웨어 코드·자산 복제 |
| 결과물 | 화면·흐름 지도, 불만 순위, 새로 짠 앱, 새 브랜드, 배포 | 의사코드·어셈블리, 모듈 관계, 라우트 후보와 근거·한계 |
| 설치 | 폴더 복사 또는 플러그인, Python 3.8+ | npx rea-agents setup, Node.js 22.23.4+ / 24.22.1+ / 26.12.1+ |
| 추가 도구 | 없음 | 네이티브 분석은 Hopper·Ghidra·IDA 중 하나 (상용 도구는 본인 라이선스) |
| 어울리는 사람 | 기존 앱의 내 버전을 기획·제작해서 팔고 싶은 1인 창업자 | 보안 연구, 호환성 작업, 내 앱 디버깅, 기능 원리를 깊게 알고 싶은 개발자 |
정리하면 Replica는 "무엇을"을 밖에서 보고, REA는 "어떻게"를 안에서 봅니다. 둘 다 MIT 라이선스지만 쓸 수 있는 대상의 기준도 다릅니다. Replica는 공개된 정보와 내 계정까지만 보고, REA는 DISCLAIMER에서 분석 권한이 있는 대상에만 쓰라고 하면서 공개된 소프트웨어라고 해서 모든 분석이 허락되는 건 아니라고 분명히 적어 둡니다.
이번 글에서는 REA를 직접 돌리지 않았습니다. 실측은 Replica에 집중하기로 했고 제 PC의 Node.js가 22.18.0이라 REA가 요구하는 버전에도 못 미쳤습니다. 그래서 REA 쪽 내용은 공식 README·문서·DISCLAIMER 기준입니다. (한국어 README도 레포 안에 있습니다.)
개인적인 생각
릴스 대본을 쓰면서도, 이번에 직접 돌리면서도 계속 든 생각은 "이용료 내던 앱을 직접 만든다"는 문장이 반은 맞고 반은 과장이라는 점입니다. recon 하나만 봐도 Linktree 핵심 루프를 혼자 만드는 데 4~6주가 걸린다고 나왔고 그건 결제·집계·테마 편집기 같은 어려운 부분을 다 포함한 숫자입니다. 링크 하나로 앱이 뚝딱 나오는 도구가 아니라, 앱 하나를 만드는 순서와 점검표를 꼼꼼하게 짜 둔 도구에 가깝습니다.
그런데도 이 레포가 좋았던 이유는 "베끼지 않는 법"을 도구로 강제한다는 점입니다. 리뷰를 지어내면 안 된다, 링크 없는 인용은 버린다, 출처가 한 곳이면 thin이다, 원본 이름이 코드에 남아 있으면 배포 안 한다. 이런 규칙은 사람이 혼자 일할 때 가장 먼저 무너지는 부분인데, 스킬과 도구에 박혀 있으니 지키기가 훨씬 쉽습니다.
상황별로 나누면 저는 이렇게 쓰실 것을 추천합니다.
1. 앱 아이디어만 있는 경우 - 11개를 다 돌리지 말고 /replica-entrepreneur 하나만 먼저 돌려 보시길 권장합니다. 사람들이 그 앱에서 무엇을 싫어하는지가 근거와 함께 나오고 출처가 얇으면 얇다고 알려 줍니다. 이번처럼 절반 정도는 직접 읽어야 하지만 그 읽는 시간이 사실상 시장 조사입니다.
2. 실제로 만들어서 팔 생각인 경우 - recon은 반드시 내 계정으로 화면을 직접 눌러 보며 같이 하셔야 합니다. 화면 없이 돌린 recon은 추정이 많았습니다. 그리고 brand 단계의 상표 확인과 이용약관 확인은 꼭 사람이 직접 하셔야 합니다. README도 돈이 걸려 있으면 출시 전에 변호사와 상의하라고 적어 두었고, 한국이라면 정기결제 고지 같은 전자상거래 규정도 따로 확인이 필요해 보입니다.
3. 어떤 기능이 안에서 어떻게 돌아가는지 궁금한 경우 - 이건 Replica가 아니라 REA 쪽 질문입니다. 다만 내 앱이거나 분석 허락을 받은 대상에 쓰셔야 하고, 남의 서비스를 뜯어서 내 제품을 만드는 용도로 쓰는 건 두 레포 모두 권하지 않는 방향입니다.
이번에 돌리지 않은 build·backend·test·deploy 단계는 실제 앱 한 개를 몇 주에 걸쳐 만드는 일이라 이 글에 담기에는 판이 너무 컸습니다. 그 단계들의 품질은 아직 직접 확인하지 못했다는 점도 같이 적어 둡니다.
이 글을 마치며 & Reference
다음 글에는 이번에 멈춘 지점부터 이어서 recon과 리뷰 분석 결과를 들고 링크 페이지의 공개 화면 하나를 build·test까지 돌려 보겠습니다. 그때는 parity 점수가 0에서 몇 점까지 올라가는지도 같이 재 보겠습니다.
관련 글
- Claude Code 모드(mods) 직접 만들어 본 기록 : Replica를 만든 OpusJake가 공개한 모드 리소스 팩을 각색해 모드 세 개를 직접 만든 글입니다
- Claude Code 플러그인 5종, 깔기 전에 직접 재본 기록 : 남이 만든 스킬·플러그인을 깔기 전에 무엇을 확인하는지 정리한 글입니다
- Claude Code 프론트엔드 디자인 도구 5종 : Replica의 design·build 단계에서 같이 쓰기 좋은 디자인 스킬과 Playwright CLI 이야기입니다
- 바이브코딩 디자인 레퍼런스 사이트 5곳 : 원본 디자인을 베끼지 않고 내 버전의 디자인 방향을 잡을 때 참고할 사이트들입니다
Reference
- Jakeschincariol/replica-skill, GitHub : 이번 글의 주인공. README의 예시(18화면, 리뷰 140건, 점수 86·91)는 설명용 가상 예시이고 실제 실행 결과는 이 글의 숫자를 참고하시면 됩니다
- morluto/rea, GitHub : REA 본체. 분석 대상 표와 설치 방법, 한국어 README가 있습니다
- REA 공식 사이트 : 사례(DX-Ball, Notion, TH04)와 단계별 가이드가 그림과 함께 정리되어 있습니다
- REA DISCLAIMER : 어떤 용도로 쓰면 안 되는지, 분석 권한은 누구 책임인지 적힌 문서입니다. REA를 쓰기 전에 한 번은 꼭 읽어 보시길 권합니다
- Claude Code 스킬 문서 : 스킬 폴더를 어디에 두면 어디서 쓰이는지, 이름은 어떻게 붙는지 공식 설명입니다
(최대한 작성 시점 기준으로 확인했지만 두 레포 모두 빠르게 바뀌고 있어서 틀린 부분도 있을 수 있습니다.)
긴 글 읽어주셔서 감사합니다 :)
추가 학습 자료 신청
ZEXEA 메인 사이트의 자료 신청 페이지로 이동합니다. 이름·이메일·전화번호 등의 입력이 필요합니다. 블로그 글과 실습 예제는 신청 없이 모두 읽을 수 있습니다.
관련 가이드
Claude Code 모드(mods) 직접 만들어 본 기록: 작업 띠·Haiku 자동 전환·할 일 패널
Claude Code 모드(mods)를 공식 문서대로 직접 세 개 만들어 돌려 봤습니다. 프롬프트 위 작업 띠, 쉬운 요청을 Haiku로 보내는 saver, 할 일 패널의 실제 화면과 비용, 남의 모드 설치 전 검사법까지 정리했습니다.
전체 과정 보기Claude Code 플러그인 5종, 깔기 전에 직접 재본 기록 (Karpathy 스킬·I Have ADHD·Superpowers·Grilling·Claude Octopus)
Claude Code 플러그인 추천으로 자주 보이는 Karpathy 스킬, I Have ADHD, Superpowers, Grilling, Claude Octopus를 직접 설치해 대화 시작 토큰과 같은 지시 A/B 결과를 쟀습니다. 무엇을 남길지 정리했습니다.
전체 과정 보기Claude Code 프론트엔드 디자인 도구 5종, AI 티 나는 웹사이트를 고치는 스킬·CLI 사용법
Claude Code로 만든 웹사이트의 AI 티를 줄이는 디자인 도구 5종. Awesome DESIGN.md, Taste Skill, Image to Code, Playwright CLI, Vercel 규칙 스킬의 정체와 설치법, 쓰는 시점, 직접 돌려본 결과를 정리했습니다.
전체 과정 보기