[Trend & Event]앱을 만드는 AI가 앱을 분석한다. 앱의 작동 원리를 추적하는 AI 역공학

[Trend & Event]

REA의 정의와 활용법, Notion·DX-Ball·Aegis의 분석 결과와 검증 범위

완성된 앱의 기능을 보고 “이 동작은 어떻게 구현했을까”라고 물으면, 관련 파일과 코드부터 찾아주는 도구가 있다. REA(Reverse Engineer Anything)는 인공지능(Artificial Intelligence, AI) 코딩 에이전트를 소프트웨어 분석 도구와 연결하는 오픈소스 프로젝트다. 기업이 검토할 활용처는 기존 프로그램의 동작 문서화와 새 구현의 결과 비교다.

2026년 10월 11일 발표된 REA 6.4.0에는 Android 기기 분석 기능과 대규모 JavaScript 분석의 자원 제한·부분 결과 보존 등이 포함됐다. 분석 대상을 넓히면서 작업을 끝내지 못했을 때도 확인한 내용은 남기도록 했다. [1][2]

REA, 앱의 작동 원리를 추적한다 · 분석 도구가 제공한 근거와 에이전트의 해석, 별도 테스트를 구분해야 한다.

사례를 읽는 기준

아래 사례는 REA 측이 공개한 기술 분석 기록이다. Notion이나 Aegis 운영사가 REA를 도입해 사업 성과를 냈다는 고객 사례가 아니다. AgencyTimes는 공개된 근거와 검증 범위를 비교했으며, 해당 프로그램을 직접 분석하거나 테스트를 재실행하지 않았다.

REA란 무엇인가: 완성된 소프트웨어에서 작동 원리를 되짚는다

역공학(Reverse Engineering)은 완성된 결과물을 분석해 내부 구조와 작동 방식을 알아내는 작업이다. 소프트웨어에서는 실행 파일, 배포된 코드, 데이터 형식, 실행 중 동작 등을 조사한다. 원래 개발자가 작성한 소스코드가 없어도 분석할 수 있지만, 원본의 변수명과 주석, 설계 의도까지 그대로 되찾는다는 뜻은 아니다.

REA는 이 작업을 코딩 에이전트의 도구 호출과 연결한다. 공식 구성은 모델 컨텍스트 프로토콜(Model Context Protocol, MCP) 서버와 명령줄 인터페이스(Command-Line Interface, CLI)다. MCP는 에이전트가 외부 도구를 호출하는 연결 규약이고, CLI는 사용자가 터미널에서 명령어로 같은 작업을 수행하는 방식이다. REA 자체를 새로운 AI 모델이나 독립적인 디컴파일러로 이해하면 역할을 혼동하게 된다. [1]

역할은 이렇게 나뉜다

사람이 질문과 범위를 정한다. 어떤 기능을 조사할지, 무엇을 실행해도 되는지 결정한다.
에이전트가 REA의 분석 기능을 호출한다. 지원 도구로 파일·함수·호출 관계를 조사하고 근거를 받는다.
에이전트가 근거를 해석한다. 설명이나 새 구현을 만들 수 있지만, 결과의 정확성과 사용 가능성은 별도 검토 대상이다.

조사 대상에는 JavaScript·Electron 앱, 네이티브 실행 파일과 라이브러리, Android 설치 파일(Android Package, APK), 웹사이트와 저장된 네트워크 기록 등이 포함된다. 컴퓨터가 직접 실행하는 네이티브 코드를 깊게 분석할 때는 Hopper·Ghidra·IDA 같은 별도 분석 엔진을 사용한다. 정적 JavaScript 분석은 이런 네이티브 엔진 없이도 가능하다. 운영체제와 대상 형식에 따라 준비할 도구는 달라진다. [1]

이름에 Anything이 들어가지만, 사진 한 장으로 제품의 제조법이나 기업의 사업 전략까지 복원하는 범용 서비스는 아니다. 웹 화면과 통신 기록을 관찰하더라도 접근할 수 없는 서버 내부 구현까지 확인했다고 볼 수는 없다. 조사할 수 있는 자료의 범위가 결론의 범위다.

