상황

Restfull으로 개발된 SpringBoot 애플리케이션을 AWS EC2에 배포하였다.

어 그런데 일정 시간이 지나면 자동으로 연결이 끝어지면서 서버가 종료하게 된다.

학교 선배님에게 듣기로는 서버는 절대 죽어서는 안되고 계속 돌아가야 한다고 하여 방법을 찾게 되었다.

nohup, disown 명령어

// 공통 명령어
bashCopy code
nohup command-to-be-run &

// 포그라운드 프로세스 Spring jar파일 기준 방법
nohup java -jar ~.jar &
// 백그라운드 프로세스 기준 
disown

nohup은 "no hangup"을 의미하며, 프로세스를 시작할 때 사용된다. 이는 터미널 세션 종료 시에 신호를 무시하도록 프로세스에 지시하는 것을 의미한다. & 기호는 명령어는 해당 프로세스를 백그라운드에서 실행하도록 한다.

disown 은 bash 셸의 내장 명령으로, 이미 실행 중인 백그라운드 프로세스에 대해 사용되며 현재 셸의 작업 목록에서 작업을 제거한다. disown이 실행되면, 해당 프로세스는 셸에서 분리되어 사용자가 로그아웃하더라도 계속 실행되게 된다.

따라서 위 명령어는 ~.jar를 실행하고, 이 프로세스를 백그라운드에서 계속 실행하도록 하며, 터미널이나 쉘이 닫혀도 종료되지 않도록 한다.

요약: 프로그램을 터미널 세션 종료 시에 신호를 무시하도록 설정 후 백그라운드로 실행시켜 사용자가 로그아웃을 하거나 네트워크 연결이 끊어져도 중단되지 않게 해준다.

특이사항

• nohup 명령어로 실행되는 프로세스는 자동으로 재시작 되지 않는다.
  • 서버가 중지되거나 재부팅 된다면 수동으로 다시 실행시켜 주어야 한다.
• nohup java -jar ~.jar > output.log 2>&1 & 명령어를 통해
  • nohup.out 파일에 출력을 저장하지 않고 다른 파일에 저장하는 것이 가능하다.

.gitignore 파일이란?

Git에게 특정 파일이나 디렉토리를 추적하지 않도록 지시하는 역할을 하는 특수한 파일
해당 프로젝트와는 관계없는 파일들이 원격저장소에 올라가지 않도록 하기 위해 사용
민감한 정보를 포함하는 파일, 시스템이나 개발 도구에 의해 생성된 파일, 빌드 결과물 등을 Git의 추적 대상에서 제외할 수 있다.

.gitignore 파일의 각 줄은 무시할 패턴을 지정하며, 아래와 같은 규칙을 따릅니다:

1. 빈 줄이나 #로 시작하는 줄은 무시됩니다.
2. 표준 Glob 패턴을 사용합니다.
3. 슬래시(/)로 시작하면 하위 디렉토리에 적용되지 않습니다.
4. 디렉토리는 슬래시(/)를 끝에 사용하여 지정할 수 있습니다.
5. 느낌표(!)로 시작하는 패턴의 파일은 무시되지 않습니다.

사용 예시:

스프링 부트 프로젝트에서 유출되면 안되는 중요한 정보가 담긴 파일이 GIt에 올라가지 않도록 설정

application.properties 파일 제거

# Application configuration
/src/main/resources/application.properties

자동 생성 사이트

https://www.toptal.com/developers/gitignore

깃허브 .gitignore파일을 편하게 만들기위한 오픈소스 프로젝트

결과물

# Created by https://www.toptal.com/developers/gitignore/api/java,windows,macos,intellij+all,visualstudiocode,gradle
# Edit at https://www.toptal.com/developers/gitignore?templates=java,windows,macos,intellij+all,visualstudiocode,gradle

### Intellij+all ###
# Covers JetBrains IDEs: IntelliJ, RubyMine, PhpStorm, AppCode, PyCharm, CLion, Android Studio, WebStorm and Rider
# Reference: https://intellij-support.jetbrains.com/hc/en-us/articles/206544839

# User-specific stuff
.idea/**/workspace.xml
.idea/**/tasks.xml
.idea/**/usage.statistics.xml
.idea/**/dictionaries
.idea/**/shelf

