💻 computer science

Vulnerability Detection with Interprocedural Context in Multiple Languages: Assessing Effectiveness and Cost of Modern LLMs

이 논문은 C, C++, Python 의 509 개 취약점을 대상으로 함수 간 의존성을 포함한 다양한 컨텍스트 수준에서 현대적 LLM 들의 취약점 탐지 효과, 비용 및 설명 품질을 실증적으로 분석하여 AI 기반 보안 도구 설계에 대한 시사점을 제시합니다.

원저자: Kevin Lira, Baldoino Fonseca, Davy Baía, Márcio Ribeiro, Wesley K. G. Assunção

게시일 2026-04-10

📖 4 분 읽기☕ 가벼운 읽기

CC BY 4.0

원저자: Kevin Lira, Baldoino Fonseca, Davy Baía, Márcio Ribeiro, Wesley K. G. Assunção

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

이 논문은 **"인공지능 (LLM) 이 코드의 버그 (취약점) 를 찾을 때, 주변 맥락을 얼마나 알려줘야 가장 잘 찾을까?"**라는 질문에 대한 답을 찾는 실험 결과입니다.

마치 **수사관 (AI) 이 범인 (버그) 을 잡으려고 할 때, 범인이 혼자 있는 방 (단일 함수) 을 보는 것이 좋을까, 아니면 범인이 누구와 대화했는지 (호출자/피호출자) 까지 모두 보여주는 것이 좋을까?**를 비교한 이야기라고 생각하시면 됩니다.

이 연구의 핵심 내용을 쉬운 비유로 설명해 드릴게요.

1. 연구의 배경: "혼자 보는 것" vs "주변까지 보는 것"

과거의 연구들은 AI 에게 **범인이 혼자 있는 방 (단일 함수)**만 보여주고 "여기 범죄가 있었나요?"라고 물었습니다. 하지만 실제 범죄는 종종 **범인과 동행자의 대화 (함수 간 연결)**에서 발생합니다.

비유: 범인이 "나 지금 도망갈 준비 중이야"라고 말하고, 동행자가 "알았어, 문 열어줄게"라고 대답하는 상황입니다.
- 단일 함수 (방만 보기): "도망갈 준비 중"이라는 말만 보고는 "아, 그냥 준비하는 거겠지"라고 넘어갈 수 있습니다.
- 인터프로시저럴 컨텍스트 (주변까지 보기): 동행자의 대화까지 보면 "아, 이건 범죄를 저지르려는 공범 관계구나!"라고 바로 알 수 있습니다.

연구진은 **"주변 맥락 (동행자 대화) 을 더 많이 알려주면 AI 가 버그를 더 잘 찾을까?"**를 확인하기 위해 실험을 했습니다.

2. 실험 방법: 4 명의 탐정과 3 가지 상황

연구진은 Claude Haiku 4.5, GPT-4.1 Mini, GPT-5 Mini, Gemini 3 Flash라는 4 명의 최신 AI 탐정에게 509 개의 실제 버그 사례를 맡겼습니다. 그리고 세 가지 다른 상황을 만들어 테스트했습니다.

상황 A (방만 보기): 범인 (코드) 혼자만 보여줌.
상황 B (동행자 추가): 범인이 누구를 불렀는지 (Callees) 까지 보여줌.
상황 C (상사 추가): 누가 범인을 불렀는지 (Callers) 까지 보여줌.

3. 놀라운 결과: "더 많은 정보는 오히려 방해가 된다?"

일반적인 상식으로는 "정보를 더 많이 주면 AI 가 더 똑똑해지겠지?"라고 생각하기 쉽습니다. 하지만 결과는 정반대였습니다.

GPT 모델 (특히 GPT-4.1 Mini): 주변 정보를 더 많이 주면 혼란스러워졌습니다. 마치 수사관에게 쓸데없는 잡담까지 모두 들려주니, 진짜 단서를 놓치고 엉뚱한 데 집중하게 된 것처럼, 오히려 버그를 찾는 정확도가 25% 까지 떨어졌습니다.
Claude 와 Gemini: 이 두 AI 는 주변 정보를 줘도 안정적이었습니다. 정보량이 변해도 실력 유지가 잘 되었습니다.

핵심 교훈: "더 많은 정보 = 더 좋은 결과"라는 공식은 AI 에 따라 다릅니다. 오히려 불필요한 정보는 AI 를 혼란스럽게 만들어 성능을 떨어뜨릴 수 있습니다.

4. 비용 문제: "더 비싼 정보, 더 낮은 성능"

정보를 더 많이 주면 AI 가 읽어야 할 글자 (토큰) 가 두 배로 늘어납니다. 이는 비용이 두 배로 증가한다는 뜻입니다.