REA 활용법: 앱 전체보다 동작 하나를 질문한다

처음에는 직접 소유하거나 분석 권한을 확보한 테스트 앱에서 시작하는 편이 낫다. “이 앱을 전부 다시 만들어줘”보다 “내보내기 버튼을 누르면 어느 코드가 파일을 저장하는가”처럼 질문을 좁히면 필요한 자료와 검증 방법을 정하기 쉽다. 아래 절차와 요청문은 공식 설치 안내를 바탕으로 구성한 실무용 예시다.

먼저 실행 환경을 준비한다. 공식 문서 기준으로 Node.js 22.x는 22.19 이상, 24.x는 24.11 이상을 지원하며 26 이상도 사용할 수 있다. npm과 호환되는 코딩 에이전트를 준비한 뒤 다음 명령으로 설정을 시작한다. [1][3]

npx rea-agents@latest setup

연결할 에이전트를 선택하고, 변경할 설정 경로와 설치 항목을 확인한 다음 승인한다. 설정이 끝나면 안내된 에이전트를 다시 시작한다. 회사 환경에서는 실제 설치 버전과 설정 변경 내역도 기록해 두는 것이 좋다. @latest는 실행 시점의 최신 배포판을 가리키므로 나중에 같은 환경을 재현할 때 버전 기록이 필요하다.

다음으로 조사 요청에 근거와 금지 범위를 함께 적는다. 파일을 읽는 정적 분석과 프로그램을 실행하는 동적 분석을 처음부터 구분한다.

분석 권한이 있는 로컬 테스트 앱에서 문서 내보내기가 시작되는 코드와 파일 저장까지의 경로를 찾아줘.

먼저 프로그램을 실행하지 않고 파일만 읽어 분석해줘. 각 결론에 파일명·함수·코드 위치 등 확인 가능한 근거를 붙여줘.

직접 확인한 내용, 코드에서 추론한 내용, 실행 검증이 필요한 부분을 나눠 설명해줘. 프로그램 실행·네트워크 접근·파일 변경은 내 승인 전에는 하지 마.

터미널에서 JavaScript·Electron 앱을 조사하는 공식 명령 형태는 다음과 같다. 경로는 분석 권한이 있는 앱의 실제 경로로 바꿔야 한다. [1]

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

마지막으로 설명을 테스트 항목으로 바꾼다. 결과를 받으면 어떤 파일의 어느 버전을 읽었는지, 결론을 뒷받침하는 코드가 어디에 있는지부터 확인한다. 새 구현을 만들었다면 정상 입력뿐 아니라 빈 값, 범위 경계, 오류 조건에서도 원래 프로그램과 같은 결과가 나오는지 비교해야 한다.

요청문에 “실행하지 마”라고 적는 것만으로 시스템 권한이 제한되지는 않는다. 별도 작업 공간에서 최소 권한으로 시작하고, 첫 테스트에는 운영 계정이나 고객 데이터를 연결하지 않는다. REA의 책임 있는 사용 안내도 파일 분석, 프로그램 실행, 네트워크 관찰을 서로 다른 권한 문제로 구분한다. [7]

Notion: 복사 버튼 하나에서도 분석과 검증이 갈린다

Notion은 문서 작성과 협업에 사용하는 서비스다. REA의 공개 사례는 그중 데스크톱 앱에서 텍스트와 서식을 클립보드로 전달하는 경로를 살펴본다. 웹 기술로 데스크톱 앱을 만드는 Electron에서는 화면을 그리는 프로세스와 운영체제 기능을 다루는 주 프로세스가 나뉜다. 이 사례에서는 복사 요청이 두 프로세스 사이를 어떻게 오가는지 조사했다. [4][8][10]

분석 대상 · Notion Desktop 7.6.1의 배포 JavaScript · REA 공개 기록상 분석일: 2026년 10월 7일