# AWS User-specific
.idea/**/aws.xml

# Generated files
.idea/**/contentModel.xml

# Sensitive or high-churn files
.idea/**/dataSources/
.idea/**/dataSources.ids
.idea/**/dataSources.local.xml
.idea/**/sqlDataSources.xml
.idea/**/dynamic.xml
.idea/**/uiDesigner.xml
.idea/**/dbnavigator.xml

# Gradle
.idea/**/gradle.xml
.idea/**/libraries

# Gradle and Maven with auto-import
# When using Gradle or Maven with auto-import, you should exclude module files,
# since they will be recreated, and may cause churn.  Uncomment if using
# auto-import.
# .idea/artifacts
# .idea/compiler.xml
# .idea/jarRepositories.xml
# .idea/modules.xml
# .idea/*.iml
# .idea/modules
# *.iml
# *.ipr

# CMake
cmake-build-*/

# Mongo Explorer plugin
.idea/**/mongoSettings.xml

# File-based project format
*.iws

# IntelliJ
out/

# mpeltonen/sbt-idea plugin
.idea_modules/

# JIRA plugin
atlassian-ide-plugin.xml

# Cursive Clojure plugin
.idea/replstate.xml

# SonarLint plugin
.idea/sonarlint/

# Crashlytics plugin (for Android Studio and IntelliJ)
com_crashlytics_export_strings.xml
crashlytics.properties
crashlytics-build.properties
fabric.properties

# Editor-based Rest Client
.idea/httpRequests

# Android studio 3.1+ serialized cache file
.idea/caches/build_file_checksums.ser

### Intellij+all Patch ###
# Ignore everything but code style settings and run configurations
# that are supposed to be shared within teams.

.idea/*

!.idea/codeStyles
!.idea/runConfigurations

### Java ###
# Compiled class file
*.class

# Log file
*.log

# BlueJ files
*.ctxt

# Mobile Tools for Java (J2ME)
.mtj.tmp/

# Package Files #
*.jar
*.war
*.nar
*.ear
*.zip
*.tar.gz
*.rar

# virtual machine crash logs, see http://www.java.com/en/download/help/error_hotspot.xml
hs_err_pid*
replay_pid*

### macOS ###
# General
.DS_Store
.AppleDouble
.LSOverride

# Icon must end with two \r
Icon


# Thumbnails
._*

# Files that might appear in the root of a volume
.DocumentRevisions-V100
.fseventsd
.Spotlight-V100
.TemporaryItems
.Trashes
.VolumeIcon.icns
.com.apple.timemachine.donotpresent

# Directories potentially created on remote AFP share
.AppleDB
.AppleDesktop
Network Trash Folder
Temporary Items
.apdisk

### macOS Patch ###
# iCloud generated files
*.icloud

### VisualStudioCode ###
.vscode/*
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json
!.vscode/*.code-snippets

# Local History for Visual Studio Code
.history/

# Built Visual Studio Code Extensions
*.vsix

### VisualStudioCode Patch ###
# Ignore all local history of files
.history
.ionide

### Windows ###
# Windows thumbnail cache files
Thumbs.db
Thumbs.db:encryptable
ehthumbs.db
ehthumbs_vista.db

# Dump file
*.stackdump

# Folder config file
[Dd]esktop.ini

# Recycle Bin used on file shares
$RECYCLE.BIN/

# Windows Installer files
*.cab
*.msi
*.msix
*.msm
*.msp

# Windows shortcuts
*.lnk

### Gradle ###
.gradle
**/build/
!src/**/build/

# Ignore Gradle GUI config
gradle-app.setting

# Avoid ignoring Gradle wrapper jar file (.jar files are usually ignored)
!gradle-wrapper.jar

# Avoid ignore Gradle wrappper properties
!gradle-wrapper.properties

# Cache of project
.gradletasknamecache

# Eclipse Gradle plugin generated files
# Eclipse Core
.project
# JDT-specific (Eclipse Java Development Tools)
.classpath

### Gradle Patch ###
# Java heap dump
*.hprof

