역공학 도구 한눈에 보기 — Ghidra·IDA·Frida부터 REA까지

정적·동적 분석과 분석 대상에 따라 대표 역공학 도구의 역할과 선택 기준을 비교하고, AI 에이전트에 도구를 연결하는 REA의 위치와 한계를 살펴본다.

게시 2026/10/21

By clang.engineer

조회 27 분읽는 시간

역공학에 관심이 생겨 도구를 찾아보면 Ghidra, IDA, Frida 같은 이름이 나온다. 여기에 AI 코딩 에이전트와 함께 쓰는 REA까지 등장하면 무엇을 먼저 써야 하는지 헷갈리기 쉽다.

이 도구들은 모두 같은 일을 하는 경쟁 제품이 아니다. 파일 안의 코드를 읽는 도구, 실행 중인 동작을 관찰하는 도구, 통신을 확인하는 도구, 이 분석 기능을 AI에 연결하는 도구가 섞여 있다. 이름보다 먼저 어떤 질문에 답하려는지 정하면 도구의 위치가 보인다.

이 글은 공식 자료를 바탕으로 역할과 선택 기준을 정리한 입문용 비교 글이다. 직접 수행한 역공학 실습 후기는 아니며, 설치·명령어 전체를 다루는 매뉴얼도 아니다. 제품 기능과 지원 환경은 2026-10-21에 확인한 공식 자료를 기준으로 한다.

역공학은 결과물에서 동작 원리를 알아내는 일이다

일반적인 개발이 설계와 소스 코드에서 프로그램을 만드는 과정이라면, 소프트웨어 역공학은 배포된 프로그램과 관찰 가능한 동작에서 구조와 구현 원리를 추론하는 작업이다.

예를 들어 다음과 같은 질문이 출발점이 된다.

이 프로그램은 파일을 어떤 순서와 형식으로 읽는가?
버튼을 누르면 어떤 함수가 실행되고 상태가 어떻게 바뀌는가?
화면에 보이는 결과는 로컬 계산인가, 서버 응답인가?

역공학이 곧 취약점 공격이나 라이선스 우회를 뜻하는 것은 아니다. 호환성 확보, 오래된 파일 형식 이해, 보안 점검, 동작 학습에도 쓰인다. 다만 분석할 수 있는 기술적 능력과 분석·변경·배포할 권한은 별개다. 자신의 프로그램이나 허가받은 대상을 선택하고, 라이선스·이용약관·관련 법률과 데이터 취급 범위를 확인해야 한다.

먼저 구분할 두 가지: 정적 분석과 동적 분석

분석 방식	무엇을 보는가	답하기 좋은 질문	한계
정적 분석	대상 프로그램을 실행하지 않고 파일·코드·리소스를 읽음	어떤 함수와 분기가 있는가? 어떤 상수와 문자열을 사용하는가?	실제로 어떤 경로가 실행됐는지는 따로 확인해야 함
동적 분석	대상 프로그램을 실행하며 호출·메모리·입출력을 관찰	이 입력에서 어떤 함수가 호출되고 어떤 값이 나오는가?	관찰한 입력과 실행 경로 밖의 동작은 알 수 없음

정적 분석은 가능한 경로를 찾고, 동적 분석은 특정 조건에서 실행된 경로를 확인한다. 둘은 우열 관계가 아니라 서로의 빈틈을 보완하는 방법이다. 정적 분석도 파일을 파싱하는 도구의 취약점이나 자원 소모 위험까지 없다는 뜻은 아니다.

또 하나의 축은 분석 대상의 형식이다. CPU 기계어로 된 실행 파일, Android 바이트코드, .NET 어셈블리, 브라우저 JavaScript는 남아 있는 정보와 분석 방법이 다르다. 정적·동적이라는 분석 방식과 네이티브·Android 같은 대상 분류를 하나의 계층처럼 섞지 않는 편이 좋다.

네이티브 실행 파일: Ghidra·IDA·Binary Ninja

C·C++·Rust 등으로 만든 네이티브 실행 파일은 보통 CPU가 실행하는 기계어를 포함한다. 원본 소스가 없다면 이를 읽을 수 있는 표현으로 바꾸는 작업이 필요하다.

디스어셈블: 기계어를 MOV, CALL 같은 어셈블리 명령으로 표현한다.
디컴파일: 기계어의 흐름을 분석해 C와 비슷한 의사 코드로 표현한다.
교차 참조: 어떤 함수나 데이터가 어디에서 사용되는지 연결한다.

