헥사고날 아키텍처와 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) : 네트워크에서 프로토콜 데이터 단위

26. AOP가 필요한 상황

AOP(Aspect Oriented Programming)란?

• 관점 지향 프로그래밍
• 어떤 로직을 기준으로 핵심 관점, 부가 관점을 분리해 관점을 기준으로 각각 모듈화
  • 유지보수성과 재사용성을 높임
• 핵심 관심 사항(Core concern) : 핵심 비지니스 로직
• 공통 관심 사항(Cross-cutting concern) : 로깅, 파일 입출력, DB연결 등 부가기능
  • 로깅
  • 트랜잭션 관리
  • 성능 모니터링
  • 보안처리

⏰ 만약 각 메서드의 실행 시간을 측정하고 싶다면? - 시간 측정 로직을 모두 추가

📂 MemberService 모든 메서드에 시간 측정 로직을 추가

@Transactional
public class MemberService {

    private final MemberRepository memberRepository;

    public MemberService(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }

    // 회원가입 - 동일인의 회원 중복 가입❌
    public Long join(Member member){
        long start = System.currentTimeMillis();
        try {
            validateDuplicatedMember(member);
            memberRepository.save(member);
            return member.getId();
        } finally {
            long finish = System.currentTimeMillis();
            long timeMs = finish - start;
            System.out.println("join() = " + timeMs + "ms");
        }
    }

    // 중복 회원 확인 
    private void validateDuplicatedMember(Member member) {
        long start = System.currentTimeMillis();
        try {
            memberRepository.findByName(member.getName())
                .ifPresent(m -> {
                    throw new IllegalStateException("이미 존재하는 회원입니다.");
                });
        } finally {
            long finish = System.currentTimeMillis();
            long timeMs = finish - start;
            System.out.println("validateDuplicatedMember() = " + timeMs + "ms");
        }
    }

    // 전체 회원 조회
    public List<Member> findMembers(){
        long start = System.currentTimeMillis();
        try {
            return memberRepository.findAll();
        } finally {
            long finish = System.currentTimeMillis();
            long timeMs = finish - start;
            System.out.println("findMembers() = " + timeMs + "ms");
        }
    }

    // 단일 회원 조회
    public Optional<Member> findMember(Long memberId){
        long start = System.currentTimeMillis();
        try {
            return memberRepository.findById(memberId);
        } finally {
            long finish = System.currentTimeMillis();
            long timeMs = finish - start;
            System.out.println("findMember() = " + timeMs + "ms");
        }
    }
}

validateDuplicatedMember() = 4ms
join() = 7ms
findMembers() = 11ms

💥 문제점

• 시간을 측정하는 기능은 핵심 관심 사항❌
• 시간을 측정하는 로직은 공통 관심사항 - 부가 기능
• 시간 측정 로직과 핵심 비지니스 로직이 섞여 유지보수가 어려움
• 시간 측정 로직을 별도의 공통 로직으로 만들기 어려움
• 시간 측정 로직을 변경할 때 모든 로직을 찾아가면서 변경해야 함

27. AOP 적용

• 핵심 관심사항(회원가입, 회원조회 등)과 공통 관심사항(시간 측정)을 분리
• 변경이 필요하면 공통 관심사항만 변경
• 원하는 적용 대상 선택 가능 - @Around

📂 TimeTraceAop

@Aspect
@Component  // 또는 SpringConfig에 @Bean으로 등록(선호하는 방법)
public class TimeTraceAop {

    @Around("execution(* hello.hello_spring..*(..))")
    public Object execute(ProceedingJoinPoint joinPoint) throws Throwable{
        long start = System.currentTimeMillis();
        // joinPoint.toString() : 어떤 메서드를 호출하는지 얻어옴
        System.out.println("START: " + joinPoint.toString());
        try {
            Object result = joinPoint.proceed();
            return result;
        } finally {
            long finish = System.currentTimeMillis();
            long timeMs = finish - start;
            System.out.println("END: " + joinPoint.toString() + " " + timeMs + "ms");
        }
    }
}

START: execution(String hello.hello_spring.controller.MemberController.list(Model))
START: execution(List hello.hello_spring.service.MemberService.findMembers())
START: execution(List org.springframework.data.repository.ListCrudRepository.findAll())
Hibernate: select m1_0.id,m1_0.name from member m1_0
END: execution(List org.springframework.data.repository.ListCrudRepository.findAll()) 4ms
END: execution(List hello.hello_spring.service.MemberService.findMembers()) 4ms
END: execution(String hello.hello_spring.controller.MemberController.list(Model)) 9ms

핵심 로직

@Around("execution(* hello.hello_spring..*(..))")
public Object execute(ProceedingJoinPoint joinPoint) throws Throwable {
    ...
}

• @Around: 해당 메서드가 지정된 포인트컷의 전후에 실행될 Advice임을 명시
• "execution(* hello.hello_spring..*(..))": hello.hello_spring 패키지 이하의 모든 메서드에 적용하겠다는 의미(join point)

Object result = joinPoint.proceed();
return result;

• 실제 타겟 메서드 실행
• proceed()는 프록시된 대상 메서드를 실행하며, 예외를 던질 수 있어 throws Throwable이 필요

🍀 AOP 관련 어노테이션

🍀 AOP가 동작하기 위한 기타 설정 어노테이션

AOP 적용 전 의존 관계

AOP 적용 후 의존 관계

• AOP가 적용되면 스프링이 올라와서 스프링 컨테이너에 빈을 등록할 때, 진짜 스프링 빈 말고 가짜 스프링 빈(프록시)을 앞에 세워둠
• joinPoint.proceed()를 실행하면 내부적으로 진짜 스프링 빈을 호출 처음에 memberController가 호출하는 건 프록시 memberService를 호출하는 것

AOP 적용 전 전체 그림

AOP 적용 후 전체 그림

실제 Proxy가 주입되는지 콘솔에 출력해서 확인

    @Autowired
    public MemberController(MemberService memberService) {
        this.memberService = memberService;
        System.out.println("memberService = " + memberService.getClass());
    }

memberService = class hello.hello_spring.service.MemberService$$SpringCGLIB$$0

🍀 CGLIB(Code Generation Library)

• 자바 동적 프록시를 생성하기 위한 바이트코드 생성 라이브러리
• 인터페이스가 없는 구체 클래스를 프록시 - 클래스 기반 프록시 생성

