조용한 개발 노트

27편에서는 Spring Boot의 Packaging 전략을 통해 왜 fat jar와 layered jar가 기본 선택이 되었는지를 살펴봤다.이번 글에서는 그 패키징 결과물이 컨테이너 환경에서 어떻게 실행되고, 왜 로컬과 다른 동작을 보이는지를 정리한다.“같은 JAR인데 왜 쿠버네티스에서는 다르게 느릴까?” “JVM 옵션을 왜 다시 봐야 할까?” 같은 질문에 구조적으로 답하는 것이 목표다.1) 컨테이너는 가상 머신이 아니다컨테이너 환경을 처음 접하면 VM과 비슷하다고 느끼기 쉽다.하지만 실행 모델은 전혀 다르다.VM: OS를 포함한 독립 환경컨테이너: 호스트 커널을 공유하는 프로세스 격리이 차이 때문에, JVM은 컨테이너 안에서 리소스를 “오해”할 가능성이 있다.Spring Boot가 컨테이너 친화적인 ..

23편에서는 Logging을 통해 애플리케이션이 실행된 이후의 상태를 어떻게 설명할 것인가를 다뤘다.이번 글에서는 그보다 더 앞선 시점, 애플리케이션이 “얼마나 빨리 준비 상태가 되는가”를 결정하는 Startup 성능을 다룬다.특히 Spring Boot에서 자주 언급되는 Lazy Initialization을 “써도 되는 도구”와 “위험한 지름길”의 경계로 정리해본다.1) Startup 성능이 중요한 순간모든 애플리케이션이 빠른 Startup을 요구하는 것은 아니다.하지만 다음과 같은 환경에서는 Startup 시간이 곧 운영 품질로 이어진다.컨테이너 기반 배포 (Kubernetes)오토스케일링 환경잦은 배포와 롤링 업데이트이 환경에서 Startup이 느리면, 서비스는 다음과 같은 문제를 겪는다.트래픽을 받..

22편에서는 ApplicationContextInitializer를 통해 Bean 이전 단계에 개입하는 책임 경계를 정리했다.이번 글에서는 애플리케이션이 실행된 이후, 가장 오래 남고 가장 많이 참조되는 산출물, 바로 로그(logging)를 다룬다.로그는 단순한 출력이 아니다. 잘 설계되면 시스템을 설명하고, 잘못 설계되면 문제를 숨긴다.1) Spring Boot Logging의 기본 철학Spring Boot는 로깅을 “라이브러리 선택의 문제”로 보지 않는다.대신 다음 질문에 답하려고 한다. “애플리케이션은 어떤 형태로 자신의 상태를 외부에 설명해야 하는가?” 그래서 Spring Boot는 별도 설정 없이도 즉시 사용 가능한 로깅 기본값을 제공한다.이 기본값의 목적은 “최적화”가 아니라 일관성 있는 출발..

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