디컴파일은 원본 소스를 그대로 복원하는 일이 아니다. 주석과 원래 변수명은 사라질 수 있고, 최적화 때문에 여러 함수가 합쳐지거나 코드 구조가 바뀌기도 한다. 읽기 쉬운 의사 코드가 나왔더라도 실제 명령과 참조 관계를 함께 확인해야 한다.

도구	중심 역할	선택할 만한 이유	확인할 점
Ghidra	디스어셈블·디컴파일·함수 및 참조 분석	무료·오픈소스이며 여러 CPU와 실행 파일 형식을 지원. 스크립트와 자동화도 가능	분석 대상의 CPU·형식 지원, 설치 버전의 Java 요구사항
IDA Pro	대화형 코드 분석과 통합 디버깅	함수 이름·타입·구조를 보정하며 참조와 제어 흐름을 추적하기 좋음	상용 제품이며 에디션·구독 구성에 따라 디컴파일과 대상 지원 범위가 달라짐
Binary Ninja	디컴파일·분석 자동화·디버깅	중간 표현과 API를 활용해 반복 분석이나 자체 분석 기능을 만들기 좋음	무료 제공 범위와 유료 라이선스별 기능·플랫폼 차이

Binary Ninja의 중간 표현은 서로 다른 CPU 명령을 분석하기 편한 공통 형태로 다루기 위한 표현이다. 화면에서 함수를 읽는 데서 나아가 데이터 흐름을 검사하거나 분석 스크립트를 만들 때 의미가 커진다.

세 제품 모두 정적 분석만 하는 것은 아니다. 위 표는 대표적인 진입점을 비교한 것이며, 통합 디버거와 확장 기능의 범위는 제품마다 다르다. 처음에는 “무조건 가장 강력한 도구”보다 자신의 실행 파일을 지원하고 분석 과정을 따라갈 수 있는 도구를 고르는 것이 낫다.

실행 중 동작: x64dbg·Frida

코드에 저장 함수가 있다는 사실과 특정 버튼을 눌렀을 때 그 함수가 호출된다는 사실은 다르다. 후자를 확인할 때 디버거와 동적 계측 도구를 쓴다.

도구	중심 역할	대표적인 관찰
x64dbg	Windows x86·x64 프로그램 디버깅	중단점에서 실행을 멈추고 레지스터·메모리·호출 스택을 확인
Frida	실행 중인 프로세스에 스크립트를 연결하는 동적 계측	관심 함수의 호출과 인자·반환값을 기록하거나 동작을 변경

중단점은 지정한 위치나 조건에서 실행을 멈추는 장치다. 디버거에서는 멈춘 상태를 살펴보고 명령을 하나씩 진행할 수 있다.

Frida에서 자주 쓰는 후킹은 함수 호출 지점 등에 관찰·변경 코드를 연결하는 방식이다. 예를 들어 허가된 테스트 프로그램의 파일 저장 함수를 관찰해 어떤 경로가 전달되는지 기록할 수 있다. 함수 후킹은 소스 코드를 직접 수정하는 것과는 다르다.

둘의 역할도 완전히 배타적이지 않다. 중요한 선택 기준은 “한 번 멈춰 상세 상태를 볼 것인가”, “여러 호출을 스크립트로 반복 관찰할 것인가”다. 프로세스 접근 권한, OS 보안 정책, 앱 보호 설정 등에 따라 연결이 제한될 수 있다.

Android·.NET·웹: 대상에 맞는 도구부터 고른다

모든 프로그램을 네이티브 디컴파일러로 시작할 필요는 없다. 바이트코드나 JavaScript가 남아 있는 대상은 그 형식에 맞는 도구가 더 직접적인 출발점이다.

대상	대표 도구	무엇을 보는가
Android APK	JADX	DEX 바이트코드를 Java 형태로 디컴파일하고 코드 사용 지점을 탐색
Android APK	Apktool	매니페스트·리소스·smali를 풀어 패키지 구조를 분석하고 재구성
.NET 관리 어셈블리	ILSpy	타입·메서드와 중간 언어를 탐색하고 C# 형태로 디컴파일
브라우저 웹 앱	Chrome DevTools	로드된 JavaScript, DOM, 네트워크 요청과 실행 중 상태를 관찰

JADX와 Apktool은 자주 함께 언급되지만 초점이 다르다. Java 형태의 로직을 읽고 싶다면 JADX, 리소스와 패키지 구성을 보고 싶다면 Apktool이 출발점이다. smali는 Android DEX 바이트코드를 사람이 읽을 수 있게 표현한 어셈블리 문법이다.