결과: 정보를 두 배로 늘려도 정확도는 오르지 않고, 오히려 떨어지는 경우가 많았습니다.
가성비 왕 (Best Value): Gemini 3 Flash가 가장 훌륭했습니다. 적은 비용으로 거의 완벽한 성능 (F1 점수 0.978 이상) 을 냈습니다.
가장 비싼 모델: Claude Haiku 4.5는 성능도 좋지만, 특히 **버그를 설명하는 능력 (해석력)**이 가장 뛰어났습니다. "여기 버그가 있어요"라고만 말하는 게 아니라, "왜 버그인지, 어떻게 고쳐야 하는지"를 아주 잘 설명해 줍니다.

5. 언어별 차이: C 언어 vs 파이쌐

C/C++ (수동 관리 언어): 메모리 관리가 복잡해서 버그가 숨어있기 쉽습니다. 여기서 GPT 모델들은 주변 정보를 주면 매우 혼란스러워졌습니다.
파이쌐 (자동 관리 언어): 코드가 더 간결해서 AI 가 혼자서도 잘 찾아냈습니다.

6. 결론: AI 를 어떻게 써야 할까?

이 연구는 보안 도구 개발자들에게 다음과 같은 조언을 합니다.

무조건 많은 정보를 주지 마세요: 사용하는 AI 모델에 따라, 오히려 정보량을 줄이는 (단순한 코드만 주는) 것이 더 정확하고 저렴할 수 있습니다.
목적에 따라 AI 를 고르세요:
- 가장 싸고 정확한 것: Gemini 3 Flash (버그를 빠르게 찾아내고 싶을 때).
- 가장 잘 설명하는 것: Claude Haiku 4.5 (왜 버그인지 자세히 설명받고 싶을 때).
- 최저가: GPT-4.1 Mini (하지만 정확도가 떨어질 수 있음).
설명이 곧 실력이다: AI 가 버그를 잘 찾으면, 그 이유도 잘 설명합니다. 반대로 설명이 엉망이면, 버그 찾기도 엉망일 가능성이 높습니다.

요약

이 논문은 **"AI 에게 코드의 버그를 찾을 때, 주변 맥락을 너무 많이 주면 오히려 AI 가 혼란스러워져서 실수가 늘고 비용만 비싸진다"**는 사실을 증명했습니다. 가장 현명한 방법은 사용하려는 AI 모델의 성향과 언어 (C, 파이쌐 등) 에 맞춰 정보의 양을 조절하는 것입니다.

1. 연구 배경 및 문제 제기 (Problem)

기존 연구의 한계: 최근 대규모 언어 모델 (LLM) 을 활용한 자동화된 소프트웨어 취약점 탐지 연구가 활발하지만, 대부분의 기존 연구는 단일 함수 (Single Function) 내의 취약점 탐지에만 초점을 맞추고 있습니다.
인터프로시저 의존성 간과: 실제 취약점 중 상당수는 데이터 흐름이나 제어 흐름이 여러 함수를 가로지르는 인터프로시저 (Interprocedural) 관계에서 발생합니다. (예: 사용 후 해제 (Use-after-free), 버퍼 오버플로우, 인젝션 등) 이러한 취약점은 호출자 (Caller) 와 피호출자 (Callee) 간의 상호작용을 분석해야만 식별 가능합니다.
다중 언어 및 비용/설명성 부족: 기존 연구는 주로 단일 프로그래밍 언어를 대상으로 하며, LLM 사용의 경제적 비용 (추론 비용) 과 생성된 결과의 설명 가능성 (Explainability) 을 체계적으로 평가하지 않았습니다.

2. 연구 방법론 (Methodology)

이 연구는 현대 LLM 들의 인터프로시저 컨텍스트 기반 취약점 탐지 능력, 비용 효율성, 그리고 설명의 질을 실증적으로 평가하기 위해 다음과 같은 설계를 수행했습니다.

