DAY 4

Network

대칭키 / 공개키

대칭키

• 암호화와 복호화 과정에 동일한 키를 사용한다
• 장점 : 계산이 빠르고 효율적이기 때문에 대량의 데이터를 빠르게 처리할 수 있다.
• 키의 배포와 관리가 어렵다. 통신하는 모든 당사자가 같은 키를 공유해야 하며, 이 키를 안전하게 전달하고 저장하는 것이 중요하다. 키가 유출되면 암호화된 데이터의 보안이 위협받는다

공개키

• 두 개의 키를 사용한다. 공개키와 개인키.
• 공개키는 누구에게나 공개될 수 있으며, 데이터를 암호화하는데 사용된다.
• 개인키는 비밀로 유지되며, 암호화된 데이터를 복호화하는데 사용된다.
• 장점 : 키의 배포 문제를 해결한다. 사람들은 자신의 개인키를 비밀로 유지하면서 공개키를 자유롭게 공유할 수 있다.
• 디지털 서명에도 사용되어 메시지의 무결성과 발신자의 인증을 제공한다.
• 단점 : 계산이 더 복잡하고 시간이 많이 소요된다. 따라서 일반적으로 작은 양의 데이터나 키 교환에 주로 사용된다.

 

HTTP / HTTPS

• 웹에서 데이터를 교환하는 방식을 규정하는 프로토콜이다. 웹 브라우저와 웹 서버 간의 통신을 가능하게 하는 핵심 기술이다.

HTTP

• 정의 : 웹에서 정보를 주고 받을 수 있는 프로토콜이다. 클라이언트와 서버 간의 요청과 응답에 사용된다.
• 클라이언트가 서버에 페이지나 이미지 등의 자원을 요청하면, 서버는 그 요청에 응답하여 필요한 자원을 클라이언트에 전송한다.
• 상태를 유지하지 않는 프로토콜이다. 즉, 이전의 통신 내용을 기억하지 않아 각 요청이 독립적이다.
• HTTP는 암호화되지 않은 텍스트로 데이터를 전송하기 때문에, 중간에서 데이터를 가로챌 수 있다. 이것은 개인 정보 누출, 데이터 변조 등의 보안 문제를 야기할 수 있다.
• 주로 80번 포트를 사용

HTTPS

• HTTP의 보안 버전이다. SSL 또는 TLS라는 암호화 프로토콜을 사용해 클라이언트와 서버 간의 통신을 암호화한다.
• HTTPS 통신에서는 클라이언트와 서버가 통신을 시작하기 전에 SSL/TLS를 통한 핸드셰이크 과정을 거친다. 이 과정에서 서로의 신원을 확인하고, 암호화된 연결을 설정한다.
• 데이터의 무결성을 보장하며, 중간자 공격을 방지한다. 또한 웹사이트의 신뢰도를 높이는 역할을 한다.
• 데이터를 암호화하여 전송하기 때문에, 데이터의 도청이나 변조를 매우 어렵게 만든다. 이는 사용자의 정보를 보호하고, 안전한 온라인 거래를 가능하게 한다.
• 주로 443번 포트를 사용
• 암호화/복호화 과정때문에 HTTPS가 HTTP보다 약간 더 많은 컴퓨팅 자원을 요구한다. 최근에는 차이가 점점 더 줄고 있다.

로드 밸런싱

• 다수의 컴퓨터, 네트워크 링크, 중앙 처리 장치 또는 기타 자원에 걸쳐 작업량을 분산시키는 기술
• 네트워크 서비스의 가용성과 응답 시간을 최적화하는데 중요한 역할을 한다. 특히 웹 서버, 데베 서버와 같이 높은 트래픽을 처리해야 하는 시스템에서 중요하다.
• 중요 목적
  1. 성능 향상 : 여러 서버에 작업을 분산시켜 처리 능력을 증가시킨다.
  2. 가용성 및 신뢰성 증가 : 하나의 서버가 실패하더라도 다른 서버가 대신 처리할 수 있어 서비스 중단 시간을 최소화한다.
  3. 확장성 : 시스템에 서버를 추가하여 쉽게 확장할 수 있다.
• 기본 원리
  • 클라이언트로부터 오는 요청을 여러 서버에 분배하는 중앙 장치이다. 로드 밸런싱 알고리즘에 따라, 이 장치는 각 서버의 현재 부하, 우선 순위, 세션 수 등 다양한 요소를 고려하여 요청을 적절히 분배한다.
• 알고리즘
  1. 라운드 로빈 : 각 서버에 차례대로 요청을 분배하는 가장 간단한 방식
  2. 가중 라운드 로빈 : 서버의 능력(CPU, RAM)에 따라 가중치를 부여하고, 이를 기반으로 요청을 분배한다.
  3. 최소 연결 : 현재 활성 연결이 가장 적은 서버에 요청을 분배한다. 동적인 웹 애플리케이션에 적합
  4. 가중 최소 연결 : 최소 연결 방식에 서버의 성능을 고려한 가중치를 추가
  5. IP 해시 : 클라이언트의 IP 주소를 기반으로 해시 값을 계산하고, 이를 통해 특정 서버에 요청을 지속적으로 할당한다. 세션 유지가 필요한 경우 유용하다.
• 기술의 분류
  • 소프트웨어 로드 밸런서 : NGINX, HAProxy와 같은 소프트웨어를 사용하여 구현한다. 유연성이 높고 비용 효율적이다.
  • 하드웨어 로드 밸런서 : 전용 물리적 장비를 사용한다. 고성능, 고가용성을 요구하는 대규모 환경에 적합하다.
• 장점
  • 향상된 웹 애플리케이션 성능
  • 서버 고장에 대한 내성 향상
  • 자동적인 서버 확장성
  • 업타임 및 가용성 증가
• 결론
  • 로드밸런싱은 다양한 서버 환경에서 높은 가용성, 우수한 성능, 뛰어난 확장성을 제공하는 핵심 기술
  • 트래픽 분산을 통해 시스템 부하를 균등하게 관리하며 어떠한 하나의 지점에서 발생할 수 있는 과부하 또는 장애 상황을 예방한다. 

 

Blocking, Non-blocking / Synchronous, Asynchronous

동기/비동기는 요청한 작업에 대해 완료 여부를 신경 써서 작업을 순차적으로 수행할지 아닌지에 대한 관점

블로킹/논블로킹은 현재 작업이 block(차단, 대기) 되느냐 아니냐에 따라 다른 작업을 수행할 수 있는지에 대한 관점

 

Synchronous vs Asynchronous

Synchronous 

• 요청한 작업에 대해 완료 여부를 따져 순차대로 처리하는 것

Asynchronous

• 요청한 작업에 대해 완료 여부를 따지지 않기 때문에 자신의 다음 작업을 그대로 수행

동기는 작업 B가 완료되어야 다음 작업을 수행하고, 비동기는 작업 B의 완료 여부를 따지지 않고 바로 다음 작업을 수행한다

 

Asynchronous의 성능 이점

I/O 작업과 같은 느린 작업이 발생할 때, 기다리지 않고 다른 작업을 처리하면서 동시에 처리하여 멀티 작업을 진행할 수 있다. 전반적인 시스템 성능 향상에 도움을 줄 수 있다.

동기 작업은 요청한 작업에 대해 순서가 지켜지는 것, 비동기 작업은 순서가 지켜지지 않을 수 있다는 것이다.

즉, 작업 3개를 요청했는데 응답에서 그 순서가 지켜진다면 동기이고 어떤게 먼저 올지 모른다면 비동기이다.

 

 

Blocking vs Non-Blocking

동기/비동기가 전체적인 작업에 대한 순차적인 흐름 유무라면, 블로킹/논블로킹은 전체적인 작업의 흐름 자체를 막냐 안막냐로 볼 수 있다.예를 들어, 파일을 읽는 작업이 있을 때, 블로킹 방식으로 읽으면 파일을 다 읽을 때까지 대기하고, 논블로킹 방식으로 읽으면 파일을 다 읽지 않아도 다른 작업을 할 수 있다.

 

 

순서와 관련지으면 비동기

전체 흐름을 안막으면 논블로킹

 

비동기는 출력 순서와 관련된 개념

논블로킹은 병렬 실행과 관련된 개념

 

 

정의된 코드 라인 순서와 출력 순서가 맞지 않는다 = 비동기

메인 함수를 블락하지 않고 백그라운드에서 별도로 처리되었다 = 병렬 처리 = 논블로킹

 

비동기 논블로킹이란 다른 작업의 결과를 기다리지 않고 병렬적으로 실행되는 방식이다. 이때 다른 작업의 완료 여부나 결과에 대한 후처리를 위해 이용되는 방식이 콜백 함수이다.

 

콜백 함수는 비동기 논블로킹을 구현하는 하나의 기술이지 개념이 아니다.

비동기 논블로킹을 구현하는 기술은 콜백 외에 여러가지가 있다. 콜백은 그 중 하나일 뿐이다.

 

제어권

함수의 코드나 프로세스의 실행 흐름을 제어할 수 있는 권리

블로킹/논블로킹은 호출된 함수가 호출한 함수에게 제어권을 바로 주느냐 안주느냐로 구분된다. 제어권이 넘어가면 해당 스레드는 블로킹된다.

 

1. Sync Blocking (동기 + 블로킹)
   • 다른 작업이 진행되는 동안 자신의 작업을 처리하지 않고(Blocking), 다른 작업의 완료 여부를 바로 받아 순차적으로 처리하는 (Sync) 방식이다. 다른 작업의 결과가 자신의 작업에 영향을 준느 경우에 활용할 수 있다.
   • 대표적인 예 : 파일을 읽어 내용을 처리하는 로직. 파일을 먼저 읽어야 그 다음 작업을 처리할 수 있기 때문.
   • 코드가 순차적으로 실행되는 특성. 일반적으로 작업이 간단하거나 작업량이 적은 경우에 사용된다.
   • 작은 데이터를 처리하거나 파일 하나를 읽고 쓰는 경우에는 Sync Blocking 방식이 더 간단하고 직관적일 수 있다.
   • 하지만 작업량이 많거나 시간이 오래걸리는 작업을 처리해야하는 경우는 독이다. 이러한 경우에는 Async Non-Blocking이 좋다.
   • 대표적으로 JAVA의 코드 실행 후 커맨드에서 입력을 받는 경우가 이에 해당한다. 사용자로부터 입력을 받아야 그 입력값을 가지고 내부 처리를 하여 결과값을 콘솔에 출력해주기 때문에 순차적인 작업이 요구된다.
2. Async Blocking (비동기 + 블로킹)
   • 다른 작업이 진행되는 동안 자신의 작업을 멈추고 기다리는(Blocking), 다른 작업의 결과를 바로 처리하지 않아 순서대로 작업을 수행하지 않는 (Async) 방식이다. 실무에서 잘 마주하지 않는다.
   • sync blocking과 거의 비슷하다. 보통 비동기 논블로킹으로 처리하려다가 실수하거나 자신도 모르게 블로킹 작업을 실행하는 의도치 않은 경우에 사용된다. 그래서 이 방식을 안티 패턴(anti-pattern)이라고 치부하기도 한다.
3. Sync Non-Blocking (동기 + 논블로킹)
   • 다른 작업이 진행되는 동안에도 자신의 작업을 처리하고 (Non Blocking), 다른 작업의 결과를 바로 처리하여 작업을 순차대로 수행하는 (Sync) 방식이다.
   • 대중적인 언어로 자바(Java)가 있다.
   • 스레드(Thread) 객체를 만들어 요청 작업을 백그라운드에 돌게 하고 메인 메서드에서 while 문을 통해 스레드가 모두 처리되었는지 끊임없이 확인하고, 처리가 완료되면 다음 메인 작업을 수행한다.
   • 분명 스레드를 이용하여 작업을 병렬적으로 처리하도록 지시했지만, 메인 코드의 while 문을 수행함으로서 요청한 작업의 완료 여부를 계속 확인하고 결과적으로 결국 동기적으로 작업을 순서대로 수행됨을 볼 수 있다.
   • 게임에서 맵을 이동할 때 생각
   • 맵 데이터 모두 다운로드 시에 로딩 스크린이 뜬다. 로딩바가 채워지고 있다. 즉, 제어권은 여전히 나에게 있어서 화면에 로드율이 표시되는 것이다. 그리고 끊임 없이 맵 데이터가 어느정도 로드가 되었는지 조회한다. 자신의 작업을 계속하고 있지만 다른 작업과의 동기를 위해 계속해서 다른 작업이 끝났는지 조회하는 것이다.
   • Sync Blocking vs Sync Non Blocking
     • 동기 + 논 블로킹은 호출하는 함수가 제어권을 가지고 있어서 다른 작업을 병렬적으로 수행할 수 있다. 반면에 동기 + 블로킹은 호출하는 함수가 제어권을 잃어서 다른 작업을 수행할 수 없다.
   • 또 다른 예제로는 브라우저에서 파일을 다운로드하면 나타나는 다운로드 진행바가 있다.
     • 파일 다운 시 작업은 웹 브라우저의 Web APIs으로 작업을 백그라운드로 넘기고 '제어권'을 바로 반환받아 다른 작업을 수행할 수 있다. 이것이 non blocking이다.
     • 그리고 파일이 모두 다운로드 완료되면 사용자가 원하는 최종 작업인 파일 다운로드 작업을 수행하게 된다. 이것이 syn이다.
4. Async Non-Blocking (비동기 + 논블로킹)
   • 다른 작업이 진행되는 동안에도 자신의 작업을 처리하고(Non Blocking), 다른 작업의 결과를 바로 처리하지 않아 작업 순서가 지켜지지 않는 (Async) 방식이다. 다른 작업의 결과가 자신의 작업에 영향을 주지 않은 경우에 활용할 수 있다.
   • 작업량이 많거나 시간이 오래 걸리는 작업을 처리해야 하는 경우에 적합하다. 예를 들어, 대용량 데이터를 처리하거나 많은 요청을 처리하는 서비스에서는 Async Non Blocking 방식을 사용하여 한 작업이 처리되는 동안 다른 작업을 처리할 수 있으므로 전체 처리 시간을 줄일 수 있어 성능 향상이 가능하다.
   • 웹 브라우저의 파일 다운로드 : 웹 사이트에서 파일을 다운로드할 때, 파일의 전송이 완료될 때까지 다른 탭이나 창을 열거나 웹 서핑을 할 수 있다. 이는 웹 브라우저가 파일 다운로드를 비동기적으로 처리하고, 콜백 함수를 통해 다운로드가 완료되면 알려주는 방식으로 구현되어 있기 때문이다.

Sync + Non Blocking

 

 

 

Blocking / Non-Blocking I/O

소켓 : 네트워크 상에서 동작하는 프로그램 간 통신의 종착점. 간단히 특정 문자들을 조합하여 만든 네트워크 주소

소켓은 프로세스가 네트워크 세계로 데이터를 내보내거나 혹은 네트워크 세계로부터 데이터를 받기 위한 실제적인 창구 역할을 한다.

소켓은 프로토콜, IP 주소, 포트 넘버로 정의된다.

프로토콜 : 통신을 원활하게 수용하도록 해주는 통신 규약

IP : 전 세계 컴퓨터에 부여된 고유 식별 주소

포트 : 논리적인 접속 장소

 

Blocking I/O

• I/O작업 (파일 읽기, 네트워크 요청)을 요청할 때, 해당 작업이 완료될 때까지 해당 스레드가 대기 상태에 놓인다.
• 즉, 작업이 완료되어야만 다음 코드 라인으로 진행할 수 있따.
• 코드를 순차적으로 작성할 수 있게 해준다. 프로그래밍을 단순화시키지만, 리소스 활용 면에서 비효율적이다.
• I/O 작업 동안 스레드가 대기 상태에 있으므로 CPU는 다른 유용한 작업을 수행하지 못하고 대기 시간을 낭비

Non-Blocking I/O

• I/O 작업을 요청하고, 작업이 완료되지 않았다면 즉시 제어를 반환받아 다른 작업을 계속 수행할 수 있다.
• 작업의 완료 여부를 주기적으로 확인하거나, 작업 완료 시 알림을 받는 방식으로 처리될 수 있다.
• I/O 작업을 기다리는 동안에도 CPU는 다른 작업을 수행할 수 있으므로 리소스 활용도가 높다
• 동시에 여러 I/O 작업을 관리해야 하므로 프로그래밍이 복잡해질 수 있다. 코드의 복잡성 증가시키고 버그 발생 가능성 높인다.

블로킹 I/O는 단순한 작업이나 순차적으로 처리되어야 하는 작업에 적합하다. 예를 들어, 파일 시스템 작업이나 단일 클라이언트를 처리하는 서버에 효과적일 수 있다.

논블로킹 I/O는 동시에 많은 수의 I/O 작업을 처리해야 하는 고성능 서버나 애플리케이션에 적합하다. 높은 처리량과 낮은 대기 시간을 요구하는 웹 서버, 데베 서버 등에서 유용하게 사용된다.

​

Spring

 

Bean Scope

빈은 스프링에서 제어 역전(IoC) 컨테이너에 의해 관리되는 객체.

1. 싱글톤
   
   • 기본 스코프
   • 스프링 IOC 컨테이너당 빈 인스턴스가 하나만 생성된다.
   • 대부분의 경우, 싱글톤 스코프가 적합하며 애플리케이션 전역에서 공유되어야 하는 상태가 없는 빈에 사용됨
2. 프로토타입
   • 매번 빈을 요청할 때마다 새로운 인스턴스가 생성
   • 각 요청 또는 참조에 대해 고유한 빈 인스턴스가 필요할 때 사용됨
   • 빈의 전체 생명주기는 스프링 컨테이너가 아니라 빈을 받은 클라이언트에 의해 관리된다.
3. 요청
   • 웹 애플리케이션에서 사용됨
   • 각 HTTP 요청마다 빈 인스턴스가 하나씩 생성됨
4. 세션
   1. • 웹 애플리케이션에서 사용됨
      • 각 세션마다 빈 인스턴스가 하나씩 생성됨
      • 사용자별 상태 정보 관리가 필요할 때 사용됨
5. 애플리케이션
   1. 서블릿 컨텍스트 당 빈 인스턴스가 하나만 생성됨
   2. 전체 애플리케이션에서 공유되어야 하는 데이터를 처리할 때 사용됨
6. 웹소켓
   1. 웹소켓의 생명주기에 맞춰 빈이 생성됨
   2. 웹소켓 연결마다 빈 인스턴스가 하나씩 생성됨
   3. 실시간 웹 통신이 필요한 애플리케이션에 사용됨

 

싱글톤 패턴이란?

• 단 하나의 유일한 객체를 만들기 위한 코드 패턴
• 메모리 절약을 위해, 인스턴스가 필요할 때 똑같은 인스턴스를 새로 만들지 않고 기존의 인스턴스를 가져와 활용함
• 객체가 리소스를 많이 차지하는 역할을 하는 무거운 클래스일 때 적합하다.
• 대표적으로 데이터베이스 연결 모듈, 디스크 연결, 네트워크 통신, 스레드풀, 캐시, 로그 기록 객체 등에 이용됨
• 애플리케이션에서 유일해야 하며 유일한 것이 좋은 것을 싱글톤 객체로 만든다.
• 생성자 메서드에 private 키워드를 붙여주면 된다.
• 문법적인 법률을 통해 구조적으로 제한하는 것이다.

MVC Framework

Model

• 애플리케이션의 데이터와 비즈니스 로직을 담당한다.
• 데이터베이스, 파일, 메모리 등에서 데이터를 조회하거나 저장하는 메서드를 포함할 수 있으며, 데이터의 가공 및 계산도 수행한다.
• 데이터가 어떻게 생성되고, 수정되며, 조회되는지에 대한 모든 규칙, 논리, 함수들이 모델에 포함된다.
• 데베, 웹서비스, 파일 시스템 등 다양한 데이터 소스와의 통신을 담당하며, 이를 통해 데이터를 가져오거나 변경한다.
• 데이터 저장소와의 상호 작용을 캡슐화
• 데이터의 상태 변화 감지하여 컨트롤러나 뷰에 알린다.
• 데이터의 가공 및 계산을 담당

View

• 사용자에게 정보를 표시하는 방법을 정의한다.
• HTML, CSS, JavaScript 등을 사용하여 사용자 인터페이스(UI)를 구성한다.
• 모델로부터 데이터를 받아 사용자에게 시각적으로 표현하는 역할을 담당한다.
• 사용자의 입력을 받아 컨트롤러에 전달하는 인터페이스 역할을 한다.
• 모델 변경될 때마다 업데이트되어 사용자에게 최신 정보를 제공

Controller

• 사용자의 입력을 받아 처리하는 컴포넌트. 
• 사용자의 요청을 분석하고, 해당하는 모델을 호출하여 데이터를 요청하거나 업데이트하며, 그 결과를 뷰에 전달하여 사용자에게 표시한다.
• 모델과 뷰 사이의 상호 작용을 관리한다.
• 사용자의 입력을 받아 모델을 업데이트하거나 모델로부터 데이터를 조회한다.
• 모델로부터 데이터를 받아 뷰를 업데이트한다.

동작 과정

1. 클라이언트가 url을 요청하면, 웹 브라우저에서 스프링으로 request가 보내진다.
2. Dispatcher Servlet이 request를 받으면, Handler Mapping을 통해 해당 url을 담당하는 controller를 탐색 후 찾아낸다.
3. 찾아낸 controller로 request를 보내주고, 보내주기 위해 필요한 Model을 구성한다.
4. Model에서는 페이지 처리에 필요한 정보들을 데베에 접근하여 쿼리문을 통해 가져온다.
5. 데이터베이스를 통해 얻은 Model 정보를 Controller에게 response 해주면, controller는 이를 받아 Model을 완성시켜 디스패쳐 서블릿에게 전달해준다.
6. 디스패쳐 서블릿은 View Resolver를 통해 request에 해당하는 view 파일을 탐색 후 받아낸다.
7. 받아낸 view 페이지 파일에 model을 보낸 후 클라이언트에게 보낼 페이지를 완성시켜 받아낸다.
8. 완성된 view 파일을 클라이언트에 response하여 화면에 출력한다.

구성 요소

• Dispatcher Servlet
  • 모든 request를 처리하는 중심 컨트롤러이다. 서블릿 컨테이너에서 http 프로토콜을 통해 들어오는 모든 request에 대해 제일 앞단에서 중앙 집중식으로 처리해주는 역할을 한다.
  • 기존에는 web.xml에 모두 등록해줘야 했지만, 디스패처 서블릿이 모든 request를 핸들링하면서 작업을 편리하게 할 수 있다.
•  Handler Mapping
  • 클라이언트의 request url을 어떤 컨트롤러가 처리해야 할 지 찾아서 Dispatcher Servlet에게 전달해주는 역할을 담당한다.
  • 컨트롤러 상에서 url을 매핑시키기 위해 @RequestMapping을 사용하는데, 핸들러가 이를 찾아주는 역할을 함.
• Controller
  • 실질적인 요청을 처리하는 곳이다. Dispatcher Servlet이 프론트 컨트롤러라면, 이 곳은 백엔드 컨트롤러라고 볼 수 있다.
•  View Resolver
  • 컨트롤러의 처리 결과를 만들 view를 결정해주는 역할을 담당한다. 다양한 종류가 있기 때문에 상황에 맞게 활용하면 된다.

장점

• 분리된 관심사 : M V C의 분리는 각 구성 요소의 독립적인 개발 및 유지 보수를 가능하게 한다.
• 재사용성 및 확장성 : 각 구성 요소는 독립적이므로, 재사용성이 높아지고 새로운 기능의 추가나 변경이 용이하다.
• 유연성 : 뷰와 모델이 직접적으로 의존하지 않기 때문에, 사용자 인터페이스 변경이 비즈니스 로직에 영향을 미치지 않는다.

 

Spring Boot, SpringApplication

Spring Boot

• Spring 기반 애플리케이션을 쉽고 빠르게 개발할 수 있도록 지원하는 도구
• 필요한 초기 설정 작업을 최소화하고, 애플리케이션을 자동 구성해준다.
• 개발자는 복잡한 설정 없이도 의존성 관리, 애플리케이션 구성, 서버 실행 등을 손쉽게 할 수 있다.
• Starter 종속성 : 다양한 Starter 종속성을 제공하여, 개발에 필요한 의존성을 간편하게 추가할 수 있다.
• 자동 구성 : 애플리케이션의 상황을 파악하여 필요한 Spring 구성을 자동으로 제공한다.
• 내장 서버 지원 : Tomcat 등의 내장 서버를 지원하여 별도의 서버 설치 없이 애플리케이션을 실행할 수 있다.
• 운영 준비 기능 : 애플리케이션 모니터링 및 관리를 위한 다양한 기능을 제공한다.(ex. actuator)

SpringApplication

• class이다. Spring Boot 애플리케이션을 부트스트랩하는 가장 기본적인 방법을 제공한다.
• 이 클래스를 사용하면 Spring 애플리케이션의 시작점으로서, 애플리케이션을 구성하고 실행하는 데 필요한 여러 설정을 손쉽게 할 수 있다.
• SpringApplication.run() 메서드를 호출하여 애플리케이션을 실행한다.
• 이 메서드는 애플리케이션의 컨텍스트를 초기화하고, 서버를 시작하는 등의 작업을 수행한다.
• 배너 커스터마이징 : 애플리케이션 실행 시 콘솔에 표시되는 배너를 커스터마이징 할 수 있다.
• Application Events와 Listeners : 애플리케이션의 생명주기 이벤트를 처리할 수 있다. 예를 들어 애플리케이션이 시작되거나 종료될 때 특정 작업을 수행할 수 있다.
• application.properties 또는 .yml파일을 통해 다양한 설정을 외부에서 관리할 수 있다.

• @SpringBootApplication 어노테이션을 통해 스프링 Bean을 읽어와 자동으로 생성해준다.
• 이 어노테이션이 있는 파일 위치부터 설정들을 읽어가므로, 반드시 프로젝트의 최상단에 만들어야 한다.
• .run()으로 해당 클래스를 run하면, 내장 WAS를 실행한다. 내장 WAS의 장점은 개발자가 따로 톰캣과 같은 외부 WAS를 설치 후 설정해두지 않아도 애플리케이션을 실행할 수 있다.
• 또한 외장 WAS를 사용할 시 이 프로젝트를 실행시키기 위한 서버에서 모두 외장 WAS의 종류와 버전, 설정을 일치시켜야만 한다. 따라서 내장 WAS를 사용하면 이런 신경은 쓰지 않아도 되기 때문에 매우 편리하다.