CONCUR: Benchmarking LLMs for Concurrent Code Generation

이 논문은 기존 벤치마크가 간과한 동시성 코드 생성 능력을 평가하기 위해 교재 기반의 43 개 문제와 72 개의 변형으로 구성된 새로운 벤치마크 'CONCUR'를 제안하고, 이를 통해 현재 LLM 들의 한계를 분석합니다.

핵심

이 논문은 **"LLM(거대 언어 모델) 이 동시성 코드를 얼마나 잘 작성할 수 있는지 테스트하는 새로운 시험지"**를 소개하는 연구입니다.

쉽게 말해, **"여러 명이 동시에 일하는 복잡한 상황에서도 AI 가 실수 없이 코드를 짜낼 수 있을까?"**를 확인한 실험 보고서입니다.

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

---

1. 왜 이 연구가 필요한가요? (기존의 문제점)

지금까지 AI 코딩 능력을 평가하는 시험지들은 대부분 **'한 사람이 순서대로 일하는 상황'**만 다루었습니다.

• 비유: 마치 "혼자서 요리하는 법"만 가르쳐 놓고, "여러 요리사가 좁은 주방에서 동시에 요리할 때 누가 무엇을 먼저 해야 하는지"를 테스트하지 않는 것과 같습니다.
• 문제: 실제로는 여러 사람이 (스레드) 동시에 일할 때 서로 부딪히거나 (경쟁 조건), 서로 기다리며 멈춰버리는 (데드락) 같은 복잡한 실수가 자주 발생합니다. 기존 시험지는 이런 '동시성 실수'를 찾아내지 못해, AI 가 엉터리 코드를 만들어도 "정답"으로 통과시켜 버리는 경우가 많았습니다.

2. 새로운 시험지 'CONCUR'란 무엇인가요?

저자들은 이 빈틈을 메우기 위해 CONCUR라는 새로운 시험지를 만들었습니다.

• 구성: 표준 교재에서 뽑은 43 개의 기본 문제와, 이를 변형한 72 개의 변형 문제, 총 115 개의 문제로 이루어져 있습니다.
• 특징: 단순히 "코드가 문법적으로 맞는지"만 보는 게 아니라, **"여러 명이 동시에 일할 때 정말로 안전하게 돌아가는지"**를 철저히 검증합니다.

3. 어떻게 검증하나요? (마법 같은 감시자)

이 시험의 가장 큰 특징은 **'모델 체킹 (Model Checking)'**이라는 기술을 사용한다는 점입니다.

• 비유: 일반적인 테스트는 "요리사가 요리를 해보니까 맛있다"고 확인하는 것입니다. 하지만 동시성 코드는 "100 번 요리해봤는데 다 맛있었다"고 해서 "101 번째에도 맛있다"고 장담할 수 없습니다. (누군가 언제 들어올지 모르기 때문이죠.)
• 해결책: CONCUR 는 **'모든 가능한 상황'을 시뮬레이션하는 감시자 (JPF)**를 투입합니다. 이 감시자는 "A 가 먼저 할까, B 가 먼저 할까?" 하는 모든 경우의 수를 빠짐없이 훑어보며, "아! 이 순서면 서로 부딪혀서 멈춰버리겠네!"라고 즉시 적발합니다.
• 결과: AI 가 만든 코드가 문법적으로 완벽해 보여도, 이 감시자가 "여러 명이 동시에 일할 때 충돌이 발생한다"고 하면 불합격입니다.

4. 실험 결과: AI 는 여전히 동시성 코드를 어려워합니다

연구진은 23 개의 최신 AI 모델에게 이 시험을 치르게 했습니다.

• 결과: 많은 AI 가 코드를 작성할 수는 있었지만, 동시성 실수 (데드락, 경쟁 조건 등) 를 피하는 데는 여전히 취약했습니다.
• 놀라운 발견:
  1. 단순한 점수 (CodeBLEU) 는 속임수: 기존에 쓰이던 '코드 유사도 점수'는 AI 가 엉터리 코드를 만들어도 높게 나올 수 있어, 동시성 코드의 정확성을 판단하는 데는 쓸모가 거의 없습니다. (예: 문장은 완벽하지만, 실제로는 여러 사람이 일하지 않는 코드를 '정답'으로 치는 경우)
  2. 가장 흔한 실수: AI 는 "동시성"이라는 개념은 알고 있지만, 실제로 여러 개의 작업을 동시에 실행시키는 코드를 짜지 못하고, 혼자서 일하는 코드를 만들어내는 경우가 많았습니다. (비유: "여러 명이 일하라"고 지시받았는데, AI 는 혼자서 일하는 시나리오만 써낸 것)