Notion의 복사 경로 · REA 공개 기록을 재구성한 설명도이며 실제 제품 화면이 아니다.

공개 기록에서 REA는 화면 쪽에 노출되는 연결 지점과 프로세스 간 통신(Inter-Process Communication, IPC) 호출을 찾아냈다. 이후 배포 코드의 연결 함수를 따로 읽어 복사 요청이 주 프로세스로 전달되고, 요청을 보낸 화면을 확인한 뒤 Electron의 클립보드 쓰기 기능으로 이어지는 구조를 설명했다.

REA가 전체 복사 경로를 자동으로 완성한 것은 아니다. 근거 문서에는 기능 추적 결과가 불완전했고, 해당 통신 채널의 전파도 그래프에서 해결되지 않았다고 적혀 있다. 공개된 경로도에는 REA의 정적 분석 결과와 별도의 코드 검토가 함께 사용됐다. [4]

서식과 구조화된 블록 데이터를 설명하는 웹 편집기 자료는 2026년 7월 13일의 별도 캐시를 사용했다. 따라서 데스크톱 패키지와 같은 버전에서 실제 복사·붙여넣기를 끝까지 재현한 실험으로 읽어서는 안 된다. 공개 자료가 뒷받침하는 것은 특정 경로와 데이터 처리 규칙의 분석이며, Notion 전체의 복제나 모든 서식의 보존 검증까지는 아니다. [4]

제품팀의 조사 요청도 기능 단위로 좁힐 수 있다. “Notion처럼 만들어 달라”는 요구보다 “우리 편집기에서 복사한 표가 다른 앱에 붙여 넣을 때 어떤 형식으로 전달되는가”가 더 구체적이다. 개발팀은 화면의 유사성보다 데이터가 전달되는 경로와 형식을 조사 대상으로 삼으면 된다.

DX-Ball: 63바이트의 계산을 두 방법으로 확인했다

DX-Ball은 Windows용 벽돌깨기 게임이다. REA가 소개한 작업은 물체의 가로 위치를 좌우 음향 값으로 바꾸는 함수 하나의 재구성이다. 게임 전체를 복원한 사례는 아니다. 벽돌이 맞은 위치에 따라 소리의 좌우 배치를 계산하는 규칙을 조사했다. [5]

분석 대상 · DX-Ball 1.07의 음향 위치 계산 함수 · 공개 검증 기준점: 2026년 10월 7일

DX-Ball, 계산 하나를 두 방식으로 검증한다 · 원본 실행 비교와 컴파일 결과 비교는 별개의 검증이다.

공개 기록에 따르면 초기 디컴파일 결과에는 입력값과 일부 계산 과정이 빠져 있었다. 분석자는 REA로 기계어 명령을 읽고, 이 함수를 호출하는 코드와 숫자 상수를 추가로 확인했다. 그 근거를 바탕으로 가로 위치에 1.5625를 곱하고 500을 뺀 다음 배율을 적용해 정수로 변환하는 C 함수를 재구성했다. [5]

재구성한 C 함수는 두 방식으로 원본과 비교했다. 프로젝트 기록은 원본 x86 코드와의 실행 결과 비교 3,205개, 그리고 컴파일한 함수의 63바이트 일치를 별도로 제시한다. 바이트 일치 검증에는 검토된 재배치와 참조 상수 확인이 포함된다. [5]

3,205개는 무엇을 센 숫자인가

641개 위치 × 5개 배율 = 3,205개 입력 조합

공개 기록의 가로 위치는 0부터 640까지의 정수이며, 배율은 0·0.5·1·20·−1이다. 이 검증 결과를 다른 함수나 게임 전체의 완성도로 확대해서는 안 된다.

오래된 할인·정산·수수료 계산을 새 시스템으로 옮길 때도 “그럴듯한 계산식”을 얻는 데서 끝내지 말고, 기존 시스템과 결과가 일치하는 입력 범위를 확인해야 한다. 정상 거래만 맞는지, 경계값과 음수·반올림 조건까지 맞는지 구분해야 전환 결정을 내릴 수 있다. 이때 필요한 산출물은 코드와 함께 남기는 비교 테스트다.

