스프링(Spring)은 단순한 프레임워크 그 이상입니다. 그 시작은 2002년, Rod Johnson이 집필한 『Expert One-on-One J2EE Design and Development』라는 책에서 등장한 소스 코드에서 비롯됩니다. 당시 **EJB(Enterprise JavaBean)**는 무거운 구조와 복잡성으로 인해 '겨울'과도 같았죠. Rod는 이를 비판하며 '단순함'을 추구했고, 그 철학이 '봄(Spring)'이라는 이름으로 이어진 것입니다.
❝ EJB의 겨울을 지나, 스프링의 봄이 온다 ❞
스프링은 2003년 6월에 처음 세상에 공개되었고, 오픈소스 프로젝트로서 Apache License 2.0을 따릅니다. 2022년 11월 기준으로는 6.0.0 버전까지 출시되어 있으며, 주요 기능은 이제 Spring Boot를 중심으로 구현되고 있습니다.
2. 왜 스프링이 중요한가?
POJO 기반: 복잡한 컴포넌트 없이 순수한 Java 객체로 개발이 가능.
DI/IoC 컨테이너: 객체의 생성과 의존성 관리를 프레임워크가 자동으로 처리.
모듈화: AOP(Aspect-Oriented Programming)를 통해 핵심 로직과 부가 기능을 깔끔히 분리.
JVM 기반 호환성: Java는 물론 Kotlin 등 다양한 언어와도 호환.
강력한 생태계: Spring MVC, Spring Data, Spring Security, Spring Cloud 등 수많은 확장 가능성.
전자정부 프레임워크 기반: 국내 공공기관 시스템의 표준으로도 사용.
3. 스프링을 제대로 활용하려면?
Spring Boot로 시작하면 빠르고 간단한 설정이 가능
IntelliJ IDEA는 Spring에 최적화된 대표 IDE (JetBrains 공식 지원)
스프링은 복잡했던 Java EE의 시대에 ‘단순함’이라는 가치를 제시하며 등장한 웹 프레임워크입니다. Rod Johnson의 철학에서 출발한 이 프로젝트는 이제 전 세계 수많은 기업과 공공기관이 사용하는 강력한 인프라가 되었습니다. 만약 Java 기반 백엔드를 시작하고 싶다면, Spring은 그 자체로도 가장 강력한 출발점입니다.
PRG(Post-Redirect-Get) 패턴은 웹 개발에서 POST 요청 후 직접 응답하지 않고, 다른 URL로 리다이렉트한 후 GET 요청을 유도하는 방식입니다. 즉, 사용자의 POST 요청 처리 후 바로 페이지를 반환하는 대신, 3XX Redirect 응답으로 GET 요청을 유도하는 구조입니다.
❗ 왜 PRG 패턴이 필요할까?
1. ⚠️ 새로고침으로 인한 중복 요청 방지
PRG를 사용하지 않으면 POST 요청 후 바로 HTML 페이지를 응답할 경우, 사용자가 새로고침(F5) 하면 같은 POST 요청이 서버에 다시 전송됨
예시:
온라인 쇼핑몰에서 결제 후 새로고침 시 → 중복 결제 발생 가능 😨
2. 🧭 URL 공유 및 북마크가 불가능
POST 요청은 URL에 직접 접근할 수 없기 때문에, 북마크나 공유가 불가능
PRG 패턴은 GET 요청으로 연결되므로 URL 공유 및 즐겨찾기 가능
🔄 PRG 패턴 흐름도
[1] 사용자가 Form을 제출 → (POST)
↓
[2] 서버가 처리 후 Redirect 응답 (3xx) → /result
↓
[3] 브라우저가 자동으로 GET 요청 → /result
↓
[4] /result 페이지 렌더링
스프링에서 수동으로 빈을 등록 할때 @Configuration 클래스 안에 @Bean을 사용한다. 왜 그런지 살펴보자.
● @Configuration 안에 @Bean을 사용하는 이유, proxyBeanMethods
- @Bean 어노테이션을 이용한 수동 빈 등록
스프링에선 일반적으로 컴포넌트 스캔을 이용해 자동으로 빈을 등록하는 방법을 이용한다. 하지만 @Bean 어노테이션을 사용해 수동으로 빈을 등록해야 할 때도 있다.
개발자가 직접 제어가 불가능한 라이브러리를 활용할 때
애플리케이션 전 범위적으로 사용되는 클래스를 등록할 때
다형성을 활용하여 여러 구현체를 등록해야 할 때
@Bean을 이용한 수동 빈 메소드는 스프링 빈 안에만 구현되어 있다면 모두 동작한다. 하지만 스프링은 @Bean은 반드시 @Configuration 어노테이션 활용하도록 하는데, 그 이유는 @Configuration에 특별한 부가 기능이 적용되기 때문이다.
● @Configuration 에 적용되는 프록시 패턴
- @Configuration 어노테이션 안에는 @Component 어노테이션이 붙어 있어 @Configuration이 붙어있는 클래스 역시 스프링 빈으로 등록이 된다. 그럼에도 스프링이 @Configuration을 만든 이유는 CGLib으로 프록시 패턴을 적용해 수동으로 등록하는 스프링 빈이 반드시 싱글톤으로 생성됨을 보장하기 위해서다.
public class Resource {}
위 클래스를 @Component를 이용해 자동으로 빈 등록을 한다면 스프링이 해당 크래스의 객체의 생성을 제어하게 되고(제어의 역전, IoC) 하나의 객체만 생성되도록 컨트롤 할 수 있다. 하지만 위의 클래스를 @Bean을 이용해 직접 빈으로 등록해준다고 하면, 우리는 다음과 같이 해당 빈 등록 메소드를 여러 번 호출할 수 있게 된다.
@Configuration
public class MyBeanConfiguration {
@Bean
public Resource resource() {
return new Resource();
}
@Bean
public MyFirstBean myFirstBean() {
return new MyFirstBean(resource());
}
@Bean
public MySecondBean mySecondBean() {
return new MySecondBean(resource());
}
}
실수로 위와 같이 빈을 생성하는 메소드를 여러 번 호출 했다면 불필요하게 여러 개의 빈이 생성이 된다. 스프링은 이러한 문제를 방지하고자 @Configuration이 있는 클래스를 객체로 생성할 때 CGLib을 사용해 프록시 패턴을 적용한다. 그래서 @Bean이 있는 메소드를 여러 번 호출하여도 항상 동일한 객체를 반환하여 싱글톤을 보장한다.
@Configuration
public class MyBeanConfigurationProxy extends MyBeanConfiguration {
private Object source;
@Override
public Resource resource() {
if (resource == null) {
source = super.resource();
}
return source;
}
@Override
public MyFirstBean myFirstBean() {
return super.myFirstBean();
}
@Override
public MySecondBean mySecondBean() {
return super.mySecondBean();
}
}
CGLib은 상속을 통해 프록시를 구현하므로 위와 같이 프록시가 구현 됬다고 이해 할 수 있다. 물론 이렇게 생성이 되는건 아니라 내부 클래스를 사용하는 등의 차이가 있으므로 이해를 돕기 위한 코드로 보면 된다.
● 싱글톤 여부를 제어하기 위한 proxyBeanMethods
대부분 @Bean에 의한 수동 빈 등록을 할 때 싱글톤으로 생성되기를 원한다. 하지만 @Bean 메소드를 호출할 때 의도적으로 매번 다른 객체가 생성되기를 바랄 수 있다. 그럴 경우엔 @Configuration 어노테이션이 갖고 있는 proxyBeanMethods를 false로 주면 된다.
@Configuration(proxyBeanMethods = false)
public class MyBeanConfigurationProxy extends MyBeanConfiguration {
private Object source;
@Override
public Resource resource() {
if (resource == null) {
source = super.resource();
}
return source;
}
@Override
public MyFirstBean myFirstBean() {
return super.myFirstBean();
}
@Override
public MySecondBean mySecondBean() {
return super.mySecondBean();
}
}
하지만 프로젝트의 규모가 커짐에 따라 사용하는 요소들은 xml에 등록하는 것이 상당히 번거로워 져서 어노테이션 기반의 Bean 등록 방법이 탄생하게 되었다. Bean을 등록하기 위한 @Bean, @Component, @Configuration 어노테이션에 대하여 알아보자.
● Spring Bean이란?
- 스프링에서 스프링의 DI Container에 의해 관리되는 POJO(Plain Old Java Object)를 Bean이라고 부른다. 이러한 Bean들이 스프링을 구성하는 핵심 요소이다.
POJO(Plain Old Java Object)로써 스프링 애플리케이션을 구성하는 핵심 객체이다.
스프링 IoC 컨테이너(또는 DI 컨테이너)에 의해 생성 및 관리된다.
class, id, scope, constructor-arg 등 주요 속성으로 지닌다.
● 스프링 빈 구성요소
- class : Bean으로 등록할 Java 클래스
- id : Bean의 고유 식별자
- scope : Bean을 생성하기 위한 방법(singleton, prototype 등)
- constructor-arg : Bean 생성 시 생성자에 전달할 파라미터
- property : Bean 생성 시 setter에 전달할 인수
● Spring Bean 등록 방법(@Bean, @Configuration, @Component)
다음과 같은 클래스를 스프링 컨테이너에 등록 해보자.
public class Resource {}
이 클래스를 빈으로 등록하기 위해선 명시적으로 설정 클래스에서 @Bean 어노테이션을 사용해 수동으로 스프링 컨테이너에 빈을 등록하는 방법이있다. @Configuration 어노테이션을 클래스에 붙여주면 된다. @Bean을 사용해 수동으로 빈을 등록할 때에는 메소드 이름으로 빈 이름이 결정된다.
@Configuration
public class ResourceConfig {
@Bean
public Resource resource() {
return new Resource();
}
}
스프링 컨테이너는 @Configuration이 붙어있는 클래스를 자동으로 등록해두고, 해당 클래스를 파싱해서 @Bean이 있는 메소드를 찾아 빈을 생성한다. 다른 임의의 클래스를 만들어 @Bean을 붙인다고 되는것이 아니고, 반드시 @Bean을 사용하는 클래스에는 @Configuration 어노테이션을 활용하여 해당 클래스에서 Bean을 등록하고자 함을 명시해 줘야 한다.
수동으로 빈을 직접 등록해야 하는 상황이라면 다음과 같은 기준으로 한다.
개발자가 직접 제어가 불가능한 라이브러리를 활용할 때
애플리케이션 전 범위적으로 사용되는 클래스를 등록할 때
다형성을 활용하여 여러 구현체를 등록해야 할 때
만약 우리가 객체를 JSON메시지로 변경하기 위해 Gson과 같은 외부 라이브러리를 사용한다고 하자. 그러면 해당 클래스를 싱글톤 빈으로 등록해 줘야 1개의 객체만 생성하여 여러 클래스가 공유함으로 메모리 상의 이점을 얻을 수 있다. 그런데 해당 클래스는 우리가 만든게 아니라 가져다 사용하는 클래스 일 뿐 불가피하게 @Bean으로 등록 해줘야만 한다.
@Bean을 사용하는 이점은 한 눈에 파악하여 유지보수하기가 쉽기 때문이다. 예를 들자면 구현체를 빈으로 등록 할때 어떠한 구현체들이 빈으로 등록됬는지 파악하기 위해서 @Configuration 클래스만 찾아보면 되기 때문이다.
● Component
수동으로 직접 빈을 등록 하는 작업은 빈으로 등록하는 클래스가 많아 질수록 상당한 시간을 차지하고 생산력 저하로 이루어질 것이다. 이때 스프링에서 특정 어노테이션이 있는 클래스를 찾아 빈으로 등록해 주는 컴포넌트 스캔 기능이 있다.
스프링은 컴포넌트 스캔(Component Scan)을 이용해 @Component 어노테이션이 있는 클래스들을 찾아 빈으로 등록을 한다. 우리가 직접 개발한 클래스를 빈으로 편리하게 등록 해야만 하는 경우에는 @Component 어노테이션을 활요하면 된다.
public class Resource {}
@Component를 갖는 어노테이션으로는 @Controller, @Service, @Repository 이 있으며 @Configuration도 @Component를 갖고 있다.
스프링은 기본적으로 컴포넌트 스캔을 이용한 자동 빈 등록 방식을 권장한다. 또한 직접 개발한 클래스는 @Component를 통해 해당 클래스를 빈으로 등록함을 노출하는 것이 좋다. 이유는 해당 클래스에 있는 @Component만 보면 해당 빈이 등록이 되도록 설정 되었는지를 파악 할수 있기 때문이다. 위와 같이 수동으로 해야하는 경우를 제외한 대부분의 경우 자동 등록 방식을 사용하자.
그리고 @Component를 이용하면 Main 또는 App 클래스에서 @ComponentScan으로 컴포넌트 스캔 범위를 지정해 줘야한다. 그러나 SpringBoot를 이용한다면 @SpringBootConfiguration에 기본적으로 포함되어 있어 별도의 설정이 필요 없다.
● 간단 정리
- @Bean, @Configuration
수동으로 스프링 컨테이너에 빈을 동록하는 방법
개발자가 직접 제어가 불가능한 라이브러리를 빈으로 등록할 때 불가피하게 사용
유지보수성을 높이기 위해 애플리케이션 전 범위적으로 사용되는 클래스나 다형성을 활용하여 여러 구현체를 빈으로 등록 할 때 사용
1개 이상의 @Bean을 제공하는 클래스의 경우 반드시 @Configuration을 명시해 줘야 싱글톤이 보장된다.
- @Component
자동으로 스프링 컨테이너에 빈을 등록하는 방법
스프링의 컴포넌트 스캔 기능이 @Component 어노테이션이 있는 클래스를 자동으로 찾아 빈으로 등록한다.
대부분의 경우 @Component를 이용한 자동 등록 방식을 사용하는 것이 좋다.
@Component 하위 어노테이션으로 @Configuration, @Controller, @Service, @Repository 등이 있다.
