터미널에서 작업하다가 이메일 하나 확인하려고 브라우저를 여는 게 은근 번거롭지 않나요? 코드 리뷰 알림이 왔는지 확인하려고 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 도구입니다.
지난 포스팅에서는 저장소의 특정 브랜치를 배포 디렉토리로 지정하여 아주 쉽고 빠르게 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
Google Cloud Console에서 VM 하나 만들려고 브라우저를 열고, 프로젝트를 전환하려고 또 클릭하고, 배포 상태를 확인하려고 다시 페이지를 새로고침하고... 이런 경험 없으신가요? gcloud는 Google Cloud의 공식 CLI 도구입니다. Compute Engine, Cloud Storage, Cloud Run, BigQuery 같은 주요 서비스를 터미널 명령어 하나로 다룰 수 있어서 브라우저 없이도 클라우드 리소스를 관리할 수 있는데요. 셸 스크립트나 CI/CD 파이프라인에서도 그대로 쓸 수 있어서 자동화에도 딱
오픈소스 프로젝트를 운영하다 보면 코드 기여자에게만 공을 돌리기 쉽습니다. 하지만 문서 작성, 번역, 버그 리포트, 디자인, 아이디어 제안 등 다양한 방식으로 프로젝트에 기여하는 분들도 많죠. 이런 다양한 기여자들을 빠짐없이 인정해주고 싶은데, 어떻게 해야 할까요? 🤔 이번 포스팅에서는 All Contributors라는 도구를 소개해드리려고 합니다. All Contributors는 코드 기여뿐만 아니라 모든 형태의 기여를 인정하자는 철학을 담은 명세(specification)이자, 이를 자동화해주는 봇과 CLI 도구입니다. All
JWT access token을 써본 분이라면 이런 순간을 마주쳤을 겁니다. "토큰이 진짜인지는 서명으로 검증한다는데, 그 서명을 확인할 공개 키는 도대체 어디서 얻지?" 또 "Authorization Server가 키를 바꾸면 Resource Server는 그걸 어떻게 따라가지?" 이 두 질문에 한 번에 답하는 장치가 **JWKS(JSON Web Key Set)**입니다. 정확한 출처는 JOSE 스펙인 RFC 7517이고, OAuth는 이 조각을 jwks_uri라는 필드로 빌려다 씁니다. 이 글에서는 JWKS 문서의 구조부터 ki
CSS에서 자식이나 후손 요소는 아주 쉽게 선택할 수 있지만, 부모나 조상 요소를 선택하는 것은 불가능한 일이 었습니다. 그래서 오랫동안 자바스크립트를 동원해서 이러한 문제를 해결하곤 했었죠. 하지만 CSS에 :has() 가상 클래스가 추가되면서 이것도 이제 옛말이 되었습니다. 웹 개발자들이 많이 기다렸던 만큼 2023년 State of JS 설문 조사 가장 많이 채택된 기능으로 뽑히고도 했었죠. 이번 포스팅에서는 비교적 최근에 CSS에 추가된 기능인 :has() 가상 클래스를 어떻게 사용하는지 알아보도록 하겠습니다. 본 포스팅은