조용한 개발 노트

49편에서는 Spring Boot 공식 문서를 다시 읽는 관점을 정리했다.이번 글은 이 시리즈의 마지막이자, 가장 오해받기 쉬운 질문을 다룬다. “Spring Boot를 언제 떠나야 할까?” 이 질문은 Spring Boot가 부족해서가 아니라, 충분히 잘 쓰고 있기 때문에 등장한다.1) “떠난다”는 말의 오해부터 정리하자Spring Boot를 떠난다는 말은 흔히 이렇게 오해된다.Spring Boot는 더 이상 쓸모없다Spring Boot는 한계가 명확하다이제는 순수 Spring이 더 낫다하지만 이 시리즈에서 말하는 “떠남”은 이런 의미가 아니다. “Spring Boot의 기본 전제에 더 이상 맞지 않는 문제를 Spring Boot 방식으로 억지로 풀지 않는다” 이는 배신이 아니라, 성숙한 사용의 결과다...

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

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