조용한 개발 노트

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

48편에서는 운영 사고의 관점에서 Spring Boot 공식 문서를 재해석했다.이번 글은 Part 5의 정리이자, 이 시리즈 전체를 관통하는 질문에 대한 답이다. “Spring Boot 공식 문서는 어떻게 읽어야 의미가 생길까?” 같은 문서를 읽었는데 누군가는 ‘사용법’만 가져가고, 누군가는 ‘기준’을 가져간다. 그 차이는 읽는 순서와 관점에서 나온다.1) 처음부터 끝까지 읽지 말아야 하는 이유많은 개발자가 공식 문서를 이렇게 대한다.처음부터 순서대로 읽는다필요한 부분만 검색해서 본다두 방법 모두 나쁘지 않다.하지만 문제는, 이 방식으로는 Spring Boot가 전제로 삼는 ‘전체 그림’을 얻기 어렵다는 점이다.공식 문서는 설명서이면서, 동시에 설계 문서다. 설계 문서는 기능 순서가 아니라 의도를 중심으..

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

46편에서는 ApplicationEvent를 로직이 아닌 운영 신호로 사용하는 기준을 정리했다.이번 글에서는 그 신호들이 실제로 모이는 장소, Actuator를 중심으로 보안(Security)과 관측(Observability)을 어떻게 함께 설계해야 하는지를 다룬다.이 영역은 실무에서 사고가 가장 자주 발생하는 교차 지점이기도 하다.1) Actuator는 “상태 API”이지 “디버그 도구”가 아니다많은 팀이 Actuator를 문제 생겼을 때만 켜는 디버그 도구처럼 취급한다.하지만 Spring Boot에서 Actuator의 본질은 애플리케이션의 상태를 설명하는 API다.즉:개발자만을 위한 도구 ❌운영 시스템과의 계약 ⭕이 관점이 없으면, 노출과 보안은 항상 땜질이 된다.2) Observability의 출발..

45편에서는 애플리케이션 종료를 어떻게 설계해야 하는지를 다뤘다.이번 글에서는 실행과 종료의 경계에 위치한 주제, ApplicationEvent를 “운영 신호”로 사용하는 방법을 정리한다.ApplicationEvent는 잘 쓰면 운영 가시성을 높이는 도구가 되지만, 잘못 쓰면 구조를 망가뜨리는 트리거가 된다.1) ApplicationEvent의 본질은 “알림”이다ApplicationEvent는 Spring 내부에서 발생한 사실을 외부로 알리는 메커니즘이다.중요한 점은 이것이다. 이벤트는 “무언가를 하라”는 명령이 아니라, “무언가가 일어났다”는 신호다. 이 차이를 무시하는 순간, 이벤트는 제어 흐름의 일부가 되어버린다.2) Spring Boot가 제공하는 주요 라이프사이클 이벤트Spring Boot는 실..

44편에서는 Spring Boot Starter를 직접 만들 때의 기준을 통해 확장의 책임이 어디까지 커지는지를 살펴봤다.이번 글에서는 그 확장의 반대편, 애플리케이션의 “끝”을 다룬다.실행은 잘 설계하면서도, 종료는 거의 설계하지 않는 경우가 많다. 하지만 운영에서 사고가 나는 지점은 대부분 이 “끝”에서 시작된다.1) 애플리케이션 종료는 예외 상황이 아니다많은 코드가 애플리케이션 종료를 “비정상 상황”으로 취급한다.하지만 현대의 운영 환경에서는 종료는 매우 일상적인 이벤트다.배포로 인한 재시작오토스케일링노드 교체즉, 애플리케이션은 언제든지 종료될 수 있다는 전제 위에서 설계되어야 한다.2) Spring Boot는 언제 “종료 신호”를 받는가Spring Boot 애플리케이션은 외부에서 종료 신호를 받으..

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

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..