Spring Framework Core

Spring Framework의 본질은 "제어를 개발자에게서 Framework로 넘기고(IoC), 개발자는 POJO로 비즈니스 로직에만 집중하게 한다"는 것이다. 이 페이지는 Library와 Framework의 근본 차이, 그리고 그 위에서 동작하는 Spring Triangle(IoC/DI, AOP, PSA)을 다룬다. Spring AOP는 AOP의 프록시 기반 구체적 구현이고, Spring Transaction은 DI + AOP로 선언적 트랜잭션을 구현한 사례이며, Spring MVC Controller는 PSA 기반 웹 계층이다.

Library vs Framework — 근본 차이: IoC

구분	Library	Framework
제어 주체	개발자(내가 Library를 호출)	Framework(Framework가 내 코드를 호출)
흐름 결정	개발자가 순서·시점 관리	Framework가 시작·호출 시점 결정
예시	HikariCP(`new HikariDataSource()`), Jackson, Lombok	Spring, Django, Vue.js

Library vs Framework의 근본 차이는 IoC(제어의 역전)다. Library는 개발자가 호출하고, Framework는 Framework가 개발자 코드를 호출한다.^[1] Tomcat이 doGet()을 개발자 대신 호출하는 것이 대표적 예다.

IoC(Inversion of Control) — 프로그램의 제어 흐름이 뒤바뀌는 것. 개발자가 작성한 코드를 직접 제어하는 것이 아니라, 외부(Framework)에 의해 제어가 이루어진다.^[1:1]

Framework는 "반완성된 틀"로 공통 기능이 미리 구현되어 있고, 개발자는 정해진 규칙에 따라 비즈니스 로직만 작성한다.^[2]

Spring Triangle — POJO 위의 3대 요소

