CLARC: C/C++ Benchmark for Robust Code Search

이 논문은 기존 벤치마크의 한계를 극복하고 C/C++ 코드의 의미적 이해와 강건성을 평가하기 위해 실제 GitHub 저장소에서 파생된 대규모 데이터셋 'CLARC'를 제안하고, 식별자 익명화 및 저수준 컴파일 등 다양한 도전적 환경에서 기존 모델들이 어휘적 특징에 과도하게 의존한다는 사실을 규명했습니다.

핵심

1. 문제점: "단어 외우기"만 하는 AI 들

지금까지 개발자들이 코드를 찾을 때 사용하는 AI 들은, 마치 단어장을 외운 학생과 비슷했습니다.

• 상황: "사과를 껍질 벗기는 함수"를 찾으려 합니다.
• 기존 AI 의 반응: 코드 안에 'apple', 'peel' 같은 단어가 들어있으면 "아! 이거야!"라고 바로 찾아냅니다.
• 문제: 하지만 변수 이름을 'apple' 대신 'fruit'로 바꾸거나, 코드를 기계가 읽는 언어 (어셈블리) 로 번역하면, 이 AI 들은 당황해서 "이게 무슨 말인지 모르겠다"며 엉뚱한 답을 내놓습니다. 즉, 코드의 진짜 뜻을 모르고 단어만 보고 추측하는 것입니다.

2. 해결책: CLARC (클라크) 라는 새로운 시험지

저자들은 이 문제를 해결하기 위해 CLARC라는 새로운 시험지를 만들었습니다.

• 실전 같은 문제: 기존 시험지들은 파이썬 같은 쉬운 언어만 다뤘지만, CLARC 는 C/C++(시스템을 만드는 어려운 언어)로 만들어졌습니다.
• 완벽한 코드: 이 코드는 실제로 컴퓨터에서 실행 (컴파일) 될 수 있도록 완벽하게 준비되어 있습니다. (기존 시험지들은 실행이 안 되는 불완전한 경우가 많았음)
• **다양한 함정 **(스트레스 테스트) AI 가 진짜로 코드를 이해하는지 보기 위해 다음과 같은 '함정'을 넣었습니다.
  1. **이름 가리기 **(Anonymization) 변수나 함수 이름을 func_a, var_b 처럼 아무 의미 없는 이름으로 바꿉니다. (단어 외우기 불가능)
  2. 기계어 변환: 코드를 사람이 읽기 힘든 **어셈블리 **(Assembly)나 **웹어셈블리 **(WebAssembly)로 바꿉니다. (원래 코드의 모양이 완전히 사라짐)

3. 실험 결과: AI 들의 실망스러운 성적

이 새로운 시험지 (CLARC) 로 최신 AI 6 개를 시험해 봤습니다. 결과는 충격적이었습니다.

• 정답: "이름을 바꾸거나 기계어로 바꾸면, AI 들의 성능이 뚝 떨어졌습니다."
• 해석: 이는 AI 들이 코드의 논리나 구조를 이해하는 게 아니라, **단어 **(이름)에 의존하고 있다는 뜻입니다. 마치 "사과"라는 단어가 없으면 "사과"를 못 찾는 학생과 같습니다.
• 특이점: 아주 최신 모델들도 이 함정에는 걸렸습니다. 특히 복잡한 코드를 기계어로 바꾸면, AI 들은 거의 아무것도 못 찾았습니다.

4. 결론 및 시사점: "진짜 이해"가 필요하다

이 논문의 핵심 메시지는 다음과 같습니다.

"지금의 AI 는 **코드를 읽는 게 아니라, 코드의 '스킨' **(단어)입니다.
개발자가 변수 이름을 바꾸거나, 코드를 최적화해서 기계어로 만들면 AI 는 길을 잃습니다.
앞으로는 단어가 바뀌어도 코드의 의미를 파악할 수 있는, 더 똑똑한 AI 가 필요합니다."

🍎 한 줄 요약

"지금의 코드 검색 AI 는 '이름'만 보고 코드를 찾는 '단어장 외우기' 수준입니다. CLARC 라는 새로운 시험지로 그 사실을 증명했으니, 이제 진짜 '이해'를 하는 AI 를 만들어야 할 때입니다!"

이 연구는 개발자들이 더 안전하고 정확한 코드를 찾을 수 있도록, AI 의 능력을 진짜 실전 (이름을 바꿔도, 기계어로 바꿔도) 에 맞춰 테스트하는 기준을 마련했다는 점에서 매우 중요합니다.

기술 요약

1. 문제 정의 (Problem)

기존의 코드 검색 벤치마크는 다음과 같은 심각한 한계를 가지고 있습니다:

• 언어 편향: 대부분의 벤치마크가 파이썬 (Python) 에 집중되어 있어, 시스템 프로그래밍 언어인 C/C++ 의 텍스트 - 코드 검색 과제를 다루지 못합니다.
• 비 compilable 한 데이터: 많은 데이터셋이 헤더 파일 누락이나 헬퍼 함수 부재로 인해 실제 컴파일이 불가능하여, 실제 개발 환경과 괴리가 있습니다.
• 표면적 특징 의존성: 기존 벤치마크는 식별자 (변수명, 함수명) 와 같은 **표면적인 어휘적 특징 (Lexical Features)**에 의존하는지, 실제 **코드 의미 (Semantics)**를 이해하는지 평가하는 스트레스 테스트 (Stress Test) 가 부족합니다. 이로 인해 모델이 오버피팅되거나, 코드 난독화나 어셈블리/웹어셈블리 같은 저수준 언어에서는 성능이 급격히 떨어지는 문제가 발견되지 않았습니다.

