CUBE.ai

AI 정보

앱을 통째로 복사한다고? REA로 이해하는 AI 리버스 엔지니어링

2026.10.15

들어가며

전체 지도

지난주 개발자 타임라인은 한 문장으로 요약됐습니다. "포토샵이 무료로 풀렸고, 앱을 통째로 복사해 주는 오픈소스가 나왔다, 소프트웨어는 끝났다." 국내에서도 이 소식을 다룬 영상이 50만 회 넘게 재생됐죠. 여러분도 아마 "그럼 이제 어도비 구독 안 해도 되나?", "바이브 코딩으로 남의 앱도 뚝딱 만들 수 있나?" 하는 생각을 한 번쯤 하셨을 겁니다.

그런데 말이죠, 이 문장은 사실 서로 다른 두 개의 뉴스가 한데 붙어서 돌아다니는 중입니다. 오늘 수업은 그 둘을 떼어놓는 것부터 시작하겠습니다.

진행은 세 덩어리로 하겠습니다. 먼저 무슨 일이 있었는지와 리버스 엔지니어링이라는 기본기를 짚습니다. 사건을 정확히 알아야 과장이 보이고, 기본 용어를 알아야 도구가 하는 일이 보이거든요. 다음으로 REA의 구조와 기존 도구와의 차이, 그리고 어도비 클론과의 진짜 관계를 따져봅니다. 마지막으로 바이브 코더에게 무엇이 쉬워졌고, 무엇을 조심해야 하며, 주니어 개발자는 이걸 어떻게 공부 도구로 쓸 수 있는지로 마무리합니다.

결론을 살짝 먼저 말씀드리면, REA는 "앱 복사기"라기보다 "앱 돋보기"에 가깝습니다. 남의 앱을 찍어내는 기계가 아니라, 이미 있는 앱이 어떻게 동작하는지 증거와 함께 보여주는 도구죠. 왜 그렇게 말할 수 있는지는 하나씩 확인해 보겠습니다.

자, 그럼 소동의 현장부터 가볼까요?

1. 어도비 무료 앱 소동, 대체 무슨 일이 있었을까?

지도의 출발점입니다. 도구를 뜯어보기 전에, 이번 주에 정확히 어떤 일이 벌어졌는지부터 정리하겠습니다.

어도비 무료 앱 소동

같은 주에 두 가지 사건이 터졌습니다.

첫 번째는 ArtCraft입니다. 미국 개발자 브랜든 토머스가 Claude와 Rust로 포토샵, 일러스트레이터, 프리미어, 라이트룸 등 어도비 프로그램을 흉내 낸 무료 오픈소스 앱을 연달아 공개했어요. 포토샵 자리를 노리는 앱은 PhotoCraft, 프리미어 자리는 FilmCraft, 이런 식입니다. 어도비의 해지 위약금에 몇 번 데인 게 계기였다고 하죠.

두 번째는 REA(Reverse Engineer Anything)입니다. AI 코딩 에이전트에게 리버스 엔지니어링 도구를 쥐여주는 오픈소스인데, 4월에 만들어진 뒤 조용히 있다가 10월 초에 폭발했습니다. 10월 6일 1만 개도 안 되던 깃허브 스타가 일주일 만에 10만 개를 넘겼고, 이 글을 쓰는 지금은 25만 개를 넘어섰습니다.

여러분이 유튜브에서 많이 REA 관련 영상이 이 흐름을 다룹니다. 유튜브 영상들은 REA의 구조를 개념도로 설명하고, 직접 윈도우 그림판을 리버스 엔지니어링해서 원래 없던 "붙여넣은 그림 목록 패널"까지 붙인 그림판을 약 11분 만에 만들어 보여줍니다. 그러면서도 "소프트웨어가 끝났다고 하기엔 이르다", "상업용 앱을 그대로 베끼는 건 불법"이라고 선을 긋죠. 균형 잡힌 영상입니다.

