Rust에서 배열([T; N])은 크기가 컴파일 시점에 고정됩니다. [i32; 5]라고 선언하면 딱 5개만 담을 수 있고, 나중에 6번째 요소를 추가할 수가 없죠. 사용자 입력을 모으거나 파일에서 데이터를 읽어오거나 API 응답을 파싱하는 상황처럼 실행 시점에 데이터 개수가 정해지는 경우에는 고정 크기 배열로 해결이 안 됩니다. 이럴 때 필요한 것이 Vec<T>입니다. Vec<T>는 힙에 데이터를 저장하는 동적 배열로, 요소를 자유롭게 추가하고 제거할 수 있습니다. Rust에서 가장 많이 쓰이는 컬렉션 타입이기도 하고요. 이 글에서
웹 개발자라면 한 번쯤은 CORS 문제 때문에 골치아팠던 적이 있으시죠? Cross-Origin Resource Sharing, 줄여서 CORS는 웹 페이지가 다른 도메인의 리소스에 안전하게 접근할 수 도와주는 브라우저의 기능입니다. 이번 포스팅에서는 CORS의 기본 개념부터 작동 원리, 요청 흐름 그리고 실제 구현 방법까지 자세히 다루도록 하겠습니다. 동일 출처 정책 CORS를 제대로 이해하려면 우선 브라우저의 기본 보안 기능인 Same-Origin Policy, 즉 동일 출저 정책에 대해서 알고 있어야 합니다. 브라우저는 현재
클로드 코드로 웹 개발을 하다 보면 개발 서버를 띄워놓은 상태에서 코드를 수정해야 하는 상황이 자주 생깁니다. 프론트엔드 서버와 백엔드 서버를 동시에 돌리면서 코드를 고쳐야 할 때도 있고요. 일반 터미널에서는 탭이나 tmux로 해결하지만, 클로드 코드 안에서는 어떻게 할까요? 🤔 백그라운드 프로세스 기능을 쓰면 됩니다. 오래 걸리는 명령어를 뒤로 보내놓고 대화를 이어가다가 필요할 때 다시 확인하거나 종료할 수 있거든요. 한번 익혀두면 개발 서버 띄우기, 빌드 감시, 테스트 실행 같은 작업이 훨씬 수월해집니다. 백그라운드로 보내는
Rust는 명시적이고 안전한 오류 처리를 중시하는 프로그래밍 언어입니다. 대표적으로 Result 타입과 ? 연산자를 통해 다양한 에러 상황을 타입 시스템으로 포착할 수 있죠. 하지만 실무에서 직접 오류 자료형을 정의하고 Error 트레이트를 구현하다 보면, 반복적인 보일러플레이트 코드 작성에 지치는 경우가 많습니다. 이럴 때 thiserror 라이브러리가 여러분의 구세주가 될 수 있습니다. Error 트레이트 우선 표준 라이브러리의 Error 트레이트를 직접 구현하는데 필요한 최소한의 코드를 보여드리겠습니다. 아래 Validatio
GitHub에서 이슈를 만들고 PR을 열고 코드를 검색하는 일은 개발자의 일상이죠. 그런데 이런 반복 작업을 AI에게 시키면 어떨까요? MCP(Model Context Protocol)가 AI와 외부 시스템을 연결하는 표준으로 자리 잡으면서 GitHub도 공식 MCP 서버를 내놓았는데요. 설정해두면 VSCode나 Cursor의 AI 채팅에서 자연어로 요청하는 것만으로 GitHub의 이슈나 PR을 간편하게 다룰 수 있게 됩니다. 이번 글에서는 GitHub MCP 서버를 설치하고 실제로 활용하는 방법을 살펴볼게요. GitHub MCP
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 명령어 실행, 코드 검색처럼 개발에 필요한 핵심 도구를 기본으로 갖추고 있습니다. 그런데 실제 개발 작업을 하다 보면 GitHub에서 이슈를 만들거나 데이터베이스 스키마를 확인하거나 웹에서 최신 문서를 검색해야 할 때가 있잖아요? 이럴 때 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의 소유권 시스템은 메모리 안전성을 보장해주지만, 여러 스레드에서 같은 데이터를 공유하려고 하면 컴파일러가 허용하지 않습니다. "한 번에 하나의 소유자만 존재할 수 있다"는 규칙 때문입니다. 소유권을 이동하면 다른 스레드에서 사용할 수 없고, 참조를 전달하려고 하면 라이프타임 문제로 컴파일 오류가 발생합니다. 실제로는 여러 스레드가 같은 설정 값을 읽거나, 공유 데이터를 참조해야 하는 상황이 많습니다. 예를 들어 웹 서버에서 모든 워커 스레드가 동일한 설정 파일을 읽어야 하거나, 여러 스레드가 같은 캐시 데이터를 조회해야 할
Rust의 소유권 시스템은 "한 번에 하나의 소유자만 존재할 수 있다"는 명확한 규칙을 가지고 있습니다. 대부분의 경우 이 규칙만으로 충분하지만, 때로는 여러 부분에서 같은 데이터를 소유해야 하는 상황이 있습니다. 예를 들어 그래프 자료구조에서 여러 노드가 같은 노드를 가리켜야 할 수 있습니다. 단일 스레드 환경에서 이런 공유 소유권이 필요할 때 Rc(Reference Counted)를 사용합니다. Rc는 참조 카운팅을 통해 여러 소유자가 같은 데이터를 공유할 수 있게 해주는 스마트 포인터입니다. 데이터를 가리키는 참조가 몇 개인지
VS Code나 IntelliJ를 잘 쓰고 있었는데, 어느 날 서버에 SSH로 접속해서 파일을 수정할 일이 생겼습니다. vim config.yaml을 입력했더니 화면이 바뀌면서 커서가 깜빡이고 있어요. 키보드를 누르는데 글자가 입력이 안 됩니다. 아니, 입력되는 것 같기도 한데 이상한 동작을 하고 있어요. 끄고 싶은데 Ctrl+C도 안 먹히고, Ctrl+W를 눌렀더니 창이 닫히는 대신 뭔가 다른 일이 벌어집니다. 이 상황, 개발자라면 한 번쯤 겪어보셨을 거예요. 😅 "Vim 종료하는 법"은 Stack Overflow에서 200만
Rust에서 대부분의 값은 스택에 저장됩니다. 스택은 빠르고 효율적이지만 컴파일 시점에 크기를 알 수 있는 데이터만 다룰 수 있다는 제약이 있죠. 그런데 프로그래밍을 하다 보면 크기를 미리 알 수 없는 데이터를 다루거나 큰 데이터를 복사 없이 전달하고 싶을 때가 있습니다. 이럴 때 쓰는 게 바로 Box입니다. Box는 Rust에서 가장 단순하면서도 자주 쓰이는 스마트 포인터로, 데이터를 힙 메모리에 저장하고 그 포인터를 스택에 두는 방식으로 동작해요. 이 글에서는 Box가 무엇이고 언제 필요한지, 실전에서 어떻게 활용하는지 예제와