조용한 개발 노트

이 글은 Spring Framework / Spring Boot 공식 문서(Testing)를 기반으로, Spring 테스트에서 가장 중요한 설계 질문인 “이 테스트에서 무엇을 어디까지 로딩해야 하는가”에 답합니다.테스트가 느려지고 복잡해지는 이유의 대부분은, 이 질문에 대한 기준이 없기 때문입니다.들어가며Spring 테스트를 작성하다 보면 다음 두 선택지 앞에 서게 됩니다.간단하니까 @SpringBootTest로 한 번에 끝내자Context 없이 빠르게 테스트하고 싶다이 선택은 단순 취향 문제가 아니라, 테스트 설계 문제입니다.1. Unit Test - Spring 없이 테스트하기Unit Test의 핵심은 명확합니다.하나의 클래스, 하나의 책임만 검증한다이 테스트는Spring Context를 띄우지 않고..

이 글은 Spring Framework 공식 문서(Testing)를 기반으로, Spring 테스트의 핵심 인프라인 TestContext Framework가 ApplicationContext를 어떻게 생성하고, 어떻게 재사용하며, 왜 테스트 성능에 결정적인 영향을 미치는지를 정리합니다.1편에서 테스트의 철학과 전략을 다뤘다면, 이번 편은 Spring 테스트가 실제로 어떻게 동작하는지를 이해하는 출발점입니다.들어가며Spring 테스트를 작성하다 보면 이런 현상을 경험하게 됩니다.테스트 하나 추가했을 뿐인데 전체 테스트가 느려졌다같은 설정인데 어떤 테스트는 빠르고, 어떤 테스트는 느리다@SpringBootTest가 왜 이렇게 무거운지 모르겠다이 문제의 대부분은 ApplicationContext의 생성과 재사용..

이 글은 Spring Framework 공식 문서(Testing)를 기반으로, Spring 애플리케이션에서 테스트가 왜 필요한지, 그리고 어떻게 설계되어야 하는지를 철학과 전략 관점에서 정리합니다.이 시리즈의 목적은 테스트 코드를 많이 작성하는 방법이 아니라, 어떤 테스트를, 왜 작성해야 하는지 판단할 수 있는 기준을 세우는 데 있습니다.들어가며테스트에 대한 이야기는 언제나 양극단으로 흐르기 쉽습니다.테스트는 무조건 많을수록 좋다테스트는 느리고 귀찮다실무에서는 테스트할 시간이 없다Spring 공식 문서는 이 논쟁의 중심에서 아주 차분한 전제를 깔고 시작합니다.Testing is a first-class concern in the Spring Framework.즉, 테스트는 부가 기능이 아니라 프레임워크가..

이 글은 Spring Security 공식 문서를 기반으로 진행한 1~9편 내용을 하나의 판단 프레임으로 정리한 마무리 편입니다.Spring Security는 “어떻게 설정하는가”보다 어디까지 맡기고, 어디서 멈출 것인가가 훨씬 중요합니다. 이 글의 목적은 그 경계를 명확히 하는 것입니다.들어가며지금까지 이 시리즈에서는 반복해서 같은 질문을 던졌습니다.이 요청은 어디에서 통제되어야 하는가?보안은 기능인가, 경계인가?프레임워크가 책임져야 할 범위는 어디까지인가?10편에서는 이 질문들을 한 번에 판단할 수 있는 기준으로 정리합니다.1. Spring Security가 잘 맞는 문제 영역Spring Security는 다음 전제를 만족할 때 가장 강력합니다.HTTP 요청 경계를 명확히 보호하고 싶다인증과 인가를 ..

이 글은 Spring Security 공식 문서를 기반으로, 실무에서 반복적으로 등장하고, 결국 장애나 보안 취약점으로 이어졌던 Spring Security 안티 패턴들을 정리합니다.이 안티 패턴들의 공통점은 하나입니다. 처음에는 합리적으로 보였다는 것입니다.안티 패턴 1. permitAll로 시작해서 permitAll로 끝나는 구조Spring Security를 처음 붙일 때 가장 흔한 출발점입니다.http .authorizeHttpRequests(auth -> auth .anyRequest().permitAll() );이 설정은 “일단 서비스가 동작하게 만드는” 데는 효과적입니다. 하지만 이 상태가 오래 유지되면 문제가 됩니다.보안 규칙이 존재하지 않는다보안은 Method Security에..

