💻 computer science

Do Code LLMs Do Static Analysis?

이 논문은 코드 LLM 이 정적 분석 (호출 그래프, AST, 데이터 흐름 생성 등) 과 코드 지능 작업 (코드 생성, 요약, 번역 등) 을 수행할 때 정적 분석 능력이 낮으며, 두 작업 간에 학습 효과가 서로 전이되지 않는다는 사실을 실험을 통해 규명했습니다.

원저자: Chia-Yi Su, Collin McMillan

게시일 2026-03-27

📖 4 분 읽기☕ 가벼운 읽기

CC BY 4.0

원저자: Chia-Yi Su, Collin McMillan

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

이 논문은 **"코딩을 잘하는 AI(대형 언어 모델) 가 실제로 코드를 '이해'하고 있을까?"**라는 아주 중요한 질문을 던집니다.

사람이 코드를 읽을 때는 단순히 글자만 보는 게 아니라, 함수가 어떻게 연결되는지 (호출 그래프), 데이터가 어떻게 흐르는지 (데이터 흐름), 코드의 구조가 어떻게 생겼는지 (문법 트리) 를 머릿속으로 그려가며 **정적 분석 (Static Analysis)**을 합니다. 마치 건축가가 건물을 설계할 때 벽돌 하나하나의 위치와 기둥의 연결 관계를 꼼꼼히 따져보는 것과 비슷하죠.

저자들은 "AI 도 사람처럼 이 과정을 거쳐 코드를 이해하고 있을까?"라고 의문을 품고 실험을 했습니다. 결과는 다소 충격적이었습니다. AI 는 코드를 '이해'하기보다는, 마치 거대한 도서관에서 책을 외운 뒤 그 책의 '표지 디자인'만 흉내 내는 것과 같았습니다.

이 연구의 핵심 내용을 일상적인 비유로 설명해 드릴게요.

1. 실험의 설정: "건축가 vs. 모방꾼"

연구진은 AI 에게 세 가지 일을 시켰습니다.

코딩 작업: 새로운 코드를 짜거나, 코드를 요약하거나, 다른 언어로 번역하기. (예: "이건 무슨 건물인지 설명해줘", "이 건물을 다른 스타일로 지어줘")
정적 분석 작업: 코드의 구조를 분석하기. (예: "이 함수가 어떤 함수를 부르는지 연결도 그려줘", "데이터가 A 에서 B 로 어떻게 이동하는지 흐름도 그려줘")

그리고 두 가지 시나리오를 테스트했습니다.

AI 가 먼저 정적 분석을 배웠을 때: "먼저 연결도 그리는 법을 가르쳐주고, 그다음 코딩을 시켰더니 더 잘할까?"
AI 가 먼저 코딩을 배웠을 때: "코딩을 잘하게 가르친 뒤, 정적 분석을 시켰더니 자연스럽게 잘할까?"

2. 주요 발견: "형식 (Form) 은 잘 따라하지만, 의미 (Semantics) 는 모른다"

비유 1: 레고 조립과 설계도

사람은 레고로 성을 만들 때, **설계도 (정적 분석)**를 먼저 봅니다. "이 기둥이 저 기둥을 받치고 있구나, 그래서 이 벽이 무너지지 않겠구나"라고 이해합니다.
하지만 이 연구에 따르면, AI 는 설계도를 보지 않고 레고 블록의 '색깔과 모양'만 보고 조립합니다.

결과: AI 가 만든 성은 겉보기엔 사람과 비슷해 보일 수 있지만, 내부 연결 구조 (호출 그래프) 를 그려달라고 하면 엉뚱한 연결을 하거나, 아예 엉망이 됩니다. 마치 레고 블록을 쌓을 때 "이게 저걸 받치고 있어야 한다"는 논리보다는 "이 색깔이 저 색깔과 잘 어울리니까 붙여보자"라고 생각하는 것과 같습니다.

비유 2: 악보 읽기 vs. 멜로디 따라 부르기

사람: 악보 (코드) 를 볼 때, "이 소절이 다음 소절로 이어지고, 이 화음이 저 화음으로 해결되네"라고 **음악의 흐름 (데이터 흐름)**을 이해합니다.
AI: 악보를 보고 "이 글자 (코드) 가 저 글자 다음에 오니까, 나도 그 순서대로 노래를 불러야지"라고 순서만 외워서 따라 부릅니다.
실험 결과: AI 에게 "이 노래의 화음 진행을 그려줘"라고 하면, AI 는 화음의 논리적 연결을 이해하지 못해 엉뚱한 화음을 연결합니다.

3. 구체적인 실험 결과 (쉬운 요약)

