조용한 개발 노트

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

37편에서는 Spring Boot에서 성능 문제를 접근하는 올바른 순서를 정리했다.이번 글에서는 그 흐름을 한 단계 더 좁혀, Auto-Configuration이 성능에 어떤 영향을 주는지를 살펴본다.“Spring Boot는 느리다”라는 말의 상당수는 실제로는 자동 설정이 만드는 간접 비용을 이해하지 못해서 나온다.1) Auto-Configuration은 공짜가 아니다Auto-Configuration은 개발 속도를 극적으로 높여준다.하지만 그 대가로, 다음과 같은 비용이 항상 발생한다.Classpath 스캔 비용조건(@Conditional) 평가 비용불필요한 Bean 정의 등록대부분의 애플리케이션에서는 이 비용이 문제가 되지 않는다.문제가 되는 시점은 애플리케이션 규모와 역할이 커질 때다.2) Start..

30편의 마지막에서 우리는 질문을 하나 남겼다. “왜 어떤 시점부터 Spring Boot의 기본값이 불편해질까?” Part 4는 이 질문에서 출발한다. 더 많은 기능을 소개하기보다, Spring Boot가 전제로 삼고 있는 가정이 언제, 어떤 조건에서 깨지는지를 하나씩 짚어보려 한다.이 글은 Spring Boot를 비판하기 위한 글이 아니다. 오히려 왜 처음에는 그렇게 잘 맞았는지를 다시 이해하기 위한 글이다.1) Spring Boot의 기본값은 “평균적인 상황”을 가정한다Spring Boot의 가장 큰 장점은 “아무 설정 없이도 잘 동작한다”는 점이다.이는 곧, Spring Boot가 다음과 같은 상황을 전제로 기본값을 설계했다는 의미다.단일 애플리케이션단일 데이터베이스명확한 요청/응답 흐름상대적으로 ..

28편에서는 컨테이너 환경에서 Spring Boot의 실행 전제와 책임 경계를 살펴봤다.이번 글에서는 그 실행 결과물에 반드시 따라붙는 주제, 보안(Security)을 다룬다.Spring Boot 프로젝트를 처음 만들면 많은 사람들이 이렇게 말한다. “아무것도 안 했는데 왜 다 막혀 있지?” 이 글의 목표는 이 질문에 구조적으로 답하는 것이다.1) Spring Boot Security의 기본 전제Spring Boot Security Auto-Configuration의 출발점은 매우 단순하다. “보안이 없는 상태보다, 기본적으로 막혀 있는 상태가 더 안전하다.” 그래서 Spring Security가 classpath에 존재하면, Spring Boot는 기본 보안 설정을 자동으로 활성화한다.이 기본값은 “사..

11편부터 19편까지, 우리는 Spring Boot를 “어떻게 쓰는가”가 아니라 “어디까지가 Boot의 책임인가”라는 관점으로 살펴봤다.이 마지막 글에서는 Part 2 전체를 관통하는 질문 하나로 정리한다. Spring Boot는 어디까지 맡기고, 언제부터는 내가 책임져야 할까? 이 질문에 답할 수 있다면, Spring Boot는 더 이상 블랙박스가 아니다.1) Spring Boot 확장의 출발점은 “불편함”이다대부분의 확장은 처음부터 의도적으로 시작되지 않는다.보통은 이런 순간에서 출발한다.기본 설정으로는 설명이 부족할 때여러 서비스에서 같은 설정을 반복할 때자동 설정의 동작을 정확히 통제하고 싶을 때중요한 점은, 이 불편함이 확장의 신호일 수는 있지만 무조건 확장해야 한다는 뜻은 아니라는 것이다.2)..

18편에서는 Embedded Server를 통해 애플리케이션의 실행 모델과 책임 경계를 정리했다.이번 글에서는 그 다음으로 가장 많은 문제가 발생하는 영역, DataSource와 트랜잭션 Auto-Configuration을 다룬다.“왜 DataSource가 두 개 생겼지?” “TransactionManager는 누가 만들었지?” 같은 질문에 구조적으로 답할 수 있게 되는 것이 목표다.1) DataSource 자동 설정은 언제 시작될까Spring Boot에서 DataSource는 Auto-Configuration의 대표 사례다.DataSource 자동 설정은 다음 조건이 맞을 때 활성화된다.JDBC 관련 라이브러리가 classpath에 존재하고사용자가 직접 DataSource Bean을 정의하지 않았으며필..

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

11편에서는 ApplicationEvent와 Listener를 통해 Spring Boot 실행 흐름을 “관찰”하는 관점을 정리했다.이번 글에서는 그 관찰 대상 자체, 즉 Spring Boot 애플리케이션이 실제로 시작되는 전 과정을 단계별로 해부해본다.목표는 단순하다. “이 시점에 이 코드를 넣어도 되는가?” 이 질문에 스스로 답할 수 있다면, Startup 단계는 더 이상 감으로 다루는 영역이 아니다.1) 모든 시작은 SpringApplication.run()이다Spring Boot 애플리케이션의 시작점은 항상 같다.public static void main(String[] args) { SpringApplication.run(Application.class, args);} 이 메서드는 단순히 ..

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

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