JADX도 모든 코드를 정확하게 디컴파일할 수 있다고 보장하지 않는다. 난독화와 변환 방식에 따라 결과가 불완전할 수 있다. Kotlin으로 작성된 앱을 Java 형태로 읽을 수 있더라도 원래 Kotlin 소스가 그대로 돌아오는 것은 아니다.

또한 APK 안의 네이티브 라이브러리나 .NET NativeAOT 결과물은 바이트코드 중심 도구만으로 분석하기 어렵다. 앱의 출신 언어보다 실제 배포된 파일의 형식을 확인해야 한다.

Electron 앱도 화면의 JavaScript와 네이티브 모듈이 함께 있을 수 있다. DevTools로 화면 동작을 확인하는 것과 패키지 전체의 백엔드 로직·네이티브 코드를 분석하는 것은 범위가 다르다.

통신 관찰: Wireshark·Burp Suite·mitmproxy

로컬 코드를 읽어도 서버 내부 구현까지 알 수는 없다. 대신 클라이언트가 어떤 요청을 보내고 응답을 어떻게 처리하는지 관찰할 수 있다.

도구	주로 보는 단위	적합한 질문
Wireshark	패킷과 네트워크 프로토콜	어떤 주소와 통신하는가? 연결과 프로토콜 흐름은 어떠한가?
Burp Suite	웹 보안 테스트와 HTTP 요청·응답	웹 기능이 어떤 요청을 만들고 응답에 따라 어떻게 달라지는가?
mitmproxy	프록시를 통과하는 요청·응답과 자동화 스크립트	요청을 기록·재현하고 반복적으로 비교하려면 어떻게 할까?

이들은 네이티브 디컴파일러가 아니라 통신을 관찰하는 보완 도구다. 패킷을 수집했다고 HTTPS 본문이 자동으로 보이는 것은 아니다. 복호화에 필요한 키 자료가 있거나, 허가된 테스트 환경에서 클라이언트가 신뢰하도록 설정한 프록시 등이 필요하다. 인증서 고정 같은 앱의 보안 설정에 따라 프록시 관찰이 제한되기도 한다.

요청·응답에는 토큰과 개인정보가 포함될 수 있으므로 캡처 파일을 공개하거나 AI에 전달하기 전에도 별도의 검토가 필요하다.

도구는 한 가지 질문을 중심으로 조합한다

가령 자신이 만든 데스크톱 앱에서 “내보내기 버튼을 누르면 파일이 어떻게 만들어지는가?”를 조사한다고 하자. 다음은 실제 수행 결과가 아니라 도구를 조합하는 방법을 보여주는 예시다.

배포 형식 확인: 네이티브 코드인지, .NET 어셈블리인지, JavaScript 패키지인지 구분한다.
정적 분석: 해당 형식의 도구로 버튼 처리와 파일 생성 코드의 연결을 찾는다.
동적 확인: 같은 입력으로 내보내기를 실행하고 호출·전달 값·생성 파일을 확인한다.
필요할 때만 통신 분석: 서버 요청이 관여한다면 요청·응답을 추가로 관찰한다.

코드에서 발견한 경로는 가설의 근거이고, 실행 결과는 선택한 입력에서의 확인이다. 둘이 다르면 분석 대상 버전, 설정, 입력 조건부터 다시 확인한다. 여러 도구를 켰다는 사실보다 질문과 증거가 연결되는지가 중요하다.

REA는 이 도구들과 어디에서 만나는가

REA(Reverse Engineer Anything)는 코딩 에이전트가 배포된 프로그램의 코드와 참조 관계, 실행 관찰 결과를 조사하도록 돕는 역공학 도구 모음이다. MCP 서버와 CLI를 통해 분석 기능을 제공한다. MCP(Model Context Protocol)는 AI 애플리케이션이 외부 도구와 리소스를 발견하고 호출하기 위한 공통 프로토콜이다.

REA 자체가 AI 에이전트이거나 Ghidra를 대체하는 새로운 디컴파일러인 것은 아니다. AI 에이전트가 조사 방향을 정하고 결과를 해석하며, REA는 분석 기능과 근거를 제공한다. 네이티브 분석에서는 지원하는 Ghidra·IDA·Hopper 등의 분석 엔진을 사용한다.

아래 화살표는 질문과 도구 요청이 전달되는 방향을 뜻한다. 분석 결과는 반대 방향으로 돌아온다.