정적 분석은 AI 가 가장 약한 점입니다:
- AI 가 코딩 (새로운 코드 생성, 요약) 은 잘하지만, 코드의 연결 구조나 데이터 흐름을 분석하는 작업은 매우 부실합니다.
- 마치 "요리 레시피를 보고 요리는 잘하지만, '왜 이 재료가 저 재료와 섞여야 하는지' 화학적 원리를 설명하라고 하면 막히는" 상황입니다.
배우면 전이되지 않습니다 (가장 중요한 발견):
- 시나리오 A: AI 에게 "먼저 연결도 그리는 법 (정적 분석) 을 가르쳐줘"라고 했더니, 코딩 실력이 나아지지 않았습니다.
- 시나리오 B: AI 에게 "코딩을 잘하게 가르쳐줘"라고 했더니, 정적 분석을 할 수 있게 되지 않았습니다.
- 의미: AI 는 사람처럼 "이해 (이론)"를 통해 "실무 (응용)"를 하는 게 아니라, 각각의 작업을 따로따로 외우는 (암기) 방식이라는 뜻입니다.
형식만 흉내 내는 것:
- AI 는 정답의 **형식 (포맷)**은 잘 맞춥니다. 예를 들어, "함수 A 가 함수 B 를 부른다"는 형식으로 글을 쓰게 하면 그 형식은 잘 맞춥니다.
- 하지만 **실제 내용 (논리)**은 틀립니다. "A 가 B 를 부른다"고 썼지만, 실제로는 A 와 B 는 전혀 관계가 없는 경우가 많습니다.

4. 결론: AI 는 '생각'하지 않는다?

이 논문의 결론은 매우 명확합니다.
"AI 는 인간처럼 코드를 '이해'하거나 '추론'하지 않는다."

AI 는 방대한 양의 코드를 학습하면서 **"사람들이 코드를 어떻게 쓰는가 (패턴)"**는 것은 완벽하게 기억했지만, **"코드가 왜 그렇게 작동하는가 (논리)"**는 이해하지 못합니다.

인간: "이 함수가 저 함수를 부르는구나. 그래서 데이터가 이렇게 흐르겠구나." (이해와 추론)
AI: "이런 코드는 보통 저런 함수를 부르는 패턴이 있더라. 그래서 나도 그렇게 써보자." (패턴 매칭과 암기)

5. 이 연구가 우리에게 주는 교훈

이 연구는 AI 가 코딩을 대신할 수 있다는 기대를 조금은 식히게 하지만, 동시에 중요한 방향을 제시합니다.

AI 는 보조 도구일 뿐: AI 가 만든 코드는 겉보기엔 완벽해 보일 수 있지만, 내부 논리 (정적 분석) 가 엉망일 수 있으므로 반드시 사람이 검증해야 합니다.
새로운 AI 개발 필요: 앞으로의 AI 는 단순히 "패턴을 외우는" 것을 넘어, "논리와 구조를 이해하는" 새로운 방식으로 발전해야 진정한 소프트웨어 엔지니어링의 파트너가 될 수 있습니다.

한 줄 요약:

AI 는 코딩을 아주 잘하는 '모방꾼'이지만, 코드가 어떻게 작동하는지 '이해'하는 '건축가'는 아닙니다.

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

배경: 최근 코드 LLM(대형 언어 모델) 은 코드 생성, 요약, 번역 등 다양한 프로그래밍 작업에서 뛰어난 성능을 보이고 있습니다. 인간 프로그래머는 코드를 이해하고 작업을 수행할 때 정적 분석 (Static Analysis) 을 핵심적으로 사용합니다. 이는 실행 없이 코드를 분석하여 함수 호출 관계 (Call Graph), 데이터 흐름 (Data Flow), 구문 구조 (AST) 등을 파악하는 과정입니다.
문제: 코드 LLM 이 인간과 유사한 '추론 (Reasoning)' 능력을 가지고 정적 분석을 수행하며 이를 통해 코드를 이해하는지, 아니면 단순히 대규모 데이터의 패턴 매칭을 통해 표면적인 형식 (Form) 만 학습하는지에 대한 의문이 제기되었습니다.
핵심 질문: 코드 LLM 이 정적 분석 작업을 수행할 수 있는가? 그리고 정적 분석 능력을 학습하는 것이 코드 개발 (Code Intelligence) 작업의 성능 향상으로 이어지는가?

2. 연구 방법론 (Methodology)

저자는 오픈소스 모델 (JAM, CodeLlama) 과 상용 폐쇄형 모델 (GPT-4o, Gemini) 을 대상으로 다음과 같은 실험을 설계했습니다.

평가 작업 (Tasks):
- 정적 분석 3 가지: 호출 그래프 생성 (Call Graph), 데이터 흐름 그래프 생성 (Data Flow Graph), 추상 구문 트리 생성 (AST).
- 코드 지능 작업 3 가지: 코드 요약 (Summarization), 코드 번역 (Translation), 코드 생성 (Generation).
- 언어: Java 와 C/C++.
실험 설계 (Research Questions):
1. (RQ1) 폐쇄형 LLM 의 정적 분석 기본 성능은 어떠한가?
2. (RQ2) 오픈소스 LLM 을 정적 분석 작업으로 파인튜닝하면 정적 분석 성능이 향상되는가?
3. (RQ3) 정적 분석으로 파인튜닝된 모델이 코드 개발 작업 (요약, 생성, 번역) 의 성능을 향상시키는가?
4. (RQ4) 코드 개발 작업으로 파인튜닝된 모델이 정적 분석 작업을 수행할 수 있는가 (부산물 효과)?
5. (RQ5) 정적 분석 작업에서 발생하는 주요 오류 유형은 무엇인가?
평가 지표:
- 정적 분석: Levenshtein 거리 (AST), Jaccard 유사도, Pair Accuracy, Chain Accuracy (호출/데이터 흐름).
- 코드 작업: METEOR, USE, BLEU, CodeBERTScore, Pass@k, 컴파일 성공률.

