스프링 프레임 워크

1. 스프링 프레임 워크란

 

**스프링 프레임워크(Spring Framework)**는
자바(Java) 기반 엔터프라이즈 애플리케이션을 효율적으로 개발하기 위한 오픈소스 프레임워크입니다.
핵심 목적은 객체 간 결합도를 낮추고(유연성↑), 반복 작업을 줄이며(생산성↑), 테스트와 유지보수를 쉽게 만드는 것입니다.

 

 

1) IoC (Inversion of Control, 제어의 역전)

• 객체를 개발자가 직접 new 하지 않음
• 스프링 컨테이너가 객체 생성과 생명주기를 관리
• 코드가 프레임워크에 덜 의존 → 변경에 강함

@Component
public class ServiceA {
    // 객체 생성 안 함
}

 

 

2) DI (Dependency Injection, 의존성 주입)

• 객체가 필요한 의존 객체를 외부에서 주입
• 결합도 감소, 테스트 용이

@RequiredArgsConstructor
@Service
public class OrderService {
    private final OrderRepository orderRepository;
}

 

3) AOP (Aspect Oriented Programming)

• 공통 관심사 분리
• 로깅, 트랜잭션, 보안 등을 핵심 로직과 분리

@Transactional
public void save() { }

 

 

스프링 vs 스프링 부트

• Spring Framework
  • 기능이 많고 유연하지만 설정이 복잡
• Spring Boot
  • 스프링을 쉽게 쓰게 만든 도구
  • 자동 설정, 내장 서버, 빠른 시작

왜 스프링을 쓰는가 (현실적인 이유)

• 대규모 서비스에 검증됨
• 유지보수·테스트에 강함
• 생태계 방대 (JPA, Security, Batch 등)
• 국내·해외 채용 시장 사실상 표준

 

2. 스프링을 실무에서 사용하지 못한다면.

 

“스프링을 실무에서 사용하지 못한다면 → 백엔드 개발자로서 실무 투입이 매우 어렵다”
특히 국내 Java 백엔드 시장에서는 거의 불가능에 가깝습니다.

 

그 이유로는 

 

1) 실무 요구 자체가 스프링 전제

대부분 채용 공고는 암묵적으로 아래를 기본값으로 둡니다.

• Spring Boot
• Spring MVC
• Spring Data JPA
• @Transactional
• DI / IoC 이해

=> *“자바는 할 줄 압니다”*는
스프링을 못 쓰면 의미가 거의 없습니다.

 

 

2) 단순 문법 문제가 아님

스프링을 못 쓴다는 건 보통 이런 상태입니다.

• @Service, @Repository 역할 구분 불가
• 트랜잭션 경계 설정 못함
• DI 설계 감각 없음
• 테스트 코드 작성 불가
• 계층 분리 개념이 흐림

이건 툴 미숙이 아니라
=>서버 애플리케이션 설계 역량 부족으로 평가됩니다.

 

3)  “다른 프레임워크 하면 되지 않나요?”의 현실

이론적으로는 가능하지만 현실은 다릅니다.

대안현실

순수 Servlet	실무 거의 없음
Node.js	Java 포지션과 분리
Python (Django)	주니어 진입 장벽 높음
Go	신입 거의 안 씀

=> Java를 선택했다면 스프링은 선택이 아니라 필수입니다.

 

 

 

3.스프링이 제공하는 최적화와 효율성

 

1) 객체 생성·관리 최적화 (IoC / DI)

문제 (스프링 없을 때)

• 객체 생성 위치가 분산됨
• new 남발 → 결합도 증가
• 교체·테스트 비용 폭증

스프링의 최적화

• 싱글톤 컨테이너 기본 관리
• 객체 재사용 → 메모리 절약
• 의존성 변경 시 코드 수정 최소화

@Service // 기본 싱글톤
public class OrderService { }

 

=>객체 생성 비용 + 관리 비용 감소

2) 트랜잭션 처리 최적화

문제

