프롬프트에서 성능까지 LLM 기반 작업 기반 병렬 코드 생성 평가

초록

본 논문은 자연어 설명, 순차 코드, 병렬 의사코드 세 가지 프롬프트를 이용해 ChatGPT‑5, Gemini‑3, Qwen‑Coder 30B가 OpenMP Task, C++ Standard Parallelism, HPX 세 프레임워크로 작업 기반 병렬 코드를 자동 생성하도록 평가한다. 정확도(pass@k), 코드 복잡도, 강·약 스케일링을 종합한 PCGQS 지표를 사용해 네 가지 벤치마크(π 근사, 병합 정렬, 행렬 곱, Conjugate Gradient)를 실험하였다. 결과는 모델·프레임워크·프롬프트 복합 요인이 성능에 큰 영향을 미치며, 특히 OpenMP이 가장 안정적이고 HPX는 가장 어려운 것으로 나타났다.

상세 분석

이 연구는 최신 대형 언어 모델(LLM)이 고성능 컴퓨팅(HPC) 분야에서 작업 기반(task‑based) 병렬 코드를 자동 생성할 수 있는지를 체계적으로 조사한다. 평가 대상은 세 가지 프롬프트 유형—(1) 자연어 문제 설명만 제공, (2) 완전한 순차 C++ 구현 제공, (3) 병렬 의사코드(알고리즘 흐름을 구조화한 의사코드) 제공—이며, 이는 실제 개발 현장에서 LLM을 활용하는 다양한 시나리오를 반영한다.

벤치마크는 병렬화 난이도와 메모리·연산 특성이 서로 다른 네 가지 문제로 구성된다. π 근사는 독립적인 작업이 많아 의존성 관리가 거의 필요 없으며, 병합 정렬은 재귀적 작업 생성과 정확한 종속성 표시가 핵심이다. 행렬‑행렬 곱은 고연산 집약적이며 메모리 대역폭에 민감하고, Conjugate Gradient은 반복적 전역 동기화와 감소 연산을 포함해 가장 까다로운 동기화 요구를 가진다.

세 프레임워크는 추상화 수준이 서로 다르다. OpenMP Task는 pragma 기반으로 명시적 task와 barrier를 사용해 모델이 의존성을 직접 표현하도록 강제한다. C++ Standard Parallelism은 std::execution 정책과 알고리즘을 통해 선언적 병렬성을 제공, 모델이 고수준 API만 사용하면 된다. HPX는 futures와 dataflow를 활용한 완전 비동기 런타임으로, 미세한 task granularity와 동적 스케줄링을 요구한다.

평가 지표는 크게 세 축으로 나뉜다. 첫째, pass@k는 k개의 샘플 중 최소 하나가 올바른지를 확률적으로 측정한다. 둘째, 코드 복잡도는 scc 도구를 이용해 실효 라인 수, 주석 비율, 사이클로매틱 복잡도를 정량화한다. 셋째, PCGQS는 기능적 정확도(C)와 스케일링 점수(S)를 각각 0.5 가중치로 결합해, 강·약 스케일링 실험을 통해 얻은 가속 비율을 정규화한다.

실험 결과는 몇 가지 중요한 패턴을 드러낸다. 모델별로는 ChatGPT‑5가 전반적으로 가장 높은 pass@1(≈ 85 %)을 기록했으며, Gemini‑3가 그 뒤를 이었다. Qwen‑Coder 30B는 특히 OpenMP과 C++ Standard Parallelism에서 낮은 정확도를 보였지만, 중간 수준의 인간 수정(‘medium fix’)을 허용하면 거의 100 %에 도달했다. 프레임워크별로는 OpenMP이 가장 일관된 성능을 보였고, C++ Standard Parallelism은 ChatGPT와 Gemini에서 거의 완벽에 가까운 결과를 냈다. 반면 HPX는 모든 모델에서 초기 pass@1이 30 % 이하로 낮았으며, 복잡한 futures와 namespace 사용 오류가 주된 실패 원인이었다.

프롬프트 유형은 전체 정확도에 큰 차이를 만들지 않았다. 자연어만 제공했을 때와 순차 코드를 제공했을 때의 차이는 통계적으로 유의미하지 않았으며, 병렬 의사코드가 약간의 개선을 보였지만 그 효과는 제한적이었다. 이는 현재 LLM이 코드 구조를 파악하고 병렬화 전략을 스스로 도출하는 능력이 아직 미숙함을 시사한다.

코드 복잡도 측면에서는 Gemini‑3가 가장 많은 주석을 삽입해 가독성을 높였지만, 사이클로매틱 복잡도는 ChatGPT가 가장 낮았다. 순차 코드 프롬프트는 모델이 기존 구조를 그대로 유지하면서 병렬 구문을 삽입하도록 유도해, 결과적으로 제어 흐름이 복잡해지는 경향을 보였다.

스케일링 실험에서는 OpenMP이 128코어까지 거의 선형에 가까운 가속을 달성했으며, C++ Standard Parallelism도 유사한 강·약 스케일링을 보였다. HPX는 초기 오버헤드와 부적절한 task 분할 때문에 32코어 이후 가속이 급격히 감소했으며, 특히 Conjugate Gradient에서 데이터 의존성 관리가 부실해 성능이 크게 뒤처졌다.

전체적으로 이 연구는 LLM이 병렬 코드 자동 생성에 어느 정도 가능성을 보여주지만, 프레임워크별 추상화 수준, 문제 복잡도, 그리고 인간의 사후 수정이 결과 품질에 결정적인 영향을 미친다는 점을 강조한다. 특히 HPX와 같은 고급 비동기 런타임에 대한 모델의 이해도가 낮으며, 향후 학습 데이터와 프롬프트 설계가 개선될 필요가 있다.