문제는 SNS에서 이 두 사건이 스테이플러로 한데 찍혀 돌아다녔다는 점입니다. "REA로 어도비를 복사했다"는 식으로요. 이건 사실이 아닙니다. 두 기사를 한 장으로 찍어 붙이면 마치 하나의 이야기처럼 읽히지만, 스테이플러 심을 빼면 각자 다른 이야기라는 게 보입니다. 이 심을 빼는 작업은 5번 섹션에서 제대로 하겠습니다.

참고 자료(4)

2. 리버스 엔지니어링은 무엇일까?

사건을 정리했으니, 이제 지도에서 기본기 구역으로 넘어갑니다. REA를 이해하려면 이 단어 하나는 확실히 잡고 가야 해요.

리버스 엔지니어링이란

리버스 엔지니어링(역공학)은 설계도 없이 완성품만 보고 그것이 어떻게 동작하는지 알아내는 일입니다. 소프트웨어에서는 소스 코드 없이 이미 빌드된 앱만 가지고 내부 동작을 추적하는 걸 말하죠.

비유를 들어볼게요. 맛집에서 케이크를 한 입 먹고, 집에 와서 레시피를 거꾸로 추적한다고 해봅시다. 단맛의 정도로 설탕 양을 짐작하고, 식감으로 굽는 온도를 추측하죠. 그런데 레시피 카드에는 끝까지 물음표로 남는 줄이 생깁니다. 셰프가 왜 그 재료를 넣었는지, 원래 순서가 뭐였는지는 맛만으로는 알 수 없거든요.

소프트웨어도 똑같습니다. 우리가 설치한 앱은 사람이 읽기 어려운 기계어(바이너리) 상태예요. 이걸 거꾸로 푸는 단계는 보통 이렇습니다.

  1. 디스어셈블: 바이너리를 어셈블리(기계 명령을 한 줄씩 적은 것)로 바꿉니다. 거의 기계적인 작업이에요.
  2. 디컴파일: 어셈블리를 C 언어 비슷한 의사 코드(pseudocode) 로 바꿉니다. 영상에서 말한 "Pseudo 코드"가 이겁니다.
  3. 이름과 의도 복원: 컴파일할 때 사라진 변수 이름, 함수 이름, 주석을 사람이 추리해서 채웁니다. 진짜 어려운 일은 여기서 일어납니다.

3번이 바로 케이크 레시피의 물음표 줄입니다. 기계는 "이 값에 100을 곱한다"까지는 보여주지만, "이게 할인율 계산이다"라는 의미는 사람이, 이제는 AI가 추론해야 해요.

한 가지 꼭 기억하실 점은 리버스 엔지니어링이 새로운 기술이 아니라는 겁니다. 에뮬레이터, 보안 분석, 악성코드 분석, 오래된 프로그램 보존이 모두 이 기술 위에 서 있어요. 수십 년 된 분야에 AI가 막 합류한 것이지, AI가 새로 발명한 분야가 아닙니다.

참고 자료(2)

3. REA는 어떤 구조로 움직일까?

기본기를 챙겼으니 이제 지도의 한가운데, REA 본체로 들어갑니다. 영상에서 개념도로 보여준 부분을 조금 더 꼼꼼히 풀어볼게요.

REA의 구조

REA는 스스로 앱을 분석하는 프로그램이 아닙니다. AI 에이전트와 기존 분석 도구 사이를 이어주는 MCP 서버예요. MCP(Model Context Protocol)는 AI가 외부 도구를 꽂아 쓸 수 있게 해주는 표준 규격입니다.

병원으로 비유하면 딱 맞습니다.

  • 환자의 질문: "이 앱의 검색 기능은 어떻게 돌아가?" (여러분이 Claude Code 같은 에이전트에게 던지는 한 줄)
  • 주치의: AI 에이전트. 무엇을 검사할지 판단하고 결과를 해석합니다.
  • 검사 접수창구: REA. 주치의의 요청을 받아 알맞은 검사실로 보냅니다.
  • 검사 장비: Ghidra, Hopper, IDA 같은 디컴파일러, 안드로이드용 JADX, 웹·Electron 앱을 볼 때 쓰는 Chrome 브라우저 등.
  • 검사 결과지: 의사 코드와 어셈블리, 문자열과 함수 호출 관계, 그리고 "이 결론의 근거"와 "아직 모르는 부분".

