Heyjinu Dev

PHP/Laravel 학습 시작 - 프로젝트 생성부터 MySQL 연결까지

Heyjinu_ — Sat, 25 Apr 2026 16:18:08 +0900

회사에서 사용하는 기술 스택을 확인해 보니 PHP, Laravel, Vue.js 주로 사용하는것같더라... 기존에는 Java/Spring 기반으로 프로젝트를 진행해 왔지만, 실제 회사 환경에 빠르게 적응하려면 Laravel 기반의 백엔드 구조도 직접 만들어보는 것이 필요하다고 판단했다.

이번 글에서는 Laravel 프로젝트를 처음 생성하고, 기본 SQLite 설정에서 MySQL로 변경한 뒤 DBeaver에서 테이블 생성까지 확인한 과정을 정리한다.

1. 개발 환경

이번 실습 환경은 다음과 같다.

OS: Windows
PHP: 8.3.9
Laravel: 13.6.0
DB: MySQL
DB Tool: DBeaver 25.3.3
Terminal: Git Bash

처음에는 Git Bash에서 Laravel 프로젝트를 생성했고, 데이터베이스 확인은 DBeaver를 사용했다.

2. Composer 설치 확인

Composer 다운로드 페이지

Laravel 프로젝트를 생성하려면 Composer가 필요하다. 먼저 터미널에서 Composer가 정상적으로 설치되어 있는지 확인했다.

composer -V

처음에는 Composer 명령어가 잡히지 않아 Windows용 Composer Installer를 설치했다. 설치 후 새 터미널을 열고 다시 확인하니 정상적으로 Composer 명령어가 실행되었다.

3. Laravel 프로젝트 생성

프로젝트는 바탕화면 경로에서 생성했다.

cd ~/Desktop
composer create-project laravel/laravel shuttle-admin-backend

프로젝트 생성이 완료되면 아래와 같은 Laravel 기본 구조가 만들어진다.

app/
bootstrap/
config/
database/
public/
resources/
routes/
storage/
vendor/
.env
artisan
composer.json

여기서 Laravel이 편하다고 느꼈던 부분은 명령어 한 번으로 .env, 라우팅, 마이그레이션, 기본 디렉토리 구조가 한 번에 생성된다는 점이었다.

Spring Boot에서 직접 설정하던 것들과 비교하면, Laravel은 초기에 필요한 골격을 빠르게 만들어주는 느낌이 강했다.

4. Laravel 서버 실행

프로젝트 폴더로 이동한 뒤 서버를 실행했다.

cd shuttle-admin-backend
php artisan serve

정상적으로 실행되면 다음과 같은 메시지가 나온다.

INFO  Server running on [http://127.0.0.1:8000].

여기서 처음 실수한 부분이 있었다. 브라우저에 127.0.0.1만 입력했더니 접속이 되지 않았다.

Laravel 개발 서버는 8000 포트에서 실행되고 있었기 때문에 정확히 아래 주소로 접속해야 했다.

http://127.0.0.1:8000

5. 첫 번째 오류 - SQLite driver 문제

처음 접속했을 때 Laravel 화면이 바로 뜨지 않고 다음과 같은 오류가 발생했다.

could not find driver
Connection: sqlite
Database: database/database.sqlite

원인은 .env 파일의 기본 DB 설정이 SQLite로 되어 있었기 때문이다.

DB_CONNECTION=sqlite

하지만 현재 PHP 환경에는 SQLite 드라이버가 활성화되어 있지 않았기 때문에 DB 연결 과정에서 오류가 발생했다.

어차피 이후 MySQL을 사용할 예정이었기 때문에 SQLite 설정을 우회하지 않고 바로 MySQL 연결로 변경하기로 했다.

6. DBeaver에서 MySQL 연결

MySQL 관리는 DBeaver를 사용했다.

DBeaver에서 새 연결을 만들고 MySQL을 선택한 뒤 다음과 같이 입력했다.

Server Host: localhost
Port: 3306
Username: root
Password: 본인 MySQL 비밀번호

처음에는 33066 포트로 연결을 시도했지만 해당 포트에 MySQL 서버가 떠 있지 않아 연결이 거부되었다.

Connection refused: getsockopt
Communications link failure

결국 일반적인 MySQL 기본 포트인 3306으로 변경해서 진행했다.

7. shuttle_admin 데이터베이스 생성

Laravel 프로젝트에서 사용할 데이터베이스를 생성했다.

DBeaver SQL Editor에서 다음 쿼리를 실행했다.

CREATE DATABASE shuttle_admin
DEFAULT CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;

생성 후 shuttle_admin 데이터베이스가 정상적으로 보이는 것을 확인했다.

8. Laravel .env MySQL 설정 변경

Laravel 프로젝트의 .env 파일을 열어 DB 설정을 수정했다.

기존 설정은 SQLite였다.

DB_CONNECTION=sqlite

이를 MySQL 설정으로 변경했다.

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=shuttle_admin
DB_USERNAME=root
DB_PASSWORD=본인비밀번호

비밀번호가 root라면 아래처럼 작성하면 된다.

DB_PASSWORD=root

비밀번호가 없다면 비워두면 된다.

DB_PASSWORD=

9. 두 번째 오류 - pdo_mysql driver 문제

.env를 MySQL로 변경한 뒤 마이그레이션을 실행했다.

php artisan migrate

그런데 다음 오류가 발생했다.

could not find driver
Connection: mysql

이번에는 MySQL 서버 문제가 아니라 PHP의 MySQL 드라이버 문제였다.

DBeaver가 MySQL에 연결되는 것과 Laravel이 MySQL에 연결되는 것은 별개다. DBeaver는 자체 드라이버로 MySQL에 접속하지만, Laravel은 PHP의 PDO MySQL 드라이버를 사용한다.

즉, PHP에서 pdo_mysql 확장이 활성화되어 있어야 한다.

PHP 설정 파일 위치를 확인했다.

php --ini

그리고 PHP 모듈 목록에서 MySQL 관련 확장을 확인했다.

php -m | grep -i mysql

pdo_mysql이 보이지 않으면 php.ini 파일에서 아래 주석을 해제해야 한다.

;extension=pdo_mysql
;extension=mysqli

아래처럼 세미콜론을 제거한다.

extension=pdo_mysql
extension=mysqli

수정 후 터미널을 새로 열고 다시 마이그레이션을 실행했다.

10. 마이그레이션 성공

다시 마이그레이션을 실행했다.

php artisan migrate

이번에는 정상적으로 실행되었다.

Laravel이 MySQL에 정상적으로 연결되었고, 기본 테이블들이 생성되었다.

11. DBeaver에서 테이블 확인

DBeaver에서 shuttle_admin 데이터베이스를 선택하고 다음 쿼리를 실행했다.

show tables;

결과는 다음과 같았다.

Laravel 기본 마이그레이션으로 생성된 테이블들이 정상적으로 확인되었다.

12. Laravel 기본 화면 확인

마지막으로 다시 Laravel 서버를 실행했다.

php artisan serve

브라우저에서 아래 주소로 접속했다.

http://127.0.0.1:8000

이번에는 DB 오류 없이 Laravel 기본 화면이 정상적으로 출력되었다.

정리

이번 실습에서는 Laravel 프로젝트를 생성하고 MySQL과 연결하는 기본 흐름을 진행했다.

정리하면 다음 순서다.

Composer 설치 확인
Laravel 프로젝트 생성
php artisan serve로 서버 실행
기본 SQLite 설정 오류 확인
MySQL 데이터베이스 생성
.env를 MySQL 설정으로 변경
pdo_mysql 드라이버 활성화
php artisan migrate 실행
DBeaver에서 테이블 생성 확인
Laravel 기본 화면 확인

이번 과정에서 중요한 점은 단순히 Laravel 화면을 띄우는 것이 아니라, Laravel이 어떤 방식으로 .env 설정을 읽고 DB에 연결하는지 직접 확인했다는 것이다.

특히 DBeaver 연결 성공과 Laravel DB 연결 성공은 별개라는 점을 알게 되었다. DBeaver는 DB GUI 도구이고, Laravel은 PHP의 PDO 드라이버를 통해 MySQL에 연결하기 때문에 PHP 확장 설정도 반드시 확인해야 한다.

[LG U+ 유레카 3기] Redis Queue + Scheduler로 선착순 쿠폰(100장) 동시성 해결 실습

Heyjinu_ — Tue, 6 Jan 2026 15:36:16 +0900

Redis Queue + Scheduler로 선착순 쿠폰(100장) 동시성 해결 실습

❶ 상황 설명

선착순 쿠폰 이벤트는 “동시에 많은 사용자가 몰리는” 대표적인 동시성 문제다.
처음엔 JPA에서 quantity를 그냥 감소시키면, 여러 요청이 동시에 들어올 때 갱신 유실(Lost Update) 때문에 재고가 깨지기 쉽다.
이번 실습에서는 DB 락에만 의존하지 않고, Redis Queue로 요청을 줄 세운 뒤 Scheduler가 순차적으로 발급하는 구조로 선착순 100장을 안정적으로 처리했다.

❷ 핵심 아이디어 (한 문장 요약)

신청(apply)은 Redis 큐에 넣기만 하고 빠르게 종료 → 발급(publish)은 스케줄러가 큐에서 꺼내 DB 재고를 감소 → 재고가 0이면 SoldOut 처리

Producer: apply() → Redis List에 userId를 쌓는다 (대기열 생성)
Consumer: Scheduler → userId를 pop해서 publish() 실행 (발급 로직)
선착순 제한: publish()에서 quantity <= 0 이면 SoldOutException 발생

❸ 전체 흐름(디버깅 관점으로 보기)

1) 1000명이 동시에 신청 요청

Thread 1000개가 동시에 couponService.apply(userId)를 호출
apply()는 DB를 건드리지 않고 Redis Queue에만 userId를 push
즉, “신청 단계”는 빠르게 끝나고 서버는 버틴다

2) Scheduler가 큐를 소비하며 발급

fixedDelay=100ms 마다 스케줄러가 실행
큐에서 userId를 하나씩 pop
publish(userId)로 DB 재고(quantity)를 1 감소

3) 수량이 0이면 마감

quantity <= 0 이면 SoldOutException 발생
Scheduler가 isSoldOut=true로 변경 후 더 이상 발급 로직을 태우지 않음
결과적으로 최종 quantity는 0에서 멈춘다

❹ 코드 (실습 전체)

✅ Entity: Coupon

package com.mycom.myapp.entity;

import jakarta.persistence.Entity;
import jakarta.persistence.GeneratedValue;
import jakarta.persistence.GenerationType;
import jakarta.persistence.Id;
import lombok.Data;
import lombok.NoArgsConstructor;

@Entity
@Data
@NoArgsConstructor
public class Coupon {
    @Id
    @GeneratedValue(strategy=GenerationType.IDENTITY)
    private Long id;
    private String name;
    private int quantity; // 쿠폰 수량

    public Coupon(String name,int quantity) {
        this.name = name;
        this.quantity = quantity;
    }
}

✅ Exception: SoldOutException

package com.mycom.myapp.exception;

// 쿠폰 소진을 의미하는 사용자 정의 예외
public class SoldOutException extends RuntimeException{

    private static final long serialVersionUID = 1L;

    public SoldOutException(String message) {
        super(message);
    }
}

✅ Redis Repository: CouponRedisRepository (Queue)

package com.mycom.myapp.repository;

import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.stereotype.Repository;
import lombok.RequiredArgsConstructor;

// Redis Queueing 작업 관련 처리
@Repository
@RequiredArgsConstructor
public class CouponRedisRepository {

    private final RedisTemplate<String, String> redisTemplate;

    // queue에 추가 (Producer)
    public void addToQueue(Long userId) {
        redisTemplate.opsForList().rightPush("coupon_queue", String.valueOf(userId));
    }

    // queue에서 꺼내기 (Consumer)
    public Long popFromQueue() {
        String userId = redisTemplate.opsForList().leftPop("coupon_queue");
        return userId != null ? Long.valueOf(userId) : null;
    }

    // queue 크기
    public Long getSize() {
        return redisTemplate.opsForList().size("coupon_queue");
    }
}

✅ JPA Repository: CouponRepository

package com.mycom.myapp.repository;

import org.springframework.data.jpa.repository.JpaRepository;
import com.mycom.myapp.entity.Coupon;

public interface CouponRepository extends JpaRepository<Coupon, Long> {
}

✅ Service Interface

package com.mycom.myapp.service;

// 신청(apply): 사용자를 줄 세움(Redis)
// 발급(publish): 쿠폰 수 감소(DB)
public interface CouponService {
    void apply(Long userId);
    void publish(Long userId);
}

✅ Service 구현: CouponServiceImpl

package com.mycom.myapp.service;

import org.springframework.stereotype.Service;

import com.mycom.myapp.entity.Coupon;
import com.mycom.myapp.exception.SoldOutException;
import com.mycom.myapp.repository.CouponRedisRepository;
import com.mycom.myapp.repository.CouponRepository;

import jakarta.transaction.Transactional;
import lombok.RequiredArgsConstructor;

@Service
@RequiredArgsConstructor
public class CouponServiceImpl implements CouponService {

