AI가 앱을 뜯어본다고? REA는 어디까지 알아낼까계산기 % 버튼 하나로 시작하는 리버스 엔지니어링 안내서

Claude CodeCodexCursorGemini CLIGitHub CopilotWindsurfOpenCodeTraeMCPGhidraElectronNode.jsnpmAndroid.NETChromeWebAssemblyGo

Claude CodeCodexCursorGemini CLIGitHub CopilotWindsurfOpenCodeTraeMCPGhidraElectronNode.jsnpmAndroid.NETChromeWebAssemblyGo

01계산기 % 버튼에 숨은 두 개의 규칙

다시 계산기로 돌아가 볼까요? 비밀은 단순합니다. 덧셈에서는 “200의 10%”, 즉 20을 구해서 더합니다. 곱셈에서는 10%를 0.1로 바꿔서 곱합니다.

버튼은 하나인데 규칙은 두 개입니다. 매일 쓰던 계산기가 갑자기 조금 수상해 보이지 않나요? 아래에서 연산자를 바꿔 가며 직접 눌러 보세요.

대부분은 “원래 그런가 보다” 하고 넘어갑니다. 그런데 개발자라면 궁금해집니다. 이 규칙은 프로그램 어디에 적혀 있을까? 내 앱에 똑같이 넣으려면 어떻게 해야 할까?

REA 공식 사이트가 첫 예제로 내세운 것이 바로 이 % 버튼입니다. 앱 전체가 아니라 버튼 하나. 이 선택에 REA를 이해하는 열쇠가 있습니다. 실제로 Microsoft가 공개한 계산기 소스를 보면 덧셈·뺄셈과 곱셈·나눗셈의 퍼센트 처리가 따로 나뉘어 있습니다.^[1] ·^[2]

02김치찌개의 비법을 맛으로 알아내기

단골 식당의 김치찌개가 너무 맛있다고 해 봅시다. 조리법은 안 알려 줍니다. 그래도 한 숟갈 떠 보면 꽤 많은 걸 알 수 있습니다. 돼지고기가 들었네. 묵은지구나. 끝맛에 멸치 육수가 느껴지는데?

프로그램도 비슷합니다. 사람이 읽고 쓰는 소스 코드는 조리법이고, 우리가 내려받아 실행하는 앱은 완성된 찌개입니다. 특히 Windows나 Mac에서 바로 실행되는 네이티브 프로그램은 조리법이 찌개가 되는 과정에서 요리사의 메모, 즉 사람이 붙인 이름과 설명이 대부분 사라집니다. 다만 JavaScript로 만든 앱처럼 읽을 수 있는 코드가 꽤 남는 경우도 있습니다.

완성된 찌개를 맛보며 조리법을 거꾸로 추리하는 일. 이것이 역공학(리버스 엔지니어링)입니다. 그렇게 알아낸 조리법은 원본을 닮은 재구성이지, 요리사의 수첩 그 자체는 아닙니다.

역공학은 새로운 기술이 아닙니다. 보안 연구자는 수상한 파일을 뜯어보고, 유지보수 담당자는 소스가 사라진 옛 프로그램을 고칩니다. 미국 국가안보국(NSA)이 공개한 Ghidra, Hopper, 상용 도구 IDA 같은 전문 도구도 오래전부터 있었습니다. 문제는 이 도구들을 다루려면 전문 지식이 많이 필요했다는 점입니다.^[3]

REA가 바꾼 건 바로 그 부분입니다. 어려운 도구를 사람 대신 AI 에이전트가 다루게 했습니다. Claude Code나 Codex 같은 에이전트가 “무엇을 알아낼지” 정하면, REA가 실제 분석을 맡고 근거와 한계를 붙여 결과를 돌려줍니다.^[4] 둘을 잇는 데는 AI 앱이 외부 도구를 쓰는 표준 규약인 MCP가 쓰입니다. USB 단자에 빗댈 수 있지만, 꽂기만 하면 끝나지는 않습니다. MCP를 지원하는 에이전트에 필요한 설정을 마쳐야 REA를 연결해 쓸 수 있습니다.

AGENT → MCP → TOOLS

질문하는 AI

Claude Code

Codex

Cursor

Gemini CLI

MCP

REA알맞은 분석 기능을 골라
근거와 한계를 붙여 돌려줌

작업

실제로 살펴보는 도구

REA 내장 JS·Electron 분석

Ghidra

HHopper

IIDA

REA가 늘 남의 도구만 빌려 쓰는 것은 아닙니다. JavaScript나 Electron으로 만든 앱은 별도의 네이티브 분석 엔진 없이 REA가 직접 코드 구조를 조사합니다. Windows나 Mac에서 실행되는 네이티브 프로그램은 Ghidra·Hopper·IDA 같은 도구와 연결해 분석합니다. 웹사이트와 Android 앱 등도 지원하지만, 대상마다 얻을 수 있는 정보와 복원 수준이 다릅니다.^[5]