이 글은 Spring Security 공식 문서를 기반으로, 인증이 끝난 후 생성된 Authentication이 어디에 저장되고, 어떻게 전파되는지를 SecurityContext 중심으로 설명합니다.SecurityContext를 이해하지 못하면, 비동기 처리, 멀티스레드 환경, 배치 작업에서 보안 이슈를 피할 수 없습니다.들어가며Spring Security를 사용하다 보면 한 번쯤은 이런 코드를 보게 됩니다.Authentication authentication = SecurityContextHolder.getContext().getAuthentication();이 코드는 단순해 보이지만, 그 뒤에는 중요한 질문이 숨어 있습니다.이 Authentication은 어디에서 온 것일까?이 질문에 답하는 것..

이 글은 Spring Security 공식 문서를 기반으로, Method Security가 무엇인지보다 언제 사용해야 하고, 언제 사용하면 안 되는지를 설계 관점에서 정리합니다.Method Security는 강력하지만, 무분별하게 사용하면 보안 규칙과 비즈니스 로직의 경계를 무너뜨립니다.들어가며Spring Security를 어느 정도 사용하다 보면 자연스럽게 이런 코드가 등장합니다.@PreAuthorize("hasRole('ADMIN')")public void deleteUser(Long userId) { ... }처음엔 매우 좋아 보입니다.보안 로직이 선언적으로 보인다if문이 사라진다컨트롤러가 깔끔해진다하지만 이 애노테이션은 언제든 남용될 수 있는 도구이기도 합니다.1. Method Security는 ..

이 글은 Spring Security 공식 문서를 기반으로, 인증(Authentication) 이후 단계인 인가(Authorization)가 어디에서, 어떤 기준으로 판단되어야 하는지를 정리합니다.인가를 잘못 설계하면, 보안은 코드 전반으로 퍼지고 비즈니스 로직과 섞여 유지보수가 불가능해집니다.들어가며실무에서 가장 흔히 보는 인가 코드는 다음과 같습니다.if (!user.hasRole("ADMIN")) { throw new AccessDeniedException();}이 코드는 얼핏 문제 없어 보이지만, Spring Security 관점에서는 가장 피해야 할 인가 방식입니다.이 편에서는권한은 무엇인가어디에서 판단되어야 하는가어디까지 프레임워크에 맡겨야 하는가를 하나씩 짚어봅니다.1. Authoriz..

이 글은 Spring Security 공식 문서를 기반으로, 인증(Authentication) 과정에서 등장하는 UserDetailsService와 도메인 사용자 엔티티 사이의 경계를 정리합니다.이 경계를 명확히 이해하지 못하면, 보안 로직이 비즈니스 코드로 새어나가고, Spring Security는 점점 통제 불가능한 프레임워크가 됩니다.들어가며Spring Security를 실무에 적용하다 보면 아주 자연스럽게 이런 고민에 도달합니다.이미 User 엔티티가 있는데 굳이 UserDetails가 필요할까?엔티티에 UserDetails를 구현하면 편하지 않을까?어차피 인증할 때 DB에서 사용자 조회하는 거 아닌가?이 질문들은 모두 합리적으로 보이지만, Spring Security 공식 문서의 관점에서는 위험..

이 글은 Spring Security 공식 문서를 기반으로, 많은 개발자들이 처음에 갖게 되는 질문인 “Spring Security는 왜 이렇게 복잡한가?”에 답하는 것으로 시작합니다.이 시리즈의 목적은 설정 방법을 나열하는 것이 아니라, Spring Security가 어떤 문제를 풀기 위해 지금의 구조를 가지게 되었는지를 설계 관점에서 이해하는 데 있습니다.들어가며Spring Security를 처음 접하면 대부분 이런 인상을 받습니다.설정이 많다개념이 어렵다어디서 막히는지 알기 힘들다그래서 흔히 이런 선택을 합니다.일단 복사해서 쓴다보안은 프레임워크가 알아서 해주겠지라고 생각한다필요한 부분만 permitAll로 열어둔다하지만 Spring Security는 “편하게 쓰라고 만들어진 프레임워크”가 아닙니다..