요즘 Model Context Protocol이나 A2A 프로토콜 관련 글을 보다 보면 "JSON-RPC 2.0 위에서 동작한다"는 표현을 자주 마주치게 되는데요. 이름만 들으면 거창해 보이지만 막상 스펙을 펼쳐보면 한 페이지로도 충분히 설명되는 작고 단순한 프로토콜입니다. 😅 JSON으로 메서드 이름과 인자를 보내고 결과를 JSON으로 받는다는, 정말 그게 전부거든요. 이번 포스팅에서는 JSON-RPC 2.0이 어떤 구조로 메시지를 주고받는지, REST와는 무엇이 다른지, 그리고 왜 최근 AI 도구 생태계가 다시 이 오래된 프로
자바스크립트로 날짜를 다뤄본 분이라면 한 번쯤은 Date 객체에 좌절해본 경험이 있을 텐데요. 월(month)이 0부터 시작하는 건 왜 그런 건지, 시간대 변환은 왜 이리 복잡한 건지, setDate()를 호출했더니 원본 객체가 변해버리는 건 또 뭔지... 🤦 그래서 moment.js나 date-fns, Day.js 같은 외부 라이브러리 없이는 날짜를 제대로 다루기 어려웠죠. 그런데 드디어 자바스크립트에 Temporal이라는 새로운 날짜/시간 API가 등장했습니다! State of JS 설문에서 "가장 기대하는 새 기능" 1위를
드디어 시리즈의 마지막 편입니다. 1편부터 7편까지 GraphQL 명세의 본문 여섯 개 장을 차례로 읽어왔는데요. 그동안 곳곳에서 "이건 September 2025에서 새로 들어왔다", "자세한 건 마지막 편에서"라며 미뤄둔 이야기들이 있었습니다. 이번 편에서 그 약속들을 한자리에 모아 갚으려고 합니다. 1편에서 짚었듯 September 2025 에디션은 2021년 10월 이후 4년 만의 정식 개정판입니다. 그동안 쌓인 변경 제안이 한꺼번에 반영됐는데요. 흥미로운 건 핵심 신규 기능들을 나란히 놓고 보면, 하나의 방향을 가리키고 있
지난 편에서 쿼리가 실행되어 데이터가 채워지는 과정까지 따라왔는데요. 이제 그 결과를 클라이언트에게 어떤 모양으로 돌려줄지를 정하는 마지막 단계, 명세 제7장 응답(Response) 차례입니다. 우리가 GraphQL을 쓸 때마다 마주하는 그 { "data": ... } JSON이 왜 항상 그렇게 생겼는지, 에러는 왜 별도의 배열로 따로 담기는지가 이번 편에서 분명해집니다. 응답은 명세에서 가장 짧은 장에 속하지만, 클라이언트 코드를 작성할 때 매일 부딪히는 부분이라 정확히 알아두면 두고두고 도움이 됩니다. 응답의 최상위에는 세 개의
Rust로 HTTP 서버를 짜다 보면 프레임워크 선택에서 한 번씩 막힙니다. actix-web은 성능이 검증됐지만 액터 모델이 낯설고, warp는 함수형 스타일이 깔끔한데 타입 에러가 미로처럼 느껴질 때가 있습니다. Axum은 Tokio 팀이 만든 웹 프레임워크입니다. "Tower 위의 얇은 라우팅 레이어"를 표방하는데, 이게 생각보다 실용적입니다. 타임아웃이나 인증 미들웨어를 Tower로 짜두면 Axum에 그대로 끼울 수 있고, 핸들러 함수 시그니처에 타입만 선언해두면 Axum이 요청에서 필요한 데이터를 알아서 꺼내줍니다. 이 글
지난 편에서 검증을 통과한 쿼리는 이제 실제로 데이터를 채워 넣을 준비가 됐습니다. 그 일을 다루는 것이 명세 제6장 실행(Execution) 인데요. GraphQL 명세에서 가장 흥미로운 동작들이 바로 이 장에 숨어 있습니다. 특히 "왜 필드 하나가 실패했는데 부모 객체까지 통째로 null이 되지?" 같은, 실무에서 한 번쯤 당황했을 동작의 정체가 여기서 밝혀집니다. 이번 편에서는 서버가 쿼리를 어떻게 한 필드씩 실행하는지, query와 mutation의 실행 순서가 왜 다른지, 그리고 에러가 났을 때 null이 어떻게 번지는지를
GraphiQL에서 존재하지 않는 필드를 입력하면, 실행하기도 전에 빨간 밑줄이 그어지면서 "그런 필드는 없다"고 알려주는 걸 보셨을 텐데요. 서버에 요청을 보내지도 않았는데 어떻게 틀렸다는 걸 알았을까요? 바로 GraphQL이 쿼리를 실행하기 전에 한 단계를 더 거치기 때문입니다. 그 단계가 이번 편의 주제인 검증(Validation) 입니다. 지난 편에서 본 인트로스펙션으로 스키마 정보를 손에 쥐면, 어떤 쿼리가 그 스키마에 맞는지 안 맞는지를 실행 없이도 판단할 수 있습니다. 명세 제5장은 바로 이 "맞는 쿼리"의 조건을 규칙
GraphiQL이나 Apollo Studio 같은 도구를 써보셨다면, 필드 이름을 한 글자만 입력해도 가능한 필드 목록이 주르륵 뜨는 경험을 하셨을 텐데요. 신기하게도 도구는 우리가 쓰는 서버의 스키마를 미리 다 알고 있는 것처럼 동작합니다. 누가 그 정보를 알려준 걸까요? 답은 GraphQL 서버 자신입니다. GraphQL 스키마는 자기 자신에 대한 정보를 GraphQL 쿼리로 되물을 수 있도록 설계되어 있는데요. 이 능력을 인트로스펙션(Introspection) 이라고 부르고, 명세 제4장이 이걸 다룹니다. 지난 편에서 본 타입
지난 편에서 우리가 작성하는 쿼리 문서의 문법을 살펴봤는데요. 그런데 쿼리는 혼자서는 아무 의미가 없습니다. user(id: "1") { name }이라는 요청이 말이 되려면, 서버 쪽에 "User라는 타입이 있고, 거기에 name이라는 필드가 있다"는 약속이 미리 정의되어 있어야 하니까요. 그 약속이 바로 스키마(schema) 이고, 스키마를 이루는 재료가 이번 편의 주제인 타입 시스템(Type System) 입니다. 명세 제3장은 GraphQL에서 가장 분량이 많고 중요한 장입니다. 서버가 어떤 타입들을 조합해 스키마를 짤 수
지난 편에서 GraphQL 명세가 어떤 문서이고 왜 읽어야 하는지 함께 살펴봤는데요. 이번 편부터는 본격적으로 명세 본문으로 들어갑니다. 첫 번째 본문 장은 제2장 Language, 그러니까 우리가 클라이언트에서 작성해 서버로 보내는 그 쿼리 텍스트의 문법을 다루는 장입니다. 평소에 별생각 없이 { user { name } } 같은 쿼리를 작성하셨겠지만, 이 짧은 텍스트 안에도 명세가 엄밀하게 정의한 문법 규칙이 빼곡히 들어 있는데요. 이번 편에서는 GraphQL 문서가 어떤 부품들로 조립되는지, 연산부터 디렉티브까지 하나씩 분해해
GraphQL로 API를 몇 번 만들어보셨다면 쿼리를 작성하고, 스키마를 정의하고, 리졸버를 붙이는 일에는 꽤 익숙하실 텐데요. 그런데 혹시 흔히 "스펙"이라고도 부르는 GraphQL 공식 명세(specification) 를 직접 펼쳐본 적 있으신가요? 아마 대부분은 "그런 게 있다는 건 아는데, 실무에서 Apollo만 잘 쓰면 되지 않나?"라고 생각하셨을 것 같습니다. 😅 저도 오랫동안 그랬습니다. 그런데 막상 명세를 읽어보니, 평소에 "왜 이렇게 동작하지?" 하고 넘어갔던 수많은 질문에 대한 답이 거기 다 적혀 있더라고요. 마
웹 API를 호출하거나 외부 서비스와 통신해야 하는 상황은 어떤 언어로 개발하든 빈번하게 마주치게 됩니다. Rust에서는 이런 HTTP 통신을 위해 reqwest라는 크레이트가 사실상 표준처럼 사용되고 있는데요. Python의 requests 라이브러리처럼 직관적인 API를 제공하면서도 Rust답게 타입 안전성과 비동기 처리를 지원하는 것이 특징입니다. 이 글에서는 reqwest 크레이트의 기본적인 사용법부터 실무에서 자주 쓰이는 패턴까지 예제와 함께 살펴보겠습니다. reqwest란? reqwest는 Rust 생태계에서 가장 널리
웹 개발자라면 한 번쯤은 CORS 문제 때문에 골치아팠던 적이 있으시죠? Cross-Origin Resource Sharing, 줄여서 CORS는 웹 페이지가 다른 도메인의 리소스에 안전하게 접근할 수 도와주는 브라우저의 기능입니다. 이번 포스팅에서는 CORS의 기본 개념부터 작동 원리, 요청 흐름 그리고 실제 구현 방법까지 자세히 다루도록 하겠습니다. 동일 출처 정책 CORS를 제대로 이해하려면 우선 브라우저의 기본 보안 기능인 Same-Origin Policy, 즉 동일 출저 정책에 대해서 알고 있어야 합니다. 브라우저는 현재
웹 개발을 하다 보면 한 가지 의문이 드는 순간이 있습니다. 버튼 하나 클릭했을 때 서버에서 데이터 받아와서 화면 일부만 바꾸고 싶은데, 꼭 React나 Vue 같은 프레임워크를 써야 할까? 간단한 검색 폼이나 좋아요 버튼 하나 만드는데 JavaScript를 수십 줄씩 작성하는 게 과연 맞는 걸까? 이런 고민은 사실 꽤 오래전부터 있었어요. SPA(Single Page Application)가 대세가 되면서 JavaScript 코드는 점점 늘어났고 빌드 도구도 복잡해졌고 번들 크기도 커졌죠. 그런데 정작 만들고 싶었던 건 "클릭하면
최근에 사이드 프로젝트를 하다가 매우 신기한 경험을 하게 되어 공유드리려고 해요. OpenAI 회원 가입을 하면 소정의 무료 크레딧을 주죠? 제가 몇 달전에는 가입할 때는 $18을 줬는데, 요즘에는 $5로 줄어든 것 같더라고요. 처음에는 이 크레딧이 얼마나 많은 건지 몰랐는데, 제가 한 달동안 ChatGPT에 대해서 공부하면서 블로그 글을 쓰고, 유튜브 영상을 찍으면서 OpenAI의 API를 정말 물쓰듯이 호출해보았지만, $1도 못 썼다는 것을 알게 되었습니다. 😅 그래서 남아도는 OpenAI의 무료 크레딧을 어떻게 하면 좀 더
URL이 바뀔 때 마다 새로운 페이지를 서버로 요청하지 않는 SPA(Single Page Application)에서는 보통 클라이언트 단에서 라우팅(routing)을 하는데요. 그래서 React, Svelte, Vue.js와 같은 대부분의 프론트엔드 프레임워크을 사용할 때는 이러한 클라이언트 단 라우팅을 지원하는 라이브러리와 함께 쓰는 경우가 많습니다. 그런데 이러한 라우팅 라이브러리는 대부분은 내부적으로 자바스크립트의 History API를 사용하고 있다는 것을 알고 계셨나요? 이번 글에서는 클라이언트 단 라우팅을 이해하는데 핵심
지난 포스팅에서는 URL API의 URL을 사용하여 좀 더 안전하게 웹 주소 다루는 방법에 대해서 살펴보았는데요. 이번 포스팅에서는 URL API에서 제공하는 또 다른 유용한 기능인 URLSearchParams를 이용하여 웹 주소의 구성 요소 중에서도 가장 다루기 어려운 쿼리 스트링(Query String) 다루는 방법에 대해서 알아보겠습니다. URLSearchParams 객체의 필요성 자바스크립트의 URLSearchParams에 대해서 본격적으로 배우기 전에 먼저 URL의 쿼리 스트링에 대해서 짚고 넘어가는 게 좋을 것 같아요.
웹 개발에서 URL을 다루는 일은 참 빈번하게 발생하죠? 프론트엔드에서는 URL로 다른 웹페이지로 링크를 걸고, CSS와 자바스크립트 코드를 불러오며, 이미지, 오디오, 비디오와 같은 멀티미디어도 제공할 수 있습니다. 반면에 백엔드에서는 요청 URL의 경로에 따라서 DB에 저장되어 있는 데이터를 조회하고 URL의 쿼리 스트링으로 넘어온 매개변수에 따라서 다른 데이터 처리를 해줄 수 있습니다. 이번 글에서는 웹 주소를 좀 더 안전하게 다룰 수 있도록 도와주는 자바스크립트의 URL API에 대해 알아보겠습니다. URL이란? 우리는 거의
ChatGPT와 같은 LLM(Large Language Model, 대형 언어 모델)이 등장하면서 웹에서 텍스트를 스트리밍하는 사례가 점점 늘어나고 있는데요. 그에 따라 별다른 라이브러리없이도 웹에서 스트림을 쓰고 읽을 수 있는 자바스크립트의 Streams API가 다시 주목받고 있는 것 같습니다. 이번 포스팅에서는 자바스크립트의 Streams API을 사용하여 스트림을 생성하고 데이터를 읽는 방법에 대해서 알아보겠습니다. 읽을 수 있는 스트림 생성 자바스크립트에서 데이터를 읽을 수 있는 스트림을 만들 때는 ReadableStrea
깃허브(GitHub)는 개발자들이 소프트웨어 프로젝트를 관리하고 협업하는 데 필요한 다양한 기능을 제공하는 매우 인기있는 플랫폼인데요. 일상적인 개발을 할 때는 깃허브의 웹사이트를 통해서 대부분의 작업을 처리할 수 있지만 개발 과정을 자동화하거나 다른 개발 도구와 통합할 때는 프로그래밍적으로 접근해야 할 때가 있습니다. 이럴 때는 깃허브에서 제공하는 REST API를 사용하면 되는데요. 이번 포스팅에서는 터미널에서 curl로 깃허브의 REST API를 실제로 같이 호출해보면서 기본적인 API 사용 방법에 대해서 알아보겠습니다. 터미