조용한 개발 노트

1편에서 Claude를 “조심스러운 모델”이 아니라 처음부터 선을 긋고 설계된 LLM이라고 정리했다.이제 그 주장이 맞는지 확인해볼 차례다. 말이 아니라 API 구조를 보면 된다.API는 의도를 숨기지 않는다. 어떤 전제를 깔고 있는지는 코드 형태로 그대로 드러난다.1. Claude API는 왜 단순 completion API가 아닌가Claude API를 처음 보면 “completion 하나 던지고 문자열 받는 구조”가 아니다.대신 중심에는 항상 messages가 있다.이 선택 하나만으로도 Claude의 관점은 분명해진다.출력은 단일 결과가 아니다대화 맥락 전체가 판단 대상이다프롬프트는 명령이 아니라 상태다Claude는 처음부터 “한 번의 요청으로 정답을 뽑아내는 모델”을 상정하지 않는다.2. syste..

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

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가 메서드 파라미..