본문 바로가기

전체 글443

Spring Boot 1.1~1.3 - @SpringBootApplication은 언제 생겼을까 1편에서 부트 1.0의 자동 설정을 따라가면서 한 가지를 짚었다. 그때는 메인 클래스에 어노테이션을 셋 따로 붙였다는 것이다.// 1.0@Configuration@EnableAutoConfiguration@ComponentScanpublic class SampleSimpleApplication {지금 쓰는 @SpringBootApplication은 없었다. 그게 언제 어떤 모양으로 생겼는지, 그리고 그 사이 부트가 어떻게 덩치를 불렸는지가 이번 편이다.다루는 구간은 1.1(2014년 6월 10일), 1.2(2014년 12월 10일), 1.3(2015년 11월 16일) 셋이다. 릴리즈 흐름 1.1 — 자동 설정이 두 배가 됐다1.1은 새 개념을 들이기보다 대상을 넓힌 버전이다. 저장소에서 spring.f.. 2026. 9. 23.

Spring Boot 1.0 - 의존성만 추가하면 설정이 되는 이유 스프링 부트로 프로젝트를 만들면 pom.xml에 이 한 줄만 넣어도 웹 애플리케이션이 뜬다. org.springframework.boot spring-boot-starter-web톰캣을 설치한 적도, web.xml을 쓴 적도, DispatcherServlet을 등록한 적도 없다. 그런데 정상적으로 동작한다. 이게 어떻게 가능한지가 이번 편의 주제다.스프링 부트 1.0은 2014년 4월 1일에 나왔다. 앞서 스프링 프레임워크 시리즈 7편에서 4.0의 @Conditional을 다루면서 "스프링 부트가 가능해진 자리"라고 했는데, 그 자리에 실제로 무엇이 지어졌는지를 따라가 본다. 먼저, 1.0에는 @SpringBootApplication이 없다지금은 메인 클래스에 어노테이션 하나만 붙인다. 그런데.. 2026. 9. 22.

Spring 0.9~7.0 - 22년치 릴리즈 한눈에 정리 스프링 릴리즈 노트를 0.9부터 7.0까지 열세 편에 걸쳐 정리를 했다. 이번 글은 그 열세 편을 정리한 자료다.버전마다 무엇이 들어왔는지, 그게 지금 쓰는 스프링 부트의 어느 부분이 됐는지를 세대별로 묶어 정리했다. 각 편에서 다룬 근거는 전부 릴리즈 노트와 실제 소스였고, 여기서는 결론만 추린다. 릴리즈 흐름 한눈에 1세대 · 0.9 ~ 1.2 (2003~2005)시작은 패키지 이름부터였다. 0.9의 패키지는 org.springframework가 아니라 com.interface21이었다. 로드 존슨의 책 제목에서 온 이름이다.// 0.9com.interface21.beans.factory.BeanFactory// 1.0org.springframework.beans.factory.BeanFactory.. 2026. 9. 22.

Spring 7.0 - 스프링의 @Nullable이 JSpecify로 넘어간 이유 스프링 7.0으로 올리면 import 문 하나가 바뀐다.// 6.2까지import org.springframework.lang.Nullable;// 7.0import org.jspecify.annotations.Nullable; 9편에서 5.0이 @Nullable을 만든 이야기를 했다. 코틀린이 널 가능성을 타입으로 구분하는데 자바로 쓰인 API에는 그 정보가 없어서, 스프링이 직접 어노테이션을 달아 알려준 것이었다. 7.0은 그 어노테이션에 @Deprecated를 붙였다.7.0은 2025년 11월 13일에 나왔다. 6.2가 2024년 11월 14일이었으니 딱 1년 만이다.이번 편이 이 시리즈의 마지막이다. 0.9부터 따라온 흐름이 어디에 도착했는지 같이 보자. 릴리즈 흐름 (7.0) Spring 7.0.. 2026. 9. 21.

Spring 6.1~6.2 - 가상 스레드가 바꾼 것 스프링 6.1에 이런 클라이언트가 들어왔다.Person person = restClient.get() .uri("/persons/{id}", id) .retrieve() .body(Person.class);WebClient와 모양이 거의 같은데 Mono도 Flux도 없다. 호출하면 그 자리에서 값이 나온다.9편에서 스프링이 왜 WebFlux를 만들었는지 살펴봤다. 문서가 직접 말하기를, 더 빨라지려고 만든 게 아니라 적은 수의 스레드로 부하를 견디려고 만든 것이라고 했다. 그 문제가 자바 21에서 다른 방식으로도 풀린다. 가상 스레드다.6.1은 2023년 11월 16일, 6.2는 2024년 11월 14일에 나왔다. 정확히 1년 간격이다. 이번 편은 두 버전을 묶어서 .. 2026. 9. 19.