Aegis: 배포 파일의 인증 계산을 기준값과 대조하다

Aegis Authenticator는 로그인에 사용하는 일회용 인증 코드를 생성하는 Android용 오픈소스 앱이다. REA의 사례는 배포된 APK에서 시간 기반 일회용 비밀번호(Time-Based One-Time Password, TOTP)의 기본 계산을 추적했다. 분석 기록은 Aegis 3.4.3을 대상으로 하며 조사일은 2026년 10월 9일이다. [6]

Aegis, 인증 코드의 생성 규칙을 확인한다 · 공개 테스트 키를 사용한 계산 비교이며 실제 계정 인증을 우회한 실험이 아니다.

조사한 기본 설정은 시간을 30초 구간으로 나누고 6자리 코드를 만드는 방식이다. 모든 계정이 이 설정을 따르는 것은 아니다. TOTP 계산에는 시간 외에 공유 비밀키도 필요하다. 알고리즘을 알아냈다고 해서 다른 사람의 인증 코드를 생성할 수 있는 것은 아니다. [6][9]

REA 측은 분석 결과에서 얻은 Java 메서드들을 별도 실행 환경에 구성한 뒤, 독립적으로 작성한 Python 계산과 133개 입력을 비교했다고 공개했다. 브라우저용 구현도 같은 Java 결과와 대조했다. 테스트에는 RFC 6238에 실린 참조 입력·출력, 시간 구간의 경계, 앞자리에 0이 들어가는 결과가 포함됐다. [6]

원본 APK를 실행해 Android 화면과 실제 로그인을 검증한 것은 아니며, 인증 정보 저장소의 보안 전체를 확인한 기록도 아니다. 배포 파일에서 읽은 계산을 별도 환경에서 대조한 결과다. 공개 기록 안의 독립 작성 구현은 외부 기관의 독립 검증과도 구분해야 한다. [6]

소스코드가 공개돼 있어도 저장소의 코드와 실제 배포 파일은 따로 확인해야 한다. 이 사례에서는 APK에서 얻은 해석을 해당 버전의 소스와 다시 대조했다. 기업의 품질 검토에서도 설계 문서, 실제 배포물, 테스트 결과를 구분해 관리하는 방식으로 응용할 수 있다.

기업은 무엇에 활용하고, 어떤 결과를 성과로 인정해야 하나

세 사례는 복사 요청의 경로, 음향 계산 함수, 인증 코드의 기본 계산으로 조사 범위를 좁혔다. 검증 방식은 서로 달랐다. 따라서 REA의 가치를 판단할 때는 “분석했다”는 한 단어 안에 무엇이 들어 있는지 먼저 확인해야 한다.

첫 적용처는 문서가 비어 있는 자사 기능이다

제품·개발팀이라면 담당자가 바뀐 기능이나 문서가 부족한 배포물을 조사 후보로 삼을 수 있다. 특정 파일 형식의 읽기·쓰기, 데이터 내보내기, 오래된 계산 규칙처럼 질문과 비교 기준을 좁힐 수 있는 작업이 출발점이다. 이는 공개 사례에서 도출한 적용 제안이며, 특정 기업에서 비용 절감이 입증됐다는 뜻은 아니다.

마케팅·데이터팀은 자사 테스트 사이트의 측정 코드와 전송 요청을 조사할 수 있다. 예를 들어 버튼 클릭 뒤 어떤 요청이 발생하는지, 관찰된 요청에 기대한 값이 들어 있는지를 개발팀과 함께 조사할 수 있다. 다만 브라우저에서 요청을 봤다는 사실만으로 광고 플랫폼의 최종 집계나 매출 기여까지 검증했다고 볼 수는 없다. 관찰 범위와 성과 측정 범위를 따로 잡아야 한다.

