스택 메모리는 프로그램이 실행되는 동안 사용되는 메모리 영역 중 하나로, 함수 호출과 로컬 변수를 저장하는데 사용된다. "스택"이라는 이름은 데이터를 쌓아 올리는 형태로 관리되기 때문에 붙여진 이름이다. 함수가 호출될 때마다 새로운 스택 프레임이 생성되고, 함수가 종료되면 해당 스택 프레임이 제거된다.
출처 Wikipedia
< 로컬 변수는 어떻게 관리될까? >
로컬 변수란, 특정 코드 블록 내에서만 사용되는 변수를 말한다. 중괄호 {}로 둘러싸인 영역에서 선언된 변수들이 이에 해당한다.
using System;
namespace StackMemoryExample
{
class Program
{
static void MyFunction()
{
int a = 10; // 로컬 변수
Console.WriteLine(a);
} // 여기서 'a'는 스택에서 제거된다.
static void Main(string[] args)
{
MyFunction();
// 여기서는 'a'에 접근할 수 없다.
}
}
}
MyFunction이라는 메서드 안에서 a라는 로컬 변수를 선언하고 있다. 이 메서드가 호출되면 a 변수가 스택 메모리에 할당된다. 그리고 메서드가 끝날 때 (닫는 중괄호 }를 만날 때), 스택에서 a 변수가 제거된다. 이 시점 이후로는 a 변수에 접근할 수 없다.
< 왜 이렇게 동작할까? >
스택 메모리는 효율적인 메모리 관리를 위해 이렇게 동작한다. 함수 호출이 끝나면 그 안에서 사용된 로컬 변수들은 더 이상 필요하지 않으므로, 메모리를 효율적으로 활용하기 위해 자동으로 해제되는 것이다.
C#이나 Java 같은 프로그래밍 언어로 코드를 작성하더라도 컴퓨터는 바로 이해하지 못한다.
왜냐하면 컴퓨터는 0과 1, 즉 이진법으로 이루어진 기계어를 이해하는데, 우리가 사용하는 프로그래밍 언어는 이 기계어와 상당히 다르기 때문이다.
이 문제를 해결하기 위해 프로그래밍 언어를 컴퓨터가 이해할 수 있는 기계어로 변환해 주는 과정이 필요한데, 이 과정이 바로 '컴파일'과 '인터프리트'이다.
컴파일은 프로그래밍 언어로 작성된 코드를 한 번에 기계어로 번역하는 과정을 의미한다. 이렇게 번역된 코드는 실행 시간에 바로 실행될 수 있으며, 그 결과 프로그램의 실행 속도가 빠르다.
반면에, 인터프리트는 프로그래밍 언어로 작성된 코드를 한 줄씩 실시간으로 기계어로 번역하며 실행하는 방식이다. 이 방식은 실행 시간에 번역과 실행이 동시에 이루어지기 때문에 컴파일 방식보다 실행 속도는 느리지만, 코드 수정이 빠르고 간편하다는 장점이 있다.
C 계열 언어와 자바는 컴파일 방식을 사용하는 언어에 속한다.
그러나 Java는 C와 같은 기존의 컴파일 언어와는 다른 점이 있다.
일반적으로 Compiled된 코드는 특정 운영체제에서만 실행될 수 있다. 예를 들어, Windows 용으로 컴파일된 코드는 Linux나 Mac에서 실행할 수 없다.
하지만 자바는 JVM(Java Virtual Machine)이라는 중간 매개체를 통해 이 문제를 해결한다. 자바로 작성된 코드는 JVM이 설치된 모든 운영체제에서 실행될 수 있다.
자바로 작성된 코드는 먼저 '자바 컴파일러'에 의해 바이트코드로 변환된다. 이 바이트코드는 기계어가 아닌 중간 코드로, JVM이 이해할 수 있는 언어이다. 그 후 JVM은 이 바이트코드를 각 운영체제에 맞는 기계어로 번역하여 실행한다.
새로 개발하는 요리의 레시피를 작성하는 것에 비유하자면 코딩한 결과, 즉 레시피를 컴파일해서 컴퓨터에게 건내주면 컴퓨터는 이 번역본을 보고 요리를 하는 것이다.
컴퓨터가 종류마다 다른 언어를 쓰는 국가라고 치고 Windows, Mac, Linux 이렇게 3개의 국가가 있다고 가정해 보자.
C나 C++ 등의 언어로 레시피를 작성하고 나면 이것들을 각국의 현지어로 번역해서 보내야 했다.
코드를 실행할 컴퓨터의 종류에 따라 따로따로 컴파일을 해야 하니 여간 번거로운 일이 아닐 수 없다.
그런데 Java는 다른 방식을 도입했다.
Windows, Mac, Linux 이렇게 3개의 국가에 JVM-자바 가상 머신이라는 주방장을 파견한다
실행할 컴퓨터에 JVM이란 프로그램을 다운로드하는 것이다.
그럼 이 주방장들은 두 가지의 언어를 할 줄 아는 것이다. 먼저, 자기가 파견된 현지의 언어. 즉, 해당 컴퓨터의 기계어를 할 줄 아는 것이다. 다른 하나는 "자바 바이트코드"라는 주방장 공용어이다.
자바로 짠 코드는 바로 이 언어로 컴파일된다.
그래서 자바를 사용하는 레시피 개발자들은 레시피를 작성한 다음 이걸 단 하나의 언어 "자바 바이트코드"로 번역해서 각 국에 보내면 이 JVM이란 주방장들이 공통 번역본을 읽고 파견된 국가의 직원들, 즉, 컴퓨터 자원들에게 현지어로 지시를 내리는 것이다. 자바 개발자들은 자바를 실행할 컴퓨터 및 기기에 이 JVM이라는 프로그램만 설치해 두면 개발을 할 때 어떤 언어로 컴파일을 해야 할지 전혀 신경 쓰지 않아도 되는 것이다.
자바를 실행하기 위해 만들어진 JVM은 Kotlin, 스칼라, 그루비, Clojure 몇몇 다른 언어들에서도 사용할 수 있다.
이 언어들도 자바 바이트코드로 컴파일되도록 만들어졌기 때문이다.
그래서 안드로이드 앱을 만들거나 스프링 부트로 서버를 프로그래밍할 때 자바뿐만 아니라, Kotlin 등도 사용할 수 있는 것이다.
오늘날에는 JVM 말고도 많은 다른 언어들이 각각의 가상머신들을 사용해서 동작하고 있다.
이제는 가상머신을 쓴다는 것이 자바만의 강점은 아닌 것이다.
그럼 JRE는 뭐 JDK는 무엇일까?
자바 개발에 필요한 도구와 라이브러리를 제공하는 것이 JDK(Java Development Kit)이다.
JDK에는 자바 컴파일러와 JVM이 포함되어 있다.
즉, 자바로 프로그램을 개발하고 실행하기 위해서는 JDK가 필요하다.
레시피를 개발하는 회사로 비유할 수 있다.JDK(회사)안에 JRE(식당)가 있고, JRE안에 JVM(주방장)이 있는 것이다.
JRE(Java Runtime Environment)는 자바 프로그램을 실행하기 위한 환경을 제공한다. JRE에는 JVM과 필수적인 라이브러리들이 포함되어 있다.
아까 현지에 파견된 주방장을 JVM이라고 했는데, 현지 식당을 JRE이라고 할 수 있다.
최신의 자바 버전에서는 JRE를 별도로 배포하지 않고, JDK 안에 JRE를 포함시키는 방향으로 가고 있다.
따라서 개발자들은 JDK를 설치하면 자바 프로그램을 개발하고 실행하는 데 필요한 모든 것을 가질 수 있게 되었다.
이 두 개념을 혼동하기 쉬우나, 이 두 개념의 차이점을 이해하는 것은 동시성(concurrency) 및 병렬성(parallelism) 문제를 해결하면서 효율적인 Software를 구현하는 데 있어서 매우 중요한 개념이라고 할 수 있다. 여기서는 C#을 중심으로 설명하겠다.
귀여워서 쓰는 gifㅎㅎ
<프로세스(Process)>
프로세스는 운영체제로부터 자원을 할당받아 실행되는 작업 단위를 말한다. 프로세스는 각각 독립된 메모리 영역(Code,Data,Stack,Heap)을 가지며, 이는 운영체제로 부터 할당 받는다.
Code : C#을 사용한다고 가정하면, C# Program code가 저장되는 영역이라 할 수 있다. 이 부분은 읽기 전용이고, 변경이 불가 하다.
[코드 영역이 읽기 전용인 이유]
만약, 프로그램 코드가 프로그램 실행 중에 변경된다면, 프로그램은 의도치 않은 방식으로 동작하거나 오류를 발생시킬 수 있기에, 코드의 무결성을 보장하기 위해 코드 영역은 보호되어야 하기에 읽기 전용으로 설정된다.
또한 악성 코드가 있다면, 프로그램의 동작을 변경하려고 시도할 수 있기에 읽기 전용으로 해놓는 이유도 있다.
Data: 전역 변수와 정적(Static) 변수 등이 저장되는 영역. 이 부분은 읽기와 쓰기가 가능하다.
[Data는 읽기가 쓰기가 왜 가능할까?]
여기는 전역 "변수", 정적 "변수"가 저장되는 영역이라고 했다. 변수라는 것은 變, 즉 변할 변 이기에 변할 수가 있는 것이다.
그럼, 이 변수들은 프로그램 실행 도중에 읽거나 변경할 수 있는것이다. 예를 들어서 프로그램이 사용자의 입력을 받아서 전역 변수의 값을 변경하거나, 계산 결과를 전역 변수에 저장하는 등의 작업을 수행하게 된다. 이런 이유로 데이터 영역은 읽기와 쓰기가 모두 가능한것이다.
Stack : 함수 호출 정보(지역 변수, 매개 변수, 반환 주소 등)가 저장되는 영역, 읽기와 쓰기가 가능하고, 함수의 호출과 함께 할당되고 함수의 반환과 함께 해제된다.
Heap : 동적 할당을 위한 영역, 필요에 따라 크기를 조절할 수 있는 영역으로 이 부분은 읽기와 쓰기가 가능하다.
new 키워드를 사용해서 동적으로 객체를 생성하면 이 영역에 할당된다.
여기서 주의해야 할 것은 코드를 변경 가능 하다는 것이 아니라. '객체'를 변경 가능하다는 것이다.
예를 들어
using System;
public class Service
{
public string Name { get; set; }
}
public class Program
{
public static void Main()
{
// 객체 생성
Service service = new Service();
// 객체의 상태 변경
service.Name = "Initial Name";
Console.WriteLine(service.Name); // "Initial Name"
// 객체의 상태 변경
service.Name = "Changed Name";
Console.WriteLine(service.Name); // "Changed Name"
}
}
이 예제에서 'Service' 객체의 Name 프로퍼티는 프로그램이 실행 중일 때 변경된다. 이런 변경은 프로그램을 다시 컴파일하거나 실행하지 않고도 일어난다.
using System;
public class Program
{
// Data 영역: 전역 변수가 이곳에 저장된다.
static int globalVariable = 10;
// Code 영역: 함수 및 메서드가 이곳에 저장된다.
public static void Main()
{
// Stack 영역: 지역 변수와 함수 호출 정보가 이곳에 저장된다.
int localVariable = 20;
Console.WriteLine("Global Variable: " + globalVariable);
Console.WriteLine("Local Variable: " + localVariable);
// Heap 영역: 동적으로 할당된 데이터가 이곳에 저장된다.
int[] dynamicArray = new int[10];
dynamicArray[0] = 30;
Console.WriteLine("Dynamic Array Value: " + dynamicArray[0]);
}
}
여기서 'globalVariable'은 전역 변수로서, Data 영역에 저장된다.
Main 함수는 Code 영역에 저장된다.
localVariable은 Main 함수 내의 지역 변수로서, Stack 영역에 저장된다.
dynamicArray는 new 키워드를 사용하여 동적으로 할당되므로 Heap 영역에 저장된다.
프로세스는 집으로도 비유할 수 있다.
Code: 집의 설계도와 같다. 설계도는 집이 어떻게 생겼는지, 어떤 방들이 있는지 등의 정보를 담고 있다. 이 설계도는 읽기만 가능하고 변경할 수 없다. 마찬가지로, 코드 영역에는 프로그램 코드가 저장되어 있고, 이는 변경할 수 없다. Data: 집안에 있는 물건들과 같다. 예를 들어, 가구나 컴퓨터 등이 이에 해당한다. 이들 물건들은 위치를 이동하거나 상태를 변경하는 것이 가능하다. 마찬가지로, 데이터 영역에는 변수와 같은 데이터가 저장되며, 이는 읽기와 쓰기가 가능하다. Stack: 이는 집안의 할 일 리스트나 메모와 같다. 할 일을 추가하거나 완료하면 메모를 변경하게 된다. 마찬가지로, 스택 영역에는 함수 호출 정보가 저장되며, 함수 호출이 발생하거나 완료될 때마다 정보가 변경된다. Heap: 이는 집의 창고와 같다. 필요에 따라 물건을 가져다 놓거나 물건을 가져갈 수 있다. 마찬가지로, 힙 영역은 동적 할당을 위한 공간으로, 필요에 따라 메모리를 할당하고 해제할 수 있다.
<스레드(Thread)>
Thread는 Process 내에서 실행되는 흐름의 단위를 의미한다. 하나의 Process 내에서 여러 Thread를 생성할 수 있고,
Thread들은 Process의 Memory 영역(Code,Data,Heap)을 공유하면서 실행된다. 그러나 각 Thread는 자신만의 Stack영역을 가지고 있다. 각 Thread가 별도의 함수 호출을 관리하기 때문이다.
using System;
using System.Threading;
class Program
{
static void Main()
{
Thread thread = new Thread(PrintNumbers);
thread.Start();
PrintNumbers();
}
static void PrintNumbers()
{
for (int i = 0; i < 10; i++)
{
Console.WriteLine(i);
}
}
}
이 코드를 예로 설명하자면 여기서는 총 두 개의 스레드가 실행된다. 하나는 Main() 함수가 실행되는 메인 스레드, 또 하나는 Thread thread = new Thread(PrintNumbers);에 의해 생성되는 새로운 스레드다.
Main() 함수에서 thread.Start();를 호출하면서 새로운 스레드가 시작되며, 이 스레드는 PrintNumbers() 함수를 실행한다. 동시에 Main() 함수 내에서 PrintNumbers() 함수를 호출하여 메인 스레드에서 동일한 함수가 실행된다.
using System;
using System.Threading;
class Program
{
static void Main()
{
// 첫 번째 추가 스레드 생성
Thread thread1 = new Thread(PrintNumbers);
thread1.Start();
// 두 번째 추가 스레드 생성
Thread thread2 = new Thread(PrintLetters);
thread2.Start();
// 메인 스레드에서 PrintNumbers와 PrintLetters 실행
PrintNumbers();
PrintLetters();
}
static void PrintNumbers()
{
for (int i = 0; i < 10; i++)
{
Console.WriteLine(i);
}
}
static void PrintLetters()
{
for (char c = 'a'; c <= 'j'; c++)
{
Console.WriteLine(c);
}
}
}
이렇게 하면 된다. 총 3개의 스레드가 실행 된다.
< 프로세스와 스레드의 관계와 차이점 >
프로세스는 운영체제로부터 자원을 받아 할당하고, 스레드는 프로세스로부터 자원을 할당받아 실행되는 것이라고 할 수 있다.
즉, 프로세스는 독립적인 실행 단위이며, 스레드는 프로세스 내에서 독립적인 실행 흐름을 나타내는 단위이다. 따라서 여러 스레드를 생성하는 것은 하나의 프로세스 내에서 병렬적인 작업을 수행하는 것을 가능하게 함으로써 여러 작업을 동시에 처리할 수 있으므로 프로그램의 실행 속도를 향상시킬 수 있다. 예를 들어, 한 스레드에서 데이터를 로드하는 동안 다른 스레드에서는 계산을 수행하는 등, 여러 작업을 동시에 진행하면 전체 실행 시간을 줄일 수 있다. 또한 사용자 인터페이스를 가진 Application에서는 별도의 스레드에서 오래 걸리는 작업을 수행하면, 주 스레드(일반적으로는 UI스레드 라고 한다.)는 사용자 입력에 대응하거나 인터페이스를 업데이트하는 등의 작업을 계속 할 수 있다.
하지만 주의해야 할 점은, 프로세스 내의 스레드들이 메모리를 공유하기 때문에 동시성 제어가 필요하다. 예를 들어, 두 스레드가 동일한 메모리 위치에 동시에 접근하려고 시도한다면, 예측할 수 없는 결과를 초래할 수 있다.
(Dev 지식으로서의 자료구조 및 알고리즘 개념 설명. 글 아래의 개념을 이해하고, 자료구조,알고리즘 카테고리에 관련한 글을 같이 읽으면 좋다.)
자료구조란 데이터에 편리하게 접근하고, 변경하기 위해서 데이터를 저장하거나 조작하는 방법을 말한다.
만약에 사과를 담는 용기가 필요하다고 생각해보자. 사과를 멀리 가지고 가려는 목적이라면 바퀴가 달려있는 수레 같은게 필요할 수 있다. 자주자주 꺼내 먹기 위한 용기가 필요하다면 손을넣어 꺼낼수있는 백이나 바구니 같은 형태가 적합하다고 할수있겠다.어떤 자료구조를 선택하느냐에 따라 퍼포먼스가 달라진다.
알고리즘이란 어떠한 문제를 해결하기 위한 일련의 절차나 방법을 공식화한 형태로 표현한 것을 의미한다.
알고리즘은 9세기 페르시아의 수학자인 무함마드 알콰리즈미의 이름을 라틴어화한 알고리스무스(Algorismus)에서 유래한 표현이다. 유한성을 가지며, 언젠가는 끝나야 하는 속성을 가지고 있다. 문제 해결을 위해 여러 개의 후보 알고리즘 중, 정확성과 효율성 등을 평가한 후에 최적의 알고리즘을 선택한다. 알고리즘은 연산, 데이터 진행 또는 자동화된 추론을 수행한다.
자료구조와 알고리즘의 관계
자료구조는 '데이터의 표현과 저장방법'을 의미한다고 하였다. 그렇다면 알고리즘은 무슨 의미일까? 사람들은 알고리즘을 공부하려면 자료구조를 공부해야한다고 한다. 알고리즘은 그러한 데이터를 대상으로 '문제의 해결 방법'을 의미한다.
예를들어 배열에 값을 저장하는 것은 자료구조적이지만, 그 배열을 통해서 총합을 구하는 코드는 알고리즘적인 코드라고 할 수 있다.
< 자료구조와 알고리즘이 필요한 이유 >
1. 메모리를 절약하기 위해
가장 기본적인 이유이며 불필요하고 추가적인 정보 없이 목적에 부합하는 정보만을 저장하면 되기 때문에 저장 공간을 효율적으로 사용할 수 있다.
2. 프로그램 실행 시간을 단축하기 위해
효율적은 구조를 구현함으로 불필요한 계산을 줄이고 프로그램의 실행 시간을 단축 시켜준다.
(이러한 절차를 '알고리즘'이라고 한다.)
3. 프로그램 구현과 유지보수를 쉽게 하기 위해
효율적은 구조는 프로그램 개발을 쉽게 만들어주고 이해하기 쉬워 협업자들로 하여금 분석하는 시간을 줄여준다.
C:\Program Files\Eclipse Adoptium\jdk-11.0.18.10-hotspot\bin path로 설정
(꼭 환경 변수 설정 부터 먼저 해야 한다. 안 그러면 cmd에서
neither the java_home nor the jre_home environment variable is defined at least one of these environment variable is needed to run this program 이라는 Error 발생)
< Tomcat 실행 하기 >
cmd 실행 하기 -> cd apache-tomcat-9.0.71 입력 후 엔터
-> cd bin 입력 후 엔터
-> startup.bat 입력 후 엔터
위의 명령어는 C:\Windows\System32\apache-tomcat-9.0.71\bin>startup.bat 경로에 있다는 걸 알 수 있다.
< Tomcat Server 종료하기 >
cmd -> cd apache-tomcat-9.0.71 -> cd bin ->shutdown.bat
단일 책임 원칙(Single Responsibility Principle)은 SRP이라고도 불린다. SRP는 Object-Oriented-Programming에서
매우 중요한 원칙 중 하나 이다. 이름에서 알 수 있듯이, 각각의 클래스는 단 한 가지의 책임만을 가져야 한다는 원칙이다.
이 원칙은 가독성과 유지보수성을 높이는데 있어 중요한 역할을 한다. 더 자세히 알아보자.
🤔 < (그래서.. 단일 책임 원칙이 뭘까?) >🤔
SRP는 한 클래스는 하나의 책임만 가져야 한다는 개념. 즉, 클래스는 한 가지의 기능만을 수행해야 하며, 그 이상의 기능이 추가되면 별도의 클래스로 분리해야 된다는 것. 이를 통해 클래스의 복잡성을 줄일 수 있으며, 클래스가 자신의 책임을 더 잘 이해하고, 다른 클래스와 독립적으로 유지보수 및 수정이 가능해지는 것이다.
🐻❄️ < SRP의 필요성 >🐻❄️
이 원칙이 필요한 이유는 간단하다. 한 클래스가 여러 가지 책임을 가질 경우, 클래스의 복잡성이 증가하고, 한 책임에 대한 변경이 다른 책임을 가진 코드에 영향을 미칠 가능성이 높아진다.
예를 들어, 계산기 클래스가 있을 때, 이 클래스가 숫자 계산뿐만 아니라 파일에서 데이터를 읽고,결과를 파일에 쓰는 역할까지 수행하게 된다면, 이 클래스는 두 가지의 책임을 가지게 된다. 이렇게 되면, 계산 로직과 파일 입출력ㅇ 로직이 서로 간섭할 수 있으며, 한 가지 로직의 수정이 다른 로직에도 영향을 끼칠 수 있다.
< SRP를 위반한 예시 >
public class Calculator {
private List numbers = new ArrayList<>();
private int result;
public void loadNumbersFromFile(String fileName) {
// 파일에서 숫자를 로드하여 numbers 리스트에 추가하는 코드
}
public void addNumber(int number){
numbers.add(number);
}
public void calculateSum() {
result = 0;
for(int number : numbers) {
result += number;
}
}
public void saveResultToFile(String fileName){
//결과를 파일에 저장하는 코드
}
}
}
위 코드에서 Calculator 클래스는 숫자를 더하는 책임과 파일 입출력 책임을 동시에 가지고 있다.
<SRP를 준수한 예시>
public class Calculator {
private List numbers = new ArrayList<>();
private int result;
public void addNumber(int number) {
numbers.add(number);
}
public void calculateSum() {
result = 0;
for (int number : numbers) {
result += number;
}
}
}
위의 코드에서는 Calculator 클래스는 숫자를 더하는 책임만 가지고 있다. 파일 입출력은 별도의 클래스에서 담당하도록 분리되었다. 이렇게 하면 클래스의 책임이 명확하게 구분되며, 코드의 가독성과 유지보수성이 향상된다.
Reference: Wikipedia: Single Responsibility Principle
Enterprise Application은 대규모의 복잡한 데이터를 관리하는 Application을 말한다.
소프트웨어 분야가 발전하며 Enterprise App은 점점 복잡해졌다. 예를 들어 은행 시스템을 생각해보면 몇 백만, 몇천만 사용자가 잔고 조회,입금,출금 요청을 한다. 이렇듯 Enterprise App은 많은 사용자의 요청을 동시 처리 해야 하므로 서버 성능,안정성,보안이 매우 중요하다고 볼 수 있다.
그런데 이런 것들을 신경쓰면서 사이트 기능, 즉, Business Logic까지 개발하기는 매우어렵다.
누군가 Enterprise App을 위한 개발 환경을 제공해서 기능 개발에만 집중할 수 있다면 얼마나 좋을까?
이런 상황에서 Spring Framework가 등장 했다. Spring framework는 앞서 언급한 서버 성능,안정성,보안을 매우 높은 수준으로 제공하는 도구였다. 덕분에 개발자들은 기능 개발에만 집중할 수 있게 되었다.
📟< 스프링을 더 쉽게 만들어주는 스프링 부트 >
스프링은 장점이 많은 개발 도구이지만 설정이 매우 복잡하다는 단점이 있었다. 그래서 스프링을 개발팀에서도 이런 단점을 인식하고 단점으로 보완하고자 스프링 부트를 출시했다. 스프링 부트는 스프링 프레임워크를 더 쉽고 빠르게 이용할 수 있도록 만들어주는 도구이다. 빠르게 스프링 프로젝트를 설정할 수 있고 의존성 세트라고 불리는 스타터를 사용해 간편하게 의존성을 사용하거나 관리할 수 있다. 스프링 부트는 개발자가 조금 더 Business Logic 개발에만 집중할 수 있도록 만들어주는 도구인 것이다. 스프링과 비교했을 때 Springboot의 주요 특징은 다음과 같이 정리할 수 있다.
①.Tomcat,Jetty,Undertow 같은 웹 애플리케이션 서버 (Web application server, WAS)가 내장되어 있어 따로 설치하지 않아도 독립적으로 실행할 수 있다. ②.Bulid 구성을 단순화 하는 Spring boot Starter를 제공한다. ③.XML 설정을 하지 않고 Java code로 모두 작성할 수 있다. ④.JAR를 이용해서 Java Option만으로도 배포가 가능하다. ⑤.App의 Monitoring 및 Manage tool인 Spring Actuator를 제공한다.
🎯참고로 Spring boot와 Spring은 서로 다른 도구가 아니라 Spring boot는 Spring에 속한 도구이다. 단, Spring과 Spring boot는 개발할 때의 몇 가지 차이점이 있다. 그 차이점에 대해서 알아보자.
🌳<Spring과 Spring boot의 차이점 >
< 구성의 차이 >
Spring은 App 개발에 필요한 환경을 수동으로 구성하고 정의해야 한다. 하지만 Spring boot는 Spring core와 Spring MVC의 모든 기능을 자동으로 로드하므로 수동으로 개발 환경을 구성할 필요가 없다.
< 내장 WAS 유무 >
Spring App은 일반적으로 Tomcat과 같은 WAS에서 배포된다. WAS란 간단히 Web App을 실행하기 위한 장치를 말한다.
하지만 Spring boot는 자체적으로 WAS를 가지고 있다. 그래서 jar file만 만들면 별도의 WAS setting을 하지 않아도 App을 실행할 수 있다. 참고로 Spring boot의 내장 WAS에는 Tomcat,Jetty,Undertow가 있어 상황에 필요한 WAS를 선택할 수도 있다. 그 외의 차이점 아래의 표와 같다.
