왜 이 주제가 중요한가요?
Rust를 배우다 보면 가장 먼저 부딪히는 벽 중 하나가 바로 소유권(ownership) 시스템이에요. 특히 "여러 곳에서 동시에 하나의 데이터를 읽고 쓰고 싶다"는 아주 흔한 요구사항이 Rust에서는 생각보다 까다롭거든요. 다른 언어에서는 그냥 전역 변수 하나 만들어서 아무 데서나 접근하면 되는데, Rust는 컴파일러가 "안 돼!"라고 막아버리니까요.
Rust의 Tokio 런타임 핵심 메인테이너인 Alice Ryhl이 정리한 이 글은, Rust에서 공유 가변 상태(shared mutable state) 를 다루는 대표적인 패턴 세 가지를 아주 깔끔하게 정리하고 있어요. Rust를 실무에서 쓰거나 배우고 있는 분이라면 꼭 알아둬야 할 내용이에요.
먼저, "공유 가변 상태"가 뭔가요?
이게 뭐냐면, 프로그램 안에서 여러 부분(스레드, 비동기 태스크 등)이 같은 데이터에 접근하면서, 그 데이터를 읽기만 하는 게 아니라 바꾸기도 하는 상황을 말해요. 예를 들어, 채팅 서버를 만든다고 해볼게요. 현재 접속 중인 유저 목록을 여러 스레드에서 동시에 확인하고, 새 유저가 들어오면 추가하고, 나가면 제거해야 하잖아요? 이게 바로 공유 가변 상태예요.
C나 Java 같은 언어에서는 이걸 그냥 하게 내버려두고, 개발자가 알아서 락(lock)을 걸어야 해요. 문제는 실수로 락을 안 걸면 데이터 레이스(data race) 라는 버그가 생기는데, 이게 재현도 어렵고 디버깅도 지옥이거든요. Rust는 이런 버그를 컴파일 타임에 원천 차단하는 대신, 개발자가 명시적으로 안전한 패턴을 사용하도록 강제해요.
세 가지 핵심 패턴
1. Mutex: 자물쇠로 잠그기
가장 직관적인 방법이에요. Arc<Mutex<T>> 패턴이라고 부르는데요, 쉽게 말하면 이래요.
- Arc는 "여러 곳에서 같은 데이터를 가리킬 수 있게 해주는 스마트 포인터"예요. 참조 카운팅 방식으로 동작해서, 마지막으로 쓰는 곳이 없어질 때 자동으로 메모리를 정리해줘요.
- Mutex는 "한 번에 하나만 접근할 수 있게 해주는 자물쇠"예요. 데이터를 쓰려면 먼저 잠금을 획득해야 하고, 다른 누군가가 잠금을 갖고 있으면 기다려야 해요.
.await를 호출하거나 무거운 연산을 하면, 다른 스레드가 줄줄이 대기하게 되어서 성능이 뚝 떨어지거든요. 그래서 Tokio에서도 비동기 Mutex보다 표준 라이브러리의 동기 std::sync::Mutex를 먼저 고려하라고 권장해요. 잠금 구간이 짧으면 동기 Mutex로도 충분하고, 오히려 오버헤드가 적어요.2. 채널(Channel): 메시지로 소통하기
Go 언어의 유명한 격언 중에 "메모리를 공유해서 소통하지 말고, 소통해서 메모리를 공유하라"는 말이 있죠? Rust에서도 같은 철학을 Tokio의 mpsc 채널로 구현할 수 있어요.
이게 뭐냐면, 데이터를 직접 공유하는 대신, 데이터를 관리하는 전담 태스크를 하나 띄우고, 다른 태스크들은 그 전담 태스크에게 "이거 해줘"라는 메시지를 보내는 방식이에요. 마치 은행 창구처럼, 고객(요청하는 쪽)이 직접 금고에 손을 대는 게 아니라 창구 직원(전담 태스크)에게 요청하는 거죠.
이 패턴의 장점은 데이터에 접근하는 곳이 딱 한 군데뿐이라 Mutex 자체가 필요 없다는 거예요. 동시성 버그가 구조적으로 발생할 수 없죠. 단점은 메시지를 보내고 응답을 기다리는 과정에서 약간의 지연이 생길 수 있고, 코드가 조금 더 길어진다는 점이에요.
3. Atomic: 잠금 없이 직접 바꾸기
정수 카운터처럼 아주 단순한 데이터를 공유할 때는 Mutex나 채널 없이도 가능해요. Atomic 타입을 쓰면 되는데, 이건 CPU 수준에서 "읽고-바꾸기"를 하나의 원자적 연산으로 처리해주는 특별한 타입이에요. 쉽게 말하면, 중간에 끼어들 틈이 없을 만큼 빠르고 작은 연산이라 잠금이 필요 없는 거예요.
AtomicU64, AtomicBool 같은 타입들이 있고, 방문자 수 카운터나 플래그 값처럼 단순한 상태를 공유할 때 성능상 가장 유리해요. 하지만 복잡한 구조체나 컬렉션에는 쓸 수 없으니, 용도가 제한적이에요.
어떤 패턴을 언제 써야 할까?
이 세 가지 패턴은 서로 대체재라기보다 상황에 따라 맞는 도구가 다른 거예요. 간단히 정리하면 이런 느낌이에요.
단순한 숫자나 불린 값 하나를 공유할 때는 Atomic이 가장 가볍고 빨라요. 여러 필드가 있는 구조체를 공유하는데 접근 시간이 짧다면 Mutex가 적절하고요. 상태 관리 로직이 복잡하거나, 상태 변경에 따른 부수 효과(다른 곳에 알림 보내기 등)가 있다면 채널 + 전담 태스크 패턴이 가장 깔끔해요.
실제 프로덕션 코드에서는 이 세 가지를 섞어서 쓰는 경우도 많아요. 예를 들어, 메인 상태는 채널 패턴으로 관리하면서, 단순 통계 카운터는 Atomic으로 따로 두는 식이죠.
다른 언어와 비교해보면
Go에서는 sync.Mutex와 고루틴+채널이 비슷한 역할을 해요. 하지만 Go는 데이터 레이스를 컴파일 타임에 잡아주지 않아서, -race 플래그로 런타임에 검출해야 해요. Rust는 이걸 컴파일러가 원천 차단하는 점이 핵심 차이예요.
Java에서는 synchronized, ReentrantLock, ConcurrentHashMap, AtomicLong 등 비슷한 도구들이 있는데, 역시 잘못 쓰면 런타임에서야 문제가 드러나요. Rust의 타입 시스템은 이런 실수를 구조적으로 방지해주는 셈이에요.
C++에서는 std::mutex, std::atomic이 있지만, 실수로 잠금 없이 접근해도 컴파일러가 아무 말도 안 해요. Rust만의 독보적인 강점이 바로 여기에 있어요.
한국 개발자에게 주는 시사점
Rust가 국내에서도 점점 채택이 늘고 있는데요, 특히 고성능 서버, 시스템 프로그래밍, WebAssembly 쪽에서 많이 쓰이고 있죠. 이 글에서 다루는 패턴들은 Rust로 실제 서비스를 만들 때 거의 반드시 마주치는 상황이에요.
Tokio 기반 비동기 서버를 만들고 있다면, 이 세 가지 패턴을 확실히 이해하고 있어야 코드 리뷰에서도 "왜 여기서 Mutex 대신 채널을 썼는지" 같은 설계 판단을 할 수 있어요. 특히 Alice Ryhl은 Tokio의 핵심 개발자이기 때문에, 이 글의 권장 사항은 Tokio 생태계의 모범 사례라고 봐도 무방해요.
한줄 정리
Rust에서 공유 가변 상태를 다루는 건 "Mutex, 채널, Atomic" 세 가지 도구를 상황에 맞게 고르는 문제이고, 컴파일러가 잘못된 선택을 막아준다는 게 Rust의 핵심 가치예요.
여러분은 실무에서 동시성 데이터 공유 문제를 어떤 방식으로 해결하고 계신가요? Rust의 접근법이 다른 언어 대비 실제로 버그를 줄여주는 경험을 하신 분이 있다면 이야기 나눠봐요!
🔗 출처: Hacker News
"비전공 직장인인데 반년 만에 수익 파이프라인을 여러 개 만들었습니다"
실제 수강생 후기- 비전공자도 6개월이면 첫 수익
- 20년 경력 개발자 직강
- 자동화 프로그램 + 소스코드 제공