공식 README의 분석 대상 목록을 묶어 정리했습니다. 공식 목록

03별 400개에서 26만 개까지, 한 달 사이 생긴 일

깃허브의 스타는 “이 프로젝트 눈여겨볼게요” 하고 누르는 별입니다. 9월 내내 REA의 별은 400개 언저리였습니다. 그러다 10월 초, 곡선이 가파르게 치솟았습니다. 날짜별 숫자는 그래프와 아래 표에 모아 두고, 여기서는 그 사이에 무슨 일이 있었는지 보겠습니다.

불씨를 던진 사람 중 하나는 AI 영상 제작자 Matthew Berman입니다. 10월 8일, 그는 REA 저장소 화면에 짧은 한마디를 붙였습니다. “Software is done.” 소프트웨어는 끝났다는 뜻입니다.^[7]

재미있는 건 같은 날 남긴 답글입니다. 그는 지금이 냅스터 초기의 무법 시대 같다며 “소송이 몰려올 것”이라고 썼습니다. 환호와 걱정이 처음부터 한 묶음으로 퍼진 겁니다.^[8]

화려한 복제 시연만 있었던 건 아닙니다. 10월 12일 Reddit의 문명 5 게시판에는 조금 다른 이야기가 올라왔습니다. Mac판 문명 5에서 다른 문명이 수도를 되찾는 순간 게임이 꺼지는 오래된 버그가 있었는데, 한 사용자가 “Claude와 REA로 원인을 추적해 패치를 만들었다”고 밝힌 겁니다. 함께 공개한 저장소 설명을 보면, 이름이 지워진 게임 파일 속 한 함수가 “앞서는 팀이 없음”을 뜻하는 값을 확인하지 않고 메모리를 읽다가 충돌했습니다. 패치는 그 확인 한 줄을 넣는 방식으로 28바이트만 바꾸고, 원본을 백업하며, 지원하는 파일 버전이 아니면 적용을 거부합니다. 앱을 베끼는 대신 내가 가진 게임의 고장 난 곳을 고친 사례라 REA의 쓰임새를 잘 보여 줍니다. 다만 게시물의 추천 수는 30여 개로 작고, 패치 효과는 작성자와 저장소의 설명 기준입니다. 비슷한 시기 ChatGPT로 같은 버그를 고쳤다는 다른 사용자의 글도 있어, 이 작업이 REA만의 능력이라고 보기도 어렵습니다.^[9] ·^[10]

04써 본 사람들의 성적표, 그리고 반전

말은 많았습니다. 그럼 실제로 써 본 사람들은 무엇을 해냈을까요? 영상 설명이나 자막에서 REA 사용이 확인된 시연 세 개를 골랐습니다.^[11][12][13] 모두 제작자의 환경에서 한 번 해 본 결과이고, 조회수는 2026년 10월 15일 기준입니다.

세 장면을 나란히 놓으면 흥미로운 그림이 보입니다. 하나, 그림판에 원래 없던 기능을 얹었습니다. 복제보다 “내 입맛대로 고치기”에 가까웠습니다. 둘, 경주에서 먼저 결승선을 끊은 쪽은 REA를 쓰지 않은 버전이었습니다. 제작자 평가로는 원본에 더 가까운 결과를 REA 쪽이 냈지만요. 셋, 검증 방법이 가장 분명한 시연은 정답지를 숨겨 둔 자기 앱이었습니다.

세 시연은 각각 특정 기능이나 제한된 동작에 초점을 맞췄습니다. 이 결과만으로 원본 앱의 모든 기능과 예외 처리까지 재현했다고 판단하기는 어렵습니다.

05직접 돌려 봤다: 오류 뒤에 남은 단서들

영상만으로는 판단하기 어려워 직접 돌려 봤습니다. 시험 대상은 Electron 팀이 공개한 예제 앱 Electron API Demos^[17]입니다. Electron은 웹 기술로 데스크톱 앱을 만드는 방식으로, 슬랙과 VS Code도 이 방식을 씁니다.

이 앱을 고른 이유는 하나입니다. 정답지가 있으니까요. 소스가 공개돼 있어서 REA의 답을 원본과 한 줄씩 맞춰 볼 수 있습니다. 다만 이 저장소는 2026년 8월 2일 보관 처리돼 읽기 전용이 된 오래된 예제라, 요즘 Electron 앱을 대표하지는 않습니다.

분석은 오류 메시지로 끝났지만, 오류 응답 안에 중간 결과가 일부 남아 있었습니다. 그 결과를 우리가 소스에서 직접 검색한 목록과 비교했습니다.

