조용한 개발 노트

47편에서는 Actuator · Security · Observability가 하나의 운영 계약으로 설계되어야 한다는 기준을 정리했다.이번 글에서는 그 기준을 한 단계 더 밀어붙여, 운영 사고 이후에야 비로소 이해되는 Spring Boot 공식 문서의 문장들을 다시 읽어본다.이 글은 새로운 기능 설명이 아니다. 이미 문서에 있었지만, 사고를 겪기 전에는 그냥 지나쳤던 내용들에 대한 이야기다.1) “production-ready”라는 표현을 너무 가볍게 읽었던 순간Spring Boot 공식 문서에는 Actuator를 설명하며 자주 이런 표현이 등장한다. “production-ready features” 많은 개발자는 이 문장을 “운영에 도움이 되는 기능 모음” 정도로 읽는다.하지만 실제 사고를 겪고 나면,..

42편에서는 Spring Boot의 암묵적 기본값을 명시적으로 드러내는 방법을 다뤘다.이번 글에서는 설정 흐름의 가장 깊은 지점, EnvironmentPostProcessor와 ApplicationContextInitializer의 차이를 정리한다.두 개념은 비슷해 보이지만, 잘못 쓰면 설정을 강하게 만들고, 잘 쓰면 설정 흐름을 명확하게 만든다.1) 둘 다 “아주 이른 시점”에 개입한다공통점부터 짚어보자.EnvironmentPostProcessor와 ApplicationContextInitializer는 모두 Bean 생성 이전에 동작한다.즉, 이 시점에서는:Bean ❌의존성 주입 ❌@ConfigurationProperties 바인딩 ❌이 공통점 때문에 두 개념은 자주 혼동된다.하지만 책임은 전혀 다르..

41편에서는 Spring Boot의 Opinionated Defaults가 무엇을 전제로 설계되었는지를 살펴봤다.이번 글에서는 그 철학을 실제 코드와 설정으로 옮긴다. “우리가 의존하고 있는 기본값을 어떻게 명시적으로 드러낼 것인가?” 이 작업은 귀찮아 보이지만, 업그레이드·운영·확장 단계에서 가장 큰 차이를 만든다.1) 기본값은 ‘없어도 되는 설정’이 아니다많은 설정은 “안 써도 되니까 기본값이겠지”라는 이유로 생략된다.하지만 기본값이란 “중요하지 않다”는 뜻이 아니다.오히려 그 반대다. 기본값은 Spring Boot가 가장 강한 의견을 가진 지점이다. 이 지점을 드러내지 않으면, 우리는 “의견을 모르고 동의한 상태”로 시스템을 운영하게 된다.2) 명시화의 1차 대상: 실행과 직결된 기본값모든 기본값을..

40편에서는 Spring Boot 업그레이드를 통해 기본값에 얼마나 의존하고 있었는지를 되돌아봤다.Part 5는 이 지점에서 출발한다. “Spring Boot의 기본값은 무엇을 전제로 설계되었을까?” 이 질문에 답하지 않으면, 기본값은 언제나 “편하다가 갑자기 불편해지는 것”으로만 느껴진다.1) Opinionated Defaults란 무엇인가Spring Boot 공식 문서에서 가장 자주 등장하는 표현 중 하나가 Opinionated Defaults다.이를 단순히 번역하면 “의견이 반영된 기본값”이다.중요한 점은, 이 기본값이 중립적이지 않다는 사실이다.Spring Boot는 가능한 선택지 중 하나를 고르고, 그것을 기본값으로 강하게 밀어준다.그 선택에는 명확한 전제가 깔려 있다.2) Spring Boot..