# End of https://www.toptal.com/developers/gitignore/api/java,windows,macos,intellij+all,visualstudiocode,gradle

Branch 네이밍 규칙

1) master branch, develop branch

본래 이름을 그대로 사용한다. 

ex: master, develop

2) feature branch.

feature/{feature-name}  형식을 사용한다.

이때 feature-name은 소문자, 하이폰 (-)의 구성으로만 작성한다.

ex: feature/parameter-json-parser, feature/opencv-result-drawing

3) release branch

release/{version} 형식을 사용한다. 

ex: release/1.0

4) hotfix branch

hotfix/{version}, hotfix/{hotfix-name} 형식을 사용한다. 

ex: hotfix/1.0, hotfix/previous-restart-issue

Commit Message

💡 커밋 규칙

• 최소 작업 단위를 기준으로 가능하면 작게 쪼갠다.
• 1개의 커밋에는 1개의 행위만 들어 있게 한다.
• 반드시 커밋구분 리스트를 접두사로 붙인다.
• 한글로 읽는 사람이 이해하기 쉽도록 작성한다. 

title

• 커밋 구분 리스트를 접두사로 사용한다.
• 그 후 ~한다는 명령어로 시작하여 한눈에 어떤 작업을 했는지 알기 쉽게 적는다.
• 영어로 예시를 들면 Create~, Add~, Fix~, Delete~

summary

• 45자 이내로 간결하게 작성한다.

description

• summary를 풀어서 작성한다.
• description만 보고도 어떤 작업을 했는지 파악할 수 있도록 작성한다.
• 기존에서 변경된 사항이 있다면 before, after 를 명시한다.
• ex) 함수 A 리턴값 타입 변경 : int → float

Pull Request

💡 PR 규칙

• 최소 작업 단위를 기준으로 가능하면 작게 쪼갠다.
• 1개의 PR에는 1개의 작업만 들어 있게 한다.
• 코드의 변화를 300줄 미만으로 유지한다.
• 리뷰어가 코딩 스타일을 리뷰하지 않도록 코드 컨벤션을 잘 지킨다.
• 정상적으로 동작하는지 테스트하고, 정상적인 경우에만 PR 한다.
• 한글로 읽는 사람이 이해하기 쉽도록 작성한다. 

title

• 작업한 브랜치 명을 그대로 따라 간다. 

description

• 작업 이유, 작업 내용, 리뷰어가 알아야 할 내용, 이미지 등을 상세하게 명시한다.

template

## 개요
작업하게 된 이유를 작성해주세요.

## 작업 내용
작업한 내용을 상세하게 설명해주세요.

### 추가된 사항
새로 추가한 작업에 대해 설명해주세요.

### 변경 사항
기존 내용에서 변경된 사항을 before -> after 형식으로 작성해주세요.

## 이슈
궁금한 사항 혹은 리뷰어들이 알아야 하는 이슈를 작성해주세요.

## 이미지
시각적인 설명이 필요한 경우 부가적으로 첨부해주세요.

https://blog.ull.im/engineering/2019/03/10/logs-on-git.html

https://blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=skykbc&logNo=222016405016 

GitLab-Flow 전략이란?

GitLab에서 제안한 효율적인 브랜치 관리 전략이다.

기존의 Git Flow나 GitHub Flow의 방식을 확장하여, 복잡한 프로젝트와 배포 환경에서도 안정적인 작업을 가능하게 하는 것이 특징이다.

GitHub Flow전략과 마찬가지로 Master 브랜치가 항상 배포 가능한 상태를 유지하며 

Git Flow전략과 마찬가지로 다양한 종류의 브랜치를 활용하여 작업을 분류 할 수 있다.

(간단한 경우) 브랜치 종류 

master : 항상 배포 가능한 상태를 유지하는 최종 브랜치
feature : 새로운 기능이나 버그 수정을 위한 브랜치 master 브랜치로부터 분기하며 master 브랜치로 병합된다.

방법

1. master 브랜치에서 작업을 시작하기 위한 feature 브랜치로 분기합니다.
2. feature 브랜치에서 작업을 시작하고 작은 단위로 쪼개 커밋합니다.
3. 작업이 완료된 코드는 리뷰 및 테스트를 하고 master 브랜치에 병합시킵니다.

