[Spring Boot] 3. 스프링(Spring)과 스프링부트(Spring Boot)

 

 

1. 스프링과 스프링부트

1.2. 스프링(Spring)의 등장

- 엔터프라이즈 애플리케이션(Enterprise Application) : 대규모의 복잡한 데이터를 관리하는 애플리케이션

- 소프트웨어 분야 발전하며 엔터프라이즈 애플리케이션은 점점 복잡해짐

ex. 은행 시스템

몇 천만 사람이 한꺼번에 잔고 조회, 입금/출금 요청, 새로운 통장 개설...

->많은 사용자의 요청 동시에 처리해야함

=>서버 성능, 안정성, 보안 매우 중요

 

이런것들 신경쓰면서 사이트 기능 == 비즈니스 로직까지 개발하기 어려움!

=> 2003.06. 스프링 프레임워크(Spring Framework) 등장

- 스프링 프레임워크 (Spring Framework) : 서버성능, 안정성, 보안을 매우 높은 수준으로 제공하는 도구

->개발자들은 기능 개발에 집중 가능!

 

1.2. 스프링(Spring)을 더 쉽게 만들어주는 스프링 부트(Spring Boot)

스프링 단점 : 매우 복잡함

-> 스프링 단점 보완 위해 스프링 부트 출시(2013.04. -> 0.5.0.M6 버전 첫 공개)

- 스프링 부트(Spring Boot) : 스프링 프레임워크를 더 쉽고 빠르게 이용할 수 있도록 만들어주는 도구

빠르게 스프링 프로젝트 설정 가능

- 의존성 세트 == 스타터(Starter) 사용 통해 간편하게 의존성 사용하거나 관리 가능

- 개발자가 조금 더 비즈니스 로직 개발에만 집중할 수 있도록 만들어주는 도구

 

스프링과 비교한 스프링 부트(Spring Boot)의 주요 특징

- 톰캣(TomCat), 제티, 언더토우 같은 웹 애플리케이션 서버 (web application server, WAS)가 내장돼있음 -> 따로 설치 안 해도 독립적 실행 가능

- 빌드 구성을 단순화하는 스프링 부트 스타터 제공

- XML 설정을 하지 않고 자바 코드로 모두 작성 가능

- JAR 이용해서 자바 옵션만으로도 배포 가능

- 애플리케이션의 모니터링 및 관리 도구인 스프링 엑츄에이터(spring actuator) 제공

※ 스프링부트는 스프링에 속한 도구

 

1.3. 스프링(Spring)  vs 스프링 부트(Spring Boot) 차이점

1) 구성 차이

- 스프링 : 애플리케이션 개발에 필요한 환경을 수동으루 구성하고 정의 해야함

- 스프링 부트 : 스프링 코어, 스프링 MVC의 모든 기능을 자동으로 로드

=> 개발 환경을 구성할 필요가 없음

 

2) 내장 WAS의 유무

- 스프링  애플리케이션 : 일반적으로 톰캣(Tomcat)과 같은 *WAS(Web Application Server)에서 배포됨

   * WAS (Web Application Server) : 웹 애플리케이션을 실행하기 위한 장치

- 스프링 부트 : WAS를 자체적으로 가지고 있음

=> jar 파일만 만들면 별도로 WAS 를 설정하지 않아도 애플리케이션을 실행할 수 있음

 

※ 스프링 부트의 내장 WAS  : 톰캣( Tomcat), 제티(Jetty), 언더토우(undertow)

=> 상황에 필요한 WAS 선택할 수 있음

 

3) 목적 

- 스프링 : 엔터프라이즈 애플리케이션을 더 쉽게 만들기

- 스프링 부트 : 스프링의 개발을 더 빠르고 쉽게 하기

 

4) 설정 파일

- 스프링 : 개발자가 수동으로 구성

- 스프링 부트 : 자동 구성

 

5) XML

- 스프링 : 일부 파일은 XML로 직접 생성하고 관리

- 스프링 부트 : XML 파일 사용하지 않음

 

6) 인메모리 데이터베이스 지원

- 스프링 : 지원X

- 스프링 부트 : 인메모리 데이터베이스 자동 설정 지원

 

7) 서버 

- 스프링 :  프로젝트를 띄우는 서버(ex. 톰캣, 제티)를 별도로 수동 설정

- 스프링 부트 : 내장형 서벌르 제공해 별도의 설정이 필요 X

 

 

2. 스프링 개념

스프링 프레임워크가 돌아가는 원리 이해

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

- 자바(Java)코드 작성하여 객체 생성 시 -> 객체가 필요한 곳에서 직접 생성

 

[예제1] java의 객체 생성 - 클래스A에서 클래스 B 객체 생성

public class A {
	b = new B();
}

: 클래스 A에서 new 키워드로 클래스 B의 객체 생성

 

제어의 역전 : 다른 객체를 직접 생성하거나 제어 X => 외부에서 관리하는 객체를 가져와 사용하는 것 O

- 기존 자바 코드 : 클래스 A 에서 B객체를 쓰고 싶은 경우 직접 생성함

 

[예제2] 예제1에 제어의 역전(IoC) 개념 적용 - 스프링 컨테이너가 객체를 관리하는 방식

public class A {
	private B b;
}

: 코드에서 객체 생성 X (new 라는 키워드가 쓰이지 않는다!) => 어디선가 받아온 객체를 b에 할당

 

(Java에서 데이터타입==객체==클래스

-> B라고 하는 데이터타입은 자바의 기본 데이터타입이 아님

-> 누군가가 만든 데이터타입 ! 즉 객체, 클래스!

어디선가 만든 객체인 B! 라는 데이터타입을 가진 b라는 변수를 만든 것)

 