    private final CouponRepository couponRepository;
    private final CouponRedisRepository couponRedisRepository;

    // Producer: 신청 → Redis Queue에 넣고 끝
    @Override
    public void apply(Long userId) {
        couponRedisRepository.addToQueue(userId);
    }

    // Consumer: 발급 → DB에서 수량 감소
    @Transactional
    @Override
    public void publish(Long userId) {
        Coupon coupon = couponRepository.findById(1L).orElseThrow();

        // 선착순 100개 제한
        if (coupon.getQuantity() <= 0) {
            throw new SoldOutException(coupon.getName() + " 쿠폰이 모두 소진되었습니다.");
        }

        coupon.setQuantity(coupon.getQuantity() - 1);

        System.out.println(
            coupon.getName() + " 발급 완료 : 사용자 : " + userId +
            " 잔여 수량 : " + coupon.getQuantity()
        );
    }
}

✅ Scheduler: CouponScheduler

package com.mycom.myapp.scheduler;

import org.springframework.scheduling.annotation.Scheduled;
import org.springframework.stereotype.Component;

import com.mycom.myapp.exception.SoldOutException;
import com.mycom.myapp.repository.CouponRedisRepository;
import com.mycom.myapp.service.CouponService;

import lombok.RequiredArgsConstructor;

@Component
@RequiredArgsConstructor
public class CouponScheduler {

    private final CouponRedisRepository couponRedisRepository;
    private final CouponService couponService;

    private boolean isSoldOut = false;

    @Scheduled(fixedDelay = 100) // 0.1초마다 호출
    public void couponEventScheduler() {
        while (true) {
            Long userId = couponRedisRepository.popFromQueue();

            if (userId == null) {
                // 처리할 요청이 없으면 종료 → 다음 스케줄에서 재시도
                break;
            }

            if (isSoldOut) {
                // 마감 이후 요청에 대한 정책(로그/저장/알림 등)은 확장 포인트
                continue;
            }

            try {
                couponService.publish(userId);
            } catch (SoldOutException e) {
                isSoldOut = true;
                System.out.println("선착순 쿠폰이 마감되었습니다!");
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    }
}

✅ Main: 스케줄러 활성화

package com.mycom.myapp;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.scheduling.annotation.EnableScheduling;

@SpringBootApplication
@EnableScheduling
public class SpringBootJpaRedisApplication {

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

❺ 테스트 코드 (동시 요청 1000명 + 선착순 100개 검증)

테스트는 핵심이 2가지다.
1) apply()는 DB를 안 건드린다 → 따라서 발급 결과는 Scheduler가 소비한 뒤에 검증해야 한다.
2) 테스트마다 coupon_queue를 초기화해야 한다 → Redis는 상태를 남기므로 테스트가 오염된다.

package com.mycom.myapp;

import static org.junit.jupiter.api.Assertions.assertEquals;

import java.util.concurrent.CountDownLatch;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.data.redis.core.RedisTemplate;

import com.mycom.myapp.entity.Coupon;
import com.mycom.myapp.repository.CouponRepository;
import com.mycom.myapp.service.CouponService;

@SpringBootTest
public class CouponConcurrencyTest {

    @Autowired
    private CouponRepository couponRepository;

    @Autowired
    private CouponService couponService;

    @Autowired
    private RedisTemplate<String, String> redisTemplate;

    @BeforeEach
    void setUp() {
        couponRepository.save(new Coupon("선착순 쿠폰", 100));
        redisTemplate.delete("coupon_queue");
    }

    @Test
    void queueingTest() throws Exception {
        int threadCount = 1000; // thread 1개 = user 1명
        ExecutorService executorService = Executors.newFixedThreadPool(32);
        CountDownLatch latch = new CountDownLatch(threadCount);

        for (int i = 0; i < threadCount; i++) {
            long userId = i; // 0~999
            executorService.submit(() -> {
                try {
                    couponService.apply(userId);
                } finally {
                    latch.countDown();
                }
            });
        }

        latch.await(); // 신청(큐 적재) 완료 대기

        // Scheduler가 큐를 소비할 시간 부여
        Thread.sleep(10000);

        int finalQuantity = couponRepository.findById(1L).orElseThrow().getQuantity();
        System.out.println("finalQuantity : " + finalQuantity);

        assertEquals(0, finalQuantity);
    }
}

❻ 내가 한 실수(중요) - Test 클래스에서 main 실행 시도

마지막에 내가 헷갈렸던 부분이 이거였다:

public SpringBootJpaRedisApplicationTests(String[] args) {
    SpringApplication.run(SpringBootJpaRedisApplication.class, args);
}

이건 JUnit 테스트 클래스에서 main을 직접 실행하려는 코드라서 잘못된 방향이다.
테스트 클래스는 Spring이 알아서 컨텍스트를 띄우도록 @SpringBootTest만 있으면 된다.

✅ 올바른 테스트 클래스 형태

package com.mycom.myapp;

import org.junit.jupiter.api.Test;
import org.springframework.boot.test.context.SpringBootTest;

@SpringBootTest
class SpringBootJpaRedisApplicationTests {

    @Test
    void contextLoads() {
        // 컨텍스트 로딩만 확인
    }
}

❼ 핵심 개념 정리

Redis Queue: Redis List를 큐처럼 사용(RPUSH + LPOP)해서 대기열을 만든다
Producer/Consumer: 신청은 빠르게 큐에 적재, 발급은 소비자가 순차 처리
동시성 해결 전략: “DB에 동시에 접근” 자체를 줄여서 경쟁을 최소화
테스트 포인트: apply는 DB 변화 없음 → Scheduler 소비 후 quantity를 검증해야 함

[LG U+ 유레카 3기]JPA 쿠폰 동시성 실습 – 커넥션 풀 설정에 따라 결과가 달라지는 이유

Heyjinu_ — Mon, 5 Jan 2026 16:30:18 +0900

JPA 쿠폰 동시성 실습 – 커넥션 풀 설정에 따라 결과가 달라지는 이유

이번 실습에서는 동일한 코드임에도 불구하고 트랜잭션 유무, HikariCP 커넥션 풀 크기에 따라 쿠폰 재고 결과가 완전히 달라지는 현상을 직접 확인했다.

❶ 실습 목표

선착순 쿠폰 100장
1000개의 쓰레드가 동시에 발급 요청
이론적으로 성공은 최대 100번만 발생해야 함

이 조건이 깨지면, 그 원인은 동시성 제어 실패다.

❷ 테스트 환경

Spring Boot + Spring Data JPA
Hibernate
MySQL
HikariCP (기본 커넥션 풀)

추가로, 동시성 충돌을 명확히 보기 위해 서비스 로직 내부에 Thread.sleep(200)을 넣었다.

❸ 핵심 서비스 로직


@Override
@Transactional
public void issue(Long couponId) {

    Coupon coupon = couponRepository.findById(couponId)
        .orElseThrow(() -> new IllegalArgumentException("존재하지 않는 쿠폰입니다."));

    coupon.setQuantity(coupon.getQuantity() - 1);

    try {
        Thread.sleep(200);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }

    couponRepository.saveAndFlush(coupon);
}

❹ HikariCP 커넥션 풀 설정


spring.datasource.hikari.maximum-pool-size=40

이 설정은 동시에 DB에 접근 가능한 커넥션 수를 40개로 제한한다.

❺ 실행 결과 로그


Hibernate: update coupon set name=?, quantity=? where id=?
Hibernate: update coupon set name=?, quantity=? where id=?
Hibernate: update coupon set name=?, quantity=? where id=?
Hibernate: select c1_0.id, c1_0.name, c1_0.quantity from coupon c1_0 where c1_0.id=?

finalQuantity : 68
successCount : 1000

❻ 결과 해석

항목	값
초기 수량	100
성공 요청 수	1000
최종 수량	68

이 결과는 매우 중요한 사실을 보여준다.

모든 요청이 성공했다고 판단했지만, 실제로는 재고 차감이 일부만 반영되었다.

❼ 왜 이런 현상이 발생했을까?

원인은 트랜잭션과 커넥션 풀의 조합이다.

쓰레드는 1000개
DB 커넥션은 최대 40개
나머지 쓰레드는 커넥션 대기

즉, DB 접근이 자연스럽게 부분 직렬화되었다.

하지만 이것은 락이 아니다.
단지 물리적 병목이 생긴 것뿐이다.

❽ select 수와 update 수의 차이

로그를 보면 select 쿼리는 매우 많이 발생했지만, update 쿼리는 그보다 훨씬 적다.

이는 여러 쓰레드가 같은 수량 값을 읽고, 마지막에 flush되는 값만 반영되었기 때문이다.

대표적인 Lost Update(갱신 손실) 상황이다.

❾ @Transactional이 해결책일까?

아니다.

@Transactional은 원자성을 보장할 뿐, 동시성 자체를 제어하지는 않는다.

이번 결과는 우연히 커넥션 풀 제한으로 충돌이 줄어든 것처럼 보였을 뿐이다.

❿ 이 실습이 주는 핵심 교훈

동시성 문제는 비즈니스 로직만의 문제가 아니다
트랜잭션, 커넥션 풀, DB 환경이 모두 결과에 영향을 준다
커넥션 풀 제한은 해결책이 아니라 착시를 만들 수 있다

실제 해결책은 다음과 같다.

낙관적 락 (@Version)
비관적 락 (PESSIMISTIC_WRITE)
Redis 분산 락

⓫ 면접에서 이렇게 말할 수 있다

“동시성 테스트 결과는 코드뿐 아니라 커넥션 풀 설정에도 크게 영향을 받습니다. @Transactional은 트랜잭션 경계를 보장할 뿐, 선착순 쿠폰이나 재고 차감 문제는 락 전략을 반드시 적용해야 합니다.”

[LG U+ 유레카 3기]JUnit & Spring 테스트 정리

Heyjinu_ — Wed, 3 Dec 2025 16:25:49 +0900

JUnit & Spring 테스트 기본기 정리

1. 상황 설명

LG U+ 유레카 3기 과정에서 JUnit과 Spring 테스트(@SpringBootTest, @WebMvcTest, MockMvc)를 이용해 테스트 주도 개발(TDD) 기초를 실습하는 시간이 있었지만, 수업을 못 들은 상태에서 소스 코드만 전달받은 상황을 가정하고 정리한 글이다.

이 글의 목표는 다음과 같다.

JUnit 5의 기본 어노테이션과 라이프사이클 이해
Assertion(단언) 메서드들의 역할과 사용법 정리
@SpringBootTest vs @WebMvcTest 차이 이해
MockMvc를 이용한 Controller 테스트 흐름 이해
STS4(Eclipse)에서 JUnit 테스트 실행 방법 정리

2. JUnit & TDD 기본 개념

2-1. JUnit이란?

JUnit은 자바에서 가장 널리 사용하는 단위 테스트 프레임워크 이다. 테스트 메소드에 @Test를 붙이고 실행하면, 실제 코드가 자동으로 실행되고 결과를 검증해 준다.

테스트 코드는 “실행 버튼만 누르면 스스로 돌아가는 검증 시나리오” 라고 생각하면 된다. 버튼 한 번으로 매번 브라우저 켜서 클릭하던 반복 테스트를 모두 자동화할 수 있다.

2-2. TDD(Test-Driven Development)와 JUnit

TDD는 다음의 짧은 사이클을 계속 반복하는 개발 방식이다.

Red : 먼저 실패하는 테스트 작성
Green : 테스트를 통과시키기 위한 최소한의 코드 작성
Refactor : 테스트를 통과하는 상태에서 코드 정리, 구조 개선

이때 “테스트”를 작성하는 도구가 바로 JUnit이다. 즉, 요구사항을 테스트 코드로 먼저 표현하고 → 그 테스트를 만족시키는 실제 코드를 나중에 작성 하는 흐름이 TDD다.

3. JUnit 5 기본 어노테이션 정리

3-1. 테스트 메소드와 실행 순서

@TestMethodOrder(MethodOrderer.OrderAnnotation.class)
public class TestBasic {

    @Test
    @Order(2)
    void test1() {
        System.out.println("test1()");
    }

    @Test
    @Order(1)
    void test2() {
        System.out.println("test2()");
    }

    @Test
    @DisplayName("회원 등록 테스트")
    @Order(4)
    void test3() {
        System.out.println("test3()");
    }

