---
title: "C/C++ 컴파일러의 느슨한 메모리 동시성 버그를 자동으로 잡는 박사논문"
published: 2026-05-19T22:17:57.000Z
canonical: https://jeff.news/article/3014
---
# C/C++ 컴파일러의 느슨한 메모리 동시성 버그를 자동으로 잡는 박사논문

C와 C++ 컴파일러에서 relaxed memory 동시성 버그를 찾는 자동 테스트 프레임워크를 다룬 박사논문이 공개됐어. Téléchat, Atomic-mixer 같은 도구로 소스 수준 동작과 컴파일된 프로그램 동작을 비교하고, LLVM과 GCC 툴체인에서 실제 버그를 찾아낸 내용이 핵심이야.

- C/C++ 컴파일러에서 relaxed memory 동시성 버그를 자동으로 찾는 박사논문이 공개됨
  - 제목은 `Detecting Relaxed Memory Concurrency Bugs in C and C++ Compilers`
  - UCL에서 출판됐고 DOI는 `10.14324/000.th.10224678`
  - 핵심은 “소스 코드의 동시성 의미”와 “컴파일된 바이너리의 실제 동작”이 어긋나는 지점을 자동으로 잡는 것임

- 첫 번째 축은 Téléchat이라는 도구임
  - 이 도구는 소스 수준 모델과 아키텍처 수준 모델을 같이 써서, 컴파일 전후 프로그램이 허용하는 동작을 비교함
  - 단순히 테스트 케이스를 많이 돌리는 게 아니라, C/C++ memory model과 실제 CPU architecture model 사이의 의미 차이를 확인하는 쪽에 가까움
  - 논문에 따르면 Téléchat은 이미 여러 개의 새로운 compiler concurrency bug를 찾아냈음

- 두 번째 축은 Mix testing이고, 구현 도구는 Atomic-mixer임
  - 여기서 보는 건 compiler mapping의 상호운용성임
  - 예를 들어 atomic 연산을 어떤 명령어 조합으로 낮출지 정하는 방식이 컴파일러나 설정마다 다를 수 있는데, 이 조합들이 섞였을 때도 안전한지 보는 거임
  - Atomic-mixer는 새로운 mixing bug를 찾아냈고, Arm 엔지니어들과 Atomics Application Binary Interface를 개발하는 데도 쓰였음

> [!IMPORTANT]
> 이 연구가 흥미로운 이유는 “동시성 버그를 찾았다”가 아니라, C/C++ atomics가 컴파일러와 CPU 아키텍처 경계를 지나도 의미를 유지하는지 자동으로 검증하려 했다는 점임.

- 마지막으로 Téléchat을 자동 테스트에 배치해서 LLVM과 GCC 툴체인의 상태를 살펴봄
  - 논문은 현재 도구와 모델이 어디까지 버티고, 어디서 한계를 드러내는지도 같이 다룸
  - LLVM과 GCC는 사실상 현대 C/C++ 생태계의 양대 축이라, 여기서 발견되는 문제는 특정 연구실 장난감 수준이 아님
  - 특히 relaxed memory는 성능 때문에 쓰지만 디버깅 난이도는 미친 듯이 올라가는 영역이라, 컴파일러 정확성 검증이 더 중요해짐

- 한국 개발자 입장에서는 커널, 런타임, DB, 고성능 서버 코드를 다루는 사람에게 직접적으로 와닿는 주제임
  - 일반 웹 백엔드에서는 매일 만질 일은 적지만, lock-free 구조나 native extension, 임베디드, 게임 서버, 스토리지 엔진 쪽에서는 얘기가 달라짐
  - “컴파일러가 알아서 잘해주겠지”라고 넘기기엔 C/C++ memory model은 너무 날카로운 영역임

---
## 기술 맥락

- 이 논문이 잡으려는 문제는 C/C++ atomics가 컴파일러를 통과하면서 의미를 잃는 경우예요. relaxed memory는 원래도 허용 동작이 넓어서, 소스에서는 괜찮아 보이는 코드가 특정 아키텍처 매핑에서 이상하게 깨질 수 있거든요.

- Téléchat의 선택이 중요한 건 소스 모델과 아키텍처 모델을 같이 비교하기 때문이에요. 그냥 실행 결과만 보는 테스트는 희귀한 interleaving을 놓치기 쉬운데, 모델 기반 비교는 “이 동작이 애초에 허용되는가”를 더 직접적으로 따질 수 있어요.

- Atomic-mixer가 보는 영역은 더 실전적이에요. 실제 시스템에서는 서로 다른 컴파일러, 라이브러리, ABI 경계가 섞일 수 있고, atomic mapping이 따로 놀면 같은 바이너리 안에서도 동시성 보장이 흔들릴 수 있거든요.

- LLVM과 GCC에 자동 테스트를 적용했다는 점도 커요. 이건 논문용 미니 컴파일러 검증이 아니라, 현실에서 수많은 프로젝트가 기대고 있는 툴체인의 correctness를 겨냥한 작업이기 때문이에요.

## 핵심 포인트

- C/C++ 컴파일러의 동시성 관련 컴파일 정확성을 자동으로 검증하는 연구
- Téléchat은 소스 모델과 아키텍처 모델을 비교해 새 동시성 버그를 발견
- Atomic-mixer는 compiler mapping 상호운용성을 테스트하고 Arm 엔지니어들과 Atomics ABI 개발에도 사용됨
- LLVM과 GCC 자동 테스트에 적용하면서 현재 도구와 모델의 한계도 드러냄

## 인사이트

C/C++ atomics는 이미 어렵고, relaxed memory까지 가면 컴파일러가 맞게 변환했는지 사람이 눈으로 확인하기 거의 불가능해져. 이 연구는 그 지점을 자동화된 테스트 대상으로 끌어내렸다는 점에서 컴파일러, 런타임, 저수준 시스템 개발자에게 꽤 중요한 작업이야.