사용자: "이 기능은 어떻게 동작하지?"
  ↓ 질문
AI 코딩 에이전트: 조사 계획·도구 선택·결과 해석
  ↓ 도구 호출
REA: 분석 기능 제공·지원 엔진 연결·근거 반환
  ├─ 네이티브 코드 → 지원하는 분석 엔진
  ├─ JavaScript·Electron → 패키지·모듈 분석
  └─ 브라우저 등 런타임 → 지원하는 실행 관찰 기능

이 글에서 소개한 모든 도구가 REA에 연결된다는 뜻은 아니다. REA의 지원 엔진·기능·호스트 OS와 설치 조건은 별도로 확인해야 한다. JavaScript 분석처럼 네이티브 디컴파일러가 필요하지 않은 작업도 있다.

달라지는 것은 분석을 진행하는 방식이다

기존에는 사람이 함수를 검색하고 교차 참조를 따라가며 분석 도구의 결과를 해석했다. REA를 연결하면 그중 지원하는 작업을 에이전트에 자연어로 요청하고, 에이전트가 후속 도구 호출을 이어갈 수 있다.

공식 사이트는 Windows 계산기의 200 + 10%가 왜 220인지 조사한 사례를 소개한다. 역할을 나누면 다음과 같다.

REA와 분석 엔진: 퍼센트 처리 함수의 명령·의사 코드·호출 관계를 제공한다.
AI 에이전트: 연산자에 따른 분기를 해석하고 10% of 200 = 20이라는 계산 규칙을 설명한다.
검증: 복원한 규칙을 원본 코드·테스트나 실제 동작과 비교한다.

이는 공식 사례의 요약이며 이 글에서 계산기를 직접 분석한 결과는 아니다. 핵심은 기계어 분석 기술이 갑자기 생겼다는 것이 아니라, 분석 도구의 결과를 바탕으로 에이전트가 탐색과 설명을 이어갈 수 있다는 점이다. AI 보조 분석 자체가 REA에만 있는 기능이라는 뜻도 아니다.

도구 연결이 분석의 정확성을 보장하지는 않는다

REA를 사용해도 디컴파일러의 한계, 난독화, 간접 호출, 실행 환경 차이는 남는다. 여기에 AI가 잘못 해석할 가능성도 추가된다. 따라서 결과를 받을 때 다음 세 가지를 나눠 보는 것이 좋다.

관찰: 어떤 파일·함수·명령·실행에서 직접 확인했는가?
추론: 그 근거로 어떤 동작을 예상하는가?
미확인: 아직 추적하지 못한 호출이나 실행 조건은 무엇인가?

또한 정적 분석 요청과 앱 실행·수정 요청은 구분해야 한다. AI가 도구를 사용할 수 있다고 해서 임의의 앱을 실행하거나 외부로 요청을 보내도 된다는 뜻은 아니다. 분석할 대상과 허용할 실행 범위를 먼저 정한다.

처음에는 무엇을 선택하면 좋을까

처음부터 도구를 모두 설치할 필요는 없다. 작은 대상 하나와 질문 하나를 정하는 편이 분석 결과를 이해하고 검증하기 좋다.

궁금한 대상	첫 출발점	시작 질문 예시
직접 빌드한 작은 네이티브 프로그램	Ghidra	이 조건문은 어떤 분기로 바뀌었을까?
자신이 만든 Android·.NET 앱	JADX 또는 ILSpy	이 입력 검사가 배포 결과물에서는 어떻게 보일까?
직접 만든 웹 페이지	Chrome DevTools	이 버튼은 어떤 함수와 요청을 실행할까?

REA가 궁금하다면 이런 좁은 질문을 코딩 에이전트에 맡겨 보고, 반환된 코드와 실제 동작을 대조하면 된다. 도구 조작 부담이 줄어드는지와 함께, 답변의 근거를 자신이 다시 확인할 수 있는지를 살펴보는 것이 좋다.

실행 파일의 형식과 소스 코드가 기계어가 되는 과정부터 알고 싶다면 프로그램 실행 로드맵과 컴파일러·오브젝트·링커를 먼저 읽어도 좋다.

역공학의 중심은 도구 이름이 아니라 결과물에서 질문의 답을 찾고, 추론을 증거로 확인하는 과정이다. Ghidra·IDA·Frida는 서로 다른 방식으로 그 증거를 찾게 해주고, REA는 그 과정에 AI 에이전트가 참여하도록 연결한다.

참고 자료

developer-tools, 역공학