서버리스 애플리케이션을 만들고 싶은데 AWS Lambda는 너무 복잡하고, 배포도 번거롭다고 느껴본 적 있으신가요? 🤔 Cloudflare Workers를 사용하면 간단한 자바스크립트 코드 몇 줄로 전 세계 300개 이상의 엣지 로케이션에서 실행되는 서버리스 함수를 만들 수 있습니다. 이번 포스팅에서는 Cloudflare Workers의 기본 개념부터 실제 배포까지 단계별로 알아보겠습니다. Cloudflare Workers란? Cloudflare Workers는 Cloudflare의 엣지 네트워크에서 실행되는 서버리스 플랫폼입니다
파이썬으로 개발하다 보면 패키지 설치와 가상 환경 관리가 의외로 번거롭다는 걸 느끼게 되는데요. pip으로 패키지를 설치하고, venv로 가상 환경을 만들고, pyenv로 파이썬 버전을 바꾸고... 도구를 여러 개 써야 한다는 점이 특히 불편합니다. uv는 이런 고민을 한 방에 해결해주는 도구입니다. Rust로 작성되어 pip보다 10~100배 빠르고 패키지 설치부터 가상 환경, 파이썬 버전 관리까지 하나의 도구로 전부 처리할 수 있습니다. 이번 글에서는 uv를 설치하고 실제 프로젝트에서 활용하는 방법을 하나씩 살펴보겠습니다. uv
터미널에서 작업하다가 이메일 하나 확인하려고 브라우저를 여는 게 은근 번거롭지 않나요? 코드 리뷰 알림이 왔는지 확인하려고 Gmail 탭을 열었다가 어느새 유튜브까지 넘어가 있는 자신을 발견하곤 합니다. 😅 Himalaya는 이런 상황에 딱 맞는 CLI 이메일 클라이언트예요. IMAP과 SMTP를 지원하기 때문에 터미널을 떠나지 않고도 이메일을 읽고, 보내고, 정리할 수 있습니다. Rust로 만들어져서 빠른 건 물론이고 TUI가 아닌 CLI라 다른 도구와 엮어 쓰기에도 좋아요. 이번 글에서는 설치부터 실제로 이메일을 주고받는 데까
Gradle은 Java와 Kotlin과 같이 JVM에서 돌아가는 프로그래밍 언어에서 거의 표준으로 자리집은 빌드 도구입니다. 이번 포스팅에서는 Kotlin 개발자 분들을 위해서 Gradle에 대해 간단히 소개해드리도록 하겠습니다. (출처: https://docs.gradle.org/current/userguide/gradle_basics.html) 기존 프로젝트 기존 Kotlin 프로젝트에 합류하시는 개발자이시라면 이미 Gradle로 빌드를 하고 있을 확률이 매우 높은데요. 이미 Gradle가 빌드 도구로 설정되어 있는 프로젝트에서
혹시 오픈 소스 프로젝트를 시작하시면서 어떤 라이선스를 선택할지 몰라서 고민해본 적이 있으신가요? 깃허브에서는 코드 저장소를 생성할 때 항상 어떤 라이선스를 사용하지 물어보죠. 이번 포스팅에서는 MIT, Apache, GPL 등 널리 사용되는 오픈 소스 라이선스를 소개해드리고, 각 라이선스를 언제 선택하면 좋은지 알아보겠습니다. 오픈 소스 라이선스란? 오픈 소스 라이선스는 오픈 소스 소프트웨어가 어떻게 사용될 수 있는지 명시해주는 문서입니다. 개발자는 오픈 소스 라이선스를 통해서 소프트웨어의 소스 코드를 사용, 수정, 배포할 수 있
소프트웨어 개발을 하다 보면 터미널 앱을 꽤 오래 고민하게 됩니다. 운영체제 기본 터미널부터 iTerm2, Kitty, Hyper, Warp까지 이것저것 써봤는데요. 요즘 개발자 커뮤니티에서 Ghostty라는 터미널에 대한 칭찬이 끊이질 않길래 한번 설치해봤더니, 완전히 취향저격이었습니다. Hyper나 Warp처럼 화려한 UI나 부가 기능이 잔뜩 달려 있지는 않아요. 대신 터미널 본연의 기능에 충실하면서 깔끔하고 직관적인 인터페이스를 갖추고 있어서, 쓸수록 만족감이 올라가는 유형의 도구입니다. 왜 또 새로운 터미널인가요? 기존 터미
9년 전, daleseo.com 블로그를 시작하기를 망설이며 제 자신에게 끊임없이 되 묻던 질문입니다. "망망대해 같은 인터넷에 좋은 자료가 이미 넘쳐나는데 사람들이 뭐하러 나 같은 평범한 개발자의 글을 읽으러 오겠어?"라는 생각 때문에 오랫동안 주저했습니다. 당시에 블로그는 주로 네이버나 다음과 같은 대형 포털에 있었기 때문에, 저처럼 개인이 직접 운영하는 블로그를 누가 찾아올지 의문이었습니다. 혹시나 하는 마음으로 조심스래 첫 포스팅을 해봤는데 역시 아무런 반응이 없었습니다. 두 번째 포스팅, 세 번째 포스팅, 네 번째 포스팅에
Kotlin의 Scope 함수는 객체의 컨텍스트 내에서 코드 블록을 실행할 수 있게 해주는 강력한 기능입니다. Scope 함수에는 let(), run(), also(), apply(), with() 이렇게 5개가 있는데요. 얘네들이 비슷한 것 같으면서도 미묘하게 달려서 잘 정리해두지 않으면 언제 어떤 녀석을 써야 하는지 은근히 헷갈릴 수 있습니다. 이번 포스팅에서는 Kotlin의 Scope 함수 5종의 사용법을 정리해드리도록 하겠습니다. 예제 클래스 다음과 같이 간단한 클래스를 가지고 간단한 예제 코드를 작성하면서 각 Scope 함
OAuth 2.0 스펙은 /authorize나 /token 같은 엔드포인트가 존재해야 한다고는 말하지만, 실제로 어떤 경로에 두어야 하는지는 정하지 않습니다. 그래서 한동안 관행은 단순했어요. "구글은 accounts.google.com/o/oauth2/v2/auth, GitHub는 github.com/login/oauth/authorize" 같은 정보를 사람이 공식 문서에서 읽어다가 클라이언트 코드에 박아 넣는 방식이었죠. 이 방식은 금방 한계를 드러냈어요. 새로운 Identity Provider(이하 IdP)를 추가할 때마다 코
웹 애플리케이션을 개발하다 보면 "이거 진짜 브라우저에서도 잘 되나?" 하는 불안감이 들 때가 있죠. 단위 테스트로 함수 하나하나는 검증했지만, 사용자가 실제로 버튼을 클릭하고 페이지를 이동하고 폼을 제출하는 흐름까지 테스트하려면 별도의 도구가 필요합니다. 이런 종단간(End-to-End) 테스트를 위해 등장한 것이 바로 Playwright입니다. 이 글에서는 Playwright가 무엇인지 살펴보고, 설치부터 테스트 작성과 실행, 그리고 디버깅까지 E2E 테스트의 전체 흐름을 다뤄보겠습니다. Playwright란? Playwrigh
JDBC(Java Database Connectivity)는 JVM 위에서 돌아가는 애플리케이션이 데이터베이스와 상호작용하는 데 근간이 되는 API입니다. 이번 포스팅에서는 간단한 예제를 통해서 Kotlin에서 JDBC API를 어떻게 사용하는지에 대해서 살펴보도록 하겠습니다. JDBC API 패키지 JDBC API는 java.sql과 javax.sql, 이렇게 두 개의 패키지로 구성되어 있는데요. java.sql 패키지는 데이터베이스 연결, SQL 쿼리 실행, 결과 집합 처리에 필요한 클래스와 인터페이스를 제공합니다. 본 포스팅에
색상 모델(color space)은 웹 디자인에서 아주 중요한 역할을 합니다. CSS에서는 기존에 RGB나 HSL 모델이 주로 사용되었지만, 최근에는 새로운 색상 모델인 OKLCH가 도입되어 점점 많은 프로젝트에서 채택되고 있습니다. 이번 포스팅에서는 OKLCH이 기존 색상 모델과 어떻게 다른지 알아보고, 간단한 실습을 통해서 OKLCH의 특장점을 살펴보겠습니다. OKLCH 색상 모델이란? 색상 모델(color model)이란 색상을 나타내기 위해서 사용되는 모델 또는 시스템을 뜻합니다. 아주 옛날부터 많이 사용되었던 색상 모델인
GraphQL을 사용하다 보면 스키마를 관리하는 일이 점점 중요해지는데요. 팀원이 늘어나고 서비스가 커지면서 "이 필드 바꿔도 기존 클라이언트에 문제 없을까?", "지금 운영 중인 스키마가 정확히 뭐였지?" 같은 고민이 생기기 마련이잖아요? 😅 이럴 때 큰 도움이 되는 도구가 바로 Apollo에서 만든 Rover CLI입니다. 이번 글에서는 Rover CLI의 설치부터 주요 명령어, CI/CD 파이프라인 연동까지 쭉 다뤄보겠습니다. Rover CLI란? Rover는 Apollo GraphQL에서 제공하는 공식 CLI 도구입니다.
오픈소스를 운영하다 보면 스타가 늘거나 이슈가 쌓이는 일에는 어느새 익숙해지는데요. 그러던 어느 날 저장소 Security and quality 탭에 처음 보는 빨간 알림이 뜨고 "당신의 패키지에서 보안 취약점을 발견했습니다"라는 제보가 들어오면 이야기가 달라집니다. 머릿속이 하얗게 변하면서 "이걸 이슈로 답해야 하나? 일단 코드부터 고쳐서 푸시할까?" 하는 생각이 먼저 떠오르죠. 😅 이건 결코 남의 일이 아닌데요. 2021년 전 세계 서버를 떨게 한 Log4j의 Log4Shell 같은 대형 사건도 있었지만, 멀리 갈 것도 없이
지난 포스팅에서는 저장소의 특정 브랜치를 배포 디렉토리로 지정하여 아주 쉽고 빠르게 GitHub Pages로 웹사이트를 호스팅할 수 있다고 배웠는데요. 하지만 요즘 웹 개발에서 HTML, CSS, JavaScript를 직접 작성하는 일은 드물죠? 대부분 React와 같은 프론트엔드 라이브러리와 Vite와 같은 빌드 도구를 사용하여 HTML, CSS, JavaScript를 생성해낼 것입니다. 이번 포스팅에서는 웹 프로젝트를 GitHub Actions를 사용하여 빌드하고, 빌드 결과물을 바로 GitHub Pages에 배포하는 방법에 대
웹 애플리케이션을 개발하다 보면 로컬에서 실행 중인 서버를 외부에서 접속할 수 있게 해야 할 때가 있습니다. 예를 들어, 작업 중인 결과물을 클라이언트나 동료에게 시연해야 하거나, 외부 서비스(예: GitHub, Stripe, Slack)의 웹훅(Webhook)을 테스트해야 하는 경우가 그렇죠. 매번 클라우드 서버에 배포하는 것은 번거롭고 시간도 오래 걸립니다. 공유기 설정을 건드려서 포트 포워딩을 하는 것도 보안상 위험할 수 있고요. 이럴 때 가장 간편하게 사용할 수 있는 도구가 바로 ngrok입니다. ngrok은 로컬 컴퓨터의
GitHub Pages에 웹사이트를 배포하면 기본적으로 github.io 서브 도메인을 무료로 제공해주는데요. 대부분의 개인 프로젝트에서는 GitHub Pages의 기본 도메인을 사용해도 큰 지장이 없을 것입니다. 하지만 비즈니스를 위한 웹사이트를 호스팅할 때는 브랜딩이나 SEO(검색 엔진 최적화) 차원에서 커스텀 도메인을 원하게 되죠. 이번 포스팅에서는 간단한 실습을 통해서 GitHub Pages에 배포한 웹사이트에 커스텀 도메인을 연결하는 방법을 알려드리겠습니다. 커스텀 도메인 구매 GitHub Pages에 커스텀 도메인을 연결
GitHub Pages는 깃허브에서 코드 저장소에 딸려오는 무료 호스팅 서비스입니다. GitHub Pages를 사용하면 정적 웹사이트, 블로그, 포트폴리오, 프로젝트 문서 등을 아주 손쉽게 웹에 배포할 수 있죠. 이번 포스팅에서는 간단한 실습을 통해서 GitHub Pages에 웹사이트를 배포하는 가장 기초적인 방법을 알려드리겠습니다. GitHub Pages란? GitHub Pages는 깃허브 저장소에 올려놓은 프로젝트를 최소한의 노력으로 웹에 호스팅해주는 서비스입니다. 깃허브에서 거의 초창기부터 무료로 제공하고 있는데 은근히 모르시
OAuth 2.0을 처음 배울 때는 "authorization code를 받아서 access token으로 바꾼다"는 큰 그림만 머리에 담아두어도 충분한데요. 하지만 실제로 연동을 구현하거나 디버깅하는 단계로 넘어가면, 어떤 엔드포인트에 어떤 파라미터를 어떤 조건으로 보내야 하는가가 성패를 좌우합니다. "동의 화면까지는 뜨는데 토큰 교환에서 invalid_grant가 뜬다", "리다이렉트가 자꾸 invalid_redirect_uri로 거부된다" 같은 이슈는 거의 전부 특정 엔드포인트의 파라미터 규약을 놓쳐서 생기거든요. OAuth
OAuth를 공부하다 보면 "Authorization Code Flow를 써라", "Client Credentials는 machine-to-machine용이다", "Implicit은 이제 쓰지 마라" 같은 말을 자주 듣게 됩니다. 처음에는 다 같은 OAuth처럼 보이는데, 왜 이렇게 flow가 여러 개인지 헷갈리기 쉽죠. 사실 스펙 관점에서 더 정확한 이름은 flow보다 grant type입니다. 클라이언트가 어떤 근거(grant)를 가지고 access token을 받아 오는지를 구분하는 이름인데요. 다만 실무 문서와 제품 콘솔에서