본 단계에서는 STEP 2에서 완성된 '의미 세계'를 '실행 세계'로 연결하기 전, 모든 실행을 일시 정지시키고 시스템의 최종 설계도를 확정하는 BeanDefinition 레이어를 다룹니다.
현재까지 구축된 core 패키지는 '의미'를 다루는 데 있어 완결된 구조를 갖추고 있습니다.
- 구조적 특징:
view,registry,selector,order모두 어디에도 실행 책임이 없습니다. - 상태: 현재의 출력물은 오직
TypeMeaningView의 집합일 뿐입니다. 여기에는 인스턴스화 전략, 생명주기, DI 정보가 누락되어 있어 실행 세계로 즉시 진입할 수 없습니다.
흔히 BeanDefinition을 빈을 만들기 위한 정보체로 보지만, 구조적으로는 **"실행을 하지 않기 위해 존재하는 객체"**입니다.
- 의도적 최소화: 실행 로직이나 Reflection, 복잡한 상태를 배제하고 오직 이름(Name)과 타입(Type) 등 최소한의 메타데이터만 가집니다.
- 본질: "지금 당장 객체를 만들지 마라. 대신 우리가 무엇을 만들어야 할지 목록부터 확정하자"는 명령입니다.
Meaning에서 즉시 Instance로 넘어가는 파이프라인(MeaningToInstancePipeline)은 반드시 실패합니다.
- 책임의 혼재: STEP 2에서 공들여 분리한 책임들이 다시 하나로 엉겨 붙게 됩니다.
- 확장성 상실: DI, AOP, Lifecycle 처리가 끼어들 틈이 사라집니다.
- 버그의 현재화: 순서 문제나 충돌이 런타임 버그로 터져 나오며 제어 불가능한 상태가 됩니다.
MeaningToBeanDefinitionConverter는 시스템의 상하부를 가르는 거대한 분수령입니다.
- 위쪽 (의미 세계): Annotation, OrderHint, Tag 등 추상적 개념.
- 아래쪽 (실행 세계): Factory, DI, Lifecycle, Proxy 등 물리적 구현.
- BeanDefinition: 이 두 세계 사이의 완충층(Buffer) 역할을 수행하며, Spring Core가 성립할 수 있는 근거가 됩니다.
BeanDefinitionRegistry가 등장하면서 드디어 시스템은 실행 전에 모든 결정을 모을 수 있게 됩니다.
- 전수 조사: 실행 전에 관리 대상 전체를 파악합니다.
- 사전 검출: 이름 중복이나 정책 충돌을 객체가 생성되기 전에 찾아냅니다.
- 순서 인지:
OrderingSeed에서 발견된 잠재적 순서 문제를 실제 관리 포인트로 가져옵니다.
"Spring은 실행하기 전에, 먼저 모든 결정을 수집한다."
STEP 2가 "우리는 무엇을 알고 있는가?"에 대한 답이었다면, STEP 3-1은 "우리는 무엇을 할 것인가?"를 실행 없이 확정하는 단계입니다.
다음 단계 예고: "이제 결정된 설계도(BeanDefinition)들을 실제로 어떻게 순서대로 배치하고 조립할 것인가?" → Dependency & Order Resolution의 단계로 이어집니다.