18과 20, 무엇이 달랐을까

REA는 79개 파일을 읽고 그중 자바스크립트 54개를 해석했습니다. 그리고 코드 구조에서 IPC 관련 호출 구문을 식별해, 앱 안의 프로세스끼리 주고받는 메시지 이름(IPC 채널) 18개를 기록했습니다. 화면 쪽 코드가 “파일 선택창 열어 줘”라고 보내면, 메인 프로세스(앱의 창과 시스템 기능을 관리하는 쪽)가 받아서 선택창을 띄우는 식의 통로입니다.

우리가 소스를 글자로 검색해 모은 후보는 20개였습니다. 두 개가 더 많지만, REA가 놓쳤다고 단정할 수는 없습니다. REA의 숫자는 코드 구조를 해석해 IPC 호출 구문으로 식별한 결과입니다. 그 코드가 실제로 실행되는지까지 확인한 것은 아닙니다. 글자 검색은 일치하는 곳을 전부 긁어옵니다. 세는 방식이 다르니, 둘을 나눠 탐지율을 계산하면 안 됩니다.

검색에서만 보인 두 이름은 open-file-dialog-sheet와 compute-factorial입니다. open-file-dialog-sheet는 HTML 파일 안의 코드에서, compute-factorial은 HTML 파일과 자바스크립트 파일의 webContents.send 호출에서 보였습니다. HTML 쪽 코드는 데모 앱 특성상 화면에 “이렇게 쓰세요” 하고 보여 주는 예제일 수도 있고, 호출 형태에 따라 세는 방식이 달라졌을 수도 있습니다. 그래서 이 둘은 “누락”이 아니라 추가로 발견한 후보입니다.

요약표의 0, 소스의 true

Electron에는 nodeIntegration이라는 스위치가 있습니다. 앱 창 안의 웹 코드가 내 컴퓨터의 파일 같은 기능에 손댈 수 있게 허락하는 설정입니다. 보안과 직결되는, 꽤 중요한 스위치죠.

REA 요약표에는 창 설정(webPreferences)을 명시한 곳이 0건이라고 나왔습니다. 그런데 소스를 열어 보니 nodeIntegration: true가 여러 파일에 있었습니다. 요약표만 보면 “보안 설정은 신경 쓸 것 없다”고 잘못 읽을 수도 있었습니다. 요약의 0이 원본에 “없다”는 뜻은 아닐 수 있습니다.

오류의 정체

오류는 분석 결과와 별개의 문제였습니다. REA는 분석을 마친 뒤 작업용 프로세스가 잘 정리됐는지 확인하려 했습니다. 그런데 우리 테스트 환경이 프로세스 목록 조회를 막아 둔 탓에 확인하지 못했습니다. 프로세스가 실제로 남았다는 뜻은 아닙니다. 정상적으로 완료된 분석이 아니었으니, 위 숫자를 성능 점수로 쓰지도 않습니다.

REA는 파일 위치와 관계를 빠르게 정리해 줬습니다. 맞는지 판정한 것은 원본과 맞춰 본 사람이었습니다. 결과는 세 칸으로 나눠 읽으면 됩니다. 직접 본 사실, 근거 있는 추정, 아직 모르는 것입니다.

06할 수 있다고 해도 되는 건 아니다

“내 돈 주고 산 앱인데 뭐 어때?” “혼자만 쓸 건데?” 충분히 나올 법한 말입니다. 하지만 법은 그렇게 단순하지 않습니다. 무엇을, 왜 뜯어보고, 결과를 어디에 쓰느냐가 핵심입니다. 이 글은 법률 자문이 아니니, 실제 판단이 필요하면 전문가에게 물어보세요.

한국 저작권법 제101조의4는 허락 없이 할 수 있는 프로그램코드역분석을 좁게 정해 둡니다. 조건은 세 가지가 모두 맞아야 합니다. 정당한 권한으로 프로그램을 쓰는 사람(또는 그의 허락을 받은 사람)일 것, 다른 프로그램과 호환하는 데 필요한 정보를 쉽게 얻을 수 없고 그 정보의 획득이 불가피할 것, 그리고 호환에 필요한 부분만 분석할 것.

그렇게 얻은 정보도 쓸 곳이 정해져 있습니다. 호환 목적 외에 이용하거나 제3자에게 제공할 수 없고, 원본과 표현이 실질적으로 유사한 프로그램을 개발하거나 제작하거나 판매하는 데 이용해서도 안 됩니다. 판매할 때만이 아니라 개발과 제작 단계도 각각 포함됩니다. 바로 앞 제101조의3에도 프로그램의 아이디어와 원리를 확인하려는 조사·연구·시험 목적의 복제 등에 관한 별도 조건이 있지만, 어느 조항도 “역공학은 다 괜찮다”는 허가증은 아닙니다.^[18]

