왜 Rust 참조와 빌림 테스트가 지금 필요한가요?
코드를 열심히 작성하다가 갑자기 빨간색 밑줄이 화면을 가득 채우는 경험을 해보셨나요? “cannot borrow `x` as mutable more than once at a time” 같은 무시무시한 에러 메시지를 마주하면 처음에는 당황스럽고 막막하기만 해요. Rust의 가장 강력한 특징인 소유권과 빌림 규칙은 안전성을 보장하지만, 동시에 개발자를 끊임없이 시험에 들게 하기도 하거든요.
단순히 에러를 없애기 위해 코드를 수정하는 것만으로는 부족해요. 내가 수정한 코드가 다른 곳에서 빌림 규칙을 깨뜨리지는 않는지, 데이터의 생명주기(Lifetime)가 적절한지를 검증할 수 있는 Rust 참조와 빌림 테스트 체계가 반드시 필요해요. 테스트가 없다면 코드를 고칠 때마다 새로운 빌림 에러가 터져 나올까 봐 불안해하며 코딩하게 될 거예요.
이 글을 끝까지 읽고 나면 여러분은 더 이상 컴파일러의 에러 메시지를 두려워하지 않게 될 거예요. 오히려 컴파일러와 협력하며, 안전한 참조 관계를 증명하는 테스트 코드를 능숙하게 작성할 수 있는 실력을 갖추게 될 거예요.
이번 가이드에서 우리는 이런 내용을 구체적으로 다뤄요.
- 테스트를 작성하기 전 반드시 알아야 할 참조와 빌림의 핵심 개념
- 실무에서 바로 써먹는 단계별 테스트 작성 프로세스
- 빌림 규칙 위반을 잡아내는 효율적인 테스트 코드 작성법
- CI 환경에서 테스트를 자동화하여 안전성을 유지하는 방법
테스트를 시작하기 위한 사전 준비와 핵심 개념
테스트 코드를 작성하기 전에 우리가 무엇을 검증하려 하는지 명확히 알아야 해요. Rust에서 참조(Reference)와 빌림(Borrowing)은 데이터의 소유권을 넘기지 않으면서도 데이터를 읽거나 수정할 수 있게 해주는 마법 같은 도구예요. 하지만 이 마법에는 엄격한 규칙이 따르고 있어요.
먼저, 불변 참조(&T)와 가변 참조(&mut T)의 차이를 명확히 이해하는 것이 첫걸음이에요. 불변 참조는 데이터를 읽기만 할 때 사용하고, 가변 참조는 데이터를 수정해야 할 때 사용해요. 여기서 가장 중요한 규칙은 한 번에 하나의 가변 참조만 존재할 수 있다는 점과, 가변 참조가 있는 동안에는 불변 참조를 만들 수 없다는 사실이에요.
테스트를 작성할 때 참조의 생명주기(Lifetime)를 고려하지 않으면, 테스트 코드 자체가 컴파일되지 않는 상황이 발생할 수 있어요. 테스트 대상이 되는 데이터가 테스트 함수 내에서 충분히 살아있는지 확인하는 습관을 가져야 해요.
우리가 어떤 유형의 참조를 테스트해야 하는지 결정하기 위해 아래 비교 표를 참고해 보세요.
| 참조 유형 | 가변성 | 동시 허용 수 | 주요 용도 |
|---|---|---|---|
| &T (불변 참조) | 불가능 | 무제한 | 데이터 읽기, 공유 |
| &mut T (가변 참조) | 가능 | 단 하나만 가능 | 데이터 수정, 상태 변경 |
테스트 대상을 선정할 때는 단순히 함수를 테스트하는 것을 넘어, 참조가 전달되는 경계면을 중점적으로 봐야 해요. 데이터가 함수로 들어갈 때(입력), 그리고 함수가 참조를 반환할 때(출력) 발생하는 규칙 위반을 잡아내는 것이 테스트의 핵심 목적이에요.
단계별 참조와 빌림 테스트 작성 실전 가이드
이제 본격적으로 테스트 코드를 작성해 볼까요? 단순히 코드를 짜는 것이 아니라, Rust의 철학에 맞게 안전성을 증명하는 과정이라고 생각하면 훨씬 쉬워져요. 다음의 5단계 프로세스를 따라가 보세요.
STEP 1. 테스트 대상이 될 데이터 구조와 함수 설계하기
먼저 테스트할 모델을 만들어야 해요. 예를 들어, 도서관 관리 시스템을 만든다고 가정해 볼게요. 책의 정보를 담은 Book 구조체와, 책들을 관리하며 빌려주는 기능을 가진 Library 구조체가 필요하겠죠. 이때 핵심은 함수들이 데이터를 어떻게 빌려 쓰느냐예요.
예를 들어, 책의 제목을 읽어오는 함수는 fn get_title(&self) -> &str처럼 불변 참조를 사용해야 하고, 책의 대출 상태를 변경하는 함수는 fn borrow_book(&mut self, id: u32)처럼 가변 참조를 사용해야 해요. 이 설계 자체가 테스트의 밑그림이 돼요.
STEP 2. 유닛 테스트를 통한 기본 참조 검증
Rust에서는 모듈 내부에 #[cfg(test)] 모듈을 만들어 유닛 테스트를 작성하는 것이 관례예요. 가장 먼저 할 일은 불변 참조를 통해 데이터를 정확히 읽어오는지 확인하는 거예요.
테스트 함수 안에서 데이터를 생성하고, 그 데이터를 함수에 참조로 전달한 뒤, 기대하는 결과값이 나오는지 assert_eq!로 확인하세요. 여기서 중요한 점은 테스트 함수가 종료될 때 데이터의 소유권이 어떻게 변하는지 관찰하는 거예요. 테스트 환경은 매우 깨끗해야 하므로, 각 테스트는 독립적인 데이터를 소유해야 해요.
STEP 3. 가변 참조와 소유권 이동(Move) 시나리오 테스트
이 단계가 가장 까다로우면서도 중요해요. 가변 참조를 사용하여 데이터의 상태가 의도한 대로 바뀌는지 확인해야 하거든요. 예를 들어, 도서관에서 책을 대출했을 때 책의 상태가 Available에서 Borrowed로 변하는지를 테스트해야 해요.
또한, 소유권 이동(Move)이 발생하는 상황도 반드시 테스트해야 해요. 어떤 함수가 값을 참조로 받는 대신 소유권을 통째로 가져가 버린다면, 그 이후에 그 데이터를 다시 쓰려고 할 때 컴파일 에러가 발생하겠죠? 테스트 코드에서 이런 시나리오를 의도적으로 구성해 봄으로써, 내 로직이 소유권을 어떻게 다루고 있는지 완벽히 파악할 수 있어요.
STEP 4. 생명주기(Lifetime) 제약 조건 검증
만약 함수가 참조를 반환한다면, 그 참조가 가리키는 데이터가 함수가 끝난 뒤에도 살아있는지 검증해야 해요. 이는 Rust에서 가장 어려운 부분 중 하나예요. 테스트를 작성할 때는 참조된 데이터의 수명이 함수 호출보다 길다는 것을 명시적으로 보여주는 코드를 짜야 해요.
실제 시나리오로 예를 들어볼게요. 어떤 설정값을 읽어오는 함수가 설정 객체의 일부를 참조로 반환한다면, 우리는 설정 객체가 살아있는 동안에만 그 참조를 사용할 수 있다는 것을 테스트를 통해 증명해야 해요. 만약 설정 객체를 중간에 드롭(Drop)해 버린다면, 남은 참조는 유효하지 않게 된다는 것을 이해하는 것이 중요해요.
STEP 5. 통합 테스트를 통한 시스템 전체 흐름 확인
마지막으로, 개별 함수가 아닌 프로젝트 전체의 흐름을 확인하는 통합 테스트를 작성해야 해요. 이는 tests/ 디렉토리에 별도의 파일을 만들어 진행해요. 외부 사용자 입장에서 라이브러리를 사용하는 것처럼 코드를 작성해 보세요.
사용자가 라이브러리를 초기화하고, 여러 번 데이터를 빌려 쓰고, 다시 가변 참조를 통해 데이터를 수정하는 전체 시나리오를 하나의 흐름으로 작성하는 거예요. 이 과정에서 여러 개의 참조가 얽히며 발생하는 복잡한 빌림 규칙 위반을 찾아낼 수 있어요. 마치 거대한 기계의 톱니바퀴들이 서로 맞물려 돌아가는 것을 확인하는 과정과 같아요.
테스트를 작성할 때 너무 완벽한 구조를 만들려고 애쓰지 마세요. 때로는 의도적으로 잘못된 참조 코드를 작성해 보고, 그것이 컴파일 에러를 일으키는지 확인하는 것도 아주 훌륭한 테스트 전략이에요.
자주 하는 실수와 해결법 및 FAQ
자주 하는 실수와 해결법
Rust를 배우는 과정에서 누구나 겪는 실수들이 있어요. 이를 미리 알고 있으면 삽질 시간을 획기적으로 줄일 수 있어요.
- ❌ 동일한 변수에 대해 가변 참조를 두 번 생성함
왜 발생하는가: Rust는 데이터 오염을 막기 위해 한 시점에 하나의 가변 참조만 허용해요.
✅ 해결법: 가변 참조의 범위를 명확히 제한하거나, 필요한 경우 데이터의 소유권을 완전히 넘겨주세요. - ❌ 함수 내부의 지역 변수 참조를 외부로 반환함
왜 발생하는가: 함수가 끝나면 지역 변수는 메모리에서 사라지는데, 그 주소를 가리키는 참조는 ‘댕글링 포인터’가 되기 때문이에요.
✅ 해결법: 참조 대신 값을 직접 반환하거나,Box등을 사용하여 힙(Heap)에 데이터를 저장하세요. - ❌ 불변 참조가 있는 상태에서 가변 참조를 시도함
왜 발생하는가: 데이터를 읽는 중(불변 참조)에 데이터가 바뀌면(가변 참조) 일관성이 깨져요.
✅ 해결법: 읽기 작업이 모두 끝난 후에 가변 참조를 생성하도록 코드 순서를 조정하세요. - ❌ 테스트 코드에서 .clone()을 남발함
왜 발생하는가: 빌림 규칙을 피하기 위해 무분별하게 복사본을 만들면, 실제 참조 로직의 결함을 놓치게 돼요.
✅ 해결법: .clone()은 정말 필요한 경우에만 최소한으로 사용하고, 최대한 참조를 통해 소유권 관계를 검증하세요. - ❌ Cargo test 실행 시 에러 메시지를 무시함
왜 발생하는가: 컴파일 에러는 단순히 코드가 틀린 게 아니라, 메모리 안전성이 깨질 위험이 있다는 경고예요.
✅ 해결법: 에러 메시지에 적힌 'borrow'와 'owner'의 관계를 천천히 읽어보고 로직을 다시 설계하세요.
자주 묻는 질문
Q. 왜 Rust는 이렇게 참조 규칙이 까다로운가요?
다른 언어에서는 흔히 발생하는 '데이터 경합(Data Race)' 문제를 컴파일 단계에서 원천 봉쇄하기 위해서예요. 조금 불편하더라도 실행 중에 프로그램이 갑자기 죽는 것보다 훨씬 안전하답니다.
Q. 테스트를 작성할 때 소유권을 넘겨주는 게 좋을까요, 참조를 쓰는 게 좋을까요?
상황에 따라 달라요. 데이터를 다시 써야 한다면 참조를 쓰는 것이 효율적이고, 데이터의 생명주기가 끝났음을 명시하고 싶다면 소유권을 넘겨주는 것이 명확해요.
Q. Lifetime(생명주기) 표시를 생략해도 되나요?
컴파일러가 추론할 수 있는 간단한 경우에는 생략이 가능하지만, 구조체 필드에 참조를 담거나 복잡한 관계가 되면 반드시 명시해 줘야 해요.
Q. 유닛 테스트와 통합 테스트 중 무엇이 더 중요한가요?
둘 다 중요해요! 유닛 테스트는 개별 로직의 정확성을, 통합 테스트는 참조 관계가 얽힌 전체 시스템의 안전성을 검증해 주기 때문이에요.
Q. 빌림 에러를 해결하기 위해 무조건 복사(Copy)를 써야 하나요?
아니요, 그것은 권장하지 않는 방식이에요. 복사는 메모리 효율을 떨어뜨리고 Rust의 핵심인 참조 시스템을 회피하는 것이므로, 올바른 참조 범위를 찾는 연습을 하는 게 훨씬 좋아요.
성공적인 테스트 전략 요약과 다음 단계
지금까지 Rust의 참조와 빌림을 안전하게 테스트하는 방법들을 살펴보았어요. 처음에는 컴파일러와 싸우는 기분이 들겠지만, 사실 컴파일러는 여러분의 가장 든든한 파트너예요. 테스트 코드는 그 파트너가 내준 숙제를 완벽하게 제출하는 과정과 같답니다.
- 참조 유형(불변 vs 가변)에 따른 규칙을 먼저 숙지하세요.
- 데이터가 함수에 들어오고 나가는 경계면을 중점적으로 테스트하세요.
- 가변 참조가 있는 동안에는 다른 참조가 생성되지 않도록 주의하세요.
- 소유권 이동(Move)과 생명주기(Lifetime) 시나리오를 반드시 포함하세요.
- 유닛 테스트로 로직을, 통합 테스트로 전체 흐름을 검증하세요.
- CI 연동을 통해 모든 테스트가 자동으로 실행되도록 환경을 구축하세요.
이제 배운 내용을 바탕으로 바로 실천해 볼 차례예요. 오늘 당장 할 수 있는 일부터 시작해 보세요.
- 오늘 할 일: 현재 작성 중인 코드에서 참조를 사용하는 함수 하나를 골라 유닛 테스트 작성해 보기
- 이번 주 할 일: 프로젝트에 통합 테스트 디렉토리를 만들고 전체 흐름 검증하기
- 실행 직전 할 일: `cargo test` 명령어가 익숙해질 때까지 다양한 시나리오로 실행해 보기
Rust 참조와 빌림을 믿을 수 있게 만드는 테스트를 작성하여, 더 단단하고 안전한 프로그램을 만들어 보세요! 여러분의 코드가 컴파일러의 승인을 받는 그 순간, 진정한 개발자의 성장을 느끼실 수 있을 거예요.
관련하여 더 공부하고 싶다면 입문 Rust 학습 가이드나 Rust 소유권 완벽 정리 글을 참고해 보세요.
