조용한 개발 노트

브라우저에서 API를 호출하다 보면, 서버 로직과는 무관하게 요청이 차단되는 상황을 자주 마주한다.콘솔에는 다음과 같은 메시지가 출력된다.“Blocked by CORS policy”이 문제는 Spring 코드의 버그가 아니라, 브라우저 보안 정책과 HTTP 응답 설계의 문제다.이 글에서는 Same-Origin Policy가 무엇인지, CORS는 왜 필요한지, 그리고 Spring Web에서 이 문제를 어디서 해결해야 하는지 정리한다.1. Same-Origin Policy란 무엇인가?Same-Origin Policy는 브라우저가 기본적으로 적용하는 보안 정책이다.여기서 Origin은 다음 세 가지 요소의 조합이다.프로토콜 (http / https)호스트 (도메인)포트이 세 가지 중 하나라도 다르면, 브라우저..

웹 애플리케이션에서는 모든 요청에 공통으로 적용해야 하는 로직이 존재한다.인증 및 인가요청/응답 로깅트랜잭션 경계 설정요청 컨텍스트 초기화Spring Web MVC는 이러한 횡단 관심사를 처리하기 위해 Filter와 Interceptor라는 두 가지 확장 지점을 제공한다.이 글에서는 두 컴포넌트의 역할과 차이를 정리하고, 어떤 경우에 무엇을 선택해야 하는지 기준을 잡아본다.1. Filter의 위치와 역할Filter는 서블릿 컨테이너 레벨에서 동작하는 컴포넌트다.HTTP 요청이 DispatcherServlet에 도달하기 전에, 또는 응답이 클라이언트로 나가기 전에 Filter 체인을 거친다.DispatcherServlet 이전 단계에서 실행ServletRequest / ServletResponse 기반Sp..

20편에서는 Filter vs Interceptor를 통해 요청 흐름에서 두 컴포넌트가 어디에 위치하고 무엇을 책임지는지 정리했습니다.이번 글에서는 그 위에서 동작하는 Spring Security가요청을 어디서 가로채고, 어떤 순서로 인증·인가를 수행하는지를 요청 흐름 기준으로 정리해보겠습니다.1. 가장 중요한 결론부터Spring Security의 핵심은 이 한 줄로 요약할 수 있습니다.Spring Security는 Filter 기반 보안 프레임워크다즉,DispatcherServlet 이전Spring MVC보다 앞단에서 요청을 보호합니다.그래서:컨트롤러까지 가지 못하는 요청이 생기고Interceptor가 실행되지 않는 경우도 발생할 수 있습니다.2. Security는 어디에 끼어들까요청 흐름을 단순화하면..

19편에서는 Spring MVC의 요청 처리 흐름을 DispatcherServlet부터 ExceptionResolver까지 한 장으로 정리했습니다.이번 글에서는 그 흐름 위에서 많이 헷갈리는 두 존재,FilterInterceptor가 정확히 어디에서, 어떤 역할을 맡는지를 구조 기준으로 정리해보겠습니다.1. 가장 먼저 정리해야 할 결론Filter와 Interceptor의 차이는 기능 차이가 아니라 위치와 책임 차이입니다.Filter – 서블릿 레벨, Spring 바깥Interceptor – Spring MVC 내부이 한 줄을 기준으로 보면 대부분의 혼란이 사라집니다.2. Filter는 어디에 위치할까Filter는DispatcherServlet 앞단에 위치합니다.즉,Spring MVC를 타기 전서블릿 컨테..

[Kotlin 공식 문서 정리] 07. 컬렉션 API 제대로 쓰기Kotlin을 쓰기 시작하면 컬렉션 API를 사용하는 빈도가 급격히 늘어납니다. 단순히 데이터를 담는 용도를 넘어서, 데이터를 변환하고 흐름을 표현하는 도구로 사용되기 때문입니다.이 글에서는 Kotlin 공식 문서를 기준으로 컬렉션 API의 기본 구조와, 실무에서 가장 자주 사용되는 패턴을 중심으로 정리합니다.1. Kotlin 컬렉션의 기본 구조Kotlin 컬렉션은 크게 읽기 전용 컬렉션과 변경 가능한 컬렉션으로 나뉩니다.val readOnly = listOf(1, 2, 3)val mutable = mutableListOf(1, 2, 3)기본 인터페이스는 다음과 같습니다.List / MutableListSet / MutableSetMap /..