Rust의 동시성은 왜 안전한가요?

소유권 시스템으로 컴파일 시점에 데이터 레이스를 방지합니다.

Arc는 왜 필요한가요?

여러 스레드에서 동일한 데이터를 공유하려면 원자적 참조 카운팅이 필요합니다.

Channel은 언제 사용하나요?

스레드 간 메시지를 전달할 때 사용합니다. 공유 메모리보다 안전합니다.

Rust 동시성 | Thread, Channel, Arc, Mutex

2026년 3월 29일 · 26분 읽기 · 수정 2026년 4월 18일 고급 튜토리얼

이 글의 핵심

use std::thread; use std::time::Duration;.

시리즈 안내

#07 | 📋 전체 목차 | 이전: #06 컬렉션 · 다음: #08 비동기

들어가며

Rust는 데이터 레이스를 컴파일 단계에서 막는 쪽에 가깝습니다. 스레드 간 공유는 `Arc`·`Mutex`로, 메시지 전달은 채널로 처리하는 패턴이 흔합니다. 공유 자원의 열쇠를 누가 쥐는지가 여전히 소유권 규칙과 연결됩니다. Go의 고루틴·채널도 “통신으로 동기화” 쪽에 서고, Kotlin 코루틴은 스레드 풀·디스패처 위에서 협력적으로 돌아갑니다. OS 스레드를 직접 다루는 흐름은 Java `Thread`·C++ `std::thread`와 나란히 보면 좋습니다.

1. 스레드

일상 비유로 이해하기: 동시성은 주방에서 여러 요리를 동시에 하는 것과 비슷합니다. 한 명의 요리사(싱글 스레드)가 국을 끓이다가 불을 줄이고, 그 사이에 야채를 썰고, 다시 국을 확인하는 식이죠. 반면 병렬성은 요리사 여러 명(멀티 스레드)이 각자 다른 요리를 동시에 만드는 겁니다. (Thread)

기본 스레드

// 실행 예제
use std::thread;
use std::time::Duration;
fn main() {
    let handle = thread::spawn(|| {
        for i in 1..10 {
            println!("스레드: {}", i);
            thread::sleep(Duration::from_millis(100));
        }
    });
    
    for i in 1..5 {
        println!("메인: {}", i);
        thread::sleep(Duration::from_millis(100));
    }
    
    handle.join().unwrap();
}

데이터 전달

use std::thread;
fn main() {
    let v = vec![1, 2, 3];
    
    let handle = thread::spawn(move || {
        println!("벡터: {:?}", v);
    });
    
    handle.join().unwrap();
    
    // v는 더 이상 사용 불가 (소유권 이동)
}

2. 채널 (Channel)

기본 채널

use std::sync::mpsc;
use std::thread;
fn main() {
    let (tx, rx) = mpsc::channel();
    
    thread::spawn(move || {
        let val = String::from("안녕하세요");
        tx.send(val).unwrap();
    });
    
    let received = rx.recv().unwrap();
    println!("받음: {}", received);
}

여러 메시지

// 실행 예제
use std::sync::mpsc;
use std::thread;
use std::time::Duration;
fn main() {
    let (tx, rx) = mpsc::channel();
    
    thread::spawn(move || {
        let vals = vec![
            String::from("hi"),
            String::from("from"),
            String::from("the"),
            String::from("thread"),
        ];
        
        for val in vals {
            tx.send(val).unwrap();
            thread::sleep(Duration::from_millis(100));
        }
    });
    
    for received in rx {
        println!("받음: {}", received);
    }
}

여러 송신자

use std::sync::mpsc;
use std::thread;
fn main() {
    let (tx, rx) = mpsc::channel();
    let tx2 = tx.clone();
    
    thread::spawn(move || {
        tx.send(String::from("스레드 1")).unwrap();
    });
    
    thread::spawn(move || {
        tx2.send(String::from("스레드 2")).unwrap();
    });
    
    for received in rx {
        println!("받음: {}", received);
    }
}

3. Arc와 Mutex

Mutex (상호 배제)

use std::sync::Mutex;
fn main() {
    let m = Mutex::new(5);
    
    {
        let mut num = m.lock().unwrap();
        *num = 6;
    }  // 락 해제
    
    println!("m = {:?}", m);
}

Arc + Mutex

