조용한 개발 노트

[Spring Boot 공식 문서 정리] 40. Spring Boot 업그레이드 전략39편에서는 테스트 환경과 운영 환경이 왜 다를 수밖에 없는지, 그리고 그 차이를 어떻게 받아들여야 하는지를 정리했다.Part 4의 마지막 글인 이번 편에서는, 그 모든 차이와 변화가 한꺼번에 몰려오는 순간, Spring Boot 업그레이드를 어떻게 바라보고 접근해야 하는지를 다룬다.많은 팀이 업그레이드를 이렇게 느낀다. “당장 안 하면 안 되지만, 하면 무언가 반드시 깨질 것 같다.” 이 불안의 정체를 분해해보는 것이 이 글의 목표다.1) Spring Boot 업그레이드는 “버전 변경”이 아니다Spring Boot 업그레이드를 단순히 라이브러리 버전 올리기로 생각하면, 거의 항상 문제가 생긴다.Spring Boot는 다..

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

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

36편에서는 SpringApplication 커스터마이징을 통해 실행 이전 단계에서 어디까지 개입해야 하는지를 정리했다.이번 글에서는 그 다음 단계, 실제 운영 중 가장 많이 마주치는 질문을 다룬다. “Spring Boot 서비스가 느린데, 어디부터 봐야 할까?” 성능 문제는 대부분 “튜닝 포인트”가 아니라 접근 순서에서 갈린다.1) 성능 문제의 90%는 Spring Boot 밖에 있다성능 이슈가 발생하면 가장 먼저 Spring Boot를 의심하는 경우가 많다.하지만 실무에서 보면, 실제 병목의 대부분은 다음 중 하나다.비즈니스 로직 복잡도DB 쿼리와 인덱스외부 API 호출 지연Spring Boot는 이 위에 얹혀 있는 실행 환경일 뿐, 병목의 근원인 경우는 드물다.그래서 성능을 볼 때는 “Boot가 느..

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의 설정 우선순위는 무작위 규칙의 집합이 아니다.핵심 철학은 단순하다. “더 늦게, 더 명시적으로 전달된 설정이 더 강한 의도를 가진다.” 그래서 일반적으로:코드에 가까운 설정 ❌실행 시점에 주입된 설정 ⭕이 원칙 덕분에 같은 바이..

33편에서는 멀티 모듈 구조에서 Spring Boot를 어디에 두어야 하는지를 기준으로 정리했다.이번 글에서는 그 구조가 한 단계 더 확장된 상황, 여러 개의 Spring Boot 애플리케이션을 동시에 운영해야 하는 시점을 다룬다.이 단계에서는 더 이상 “코드 구조”만의 문제가 아니다. 배포 단위, 운영 책임, 장애 전파 범위가 핵심이 된다.1) “왜 굳이 애플리케이션을 나눠야 할까?”단일 Spring Boot 애플리케이션으로 시작하는 것은 매우 자연스럽고 합리적인 선택이다.하지만 다음 질문이 나오기 시작하면, 분리를 고민할 시점이다.배치 작업이 API 서버 성능에 영향을 준다일부 기능만 따로 배포하고 싶다실행 옵션(JVM, 리소스)이 서로 다르다이 문제들은 코드 정리로 해결되지 않는다. 운영 단위의 문..

32편에서는 Spring Boot를 써도 아키텍처는 해결되지 않는 이유를 다뤘다.이번 글에서는 그 아키텍처 고민을 실제 코드 구조로 옮겨본다.멀티 모듈 환경에서 가장 자주 나오는 질문은 이것이다. “Spring Boot는 어디까지 내려가야 할까?” 이 질문에 답하지 못하면, 멀티 모듈은 곧 의존성 지옥으로 변한다.1) 멀티 모듈의 목적부터 분명히 하자멀티 모듈을 쓰는 이유는 단순히 프로젝트를 나누기 위해서가 아니다.역할과 책임을 분리하기 위해의존성 방향을 고정하기 위해변경 영향 범위를 제한하기 위해즉, 멀티 모듈은 아키텍처를 코드로 표현하는 수단이다.이 전제가 없으면, 모듈은 “폴더만 나뉜 단일 프로젝트”가 된다.2) Spring Boot는 “애플리케이션 모듈”에만 있어야 한다멀티 모듈 구조에서 가장 중..

31편에서는 Spring Boot의 기본값이 언제부터 불편해지는지를 살펴봤다.이번 글은 그 다음 질문으로 이어진다. “Spring Boot를 쓰고 있는데도 왜 구조가 무너지기 시작할까?” 이 질문의 답은 의외로 단순하다. Spring Boot는 아키텍처를 해결해 주는 도구가 아니기 때문이다.1) Spring Boot가 실제로 해결해 주는 것Spring Boot가 잘하는 일은 분명하다.애플리케이션을 빠르게 실행 가능하게 만든다설정과 의존성의 기본값을 제공한다운영에 필요한 최소한의 장치를 기본으로 포함한다이 덕분에 우리는 “환경을 만드는 비용”을 크게 줄일 수 있다.하지만 이 모든 것은 실행과 운영의 영역에 가깝다.2) Spring Boot가 해결하지 않는 것반대로 Spring Boot가 의도적으로 관여하지..

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