인프런/스프링 부트 - 핵심 원리와 활용

1) 스프링부트 소개, 톰캣 설정

backend dev 2024. 10. 31.

스프링 부트

 

부트? -> BOOT, 부팅

 

최소한의 인간 개입으로 시작하고 완전히 작동하는 것을 의미

어떤 일을 시작하기 위해 필요한 모든 준비를 마친다는 의미

 

시작을 위한 복잡한 설정 과정은 스프링 부트가 해결

개발자는 새로운 스프링 애플리케이션을 쉽고 빠르게 시작

 

스프링을 편리하게 사용할 수 있도록 지원, 최근에는 기본으로 사용

단독으로 실행할 수 있는 스프링 애플리케이션을 쉽게 생성

관례에 의한 간결한 설정

 

 

핵심 기능 5가지

 

WAS: Tomcat 같은 웹 서버를 내장해서 별도의 웹 서버를 설치하지 않아도 됨

 

라이브러리 관리

손쉬운 빌드 구성을 위한 스타터 종속성 제공

스프링과 외부 라이브러리의 버전을 자동으로 관리

 

자동 구성: 프로젝트 시작에 필요한 스프링과 외부 라이브러리의 빈을 자동 등록

 

외부 설정: 환경에 따라 달라져야 하는 외부 설정 공통화

 

프로덕션 준비: 모니터링을 위한 메트릭, 상태 확인 기능 제공

 

 

스프링 부트는 스프링 프레임워크를 편리하게 사용할 수 있도록 도와주는 도구일뿐이다.

그래서 스프링부트를 사용한다는것은 스프링 프레임워크를 사용한다는 것이다.

 

 

스프링 프레임워크와 스프링 부트

스프링 부트는 스프링 프레임워크를 쉽게 사용할 수 있게 도와주는 도구일 뿐이다!

 

본질은 스프링 프레임워크

 

• 하지만 스프링 부트가 제공하는 편의 기능이 너무 막강해서 스프링 부트 사용은 필수

 

스프링 부트를 배워야 하는 이유

스프링 부트는 편리하지만, 너무 많은 것을 자동화

 

최소한 스프링 부트가 어떤 원리로 작동하는지 알아두어야 함

 

그래야 문제가 발생했을 때 해결 가능

 

스프링 부트의 원리를 이해하면 문제점을 쉽게 파악

 

• 스프링 부트는 수 많은 편의 기능들을 제공

 

• 대부분의 개발자가 비슷하게 고민하는 기능을 스프링 부트는 이미 만들어서 제공

 

• 예를 들어서 외부 설정, 액츄에이터를 통한 모니터링 관리 기능

 

• 개발 시간 단축

 

 

스프링 단어?

스프링이라는 단어는 문맥에 따라 다르게 사용된다.

 

스프링 DI 컨테이너 기술

or

스프링 프레임워크

or

스프링 부트, 스프링 프레임워크 등을 모두 포함한 스프링 생태계


 

웹 서버와 서블릿 컨테이너

 

웹 서버와 스프링 부트 소개

 

외장 서버 VS 내장 서버

 

 

 

외장서버는 전통적인 방식으로 WAS가 별도로 있고 WAS안에 어플리케이션 코드를 넣어서 실행하는 방식

 

내장서버는 자바를 빌드하면 JAR파일이 되는데 그 안에는 다양한 라이브러리가 있는데

그 라이브러리중 웹 서버 라이브러리가 포함되어 있는 방식이다.

그래서 이 JAR를 실행하면 그냥 바로 서버가 실행되는 방식이다. 

 

 

전통적인 방식

 

 

과거에 자바로 웹 애플리케이션을 개발할 때는 먼저 서버에 톰캣 같은 WAS(웹 애플리케이션 서버)를 설치했다.

 

그리고 WAS에서 동작하도록 서블릿 스펙에 맞추어 코드를 작성하고 WAR 형식으로 빌드해서 war 파일을 만들었다.

 

이렇게 만들어진 war 파일을 WAS에 전달해서 배포하는 방식으로 전체 개발 주기가 동작했다.

 

이런 방식은 WAS 기반 위에서 개발하고 실행해야 한다.

 