    @Test
    @DisplayName("회원 수정 테스트")
    @Order(3)
    void test4() {
        String s = null;
        s.length(); // NullPointerException 발생
        System.out.println("test4()");
    }
}

@Test : 이 메소드는 JUnit 테스트 메소드라는 의미. 리턴 타입은 void, 파라미터 없음.
@TestMethodOrder(MethodOrderer.OrderAnnotation.class) : @Order 애노테이션을 사용해 테스트 실행 순서를 지정.
@Order(n) : 숫자가 작을수록 먼저 실행. 기본 JUnit은 순서를 보장하지 않기 때문에, 시나리오 순서가 중요할 때만 사용.
@DisplayName("설명") : JUnit 뷰나 리포트에서 보이는 이름을 사람이 읽기 좋게 변경.

실행 순서를 정리하면 다음과 같다.

1순위: test2() (Order 1)
2순위: test1() (Order 2)
3순위: test4() (Order 3)
4순위: test3() (Order 4)

3-2. 테스트 라이프사이클 – Before/After

@BeforeAll
static void beforeAll() {
    System.out.println("beforeAll()");
}

@AfterAll
static void afterAll() {
    System.out.println("afterAll()");
}

@BeforeEach
void beforeEach() {
    System.out.println("beforeEach()");
}

@AfterEach
void afterEach() {
    System.out.println("afterEach()");
}

@BeforeAll : 테스트 클래스 전체에서 딱 한 번, 모든 테스트 전에 실행. ( static 메소드 )
@AfterAll : 모든 테스트가 끝난 뒤 딱 한 번 실행. 리소스 정리 등.
@BeforeEach : 각 테스트 메소드 실행 직전에 매번 실행.
@AfterEach : 각 테스트 메소드 실행 직후에 매번 실행 (테스트가 실패해도 실행된다는 점이 중요).

예를 들어 DB를 사용하는 테스트라면,

@BeforeAll : 테스트용 스키마 생성, 테스트 DB 연결
@BeforeEach : 테스트 데이터 초기화
@AfterEach : 트랜잭션 롤백, 임시 데이터 삭제
@AfterAll : 테스트용 스키마 제거, 커넥션 종료

4. JUnit Assertions(단언) 정리

4-1. 예외 발생 테스트 – `assertThrows`

int getStringLength(String str) { 
    return str.length(); 
}

@Test
void testException() {
    String str = null;

    assertThrows(NullPointerException.class,
                 () -> getStringLength(str),
                 "NullPointerException throws");
}

assertThrows 는 “이 코드가 실행될 때 특정 예외가 반드시 발생해야 한다” 는 것을 테스트한다. 입력이 잘못됐을 때 커스텀 예외를 던지는 서비스 로직을 검증할 때 매우 유용하다.

4-2. 묶음 테스트 – `assertAll`

int result = 0;
int m1() { return 4; }
boolean m2() { return true; }
String m3() { return "hello"; }

@Test
void testGroup() {
    assertAll("묶음 테스트",
        () -> assertEquals(4, m1()),
        () -> assertTrue(m2()),
        () -> assertNotNull(m3()),
        () -> assertEquals(0, result)
    );
}

여러 개의 관련된 검증을 한 번에 묶어서 실행할 수 있다. 중간에 하나가 실패해도 나머지 검증을 모두 수행한 뒤 어떤 것들이 실패했는지 함께 보여준다.

4-3. 배열/컬렉션 비교

int[] expectedArray = {1, 2, 3};
int[] actualArray   = {1, 2, 4};

@Test
void testArrayEquals() {
    assertArrayEquals(expectedArray, actualArray, "두 정수 배열이 같다.");
}

List<String> expectedList = List.of("abc", "def");
List<String> actualList   = List.of("abc", "xyz");

@Test
void testIterableEquals() {
    assertIterableEquals(expectedList, actualList, "두 문자열 컬렉션이 같다.");
}

배열/컬렉션의 길이와 각 항목을 모두 비교해 주기 때문에, 알고리즘 문제나 JPA 조회 결과를 검증할 때 자주 사용한다.

4-4. 동일성 vs 동등성 – `assertSame` / `assertEquals`

@Test
void testSame() {
    String str1 = "hello";
    String str2 = new String("hello");
    assertSame(str1, str2, "두 객체는 같다"); // == 비교 → 실패
}

@Test
void testEquals() {
    String str1 = "hello";
    String str2 = new String("hello");
    assertEquals(str1, str2, "두 객체는 같다"); // equals() 비교 → 성공
}

assertSame : a == b (동일한 객체인지) 비교
assertEquals : a.equals(b) (값이 같은지) 비교

4-5. 수행 시간 테스트 – `assertTimeout`

void businessLogic() {
    try {
        Thread.sleep(3000); // 3초 대기
    } catch (Exception e) {
        e.printStackTrace();
    }
}

@Test
void testTimeout() {
    assertTimeout(Duration.ofSeconds(1),
                  () -> businessLogic(),
                  "1초 미만 수행 테스트");
}

지정한 시간 안에 코드가 끝나지 않으면 테스트를 실패시키는 방식이다. 간단한 성능 기준(예: 1초 이내 처리)을 검증할 때 사용할 수 있다.

5. SpringBootTest – 애플리케이션 전체 통합 테스트

5-1. 코드 구조

@SpringBootTest
@TestMethodOrder(MethodOrderer.OrderAnnotation.class)
@Slf4j
public class DITest {

    @Autowired
    UserController userController;

    @Autowired
    UserService userService;

    @Autowired
    UserRepository userRepository;

    @Autowired
    HttpSession session;

    @Autowired
    HttpServletRequest request;

    @Test
    @Order(1)
    void testDI() {
        log.info("testDI() 시작");
        assertNotNull(userController);
        assertNotNull(userService);
        assertNotNull(userRepository);
        log.info("testDI() 종료");
    }

    @Test
    @Order(2)
    void testDIAll() {
        log.debug("testDIAll() 시작");
        assertAll("DI 묶음 테스트",
            () -> assertNotNull(userController),
            () -> assertNotNull(userService),
            () -> assertNotNull(userRepository)
        );
        log.debug("testDIAll() 종료");
    }

    @Test
    @Order(3)
    void testDISessionRequest() {
        log.info("testDISessionRequest() 시작");
        assertAll("DI 묶음 테스트",
            () -> assertNotNull(session),
            () -> assertNotNull(request)
        );
        log.info("testDISessionRequest() 종료");
    }
}

5-2. @SpringBootTest의 의미

스프링부트 애플리케이션 전체 컨텍스트를 로딩한다.
내장 톰캣, Controller, Service, Repository, DataSource 등 모든 Bean이 실제 서비스처럼 동작.
실행 속도는 느리지만, 통합 테스트 용도로 매우 유용하다.

5-3. 이 테스트가 검증하는 것

UserController, UserService, UserRepository가 정상적으로 Bean 등록되어 있는지 (DI 성공 여부).
웹 환경이 제대로 올라와서 HttpServletRequest, HttpSession 같은 객체도 주입 가능한지.
전체 애플리케이션 설정에 치명적인 문제가 없는지.

실무에서는 이 위에 실제 API 호출 테스트(예: TestRestTemplate 사용)까지 결합하여 “회원가입 → 로그인 → 권한 확인”와 같은 흐름을 하나의 통합 시나리오로 테스트하기도 한다.

6. WebMvcTest + MockMvc – Controller 레이어 슬라이스 테스트

6-1. TestController + WebMvcTest

@RestController
@Slf4j
public class TestController {

    @GetMapping("/hello")
    public void m1() {
        log.info("/hello");
    }

    @GetMapping("/param1")
    public void m2(@RequestParam("id") Integer id,
                   @RequestParam("name") String name) {
        log.info("/param1");
        log.info("id : " + id + " name : " + name);
    }

    @PostMapping("/param2")
    public void m3(TestDto testDto) {
        log.info("/param2");
        log.info(testDto.toString());
    }
}

@WebMvcTest(TestController.class)
@TestMethodOrder(MethodOrderer.OrderAnnotation.class)
public class TestControllerTest {

    @Autowired
    MockMvc mockMvc;

    @Test
    @Order(1)
    void testHello() throws Exception {
        this.mockMvc
            .perform(get("/hello"))
            .andExpect(status().isOk());
    }
}

6-2. @WebMvcTest의 특징

Web/MVC 레이어만 로딩하는 슬라이스 테스트.
지정한 Controller와 관련된 MVC 구성 요소만 올리기 때문에, 속도가 빠르다.
Service/Repository Bean은 자동으로 올리지 않으므로, 필요하면 @MockBean으로 가짜를 주입한다.

6-3. MockMvc로 HTTP 요청 흉내 내기

MockMvc는 “서버를 실제로 띄우지 않고도 Controller에 HTTP 요청을 보내는 도구”이다.

perform(get("/hello")) : GET /hello 요청을 가짜로 발생.
andExpect(status().isOk()) : HTTP 응답 코드가 200 OK인지 검증.

브라우저나 Postman으로 일일이 테스트하던 작업을 JUnit 코드로 자동화하는 것이 바로 WebMvcTest + MockMvc 패턴이다.

6-4. @SpringBootTest vs @WebMvcTest 비교

항목	@SpringBootTest	@WebMvcTest
로드 범위	애플리케이션 전체 (Controller, Service, Repository, DB 등)	Web/MVC 레이어만 (Controller 중심)
속도	느림	빠름
용도	통합 테스트, 실제 환경에 가깝게 전체 검증	Controller URL, 바인딩, 응답 코드 등 웹 레이어 집중 테스트
의존성	실제 Bean 사용	Service/Repository는 보통 `@MockBean`으로 가짜 주입

7. STS4(Eclipse)에서 JUnit 실행 방법

7-1. 단일 테스트 클래스 실행

src/test/java에서 원하는 테스트 클래스 파일을 연다.
에디터에서 파일 우클릭 → Run As > JUnit Test 선택.
하단의 JUnit 뷰에서 초록/빨강 바와 각 테스트 결과를 확인한다.

7-2. 메소드 하나만 실행

실행하고 싶은 @Test 메소드 안에 커서를 둔다.
우클릭 → Run As → JUnit Test.

7-3. 프로젝트 전체 테스트 실행

프로젝트 루트(최상단 패키지) 우클릭.
Run As → JUnit Test 또는 Maven Test(빌드 과정 포함) 선택.

한 번 실행한 뒤에는 Ctrl + F11 (마지막 실행 구성 재실행) 로 계속 반복 실행할 수 있다.

8. 개념 정리 & 교훈

8-1. 핵심 개념 요약

JUnit 5 : 자바 표준 단위 테스트 프레임워크. @Test, @BeforeEach, assertEquals 등을 제공.
단위 테스트 : 메소드/클래스 단위의 작은 기능을 빠르게 반복 검증.
통합 테스트 : 여러 레이어(웹, 서비스, DB)를 함께 묶어 실제에 가깝게 검증.
@SpringBootTest : 애플리케이션 전체를 로딩하는 무거운 통합 테스트.
@WebMvcTest + MockMvc : Controller만 빠르게 테스트하는 웹 슬라이스 테스트.
assertThrows / assertAll / assertTimeout : 예외, 묶음, 시간 검증 등 다양한 Assertion 기능.

8-2. 이번 실습에서 얻은 교훈

“브라우저 열고 클릭해서 눈으로 확인하던 테스트”를 모두 JUnit 코드로 옮겨오면, 언제든지 반복 실행할 수 있는 자동 회귀 테스트가 된다.
테스트가 많을수록 리팩터링이 두렵지 않고, 시스템 규모가 커져도 기존 기능이 깨졌는지 빠르게 확인할 수 있다.
실제 현업에서는 단위 테스트를 가장 많이, WebMvcTest 같은 슬라이스 테스트를 적당히, SpringBootTest 통합 테스트는 소수만 두는 “테스트 피라미드” 구조를 많이 사용한다.
유레카 과정에서 미리 JUnit과 테스트 문화를 익혀두면, 이후 프로젝트나 취업 후에도 코드 품질과 생산성을 동시에 챙길 수 있다.

이번 글은 JUnit과 Spring 테스트 기본기를 한 번에 정리한 실습 복습용 노트이다. 실제 프로젝트 코드에 @SpringBootTest, @WebMvcTest, MockMvc를 직접 붙여보고, 테스트를 돌려 보면서 감각을 익히는 것이 가장 좋은 공부 방법이다.

[LG U+ 유레카 3기]Spring Boot REST API + Swagger + Postman 연동 실습

Heyjinu_ — Tue, 2 Dec 2025 13:40:56 +0900

오늘은 Spring Boot로 만든 학생 관리 REST API에 Swagger(OpenAPI 3.0)와 Postman을 붙여서, “백엔드 API → 문서 → 테스트 도구”까지 한 번에 연결하는 실습을 했다.
단순히 코드만 작성하는 수준이 아니라, HTTP 응답 설계(ResponseEntity), API 문서화(@Tag, @Operation), OpenAPI JSON, Postman 연동까지 현업에서 실제로 사용하는 흐름과 거의 동일한 구조였다.

❶ REST API 기반 Student CRUD 구조 복습

1) 레이어드 아키텍처 구조

이번 실습의 기본 골격은 이미 만들어 둔 Student CRUD 프로젝트다. 레이어드 아키텍처 구조는 다음과 같다.

Controller : HTTP 요청(URI, 메서드) → Java 메서드 매핑, DTO 입출력 담당
Service : 비즈니스 로직, Entity ↔ DTO 변환, 예외 처리
Repository : Spring Data JPA, DB CRUD 담당
Entity : DB 테이블과 매핑되는 도메인 객체
DTO : 클라이언트와 주고받는 데이터 모델


// Entity
@Entity
@Data
@Builder
@NoArgsConstructor
@AllArgsConstructor
public class Student {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private int id;
    private String name;
    private String email;
    private String phone;
}

// DTO
@Data
@Builder
@NoArgsConstructor
@AllArgsConstructor
public class StudentDto {
    private int id;
    private String name;
    private String email;
    private String phone;
}