2.2. 의존성주입(DI, Dependency Injection)

- 스프링에서는 객체들을 관리하기 위해 제어의 역전 사용

- 의존성주입(DI, Dependency Injection) : 제어의 역전 구현하기 위해 사용하는 방법

=> 어떤 클래스가 다른 클래스에 의존한다는 뜻

 

[예제3] IoC/DI를 기초로 하는 스프링 코드 - 객체를 주입받는 모습

public class A {
	// A에서 B를 주입받음
    @Autowired
    B b;
}

- @Autowired : 스프링 컨테이너(Spring Container)에 있는 빈(Bean)이라는 것을 주입하는 역할을 하는 애너테이션

- 빈(Bean) == 스프링 컨테이너에서 관리하는 객체

- [예제2]에서는 개발자가 직접 B 객체를 생성 (private B b;)

- [예제3]은 어딘가에서 B b; 라고 선언했을 뿐, 직접 객체 생성X (B b) == 객체를 주입받고 있음

-> 이 코드 작성 시  프로그램 잘 작동하는 이유?

=> 스프링 컨테이너에서 객체를 주입했기 때문! == 스프링 컨테이너가 B 객체를 만들어서 클래스 A에 준 것

- 스프링의 경우 : 클래스 A 에서 B 객체를 쓰고 싶은 경우

=> 객체를 직접 생성x

=>스프링 컨테이너에서 객체를 주입 받아 사용

=> IoC/DI 개념은 스프링의 핵심 개념!!

 

2.3. 스프링 컨테이너(Spring Container)

- 스프링은 스프링 컨테이너 제공

- 스프링 컨테이너(Spring Container) : 빈(Bean)을 생성하고 관리== 빈이 생성되고 소멸되기까지의 생명주기를 스프링 컨테이너가 관리

- @Autowired 같은 애너테이션 사용해 빈을 주입받을 수 있게 DI를 지원하기도 함

 

 

2.4. 빈(Bean)

- 빈(Bean) : 스프링 컨테이너가 생성하고 관리하는 객체 == 스프링에서 제공해주는 객체

- ex.  [예제4]의 B가 빈

- 스프링은 빈을 스프링 컨테이너에 등록하기 위해 XML 파일 설정, 애너테이션 추가 등의 방법 제공

=> 빈 등록 방법 여러가지 존재!

 

[예제5] 클래스를 빈으로 등록하는 방법

@Component // 클래스 MyBean 빈으로 등록
public class MyBean {
}

ex. MyBean 클래스에 @Component 애너테이션 붙이면?

 

=> MyBean 클래스가 빈으로 등록됨

->이후 스프링 컨테이너에서 이 클래스를 관리

 

빈의 이름 == 클래스 이름의 첫 글자를 소문자로 바꿔 관리

=> MyBean 클래스의 빈 이름 == myBean

 

2.5. 관점 지향 프로그래밍(AOP, Aspect Oriented Programming)

- 프로그램에 대한 관심을 핵심 관점, 부가 관점으로 나누어서 관심 기준으로 모듈화하는 것

 

ex. 계좌이체, 고객 관리하는 프로그램

1) 로깅로직 == 지금까지 벌어진 일을 기록하기 위한 로직

2) 여러 데이터를 관리하기 위한 데이터베이스 연결로직 

포함

- 핵심관점 : 계좌이체 , 고객 관리 로직

- 부가 관점 : 로깅, 데이터베이스 연결로직 => 계좌이체, 고객 관리에 필요

=>AOP 관점 적용 : 

부가 관점에 해당하는 로직을 모듈화 해서 그림처럼 개발 가능하게함

==  부가 관점 코드를 핵심관점 코드에서 분리할 수 있게 해줌

=> 프로그래머는 핵심 관점 코드에만 집중가능 + 프로그램의 변경과 확장에도 유연하게 대응 가능

 

 

 

2.6. 이식 가능한 서비스 추상화 (PSA, Portable Service Abstraction)

: 스프링에서 제공하는 다양한 기술들을 추상화->개발자가 쉽게 사용하는 인터페이스

- 대표적인 PSA 예

ex. 클라이언트의 매핑과 클래스

ex. 메서드의 매핑을 위한 애너테이션\

 

ex. 스프링에서 데이터베이스에 접근하기 위한 기술 : JPA( Java Persistence API), MyBatis, JDBC...

=>어떤 기술을 사용하든 일관된 방식으로 데이터베이스에 접근하도록 인터페이스 지원

 

ex. WAS ( web application server )

=> 코드는 그대로 두고 WAS를 톰캣이 아닌 언더토우, 네티와 같은 다른 곳에서 실행해도 기존 코드를 그대로 사용 가능

 

 

 

<한줄 요약>

- 제어의 역전(IoC, Inversion of Control) : 객체의 생성과 관리를 개발자가 하는것이 아니라 프레임워크가 대신하는 것

- 의존성주입(DI, Dependency Injection) : 외부에서 객체를 주입받아 사용하는 것

- 관점 지향 프로그래밍(AOP, Aspect Oriented Programming): 프로그래밍을 할 때 핵심 관점과 부가 관점을 나누어서 개발하는 것

- 이식 가능한 서비스 추상화 (PSA, Portable Service Abstraction) : 어느 기술을 사용하던 일관된 방식으로 처리하도록 하는 것

=> 스프링 프레임워크는 IoC/DI를 통해 객체 간의 의존 관계를 설정하고, AOP를 통해 핵심 관점과 부가 로직을 분리해 개발하며, PSA를 통해 추상화된 다양한 서비스들을 일관된 방식으로 사용하도록 함!