이직을 하고 Kotlin과 Rust라는 저에게 생소한 언어 두 개를 동시에 써야하는 기회가 생겼습니다. 마침 코딩 에이전트가 막 부상하던 시기였는데요. 공부를 하는 방법에도 변화를 주면 어떨까 싶었습니다. 그래서 두 프로그래밍 언어를 완전히 다른 방식으로 공부하는 실험을 시작했습니다. Kotlin 학습은 철저하게 AI 주도로 하기로 결심했습니다. 무조건 AI가 코드를 작성하게 하고, 코드를 이해할 때도 AI의 도움을 받았습니다. 모르는 문법이 나오면 바로 질문해서 답변을 얻고, 새로운 라이브러리를 만나면 핵심 용례만 빠르게 파악했습
Rust로 크레이트를 가져다 쓰다 보면 Cargo.toml에서 이런 줄을 한 번쯤 보셨을 거예요. 여기서 features는 대체 뭘까요? 왜 어떤 크레이트는 그냥 추가하면 되는데, 어떤 크레이트는 ["derive"]나 ["full"] 같은 걸 콕 집어줘야 제대로 동작할까요? 🤔 Cargo features는 크레이트의 기능을 조건부로 켜고 끄는 스위치입니다. 크레이트를 만드는 쪽에서는 "이 기능은 옵션이야"라고 미리 나눠두고, 쓰는 쪽에서는 필요한 것만 골라서 켤 수 있죠. 덕분에 안 쓰는 기능까지 컴파일하느라 빌드가 느려지거나 바
Tokio로 비동기 코드를 짜다 보면 생각보다 빨리 tokio::sync를 만나게 됩니다. 태스크 하나가 다른 태스크에게 일을 넘겨야 하고, 결과를 돌려받아야 하고, 여러 태스크에 종료 신호를 보내야 하고, 공유 상태를 잠가야 하니까요. 문제는 선택지가 꽤 많다는 점입니다. mpsc, oneshot, broadcast, watch, Mutex, RwLock, Semaphore, Notify가 한 모듈 안에 같이 있는데, 이름만 봐서는 언제 무엇을 써야 할지 헷갈립니다. mpsc로도 종료 신호를 보낼 수 있고, watch로도 보낼 수
Rust에서 모듈 시스템의 큰 그림을 잡고 파일을 나누는 mod, 경로를 가져오는 use까지 익히고 나면 다음으로 부딪히는 벽은 공개 범위입니다. 분명 함수에 pub을 붙였는데 외부에서 안 보이거나, 반대로 내부 구현까지 밖으로 드러나서 API가 지저분해지는 일이 생기죠. 여기에 crate::, self::, super::, pub(crate), pub use까지 섞이면 머릿속 모듈 지도가 금방 흐려집니다. 이번 글에서는 Rust 모듈 시스템에서 공개 범위가 어떻게 결정되는지 정리해보겠습니다. 핵심은 "항목이 공개인가?"만 보는 게
Rust 예제를 보면 파일 맨 위에 use std::collections::HashMap; 같은 줄이 자주 나옵니다. 익숙해지면 아무렇지 않게 쓰지만, 처음에는 mod와 use가 비슷해 보여 헷갈리기 쉽습니다. "파일을 가져오는 건가?", "모듈을 만드는 건가?", "이걸 쓰면 공개되는 건가?" 같은 질문이 자연스럽게 따라오죠. 결론부터 말하면 use는 이미 존재하는 경로를 현재 스코프에서 짧은 이름으로 쓰게 해주는 키워드입니다. 모듈을 새로 만들지도 않고, 항목의 공개 범위를 바꾸지도 않습니다. 이번 글에서는 use가 하는 일과
Serde로 데이터를 직렬화할 때는 보통 구조체를 먼저 선언하고 #[derive(Serialize, Deserialize)]를 붙이는데요. 데이터의 모양을 미리 알고 있다면 이 방식이 가장 안전하고 깔끔합니다. 그런데 현업에서는 구조체로 미리 못 박기 애매한 경우도 자주 만나게 됩니다. 외부 API가 내려주는 응답 중 일부 필드만 필요하거나, 응답 구조가 자주 바뀌거나, 요청 본문을 그때그때 즉석에서 조립해야 할 때가 그렇죠. 이럴 때 구조체를 일일이 정의하는 건 오히려 번거롭습니다. 그래서 이 글에서는 serde_json이 제공하
Rust를 처음 배우면서 파일을 나누기 시작하면 mod에서 한 번쯤 멈칫하게 됩니다. 다른 언어의 import나 require에 익숙하다면 mod user;를 보고 "아, user 파일을 가져오는 건가?"라고 생각하기 쉬운데요. 반은 맞고 반은 틀립니다. mod는 파일을 읽어 오는 명령이라기보다 이 위치에 이런 이름의 모듈이 있다고 선언하는 키워드입니다. 그 모듈의 내용이 같은 파일 안에 있을 수도 있고, 별도 파일에 있을 수도 있죠. 이번 글에서는 Rust의 mod 키워드가 어떤 일을 하는지, main.rs와 lib.rs에서 모듈
Rust를 배우다 보면 어느 순간 코드가 한 파일에 다 들어가지 않게 됩니다. 처음에는 main.rs 하나로 충분하지만, 타입이 늘고 함수가 많아지면 자연스럽게 파일을 나누고 싶어지죠. 그때 등장하는 키워드가 mod, use, pub입니다. 문제는 이 셋이 비슷한 위치에 자주 나타난다는 점입니다. 파일 위쪽에 mod config;가 있고, 바로 아래에 use crate::config::Config;가 있으며, 다른 파일에는 pub struct Config가 있죠. 처음 보면 "이게 다 import인가?", "왜 pub을 붙였는데 밖
큐(queue)는 먼저 들어온 데이터가 먼저 나가는 선입선출(First In First Out, 이하 FIFO) 자료구조입니다. 줄을 서서 기다리는 모습을 떠올리면 됩니다. 먼저 줄을 선 사람이 먼저 처리되죠. 작업 대기열, 메시지 버퍼, 너비 우선 탐색(BFS) 같은 곳에서 빠지지 않고 등장합니다. 그런데 Rust를 막 시작한 분들은 큐가 필요할 때 일단 Vec에 손이 갑니다. Vec의 끝에 push로 넣고, 앞에서 remove(0)으로 빼면 되니까요. 동작은 하는데요, 문제가 하나 있습니다. Vec은 메모리에 데이터를 일렬로 붙
블로그나 문서 사이트를 운영하다 보면 빌드 시간이 슬금슬금 늘어나는 순간이 옵니다. 글이 수백 개를 넘어가면 마크다운 파싱과 변환에만 수십 초가 쓰이고, 거기에 remark/rehype 플러그인을 몇 개 더 끼우면 1분을 훌쩍 넘기는 경우도 흔하죠. 저도 이 블로그를 운영하면서 빌드 로그를 보다가 "마크다운 처리에 이만큼 시간을 쓴다고?"라는 생각을 한두 번 해본 게 아닌데요 😅 최근 Astro 6.4에서 markdown.processor API가 새로 등장하면서, unified 생태계가 아닌 다른 마크다운 처리기로 갈아탈 수 있
데이터베이스에 LIKE '%검색어%'를 박아 쓰다 보면 한계가 금방 옵니다. 결과는 느리고, 오타에 약하고, 관련도 점수도 없습니다. 본격적으로 검색다운 검색을 붙이려면 Elasticsearch나 OpenSearch를 띄우는 게 정석이지만, 가벼운 사이드 프로젝트나 임베디드 환경에서 별도 서버까지 두기는 부담스러울 때가 있어요. tantivy는 Rust로 작성된 풀텍스트 검색 엔진 라이브러리입니다. Apache Lucene에서 영감을 받은 설계라서 한 번 배워두면 검색 엔진의 기본기를 그대로 익힐 수 있고, 별도의 데몬 없이 우리
개발자 모임이나 사내 세미나에서 발표 자료를 만들 때 늘 똑같은 고민이 들곤 합니다. Keynote나 파워포인트로 만들자니 코드 블록 하나 넣자고 폰트와 들여쓰기를 만지작거리는 게 영 번거롭고, 그렇다고 Google Slides는 코드 신택스 하이라이팅이 부실하죠. 마크다운으로 그냥 글 쓰듯 쓰면 안 될까 싶었던 적이 한두 번이 아닙니다. presenterm은 딱 그 가려운 곳을 긁어주는 도구입니다. 마크다운 파일 하나로 슬라이드를 만들고 터미널에서 바로 띄울 수 있어요. 코드 블록은 bat 기반의 신택스 하이라이팅이 자동으로 들어
웹 API를 호출하는 코드를 작성하다 보면 항상 마주치는 고민이 있는데요. "이 코드는 어떻게 테스트하지?" 하는 문제입니다. 실제 API를 호출하는 테스트는 네트워크 상태에 따라 결과가 달라지고, 외부 서비스의 응답을 마음대로 흉내내기도 어렵죠. 이럴 때 유용한 것이 바로 HTTP 모킹 라이브러리인데요. Rust 생태계에서는 mockito 크레이트가 가장 널리 사용되고 있습니다. 이 글에서는 mockito를 사용해서 HTTP 요청을 보내는 코드를 어떻게 테스트하는지 단계별로 살펴보겠습니다. mockito란? mockito는 Rus
Rust로 어느 정도 규모가 있는 코드를 짜다 보면 한 번쯤 부딪히는 문제가 있는데요. 바로 외부 의존성을 단위 테스트에서 어떻게 분리할 것인가 하는 문제입니다. 데이터베이스에 붙는 함수나 결제 게이트웨이를 호출하는 로직을, 매번 실제 서비스를 띄워놓고 검증할 수는 없잖아요. 자바에서는 Mockito, 파이썬에서는 unittest.mock이 이런 역할을 해주는데요. Rust 진영에서 이에 해당하는 라이브러리가 바로 mockall입니다. mockito가 HTTP 요청을 가로채는 도구라면, mockall은 트레이트의 구현체를 통째로 흉
새로운 시스템 프로그래밍 언어 소식이 또 하나 들려왔는데요. 이름은 Rue, 만든 사람은 The Rust Programming Language 책의 공동 저자로 잘 알려진 Steve Klabnik입니다. 흥미로운 점은 Klabnik이 혼자 만든 게 아니라 Claude와 짝을 지어 짧은 기간에 컴파일러 뼈대를 세웠다는 사실이죠. 이번 글에서는 Rue가 어떤 자리에 서고 싶어 하는지, 그리고 Rust 소유권을 어떤 식으로 다시 풀어낸 건지 살펴봅니다. 아직 초기 단계의 실험이지만, 시스템 언어가 어떤 방향으로 더 갈 수 있을지 엿볼 만
Rust로 함수를 하나 만들면, 그 함수가 여러 입력에서 제대로 동작하는지 확인하고 싶어집니다. 점수를 학점으로 바꾸는 함수라면 95점은 A, 85점은 B, 40점은 F가 나오는지 일일이 따져봐야 하죠. 그런데 이걸 #[test] 함수로 하나하나 적다 보면 거의 똑같은 코드가 입력값만 바뀐 채 우수수 늘어납니다. 이럴 때 손이 가는 도구가 rstest입니다. 입력과 기대값만 나열해 두면 테스트 함수를 입력 개수만큼 자동으로 찍어내 주거든요. assert 매크로로 값을 검증하는 기본기 위에, "같은 검증을 여러 입력으로 반복"하는 부
Rollup은 이미 잘 만들어진 번들러인데, 왜 갑자기 이름이 비슷한 Rolldown이라는 도구가 등장했을까요? 🤔 게다가 Vite는 8 버전부터 오랫동안 써 온 Rollup을 두고 이 Rolldown을 기본 번들러로 채택했습니다. 멀쩡히 돌아가던 도구를 갈아엎은 데는 그만한 이유가 있겠죠. 최근 JavaScript 도구들이 하나둘 Rust로 다시 작성되는 흐름 위에 Rolldown도 놓여 있습니다. SWC가 Babel을, Oxc가 ESLint를 겨냥했다면, Rolldown은 Rollup의 자리를 노립니다. 이번 글에서는 Roll
Homebrew를 쓰면서 느린 속도 때문에 답답했던 적 있으신가요? brew install 하나 실행했을 뿐인데 몇십 초씩 걸리고, brew update는 아예 커피 한 잔 타올 시간을 주기도 하죠. Homebrew는 macOS 개발 환경의 사실상 표준이지만 Ruby로 작성된 태생적 한계 때문에 성능은 늘 아쉬웠습니다. Zerobrew는 바로 이 문제를 풀려고 나온 프로젝트입니다. Rust로 작성했고 Homebrew의 패키지 생태계를 그대로 쓰면서도 설치 속도를 5배에서 최대 20배까지 끌어올렸는데요. Python 생태계에서 pip
터미널을 열 때마다 보이는 프롬프트가 밋밋하다고 느끼신 적 있으신가요? 기본 프롬프트는 현재 디렉터리 정도만 보여주다 보니 Git 브랜치를 확인하려면 git branch를 치고, Node.js 버전이 궁금하면 node -v를 입력해야 하죠. Starship은 이런 불편을 해결해주는 크로스 쉘 프롬프트입니다. Rust로 만들어져서 빠르고, Bash부터 Zsh, Fish, PowerShell까지 거의 모든 쉘에서 동작합니다. 이 글에서는 Starship을 설치하고 나만의 프롬프트를 설정하는 방법을 알아보겠습니다. Starship이란?
Rust로 라이브러리를 만들어서 crates.io에 배포하고 있다면 릴리스할 때마다 반복해야 하는 작업이 꽤 많다는 걸 느끼셨을 거예요. Cargo.toml의 버전 올리고 체인지로그 정리하고 cargo publish 실행하고 git 태그 만들고 GitHub Release도 작성하고... 🤔 매번 수작업으로 하다 보면 빼먹는 단계가 생기기 마련이죠. release-plz는 이 과정을 통째로 자동화해주는 도구인데요. Conventional Commits 기반으로 버전을 알아서 올려주고, 체인지로그도 자동 생성하고, PR 하나 머지하면