조용한 개발 노트

1편부터 9편까지, 우리는 Spring Boot의 기능을 “나열”하지 않았다.대신 다음 질문을 계속 던졌다.왜 이렇게 설계됐을까?언제 자동으로 동작하고, 언제 개입해야 할까?어디까지가 Spring Boot의 책임일까?이 마지막 글에서는 그 질문들을 한 번에 묶어, Spring Boot를 어떻게 바라보고 써야 하는지를 정리하며 1차 시리즈를 마무리한다.1) Spring Boot는 “프레임워크”가 아니다흔히 Spring Boot를 “Spring의 상위 프레임워크”처럼 표현한다.하지만 정확히 말하면, Spring Boot는 새로운 프레임워크가 아니다.Spring Boot는 Spring 위에서 동작하는 실행 환경이자, 설계된 기본값의 집합이다.그래서 Spring Boot의 역할은 “모든 걸 대신 해주는 것”이 ..

8편에서는 Spring Boot의 Externalized Configuration이 왜 복잡해 보이지만 필요한 설계인지 살펴봤다.설정 이야기를 조금 더 깊게 들어가면, 결국 반드시 마주치는 주제가 하나 있다.Profile은 어떻게 나눠야 할까?많은 프로젝트가 dev / prod 두 개의 Profile로 시작한다. 하지만 규모가 조금만 커져도 이 구조는 빠르게 한계에 부딪힌다.이번 글에서는 왜 dev/prod만으로는 부족한지, 그리고 실무에서 유지 가능한 Profile 설계 기준을 YAML 예시와 함께 정리해본다.1) Profile은 “환경 이름”이 아니다Profile을 이야기할 때 가장 흔한 오해는 이것이다.“Profile = 실행 환경”물론 환경을 표현하는 데 쓰이지만, Profile의 본질은 거기에 ..

7편에서는 Auto-Configuration과 사용자 설정 사이에서 어디까지 개입해야 하는지를 기준으로 정리했다.설정 이야기를 하다 보면, 결국 반드시 마주치는 주제가 하나 있다.“Spring Boot의 설정은 왜 이렇게 복잡해 보일까?”properties, yaml, profile, 환경 변수, 커맨드라인 인자까지. 처음 보면 설정 위치도 많고, 우선순위도 헷갈린다.이번 글에서는 이 복잡함의 정체인 Externalized Configuration을 “왜 이렇게 설계됐는지” 관점에서 풀어본다.1) Externalized Configuration의 목표는 단 하나다Spring Boot가 Externalized Configuration을 도입한 이유는 명확하다.“같은 코드로, 서로 다른 환경에서 실행할 수 ..

6편에서는 Auto-Configuration을 디버깅하는 방법을 중심으로 살펴봤다.이제 구조도 알고, 왜 적용됐는지도 추적할 수 있다면 다음 질문이 반드시 나온다.이 자동 설정, 그냥 써도 될까?내가 직접 설정을 추가해도 괜찮을까?어디까지가 “개입”이고, 어디부터가 “과한 설정”일까?이번 글에서는 Auto-Configuration과 사용자 설정의 경계를 Spring Boot의 철학과 실무 기준으로 정리한다.1) Spring Boot는 “자동 설정을 쓰지 말라”고 하지 않는다Spring Boot를 오래 쓰다 보면, 자동 설정을 경계하는 분위기를 한 번쯤 접하게 된다.하지만 Spring Boot의 철학은 정반대다.“자동 설정을 기본으로 쓰고, 필요할 때만 개입하라.”Auto-Configuration은 단순 ..

5편에서는 Spring Boot의 Auto-Configuration이 미리 정의된 설정 후보 목록을 조건에 따라 선별해 ApplicationContext에 Import하는 구조라는 것을 살펴봤다.구조를 이해했다면, 다음 단계는 자연스럽다.왜 이 Bean이 생겼는지 알고 싶다왜 어떤 자동 설정은 적용되지 않았는지 확인하고 싶다문제가 생겼을 때, 어디서부터 추적해야 할지 알고 싶다이번 글에서는 Spring Boot가 제공하는 Auto-Configuration 디버깅 도구를 중심으로, 자동 설정을 실제로 추적하는 방법을 정리한다.1) “왜 이 Bean이 생겼지?”라는 질문의 정체실무에서 가장 자주 듣는 질문 중 하나는 이것이다.“이 Bean은 내가 만든 적이 없는데, 왜 생겼지?”대부분의 경우 답은 하나다.A..

4편에서는 SpringApplication.run()을 기준으로 Spring Boot 애플리케이션이 Environment → ApplicationContext → Bean 생성 순서로 초기화된다는 것을 살펴봤다.이제 자연스럽게 다음 질문이 나온다.Auto-Configuration은 도대체 어디에 정의돼 있을까?수많은 자동 설정 클래스는 언제, 어떤 기준으로 로딩될까?왜 어떤 설정은 적용되고, 어떤 설정은 빠질까?이번 글에서는 Spring Boot의 핵심 기능인 Auto-Configuration이 실제로 로딩되는 흐름을 내부 동작 기준으로 정리한다.1) Auto-Configuration은 “마법”이 아니라 “목록”에서 시작된다Auto-Configuration은 런타임에 즉석에서 만들어지는 기능이 아니다. ..

3편에서는 @SpringBootApplication이 Spring Boot 애플리케이션의 진입점이라는 것을 살펴봤다.이제 남은 질문은 이것이다.main()에서 실행 버튼을 누르면 실제로 무슨 일이 일어날까?ApplicationContext는 언제 만들어질까?우리가 작성한 코드는 언제부터 안전하게 실행할 수 있을까?이 모든 흐름은 SpringApplication.run() 내부에서 시작된다.1) main()은 단순한 시작 버튼이다Spring Boot 애플리케이션의 main() 메서드는 생각보다 하는 일이 많지 않다.public static void main(String[] args) { SpringApplication.run(Application.class, args);} 이 코드는 “애플리케이션을..

2편에서는 Spring Boot의 핵심 도구인 Starter / Auto-Configuration / Actuator를 살펴봤다.이제 자연스럽게 이런 질문이 생긴다.왜 Spring Boot 프로젝트는 항상 이 어노테이션 하나로 시작할까?설정 파일도 거의 없는데, 어떻게 애플리케이션이 구성될까?Spring Boot의 “큰 그림”은 어디서 시작되는 걸까?이 모든 흐름의 출발점이 바로 @SpringBootApplication이다.1) @SpringBootApplication은 단일 기능이 아니다이름 때문에 오해하기 쉽지만, @SpringBootApplication은 하나의 기능을 수행하는 어노테이션이 아니다.실제로는 다음 세 가지 핵심 어노테이션을 묶어 놓은 조합이다.@SpringBootConfiguratio..

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?설..