• 리포지토리에 구현 클래스 없이 인터페이스만으로 개발이 완료
• CRUD, findById, findAll, DB에서 PK로 검색하는 기능이
  모두 만들어져있어 스프링 데이터 JPA가 제공(공통 기능 제공)
  • 개발자는 그냥 가져다 쓰면 됨!
  • findByName(), findByEmail() 등은 비지니스가 다르므로 공통 정의❌
  • 공통으로 할 수 없는건 직접 정의
  • 그럼 JPA가 이걸 기준으로 쿼리를 작성해줌 ..! - JPQL
  • 즉, 인터페이스 이름만으로도 개발 끝 개쩐당
  • Reflection 기술 사용
• 스프링 데이터 JPA는 JPA를 편리하게 사용하도록 도와주는 기술

📂 SpringDataJpaMemberRepository

• 스프링 데이터 JPA는 JpaRepository를 상속받고 있으면
  구현체를 자동으로 생성하고, 스프링 빈에 자동으로 등록
• 프록시 기술을 이용해 런타임에 구현체를 동적 생성 및 스프링 빈 등록

public interface SpringDataJpaMemberRepository extends JpaRepository<Member, Long>, MemberRepository {
    // MemberRepository의 findByName() 오버라이딩
    // 'select m from Member m where m.name = ?' JPQL -> SQL로 변환돼 실행
    @Override
    Optional<Member> findByName(String name);
}

📂 SpringConfig

@Configuration
public class SpringConfig {

    private final MemberRepository memberRepository;

    // DI -> Spring Data JPA가 만든 구현체가 등록됨
    // 스프링 컨테이너에서 MemberRepository를 찾음 -> 근데 등록한게 없잖아? 사실 하나 있음 SpringDataJpaMemberRepository
    // SpringDataJpaMemberRepository는 JpaRepository를 상속, 스프링 데이터JPA 인터페이스에 대한 구현체를 만들어서 스프링 빈에 등록
    @Autowired
    public SpringConfig(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }

    @Bean
    public MemberService memberService(){
        return new MemberService(memberRepository);
    }
}

스프링 데이터 JPA는 어떻게 인터페이스만으로 레포지토리 역할이 가능할까?

🍀 스프링과 프록시 객체

스프링 데이터 JPA에서 구현체 없이 인터페이스만으로 개발이 가능한 이유는 스프링이 런타임 시점에 프록시 객체를 자동으로 생성하고,
내부적으로 JPA API를 호출하도록 위임해주기 때문

🍀 핵심 이유 요약

1. 프록시 기반 동적 구현

• 스프링이 JpaRepository 인터페이스를 기반으로 프록시 객체를 만들어 동작을 위임

2. Query 메서드 자동 분석

• 메서드 이름을 분석해 JPQL 쿼리를 자동 생성

3. 스프링 컨테이너가 구현체 주입

• 개발자가 구현하지 않아도 @Autowired로 주입 가능

🍀 스프링의 런타임 시점 수행과정

1. 컴포넌트 스캔

• 애플리케이션 실행 시 @SpringBootApplication을 통해 자동으로 패키지를 스캔
• @Component, @Controller, @Service, @Repository 등으로 등록된 클래스 또는 인터페이스를 스캔해 빈으로 등록

2. 프록시 객체 생성

• JpaRepository를 상속받는 인터페이스는 실제 구현체가 없으므로, Spring이 프록시 객체를 런타임에 생성
• 프록시 객체는 Spring AOP 기반의 JDK Dynamic Proxy 또는 CGLIB Proxy를 통해 생성

3. 프록시를 빈으로 등록

• 생성된 프록시 객체는 빈으로 등록되며, 이후 DI로 사용 가능