마지막 줄이 중요합니다. REA는 결과마다 근거(evidence)와 한계(limitations)를 함께 돌려줍니다. 좋은 검사 결과지가 "판독 불가" 항목을 숨기지 않는 것처럼요. 에이전트는 이 결과지를 받아 코드를 짜보고, 테스트하고, 모자라면 다시 검사를 요청합니다. 영상에서 "원하는 기능이 다 만들어질 때까지 반복한다"고 한 그 루프입니다.

분석할 수 있는 대상도 넓습니다. 윈도우·맥 실행 파일, JavaScript와 Electron 앱, .NET 어셈블리, 안드로이드 APK, 웹사이트, 펌웨어, 네트워크 캡처까지 공식 문서에 표로 정리돼 있어요. 단, 깊은 네이티브 분석에는 Ghidra(무료)나 IDA·Hopper(유료) 중 하나가 내 컴퓨터에 설치돼 있어야 합니다. REA가 디컴파일러를 직접 내장하지 않기 때문이죠.

설치는 npx rea-agents setup 한 줄로 시작합니다. 에이전트를 고르면 바꿀 설정을 먼저 보여주고, 승인해야 적용하며, 기존 설정은 백업해 둡니다. 영상처럼 깃허브 링크를 에이전트에게 붙여넣고 "설치해줘"라고 맡겨도 됩니다. Node.js 22.19 이상이 필요해요.

참고 자료(3)

4. REA는 기존 도구와 무엇이 다를까?

구조를 봤으니, 지도에서 비교 구역으로 넘어갑니다. "그래서 뭐가 새롭냐"는 질문에 답할 차례예요.

기존 도구와의 차이

REA 안의 도구들은 하나도 새것이 아닙니다. IDA는 1990년대부터 쓰인 업계 표준이고, Hopper도 10년이 넘었습니다. Ghidra는 출신이 특이한데, 미국 국가안보국(NSA)이 내부에서 쓰던 도구를 2019년에 오픈소스로 공개한 겁니다. Ghidra를 AI에 연결하는 MCP 서버도 이미 여럿 있었어요.

그럼 REA는 뭘 바꿨을까요? 여행용 멀티 어댑터를 떠올려 보세요. 나라마다 콘센트 모양이 달라서 예전엔 어댑터를 종류별로 챙겨야 했죠. 멀티 어댑터는 전기를 새로 만들지 않습니다. 다만 어떤 플러그든 한 구멍에 꽂히게 해줘요. REA도 마찬가지로, 제각각 사용법이 다른 분석 도구들을 에이전트가 한 가지 방식으로 부를 수 있게 묶어줍니다.

여기에 REA만의 장치가 몇 가지 더 붙어 있습니다.

  • 근거 기록: 결과마다 어떤 도구로 무엇을 봤는지, 무엇은 확인하지 못했는지 남깁니다.
  • 로컬 실행: 분석은 내 컴퓨터에서 돌아갑니다. 다만 결과는 에이전트로 넘어가므로, 사용하는 AI 서비스의 데이터 정책은 따로 확인해야 해요.
  • 빠른 개발 속도: 10월 3일부터 11일 사이에만 릴리스가 8번 나왔고, 10월 11일에 6.4 버전이 나왔습니다. 그만큼 깨지는 변경(breaking change)도 잦습니다.

그런데 말이죠, 공짜 점심은 없습니다. 멀티 어댑터를 꽂아도 전기 요금은 나가듯, REA는 토큰을 많이 씁니다. 프로젝트가 직접 공개한 실험에서 WASM으로 컴파일된 SQLite 하나를 분석하는 데 도구 호출 42번, 5분, 입력 토큰 30만 개가 들었어요. 평범한 맥 앱 하나를 살펴보는 데 8만~23만 토큰이 한 번에 쏟아진다는 이슈도 올라와 있습니다.

