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인지 확인하고, 만
여러 프로그래밍 언어를 자유자재로 넘나드는 풀스택 개발자들에게는 다양한 런타임의 버전을 관리하는 게 쉽지 않죠? 대개는 Node.js는 nvm, Python은 pyenv, Java는 SDKMAN과 같은 런타임 매니저를 사용해서 버전을 관리하실 거예요. 하지만 이 역시도 프로그래밍 언어마다 관리 도구와 설정 파일이 달라서 정신이 혼미해질 때가 있죠. 😵💫 Mise는 이러한 런타임 버전 관리에 대한 고민에 해결해주는 끝판왕 도구인데요. Mise만 있으면 하나의 표준화된 방식으로 여러 프로그래밍 언어의 런타임 버전을 빠르고 간편하게
Rust를 처음 배울 때 많은 분이 당황하는 지점이 있습니다. 문자열 타입이 두 개라는 겁니다. String도 있고 &str도 있는데, 대체 뭐가 다른 걸까요? 다른 언어에서는 문자열 하나면 충분했는데 Rust는 왜 이렇게 만들었을까요? 답은 Rust의 소유권 시스템에 있습니다. 누가 문자열 데이터를 소유하고 있느냐, 아니면 잠깐 빌려서 보고 있느냐를 타입으로 구분하는 거죠. 이 글에서는 String과 &str의 내부 구조부터 시작해서 언제 어떤 걸 쓰는지까지 정리해보겠습니다. String의 내부 구조 String은 힙에 할당된 문
어떤 프로그래밍 언어를 학습하든 Primitives, 즉 원시 자료형에 대한 이해은 매우 중요합니다. 나중에 배우게 될 struct과 enum과 같은 커스텀(Custom) 자료형의 근간이 되는 중요한 개념이기 때문입니다. 이번 글에서는 Rust의 주요 원시 자료형들을 살펴보고, 각 타입이 어떤 특성을 가지는지, 그리고 실제로 어떻게 사용하는지 예제를 통해 알아보겠습니다. 원시 자료형이란? Rust의 원시 자료형은 언어에 내장되어 있는 가장 기본적인 데이터 유형(type)입니다. 변수나 함수 선언 시 명시적으로 자료형을 지정할 수도
macOS에서 Docker 컨테이너를 돌리려면 보통 Docker Desktop을 설치하는데요. 그런데 Docker Desktop이 2022년부터 대규모 조직에 유료 구독을 요구하면서 무료 대안을 찾는 개발자가 부쩍 늘었습니다. 그중에서도 Colima는 설치 한 줄이면 바로 쓸 수 있어서 가장 인기 있는 선택지로 자리 잡았는데요. 이번 글에서는 Colima가 뭔지, 어떻게 쓰는지 처음부터 차근차근 살펴보겠습니다. Colima란? Colima는 Containers in Lima의 줄임말입니다. Lima가 Linux on Mac이니까,
Rust를 배우다 보면 화면에 무언가를 출력하기 위해 println! 같은 매크로를 많이 사용하게 됩니다. 그런데 이 매크로들 뒤에는 Display와 Debug라는 트레이트가 숨어 있고, 이 둘의 차이를 이해하면 Rust의 출력 메커니즘을 더 깊이 있게 다룰 수 있습니다. 출력 매크로 Rust에는 표준 출력 및 에러 출력을 위한 다양한 매크로(macro)가 있습니다. 아래는 가장 많이 사용하는 출력 관련 매크로들입니다. println!: 표준 출력(stdout)에 줄바꿈과 함께 문자열을 출력합니다 print!: 줄바꿈 없이 출력합니
최근 한국에 아는 개발자 분께서 미국에서 근무할 수 있는 포지션의 최종 면접을 앞두고 있었는데 갑자기 채용이 무기한 연기되었다는 황당한 소식을 듣게 되셨습니다. 다른 개발자 분께서는 심지어 최종 합격을 하고 리로케이션 패키지까지 받았는데, 느닷없이 오퍼가 취소되어 멘붕에 빠지셨다고 하네요... 🫠 주변에서 일어나는 이런 안타까운 일들을 보며 해외 취업 시장이 진짜 예전같지 않다는 것을 체감하게 됩니다. 미중 관세 전쟁으로 오랫동안 지속되었던 자유 무역과 세계화의 시대가 점점 저물고 있는 것이 아닌가 싶어요. 미국을 비롯한 여러 나
여러분 안녕하세요! 오늘은 정말 설레는 소식을 하나 전해드리려 해요. 크레에이터와 팬을 이어주는 플랫폼 에손토리(essentory)와 파트너십을 맺고, 저만의 특별한 멤버십 콘텐츠를 새롭게 선보이게 되었습니다. 해외에서는 Patreon 같은 플랫폼을 통해 수많은 크리에이터들이 자신만의 멤버십 커뮤니티를 만들고, 진짜 팬들과의 관계에 집중하며 지속 가능한 창작 활동을 이어가고 있죠. 에센토리는 이런 흐름을 한국에서 이끌고 있는 플랫폼이며, 저도 감사하게 초기 창작자로 함께하게 되었습니다. 제가 18년 동안 개발자로 지내며 깨달은 가장
달레 스터디에서 진행 중인 오픈소스 디자인 시스템 프로젝트 "달레UI"는 오픈 소스 디자인 시스템을 만들어가며 겪는 고민과 시행착오, 그리고 그 과정에서의 배움을 정기적으로 블로그를 통해 나누려고 합니다. 그 첫 번째 이야기로, 디자인 시스템 팀의 초대 개발자이신 Sehwan Lee 님께서 달레UI의 핵심 기술 스택을 선정하게 된 배경과 이유를 깊이 있게 풀어주셨습니다. 단순한 기술 비교를 넘어, 왜 이 기술이어야 했는지에 대한 철학적 고민까지 담겨 있어 디자인 시스템 구축에 관심 있는 분들께 꼭 추천드리고 싶습니다. 📝 블로그
Vite로 프로젝트를 만들다 보면 @vitejs/plugin-react나 vite-plugin-svgr 같은 플러그인을 한두 개쯤은 꼭 설치하게 되는데요. vite.config.js의 plugins 배열에 함수 하나 넣었을 뿐인데 JSX가 변환되고, SVG가 컴포넌트로 바뀌고, 환경 변수가 주입됩니다. 도대체 이 플러그인이라는 게 안에서 무슨 일을 하길래 빌드 과정에 이렇게 자연스럽게 끼어들 수 있는 걸까요? 🤔 사실 Vite 플러그인은 생각보다 훨씬 단순한 구조로 되어 있습니다. 객체 하나에 약속된 이름의 함수 몇 개를 넣어주면
현대 소프트웨어 개발에서 의존성(Dependency)은 필수 불가결한 존재입니다. 직접 구현해야 하는 코드를 줄여 생산성을 높여주지만, 관리되지 않고 방치된 의존성은 보안 취약점이나 호환성 문제로 이어지기 쉽죠. 이번 글에서는 깃허브에서 제공하는 Dependabot을 통해 의존성 관리와 보안 업데이트를 어떻게 자동화할 수 있는지 알아보겠습니다. Dependabot이란? Dependabot은 깃허브에서 제공하는 보안 취약점 경보 및 의존성 업데이트 기능입니다. 초기에는 독립 서비스였지만, 2019년 GitHub에 인수된 후 현재는 깃
코드를 작성하다 보면 AI의 도움이 필요한 순간이 자주 찾아옵니다. 복잡한 알고리즘을 짜야 할 때라든가 에러 메시지가 도통 이해가 안 될 때 말이죠. 이럴 때 에디터를 떠나서 ChatGPT나 클로드 코드를 따로 실행하면 작업 흐름이 끊기기 쉬운데요. Zed 에디터는 AI 기능을 에디터 깊숙이 통합해서 이런 컨텍스트 전환을 줄여줍니다. 에이전트 패널에서 AI와 대화하면서 코드를 수정하거나 인라인 어시스턴트로 선택한 코드를 즉석에서 바꾸는 것도 됩니다. 편집 예측은 다음에 칠 코드를 알아서 제안해주고요. 거기에 클로드 코드까지 에디터
Git 작업을 할 때 에디터와 터미널을 왔다 갔다 하시나요? 코드를 수정하고 터미널로 전환해서 git diff를 확인하고 다시 에디터로 돌아오는 이 반복이 은근히 흐름을 끊죠. Zed 에디터는 Git 기능을 에디터 안에 깊이 통합해서 이런 컨텍스트 전환을 최소화해 줍니다. 단순히 변경된 파일 목록을 보여주는 수준이 아닙니다. 스테이징, 커밋, 푸시, 브랜치 관리, 스태시, 머지 충돌 해결까지 거의 모든 Git 워크플로우가 에디터 안에서 돌아가요. 심지어 AI가 커밋 메시지를 대신 써주기까지 합니다. 이 글에서는 Zed의 Git 통합
외국어를 사용해서? 돈을 더 많이 벌어서? 새로운 기회가 많아서? 글로벌 경력을 쌓을 수 있어서? 실제로 한국에서 일하시다가 외국으로 이직을 하신 분들께 뭐가 제일 좋으시냐고 여쭤보면 이런 답변을 자주 들어요. "제 할 일만 할 수 있어서 너무 좋아요!”💡 참 의외죠? 😯 돌아켜보면 저도 한국에서 직장을 다닐 때는 항상 제 직무에서 벗어나는 무언가를 하느라 바빴던 것 같아요. 신입 때는 회식, 단합 대회, 송년회 등 각종 행사를 챙기느라 정신이 없었고, 올라가니 뜬금없이 위에서 긴급으로 자료를 취합해 오라는 경우가 많아서 야근이
현대 소프트웨어 개발에서 HTTP 기반 API를 생각하면 우리는 크게 두 가지 기술을 떠올리게 되죠? REST와 GraphQL. 역사가 오래된 REST는 비교적 간단한 백엔드 시스템이나 개발된 지 시간이 좀 지난 레거시 시스템에서 많이 사용되고 있습니다. 반면에 GraphQL은 관계가 복잡한 데이터를 다루는 API를 개발하거나 BFF(Backend for Frontend) 또는 API Orchestration(오케스트레이션)을 위해 많이 채택되고 있습니다. 만약 이 두 대표적인 API 기술을 유기적으로 통합할 수 있다면 얼마나 좋을
React로 폼을 만들어 본 적이 있다면 알 겁니다. 처음엔 useState()로 간단하게 시작하지만, 필드가 늘어나고 유효성 검사가 복잡해지면서 코드가 걷잡을 수 없이 커지는 경험 말이에요. React Hook Form이 이 문제를 꽤 잘 해결해줬지만, TypeScript와 궁합이 아쉬운 경우가 종종 있었습니다. TanStack Query로 서버 상태 관리를 혁신한 TanStack 팀이 이번엔 폼 관리에 도전장을 내밀었는데요. TanStack Form은 처음부터 TypeScript로 설계되어 필드 이름 하나까지 타입으로 잡아주고,
디스코드 봇을 만들어 서버에 초대해 뒀다면, 이제 그 봇으로 실제로 무언가를 시켜볼 차례인데요. 가장 먼저 해볼 일은 채널에 메시지 하나 보내는 겁니다. 보통은 discord.js 같은 라이브러리가 이걸 한 줄로 처리해 주지만, 이번 글에서는 라이브러리를 걷어내고 Discord REST API를 맨손으로 직접 호출해 보겠습니다. 굳이 왜 이걸 알아야 할까요? 우선 라이브러리가 무엇을 대신해 주는지 알면 문제가 생겼을 때 디버깅이 쉬워집니다. 또 Cloudflare Workers 같은 서버리스 환경에서는 무거운 라이브러리 없이 fet
요즘 대학생이나 취준생 분들을 멘토링하다 보면 AI가 곧 개발자를 대체할까 봐 걱정하시는 분들이 은근히 많은 것 같습니다. 특히 프로그래밍을 공부하신 지 얼마 안 되신 분들의 불안감이 높은 것 같은데요. 시간이 좀 지나 자신이 구직을 시작할 때 쯤이면, 그동안 열심히 학습해온 것들이 AI 때문에 아무 쓸모가 없어지는 것은 아닌지... 이제 막 개발자로 진로를 정하신 분들도 과연 이 길이 맞는지 심란한 마음이 드시는 것 같습니다. 사실 제가 AI 전문가도 아니고 관련해서 깊은 통찰이 있는 것도 아니지만, 요즘 이 것 때문에 고민하시는