(복잡한 경우) 브랜치 종류

master : 항상 배포 가능한 상태를 유지하는 최종 브랜치로 모든 배포 환경에 대한 공통 코드가 존재한다.
feature : 새로운 기능이나 버그 수정을 위한 브랜치 master 브랜치로부터 분기하며 master 브랜치로 병합된다.
environment : 특정 환경에 대응하는 브랜치 환경에 따라 여러개의 종류가 있을 수 있다.
- development : environment 브랜치 중 하나로 개발자들이 새로운 기능을 개발하고 초기 테스트를 진행하는 환경의 브랜치
- staging : environment 브랜치 중 하나로 실제 서비스 배포 전 마지막 테스트와 검증을 수행하는 환경의 브랜치
- production : environment 브랜치 중 하나로 실제로 사용자에게 서비스되는 프로덕션 환경의 코드를 담당하는 최종 브랜치

방법

1. master 브랜치에서 새로운 기능이나 수정이 필요한 부분에 대해 feature 브랜치를 생성하여 분기합니다.
2. feature 브랜치에서 작업을 시작하고 작은 단위로 쪼개 커밋합니다.
3. 작업이 완료된 코드는 PR 리뷰 및 테스트를 하고 master 브랜치에 병합합니다.
4. master 브랜치에 병합된 변경 사항을 development 브랜치, 환경에 반영합니다.
5. development 브랜치,환경에서 테스트가 성공적으로 수행되면 staging 브랜치,환경에 반영합니다.
6. 실제 서비스 배포 전 마지막 테스트와 검증을 수행하고 완료되면 최종적으로 production 브랜치,환경으로 병합합니다.

(특별한 경우) 브랜치 종류

master : 항상 배포 가능한 상태를 유지하는 최종 브랜치 모든 배포 환경에 대한 공통 코드가 존재한다.
feature : 새로운 기능이나 버그 수정을 위한 브랜치 master 브랜치로부터 분기하며 master 브랜치로 병합된다.
environment : 특정 환경에 대응하는 브랜치
- development : environment 브랜치 중 하나로 개발자들이 새로운 기능을 개발하고 초기 테스트를 진행하는 환경의 브랜치
- staging : environment 브랜치 중 하나로 실제 서비스 배포 전 마지막 테스트와 검증을 수행하는 환경의 브랜치
- production : environment 브랜치 중 하나로 실제로 사용자에게 서비스되는 프로덕션 환경의 코드를 담당하는 최종 브랜치
release : 특정 버전의 배포를 위한 브랜치, 특정 버전의 준비가 완료된 후 해당 브랜치를 프로덕션 브랜치로 병합하여 배포하게 된다.
hotfix : 프로덕션에서 발생한 긴급한 이슈를 해결하기 위한 브랜치 production 브랜치로부터 분기하며 수정 후에는 production과 master 브랜치 모두에 병합된다.

방법

1. master 브랜치에서 작업을 시작하기 위한 feature 브랜치로 분기합니다.
2. feature 브랜치에서 작업을 시작하고 작은 단위로 쪼개 커밋합니다.
3. 작업이 완료된 코드는 PR 리뷰 후 mater 브랜치에 병합합니다.
4. master 브랜치에서 release 브랜치로 분기 후 테스트와 검증을 수행합니다.
5. release 브랜치에 병합된 변경 사항에 테스트가 성공적으로 수행되면 master, development 브랜치, 환경에 반영합니다.
6. development 브랜치,환경에서 테스트가 성공적으로 수행되면 staging 브랜치,환경에 반영합니다.
7. 실제 서비스 배포 전 마지막 테스트와 검증을 수행하고 완료되면 최종적으로 production 브랜치,환경으로 병합합니다.
8. production 환경에서 발생한 긴급한 이슈는 hotfix 브랜치에서 긴급 수정하고 production 및 master 브랜치로 병합합니다.

장점

• 다양한 브랜치를 전략을 사용하여 작업을 분류하기 때문에 복잡한 프로젝트에 적합하다.
• 다양한 브랜치 전략으로 조합하여 사용할 수 있어 유연성이 높다.
• 지속적인 배포와 통합 master 브랜치에서 일어나는 모든 변경 사항은 즉시 테스트와 통합이 가능해지므로, 지속적인 통합(CI)와 배포(CD)를 가능하게 한다. 