use std::sync::{Arc, Mutex};
use std::thread;
fn main() {
    let counter = Arc::new(Mutex::new(0));
    let mut handles = vec![];
    
    for _ in 0..10 {
        let counter = Arc::clone(&counter);
        let handle = thread::spawn(move || {
            let mut num = counter.lock().unwrap();
            *num += 1;
        });
        handles.push(handle);
    }
    
    for handle in handles {
        handle.join().unwrap();
    }
    
    println!("결과: {}", *counter.lock().unwrap());  // 10
}

4. 실전 예제

예제: 병렬 계산

use std::thread;
use std::sync::{Arc, Mutex};
fn parallel_sum(numbers: Vec<i32>) -> i32 {
    let chunk_size = numbers.len() / 4;
    let numbers = Arc::new(numbers);
    let result = Arc::new(Mutex::new(0));
    let mut handles = vec![];
    
    for i in 0..4 {
        let numbers = Arc::clone(&numbers);
        let result = Arc::clone(&result);
        
        let handle = thread::spawn(move || {
            let start = i * chunk_size;
            let end = if i == 3 { numbers.len() } else { (i + 1) * chunk_size };
            
            let sum: i32 = numbers[start..end].iter().sum();
            
            let mut total = result.lock().unwrap();
            *total += sum;
        });
        
        handles.push(handle);
    }
    
    for handle in handles {
        handle.join().unwrap();
    }
    
    *result.lock().unwrap()
}
fn main() {
    let numbers: Vec<i32> = (1..=1000).collect();
    let sum = parallel_sum(numbers);
    println!("합계: {}", sum);  // 500500
}

실전 심화 보강

실전 예제: 데이터 청크를 스레드로 나누어 합산 (표준 라이브러리만)

std::mpsc::Receiver는 복제할 수 없어 “여러 워커가 한 큐를 나눠 먹기” 패턴을 그대로 구현하기 어렵습니다. 그 대신 데이터를 미리 청크로 나눈 뒤 스레드마다 한 청크만 처리하면 동일한 효과를 얻을 수 있습니다.

use std::thread;
fn parallel_sum(nums: Vec<i32>, workers: usize) -> i32 {
    assert!(workers > 0);
    let chunk_size = (nums.len() + workers - 1) / workers;
    let chunks: Vec<Vec<i32>> = nums
        .chunks(chunk_size.max(1))
        .map(|c| c.to_vec())
        .collect();
    let handles: Vec<_> = chunks
        .into_iter()
        .map(|chunk| {
            thread::spawn(move || chunk.iter().copied().sum::<i32>())
        })
        .collect();
    handles.into_iter().map(|h| h.join().unwrap()).sum()
}
fn main() {
    let nums: Vec<i32> = (1..=10_000).collect();
    let total = parallel_sum(nums, 4);
    println!("합계: {}", total);
}

자주 하는 실수

Mutex 락을 잡은 채로 I/O를 하여 다른 스레드를 굶기는 경우.
Arc 없이 스레드 간 데이터 공유를 시도하는 경우.
데드락: 두 개 이상의 뮤텍스를 서로 다른 순서로 잠그는 경우.

주의사항

Mutex의 lock() 실패(panic)는 포이즌 상태를 의미할 수 있습니다.
Send/Sync 제약을 이해하지 못해 클로저 캡처에서 막히는 경우가 많습니다.

실무에서는 이렇게

CPU 병렬은 rayon, I/O 동시성은 tokio로 역할을 나눕니다.
공유 상태 최소화를 위해 메시지 패싱 우선을 고려합니다.

비교 및 대안

도구	용도
OS 스레드	CPU 바운드, 격리
Tokio task	I/O 대기 많음
프로세스 분리	강한 격리·크래시 내성

추가 리소스

내부 동작과 핵심 메커니즘

이 글의 주제는 「Rust 동시성 | Thread, Channel, Arc, Mutex」입니다. 여기서는 앞선 설명을 구현·런타임 관점에서 한 번 더 압축합니다. 시스템·런타임 경계(스케줄링, I/O, 메모리, 동시성)를 기준으로 생각하면, “입력이 어디서 검증되고, 핵심 연산이 어디서 일어나며, 부작용(I/O·네트워크·디스크)이 어디서 터지는가”가 한눈에 드러납니다.

처리 파이프라인(개념도)

flowchart TD
  A[입력·요청·이벤트] --> B[파싱·검증·디코딩]
  B --> C[핵심 연산·상태 전이]
  C --> D[부작용: I/O·네트워크·동시성]
  D --> E[결과·관측·저장]