Spring 6.0 - AOT는 시작 전에 무엇을 미리 하는가 Spring 6.0은 5.3 다음 버전이다. 5.3이 2020년 10월이었으니 2년 만이고, GA는 2022년 11월 16일이다. 지난 편 마지막에 스프링이 네이티브 이미지를 준비하고 있다고 했다. 6.0에서 그게 도착한다.그런데 6.0을 실제로 올려본 사람에게 6.0은 아마 다른 기억일 것이다. import 문을 전부 고친 기억...// 5.ximport javax.servlet.http.HttpServletRequest;import javax.persistence.Entity;// 6.0import jakarta.servlet.http.HttpServletRequest;import jakarta.persistence.Entity;이번 편은 이 두 가지를 본다. 밖에서 강제된 변화 하나와, 스프링이 스.. 2026. 9. 17.

Spring 5.0 - 스프링은 왜 새 웹 프레임워크를 만들었을까 스프링 부트로 프로젝트를 만들 때 의존성 목록을 보면 웹 프레임워크가 두 개다.implementation 'org.springframework.boot:spring-boot-starter-web'implementation 'org.springframework.boot:spring-boot-starter-webflux'하나는 스프링 MVC고 하나는 WebFlux다. 둘 다 컨트롤러를 만들고 @GetMapping을 붙인다. 그런데 왜 두 개일까. 쓰던 것을 고치면 되지 않았을까. Spring 5.0 레퍼런스 문서에도 동일한 질문이 섹션 제목으로 올라와 있다.Why a new web framework?이번 편은 그 답을 따라가 본다. 8편에서 살펴본 4.3은 2016년 6월에, 5.0은 2017년 9월 28일.. 2026. 9. 15.

Spring 5.1~5.3 - WebFlux에서 만든 것이 스프링 MVC로 넘어온 과정 스프링 MVC로 만든 프로젝트에서도 이런 코드를 쓸 수 있다.@Beanpublic RouterFunction routes(PersonHandler handler) { return route() .GET("/person/{id}", accept(APPLICATION_JSON), handler::getPerson) .POST("/person", handler::createPerson) .build();}지난 편에서 5.0의 함수형 라우팅을 살펴봤다. 그건 WebFlux 얘기였다. 그런데 위 코드는 WebFlux가 아니라 스프링 MVC에서 돈다. 서블릿 위에서.이번 편은 5.1, 5.2, 5.3 세 버전을 묶어서 본다. 5.0처럼 새 모듈이 생기.. 2026. 9. 14.

Spring 4.1~4.3 - @Autowired를 지워도 되는 이유 지금 스프링으로 컨트롤러와 서비스를 짜면 대략 이런 모양이 된다.@RestController@RequiredArgsConstructorpublic class UserController { private final UserService userService; @GetMapping("/users/{id}") public UserResponse find(@PathVariable Long id) { return userService.find(id); }}@GetMapping을 쓰고, 생성자에 @Autowired를 붙이지 않는다. 둘 다 너무 당연해서 언제부터 그랬는지 생각해본 적이 없을 것이다.이 두 가지가 언제 들어왔는지 찾아보면 공교롭게도 같은 버전이다. 2016년 6월에 .. 2026. 9. 12.

Spring 4.0 - 스프링 부트는 여기서 가능해졌다 지난 편까지 오면서 스프링이 XML을 걷어내고 자바 설정으로 옮겨가는 과정을 살펴봤다. 3.0에서 @Configuration이 나왔고, 3.1에서 @Enable로 XML 네임스페이스를 대체했다.그런데 여기까지만으로는 스프링 부트가 나올 수 없다. 부트의 핵심은 "클래스패스에 이 라이브러리가 있으면 이 설정을 자동으로 켠다"인데, 그 판단을 할 수단이 없었기 때문이다.그 수단이 4.0에서 들어온다. 이번 편은 그 이야기부터 시작해보자. 참고로 이번 편부터 자료 조사 방식이 조금 달라졌다. 4.0부터는 공식 changelog.txt 파일이 더 이상 배포되지 않는다. 4편에서 "3.0부터 git 히스토리가 남아있다"고 했는데, 4.0에 와서는 그 히스토리가 유일한 상세 기록이 됐다. 릴리즈 흐름 (4.0 M1.. 2026. 9. 12.

이전 1 2 3 4 ··· 45 다음

티스토리툴바