라떼군 이야기
AI에게 40MB 바이너리 속 백도어를 찾아보라고 시켰더니... 결과는?
TL;DR 연구팀이 소스 코드 없이 컴파일된 바이너리만 주고 AI에게 백도어를 찾게 한 결과, 최고 성능 모델인 Claude Opus 4.6이 약 49%의 탐지율을 보였습니다. 하지만 뻔한 악성 코드를 정상 기능으로 합리화하거나, 멀쩡한 파일에서 백도어를 찾았다고 우기는 높은 오탐률(False Positive) 때문에 아직 실무 도입은 시기상조임이 밝혀졌습니다.
최근 XZ Utils 백도어 사태처럼 오픈소스 공급망 공격이 증가하면서, 소스 코드가 아닌 ‘바이너리’ 자체를 분석해야 할 필요성이 커지고 있습니다. 하지만 리버스 엔지니어링은 고도의 전문성이 필요한 영역입니다. 과연 최신 LLM과 오픈소스 도구(Ghidra 등)를 결합하면, 인간 전문가 없이도 숨겨진 악성 코드를 찾아낼 수 있을까요? 이 글은 그 가능성과 한계를 냉정하게 실험한 벤치마크 결과를 다룹니다.
핵심 내용
연구팀은 lighttpd, dnsmasq 등 유명 오픈소스 프로젝트에 인위적인 백도어를 심고, 소스 코드 없이 바이너리만 AI에게 제공했습니다. Claude Opus 4.6은 일부 사례에서 라이브러리 임포트(popen)를 추적해 백도어를 찾아내는 데 성공했습니다. 그러나 충격적인 실패 사례도 있었습니다. 뻔히 보이는 /bin/sh 실행 코드를 보고도 ‘정상적인 DHCP 스크립트 실행 기능일 것’이라며 스스로 합리화해버린 것입니다. 또한, 백도어가 없는 깨끗한 바이너리에서도 28%의 확률로 ‘악성 코드를 찾았다’고 잘못 보고하는 등 신뢰성 문제가 심각했습니다.
기술적 인사이트
이 실험은 LLM이 ‘코드의 문법’은 이해하지만 ‘맥락과 의도’를 파악하는 데는 여전히 취약하다는 점을 시사합니다. 소스 코드는 추상화가 잘 되어 있어 LLM이 이해하기 쉽지만, 컴파일된 어셈블리나 디컴파일된 C 코드는 변수명과 구조가 소실되어 AI가 맥락을 잃기 쉽습니다. 특히 AI가 악성 코드를 보고도 ‘이건 정상 기능일 거야’라고 합리화(Rationalization)하는 현상은 보안 감사 도구로서 치명적입니다. 또한, AI 자체의 지능뿐만 아니라 입력으로 들어가는 디컴파일러(Ghidra, Radare2)의 품질이 결과에 결정적인 영향을 미친다는 점도 기술적으로 중요한 포인트입니다.
시사점
현재로서는 AI를 단독 보안 감사관으로 쓰기엔 위험 부담이 큽니다. 높은 오탐률은 보안 팀의 피로도(Alert Fatigue)만 높일 뿐입니다. 하지만 AI가 리버스 엔지니어링의 진입 장벽을 낮추고, 초동 분석이나 특정 함수의 기능을 설명하는 ‘보조 도구(Copilot)‘로서의 잠재력은 확인되었습니다. 개발자 입장에서는 ‘코드를 컴파일했으니 안전하겠지’라는 ‘보안을 통한 은폐(Security through obscurity)‘가 앞으로 더욱 통하지 않게 될 것임을 인지해야 합니다.
AI는 49%의 확률로 백도어를 찾았지만, 동시에 수많은 허위 보고를 쏟아냈습니다. 과연 모델의 추론 능력이 향상되고 디컴파일 도구가 발전하면 이 간극이 메워질까요? 아니면 인간의 직관적인 ‘의심’은 AI가 영원히 모방할 수 없는 영역일까요? 보안 자동화의 미래를 엿볼 수 있는 흥미로운 실험입니다.