2. 방법론 (Methodology)

저자들은 GitHub 의 실제 C/C++ 저장소에서 데이터를 추출하고, 자동화된 파이프라인을 통해 CLARC를 구축했습니다.

A. 데이터셋 구축 파이프라인

1. 데이터 수집 및 컴파일 가능성 보장: 144 개의 인기 있는 GitHub 저장소에서 함수를 추출하고, 표준 라이브러리 헤더 화이트리스트를 기반으로 모든 코드가 컴파일 가능하도록 필터링했습니다.
2. 의존성 복잡도 분류: 함수를 의존성 수준에 따라 3 가지 그룹으로 분류했습니다.
   • Group 1: 표준 라이브러리 함수/타입만 사용.
   • Group 2: 표준 라이브러리 사용 + 사용자 정의 변수 타입 의존.
   • Group 3: 사용자 정의 헬퍼 함수 호출 포함 (Short: 분리된 스니펫, Long: 통합된 스니펫).
3. 쿼리 생성 및 검증: LLM (o3-mini, grok-4) 을 사용하여 자연어 쿼리를 생성했습니다. 생성된 쿼리의 품질을 보장하기 위해 **가설 검정 (Hypothesis Testing)**을 수행하여 인간 전문가가 작성한 설명과 통계적으로 비교했습니다 (LLM 이 인간과 동등하거나 더 우수한 품질을 보임).
4. 강건성 평가 설정 (Settings): 모델이 어휘적 특징에 의존하는지 테스트하기 위해 다음과 같은 변형 데이터를 생성했습니다.
   • Neutralized: 식별자를 func_a, var_b 등 중립적인 플레이스홀더로 변경.
   • Randomized: 식별자를 무작위 문자열로 변경 (모든 어휘 정보 제거).
   • Assembly & WebAssembly (Wasm): C/C++ 코드를 x86 어셈블리 및 WebAssembly 로 컴파일하여 저수준 언어에서의 검색 능력을 평가.

B. 평가 모델 및 지표

• 모델: BM25, CodeT5+, OASIS, Nomic-emb-code, OpenAI-text-embedding-large, Voyage-code-3 등 6 가지 최신 모델 평가.
• 지표: NDCG, MRR, MAP, Recall@k 등 정보 검색 표준 지표 사용.

3. 주요 기여 (Key Contributions)

1. CLARC 벤치마크 출시: C/C++ 기반의 완전 컴파일 가능 데이터셋 (평가용 1,245 쌍, 학습용 5,472 쌍) 을 공개했습니다.
2. 자동화 파이프라인 및 검증: LLM 기반 쿼리 생성과 인간 검증, 가설 검정을 결합한 확장 가능한 벤치마크 생성 파이프라인을 제시했습니다.
3. 모델 강건성 한계 규명: 기존 모델들이 식별자 이름과 같은 표면적 어휘적 특징에 과도하게 의존하고 있으며, 저수준 언어 (어셈블리 등) 나 식별자가 제거된 환경에서는 성능이 급격히 저하됨을 실증했습니다.

4. 실험 결과 (Results)

• 표준 설정 (Standard Setting): 최신 모델 (Voyage-code-3, Nomic-emb-code 등) 이 높은 성능을 보였으나, 이는 여전히 어휘적 특징에 의존할 가능성을 시사합니다.
• 식별자 무효화 (Neutralized/Randomized):
  • 모든 모델에서 성능이 급격히 하락했습니다. 특히 Group 2(사용자 정의 타입) 와 Group 3(헬퍼 함수) 에서 하락폭이 컸습니다.
  • 이는 모델이 타입 이름이나 함수 이름의 의미적 맥락이 아닌, 단순한 텍스트 매칭에 의존하고 있음을 의미합니다.
• 저수준 언어 (Assembly/Wasm):
  • 어셈블리와 웹어셈블리 환경에서 모델 성능이 극도로 낮아졌습니다.
  • 고수준 언어의 논리가 저수준 명령어로 변환되면서 토큰 수가 5~10 배 증가하고 고유 지시어 (Unique Instructions) 가 늘어나면서 모델이 의미적 동등성을 파악하지 못했습니다.
• 파인튜닝의 한계: 학습 데이터로 파인튜닝을 수행한 결과, 특정 설정에서는 성능이 개선되었으나, 표준 설정과 무효화 설정 간의 성능 격차는 여전히 존재했습니다. 이는 단순한 지도 학습만으로는 강건성 문제를 해결할 수 없음을 보여줍니다.

5. 의의 및 결론 (Significance & Conclusion)

• 현실적 평가 기준 제시: 실제 개발 환경 (컴파일 가능, 의존성 포함) 과 보안/난독화 시나리오 (식별자 제거, 저수준 변환) 를 반영한 최초의 C/C++ 벤치마크를 제공했습니다.
• 모델의 본질적 한계 지적: 현재 SOTA 코드 검색 모델들은 진정한 의미 이해 (Semantic Understanding) 가 부족하고, 여전히 **표면적인 어휘적 특징 (Lexical Features)**에 과도하게 의존하고 있음을 드러냈습니다.
• 미래 연구 방향: 강건한 코드 검색을 위해서는 단순한 텍스트 매칭을 넘어, 코드의 구조적, 논리적 의미를 이해할 수 있는 새로운 아키텍처와 학습 전략이 필요하며, CLARC 는 이를 위한 중요한 평가 도구로 활용될 것입니다.

이 논문은 코드 검색 기술이 실제 산업 환경 (특히 시스템 프로그래밍 및 보안 관련) 에 적용되기 위해 해결해야 할 핵심 과제를 명확히 제시했다는 점에서 의의가 큽니다.