38편에서는 Auto-Configuration이 성능에 미치는 영향을 통해 기본값이 언제 비용이 되는지를 살펴봤다.이번 글에서는 그 연장선에서, 실무에서 가장 당황스러운 상황 중 하나를 다룬다. “테스트는 다 통과하는데, 운영에서는 왜 깨질까?” 이 문제는 우연이 아니라, 테스트 환경과 운영 환경의 전제가 다르기 때문에 반복해서 발생한다.1) 테스트는 항상 “다른 Spring Boot”를 띄운다많은 개발자가 테스트를 이렇게 인식한다. “운영이랑 같은 Spring Boot를 띄우는 거니까 안전하겠지.” 하지만 실제로 테스트에서 띄우는 Spring Boot는 운영과 완전히 동일하지 않다.테스트는 다음을 의도적으로 바꾼다.ProfilePropertySourceAuto-Configuration 적용 범위외부 의..

35편에서는 PropertySource 우선순위를 언제 직접 만져야 하는지, 그리고 그 선택이 얼마나 무거운 책임인지 살펴봤다.이번 글에서는 그보다 더 앞선 지점, Spring Boot 실행의 진짜 시작점인 SpringApplication 자체를 커스터마이징하는 전략을 다룬다.이 주제는 자주 쓰이지 않지만, 한 번 쓰기 시작하면 애플리케이션의 성격 자체를 바꾸는 힘을 가진다.1) SpringApplication은 단순한 헬퍼가 아니다많은 코드에서 SpringApplication.run()은 거의 의식 없이 호출된다.public static void main(String[] args) { SpringApplication.run(Application.class, args);} 하지만 SpringApp..

34편에서는 여러 Spring Boot 애플리케이션을 운영할 때 배포·운영 단위를 어떻게 나누는지를 다뤘다.이번 글에서는 그 구조 위에서 반드시 다시 마주치게 되는 주제, PropertySource 우선순위를 다룬다.이 주제는 대부분 이렇게 시작된다. “분명 설정을 바꿨는데, 왜 반영이 안 되지?” 이 질문에 답하려면 Spring Boot의 설정 우선순위를 “기능 목록”이 아니라 설계 의도로 이해해야 한다.1) Spring Boot 설정 우선순위의 기본 철학Spring Boot의 설정 우선순위는 무작위 규칙의 집합이 아니다.핵심 철학은 단순하다. “더 늦게, 더 명시적으로 전달된 설정이 더 강한 의도를 가진다.” 그래서 일반적으로:코드에 가까운 설정 ❌실행 시점에 주입된 설정 ⭕이 원칙 덕분에 같은 바이..

25편에서는 Spring Boot Test의 전체 설계 철학과 @SpringBootTest vs Slice Test의 책임 경계를 정리했다.이번 글에서는 테스트를 작성하다 보면 반드시 마주치는 질문을 다룬다. “테스트를 위해 설정을 어디까지 바꿔도 괜찮을까?” 이 질문에 대한 기준이 없으면, 테스트는 점점 늘어나지만 구조는 빠르게 망가진다.1) TestConfiguration은 “편의 기능”이 아니다Spring Boot에서 테스트 전용 설정을 추가할 때 가장 먼저 떠올리는 도구가 @TestConfiguration이다.하지만 이 어노테이션은 “아무 설정이나 넣어도 되는 공간”이 아니다. TestConfiguration은 프로덕션 설정을 대체하기 위한 수단이 아니라, 테스트 환경을 설명하기 위한 도구다. 2..

2편에서는 Spring 애플리케이션의 출발점인 IoC 컨테이너(ApplicationContext)가 언제, 어떻게 만들어지는지를 살펴봤습니다.컨테이너가 만들어졌다면 다음 질문은 자연스럽게 이어집니다.“그럼 이 컨테이너 안에는 어떤 객체들이, 어떤 기준으로 들어가게 될까?”이번 글에서는 Spring이 Bean을 컨테이너에 등록하는 방식을 공식문서 흐름에 맞춰 정리해보겠습니다.1. Bean이란 무엇인가Spring에서 Bean은 단순한 객체가 아닙니다.한 문장으로 정의하면 다음과 같습니다.Spring IoC 컨테이너가 생성하고, 관리하며, 생명주기를 책임지는 객체즉, new 키워드로 직접 생성한 객체는 Spring 관점에서는 Bean이 아닙니다.컨테이너의 관리 대상이 되느냐, 이것이 Bean과 일반 객체를 가..

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