단점

• 다양한 브랜치와 워크플로우를 관리해야 하므로 복잡성이 높다.
• 다양한 브랜치를 유지하고 관리하기 위한 비용이 발생할 수 있다.

언제 사용하면 좋은가?

1. 복잡한 프로젝트를 관리 해야할 때
2. 다양한 환경에서 배포해야 할 프로젝트인 경우
3. 지속적인 통합 및 배포 (CI, CD)환경의 구축이 필요한 프로젝트인 경우

GitHub-Flow 전략이란?

GitHub에서 제안한 간단하고 직관적인 Git 브랜치 전략이다.

브랜치를 master 브랜치와 각각의 작업을 위한 topic 브랜치로 나누어서 작업하는게 특징으로 단순성과 배포 중심을 가지고 있다.

주요 포인트는 브랜치를 작업 단위로 만들고 각 브랜치가 자체적으로 완결성을 가져 항상 배포 가능한 상태인 master 브랜치로 병합될 수 있게 관리하는 것이다.

이러한 특징으로 인해 GitHub Flow는 빠른 반복적인 개발과 배포를 가능하게 한다.

브랜치 종류

master : 항상 배포 가능한 상태를 유지하는 최종 브랜치
topic : 새로운 기능 또는 변경 사항을 구현하기 위해 master 브랜치로부터 분기하여 생성되는 브랜치

방법

주의사항: master 브랜치는 언제나 배포 가능한 상태를 유지해야 합니다.

1. master 브랜치에서 작업을 시작하기 위한 새로운 브랜치를 분기합니다.
2. 이때 브랜치의 이름은 작업 내용을 설명하는 방식으로 짓습니다.
3. 새로운 브랜치에서 작업을 수행하고 작은 단위로 쪼개 커밋을 만듭니다.
4. 작업이 완료되면 GitHub에 푸시하고 PR을 생성합니다.
5. PR을 통한 코드리뷰 과정을 거치고 테스트가 통과하면 master 브랜치로 merge합니다.
6. merge된 브랜치를 즉시 배포합니다.

장점

• 간단하고 직관적이다. 새로운 기능을 위한 브랜치를 만들고 그 기능을 완성한 후에 master 브랜치로 병합하는 간단한 워크플로우 작업이기 때문이다.
• 코드 리뷰를 통한 품질 관리. PR을 통해 팀원들의 코드를 리뷰 

단점

• 단순한 워크 플로우를 가지고 있기 때문에 복잡한 프로젝트에 적합하지 않을 수 있다.
• 브랜치 전략이 고정적이다. master 브랜치에서 새 브랜치를 만들고 다시 master 브랜치로 병합하는 방식을 사용하므로 다양한 브랜치 전략을 적용하기 어렵다.

언제 사용하면 좋은가?

1. 작은 규모의 팀에서 단순한 프로젝트를 관리 할 때
2. 빠른 반복과 개발주기를 가지며 지속적인 배포가 필요한 경우

Git-Flow 전략이란?

배달의 민족 안드로이드 개발 파트에서 사용하고 있는 Git branch 전략으로

브랜치를 기능(feature), 릴리스(release), 핫픽스(hotfix) 등으로 구분하여 운영하는게 특징이다.

개발은 develop 브랜치에서 이루어지고, 테스트와 스테이징은 release 브랜치에서 이루어진다.

그리고 문제가 발생하면 핫픽스 브랜치에서 수정하여 메인 브랜치로 병합하게 된다. 

이미지 출처, 참고: https://techblog.woowahan.com/2553/

브랜치 종류

master : 최종 브랜치로 제품을 배포하는 브랜치
develop : 다음 출시 버전을 개발하는 브랜치로 개발자들이 이 브랜치를 기준으로 각자 작업한 기능들을 PR, Merge 한다
feature : 단위 기능을 개발하는 브랜치로 기능 개발이 완료되면 develop 브랜치에 PR, Merge 한다
release : 배포를 위해 master 브랜치로 보내기 전에 먼저 테스트와 스테이징을 하기위한 브랜치
hotfix : master 브랜치로 배포를 했는데 버그가 생겼을 떄 긴급 수정하는 브랜치