3. 주요 결과 (Key Results)

A. 정적 분석 수행 능력 (RQ1, RQ2)

기본 성능: GPT-4o 와 Gemini 같은 최상위 상용 모델조차 정적 분석 (특히 호출 그래프와 데이터 흐름) 에서 매우 낮은 성능을 보였습니다. In-context learning(예시 포함 프롬프트) 은 AST 생성에는 일부 도움을 주었으나, 복잡한 추론이 필요한 호출 그래프나 데이터 흐름 생성에는 성능 향상을 가져오지 못했습니다.
파인튜닝 효과: 오픈소스 모델을 정적 분석 데이터로 파인튜닝하면 AST 생성 성능은 크게 향상되었으나, 호출 그래프와 데이터 흐름 그래프 생성에서는 여전히 Chain Accuracy(전체 그래프 정확도) 가 극도로 낮았습니다. 이는 모델이 개별 노드나 엣지는 맞추더라도 전체적인 구조적 관계를 이해하지 못함을 의미합니다.

B. 작업 간 전이 효과 (RQ3, RQ4)

정적 분석 $\rightarrow$ 코드 개발: 정적 분석 작업으로 파인튜닝된 모델이 코드 요약, 생성, 번역 작업의 성능을 유의미하게 향상시키지 못했습니다. 오히려 모델은 정적 분석을 통해 얻은 '의미 (Semantics)'보다는 '형식 (Form)'만 학습하여, 논리적 오류를 그대로 반복하거나 문법적 구조만 개선하는 경향을 보였습니다.
코드 개발 $\rightarrow$ 정적 분석: 코드 개발 작업으로 파인튜닝된 모델이 정적 분석 작업을 수행할 수 있는 '부산물'을 보여주지 못했습니다. 오히려 정적 분석 전용으로 학습된 모델보다 성능이 현저히 낮았습니다.

C. 오류 유형 분석 (RQ5)

호출 그래프: 모델은 실제 존재하지 않는 직접 호출 (Extra Direct Calls) 을 생성하거나, 간접 호출을 누락하는 경향이 강했습니다. 특히 순환 참조 (Cycles) 를 과도하게 예측하는 경향이 있었습니다.
데이터 흐름: 불필요한 데이터 흐름 엣지를 생성하거나 (False Positive), 실제 흐름을 놓치는 (False Negative) 오류가 빈번했습니다.
AST: 태그 불일치 (Tag Mismatch) 와 파싱 오류가 주를 이루었으며, 이는 모델이 구문적 형식을 학습했으나 의미론적 구조를 이해하지 못했음을 시사합니다.

4. 주요 기여 및 결론 (Contributions & Conclusion)

핵심 발견: 코드 LLM 은 인간 프로그래머처럼 정적 분석을 통해 코드를 '이해'하고 추론하는 것이 아니라, 대규모 데이터에서 학습된 통계적 패턴과 형식 (Form) 을 기억 (Memorization) 하고 재현하는 것으로 결론지어졌습니다.
의미:
1. 인간과 다른 사고 과정: LLM 의 사고 과정은 인간의 정적 분석 기반 추론과 근본적으로 다릅니다.
2. 학습의 한계: 정적 분석 작업을 학습한다고 해서 코드 이해도가 높아지거나, 반대로 코드를 잘 생성한다고 해서 정적 분석 능력이 생기는 것은 아닙니다.
3. 향후 방향: 단순한 모델 크기 확장이나 데이터 양 증가만으로는 해결되지 않으며, 의미론적 추론 (Semantic Reasoning) 을 가능하게 하는 새로운 아키텍처나 학습 절차가 필요함을 시사합니다.

5. 의의 (Significance)

이 연구는 코드 LLM 에 대한 과도한 기대 ("LLM 이 코드를 이해한다") 를 재고하게 만들었습니다. 현재 LLM 은 정적 분석 도구의 역할을 대체할 수 없으며, 보안 및 신뢰성 측면에서 LLM 이 생성한 코드의 논리적 오류를 검증할 때 인간이나 기존 정적 분석 도구의 개입이 여전히 필수적임을 강조합니다. 또한, 소프트웨어 공학 분야에서 LLM 을 효과적으로 활용하기 위해서는 단순한 프롬프트 엔지니어링을 넘어, 모델이 코드의 의미와 구조를 진정으로 이해하도록 하는 새로운 연구 방향이 필요함을 제시합니다.