그리고 흥미로운 비교 실험이 하나 있습니다. 간단한 맥 사진 뷰어를 REA를 쓴 에이전트와 그냥 에이전트로 각각 따라 만들었더니, 둘 다 원본과 거의 비슷한 결과물이 나왔다고 해요. REA 쪽이 조금 더 정교했지만 시간은 훨씬 오래 걸렸고요. 한 번의 소규모 테스트라 단정하긴 어렵지만, 능력의 상당 부분은 REA가 아니라 에이전트 모델 자체에서 나온다는 힌트입니다.

참고 자료(4)

5. 그래서 어도비 클론은 REA로 만든 걸까?

이제 1번 섹션에서 예고한 스테이플러 심을 뺄 차례입니다. 지도에서 비교 구역의 마지막 칸이에요.

어도비 클론과 REA의 관계

결론부터 말씀드리면, ArtCraft는 REA로 만든 것이 아닙니다. 개발자 본인이 이 프로젝트를 "클린룸(clean-room) 재구현"이라고 설명합니다. 클린룸이란 원본 코드를 전혀 보지 않고, 공개 문서와 겉으로 관찰되는 동작만으로 처음부터 새로 짜는 방식이에요. 1980년대 IBM PC의 BIOS를 다른 회사들이 합법적으로 따라 만들 때 쓴 오래된 기법이죠. 코드가 Rust로 새로 쓰였기 때문에 영상에서도 "그레이 영역 같다"고 조심스럽게 표현했습니다.

그럼 품질은 어떨까요? 모델하우스를 떠올려 보세요. 거실 소파 배치, 주방 타일, 창밖 풍경까지 실제 아파트와 똑같아 보입니다. 사진으로 찍으면 구분이 안 돼요. 그런데 수도꼭지를 틀면 물이 안 나오고, 벽 뒤에는 배관 대신 합판이 있죠.

PhotoCraft가 지금 그 상태입니다. 9월 30일에 저장소가 생긴 2주짜리 초기 알파 버전이고, 열린 이슈가 800개를 넘습니다. 8,192픽셀이 넘는 이미지에서 성능이 급격히 떨어지고, 인쇄에 필요한 색 관리(CMYK, ICC 프로파일)는 아직 걸음마 단계예요. 한 픽셀 아티스트는 "전혀 쓸 수 없다"는 평가까지 했고, 개발자도 "한 달 안에 어도비 기능을 따라잡겠다"던 약속을 "몇 달 걸릴 것"으로 물렸습니다.

더 근본적인 이유도 있습니다. 요즘 포토샵 구독을 지탱하는 생성형 채우기 같은 기능은 내 컴퓨터가 아니라 어도비 서버(Firefly) 에서 돌아갑니다. 내 컴퓨터에 바이너리가 없으니 뜯어볼 대상 자체가 없어요. 카메라별 색 프로파일이나 팬톤 색상표처럼 수십 년의 데이터와 라이선스 계약으로 쌓인 부분도 코드만 따라 짠다고 생기지 않습니다.

REA 저장소 스스로도 이 점을 분명히 합니다. README에는 원본 소스 코드를 복구하거나 앱을 자동으로 복제한다고 주장하지 않는다는 문장이 들어 있고, 웹사이트 그림을 만드는 내부 지침에도 "자동 복제"나 "완전한 재구성"을 암시하지 말라고 적혀 있어요. 만든 사람이 먼저 "복사기 아닙니다"라고 말하고 있는 셈입니다.

참고 자료(3)

6. 바이브 코더에게 문턱은 정말 낮아졌을까?

사실관계를 바로잡았으니 이제 지도의 실전 구역입니다. 과장을 걷어내도 남는 진짜 변화가 무엇인지 보겠습니다.

바이브 코더의 문턱

남는 변화는 분명히 있습니다. 그림판 프로그램 다시 만들기 실험이 좋은 예예요. 성공지식백과는 "윈도우 그림판을 리버스 엔지니어링해서 간단한 그림판을 만들고, 오른쪽에 붙여넣은 그림이 목록으로 쌓이는 패널을 추가해줘"라고 한 줄 입력했습니다. 정확한 시간을 모르지만 길지 않은 시간 뒤 그리기, 색 바꾸기, 아이콘 툴팁, 채우기가 동작하는 그림판이 나왔을 것입니다. 새로 요청한 에셋 목록 패널에서는 이름 바꾸기, 다시 붙여넣기, 다운로드, 삭제까지 됐어요. 물론 채우기 커서 모양이 안 바뀌는 등 빈틈은 있었습니다.