일반적인 설명이며 법률 자문이 아닙니다. 국가와 계약 조건에 따라 판단이 달라질 수 있습니다. 저작권법 조문

REA 프로젝트 측도 합법적인 연구, 교육, 호환성, 보존, 그리고 분석 권한이 있는 소프트웨어를 강조합니다. REA의 MIT 라이선스는 REA 코드에 대한 것일 뿐, 분석 대상의 권리까지 풀어 주지는 않습니다.^[19]

정보가 어디로 흘러가는지도 챙기세요. 분석은 내 컴퓨터에서 해도, 에이전트가 결과를 AI 모델에 보낼 때 코드 조각이 함께 넘어갈 수 있습니다. 회사 앱이라면 회사 규정과 모델 제공업체의 데이터 정책부터 확인하세요.

시작 전 체크리스트

• 준비물: Node.js 22.x에서는 22.19 이상, 24.x에서는 24.11 이상, 또는 26 이상 버전과 npm이 필요합니다(23·25는 미지원). 그다음 npx rea-agents setup을 실행해 쓸 에이전트를 고르고 변경 사항을 승인합니다.^[20]
• 분석 엔진: JavaScript·Electron 앱은 별도의 네이티브 분석 엔진이 필요 없습니다. 다만 Linux에서는 procps 호환 ps 같은 환경별 조건이 있습니다. 네이티브 프로그램은 Hopper, Ghidra, IDA 중 하나가 필요합니다.
• 비용: REA 자체는 MIT 라이선스 오픈소스라 무료지만, AI 모델 사용료와 상용 분석 도구 라이선스는 따로 듭니다.
• 첫 대상: 내가 만든 작은 프로그램이나 분석이 허용된 오픈소스 예제로 시작하세요.

07찌개 맛을 알아내도 식당 운영에는 더 많은 것이 필요하다

다시 김치찌개로 돌아가 봅시다. 열심히 맛을 보고 재료를 알아냈다고 해 볼게요. 비슷한 맛을 내는 데 도전할 수는 있습니다. 그런데 그 식당처럼 장사를 하려면요? 매일 좋은 재료를 구하고, 점심시간 주문을 소화하고, 어제와 똑같은 맛을 오늘도 내야 합니다. 맛의 비밀은 식당이라는 거대한 일의 한 조각일 뿐입니다.

소프트웨어도 같습니다. REA는 버튼 하나의 규칙을 찾고 근거를 정리하는 첫 조각을 훨씬 쉽게 만들었습니다. 서버를 운영하고, 업데이트하고, 고객 문의에 답하는 일은 그 뒤에도 남습니다. 레시피를 알아내는 일과 식당을 꾸리는 일은 다른 일입니다.

읽고 나면 생기는 질문 5가지

REA를 쓰면 앱의 원본 소스 코드를 그대로 돌려받을 수 있나요?

아닙니다. 네이티브 프로그램은 만들어지는 과정에서 사람이 붙인 이름과 설명이 대부분 사라지기 때문에, 분석으로 얻는 코드는 원본을 닮은 재구성입니다. REA는 특정 기능이 어떻게 동작하는지 근거를 찾는 데 강합니다.

코딩을 몰라도 REA를 쓸 수 있나요?

설치와 결과 확인에는 기본적인 터미널 사용이 필요합니다. Node.js와 npm을 설치한 뒤 npx rea-agents setup으로 에이전트를 연결하고, 질문은 일상 언어로 하면 됩니다. 다만 결과가 맞는지 원본과 맞춰 보는 일은 여전히 사람의 몫입니다.

분석을 내 컴퓨터에서 하면 데이터가 밖으로 나가지 않나요?

그렇지 않을 수 있습니다. 분석 자체는 로컬에서 돌아가도, 에이전트가 결과를 AI 모델에 보낼 때 코드 조각이 함께 전달될 수 있습니다. 회사 앱이라면 회사 규정과 모델 제공업체의 데이터 정책을 먼저 확인하세요.

구매한 앱이면 마음대로 분석해도 되나요?

구매만으로 모든 분석과 배포가 허용되지는 않습니다. 한국 저작권법 제101조의4는 정당한 이용자가 호환에 필요한 정보를 쉽게 얻을 수 없고 그 획득이 불가피할 때, 필요한 부분에 한해 역분석을 허용합니다. 얻은 정보도 호환 목적 외 이용이나 유사한 프로그램 개발에 쓸 수 없습니다.

처음에는 무엇으로 연습하면 좋을까요?

내가 만든 작은 앱이나 분석이 허용된 오픈소스 예제가 좋습니다. 원본 소스가 있으니 REA의 답을 직접 맞춰 볼 수 있고, 권리 문제도 분명합니다.