• try-catch + commit/rollback 직접 관리
• 예외 누락 시 데이터 꼬임
• 코드 가독성 최악

스프링의 최적화

• 선언적 트랜잭션 (@Transactional)
• 런타임 예외 기준 자동 rollback
• 커넥션 효율적 재사용

@Transactional
public void saveOrder() { }

 

=>정합성 유지 + 개발자 실수 제거

3) AOP 기반 공통 로직 분리

문제

• 로깅, 권한, 시간 측정 코드 중복
• 핵심 로직 가독성 붕괴

스프링의 최적화

• 프록시 기반 AOP
• 핵심 비즈니스 로직 집중

@Around("execution(* service..*(..))")

 

=>중복 제거 + 코드 응집도 상승

4) 데이터 접근 성능 최적화 (Spring Data JPA)

제공 최적화 요소

• 1차 캐시 (영속성 컨텍스트)
• 쓰기 지연 (Batch Insert)
• 변경 감지 (Dirty Checking)

member.setName("변경");
// update 쿼리 자동 처리

=>불필요한 SQL 감소 = DB 부하 감소

5) 웹 요청 처리 효율 (Spring MVC)

최적화 포인트

• DispatcherServlet 중앙 제어
• 스레드 재사용 (서블릿 컨테이너)
• 파라미터 바인딩 자동화

@GetMapping("/users/{id}")
public UserDto get(@PathVariable Long id)

=>요청 처리 비용 감소 + 코드 간결

6) 예외 처리 & 안정성 최적화

• 전역 예외 처리 (@ControllerAdvice)
• 일관된 에러 응답
• 장애 지점 추적 용이

=>운영 안정성 ↑ / 장애 대응 시간 ↓

7) 테스트 효율 극대화

• DI 기반 Mock 주입 가능
• 단위 테스트/통합 테스트 분리

@MockBean
private UserRepository userRepository;

 

=>테스트 작성 비용 감소 + 품질 상승

 

4. 면접관이 해당 질문을 한다면 그 의도는. 

 

1) “이 사람이 스프링을 써본 사람인가?”

• 의도: 공식 문서 암기 vs 실무 사용 경험 구분
• 보고 싶은 신호
  • “CPU 최적화” 같은 추상적 얘기 X
  • 트랜잭션, 객체 생명주기, 중복 제거 같은 현실적 얘기 O

=> 실무자는
“스프링의 최적화는 성능보다 실수 방지·유지보수 비용 감소 쪽이 큽니다”라고 답함

 

2) “프레임워크의 역할을 과대평가하지는 않는가?”

• 의도: 스프링을 만능으로 보는지 확인
• 보고 싶은 신호
  • “스프링이 알아서 성능 다 잡아줍니다” X
  • “설계를 단순화해 잘못된 최적화를 줄여준다” O

=> 면접관은
**‘스프링이 뭘 해주고, 뭘 안 해주는지’**를 아는지를 봅니다.

 

 

 

3) “이 사람이 왜 이 구조를 쓰는지 알고 있나?”

• 의도: 관성적인 사용자인지 판단
• 보고 싶은 신호
  • DI → 결합도 감소
  • AOP → 공통 로직 분리
  • @Transactional → 정합성·커넥션 관리

=> “왜 쓰는지” 설명 못 하면
복붙 개발자로 분류됩니다.

 

4) “문제 생겼을 때 원인 추적이 가능한가?”

• 의도: 장애 대응 가능성 평가
• 보고 싶은 신호
  • 프록시/AOP/트랜잭션 경계 이해
  • “이 지점에서 프록시 때문에 동작이 달라질 수 있다”는 인식

=> 이 질문은
**‘운영 중 문제를 혼자 해결할 수 있나?’**를 보는 질문입니다.

 

 

5) “우리 팀에 바로 투입해도 되는가?”

• 의도: 온보딩 비용 계산
• 합격 신호
  • 스프링이 개발 속도·안정성·협업 효율을 높인다는 설명
  • 코드 품질 관점의 최적화 언급