조용한 개발 노트

요청이 느려질 때 흔히 보는 설정 중 하나가 Keep-Alive입니다.HTTP/2를 쓰면 빨라진다는 이야기도 자주 듣습니다.하지만 왜 이 설정들이 필요한지, 그리고 무엇을 해결하려는 것인지는 명확하지 않은 경우가 많습니다.이 편에서는 연결을 계속 유지하는 선택이 왜 지연 문제를 완화하는지부터 정리합니다.1. 매 요청마다 연결을 만드는 구조의 문제Keep-Alive가 없으면, 요청 하나마다 다음 작업이 반복됩니다.DNS 조회TCP 연결 생성TLS handshake요청 전송연결 종료이 흐름은 단순하지만, 지연 관점에서는 가장 비싼 선택입니다.2편에서 다뤘듯이, TCP 연결 자체가 이미 RTT 비용을 포함합니다.여기에 TLS까지 얹히면, 요청 처리 이전에 이미 상당한 시간이 소비됩니다.2. Keep-Alive..

API 응답이 갑자기 느려졌습니다.CPU 사용률은 낮고, GC 로그도 깨끗합니다. 쿼리 플랜을 다시 봐도 이상한 점은 없습니다.이럴 때 백엔드 엔지니어가 가장 자주 듣는 말은 보통 이겁니다.“네트워크 문제인 것 같습니다.”하지만 막상 네트워크를 보려고 하면 애매해집니다. 패킷을 직접 보자는 얘기도 아니고, 단순히 핑 몇 번 찍어본다고 해결될 문제도 아닙니다.이 글은 이런 상황에서 자주 나오는 질문,“네트워크는 도대체 왜 느려지는 걸까?”에 답하기 위해 시작합니다.1. 느림은 대부분 애플리케이션 밖에서 발생한다백엔드 요청 하나의 응답 시간을 단순화하면 다음 두 덩어리로 나눌 수 있습니다.서버 내부 시간 - CPU 실행, GC, 락 대기, 쿼리, 직렬화/역직렬화네트워크 시간 - 연결, 전송, 대기, 재전송,..

2편에서 Trace와 Span을 통해 요청 하나의 흐름을 연결해서 볼 수 있다는 이야기를 했다. 그런데 실제 환경에서는 이런 경험을 자주 하게 된다.“분명 트레이싱을 붙였는데, 서비스 A까지만 보이고 서비스 B부터는 trace가 끊긴다.”이 문제의 핵심은 Trace도 Span도 아니다. Context Propagation이다.traceId는 왜 저절로 이어지지 않을까흔히 하는 오해가 있다. “같은 요청이면 traceId는 자동으로 따라다니는 것 아닌가?”하지만 분산 시스템에서 요청은 하나의 프로세스-하나의 스레드 안에서 끝나지 않는다.HTTP 요청으로 들어왔다가다른 서비스로 HTTP 또는 gRPC 호출을 하고비동기 작업이나 메시지 큐를 거치고다시 다른 스레드에서 처리된다이 경계들을 넘는 순간, 아무 작업..

REST는 종종URI를 명사로 쓰는 것GET, POST를 구분하는 것JSON을 반환하는 API정도로 이해된다.하지만 이러한 설명만으로는 REST가 무엇인지, 그리고 왜 REST가 등장했는지를 설명하기에 충분하지 않다.이 글에서는 REST를 하나의 API 스타일로 보지 않고, HTTP를 얼마나 충실하게 사용하는 아키텍처 제약 조건으로서 RFC 관점에서 다시 정리한다.1. REST는 무엇을 해결하려 했는가?REST(Representational State Transfer)는 HTTP를 새로 정의하려는 시도가 아니었다.REST의 출발점은 명확하다. 웹이 이미 잘 동작하고 있는데, 왜 API는 웹처럼 확장되지 않는가? REST는확장 가능하고중간 계층에 친화적이며느슨하게 결합된 시스템을 만들기 위한 아키텍처 제약..

HTTP API를 개발하다 보면, 서버는 정상적으로 응답을 보내는데 브라우저에서만 요청이 실패하는 상황을 자주 마주한다.콘솔에는 보통 다음과 같은 메시지가 나타난다. Blocked by CORS policy 이 문제는 HTTP 서버의 오류도, 네트워크 장애도 아니다.이 글에서는 CORS가 무엇인지, 왜 HTTP 문제가 아닌지, 그리고 왜 브라우저에서만 발생하는지를 웹 표준 관점에서 정리한다.1. Same-Origin Policy란 무엇인가?CORS를 이해하려면 먼저 Same-Origin Policy를 이해해야 한다.Same-Origin Policy는 브라우저가 기본적으로 적용하는 보안 정책이다.여기서 Origin은 다음 세 요소의 조합으로 정의된다.프로토콜 (http / https)호스트 (도메인)포트이..