사업·기획팀은 분석 요청서에 조사 범위와 검수 기준을 적는다. 경쟁 제품의 화면을 닮게 만드는 요구보다 우리 고객에게 필요한 동작, 이전해야 할 데이터, 유지해야 할 오류 처리 조건을 적는 편이 구현과 검증을 연결하기 쉽다. 경쟁 서비스의 고객 데이터나 서버 운영 방식이 공개되지 않았다면 그 부분은 분석 보고서에서도 빈칸으로 남겨야 한다.

보고서에서 발견·해석·검증을 분리한다

AgencyTimes의 검수 기준

발견: 파일·함수·통신 호출이 실제로 존재하는가. 버전과 코드 위치를 함께 남긴다.

해석: 그 근거로 어떤 동작을 설명하는가. 직접 관찰하지 않은 연결과 조건을 표시한다.

검증: 무엇과 어떤 입력으로 비교했는가. 원본 프로그램 실행, 추출한 계산의 실행, 컴파일 결과 비교를 서로 다른 증거로 기록한다.

Notion의 경로 분석과 DX-Ball의 원본 실행 비교는 같은 수준의 “재현 성공”으로 묶을 수 없다. Aegis의 계산 비교도 앱 전체의 보안 검증으로 확대하지 않는다. 도입 목표가 공개 사례에서 확인한 범위를 넘어선다면, 추가 검증 항목을 정하고 담당자를 배정한다.

분석 권한과 재사용 권한은 따로 확인한다

REA의 책임 있는 사용 안내는 정당한 분석, 상호운용성, 소프트웨어 보존, 권한이 있는 디버깅과 점검을 사용 목적으로 제시한다. 반면 인증·라이선스·기술적 보호조치 우회나 보호되는 코드·자산의 무단 복제는 지원 범위에서 제외한다. 파일을 갖고 있다는 사실만으로 모든 분석·실행·배포가 허용되는 것은 아니라는 설명도 포함한다. 이는 프로젝트의 사용 안내이며 개별 행위의 적법성을 보장하는 법률 판단은 아니다. [7]

업무 적용 전에는 분석 대상의 계약과 라이선스, 접근 허가, 결과물의 재사용 범위를 검토해야 한다. 로컬 분석이라는 설명도 데이터가 외부로 전달되지 않는다는 보증으로 받아들여서는 안 된다. 연결한 코딩 에이전트가 어떤 내용을 외부 모델에 보내는지, 실행 대상과 다른 도구가 네트워크를 사용하는지 별도로 확인해야 한다. [7]

검증을 마친 작업 하나에 얼마가 들었는가

플랫폼 운영 관점에서는 코드 생성량보다 검수를 통과한 작업 수를 성과로 잡는 편이 낫다. REA의 시범 도입을 평가한다면 모델 사용료와 분석 도구 비용뿐 아니라 사람이 근거를 읽고, 테스트를 만들고, 잘못된 구현을 고친 비용까지 함께 기록하는 방식을 제안한다.

검증 완료 작업당 비용
= 모델·분석 도구 사용 비용과 사람의 검토·테스트·재작업 비용의 합계 ÷ 사전에 정한 검수 기준을 통과한 작업 수

이 식은 공인된 성능 지표가 아니라 도입 판단을 위한 AgencyTimes의 제안이다. 난도가 다른 작업을 한데 섞지 말고, 같은 검수 범위의 기존 방식과 비교해야 한다. 승인된 작업이 없다면 단가를 계산하기보다 무엇 때문에 검증이 끝나지 않았는지부터 기록한다.

문서가 부족한 기능 하나를 골라 시범 과제로 삼는다. 기존 설명에 없던 동작을 얼마나 더 확인했는지, 미확인 항목이 얼마나 줄었는지, 검수까지 든 총비용이 얼마인지 기록한다. 기존 방식과 비교한 뒤 적용할 기능과 예산을 늘릴지 결정한다.

Summary