Service 계층에서는 Entity ↔ DTO 변환을 직접 해 주어 JPA 내부 구현이 외부(API 응답)에 새어 나가지 않도록 막는다. 이는 실제 서비스에서도 많이 쓰는 패턴이다.

❷ ResponseEntity로 HTTP 응답 제어하기

기존 컨트롤러는 단순히 StudentResultDto만 리턴해서, 스프링이 항상 200 OK로 응답하도록 두었다. 오늘은 여기서 한 단계 더 나가서 HTTP 응답 코드와 바디를 직접 제어하는 방법을 실습했다. 그 핵심이 ResponseEntity<T> 이다.

1) 기본 사용 예시


@RestController
@RequestMapping("/api")
@RequiredArgsConstructor
public class StudentControllerCrudResponseEntity {

    private final StudentServiceCrud studentServiceCrud;

    // 목록
    @GetMapping("/students")
    public ResponseEntity<StudentResultDto> listStudent() {

        StudentResultDto resultDto = studentServiceCrud.listStudent();

        // 성공
        return new ResponseEntity<>(resultDto, HttpStatus.OK);

        // 혹은 축약형
        // return ResponseEntity.ok(resultDto);
    }
}

2) 다른 HTTP 상태 코드 사용

단순 성공(200) 뿐 아니라, 상황에 따라 다른 상태 코드를 줄 수 있다.


// 200 OK - 바디 포함
return ResponseEntity
        .status(HttpStatus.OK)
        .body(studentResultDto);

// 404 Not Found - 바디 없음
return ResponseEntity
        .status(HttpStatus.NOT_FOUND)
        .build();

// 축약형 404
return ResponseEntity.notFound().build();

이렇게 하면 StudentResultDto 안에 result="success/fail" 같은 문자열만 두는 것보다, HTTP가 원래 가진 표현력(200, 404, 500 등)을 활용할 수 있어서 REST API스럽고, 클라이언트(프론트) 입장에서도 해석이 더 명확해진다.

❸ Swagger(springdoc-openapi)로 REST API 문서화

1) Gradle 의존성 추가

Swagger 2가 아니라, springdoc-openapi 기반으로 OpenAPI 3.0을 사용했다.


dependencies {
    implementation 'org.springdoc:springdoc-openapi-starter-webmvc-ui:2.5.0'
}

서버 재시작 후 아래 주소로 접속하면 Swagger UI가 자동으로 뜬다.

Swagger UI : http://localhost:8080/swagger-ui/index.html
OpenAPI JSON : http://localhost:8080/v3/api-docs
OpenAPI YAML : http://localhost:8080/v3/api-docs.yaml

2) @Tag – 컨트롤러(그룹) 단위 설명

Swagger UI에서 API를 그룹으로 묶기 위해 @Tag를 사용했다.


import io.swagger.v3.oas.annotations.tags.Tag;

@Tag(
    name = "기본 Student CRUD REST API",
    description = "Student의 등록, 수정, 삭제, 목록 조회, 상세 조회 기능을 REST API 로 제공합니다."
)
@RestController
@RequestMapping("/api")
@RequiredArgsConstructor
public class StudentControllerCrud {
    ...
}

이 태그 정보가 Swagger UI 왼쪽의 섹션 이름으로 표시된다.

3) @Operation – 메서드 단위 설명

각 API 엔드포인트(메서드)에는 @Operation을 붙여 요약(summary)과 상세 설명(description)을 작성했다.


import io.swagger.v3.oas.annotations.Operation;

@Operation(
    summary = "학생 목록 조회",
    description = "전체 학생 목록을 조회합니다."
)
@GetMapping("/students")
public StudentResultDto listStudent() {
    return studentServiceCrud.listStudent();
}

@Operation(
    summary = "학생 상세 조회",
    description = "ID 값을 이용해 개별 학생 1명의 상세 정보를 조회합니다.",
    deprecated = true   // Swagger UI 에 해당 API가 deprecated 표시
)
@GetMapping("/students/{id}")
public StudentResultDto detailStudent(@PathVariable("id") Integer id) {
    return studentServiceCrud.detailStudent(id);
}

deprecated = true 로 표시하면 Swagger UI에서 이 API가 “더 이상 권장되지 않는 API”라는 표시가 뜬다. 실무에서는 구버전 API를 남겨 두되, 새 API로 갈아타게 안내할 때 사용한다.

❹ Swagger 문서를 인터페이스로 분리하는 패턴

오늘 배운 것 중에 특히 인상 깊었던 부분은, Swagger 어노테이션을 인터페이스에 모으고, 컨트롤러 클래스는 그 인터페이스를 구현만 하는 구조였다.

1) Swagger 전용 인터페이스


@Tag(
    name = "JSON Student CRUD REST API",
    description = "JSON 요청을 통해 Student의 등록, 수정, 삭제, 조회를 수행하는 REST API"
)
public interface StudentControllerCrudJsonRequestSwagger {

    @Operation(
        summary = "학생 목록",
        description = "전체 학생 목록을 조회합니다."
    )
    @GetMapping("/students")
    StudentResultDto listStudent();

    @Operation(
        summary = "학생 상세",
        description = "개별 학생 1명을 조회합니다."
    )
    @GetMapping("/students/{id}")
    StudentResultDto detailStudent(@PathVariable("id") Integer id);

    @Operation(
        summary = "학생 등록",
        description = "JSON 요청을 통해 신규 학생 1명을 등록합니다."
    )
    @PostMapping("/students")
    StudentResultDto insertStudent(StudentDto studentDto);
}

2) 실제 컨트롤러 구현


@RestController
@RequiredArgsConstructor
public class StudentControllerCrudJsonRequest
        implements StudentControllerCrudJsonRequestSwagger {

    private final StudentServiceCrud studentServiceCrud;

    @Override
    public StudentResultDto listStudent() {
        return studentServiceCrud.listStudent();
    }

    @Override
    public StudentResultDto detailStudent(Integer id) {
        return studentServiceCrud.detailStudent(id);
    }

    @Override
    public StudentResultDto insertStudent(StudentDto studentDto) {
        return studentServiceCrud.insertStudent(studentDto);
    }
}

이 패턴의 장점은 다음과 같다.

컨트롤러 구현 코드가 Swagger 어노테이션으로 지저분해지지 않는다.
인터페이스가 API 스펙 역할을 하기 때문에, 구현체가 반드시 이 스펙을 따르도록 강제할 수 있다.
버전이 여러 개(v1, v2...)일 때 인터페이스를 나눠서 관리하기 좋다.

실무에서도 “API 스펙 인터페이스 + 구현 컨트롤러” 패턴을 쓰는 팀이 꽤 있다.

❺ /v3/api-docs JSON 확인 + JSON 포매터 + Postman Import

1) /v3/api-docs JSON 확인

Swagger UI는 사실 /v3/api-docs 에서 제공되는 OpenAPI JSON 문서를 렌더링한 것일 뿐이다.

브라우저에서 http://localhost:8080/v3/api-docs 접속
엄청 긴 JSON 텍스트가 나온다 → 이것이 API 스펙의 원본
내용 복사 후, JSON 포매터 사이트에 붙여서 구조를 보기 좋게 정리

JSON 포매터를 사용하면 paths, components.schemas, tags 구조를 한눈에 볼 수 있어서 “내 API가 OpenAPI 기준으로 어떻게 정의되어 있는지”를 정확히 확인할 수 있다.

2) Postman에 OpenAPI 스펙 Import

다음으로, 이 OpenAPI JSON을 Postman에 가져와서 API 테스트 컬렉션으로 만드는 작업을 실습했다.

Postman 실행 후 상단의 Import 버튼 클릭
Raw text 탭 선택
/v3/api-docs 에서 복사한 JSON 전체를 붙여넣기
Postman이 포맷을 자동으로 OpenAPI 3.0 으로 인식
Import as: API Collection 으로 표시되는 것 확인 후 Import 클릭

이렇게 하면 Swagger에서 정의한 모든 엔드포인트가 Postman Collection으로 자동 생성된다. 각 요청에는 이미 HTTP 메서드, URL, PathVariable 구조, RequestBody 형식이 들어있어서, 별도로 등록할 필요 없이 바로 Send 버튼만 눌러 테스트할 수 있다.

실무에서는 이 과정을 통해 “백엔드 개발자가 만든 Swagger 스펙 → 프론트/QA 팀이 Postman으로 가져와 테스트” 라는 협업 흐름이 자연스럽게 만들어진다.

❻ 오늘 실습에서 정리된 핵심 개념 요약

레이어드 아키텍처 Controller - Service - Repository - Entity/DTO를 분리해서 유지보수성과 테스트성을 높이는 구조.
ResponseEntity<T> HTTP 응답 코드, 헤더, 바디를 직접 제어할 수 있는 스프링의 응답 래퍼. ok(), status(), notFound() 등으로 표현.
springdoc-openapi Spring MVC 기반 REST API를 OpenAPI 3.0 문서로 자동 변환해 주는 라이브러리. Swagger UI도 함께 제공.
@Tag / @Operation Swagger에서 컨트롤러 그룹과 개별 API 메서드를 설명하기 위한 어노테이션.
/v3/api-docs Swagger UI가 참조하는 OpenAPI JSON 원본 문서. 이 파일이 실제 “API 계약서”.
Postman Import (OpenAPI) /v3/api-docs JSON을 Postman에 가져오면 Swagger 스펙을 기반으로 한 API Collection이 자동 생성되어 테스트가 매우 편해진다.

❼ 오늘 실습에서 얻은 교훈

단순히 “엔드포인트를 만들었다”에서 끝나는 것이 아니라, HTTP 상태 코드, 문서화, 테스트 도구까지 연결하는 것이 요즘 백엔드 개발자의 기본 역량이라는 걸 몸으로 느낀 날이었다.

코드를 짜는 것뿐 아니라, API를 설명하고 공유할 수 있는 상태까지 만들어야 한다.
Swagger(OpenAPI)와 Postman은 이를 도와주는 표준 도구 세트다.
앞으로 개인 프로젝트에서도 REST API를 만들 때, 오늘 실습한 흐름을 그대로 적용하면 포트폴리오의 완성도가 크게 올라갈 것이다.

[LG U+ 유레카 3기] Spring Data JPA find() 메서드 실습

Heyjinu_ — Wed, 26 Nov 2025 17:54:03 +0900

Spring Data JPA find() 메서드 실습 - Student 검색 패턴 정리

❶ 상황 설명

이번 오전 실습에서는 Spring Data JPA의 메서드 이름 규칙 기반 조회(find)를 집중적으로 연습했다.
특히 Student 엔티티를 대상으로 다양한 검색 패턴을 만들어 보는 것이 목표였다.

단일 조건 조회: findByName()
복합 조건 조회: findByEmailAndPhone(), findByEmailOrPhone()
문자열 패턴 조회: StartingWith, EndingWith, Containing, Like
정렬: findAllByOrderByNameDesc()
범위 검색: findByIdBetween()

핵심은 “쿼리를 직접 안 써도, 메서드 이름만으로 조건과 정렬을 표현할 수 있다”를 몸으로 체득하는 것.

❷ Student 엔티티 – 조회 대상 도메인

실습에서 조회의 대상이 되는 엔티티는 Student 테이블과 매핑되는 클래스이다.


package com.mycom.myapp.entity;

import jakarta.persistence.Entity;
import jakarta.persistence.Id;
import jakarta.persistence.Table;
import jakarta.persistence.GeneratedValue;
import jakarta.persistence.GenerationType;
import jakarta.persistence.Column;

import lombok.Getter;
import lombok.Setter;
import lombok.ToString;

@Entity
@Table(name = "student")
@Getter
@Setter
@ToString
public class Student {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Integer id;

    @Column(length = 200, nullable = false)
    private String email;

    @Column(length = 13, nullable = false)
    private String phone;

    @Column(length = 255, nullable = false)
    private String name;
}

@Entity, @Table : JPA가 관리하는 엔티티 + 테이블 이름 지정
@Id + @GeneratedValue(IDENTITY) : PK + AUTO_INCREMENT 전략
@Column : 길이와 null 여부 설정

이제 이 Student 엔티티를 기준으로, Spring Data JPA의 findBy... 메서드들을 다양하게 만들어본 것이 이번 실습의 내용이다.

❸ Repository – 메서드 이름만으로 쿼리 만들기

핵심은 Spring Data JPA 메서드 이름 규칙이다.
StudentRepository에서 메서드 이름만 보고도 어떤 SQL이 나갈지 유추할 수 있게 되는 것이 목표였다.


package com.mycom.myapp.repository;

import java.util.List;

import org.springframework.data.jpa.repository.JpaRepository;

import com.mycom.myapp.entity.Student;

public interface StudentRepository extends JpaRepository<Student, Integer> {

    // 1) 단일 조건
    List<Student> findByName(String name);

    // 2) 복합 조건 (AND / OR)
    List<Student> findByEmailAndPhone(String email, String phone);
    List<Student> findByEmailOrPhone(String email, String phone);