flowchart TD
  POJO["POJO
(Plain Old Java Object)"]
  IoC["IoC / DI
(제어 역전 + 의존성 주입)"]
  AOP["AOP
(횡단 관심사 분리)"]
  PSA["PSA
(서비스 추상화)"]
  POJO --> IoC
  POJO --> AOP
  POJO --> PSA

요소	의미	핵심 역할
POJO	특정 환경/기술에 종속되지 않는 순수 Java 객체	유지보수 용이, 테스트 용이, 객체지향 설계 자유
IoC/DI	객체 생성·생명주기 관리를 Spring Container가 대신함. "어떻게 만들지" 대신 "무엇을 원하는지"만 선언	개발자는 비즈니스 로직에 집중
AOP	횡단 관심사(로깅·트랜잭션·보안·성능 측정)를 비즈니스 코드와 분리	모듈성 향상, 공통 기능 중복 제거
PSA	환경·세부 기술 변경과 무관하게 일관된 방식으로 기술 접근	MyBatis/JPA 어떤 ORM을 써도 트랜잭션 처리 동일

Spring 핵심 철학은 POJO 기반 개발이다 — 순수 Java 클래스만으로 엔터프라이즈 수준 개발이 가능하며, Spring 코드가 비즈니스 코드에 침투하지 않는 비침투적 설계를 따른다.^[3]

IoC/DI: 객체의 생성과 생명주기 관리를 Spring Container가 대신하고, DI는 IoC를 구현하는 구체적 방법으로 객체가 필요로 하는 의존 객체를 외부(Spring)에서 주입한다.^[4]
AOP: 애플리케이션에는 비즈니스 로직 외에 모든 곳에 공통으로 필요한 횡단 관심사(성능 모니터링·로깅·트랜잭션·보안 검사)가 있고, AOP는 이를 비즈니스 코드와 분리하는 기술이다.^[5]
PSA: 환경과 세부 기술의 변경과 관계없이 일관된 방식으로 기술에 접근할 수 있게 해주는 설계 원칙이다. 트랜잭션 추상화, ORM 추상화, Exception 변환 등이 포함되며, MyBatis나 JPA 어떤 ORM을 쓰더라도 트랜잭션 처리는 동일하다.^[6]

이 구조가 비침투적 설계를 가능케 한다고 볼 수 있다 — Spring 코드가 비즈니스 코드에 침투하지 않으므로 비즈니스 로직은 순수 Java 객체로 남고, 프레임워크를 바꿔도 비즈니스 코드는 살아남는다는 것이 이 페이지의 종합이다.

EJB에서 Spring으로

EJB의 문제점: 설정이 극도로 복잡(XML 설정 파일만 수십 개), EJB 컨테이너 없이는 동작하지 않아 테스트 불가, 특정 인터페이스 구현 강제로 순수 Java 객체 사용 불가, 개발/배포 사이클이 매우 느림.^[7]
Rod Johnson이 2002년 저서 "Expert One-on-One J2EE Design and Development"에서 EJB 없이도 좋은 설계가 가능함을 증명했고, 2003년 이 코드를 기반으로 Spring Framework가 공개됐다.^[7:1]

실패 모드

DI 없이 직접 new로 의존성을 생성하면 결합도가 높아지고 테스트가 어려워진다.
AOP 프록시로 모든 cross-cutting concern을 처리하려다 과도한 추상화로 디버깅이 어려워지는 경우.
PSA의 추상화 계층이 세부 기술의 장점을 가리는 경우 — ORM 고유 기능을 쓰려면 추상화를 우회해야 하는 상황.
POJO를 지키지 않고 Spring API(@Autowired, @Transactional)가 비즈니스 코드 깊숙이 침투하는 경우 — 비침투적 설계 원칙 위배.
IoC를 이해하지 못하고 Framework 위에서 절차적 코드를 작성하는 경우 — Spring의 이점을 못 쓴다.

출처

테스트 질문

Library와 Framework의 근본 차이는 무엇인가? IoC는 어떤 점에서 "제어의 역전"인가?
Spring Triangle(IoC/DI, AOP, PSA)이 POJO 위에서 어떻게 상호 작용하는가?
비침투적 설계가 "Spring 코드가 비즈니스 코드에 침투하지 않는다"는 것의 실제 의미는 무엇인가?
PSA가 "어떤 ORM을 써도 트랜잭션 처리가 동일"하게 만드는 원리는 무엇인가?
EJB의 어떤 문제를 Spring이 POJO + IoC로 해결했는가?

Framework.md — "근본적 차이 : 제어의 역전 (Inversion of Control, IoC)", "프로그램의 제어 흐름 구조가 뒤바뀌는 것", "개발자가 작성한 코드를 직접 제어하는 것이 아니라, 외부(Framework)에 의해 제어가 이루어지는 것" ↩︎ ↩︎
Framework.md — "완성된 애플리케이션이 아닌 "반완성된 틀"", "개발자는 정해진 규칙 (Convention)에 따라 비즈니스 로직 (핵심 코드)만 작성하면 됨" ↩︎
Framework.md — "POJO (Plain Old Java Object) 기반 개발", "순수 Java 클래스만으로 엔터프라이즈 수준 개발 가능", "비침투적 설계 (Spring 코드가 비즈니스 코드에 침투하지 않음)" ↩︎
Framework.md — "객체의 생성과 생명주기 관리를 Spring Container가 대신 해 줌", "DI: IoC를 구현하는 구체적인 방법", "객체가 필요로 하는 의존 객체를 외부 (Spring)에서 주입해줌" ↩︎
Framework.md — "횡단 관심사 (Cross-Cutting Concerns)를 비즈니스 코드와 분리하는 기술이 AOP", 모든 메서드 실행 시간 측정·로그 기록·트랜잭션·보안 검사를 횡단 관심사 예시로 제시. ↩︎
Framework.md — "환경과 세부기술의 변경과 관계없이 일관된 방식으로 기술에 접근할 수 있게 해주는 설계 원칙", "MyBatis나 JPA등 어떤 ORM을 쓰더라도 트랜잭션 처리는 동일" ↩︎
Framework.md — "설정이 극도로 복잡 (XML 설정 파일만 수십 개)", "EJB 컨테이너 없이는 동작하지 않아 테스트 불가", "Rod Johnson이 2002년 저서 "Expert One-on-One J2EE Design and Development"에서 EJB 없이도 좋은 설계가 가능함을 증명", "2003년 이 코드를 기반으로 Spring Framework 공개 (오픈소스)" ↩︎ ↩︎