이 단계에서 얻는 것
이 단계는 “스프링 어노테이션을 외우는 단계”가 아니라, 스프링이 왜 이렇게 동작하는지를 이해하고, 실제로 운영 가능한 백엔드 애플리케이션의 기본 뼈대를 갖추는 단계입니다.
- IoC/DI/AOP/Proxy 감각: “왜 프록시가 생기고, 어디서 안 먹히는지(self-invocation)”를 설명할 수 있습니다.
- 트랜잭션을 ‘안전하게’ 쓰기: 경계/전파/롤백 규칙을 이해하고, 실수 패턴을 예방합니다.
- API 계약을 고정하기: Validation, 에러 응답 규약, 공통 예외 처리로 API를 예측 가능하게 만듭니다.
- 운영 가능한 설정 구조: 프로필/설정 분리, Boot 자동설정 이해로 “환경에 따라 깨지는” 문제를 줄입니다.
- 테스트 베이스라인: 단위/슬라이스/통합 테스트를 구분하고, 최소 비용으로 신뢰도를 올립니다.
이 모듈을 보는 방법
이 페이지 아래에 연결된 글이 순서대로 정렬됩니다. 위에서 아래로 읽되, 각 글은 다음 순서로 활용하면 좋습니다.
- “이 글에서 얻는 것”을 보고 내가 지금 필요한 지점을 정한다
- 핵심 개념을 읽고, 예제 코드를 한 번이라도 직접 실행/재현한다
- “자주 하는 실수”를 체크해서 같은 함정을 피한다
- 마지막 연습 과제로 개념을 잠근다
왜 이런 순서인가
스프링에서 흔한 문제는 결국 “컨테이너/프록시/트랜잭션/계약”으로 수렴합니다.
- 먼저 IoC/DI로 객체 그래프와 생명주기를 잡고,
- 그 위에서 트랜잭션/AOP가 프록시로 어떻게 적용되는지 이해한 뒤,
- Validation/에러 핸들링으로 API 계약을 고정하고,
- Boot 자동설정/프로필로 환경 차이를 통제합니다.
다음 단계로 넘어가기 전에(권장 기준)
@Transactional이 적용 안 되는 케이스를 2~3가지 설명할 수 있다(프록시/호출 경계/예외 타입 등)- 검증 실패/비즈니스 실패/시스템 실패를 서로 다른 응답으로 구분해 설계할 수 있다
- “왜 이 빈이 등록됐지?”를 자동설정/컴포넌트 스캔/조건부 설정 관점에서 추적할 수 있다