5. 결론 및 시사점

이 연구는 **"AI 가 동시성 코드를 잘 짜는지 확인하려면, 단순히 코드를 비교하는 게 아니라 '모든 상황'을 시뮬레이션하는 엄격한 테스트가 필요하다"**는 것을 증명했습니다.

• 한 줄 요약: "혼자서 일하는 코드는 잘 짜는 AI 도, 여러 명이 동시에 일하는 복잡한 상황에서는 여전히 헷갈려서 실수를 많이 합니다. 우리는 AI 의 진짜 실력을 보기 위해 더 까다롭고 정교한 시험 (CONCUR) 이 필요합니다."

이 연구는 앞으로 AI 가 더 복잡한 소프트웨어를 개발할 때, 우리가 신뢰할 수 있는 기준을 마련하는 데 중요한 발걸음이 될 것입니다.

기술 요약

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

• 기존 벤치마크의 한계: 현재 대규모 언어 모델 (LLM) 의 코드 생성 능력을 평가하는 벤치마크 (HumanEval, MBPP 등) 는 주로 순차적 (Sequential) 코드에 집중되어 있습니다.
• 동시성 코드의 특수성: 동시성 (Concurrency) 코드는 순차적 코드와 달리 스레드 간의 인터리빙 (interleaving) 실행, 비결정적 스케줄링, 동기화 요구사항 등으로 인해 훨씬 복잡합니다.
• 고유한 버그: 동시성 코드는 데드락 (Deadlock), 레이스 컨디션 (Race Condition), 기아 (Starvation) 등 순차적 코드에서는 발생하지 않는 고유한 버그를 포함합니다.
• 평가의 부재: 기존 벤치마크는 정적 유사도 지표 (CodeBLEU 등) 나 단순 유닛 테스트에 의존하는데, 이는 동시성 코드의 논리적 정확성을 포착하지 못하거나, 비결정적 스레드 스케줄링을 체계적으로 탐색하지 못해 결함이 있는 코드를 정답으로 오인할 수 있습니다. 따라서 LLM 이 동시성 코드를 생성할 수 있는지 평가할 수 있는 전용 벤치마크가 부재했습니다.

2. 제안된 방법론 (Methodology)

저자들은 CONCUR라는 새로운 벤치마크를 제안하였으며, 이는 데이터셋 설계와 엄격한 평가 프레임워크로 구성됩니다.

2.1 데이터셋 구성 (Dataset)

• 문제 선정: 표준 동시성 교재 [14] 에서 43 개의 기본 동시성 문제를 선정했습니다.
• 변형 (Mutant) 생성: 암기 방지와 다양성 확보를 위해 기본 문제의 일부에서 72 개의 변형 (Mutant) 버전을 생성하여 총 115 개의 문제로 구성했습니다.
• 프롬프트 엔지니어링: Java 8 을 타겟 언어로 하며, 스레드 수와 반복 횟수를 명시적으로 제한하여 모델 체킹 시 상태 공간 폭발 (State-space explosion) 을 방지하도록 프롬프트를 구조화했습니다.
• Ground Truth: 교재의 불완전한 코드 스니펫을 실행 가능한 완전한 Java 프로그램으로 재구성하고, JPF(Java Pathfinder) 설정을 위한 최대 실행 깊이 등을 정의했습니다.

2.2 평가 프레임워크 (Evaluation Framework)

CONCUR 는 단순 컴파일 검사를 넘어 모델 체킹 (Model Checking) 기술을 활용합니다.

1. 컴파일 단계: 생성된 코드가 Java 8 환경에서 컴파일되는지 확인합니다.
2. 모델 체킹 단계 (JPF):
   • Java PathFinder (JPF) 를 사용하여 생성된 코드의 모든 가능한 스레드 인터리빙을 체계적으로 탐색합니다.
   • 커스텀 리스너 (Listeners): 데드락, 레이스 컨디션, 기아, 단일 스레드 실행 (ST), 예외 처리 실패 등 다양한 동시성 오류를 감지하기 위해 맞춤형 리스너를 적용합니다.
   • 경계 설정 (Bounding): 상태 공간 폭발을 막기 위해 Ground Truth 기반의 깊이 제한 (Depth Limit) 과 시간 제한 (Time Limit) 을 적용하여 검증의 실용성을 확보했습니다.
