여러 스레드에서 카운터 하나를 안전하게 올리고 싶을 때 가장 먼저 떠오르는 게 Mutex<i32>인데요. 그런데 막상 짜놓고 보면 "고작 정수 하나 더하자고 잠금을 잡았다 풀었다 한다고?" 싶어집니다. 실제로 이 패턴은 Sync 트레이트 글에서도 잠깐 언급했던 원자적 타입을 쓰면 훨씬 가볍게 해결할 수 있어요. Mutex도 Arc도 안 보이는데 5,000이 정확히 출력됩니다. 그런데 이 코드를 처음 보면 두 가지가 좀 거슬리는데요. &counter로 변경이 되는 게 어떻게 가능한지, 그리고 저 Ordering::Relaxed는 도대
Rust로 함수를 작성하다 보면 이런 고민이 생깁니다. &str을 받는 함수를 만들었는데, 호출하는 쪽에서 String을 넘기려면 매번 &를 붙이거나 .as_str()을 호출해야 하죠. 역참조 강제 덕분에 &name만으로도 잘 되긴 하지만, 직접 라이브러리 API를 설계할 때는 "이 함수가 어떤 타입을 받을 수 있는지"를 시그니처에서 명확히 드러내고 싶을 때가 있습니다. AsRef<T> 트레이트가 바로 이런 상황을 위해 존재합니다. AsRef 트레이트란? AsRef<T>는 어떤 값에서 &T를 저비용으로 얻을 수 있다는 것을 나타내는
MCP 서버를 하나 만들었습니다. 도구를 정의하고 핸들러를 구현했는데, 이걸 Claude나 ChatGPT에 바로 연결해서 테스트하면 문제가 생겼을 때 원인을 찾기가 쉽지 않아요. LLM이 도구를 잘못 호출한 건지, 서버가 엉뚱한 응답을 보낸 건지, 전송 계층에서 뭔가 꼬인 건지 구분이 안 되거든요 😅 REST API를 만들면 Postman으로 테스트하잖아요. MCP 서버도 프로토콜 수준에서 직접 메시지를 주고받으며 검증할 수 있으면 좋겠죠. 바로 그 역할을 하는 것이 Anthropic에서 공식적으로 제공하는 MCP Inspecto
개발하다 보면 한 번쯤 마우스에서 손을 떼고 싶은 순간이 옵니다. 코드를 쓰다가 파일을 열려고 마우스로 사이드바를 클릭하고, 다시 키보드로 돌아와서 코드를 치고, 또 마우스로 터미널을 클릭하고... 이 왔다 갔다 하는 시간이 쌓이면 생각보다 꽤 거슬리거든요. NeoVim은 바로 이 불편함을 없애주는 텍스트 에디터입니다. 키보드에서 손을 뗄 필요 없이 파일 편집, 검색, 탐색을 전부 할 수 있죠. "그냥 Vim 아닌가?" 싶으실 수 있는데, NeoVim은 Vim을 뿌리로 두되 현대 개발 환경에 맞게 새로 설계된 에디터예요. 이 글에서
클로드 코드는 기본적으로 파일 읽기와 쓰기, Bash 명령어 실행, 코드 탐색처럼 소프트웨어 개발에 필요한 핵심 도구를 갖추고 있습니다. 하지만 실제 개발 작업을 하다 보면 클로드 코드에 내장된 기본 도구만으로는 부족할 때가 있습니다. 이럴 때 MCP(Model Context Protocol) 서버를 연결하면 클로드 코드의 능력을 크게 확장할 수 있습니다. MCP 서버를 한번 설정해두면 "GitHub 이슈 42번 내용 알려줘", "users 테이블 스키마 보여줘" 같은 자연어 요청만으로 외부 시스템을 다룰 수 있게 되거든요. 이 글
Send 트레이트를 공부하다 보면 자연스럽게 따라오는 질문이 있는데요. "값을 스레드로 옮기지 않고, 여러 스레드에서 동시에 참조만 하고 싶으면 어떻게 하지?" 예를 들어 Arc로 RefCell을 감싸서 여러 스레드에서 접근하려고 하면 이런 컴파일 에러가 납니다. "스레드 간에 안전하게 공유할 수 없다"는 이 에러의 핵심이 바로 Sync 트레이트입니다. Send가 소유권 이동의 안전성을 보장한다면, Sync는 참조 공유의 안전성을 보장하는 건데요. 이 글에서 Sync가 어떤 역할을 하고 어떤 타입이 Sync이고 어떤 타입은 아닌지,
GitHub에서 이슈를 확인하려고 브라우저를 열고, PR을 만들려고 또 브라우저를 열고... 터미널에서 코딩하다가 브라우저와 터미널 사이를 왔다 갔다 하는 게 은근히 번거롭지 않으셨나요? GitHub REST API를 curl로 직접 호출하는 방법도 있지만 URL과 헤더를 매번 타이핑하는 건 솔직히 고통스럽죠. 그래서 GitHub이 만든 게 바로 gh라는 공식 CLI 도구입니다. 터미널을 떠나지 않고도 이슈부터 PR, 릴리스까지 다 처리할 수 있어요. 이번 글에서는 gh CLI의 설치부터 실무에서 자주 쓰는 핵심 명령어까지 살펴보겠
클로드 코드를 처음 쓸 때 /help를 입력해보면 70개가 넘는 슬래시 커맨드가 쏟아져 나옵니다. "이걸 언제 다 외우지?"라는 생각이 들 수 있는데요. 사실 매일 쓰는 명령어는 그중 일부에 불과합니다. 나머지는 특정 상황에서만 꺼내 쓰는 도구에 가깝죠. 이 글에서는 실무에서 자주 쓰는 명령어를 카테고리별로 정리해봤습니다. 각 명령어가 어떤 상황에서 유용한지, 관련 기능을 더 깊이 다룬 글은 어디 있는지까지 함께 안내합니다. 가장 먼저 알아둘 명령어는 **/help**입니다. 전체 명령어 목록을 보여주기 때문에, 나머지 명령어가 기
Rust에서 Option<String>을 다루다 보면 꽤 답답한 순간이 찾아옵니다. Option 안에 들어있는 String을 &str과 비교하고 싶은데 타입이 맞지 않아 컴파일러가 거부하는 상황이죠. Option<String>과 Option<&str>은 서로 다른 타입이라 직접 비교할 수 없습니다. 이런 상황에서 as_deref()를 알고 있으면 아주 깔끔하게 해결할 수 있는데요. 이 글에서는 as_ref()와 비교하면서 as_deref()가 왜 필요하고 어떻게 동작하는지 살펴보겠습니다. Option에서 소유와 참조 문제의 근본 원
우리는 지난 몇 년간 소프트웨어 개발 방식에 혁명적인 변화를 가져온 AI 도구들을 경험했습니다. 초기에는 ChatGPT가 생성해주는 코드를 IDE로 복붙하다가, 깃허브 Copilot이나 Cursor와 같은 도구들이 코딩을 도와주는 시대를 지나 이제 새로운 패러다임이 등장하고 있습니다. 바로 Anthropic이 선보인 CLI(명령줄 인터페이스) 기반의 AI 코딩 도구, 클로드 코드입니다. 단순한 코드 완성이 아닌, 작업 위임의 시대 클로드 코드는 단순히 코드를 완성해주거나 코드를 생성하는 도구를 넘어섭니다. 이 도구의 핵심에는 사용자
요즘 개발자 커뮤니티에서 코딩 에이전트 이야기가 정말 많이 나옵니다. Claude Code, Cursor, Windsurf, Copilot 등등 하루가 멀다 하고 새로운 도구가 등장하고 있죠. 그런데 이 도구들이 내부적으로 어떻게 돌아가는지 아는 사람은 의외로 많지 않습니다. 코딩 에이전트는 단순히 코드를 생성하는 것을 넘어서 파일을 읽고 명령어를 실행하고 테스트까지 돌리는 꽤 복잡한 시스템인데요. 그 중심에는 **도구 사용(Tool Use)**이라는 메커니즘이 있습니다. 이 글에서는 코딩 에이전트가 어떻게 작동하는지 그 원리를 하
Rust로 멀티스레드 프로그래밍을 하다 보면 이런 컴파일 에러를 만나게 되는 경우가 있는데요. "스레드 간에 안전하게 보낼 수 없다"는 말은 대체 무슨 뜻일까요? 그리고 Send 트레이트는 뭘까요? 🤔 사실 이 에러 메시지 안에 Rust가 동시성 프로그래밍에서 데이터 경합(data race)을 원천 차단하는 메커니즘이 담겨 있습니다. Send 트레이트가 어떻게 동작하고, 어떤 상황에서 우리를 보호해 주는지 살펴볼게요. Send 트레이트란? Send는 Rust 표준 라이브러리의 std::marker 모듈에 정의된 마커 트레이트(ma
Rust의 소유권 시스템은 메모리 안전성을 보장해주지만, 여러 스레드에서 같은 데이터를 공유하려고 하면 컴파일러가 허용하지 않습니다. "한 번에 하나의 소유자만 존재할 수 있다"는 규칙 때문입니다. 소유권을 이동하면 다른 스레드에서 사용할 수 없고, 참조를 전달하려고 하면 수명(lifetime) 문제로 컴파일 오류가 발생합니다. 실제로는 여러 스레드가 같은 설정 값을 읽거나, 공유 데이터를 참조해야 하는 상황이 많습니다. 예를 들어 웹 서버에서 모든 워커 스레드가 동일한 설정 파일을 읽어야 하거나, 여러 스레드가 같은 캐시 데이터를
Rust의 소유권 시스템은 "한 번에 하나의 소유자만 존재할 수 있다"는 명확한 규칙을 가지고 있습니다. 대부분의 경우 이 규칙만으로 충분하지만, 때로는 여러 부분에서 같은 데이터를 소유해야 하는 상황이 있습니다. 예를 들어 그래프 자료구조에서 여러 노드가 같은 노드를 가리켜야 할 수 있습니다. 단일 스레드 환경에서 이런 공유 소유권이 필요할 때 Rc(Reference Counted)를 사용합니다. Rc는 참조 카운팅을 통해 여러 소유자가 같은 데이터를 공유할 수 있게 해주는 스마트 포인터입니다. 데이터를 가리키는 참조가 몇 개인지
VS Code나 IntelliJ를 잘 쓰고 있었는데, 어느 날 서버에 SSH로 접속해서 파일을 수정할 일이 생겼습니다. vim config.yaml을 입력했더니 화면이 바뀌면서 커서가 깜빡이고 있어요. 키보드를 누르는데 글자가 입력이 안 됩니다. 아니, 입력되는 것 같기도 한데 이상한 동작을 하고 있어요. 끄고 싶은데 Ctrl+C도 안 먹히고, Ctrl+W를 눌렀더니 창이 닫히는 대신 뭔가 다른 일이 벌어집니다. 이 상황, 개발자라면 한 번쯤 겪어보셨을 거예요. 😅 "Vim 종료하는 법"은 Stack Overflow에서 200만
Rust 비동기 코드를 읽다 보면 이런 타입을 마주칠 때가 있습니다. 처음 보면 부담스럽습니다. Box도 알고, Future도 대충 알겠는데 중간에 Pin이 끼어들면서 갑자기 어려워 보이죠. 게다가 예제 코드에서는 Box::new()가 아니라 Box::pin()을 쓰기도 합니다. 이건 단순히 future를 박스에 넣는 코드일까요? 아니면 뭔가 더 특별한 일을 하는 걸까요? 이번 글에서는 Box::pin이 언제 필요한지 차근차근 살펴보겠습니다. Box 자체가 아직 익숙하지 않다면 Box로 힙에 데이터 저장하기를 먼저 읽어보시면 좋습니
Rust에서 대부분의 값은 스택에 저장됩니다. 스택은 빠르고 효율적이지만 컴파일 시점에 크기를 알 수 있는 데이터만 다룰 수 있다는 제약이 있죠. 그런데 프로그래밍을 하다 보면 크기를 미리 알 수 없는 데이터를 다루거나 큰 데이터를 복사 없이 전달하고 싶을 때가 있습니다. 이럴 때 쓰는 게 바로 Box입니다. Box는 Rust에서 가장 단순하면서도 자주 쓰이는 스마트 포인터로, 데이터를 힙 메모리에 저장하고 그 포인터를 스택에 두는 방식으로 동작해요. 이 글에서는 Box가 무엇이고 언제 필요한지, 실전에서 어떻게 활용하는지 예제와
Chat GPT와 같은 대형 언어 모델(LLM)이 급속도로 발전하면서 이를 활용한 다양한 AI 에이전트 및 확장 서비스들이 등장하고 있습니다. 하지만 LLM은 학습된 시점의 데이터에 갇혀 실시간 정보에 접근하거나 외부 시스템과 상호작용하는 데 한계가 있습니다. 뿐만 아니라, 비지니스 도메인에 맞는 문맥(Context)에서 AI 애플리케이션이 작동하도록 하는 것은 여전히 큰 도전입니다. 이러한 LLM의 한계를 극복하고 AI의 잠재력을 최대한 발휘하기 위해 등장한 것이 바로 Model Context Protocol, 줄여서 MCP입니다
Rust로 네트워크 서버를 만들거나 여러 작업을 동시에 처리해야 할 때, 어디서부터 시작해야 할지 막막한 적이 있으신가요? Rust는 async/await 문법을 언어 차원에서 지원하지만, 이걸 실제로 실행하려면 비동기 런타임이 필요합니다. 그리고 Rust 생태계에서 가장 널리 쓰이는 비동기 런타임이 바로 Tokio입니다. 이번 글에서는 Tokio가 무엇이고, 왜 필요한지부터 시작해서 실제로 비동기 코드를 작성하고 실행하는 방법까지 차근차근 다뤄보겠습니다. 비동기 프로그래밍이 필요한 이유 웹 서버를 하나 만든다고 생각해볼까요? 클라
Rust로 코드를 작성하다 보면 신기한 장면을 목격할 때가 있습니다. Box<String>을 넘겼는데 &str을 기대하는 함수가 아무 문제없이 호출된다거나, Rc<Vec<i32>>에 대고 .iter()를 바로 호출할 수 있다거나 하는 것들이죠. 분명 타입이 다른데 컴파일러가 알아서 잘 처리해줍니다. 이런 마법 같은 일이 가능한 건 Rust의 Deref 트레이트와 역참조 강제(Deref coercion)라는 메커니즘 덕분입니다. 이 글에서는 역참조가 무엇인지부터 시작해서 Deref 트레이트를 직접 구현해보고, 역참조 강제가 실제로 어