목차(클릭하세요)
일반인에게도 열린 리버스 엔지니어링 방식, 진짜 가치는 CLI와 연결될 때, 이제 시작이다!
[해당 깃허브 레포지토리] 현재 약 44만개 스타를 받음
[참고영상1]
[참고영상2]
[기본 용어 정리]
리버스 엔지니어링 기본 용어
용어 | 뜻 | 페이지 속 비유와 연결 |
리버스 엔지니어링 | 완성된 결과물을 거꾸로 뜯어보며 구조와 동작 원리를 알아내는 일 | 찌개를 맛보고 레시피를 알아내기 |
소스 코드 | 개발자가 사람이 읽을 수 있는 언어로 작성한 프로그램 원본 | 레시피 |
컴파일 | 소스 코드를 CPU가 실행하는 기계어로 바꾸는 과정. 이때 변수 이름, 주석, 구조가 사라짐 | 레시피대로 찌개를 끓이는 것 |
바이너리 (실행 파일) | 컴파일된 결과물. 윈도우의 .exe, .dll 등 | 다 끓인 찌개 |
어셈블리 | 기계어(0과 1)를 사람이 겨우 읽을 수 있게 1:1로 옮긴 저수준 명령어 | 성분을 하나하나 나열한 목록 |
디스어셈블러 | 기계어를 어셈블리로 풀어 주는 도구 | 성분표 뽑기 |
디컴파일러 | 기계어를 C언어 비슷한 코드로 되돌려 주는 도구 (Ghidra, IDA의 Hex-Rays) | 성분표로 레시피 비슷한 것을 재구성 |
의사 코드 (Pseudo code) | 디컴파일러가 만든, 원본과 똑같지는 않지만 동작을 짐작할 수 있는 코드. 이름이 사라져 FUN_00401A30처럼 표시됨 | 재료 이름이 지워진 레시피 |
심볼 | 함수 이름, 변수 이름 같은 이름 정보. 배포할 때 지우는 경우가 많고, 이를 스트리핑이라고 함 | 레시피 속 재료 이름 |
난독화 (Obfuscation) | 프로그램은 똑같이 동작하게 두면서, 분석하기 어렵도록 코드를 일부러 꼬아 놓는 기법 | 레시피를 암호문과 헛갈리는 단계로 뒤섞기 |
정적 분석 | 프로그램을 실행하지 않고 파일 내용만 읽어서 분석하는 것 | 성분 분석 |
동적 분석 | 프로그램을 실제로 실행하며 동작, 통신, 파일 접근을 관찰하는 것 | 끓이는 과정을 CCTV로 찍기 |
후킹 / 인스트루먼테이션 | 실행 중인 프로그램의 특정 함수에 끼어들어 오가는 값을 엿보거나 바꾸는 기법. 대표 도구는 Frida | 조리 중간에 냄비 속을 들여다보기 |
클린룸 설계 | 분석 팀은 동작 설명서만 쓰고, 원본을 본 적 없는 구현 팀이 그 설명서만 보고 새로 만드는 방식. 저작권 침해를 피하기 위한 절차 | 맛 설명서만 받은 다른 요리사가 새로 끓이기 |
1. REA가 핫한 이유
1-1. REA는 도대체 무엇인가?
•
REA=Reverse Engineer Anything
•
Claude Code, Codex, antigravity 같은 코딩 에이전트에 REA를 연결하여 바로 사용가능
•
AI가 Ghidra(기드라) 같은 분석 도구를 직접 호출해 조작
•
REA는 기존 리버스 엔지니어링 도구들을 하나로 묶은 로컬 분석 도구
◦
MCP, CLI, 스킬이 모두 제공 됨
◦
컴퓨터에서 돌아가는 웬만한건 다 뜯어볼 수 있다고 알려짐(플레이스테이션, 웹,앱, 안드로이드 등)
1-2. 화제가 된 사건
•
한 개발자가 어도비 앱 7개를 다시 만들어 무료로 공개함 (ArtCraft)
◦
포토샵, 프리미어, 라이트룸, 일러스트레이터 등
◦
Claude Opus 5.5로 Rust 언어로 작성
◦
계기: 어도비 해지 위약금에 대한 불만
•
커뮤니티 반응: "이제 소프트웨어의 시대는 끝났다"
1-3. 프로그램은 왜 '금고'였나?
•
프로그램의 두 모습
◦
소스 코드: 사람이 읽을 수 있는 글자
◦
실행 파일: 컴파일을 거친 0과 1의 기계어
•
비유: 코드는 레시피, 실행 파일은 다 끓인 된장찌개
•
컴파일하면 변수 이름, 주석, 구조가 사라짐
•
회사들은 레시피는 금고에 두고 찌개만 판매함 (어도비, MS, 게임사)
•
디컴파일러(Ghidra 등)는 오래전부터 있었음
◦
결과물이 FUN_00401A30 같은 이름 없는 코드라 해석에 전문가가 몇 주씩 걸림
•
자물쇠가 튼튼해서가 아니라 따는 데 너무 오래 걸려서 아무도 안 따던 금고
1-4. AI가 금고를 따기 시작함
•
기계적인 되돌리기는 원래 가능했음
•
사람이 지쳐서 못 하던 일은 "이 함수가 무슨 일을 하는지" 알아내는 해석
•
AI는 이름 없는 코드 수만 줄을 지치지 않고 해석함: 몇 주 → 몇 분
•
이것이 "소프트웨어는 끝났다"는 말이 나온 이유
2. REA 개요와 작동 원리
2-1. 작동 구조
•
사용자가 에이전트(클로드 코드 등)에 "이 앱 기능을 똑같이 만들어 달라"고 지시
•
에이전트가 REA MCP를 호출하고, REA가 분석 툴(Ghidra, Hopper, IDA)에 작업 지시
•
웹사이트와 일렉트론 앱은 Chrome 브라우저로 화면 구조와 네트워크까지 분석
•
분석 결과물 3종
◦
Pseudo 코드(=의사코드): 동작을 사람이 읽을 수 있게 적은 설명
▪
디테일한 코드는 아님
◦
근거: 해당 동작이 일어나는 이유
◦
모르는 부분: 분석하지 못한 영역
•
에이전트가 코드 작성, 테스트, 재질문을 반복해 원하는 기능이 모두 구현될 때까지 진행
2-2. 핵심 분석도구: Ghidra
•
미국 국가안보국(NSA)이 내부에서 약 20년간 사용했던 리버스 엔지니어링 도구, 2019년 오픈소스로 공개
•
기능: 기계어를 명령어로 풀고 C언어 비슷한 코드로 재조립
•
비유: 찌개의 성분 분석 (무엇이 들어갔는지는 알려 주지만, 왜 넣었는지는 사람이 해석)
•
한계: 사람이 쓰라고 만든 프로그램이라 AI가 바로 쓰기엔 불편하고, 바로 리버스 엔지니어링이 끝나지 않았음
2-3. 보조 분석도구 및 REA의 핵심
•
IDA((Interactive DisAssembler)
◦
1990년대부터 사용
◦
버스 엔지니어링 업계의 사실상 표준 도구
◦
보안 연구, 악성코드 분석, 취약점 연구에서 가장 오래 쓰여 온 상용 도구
•
Hopper(=Hopper Disassembler)
◦
프랑스 개발자가 만든 비교적 저렴한 상용 도구
◦
macOS와 Linux용 (Windows 미지원)
◦
맥과 iOS 앱 분석에 강점 (Objective-C, Swift 구조 해석)
◦
디스어셈블과 디컴파일(의사 코드) 모두 지원
•
REA의 역할: 기존 분석 툴을 에이전트가 쓰기 쉽게 하나로 연결
◦
네이티브 분석: Ghidra, IDA, Hopper
◦
안드로이드 앱 분석: JADX
◦
실행 관찰: Frida
3. 설치와 실습, 사례
3-1. 설치 방법(A와 B중 선택)
•
방법 A: 깃허브 README의 설치 명령어를 터미널에 입력
•
방법 B: 깃허브 링크를 에이전트에 붙여넣고 "클로드 코드에 맞게 셋업해줘" 요청
•
설치 후에는 위에서 설명한 Ghidra, IDA, JADX 등이 제대로 작동되는지, 연결 상태를 확인하는 것도 좋음
•
Agent에 따라 MCP연결을 따로 설정해줘야 하는 경우가 있음
3-2. [실습1] 윈도우 그림판 재구현(APP)
•
지시: 그림판을 리버스 엔지니어링해 간단한 그림판 제작
[예시 프롬프트]
윈도우 그림판을 rea 사용해서 새로운 간단한 그림판을 만들어주고, 추가기능으로 우측패널에 내가 붙여넣기하는 그림들이 에셋으로 리스트로 저장되는 기능을 넣어줘.
JavaScript
복사
•
추가 기능: 붙여넣은 그림이 우측 패널에 에셋 리스트로 저장되는 기능
•
대략 10분 정도만에 초안이 완성됨
•
핵심 기능이였던 에셋 역시 제대로 구현된 것을 볼 수 있음
[초안 파일 다운로드]
3-3. [실습2] 단축주소 bit.ly 재구현(Web)
[타겟 사이트] bit.ly
•
애용하는 사이트 중 하나
•
원하는 단축주소로 링크를 생성할 수 있는 장점
[예시 프롬프트]
https://bitly.com/ 이 사이트를 rea활용해서
bit.link 사이트를 만들꺼야. 먼저 핵심기능은 내가 원하는 단축주소로 바꿀 수 있어야 하는 거야. 그걸 제대로 구현해내
JavaScript
복사
•
해당 서비스를 나를 위한 맞춤형 비공개 서비스로 전환하기 위해 REA진행
•
1일 최대 5회까지 사용가능, 접속자 통계 정보 등을 구현
•
특히, 실제로 웹 서비스로 이용하기 위해 구글 fire_base서비스 연동
•
작업 과정은 Agent-Desktop모드를 활용하여 대부분 자동으로 진행되었으나, 구글 로그인, blaze유료 결제 같은 risk있는 작업은 사람 클릭이 필요 했음
•
실제 만들어본 서비스: 양파고의 bit.link
•
VIP를 위한 비공개 서비스로 실제로 내가 사용 예정
•
테스트 결과: 매우 잘됨
•
이 페이지를 단축주소로 테스트 해본 결과 오류없이 작동
4. 활용 기준과 법적 유의
4-1. 권장 사용 시점
•
내가 쓰는 앱에 원하는 기능을 추가할 때 (그림판 + 에셋 리스트 사례)
•
개인용 앱을 만들 때 잘 만든 도구의 플로우를 확인해 가져오기
4-2. 비권장( 법적 문제)
•
남의 앱을 통째로 베끼거나 같은 앱을 찍어낼 때 → 불법 복제 앱이 됨
•
프로덕션급 앱 제작에는 부적합하다는 전문가 의견
4-3. 법적 기준
•
상업용 앱을 임의로 분석해 똑같이 만드는 행위는 불법
•
라이선스가 걸린 앱은 소프트웨어 관련 법 준수
•
재구현한 앱은 개인 공부용으로만 사용
5. 전망과 결론
5-1. 소프트웨어 방향과 기업 대응
•
대부분의 소프트웨어가 사실상 오픈소스처럼 될 것
◦
모델 성능이 좋아져 프론트엔드와 백엔드를 누구나 구현할 수 있음
◦
스타트업 웹서비스를 코덱스와 클로드가 흡수하는 중
•
기업 대응 예상
◦
반대로 기업은 핵심 로직과 오프라인 기능을 앱에 탑재하기를 꺼림
◦
해당 기능을 서버에서 제공하는 방식으로 이동
5-2. REA 없이도 가능한 방식
•
REA를 사용하지 않더라도, Agent에게 기능 분석 요청, 스크린샷 촬영 후 추론해 비슷하게 재현할수 도있음
•
REA의 장점: 파일 내부까지 세밀하게 분석해 완성도 향상
•
예측컨대 한두 달 안에 분석 기능이 Agent의 기본 기능이 될 가능성도 있음
5-3. 한계
폴리싱이 진짜 승부처•
프로토타입보다 매끄럽게 다듬는 ‘폴리싱’이 훨씬 어렵고 오래 걸림
◦
웹보다 앱, 앱보다 게임으로 갈수록 더 어려움
◦
반응 속도, 미세한 끊김, 손에 붙는 느낌
•
프로토타입은 몇 주, 폴리싱은 몇 년이 걸리기도 함
•
ArtCraft는 폴리싱 단계가 통째로 빠진 상태
[앞으로의 주요 Point]
오픈소스 개발자들이 AI와 함께 달려들면 폴리싱도 빨라질까?
5-3. 지금 REA가 가지는 가치
•
CLI방식과 연결될 때의 가치는 무궁무진
•
이게 뭔소리인가?
◦
REA방식으로 만든 프로그램을 CLI로 연결시켜, AGent에서 해당 프로그램의 작업을 모두 다 말로 시킬 수 있는 시대가 열린 것임
•
즉, 만들어진 프로그램이 사람에게 최적화된 방식이 아니라 AI가 CLI로 제어하기에 최적화된 방식 이라는 점
◦
ArtCraft의 경우 CLI용 설치 프로그램이 아예 별로도 존재함
