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스프링 내부→
• Config Server — 흩어진 설정을 한 곳에서 뿌리기DB 주소·키·플래그가 서비스마다 흩어지면, 값 하나 바꾸는 데 전부 재배포해야 한다. 설정을 중앙에 모아 각 서비스에 내려보내는 Config Server가 무엇을 풀어주는지, 부팅 시점의 흐름과 갱신·암호화까지 따라간다백엔드MSASpring→
• Eureka — 서비스들이 서로를 이름으로 찾는 전화번호부서비스가 수시로 죽고 살아나고 늘어나는 환경에서, IP를 코드에 박으면 곧 깨진다. 서비스가 자기 위치를 등록하고 서로를 이름으로 찾게 해주는 서비스 디스커버리 — Eureka의 등록·발견·헬스체크 흐름을 따라간다백엔드MSASpring→
• Spring Cloud — 흩어진 서비스를 하나처럼 묶는 도구 모음서비스를 여러 개로 쪼개면 생기는 공통 문제들 — 설정 관리, 서로 찾기, 입구 통일, 장애 격리 — 을 스프링이 한 묶음으로 풀어주는 게 Spring Cloud다. 각 조각이 무슨 문제를 맡는지 지도부터 그려본다백엔드MSASpring→