    // 3) 문자열 패턴
    List<Student> findByNameStartingWith(String name);
    List<Student> findByEmailEndingWith(String email);
    List<Student> findByPhoneContaining(String phone);
    List<Student> findByNameLike(String name);

    // 4) 정렬
    List<Student> findAllByOrderByNameDesc();

    // 5) 범위 검색
    List<Student> findByIdBetween(int from, int to);
}

메서드 이름 → SQL 매핑 요약

메서드 이름	의미	대략적인 JPQL / SQL
`findByName`	이름이 정확히 일치	`where name = ?`
`findByEmailAndPhone`	이메일과 전화번호 둘 다 일치	`where email = ? and phone = ?`
`findByEmailOrPhone`	이메일 또는 전화번호 중 하나라도 일치	`where email = ? or phone = ?`
`findByNameStartingWith`	이름이 특정 문자열로 시작	`where name like '값%'`
`findByEmailEndingWith`	이메일이 특정 문자열로 끝남	`where email like '%값'`
`findByPhoneContaining`	전화번호에 특정 문자열이 포함	`where phone like '%값%'`
`findByNameLike`	직접 패턴을 넣어서 like 검색	`where name like ?` (와일드카드는 개발자가 붙임)
`findAllByOrderByNameDesc`	전체를 name 내림차순으로 정렬	`order by name desc`
`findByIdBetween`	id가 구간 안에 포함되는 데이터	`where id between ? and ?` (양끝 포함)

❹ Service & Controller – 레이어드 아키텍처 적용

① Service 인터페이스


package com.mycom.myapp.service;

import java.util.List;
import com.mycom.myapp.entity.Student;

public interface StudentServiceFind {

    List<Student> findByName(String name);
    List<Student> findByEmailAndPhone(String email, String phone);
    List<Student> findByEmailOrPhone(String email, String phone);

    List<Student> findByNameStartingWith(String name);
    List<Student> findByEmailEndingWith(String email);
    List<Student> findByPhoneContaining(String phone);
    List<Student> findByNameLike(String name);

    List<Student> findAllByOrderByNameDesc();
    List<Student> findByIdBetween(int from, int to);
}

② Service 구현체


package com.mycom.myapp.service;

import java.util.List;

import org.springframework.stereotype.Service;

import com.mycom.myapp.entity.Student;
import com.mycom.myapp.repository.StudentRepository;

import lombok.RequiredArgsConstructor;

@Service
@RequiredArgsConstructor
public class StudentServiceFindImpl implements StudentServiceFind {

    private final StudentRepository studentRepository;

    @Override
    public List<Student> findByName(String name) {
        return studentRepository.findByName(name);
    }

    @Override
    public List<Student> findByEmailAndPhone(String email, String phone) {
        return studentRepository.findByEmailAndPhone(email, phone);
    }

    @Override
    public List<Student> findByEmailOrPhone(String email, String phone) {
        return studentRepository.findByEmailOrPhone(email, phone);
    }

    @Override
    public List<Student> findByEmailEndingWith(String email) {
        return studentRepository.findByEmailEndingWith(email);
    }

    @Override
    public List<Student> findByPhoneContaining(String phone) {
        return studentRepository.findByPhoneContaining(phone);
    }

    @Override
    public List<Student> findByNameStartingWith(String name) {
        return studentRepository.findByNameStartingWith(name);
    }

    @Override
    public List<Student> findByNameLike(String name) {
        // Like 패턴은 직접 만들어서 넘겨준다.
        return studentRepository.findByNameLike("%" + name + "%");
    }

    @Override
    public List<Student> findAllByOrderByNameDesc() {
        return studentRepository.findAllByOrderByNameDesc();
    }

    @Override
    public List<Student> findByIdBetween(int from, int to) {
        return studentRepository.findByIdBetween(from, to);
    }
}

③ Controller – REST API 엔드포인트


package com.mycom.myapp.controller;

import java.util.List;

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

import com.mycom.myapp.entity.Student;
import com.mycom.myapp.service.StudentServiceFind;

import lombok.RequiredArgsConstructor;

@RestController
@RequestMapping("/students")
@RequiredArgsConstructor
public class StudentControllerFind {

    private final StudentServiceFind studentServiceFind;

    @GetMapping("/find/name")
    public List<Student> findByName(@RequestParam("name") String name) {
        return studentServiceFind.findByName(name);
    }

    @GetMapping("/find/emailandphone")
    public List<Student> findByEmailAndPhone(@RequestParam("email") String email,
                                                @RequestParam("phone") String phone) {
        return studentServiceFind.findByEmailAndPhone(email, phone);
    }

    @GetMapping("/find/emailorphone")
    public List<Student> findByEmailOrPhone(@RequestParam("email") String email,
                                               @RequestParam("phone") String phone) {
        return studentServiceFind.findByEmailOrPhone(email, phone);
    }

    @GetMapping("/find/namestartingwith")
    public List<Student> findByNameStartingWith(@RequestParam("name") String name) {
        return studentServiceFind.findByNameStartingWith(name);
    }

    @GetMapping("/find/emailendingwith")
    public List<Student> findByEmailEndingWith(@RequestParam("email") String email) {
        return studentServiceFind.findByEmailEndingWith(email);
    }

    @GetMapping("/find/phonecontaining")
    public List<Student> findByPhoneContaining(@RequestParam("phone") String phone) {
        return studentServiceFind.findByPhoneContaining(phone);
    }

    @GetMapping("/find/namelike")
    public List<Student> findByNameLike(@RequestParam("name") String name) {
        return studentServiceFind.findByNameLike(name);
    }

    @GetMapping("/find/orderbynamedesc")
    public List<Student> findAllByOrderByNameDesc() {
        return studentServiceFind.findAllByOrderByNameDesc();
    }

    @GetMapping("/find/idbetween")
    public List<Student> findByIdBetween(@RequestParam("from") int from,
                                            @RequestParam("to") int to) {
        return studentServiceFind.findByIdBetween(from, to);
    }
}

이렇게 해서 Controller → Service → Repository → Entity → DB 흐름을 깔끔하게 나눈 레이어드 아키텍처로 작성했다.

❺ Postman으로 테스트한 주요 예시

1) 이름 정확 일치 검색


GET http://localhost:8080/students/find/name?name=홍길동1

2) 이메일 + 전화번호 AND 검색


GET http://localhost:8080/students/find/emailandphone?email=1@gildong.com&phone=010-0000-0001

3) 이메일 OR 전화번호 검색


GET http://localhost:8080/students/find/emailorphone?email=1@gildong.com&phone=010-0000-0003

4) 이름 시작 문자열 검색 (StartingWith)


GET http://localhost:8080/students/find/namestartingwith?name=홍길동

5) 이메일 끝나는 문자열 검색 (EndingWith)


GET http://localhost:8080/students/find/emailendingwith?email=@gmail.com

6) 전화번호 포함 문자열 검색 (Containing)


GET http://localhost:8080/students/find/phonecontaining?phone=0000

7) Like 검색 (직접 패턴 구성)


GET http://localhost:8080/students/find/namelike?name=홍길동

8) 이름 내림차순 정렬


GET http://localhost:8080/students/find/orderbynamedesc

9) ID 범위 검색 (Between)


GET http://localhost:8080/students/find/idbetween?from=31&to=40

각 요청에 대해 Hibernate가 출력하는 SQL 로그를 보면서, “메서드 이름 → 실제 쿼리”가 머릿속에서 연결되도록 확인했다.

❻ 개념 정리 – 꼭 기억해둘 포인트

Spring Data JPA 메서드 규칙을 이해하면, 간단한 조회는 JPQL/SQL을 직접 쓰지 않고도 구현 가능하다.
findByXxx : 기본 equal 검색
And, Or : 복합 조건 결합
StartingWith / EndingWith / Containing : 내부적으로 like를 사용
Like : 패턴("%값%")은 개발자가 직접 만들어서 넣는 방식
OrderBy필드명Desc/Asc : 정렬 조건을 메서드 이름에 포함
Between : 범위 검색이며, 양 끝값도 포함된다.
레이어드 아키텍처: Controller → Service → Repository → Entity → DB 구조를 유지하면, 나중에 기능이 복잡해져도 유지보수가 훨씬 쉽다.

❼ 오늘 실습에서 얻은 교훈 / 느낀 점

간단한 조회 기능 수준에서는, “메서드 이름을 잘 짓는 것 = 쿼리를 잘 짜는 것”과 비슷하다는 감각을 얻었다.
findByNameLike("%" + name + "%") 처럼, 결국 뒤에서 어떤 SQL이 나갈지를 상상할 수 있어야 진짜로 JPA를 이해한 것이다.
Controller, Service, Repository를 분리해 둔 덕분에, 중간에 검색 조건을 추가하거나 바꿀 때 구조 전체를 바꿀 필요가 없다.
이번 실습은 이후에 배울 페이징(Pageable), 정렬(Sort), 동적 쿼리(JPQL/QueryDSL)을 이해하는 기초가 된다.

오전 실습 덕분에, 앞으로 프로젝트에서 학생/회원/게시글 등의 검색 기능을 만들 때 Spring Data JPA의 메서드 이름 기반 조회를 자신 있게 활용할 수 있는 기반이 만들어졌다.

[LG U+ 유레카 3기] Spring Data JPA CRUD + Lombok + 패턴 실습 정리

Heyjinu_ — Tue, 25 Nov 2025 17:59:06 +0900

Spring Data JPA CRUD + Lombok + 패턴 + 레이어드 아키텍처 한 번에 정리

1. 오늘 실습 상황 정리

이번 실습에서는 Spring Boot + Spring Data JPA + Lombok 조합으로 Student 테이블 CRUD + 페이징을 구현하고,
추가로 레이어드 아키텍처 개념, Lombok의 역할, Spring Data JPA 구조, Builder 패턴, Singleton 패턴까지 연결해서 정리했다.

구조는 다음처럼 구성했다.

entity : Student 엔티티
repository : StudentRepository (JpaRepository 상속)
service : StudentServiceCrud / StudentServiceCrudImpl
controller : StudentControllerCrud (REST API)
pattern : builder / methodchain / singleton 개념 예제
lombok : Lombok 어노테이션 맛보기

2. 레이어드 아키텍처 vs Spring MVC (개념 정리)

2-1. 레이어드 아키텍처란?

레이어드 아키텍처(Layered Architecture)는 애플리케이션을 역할별 층(layer)으로 나눠서 설계하는 방식이다.

대표적인 구조:

[Controller]  ← 프레젠테이션 계층 (웹 요청/응답)
   ↓
[Service]     ← 비즈니스 로직 계층
   ↓
[Repository]  ← 데이터 접근 계층 (DB 조회/저장)
   ↓
[DB]          ← 실제 데이터베이스 (MySQL 등)

각 계층은 “아래 계층의 기능만 사용”하도록 설계 → 결합도 감소, 변경 용이
테스트, 유지보수, 역할 분리가 쉬워진다.

2-2. Spring MVC는 무엇인가?

Spring MVC는 웹 요청(HTTP 요청/응답)을 처리하는 프레임워크다.
레이어드 아키텍처 중 프레젠테이션 계층(Controller + View)을 담당하는 기술이라고 보면 된다.

@Controller, @RestController 로 요청 처리
@GetMapping, @PostMapping 등으로 URL + HTTP Method 매핑

2-3. 관계 정리

레이어드 아키텍처 = 애플리케이션 전체 구조 설계 방식
Spring MVC = 그 구조 중 “웹 계층(Controller)”을 구현하는 웹 프레임워크

한 줄로 요약하면,
레이어드 아키텍처는 건물 설계도, Spring MVC는 1층 로비를 구현하는 기술 정도로 이해하면 된다.

3. DB & Student 엔티티 매핑

3-1. Student 테이블 DDL (요약)

create table student (
  id int not null auto_increment,
  email varchar(200) default null,
  phone varchar(13) default '010-0000-0000',
  name varchar(255) default null,
  primary key (id)
);

실습에서는 미리 1~100까지 홍길동1~홍길동100 데이터를 insert 해 두고, 곧바로 조회/페이징 테스트가 가능하도록 구성했다.

3-2. Student 엔티티 코드

package com.mycom.myapp.entity;

import jakarta.persistence.Entity;
import jakarta.persistence.Id;
import jakarta.persistence.Table;
import jakarta.persistence.GeneratedValue;
import jakarta.persistence.GenerationType;
import jakarta.persistence.Column;

import lombok.Getter;
import lombok.Setter;
import lombok.ToString;

@Entity
@Table(name = "student")
@Getter
@Setter
@ToString
public class Student {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY) // AUTO_INCREMENT
    private Integer id;

    @Column(length = 200)
    private String email;

    @Column(length = 13, columnDefinition = "varchar(13) default '010-0000-0000'")
    private String phone;

    @Column(length = 255)
    private String name;
}

@Entity : JPA가 관리하는 엔티티 클래스
@Table(name = "student") : 실제 매핑될 테이블 이름
@Id + @GeneratedValue(IDENTITY) : PK + AUTO_INCREMENT 전략 사용
Lombok(@Getter, @Setter, @ToString)로 보일러플레이트 코드 제거

4. Lombok이 실제로 하는 일과 정체

4-1. Lombok 이란?

