knowledge

Wiki

• AOP와 Dynamic Proxy — @Transactional·@Cacheable의 비밀메서드에 @Transactional 하나 붙였을 뿐인데 앞뒤로 트랜잭션이 열리고 닫힌다. 내 코드엔 그런 로직이 한 줄도 없는데. 그 비밀은 스프링이 내 객체를 몰래 '프록시'로 바꿔치기하기 때문이다. AOP와 다이내믹 프록시가 어떻게 부가 기능을 끼워 넣는지 연다백엔드Spring스프링 내부→
• BeanFactory vs ApplicationContext — 스프링 컨테이너의 두 얼굴스프링은 객체를 대신 만들고 관리해 주는 '컨테이너'다. 그 컨테이너의 가장 밑바닥 인터페이스가 BeanFactory이고, 실무에서 실제로 쓰는 건 그 위에 편의 기능을 잔뜩 얹은 ApplicationContext다. 둘의 관계와 차이를 밑바닥부터 짚는다백엔드Spring스프링 내부→
• Bean 생성 과정 — 설계도에서 완성된 객체까지@Component 하나 붙였을 뿐인데 스프링은 그 객체를 알아서 만들어 꽂아 준다. 그 '알아서'의 내부를 연다. BeanDefinition이라는 설계도를 모으고 → 인스턴스를 만들고 → 의존성을 채우고 → 초기화하고 → 후처리로 마무리하는 다섯 단계를 순서대로 따라간다백엔드Spring스프링 내부→
• BeanPostProcessor — 애노테이션이 실제 동작으로 바뀌는 곳@Autowired를 붙이면 값이 채워지고, @EventListener를 붙이면 이벤트를 받고, @Transactional을 붙이면 트랜잭션이 걸린다. 이 '붙이면 저절로'의 정체가 바로 BeanPostProcessor다. 빈 생성 파이프라인에 끼어들어 애노테이션을 해석하는 확장 지점을 연다백엔드Spring스프링 내부→
• DispatcherServlet — HTTP 요청이 Controller까지 가는 길브라우저가 GET /orders/42를 보내면, 그게 어떻게 내 @GetMapping 메서드까지 도달할까. 그 사이엔 DispatcherServlet이라는 '중앙 교통정리원'이 있다. 요청을 받아 어느 컨트롤러로 보낼지 찾고, 인자를 만들어 넣고, 결과를 응답으로 바꾸는 전 과정을 연다백엔드Spring스프링 내부→