2023-03-04

면접 스터디를 시작하고 매주 받는 과제들로부터 조사한 내용들의 정리

 

 

 

Spring vs Spring boot 버전관리 자동화 내장톰캣에 대해서..

스프링은 사용자가 어플리케이션을 개발하는데에 편리한 기능들을 제공해주는 도구입니다.
스프링 부트는 이러한 스프링을 기반으로 동일한 기능을 제공하되 내장 서버와 의존성 자동 관리 등을 지원해 사용자가 좀 더 개발에 집중하게 해주는 어플리케이션 제작 도구 입니다.

• 소소한 재미로 보는 Spring 이름의 유래
  ’개발자들의 겨울은 끝났다. 이 프레임워크로 인해서 봄이왔다’ 라고 합니다 ㅋㅋㅋ..
  스프링 이전에 가장 대표적으로 사용했던 EJB 프레임워크가 상대적으로 불친절하고 기술의 복잡도가 증가해 성능이 느렸던 것을 다 해결해버린 프레임워크의 등장으로 인해서 라고 합니다.

 

시작전에 살펴보는 스프링부트 만의 장점 요약

1. 단독 실행(Stand-alone)
   가능한 스프링 애플리케이션을 생성합니다.
2. 내장 서버(Web-container) 를 포함하고 있습니다.
3. 의존성 관리가 편리합니다.
   빌드 구성을 단순화하는 starter 제공하여 인코딩,플러그인,버전 등 의존성을 관리합니다.
4. Auto Configuration 을 지원합니다.
   xml이나 java 설정이 필요 없이 의존성과 환경 변수만 설정하면 됩니다.

 

스프링부트의 장점들에 대한 상세 정리

 

단독 실행 보장

WAR 과 JAR 둘 다 JAVA 의 jar 옵션을 이용해 생성된 압축 파일로,
어플리케이션을 쉽게 배포하고 동작하게 해주는 관련 파일(리서스, 속성 파일 등) 을 패키징한 파일입니다.

WAR 파일은 Java EE 서버에서 실행되며 웹 컨테이너에 배포되어 웹 어플리케이션을 실행합니다.

즉, 주로 웹 어플리케이션을 배포 및 실행할 때 사용합니다.

반면, JAR 파일은 JVM 에서 직접 실행되며 JAVA 어플리케이션을 실행할 때 사용합니다. 즉, JAVA 어플리케이션을 배포하고 실행할 때 사용합니다.

결국 둘 모두 패키징 방식에서 차이가 있을 뿐 개발자의 판단에 따라 다릅니다.

 

• WAR 와 JAR 에 대해서
  • WAR (Web Application Archive)
    • JAVA 어플리케이션이 동작할 수 있도록 자바 프로젝트를 압축한 파일입니다.
    • Class (JAVA 리소스, 속성 파일), 라이브러리 파일을 포함하고 있습니다.
    • JRE 만 있어도 실행이 가능합니다.
  • JAR (Java Archive)
    • Servlet / JSP 컨테이너에 배치할 수 있는 웹 어플리케이션 압축파일 입니다.
    • 웹 관련 자원을 포함합니다. (JSP, Servlet, JAR, CLass, XML, HTML, Javascript)
    • 별도의 웹서버(WEB) 또는 웹 컨테이너(WAS) 를 필요로 합니다.
    • 즉, JAR 파일의 일종으로 웹 어플리케이션 전체를 패키징 하기 위한 JAR 파일입니다.

 

 

내장 서버 포함

스프링과 다르게 Tomcat 서버(WAS) 를 기본적으로 내장하고 있기 때문에, 서버에 관한 설정이 별도로 필요치 않습니다. 덕분에, 어플리케이션을 빌드, 실행하는 것만으로 웹 어플리케이션의 서비스가 가능합니다.

물론 외장 Tomcat 으로도 가능하지만, 빌드하고 jar 파일을 java 명령어로 실행만 하면 끝인것에 비해서 스프링으로 구축할 시 더 까다롭습니다.

 

외장 Tomcat 에서의 구축 방법

Tomcat 설치 → Tomcat 설정 파일 구성 → Tomcat Webapp 디렉토리에 빌드 된 스프링 어플리케이션 war 파일을 같이 구성하기 → Tomcat 실행

 

간단히 정리한 스프링에서의 과정을 비교해보면 상당히 불편한 것을 알 수 있습니다.

또한, 위의 과정을 수행하기 위해서 별도로 Tomcat 서버를 설치를 해야만 설정 및 실행이 가능합니다.

결과적으로 불친절한 과정들을 생략함으로 인해 개발자가 어플리케이션단의 코드 작성에 더 집중할 수 있게 해줍니다.

 

• 내장 Tomcat 과 외장 Tomcat 의 차이
  외장 톰캣은 Virtual Host 기능을 사용할 수 있습니다.
  이는, 도메인 host에 따라 각각의 다른 루트 컨텍스트를 가지게 해서 하나의 웹 어플리케이션 배포만으로 여러 어플리케이션을 운영하는 것 처럼 할 수 있습니다. 이 기능을 사용하기 위해서는 외장톰캣의 구성요소인 server.xml 을 수정해야 합니다.

<Host name="a.thxwelchs.com"  appBase="/webapps/weba" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false">
</Host>

<Host name="b.thxwelchs.com"  appBase="/webapps/webb" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false">
</Host>

위처럼 구성하면,

a.thxwelchs.com 에 접속시 weba 루트 컨텍스트를 기준으로 작성된 뷰 메인페이지가 보이고

