조용한 개발 노트

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

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가 의도적으로 관여하지..