HTTP 요청과 응답을 보면, Method와 Status Code만큼이나 눈에 띄는 요소가 있다.바로 HTTP Header다.Header는 종종 “부가 정보” 정도로 취급되지만, RFC 관점에서 Header는 요청과 응답의 조건과 맥락을 정의하는 핵심 요소다.이 글에서는 HTTP Header가 어떤 역할을 하는지, 그리고 왜 Header를 제대로 이해하지 않으면 HTTP를 올바르게 사용하고 있다고 보기 어려운지를 RFC 기준으로 정리한다.1. HTTP Header의 역할HTTP 메시지는 크게 세 부분으로 구성된다.Start Line (Request Line / Status Line)HeaderBody이 중 Header는요청이 어떤 조건에서 유효한지응답이 어떤 의미를 가지는지메시지를 어떻게 해석해야 하는지..

HTTP 응답에서 가장 눈에 띄는 정보는 Status Code다.많은 경우 상태 코드는 “대충 성공이면 200, 실패면 400이나 500” 정도로 사용된다.하지만 RFC에서 정의하는 HTTP Status Code는 단순한 숫자가 아니라, 요청과 응답 사이의 명확한 계약이다.이 글에서는 HTTP Status Code가 무엇을 약속하는지, 그리고 왜 정확하게 사용해야 하는지를 RFC 기준으로 정리한다.1. HTTP Status Code의 역할HTTP Status Code는 요청 처리 결과를 서버의 공식 입장으로 표현하는 수단이다.응답 본문보다 먼저 해석되는 정보이기도 하다.클라이언트, 프록시, 캐시는 응답 본문을 보지 않고도 Status Code만으로 다음 동작을 결정할 수 있다.즉, Status Code는..

HTTP Method는 서버에게 “무엇을 할 것인가”를 전달하는 수단이다.하지만 실무에서는 종종 Method를 단순히 “요청을 보내는 방식” 정도로만 이해한다.이 글에서는 HTTP Method가 단순한 문법이 아니라, 의미와 계약을 담고 있는 규칙이라는 점을 RFC 기준으로 정리한다.1. HTTP Method는 무엇을 표현하는가?HTTP Method는 요청의 의도(Intent)를 표현한다.즉,이 요청은 무엇을 하려는 것인가?서버는 이 요청을 어떻게 해석해야 하는가?를 명확하게 전달하기 위한 장치다.HTTP는 Method에 따라 요청의 의미를 다르게 해석하도록 설계되었다.2. GET과 POST의 근본적인 차이GET과 POST의 차이를 “쿼리스트링 vs Body”로 설명하는 경우가 많다.하지만 이는 표면적인..

HTTP는 웹 프레임워크의 기능이 아니다. HTTP는 그보다 훨씬 앞단에 존재하는, 웹이 동작하기 위한 기본 규칙이다.Spring, gRPC, REST API, 브라우저 통신은 모두 이 규칙 위에서 동작한다.이 글에서는 HTTP가 무엇을 책임지는 프로토콜인지, 그리고 HTTP가 무엇을 의도적으로 책임지지 않는지를 공식 RFC 문서를 기준으로 정리한다.1. HTTP는 무엇을 하는 프로토콜인가?HTTP(Hypertext Transfer Protocol)는 리소스를 주고받기 위한 애플리케이션 계층 프로토콜다.RFC 9110은 HTTP를 다음과 같이 정의한다. HTTP는 클라이언트와 서버 간에 요청(Request)과 응답(Response)을 교환하기 위한 표준화된 메시지 규칙이다. 즉, HTTP는요청을 어떻게 ..

Spring Web은 단순히 Controller를 만드는 기술이 아니라, HTTP 요청이 애플리케이션 내부를 통과하는 전체 흐름을 정의한 프레임워크다.이 글에서는 지금까지 살펴본 구성 요소들을 하나의 흐름으로 묶고, 실무에서 어떤 선택을 해야 하는지 기준을 정리한다.1. Spring Web 요청 처리 전체 흐름Spring Web MVC 기준으로, HTTP 요청은 다음 순서로 처리된다.브라우저 또는 클라이언트가 HTTP 요청을 전송한다Filter가 요청을 가장 먼저 가로챈다DispatcherServlet이 모든 요청의 진입점이 된다HandlerMapping이 요청을 처리할 Controller를 찾는다HandlerAdapter가 Controller 실행을 준비한다ArgumentResolver가 메서드 파라미..