IDE 같은 개발 환경에서도 WAS와 연동해서 실행되도록 복잡한 추가 설정이 필요하다.

 

 

 

최근 방식

최근에는 스프링 부트가 내장 톰캣을 포함하고 있다.

 

애플리케이션 코드 안에 톰캣 같은 WAS가 라이브러리로 내장되어 있다는 뜻이다.

 

개발자는 코드를 작성하고 JAR로 빌드한 다음에 해당 JAR를 원하는 위치에서 실행하기만 하면 WAS도 함께 실행된다.

 

쉽게 이야기해서 개발자는 main() 메서드만 실행하면 되고,

WAS 설치나 IDE 같은 개발 환경에서 WAS와 연동하는 복잡한 일은 수행하지 않아도 된다.

 

 

 

톰캣 설치

스프링 3.0을 사용하는데 자바 17이 최소 요구 버전

 

톰캣 다운로드 https://tomcat.apache.org/download-10.cgi

 

Download 메뉴에서 Apache Tomcat 10 버전의 톰캣 다운로드

 

Core에 있는 zip 을 선택 다운로드 후 압축 풀기

 

다운로드 링크: https://dlcdn.apache.org/tomcat/tomcat-10/v10.1.17/bin/apachetomcat-10.1.17.zip

 

 

 

톰캣 실행 설정

 

 

MAC, 리눅스 사용자

 

톰캣폴더/bin 폴더로 이동

권한 주기: chmod 755 *

실행: ./startup.sh

종료: ./shutdown.sh

 

더보기

 

MAC, 리눅스 사용자는 권한을 주지 않으면 permission denied 라는 오류가 발생할 수 있다.

 

윈도우 사용자

 

톰캣폴더/bin 폴더로 이동

실행: startup.bat

종료: shutdown.bat

 

 

 

실행 확인

 

톰캣을 실행한 상태로 다음 URL에 접근하면 톰캣 서버가 실행된 화면을 확인할 수 있다.

http://localhost:8080

 

더보기

톰캣의 실행 로그는 톰캣폴더/logs/catalina.out 파일로 확인할 수 있다.

 

톰캣을 실행하고 localhost:8080 url에 접속해보면 다음과 같은 화면을 확인할 수 있다.

 

 

 

 

프로젝트 설정

TestServlet

전체 설정이 잘 동작하는지 확인하기 위해 간단한 서블릿이다.

웹 서버를 통해 이 서블릿이 실행되어야 한다.

@WebServlet(urlPatterns = "/test") // url 매핑
public class TestServlet extends HttpServlet {

    @Override
    protected void service(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        System.out.println("TestServlet.service");
        resp.getWriter().println("Test");

    }

}

/test 로 요청이 오면 이 서블릿이 실행된다. TestServlet.service 를 로그에 출력한다.

 

test 를 응답한다. 웹 브라우저로 요청하면 이 서블릿이 실행되고 화면에 test 가 출력되어야 한다.

 

이 서블릿을 실행하려면 톰캣 같은 웹 애플리케이션 서버(WAS)에 이 코드를 배포해야 한다.

 

index.html

webapp 폴더아래 index.html -> 웹 서버가 정적 리소스를 잘 전달하는지 확인하기 위한 HTML파일

<html>
<body>
indext html
</body>
</html>

 

하나의 서블릿, 하나의 html 파일을 생성해서 간단하게 테스트를 먼저해보자.

 

만든 코드를 배포하려면 해당 코드를 WAR로 빌드한다음 WAS에 배포하면된다.

 

더보기

두 개의 service() 메소드 중에서 protected를 써야하는 이유

// 1. Public service() 메소드
public void service(ServletRequest req, ServletResponse res) {
    // HTTP 타입으로 캐스팅
    HttpServletRequest request = (HttpServletRequest) req;
    HttpServletResponse response = (HttpServletResponse) res;
    
    // Protected service() 호출
    service(request, response);  // protected 메소드 호출
}