REA는 코딩 에이전트가 소프트웨어의 작동 원리를 조사할 수 있도록 분석 도구와 근거를 연결한다. Notion은 복사 경로 분석, DX-Ball은 특정 함수의 원본 실행·컴파일 결과 비교, Aegis는 별도 환경의 인증 계산 대조를 다뤘다. 기능을 분석했다고 해서 앱 전체의 동작을 검증한 것은 아니다. 기업에서는 분석 권한과 검수 항목을 정하고, 검증이 끝날 때까지 든 비용으로 도입 여부를 판단할 수 있다.

FAQ

REA에 관해 자주 묻는 질문

Q. REA는 일반적인 역공학과 무엇이 다른가요?

역공학은 분석 작업을 가리키고, REA는 그 작업에 필요한 도구를 코딩 에이전트와 연결하는 프로젝트입니다. 기존 분석 엔진과 정적 분석 기능 등을 호출하고, 에이전트가 근거를 읽어 후속 질문이나 구현 작업을 이어가도록 돕습니다. [1]

Q. 개발을 몰라도 REA를 사용할 수 있나요?

자연어로 조사 질문을 작성할 수는 있습니다. 다만 환경 설정과 권한 관리, 불완전한 분석 결과의 해석, 재현 테스트에는 기술적 검토가 필요하므로 비개발자의 단독 사용보다 개발 담당자와의 공동 검토를 권합니다.

Q. REA로 Notion 같은 서비스를 통째로 복제할 수 있나요?

공개 사례는 그런 결론을 뒷받침하지 않습니다. Notion 사례는 특정 배포 코드의 복사 경로와 관련 데이터 처리 규칙을 분석한 기록입니다. 서버 내부 구현과 운영 데이터까지 복원했다는 뜻도 아니며, 분석 결과를 제품에 재사용할 권한도 별도로 확인해야 합니다. [4][7]

Q. REA는 무료인가요?

REA 자체는 MIT License로 공개된 오픈소스 프로젝트입니다. 코딩 에이전트와 모델 사용료, 상용 분석 도구의 라이선스, 검토·테스트 인력 비용은 별개입니다. REA를 설치한다고 상용 도구의 사용 권한까지 제공되는 것은 아닙니다. [1][7]

Q. 로컬에서 분석하면 회사 자료가 외부로 나가지 않나요?

로컬 분석만으로 외부 전송이 없다고 단정할 수는 없습니다. 연결한 에이전트의 모델 호출과 데이터 처리 정책, 분석 대상 프로그램과 외부 도구의 통신을 함께 확인해야 합니다. 고객 자료와 인증 정보가 포함된 파일은 승인된 환경과 범위 안에서 다뤄야 합니다. [7]

Terminology

본문의 기술 용어

모델 컨텍스트 프로토콜(MCP): 에이전트가 외부 도구와 연결하는 규약. 연결돼 있다는 사실과 그 도구에 어떤 작업 권한을 줄지는 별도 문제다.
명령줄 인터페이스(CLI): 터미널에서 명령어로 프로그램을 사용하는 방식. 실행 명령과 버전을 기록하면 분석 환경을 다시 구성하는 데 도움이 된다.
정적 분석과 동적 분석: 정적 분석은 대상 프로그램을 실행하지 않고 파일과 코드를 읽는 작업이고, 동적 분석은 실행 중 동작을 관찰하는 작업이다. 코드가 존재한다는 근거와 실제로 실행됐다는 근거를 혼동하지 않아야 한다.
디컴파일(Decompilation): 컴파일된 프로그램을 분석해 사람이 읽기 쉬운 코드 형태로 표현하는 작업. 원래 소스코드와 동일한 문서가 복원되는 것은 아니다.
프로세스 간 통신(IPC): 분리된 실행 단위가 요청과 데이터를 주고받는 방식. Notion 사례에서는 화면의 복사 요청이 주 프로세스로 전달되는 경로를 이해하는 데 쓰인다.
시간 기반 일회용 비밀번호(TOTP): 공유 비밀키와 시간 구간을 이용해 일회용 코드를 계산하는 방식. 계산 규칙의 공개와 개별 계정 비밀키의 공개는 전혀 다른 문제다.

이 블로그 검색