Lombok은 컴파일 시점에 어노테이션을 보고 자바 코드를 자동 생성해주는 라이브러리이다.

자바 표준이 아니라 외부 라이브러리
IDE 플러그인 + Gradle/Maven 의존성 필요
소스에는 코드가 안 보여도, .class 파일에는 실제 메서드가 생성되어 들어간다.

4-2. 실습에서 사용한 Lombok 어노테이션

@Getter / @Setter : getter / setter 자동 생성
@ToString : toString() 자동 생성
@EqualsAndHashCode : equals, hashCode 자동 생성 (이번엔 직접 쓰진 않았지만 대표적인 기능)
@AllArgsConstructor, @NoArgsConstructor : 모든 필드/기본 생성자 자동 생성
@Builder : 빌더 패턴 코드 자동 생성
@RequiredArgsConstructor : final 필드만 받는 생성자 자동 생성 → 생성자 주입(DI)에 많이 사용

4-3. 왜 Spring과 궁합이 좋나?

예를 들어 Service에서 이렇게 작성하면:

@Service
@RequiredArgsConstructor
public class StudentServiceCrudImpl implements StudentServiceCrud {

    private final StudentRepository studentRepository;

    // 나머지 메서드들...
}

@RequiredArgsConstructor가 StudentRepository를 파라미터로 받는 생성자를 자동 생성
Spring 이 이 생성자를 사용해서 생성자 주입(DI)을 수행
우리는 굳이 public StudentServiceCrudImpl(StudentRepository studentRepository) {...}를 안 적어도 된다.

STS4 에 자동으로 설정되는것이아닌 직접 Lombok.jar을 열어

sts의 exe 파일을 지정해줬다.

5. Spring Data JPA & JpaRepository

5-1. JPA / Hibernate / Spring Data JPA 관계

JPA : 자바 ORM에 대한 표준 스펙(인터페이스 규격)
Hibernate : JPA 구현체 중 하나 (우리가 실제로 사용하는 라이브러리)
Spring Data JPA : JPA/Hibernate 위에 얹혀 Repository 인터페이스만 정의하면 CRUD/페이징 등을 자동 구현해 주는 스프링 프레임워크

5-2. StudentRepository 코드

package com.mycom.myapp.repository;

import org.springframework.data.jpa.repository.JpaRepository;
import com.mycom.myapp.entity.Student;

// Spring Data Jpa 의 시작은 제공되는 interface 를 상속받는 것.
// 이를 통해서 Student 에 대한 기본적인 CRUD 는 자동화 처리
// 이 interface 를 구현하는 클래스를 생성 X <= Spring Data Jpa 가 자동으로 생성
public interface StudentRepository extends JpaRepository<Student, Integer> {

}

여기서 중요한 부분:

JpaRepository<Student, Integer> 상속 → 이 순간부터 Student에 대한 CRUD, 페이징, 정렬 기능이 자동 제공
우리가 구현체 클래스를 만들지 않아도, Spring Data JPA가 프록시 객체를 만들어서 빈으로 등록

5-3. 기본 제공 메서드

findAll() : 전체 목록 조회
findById(id) : PK로 한 건 조회 → Optional<Student>
save(entity) : id 없으면 insert, id 있으면 update
deleteById(id) : PK로 삭제
count() : 전체 건수
findAll(Pageable pageable) : 페이징 & 정렬된 목록

6. Service 계층 – StudentServiceCrud & Impl

6-1. Service 인터페이스

package com.mycom.myapp.service;

import java.util.List;
import java.util.Optional;

import com.mycom.myapp.entity.Student;

// 학습 예제 코드의 간단함을 위해 Student <-> StudentDto 생략
public interface StudentServiceCrud {

    // 목록, 상세
    List<Student> listStudent();
    Optional<Student> detailStudent(int id);

    // 등록, 수정, 삭제
    Student insertStudent(Student student);
    Optional<Student> updateStudent(Student student);
    void deleteStudent(int id);

    // 전체 건수, 페이징
    long countStudent();
    List<Student> listStudent(int pageNumber, int pageSize);
}

Controller는 이 인터페이스만 바라보고 호출
구현체를 다른 걸로 교체해도 Controller 코드는 그대로 유지 가능 → 느슨한 결합

6-2. Service 구현 – StudentServiceCrudImpl

package com.mycom.myapp.service;

import java.util.List;
import java.util.Optional;

import org.springframework.data.domain.Page;
import org.springframework.data.domain.PageRequest;
import org.springframework.data.domain.Pageable;
import org.springframework.stereotype.Service;

import com.mycom.myapp.entity.Student;
import com.mycom.myapp.repository.StudentRepository;

import lombok.RequiredArgsConstructor;

@Service
@RequiredArgsConstructor
public class StudentServiceCrudImpl implements StudentServiceCrud {

    // 생성자 주입
    private final StudentRepository studentRepository;

    @Override
    public List<Student> listStudent() {
        return studentRepository.findAll(); // 전체 목록
    }

    @Override
    public Optional<Student> detailStudent(int id) {
        return studentRepository.findById(id);
    }

    // save()
    //  전달되는 엔티티 객체에 id 가 있으면 select - update
    //  전달되는 엔티티 객체에 id 가 없으면 insert
    @Override
    public Student insertStudent(Student student) {
        return studentRepository.save(student);
    }

    @Override
    public Optional<Student> updateStudent(Student student) {
        // 무조건 save 호출
        return Optional.of(studentRepository.save(student));

        // 체크하고 save 호출 (예시)
        // Optional<Student> existingStudent = studentRepository.findById(student.getId());
        // if (existingStudent.isPresent()) {
        //     return Optional.of(studentRepository.save(student));
        // }
        // return Optional.empty();
    }

    @Override
    public void deleteStudent(int id) {
        studentRepository.deleteById(id);
    }

    @Override
    public long countStudent() {
        return studentRepository.count();
    }

    // 마지막 페이지에 대한 요청을 제외하고, 페이지 요청을 하면 항상 count() 를 통해서 Page 객체를 구성한다.
    // 단순 목록 외 나머지 항목들 계산을 위해 count() 수행
    @Override
    public List<Student> listStudent(int pageNumber, int pageSize) {
        Pageable pageable = PageRequest.of(pageNumber, pageSize);
        Page<Student> page = studentRepository.findAll(pageable);
        return page.toList();
    }
}

6-3. save() 내부 동작 이해

id 없음 → 신규 엔티티로 판단 → insert into student ...
id 있음 → 기존 엔티티로 간주 → 내부적으로 select 후 update 처리

강사님 주석 내용처럼,
“id 가 없는 update 처리. findById() 와 if() 코드를 따르지 않고, 항상 save 하도록 하면 insert 가 수행된다.”
→ 이게 바로 save()의 동작 원리.

7. Controller 계층 – StudentControllerCrud

package com.mycom.myapp.controller;

import java.util.List;
import java.util.Optional;

import org.springframework.web.bind.annotation.*;

import com.mycom.myapp.entity.Student;
import com.mycom.myapp.service.StudentServiceCrud;

import lombok.RequiredArgsConstructor;

@RestController
@RequestMapping("/students")
@RequiredArgsConstructor
public class StudentControllerCrud {

    private final StudentServiceCrud studentServiceCrud;

    // 1. 전체 목록
    @GetMapping("/list")
    public List<Student> listStudent() {
        return studentServiceCrud.listStudent();
    }

    // 2. 상세 조회
    @GetMapping("/detail/{id}")
    public Optional<Student> detailStudent(@PathVariable("id") int id) {
        return studentServiceCrud.detailStudent(id);
    }

    // 3. 등록 (JSON Body)
    @PostMapping("/insert")
    public Student insertStudent(@RequestBody Student student) {
        return studentServiceCrud.insertStudent(student);
    }

    // 4. 수정 (JSON Body)
    @PutMapping("/update")
    public Optional<Student> updateStudent(@RequestBody Student student) {
        return studentServiceCrud.updateStudent(student);
    }

    // 5. 삭제
    @DeleteMapping("/delete/{id}")
    public void deleteStudent(@PathVariable("id") int id) {
        studentServiceCrud.deleteStudent(id);
    }

    // 6. 전체 건수
    @GetMapping("/count")
    public long countStudent() {
        return studentServiceCrud.countStudent();
    }

    // 7. 페이징 목록
    @GetMapping("/page")
    public List<Student> listStudent(
            @RequestParam("pageNumber") Integer pageNumber,
            @RequestParam("pageSize") Integer pageSize) {
        return studentServiceCrud.listStudent(pageNumber, pageSize);
    }
}

각 API 요약 (Postman 기준)

전체 목록 : GET /students/list
상세 : GET /students/detail/{id} (예: /students/detail/1)
등록 : POST /students/insert + Body(JSON)
수정 : PUT /students/update + Body(JSON)
삭제 : DELETE /students/delete/{id}
전체 건수 : GET /students/count
페이징 : GET /students/page?pageNumber=0&pageSize=10

8. Postman 테스트 & -parameters 문제 트러블슈팅

8-1. -parameters 에러 상황

삭제 API 호출 시 다음과 같은 에러가 떴다.

IllegalArgumentException: Name for argument of type [int] not specified,
and parameter name information not available via reflection.
Ensure that the compiler uses the '-parameters' flag.

원인:

Java 컴파일 시, 메서드 파라미터 이름(id) 정보가 class에 포함되지 않음
Spring이 @PathVariable int id 에서 id란 이름을 reflection으로 읽지 못해 에러

8-2. 해결 방법 (Gradle + STS4)

build.gradle에 다음 추가:

tasks.withType(JavaCompile) {
    options.compilerArgs += ["-parameters"]
}

추가 후:

Gradle Refresh
Project Clean
Spring Boot 재실행

8-3. @PathVariable 명시적으로 이름 지정

다음처럼 이름을 명시해 주면 더 안전하다.

@DeleteMapping("/delete/{id}")
public void deleteStudent(@PathVariable("id") int id) {
    studentServiceCrud.deleteStudent(id);
}

8-4. Postman DELETE 요청 주의

Method: DELETE
URL: http://localhost:8080/students/delete/100
Body: none (DELETE는 보통 Body 필요 없음)

9. 패턴 패키지 – Builder / Method Chaining / Singleton

9-1. Builder 패턴 예제 – Board

package com.mycom.myapp.pattern.builder;

// builder pattern (Inner Class 버전)
public class Board {
    private final String title;
    private final String content;
    private final String category;

    Board(Builder builder){
        this.title = builder.title;
        this.content = builder.content;
        this.category = builder.category;
    }

    public static class Builder{
        private String title;
        private String content;
        private String category;

        public Builder title(String title) {
            this.title = title;
            return this;
        }

        public Builder content(String content) {
            this.content = content;
            return this;
        }

        public Builder category(String category) {
            this.category = category;
            return this;
        }

        public Board build() {
            return new Board(this);
        }
    }

    @Override
    public String toString() {
        return "Board [title=" + title + ", content=" + content + ", category=" + category + "]";
    }
}

public class Test {

    public static void main(String[] args) {
        Board board = new Board.Builder()
                            .title("게시글 제목")
                            .content("게시글 내용")
                            .category("분류 A")
                            .build();

        System.out.println(board);
    }
}

9-2. Builder 패턴 vs 메서드 체이닝

메서드 체이닝(Method Chaining): obj.a().b().c() 처럼 메서드 호출을 이어서 쓰는 “스타일”
Builder 패턴: 이 체이닝 스타일을 활용해서 복잡한 객체 생성 문제를 푸는 디자인 패턴

이번 Board 예제에서:

new Board.Builder() → 빌더 객체 생성
.title(), .content(), .category() → 빌더에 값 세팅 (체이닝)
.build() → 최종 Board 객체 생성

핵심은 “필드가 많은 객체를, 생성자 대신 가독성 좋게 만들기”라는 점이다.

9-3. Singleton 패턴 – Logger 예제

public class Logger {
    private static final Logger instance = new Logger();

    private Logger() {}

    public static Logger getInstance() {
        return instance;
    }

    public void log(String msg) {
        System.out.println(msg);
    }
}

private static final Logger instance = new Logger();
→ 애플리케이션 전체에서 단 하나만 존재하는 객체를 미리 생성
private Logger() {} → 외부에서 new Logger() 금지 (생성자 숨김)
getInstance() → 이 메서드를 통해서만 Logger에 접근

즉, 질문했던 것처럼
private static final Logger instance = new Logger(); 이 줄이 “싱글톤 인스턴스 선언 + 생성”하는 부분이 맞다.
다만, 진짜 싱글톤 패턴은 보통 “private 생성자 + static 단일 필드 + static getter” 이 세트를 함께 본다.

Spring에서는 @Service, @Repository, @Controller 빈이 기본적으로 싱글톤 스코프라, 이런 패턴을 직접 구현하는 일이 많이 줄어든다.

10. 오늘 Q&A 개념 정리 요약

10-1. 레이어드 아키텍처 vs Spring MVC

레이어드 아키텍처 = 애플리케이션 전체를 계층(Controller / Service / Repository / DB)으로 나눈 설계 방식
Spring MVC = 그 중 “웹 계층(Controller)”을 구현하는 웹 프레임워크