// 2. Protected service() 메소드
protected void service(HttpServletRequest req, HttpServletResponse resp) {
    // 실제 HTTP 메소드(GET, POST 등)에 따른 처리
    String method = req.getMethod();
    if (method.equals("GET")) {
        doGet(req, resp);
    } else if (method.equals("POST")) {
        doPost(req, resp);
    }
    // ...
}
  • public service()는 사실상 중간 다리 역할만 하고, 실제 요청 처리는 protected service()에서 일어납니다
  • protected service()를 오버라이드하면 HTTP 메소드(GET, POST 등)에 대한 처리 로직을 직접 제어할 수 있습니다
  • public service()를 오버라이드하면 HTTP 처리의 기본 흐름을 깨트릴 수 있어 위험합니다

쉽게 말해서:

  • protected service(): "실제 일하는 메소드"를 오버라이드
  • public service(): "중간 관리자 메소드"는 건드리지 않는 것이 좋음

따라서 실제 HTTP 요청 처리를 위해서는 protected service()를 오버라이드 하는 것이 올바른 방법입니다.

 

WAR 빌드와 배포

 

 우리가 만든 코드를 빌드하고 WAS에 배포해보자.

 

 

프로젝트 빌드 

프로젝트 폴더로 이동

프로젝트 빌드
[MAC]: ./gradlew build
[윈도우 OS]: gradlew build

WAR 파일 생성 확인 -> build/libs/server-0.0.1-SNAPSHOT.war

 

 

 

war로 빌드 되는 이유는

build.gradle을 보면

plugins {
    id 'java'
    id 'war' // 빌드방식
}

group = 'hello'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '17'

repositories {
    mavenCentral()
}

dependencies {
    //서블릿
    implementation 'jakarta.servlet:jakarta.servlet-api:6.0.0'
}

tasks.named('test') {
    useJUnitPlatform()
}

 

war 플러그인이 사용된 것을 확인할 수 있다. 

이 플러그인이 war 파일을 만들어준다.

 

WAR 압축 풀기

 

우리가 빌드한 war 파일의 압축을 풀어서 내용물을 확인해보자.

 

build/libs 폴더로 이동하자.

 

다음 명령어를 사용해서 압축을 풀자

jar -xvf server-0.0.1-SNAPSHOT.war

 

WAR를 푼 결과

 

WEB-INF
	- classes
		- hello/servlet/TestServlet.class
	- lib
		- jakarta.servlet-api-6.0.0.jar
index.html

 

WAR를 푼 결과를 보면 WEB-INF , classes , lib 같은 특별한 폴더들이 보인다. 이 부분을 알아보자.

[ webapp에 넣어놓은 정적 리소스파일은 WEB-INF로 같은 레벨에 존재하게 된다. ]

 

 

 

JAR, WAR 간단 소개

 

JAR 소개

 

자바는 여러 클래스와 리소스를 묶어서 JAR (Java Archive)라고 하는 압축 파일을 만들 수 있다.

 

이 파일은 JVM 위에서 직접 실행되거나 또는 다른 곳에서 사용하는 라이브러리로 제공된다.

 

직접 실행하는 경우 main() 메서드가 필요하고,

MANIFEST.MF 파일에 실행할 메인 메서드가 있는 클래스를 지정해 두어야 한다.

 

실행 예) java -jar abc.jar

Jar는 쉽게 이야기해서 클래스와 관련 리소스를 압축한 단순한 파일이다.

 

필요한 경우 이 파일을 직접 실행할 수도 있고, 다른 곳에서 라이브러리로 사용할 수도 있다.

 

 

 

WAR 소개

WAR(Web Application Archive)라는 이름에서 알 수 있듯

WAR 파일은 웹 애플리케이션 서버(WAS)에 배포할 때 사용하는 파일이다.

 

JAR 파일이 JVM 위에서 실행된다면, WAR는 웹 애플리케이션 서버 위에서 실행된다.

 

웹 애플리케이션 서버 위에서 실행되고,

HTML 같은 정적 리소스와 클래스 파일을 모두 함께 포함하기 때문에 JAR와 비교해서 구조가 더 복잡하다.

그리고 WAR 구조를 지켜야 한다.

 

 

WAR 구조

WEB-INF
	classes : 실행 클래스 모음
	lib : 라이브러리 모음
	web.xml : 웹 서버 배치 설정 파일(생략 가능)
index.html : 정적 리소스

WEB-INF 폴더 하위는 자바 클래스와 라이브러리, 그리고 설정 정보가 들어가는 곳이다.
WEB-INF 를 제외한 나머지 영역은 HTML, CSS 같은 정적 리소스가 사용되는 영역이다.

 

 

