2단계: 스프링 핵심 공략 (Core/Boot/JPA/테스트)

이 단계에서 얻는 것

이 단계는 “스프링 어노테이션을 외우는 단계”가 아니라, 스프링이 왜 이렇게 동작하는지를 이해하고, 실제로 운영 가능한 백엔드 애플리케이션의 기본 뼈대를 갖추는 단계입니다.

• IoC/DI/AOP/Proxy 감각: “왜 프록시가 생기고, 어디서 안 먹히는지(self-invocation)”를 설명할 수 있습니다.
• 트랜잭션을 ‘안전하게’ 쓰기: 경계/전파/롤백 규칙을 이해하고, 실수 패턴을 예방합니다.
• API 계약을 고정하기: Validation, 에러 응답 규약, 공통 예외 처리로 API를 예측 가능하게 만듭니다.
• 운영 가능한 설정 구조: 프로필/설정 분리, Boot 자동설정 이해로 “환경에 따라 깨지는” 문제를 줄입니다.
• 테스트 베이스라인: 단위/슬라이스/통합 테스트를 구분하고, 최소 비용으로 신뢰도를 올립니다.

이 모듈을 보는 방법

이 페이지 아래에 연결된 글이 순서대로 정렬됩니다. 위에서 아래로 읽되, 각 글은 다음 순서로 활용하면 좋습니다.

1. “이 글에서 얻는 것”을 보고 내가 지금 필요한 지점을 정한다
2. 핵심 개념을 읽고, 예제 코드를 한 번이라도 직접 실행/재현한다
3. “자주 하는 실수”를 체크해서 같은 함정을 피한다
4. 마지막 연습 과제로 개념을 잠근다

왜 이런 순서인가

스프링에서 흔한 문제는 결국 “컨테이너/프록시/트랜잭션/계약”으로 수렴합니다.

• 먼저 IoC/DI로 객체 그래프와 생명주기를 잡고,
• 그 위에서 트랜잭션/AOP가 프록시로 어떻게 적용되는지 이해한 뒤,
• Validation/에러 핸들링으로 API 계약을 고정하고,
• Boot 자동설정/프로필로 환경 차이를 통제합니다.

다음 단계로 넘어가기 전에(권장 기준)

• @Transactional이 적용 안 되는 케이스를 2~3가지 설명할 수 있다(프록시/호출 경계/예외 타입 등)
• 검증 실패/비즈니스 실패/시스템 실패를 서로 다른 응답으로 구분해 설계할 수 있다
• “왜 이 빈이 등록됐지?”를 자동설정/컴포넌트 스캔/조건부 설정 관점에서 추적할 수 있다