달레 스터디에서 진행 중인 오픈소스 디자인 시스템 프로젝트 "달레UI"는 오픈 소스 디자인 시스템을 만들어가며 겪는 고민과 시행착오, 그리고 그 과정에서의 배움을 정기적으로 블로그를 통해 나누려고 합니다. 그 첫 번째 이야기로, 디자인 시스템 팀의 초대 개발자이신 Sehwan Lee 님께서 달레UI의 핵심 기술 스택을 선정하게 된 배경과 이유를 깊이 있게 풀어주셨습니다. 단순한 기술 비교를 넘어, 왜 이 기술이어야 했는지에 대한 철학적 고민까지 담겨 있어 디자인 시스템 구축에 관심 있는 분들께 꼭 추천드리고 싶습니다. 📝 블로그
현대 소프트웨어 개발에서 의존성(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로 설계되어 필드 이름 하나까지 타입으로 잡아주고,
요즘 대학생이나 취준생 분들을 멘토링하다 보면 AI가 곧 개발자를 대체할까 봐 걱정하시는 분들이 은근히 많은 것 같습니다. 특히 프로그래밍을 공부하신 지 얼마 안 되신 분들의 불안감이 높은 것 같은데요. 시간이 좀 지나 자신이 구직을 시작할 때 쯤이면, 그동안 열심히 학습해온 것들이 AI 때문에 아무 쓸모가 없어지는 것은 아닌지... 이제 막 개발자로 진로를 정하신 분들도 과연 이 길이 맞는지 심란한 마음이 드시는 것 같습니다. 사실 제가 AI 전문가도 아니고 관련해서 깊은 통찰이 있는 것도 아니지만, 요즘 이 것 때문에 고민하시는
ChatGPT를 사용하다 보면 이런 생각 해보셨나요? "이 작업을 위해 매번 똑같은 프롬프트를 입력하는 게 너무 번거로운데, 미리 설정해둘 수는 없을까?" 혹은 "우리 팀만의 특별한 용도로 커스터마이징된 ChatGPT가 있으면 좋겠는데..." 같은 생각 말이죠. OpenAI가 2023년 11월에 발표한 Custom GPT와 GPT Store가 바로 이런 니즈를 해결해주는 기능입니다. 코드를 한 줄도 작성하지 않고도 나만의 맞춤형 AI 어시스턴트를 만들고, 다른 사람들과 공유할 수 있게 된 거예요. 이 글에서는 Custom GPT가
오픈소스 프로젝트를 만들고 유지하는 건 생각보다 손이 많이 갑니다. 주말마다 이슈를 처리하고, 새벽에 PR을 리뷰하고, 버전 업데이트에 맞춰 코드를 고치죠. 이렇게 매일 시간을 쏟는 개발자에게 "고마워요"라는 말 대신 커피 한 잔이라도 사줄 수 있다면 어떨까요? GitHub Sponsors는 바로 이 목적으로 만들어진 GitHub의 공식 후원 프로그램이에요. 오픈소스에 기여하는 개발자나 조직이 GitHub 안에서 바로 후원을 받을 수 있게 해주죠. 이번 글에서는 후원을 받는 쪽, 후원을 하는 쪽 양쪽 관점에서 GitHub Spons
지난 포스팅에서 Node.js의 worker_threads 모듈을 통해 이제 자바스크립트에서도 멀티 쓰레딩이 가능하다는 것을 배웠는데요. 이번 포스팅에서는 워커 스레드 풀링(pooling)을 도와주는 라이브러리인 Piscina에 대해서 알아보겠습니다. Piscina란? 상용 애플리케이션을 개발할 때는 Node.js의 worker_threads 모듈을 그대로 쓰기는 곤란한 경우가 많은데요. 필요할 때 마다 매번 새로운 워커 스레드를 생성하면 서버에 부하를 주어 오히려 성능을 떨어뜨릴 수도 있죠. 그래서 스레드 풀(pool)을 사용하여
Cloudflare Workers로 서버리스 API를 만들다 보면 결국 데이터를 어딘가에 저장해야 하는 순간이 옵니다. KV는 단순한 키-값 저장에는 좋지만 관계형 쿼리가 필요해지면 한계가 드러나죠. 그렇다고 외부 데이터베이스를 연결하면 엣지에서 실행되는 Workers의 속도 이점이 사라집니다. D1은 이 문제를 해결하기 위해 Cloudflare가 만든 서버리스 SQL 데이터베이스예요. SQLite를 기반으로 Workers에서 바인딩 하나로 바로 접근할 수 있고, 별도의 서버 관리나 연결 풀링 없이 SQL 쿼리를 실행할 수 있습니다
worker_threads는 싱글 스레드 언어로 알려진 자바스크립트로도 멀티 스레드 프로그래밍을 가능하게 해주는 Node.js의 내장 모듈입니다. 이번 포스팅에서는 worker_threads 모듈을 사용하여 어떻게 멀티 스레드 프로그래밍을 할 수 있는지 예제를 통해서 설명드리겠습니다. 싱글 스레드의 한계 자바스크립트는 태성적으로 하나의 스레드로 동작하는 여러 작업을 처리할 수 있는 비동기 프로그래밍 언어였는데요. 이러한 특징은 작은 하드웨어 리소스로 여러 개의 IO 작업을 동시에 처리하는데 유리했으며 특히 브라우저 환경에서 빛을 발
클라우드에 파일을 저장하려면 보통 AWS S3를 떠올립니다. 문제는 비용이에요. S3에 파일을 올리는 건 저렴한데 사용자가 그 파일을 다운로드할 때마다 이그레스(egress) 비용이 붙습니다. 트래픽이 늘어나면 이 비용이 생각보다 빠르게 커지죠. Cloudflare R2는 이 문제를 정면으로 해결합니다. S3 호환 API를 제공하면서 이그레스 비용이 아예 없어요. 데이터를 얼마나 자주 내려받든 추가 비용이 발생하지 않습니다. 게다가 Cloudflare Workers에서 바인딩으로 직접 접근할 수 있어서 파일 업로드 API나 이미지
Cloudflare Workers로 애플리케이션을 만들다 보면 어딘가에 데이터를 저장해야 할 때가 옵니다. 설정값을 관리하거나 API 응답을 캐싱하거나 세션 토큰을 저장하는 등 간단한 키-값 패턴이 필요한 경우가 많죠. Workers KV는 이런 용도에 딱 맞는 서버리스 키-값 저장소입니다. Cloudflare의 전역 네트워크에 데이터가 분산 저장되어 있어서 세계 어디서든 빠르게 읽을 수 있고 Workers에서 바인딩 하나로 바로 접근할 수 있어요. Workers KV란 Workers KV는 Cloudflare의 엣지 네트워크 전체
DOM API에는 많은 웹 개발자들을 헷갈리게 하는 3가지 속성이 있습니다. 바로 느낌이 비슷한 innerHTML, innerText, textContent인데요. 모두 HTML 요소의 내용을 접근할 때 사용하는 속성이지만 알고 보면 중요한 차이점이 있죠. 이번 포스팅에서는 이 알쏭달쏭한 HTML 요소의 3가지 속성에 대해서 알아보겠습니다. innerHTML 속성 innerHTML 속성은 HTML 요소 내부에 있는 HTML 코드를 있는 그대로 문자열 형태로 접근할 수 있도록 해줍니다. 예를 들어, 다음과 같이 3개의 <li> 요소로
Cloudflare Workers로 서버리스 애플리케이션을 개발해보신 분이라면 Wrangler라는 CLI 도구를 한 번쯤 써보셨을 거예요. 프로젝트 생성부터 로컬 개발 서버, 배포까지 터미널 하나로 해결할 수 있거든요. 그런데 Wrangler는 단순히 Workers를 배포하는 도구가 아닙니다. KV, R2, D1 같은 Cloudflare 서비스도 관리할 수 있고 환경별 설정 분리나 시크릿 관리 기능까지 갖추고 있어요. 이번 글에서는 Wrangler CLI를 실무에서 제대로 활용하는 방법을 살펴보겠습니다. Cloudflare Work
개발 블로그나 기술 문서를 작성할 때 코드를 예쁘게 보여주는 것은 생각보다 중요한 문제입니다. 읽기 좋은 코드 하이라이팅은 독자가 내용을 빠르게 파악하는 데 큰 도움이 되기 때문이죠. 이번 포스팅에서는 VS Code와 동일한 문법 엔진을 사용해서 아름답고 정확한 코드 하이라이팅을 제공하는 Shiki에 대해서 알아보겠습니다. Shiki란? Shiki(式, 일본어로 "스타일"이라는 뜻)는 코드를 구문 강조(syntax highlighting)해주는 JavaScript 라이브러리입니다. VS Code에서 사용하는 것과 동일한 TextMa
서버리스 애플리케이션을 만들고 싶은데 AWS Lambda는 너무 복잡하고, 배포도 번거롭다고 느껴본 적 있으신가요? 🤔 Cloudflare Workers를 사용하면 간단한 자바스크립트 코드 몇 줄로 전 세계 300개 이상의 엣지 로케이션에서 실행되는 서버리스 함수를 만들 수 있습니다. 이번 포스팅에서는 Cloudflare Workers의 기본 개념부터 실제 배포까지 단계별로 알아보겠습니다. Cloudflare Workers란? Cloudflare Workers는 Cloudflare의 엣지 네트워크에서 실행되는 서버리스 플랫폼입니다
파이썬으로 개발하다 보면 패키지 설치와 가상 환경 관리가 의외로 번거롭다는 걸 느끼게 되는데요. pip으로 패키지를 설치하고, venv로 가상 환경을 만들고, pyenv로 파이썬 버전을 바꾸고... 도구를 여러 개 써야 한다는 점이 특히 불편합니다. uv는 이런 고민을 한 방에 해결해주는 도구입니다. Rust로 작성되어 pip보다 10~100배 빠르고 패키지 설치부터 가상 환경, 파이썬 버전 관리까지 하나의 도구로 전부 처리할 수 있습니다. 이번 글에서는 uv를 설치하고 실제 프로젝트에서 활용하는 방법을 하나씩 살펴보겠습니다. uv