조용한 개발 노트

11편부터 19편까지, 우리는 Spring Boot를 “어떻게 쓰는가”가 아니라 “어디까지가 Boot의 책임인가”라는 관점으로 살펴봤다.이 마지막 글에서는 Part 2 전체를 관통하는 질문 하나로 정리한다. Spring Boot는 어디까지 맡기고, 언제부터는 내가 책임져야 할까? 이 질문에 답할 수 있다면, Spring Boot는 더 이상 블랙박스가 아니다.1) Spring Boot 확장의 출발점은 “불편함”이다대부분의 확장은 처음부터 의도적으로 시작되지 않는다.보통은 이런 순간에서 출발한다.기본 설정으로는 설명이 부족할 때여러 서비스에서 같은 설정을 반복할 때자동 설정의 동작을 정확히 통제하고 싶을 때중요한 점은, 이 불편함이 확장의 신호일 수는 있지만 무조건 확장해야 한다는 뜻은 아니라는 것이다.2)..

18편에서는 Embedded Server를 통해 애플리케이션의 실행 모델과 책임 경계를 정리했다.이번 글에서는 그 다음으로 가장 많은 문제가 발생하는 영역, DataSource와 트랜잭션 Auto-Configuration을 다룬다.“왜 DataSource가 두 개 생겼지?” “TransactionManager는 누가 만들었지?” 같은 질문에 구조적으로 답할 수 있게 되는 것이 목표다.1) DataSource 자동 설정은 언제 시작될까Spring Boot에서 DataSource는 Auto-Configuration의 대표 사례다.DataSource 자동 설정은 다음 조건이 맞을 때 활성화된다.JDBC 관련 라이브러리가 classpath에 존재하고사용자가 직접 DataSource Bean을 정의하지 않았으며필..

17편에서는 Auto-Configuration을 어디까지, 어떤 순서로 커스터마이징해야 하는지를 정리했다.이번 글에서는 그 연장선에서, Spring Boot 애플리케이션이 실행되는 런타임의 가장 바깥 경계, 바로 Embedded Server를 다룬다.“스레드 풀을 튜닝해야 할까?” “Tomcat 설정을 직접 건드려야 할까?” 같은 질문에 대한 기준을 세우는 것이 목표다.1) Embedded Server는 “편의 기능”이 아니라 “설계 선택”이다Spring Boot 이전에는 애플리케이션 서버(WAS)와 애플리케이션이 명확히 분리되어 있었다.Spring Boot는 이 구조를 뒤집었다. “서버를 애플리케이션 안으로 가져오자.” Embedded Server는 단순한 편의 기능이 아니다. 배포 단위를 단순화하고,..

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

15편에서는 Metrics & Monitoring을 통해 운영 판단에 필요한 관측 기준을 정리했다.이번 글에서는 그 판단의 출발점이 되는 설정(Configuration)을 어떻게 다뤄야 하는지, 특히 @ConfigurationProperties를 중심으로 “제대로 쓰는 기준”을 정리한다.설정은 단순한 값 모음이 아니다. 잘 설계하면 구조를 안정시키고, 잘못 설계하면 장애의 시작점이 된다.1) @Value는 편하지만, 구조를 남기지 않는다Spring을 처음 쓰면 설정 값을 이렇게 읽기 시작한다.@Value("${external.api.timeout}")private long timeout; 이 방식은 간단하고 빠르다. 하지만 프로젝트가 커질수록 문제가 드러난다.설정 값이 여기저기 흩어진다어떤 설정이 한 ..