방법

1. master 브랜치에서 develop 브랜치를 분기합니다.
2. 개발자들은 develop 브랜치를 기준으로 브랜치를 분기합니다.
3. 각 구현해야 할 기능 마다 develop 브랜치에서 feature-* 브랜치로 분기합니다.
4. 작업 변경 사항을 최소단위로 feature-* 브랜치로 commit 합니다.
5. 기능을 개발하던 도중 다른 개발자의 PR혹은 커밋으로 develop 브랜치가 변화 했다면 rebase 하여 현재 브랜치의 커밋을 임시적으로 제거하고, rebase 대상 브랜치의 모든 커밋을 먼저 적용한 다음, 이전에 제거했던 커밋을 다시 적용해 작업합니다. (merge 와의 차이점은 선형적인 커밋 이력을 유지할 수 있다는 점 입니다.)
6. 기능 개발이 완료 되었다면 develop 브랜치로 PR 합니다.
7. 배포를 준비하기 위해 develop 브랜치에서 release-* 브랜치를 분기합니다.
8. 테스트를 진행하면서 발생하는 버그 수정은 release-* 브랜치에 직접 반영합니다.
9. 테스트가 완료되면 release 브랜치를 master와 develop에 merge합니다.
10. master 브랜치에서 버그 발생시 hotfix-* 브랜치로 분기하여 작업합니다. 이후 develop 브랜치와 master브랜치에 반영합니다.

장점

• 각 단계(개발, 스테이징, 배포 등)에 맞는 브랜치를 사용함으로써 작업을 체계적으로 관리할 수 있다.
• 복잡한 프로젝트에 적합하며, 큰 규모의 팀에서도 효과적으로 작동한다.

단점

• 많은 수의 브랜치를 관리해야 하므로, 브랜치 관리가 복잡해질 수 있다.
• 처음 해당 개발 흐름을 접할 때 이해가 어려울 수 있다. 

언제 사용하면 좋은가?

1. 복잡한 프로젝트를 관리 할 때
2. 정기적인 릴리즈 주기와 명확한 릴리즈 관리가 필요한 프로젝트인 경우

Tomcat

Apache Software Foundation에서 개발한 오픈 소스 웹 서버 및 서블릿 컨테이너.
Java Servlet, JavaServer Pages (JSP), Java EL 등을 지원하며, 웹 애플리케이션을 위한 컨테이너 역할 수행한다.

장점:

1. 오랜 기간 동안 사용되어 왔고, 안정성이 검증되어 있다.
2. 방대한 커뮤니티 지원과 풍부한 문서화.
3. Spring과 같은 인기 있는 Java 프레임워크와 잘 호환된다.
4. Java 웹 애플리케이션 표준인 Servlet과 JSP를 잘 준수한다.

단점:

1. 경량화에 비중을 둔 웹 서버에 비해 상대적으로 무거울 수 있다.
2. 비동기 처리와 같은 몇몇 고급 기능 지원이 제한적일 수 있다.

Jetty

Eclipse Foundation에서 개발한 오픈 소스 웹 서버 및 서블릿 컨테이너.
작은 크기, 빠른 시작 시간, 모듈식 플러그인 아키텍처 등이 특징.

장점:

1. 경량화되어 있어 메모리 사용량이 적고 시작 시간이 빠르다.
2. 모듈식 아키텍처로 필요한 기능만 선택적으로 사용할 수 있다.
3. 임베디드 웹 서버로서 사용하기 적합하다.

단점:

1. Tomcat과 비교할 때 상대적으로 작은 커뮤니티 지원.
2. 문서화가 Tomcat만큼 풍부하지 않을 수 있다.

Undertow

JBoss에서 개발한 경량화된 오픈 소스 웹 서버.
Servlet 3.1, WebSocket, HTTP/2 등 최신 Java 웹 표준을 지원하며, 높은 성능과 비동기 처리를 지원.

장점:

