조용한 개발 노트

43편에서는 EnvironmentPostProcessor와 ApplicationContextInitializer를 통해 설정 흐름의 가장 깊은 확장 포인트를 살펴봤다.이번 글에서는 그 확장의 결과물에 해당하는 주제, Spring Boot Starter를 직접 만드는 기준을 다룬다.Starter는 잘 만들면 팀의 생산성을 폭발적으로 높이지만, 잘못 만들면 업그레이드와 운영을 망치는 공통 의존성이 된다.1) Starter는 “편의 라이브러리”가 아니다Spring Boot Starter를 단순히 “의존성 묶음”으로 생각하면 설계가 바로 흔들린다.Starter의 본질은 이것이다. “특정 기능을 사용하는 방법에 대한 팀 또는 조직의 공식적인 의견” 즉, Starter는 코드가 아니라 표준을 배포하는 수단이다.2)..

16편에서는 Configuration Properties를 설정의 “도메인 모델”로 다루는 기준을 정리했다.이번 글에서는 그 다음 단계, Spring Boot의 자동 설정을 어디까지, 어떻게 건드려야 하는지를 다룬다.Auto-Configuration은 Spring Boot의 가장 큰 장점이지만, 동시에 가장 많이 오해되는 영역이기도 하다.1) 자동 설정은 “편의 기능”이 아니라 “확장 포인트”다많은 개발자가 Auto-Configuration을 “Boot가 대신 해주는 마법”으로 인식한다.하지만 실제로 Auto-Configuration은 확장 가능하도록 설계된 기본 구현에 가깝다.Spring Boot가 제공하는 자동 설정에는 거의 항상 다음과 같은 조건이 붙어 있다.@ConditionalOnClass@Co..

1편에서는 Spring Boot가 무엇을 해결하기 위해 등장했는지를 살펴봤다. 정리하면 핵심은 하나였다.“Spring으로 서비스를 만들 때 반복되는 초기 세팅·표준화·운영 준비 비용을 줄이자.”이번 글에서는 Spring Boot가 이 문제를 해결하기 위해 제공하는 세 가지 핵심 도구를 살펴본다.StarterAuto-ConfigurationActuator이 세 가지를 이해하면, Spring Boot를 “왜 이렇게 동작하는지 아는 상태”로 사용할 수 있게 된다.1) Starter: 의존성 선택 비용을 없애다Spring 프로젝트를 처음 만들 때 가장 귀찮은 작업 중 하나는 의존성 조합을 고르는 일이다.웹 프로젝트에 필요한 라이브러리는 무엇인가?로그는 어떤 구현체를 쓰는가?테스트 라이브러리는 어디까지 포함해야 ..

Spring을 처음 쓸 때 가장 많이 듣는 말이 있습니다.“Spring은 좋은데… 설정이 너무 많아.”“프로젝트 시작하려면 먼저 골격 잡다가 하루가 간다.”“로컬/개발/운영 환경 설정 분리하다가 결국 사람이 실수한다.”Spring Boot는 딱 이 지점, 즉 “잘 만들 수는 있는데 시작/표준/운영 준비가 너무 비싸다”는 비용을 줄이기 위해 등장했다. 공식 문서에서도 Spring Boot는 stand-alone 형태로 실행 가능하고, production-grade 애플리케이션을 최소한의 번거로움으로 만들기 위한 도구라고 설명한다.1) “Spring 자체가 어렵다”가 아니라, “프로젝트의 기본값이 없다”가 문제였다Spring Framework는 강력하지만 선택지가 많다.웹 서버: Tomcat? Jetty?설..