알고리즘·프로토콜 관점에서의 체크포인트

불변 조건(Invariant): 각 단계가 만족해야 하는 조건(예: 버퍼 경계, 프로토콜 상태, 트랜잭션 격리)을 문장으로 적어 두면 디버깅 비용이 줄어듭니다.
결정성: 동일 입력에 동일 출력이 보장되는 순수한 층과, 시간·네트워크에 의해 달라질 수 있는 층을 분리해야 테스트와 장애 분석이 쉬워집니다.
경계 비용: 직렬화/역직렬화, 문자 인코딩, syscall 횟수, 락 경합처럼 “한 번의 호출이 아니라 누적되는 비용”을 의심 목록에 넣습니다.

프로덕션 운영 패턴

실서비스에서는 기능 구현과 함께 관측·배포·보안·비용이 동시에 요구됩니다. 아래는 팀에서 자주 쓰는 최소 체크리스트입니다.

영역	운영 관점에서의 질문
관측성	요청 단위 상관 ID, 에러율/지연 분위수, 주요 의존성 타임아웃이 보이는가
안전성	입력 검증·권한·비밀 관리가 코드 경로마다 일관적인가
신뢰성	재시도는 멱등한 연산에만 적용되는가, 서킷 브레이커·백오프가 있는가
성능	캐시 계층·배치 크기·풀링·백프레셔가 데이터 규모에 맞는가
배포	롤백 룬북, 카나리, 마이그레이션 호환성이 문서화되어 있는가

운영 환경에서는 “개발자 PC에서는 재현되지 않던 문제”가 시간·부하·데이터 크기 때문에 드러납니다. 따라서 스테이징의 데이터 양·네트워크 지연을 가능한 한 현실에 가깝게 맞추는 것이 중요합니다.

문제 해결(Troubleshooting)

증상	가능 원인	조치
간헐적 실패	레이스 컨디션, 타임아웃, 외부 의존성 불안정	최소 재현 스크립트 작성, 분산 트레이스·로그 상관관계 확인
성능 저하	N+1 쿼리, 동기 I/O, 잠금 경합, 과도한 직렬화	프로파일러·APM으로 핫스팟 확인 후 한 가지씩 제거
메모리 증가	캐시 무제한, 클로저/이벤트 구독 누수, 대용량 객체의 불필요한 복사	상한·TTL·스냅샷 비교(힙 덤프/트레이스)
빌드·배포만 실패	환경 변수·권한·플랫폼 차이	CI 로그와 로컬 `diff`, 컨테이너/런타임 버전 핀(pin)

권장 디버깅 순서: (1) 최소 재현 만들기 (2) 최근 변경 범위 좁히기 (3) 의존성·환경 변수 차이 확인 (4) 관측 데이터로 가설 검증 (5) 수정 후 회귀·부하 테스트.

정리

핵심 요약

thread::spawn: 스레드 생성
mpsc::channel: 스레드 간 통신
Arc: 원자적 참조 카운팅 (여러 스레드 공유)
Mutex: 상호 배제 (동시 접근 방지)
join: 스레드 완료 대기

다음 단계

자주 묻는 질문 (FAQ)

Q. 이 내용을 실무에서 언제 쓰나요?

A. Rust 동시성 use std::thread; use std::time::Duration;. 실전 예제와 코드로 개념부터 활용까지 정리합니다. Rust·동시성·Thread 중심으로 설명합니다. Start now. 실무에서는 위 본문의 예제와 선택 가이드를 참고해 적용하면 됩니다.

Q. 선행으로 읽으면 좋은 글은?

A. 각 글 하단의 이전 글 또는 관련 글 링크를 따라가면 순서대로 배울 수 있습니다. C++ 시리즈 목차에서 전체 흐름을 확인할 수 있습니다.

Q. 더 깊이 공부하려면?

A. cppreference와 해당 라이브러리 공식 문서를 참고하세요. 글 말미의 참고 자료 링크도 활용하면 좋습니다.

같이 보면 좋은 글 (내부 링크)

이 주제와 연결되는 다른 글입니다.

이 글에서 다루는 키워드 (관련 검색어)

Rust, 동시성, Thread, Concurrency 등으로 검색하시면 이 글이 도움이 됩니다.

이 글이 도움이 되셨나요?

여러분의 피드백은 더 나은 콘텐츠를 만드는 데 도움이 됩니다

문제가 있거나 개선 제안이 있으시면 연락처로 알려주세요.