10-2. Lombok 이란?

컴파일 시점에 어노테이션을 보고 코드(getter/setter/생성자/builder 등)를 생성해주는 라이브러리
보일러플레이트 코드 제거 → 코드 양 줄이고 가독성 증가

10-3. Spring Data JPA & JpaRepository

JpaRepository<Student, Integer> 상속 = “이 엔티티에 대한 CRUD/페이징/정렬을 Spring Data JPA가 자동 구현해줘” 라는 의미
우리는 Repository 인터페이스만 선언하고, 구현체는 만들지 않는다.

10-4. Builder 패턴 핵심

메서드 체이닝을 이용하는 “스타일”이면서, 동시에 “객체 생성 문제”를 해결하는 디자인 패턴
필드가 많거나, 선택적인 값이 많은 경우에 유용

10-5. Singleton 패턴 핵심

애플리케이션 전체에서 인스턴스가 딱 하나만 존재해야 할 때 사용하는 패턴
private static final 인스턴스 + private 생성자 + public static getter 세트로 이해

11. 교훈 / 핵심 요약

레이어드 아키텍처를 이해하면, 프로젝트 구조가 단숨에 눈에 들어온다.
Lombok은 코드 양을 줄여줄 뿐 아니라, 생성자 주입(@RequiredArgsConstructor)과 같이 스프링과 궁합이 매우 좋다.
Spring Data JPA는 JPA 위에 얹힌 추상화 계층으로, Repository 인터페이스만 정의하면 CRUD/페이징을 거의 공짜로 얻는다.
Builder 패턴은 메서드 체이닝을 활용해 복잡한 객체 생성을 가독성 좋게 만드는 패턴이다.
Singleton 패턴은 “단일 인스턴스”를 보장하는 패턴이고, 스프링 빈 기본 스코프와 개념적으로 연결된다.
Postman으로 API를 직접 호출하면서, Controller → Service → Repository → DB 흐름을 눈으로 확인해 보며 JPA 동작 방식(save, find, delete, paging)을 체감했다.

[LG U+ 유레카 3기] Spring MVC + CORS 실습

Heyjinu_ — Tue, 25 Nov 2025 14:10:13 +0900

이번 실습은 Spring MVC의 핵심 개념인 POST 처리, redirect 흐름, RestController의 JSON 응답 방식, 그리고 CORS 전역 설정까지 묶어서 진행했다.

✔ @SpringBootApplication

1️⃣ @SpringBootConfiguration

내부적으로 @Configuration을 상속
스프링 컨테이너에 설정 클래스임을 알려줌

2️⃣ @EnableAutoConfiguration

스프링이 자동으로 필요한 Bean 들을 설정해주는 기능
예:
- Tomcat 자동 설정
- DataSource 자동 설정
- MVC 설정 자동 적용
스프링 부트 “자동 설정” 핵심 기능

3️⃣ @ComponentScan

현재 패키지를 기준으로 하위 패키지 전체에서 Bean(@Component, @Service, @Repository,

❶ 로그인 POST + Redirect 동작 이해

아래는 실습에서 작성한 @PostMapping("/login") 코드이다.

@PostMapping("/login")
public String login(@RequestParam("username") String username,
                    @RequestParam("password") String password) {

    System.out.println(username);
    System.out.println(password);

    // return "main.html"; // ← 오류 남 (POST를 static HTML로 forward 시도)
    return "redirect:main.html"; // ← 정상 동작
}

✔ 왜 return "main.html" 은 에러가 발생했는가?

main.html은 static 폴더에 있고, static 리소스 제공자는 GET/HEAD만 처리한다.
POST 요청으로 static HTML을 열려고 시도하면서 다음 오류가 발생한다.

Request method 'POST' is not supported

즉, static 폴더의 HTML은 POST 방식으로 forward 할 수 없다.

✔ redirect를 사용해야 하는 이유

return "redirect:main.html" 은 내부 forward가 아니라 302 Redirect 응답이다.

브라우저에게 “/main.html 로 다시 GET 요청해라” 라고 지시
브라우저는 GET /main.html 요청 수행
static 핸들러가 정상적으로 main.html을 제공

이 구조는 웹의 고전적 패턴인 PRG (Post-Redirect-Get) 과 동일하며, 새로고침 시 중복 POST도 방지한다.

❷ @RestController 실습 – JSON/문자 응답 과정

두 번째 실습에서는 Spring MVC에서 뷰를 반환하지 않고 데이터를 직접 반환하는 @RestController 를 사용했다.

@RestController
public class JsonController {

    @GetMapping("/string")
    public String m1() {
        System.out.println("/string");
        return "안녕하세요!";
    }
}

✔ @RestController 의 의미

@RestController = @Controller + @ResponseBody

즉, 리턴값이 뷰 이름이 아니라 HTTP 응답 바디로 나간다.

그래서 return "안녕하세요!" 는 그대로 브라우저에서 문자열이 출력된다.

프론트(Vue/React)와 통신할 때 사용하는 모든 API는 이런 방식으로 만들어지며, JSON 객체도 자동 변환되어 응답된다.

❸ CORS 전역 설정 실습

오늘의 마지막 개념은 CORS (Cross-Origin Resource Sharing) 이었다.

프론트가 localhost:3000, 백엔드가 localhost:8080이면 두 도메인은 서로 다른 Origin이다.
브라우저는 보안상 이 요청을 기본적으로 차단하므로 서버가 허용해주도록 설정해야 한다.

실습에서 사용한 전역 CORS 설정 예시는 다음과 같다.

@Configuration
public class MvcConfig implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOrigins("http://localhost:3000")
                .allowedMethods("GET", "POST", "PUT", "DELETE")
                .allowedHeaders("*")
                .allowCredentials(true);
    }
}

✔ 이 설정이 의미하는 것

우리 서버의 모든 URL("/**") 에 대해
React 개발 서버(3000)에서 오는 요청을 허용
GET/POST 등 모든 주요 메서드 허용
쿠키/세션/인증 정보도 허용

요약하면, 프론트 → 백엔드 API 호출이 가능하도록 브라우저에서 막는 보안 정책을 서버가 허용해주는 것이다.

❹ 오늘 실습 전체 흐름 정리

오늘 배운 내용을 간단하게 전체 흐름으로 묶으면 아래와 같다.

로그인 화면에서 POST /login 요청 전송
@PostMapping에서 파라미터 받음
static HTML을 바로 열 수 없기 때문에 redirect 처리
API가 필요한 경우 @RestController 로 JSON/문자 반환
프론트와 실제로 연동하려면 CORS 설정 필수

즉, “Spring MVC 기본 구조 → 화면 이동 흐름 → API 방식 → CORS 허용” 의 순서로 오늘의 모든 실습은 서로 연결되어 있다.

❺ 개념 정리 (CS + Spring 핵심)

Forward: 서버 내부에서 다른 페이지로 연결 (URL 안 바뀜)
Redirect: 브라우저에게 새 GET 요청 보내도록 지시 (URL 바뀜)
@RestController: 데이터(JSON/문자)를 그대로 응답하는 컨트롤러
JSON: 프론트–백엔드 통신 표준 포맷
CORS: 브라우저가 다른 Origin 요청을 차단하는 보안 정책
static 리소스: GET 방식만 제공하는 정적 HTML/CSS/JS 파일
PRG 패턴: POST → Redirect → GET 흐름

마무리

이번 24일 실습은 Spring 기본기 중에서 가장 핵심적인 흐름을 전부 손으로 직접 해본 중요한 수업이었다.
특히 redirect 문제와 RestController/CORS 개념은 나중에 React/Spring 연동할 때 그대로 쓰이기 때문에 꼭 정확히 이해해두면 좋다.

[LG U+ 유레카 3기] JPA N+1 · Fetch Join · JPQL Join

Heyjinu_ — Thu, 20 Nov 2025 16:33:19 +0900

오늘은 JPA를 사용할 때 반드시 알아야 하는 N+1 문제와 이를 해결하는 fetch join, 그리고 JPQL Join 문법을 실습 중심으로 정리한 날이다.
실제 Hibernate 로그가 어떻게 출력되는지 직접 보면서 이해하는 “핵심 실습”이었기 때문에 내용을 정확히 정리해두면 향후 프로젝트/JPA 최적화에 큰 도움이 된다.

❶ N+1 문제란?

기본 엔티티 목록을 조회하는 SELECT(1) 후, 각 엔티티가 가지고 있는 연관 엔티티를 N번 추가로 조회하며 발생하는 비효율이다.

String jpql = "select o from Orders o";
List<Orders> list = em.createQuery(jpql, Orders.class)
                       .getResultList();

Hibernate 로그는 아래처럼 찍힌다.

# 1) Orders 목록 조회
select * from orders;

# 2) Orders 각각에 대해 Product/Customer 즉시 로딩(EAGER)
select * from product where id=?
select * from customer where id=?
select * from product where id=?
select * from customer where id=?
...

즉 1번 + N번 = 총 N+1개의 SQL이 실행되어 성능이 치명적으로 떨어진다.

❷ 왜 발생하는가? (핵심 원리)

JPA의 연관 관계 기본 로딩 전략 때문.

LAZY → “필요한 순간 조회” → 목록 조회 시 거의 100% N+1
EAGER → “즉시 조회”이지만 JOIN을 강제하는 게 아니라 엔티티 로딩 순간 추가 SELECT를 실행

그래서 EAGER도 목록 조회에서는 N+1이 발생한다.

❸ 해결 방법: Fetch Join

핵심 해결책은 join fetch 한 줄이다.

String jpql = 
"select o from Orders o 
 join fetch o.customer 
 join fetch o.product";

List<Orders> list = em.createQuery(jpql, Orders.class).getResultList();

Hibernate 출력:

select o.*, c.*, p.*
from orders o
join customer c on o.customer_id = c.id
join product p on o.product_id = p.id;

→ 단 1번의 SELECT로 Orders + Product + Customer를 모두 로딩
→ N+1 완벽 제거

❹ JPQL Join 문법 2가지 방식

1) 현대적인 join 문법 (추천)

select o, p
from Orders o
join o.product p

관계 필드를 기준으로 JOIN하는 정석 JPQL 문법이다.

2) 전통 스타일 (SQL 스타일)

select o, p 
from Orders o, Product p 
where o.product = p

이는 SQL의 고전 조인 방식이며 내부적으로는 아래와 동일한 의미이다.

from orders o
cross join product p
where o.product_id = p.id

실제로는 INNER JOIN처럼 동작한다.
하지만 실무/강의에서는 관계 필드 기반 JOIN을 훨씬 더 많이 사용한다.

❺ 엔티티 두 개를 동시에 Select하는 경우

select o, p 
from Orders o 
join o.product p

결과 타입은 무조건 List<Object[]> 형태.

for(Object[] row : result){
    Orders o = (Orders) row[0];
    Product p = (Product) row[1];
}

❻ UnknownEntityException 원인 정리

JPA/Hibernate 수동 환경에서는 엔티티를 직접 등록해야 한다.
MyPersistenceUnitInfo 안에 아래가 반드시 있어야 한다.

@Override
public List<String> getManagedClassNames() {
    return List.of(
        "entity.Orders",
        "entity.Customer",
        "entity.Product"
    );
}

등록을 빠뜨리면 Hibernate는 엔티티를 모른다 → UnknownEntityException: Could not resolve root entity ‘Orders’

❼ 실무적 결론

JPA 사용할 때 반드시 기억해야 하는 3줄 결론:

1) 목록 조회 시는 무조건 LAZY + fetch join 조합
2) EAGER는 예상보다 더 쉽게 N+1을 유발
3) JPQL join은 join o.product 형태가 가장 안전하고 정석

오늘 내용은 JPA 성능 최적화의 핵심이기 때문에 나중에 스프링 부트 프로젝트에서도 그대로 적용된다.

마무리

Hibernate 로그를 직접 확인하며 N+1 → fetch join → join 문법을 모두 체득한 하루였다.
이제부터 JPQL 목록 조회가 보이면 자동으로 “여기 fetch join 필요하겠는데?” 하고 감이 올 것이다.

[LG U+ 유레카 3기] JPA 연관관계 & Fetch 전략

Heyjinu_ — Wed, 19 Nov 2025 22:48:17 +0900

[LG U+ 유레카 3기] "JPA 연관관계 & Fetch 전략(OneToMany / ManyToMany) 실습 정리"

JPA 연관관계 & Fetch 전략 (어제+오늘 실습 총정리)

❶ 실습 환경 & 공통 흐름

이번 이틀 동안의 실습은 순수 JPA + Hibernate 조합으로 진행했다.
Spring 없이 직접 EntityManagerFactory와 EntityManager를 만들면서 내부 동작을 눈으로 확인하는 것이 목표였다.


public class TestTemplate {

    public static void main(String[] args) {

        Map<String, String> props = new HashMap<>();
        props.put("hibernate.hbm2ddl.auto", "update");
        props.put("hibernate.show_sql", "true");

        EntityManagerFactory emf = new HibernatePersistenceProvider()
                .createContainerEntityManagerFactory(new MyPersistenceUnitInfo(), props);

        EntityManager em = emf.createEntityManager();
        em.getTransaction().begin();

        // 여기서 각종 실습 코드 실행

        em.getTransaction().commit();
        em.close();
    }
}