데이터셋: ReposVul 데이터셋에서 추출한 509 개의 인터프로시저 취약점 (C, C++, Python 언어 포함) 을 사용했습니다.
평가 대상 모델: 4 가지 현대 LLM 을 비교 평가했습니다.
- Claude Haiku 4.5 (Anthropic)
- GPT-4.1 Mini, GPT-5 Mini (OpenAI)
- Gemini 3 Flash (Google)
실험 변수 (컨텍스트 수준): 각 함수에 대한 입력을 3 가지 구성으로 변경하여 실험했습니다.
1. Code Only (CO): 대상 함수 코드만 제공.
2. Code + Callees (CC): 대상 함수 + 해당 함수가 호출하는 하위 함수 (Callees) 코드.
3. Code + Callers (CK): 대상 함수 + 해당 함수를 호출하는 상위 함수 (Callers) 코드.
평가 지표:
- 효과성: 정확도 (Accuracy), F1 점수.
- 비용: 토큰 소비량 기반 추론 비용 (USD).
- 설명 품질: 취약점 식별의 정확성 (Correctness) 과 포괄성 (Comprehensiveness, 공격 벡터 및 수정 제안 포함 여부) 을 0~2 점 척도로 전문가가 수동 평가.
통계 분석: 맥니마르 검정 (McNemar's test) 을 사용하여 컨텍스트 구성 간의 성능 차이가 통계적으로 유의미한지 확인했습니다.

3. 주요 기여 및 결과 (Key Contributions & Results)

A. 인터프로시저 컨텍스트의 효과성 (RQ1)

역설적 발견: 추가적인 인터프로시저 컨텍스트 (호출자/피호출자 코드) 를 제공하는 것이 항상 성능을 향상시키는 것은 아니며, 오히려 성능을 저하시키는 경우가 많았습니다.
모델별 차이:
- Claude Haiku 4.5 와 Gemini 3 Flash: 컨텍스트 변화에 매우 강건 (Robust) 했습니다. 단일 함수만으로도 높은 성능을 유지했으며, 추가 컨텍스트가 성능을 크게 떨어뜨리지 않았습니다.
- GPT 모델 (특히 GPT-4.1 Mini): 추가 컨텍스트가 성능을 급격히 저하시켰습니다. C 언어의 경우, GPT-4.1 Mini 는 CC(피호출자 포함) 컨텍스트에서 정확도가 **75.6% 에서 54.0%**로 약 25%p 하락했습니다. 이는 불필요한 정보가 모델의 추론을 방해하는 '노이즈'로 작용했음을 시사합니다.

B. 다중 언어 영향 (RQ2)

C 언어: GPT 모델에서 컨텍스트 추가 시 성능 저하가 통계적으로 유의미하게 나타났습니다.
Python: C 에 비해 인터프로시저 결합도가 낮아 컨텍스트 추가의 영향이 덜 뚜렷했으나, 여전히 GPT 모델은 성능이 감소하는 경향을 보였습니다.
C++: 샘플 수가 부족하여 통계적 결론 도출은 어렵지만, CO(코드만) 구성에서 높은 정확도를 보였습니다.

C. 비용 효율성 (RQ3)

비용 증가: 인터프로시저 컨텍스트를 추가하면 프롬프트 토큰 수가 약 2 배 증가하여 추론 비용도 비례하여 증가했습니다.
성능 대비 비용: 추가 컨텍스트로 인한 비용 증가는 정확도 향상으로 이어지지 않았습니다.
최고의 비용 효율성: Gemini 3 Flash가 C 언어 취약점 탐지에서 가장 우수한 비용 - 성능 트레이드오프를 보였습니다. F1 점수 0.978 이상을 달성하면서 구성당 약 $0.50~$ 0.58 의 비용으로 가장 효율적이었습니다. (Claude Haiku 4.5 는 성능은 좋았으나 비용이 2 배 이상 더 들었습니다.)

D. 설명의 질 (RQ4)

Claude Haiku 4.5: 취약점 식별의 정확성과 설명의 포괄성 모두에서 가장 우수한 성능을 보였습니다. 평가된 사례의 **93.6%**에서 완벽한 점수 (2, 2) 를 받았습니다.
GPT 모델: 취약점을 잘못 식별하거나 (Correctness 0 점), 설명이 부실한 (Comprehensiveness 0 점) 비율이 Haiku 와 Gemini 보다 5 배 높았습니다.
상관관계: 탐지 성능이 낮은 모델은 설명의 질도 낮았습니다. 즉, 내부적으로 취약점을 올바르게 이해하지 못하면 설명도 부정확해지는 경향이 있었습니다.

4. 연구의 의의 및 시사점 (Significance)

"더 많은 컨텍스트 = 더 좋은 성능"이라는 통념의 깨짐: LLM 기반 취약점 탐지 시스템 설계 시, 무조건적으로 호출자/피호출자 코드를 포함시키는 것이 오히려 성능을 저하시킬 수 있음을 입증했습니다. 모델 아키텍처에 따라 최적의 컨텍스트 수준이 다릅니다.
비용 효율적인 도구 선정 가이드:
- Gemini 3 Flash: 비용과 정확도의 균형이 가장 뛰어난 모델로, 대규모 코드베이스 스캐닝에 적합합니다.
- Claude Haiku 4.5: 개발자가 취약점의 원인과 수정 방안을 명확히 이해해야 하는 경우 (설명성 우선) 에 가장 적합합니다.
- GPT-4.1 Mini: 비용은 가장 저렴하지만, 특히 C 언어와 인터프로시저 컨텍스트가 포함된 경우 성능이 크게 떨어지므로 신중한 사용이 필요합니다.
실무 적용 전략: LLM 기반 보안 분석 도구를 개발할 때는 대상 프로그래밍 언어 (C vs Python) 와 선택한 LLM 모델의 특성에 따라 인터프로시저 컨텍스트의 제공 여부를 동적으로 조절해야 합니다.

결론

이 연구는 현대 LLM 이 인터프로시저 의존성을 가진 취약점을 탐지할 때, 단순히 컨텍스트를 늘리는 것이 해결책이 아니며, 모델별 특성과 비용 효율성을 고려한 전략적 접근이 필요함을 실증적으로 증명했습니다. 특히 Gemini 3 Flash 의 비용 효율성과 Claude Haiku 4.5 의 설명 능력은 실제 보안 분석 도구 설계에 중요한 지침을 제공합니다.