이건 옷 수선과 비슷합니다. 옷을 처음부터 디자인하는 건 어렵지만, 이미 잘 맞는 셔츠에 주머니 하나 다는 건 훨씬 쉽죠. 원래 옷의 재단선을 보고 거기에 맞춰 바느질하면 되니까요. 영상도 REA가 가장 의미 있는 순간을 "내가 쓰던 앱에 내가 원하던 기능을 추가로 넣을 때"라고 정리합니다.

예전에는 이 수선을 하려면 Ghidra 설치법부터 어셈블리 읽는 법까지 따로 배워야 했어요. 이제는 "이 앱의 이 기능이 어떻게 돌아가는지 봐줘" 한 줄이면 1차 분석이 시작됩니다. 영상이 REA를 "전문가용이라기보다 일반인·바이브 코더용"이라고 평가한 이유입니다.

다만 반대 의견도 알아두세요. 다른 분석가는 REA를 "이미 리버스 엔지니어링을 할 줄 아는 사람이 Ghidra를 쥔 에이전트를 부리는 공구함"이라고 봅니다. 둘 다 맞는 말이에요. 진입은 쉬워졌지만, 결과를 판단하는 눈은 여전히 필요합니다. 그림판처럼 단순한 앱은 11분이지만, 앱이 커질수록 토큰과 시간과 검증 부담이 함께 커지거든요.

영상은 두 가지 전망도 덧붙입니다. 하나는 회사들이 핵심 로직을 앱 안에 넣지 않고 서버로 옮길 것이라는 점, 다른 하나는 이런 분석 기능이 머지않아 에이전트의 기본 기능이 될 것이라는 점이에요. 사실 지금도 REA 없이 스크린샷을 보여주고 "이렇게 만들어줘"라고 하는 방식은 다들 해보셨을 겁니다. REA는 거기서 한 단계 더, 파일 안쪽까지 들여다보게 해줄 뿐이죠.

참고 자료(2)

7. 무엇을 조심해야 할까?

문턱이 낮아진 만큼 발을 헛디딜 곳도 많아졌습니다. 지도에서 가장 빨간 표시가 붙은 구역이에요.

조심해야 할 것

열쇠공을 생각해 보세요. 자물쇠를 여는 기술은 하나지만, 그 기술로 잠긴 내 집 문을 여는 것과 남의 집 문을 여는 것은 완전히 다른 일입니다. 리버스 엔지니어링도 기술 자체보다 "어디에 쓰느냐"가 문제가 됩니다.

① 법적 선. 우리나라 저작권법 제101조의4는 정당하게 프로그램을 쓰는 사람이 다른 프로그램과의 호환에 필요한 정보를 다른 방법으로 얻기 어려울 때, 그 필요한 부분에 한해서만 역분석을 허용합니다. 그렇게 얻은 정보를 호환 외의 목적에 쓰거나, 원래 프로그램과 표현이 실질적으로 비슷한 프로그램을 만들어 파는 데 쓰면 안 돼요. 즉 "상업 앱을 분석해서 똑같이 만들어 팔기"는 명백히 선 밖입니다. 라이선스 약관에서 역분석을 금지하는 경우도 많으니 그것도 확인해야 하고요. (이 글은 법률 자문이 아니니, 실제 판단이 필요하면 전문가와 상의하세요.)

② REA가 스스로 금지한 용도. REA의 면책 문서는 DRM·라이선스 체크·안티치트 우회, 게임 핵 개발, 남의 시스템 인증 우회, 상용 소프트웨어의 보호된 코드와 에셋 복제를 돕지 않는다고 명시합니다. 이런 요청은 이슈에서 답변 없이 닫힌다고 해요. 또 IDA·Hopper 같은 유료 도구는 정식 라이선스로 써야 하고, 크랙 버전은 허용되지 않습니다.

