큐(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 소유권을 어떤 식으로 다시 풀어낸 건지 살펴봅니다. 아직 초기 단계의 실험이지만, 시스템 언어가 어떤 방향으로 더 갈 수 있을지 엿볼 만
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 하나 머지하면
Rust 크레이트를 배포하다 보면 한 번쯤 이런 경험이 있을 거예요. 패치 버전만 올려서 배포했는데, 사실은 공개 함수의 시그니처를 바꿔버렸던 거죠. 의존하는 쪽에서는 갑자기 빌드가 깨지고, 이슈가 올라오고... 😅 시맨틱 버저닝(Semantic Versioning)은 API 변경의 종류에 따라 메이저, 마이너, 패치 버전을 구분하는 규칙인데, 사람이 매번 이걸 정확히 판단하기는 쉽지 않습니다. 구조체에 필드 하나 추가한 게 호환성을 깨는 변경인지, 트레이트에 기본 구현이 있는 메서드를 추가한 건 괜찮은 건지, 헷갈리는 경우가 많
테스트를 열심히 작성했는데 과연 우리 코드가 어디까지 테스트되고 있는 걸까요? "이 모듈은 테스트를 꽤 많이 짰으니까 괜찮겠지"라고 막연하게 생각하다가 정작 핵심 에러 처리 분기는 한 번도 실행된 적이 없었다는 걸 나중에 발견하는 경우가 종종 있습니다 😅 코드 커버리지는 이런 사각지대를 눈에 보이게 만들어주는 도구입니다. Rust에서는 cargo-llvm-cov가 이 역할을 맡고 있는데 LLVM의 소스 기반 커버리지 기능을 활용해서 정확한 측정 결과를 제공해요. 이번 글에서는 설치부터 기본 사용법, 여러 리포트 형식, CI 연동까
팀에서 코드 리뷰를 하다 보면 로직과 무관한 스타일 논쟁에 시간을 쓸 때가 있어요. 중괄호를 같은 줄에 둘지 다음 줄에 둘지, use 구문을 어떻게 묶을지, 한 줄이 몇 글자를 넘으면 줄바꿈할지... 이런 토론이 쌓이면 정작 중요한 설계나 로직 리뷰에 집중하기 어렵습니다 😅 Rust 생태계에서는 이 문제를 rustfmt라는 공식 포매터로 깔끔하게 해결합니다. cargo fmt 한 번이면 코드 스타일이 일관되게 정리되니까 팀원들은 포매팅에 신경 쓸 필요 없이 코드 자체에만 집중할 수 있죠. 이번 글에서는 rustfmt의 설치부터 설
Rust 컴파일러는 워낙 꼼꼼해서 컴파일만 통과하면 꽤 안심이 되죠. 하지만 "컴파일은 되는데 이게 정말 좋은 코드인가?"라는 질문에는 컴파일러가 답해주지 않습니다. 불필요한 clone() 호출, 더 간결하게 쓸 수 있는 패턴, 성능을 깎아먹는 습관적인 코드... 이런 건 컴파일러의 관심사가 아니거든요. Clippy는 바로 이 영역을 담당하는 Rust의 공식 린트 도구입니다. 700개가 넘는 린트 규칙으로 코드를 분석해서 잠재적인 버그부터 스타일 개선 사항까지 짚어줍니다. 이번 글에서는 Clippy의 설치와 기본 사용법, 주요 린트
Rust를 처음 시작할 때 공식 사이트에서 안내하는 대로 설치 스크립트를 실행하면 rustup이라는 도구가 함께 깔립니다. 처음에는 "Rust 설치 프로그램"쯤으로 생각하고 넘어가기 쉬운데, 사실 rustup은 그보다 훨씬 많은 일을 해요. 컴파일러 버전을 바꾸거나 nightly 기능을 잠깐 써보거나 팀 전체의 Rust 버전을 맞추거나 WebAssembly로 크로스 컴파일하는 것까지 전부 rustup이 담당합니다. 이번 글에서는 rustup의 설치부터 툴체인 관리, 컴포넌트와 타겟 설정, 팀 단위 버전 고정까지 살펴보겠습니다. ru
Tower 미들웨어 실전에서 본 빌트인 미들웨어로 대부분의 자리는 커버되지만, 가끔은 직접 만들어야 하는 순간이 옵니다. 사내 인증 토큰 검증, 도메인 특화 메트릭 수집, 비표준 헤더 처리 같은 자리죠. 이번 글에서는 Tower의 Service와 Layer를 직접 구현해서 미들웨어를 작성하는 방법을 정리해보겠습니다. 비동기 future를 직접 만드는 패턴까지 포함해서요. 입문 개념은 Tower 입문에서 다뤘으니, 이 글은 그 위에서 한 단계 깊이 들어가는 내용입니다. 만약 Future의 poll, Waker, Pin 같은 단어가 아
Rust로 서비스를 짜다 보면 가끔 이런 욕심이 생깁니다. "이 분기 로직을 코드 변경 없이 운영자가 살짝 바꿀 수 있으면 좋을 텐데", "고객사마다 다른 헤더 변환 규칙을 그때그때 다른 바이너리로 빌드하긴 너무 무거운데"처럼요. 이런 상황을 위한 도구가 바로 임베디드 스크립트 엔진입니다. 이번 글에서는 Rust 생태계에서 자주 쓰이는 Rhai 스크립트 엔진을 소개합니다. 호스트 Rust 코드에 박아 넣는 방법부터 Rhai 자체 문법까지 한 번에 살펴보겠습니다. 임베디드 스크립트가 필요한 순간 서비스 본체는 Rust로 단단하게 컴파
Rust로 HTTP 서버를 짜다 보면 프레임워크 선택에서 한 번씩 막힙니다. actix-web은 성능이 검증됐지만 액터 모델이 낯설고, warp는 함수형 스타일이 깔끔한데 타입 에러가 미로처럼 느껴질 때가 있습니다. Axum은 Tokio 팀이 만든 웹 프레임워크입니다. "Tower 위의 얇은 라우팅 레이어"를 표방하는데, 이게 생각보다 실용적입니다. 타임아웃이나 인증 미들웨어를 Tower로 짜두면 Axum에 그대로 끼울 수 있고, 핸들러 함수 시그니처에 타입만 선언해두면 Axum이 요청에서 필요한 데이터를 알아서 꺼내줍니다. 이 글
웹 개발자라면 한 번쯤 "내가 만든 웹 앱을 데스크톱 앱으로 배포할 수 있으면 좋겠다"고 생각해 보신 적 있을 겁니다. Electron이 이 영역을 오랫동안 지배해 왔지만, 앱 하나에 Chromium 전체를 번들하다 보니 설치 파일이 100MB를 넘어가는 건 일상이었죠 😅 Tauri는 이 문제를 풀려고 만들어진 프레임워크입니다. 프론트엔드는 기존 웹 기술을 그대로 쓰되 백엔드를 Rust로 작성하고, OS의 네이티브 웹뷰를 활용해서 앱 크기를 수 MB 수준으로 줄여 줘요. 이번 글에서는 Tauri 2로 데스크톱 앱을 처음부터 만들어