3. 오류 분류: 컴파일 오류, JPF 감지 오류 (Deadlock, Race Condition, Starvation, Uncaught Exception, No Entry Method, Single Thread, Termination Error) 로 세분화하여 평가합니다.

3. 주요 기여 (Key Contributions)

1. 최초의 동시성 코드 생성 벤치마크 (CONCUR): 115 개의 동시성 문제와 구조화된 프롬프트, 검증된 Ground Truth 를 포함하는 최초의 전용 벤치마크를 공개했습니다.
2. 모델 체킹 기반 자동 검증 프레임워크: 기존 벤치마크가 의존하던 정적 분석이나 단순 유닛 테스트 대신, JPF 를 활용한 상태 공간 탐색을 통해 동시성 버그를 체계적으로 검출하는 자동화 시스템을 구축했습니다.
3. 23 개 LLM 에 대한 광범위한 평가: 상용 API 모델 (GPT-5, Claude 등) 과 오픈소스 모델 (Llama, Qwen 등) 총 23 개 모델을 평가하여 현재 LLM 의 동시성 코드 생성 한계를 규명했습니다.
4. CodeBLEU 의 한계 규명: 정적 유사도 지표인 CodeBLEU 가 동시성 코드의 논리적 정확성을 반영하지 못함을 실증적으로 증명했습니다.

4. 실험 결과 (Results)

• 성능: 평가된 23 개 모델 중 가장 성능이 좋은 모델 (GPT-5) 도 Pass@1 기준 77.39% 의 통과율을 보였으며, 대부분의 모델은 50% 미만의 통과율을 기록했습니다. Pass@3(3 번 시도) 으로 늘리면 성능이 크게 향상되지만, 여전히 동시성 코드는 생성이 어렵습니다.
• 주요 오류 유형:
  • 단일 스레드 실행 (ST): LLM 이 동시성 로직을 개념적으로 이해했음에도 불구하고, 실제로 여러 스레드를 생성하지 않고 단일 스레드로 실행하는 경우가 빈번했습니다.
  • 예외 처리 실패 (UE): 실행 중 발생할 수 있는 예외를 처리하지 못해 런타임 오류가 발생했습니다.
  • 데드락 및 레이스 컨디션: 동기화 메커니즘 (Lock, Semaphore 등) 을 잘못 적용하여 고전적인 동시성 버그가 발생했습니다.
• CodeBLEU 분석: 높은 CodeBLEU 점수를 받은 모델도 실제 동시성 버그가 많아 정답으로 판정되지 않았습니다. 이는 정적 유사도가 동시성 코드의 논리적 정확성을 대체할 수 없음을 의미합니다.
• 검증 신뢰도: 자동 평가 프레임워크의 정확성을 확인하기 위해 115 개의 통과 코드를 수동으로 감사한 결과, 92% 의 정밀도 (Precision) 를 확인하여 프레임워크의 신뢰성을 입증했습니다.

5. 의의 및 결론 (Significance)

• 새로운 평가 패러다임: 동시성 코드의 복잡성과 고유한 버그를 고려한 동적 검증 (Dynamic Verification) 기반 벤치마크의 필요성을 제시했습니다.
• LLM 의 한계 명확화: 현재 LLM 들은 순차적 로직은 잘 생성하지만, 스레드 간의 상호작용, 동기화, 비결정적 실행 흐름을 다루는 데에는 여전히 심각한 한계가 있음을 보여주었습니다.
• 향후 연구 방향: 정적 지표 대신 모델 체킹과 같은 형식적 방법 (Formal Methods) 을 코드 생성 평가에 통합해야 함을 강조하며, 다양한 프로그래밍 언어와 더 복잡한 동시성 시나리오로 벤치마크를 확장할 것을 제안합니다.

이 논문은 소프트웨어 공학 분야에서 LLM 의 동시성 코드 생성 능력을 평가하기 위한 새로운 표준을 제시하며, 향후 안전하고 신뢰할 수 있는 병행 프로그램 생성을 위한 중요한 기초를 마련했습니다.