1. 빠른 시작 시간과 높은 성능.
2. 비동기 처리를 지원하여 고성능이 요구되는 애플리케이션에 적합하다.
3. 최신 Java 웹 표준을 지원한다.

단점:

1. 상대적으로 새로운 웹 서버로 커뮤니티 지원이 더 적을 수 있다.
2. Tomcat과 Jetty에 비해 일부 애플리케이션에서의 호환성 문제가 있을 수 있다.

소개

• Spring: 자바 플랫폼을 위한 오픈 소스 프레임워크로, 2003년에 Rod Johnson에 의해 처음 발표되었다. 
• SpringBoot: Spring Framework 위에서 구축된 독립적인(stand-alone), 생산 수준의 Spring 기반 애플리케이션을 쉽게 만들 수 있도록 돕는 도구

공통점

• Java로 개발된 애플리케이션을 만들기 위한 프레임워크

라이브러리: 개발자가 코드의 흐름을 제어하며 필요한 시점에서 호출하여 사용한다.
프레임워크: 개발자가 아닌 프레임워크가 애플리케이션의 흐름을 제어하며, 애플리케이션의 전반적인 구조를 제공하며 개발자는 정해진 구조 위에서 기능을 추가하게 된다. 

차이점

• 설정과 구성
  • Spring Framework: Spring 애플리케이션을 설정하고 구성하는 데에 XML 기반 또는 주석 시반 설정으로 복잡한 부분이 있어 많은 시간이 소요된다.
  • Spring Boot: opinionated defaults 기법을 통해 기본 설정을 제공받아 설정을 자동화하여 개발자가 별도의 설정을 하지 않아도 바로 애플리케이션을 실행할 수 있게 해준다. 상대적으로 적은 시간이 소요된다.
• 서버 설정
  • Spring Framework: 별도의 내장 서버를 포함하지 않기 때문에 개발자가 별도로 웹 서버를 설치하고 구성해야 한다.
  • Spring Boot: 내장 Tomcat, Jetty, Undertow 등의 서버를 제공하므로 웹 서버를 따로 설치하거나 구성할 필요가 없다.
• 의존성 관리
  • Spring Framework: 개발자가 필요한 모든 라이브러리의 의존성을 수동으로 관리해야 한다.
  • Spring Boot: 스타터(starter)종속성을 제공하여, 프레임워크 자체에서 관련된 의존성 그룹을 자동으로 가지고 와서 설치해준다.
• 프로젝트 배포
  • Spring Framework: WAR 파일로 패키지화하여 별도의 서버에 배포하여야 한다.
  • Spring Boot: JAR 파일로 패키지화하여 자체 내장 서버를 통해 쉽게 실행하고 배포할 수 있다. 
  • ( https://suhanlim.tistory.com/192 )배포 및 WAR, JAR 파일 설명 글
• 개발 및 시장 출시 시간
  • Spring Framework: 설정, 의존성 관리 등으로 인해 개발 및 배포 시간이 상대적으로 길 수 있다.
  • Spring Boot: 자동 설정, 내장 서버, 스타터 종속성 등으로 인해 빠르게 애플리케이션을 개발하고 배포 할 수 있다.
• SpringBoot에서 추가된 기능
  • Actuator: Spring Boot Actuator는 애플리케이션의 상태를 모니터링하고 관리하는 기능을 제공한다. HTTP 엔드포인트나 JMX를 통해 애플리케이션의 다양한 정보(예: 메트릭, 헬스 체크, 환경 설정 등)를 확인할 수 있다.
  • ( https://suhanlim.tistory.com/193 )사용 방법 정리 글
  • YAML: YAML형식의 설정 파일을 지원한다.

언제 사용해야 하는가?

• Spring Framework: 복잡한 애플리케이션에 대해 더 많은 제어가 필요하거나 특정 설정을 최적화하려는 경우나, 학습 목적으로 Spring의 내부 동작을 더 잘 이해하려는 경우에 사용하는게 적합하다.
• Spring Boot: 빠른 프로토타이핑이나 마이크로서비스 아키텍처와 같이 빠른 개발과 배포가 중요한 상황에서 적합하다. 설정의 복잡성을 최소화하고 빠르게 실행 가능한 애플리케이션을 만들 때 사용하면 좋다.