b.thxwelchs.com 에 접속시 webb 루트 컨텍스트를 기준으로 작성된 뷰 메인페이지가 보일 것입니다.

물론 내장 톰캣으로도 이는 가능하지만, 방법이 상당히 까다롭다고 합니다.

 

 

Dependency 버전 자동화

이전의 스프링 프레임워크 에서는 각각의 Dependency 들의 호환되는 버전을 일일이 맞추어 주어야 했습니다.

하지만, 스프링부트 에서는 spring-boot-starter 와 spring-boot-starter-parent 으로 인해서 위에서 말한 작업을 상당히 줄여줍니다.

 

• spring-boot-starter
  사전에 미리 정의한 의존성 조합을 제공합니다.
  프로젝트에 설정해야 하는 다수의 의존성들을 starter 에서 미리 가지고 있기 때문에 이 의존성 하나만 추가해도 프로젝트를 시작하거나 새로운 기능의 추가가 가능합니다.
  예로, A 라는 의존성을 추가하고 싶은데 이를 위해선 충돌 검사 및 A 를 추가하기 위해서 필요한 다른 의존성들도 직접 추가해야 하는 경우가 있다고 하면, 이를 spring-boot-starter-A 라는 의존성의 추가만으로 앞서 말한 모든 과정을 생략할 수 있습니다.
• spring-boot-starter-parent
  다양한 의존성들을 사용함에 따라 충돌이 발생할 수 있는 상황을 예방할 수 있습니다.
  이는, parent 에서 조합간 충돌 문제가 없는 검증된 버전정보 조합을 제공해주기 때문입니다.
  그래서 우리는 spring-boot-starter-parent 버전만 설쟁해줘도 수많은 라이브러리들 간의 버전 충돌 문제를 피할 수 있습니다.

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.1.7.RELEASE</version>
</parent>

위의 코드가 바로 spring-boot-starter-parent 를 적용한 모습입니다.

그리고 아래에서 이전에 어떻게 입력하고 설정했었는지에 대해서 알아보겠습니다.

---

 

<dependency>
	<groupId>org.thymeleaf</groupId>
	<artifactId>thymeleaf-spring5</artifactId>
	<version>3.0.11.RELEASE</version>
</dependency>

위와 같이 직접 일일이 버전 정보를 입력해야 했지만 현재는

<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-thymeleaf</artifactId>
</dependency>

이렇게 버전 정보를 생략해도 Spring Boot Starter 에서 알아서 처리해줍니다.

---

 

심지어 위의 방식은 Maven 방식인데 이를 Gradle 방식으로 변경하면 더욱 간단해집니다.

implementation 'org.springframework.boot:spring-boot-starter-thymeleaf'

위처럼 훨씬 더 간단하게 라이브러리를 가져와서 적용이 가능합니다.

이렇게 보면 관리에 있어서도 상당히 편리하지만 Gradle 방식을 적용하면 가독성도 올라가는 것을 알 수 있습니다.

 

하지만 Gradle 로 넘어오면서 spring-boot-starter-parent 를 설정하는 부분이 없어졌는데 이 부분은 조금 다르게 작동하는 것 같습니다.

Gradle 의 의존성을 설정하는 build.gradle 에 들어가보면 최상단에 아래와 같은 코드를 볼 수 있습니다.

plugins {
    id 'java'
    id 'org.springframework.boot' version '2.7.7'
    id 'io.spring.dependency-management' version '1.0.15.RELEASE'
}

 

해당 플러그인을 통해서 spring-boot-starter-parent 를 import 한다고 하는데, 이는 Gradle 로 프로젝트를 생성하면 자동으로 아래의 플러그인이 적용됩니다.

 

이는 Maven 을 사용할 때 의존성 관리를 해주던 것과 유사한 경험을 할 수 있도록 제공해준다고 합니다.

 

 

Auto Configuration 지원

Auto Configuration, 말 그대로 자동 환경 설정 입니다.

스프링 부트에서 새롭게 추가하는 라이브러리(jar) 는 자동설정 의존성에 따라 설정이 자동으로 적용됩니다.

 

@EnableAtuoConfiguration 또는 @SpringBootApplication 둘 중 하나만 사용하면 됩니다. 즉, 정말 간단하게 해결이 가능합니다.

@EnableAutoConfiguration은 Spring boot의 핵심으로써,미리 정의되어 있는 Bean들을 가져와서 등록해줍니다.
미리 정의되어 있는 Bean들은 spring-boot-autoconfigure > META-INF > spring.factories에 위치하여 있습니다.

게다기 우리가 사용할 때는 이를 설정할 필요도없이 새 프로젝트를 생성하는 단계에서부터 이미 만들어져서 적용이 됩니다. 그 예를 아래 사진으로 보여드리면…

 

 

어플리케이션 실행 부의 @SpringBootApplication 어노테이션이 이미 적용되어 있는데,

이 어노테이션의 안에는 @EnableAtuoConfiguration 이 존재합니다. 결국 어플리케이션이 만들어진 순간부터 적용이 되어있다는 의미가 됩니다.

 

@EnalbeAutoConfiguration 이 어노테이션이 자동으로 설정해주는 역할을 합니다.

위에서 자동으로 이루어지는 과정은 @ComponentSacn 을 통해 Bean 을 등록하고 이후에 @EnalbeAutoConfiguration 에서 추가적인 Bean 들을 읽어서 추가하게 됩니다.

 

@EnalbeAutoConfiguration 에서 하는 일을 조금만 더 설명 하자면, 스프링부트의 meta 파일을 읽어서 미리 정의 되어있는 **자바 설정 파일(@Configuration)**들을 빈으로 등록합니다.