WAR 배포

이렇게 생성된 WAR 파일을 톰캣 서버에 실제 배포해보자

 

 

1. 톰캣 서버를 종료한다.
./shutdown.sh

2. 톰캣폴더/webapps 하위를 모두 삭제한다.

3. 빌드된 server-0.0.1-SNAPSHOT.war 를 복사한다.

4. 톰캣폴더/webapps 하위에 붙여넣는다.
톰캣폴더/webapps/server-0.0.1-SNAPSHOT.war

5. 이름을 변경한다.
톰캣폴더/webapps/ROOT.war

6. 톰캣 서버를 실행한다. 
./startup.sh

 

톰캣하위의 webapps 폴더에는 기본 예제같은게 깔려있다.

모두 삭제해준다.

빌드된 war파일 복사

파일이름을 ROOT로 바꿔준다.

 

 

그리고 다시 톰캣실행

 

다 잘 동작하는것을 확인할 수 있다.

톰캣 실행한 화면인데 한글이 깨지긴하지만

localhost:8080/test  

url를 request하니까

TestServlet.service라고 로그가 남는것을 확인할 수 있다.

System.out.println("TestServlet.service");

 

더보기

진행이 잘 되지 않으면 톰캣폴더/logs/catalina.out 로그를 꼭 확인해보자.

실제 서버에서는 이렇게 사용하면 되지만, 개발 단계에서는 war 파일을 만들고,

이것을 서버에 복사해서 배포하는 과정이 너무 번잡하다.

 

인텔리J나 이클립스 같은 IDE는 이 부분을 편리하게 자동화해준다.

 

 

톰캣 설정 - 인텔리J 유료 버전

인텔리J 유로 버전에는 톰캣 지원이 포함되어 있다.

 

다음으로 이동한다.

메뉴 -> Run... -> Edit Configurations

왼쪽 상단의 플러스 버튼을 클릭한다.

 

Other 하위에 있는 Tomcat Server에 Local을 선택한다.

Tomcat Server 를 선택해야 한다. TomEE Server 를 선택하면 안된다

Configure… 부분을 선택한다.

Tomcat Home: 부분에 설치된 톰캣 폴더를 선택한다

 

Deployment 메뉴를 선택한다.

+ 버튼을 선택한다.

끝에 (exploded)로 끝나는 war 파일을 선택한다

 

Application context 박스 안에 있는 내용을 모두 지워준다

 

더보기

Application context 박스 안의 내용을 모두 지우는 이유는 애플리케이션을 루트 컨텍스트("/")로 배포하기 위함입니다.

자세한 설명

  1. 기본 컨텍스트 경로 설정
    • Application context 박스에 특정 경로가 입력되어 있으면, 그 경로로 웹 애플리케이션이 배포됩니다. 예를 들어 /Gradle__hello__server_0_0_1_SNAPSHOT_war__exploded_와 같은 경로가 입력된 경우, 애플리케이션은 http://localhost:8080/Gradle__hello__server_0_0_1_SNAPSHOT_war__exploded_에서 접근할 수 있습니다.
  2. 루트 컨텍스트로 설정
    • Application context 박스를 비워두면, 애플리케이션이 루트 컨텍스트(/)에 배포됩니다. 이렇게 하면 http://localhost:8080/에서 바로 애플리케이션에 접근할 수 있어 편리합니다.
    • 예를 들어, 경로에 /를 입력하거나 비워두면 http://localhost:8080/가 기본 접근 경로가 됩니다.
  3. 가독성과 접근성 향상
    • 루트 컨텍스트로 배포하면 URL이 간결해지고 가독성이 향상됩니다. 특히 개발 환경에서 테스트 시 http://localhost:8080/만으로 접근할 수 있으므로 사용하기 편리합니다.

요약

따라서, Application context 박스를 비워 루트 컨텍스트로 설정하면 애플리케이션에 더 간편하게 접근할 수 있으며, 개발이나 테스트 환경에서 URL 경로를 단순화하는 데 유리합니다.

 

설정한 톰캣을 선택하고 실행한다.

 

 

 

인텔리제이 무료버전일시

강의자료 참고

 

댓글