• JPA는 기존의 반복 코드와, 기본적인 SQL도 JPA가 직접 만들어서 실행
• JPA를 사용하면 SQL와 데이터 중심 설계에서 객체 중심 설계가 가능
• JPA는 인터페이스만 제공, 구현체는 Hibernate(또는 여러 기술 벤더들이 있음
• JPA는 ORM 기술 - 객체(Object)와 RDB(Relational) 매핑
  • 어떻게 매핑? 어노테이션(@Entity)으로 매핑

📂 build.gradle

• JPA 관련 라이브러리 추가
  • JPA 라이브러리는 내부에 JDBC 관련 라이브러리를 추가

    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'

📂 application.properties

• 스프링 부트에 JPA 설정 추가
• show-sql : JPA가 생성하는 SQL을 출력
• ddl-auto=none : JPA의 테이블 자동 생성 기능을 끔
  • create : 애플리케이션 실행 시 기존 테이블 삭제 후 새로 생성
  • create-drop : 애플리케이션 실행 시 테이블 생성, 종료 시 테이블 삭제
  • update : 데이터베이스 스키마를 매핑 정보와 비교해 필요한 부분만 변경
  • validate : 데이터베이스와 매핑 정보 검증만 수행

spring.jpa.show-sql=true
spring.jpa.hibernate.ddl-auto=none

📂 Member

• JPA 엔티티 매핑

• @Entity : 데이터베이스 테이블과 매핑되는 클래스 명시

• @Id : 기본 키 지정

• @GeneratedValue(strategy = GenerationType.IDENTITY) : 기본 키 자동 생성 전략

  • GenerationType.IDENTITY : DB의 AUTO_INCREMENT 기능 사용

  • GenerationType.SEQUENCE : DB의 시퀀스를 사용(Oracel, PostgreSQL)

  • GenerationType.TABLE : 별도의 키 관리 테이블 사용

  • GenerationType.AUTO : DB에 맞는 전략을 자동 선택

    @Entity
    public class Member {
    
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String name;
    
    public Long getId() {return id;}
    public void setId(Long id) {this.id = id;}
    public String getName() {return name;}
    public void setName(String name) {this.name = name;}
    }

📂 JpaMemberRepository

• JPA를 사용하기 위해 트랜잭션 필요 - MemberService에 @Transactional 추가
  • JPA를 통한 모든 데이터 변경은 트랜잭션 안에서 실행
• JPA는 EntityManager로 동작
  • build.gradle에서 JPA관련 라이브러리를 받으면 스프링 부트가 EntityManager를 생성
  • JPA를 사용하려면 EntityManager를 주입받아야 함

public class JpaMemberRepository implements MemberRepository{

    private final EntityManager em;

    public JpaMemberRepository(EntityManager em) {
        this.em = em;
    }

    @Override
    public Member save(Member member) {
        em.persist(member);
        return member;
    }

    @Override
    public Optional<Member> findById(Long id) {
        // find(조회할 타입, 식별자(PK))
        Member member = em.find(Member.class, id);
        return Optional.ofNullable(member);
    }

    @Override
    public Optional<Member> findByName(String name) {
        // 📌 PK가 아닌 다른 컬럼으로 조회시 JPQL을 사용
        // JPQL은 테이블 대상 쿼리가 아닌 객체(엔티티) 대상 쿼리
        // SELECT 의 대상은 엔티티
        List<Member> member = em.createQuery("select m from Member m where m.name = :name", Member.class)
                .setParameter("name", name)
                .getResultList();

        return member.stream().findAny();
    }

    @Override
    public List<Member> findAll() {
        return em.createQuery("select m from Member m", Member.class).getResultList();
    }
}

EntityManager, PC, EntityManagerFactory

🍀 1. EntityManager

• JPA에서 제공하는 엔티티 관리 인터페이스
• 엔티티의 생성, 조회, 수정, 삭제와 같은 데이터 조작 작업을 수행
• EntityManager는 내부에 Persistence Context를 둬서 엔티티들을 관리

핵심 역할

• 영속성 컨텍스트 관리
• 트랜잭션 관리
• 쿼리 실행 및 데이터베이스 연결 관리

생명 주기

• 단일 트랜잭션 또는 작업 단위에서만 유효
• 트랜잭션이 종료되거나 close() 메서드가 호출되면 더 이상 사용❌

🍀 2. 영속성 컨텍스트(Persistence Context)

• 엔티티 객체를 관리하는 메모리 공간
• EntityManager가 관리하는 1차 캐시 역할
• 객체의 상태를 추적하고 동기화

주요 특징

1. 1차 캐시

• 동일 트랜잭션 내에서 동일 엔티티 조회 시,
• 데이터베이스 재조회 없이 메모리에서 가져옴*

2. 변경 감지(Dirty Checking)

• 엔티티의 상태가 변경되면 자동으로 업데이트 쿼리를 생성하고 반영

3. 쓰기 지연(Wrire Behind)

• 트랜잭션이 커밋될 때까지 SQL 쿼리를 지연 저장하여 성능 최적화
• 트랜잭션이 커밋 되기 전까지 모든 쿼린문은 영속성 컨텍스트 내부의 쓰기 지연 SQL 저장소에 저장 - 커밋되는 순간 모든 쿼리를 한 번에 날림

4. 동기화(Flush)

• 영속성 컨텍스트와 데이터베이스를 동기화

상태 변화

User user = new User();   // 비영속 (Transient)
em.persist(user);         // 영속 (Persistent)
em.detach(user);          // 준영속 (Detached)
em.remove(user);          // 삭제 (Removed)

1. 비영속(Transient) : 아직 영속성 컨텍스트에 포함되지 않은 상태
2. 영속(Persistent) : persist() 호출 후 관리되는 상태
3. 준영속(Detached) : detach() 또는 clear() 호출 시 관리가 해제된 상태
4. 삭제(Removed) : remove() 호출 후 삭제 예약 상태

🍀 3. EntityManagerFactory

• EntityManager 인스턴스를 생성하는 팩토리 클래스
• JPA 설정(데이터베이스 연결, 매핑 정보)를 기반으로 애플리케이션 전체에서 공유
• 애플리케이션 실행 시 한 번만 생성해야 함

주요 특징

• 애플리케이션당 하나의 인스턴스만 사용
• Thread-Safe : 멀티스레드 환경에서 안전하게 사용 가능
• 데이터베이스 연결 정보 및 설정을 포함
• 성능 최적화를 위해 커넥션 풀링을 지원

EntityManagerFactory emf = Persistence.createEntityManagerFactory("example-unit");
EntityManager em1 = emf.createEntityManager(); // EntityManager 생성
EntityManager em2 = emf.createEntityManager(); // 또 다른 EntityManager 생성

em1.close();
em2.close();
emf.close(); // 최종 종료

🍀 정리

1. EntityManagerFactory 생성 : 전체 애플리케이션에서 하나만 생성
2. EntityManager 생성 : 각 작업 단위(트랜잭션)에 대해 생성
3. 영속성 컨텍스트 관리 : 데이터베이스와 메모리 간 상태 동기화

• 순수 JDBC와 동일한 환경 설정
• JdbcTemplate은 JDBC의 반복 코드를 제거
• 단, SQL은 직접 작성해야 함

📂 JdbcTemplateMemberRepository

public class JdbcTemplateMemberRepository implements MemberRepository {
    private final JdbcTemplate jdbcTemplate;

    // 생성자가 1개인 경우 @Autowired 생략가능
    // JdbcTemplateMemberRepository에 DataSource객체를 주입
    public JdbcTemplateMemberRepository(DataSource dataSource) {
        this.jdbcTemplate = new JdbcTemplate(dataSource);
    }

    @Override
    public Member save(Member member) {
        // SimpleJdbcInsert : JdbcTemplate을 만들어서 넘김
        SimpleJdbcInsert jdbcInsert = new SimpleJdbcInsert(jdbcTemplate);

        // 테이블명, PK를 넘기면 insert문 쿼리 작성할 필요❌
        jdbcInsert.withTableName("member").usingGeneratedKeyColumns("id");

        Map<String, Object> parameters = new HashMap<>();
        parameters.put("name", member.getName());

        Number key = jdbcInsert.executeAndReturnKey(new MapSqlParameterSource(parameters));
        member.setId(key.longValue());
        return member;
    }

    // 📌 조회는 쿼리 실행의 결과를 RowMappeer로 매핑이 필요
    @Override
    public Optional<Member> findById(Long id) {
        // query() : 반환타입 List, SQL 쿼리 결과를 조회하고 객체로 매핑
        // query(String sql, RowMapper<T> rowMapper)
        List<Member> result = jdbcTemplate.query(
                "select * from member where id = ?",
                memberRowMapper(),
                id);
        return result.stream().findAny();
    }

    @Override
    public Optional<Member> findByName(String name) {
        List<Member> result = jdbcTemplate.query(
                "select * from member where name = ?",
                memberRowMapper(),
                name);
        return result.stream().findAny();
    }

    @Override
    public List<Member> findAll() {
        return jdbcTemplate.query("select * from member", memberRowMapper());
    }

    // 📌 RowMapper
    private RowMapper<Member> memberRowMapper(){
        return (rs, rowNum) -> {
            Member member = new Member();
            member.setId(rs.getLong("id"));
            member.setName(rs.getString("name"));
            return member;
        };
    }
}

• 스프링 컨테이너와 DB까지 연결한 통합 테스트
• @SpringBootTest : 스프링 컨테이너와 테스트를 함께 실행
• @Transactional : 테스트 시작 전에 트랜잭션을 시작, 테스트 완료 후 롤백

스프링을 띄우는 테스트가 왜 필요할까?

1. 빈(Bean) 관리 검증

• 빈이 올바르게 생성되고 의존성이 주입되는지 검증
  • Ex. MemberService가 MemberRepository에 의존하는지 확인.

2. 트랜잭션 테스트

• 실제 데이터베이스와 연결하여 쿼리 실행 후 롤백되는지 검증
  • Ex. INSERT 이후 데이터가 저장되었는지 확인하고 테스트 후 원상복구

3. 통합 테스트

• 컨트롤러, 서비스, 리포지터리 등 애플리케이션의 여러 계층이
  올바르게 상호작용하는지 테스트
  • Ex. HTTP 요청 → 컨트롤러 → 서비스 → 레포지터리 흐름 검증

4. Mock 환경 테스트

• 웹 요청을 테스트하거나, 모의 객체(Mock)를 활용하여 특정 부분만 검증
  • Ex. MockMvc를 이용한 HTTP 요청 시나리오 검증

📂 MemberServiceIntegrationTest

@SpringBootTest
@Transactional
class MemberServiceIntegrationTest {
    @Autowired MemberService memberService;

    // 📌 구현체는 @Configuration한 곳에서 주입받음
    @Autowired MemberRepository memberRepository;

    // 📌 직접 객체 생성 방식❌ -> 스프링 컨테이너에게 주입받는 방식으로 변경
//    @BeforeEach
//    void beforeEach(){
//        memberRepository = new MemoryMemberRepository();
//        memberService = new MemberService(memberRepository);
//    }

    // 📌 테스트의 반복 가능 -> @Transactional로 해결
//    @AfterEach
//    void afterEach(){
//        memberRepository.clearStore();
//    }

    @Test
    // @Commit     // 테스트 데이터가 롤백되지않고 DB에 반영
    void 회원가입() {
        // given
        Member member = new Member();
        member.setName("zizon의연v");

        // when
        Long savedId = memberService.join(member);

        // then
        // Service의 findMember()로 테스트
        Member findMember1 = memberService.findMember(savedId).get();
        assertThat(member.getName()).isEqualTo(findMember1.getName());

        // Repository의 findById()로 테스트
        Member findMember2 =  memberRepository.findById(savedId).get();

    }

    @Test
    void 중복_회원_예외(){
        // given
        Member member1 = new Member();
        member1.setName("zizon의연v");

        Member member2 = new Member();
        member2.setName("zizon의연v");

        // when
        memberService.join(member1);

        // then
        IllegalStateException e = assertThrows(IllegalStateException.class, 
                        () -> memberService.join(member2));
        assertThat(e.getMessage()).isEqualTo("이미 존재하는 회원입니다.");
    }

    ...

}

🍀통합 테스트에서 @Transactional을 사용하는 이유

스프링 부트 통합 테스트(@SpringBootTest)에서 @Transactional을 붙이면,

• 테스트 메서드가 끝난 뒤 자동으로 트랜잭션 롤백
• 테스트로 인해 DB에 변경된 내용이 테스트 종료 후 남지 않도록

@Transactional 동작 원리

• 테스트가 실행되면 @Transactional은
• 트랜잭션을 시작하고
• 테스트가 끝나면 rollback()이 실행됨

@Transactional가 통합 테스트에서 중요한 이유

1. 테스트를 실행할 때마다 DB가 초기 상태로 보장 - 반복 실행 가능
2. 데이터가 섞이지 않아 테스트 간 간섭이 없음 - 테스트 격리
3. 실제 DB 환경에서 서비스/레포지토리 계층을 통합적으로 검증 가능

• 자바 진영에서 데이터베이스에 접속할 수 있도록하는 API
• 자바 애플리케이션에서 JDBC API를 사용해 DB에 접근 (자바 언어로 DB 프로그래밍을 하기 위한 라이브러리)

환경 설정

• build.gradle파일에 JDBC, h2 데이터베이스 관련 라이브러리 추가

  • 자바는 DB랑 붙으려면 JDBC 드라이버가 반드시 필요

    implementation 'org.springframework.boot:spring-boot-starter-jdbc'
    runtimeOnly 'com.h2database:h2'

• DB접속 정보는 application.properties에 추가

  spring.datasource.url=jdbc:h2:tcp://localhost/~/test
  spring.datasource.driver-class-name=org.h2.Driver
  spring.datasource.username=sa
  spring.datasource.password=

• 회원을 저장하는 역할은 MeberRepository가 하지만 구현은 메모리랑 할 지(MemoryMemberRepository),

• DB랑 연동해서 JDBC가 할 지(JdbcMemberRepository)에 대한 차이

JDBC 레포지토리 구현

• DateSource는 데이터베이스 커넥션을 획득할 때 사용하는 객체
• 스프링 부트는 데이터베이스 커넥션 정보를 바탕으로 DataSource를 생성하고, 스프링 빈을 만들어 둠 → DI를 받을 수 있음

📂 JdbcMemberRepository

public class JdbcMemberRepository implements MemberRepository{
    // 📌 DB에 붙으려면 DataSource가 필요 -> 스프링에게 주입 받아야 함
    // 📌 application.properties의 내용을 스프링부트가 DataSource 생성 및 주입
    private final DataSource dataSource;

    public JdbcMemberRepository(DataSource dataSource){
        this.dataSource = dataSource;
    }

    @Override
    public Member save(Member member) {
        String sql = "insert into member(name) values(?)";

        Connection conn = null;
        PreparedStatement pstmt = null;
        ResultSet rs = null;

        try{
            conn = getConnection();
            pstmt = conn.prepareStatement(sql, Statement.RETURN_GENERATED_KEYS);

            // parameterIndex 1은 SQL의 ?와 매칭
            pstmt.setString(1, member.getName());

            pstmt.executeUpdate();            // DB에 쿼리(insert)가 날라감
            rs = pstmt.getGeneratedKeys();    // 방금 생성된 KEY(1, 2, ..)를 반환

            if(rs.next()){
                member.setId(rs.getLong(1));
            } else{
                throw new SQLException("id 조회 실패");
            }
            return member;
        } catch (Exception e){
            throw new IllegalStateException(e);
        } finally {
            close(conn, pstmt, rs);
        }
    }

    @Override
    public Optional<Member> findById(Long id) {
        String sql = "select * from member where id = ?";

        Connection conn = null;
        PreparedStatement pstmt = null;
        ResultSet rs = null;

        try{
            conn = getConnection();
            pstmt = conn.prepareStatement(sql);
            pstmt.setLong(1, id);

            // 조회는 executeUpdate()❌, executeQuery⭕
            rs = pstmt.executeQuery();

            if(rs.next()){
                Member member= new Member();
                member.setId(rs.getLong("id"));
                member.setName(rs.getString("name"));
                return Optional.of(member);
            } else {
                return Optional.empty();
            }
        } catch (Exception e){
            throw new IllegalStateException(e);
        } finally {
            close(conn, pstmt, rs);
        }
    }

    @Override
    public Optional<Member> findByName(String name) {
        String sql = "select * from member where name = ?";
        Connection conn = null;
        PreparedStatement pstmt = null;
        ResultSet rs = null;

        try{
            conn = getConnection();
            pstmt = conn.prepareStatement(sql);
            pstmt.setString(1, name);

            rs = pstmt.executeQuery();

            if(rs.next()){
                Member member = new Member();
                member.setId(rs.getLong("id"));
                member.setName(rs.getString("name"));
                return Optional.of(member);
            }
            return Optional.empty();
        } catch (Exception e){
            throw new IllegalStateException(e);
        } finally {
            close(conn, pstmt, rs);
        }
    }

    @Override
    public List<Member> findAll() {
        String sql = "select * from member";

        Connection conn = null;
        PreparedStatement pstmt = null;
        ResultSet rs = null;

        try{
            conn = getConnection();
            pstmt = conn.prepareStatement(sql);
            rs = pstmt.executeQuery();

            List<Member> members = new ArrayList<>();
            while(rs.next()){
                Member member = new Member();
                member.setId(rs.getLong("id"));
                member.setName(rs.getString("name"));
                members.add(member);
            }
            return members;
        } catch (Exception e){
            throw new IllegalStateException(e);
        } finally {
            close(conn, pstmt, rs);
        }
    }

    // 📌 커넥션을 얻
    private Connection getConnection(){
        return DataSourceUtils.getConnection(dataSource);
    }

    // 📌 자원을 역순으로 해제**
    private void close(Connection conn, PreparedStatement pstmt, ResultSet rs){
        try{
            if(rs!= null){
                rs.close();
            }
        } catch (SQLException e){
            e.printStackTrace();
        }
        try{
            if(pstmt != null){
                pstmt.close();
            }
        } catch (SQLException e){
            e.printStackTrace();
        }

        try{
            if(conn != null){
                close(conn);
            }
        } catch (SQLException e){
            e.printStackTrace();
        }
    }

    // 📌 dataSource.getConnection()❌, DataSourceUtils 권장 -> 트랜잭션 유지
    // 📌 데이터베이스와 연결된 커넥션을 얻음
    // 📌 진짜 데이터베이스와 연결되는 열린 소켓을 얻을 수 있음?**
    private void close(Connection conn) throws SQLException{
        DataSourceUtils.releaseConnection(conn, dataSource);
    }
}

📂 SpringConfig

// 스프링이 application.properties를 보고 DataSource를 빈으로 자동 생성
@Configuration
public class SpringConfig {

    private DataSource dataSource;

    // DI, DataSource주입**

    @Autowired         
    public SpringConfig(DataSource dataSource) {
        this.dataSource = dataSource;
    }

    @Bean
    public MemberService memberService(){
        return new MemberService(memberRepository());
    }

    @Bean
    public MemberRepository memberRepository() {
        // return new MemoryMemberRepository();        // 구현체 변경
        return new JdbcMemberRepository(dataSource);
    }
}

JDBC의 정형화된 패턴

• JdbcMemberRepository는 JDBC를 직접 사용하는 레포지토리 구현의 전형적인 패턴

1. SQL 준비

String sql = "select * from member where id = ?";

• 쿼리는 항상 String으로 선언
• 쿼리 안에 ?를 넣고, 나중에 바인딩

2. Connection 획득

conn = getConnection();

• DataSource로부터 커넥션을 가져옴
  • DataSource는 DB와 연결을 관리하는 객체
  • 내부적으로 Connection을 생성하고 풀링하는 역할
  • DS에서 커넥션을 가져온다는 건
  • DB에 연결된 소켓 하나를 열고, 해당 연결을 Connection 객체로 받는 것*
  • 이 커넥션을 이후 SQL 실행, 트랜잭션 처리 등에 사용됨
• 스프링에서는 반드시 DataSourceUtils.getConnection() 사용해야 함
  • 트랜잭션 매니저와 연동되지 않으면 트랜잭션 동기화가 깨질 수 있음 (몬말일까?)

3. PreparedStatement 생성 및 파라미터 바인딩

pstmt = conn.prepareStatement(sql);
pstmt.setLong(1, id);

• PreparedStatement를 통해 SQL 실행 준비
• setXxx()로 파라미터 바인딩 (1은 ?의 인덱스)

4. 쿼리 실행

rs = pstmt.executeQuery();         // 조회
rs =  pstmt.executeUpdate();     // 삽입, 수정, 삭제

5. ResultSet을 통해 결과 매핑

if(rs.next()){
    Member member = new Member();
    member.setId(rs.getLong("id"));
    member.setName(rs.getString("name"));

• ResultSet을 객체로 변환하는 단계 (Manual ORM)
• 하나씩 수동으로 getter 호출

6. 예외 처리 및 감싸기

} catch (Exception e){
    throw new IllegalStateException(e);
}

• 체크 예외인 SQLException을 런타임 예외로 감싸서 던짐
• 스프링에서는 DataAccessException을 사용하는 경우도 많음

7. 리소스 해제

close(conn, pstmt, rs);

• 반드시 역순으로 닫기: ResultSet → Statement → Connection

🍀 정리

1. JdbcMemberRepository - Repository 계층
   • 데이터베이스에 직접 접근해 SQL쿼리를 실행하고 결과처리
   • 데이터베이스 연결을 위한 DataSource객체가 필요한데, 생성자 주입 방식으로 SpringConfig에서 설정된 DataSource가 전달됨
2. SpringConfig - 설정 및 의존성 주입 관리
   • 스프링 설정 클래스, 애플리케이션의 빈(Bean)을 관리
   • DI를 통해 객체 생성 및 관리 역할을 수행
   • MemberService → MemberRepository → DataSource 순서로 의존관계 주입
3. application.properties - 설정파일
   • 데이터베이스 설정, 애플리케이션 이름, 정적 리소스 경로 등을 정의
   • 스프링부트는 이 파일을 기반으로 자동 설정(Auto Configuration)을 수행

🍀 스프링 전체 동작 과정 정리

1. 애플리케이션 실행

• application.properties를 기반으로 DataSource 객체가 빈으로 자동 생성

2. SpringConfig 로드

• JdbcMemberRepository와 MemberService가 빈으로 등록
• 생성자 주입을 통해 의존 관계가 설정

3. Repository 사용

• MemberService에서 memberRepository를 호출하면, 실제 데이터베이스와 연결된 JDBC 코드가 실행
• SQL 쿼리를 통해 데이터 삽입, 조회가 이루어짐.

4. 트랜잭션 및 커넥션 관리

• DataSourceUtils를 통해 커넥션 풀을 관리하며,
  자원 누수 없이 트랜잭션을 유지

🍀 스프링과 다형성

MemoryMemberRepository에서 JdbcMemberRepository로 갈아끼우기

• 인터페이스를 두고 구현체를 바꿔끼울수 있음 - 스프링 사용 이유(스프링 컨테이너가 지원)
• DI를 통해 편리하게 기존 코드 변경없이 가능
• 오직 애플리케이션을 설정하는 코드만 변경하면
  애플리케이션과 관련된 코드는 손댈게 하나도 없음 - OCP(개방 폐쇄 원칙)

• url과 매핑된 컨트롤러가 없으면 static/index.html 실행
• url과 매핑된 컨트롤러가 있으면 해당 컨트롤러를 호출(우선순위 적용)

📂 HomeController.java

@Controller
public class HomeController{
    @GetMapping("/")
    public String home(){
        return "home";
    }
}

📂 resources/templates/hello.html

<!DOCTYPE HTML>
<html xmlns:th="http://www.thymeleaf.org">
<body>
<div class="container">
    <div>
        <h1>Hello Spring</h1>
        <p>회원 기능</p>
        <p>
            <a href="/members/new">회원 가입</a>
            <a href="/members">회원 목록</a>
        </p>
    </div>
</div>
</body>
</html>

18. 회원 웹 기능 - 등록

📂MemberController.java

@Controller
public class MemberController {
    private final MemberService memberService;

    @Autowired
    public MemberController(MemberService memberService) {
        this.memberService = memberService;
    }

    @GetMapping("/members/new")
    public String createForm(){

        // View Resolver가 찾아서 선택 -> Thymeleaf가 렌더링
        // templates/members/createMemberForm.html
        return "members/createMemberForm";
    }

    @PostMapping("/members/new")
    // @ModelAttribute 기능을 통해 매핑
    // HTTP 요청의 파라미터 중 키(name)가 MemberForm의 필드 이름과 일치하면 해당 필드에 값이 자동 매핑
    public String create(MemberForm form){  
        Member member = new Member();
        member.setName(form.getName())

        memberService.join(member);

        // 회원가입이 종료되면 홈 화면으로 리다이렉트
        return "redirect:/";
    }
}

📂resources/templates/members/createMemberForm.html

<!DOCTYPE HTML>
<html xmlns:th="http://www.thymeleaf.org">
<body>
<div class="container">

<!-- 📌 submit -> /members/new에  post 요청-->
    <form action="/members/new" method="post">
        <div class="form-group">
            <label for="name">이름</label>

            <!-- 📌 "name" : 서버로 넘어갈 때 key가 됨-->
            <input type="text" id="name" name="name" placeholder="이름을 입력하세요">
        </div>
        <button type="submit">등록</button>
    </form>
</div> <!-- /container -->
</body>
</html>

📂MemberForm.java

// 폼 데이터를 매핑하기 위한 DTO역할
// setName()을 통해 name값이 설정
public class MemberForm {
    private String name;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

회원 등록 플로우

[사용자 브라우저]
       |
       | GET /members/new
       v
[MemberController - createForm()]
       |
       | return "members/createMemberForm"
       v
[createMemberForm.html 렌더링됨]
       |
       | <form> 입력 후 등록 버튼 클릭
       v
[POST /members/new 요청]
       |
       | @ModelAttribute: MemberForm에 name 매핑
       v
[MemberController - create()]
       |
       | Member 객체 생성 + 이름 설정
       v
[memberService.join(member)]
       |
       | 회원 저장 로직 실행
       v
[회원 가입 완료 → redirect:/]
       |
       v
[홈 화면으로 리다이렉트]

@ModelAttribute

• HTTP 요청 파라미터를 객체(빈)에 바인딩해주는 어노테이션
• HTML 폼에서 넘어온 데이터를 자바 객체 필드에 자동으로 넣어줌
• 🌿 객체 타입(MemberForm))인 경우 생략 가능
• 🌿 기본 타입(String, int)인 경우 @RequestParam으로 처리

19. 회원 웹 기능 - 조회

📂MemberController.java

    @GetMapping("/members")
    public String list(Model model){
        List<Member> members = memberService.findMembers();
        model.addAttribute("members", members);
        return "members/memberList";
    }

📂memberList.html

<!DOCTYPE HTML>
<html xmlns:th="http://www.thymeleaf.org">
<body>
<div class="container">
    <div>
        <table>
            <thead>
            <tr>
                <th>#</th>
                <th>이름</th>
            </tr>
            </thead>
            <tbody>
            <!-- Thymeleaf 템플릿 엔진이 동작하는 부분-->

            <!--  Service의 findMembers() -> Controller가 members로 전달-->
            <!-- ${...} : Model안에 있는 값을 꺼냄-->**
            <tr th:each="member : ${members}">
                **<!--  getId(), getName()으로 접근해서 값을 읽음-->**
                <td th:text="${member.id}"></td>
                <td th:text="${member.name}"></td>
            </tr>
            </tbody>
        </table>
    </div>
</div> <!-- /container -->
</body>
</html>

Model 객체

• 스프링 MVC에서 컨트롤러와 뷰(HTML 템플릿) 사이의 데이터 전달자 역할
• 내부적으로는 Map<String, Object> 구조

  Map<String, Object> model = new HashMap<>();
  model.put("members", members);
  

• 스프링 프레임워크에서 스프링 컨테이너가 관리하는 객체, 인스턴스
• 스프링이 생성하고, 의존성을 주입하고, 생명 주기를 관리하는 객체
• 일반 자바 객체는 new 키워드로 생성하는 반면,
• 스프링에서는 스프링 컨테이너(Application Context)가 대신 객체 생성 및 관리*
• 어노테이션에 따라 스프링 빈의 대상이 됨 - 해당 클래스의 인스턴스는 빈으로 등록
• @Component, @Service, @Repository, @Controller, @Configuration + @Bean

스프링 빈을 등록하는 2가지 방법

1. 컴포넌트 스캔과 자동 의존관계 설정
2. 자바 코드로 직접 스프링 빈 등록

15. 컴포넌트 스캔과 자동 의존 관계 설정

• Controller가 Service와 Repository를 사용할 수 있도록 의존 관계를 준비

• 스프링이 처음에 뜰 때 스프링 컨테이너가 생성되는데,
  MemberController.java 파일에 @Controller 를 붙여두면

• 컨트롤러 객체를 생성해서 스프링 컨테이너에 넣어두고 관리*한다.

• 즉, 스프링 컨테이너에서 스프링 빈이 관리된다.

의존 관계의 DI - new를 지양한다

@Controller
public class MemberController {

    private final MemberService memberService = new MemberService();

    ...
}

@Controller
public class MemberController {

    private final MemberService memberService;

    @AutoWired
    public MemberController(MemberService memberService) {
        this.memberService = memberService;

    }
    ...
}

• Controller와 Service 의존관계를 맺는 과정에서 첫 번째 코드처럼 new를 사용하는건 스프링답지 않다.
  • 스프링의 의존성 주입이 안됨
  • AOP, 트랜잭션 등 스프링의 기능이 적용되지 않음
  • 테스트나 유지보수가 불편
• 스프링답게 사용하기 위해서는 스프링 컨테이너에 빈으로 등록하고,
  스프링 컨테이너에서 받아서(주입받아서) 사용할 수 있어야 한다.
• 🌿 따라서 @Autowired를 사용해 의존관계를 주입한다.

컴포넌트 스캔 *- @Component, 스프링이 관리할 객체(빈)를 자동 등록 *

• @Component는 해당 클래스를 스프링 컨테이너가 관리할 수 있도록 등록하는 어노테이션
• 위에서 언급한 대로 @Controller, @Servcie, @Repository 등의 어노테이션은
  내부적으로 @Component를 포함하고 있어,
• 스프링이 실행될 때 자동으로 객체를 만들어 관리(스프링 컨테이너에 빈 등록)*
• ⚠️ 단, @ComponentScan이 설정된 패키지 안에 있어야 감지됨!

참고 - 스프링의 기본 빈 생성 방식, Singleton

• 스프링 컨테이너에 빈을 등록할 때 기본적으로 싱글톤으로 등록
• 오직 하나의 객체(인스턴스)를 생성해 애플리케이션 전체에서 공유하는 방식
• 모든 빈을 싱글톤으로 생성해 필요할 때마다 같은 객체를 주입
• 메모리 효율, 공통된 설정 및 데이터 공유 가능, 애플리케이션 전반에서 동일한 동작 유지

자동 의존관계 설정 -@Autowired, 자동으로 필요한 객체를 주입

• @Autowired는 스프링 컨테이너 안에 있는 필요한 객체(빈)을 자동으로 주입하는 어노테이션

• Controller가 Service를 사용하고, Service가 Repository를 사용할 수 있도록 @Autowired는 연관관계(의존관계)를 자동으로 맵핑(주입)해줌

• 생성자, 필드, setter() 등에 사용 가능

  • 생성자에@Autowired를 사용하면 객체 생성 시점에
    스프링 컨테이너에서 스프링 빈을 찾아서 주입

• ⚠️ 단, @Autowired를 통한 DI는 스프링이 관리하는 객체에서만 동작 (스프링 빈으로 등록하지 않거나, 개발자가 직접 생성한 객체에서는 동작❌)

정리하자면,

• @Component를 통해 스프링 빈으로 등록하고,
• @Autowired를 통해 빈들 간의 의존관계를 자동으로 맺는다.
• 🌿 스프링 컨테이너가 객체를 만들고, 필요한 곳에 자동으로 연결해주는 것이 DI의 핵심

16. 자바 코드로 직접 스프링 빈 등록하기

@Service, @Repository, @Autowired를 제거하면?

@Controller
public class MemberController {

    private final MemberService memberService;

    @Autowired
    public MemberController(MemberService memberService) {
        this.memberService = memberService;
    }

• Controller에서 사용하는 Service가 스프링 빈으로 등록되지 않는 경우,
• Component Scan을 사용하지 않고 직접 등록해서 사용 가능*
• Config 파일에서 수동으로 Bean으롤 정의한 Service를 Controller에 DI해줌

@Configuration

• 해당 클래스가 스프링 설정 클래스임을 명시
• 스프링은 이 클래스를 빈 구성정보로 사용하여 애플리케이션의 객체(빈) 관리를 수행
• @Bean 어노테이션을 사용해 메서드에서 정의한 빈들을 스프링 컨테이너에 등록
• 스프링은 이 클래스를 읽고, 내부의 빈 정의를 스캔해 스프링 컨테이너에 빈을 등록

@Bean

• 메서드에서 반환하는 객체를 스프링 빈으로 등록
• 빈으로 등록된 객체는 싱글톤으로 관리, 필요할 때 의존성 주입을 통해 사용

📂SpringConfig.java

@Configuration
public class SpringConfig {

    @Bean
    public MemberService memberService(){
        return new MemberService(memberRepository());
    }

    @Bean
    public MemberRepository memberRepository(){
        return new MemoryMemberRepsoitory();
    }
}

기타 참고사항

• DI의 세 가지 방식(생성자 주입, 필드 주입, setter 주입) 중,
  의존관계가 실행 중에 동적으로 변경되는 경우는 ㄴ거의 없으므로 생성자 주입을 권장
• 실무에서 정형화된 Controller, Service, Repsotitory 는 컴포넌트 스캔을 사용
• 정형화되지 않거나, 상황에 따라 구현 클래스를 변경해야 되는 경우,
  설정을 통해 스프링 빈으로 등록 - @Configuration + @Bean

• 테이블의 모든 블록을 처음부터 끝까지 읽는 방식
• 조건과 관계없이 모든 Row를 다 읽고 필요한 조건을 나중에 필터링

🍀 사용되는 상황

• WHERE 조건이 인덱스를 사용할 수 없는 경우
• 조건이 없거나, 너무 많은 Row를 반환하는 조건(WHERE salary > 100)
• 인덱스를 사용해도 효율이 낮은 경우 (인덱스 사용 시 I/O 비용 > Table Full Scan)
• 옵티마이저가 Table Full Scan이 더 빠르다고 판단할 때
• /*+ FULL */ 힌트를 명시했을 때

🍀 성능 특징

• Multiblock I/O 방식으로 상대적으로 빠르게 읽을 수 있음
• 큰 테이블에서 많은 데이터를 읽을 때는 오히려 효율적일 수 있음
• 병렬 처리(PQ)도 용이

Index Full Scan

• 인덱스의 루트부터 리프까지 전체 노드를 순차적으로 모두 스캔
• 테이블은 접근하지 않고, 인덱스만을 통해 필요한 데이터를 모두 가져올 수 있을 때 사용

🍀 사용되는 상황

• 인덱스가 WHERE, SELECT절에 있는 모든 컬럼을 포함할 때 -커버링 인덱스
  (테이블 접근 없이 인덱스만으로 처리 가능한 경우)
• ORDER BY나 GROUP BY에서 정렬을 위한 인덱스를 사용하는 경우
• 옵티마이저가 인덱스 전부 읽는 것이 더 낫다고 판단할 경우
• /*+ INDEX_FFS */ 힌트 사용 시

🍀 성능 특징

• 테이블을 접근하지 않음 → Disk I/O 줄어듦
• 주로 인덱스 컬럼만 필요할 때 유리
• 읽기 순서가 정렬된 상태이므로 정렬이 불필요한 경우도 있음
• 인덱스 전체를 읽으므로 레코드 수가 많으면 비용 발생

• 쿼리가 필요한 모든 컬럼의 값을 인덱스만 보고 조회할 수 있는 경우, 그 인덱스가 커버링 인덱스
• 즉, 테이블까지 접근할 필요 없이 인덱스에서만 모든 데이터를 가져올 수 있는 경우
• 쿼리를 수행할 때 인덱스만 보고도 결과를 낼 수 있는 상황
• ✨ 테이블 액세스 없이 처리된다는 점이 핵심

SELECT name, age FROM users WHERE email = 'abc@example.com';

CREATE INDEX idx_users_email_name_age ON users(email, name, age);

• 이 인덱스는 다음 순서로 데이터를 포함한다.
  • email
  • name
  • age
• 인덱스 구성요소인 email 은 위의 SQL 쿼리에서 검색 조건에 해당하고,
  name과 age는 조회 컬럼에 해당하는데
  SQL 쿼리가 요구하는 바(email로 필터링하고 name, age를 조회)와 상응하기에
• 인덱스만으로 쿼리 결과를 반환할 수 있어 커버링 인덱스*에 해당된다.
• 즉, email 을 검색 조건으로 사용하고, name과 age가 이미 인덱스 안에 포함돼있어, 인덱스만 보고 결과를 만들 수 있다 - 커버링 인덱스

커버링 인덱스의 성능상 이점

1. 테이블 액세스를 생략(인덱스 레벨에서 처리 → 랜덤 I/O 감소)
2. 디스크 I/O 절감
3. 쿼리 속도 향상(🚀빠른 쿼리 수행)

커버링 인덱스 주의할 점

1. SELECT * 같은 쿼리는 효과 없음❗ (테이블 전체 컬럼을 참조하므로 인덱스로 커버 불가능하다)
2. 인덱스에 너무 많은 컬럼을 포함시키면 쓰기 성능 저하 및 인덱스 크기 증가 우류
3. 인덱스 컬럼 순서도 중요 (WHERE, SELECT 절을 모두 고려해 설계해야 함)

일반 인덱스 vs 커버링 인덱스 차이

ref. https://jojoldu.tistory.com/476

WHERE 업체명 LIKE '%대한%'

• 와일드카드 %가 앞에 위치하면 문자열의 시작 위치가 불확실하여, 인덱스를 사용 불가능(Range Scan 불가능)❌
• 일반적으로 Table Full Scan이 수행된다.

WHERE 업체명 LIKE '대한%'

• 와일드카드가 뒤에만 위치한 경우, 문자열의 시작이 고정되므로 B-Tree 인덱스를 활용한 Range Scan이 가능

그런데 LIKE 연산자에서도 사용 가능한 인덱스가 있다 ..? 👀

LIKE '%KEYWORD%' 같은 접두어가 없는 패턴 검색은
B-Tree 인덱스로는 인덱스 사용이 불가능하지만, 전문 검색(FULL TEXT SEARCH) 기술을 도입하면 인덱스를 통한 효율적인 검색이 가능하다.

1. InnoDB Full Text Index

• %KEYWORD% 처럼 중간 또는 끝에 있는 단어 검색 가능
• MATCH(column) AGAINST('keyword' IN BOOLEAN MODE) 형식으로 사용
• 내부적으로 역색인(Inverted Index)을 활용하므로, 중간 검색도 빠름

✅ FULL TEXT INDEX의 역색인 구조는 일반 인덱스의 B-Tree 구조와 다름!

2. n-gram parser

• 한글처럼 공백 없는 언어 지원을 위해 도입
• FULL TEXT INDEX에 WITH PARSER ngram 설정 필요
• 한글 포함 문자열에서도 '%KEYWORD%' 검색 최적화 가능

3. ElasticSearch - 외부 전문 검색 엔진

• 외부에 데이터를 연동해서 사용하는 방식.
• LIKE '%keyword%'가 아닌, match나 wildcard 등 다양한 검색 쿼리 제공
• 중간 단어, 복합 키워드, 형태소 분석까지 고도화 가능.
• 대규모 검색 시스템에 적합 (쇼핑몰 검색, 리뷰 검색 등)

FULL TEXT INDEX를 활용한 개발 경험 사례 공유

FULL TEXT INDEX을 사용한 개발 및 학습 일지 FULL TEXT INDEX를 도입한 개발 PR