핵심 요약
AI 요약
기사 목차 펼치기 / 접기
소스 코드 한 줄 받지 않고 노션을 24분 만에 통째로 복사했다는 시연 영상이 지난 17일 유튜브에 올라왔다. 영상이 쓴 도구는 깃허브(GitHub)에서 별 30만개를 넘긴 리버스 엔지니어링 도구 REA다. 본지가 같은 도구로 오픈소스 가계부 앱 하나를 직접 뜯어봤다.
설치에서 어디가 막히는지, 분석 대상을 어떻게 준비하는지, 결과를 무엇으로 채점하는지 순서대로 적었다. 실습 환경은 윈도우와 REA 6.7.0, Node.js 24.20.0이고 확인 기준일은 10월 19일이다.
REA의 정체와 정적 분석의 실제 범위
REA는 AI 에이전트에 역분석 도구를 연결해 주는 MCP 서버이자 명령줄 도구다. 클로드 코드(Claude Code) 같은 에이전트가 REA를 부르면 REA가 대상 프로그램을 분석해 근거를 돌려주며, 라이선스는 MIT다. README를 보면 분석 대상이 넓다. 윈도우·맥 실행 파일 같은 네이티브 바이너리, 자바스크립트로 만든 Electron 데스크톱 앱, .NET 프로그램, 안드로이드 앱, 웹사이트까지 다룬다. 네이티브 바이너리는 Ghidra 같은 별도 분석 엔진이 필요하지만, 자바스크립트 앱의 정적 분석은 엔진 없이 된다.
잠깐, 정적 분석은 뭘까. 프로그램을 실행하지 않고 파일만 읽어 구조를 파악하는 방식이다. 설계도를 펼쳐 보는 일에 가깝고, 이번 실습도 이 방식만 썼다.
Node.js 버전의 덫… 22.14에서 멈춰 선 설치
REA는 공식 시스템 요구 사항에서 Node.js 22.19 이상, 24.11 이상, 또는 26 이상을 요구한다. 본지 PC의 버전은 22.14였다. 22 버전대지만 기준(22.19)에 못 미쳤다.
Node.js를 공식 설치 파일로 깔았다면, winget의 업그레이드 명령은 패키지를 찾지 못한다. 설치 명령으로 덮어써야 한다.
PowerShell 창을 새로 연 뒤, 버전을 다시 확인했다. 24.20.0이 깔렸고 REA도 정상 실행됐다. 중간에 나오는 prebuild-install 경고는 REA가 쓰는 하위 패키지의 유지보수 종료 안내라 실행과는 관계가 없다.
REA는 실습 폴더에만 등록했다. 평소 쓰는 클로드 코드 설정을 건드리지 않으려는 조치다. 명령은 REA 설치 문서의 윈도우용 형식을 따랐다.
분석 대상 Actual Budget과 ‘블라인드 사본’ 격리
대상은 Actual Budget 26.10.0이다. MIT 라이선스로 공개된 Electron 가계부 앱이라 분석과 복제가 라이선스상 허용되고, 공개된 원본 소스를 정답지로 쓸 수 있다. 노션처럼 이용약관이 역분석을 금지하는 상용 앱은 고르지 않았다.
깃허브 릴리스의 Actual-windows-x64.exe(117MB)를 설치했다. 설치 폴더 이름은 앱 이름이 아니라 desktop-electron이었다. 첫 실행 화면에는 “Data folder unavailable”이 떴다. 예산 파일을 저장할 문서 폴더가 없어서 생긴 오류다.
Electron 앱은 코드를 app.asar라는 압축 파일 하나에 담는다. 이 파일만 복사해 풀었더니 198개 파일에서 오류가 났다. C++로 만든 네이티브 모듈은 압축 파일에 들어가지 못해 옆 폴더 app.asar.unpacked에 따로 있기 때문이다. 두 폴더를 함께 복사해 합치자 파일 7790개가 나왔다.
풀어 보니 설치 파일 안에 원본 소스가 들어 있었다. 동기화 서버와 동기화 엔진의 원본 파일 166개다. 이걸 두면 역분석이 아니라 소스 읽기가 된다. 본지는 이 파일을 지운 사본을 AI에 넘겼고, 다시 소스를 꺼낼 수 있는 원본 압축 파일도 실습 폴더에서 치웠다.
본지가 직접 돌려보니…REA는 껍데기를, AI는 두뇌를 읽었다
과제는 하나였다. 거래 내역을 입력·수정·삭제하는 기능이 어떻게 동작하고 데이터가 어디에 저장되는지 근거와 함께 설명하고, 같은 기능의 웹 앱을 만들게 했다. 클로드 코드는 웹 검색과 웹 조회를 끈 채 대화 화면 없이 실행했고, 모든 동작을 로그로 남겼다.
19일 오후 4시33분에 시작해 47분 만에 끝났다. 정가 기준 비용은 12.48달러(약 1만6600원)였다. 도구 호출 161회 중 REA 호출은 18회였다.
시간 초과는 본지 PC만의 문제가 아니었다. 본지가 실습 전에 리눅스 환경에서 같은 파일을 30분 제한으로 돌렸을 때도 끝나지 않았다.
AI는 두 번째 시간 초과 뒤 REA를 내려놓았다.
대신 검색 도구로 함수 이름을 찾아 해당 줄로 바로 들어갔다. 핵심 로직 묶음은 압축되지 않은 채 배포돼 있었다. 함수 이름이 그대로 남았고, 원본 파일 경로를 적은 주석도 907개 붙어 있었다.
AI가 쓴 보고서는 결론마다 근거의 출처를 달았다. 파일을 직접 읽은 근거가 25건, REA 분석이 5건, 모델이 원래 알던 지식이 3건이었다. 패키지 이름을 보고 앱의 정체를 알아챘다는 사실도 보고서에 적었다.
결론은 원본 소스와 대조했다. AI는 거래의 추가·수정·삭제가 모두 transactions-batch-update 한 곳으로 모인다고 짚었고, 원본도 그렇다. 화면에서 백엔드까지의 호출 경로와 저장 위치도 원본과 같았다.
저장 형태까지 맞았다.
금액은 100을 곱한 정수로, 날짜는 8자리 정수로 들어간다. 삭제한 거래는 지우지 않고 삭제 표시만 해 둔다. 만든 웹 앱은 테스트 5개를 통과했지만, 화면 클릭 검증은 권한이 없어 하지 못했다.
대형 번들의 한계와 REA가 멈춰 서는 지점
큰 자바스크립트 묶음 하나에 로직이 몰린 앱이면 REA의 구조 분석이 끝까지 돌지 못할 수 있다. 이번 앱이 그랬는데, 이 경우 AI는 파일을 직접 읽는 쪽으로 돌아간다. 코드가 압축돼 있으면 이 우회로도 좁아진다. 기능 추적처럼 네이티브 분석 엔진에 기대는 기능은 자바스크립트 앱에 쓰지 못한다. 프로그램 실행 과정을 기록하는 프로세스 캡처는 REA 문서상 리눅스와 맥 전용이다.
에이전트 설정도 결과를 바꾼다. 본지 PC의 클로드 코드에는 플러그인이 여럿 켜져 있었다. AI가 코드 검토 에이전트를 따로 띄우고 보안 지적까지 고친 데에는 이 영향이 있었을 수 있다. 도구 호출 161회 가운데 절반가량이 그 일에 쓰였다.
상용 앱을 대상으로 삼는 일은 다른 문제다.
REA의 면책 문서는 독점 소프트웨어를 복제하거나 보호된 코드를 재현하는 일을 돕지 않는다고 적었다. 이 실습이 성립한 건 대상이 MIT 앱이었기 때문이다.
REA는 지도를 그렸고 길은 AI가 걸었다
REA는 앱의 뼈대를 정확히 짚었다. 어떤 통로로 화면과 백엔드가 이어지고 데이터가 어떤 표에 담기는지는 REA가 처음 몇 차례 호출에서 내놓은 결과에 이미 들어 있었다. 가계부의 두뇌에 해당하는 계산과 저장 로직 앞에서는 멈췄다.
“도구는 앱의 뼈대와 지도를 그렸을 뿐, 비압축 자바스크립트의 원본 함수명을 파고들어 계산대 문을 연 것은 AI 자신이었다.”
복제를 가능하게 한 건 도구의 성능보다 앱이 배포된 방식이었다.
로직은 압축되지 않은 채 함수 이름을 달고 있었고, 원본 소스까지 설치 파일에 실려 있었다.
