들어가며: 완성된 Bean을 두고 왜 또 다른 객체를 만드는가?Spring Container는 BeanDefinition을 기반으로 Bean을 생성하고, 의존성을 해결하여 객체 그래프를 완성한다. 나아가 BeanPostProcessor를 통해 생성이 완료된 Bean을 후처리한다. 여기서 한 가지 의문이 발생한다. 이미 완성된 Bean이 있는데, Spring은 왜 굳이 또 다른 객체를 만들어 등록하는가?Spring의 이례적인 동작 방식: 원본 Bean을 그대로 사용하지 않고, 전혀 다른 객체를 생성하여 Bean 대신 등록한다. 애플리케이션은 원본 객체가 아닌 이 새로운 객체를 사용하게 된다.성능상의 손해 감수: 객체를 추가로 생성하는 것은 메모리 사용량 증가와 메서드 호출 단계 추가를 의미한다.핵심 기능의..

들어가며: "Spring은 이미 생성된 Bean에 어떻게 새로운 기능을 투명하게 추가할까?" 앞 장에서는 Spring이 BeanDefinition을 바탕으로 Bean을 생성(Instantiate)하고, 의존성을 해결(Populate/DI)하여 하나의 완성된 객체 그래프를 구축하는 과정을 다루었습니다. 여기서 한 가지 근본적인 의문이 생깁니다.OrderService 객체가 메모리에 올라가고, 필요한 PaymentService 의존성까지 모두 주입되었다면 Spring의 역할은 여기서 완전히 끝난 것일까요?실제 Spring 애플리케이션의 Bean들은 생성 직후보다 생성된 이후에 훨씬 더 놀라운 일들을 겪게 됩니다.@Service@Transactionalpublic class OrderService { ..

들어가며: "Bean은 만들어졌다. 그런데 Spring은 수많은 Bean 중에서 어떤 객체를 찾아 연결할까?"앞 장에서는 Spring이 BeanDefinition을 기반으로 Bean을 생성하는 5단계 파이프라인을 살펴보았다. 그러나 객체를 인스턴스화(Instantiate)했다고 해서 곧바로 사용할 수 있는 것은 아니다. 객체지향 세계에서 단독으로 모든 일을 처리하는 객체는 드물다. OrderService는 PaymentService가 필요하고, PaymentService는 PaymentGateway가 필요하다.따라서 Bean은 메모리에 올리는 것만으로는 부족하며, 필요한 의존성을 찾아 서로 연결(Link)해야 비로소 하나의 객체 그래프(Object Graph)가 완성된다. Spring은 이 과정을 Dep..

Chapter 5. BeanDefinition과 Bean 생성 과정"Spring은 왜 객체를 관리하기 전에, 먼저 객체의 설계도를 관리할까?" 앞 장에서는 Spring Container가 Bean을 생성하고 관리하는 실행 환경이라는 점을 살펴보았다. 또한 Bean은 특별한 객체가 아니라 Spring Container가 관리하는 객체라는 사실도 확인했다. 그렇다면 이제 자연스럽게 새로운 질문이 생긴다."Spring은 어떤 Bean을 생성해야 하는지 어떻게 알고 있을까?"애플리케이션에는 수십 개, 많게는 수천 개의 Bean이 존재한다. Spring은 이 모든 객체를 무작정 생성하지 않는다. 먼저 어떤 객체를 생성해야 하는지, 어떻게 생성해야 하는지, 어떤 의존성을 가져야 하는지에 대한 정보를 수집한다. 그리..

들어가며: "Container를 이해하면 Bean, DI, AOP, Transaction이 모두 하나의 그림으로 연결된다." 대부분의 Spring 개발자가 `@Component`, `@Bean`, `@Autowired`를 일상적으로 사용하지만, 정작 Spring Container가 무엇인지 명확하게 설명하는 데는 어려움을 겪는다. 이 장은 단순히 ApplicationContext라는 인터페이스를 소개하는 데 그치지 않고, Spring이라는 프레임워크의 심장(Heart)이자 핵심 운영 체제를 파헤치는 장이다.4.1 Framework와 Library의 차이Spring Container를 제대로 이해하려면, 먼저 Framework와 Library의 결정적인 차이부터 짚고 넘어가야 한다. 두 개념 모두 재사용 ..

들어가며: "객체를 누가 생성하고, 누가 연결하며, 누가 관리해야 하는가?"앞 장에서는 객체가 자신의 의존성을 직접 new로 생성하는 구조가 왜 단일 책임 원칙(SRP)과 개방-폐쇄 원칙(OCP)을 뒤흔드는지 살펴보았다. 객체가 자신의 비즈니스 로직뿐만 아니라 "타 객체의 생성 및 조립"이라는 무거운 책임까지 끌어안게 되면, 코드는 구체 클래스와 단단히 결합되어 작은 변화에도 쉽게 무너지는 취약한 구조로 전락한다. 그렇다면 객체지향의 이상을 실현하기 위해 객체 생성과 관리라는 거대한 책임은 대체 누가 가져야 할까? Spring이 제시하는 답은 단호하고 명쾌하다. "객체가 스스로를 제어하지 말고, 제3의 존재인 컨테이너(Container)가 객체를 제어하도록 만들자."이 수동적인 변화이자 거대한 거버넌스..

들어가며: "객체는 자신의 일을 해야 할까, 아니면 필요한 객체까지 직접 만들어야 할까?"앞 장에서는 객체지향 프로그래밍이 역할과 구현을 분리하고, 다형성을 통해 변화에 유연한 설계를 지향한다는 점을 다루었다. 하지만 실제 프로젝트 현장에서는 이러한 이상적인 구조를 지속해서 유지하기가 매우 어렵다. 그 근본적인 이유는 대부분의 객체가 자신의 본래 책임을 수행하는 것뿐만 아니라, 자신이 사용할 객체를 직접 생성하고 조립하는 책임까지 떠안고 있기 때문이다. 이번 장에서는 객체가 직접 객체를 생성하는 행위가 어떻게 객체지향의 유연성을 무너뜨리는지 철저히 파헤쳐 본다. 그리고 본인 스스로 다음 한 가지 명확한 결론을 깨닫도록 이끄는 것이 이번 장의 핵심 목적이다.💡 이번 장의 핵심 결론: "객체 생성(Cons..

들어가며: "Spring은 왜 IoC와 DI를 핵심 철학으로 선택했을까?"많은 개발자는 Spring을 처음 접할 때 @Component, @Service, @Autowired 같은 애노테이션부터 배우기 시작한다. 하지만 이러한 기능들은 Spring의 본질이 아니다. Spring이 해결하려 했던 문제를 이해하지 못하면 IoC(Inversion of Control, 제어의 역전)와 DI(Dependency Injection, 의존성 주입)는 그저 "객체를 대신 생성해 주는 단순 편의 기능" 정도로만 받아들이게 된다. Spring을 제대로 이해하려면 먼저 객체지향 프로그래밍(OOP)이 무엇을 목표로 했는지, 그리고 왜 현실에서는 그 목표를 달성하기 어려웠는지를 살펴봐야 한다. Spring은 새로운 프로그래밍 ..