Rust의 소유권 시스템은 메모리 안전성을 보장해주지만, 여러 스레드에서 같은 데이터를 공유하려고 하면 컴파일러가 허용하지 않습니다. "한 번에 하나의 소유자만 존재할 수 있다"는 규칙 때문입니다. 소유권을 이동하면 다른 스레드에서 사용할 수 없고, 참조를 전달하려고 하면 라이프타임 문제로 컴파일 오류가 발생합니다. 실제로는 여러 스레드가 같은 설정 값을 읽거나, 공유 데이터를 참조해야 하는 상황이 많습니다. 예를 들어 웹 서버에서 모든 워커 스레드가 동일한 설정 파일을 읽어야 하거나, 여러 스레드가 같은 캐시 데이터를 조회해야 할
Rust의 소유권 시스템은 "한 번에 하나의 소유자만 존재할 수 있다"는 명확한 규칙을 가지고 있습니다. 대부분의 경우 이 규칙만으로 충분하지만, 때로는 여러 부분에서 같은 데이터를 소유해야 하는 상황이 있습니다. 예를 들어 그래프 자료구조에서 여러 노드가 같은 노드를 가리켜야 할 수 있습니다. 단일 스레드 환경에서 이런 공유 소유권이 필요할 때 Rc(Reference Counted)를 사용합니다. Rc는 참조 카운팅을 통해 여러 소유자가 같은 데이터를 공유할 수 있게 해주는 스마트 포인터입니다. 데이터를 가리키는 참조가 몇 개인지
Rust를 처음 배우다 보면 컴파일러가 자꾸 "value used here after move"나 "borrow of moved value" 같은 오류를 뱉어서 당황하게 되죠. 분명 올바른 코드를 작성한 것 같은데 컴파일이 안 되니 답답하기도 하고요. 이런 오류들은 모두 Rust의 핵심 개념인 소유권(Ownership)과 관련이 있습니다. 대부분의 프로그래밍 언어는 가비지 컬렉터(GC)를 통해 메모리를 관리하거나, C/C++처럼 프로그래머가 직접 메모리를 할당하고 해제합니다. Rust는 이 두 가지 방식 대신 소유권이라는 독특한 시
Rust로 코드를 작성하다 보면 신기한 장면을 목격할 때가 있습니다. Box<String>을 넘겼는데 &str을 기대하는 함수가 아무 문제없이 호출된다거나, Rc<Vec<i32>>에 대고 .iter()를 바로 호출할 수 있다거나 하는 것들이죠. 분명 타입이 다른데 컴파일러가 알아서 잘 처리해줍니다. 이런 마법 같은 일이 가능한 건 Rust의 Deref 트레이트와 역참조 강제(Deref coercion)라는 메커니즘 덕분입니다. 이 글에서는 역참조가 무엇인지부터 시작해서 Deref 트레이트를 직접 구현해보고, 역참조 강제가 실제로 어
터미널에서 개발하다 보면 창이 부족해지는 순간이 오죠. 개발 서버 하나 돌리고, 로그 보면서, 또 다른 창에서 Git 작업하고, 테스트도 돌려야 하고... 결국 터미널 탭이 열 개쯤 열려 있는 자신을 발견하게 됩니다. 😅 이런 문제를 해결하려고 tmux 같은 터미널 멀티플렉서를 써보신 분들도 계실 텐데요. 솔직히 tmux는 진입 장벽이 꽤 높습니다. 키 바인딩을 외워야 하고, 설정 파일도 복잡하고, 처음 켜면 뭘 어떻게 해야 하는지 막막하죠. Zellij는 이런 고민을 깔끔하게 해결해주는 차세대 터미널 멀티플렉서입니다. Rust로
Rust에서 대부분의 값은 스택에 저장됩니다. 스택은 빠르고 효율적이지만 컴파일 시점에 크기를 알 수 있는 데이터만 다룰 수 있다는 제약이 있죠. 그런데 프로그래밍을 하다 보면 크기를 미리 알 수 없는 데이터를 다루거나 큰 데이터를 복사 없이 전달하고 싶을 때가 있습니다. 이럴 때 쓰는 게 바로 Box입니다. Box는 Rust에서 가장 단순하면서도 자주 쓰이는 스마트 포인터로, 데이터를 힙 메모리에 저장하고 그 포인터를 스택에 두는 방식으로 동작해요. 이 글에서는 Box가 무엇이고 언제 필요한지, 실전에서 어떻게 활용하는지 예제와
Rust에서 변수를 다른 변수에 할당하면 값이 복사될 때도 있고 소유권이 이동할 때도 있습니다. 정수는 let y = x; 해도 x를 계속 쓸 수 있는데, String은 같은 걸 하면 원래 변수를 못 쓰게 되죠. 이 차이를 결정하는 게 바로 Copy와 Clone 트레이트입니다. 둘 다 "값을 복사한다"는 점은 같지만, 동작 방식과 쓰임새가 꽤 다릅니다. 이 글에서는 Copy와 Clone이 각각 무엇이고, 어떤 관계이며, 실제로 어떻게 쓰는지 알아보겠습니다. 소유권과 빌림에서 다룬 이동(move)과 복사(copy) 개념을 알고 있으면
Rust는 명시적이고 안전한 오류 처리를 중시하는 프로그래밍 언어입니다. 대표적으로 Result<T, E> 타입을 통해 다양한 에러 상황을 타입 시스템으로 포착할 수 있죠. 하지만 실무에서 직접 오류 자료형을 정의하고 Error 트레이트를 구현하다 보면, 반복적인 보일러플레이트 코드 작성에 지치는 경우가 많습니다. 이럴 때 thiserror 라이브러리가 여러분의 구세주가 될 수 있습니다. Error 트레이트 우선 표준 라이브러리의 Error 트레이트를 직접 구현하는데 필요한 최소한의 코드를 보여드리겠습니다. 아래 Validation
Rust는 시스템 프로그래밍 언어이기 때문에 데이터를 외부로 안전하게 내보내거나 받아오는 일이 많은데요. 이러한 데이터 직렬화/역직렬화를 위해서 사실상 표준처럼 사용되는 라이브러리가 Serde입니다. 거의 모든 Rust 프로젝트가 사용되는 크레이트(Crate)라고 봐도 과언이 아니죠. 이 글에서는 왜 Serde 라이브러를 어떻게 사용하는지 예제와 함께 살펴보겠습니다. Serde란? 직렬화는 데이터를 Rust 자료형에서 JSON이나 YAML, TOML 등의 형식으로 변화하는 과정을 의미하고, 역직렬화는 변환된 데이터를 다시 원래대로
자료형 간의 명시적이고 안전한 데이터 변환은 Rust의 중요한 철학 중 하나입니다. Rust는 From과 Into라는 표준 트레이트을 제공하여 데이터 변환을 안전하고 명확하게 할 수 있도록 돕는데요. 이 글에서는 이 두 트레이트의 관계와 차이점, 그리고 활용법을 살펴보겠습니다. From 트레이트란? From 트레이트은 다른 자료형부터(from) 현재 자료형으로 변환하는 방법을 정의할 때 사용합니다. From 트레이트의 from() 메서드는 다른 제네릭(generic) 타입을 인자로 받고 자신의 타입을 반환합니다. 예를 들어, Rus
Rust를 쓰는 이유 패턴 매칭 시스템이라는 말이 있을 정도로 Rust는 강력한 패턴 매칭 시스템을 자랑하는데요. 이러한 패턴 매칭은 바로 안전성과 가독성을 동시에 만족시키는 표현식 match에서 시작됩니다. 이 글에서는 match 표현식의 기본 사용법부터 자주 사용되는 패턴 매칭 기법, 그리고 실무에서 볼 수 있는 활용 예시까지 살펴보겠습니다. 기본 문법 match는 어떤 값에 대해 가능한 여러 가지 경우를 "패턴"으로 나눠 처리할 수 있게 해줍니다. 다른 프로그래밍 언어에서는 보통 switch 문으로 비슷한 기능을 제공하지만,
Rust에서 구조체가 데이터 구조를 표현하는 방법라면, 열거형은 선택지를 추상화하는데 특화된 자료형입니다. 이 글에서는 Rust에서 열거형이 무엇이고 어떻게 사용하는지 예제와 함께 살펴보겠습니다. 열거형이란? 열거형(Enum)은 여러 가지 가능한 값(variant) 중 하나만 가질 수 있는 사용자 정의(custom) 자료형(type)입니다. enum 키워드로 열거형의 이름을 붙이고, 중괄호 안에 모든 배리언트 이름을 나열하면 됩니다. 예를 들어, 웹에서 발생할 수 있는 4가지 이벤트로 이루어진 열거형으로 다음과 같이 정의할 수 있습
Rust에 내장된 원시 자료형만으로는 실제 비지니스에서 필요한 복잡한 구조의 데이터를 표현하는데는 한계가 있습니다. 그래서 구조체(Structure)를 통해서 여러 개의 관련된 데이터를 한 곳에 묶어서 추상화하게 되죠. 이 글에서는 Rust에서 구조체가 무엇이고 어떻게 사용하는지 예제와 함께 살펴보겠습니다. 구조체란? 구조체(Structure)는 여러 필드를 가진 사용자 정의(custom) 자료형(type)입니다. struct 키워드로 구조체의 이름을 붙이고, 중괄호 안에 각 필드의 이름과 자료형을 나열하면 됩니다. 예를 들어, 번
Rust로 코드를 작성하다 보면 "이 값이 정말 내가 기대한 것과 같을까?"를 확인해야 하는 순간이 많습니다. 단위 테스트를 작성할 때는 물론이고, 개발 중에 특정 조건이 반드시 성립하는지 검증하고 싶을 때도 그렇죠. 이럴 때 Rust가 제공하는 assert!, assert_eq!, assert_ne! 매크로가 딱입니다. 이번 글에서는 이 매크로들을 어떻게 쓰는지, 그리고 테스트에서 어떻게 활용하면 좋은지 알아보겠습니다. assert! 매크로 assert!는 가장 기본적인 검증 매크로입니다. 주어진 조건이 true인지 확인하고, 만
어떤 프로그래밍 언어를 학습하든 Primitives, 즉 원시 자료형에 대한 이해은 매우 중요합니다. 나중에 배우게 될 struct과 enum과 같은 커스텀(Custom) 자료형의 근간이 되는 중요한 개념이기 때문입니다. 이번 글에서는 Rust의 주요 원시 자료형들을 살펴보고, 각 타입이 어떤 특성을 가지는지, 그리고 실제로 어떻게 사용하는지 예제를 통해 알아보겠습니다. 원시 자료형이란? Rust의 원시 자료형은 언어에 내장되어 있는 가장 기본적인 데이터 유형(type)입니다. 변수나 함수 선언 시 명시적으로 자료형을 지정할 수도
Rust를 배우다 보면 화면에 무언가를 출력하기 위해 println! 같은 매크로를 많이 사용하게 됩니다. 그런데 이 매크로들 뒤에는 Display와 Debug라는 트레이트가 숨어 있고, 이 둘의 차이를 이해하면 Rust의 출력 메커니즘을 더 깊이 있게 다룰 수 있습니다. 출력 매크로 Rust에는 표준 출력 및 에러 출력을 위한 다양한 매크로(macro)가 있습니다. 아래는 가장 많이 사용하는 출력 관련 매크로들입니다. println!: 표준 출력(stdout)에 줄바꿈과 함께 문자열을 출력합니다 print!: 줄바꿈 없이 출력합니
코드 에디터 하면 VSCode를 떠올리시는 분이 많을 텐데요. 실제로 VSCode가 시장을 지배하고 있지만 가끔 무겁다고 느끼신 적 없나요? 확장을 좀 설치하다 보면 메모리를 잡아먹고, Electron 기반이다 보니 네이티브 앱만큼 빠릿빠릿하지는 않죠. Zed는 이런 불만을 정면으로 해결하려는 코드 에디터입니다. Atom을 만들었던 Nathan Sobo가 Atom의 단종 이후 새로 시작한 프로젝트인데요. Rust로 처음부터 다시 만들어서 GPU 가속 렌더링으로 120 FPS에 가까운 성능을 내고 실시간 협업과 AI 코딩 기능까지 기