Rust 소유권 에러 디버깅 실전 사례 | 'borrow checker가 막아요' 해결기
이 글의 핵심
Rust 초보자가 자주 겪는 소유권, 빌림, 수명 에러를 실전 사례로 해결하는 방법. borrow checker 에러 메시지 읽는 법부터 RefCell, Rc, Arc 활용까지 다룹니다.
들어가며
“C++에서는 되는데 Rust에서는 왜 안 되나요?” Rust를 처음 배울 때 가장 많이 하는 말입니다. 이 글에서는 실제로 겪은 소유권 에러 사례를 통해 borrow checker를 이해하고 해결하는 방법을 다룹니다.
일상에 빗대면, 도서관 책을 빌린 상태에서 표지를 뜯어 가져오려는 것과 비슷합니다. 빌린 것은 반납할 때까지 통째로 있어야 하고, 필요하면 복사본을 새로 만들거나 참조만 읽어야 합니다.
이 글을 읽으면
- Borrow checker 에러 메시지를 읽는 법을 배웁니다
- 소유권, 빌림, 수명의 관계를 실전에서 이해합니다
- RefCell, Rc, Arc 등 해결 패턴을 익힙니다
- Rust의 메모리 안전성을 활용하는 방법을 습득합니다
실전 경험에서 배운 교훈
이 기술을 실무 프로젝트에 처음 도입했을 때, 공식 문서만으로는 알 수 없었던 많은 함정들이 있었습니다. 특히 프로덕션 환경에서 발생하는 엣지 케이스들은 로컬 개발 환경에서는 재현조차 되지 않았죠.
가장 어려웠던 점은 성능 최적화였습니다. 처음엔 “동작만 하면 되겠지”라고 생각했지만, 실제 사용자 트래픽이 몰리면서 병목 지점들이 하나씩 드러났습니다. 특히 데이터베이스 쿼리 최적화, 캐싱 전략, 에러 핸들링 구조 등은 여러 번의 장애를 겪으면서 개선해 나갔습니다.
이 글에서는 그런 시행착오를 통해 얻은 실전 노하우와, “이렇게 하면 안 된다”는 교훈들을 함께 정리했습니다. 특히 트러블슈팅 섹션은 실제 장애 대응 경험을 바탕으로 작성했으니, 비슷한 문제를 마주했을 때 참고하시면 도움이 될 것입니다.
1. 사례 1: “cannot move out of borrowed content”
이 사례의 흐름은 (1) 컴파일러가 빌린 user에서 필드를 옮기려 한 것을 막고, (2) 참조로 읽거나, clone으로 복사해 소유권을 분리하는 순서로 해결합니다.
문제 코드
struct User {
name: String,
email: String,
}
fn process_users(users: &Vec<User>) {
for user in users {
let name = user.name; // ❌ cannot move out of `user.name`
println!("Processing: {}", name);
}
}에러 메시지
error[E0507]: cannot move out of `user.name` which is behind a shared reference
--> src/main.rs:8:20
|
8 | let name = user.name;
| ^^^^^^^^^ move occurs because `user.name` has type `String`, which does not implement the `Copy` trait왜 에러인가?
users는 불변 참조 (&Vec<User>)user.name은String(소유권 타입)let name = user.name은 소유권 이동을 시도- 하지만 빌린 데이터에서는 소유권을 가져올 수 없음!
해결 방법
// 방법 1: 참조만 사용
fn process_users(users: &Vec<User>) {
for user in users {
let name = &user.name; // ✅ 참조
println!("Processing: {}", name);
}
}
// 방법 2: 복사
fn process_users(users: &Vec<User>) {
for user in users {
let name = user.name.clone(); // ✅ 복사
println!("Processing: {}", name);
}
}
// 방법 3: 소유권 받기
fn process_users(users: Vec<User>) { // &를 제거
for user in users {
let name = user.name; // ✅ 소유권 이동
println!("Processing: {}", name);
}
}2. 사례 2: “cannot borrow as mutable more than once”
문제 코드
struct ChatRoom {
users: Vec<User>,
messages: Vec<String>,
}
impl ChatRoom {
fn broadcast(&mut self, sender: &User) {
let msg = format!("{}: Hello", sender.name);
// ❌ cannot borrow `self` as mutable more than once
for user in &mut self.users {
self.messages.push(msg.clone()); // 💥 두 번째 가변 빌림!
}
}
}에러 메시지
error[E0499]: cannot borrow `self.messages` as mutable more than once at a time
--> src/main.rs:12:13
|
10 | for user in &mut self.users {
| --------------- first mutable borrow occurs here
11 | self.messages.push(msg.clone());
| ^^^^^^^^^^^^^ second mutable borrow occurs here왜 에러인가?
&mut self.users로 첫 번째 가변 빌림self.messages.push()로 두 번째 가변 빌림 시도- Rust는 동시에 하나의 가변 참조만 허용
해결 방법
다음은 broadcast 함수의 Rust 구현 예제입니다.
// 방법 1: 필드 분리 빌림
impl ChatRoom {
fn broadcast(&mut self, sender: &User) {
let msg = format!("{}: Hello", sender.name);
// users와 messages를 따로 빌림
let users = &mut self.users;
let messages = &mut self.messages;
for user in users {
messages.push(msg.clone()); // ✅ 다른 필드
}
}
}
// 방법 2: 반복 전에 메시지 생성
impl ChatRoom {
fn broadcast(&mut self, sender: &User) {
let msg = format!("{}: Hello", sender.name);
self.messages.push(msg.clone()); // 먼저 추가
for user in &mut self.users {
// messages는 더 이상 빌리지 않음
user.notify();
}
}
}
// 방법 3: 인덱스 사용
impl ChatRoom {
fn broadcast(&mut self, sender: &User) {
let msg = format!("{}: Hello", sender.name);
for i in 0..self.users.len() {
self.messages.push(msg.clone()); // ✅ 인덱스는 빌림 아님
}
}
}3. 사례 3: “lifetime may not live long enough”
문제 코드
struct UserCache {
users: Vec<User>,
}
impl UserCache {
fn find(&self, name: &str) -> Option<&User> {
self.users.iter().find(|u| u.name == name)
}
fn get_or_create(&mut self, name: &str) -> &User {
// ❌ lifetime 에러
if let Some(user) = self.find(name) {
return user; // 💥 빌림이 살아있는데 &mut self 필요
}
self.users.push(User { name: name.to_string(), email: String::new() });
self.users.last().unwrap()
}
}에러 메시지
error[E0502]: cannot borrow `self.users` as mutable because it is also borrowed as immutable
--> src/main.rs:15:9
|
12 | if let Some(user) = self.find(name) {
| ---- immutable borrow occurs here
13 | return user;
| ---- returning this value requires that `*self` is borrowed for `'1`
...
15 | self.users.push(...);
| ^^^^^^^^^^^ mutable borrow occurs here해결 방법
// 방법 1: 인덱스 사용
impl UserCache {
fn get_or_create(&mut self, name: &str) -> &User {
// 먼저 인덱스 찾기
if let Some(idx) = self.users.iter().position(|u| u.name == name) {
return &self.users[idx]; // ✅ 새로운 빌림
}
self.users.push(User { name: name.to_string(), email: String::new() });
self.users.last().unwrap()
}
}
// 방법 2: Entry API (HashMap)
use std::collections::HashMap;
struct UserCache {
users: HashMap<String, User>,
}
impl UserCache {
fn get_or_create(&mut self, name: &str) -> &User {
self.users.entry(name.to_string())
.or_insert_with(|| User { name: name.to_string(), email: String::new() })
}
}4. 사례 4: “cannot return reference to local variable”
문제 코드
fn get_default_user() -> &User {
let user = User {
name: "Guest".to_string(),
email: "[email protected]".to_string(),
};
&user // ❌ user는 함수 끝에서 소멸
}에러 메시지
error[E0515]: cannot return reference to local variable `user`
--> src/main.rs:8:5
|
8 | &user
| ^^^^^ returns a reference to data owned by the current function해결 방법
// 방법 1: 소유권 반환
fn get_default_user() -> User {
User {
name: "Guest".to_string(),
email: "[email protected]".to_string(),
}
}
// 방법 2: 정적 수명
fn get_default_user() -> &'static User {
static DEFAULT: User = User {
name: String::new(), // ❌ const fn이 아니라 안 됨
};
&DEFAULT
}
// 방법 2-1: lazy_static 사용
use lazy_static::lazy_static;
lazy_static! {
static ref DEFAULT_USER: User = User {
name: "Guest".to_string(),
email: "[email protected]".to_string(),
};
}
fn get_default_user() -> &'static User {
&DEFAULT_USER
}
// 방법 3: Box로 힙 할당
fn get_default_user() -> Box<User> {
Box::new(User {
name: "Guest".to_string(),
email: "[email protected]".to_string(),
})
}5. 사례 5: 멀티스레드
일상 비유로 이해하기: 동시성은 주방에서 여러 요리를 동시에 하는 것과 비슷합니다. 한 명의 요리사(싱글 스레드)가 국을 끓이다가 불을 줄이고, 그 사이에 야채를 썰고, 다시 국을 확인하는 식이죠. 반면 병렬성은 요리사 여러 명(멀티 스레드)이 각자 다른 요리를 동시에 만드는 겁니다.
공유 상태 {#case-5}
문제 코드
use std::thread;
struct Counter {
count: i32,
}
fn main() {
let counter = Counter { count: 0 };
let handle = thread::spawn(|| {
counter.count += 1; // ❌ closure may outlive the current function
});
handle.join().unwrap();
}에러 메시지
error[E0373]: closure may outlive the current function, but it borrows `counter`, which is owned by the current function
--> src/main.rs:9:31
|
9 | let handle = thread::spawn(|| {
| ^^ may outlive borrowed value `counter`
10 | counter.count += 1;
| ------- `counter` is borrowed here해결 방법
// 방법 1: Arc + Mutex (멀티스레드 안전)
use std::sync::{Arc, Mutex};
use std::thread;
fn main() {
let counter = Arc::new(Mutex::new(0));
let counter_clone = Arc::clone(&counter);
let handle = thread::spawn(move || {
let mut count = counter_clone.lock().unwrap();
*count += 1;
});
handle.join().unwrap();
println!("Count: {}", *counter.lock().unwrap());
}
// 방법 2: 채널 사용 (메시지 전달)
use std::sync::mpsc;
fn main() {
let (tx, rx) = mpsc::channel();
thread::spawn(move || {
tx.send(1).unwrap();
});
let count = rx.recv().unwrap();
println!("Count: {}", count);
}
// 방법 3: 원자적 타입 (AtomicI32)
use std::sync::atomic::{AtomicI32, Ordering};
fn main() {
let counter = Arc::new(AtomicI32::new(0));
let counter_clone = Arc::clone(&counter);
let handle = thread::spawn(move || {
counter_clone.fetch_add(1, Ordering::SeqCst);
});
handle.join().unwrap();
println!("Count: {}", counter.load(Ordering::SeqCst));
}6. 패턴 정리: 언제 무엇을 쓰나
소유권 vs 빌림
| 상황 | 해결 방법 | 예시 |
|---|---|---|
| 읽기만 필요 | 불변 참조 &T | fn print(user: &User) |
| 수정 필요 | 가변 참조 &mut T | fn update(user: &mut User) |
| 소유권 필요 | 값 T | fn consume(user: User) |
| 복사 가능 | Copy 트레이트 | fn calc(x: i32) |
내부 가변성
| 타입 | 용도 | 스레드 안전 |
|---|---|---|
Cell<T> | Copy 타입 내부 가변성 | ❌ |
RefCell<T> | 런타임 빌림 검사 | ❌ |
Mutex<T> | 멀티스레드 가변성 | ✅ |
RwLock<T> | 읽기 많은 경우 | ✅ |
공유 소유권
| 타입 | 용도 | 스레드 안전 |
|---|---|---|
Rc<T> | 단일 스레드 공유 | ❌ |
Arc<T> | 멀티스레드 공유 | ✅ |
Weak<T> | 순환 참조 방지 | 상황에 따라 |
조합 패턴
Rust 예제 코드입니다.
// 단일 스레드: Rc + RefCell
use std::rc::Rc;
use std::cell::RefCell;
let shared = Rc::new(RefCell::new(vec![1, 2, 3]));
let clone = Rc::clone(&shared);
shared.borrow_mut().push(4);
println!("{:?}", clone.borrow()); // [1, 2, 3, 4]
// 멀티스레드: Arc + Mutex
use std::sync::{Arc, Mutex};
let shared = Arc::new(Mutex::new(vec![1, 2, 3]));
let clone = Arc::clone(&shared);
thread::spawn(move || {
clone.lock().unwrap().push(4);
});7. 실전 예제: 이벤트 시스템
C++ 스타일 (컴파일 안 됨)
struct EventManager {
listeners: Vec<Box<dyn Fn(&Event)>>,
}
impl EventManager {
fn subscribe(&mut self, callback: impl Fn(&Event) + 'static) {
self.listeners.push(Box::new(callback));
}
fn publish(&self, event: &Event) {
for listener in &self.listeners {
listener(event); // ✅ 이건 괜찮음
}
}
}
// 문제: 구독자가 EventManager를 수정하려 하면?
fn main() {
let mut mgr = EventManager { listeners: vec![] };
mgr.subscribe(|event| {
mgr.publish(event); // ❌ cannot borrow `mgr` as mutable
});
}Rust 스타일 (Rc + RefCell)
use std::rc::Rc;
use std::cell::RefCell;
struct EventManager {
listeners: Vec<Box<dyn Fn(&Event)>>,
}
fn main() {
let mgr = Rc::new(RefCell::new(EventManager { listeners: vec![] }));
let mgr_clone = Rc::clone(&mgr);
mgr.borrow_mut().subscribe(Box::new(move |event| {
// 클로저 내부에서 mgr_clone 사용
mgr_clone.borrow().publish(event);
}));
}8. 디버깅 팁
에러 메시지 읽는 법
error[E0502]: cannot borrow `x` as mutable because it is also borrowed as immutable
--> src/main.rs:10:5
|
8 | let r = &x;
| -- immutable borrow occurs here
9 |
10 | x.push(1);
| ^^^^^^^^^ mutable borrow occurs here
11 | println!("{}", r);
| - immutable borrow later used here읽는 순서:
- 에러 타입:
E0502(동시 빌림 불가) - 문제 위치: 10번 줄
- 원인: 8번 줄에서 불변 빌림
- 사용 위치: 11번 줄까지 사용
rustc —explain
$ rustc --explain E0502
This error indicates that you are trying to borrow a value as mutable when it
is already borrowed as immutable.
...Clippy 활용
$ cargo clippy
warning: this `RefCell` Ref is held across an 'await' point
--> src/main.rs:10:9
|
10 | let data = cell.borrow();
| ^^^^
|
= help: consider using a `Mutex` instead마무리
Rust의 borrow checker는 처음엔 답답하지만, 컴파일 타임에 메모리 안전성을 보장해줍니다. 이 사례들을 통해:
- 에러 메시지를 정확히 읽는 법을 배웠습니다
- 소유권, 빌림, 수명의 관계를 이해했습니다
- RefCell, Rc, Arc 등 해결 패턴을 익혔습니다
- C++와 다른 사고방식을 습득했습니다
핵심: Borrow checker와 싸우지 말고, Rust의 철학을 이해하고 따르세요.
FAQ
Q1. Rust는 C++보다 어려운가요?
초기 학습 곡선은 가파르지만, 익숙해지면 메모리 버그를 원천 차단할 수 있습니다.
Q2. RefCell을 남용하면 안 되나요?
RefCell은 런타임 검사이므로 panic 가능성이 있습니다. 가능하면 컴파일 타임 빌림을 사용하세요.
Q3. Arc<Mutex
네, 오버헤드가 있습니다. 필요한 곳에만 사용하고, 읽기가 많으면 RwLock을 고려하세요.
관련 글
실전 체크리스트
Borrow Checker 에러 해결 체크리스트
- 에러 메시지 정확히 읽기
- 빌림 범위 확인 (어디서 시작, 어디까지 사용)
- 소유권이 필요한지 참조만 필요한지 판단
- 가변/불변 빌림 구분
- 수명 관계 확인
- 적절한 패턴 선택 (Rc, RefCell, Arc, Mutex)
- Clippy로 추가 검사
멀티스레드 안전성 체크리스트
- Send/Sync 트레이트 확인
- Arc + Mutex 조합 고려
- 데드락 가능성 검토
- 채널 사용 고려
- 원자적 타입 활용
키워드
Rust, Ownership, 소유권, Borrow Checker, 빌림, Lifetime, 수명, RefCell, Rc, Arc, Mutex, 실전 사례, 디버깅, 에러 해결
심화 부록: 구현·운영 관점
이 부록은 앞선 본문에서 다룬 주제(「Rust 소유권 에러 디버깅 실전 사례 | ‘borrow checker가 막아요’ 해결기」)를 구현·런타임·운영 관점에서 다시 압축합니다. 도메인별 세부 구현은 글마다 다르지만, 입력 검증 → 핵심 연산 → 부작용(I/O·네트워크·동시성) → 관측의 흐름으로 장애를 나누면 원인 추적이 빨라집니다.
내부 동작과 핵심 메커니즘
flowchart TD A[입력·요청·이벤트] --> B[파싱·검증·디코딩] B --> C[핵심 연산·상태 전이] C --> D[부작용: I/O·네트워크·동시성] D --> E[결과·관측·저장]
sequenceDiagram participant C as 클라이언트/호출자 participant B as 경계(런타임·게이트웨이·프로세스) participant D as 의존성(API·DB·큐·파일) C->>B: 요청/이벤트 B->>D: 조회·쓰기·RPC D-->>B: 지연·부분 실패·재시도 가능 B-->>C: 응답 또는 오류(코드·상관 ID)
- 불변 조건(Invariant): 버퍼 경계, 프로토콜 상태, 트랜잭션 격리, FD 상한 등 단계별로 문장으로 적어 두면 디버깅 비용이 줄어듭니다.
- 결정성: 순수 층과 시간·네트워크·스케줄에 의존하는 층을 분리해야 테스트와 장애 분석이 쉬워집니다.
- 경계 비용: 직렬화, 인코딩, syscall 횟수, 락 경합, 할당·GC, 캐시 미스를 의심 목록에 둡니다.
- 백프레셔: 생산자가 소비자보다 빠를 때 버퍼·큐·스트림에서 속도를 줄이는 신호를 어디에 둘지 정의합니다.
프로덕션 운영 패턴
| 영역 | 운영 관점 질문 |
|---|---|
| 관측성 | 요청 단위 상관 ID, 에러율·지연 p95/p99, 의존성 타임아웃·재시도가 대시보드에 보이는가 |
| 안전성 | 입력 검증·권한·비밀·감사 로그가 코드 경로마다 일관적인가 |
| 신뢰성 | 재시도는 멱등 연산에만 적용되는가, 서킷 브레이커·백오프·DLQ가 있는가 |
| 성능 | 캐시·배치 크기·커넥션 풀·인덱스·백프레셔가 데이터 규모에 맞는가 |
| 배포 | 롤백 룬북, 카나리/블루그린, 마이그레이션·피처 플래그가 문서화되어 있는가 |
| 용량 | 피크 트래픽·디스크·FD·스레드 풀 상한을 주기적으로 검증하는가 |
스테이징은 데이터 양·네트워크 RTT·동시성을 프로덕션에 가깝게 맞출수록 재현율이 올라갑니다.
확장 예시: 엔드투엔드 미니 시나리오
앞선 본문 주제(「Rust 소유권 에러 디버깅 실전 사례 | ‘borrow checker가 막아요’ 해결기」)를 배포·운영 흐름에 맞춰 옮긴 체크리스트입니다. 도메인에 맞게 단계 이름만 바꿔 적용할 수 있습니다.
- 입력 계약 고정: 스키마·버전·최대 페이로드·타임아웃·에러 코드를 경계에 둔다.
- 핵심 경로 계측: 요청 ID, 단계별 지연, 외부 호출 결과 코드를 로그·메트릭·트레이스에서 한 흐름으로 본다.
- 실패 주입: 의존성 타임아웃·5xx·부분 데이터·락 대기를 스테이징에서 재현한다.
- 호환·롤백: 설정/마이그레이션/클라이언트 버전을 되돌릴 수 있는지 확인한다.
- 부하 후 검증: 피크 대비 p95/p99, 에러율, 리소스 상한, 알림 임계값을 점검한다.
handle(request):
ctx = newCorrelationId()
validated = validateSchema(request)
authorize(validated, ctx)
result = domainCore(validated)
persistOrEmit(result, idempotentKey)
recordMetrics(ctx, latency, outcome)
return result문제 해결(Troubleshooting)
| 증상 | 가능 원인 | 조치 |
|---|---|---|
| 간헐적 실패 | 레이스, 타임아웃, 외부 의존성, DNS | 최소 재현 스크립트, 분산 트레이스·로그 상관관계, 재시도·서킷 설정 점검 |
| 성능 저하 | N+1, 동기 I/O, 락 경합, 과도한 직렬화, 캐시 미스 | 프로파일러·APM으로 핫스팟 확인 후 한 가지씩 제거 |
| 메모리 증가 | 캐시 무제한, 구독/리스너 누수, 대용량 버퍼, 커넥션 미반납 | 상한·TTL·힙/FD 스냅샷 비교 |
| 빌드·배포만 실패 | 환경 변수, 권한, 플랫폼 차이, lockfile | CI 로그와 로컬 diff, 런타임·이미지 버전 핀 |
| 설정 불일치 | 프로필·시크릿·기본값, 리전 | 스키마 검증된 설정 단일 소스와 배포 매트릭스 표준화 |
| 데이터 불일치 | 비멱등 재시도, 부분 쓰기, 캐시 무효화 누락 | 멱등 키·아웃박스·트랜잭션 경계 재검토 |
권장 순서: (1) 최소 재현 (2) 최근 변경 범위 축소 (3) 환경·의존성 차이 (4) 관측으로 가설 검증 (5) 수정 후 회귀·부하 테스트.
배포 전에는 git add → git commit → git push 후 npm run deploy 순서를 권장합니다.
같이 보면 좋은 글 (내부 링크)
이 주제와 연결되는 다른 글입니다.
- Rust 메모리 안전성 완벽 가이드 | 소유권·Borrow checker·수명·unsafe 실전
- Rust 소유권 시스템 완벽 가이드 | Ownership·Borrowing·Lifetime
- C++ vs Rust 완전 비교 | 소유권·메모리 안전성·에러 처리·동시성·성능 실전 가이드
이 글에서 다루는 키워드 (관련 검색어)
Rust, Ownership, Borrow Checker, 소유권, 빌림, Lifetime, 실전 사례, 디버깅 등으로 검색하시면 이 글이 도움이 됩니다.