Rust에서 데드락을 원천 차단하는 Surelock — 뮤텍스의 고질적 문제를 해결할 수 있을까?

데드락, 멀티스레드 프로그래밍의 오래된 악몽

멀티스레드 프로그래밍을 해본 분이라면 "데드락(deadlock)"이라는 단어만 들어도 머리가 아플 거예요. 데드락이 뭐냐면, 두 개 이상의 스레드가 서로가 가진 자원을 기다리면서 영원히 멈춰버리는 상황이에요. 비유하자면, 좁은 골목에서 두 사람이 마주 보고 서서 "당신이 먼저 비켜요"라고 하면서 둘 다 안 움직이는 것과 비슷하죠.

이 문제를 해결하기 위해 프로그래밍 언어마다 다양한 방법을 제공하는데요, Rust는 특히 "안전한 동시성(concurrency)"을 핵심 가치로 내세우는 언어예요. 컴파일러가 데이터 레이스(여러 스레드가 동시에 같은 데이터에 접근하는 문제)를 잡아주거든요. 그런데 아이러니하게도, Rust의 표준 라이브러리에 있는 Mutex(뮤텍스)를 쓰면 데드락은 여전히 발생할 수 있어요. Rust 컴파일러가 데이터 레이스는 잡아줘도 데드락까지는 못 잡거든요.

바로 이 문제를 정면으로 해결하겠다고 나선 라이브러리가 Surelock이에요.

Surelock이 데드락을 막는 원리

뮤텍스가 뭔지 먼저 간단히 짚고 넘어갈게요. 뮤텍스는 "이 데이터는 한 번에 하나의 스레드만 접근할 수 있어요"라고 잠금을 거는 장치예요. 화장실 문에 잠금장치 달린 것처럼, 한 사람이 쓰고 있으면 다른 사람은 밖에서 기다려야 하는 거죠.

문제는 뮤텍스를 여러 개 쓸 때 생겨요. 스레드 A가 뮤텍스 1을 잠그고 뮤텍스 2를 기다리는데, 스레드 B는 뮤텍스 2를 잠그고 뮤텍스 1을 기다리면? 둘 다 영원히 기다리게 돼요. 이게 데드락이에요.

Surelock은 이 문제를 잠금 순서(lock ordering)를 강제하는 방식으로 해결해요. 이게 뭐냐면, 모든 뮤텍스에 번호를 매기고, 항상 번호가 작은 것부터 먼저 잠그도록 규칙을 만드는 거예요. 아까 좁은 골목 비유로 돌아가면, "왼쪽에 있는 사람이 항상 먼저 지나간다"라는 규칙을 정해놓으면 교착 상태가 안 생기는 것과 같은 원리죠.

컴퓨터 과학에서는 이걸 "전순서(total ordering)"라고 부르는데요, 데드락이 발생하려면 "순환 대기(circular wait)" 조건이 필요한데, 잠금 순서를 강제하면 이 순환 자체가 만들어질 수 없어요. 수학적으로 증명된 방법이에요.

기존 Rust Mutex와 뭐가 다른가요?

Rust 표준 라이브러리의 std::sync::Mutex는 사용법이 꽤 단순해요. .lock()을 호출하면 잠금을 얻고, 스코프를 벗어나면 자동으로 풀려요. 하지만 여러 뮤텍스를 어떤 순서로 잠글지는 전적으로 개발자의 책임이에요. 실수하면 데드락이 나고, 이런 버그는 재현도 어렵고 디버깅은 더 어려워요.

Surelock은 API 레벨에서부터 이걸 다르게 설계했어요. 뮤텍스를 생성할 때 순서(레벨)를 지정하고, 잘못된 순서로 잠그려고 하면 컴파일 타임이나 런타임에 에러를 발생시키는 구조예요. 즉, "실수할 수 있는 여지 자체를 없애겠다"는 철학인 거죠. Rust가 메모리 안전성에서 추구하는 철학과 정확히 같은 방향이에요.

일반적으로 이런 안전장치를 추가하면 성능이 떨어지지 않을까 걱정할 수 있는데요, 잠금 순서 검증은 대부분 컴파일 타임이나 잠금 획득 시점에 한 번만 체크하면 되기 때문에, 실제 잠금/해제 과정의 성능 오버헤드는 미미한 수준이에요.

경쟁 프로젝트와의 비교

Rust 생태계에서 동시성 안전을 위한 시도가 Surelock만 있는 건 아니에요. parking_lot은 표준 뮤텍스보다 빠른 성능을 제공하는 인기 있는 대안이지만, 데드락 방지 자체를 목표로 하진 않아요. tracing-mutex는 런타임에 잠금 순서를 추적해서 데드락 가능성을 탐지하는 디버깅 도구에 가깝고요.

Surelock의 차별점은 데드락 방지를 설계 단계에서 강제한다는 거예요. 디버깅 도구가 아니라 아예 잘못된 코드를 작성할 수 없게 만드는 거죠. 이건 Rust의 소유권(ownership) 시스템이 메모리 버그를 "런타임에 잡는" 게 아니라 "애초에 작성 못하게 하는" 것과 같은 접근 방식이에요.

다른 언어에서는 어떻게 하고 있을까요? Java에서는 ReentrantLock과 함께 잠금 순서를 수동으로 관리하는 게 일반적이고, Go에서는 sync.Mutex를 쓰면서 데드락 감지를 런타임 도구에 의존해요. C++에서는 std::lock으로 여러 뮤텍스를 동시에 잠그는 방법이 있지만, 이것도 개발자가 명시적으로 써야 하는 거라 실수 가능성이 여전히 존재하죠. 타입 시스템 레벨에서 강제하는 Surelock의 접근은 꽤 참신한 편이에요.