지금까지 OAuth를 이야기할 때는 늘 사용자가 주인공이었습니다. 인가 코드(Authorization Code) + PKCE 흐름에서 봤듯이, 사용자가 로그인하고 동의하면 그 사용자를 대신할 토큰이 발급되는 식이었죠. 그런데 현실에는 로그인할 사람이 아예 없는 통신도 많습니다. 새벽 3시에 도는 결제 배치 작업이 결제 API를 호출하고, 백엔드 서비스 A가 내부 서비스 B의 API를 두드리고, CI 파이프라인이 배포 API를 부르는 상황을 떠올려 보세요. 여기엔 브라우저도, 동의 화면도, 사용자도 없습니다. 이렇게 서버가 서버를 부
OAuth 2.0을 처음 배울 때는 "인가 코드(authorization code)를 받아서 액세스 토큰(access token)으로 바꾼다"는 큰 그림만 머리에 담아두어도 충분한데요. 하지만 실제로 연동을 구현하거나 디버깅하는 단계로 넘어가면, 어떤 엔드포인트에 어떤 파라미터를 어떤 조건으로 보내야 하는가가 성패를 좌우합니다. "동의 화면까지는 뜨는데 토큰 교환에서 invalid_grant가 뜬다", "리다이렉트가 자꾸 invalid_redirect_uri로 거부된다" 같은 이슈는 거의 전부 특정 엔드포인트의 파라미터 규약을 놓쳐
OAuth를 배우다 보면 결국 이 문장을 자주 만나게 됩니다. 사용자 로그인이 있으면 인가 코드(Authorization Code) + PKCE를 쓰세요. 맞는 말인데, 처음 구현할 때는 막상 손에 잘 잡히지 않습니다. code는 어디서 오고, code_verifier는 누가 들고 있어야 하고, state는 PKCE와 다른 건지 헷갈리거든요. 동의 화면까지는 잘 뜨는데 콜백에서 invalid_grant가 나거나, 토큰 교환에서 redirect_uri가 다르다고 거부되는 일도 흔합니다. 이 글에서는 인가 코드 + PKCE 흐름을 요청
OAuth를 공부하다 보면 "인가 코드 흐름(Authorization Code Flow)을 써라", "클라이언트 자격 증명(Client Credentials)은 서버 간 통신용이다", "암묵적 흐름(Implicit)은 이제 쓰지 마라" 같은 말을 자주 듣게 됩니다. 처음에는 다 같은 OAuth처럼 보이는데, 왜 이렇게 flow가 여러 개인지 헷갈리기 쉽죠. 사실 스펙 관점에서 더 정확한 이름은 흐름(flow)보다 **그랜트 유형(grant type)**입니다. 클라이언트가 어떤 근거(grant)를 가지고 액세스 토큰(access t
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를 검증하려면 서명을 확인할 공개 키가 필요한데요. 그런데 그 공개 키, 도대체 어떤 형식으로 표현하고 어떻게 주고받을까요? 전통적으로는 X.509 인증서나 PEM 같은 형식을 썼지만, JSON 기반인 JOSE 생태계에는 키를 위한 전용 형식이 따로 있습니다. 바로 **JWK(JSON Web Key)**입니다. 키 하나를 JWK로 표현하고, 여러 JWK를 묶으면 **JWKS(JWK Set)**가 되는데요. OAuth/OIDC에서 인가 서버가 공개 키를 배포할 때 쓰는 그 꾸러미가 바로 JWKS입니다. 이 글에서는 JWK가 무엇
남은 신호는 로그 하나입니다. 그런데 지표 정리까지 왔다면 좀 이상하게 느껴질 거예요. 로그는 이미 다들 쓰고 있잖아요. 😅 파이썬이면 logging, Node라면 Pino나 Winston을 붙여 두고 잘 돌아가는데 여기에 또 새로운 걸 얹어야 하나 싶죠. OpenTelemetry도 같은 생각을 했습니다. 그래서 로그만 다른 길을 갔어요. 이 글에서는 그 선택이 무엇이었는지, 그리고 기존 로그를 추적과 이어 붙이는 방법을 다루겠습니다. 로그만 접근이 달랐던 이유 추적과 지표는 OpenTelemetry가 새로 표준을 만들었습니다.
CSS에서 자식이나 후손 요소는 아주 쉽게 선택할 수 있지만, 부모나 조상 요소를 선택하는 것은 불가능한 일이 었습니다. 그래서 오랫동안 자바스크립트를 동원해서 이러한 문제를 해결하곤 했었죠. 하지만 CSS에 :has() 가상 클래스가 추가되면서 이것도 이제 옛말이 되었습니다. 웹 개발자들이 많이 기다렸던 만큼 2023년 State of JS 설문 조사 가장 많이 채택된 기능으로 뽑히고도 했었죠. 이번 포스팅에서는 비교적 최근에 CSS에 추가된 기능인 :has() 가상 클래스를 어떻게 사용하는지 알아보도록 하겠습니다. 본 포스팅은
데이터를 특정 기준에 따라 분류하는 것은 자바스크립트로 데이터 처리를 할 때 자주 필요한 작업인데요. 그런데 아직도 데이터 그룹화를 위해서 reduce() 함수나 Lodash 라이브러리를 사용하시나요? 이번 포스팅에서는 자바스크립트에서 데이터를 그룹화를 위해 쓸 수 있는 비교적 새로운 API인 groupBy()에 대해서 알아보도록 하겠습니다. 기존 데이터 그룹화 방법 우선 예전에 자바스크립트에서 데이터 그룹화가 얼마나 불편했는지 살펴볼까요? 다음과 같이 여러 사용자의 이름, 나이, 국가를 담은 배열이 주어졌을 때, 아래와 같이 국가
React로 화면을 만들다 보면 useMemo를 써야 할지, useCallback으로 감싸야 할지, 의존성 배열에 뭘 빠뜨리지는 않았는지 고민하는 시간이 꽤 길어지는데요. 값이 바뀌면 화면이 바뀐다는 단순한 아이디어를 위해 이렇게 많은 걸 신경 써야 하는지 의문이 들 때가 있습니다. 🤔 Svelte는 이 문제를 런타임이 아니라 컴파일러로 풀어 온 프레임워크입니다. 그리고 2024년 10월 19일, 반응성(reactivity) 모델을 처음부터 다시 설계한 Svelte 5가 정식으로 출시됐는데요. 이번 글에서는 Svelte가 다른 프
SSH로 원격 서버에 접속해서 배포 스크립트를 돌리고 있는데 갑자기 인터넷이 끊겼습니다. 다시 접속해보니 실행하던 프로세스가 사라져 있어요. 처음부터 다시 해야 합니다. 😅 이런 경험, 서버 작업을 해보신 분이라면 한 번쯤 겪어보셨을 거예요. 아니면 터미널 탭을 10개쯤 열어놓고 "아까 그 로그 보던 탭이 어디였지?" 하고 헤매본 적도 있으실 테고요. tmux는 이 두 가지 문제를 한 번에 해결해주는 터미널 멀티플렉서입니다. 1987년 GNU Screen에서 시작된 터미널 멀티플렉서의 계보를 잇는 도구로, 2007년에 처음 등장한
CSS에서 스타일이 적용되는 범위를 제한하는 일(CSS Scoping)은 오랫동안 웹 개발자들에게 굉장히 커더란 숙제였습니다. 소규모 웹사이트에서는 스타일 충돌을 막기 위해서 BEM(Block Element Modifier)와 같이 클래스의 이름을 일관적으로 짓기 위한 섬세한 규칙을 정해놓고 모든 개발자들이 기억하고 따라야 했습니다. 어느 정도 규모가 있는 앱 애플레케이션을 개발할 때는 React, Svelte, Vue와 같은 프론트엔드 프레임워크의 도움을 받거나 CSS 모듈 또는 CSS-in-JS를 사용해야 특정 컴포넌트에만 스타
웹 개발을 하다보면 CSS를 작성할 때 원하는 스타일이 우선적으로 적용되지 않아서 골치가 아플 때가 많습니다. 특히 대규모 프로젝트에서는 여러 CSS 파일에서 스타일을 가져오다 보니 스타일의 우선순위를 파악하는 것이 쉽지 않죠. 이런 문제를 해결하기 위해 CSS에는 @layer라는 새로운 at-rule을 도입되었습니다. 이번 포스팅에서는 @layer를 사용하여 CSS 스타일 시트를 계층화하여 우선순위를 효과적으로 설정하는 방법에 대해서 알아보겠습니다. 기존의 스타일 우선순위 관리법 CSS에 @layer가 없던 시절에는 동일한 요소를
Bun이 Node.js를 잇는 차세대 자바스크립트 런타임으로 급 부상하면서, Bun을 위해서 탄생한 웹 프레임워크인 Elysia도 큰 관심을 받고 있습니다. 이번 포스팅에서는 Elysia의 주요 특징과 사용법, 그리고 Elysia가 다른 웹 프레임워크와 어떻게 차별화되는지에 대해서 살펴보겠습니다. Elysia란? Express 프레임워크가 Node.js 생태계에서 대표 웹 프레임워크를 담당하고 있다면 Elysia는 Bun 생태계에서 비슷한 역할과 인지도를 갖고 있는 하고 있는 웹 프레임워크입니다. 물론 간단한 웹 서버를 개발할 때는
마침내 제가 쓴 자바스크립트 책, "헬로 Bun"이 출간되어 온라인 서점에서 예약 판매가 시작되었습니다. Bun은 아직 국내에는 많이 알려지지 않았지만, 해외에서는 Node.js의 뒤를 잇는 차세대 자바스크립트 런타임으로 주목받고 있습니다. JavaScript Rising Stars 🌟 2023 집계에서 당당히 2위를 차지한 오픈 소스 프로젝트이며, State of JS 2023 설문 조사에서 개발자 응답에 가장 많이 오르고 내린 정말 HOT🔥한 기술입니다. 사실 처음 Bun을 접했을 때는 제가 국내에 이 기술을 소개하는 책까지
CSS 코드를 작성하다 보면 "이 속성 순서가 맞나?", "컬러 값을 hex로 쓸까 rgb로 쓸까?", "이 선택자는 너무 복잡한 거 아닌가?" 같은 고민을 하게 되는데요. 특히 여러 명이 함께 작업하는 프로젝트에서는 각자 선호하는 CSS 작성 스타일이 달라서 코드 리뷰 때마다 사소한 의견 차이로 시간을 낭비하기 일쑤입니다. 🤔 자바스크립트에는 ESLint라는 훌륭한 린터가 있어서 코드 품질을 자동으로 검사하고 일관된 스타일을 유지할 수 있는데요. CSS에도 이와 똑같은 역할을 해주는 도구가 있습니다. 바로 Stylelint입니다
코드 에디터 하면 VSCode를 떠올리시는 분이 많을 텐데요. 실제로 VSCode가 시장을 지배하고 있지만 가끔 무겁다고 느끼신 적 없나요? 확장을 좀 설치하다 보면 메모리를 잡아먹고, Electron 기반이다 보니 네이티브 앱만큼 빠릿빠릿하지는 않죠. Zed는 이런 불만을 정면으로 해결하려는 코드 에디터입니다. Atom을 만들었던 Nathan Sobo가 Atom의 단종 이후 새로 시작한 프로젝트인데요. Rust로 처음부터 다시 만들어서 GPU 가속 렌더링으로 120 FPS에 가까운 성능을 내고 실시간 협업과 AI 코딩 기능까지 기
지난 포스팅는 HTML, CSS, JavaScript 만으로 UI 컴포넌트를 만들 수 있는 웹 표준 기술인 웹 컴포넌트(Web Components)에 대해서 기본 개념을 잡아보았습니다. 이번 포스팅에서는 웹 컴포넌트를 좀 더 제대로 쓰기 위해서 사용자 정의 요소에 속성(attribute)으로 주어진 값을 활용하는 방법에 대해서 배우도록 하겠습니다. HTML 템플릿 작성 우선 웹 컴포넌트에서 사용할 HTML 코드를 보관하기 위한 HTML 템플릿을 작성해보겠습니다. HTML 템플릿이란 <template> 요소를 사용해서 작성하는 HTM
React 앱을 만들다 보면 라우팅은 빠질 수 없는 주제입니다. 대부분 React Router를 쓰고 있을 텐데요. 잘 동작하긴 하지만, 경로를 오타 내도 런타임까지 가야 알 수 있고, URL 검색 파라미터를 다루려면 직접 파싱하고 타입을 붙여야 하는 번거로움이 있죠. TanStack Router는 이런 불편함을 정면으로 해결하려는 라이브러리입니다. TanStack Query와 TanStack Form으로 유명한 TanStack 생태계의 라우팅 솔루션인데요. 라우트 경로, 파라미터, 검색 파라미터, 로더 데이터까지 전부 TypeSc