14편에서는 Health Indicator를 통해 언제 트래픽을 받아야 하고, 언제 빠져야 하는지를 다뤘다.이번 글에서는 그 다음 단계, “그래서 지금 시스템 상태는 어떤가?”에 답해주는 Metrics와 Monitoring을 정리한다.메트릭은 많이 모을수록 좋은 것처럼 보이지만, 실제 운영에서는 정반대인 경우가 많다.1) Metrics의 목적은 “관찰”이지 “기록”이 아니다처음 모니터링을 도입할 때 흔히 생기는 오해는 이것이다.“일단 다 모아두면 언젠가 쓰겠지.”하지만 Metrics의 목적은 나중을 위한 로그 저장이 아니다. 지금 시스템이 어떤 상태인지, 문제가 생기고 있는지 빠르게 판단하기 위함 이 목적에서 벗어난 메트릭은 비용만 늘리고 판단을 흐리게 만든다.2) Spring Boot Metrics의 ..

13편에서는 Actuator가 왜 Spring Boot의 핵심 기능인지, 그리고 “production-ready”가 무엇을 의미하는지 살펴봤다.이제 그중에서도 운영에 가장 직접적으로 영향을 미치는 주제, Health Indicator를 다뤄보자.Health Indicator는 단순한 상태 체크가 아니다. 잘 설계되면 장애를 빠르게 복구하게 만들고, 잘못 설계되면 멀쩡한 서비스를 스스로 죽이기도 한다.1) Health Check는 “살아있다”의 정의부터 다르다많은 서비스가 Health Check를 이렇게 생각한다.“요청 하나 보내서 200이면 OK”하지만 Spring Boot Actuator가 말하는 Health는 훨씬 더 구체적이다.지금 프로세스가 살아 있는가?필수 의존성은 정상인가?지금 트래픽을 받아도..

12편에서는 Spring Boot 애플리케이션의 Startup 단계 전체 흐름를 해부했다.이제 관점을 한 단계 더 넓혀보자.애플리케이션이 “실행된 이후”에 무엇이 필요한가?이 질문에 대한 Spring Boot의 대답이 바로 Actuator다.1) Actuator는 “있으면 좋은 옵션”이 아니다많은 사람들이 Actuator를 “모니터링용 부가 기능” 정도로 생각한다.하지만 Spring Boot 공식 문서에서 Actuator는 명확히 production-ready 기능으로 분류된다.이 말의 의미는 단순하다. “운영에 필요한 기능은 나중에 붙이는 것이 아니라, 애플리케이션의 일부다.” Actuator는 애플리케이션이 살아 있는 동안 스스로의 상태를 외부에 설명할 수 있게 해준다.2) Spring Boot가 말..

11편에서는 ApplicationEvent와 Listener를 통해 Spring Boot 실행 흐름을 “관찰”하는 관점을 정리했다.이번 글에서는 그 관찰 대상 자체, 즉 Spring Boot 애플리케이션이 실제로 시작되는 전 과정을 단계별로 해부해본다.목표는 단순하다. “이 시점에 이 코드를 넣어도 되는가?” 이 질문에 스스로 답할 수 있다면, Startup 단계는 더 이상 감으로 다루는 영역이 아니다.1) 모든 시작은 SpringApplication.run()이다Spring Boot 애플리케이션의 시작점은 항상 같다.public static void main(String[] args) { SpringApplication.run(Application.class, args);} 이 메서드는 단순히 ..

10편에서는 Spring Boot를 “프레임워크처럼 의존하는 대상”이 아니라 이해한 뒤 활용해야 할 실행 환경으로 바라보는 관점을 정리했다.Part 2는 그 관점을 바탕으로, Spring Boot 애플리케이션의 실행과 운영을 더 깊게 이해하는 단계다.그 첫 주제는 실행 흐름과 항상 함께 등장하지만, 기준 없이 쓰이면 구조를 망치기 쉬운 기능, ApplicationEvent와 Listener다.1) ApplicationEvent는 “알림”이지 “제어 수단”이 아니다Spring Boot에는 애플리케이션 실행 과정에서 발생하는 여러 이벤트가 존재한다.이를 흔히 이렇게 오해한다.“이 시점에 이 코드가 실행되게 하고 싶다 → 이벤트 쓰자”하지만 ApplicationEvent의 본래 목적은 흐름을 제어하는 것이 아..