당신의 AI Agent가 CTF 문제를 못 푸는 이유: 리버싱 편# 당신의 AI Agent가 CTF 문제를 못 푸는 이유 - 리버싱 편 AI Agent는 이제 CTF 전반에서 상위권 경쟁에 없어서는 안되는 필수 도구입니다. 예전 같으면 사람이 며칠씩 붙잡고 있던 문제도, 이제는 Agent에게 던져두고 사실상 `딸깍`으로 풀 수 있습니다. 웹, 포너블, 리버싱, 크립토, 포렌식 어디든 비슷한 장면이 나오고 있습니다. 문제는 Agent가 잘 푸는 문제와 못 푸는 문제가 뚜렷하게 갈린다는 점입니다. 어떤 문제는 Agent가 사람보다 먼저 길을 열고, 어떤 문제는 한참 도구를 돌리고도 마지막 한 단계를 넘지 못합니다. 그리고 이 차이는 특정 분야에만 있는 현상이 아닙니다. 분야마다 모습만 다를 뿐, 분석 결과를 잘못 읽거나, 컨텍스트를 놓치거나, 또는 검증 없이 가설에 매달리는 순간 Agent는 쉽게 흔들립니다. 이 글은 시리즈로, 이러한 차이가 어디서 나오는지 분야별로 살펴봅니다. 첫 번째 글에서는 리버싱을 다룹니다. 2025년부터 2026년 사이에 나온 컨퍼런스 발표, 오픈소스 도구, 논문들을 참고하여 Agent는 리버싱 문제를 어떻게 풀고, 어떤 조건에서 잘 풀며, 어느 지점에서 잘 풀지 못하는지 정리해 보았습니다. ## 목차 - [Agent가 리버싱 문제를 푸는 방식](#agent%EA%B0%80-%EB%A6%AC%EB%B2%84%EC%8B%B1-%EB%AC%B8%EC%A0%9C%EB%A5%BC-%ED%91%B8%EB%8A%94-%EB%B0%A9%EC%8B%9D) - [Agent가 잘 푸는 문제](#agent%EA%B0%80-%EC%9E%98-%ED%91%B8%EB%8A%94-%EB%AC%B8%EC%A0%9C) - [분석 결과를 잘못 믿는 경우](#%EB%B6%84%EC%84%9D-%EA%B2%B0%EA%B3%BC%EB%A5%BC-%EC%9E%98%EB%AA%BB-%EB%AF%BF%EB%8A%94-%EA%B2%BD%EC%9A%B0) - [컨텍스트 손실](#%EC%BB%A8%ED%85%8D%EC%8A%A4%ED%8A%B8-%EC%86%90%EC%8B%A4) - [설명은 맞는데 정답은 못 찾는 경우](#%EC%84%A4%EB%AA%85%EC%9D%80-%EB%A7%9E%EB%8A%94%EB%8D%B0-%EC%A0%95%EB%8B%B5%EC%9D%80-%EB%AA%BB-%EC%B0%BE%EB%8A%94-%EA%B2%BD%EC%9A%B0) - [잘못된 가설을 버리지 못하는 경우](#%EC%9E%98%EB%AA%BB%EB%90%9C-%EA%B0%80%EC%84%A4%EC%9D%84-%EB%B2%84%EB%A6%AC%EC%A7%80-%EB%AA%BB%ED%95%98%EB%8A%94-%EA%B2%BD%EC%9A%B0) - [디컴파일 결과는 정답이 아니다](#%EB%94%94%EC%BB%B4%ED%8C%8C%EC%9D%BC-%EA%B2%B0%EA%B3%BC%EB%8A%94-%EC%A0%95%EB%8B%B5%EC%9D%B4-%EC%95%84%EB%8B%88%EB%8B%A4) - [이를 보완하는 연구와 도구](#%EC%9D%B4%EB%A5%BC-%EB%B3%B4%EC%99%84%ED%95%98%EB%8A%94-%EC%97%B0%EA%B5%AC%EC%99%80-%EB%8F%84%EA%B5%AC) - [성공/실패 조건 정리](#%EC%84%B1%EA%B3%B5%EC%8B%A4%ED%8C%A8-%EC%A1%B0%EA%B1%B4-%EC%A0%95%EB%A6%AC) - [참고한 글과 자료](#%EC%B0%B8%EA%B3%A0%ED%95%9C-%EA%B8%80%EA%B3%BC-%EC%9E%90%EB%A3%8C) ## Agent가 리버싱 문제를 푸는 방식 Agent의 기본 전략은 사람 리버서가 밟는 분석 과정을 빠르게 반복하는 것입니다. 먼저 파일 형식과 보호 기법을 확인하고, `strings`, `readelf`, `objdump`, `radare2`, `Ghidra`, `IDA` 같은 도구로 정적 분석 결과를 모읍니다. 필요하면 GDB 또는 trace 도구도 붙입니다. 그리고 의심스러운 함수나 문자열을 기준으로 가설을 세운 뒤, Python solver나 keygen을 만들어 실제 바이너리에 넣어봅니다. CrackMeBench의 평가 기준을 보면, Agent 리버싱에서는 설명보다 실제 결과물이 중요하다는 것을 알 수 있습니다 \[2\]. Agent의 강점은 분석 방향이 아니라 속도와 반복입니다. 사람이라면 디컴파일 결과를 읽고 solver를 한 번 짜본 뒤, 안 되면 잠깐 멈출 수 있습니다. 하지만 Agent는 입력값을 바꿔가며 수십 번을 지치지 않고 돌립니다. 그리고 스크립트 작성 속도도 빠릅니다. CREBench 평가에 따르면 모델은 표준 암호 구현에서 자주 나오는 패턴을 비교적 잘 찾아냅니다 \[13\]. CTF 리버싱도 비슷합니다. 상수 비교, 단순 인코딩, 문자열 변형, 평범한 keygen, 잘 알려진 crypto 패턴처럼 정적 분석에서 검증 루틴이 잘 드러나는 문제는 Agent가 빠르게 풉니다. > **CrackMeBench**는 자유로운 설명 대신 프로그램이 받아들이는 input이나 serial, artifact 또는 keygen을 외부에서 채점하는 리버싱 특화 벤치마크입니다. symbol 정보가 거의 없는 바이너리와 표준 리버싱 도구만 제공하며, Agent는 네트워크가 차단된 Linux Docker에서 문제를 풉니다 \[2\]. > **CREBench**는 48개 표준 암호 알고리즘과 취약한 key 사용 방식 3종을 바탕으로 난이도가 다른 432개 문제를 구성한 벤치마크입니다. 평가는 알고리즘 식별부터 실제 flag 복구까지 네 단계로 나눠 평가합니다. \[13\]. 두 벤치마크에서 공통으로 드러나는 점은 상수 비교·단순 인코딩·문자열 변형·잘 알려진 crypto 패턴처럼 정적 분석에서 검증 루틴이 바로 드러나는 문제를 Agent가 빠르게 풀어낸다는 것입니다. 하지만 정답과 관련된 값이 런타임에만 만들어지거나 여러 함수와 메모리 영역에 흩어져 있다면 이야기가 달라집니다. 디컴파일 결과까지 부정확한 상황에서는 단순히 시도 횟수를 늘리는 것만으로 풀기 어렵습니다. ## Agent가 잘 푸는 문제 앞에서 본 연구 결과를 종합하면, Agent는 정적 분석 결과가 실제 동작과 크게 다르지 않고, 필요한 컨텍스트가 짧으며, 답을 바로 검증할 수 있는 문제에 강하다고 볼 수 있습니다 \[1\], \[2\], \[5\]. 먼저 정적 분석으로 관찰한 코드와 실제 실행 경로가 크게 다르지 않아야 합니다. 문자열이나 상수, 또는 비교 루틴이 어느 정도 남아 있다면 Agent는 빠르게 실마리를 잡습니다. 반대로 검증 로직이나 특징적인 상수를 런타임에 복원하도록 숨기면 모델의 성능이 떨어진다는 결과가 보고되었습니다 \[1\], \[13\]. 그리고 `strings`에서 눈에 띄는 문구가 나오고 디컴파일러가 검증 함수를 어느 정도 복원해준다면 분석을 시작할 지점도 명확해집니다. 검증 로직이 한두 개 함수에 모여 있거나 caller/callee 관계가 단순한 문제도 상대적으로 유리합니다. 실제 연구에서도 긴 분석 과정에서 이전 증거를 놓치는 context limitation이 Agent의 주요 실패 원인으로 나타났습니다. 그리고 call graph와 variable data flow를 함께 제공하는 방식은 바이너리 분석 성능을 개선했습니다 \[1\], \[5\]. 알려진 알고리즘 또는 하나의 분명한 목적을 가진 함수를 분석할 때 LLM 지원이 더 효과적이었다는 사용자 연구 결과도 같은 경향을 보여줍니다 \[10\]. 후보 입력을 바이너리에 바로 넣어볼 수 있는지도 중요합니다. CrackMeBench는 executable oracle을 통해 password나 artifact, 또는 keygen을 실제 프로그램으로 검증합니다. 그리고 복구한 값을 작은 검증 스크립트로 빠르게 전환한 Agent가 더 좋은 성과를 보였습니다 \[2\]. solver 결과를 즉시 확인할 수 있으면 틀린 답을 빨리 버리고 다음 후보로 넘어갈 수 있습니다. 반대로 관찰한 코드가 실제 실행 경로와 다르거나, 필요한 값이 여러 함수와 메모리 영역에 흩어져 있거나, 중간 결과를 검증하기 어렵다면 성능이 떨어집니다 \[1\], \[13\]. 이 결과를 CTF에 적용하면, 이런 문제에서는 코드 한 부분을 설명하는 능력보다 서로 다른 분석 결과를 연결하고 가설을 계속 검증하는 능력이 더 중요하다고 볼 수 있습니다. ## 분석 결과를 잘못 믿는 경우 바이너리에서 실제로 실행되는 코드가 디스크에 그대로 있으리라는 보장은 없습니다. anti-debugging 때문에 디버거를 붙이는 순간 동작이 바뀔 수도 있습니다. 그리고 문자열과 검증 로직을 런타임에 복호화하는 바이너리라면 정적 분석 결과만 보고 시작한 Agent는 처음부터 엉뚱한 코드를 분석하게 됩니다. Towards LLM-Resistant Software Protection은 Agent의 작업을 Observe-Comprehend-Plan, 즉 분석 대상을 확인하고 의미를 파악한 뒤 다음 행동을 계획하는 단계로 나눕니다. concealment는 그중 첫 단계인 Observe부터 방해합니다 \[1\]. > **Towards LLM-Resistant Software Protection**은 2025년 CTF에서 고른 24개 리버싱 문제를 세 LLM Agent에게 풀게 한 뒤 실패 로그를 분석한 연구입니다. 보호 기법도 정보를 숨기는 concealment, 구조를 복잡하게 만드는 complication, 거짓 단서로 유도하는 misdirection으로 나눕니다 \[1\]. 첫 단계에서 잘못된 정보를 얻으면 이후 추론도 연달아 틀어집니다. 코드가 숨겨져 있거나 런타임 상태를 확인하지 못한 채 분석을 이어가면, 뒤에서 아무리 그럴듯한 계획을 세워도 정답에 도달하기 어렵습니다. 따라서 도구가 보여준 결과를 곧바로 사실로 받아들이면 안 됩니다. 사람 리버서라면 이런 상황에서 먼저 "지금 보고 있는 코드가 실제 실행 경로가 맞나?"라고 의심합니다. 반면 Agent는 디컴파일된 함수가 그럴듯해 보이면 실제로 호출되는 함수인지 확인하기 전에 코드의 의미부터 해석하려는 경향이 있습니다. Clue-Driven Reverse Engineering에서는 전체 코드를 한꺼번에 요약시키는 대신 분석에 중요한 단서부터 찾게 합니다 \[8\]. 그리고 Celebi-POC도 이 방식을 실제 악성코드 분석 과정에 적용합니다 \[9\]. CTF 리버싱 Agent에도 비슷한 접근이 필요합니다. 단순히 더 긴 컨텍스트를 넣는 것으로는 부족합니다. 도구로 확인한 사실, 아직 검증하지 않은 추정, 그리고 추가로 확인할 단서를 구분해 기록해야 잘못된 분석 결과에 끌려가지 않습니다. > **Clue-Driven Reverse Engineering**은 함수명, API 호출, 문자열처럼 가치가 높은 단서를 먼저 추출하고, planning·rewriting·evaluation을 거쳐 분석 결과를 검증하는 흐름을 제안한 연구입니다 \[8\], \[9\]. > **Celebi-POC**는 전체 Celebi 시스템 중 evaluation 단계를 공개한 PoC입니다. `Ref Check`는 이름 제안 시 모델이 실제 단서를 보고 있는지 attention head를 분석하고, `Lie Detector`는 token 생성 확률에서 불확실성이 큰 답을 찾습니다 \[9\]. ## 컨텍스트 손실 LLM은 함수 하나의 의사코드를 설명하는 데는 꽤 강합니다. 하지만 실제 문제에서는 정답에 필요한 로직이 여러 함수에 나뉘어 있는 경우가 많습니다. 예를 들어 입력은 `main`에서 받지만 길이 검사는 helper 함수에서 처리합니다. 그리고 키는 전역 초기화 루틴에서 조합하고, 최종 비교는 VM bytecode interpreter 안에서 할 수 있습니다. 암호 문제라면 상수 테이블과 key schedule, IV, padding, 그리고 출력 인코딩이 서로 다른 함수와 메모리 영역에 나뉘어 있기도 합니다. ReCopilot은 관련 컨텍스트를 구조화하기 위해 call graph와 variable data flow를 활용합니다 \[5\]. call graph는 함수 사이의 호출 관계를, variable data flow는 값이 함수와 변수 사이에서 어떻게 이동하는지를 보여줍니다. 함수 이름 복원 또는 변수 타입 추정은 독립된 작업처럼 보이지만, 실제 결과는 주변 호출 관계와 데이터 흐름을 얼마나 정확히 함께 제공하느냐에 따라 달라집니다. 그리고 Kong은 작은 함수부터 분석한 뒤 그 결과를 쌓아 전체 프로그램으로 범위를 넓히는 bottom-up 방식으로 컨텍스트 손실을 줄입니다 \[12\]. > **ReCopilot**은 범용 LLM에 prompt만 붙인 도구가 아니라 추가 사전학습(CPT), 지도 미세조정(SFT), 선호 최적화(DPO)를 거쳐 학습한 바이너리 분석 특화 모델입니다. 함수명 복원과 변수 타입 추론 평가에서 기존 도구와 LLM보다 13% 높은 성능을 보고했습니다 \[5\]. > **Kong**은 복원한 함수명, 타입, signature를 Ghidra 프로그램 DB에 반영하고 최종 분석 결과를 내보내는 리버싱 Agent입니다 \[12\]. 함수별 요약을 쌓았다면 서로 연결해야 합니다. "이 함수는 입력을 검증하는 것 같다"는 설명만으로는 부족합니다. call graph와 xref, string reference, global state, 그리고 runtime trace를 함께 확인해 "`argv[1]`의 특정 바이트를 전역 테이블과 비교하며, 이 테이블은 init 루틴에서 XOR로 복호화된다"는 전체 흐름까지 찾아야 합니다. 결국 함수 하나를 정확히 설명했더라도 전체 검증 로직을 연결하지 못하면 flag는 나오지 않습니다. ## 설명은 맞는데 정답은 못 찾는 경우 리버싱에서 LLM은 "XOR 기반 검증으로 보입니다", "AES와 유사한 구조입니다", 또는 "입력 문자열을 변형해 비교합니다" 같은 설명을 곧잘 만듭니다. 분석 내용 자체는 맞을 수도 있지만 CTF에서 제출해야 하는 것은 설명이 아니라 flag입니다. CrackMeBench처럼 실제 결과물을 요구하는 평가에서는 이 차이가 뚜렷하게 드러납니다. Agent는 바이너리만 보고 프로그램이 받아들이는 password나 artifact, 또는 keygen을 만들어야 합니다 \[2\]. 특히 keygen은 주어진 입력에 맞는 키를 생성해야 하므로 예시 하나를 맞히는 것보다 어렵습니다. 그리고 숨겨진 사용자 이름으로도 검증하기 때문에 특정 값만 하드코딩해서는 통과할 수 없습니다. CREBench의 암호 바이너리 평가도 "AES처럼 보인다"고 알아맞히는 능력과 실제 flag를 복구하는 능력을 따로 봅니다 \[13\]. S-box나 라운드 상수처럼 익숙한 패턴이 보이면 모델은 알고리즘 이름을 잘 맞힙니다. 그러나 상수가 XOR로 숨겨져 있거나 key가 여러 조각으로 나뉘어 있고, 여기에 PRNG state까지 추적해야 한다면 복구 성공률은 크게 떨어집니다. 그래서 리버싱 Agent의 결과는 항상 실행해서 확인할 수 있어야 합니다. 후보 입력을 실제 바이너리에 넣고, solver 또는 keygen은 여러 테스트 케이스로 돌려봐야 합니다. 그리고 runtime trace가 세운 가설과 일치하는지도 확인해야 합니다. ## 잘못된 가설을 버리지 못하는 경우 Agent가 명령을 계속 실행한다고 해서 분석이 진전되고 있는 것은 아닙니다. 처음 세운 가설이 틀렸는데도 그 주변에서 비슷한 명령만 반복하거나 같은 결과를 표현만 바꿔 다시 해석하는 경우가 있습니다. Towards 논문은 이런 실패를 training bias, over-trust in observations, context limitation, plan persistence로 나눠 분석합니다 \[1\]. 익숙한 패턴에 지나치게 끌리거나 도구의 출력을 과신합니다. 그리고 긴 분석 과정에서 이전 컨텍스트를 놓치거나 이미 실패한 계획을 계속 고수합니다. CREBench에서도 모델이 처음 떠올린 암호 알고리즘 또는 검증 방식을 지나치게 오래 고수하는 모습이 나타났습니다 \[13\]. Agent가 한 번 "이건 AES다"라고 판단하면 AES가 아니라는 증거보다 그 가설에 맞는 증거를 계속 찾습니다. 그리고 초기 판단이 틀리면 뒤의 분석도 전부 그쪽으로 끌려갑니다. GDB 명령은 계속 실행하지만 새로운 가설로 넘어가지 못하는 상황이라면 도구 사용법보다 분석을 중단하고 방향을 바꾸는 기준이 없는 것이 문제입니다. Failing to Falsify의 평가에서도 LLM은 현재 가설을 반박하거나 대안을 찾기보다 뒷받침하려는 모습을 보입니다 \[11\]. 리버싱에 관한 연구는 아니지만, 이 결과는 리버싱 Agent에도 적용해 볼 수 있습니다. 현재 가설을 깨기 위한 테스트와 중단 조건이 없다면 Agent는 같은 분석을 계속 반복하게 됩니다. > **Failing to Falsify**는 숨겨진 규칙을 맞히기 위해 숫자 세 개의 조합을 제안하고 피드백을 받는 실험으로 11개 LLM을 평가한 연구입니다. 반례를 찾도록 유도하자 평균 규칙 발견률이 42%에서 56%로 높아졌습니다 \[11\]. ## 디컴파일 결과는 정답이 아니다 LLM을 활용하는 리버싱 도구 대부분은 디컴파일러 출력에 크게 의존합니다. 의사코드가 어셈블리보다 모델과 사람 모두에게 읽기 편하기 때문입니다. 하지만 디컴파일 결과는 분석을 위한 참고 자료일 뿐, 원본 코드나 실제 동작을 그대로 보여주는 것은 아닙니다. Towards 논문에서도 디컴파일러에 의존한 분석이 항상 좋은 결과로 이어지지는 않았습니다 \[1\]. 디컴파일 과정에서 잘못된 제어 구조 또는 타입이 만들어질 수 있고, 최적화나 난독화가 적용된 코드에서는 원래 의미가 더 크게 틀어집니다. 이런 경우에는 어셈블리를 직접 보거나 runtime trace와 비교하는 편이 낫습니다. DecLLM은 LLM이 코드를 한 번에 완벽하게 복원할 것이라고 기대하는 대신, 컴파일 오류와 실행 결과를 피드백으로 주고 반복해서 수정합니다 \[6\]. 사람이 보기에는 그럴듯한 의사코드도 실제로 컴파일하거나 실행해보면 틀린 경우가 많기 때문입니다. > **DecLLM**은 디컴파일 결과를 재컴파일 가능한 코드로 복원하는 방법을 제안한 연구입니다. C 벤치마크와 실제 바이너리에서 기존에는 재컴파일할 수 없었던 결과의 약 70%를 복원했으며, 복원한 코드는 CodeQL 기반 취약점 분석에도 사용할 수 있습니다 \[6\]. CTF 리버싱에서도 마찬가지입니다. 디컴파일 결과를 설명하는 데서 끝내지 말고 solver나 emulator, 또는 patch와 keygen처럼 실행 가능한 결과물로 옮겨야 합니다. 그리고 이 결과물이 원본 바이너리의 동작과 일치하는지 확인해야 합니다. ## 이를 보완하는 연구와 도구 최근 연구와 도구는 LLM 하나에 바이너리를 통째로 맡기지 않습니다. RE 도구가 추출한 정보를 구조화해 컨텍스트로 제공하고, Agent가 세운 가설은 다시 도구로 검증하는 방향으로 발전하고 있습니다. R2AI, ida-semray, ReCopilot처럼 기존 리버싱 환경에 LLM을 연결하면 함수 설명과 이름 지정, 그리고 타입 추론 같은 반복 작업을 줄일 수 있습니다 \[3\], \[5\], \[14\]. Rikugan과 Kong은 여기서 한발 더 나아가 Agent가 분석 도구를 직접 호출하고, 다음 분석 순서까지 정합니다 \[4\], \[12\]. R2AI 또는 ida-semray가 분석가의 반복 작업을 줄여준다면, Rikugan과 Kong은 Agent가 분석 과정 자체를 주도합니다. 어느 방식이든 정확한 분석 결과와 충분한 컨텍스트를 제공하고 답을 바로 검증할 수 있을 때 더 안정적으로 동작합니다. > **R2AI**는 radare2 shell 안에서 REPL이나 batch mode, 또는 ReAct mode를 사용할 수 있게 만든 LLM 플러그인입니다. 그리고 Ollama 같은 local model과 상용 API를 모두 연결할 수 있습니다 \[3\]. > **ida-semray**는 분석 범위와 입력 형식을 선택하고 LLM의 제안을 검토한 뒤 IDA에 적용할 수 있게 만든 플러그인입니다. 단일 함수나 전체 함수, 또는 지정한 call depth 범위를 분석할 수 있으며 디컴파일된 C와 raw assembly를 모두 지원합니다 \[14\]. > **Rikugan**은 외부 MCP client 없이 IDA Pro 또는 Binary Ninja 프로세스 안에서 자체 agent loop를 실행하는 리버싱 Agent입니다. 그리고 script 실행 전에는 사용자 허가를 받고 target binary는 직접 실행하지 않는다는 안전 경계를 둡니다 \[4\]. Clue-Driven Reverse Engineering과 Celebi-POC는 먼저 분석할 가치가 있는 함수와 변수를 추려냅니다. 그리고 LLM이 제안한 이름이나 요약이 실제 단서에 근거하는지 확인합니다 \[8\], \[9\]. LLM의 설명을 그대로 받아들이지 않고 출처가 된 분석 결과로 다시 확인하는 방식입니다. Toss의 취약점 분석 자동화 글에서 소개한 후보군 축소와 LLM 입력 통제도 비슷한 문제를 다룹니다 \[7\]. > **Toss의 취약점 분석 자동화 사례**는 ctags·tree-sitter 기반 MCP와 SAST, Discovery Agent, Analysis Agent를 조합해 취약점 분석을 자동화한 실무 사례입니다. SAST는 취약점 판정이 아니라 검토할 입력 경로를 수집하는 용도로 사용합니다 \[7\]. CrackMeBench와 CREBench도 산문 형태의 설명보다 password나 artifact, keygen, 또는 flag 복구처럼 외부에서 검증 가능한 결과를 평가합니다 \[2\], \[13\]. Agent가 문제를 실제로 풀었는지 확인하려면 "설명을 잘했는가"보다 "검증 가능한 답을 냈는가"를 보는 편이 정확합니다. Decompiling the Synergy 연구에서 LLM 지원은 초보자의 프로그램 이해도를 크게 높였지만, 전문가의 전체 성과에는 거의 영향을 주지 않았습니다. 일부 사용자 정의 함수에서는 전문가의 분석 시간이 오히려 늘었고, 잘못된 취약점 제안이 이후 분석을 방해하는 사례도 관찰됐습니다 \[10\]. 이 결과를 Agent 설계에 적용하면, 자율 분석용 Agent에는 외부에서 검증 가능한 결과가, 분석가 보조용 Agent에는 판단 근거와 불확실성을 확인할 수 있는 인터페이스가 필요하다고 볼 수 있습니다. > **Decompiling the Synergy**는 전문가 24명과 초보자 24명이 두 개의 CTF형 문제를 푸는 과정을 전용 디컴파일러 플러그인으로 계측한 연구입니다. 총 6,586분의 분석 과정과 1,517번의 LLM 상호작용을 기록해 숙련도에 따른 차이를 비교했습니다 \[10\]. ## 성공/실패 조건 정리 이제 글을 마무리해 보겠습니다. 앞에서 살펴본 것처럼 AI Agent가 잘 푸는 문제에는 몇 가지 공통점이 있습니다. | 잘 푸는 조건 | 관찰되는 특징 | 왜 잘 맞는가 | | --- | --- | --- | | 신뢰할 수 있는 분석 결과 | 문자열, 상수, 비교 루틴이 정적 분석에서 바로 보입니다 | 정적 분석 결과와 실제 실행 경로가 크게 다르지 않습니다 | | 짧은 컨텍스트 | 검증 로직이 한두 개 함수나 단순한 호출 관계 안에 모여 있습니다 | 함수 요약과 코드 설명만으로도 전체 흐름을 따라갈 수 있습니다 | | 빠른 검증 | 후보 입력이나 solver 결과를 바이너리에 바로 넣어볼 수 있습니다 | 틀린 가설을 빨리 버리고 다음 후보를 반복해서 시험할 수 있습니다 | | 익숙한 패턴 | XOR, base64, 단순 인코딩, 표준 crypto 상수처럼 알려진 구조가 보입니다 | 모델이 학습 중 자주 본 코드 패턴과 문제 풀이 방식이 잘 맞습니다 | | 실행 가능한 결과물 | password, keygen, patch, emulator처럼 검증 가능한 결과물을 만들 수 있습니다 | 설명에서 멈추지 않고 실제 정답 여부를 외부에서 확인할 수 있습니다 | | 분석 컨텍스트 제공 | call graph, data flow, xref, runtime trace가 함께 제공됩니다 | 흩어진 단서를 하나의 검증 흐름으로 묶기 쉬워집니다 | 반대로 정적 분석 결과를 신뢰하기 어렵거나 컨텍스트가 끊기고, 중간 결과를 검증할 수 없다면 같은 자리에서 분석을 반복하기 쉽습니다. | 실패 조건 | 관찰되는 특징 | 필요한 보완 | | --- | --- | --- | | 잘못된 분석 결과 | anti-debugging, packing, 런타임 복호화 때문에 엉뚱한 코드만 분석합니다 | 동적 분석, 메모리 덤프, runtime trace로 정적 분석 결과를 검증해야 합니다 | | 컨텍스트 손실 | 한 함수 설명은 맞지만 입력이 어디서 바뀌고 어디서 비교되는지 끝까지 잇지 못합니다 | 호출 관계, 데이터 흐름, 전역 값, runtime trace를 한 흐름으로 묶어야 합니다 | | 결과물 부재 | 설명은 그럴듯하지만 실제 입력, password, keygen이 없습니다 | 실행 가능한 결과물을 만들고 실제 바이너리로 검증해야 합니다 | | 가설 고착 | 틀린 암호나 검증 방식에 계속 매달립니다 | 반박 검증 루프, 중단 조건, 대안 계획 강제 | | 디컴파일 과신 | 디컴파일 결과를 사실처럼 믿습니다 | 어셈블리와 실행 시점 비교, 컴파일/실행 피드백, 근거 분리 | | 검증 비용 증가 | 사람이 Agent의 설명을 다시 검증하느라 오히려 시간이 더 듭니다 | 확인된 사실, 의심스러운 부분, 재현 명령을 함께 남겨야 합니다 | 전체적으로 정리하면 다음과 같습니다. 어떤 문제는 Agent에게 던져두는 것만으로 쉽게 풀리지만, 어떤 문제는 마지막 입력 하나를 찾지 못한 채 멈춥니다. 그리고 그 차이는 모델의 성능만으로 설명되지 않습니다. 분석 결과를 다시 확인하고, 끊어진 컨텍스트를 이으며, 틀린 가설을 버리는 과정이 없기 때문입니다. 이것이 당신의 AI Agent가 CTF 리버싱 문제를 못 푸는 이유입니다. ## 참고한 글과 자료 \[1\] Ryutaro Nishizaka et al., "Towards LLM-Resistant Software Protection: Agent Failure Patterns in CTF Reverse Engineering": \[2\] Isaac David, Arthur Gervais, "CrackMeBench: Binary Reverse Engineering for Agents": \[3\] radareorg/r2ai: \[4\] buzzer-re/Rikugan: \[5\] Guoqiang Chen et al., "ReCopilot: Reverse Engineering Copilot in Binary Analysis"; XingTuLab/recopilot: , \[6\] "DecLLM: LLM-Augmented Recompilable Decompilation for Enabling Programmatic Use of Decompiled Code", ISSTA 2025, \[7\] Toss Tech Blog, "LLM을 이용한 서비스 취약점 분석 자동화 #2": \[8\] Black Hat USA 2025, "Pay Attention to the Clue: Clue-Driven Reverse Engineering by LLM in Real-World Malware Analysis": \[9\] cycraft-corp/Celebi-POC: \[10\] "Decompiling the Synergy: An Empirical Study of Human-LLM Teaming in Software Reverse Engineering", NDSS 2026, \[11\] "Failing to Falsify: Evaluating and Mitigating Confirmation Bias in Language Models": \[12\] amruth-sn/kong: \[13\] Baicheng Chen et al., "CREBench: Evaluating Large Language Models in Cryptographic Binary Reverse Engineering"; wangyu-ovo/CREBench: , \[14\] 19h/ida-semray: