MSA는 업무 기능별 서비스를 나누고, 각 서비스를 독립적으로 개발·배포·운영하는 아키텍처

1. 먼저 이해할 개념

쇼핑몰을 예로 들면 주문, 결제, 재고를 각각 서비스로 나눌 수 있습니다.

MSA에서는 독립 배포와 선택적 확장이 쉬워지는 대신, 네트워크 장애와 데이터 일관성 같은 분산 시스템 문제를 다뤄야 합니다. Microsoft 아키텍처 개요

2. 서비스를 나누는 기준

핵심은 업무 책임과 함께 변경되는 기능을 기준으로 경계를 정하는 것입니다.

• 도메인: 주문, 결제, 배송처럼 비즈니스가 다루는 영역
• DDD: 비즈니스 개념을 중심으로 소프트웨어를 설계하는 접근
• Bounded Context: 특정 용어와 모델이 일관된 의미를 갖는 경계

예를 들어 주문 서비스의 ‘상품’에는 주문 당시의 가격이 중요하고, 재고 서비스의 ‘상품’에는 가용 수량이 중요합니다. 같은 이름이라도 책임과 모델은 다를 수 있습니다. 도메인 분석 학습 자료

학습 과제: 쇼핑몰 기능을 주문·결제·재고로 분류하고, 각 서비스가 책임질 규칙을 세 가지씩 적어보세요.

3. 서비스 간 통신과 데이터 소유권

각 서비스는 자신의 데이터를 소유하고, 다른 서비스는 API나 이벤트를 통해 접근하는 것이 기본 원칙입니다. DB 서버를 반드시 각각 마련해야 한다는 뜻은 아니며, 데이터 소유권과 접근 경계를 분리하는 것이 핵심입니다. 서비스별 데이터 소유권

4. 반드시 공부할 데이터 패턴

• 최종적 일관성: 서비스 간 데이터가 즉시 같아지지 않아도, 처리가 완료되면 일관된 상태에 도달하는 방식
• Saga: 여러 서비스의 로컬 트랜잭션을 연결하고, 실패하면 업무상 보상 작업을 수행하는 패턴. 예를 들어 결제 실패 시 재고 예약을 해제합니다. Saga 설명
• Transactional Outbox: 업무 데이터와 발행할 이벤트를 같은 DB 트랜잭션으로 기록한 뒤, 별도 처리기가 이벤트를 전달하는 패턴. DB 저장 성공과 메시지 발행 실패가 엇갈리는 문제를 다룹니다. Outbox 설명
• 멱등성: 같은 요청이나 메시지를 여러 번 처리해도 결제·재고 차감 등의 효과가 중복 발생하지 않도록 설계하는 성질

Saga의 보상 작업은 전체 DB 트랜잭션을 되돌리는 롤백과 다릅니다. 이미 수행된 작업을 업무 규칙에 따라 취소하거나 상쇄하는 것입니다.

5. 운영에서 알아야 할 항목

• 타임아웃·재시도: 응답 지연과 일시적 실패 처리
• Circuit Breaker: 반복적으로 실패하는 서비스 호출을 일시적으로 차단
• 관측 가능성: 로그, 메트릭, 분산 추적으로 요청 흐름과 장애 원인 파악
• CI/CD·호환성: 서비스별 배포 자동화와 API 변경 관리

이 항목들은 장애 격리와 독립 배포를 실제로 유지하기 위한 기반입니다. Microsoft 운영·설계 가이드

학습 목표는 “서비스를 어떻게 나눌까?”, “일부가 실패하면 어떻게 복구할까?”, “서로 독립적으로 배포할 수 있을까?”에 답할 수 있게 되는 것입니다.

JDBC

• 자바 애플리케이션에서 데이터베이스에 접근하고 SQL을 실행하기 위한 표준 API
• JDBC를 직접 사용하는 경우 개발자는 SQL을 작성하고, 실행 결과를 자바 객체로 변환하는 작업도 처리
• JDBC는 자바와 DB가 통신할 수 있는 수단을 제공하지만, 객체와 테이블을 자동으로 매핑

  String sql = "SELECT * FROM memo WHERE id = ?";
  

PreparedStatement pstmt = connection.prepareStatement(sql); pstmt.setLong(1, 1L);

ResultSet rs = pstmt.executeQuery();

if (rs.next()) { Long id = rs.getLong("id"); String username = rs.getString("username"); }

### ORM 
- **객체지향 프로그래밍의 객체와 관계형 데이터베이스의 테이블을 매핑하는 기술**
- 자바 애플리케이션에서는 객체를 사용하지만, 관계형 DB에서는 테이블과 행(Row)을 사용한다.
이러한 표현 방식의 차이를 해결하고 객체 중심으로 데이터를 다룰 수 있도록 돕는 기술이 ORM이다.

### JPA
- **자바에서 ORM을 사용하기 위한 표준 명세**
- JPA 자체가 ORM 기능을 구현한 프로그램인 것이 아님!
- ORM을 구현하기 위한 인터페이스와 동작 규칙을 정의하고, 실제 동작은 JPA 구현체가 담당

예를 들어 JPA는 다음과 같은 인터페이스와 메서드를 정의한다 : 
- `EntityManager`
- `EntityManagerFactory`
- `persist()`
- `find()`
- `remove()`

### Hibernate
- **JPA를 실제로 구현한 대표적인 ORM 프레임워크**
- JPA API를 사용하여 엔티티의 저장이나 조회를 요청하면 Hibernate가 엔티티 매핑 정보를 바탕으로 
필요한 SQL을 생성하고 실행한다.

### Spring Data JPA
- JPA를 더 편리하게 사용할 수 있도록 지원하는 Spring Data 프로젝트의 모듈
- **JPA만 사용할 경우 개발자가 EntityManager를 이용하여 엔티티 저장, 조회 등의 작업을 직접 구현해야 하는데, 
Spring Data JPA를 사용하면 JpaRepository 인터페이스를 통해 기본적인 CRUD 기능을 간편하게 사용**할 수 있다.
- Repository 구현체를 자동으로 생성하고, 내부적으로 JPA의 EntityManager 등을 이용해 DB 작업 수행

| 구분 | 개념 | 역할 |
|---|---|---|
| 🍀**JDBC** | 데이터베이스 접근 API | SQL 실행 및 DB 통신 |
| 🍀**ORM** | 객체-관계 매핑 기술 | 객체와 관계형 DB 매핑 |
| 🍀**JPA** | ORM 표준 명세 | ORM 사용을 위한 API와 규칙 정의 |
| 🍀**Hibernate** | ORM 프레임워크 | JPA 기능 구현, SQL 생성 및 실행 |
| 🍀**Spring Data JPA** | JPA 추상화 기술 | Repository를 통한 CRUD 및 쿼리 기능 제공 |

--- 
## 엔티티와 테이블
### 엔티티(클래스)
- 데이터베이스 테이블과 매핑되는 자바 클래스
- `@Entity`가 선언된 자바 클래스가 JPA에서 관리할 수 있는 엔티티 클래스가 된다.
- JPA를 사용한다고 **반드시 DB 테이블이 새로 생성되는 것은 아니다.** _- Hibernate 설정에 따라_

### 엔티티와 테이블 간 관계
- 엔티티 클래스 `Memo` 는 memo 테이블과 매핑된다.
- 하나의 엔티티 인스턴스는 테이블의 하나의 행(Row)에 대응한다.
#### 엔티티 클래스

@Entity @Getter @NoArgsConstructor(access = AccessLevel.PROTECTED) public class Memo { @Id @GeneratedValue(stragy = GeneratedType.IDENTITY) private Long id;

@Column(nullable = false)
private String username;

@Column(nullable = false)
private String contents;

}

#### DB 테이블
| id | username | contents |
|-------|-------|-------|     
| 1   | Jude   | Jude memo   |
| 2   | Judy  | Judy memo   |
| 3   | Juice  | Jucie memo   |

## 엔티티 인스턴스 생성
엔티티 클래스와 DB 테이블이 매핑되었다고 해서 엔티티 인스턴스가 자동으로 생성되는 것은 아니다.

### 1. 개발자가 생성하는 경우

```java
Memo memo = new Memo();

• 개발자가 new 키워드를 사용하여 직접 인스턴스를 생성
• 이 시점의 객체는 단순한 자바 객체, JPA의 영속성 컨텍스트에서 관리되는 상태❌

em.persist(memo);       // 영속성 컨텍스트에 등록

• persist()를 호출하면 엔티티가 영속 상태가 되고, 이후 적절한 시점에 DB에 INSERT SQL 실행

2. DB에서 데이터를 조회하는 경우

Memo memo = em.find(Memo.class, 1L);

• Hibernate는 필요할 경우 다음 작업을 수행한다:
  • 엔티티 조회 요청
  • DB에 SELECT SQL 실행
  • 조회 결과(Row) 확인
  • Memo 엔티티 인스턴스 생성
  • Row의 컬럼 값을 인스턴스 필드에 매핑
  • 완성된 인스턴스 반환

✨ [참고] JPA 영속성 컨텍스트에 이미 해당 엔티티가 존재하면 별도의 DB 조회나 새 인스턴스 생성 없이 기존 인스턴스를 반환할 수도 있다.

JPA 엔티티(Entity) 클래스를 작성할 때 기본 생성자(Default Constructor)를 반드시 포함해야 하는 주된 이유는 무엇입니까? JPA 구현체는 데이터베이스 조회 결과를 자바 엔티티 객체로 생성할 때 Java Reflection API를 활용합니다. 이때 매개변수가 없는 기본 생성자를 호출하여 객체를 생성한 뒤 리플렉션으로 값을 주입하므로, 기본 생성자가 반드시(최소 protected 접근 제어자 이상으로) 필요합니다.

--

영속성 컨텍스트 - Persistence Context

영속성 컨텍스트, EntityManager, EntityManagerFactory, JPA 트랜잭션

영속성 컨텍스트의 기능

영속성 컨텍스트는 Entity 객체를 효율적으로 쉽게 관리하기 위해 만들어진 공간

1차 캐시

스프링 IoC와 DI의 핵심

객체를 내가 직접 생성하고 연결하지 않고, 스프링 컨테이너가 객체 생성과 의존관계를 관리하도록 맡기는 것

🍀 IoC(Inversion of Control, 제어의 역전)

예제 코드

public class OrderService {

    private PaymentService paymentService = new PaymentService();
}

OrderService가 직접:

• PaymentService 객체 생성
• 객체 관리
• 어떤 구현체를 사용할지 결정 즉, 제어권이 개발자 코드에 있다.

예제 코드

@Service
public class OrderService {

    private final PaymentService paymentService;

    public OrderService(PaymentService paymentService) {
        this.paymentService = paymentService;
    }
}

@Service
public class PaymentService {
}

• PaymentService 객체를 누가 만드는가?(생성) → Spring Container
• OrderService에 누가 넣어주는가?(주입) → Spring Container

IoC 정리

객체에 대한 제어권이 개발자 → 프레임워크로 넘어갔기 때문에 IoC(제어의 역전)라고 한다.

🍀 DI(Dependency Injection, 의존성 주입)

DI는 IoC를 구현하는 대표적인 방법으로, 필요한 객체를 내부에서 직접 생성하지 않고 외부에서 전달받는 것이다.

예제코드

public class OrderService {

    private PaymentService paymentService;
}

• OrderService가 정상적으로 동작하려면 PaymentService가 필요하다.
• OrderService → (의존관계) → PaymentService

예제코드

public OrderService(PaymentService paymentService) {
    this.paymentService = paymentService;
}

• PaymentService를 외부에서 넣어준다.

🍀 IoC와 DI의 관계

Bean과 IoC Container

🍀 Bean

• 스프링(Spring IoC Container)이 생성하고 관리하는 객체
• 관련 어노테이션:
  • @Service, @Component, @Repository, @Controller이 붙은 클래스는 Component Scan의 대상이 되어 Spring Bean으로 등록된다.

🍀 IoC Container

• 애플리케이션에서 사용할 Bean(객체)을 생성하고, 보관하고, 필요한 곳에 주입해주는
• 스프링의 객체 관리 공간*
• 대표적으로 ApplicationContext가 IoC Container 역할을 한다.

✨ [참고] BeanFactory와 ApplicationContext

 IoC Container
   │
   ├── 📦 BeanFactory
   │      └─ Bean 관리의 가장 기본 기능
   │
   └── 📦 ApplicationContext
          └─ BeanFactory 기능 + 여러 부가 기능

• BeanFactory : 기본적인 Bean 생성/조회/관리 기능을 제공
  • ApplicationContext : BeanFactory를 확장하여 그 기능을 포함하면서 여러 부가 기능 제공

Spring Bean 등록

간만에 스프링 공부하니까 개ㅐ어지럽다. 다양한 어노테이션과 개념들이 연달아 쏟아지듯 등장하면서 뇌가 지끈거렸는데 각각 따로 보면 헷갈리지만 결국 모두 스프링이 객체를 생성하고 관리하면서 필요한 객체끼리 연결하는 과정과 관련된 개념이다.

📍 전체 흐름 먼저 보기

@SpringBootApplication
        ↓
@ComponentScan
        ↓
@Component 계열 클래스 탐색
        ↓
Bean 생성 및 등록
        ↓
ApplicationContext가 Bean 관리
        ↓
생성자 주입 / @Autowired
        ↓
필요한 Bean을 다른 Bean에 주입

🍀 @Component

• 해당 클래스를 스프링이 관리하는 객체인 Bean으로 등록할 대상임을 표시
• 스프링은 @Component가 붙은 클래스를 발견하면 객체를 생성하고 스프링 Container에 Bean으로 등록한다.

🍀 @Component 계열 어노테이션

@Controller

@Service

@Repository

🍀 @ComponentScan

• 특정 패키지를 탐색하면서 @Component 계열 어노테이션이 붙은 클래스를 찾아 Bean으로 등록한다.
• 스프링 부트에서 ComponentScan을 직접 작성하지 않는다.
• 왜? @SpringBootApplication안에 @ComponentScan이 포함되어 있으니까 !!!
  • @SpringBootApplication이 있는 현재 패키지+하위 패키지 스캔
• 그래서 메인 클래스를 최상위 패키지에서 두는 것이 일반적

✨ [참고] @SpringBootApplication의 핵심 어노테이션

@SpringBootApplication
   ├─ @SpringBootConfiguration
   │      └─ @Configuration
   ├─ @EnableAutoConfiguration
   └─ @ComponentScan

• @SpringBootConfiguration : 클래스가 Spring Boot의 설정 클래스임을 나타냄
  • @Configuration : 클래스가 Spring의 설정 클래스임을 나타냄
• @EnableAutoConfiguration : 클래스 패스와 설정값을 바탕으로 필요한 설정을 자동 구성
• @ComponentScan : 현재 패키지와 하위 패키지의 @Component 계열 클래스를 탐색해 Bean 등록

✨ [참고] @Component vs @Configuration + @Bean

둘 다 Bean을 등록하는 방법이지만 누가 Bean 등록을 결정하느냐가 다름

@Component

@Component
public class PaymentService {
}

@Cofiguration + @Bean

@Configuration
public class AppConfig {

    @Bean
    public PaymentService paymentService() {
        return new PaymentService();
    }
}

의존성 주입(DI)

여러 어노테이션을 통해 Bean을 등록한 다음에는 Bean끼리 연결을 해야하는데 이때 사용하는 것이 의존성 주입(DI)이다.

🍀 @Autowired

• @Autowired는 스프링 컨테이너에서 필요한 타입의 Bean을 찾아 자동으로 주입하도록 요청한다.
• 객체를 새로 생성하는 것이 아니라 컨테이너가 관리하는 빈을 찾아 연결해준다.

예제 코드

@RestController
public class UserController {

    @Autowired
    private UserService userService;
}

• 스프링은 UserService타입의 Bean을 찾아 userService 필드에 넣어준다.

의존성 주입 방법

1. 생성자 주입
2. 필드 주입
3. Setter 주입

🍀 생성자 주입

• 생성자를 통해 필요한 Bean을 전달받는 방식
• 객체 생성 시 필요한 의존성을 주입
• final 필드 사용 가능
• 필수 의존성이 누락되면 객체를 정상적으로 생성 불가
• 생성자가 하나라면 @Autowired 생략 가능

@RestController
public class MemoController {

    private final MemoService memoService;

    @Autowired
    public MemoController(MemoService memoService) {
        this.memoService = memoService;
    }
}

• Controller 객체가 생성되는 시점에 Serivce를 전달받는다.

✨ [참고] @RequiredArgsConstructor

• @RequiredArgsConstructor는 final 필드와 @NonNull 필드를 매개변수로 가지는 생성자를 자동으로 만들어준다.

@RestController
@RequiredArgsConstrucutor
public class MemoController {

    private final MemoService memoService;

}

🍀 필드 주입

• 필드에 직접 @Autowired를 붙여 주입받는 방식
• final 필드에 일반적인 필드 주입을 적용 불가
  • 필드 의존성 주입은 객체 생성 후 수행(리플렉션)되므로 객체가 생성될 때 초기화되어야 하는 final과 충돌
• 의존성이 클래스 내부에 숨겨져 있음 - 생성자에 노출X, 필드 내부에 선언
• 따라서 스프링 없이 객체를 직접 생성하면 해당 필드가 null

@RestController
public class MemoController {

    @Autowired
    private MemoService memoService;
}

MemoController controller = new MemoController(); // 이때 memoService는 null

🍀 Setter 주입

• Setter 메서드를 통해 의존성을 전달받는 방식
• 스프링이 객체를 생성한 후 set..()를 호출해서 주입
• 객체 생성 이후 의존성 주입되므로 의존성을 나중에 변경할 수 있음
• final 사용 불가
• 필수가 아닌 선택적 의존성을 설정할 때 활용할 수 있음

@RestController
public class MemoController {

    private MemoService memoService;

    @Autowired
    public void setMemoService(MemoService memoService) {
        this.memoService = memoService;
    }
}

생성자 주입이 권장되는 이유

1. 필수 의존성 보장

필수 의존성 없이 객체를 생성하는 것을 방지할 수 있음

2. final 사용 가능

final 필드는 한 번 초기화되면 다른 객체로 재할당이 불가해, 의존성이 실수로 변경되는 것을 방지 할 수 있음 - Setter 주입은 변경이 가능

3. 기타

• 테스트 편리
• 순환 참조 조기 발견

📍 전체 흐름 다시 정리

@SpringBootApplication
        │
        └── @ComponentScan
                  │
                  ↓
        Component Scan 수행
                  │
                  ↓
@Component / @Controller / @RestController
@Service / @Repository 클래스 발견
                  │
                  ↓
              Bean 생성
                  │
                  ↓
          ApplicationContext
          ┌─────────────────┐
          │ Bean 관리       │
          │ Bean 조회       │
          │ 의존성 관리     │
          └─────────────────┘
                  │
                  ↓
       생성자 주입 / @Autowired
                  │
                  ↓
           Bean 간 의존성 연결

• Optional<T>는 값이 있을 수도 있고, 없을 수도 있는 상황을 표현하는 타입
• null로 인한 (NPE)를 안전하게 처리 위해 제공되는 래퍼 클래스
• 실제 객체를 포장하는 상자에 비유

Optional 생성 방법

• Optional.empty(): 빈 Optional 객체 생성
• Optional.of(value): 값이 있는 Optional 객체를 생성(만약 value가 null이면 NPE 발생)
• Optional.ofNullable(value): value가 null일 수도 아닐 수도 있을 때 사용, null이면 빈 Optional을 반환

Optional<String> empty = Optional.empty();
Optional<String> name = Optional.of("의연");
Opitonal<String> unknown = Optional.ofNull(null);

Optional 처리 방법

값 확인

• isPresent(): Optional 내부에 값이 있으면 true, 없으면 false를 반환
• isEmpty(): Optional 내부에 값이 없으면 true, 있으면 false를 반환

if (optional.isPresent()) {
    System.out.println(optional.get());
}

if (optional.isEmpty()) {
    System.out.println(optional.get());
}

값 꺼내기

• get(): Optional 내부의 값을 반환, 없으면 NoSuchElementException 발생
• orElse(value): Optional 내부에 값이 있으면 반환하고, 없으면 전달한 value를 반환
• orElseGet(...): Optional 내부에 값이 있으면 반환하고, 없으면 전달한 함수를 실행하여 그 결과를 반환
• orElseThrow(...): Optional 내부에 값이 있으면 반환하고, 없으면 지정한 예외를 발생
  • Spring Data JPA의 findById()는 Optional을 반환

String name = optional.get();
String name = optional.orElse("Guest");
String name = optional.orElseGet(() -> "Guest");
User user = userRepository.findById(id)
        .orElseThrow(() -> new IllegalArgumentException("사용자를 찾을 수 없습니다."));

값 처리

• ifPresent(...): Optional 내부에 값이 있을 때만 전달한 동작을 실행

optional.ifPresent(name -> {
    System.out.println(name);
});

• 계층 간 데이터를 전달하기 위해 사용하는 객체로, 사용하는 이유는
  • 데이터 전달
  • 데이터 캡슐화 : Entity를 직접 노출하지 않고 필요 데이터만 전달
  • 보안 : 민감한 정보가 응답에 포함되는 것을 방지
  • 유효성 검증 : @NotNull, @NotBlack 등으로 요청 데이터 검증
  • 유지보수 : Entity 구가 변경되어도 API의 요청/응답 구조를 독립적 관리

DTO 작성 방법 : Class vs Record

Class

@Getter
@Setter
@NoArgsConstructor
@AllArgsConstructor
public class UserRequestDto {

    private String name;
    private int age;
}

• 필드 값 변경 가능(Setter사용 시)
• 생성자, Getter, Setter등을 직접 정의하거나 Lombok으로 생성
• 상속 가능(final이 아닌 경우)
• 복잡한 객체 구조나 값 변경이 필요한 경우 적합

Record

public record UserRequestDto(
    String name,
    int age
) {}

• private final 필드 자동 생성
• 생성자, 접근자 equals(), hashCode(), toString() 자동 생성
• Setter가 없으며 생성 이후 필드 값 변경 불가 - 불변
• 다른 클래스 상속 불가
• 코드가 간결하며 데이터 전달 목적에 적합

toEntity(), from() 메서드

record타입으로 DTO를 작성한다면 toEntity()와 from() 메서드를 작성할 수 있다. 둘 다 DTO ↔ Entity 변환 책임을 DTO 안에 두는 패턴이다.

toEntity()

• Request DTO를 Entity로 변환하는 메서드
• 클라이언트 요청 JSON → Dto.toEnity(); → Entity
• Entity 클래스 생성자에 @Builder를 붙여 함께 사용함

Memo.java

    @Builder
    public Memo(String username, String title, String contents) {
        this.username = username;
        this.title = title;
        this.content = content;
        this.deleteStatus = false;  // 명시용(boolean타입 기본값: false)
    }

MemoCreateRequest.java

public record MemoCreateRequest(
        @NotBlank(message = "사용자 이름은 필수입니다.")
        String username,

        @NotBlank(message = "제목은 필수입니다.")
        String title,

        @NotBlank(message = "내용은 필수입니다.")
        String contents
) {
        public Memo toEntity(){
                return Memo.builder()
                        .username(username)
                        .title(title)
                        .contents(contents)
                        .build();
        }
}

from()

• Entity를 Response DTO로 변환하는 메서드
• Entity → Entity.from(entity) → 클라이언트 응답 JSON
• from() 메서드는 정적 팩토리 메서드

public record MemoResponse(
        Long id,
        String username,
        String titile,
        String content
) {
    public static MemoResponse from(Memo memo){
        return new MemoResponse(
                memo.getId(),
                memo.getUsername(),
                memo.getTitle(),
                memo.getContent()
        );
    }
}

✨ [참고] 정적 팩토리 메서드

• 정적 팩토리 메서드는 new 대신 객체를 생성해서 반환해주는 static 메서드
• 객체를 만들기 위한 메서드로 아직 객체가 존재하지 않기 때문에 static메서드로 만들어
• 객체 없이 클래스 자체에서 호출*할 수 있도록 함

• Gradle 은 빌드 자동화 시스템으로, 작성한 Java코드를 설정에 맞게 자동으로 빌드해준다.
• 여기서 빌드란, 소스코드를 실행 가능한 결과물로 만드는 과정이다. - .jar 파일

build.gradle

• Gradle 기반의 빌드 스크립트(groovy, kotlin 언어로 작성)
• 소스 코드를 빌드하고 라이브러리들의 의존성을 쉽게 관리하도록 한다.

🍀 WS(Web Server) / WAS(Web Application Server)

WS와 WAS 관련 포스팅 바로가기

WS(Web Server)

• 클라이언트의 요청에 정적 컨텐츠 응답
• 대표적으로 Apache, Nginx

WAS(Web Application Server)

• 클라이언트의 요청에 동적 컨텐츠 생성 및 비즈니스 로직 실행
• WS의 기능을 WAS에서도 처리 가능
• 대표적으로 Apache Tomcat, JBoss

✨ [참고] WS와 WAS의 협력 관계

대부분 실무에서는 WS와 WAS를 함께 사용하는데, 웹 서버가 앞단에서 정적 요청을 먼저 처리하고 동적 처리가 필요할 때만 WAS로 넘겨 서버 과부하를 방지한다.

🍀 Spring MVC / Front Controller패턴 / Dispatcher Servlet

🍀 정적 페이지 vs 동적 페이지

템플릿 엔진 유무에 따른 HTML 처리

• templates/ : 서버에서 데이터를 적용해 렌더링하는 View
• static/ : 별도의 렌더링 없이 그대로 제공하는 정적 리소스

예제코드

@Controller
public class HtmlController {

    @GetMapping("/html/hello")
    public String hello() {
        return "hello";
    }
}

템플릿 엔진이 있는 경우

HTTP 요청
   ↓
DispatcherServlet
   ↓
Controller
   ↓
return "hello"
   ↓
ViewResolver
   ↓
Template Engine
   ↓
templates/hello.html
   ↓
HTML 응답

템플릿 엔진이 없는 경우

HTTP 요청
   ↓
DispatcherServlet
   ↓
Controller
   ↓
정적 리소스 처리
   ↓
Static Resource Handler
   ↓
static/hello.html
   ↓
HTML 응답

@ResponseBody와 Jackson 라이브러리, ObejectMapper까지

Servlet

Servlet은 자바에서 HTTP 요청과 응답을 처리하기 위한 서버 측 기술이고 실제 코드에서는 Servlet 규약을 따르는 클래스를 만들고 서블릿 컨테이너가 그 클래스의 객체를 생성해서 요청을 처리한다.

🍀 기술

• 서블릿에 대한 가장 넓은 의미로, 자바 웹 서버에서 HTTP 요청을 처리하기 위한 표준 기술/규악이다.

클라이언트 요청
   ↓
Servlet 기술
   ↓
Java 코드로 요청 처리
   ↓
응답

🍀 클래스

• 실제 코드로 작성할 때는 보통 HttpServlet을 상속한 클래스를 작성한다.

public class HelloServlet extends HttpServlet {

    @Override
    protected void doGet(
            HttpServletRequest req,
            HttpServletResponse resp
    ) {
        // 요청 처리
    }
}

• 이런 클래스를 "서블릿 클래스"라고 부르며, 서블릿으로 동작하도록 작성한 자바 클래스이다.

🍀 객체

• 서버가 실행되면 Tomcat같은 서블릿 컨테이너가 서블릿 클래스(HelloServlet)의 객체를 생성한다.
• 실제로 개발자가 직접 관리하지 않고, Tomcat이 생성/관리한다.

GET /hello 요청
    ↓
Tomcat
    ↓
HelloServlet 객체
    ↓
doGet()

✨ 전체 흐름 정리

Servlet
= 자바 웹 요청 처리 기술/규약
        ↓

HttpServlet
= Servlet 규약을 편하게 구현하도록 제공되는 클래스
        ↓

HelloServlet
= 개발자가 작성한 Servlet 클래스
        ↓

new HelloServlet()
= Tomcat이 생성한 Servlet 객체
        ↓

HTTP 요청이 오면
doGet(), doPost() 등을 호출

💚 다양한 요청 처리 방식

@Controller vs @RestController

SSR 방식이 아닌 이상 Spring MVC 패턴에서 Model과 View의 역할을 FE가 처리함에 따라 BE는 데이터만 내려주게 된다. - JSON 형식

• @Controller : 전통적인 Spring MVC의 컨트롤러, View를 반환하기 위해 사용
• @RestController : @Controller + @ResponseBody
• @ResponeBody :
• Controller 메서드가 반환한 Java 객체를 HTTP 응답 Body*에 담아서 보내는 어노테이션 Java 객체 → JSON

✨[참고] @RequesetBody

• @RequestBody :
• HTTP 요청 Body에 담겨온 데이터를 Java 객체로 변환*해서 받는 어노테이션 JSON → Java객체

✨[참고] HttpMessageConverter와 Jackson라이브러리 Spring에서 JSON ↔ Java 실제 변환 작업은 내부의 HttpMessageConverter가 하고, JSON 변환에는 기본적으로 Jackson 라이브러리가 사용된다

@RequestMapping

• @RequestMapping 은 특정 URL 요청을 Controller의 클래스/메서드에 연결해준다.

사용법1

@ResController
@RequestMapping("/users)
public class UserController{

    @GetMapping    
    @PostMapping 
    @PutMapping 
    @PatchMapping
    @DeleteMapping

}

사용법2

@RestController
public class UserController{

    @RequestMapping(value = "/users", method = RequestMethod.GET)
    public void getUser(){
        ...
    }
}

💚 데이터 전달 방식과 어노테이션

클라이언트 → 서버 데이터 전달 방식

• @RequestParam은 디폴트가 required=true 이므로 false 설정을 해주지 않으면 필수값

✨[참고] 쿼리 파라미터 vs 경로 변수

• 쿼리 파라미터(@RequestParam) : URL 경로 ? 뒤에 오는 조건값(선택적) 검색, 필터링, 정렬, 페이징 용도 예시 : /users?id=1

• 경로 변수(@PathVariable) : URL 경로 자체에 값이 포함되는 필수값 특정 리소스를 식별하기 위해 사용 예시 : users/1

💚 DTO를 record로 작성기

record 는 데이터 전달 목적의 객체를 간결하게 만들기 위한 문법으로 DTO의 성질과 부합한다. 또한 record는 내부 필드가 private final이기 때문에 불변을 보장한다.

public record UserRequest(
    String name,
    int age
) { }

위와 같이 record를 작성하면 자바가 자동으로 아래 기능을 만들어준다.

• 생성자
• getter 역할 메서드
• equals()
• hashCode()
• toString()

✨[참고] class vs record

💚 Docker

도커는 소프트웨어 개발과 배포를 도와주는 컨테이너 기술로 애플리케이션을 빌드, 배포, 실행하는 과정을 쉽게 관리하게 해준다.

Container

• 애플리케이션과 그 실행 환경을 함께 패키징하여 어디서든 동일하게 실행될 수 있도록 하는 기술

Docker Image = 게임 CD

• 코드, 라이브러리, 설정 등을 포함하고 있는 읽기 전용(Read-only) 템플릿 - 변경 불가
• 실행에 필요한 모든 것을 담고 있는 정적 파일(설계도)
• ‼️하나의 이미지로 여러 개의 컨테이너를 만들 수 있다.

Docker Container = 실행되고 있는 게임

• 도커 이미지를 실행(Run)한 상태로 독립된 격리 프로세스
• 이미지를 실제로 실행한 인스턴스

Docker File

• 도커 이미지를 생성하기 위한 설정 및 명령어 템플릿 파일

Dockerfile 작성
   ↓
$ docker build
   ↓
Docker Image 생성
   ↓
$ docker run
   ↓
Docker Container 생성 및 실행

데이터베이스

데이터 무결성(Data Integrity)

• 엔티티 무결성
  • 각 행을 유일하게 식별할 수 있어야 한다.
  • PK는 중복❌, NULL❌
• 참조 무결성
  • 테이블 간 관계가 올바르게 유지되어야 한다.
  • FK는 실제로 존재하는 PK값을 참조해야 한다.
• 도메인 무결성
  • 컬럼에 들어가는 값은 정해진 데이터 타입, 범위, 조건을 만족해야 한다.

DROP vs DELTE vs TRUNCATE

3아키텍처 레이어

모든 데이터 클래스는 getter가 필수 스프링 내부적으로 객체를 조작할 때 getter를 사용

영속성 컨텍스트는 트랜잭션 내에서 동작 @Transactional 이 붙이면 그 내부 코드는 트랜잭션으로 관리 및 영속성 컨텍스트가 동작

1. Spring 시작하기

💚 HTTP

HTTP란,

클라이언트와 서버가 웹에서 데이터를 주고받기 위해 사용하는 프로토콜

HTTP 특징

• 클라이언트-서버 구조
  • Request-Response 구조
• Stateless(무상태) 프로토콜
  • 서버가 클라이언트의 상태를 보존❌
  • 장점: 서버 확장성이 높음(스케일 아웃)
  • 단점: 클라이언트가 추가 데이터 전송
• 비연결성
  • '하나의 요청과 응답이 독립적인가?'
• HTTP 메세지
• 단순함
• 확장 가능

💚 Servlet

Servlet이란,

자바 진영에서 HTTP 요청을 받아 처리하고 HTTP 응답을 만들어주는 객체 예를 들어 GET 요청은 HttpServlet의 doGet() 메서드가 처리한다.

Servlet 역할

• 요청 데이터 읽기
• 필요한 로직 실행
• 응답 데이터 만들기

즉, 요청 처리 담당

💻 예제코드

@WebServlet("/hello")
public class HelloServlet extends HttpServlet {

    @Override
    protected void doGet(
        HttpServletRequest req,
        HttpServletResponse resp
    ) throws IOException {

        resp.getWriter().print("Hello");
    }
}

• @WebServlet : 특정 URL 요청을 어떤 Servlet 클래스가 처리할지 연결해주는 어노테이션
• HttpServletRequest : 클라이언트가 서버로 보낸 HTTP 요청 정보를 담고 있는 객체
• HttpServletResponse : 서버가 클라이언트에게 보낼 HTTP 응답을 만들기 위한 객체

Servlet Container란,

Servlet을 실행하고 관리해주는 환경으로 대표적으로 Tomcat이 있다.

Servlet Container의 역할

• HTTP 요청 받기
• URL에 맞는 서블릿 찾기
• HttpServletRequest, HttpServletResponse 객체 생성
• 메서드 호출(GET 요청이면 doGet();)
• 서블릿 객체 생성 및 생명주기 관리
• 서블릿이 만든 응답을 클라이언트에게 전송

동작 순서

클라이언트가 HTTP 요청을 보내면 서블릿 컨테이너가 요청을 받은 뒤, 해당 요청을 처리할 서블릿을 찾아 실행한다.

Client
  ↓
HTTP Request
  ↓
Tomcat(Servlet Container)
  ↓
Servlet 찾기, 실행
  ↓
HTTP Response

✨ Servlet은 개발자가 아닌 Servelt Container가 Servlet의 실행과 생명주기를 관리한다.

@ServletComponentScan

스프링 부트에서 서블릿 관련 어노테이션이 붙은 클래스를 찾아 Tomcat같은 서블릿 컨테이너에 등록해주는 어노테이션

💻 예제코드

@SpringBootApplication
@ServletComponentScan
public class DemoApplication {

    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
    }
}

스프링 부트가 해당 패키지와 하위 패키지를 스캔하면서

• @WebServlet
• @WebFilter
• @WebListener

가 붙은 클래스를 찾아 서블릿 컨테이너에 등록한다

💚 CSR, SSR, SEO

CSR(Client Side Rendering)

브라우저 요청
    ↓
서버에서 HTML + JavaScript 전달
    ↓
브라우저에서 JavaScript 실행
    ↓
API를 통해 필요한 데이터 요청
    ↓
화면 렌더링

SSR(Server Side Rendering)

⚙️ 동작 방식

브라우저 요청
    ↓
서버에서 데이터 조회
    ↓
서버에서 HTML 생성
    ↓
완성된 HTML 전달
    ↓
브라우저에서 화면 표시

💚 Spring MVC

2장. 두 가지 가치에 대한 이야기

포트폴리오 프로젝트도 부족하고 일상에서 아이디어를 얻은 김에 모바일 오더 앱 서비스를 만들어서 DX를 해보고자 한다.

이것도 미루다 미루다 새벽에 노트북 토닥이는 김에 메인 로고, 서브 로고, 앱 아이콘, 컬러 팔레트를 GPT로 뽑아냈다.

이미지라도 올려서 서비스 첫 포스팅을 게시하고 열심히 개발해보좌 ~.. 무기력 우울증 쉬었음 청년의 취뽀를 위하여 !! 💚💛🧡🤍

🥛메인 로고

서브로고

앱 아이콘

🎨컬러 팔레트

HEX 코드

CSS 변수

:root {
  --color-primary: #0F5A40;
  --color-secondary: #1E7B57;
  --color-accent: #5E9F78;
  --color-muted: #B7C8B3;
  --color-background: #F2EFE4;
}

헥사고날 아키텍처와 DDD

헥사고날 아키텍처와 DDD는 둘 다 도메인(비지니스 로직)을 중심에 둔다는 공통점이 있지만, 헥사고날 아키텍처는 "시스템을 어떻게 계층화하고 의존성을 배치할까?"에 초점 DDD는 "도메인을 어떻게 모델링할까?"에 초점

헥사고날 아키텍처

Hexagonal Architecture

🍀 헥사고날 아키텍처의 필요성

기존에 주로 개발하던 계층형 구조는 단순하고 직관적이다.

• Controller : 외부 요청을 받는 역할
• Service : 비지니스 로직
• Repository : DB 접근

하지만 계층형 구조의 문제점은 의존성 방향에 있다. Controller → Service → Repository 순서로 아래로 내려가야 하고, Service 레이어는 DB같은 외부 인프라에 강하게 의존하게 된다. 따라서 비지니스 로직이 DB나 프레임워크에 종속되는 상황이 발생할 수 있다 ! !

🍀 헥사고날 아키텍처의 핵심 아이디어

• 비지니스 로직(=도메인)을 중심에 둔다.
• DB, UI, 외부 API 등은 바깥쪽에 둔다.
• 도메인이 바깥쪽 인프라에 직접 의존하지 않는다.

따라서 어떤 프레임워크나 DB를 쓰더라도 비지니스 로직은 흔들리지 않는게 핵심이다.

• [규칙서] Domain : 순수한 핵심 규칙(비지니스 로직), DB/웹/프레임워크를 모름
• [지시자] Application : 유스케이스(Service 역할), Domain을 이용해 시나리오 실행
• [계약서] Port : Application이 외부에 기대는 인터페이스(Ex. UserRepository)
• [실행자] Adapter : Port를 구현한 구체체(Ex. JPA 기반 JpaUserRepository)

즉, 헥사고날 아키텍처는 비지니스 로직을 외부 기술에서 독립시키는 구조

도메인 주도 설계

DDD, Domain-Driven Design

🍀 DDD의 필요성

보통 개발을 하면 발생하는 문제점:

• 코드가 기능 단위로만 작성 → 시간이 지나면 스파게티 코드
• 비지니스 규칙이 흩어져서 어디서 처리되는지 불명확
• 요구사항 변경 시 수정해야 할 코드가 여러 군데

DDD는 도메인(비지니스 문제)를 중심에 두고, 이를 코드에 직접 반영하려는 접근 (뭔 소릴까 ..?)

🍀 DDD의 핵심 아이디어

• 도메인에 집중한다.
  • 도메인 = 해결하려는 문제 영역
  • Ex. 따맵 : 자전거, 대여소, 사용자 / 은행 시스템 : 계좌, 송금, 대출
• 유비쿼터스 언어
  • 개발자, 기획자, 현업 담당자 모두 같은 용어를 사용
  • '결제 승인'이라는 말을 코드에도 그대로 approvePayment()로 반영

🍀 DDD의 기본 빌딩 블록

DDD에서는 코드를 도메인 개념에 맞게 나눈다.

(1) Entity (엔티티)

• 고유한 ID로 구별되는 객체
• 값이 변해도 동일성을 유지
• Ex. User(id=1, name="의연") → 이름 바뀌어도 id=1이면 같은 User

(2) Value Object (값 객체)

• 속성 값 자체로만 의미가 있는 객체 (ID 없음❌)
• 불변(immutable)으로 다루는 게 일반적
• Ex. Money(1000, "KRW"), Email("velog@gmail.com")

(3) Aggregate

• Entity + VO 묶음 → 하나의 비즈니스 단위
• 항상 일관성을 유지해야 함
• 대표 엔티티 = Aggregate Root
• Ex. Order (root) → OrderItem(entity), Money(VO)

(4) Repository

• Aggregate 저장/조회 담당
• DB 접근을 추상화 (interface)
• Ex. OrderRepository.save(order)

(5) Domain Service

• 특정 Entity 하나에 속하지 않는 비즈니스 규칙을 담는 곳
• Ex. 환율 계산, 결제 승인

어렵땅 ...

• ✅ 따릉이 대여소 API 호출 → DB 저장
• ✅ 신규 및 폐쇄 대여소를 고려해 하루 1회 스케줄링

외부 API를 호출하려면?

우선 따릉이 대여소 API를 호출해 우리쪽 DB에 저장하는게 첫 번째 목표였다. 외부 API를 호출하는 방법은 대표적으로 5가지가 있는데, 그 중에서 가장 권장되는 방식인 WebClient를 사용했다.

✨ 외부 API를 호출할 때 사용하는 HTTP Client 정리 포스팅

1. application.yml 작성

application.yml은 스프링 부트 애플리케이션이 동작할 때 필요한 설정 값을 선언하는 곳으로,
따릉이 대여소 API를 호출하는 baseUrl과 key 작성했다. (이 외에 서버, DB, JPA, 로그 설정 등을 yml에 작성한다.)

bikeseoul:
  static:
    key: ${bikeseoul.static.key}
    baseUrl: http://openapi.seoul.go.kr:8088/{apiKey}/json/tbCycleStationInfo

  realtime:
    key: ${bikeseoul.realtime.key}
    baseUrl: http://openapi.seoul.go.kr:8088/{apiKey}/json/bikeList

✨ 발급받은 key는 application-secret.yml에 별도 저장

2. @ConfigurationProperties

@ConfigurationProperties 어노테이션은 application.yml에 정의된 설정 값을 자바 객체의 필드로 자동 바인딩해주는 어노테이션이다.

즉, yml의 설정 값 → @ConfigurationProperties가 붙은 클래스의 객체로 매핑 → 필요한 클래스(외부 API를 호출하는 클래스)에서 주입받아 사용

@Component
@ConfigurationProperties(prefix = "bikeseoul.static")
@Getter
@Setter
public class StationProperties {
    private String key;
    private String baseUrl;
}

✨ 추후에 StationApiClient에서 StationProperties를 주입받아 외부 API 호출에 사용

3. WebClient 설정

외부 API를 호출하기 위해서는 다른 서버로 HTTP 요청을 보내고 응답을 받아오는 라이브러리가 필요한데, 그 중 하나가 WebClient다.

✨ 스프링에서는 재사용 가능한 객체(빈)는 직접 생성하지 않고, @Configuration에서 설정해놓고 필요할 때 의존성 주입을 통해 사용한다.

@Configuration        // 설정 클래스 명시
public class StationConfig {

    @Bean            // 스프링 빈 객체 등록 대상
    public WebClient.Builder webClientBuilder() {
        return WebClient.builder()
                .exchangeStrategies(ExchangeStrategies.builder()
                        .codecs(configurer -> configurer
                                .defaultCodecs()
                                .maxInMemorySize(10 * 1024 * 1024)) // 10MB
                        .build());
    }
}

4. 외부 API 응답 DTO 작성

외부 API를 호출한 뒤에 받는 응답

5. 외부 API 호출 클라이언트 구현

6. DB 저장

스케줄링

동시성 제어와 락(Lock)

♻️동시성 제어(Concurrency Control)

• 동시성 제어란 여러 트랜잭션에 동시에 같은 데이터베이스에 접근할 때,
• 데이터의 정합성과 일관성을 보장*하는 기법
• 데이터베이스는 성능을 위해 동시 처리(병행 실행)를 최대한 허용하지만,
• 동시에 실행되면 문제가 발생*할 수 있음

대표적인 동시성 문제1 - Dirty Read

• 다른 트랜잭션이 아직 커밋하지 않은 변경 데이터를 읽음
• 만약 T1이 롤백한다면, T2가 읽은 var = 100은 존재하지 않는 값이 되버림

대표적인 동시성 문제2 - Non-Repeatable Read

• 한 트랜잭션에서 같은 데이터를 두 번 읽을 때 값이 다름
• 첫 번째 SELECT와 두 번째 SELECT 사이에 다른 트랜잭션이 값을 변경

대표적인 동시성 문제3 - Phantom Read

• 조건에 맞는 행의 개수나 집합이 바뀜
• 첫 번째 SELECT 후 다른 트랜잭션이 INSERT하여 두 번째 SELECT 결과가 달라짐

락(Lock)의 필요성

• 트랜잭션 간 동시 접근으로 인한 데이터 충돌을 방지
• DBMS는 동시성과 일관성 사이의 균형을 유지
  • 락을 너무 강하게 걸면 → 동시성이 떨어져 성능 저하
  • 락을 너무 약하게 걸면 → 데이터 정합성이 깨짐
• 필요한 데이터 범위와 작업 성격에 따라 락을 선택적으로 걸어줌

🔒락의 두 가지 기본 형태

공유 락(S Lock, Shared Lock)

• 읽기 전용 락
• 여러 트랜잭션이 동시에 같은 데이터에 공유 락을 걸 수 있음
• 공유 락이 걸린 데이터에 쓰기(UPDATE/DELETE)는 불가능
• 주로 SELECT .. LOCK IN SHARE MODE 같은 읽기 작업에서 사용

T1: SELECT * FROM account WHERE id = 1 LOCK IN SHARE MODE;      -- S Lock 획득
T2: SELECT ... LOCK IN SHARE MODE;                              -- 가능
T3: UPDATE account SET balance = 0 WHERE id = 1;                 -- 대기

쓰기 락(X Lock, Exclusive Lock)

• 읽기/쓰기 모두 차단하는 락
• 해당 데이터는 오직 락을 가진 트랜잭션만 읽고 쓸 수 있음
• 주로 UPDATE, DELETE, INSERT, 또는 SELECT ... FOR UPDATE 시 걸림
• 데이터 정합성을 위해 읽기조차 막음(Dirty Read 방지)

💡SELECT .. FOR UPDATE는 트랜잭션에서 SELECT한 행에 대해 배타 락을 거는 문법으로 읽는 동시에 그 행을 수정할 권리를 독점(즉, SELECT 한 뒤에 UPDATE 할거야!)

T1: UPDATE account SET balance = 0 WHERE id = 1;                   -- X Lock 획득
T2: SELECT ... LOCK IN SHARE MODE;                                 -- 대기
T3: UPDATE account SET balance = 100 WHERE id = 1;                 -- 대기

⏳ 락과 데드락의 관계

• 락(Lock)은 동시성 제어를 위해 필요하지만, 잘못 사용되면
• 서로가 서로의 락을 기다리는 교착 상태(Deadlock)*를 만들 수 있음
• 데드락은 두 개 이상의 트랜잭션이 서로가 보유한 자원을 기다리며 무한 대기에 빠지는 상황

T1: account.id = 1 행의 S Lock → 그 다음 account.id = 2 행을 X Lock 하려고 함
T2: account.id = 2 행의 S Lock → 그 다음 account.id = 1 행을 X Lock 하려고 함

데드락 해결/예방 방법1 - 트랜잭션 설계 단계에서 예방

• 항상 동일한 순서로 자원을 잠금(락 획득 순서를 일관적으로 정해둠) (Ex. 모든 트랜잭션에서 1번 데이터, 2번 데이터 순으로 락을 획득)
• 트랜잭션을 최소화 해 락을 오래 점유하지 못하도록 함
• 조건절 최적화, 범위 줄이기를 통해 불필요한 락 범위 줄이기

데드락 해결/예방 방법2 - DB 설정으로 완화

• Lock Timeout 설정 : 일정 시간 기다렸다가 락이 안풀리면 ROLLBACK
• 격리 수준 낮추기 : READ COMMITED나 MVCC를 활용해 불필요한 대기 감소

데드락 해결/예방 방법3 - 데드락 감지&자동 해제

• InnoDB, PostgreSQL, Oracle 등 대부분 DB는 주기적으로 데드락 감지 스레드가 돌아감
• 감지 시 둘 중 하나의 트랜잭션을 강제 ROLLBACK

NEXT STEP

트랜잭션에 대해서 더 깊게 학습이 필요하다 ..!

🔗 데이터베이스 커넥션

• 서버는 DB와 통신할 때 Connection 이라는 연결 통로가 필요하다.
• 즉, 커넥션은 애플리케이션 서버와 데이터베이스 사이의 통신선
• 커넥션을 통해 SQL 쿼리를 전송하고 결과를 받아온다.
• 즉 애플리케이션과 DB 사이의 연결 세션으로, 쿼리를 보내고 응답을 받기 위한 통신 통로
• 하나의 커넥션은 DB와의 TCP 커넥션 + 세션 컨텍스트를 의미한다.(TCP + DB 세션 연결)
• 커넥션을 열고 닫는 데는 네트워크 연결, 인증, 세션 설정 등의 작업으로 비용이 크다.

커넥션의 특징과 문제점

1. 비싼 비용💸

• 매 요청 마다 커넥션을 열고 닫으면, DB와 네트워크에 부하가 크다.

2. 제한된 커넥션 수🚫

• DB 서버는 동시에 처리할 수 있는 커넥션 수가 정해져 있어, 웹 서버 트래픽이 몰릴 때 커넥션이 부족한 문제가 발생할 수 있다. (Connection refused, Too many connections)

🔗 커넥션 풀

• 커넥션의 특징/문제점으로 인해 필요한 개념이 Connection Pool이다.
• 커넥션 풀은 미리 커넥션을 만들어두고 재사용해서 커넥션 생성/삭제 비용을 줄이고, 커넥션 수를 안정적으로 관리하는 방식이다.
• 대표적인 구현체로는 Java/Spring의 HikariCP - 자주봤죵~?

커넥션 풀 주요 설정

• maximumPoolSize : 풀에 유지할 최대 커넥션 수
• minimumIdle : 유휴 상태로 유지할 커넥션 수
• connectionTimeout : 커넥션을 못 얻어올 떄까지 기다릴 최대 시간
• idleTimeout : 유휴 커넥션을 얼마나 오래 유지할지
• maxLifetime : 커넥션 객체가 살아있을 수 있는 최대 시간

💡 커넥션 유휴 상태란 DB 커넥션이 열려있지만, 아무 작업도 하지 않는 대기 상태

커넥션 풀 작동 방식

• 서버 시작 시 DB 커넥션을 미리 일정 개수 열어둠
• HTTP 요청이 들어오면 풀에서 커넥션을 꺼내서 사용
• 처리 후 커넥션을 닫는게 아니라 풀에 반환

커넥션 누수

• 커넥션을 반환하지 않으면 누수가 발생해 커넥션 고갈 문제 발생
• 이슈 발생 시 Hikari Pool - Connection timeout, connection leak detected 경고

🍀 커넥션 풀을 사용하지 않는다면?

1. 매 요청마다 커넥션 생성/종료 → 성능저하

• 커넥션 생성 과정은
  1. TCP 소켓 연결
  2. DB 인증
  3. 세션 초기화
• 이 과정은 수 ms ~ 수백 ms 걸릴 수 있는 과정
• 매 HTTP 요청마다 이 과정을 반복하면 응답 속도가 급격히 느려짐
• TPS가 떨어져서 같은 서버 성능으로 처리할 수 있는 요청 수 감소

2. DB 부하 증가

• 매번 커넥션을 새로 만들면 DB 서버는 계속 새 세션을 생성/삭제해야 함
• 세션 생성/삭제도 DB의 CPU, 메모리 자원을 많이 소모
• 동시에 수백~수천 요청이 들어오면 DB가 세션 생성 처리만 하다가 병목 발생

3. 커넥션 폭주 & 제한 초과

• DB는 동시 접속 수(max_connections)가 제한됨
• 커넥션 풀 없이 무제한 생성은 순간적으로 DB 동시 접속 한도를 초과
• 결과적으로 Too many connections 오류로 서비스 전체 장애

4. 커넥션 재사용 불가 → 리소스 낭비

• 커넥션은 만들기 비싼 자원인데, 매번 만들고 바로 버리면 낭비
• 풀을 쓰면 한 번 만든 커넥션을 여러 요청이 재사용 가능
• 재사용이 없으면 네트워크, DB, CPU 낭비 + 응답속도 지연

❗ 이 외에도 커넥션 풀을 사용하지 않아 커넥션을 관리하지 않으면 확장성(Scalability) 문제, 장애 복구 및 안정성 저하 문제를 초래할 수 있음

정리

매일메일 스터디에서 커넥션 타임아웃(Connection Timeout)과 관련된 질문을 받았을 때, 명확한 답변을 하지 못했는데, 그 이유는 커넥션을 DB에 중점을 두고 생각했기 때문이다.

커넥션은 애플리케이션과 DB간의 통신선이라고 위에서 정리했는데, 그 통신의 기반이 TCP라는 부분을 간과했던 것 같다.

다시 정리하자면,

✅ 커넥션 = 애플리케이션 ↔ DB 간의 통신선 ✅ DB 커넥션은 TCP 연결 + DB 세션 상태까지 포함한 개념 ✅ 애플리케이션과 DB의 통신 기반은 TCP(TCP 소켓 연결)

[애플리케이션]                  [DB 서버]
    |                               |
    | 1. TCP 연결 (소켓 open)       |
    |------------------------------>|
    |                               |
    | 2. DB 인증 & 세션 생성        |
    |------------------------------>|
    |                               |
    | ← 커넥션(=TCP + 세션) -------- |
    |                               |
    ▼                               ▼
 ┌─────────────────────────────────────────┐
 │             커넥션 풀(Connection Pool)  │
 │ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
 │ │Conn #1    │ │Conn #2    │ │Conn #3    │ │  ← 미리 만든 커넥션들
 │ │TCP + 세션 │ │TCP + 세션 │ │TCP + 세션 │ │
 │ └───────────┘ └───────────┘ └───────────┘ │
 └─────────────────────────────────────────┘
         ▲                 ▲
         |                 |
   요청 시 꺼내서 사용   요청 끝나면 반환

NEXT STEP

DB 세션을 공부해야겠다 ..!

각종 프로젝트에서 서비스를 개발하다보면 외부 API를 호출해야하는 일이 심심치 않게 발생하는데, 이렇게 Spring Boot에서 외부 API를 호출할 때 사용하는 다양한 Http Client에 대해 알아보자!

HTTP Client란?

• HTTP Client는 다른 서버(보통 HTTP 서버)로 HTTP 요청을 보내고, 응답을 받아오는 프로그램 또는 라이브러리를 의미한다.
• 다시 말해 Java나 Spring 진영에서 클라이언트 역할을 하는게 Http Client다.

HTTP Client의 작업

🌼1. RestTemplate(Deprecated 예정)

• 동기적 요청 처리
• Spring에서 오래된 기본 Http Client
• 사용법이 간단하지만 deprecated 예정 - WebClient로 대체되는 추세

@RestController
public class ApiController {

    private final RestTemplate restTemplate = new RestTemplate();

    @GetMapping("/call-api")
    public String callApi() {
        String url = "https://api.example.com/data";
        // 해당 url로 GET 요청
        ResponseEntity<String> response = restTemplate.getForEntity(url, String.class);
        return response.getBody();
    }
}

🌼2. WebClient

• 비동기(Reactive)& 논블로킹 지원 - Mono, Flux
• 동기 방식으로도 사용 가능 - .block()
• Spring이 권장하는 최신 방식

비동기 방식

@RestController
public class ApiController {

    private final WebClient webClient = WebClient.create();

    @GetMapping("/call-api")
    public Mono<String> callApi() {
        return webClient.get()                // GET 요청
                .uri("https://api.example.com/data")
                .retrieve()                    // 응답 처리
                .bodyToMono(String.class);    // Mono로 래핑된 결과
    }
}

동기 방식

@GetMapping("/call-api-blocking")
public String callApiBlocking() {
    return webClient.get()
            .uri("https://api.example.com/data")
            .retrieve()
            .bodyToMono(String.class)
            .block(); // 동기 방식
}

Mono가 모에요?

• Mono는 Reactor(비동기, 논블로킹 라이브러리)에서 제공하는 비동기 데이터 처리용 객체
• 0개 또는 1개의 데이터를 비동기적으로 반환

🌼3. HttpClient

• 동기 방식
• Apache HttpComponents, CloseableHttpClient
• Apache의 라이브러리 (spring-core에는 포함되지 않음❌) - 외부 의존성 필요
• 커넥션 풀, 타임아웃 등 세밀한 설정이 가능
• RestTemplate이나 WebClient의 하위 엔진으로도 사용됨

@RestController
public class ApiController {

    @GetMapping("/call-api-apache")
    public String callApiApache() throws IOException {
        CloseableHttpClient client = HttpClients.createDefault();
        HttpGet request = new HttpGet("https://api.example.com/data");
        CloseableHttpResponse response = client.execute(request);
        return EntityUtils.toString(response.getEntity());
    }
}

🌼4. OkHttp

• 비동기 방식, 동기 방식 모두 지원
• Square사에서 만든 경량 HTTP client - 외부 라이브러리 필요
• 안드로이드나 네이티브 자바에서 많이 사용
• 간결하고 빠름

@RestController
public class ApiController {

    private final OkHttpClient client = new OkHttpClient();

    @GetMapping("/call-api-okhttp")
    public String callApiOkHttp() throws IOException {
        Request request = new Request.Builder()
                .url("https://api.example.com/data")
                .build();
        try (Response response = client.newCall(request).execute()) {
            return response.body().string();
        }
    }
}

🌼5. RestClient

• 동기 방식
• RestTemplate의 진화 버전
• Java 17 이상의 HttpClient 기반
• 타입 세이프한 요청 방식, 간결한 코드
• Spring Boot 3.2 이상에서 정식 지원

@RestController
public class ApiController {

    private final RestClient restClient = RestClient.create();

    @GetMapping("/call-api-restclient")
    public String callApiRestClient() {
        return restClient.get()
                .uri("https://api.example.com/data")
                .retrieve()
                .body(String.class);
    }
}

🍀 Http Client의 동기/비동기 방식

동기 방식(RestTemplate, WebClient.block())

• 요청을 보낸 스레드는 응답이 올 때까지 대기
• 응답이 온 뒤에 다음 코드 를 실행
• 요청/응답이 순차적이고 직관적이지만, 많은 요청 처리 시 스레드 낭비 우려

String body = restTemplate.getForObject(url, String.class)
// ❗ 응답이 올 때까지 기다림(동기 방식)
// ❗ 이 다음 코드는 응답을 받은 후에 실행됨

비동기 방식(WebClient, Mono, OkHttp async, CompletableFuture)

• 요청을 보낸 후 스레드는 바로 다음 코드로 넘어가 실행
• 응답은 나중에 도착하고, 콜백이나 리액티브 방식으로 처리됨
• 응답이 나중에 오더라도 처리할 준비만 해두고, 그동안 CPU는 다른 일을 처리할 수 있어 효율적

WebClient.create()
    .get()
    .uri(url)
    .retrieve()
    .bodyToMono(String.class)
    .subscribe(body -> System.out.println("응답: " + body));
// ❗ 응답 기다리지 않고 바로 다음 코드 실행됨

🍀 Http Client별 동기/비동기 방식 정리

동기/비동기 방식에서 고민점

사용자가 서비스를 이용하는 UX적인 관점에서 비동기 방식으로 요청을 처리하는게 뭐가 있을까?

🍀 역할과 구현을 분리

• 역할과 구현으로 구분하면 단순해지고, 유연해지며 변경도 편리해진다.
• 역할과 구현의 분리에서 자바 언어의 다형성을 활용
  • 역할 = 인터페이스
  • 구현 = 인터페이스를 구현한 클래스, 구현 객체
• 객체를 설계할 때 역할과 구현을 명확히 분리
• 객체 설계 시 역할(인터페이스)을 먼저 부여하고, 그 역할을 수행하는 구현 객체 만들기

🍀 역할과 구현 분리의 장점

• 클라이언트는 대상의 역할(인터페이스)만 알면 된다
• 클라이언트는 구현 대상의 내부 구조를 몰라도 된다
• 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않는다
• 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다

🍀 객체의 협력이라는 관계부터 생각

• 혼자 있는 객체는 없다
• 수 많은 객체 클라이언트와 객체 서버는 서로 협력 관계를 가짐

🍀 다형성의 본질

• 인터페이스를 구현한 객체 인스턴스를 실행 시점에 유연하게 변경 가능
• 다형성의 본질을 이해하려면 협력이라는 객체 사이의 관계에서 시작
• 클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있음

🍀 [정리]역할과 구현의 분리

• 실세계의 역할과 구현이라는 컨셉 → 다형성을 통해 객체 세상에 적용
• 유연성, 변경 용이, 확장 가능한 설계
• 클라이언트에 영향을 주지 않는 변경 가능
• 인터페이스를 안정적으로 잘 설계하는 것이 중요

🍀 [한계]역할과 구현의 분리

• 역할(인터페이스) 자체가 변하면 클라이언트, 서버 모두에 큰 변경이 발생
• ✨ 인터페이스를 안정적으로 잘 설계하는 것이 중요

🍀 스프링과 객체 지향

• 다형성이 가장 중요, 스프링은 다형성을 극대화해 이용할 수 있도록 도와줌
• 제어의 역전(IoC), 의존관계 주입(DI)은 다형성을 활용해
  역할과 구현을 편리하게 다룰 수 있도록 지원

07. 좋은 객체 지향 설계의 5가지 원칙(SOLID)

OCP(개방 폐쇄 원칙), DIP(의존관계 역전 원칙)이 중요!

🍀 단일 책임 원칙, SRP(Single Responsibility Principle)

• 한 클래스는 하나의 책임만
  • 하나의 책임이라는 것은 모호하다
  • 클 수도, 작을 수도 있고 문맥과 상황에 따라 다르다
• ✨ 중요한 기준은 변경, 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른것
• 범위를 적절히 조절하는게 객체 지향 설계의 묘미

🍀 개방 폐쇄 원칙, OCP, Open Close Principle

• ✨ 소프트웨어 요소는 확장에는 열려있으나, 변경에는 닫혀있어야 한다.
• 다형성, 역할과 구현의 분리를 의미
• 인터페이스를 구현한 클래스를 하나 만들어서 새로운 기능을 구현

개방 폐쇄 원칙의 문제점

public class MemberService {
        private MemberRepository memberRepository = new MemoryMemberRepository();
}

public class MemberService {
 // private MemberRepository memberRepository = new MemoryMemberRepository();
        private MemberRepository memberRepository = new JdbcMemberRepository();
}

• MemberService 클라이언트가 구현 클래스(레포지토리를 new를 통해 생성)를 직접 선택
• 구현 객체(MemoryRepository → JdbcRepository)를 변경하려면 클라이언트 코드에 변경이 필요
• 다형성을 사용했지만 OCP 원칙을 지킬 수 없다.
  • 이 문제를 해결하려면 객체를 생성하고, 연관관계를 맺어주는 별도의 조립/설정자가 필요
  • 이 역할을 스프링 컨테이너가 해줌

🍀 리스코프 치환 원칙, LSP, Liskov Substitution Principle

• 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서,
• 하위 타입의 인스턴스로 바꿀 수 있어야 한다.*
• 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 것
• 다형성을 지원하기 위한 원칙
• 인터페이스를 구현한 구현체는 믿고 사용하려면 이 원칙이 필요

🍀 인터페이스 분리 원칙, ISP, Interface Segregation Principle

• 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다
• 인터페이스가 명확해지고, 대체 가능성이 높아진다.

🍀 의존관계 역전 원칙, DIP, Dependency Inversion Principle

• 추상화에 의존하되 구체화에 의존하면 안된다. - 의존성 주입은 이 원칙을 따르는 방법 중 하나
• 구현 클래스에 의존❌, 인터페이스에 의존⭕
• 역할에 의존하게 해야 한다는 것
• 클라이언트가 인터페이스에 의존해야 유연하게 구현체 변경 가능 구현체에 의존할 경우 변경이 매우 어려워짐

public class MemberService {
        private MemberRepository memberRepository = new MemoryMemberRepository();
}

public class MemberService {
 // private MemberRepository memberRepository = new MemoryMemberRepository();
        private MemberRepository memberRepository = new JdbcMemberRepository();
}

• 이 코드에서 MemberService는 인터페이스에 의존하지만, 구현 클래스도 동시에 의존한다.
  • 인터페이스 : MemberRepository
  • 구현 클래스 : MemoryMemberRepository, JdbcMemberRepository
• MemberService 클라이언트가 구현 클래스를 직접 선택(직접 의존)
  • MemberService가 구현 클래스의 내부 구조를 알고 있다

🍀정리

• 객체 지향의 핵심은 다형성
• 다형성만으로 쉽게 부품을 갈아끼우듯이 개발할 수 없다.
• 다형성만으로는 구현 객체를 변경할 때 클라이언트 코드도 함께 변경해야 한다.
• 다형성만으로는 OCP, DIP를 지킬 수 없다. 그래서 뭔가가 더 필요하다! - 스프링

08. 객체 지향 설계와 스프링

🍀 객체 지향과 스프링

• 스프링은 다형성 + OCP, DIP를 가능하도록 기술을 지원
  • DI : 의존관계, 의존성 주입
  • DI 컨테이너 제공 : 이 컨테이너 내부에서 객체 간 의존 관계 연결 및 주입
• 클라이언트 코드의 변경없이 기능 확장
• 쉽게 부품을 교체하듯이 개발

🍀 정리

• 모든 설계에 역할과 구현을 분리
• 이상적으로 모든 설계에 인터페이스를 부여
• 하지만 인터페이스를 도입하면 추상화라는 비용이 발생(한번 더 까봐야 된다)
  • ✅ 장점이 단점을 넘어설 때 선택
• 기능을 확장할 가능성이 없다면 구체 클래스를 직접 사용하고 향후 인터페이스 도입

프로세스(Process)란 컴퓨터에서 연속적으로 실행되고 있는 프로그램이다.
종종 스케줄링의 대상이 되는 작업(Task)이라는 용어와 거의 같은 의미로 쓰인다. - 위키백과

프로세스의 문맥(Context)

• CPU 수행 상태를 나타내는 하드웨어 문맥
• 프로세스의 현재 상태를 의미 - 뭘 해서 지금의 상태까지 왔는가?
• 특정 시점에서 어디까지 수행을 했는지 규명하는데 필요한 요소
• 프로세스의 문맥을 나타내기 위해서는 PC(Program Counter)가 가리키는 부분을 참조
  • PC는 CPU가 다음에 실행할 명령어의 주소를 저장하고 있는 레지스터
  • 현재 프로세스의 실행 위치(명령어)를 추적
• 프로세스의 문맥은 code, data, stack 의 상태를 저장함
  • 코드는 어디까지 수행? 어떤 데이터를 저장? 어떤 메서드를 호출?
• 프로세스는 실행 시 독립적인 주소 공간을 생성한 뒤
  CPU를 할당받으면 PC가 프로세스의 code 영역의 어느 한 부분을 가리키고,
  매 순간 명령어를 읽어 실행(레지스터에 값을 넣고 연산하고 저장하고 등)

프로세스 문맥의 구성요소

1. 하드웨어 문맥(Hardware Context)

프로세스가 CPU를 사용하던 상태를 저장한 정보

• PC(Program Counter) : 다음에 실행할 명령어의 주소
• Register : 현재 작업 중인 값들이 저장되어 있음

2. 주소 공간 문맥(Memory Context)

프로세스의 독립적인 메모리 공간 상태를 나타냄

• Code 영역 : 실행할 명령어
• Date 영역 : 전역 변수, 정적 변수
• Stack 영역 : 함수 호출, 지역 변수 등 실행 흐름과 관련된 정보

3. 커널 문맥(Kernel Context)

운영체제가 프로세스를 관리하기 위해 유지하는 정보

• PCB(Process Control Block) : 프로세스 ID, 상태, 우선순위 등 관리 정보
• Kernel Stack : 시스템 콜 처리 중에 사용하는 커널 스택
  • 프로세스마다 별도의 커널 스택이 존재
  • 시스템 콜 진입 시, PC는 사용자 영역이 아닌 커널 코드 영역을 가리킴

프로세스의 상태

• Running : CPU를 잡고 명령어를 수행 중인 상태
  • 운영체제의 상태를 Running으로 표현하지 않음
• Ready : (다른 조건을 모두 만족하고) CPU 할당을 기다리는 상태
• Blocked(wait, sleep) : CPU를 줘도 당장 명령어를 실행할 수 없는 상태
  • 자신이 요청한 이벤트(I/O 요청 등)가 즉시 만족되지 않아 대기 중인 상태
  • Ex. 디스크에서 파일을 읽어와야 하는 경우, 메모리에 로드되지 않은 경우
  • 자신이 요청한 이벤트가 만족되면 Ready 상태
• Suspended(Stopped) : 외부적인 이유로 프로세스 수행이 정지된 상태, 강제 종료
  • 프로세스는 통째로 디스크에 Swap Out
  • 메모리에 너무 많은 프로세스가 올라와있을 때
  • 외부에서 resume 해줘야 Active 상태로 변화
• New : 프로세스가 생성 중인 상ㅌ애
• Terminated : 수행(execution)이 끝난 상태

PCB(Process Control Block)

• 운영체제가 각 프로세스를 관리하기 위해 프로세스마다 유지하는 정보
• 프로세스마다 하나씩 1:1 매핑
• 구조체로 유지

  PCB 구성 요소

  

이미지 출처

1. OS가 관리상 사용하는 정보

• Process State(Ready, Blocked .. ), Process Id
• Scheduling Information, Priority

2. CPU 수행 관련 하드웨어 값 - 프로세스 문맥

• Program Counter(PC), Register

3. 메모리 관련

• code, data, stack 위치 정보

4. 파일 관련

• Open File Descriptors, ..

Context Switch(문맥 교환)

이미지 출처

• CPU를 한 프로세스에서 다른 프로세스를 넘겨주는 과정
• CPU가 다른 프로세스에게 넘어갈 때 운영체제는 :
  • 1. CPU를 뺏기는 프로세스의 상태를 그 프로세스의 PCB에 저장
  • 2. CPU를 새롭게 얻는 프로세스의 상태를 PCB에서 읽어옴
• ⚠️ 시스템 콜이나 인터럽트 발생 시 반드시 문맥 교환이 일어나는 것은 아님
  • CPU제어권이 사용자 프로세스 → OS로 넘어가는 과정이 문맥교환❌
  • 문맥교환은 사용자 프로세스A ↔ 사용자 프로세스B

프로세스를 스케줄링하기 위한 큐

운영체제가 프로세를 효율적으로 관리하고 스케줄링하기 위해 사용하는 대기열

• Job Queue : 현재 시스템 내에 있는 모든 프로세스의 집합
• Ready Queue : CPU를 기다리는 모든 프로세스들의 대기열, 실행 가능한 상태
• Deviced Queue : I/O 장치의 사용을 기다리는 프로세스들의 대기열

큐 간 전이

• 프로그램 시작 → Job Queue에 등록
• 메모리에 올라오면 → Ready Queue로 이동
• CPU 할당 → 실행 (Running 상태)
• I/O 요청 → Device Queue로 이동
• I/O 완료 → 다시 Ready Queue로 이동

스케줄러

Long-term (장기 스케줄러, Job 스케줄러)

• 시작 프로세스 중 어떤 것들을 Ready queue에 보낼지 결정
  • New → Ready
• 프로세스에 메모리를 주는 문제 - 멀티 프로그래밍을 제어
  • 메모리에 몇 개 올릴래?
• ✨ 시분할 시스템(Time Sharing System)에는 보통 장기 스케줄러가 없고 무조건 ready 상태
  • 그래서 Medium-term 스케줄러가 필요

Short-term scheduler(단기 스케줄러, CPU 스케줄러)**

• 어떤 프로세스를 다음번에 Running 시킬지 결정
• 프로세스에 CPU를 주는 문제
• 충분히 빨라야 함

Medium-term scheduler(중기 스케줄러, Swapper)

• 여유 공간 마련을 위해 프로세스 통째로 메모리에서 디스크로 쫓아냄 - Swap Out
• 프로세스에게서 메모리를 뺏는 문제 - 멀티 프로그래밍을 제어
• 중기 스케줄러로 인해 Suspended(stopped)상태가 추가

• 주고받는 정보를 패킷(packet)단위로 주고받는 네트워크
• 패킷: 패킷 교환 네트워크에서 주고받는 데이터 단위
• 정보를 패킷 단위로 분할해서 송신하고, 수신 측에서 패킷을 재조립
• 패킷 교환기: 패킷을 어디로 전송할지(라우팅), 패킷의 손상 유무를 판별

회선 교환 네트워크

• 정해진 회선(circuit)으로만 통신하는 네트워크
• 사전에 연결 수립 작업
• 다른 호스트는 도중에 끼어들 수 없음❌
• 전송률을 보장하지만 회선 이용률 저하

패킷 구성 요소

• Header : 패킷에 붙일 부가 정보
• Payload : 패킷에 보낼 정보
• Trailer : 패킷 뒤에 붙일 부가정보

프로토콜

• 네트워크에 참여한 장비 간 정보를 주고받을 규칙하는 방법
• 호스트 간에 합의된 의사소통 규칙 - 노드 간의 언어
• ✨ 패킷 헤더의 내용은 프로토콜의 영향을 받는다
  • 헤더는 패킷에 붙일 부가 정보
  • 프로토콜이 달라지면 헤더의 내용이 달라진다 - 프로토콜마다 목적이 다름
  • TCP 프로토콜 헤더와 vs UDP 프로토콜 헤더
    • TCP : 신뢰성이 보장된 전송
    • UDP : 빠른 전송

네트워크 참조 모델 - TCP/IP 4 Layer

캡슐화와 역캡슐화

PDU(Protocol Data Unit) : 네트워크에서 프로토콜 데이터 단위