③ 실제로 벌어지는 일. 이미 게임사들은 움직이고 있습니다. 액티비전은 AI로 디컴파일한 콜 오브 듀티 영상을 내리게 했고, 베데스다는 AI로 만든 폴아웃 브라우저 게임에 중지 요청을 보냈어요. 레트로 게임 커뮤니티에서는 품질 낮은 AI 이식판을 "슬롭컴프(slopcomp)"라고 부르며 반발하기도 합니다.

④ 보안과 비용. 일부 분석은 대상 프로그램을 실제로 실행하거나 네트워크를 엿봅니다. 출처를 모르는 프로그램은 가상 머신 같은 격리된 환경에서 다뤄야 해요. 그리고 REA 공식 경로가 아닌 비슷한 이름의 저장소나 복사된 README를 조심하라는 경고가 README 맨 위에 있습니다. 인기 도구에는 늘 가짜가 따라붙거든요. 마지막으로 토큰 비용, 이건 4번에서 본 대로입니다.

참고 자료(4)

8. 주니어 개발자는 REA를 어떻게 써야 할까?

지도의 마지막 칸입니다. 조심할 것을 알았으니, 이제 이 도구를 우리 공부에 제대로 써먹는 방법으로 마무리하겠습니다.

주니어 개발자의 활용법

제가 추천하는 방식은 과학 실험 노트처럼 쓰는 겁니다. 실험 노트에는 질문, 관찰, 가설, 검증이 순서대로 적히죠. REA 공식 사이트의 예제가 정확히 이 구조예요.

윈도우 계산기에서 200 + 10%를 누르면 왜 220이 나올까요? 이 질문 하나로 시작합니다.

  1. 질문 하나만 던진다: "REA로 윈도우 계산기의 % 버튼을 살펴봐. + 뒤와 × 뒤에서 규칙이 어떻게 다른지 알려줘."
  2. 증거를 받는다: REA가 % 처리 부분의 어셈블리와 디컴파일 결과를 돌려줍니다. 연산자 번호를 비교하는 분기와 상수 100이 보여요.
  3. 규칙을 말로 정리한다: + 뒤에서는 "앞 숫자의 10%"(200의 10% = 20)를 계산하고, × 뒤에서는 10%를 0.1로 바꿉니다. 그래서 200 + 20 = 220.
  4. 작게 다시 만들고 비교한다: 그 규칙대로 작은 계산기를 만들고, 원본과 같은 입력에 같은 결과가 나오는지 테스트합니다.

크롬의 공룡 게임 예제도 같은 흐름입니다. 속도가 6에서 시작해 매 업데이트마다 0.001씩 늘어 13에서 멈춘다는 규칙을 찾아내고, 그 규칙으로 속도 조절 슬라이더가 달린 미니 게임을 만들죠.

이 방식이 주니어에게 좋은 이유는 "왜 이렇게 동작하지?"라는 질문을 코드 수준의 증거로 답하는 연습이 되기 때문입니다. 실무에서 남이 짠 코드를 디버깅하는 근육과 정확히 같은 근육이에요.

연습 대상은 이렇게 고르세요.

  • 내가 직접 만든 앱, 또는 소스가 공개된 오픈소스 앱 (공룡 게임처럼 원본 코드와 비교해 볼 수 있으면 가장 좋습니다)
  • 기능 하나만 묻기. "이 앱 전체를 복제해줘"는 토큰만 태우고 배우는 건 적습니다
  • 결과물의 "모르는 부분" 항목을 꼭 읽기. AI가 확신하지 못한 곳이 여러분이 공부할 곳입니다

아무 지식 없이 "처음부터 끝까지 해줘"만 반복하면 안 되고, 최소한 AI가 만든 결과물을 읽고 검토할 실력은 있어야 품질이 올라갑니다. REA는 그 실력을 키우는 돋보기로 쓸 때 가장 빛납니다.

참고 자료(3)

댓글

불러오는 중입니다…