마치 **거대한 도서관 **(소프트웨어 코드)에서 **불이 난 곳 **(보안 취약점)을 찾아서 고치는 작업을 상상해 보세요. 최근에는 AI(거대 언어 모델, LLM) 가 이 일을 대신할 수 있다고 하지만, AI 를 어떻게 배치하느냐에 따라 결과가 천차만별입니다.
저자들은 네 가지 다른 **'수리 팀 구성 방식 **(아키텍처)을 실험해 보았고, 그 결과를 재미있는 비유로 설명해 드리겠습니다.
🏗️ 네 가지 수리 팀의 구성 방식
연구진은 AI 를 어떻게 팀으로 꾸릴지 네 가지 방식을 비교했습니다.
1. 고정된 조립 라인 (Fixed Workflow)
비유: 공장 컨베이어 벨트
어떻게 작동하나요?
"먼저 문제를 찾고 → 그다음 고치고 → 다시 확인해"라는 엄격한 순서대로만 움직입니다.
AI 는 스스로 "아, 이 방법은 안 되네. 다른 방법을 써야지!"라고 생각할 수 없습니다. 오직 정해진 명령만 따릅니다.
장점: 빠르고 비용이 적게 듭니다.
단점: 예상치 못한 복잡한 문제가 생기면 바로 멈춰버립니다. (유연성이 부족함)
2. 혼자 일하는 전문가 (Single-Agent System)
비유: 유능한 프리랜서 기술자
어떻게 작동하나요?
AI 한 명이 모든 일을 합니다. "문제를 찾아보고, 도구를 꺼내서 고치고, 다시 테스트해"라고 스스로 계획을 세웁니다.
실패하면 "왜 실패했지? 다시 생각해 봐야겠다"라고 스스로 반성하고 다음 행동을 결정합니다.
장점: 유연하면서도 비용과 효율의 균형이 좋습니다.
단점: 너무 복잡한 문제 앞에서는 혼란스러워할 수 있습니다.
3. 팀워크를 중시하는 다중 에이전트 (Multi-Agent System)
비유: 전문가들로 구성된 대형 건설 팀
어떻게 작동하나요?
한 명에게 모든 일을 시키지 않고, 역할을 나눕니다.
A 는 "문제가 어디 있는지 찾는 탐정"
B 는 "해결책을 제안하는 기획자"
C 는 "실제로 고치는 기술자"
D 는 "다시 한번 점검하는 감시자"
서로 대화하며 문제를 해결합니다.
장점: 복잡한 문제를 잘 해결하고 일반화 능력이 뛰어납니다.
단점: 비용이 매우 비싸고 느립니다. 팀원들이 서로 말다툼을 하거나 (의사소통 오버헤드), 같은 문제를 두고 계속 논쟁할 수도 있습니다.
4. 만능 개발자 코파일럿 (General-Purpose Code Agent)
비유: 실제 인간 개발자처럼 행동하는 AI
어떻게 작동하나요?
이 AI 는 "수리"라는 특정 임무만 하는 게 아니라, 어떤 프로젝트든 스스로 탐험할 수 있습니다.
"이건 뭐지? 파일 열어볼까? 실행해볼까? 에러가 나네? 다시 써볼까?"라고 개발자처럼 자연스럽게 코드를 훑고 수정합니다.
장점: 가장 잘 고칩니다! 특히 거대하고 복잡한 프로젝트일수록 인간 개발자처럼 유연하게 대처해서 성공률이 가장 높았습니다.
단점: **비용 **(토큰 사용량)이 가장 많이 듭니다.
🏆 연구 결과: 누가 이겼을까?
놀랍게도, **가장 잘 고친 팀은 '만능 개발자 코파일럿 **(General Code Agent)이었습니다.
왜 그랬을까?
다른 팀들은 "수리"라는 특정 규칙에 갇혀 있었지만, 만능 AI 는 상황에 따라 유연하게 대처할 수 있었기 때문입니다. 마치 정해진 메뉴만 나오는 식당 (고정 라인) 보다, 주문대로 요리를 해주는 셰프 (만능 개발자) 가 더 맛있는 요리를 만드는 것과 같습니다.
하지만 비용 문제!
만능 AI 가 가장 잘 고치지만, **전기세 **(비용)를 가장 많이 먹습니다. 반면, 고정된 조립 라인이나 혼자 일하는 기술자는 비용은 적게 들지만, 아주 복잡한 문제 앞에서는 실패할 확률이 높습니다.
💡 결론: 중요한 것은 '모델'이 아니라 '팀 구성'입니다
이 논문의 핵심 메시지는 다음과 같습니다.
"AI 가 똑똑한지 여부보다, 그 AI 를 어떻게 팀으로 꾸리느냐가 성공을 결정한다."
빠르고 싸게 해결하고 싶다면: 고정 라인이나 혼자 일하는 전문가가 좋습니다.
복잡하고 어려운 문제를 완벽하게 해결하고 싶다면: **비용을 더 들이더라도 만능 개발자 **(General Agent)가 가장 좋습니다.
**팀워크 **(다중 에이전트)는 비용 대비 효과가 떨어질 수 있어, 잘 설계된 '혼자 일하는 전문가'보다 나을 때가 많지 않았습니다.
이 연구는 앞으로 소프트웨어 보안을 자동화할 때, 단순히 "더 똑똑한 AI"를 찾는 것보다 "어떤 구조로 AI 를 배치할지"를 고민하는 것이 더 중요하다는 것을 보여줍니다.
1. 연구 배경 및 문제 정의 (Problem)
배경: Log4Shell, MongoBleed 등 현대 소프트웨어 생태계에서 단일 취약점이 대규모 시스템에 연쇄적으로 영향을 미칠 수 있습니다. 취약점 탐지는 자동화되고 있지만, **패치 생성 (수정)**은 여전히 병목 현상입니다. 패치는 프로그램의 의미를 유지하면서 취약점을 제거하고 대규모 코드베이스에 통합되어야 하므로 깊은 의미 추론과 정밀한 검증이 필요합니다.
문제: 최근 LLM 기반의 자동 패칭 시스템 (예: AIxCC 의 파이널리스트 팀, CodeMender 등) 이 등장했으나, 어떤 아키텍처 통합 전략이 수리 효율성, 효율성, 견고성에 가장 효과적인지에 대한 체계적인 비교 연구는 부재했습니다. 기존 연구들은 대부분 아키텍처를 단순한 구현 세부사항으로 취급하거나, 상용 시스템의 블랙박스 특성상 설계 결정 사항을 명확히 분석하지 못했습니다.
2. 방법론 (Methodology)
저자는 DARPA AI Cyber Challenge (AIxCC) 의 델타 스캔 (delta-scan) Java 취약점 데이터셋 (19 개 취약점, 6 개 대규모 프로젝트 포함) 을 기반으로 4 가지 LLM 기반 패칭 아키텍처를 통제된 환경에서 비교 평가했습니다.
4 가지 아키텍처 패러다임
고정 워크플로우 (Fixed Workflow):
정적 분석 → 패치 생성 → 편집 → 검증 → 피드백의 결정론적이고 규칙 기반의 파이프라인을 따릅니다.
동적 계획이 없으며, 실패 시 동일한 워크플로우를 반복합니다.
투명하고 디버깅이 쉽지만, 유연성이 부족합니다.
싱글 에이전트 시스템 (Single-Agent System):
하나의 LLM 에이전트가 자율적으로 계획, 도구 호출 (검색, 편집, 검증), 그리고 피드백 루프를 수행합니다.
고정 워크플로우의 단계가 명시적 도구 호출로 대체되며, 모델이 실패 신호를 받아 다음 행동을 동적으로 결정합니다.
공유 상태 (Shared State) 를 통해 에이전트 간 협업하며, 복잡한 작업에서 전문성을 극대화합니다.
하지만 에이전트 간 조정 오버헤드와 '추론 드리프트 (reasoning drift)' 위험이 있습니다.
범용 코드 에이전트 (General-Purpose Code Agents):
Claude Code와 같은 범용 코딩 도우미를 사용합니다.
특정 패칭 작업에 국한되지 않고, 프로젝트 전체를 탐색하고, 동적 계획을 수립하며, 다양한 도구를 유연하게 사용합니다.
개발자처럼 행동하며 적응력이 높습니다.
평가 모델: GPT-5 와 Claude Sonnet-4.5 를 사용하여 위 아키텍처들을 평가했습니다.
3. 주요 기여 (Key Contributions)
아키텍처 수준의 분류 체계 정립: LLM 기반 취약점 패칭을 위한 4 가지 아키텍처 패러다임을 식별하고, 이를 통일된 실험 환경에서 재구현하여 체계적으로 평가한 최초의 연구입니다.
통합 평가 프레임워크: AIxCC 벤치마크를 사용하여 4 가지 아키텍처를 동일한 조건에서 비교했습니다.
시스템 행동 및 비용 분석: 토큰 사용량, 실행 시간, 도구 사용 패턴, 에이전트 상호작용 로그를 심층 분석하여 각 아키텍처의 장단점을 규명했습니다.
4. 주요 결과 (Results)
4.1 패치 정확도 (Patch Correctness)
범용 코드 에이전트 (Claude Code) 의 우위: 전체적인 패칭 성능과 견고성 (특히 대규모 코드베이스에서) 에서 가장 높은 성과를 보였습니다. (19 개 중 16 개 성공)
전용 에이전트와의 비교: 가장 잘 수행된 전용 멀티 에이전트 시스템 (GPT-5 기반) 은 13/19 를 성공시켰습니다. 범용 에이전트가 더 높은 성능을 보였으나, 토큰 비용은 훨씬 더 높았습니다.
상호 보완적 관계: 범용 에이전트가 실패한 일부 사례 (예: ZooKeeper 의 무한 루프 취약점) 는 전용 멀티 에이전트 시스템이 성공적으로 수정했습니다. 이는 특정 아키텍처가 특정 취약점 유형에 더 효과적일 수 있음을 시사합니다.
4.2 시스템 행동 및 비용 분석
멀티 에이전트의 오버헤드: 멀티 에이전트 시스템은 단순한 작업에서는 효율적이지만, 복잡한 작업에서는 **반복적인 추론 (Root-Cause → Patch → Reflection)**으로 인해 토큰 사용량과 실행 시간이 급증합니다. 에이전트 간의 조정 오버헤드가 전문성의 이점을 상쇄할 수 있습니다.
싱글 에이전트의 효율성: 단일 에이전트는 유연성과 비용 사이의 균형을 잘 맞추며, 토큰 효율성이 높고 실행 속도가 빠릅니다.
고정 워크플로우의 한계: 가장 적은 토큰을 사용하지만, 취약점 유형이 복잡해지거나 검색 범위가 넓어지면 **취약한 검색 행동 (brittle search behavior)**으로 인해 실패율이 높아집니다.
범용 에이전트의 특징: Claude Code 는 높은 토큰 소비를 감수하더라도 무한 루프나 장기 실패에 대한 견고성이 뛰어났습니다.
5. 의의 및 결론 (Significance & Conclusion)
아키텍처 설계의 중요성: LLM 의 모델 능력 자체보다는 추론, 제어, 도구 사용이 어떻게 아키텍처화되는지가 자동화된 패칭의 신뢰성과 비용을 결정하는 핵심 요소임을 증명했습니다.
트레이드오프의 명확화:
범용 에이전트: 높은 성능과 견고성 ↔ 높은 비용.
전용 에이전트 (싱글/멀티): 비용 효율성과 제어 가능성 ↔ 특정 복잡한 작업에서의 성능 한계.
향후 방향: 단일 아키텍처가 모든 상황에서 우월하지는 않으므로, 범용 에이전트의 적응력과 전용 에이전트의 효율성을 결합한 하이브리드 접근법이나, 작업 유형에 따른 아키텍처 선택 전략이 필요함을 시사합니다.
이 연구는 자동화된 소프트웨어 보안 수리 시스템 설계 시 모델 선택뿐만 아니라 **시스템 아키텍처를 최우선 설계 변수 (first-class design variable)**로 고려해야 함을 강조합니다.