핵심 포인트
- MyPersistenceUnitInfo : persistence.xml 대신 자바 코드로 설정을 넘겨주는 역할
- hibernate.show_sql=true : JPA 코드 한 줄이 어떤 SQL로 바뀌는지 눈으로 확인</음>
- hibernate.hbm2ddl.auto=update : 테이블 구조만 자동 갱신, 기존 데이터는 유지

❷ OneToMany(Post ↔ Comment) 연관관계 & Fetch 전략

1) 엔티티 구조

게시글(Post) 하나에 댓글(Comment) 여러 개가 달리는 아주 익숙한 구조를 사용했다.


// Post.java
@Entity
public class Post {

    @Id @GeneratedValue
    private Integer id;

    private String title;
    private String content;

    @OneToMany(mappedBy = "post", fetch = FetchType.LAZY)
    private List<Comment> comments = new ArrayList<>();

    // getters, setters, toString ...
}

// Comment.java
@Entity
public class Comment {

    @Id @GeneratedValue
    private Integer id;

    private String content;

    @ManyToOne(fetch = FetchType.LAZY)
    private Post post;

    // getters, setters, toString ...
}

Post : Comment = 1 : N
@OneToMany(mappedBy = "post") : 연관관계의 주인은 Comment (FK를 가진 쪽)
양쪽 모두 FetchType 기본값은 LAZY

2) LAZY에서의 조회 흐름


Post p = em.find(Post.class, 1);      // Post 한 건만 select
List<Comment> comments = p.getComments(); // 이 시점에는 select 없음

// 실제로 데이터를 사용할 때 비로소 select 발생
comments.forEach(System.out::println);

처음에는 find() 호출 시 댓글까지 전부 가져올 줄 알았지만, 콘솔을 보니 Post만 select되고 댓글은 조회되지 않았다. 리스트를 실제로 출력하는 순간에야 Hibernate가 댓글을 가져오기 위한 SQL을 날리는 것을 확인했다.

즉, LAZY는 “필요할 때까지 DB 접근을 미룬다” 라는 개념을 눈으로 확인한 실습이었다.

3) EAGER로 바꿨을 때의 변화


@OneToMany(mappedBy = "post", fetch = FetchType.EAGER)
private List<Comment> comments;


Post p = em.find(Post.class, 1); // 이 한 줄에서 Post + Comment + 조인 테이블까지 한 번에 join

FetchType을 EAGER로 바꾼 후에는 게시글 하나를 조회하는 순간, JPA가 Post, Comment, 조인 테이블을 한 번에 join 해서 가져왔다. “편해 보이지만, 댓글이 수천 개라면 매번 join 지옥”이 되기 때문에 실무에서는 거의 사용하지 않는다는 것을 체감했다.

4) 컬렉션 변경 시 delete → insert 폭탄의 이유


Post p = em.find(Post.class, 1); // 기존 댓글 2개라고 가정

Comment c3 = new Comment();
c3.setContent("코멘트 3");
c3.setPost(p);

p.getComments().add(c3);
em.persist(c3);  // c3 영속화

// 트랜잭션 커밋 시점
em.getTransaction().commit();

커밋 시점에 로그를 확인해보면 다음과 같은 순서로 SQL이 실행된다.

select : 기존 Post, Comment, 조인 테이블 조회
insert into Comment ...
delete from Post_Comment where post_id = ?
insert into Post_Comment (post_id, comments_id) values (?,?) 여러 번

처음에는 “댓글 하나 추가했는데 왜 전체 delete 후 insert를 다시 하지?” 라는 의문이 들었다.
원인은 Hibernate의 변경 감지(Dirty Checking) 방식 때문이다.

엔티티가 처음 영속 상태가 될 때 스냅샷(snapshot)을 저장해 둔다.
단순 필드(제목, 내용 등)는 이전 값과 지금 값을 비교해서 변경 여부를 쉽게 판단할 수 있다.
하지만 컬렉션(List<Comment>)은 “어떤 것이 추가/삭제/순서 변경되었는지” 비교 비용이 크다.

그래서 Hibernate는 컬렉션에 대해서는 똑똑하게 diff를 계산하는 대신,
“그냥 다 지우고 지금 리스트 상태대로 다시 넣자” 라는 단순한 전략을 택한다.

이 동작을 실제 SQL 로그로 확인하면서, 면접에서 자주 나오는 컬렉션 연관관계의 delete → insert 패턴을 몸으로 이해하게 된 실습이었다.

❸ ManyToMany(Team ↔ User) 저장 실습 – 연관관계의 주인 & Cascade

1) 엔티티 구조


// Team.java
@Entity
public class Team {

    @Id @GeneratedValue
    private Integer id;

    private String name;

    @ManyToMany(/* 필요 시 cascade, fetch 등 옵션 */)
    private List<User> users = new ArrayList<>();
}

// User.java
@Entity
public class User {

    @Id @GeneratedValue
    private Integer id;

    private String name;

    @ManyToMany(mappedBy = "users")
    private List<Team> teams = new ArrayList<>();
}

Team과 User 사이에는 다대다(N:N) 관계가 있고,
DB에는 teams, users, teams_users 3개의 테이블이 생성된다.

2) Team ↔ User를 어떻게 저장하느냐에 따른 결과 비교

(1) Team과 User를 각각 따로 저장


User u1 = new User(); u1.setName("회원 1");
User u2 = new User(); u2.setName("회원 2");

Team t1 = new Team(); t1.setName("팀 1");
Team t2 = new Team(); t2.setName("팀 2");

em.persist(u1);
em.persist(u2);
em.persist(t1);
em.persist(t2);

users 테이블 : 2건 insert
teams 테이블 : 2건 insert
teams_users : 아무 것도 insert 안 됨 (연관관계를 아직 안 걸었기 때문)

(2) Team에 User 리스트를 연결 후, Team만 persist 했을 때


t1.setUsers(List.of(u1, u2));
t2.setUsers(List.of(u2));

em.persist(t1);
em.persist(t2);

User가 아직 영속 상태가 아니기 때문에, 저장되지 않은(transient) 객체를 참조한다는 예외가 발생한다.

(3) Team에 User를 연결하고, Team과 User 모두 persist 했을 때


t1.setUsers(List.of(u1, u2));
t2.setUsers(List.of(u2));

em.persist(t1);
em.persist(t2);
em.persist(u1);
em.persist(u2);

teams insert 2건
users insert 2건
teams_users insert 3건 (t1-u1, t1-u2, t2-u2)

여기서 배운 것: 다대다 관계에서는 조인 테이블 저장을 누가 담당하는지가 중요하다.

(4) User에 Team을 설정하고, User만 persist 했을 때


u1.setTeams(List.of(t1, t2));
u2.setTeams(List.of(t2));

em.persist(u1);
em.persist(u2);

users : insert 2건
teams : insert 없음
teams_users : 역시 insert 없음

처음에는 “User에서 Team을 걸어줬는데 왜 조인 테이블이 비어 있지?” 라는 의문이 들었지만, 원인은 연관관계의 주인(Owning Side) 개념에 있다.

이 실습에서는 Team 쪽이 주인이라고 가정했기 때문에,
주인이 아닌 User에서 아무리 setTeams()를 해도 DB에는 반영되지 않는다.

(5) CascadeType.PERSIST를 사용한 Team 중심 저장

Team에 cascade = CascadeType.PERSIST를 설정하고 다음 코드를 실행했다.


t1.setUsers(List.of(u1, u2));
t2.setUsers(List.of(u2));

em.persist(t1);
em.persist(t2); // cascade 덕분에 User도 함께 persist

teams : insert 2건
users : insert 2건 (cascade)
teams_users : insert 3건

결론적으로 Cascade는 엔티티 저장 전파를 담당하고,
조인 테이블에 무엇이 들어가는지는 연관관계의 주인이 결정한다는 것을 실습으로 확인했다.

❹ ManyToMany 조회 & Fetch 전략 + toString() 순환 참조

1) Team 한 건만 find 했을 때 (LAZY)


Team t1 = em.find(Team.class, 1);

SQL 로그를 보면 teams 테이블만 select 되고, teams_users와 users는 조회되지 않는다. ManyToMany의 기본 fetch가 LAZY라는 것을 다시 한 번 확인한 부분이다.

2) Team을 출력하면서 toString() 호출 – StackOverflowError


Team t1 = em.find(Team.class, 1);
System.out.println(t1); // toString() 체인 호출

Team의 toString()에서 users를 출력하고,
User의 toString()에서 다시 teams를 출력하도록 구현되어 있으면, 아래와 같은 순환이 만들어진다.

Team.toString() → users 출력
User.toString() → teams 출력
다시 Team.toString() → users 출력
… 무한 반복 → StackOverflowError

실제 실행 결과, 연관된 Team과 User를 번갈아가며 select 하다가 스택이 꽉 차서 에러가 발생했다.

그래서 실무에서는 다음과 같이 처리하는 것이 기본 패턴이다.

toString()에서 연관 필드는 빼거나
Lombok 사용 시 @ToString.Exclude 적용
JSON 변환 시에는 @JsonIgnore 등으로 순환 참조 방지

3) User에서 teams를 사용할 때의 쿼리 흐름 (LAZY)


User u1 = em.find(User.class, 1);      // users 한 건만 select
u1.getTeams().forEach(System.out::println); // 이 시점에 teams, users 추가 select

여기서는 다음과 같은 순서로 쿼리가 발생한다.

user 1건 조회
해당 user가 속한 team 목록을 가져오기 위해 teams_users + teams join
각 team의 toString() 안에서 users를 출력하면 다시 teams_users + users 조회

즉, LAZY를 잘못 쓰면 이런 식으로 N+1 문제가 자연스럽게 발생한다는 것을 몸으로 느낀 실습이었다.

4) Team의 FetchType을 EAGER로 바꿨을 때


@ManyToMany(fetch = FetchType.EAGER)
private List<User> users;


Team t1 = em.find(Team.class, 1);

이번에는 Team 한 건을 조회하는 순간, teams, teams_users, users를 모두 left join 해서 가져왔다.

“조회 한 번에 다 가져와서 편해 보이지만, join 폭탄이 될 수 있다”는 점 때문에
실무에서는 기본적으로 LAZY + 필요할 때 fetch join 사용이 정석이라는 것도 다시 정리했다.

❺ hbm2ddl.auto 옵션 실습 – create vs update

Product 예제에서 JPQL을 사용하기 전에, 미리 MySQL에서 데이터를 insert 해 두고 실행했는데 콘솔에 아무 것도 찍히지 않는 상황을 경험했다.

로그를 보니 다음과 같은 SQL이 실행되고 있었다.


drop table if exists Product;
create table Product (...);

원인은 설정값이 hibernate.hbm2ddl.auto = create였기 때문이었다.

create : 기존 테이블을 무조건 drop 후 다시 생성 → 사전에 넣어둔 데이터가 모두 사라짐
update : 스키마를 변경할 필요가 있을 때만 alter, 데이터는 유지

그래서 실습용 DB에서 미리 데이터를 넣어두고 JPA로 조회하고 싶다면, 반드시 update로 설정해 두어야 한다는 점을 알게 되었다.

❻ 이번 이틀 실습에서 얻은 핵심 정리

연관관계 & Fetch 전략
- OneToMany, ManyToMany 모두 기본 fetch는 LAZY
- EAGER는 편해 보이지만 join 폭탄 → 실무에서는 지양
- 컬렉션 연관관계는 dirty checking 시 delete → insert 패턴이 자주 발생
연관관계의 주인(Owning Side)
- ManyToMany에서 조인 테이블에 무엇이 저장될지는 주인 엔티티에 달려 있다
- Non-owner 쪽에서 setTeams()를 해도 DB에는 반영되지 않는다
- CascadeType.PERSIST는 엔티티 저장을 전파할 뿐, 주인이 아닌 쪽의 연관관계를 대신 저장해주지 않는다
toString(), LAZY, N+1 문제
- 양방향 연관관계에서 서로를 toString()에 넣으면 StackOverflowError 발생
- LAZY는 “필요할 때만 DB 가기”라서 좋지만, 부주의하면 N+1 문제를 낳는다
- 엔티티 설계 시 toString(), JSON 직렬화, fetch 전략을 함께 고민해야 한다
DDL 자동 생성 옵션
- create는 연습용/초기 개발 단계에서만 사용 (데이터 날아감)
- update를 이용하면 기존 데이터를 유지하면서 구조만 맞춰갈 수 있다

이번 이틀 동안의 실습은 단순히 코드를 따라 치는 수준을 넘어서, “JPA가 내부에서 어떤 전략으로 동작하는지”를 직접 SQL 로그로 체험하면서 이해하는 시간이었다.
특히 연관관계의 주인, LAZY/EAGER, dirty checking, cascade 같은 개념은 앞으로 Spring + JPA로 프로젝트를 진행할 때 성능과 안정성에 큰 영향을 주는 핵심 포인트들이라, 이번 정리를 통해 머릿속에 한 번 더 깊게 박아두는 계기가 되었다.