메뉴 단건 조회 API에서 존재하지 않는 매장의 ID와 유효한 메뉴 ID를 함께 요청했음에도 정상적인 메뉴 정보가 반환되는 문제가 발생했습니다.

예시

매장 목록

Redis에 저장된 데이터

요청 API

반환 결과

존재하지 않는 매장 ID인 333과 Redis에 캐싱된 메뉴 ID인 3을 함께 요청했음에도, 메뉴3이 정상적으로 조회되는 모습입니다.

원인 추론

캐싱된 메뉴에서만 문제가 발생하는것으로 보아 캐시 키 구조가 매장 ID에 관한 정보는 모르는 상황에서 메뉴 3에 대한 조회 요청이 들어오니, 캐시에서 바로 반환했을것이라 생각했습니다.

따라서 캐시 키를 만들 때 매장 ID에 관한 정보를 포함시켜서, 조회 요청 시 매장 ID와 메뉴 ID가 모두 일치할때만 캐시 데이터를 반환하도록 변경하면 될것이라 판단했습니다.

문제 해결

기존의 캐시 키 구조입니다.

위 구조를 아래와 같이 변경하였습니다.

테스트

유효한 매장 ID인 10과 메뉴 ID 17을 바탕으로 캐시 키를 만들겠습니다.

매장 10의 메뉴 17 키가 생성되었습니다.

다시금 유효하지 않은 매장 ID인 1000과 유효한 메뉴 ID인 17로 조회 요청을 보내겠습니다.

기대하던 결과가 반환되었습니다.

Redis를 사용할 때 키 전략을 더욱 신중하게 고민해야한다는것을 깨달았습니다.

Batch size INSERT 적용법에 대해 알아보겠습니다.

Batch Size란?

Batch size는 JPA가 다수의 INSERT, UPDATE, DELETE 작업을 처리할 때 SQL 실행을 모아서 일괄 실행(batch execution) 하는 단위를 뜻합니다.

예를 들어 도서 관리 시스템에서 도서별 평점 평균을 기반으로 순위를 집계하여 통계(Statistics)테이블에 저장하는 로직이 있다면, 통계 테이블에 저장하는 과정에서 엔티티별로 Insert 쿼리가 실행됩니다.

즉 100개 도서의 평점 평균을 집계하여 통계 테이블에 저장하게 되면, 100개의 Insert 쿼리가 실행됩니다.

이 때 Batch size를 50으로 설정해주면, Insert쿼리를 50개씩 묶어서 2번 실행하여 성능을 최적화합니다.

사용 시 주의사항

우선 Batch size는 엔티티(Entity)의 PK 생성전략이 IDENTITY일 경우 사용할 수 없습니다.

그 이유는 아래 블로그를 참조하여 설명하겠습니다.

해당 블로그 2번 목차 참조

IDNETITY전략은, DB에 데이터가 저장될 때 ID값을 AUTO INCREMENT하여 값을 자동으로 1씩 증가시켜 저장해줍니다.

그러나 Batch Size INSERT는 쿼리를 묶어서 처리하기 때문에 값이 저장될 때 ID값을 할당하는 IDENTITY전략과는 맞지 않습니다. 예를들어 10개의 쿼리를 묶어서 처리하려면, 묶어둔 10개의 데이터에 각각 PK를 지정해주어야하는데, IDENTITY전략의 경우 데이터가 저장될 때 PK값을 할당하므로 동작하지 않습니다.

@GeneratedValue의 generator값은 @SequenceGenerator의 name과 일치해야합니다.

• seuqenceName : DB 내의 실제 시퀀스 이름을 뜻합니다.
• allocationSize : 한 번에 가져올 ID의 수를 설정합니다. 기본값은 50이나, 예시를위해 임시로 100으로 설정하였습니다.

Batch Size 사용 방법

우선 하이버네이트 배치 설정을 해주어야 합니다.

application.yml 파일에 jpa.properties.hibernate.jdbc.batch_size 설정을 적용합니다.

반드시 properties.hibernate에 적용해야 합니다.

saveAll메서드로 한 번에 저장하기 위해 리스트를 만들고, 리스트에 값을 담아준 뒤 saveAll메서드를 실행합니다.

콘솔에 출력된 로그를 보겠습니다.

여전히 쿼리가 개별적으로 나가는것으로 확인됩니다.

관련 정보를 찾던 중 참고 블로그

MySQL JDBC의 경우 JDBC URL에 rewriteBatchedStatements=true 옵션을 추가해주면 된다. 는 내용을 보아 .env파일에 추가 해주었습니다.

다시 실행해보겠습니다.

여전히 개별 처리되는것을 볼 수 있습니다.

다시 블로그 내용을 보니

MySQL의 경우 실제로 생성된 쿼리는 logger=com.mysql.jdbc.log.Slf4JLogger&profileSQL=true 옵션으로 로그를 통해 확인할 수 있다.는 내용을 확인해 .env 파일의 DB_URL에 &profileSQL=true&logger=Slf4JLogger를 추가해준 후 다시 실행시켰습니다.

여전히 콘솔에서는 개별 처리된 것으로 보이지만 아래 새로 찍힌 로그를 자세히 살펴보겠습니다.

: [QUERY] /* insert for com.example.bookify.domain.statistics.domain.model.Statistics */insert into statistics (book_id,created_at,rating_avg,review_count,review_rank,updated_at,statistics_id) values (1,'2025-07-13 20:11:15.800214',5.0,3,1,'2025-07-13 20:11:15.800214',402),(2,'2025-07-13 20:11:15.809448',5.0,3,2,'2025-07-13 20:11:15.809448',403),(7,'2025-07-13 20:11:15.809448',5.0,2,3,'2025-07-13 20:11:15.809448',404),(8,'2025-07-13 20:11:15.810449',5.0,2,4,'2025-07-13 20:11:15.810449',405),(3,'2025-07-13 20:11:15.810449',4.0,3,5,'2025-07-13 20:11:15.810449',406),(9,'2025-07-13 20:11:15.810449',4.0,2,6,'2025-07-13 20:11:15.810449',407),(10,'2025-07-13 20:11:15.810775',3.0,2,7,'2025-07-13 20:11:15.810775',408),(4,'2025-07-13 20:11:15.810775',2.5,6,8,'2025-07-13 20:11:15.810775',409),(6,'2025-07-13 20:11:15.810775',2.3333,3,9,'2025-07-13 20:11:15.810775',410),(5,'2025-07-13 20:11:15.811279',1.0,3,10,'2025-07-13 20:11:15.811279',411) [Created on: Sun Jul 13 20:11:15 KST 2025, duration: 0, connection-id: 760, statement-id: 0, resultset-id: 0,    at com.zaxxer.hikari.pool.ProxyStatement.executeBatch(ProxyStatement.java:128)]

위 내용을 요약하면 다음과 같습니다.

: [QUERY] */insert into statistics (각 컬럼) values (1),(2),(7),(8,),(3,),(9,),(10,),(4,),(6,),(5,) [Created on: Sun Jul 13 20:11:15 KST 2025, duration: 0, connection-id: 760, statement-id: 0, resultset-id: 0,    at com.zaxxer.hikari.pool.ProxyStatement.executeBatch(ProxyStatement.java:128)]

즉 배치 처리가 성공적으로 처리되었지만 하이버네이트는 배치처리 여부와 관계없이 무조건 콘솔에 쿼리를 엔티티마다 한건 씩 처리한다는 사실을 알 수 있습니다.

사용법 정리

• PK 생성 전략이 IDENTITY가 아닐 것

• application.yml 파일에 jpa.properties.hibernate.jdbc.batch_size 설정을 적용할 것

• DB 저장 시 saveAll메서드를 사용할 것

• JDBC URL에 rewriteBatchedStatements=true 옵션을 추가해줄 것

위 4가지 조건을 만족할 경우 Batch Size 적용이 완료됩니다.

처음 생각했던 구조

• 도서 총 리뷰 수를 집계하는 쿼리를 작성하여 통계 엔티티로 반환
• 도서 평점 평균을 집계하는 쿼리를 작성하여 통계 엔티티로 반환
• 평점 평균 포매팅

  변경 이유

집계 결과를 엔티티로 반환하여 그대로 사용하려했는데, 집계 쿼리의 경우 계산된 값을 엔티티에 직접 매핑할 수 없었습니다.

1. 엔티티의 컬럼에 값을 넣어볼까? 생각하니 반환 값이 딱 떨어지는 하나의 값이 아닌, 각 도서별 집계 결과여서 하나의 컬럼에 값을 넣는것도 불가능하다고 판단했습니다.

2. 그래서 List에 엔티티를 담아서 따로 반환하면 되지 않을까? 싶어서 시도 해봤지만, 집계 결과와 엔티티가 매핑되지 않아 다른 방법을 모색했습니다.

마땅한 방법이 떠오르지 않아서 구글에 '집계 쿼리 결과 매핑'으로 키워드라도 얻고자 추상적으로 검색했는데, 구글 AI가 해결 방법을 알려주었습니다.

사용 방법과 예시도 작성되어 있었지만, 처음 접하다보니 관련 내용을 좀 더 찾아보았고 한 블로그를 찾았습니다.

참고 블로그 링크

제가 사용하고자 하는것이 JPA이므로 해당 블로그 목차 2번을 살펴보았고

다른 블로그도 찾아보았습니다.

추가 참고 블로그 링크

SELECT 구문에 new DTO경로 (조회 컬럼) 이와 같은 방식으로 사용한다는것을 알았습니다.

이 과정에서 두 개 였던 집계 쿼리를 하나로 합치게 되었는데, 그 이유는 두 개의 집계 쿼리를 매핑할 DTO를 각각 따로 만들게 될 경우 두 개의 리스트에서 도서 관련 정보를 처리하는 과정이 중복된다고 느꼈고 이를 어떻게 처리하면 좋을지 고민하던 중 쿼리를 하나로 합치게 되었습니다.

또한 기존 구조에서는 통계 테이블에서 도서 정보에 접근하고, 해당 도서 정보를 바탕으로 리뷰 정보에 접근하려 했으나, 도서 -> 리뷰 연관관계가 존재하지 않고, 리뷰 -> 도서 연관관계만 존재한다는 사실을 인지했습니다.

하여 리뷰 테이블을 기준으로 도서 정보를 조회하도록 쿼리를 변경하였습니다.

최종 쿼리

    @Query("SELECT new com.example.bookify.domain.statistics.service.dto.AvgReviewGradeDto(b, AVG (r.grades), COUNT (r)) " +
            "FROM Review r " +
            "JOIN r.book b " +
            "WHERE r.updatedAt BETWEEN :startDate AND :endDate " +
            "GROUP BY r.book " +
            "ORDER BY AVG (r.grades) DESC, COUNT (r) DESC")
    List<AvgReviewGradeDto> avgByReviewByGrades(@Param("startDate") LocalDateTime startDate,
                                                @Param("endDate") LocalDateTime endDate
    );

추가적으로 평점 평균 포매팅은 아직까지 평점 평균을 반환하지 않으므로 보류하였습니다.

순위 중첩 문제

        Long reviewRank = 1L;

        for (AvgReviewGradeDto gradeRank : avgGradesReview) {
            Statistics ratingRanking = new Statistics(
                    reviewRank++,
                    gradeRank.getAvgGrade(),
                    gradeRank.getCountReview(),
                    gradeRank.getBook()
            );
            statisticsRepository.save(ratingRanking);
        }

위 코드가 스케줄러에 의해 5분 주기로 실행되어 이미 집계 된 정보를 중복하여 집계하는 문제가 발생했습니다.

따라서 해당 월의 통계를 지우는 로직을 위 코드 위에 작성하면, 해당 월의 통계가 삭제되고 최신 정보를 반영한 채 다시 집계되어 저장되는 효과를 기대했습니다.

    @Query("DELETE FROM Statistics s WHERE s.createdAt BETWEEN :startDate AND :endDate")
    void deleteStatistics(@Param("startDate") LocalDateTime startDate,
                          @Param("endDate") LocalDateTime endDate
    );

하여 통계 삭제 쿼리를 작성한 후 실행하였는데 오류가 발생하며 프로그램이 종료되었습니다.

    @Modifying
    @Query("DELETE FROM Statistics s WHERE s.createdAt BETWEEN :startDate AND :endDate")
    void deleteStatistics(@Param("startDate") LocalDateTime startDate,
                          @Param("endDate") LocalDateTime endDate
    );

위와 같이 수정하니 프로그램이 의도한대로 작동하였습니다.

이유 = @Query는 기본적으로 SELECT 구문일것이라 가정합니다. 따라서 조회 쿼리가 아니라 DB 상태를 변경하는 쿼리라는것을 명시적으로 지정해줘야 합니다.

• Spring Framework에서 제공하는 기능으로, 정해진 시간에 작업을 자동으로 실행할 수 있게 도와주는 기능입니다.

Scheduler 사용법

@EnableScheduling

어플리케이션 클래스에 @EnableScheduling을 사용합니다.

@EnableScheduling   //클래스 단위 선언
public class BookifyApplication {

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

}

@Scheduled

• Spring Bean으로 등록된 클래스의 메서드 단위에서 선언하여 사용합니다.

@Service     // @Service 어노테이션으로인해 컴포넌트 스캔되어 스프링 빈으로 자동 등록
public class StatisticsService {

    @Scheduled     // 메서드 단위에서 사용
    public void bookRatingStatistics(){
    }
}

@Scheduled 규칙

메서드 타입은 반드시 void입니다.

• @Scheduled 어노테이션은 특정 주기에 따라 메서드를 실행하도록 예약하는 데 사용됩니다. 이 어노테이션이 붙은 메서드는 스케줄러에 의해 주기적으로 호출되는데, 이때 반환 값은 무시됩니다. 따라서 굳이 반환 값을 사용할 필요가 없으므로, void로 설정합니다.

매개변수를 받을 수 없습니다.

• @Scheduled어노테이션이 void타입이므로, 매개변수를 가질 수 없습니다.

@Scheduled 속성

@Scheduled의 속성은 해당 어노테션 내부를 살펴보면 확인할 수 있습니다.

각 속성의 적용 및 사용 방법을 알아보겠습니다.

cron (크론표현식 : 실행 주기 설정)

크론 표현식에서 각 자리는 초, 분, 시, 일, 월, 요일을 나타냅니다.

    @Scheduled(cron = "* * * * * *") // "*초 *분 *시 *일 *월 *요일" 즉 매 초마다 실행
    public void bookRatingStatistics() {
    }
}

    @Scheduled(cron = "30 * * * * *") // "*초 *분 *시 *일 *월 *요일" 매분30초마다
    public void bookRatingStatistics() {
    }
}

    @Scheduled(cron = "30 5 * * * *") // "*초 *분 *시 *일 *월 *요일" 매시간5분30초마다
    public void bookRatingStatistics() {
    }
}

    @Scheduled(cron = "30 5 15 * * *") // "*초 *분 *시 *일 *월 *요일" 매일15시5분30초마다
    public void bookRatingStatistics() {
    }
}

    @Scheduled(cron = "30 5 15 5 * *") // "*초 *분 *시 *일 *월 *요일" 매월5일15시5분30초마다
    public void bookRatingStatistics() {
    }
}

요일은 0=일, 1=월, 2=화, 3=수, 4=목, 5=금, 6=토 입니다.

표현식은 다음과 같습니다.

1. * (모든 값)

   @Scheduled(cron = "0 * * * * *") // 매 분 0초

2. ? (충돌 회피)

   @Scheduled(cron = "0 0 12 ? * WED") // 매주 수요일 12시에 실행

3. - (범위)

   @Scheduled(cron = "0 0 9-17 * * *") // 매일 9시~17시 매시 정각

4. , (다중 값)

   @Scheduled(cron = "0 0 9,15 * * *") // 매일 9시, 15시 정각에 실행

5. / (증분)

   @Scheduled(cron = "0 */10 * * * *") // 매 10분마다 실행 (0분부터 시작)

6. L (마지막)

   @Scheduled(cron = "0 0 0 L * *") // 매월 마지막 날 자정에 실행

7. W (가장 가까운 평일)

   @Scheduled(cron = "0 0 9 10W * *") // 매월 10일 기준 가장 가까운 평일 9시에 실행

8. # (N번째 요일)

   @Scheduled(cron = "0 0 9 ? * 4#2") // 매월 둘째 주 목요일 오전 9시에 실행

zone (cron 표현식 타임존 설정)

크론 표현식을 사용할 때의 타임존을 설정합니다.

    @Scheduled(cron = "* * * * * *", zone = "Asia/Seoul")
    public void bookRatingStatistics() {
    }
}

위와 같이 설정할 경우 아시아/서울 기준의 타임존이 적용됩니다.

fixedRate (작업 시작 시점부터 정의된 시간이 지나면 다음 작업 실행)

    @Scheduled(fixedRate = 2000)
    public void bookRatingStatistics() {
    }

milliseconds 단위입니다.

이전 작업 시작 시점으로부터 2초가 지날 경우 다음 작업을 실행합니다.

fixedRateString (fixedRate와 동일하나 문자열로 표기)

    @Scheduled(fixedRate = "2000")
    public void bookRatingStatistics() {
    }

fixedRate와 마찬가지로 이전 작업 시작 시점으로부터 2초 후에 다음 작업을 실행합니다.

fixedDelay (이전 작업 종료 시점부터 정의된 시간이 지나면 다음 작업 실행)

    @Scheduled(fixedDelay = 2000)
    public void bookRatingStatistics() {
    }

milliseconds 단위입니다.

이전 작업 종료 시점으로부터 2초가 지날 경우 다음 작업을 실행합니다.

fixedDelayString (fixedDelay와 동일하나 문자열로 표기)

    @Scheduled(fixedDelay = "2000")
    public void bookRatingStatistics() {
    }

fixedDelay와 마찬가지로 이전 작업 종료 시점으로부터 2초가 지날 경우 다음 작업을 실행합니다.

initialDelay (초기 지연 시간 설정)

    @Scheduled(fixedRate = 2000, initialDelay = 10000)
    public void bookRatingStatistics() {
    }

milliseconds 단위입니다.

initialDelay설정 시 10초의 대기시간이 지난 후 작업 종료 2초마다 다음 작업을 실행합니다.

initialDelayString (initialDelay와 동일하나 문자열로 표기)

    @Scheduled(fixedRate = 2000, initialDelay = "10000")
    public void bookRatingStatistics() {
    }

initialDelay와 마찬가지로 10초의 대기시간이 지난 후 작업 종료 2초마다 다음 작업을 실행합니다.

5분 주기 로그 출력 테스트

    @Scheduled(fixedDelay = 300000)
    public void bookRatingStatistics() {
        log.info("테스트중입니다.");
    }

CascadeType을 ALL로 할지 PERSIST로 할지 고민하던 중 일정 삭제 시 담당자도 삭제되는것이 옳다고 생각해 ALL을 적용하여 해결했었습니다. 그러나 추후 CascadeType을 여러가지를 적용할 수 있다는 사실을 알게되었고, PERSIST와 REMOVE를 함께 적용하도록 변경하였습니다.

Lv2 - 8 QueryDSL

QueryDSL을 기존에 사용하던 Repository에서 사용하고 싶어서 여러 방법으로 시도 해보았는데 기존 Repository가 인터페이스이기 때문에 JPAQueryFactory를 사용할 수 없었습니다.

왜 그런가 하니 인터페이스는 메서드 선언만 존재하기 때문에 의존성 주입을 할 수 없기 때문이라는 사실을 알았습니다.

하여 결국 CustomRepository와 그 구현체(CustomRepositoryImpl)을 생성하여, 문제를 해결했습니다.

Spring JPA에서 조건에 따라 검색 조건이 달라지는 쿼리를 작성할 때 자주 사용하는 기법이 바로 Dynamic Filter, 즉 동적 필터링입니다.

사용자의 입력 값이 존재하는 경우에만 조건을 추가하고, 그렇지 않으면 해당 조건을 무시하는 방식으로 단일 쿼리로 다양한 경우를 처리할 수 있게 합니다.

동적 필터링이 필요한 이유

• 검색 조건이 많고 그중 일부만 선택적으로 사용될 경우, 모든 조합에 대해 별도의 쿼리를 만들면 코드가 복잡해짐
• 조건의 유무에 따라 동적으로 필터링할 수 있는 유연한 쿼리 구조가 필요
• QueryDSL을 쓰지 않고도 복잡한 조건 분기를 깔끔하게 처리 가능

코드 예시 (Spring JPA + JPQL)

    @Query("SELECT t" +
            " FROM Todo t " +
            "LEFT JOIN FETCH t.user u " +
            "WHERE (:weather IS NULL OR t.weather = :weather)" +
            "AND (:searchStartDate IS NULL OR t.modifiedAt >= :searchStartDate) " +
            "AND (:searchEndDate IS NULL OR t.modifiedAt <= :searchEndDate)" +
            "ORDER BY t.modifiedAt DESC")

    Page<Todo> findAllOrSearch(
            @Param("weather") String weather,
            @Param("searchStartDate") LocalDateTime searchStartDate,
            @Param("searchEndDate") LocalDateTime searchEndDate,
            Pageable pageable);

작동 원리

• :weather IS NULL OR t.weather = :weather
  → weather 파라미터가 null이면 조건 무시 (모든 날씨 허용)
  → 값이 있으면 해당 값과 일치하는 항목만 필터링

• :start IS NULL OR t.modifiedAt >= :start
  → 시작일이 null이면 조건 무시
  → 값이 있으면 해당 시점 이후의 데이터만 필터링

• :end IS NULL OR t.modifiedAt <= :end
  → 종료일이 null이면 조건 무시
  → 값이 있으면 해당 시점 이전의 데이터만 필터링

개념

언제 사용할까?

• 검색 필터 기능을 구현할 때 (예: 기간, 상태, 카테고리 등)
• 복잡한 조건 조합을 단일 메서드로 처리하고 싶을 때
• QueryDSL이 없는 프로젝트에서 유연한 조건 처리가 필요할 때

팁

• 쿼리 길이가 너무 길어지면 QueryBuilder로 분리하거나 QueryDSL 도입 고려
• @Query 방식은 빠르게 구현 가능하지만, 복잡한 조합에는 한계가 있음
• 조건이 많아질수록 Specification 또는 Criteria API 방식과 비교해보는 것이 좋음

마무리

동적 필터링(Dynamic Filter)은 null 조건을 이용해 JPQL에서 다양한 검색 조건을 유연하게 적용하는 기법입니다.
불필요한 쿼리 메서드의 중복을 줄이고, 검색 기능 구현에 매우 유용합니다.

• 자기 자신의 메서드를 호출하는 것입니다.

그게 왜 문제일까?

Spring AOP관점에서 살펴보겠습니다.

• AOP기능은 반드시 프록시 객체를 통해 메서드를 호출해야만 작동합니다.

이 때 Self-invocation이 발생할 경우, 프록시 객체가 아닌 진짜 자기 자신의 메서드를 호출하므로 AOP가 적용되지 않습니다.

예시

 @Service
public class UserService {

    @Transactional
    public void registerUser() {
        saveUser(); // ← Self-invocation 발생!
    }

    @Transactional
    public void saveUser() {
        userRepository.save(...);
    }
}

UserService클래스에 @Transactional을 사용한 두 메서드가 있습니다.

그러나 registerUser메서드 내부에서 saveUser메서드를 호출합니다.

즉 registerUser메서드가 프록시 객체를 거치지 않고 직접 saveUser메서드를 호출하였으므로, @Transactional어노테이션이 적용되지 않습니다.

따라서 saveUser메서드에서 예외가 발생하게 되더라도, 롤백이 되지 않습니다.

우리가 기대한것은 예외가 발생할 경우 유저가 등록되지 않고 롤백 되어야하는데, 유저 정보가 DB에 남고, 예외가 발생하게됩니다.

해결 방법

1.

  @Service
public class UserService {

    @Transactional
    public void registerUser() {
        saveUser(); // ← Self-invocation 발생!
    }

//  ↓ 어노테이션 제거
    public void saveUser() {
        userRepository.save(...);
    }
}

saveUser에서 @Transactional을 제거하면, 해당 메서드는 별도의 트랜잭션을 생성하지 않고, 이미 트랜잭션이 적용된 registerUser의 트랜잭션 범위 내에서 실행되므로 Self-invocation 문제가 발생하지 않습니다.

2.

@Service
public class UserService {
    private final UserInternalService internal;

    @Transactional
    public void registerUser() {
        internal.saveUser();  // 프록시를 통해 호출됨
    }
}

@Service
public class UserInternalService {

    @Transactional
    public void saveUser() {
        // 트랜잭션 적용됨
    }
}

위 코드와 같이 서비스를 분리할 경우

UserInternalService는 Spring에 의해 프록시로 감싸진 객체이며, UserService에서 이를 주입받아 호출하면 프록시를 통해 saveUser가 실행되므로, @Transactional이 정상적으로 적용됩니다.

트랜잭션(Transaction)은 데이터베이스에서 하나의 논리적 작업 단위를 의미합니다. 여러 SQL 명령을 하나의 단위로 묶어 모두 성공하거나 모두 실패해야만 데이터 정합성을 유지할 수 있습니다.

예시

• A → B 계좌 이체 작업
  • A의 잔액 차감
  • B의 잔액 증가
    → 하나라도 실패하면 전체 롤백되어야 함.

트랜잭션의 4가지 특성 (ACID)

예시

• Atomicity
  • 주문 처리 중 결제는 되었는데 재고 차감 실패 → 전체 롤백
• Consistency
  • 외래키, 제약조건, 형식 등이 트랜잭션 후에도 여전히 만족되어야 함
• Isolation
  • 두 사용자가 동시에 같은 좌석을 예매하려고 할 때 충돌 방지
• Durability
  • 결제 완료 후 서버가 다운되어도 결제 내역은 보존되어야 함

트랜잭션 제어 명령어

예시

BEGIN;
UPDATE accounts SET balance = balance - 10000 WHERE id = 1;
UPDATE accounts SET balance = balance + 10000 WHERE id = 2;
COMMIT;

• 중간에 오류 발생 시 ROLLBACK으로 두 작업 모두 취소 가능

Isolation Level (격리 수준)

트랜잭션 간 간섭을 얼마나 허용할 것인지 설정하는 기준입니다.

예시

• Dirty Read
  T1이 수정했지만 아직 COMMIT 안 한 데이터를 T2가 읽음 → 이후 ROLLBACK되면 데이터 모순
• Non-repeatable Read
  T1이 조회한 데이터를 T2가 수정 → T1이 다시 조회 시 값 달라짐
• Phantom Read
  T1이 조건으로 조회한 후, T2가 새 데이터를 INSERT → T1이 같은 조건으로 다시 조회하면 새로운 행이 생김
• Serializable
  여러 트랜잭션이 직렬적으로 실행됨 → 모든 위 현상 방지 가능

Spring에서의 트랜잭션 관리

Spring에서는 @Transactional 어노테이션으로 트랜잭션을 선언적(명시적 코드 없이)으로 설정할 수 있습니다.

@Transactional
public void transfer(Long fromId, Long toId, int amount) {
    accountRepository.withdraw(fromId, amount);
    accountRepository.deposit(toId, amount);
}

예시 설명

• 위 메서드 내에서 오류 발생 시 withdraw()도 자동으로 롤백
• 예외가 발생하지 않으면 COMMIT 처리됨

예외와 롤백 조건

• 기본적으로 RuntimeException 발생 시 자동으로 롤백됨
• CheckedException은 기본적으로 롤백되지 않음 → 명시적으로 설정 가능

@Transactional(rollbackFor = SQLException.class)
public void doSomething() throws SQLException {
    // 예외 발생 시 롤백됨
}

트랜잭션과 테스트

• 테스트 클래스나 메서드에 @Transactional을 붙이면 테스트 종료 시 자동으로 롤백되어 DB 상태가 유지됨

@SpringBootTest
@Transactional
public class UserServiceTest {
    // 테스트 DB 변경 후 자동 롤백됨
}

트랜잭션은 단순한 DB 조작이 아닌, 데이터 무결성과 동시성 문제를 방지하기 위한 핵심 개념입니다. 제대로 이해하고 설계에 반영하는 것이 안정적인 서비스 운영의 출발점입니다.

1. AOP란?

AOP(Aspect-Oriented Programming, 관점 지향 프로그래밍)은 공통된 기능(=횡단 관심사)을 분리하여 핵심 비즈니스 로직과 독립적으로 관리하기 위한 프로그래밍 패러다임입니다.

• 예: 로깅, 트랜잭션, 보안, 성능 측정 등

핵심 로직을 건드리지 않고도 공통 기능을 모듈화할 수 있습니다.

2. 핵심 개념 정리

3. 어드바이스 종류

4. 실전 예제 – 메서드 실행 시간 로깅

@Aspect
public class AopPractice {

    private static final Logger log = LoggerFactory.getLogger(AopPractice.class);

    // [1] 포인트컷: service 패키지 하위 전체 메서드
    @Pointcut("execution(* com.spring.basic.service..*(..))")
    public void serviceLayerPointCut() {}

    // [2] 포인트컷: @TrackTime 어노테이션이 붙은 메서드
    @Pointcut("@annotation(com.spring.basic.aop.TrackTime)")
    public void trackTimePointCut() {}

    // [3] 어드바이스 - 실행 전
    @Before("serviceLayerPointCut()")
    public void beforeMethod() {
        log.info("@Before");
    }

    // [4] 어드바이스 - 정상 실행 후
    @AfterReturning(pointcut = "serviceLayerPointCut()", returning = "result")
    public void afterReturningMethod(Object result) {
        log.info("@AfterReturning");
        log.info("::: result : {}", result.getClass());
    }

    // [5] 어드바이스 - 예외 발생 시
    @AfterThrowing(pointcut = "serviceLayerPointCut()", throwing = "exception")
    public void afterThrowingMethod(Throwable exception) {
        log.info("@AfterThrowing");
        log.info("::: exception: {}", exception.getClass());
    }

    // [6] 어드바이스 - 무조건 실행
    @After("serviceLayerPointCut()")
    public void AfterMethod() {
        log.info("@After");
    }

    // [7] 어드바이스 - Around 위 모든 경우에 사용 가능 ( ex)시간 측정 )
    @Around("trackTimePointCut()")
    public Object AroundMethod(ProceedingJoinPoint joinPoint) throws Throwable {
        long startTime = System.currentTimeMillis();
        try {
            Object proceed = joinPoint.proceed();
            log.info("@AfterReturning");
            return proceed;
        } catch (Throwable e) {
            log.info("@AfterThrowing");
            throw e;
        } finally {
            long endTime = System.currentTimeMillis();
            long executionTime = endTime - startTime;
            log.info("::: executionTime: {}ms", executionTime);
        }
    }
}

• 댓글 삭제 기능을 만든 뒤 Postman에서 테스트를 해보려는데, 반환값이 출력되지 않는 문제가 발생했습니다.
  • 해결과정 : HTTP Method가 204 NO CONTENT일 경우 Body를 반환할 수 없다는 사실을 알게되어, 200 OK로 변경했습니다. (API 명세서도 수정했습니다.)

문제2

git pull → git push 과정에서 pull받은 후 충돌을 해결한 뒤, 모든 내용을 commit하지 않고 머지시킬 경우 다른 사람의 작업 내용이 날아가는 문제를 겪었습니다.

• 해결과정 : git log → git reset --hard fbd18de 우선 커밋 로그를 확인한 후 리셋을 통해 원하는 시점으로 돌아간 후 해당 부분을 해결하여 다시 push했습니다.

  • (제 커밋이 가장 최근 시점이었기에 이 방법을 택했습니다. 하드리셋을 할 경우 다른 팀원의 커밋 로그가 날아갈 수 있습니다.)

Spring Validation은 Spring Framework에서 제공하는 입력값 검증 기능으로, 사용자의 입력값이 미리 정해진 조건에 부합하는지를 확인하는 데 사용됩니다.
이 기능은 Bean Validation 2.0(JSR-380) 스펙을 기반으로 작동하며, 대표적인 구현체는 Hibernate Validator입니다.

검증 기능의 목적

Spring Validation의 주요 목적은 다음과 같습니다:

• 서비스 로직 보호: 잘못된 데이터가 핵심 로직에 도달하는 것을 방지합니다.
• 사용자 응답 처리: 오류 발생 시 적절한 에러 메시지를 사용자에게 전달합니다.
• 객체 무결성 보장: 엔터티나 DTO가 비정상적인 상태로 시스템에 유입되지 않도록 합니다.

주요 구성 요소 및 개념

Spring Validation 동작 방식 (검증 흐름)

Spring Validation은 다음과 같은 순서로 동작합니다:

1. 검증 대상 객체에 어노테이션 추가

   • DTO 클래스에 @NotNull, @Size, @Email 등 제약 조건을 선언합니다.
   • 컨트롤러 메서드 파라미터에 @Valid 또는 @Validated를 선언합니다.

   public ResponseEntity<?> createUser(@Valid @RequestBody UserDto dto, BindingResult result) { ... }

2. Spring이 Validator를 통해 자동 검증 수행

   • LocalValidatorFactoryBean을 통해 Hibernate Validator가 동작하며, 선언된 제약 조건을 기준으로 DTO를 자동 검증합니다.

3. 검증 오류 발생 시 BindingResult에 에러 바인딩

   • BindingResult가 파라미터로 선언된 경우, 예외를 발생시키지 않고 오류 내용을 해당 객체에 저장합니다.
   • 선언되지 않았다면, MethodArgumentNotValidException 등의 예외가 발생합니다.

4. 오류 메시지를 기반으로 사용자 응답 처리

   • 오류 정보를 바탕으로 에러 응답을 생성하거나, 뷰로 다시 이동시킬 수 있습니다.
   • REST API인 경우 @RestControllerAdvice 등으로 글로벌 처리도 가능합니다.

자주 쓰는 제약 어노테이션

@Validated vs @Valid 차이

BindingResult란?

• BindingResult는 검증 후의 결과를 담는 객체입니다.
• @Valid 또는 @Validated와 함께 사용하면 검증 실패 시 예외가 발생하지 않고, 오류 정보를 확인할 수 있습니다.
• 반드시 검증 대상 파라미터 직후에 선언해야 정상 작동합니다.

public String submitForm(@Valid FormDto dto, BindingResult result) {
    if (result.hasErrors()) {
        return "formPage"; // 에러 있는 경우
    }
    return "redirect:/success";
}

글로벌 예외 처리와 연계 (@ControllerAdvice)

Spring Validation 실패 시 전역적으로 일관된 에러 응답을 만들고 싶다면 @RestControllerAdvice와 함께 사용할 수 있습니다.

발생하는 주요 예외

• MethodArgumentNotValidException → DTO 검증 실패
• ConstraintViolationException → 파라미터 수준 검증 실패 (@RequestParam, @PathVariable 등)

예외 처리 예시

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(MethodArgumentNotValidException.class)
    public ResponseEntity<?> handleValidation(MethodArgumentNotValidException ex) {
        Map<String, String> errors = new HashMap<>();
        for (FieldError error : ex.getBindingResult().getFieldErrors()) {
            errors.put(error.getField(), error.getDefaultMessage());
        }
        return ResponseEntity.badRequest().body(errors);
    }
}

Lv.2 과제 진행 사항에 fetch join을 사용하여 N+1 문제를 해결하고 있는 TodoRepository를 동일하게 동작하는 @EntityGraph기반의 구현으로 수정하는 부분이 있었습니다.

우선 @EntityGraph가 무엇인지 간단하게 알아보았습니다.

간단하게 말해 fetch join을 어노테이션으로 사용할 수 있도록 만들어 준 기능이라는 사실을 알았습니다.

여기서 의문이 생겼습니다.

그냥 쿼리문 안에 JOIN FETCH 쓰면 굳이 어노테이션 추가 안해도 되는 거 아닌가? 왜 @EntityGraph를 사용하지?

하여 둘의 차이점을 알아보았습니다.

@EntityGraph를 사용하는 이유 및 상황 내용 정리 블로그

    @Query("SELECT t FROM Todo t LEFT JOIN FETCH t.user u ORDER BY t.modifiedAt DESC")
    Page<Todo> findAllByOrderByModifiedAtDesc(Pageable pageable);

위 코드를

    @Query("SELECT t FROM Todo t ORDER BY t.modifiedAt DESC")
    @EntityGraph(attributePaths = {"user"})
    Page<Todo> findAllByOrderByModifiedAtDesc(Pageable pageable);

이와 같이 수정하여 해결했습니다.

2. AssertionFailedError

Lv.3-1의 테스트코드 수정 과정에서 AssertionFailedError에러가 발생했습니다.

검색을 통해 테스트를 수행할 때 기대한 값과 실제 값이 일치하지 않을 경우 발생하는 에러라는 것을 알았습니다.

@ExtendWith(SpringExtension.class)
class PasswordEncoderTest {

    @InjectMocks
    private PasswordEncoder passwordEncoder;

    @Test
    void matches_메서드가_정상적으로_동작한다() {
        // given
        String rawPassword = "testPassword";
        String encodedPassword = passwordEncoder.encode(rawPassword);

        // when
        boolean matches = passwordEncoder.matches(encodedPassword, rawPassword);

        // then
        assertTrue(matches);
    }
}

위 코드는 저장된 비밀번호와 입력한 비밀번호를 비교하는 테스트 로직입니다.

처음 테스트 코드를 살펴보았을 때 크게 문제가 될만한 부분을 찾지 못했습니다. 하여 테스트 로직을 처음부터 다시 짚어보았습니다.

given부분 (테스트 데이터 준비 부분)에서 rawPassword는 testPassword이고, encodedPassword는 passwordEncoder의 기능인 encoder로 rawPassword를 인코딩한 값을 담고있습니다.

when부분 (실제 테스틀 로직)에서 boolean타입의 변수 matches에 passwordEncoder의 기능인 matches를 이용하여 encodedPassword와 testPassword가 같다면 true, 다르면 false가 반환되도록 합니다.

then부분 (테스트 검증 로직)에서 assertTrue로 matches의 값이 true인지 확인합니다.

위 흐름에서 인코딩한 데이터의 값도 testPassword이고, 비교 대상 값도 testPassword인데, 테스트는 실패하는 상황이었습니다.

따라서 비밀번호 인코딩 과정에서 문제가 발생했을 수 있겠다는 생각으로, PasswordEncoder클래스를 확인했습니다.

(PasswordEncoder클래스입니다.)

@Component
public class PasswordEncoder {

    public String encode(String rawPassword) {
        return BCrypt.withDefaults().hashToString(BCrypt.MIN_COST, rawPassword.toCharArray());
    }

    public boolean matches(String rawPassword, String encodedPassword) {
        BCrypt.Result result = BCrypt.verifyer().verify(rawPassword.toCharArray(), encodedPassword);
        return result.verified;
    }
}

PasswordEncoder클래스를 확인해보니 사용중인 matches메서드의 매개변수는 (rawPassword, encodedPassword)의 구조인 반면, 테스트 코드는 (encodedPassword, rawPassword)로 사용중인 사실을 확인했습니다.

따라서 테스트 코드의 when부분을 다음과 같이 수정하였습니다.

        // when
        boolean matches = passwordEncoder.matches(rawPassword, encodedPassword);

이 후 테스트해보니 정상적으로 테스트가 완료되었습니다.

@EntityGraph란?

• JPA에서 연관된 엔티티를 즉시 로딩(Fetch Join) 하도록 선언하는 방법입니다. 내부적으로 SQL문의 JOIN FETCH와 유사한 SQL을 자동 생성해줍니다.

• JPQL 없이도 선언적으로 Fetch Join 사용이 가능합니다.

Fetch join 사용 방법

• 쿼리문 안에 JOIN FETCH를 작성하여 사용합니다.

@Query("SELECT p FROM Post p JOIN FETCH p.author")
List<Post> findAllWithAuthor();

즉 위의 코드는 Post를 전체 조회 할 때 author필드도 함께 조회한다는 뜻을 지닙니다.

@EntityGraph 사용 방법

• JPA Repository 인터페이스의 메서드에서 @EntityGraph(attributePaths = {연관필드명})으로 사용합니다.
• fetch join 하고 싶은 연관 필드들의 경로를 지정해야 합니다.

@EntityGraph(attributePaths = {"user"})
List<Post> findAll();

즉 위의 코드는 Post를 전체 조회 할 때 user필드도 함께 조회한다는 뜻을 지닙니다.

@EntityGraph를 왜 써야할까?

그렇다면 두 기능 모두 N + 1문제를 해결하기 위해 사용하는 기능인데, @EntityGraph는 왜 사용해야 할까요?

저는 처음 @EntityGraph을 알게 되었을 때, 굳이 사용해야하나? 그냥 쿼리문 안에 JOIN FETCH쓰면 되는 거 아닌가? 하는 생각이 들었습니다.

그래서 어떤 상황에서 @EntityGraph를 사용하는지, 둘의 차이점에 대해 알아보았습니다.

@EntityGraph와 Fetch join의 차이

작동 방식의 차이

둘의 차이점을 알아보니 어떤 상황에서 @EntityGraph를 사용하는지에 대한 판단이 비교적 쉬워졌습니다.

@EntityGraph를 사용해야 하는 대표적인 상황

프로그래머스 Lv.1 가운데 글자 가져오기 문제.

문제 설명

입출력 예시

작성 코드

class Solution {
    public String solution(String s) {
        String answer = "";
        int strLength = s.length();


            answer = strLength % 2 != 0 
                ? s.substring(strLength / 2, strLength / 2 +1)
                : s.substring(strLength / 2 -1, strLength / 2 +1);


        return answer;
    }
}

처음 문제를 접했을 때 들었던 생각은 문자열의 길이를 구하고, 홀수 짝수 여부를 판별해 가져올 글자의 범위를 정하면 되겠다는 생각이 들었습니다.

하여 문자열의 길이를 strLength 변수에 담아준 뒤, if()문을 사용해 홀수 짝수 여부를 판별하려 했습니다.

그러나 현재 문제에서 주어진 경우의 수가, 홀수와 짝수 두 가지밖에 없으므로, 삼항연산자를 사용해도 될 것 같다는 생각이 들었습니다.

리턴 함수인 answer를 strLength % 2 != 0 2로 나누었을 때 0이 아니라면(글자의 길이가 홀수라면),

? s.substring(strLength / 2, strLength / 2 +1)

s.substring(strLength / 2, 문자열 길이를 2로 나눈 범위부터 (입 출력 예시의 글자수는 5이므로 / 2 했을 때 2) 즉 index 2부터

strLength / 2 +1) (index 2 + 1) 즉 index 3 전까지의 글자를 반환해줘.

입 출력 예시의 'abcde'에서 index 2는 c이고, index 3는 d입니다. 따라서 글자의 길이가 홀수인 'abcde'의 경우 c부터 d전까지의 글자를 반환하므로, 가운데 글자인 c를 반환합니다.

: s.substring(strLength / 2 -1, strLength / 2 +1);

글자의 길이가 짝수라면,

s.substring(strLength / 2 -1 문자열의 길이를 반으로 나눈 값의 -1 (입 출력 예시의 글자수는 4이므로 / 2 -1을 했을 때 1) 즉 index 1부터

strLength / 2 +1); (같은 맥락으로 / 2 + 1을 했을 때 3) 즉 index 3 전까지의 글자를 반환해줘.

입 출력 예시의 'qwer'에서 index 1은 w이고, index 3은 r입니다. 따라서 글자의 길이가 짝수인 'qwer'의 경우 w부터 r전까지의 글자를 반환하므로, 가운데 두 글자인 we를 반환합니다.

예외란?

자바에서는 예외(Exception)를 클래스 형태로 정의해두었으며, 크게 체크 예외와 언체크 예외로 나뉜다.

• 체크 예외: Exception을 상속받은 예외 중 RuntimeException을 제외한 모든 예외이다.
• 언체크 예외: RuntimeException과 그 하위 예외이다.

예외 전가 (throws)

예외를 메서드 내부에서 직접 처리하지 않고 상위 계층으로 책임을 넘기고 싶을 때, 메서드 선언부에 throws 예외클래스명 을 명시한다.

public void connect() throws IOException {
    // 예외 발생 가능 코드
}

예외 선택 기준

• 서버에서 즉시 처리가 가능한가?
  → 가능하면 체크 예외, 불가능하면 언체크 예외

• 예외가 복구 가능성이 있는가?
  → 재시도가 가능하거나, 서버에서 처리 경로가 존재하면 체크 예외 사용

• 예외가 발생했을 때 사용자 잘못인가?
  → 클라이언트 실수로 발생하는 예외는 언체크 예외로 처리

@ControllerAdvice란?

Spring에서는 @ControllerAdvice를 통해
애플리케이션 전역의 예외를 하나의 클래스에서 처리할 수 있다.

이를 통해 컨트롤러 단에서 발생하는 예외를 일괄적으로 핸들링할 수 있으며,
@ExceptionHandler와 함께 사용하여 다양한 예외에 따른 응답을 설정할 수 있다.

GlobalExceptionHandler 예시

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(MethodArgumentTypeMismatchException.class)
    public ResponseEntity<String> handleTypeMismatch(MethodArgumentTypeMismatchException ex) {
        return ResponseEntity.status(HttpStatus.BAD_REQUEST)
                             .body("파라미터 타입이 올바르지 않습니다.");
    }

    @ExceptionHandler(HttpMessageNotReadableException.class)
    public ResponseEntity<String> handleUnreadable(HttpMessageNotReadableException ex) {
        return ResponseEntity.status(HttpStatus.BAD_REQUEST)
                             .body("요청 본문을 읽을 수 없습니다.");
    }

    // 기타 예외 처리 추가 가능
}

마무리 정리

• 자바 예외는 복구 가능성, 처리 주체, 즉시 대응 가능성에 따라
  체크 예외와 언체크 예외를 구분해서 사용해야 한다.

• 서버에서 복구가 가능하거나 예외를 컨트롤할 수 있다면 체크 예외, 복구 불가능하거나 사용자의 잘못으로 발생한 경우는 언체크 예외가 적절하다.

• 스프링에서는 @ControllerAdvice를 활용해 전역 예외를 효율적으로 관리할 수 있으며,
  코드 중복을 줄이고 일관된 에러 응답 포맷을 제공할 수 있다.

• 실무에서는 도메인마다 커스텀 예외 클래스를 만들어
  에러 코드, 상태 코드, 에러 메시지 등을 체계적으로 관리하는 것이 중요하다.

• @PathVariable의 값이 URL 경로에서 누락된 경우 발생한다.

@GetMapping("/posts/{id}")
public String getPost(@PathVariable Long id) { ... }

위 API 사용할 경우 URL경로를 /posts/{id}로 보내야 하는데, 이 때 /posts로 보내고 id값이 누락되는 경우 MissingPathVariableException이 발생한다.

URL 경로에 변수가 누락됐을 때 발생한다.

MissingServletRequestParameterException

• @RequestParam이 필수인데 요청에서 누락된 경우 발생한다.

@GetMapping("/search")
public String search(@RequestParam String keyword) { ... }

위 코드의 경우 @RequestParam을 사용했으므로 API호출 시 /search?keyword="??"와 같은 형식으로 보내야 한다. 이 때 keyword값이 누락된 경우 MissingServletRequestParameterException이 발생한다.

@RequestParam의 파라미터가 누락된 경우 발생한다.

MethodArgumentTypeMismatchException

• 파라미터가 잘못된 타입으로 들어와 변환 실패한 경우에 발생한다.

@GetMapping("/posts/{id}")
public String getPost(@PathVariable Long id) { ... }

위와 같은 코드에서 /posts/{id}의 id값은 Long타입이다. 그러나 API 호출 시 /posts/abc이와 같이 호출한 경우 MethodArgumentTypeMismatchException이 발생한다.

요청 URL의 타입이 일치하지 않을 때 발생한다.

HttpMessageNotReadableException

• **@RequestBody로 받은 JSON 본문이 비었거나, 파싱이 불가능할 때 발생한다.

@PostMapping("/posts")
public String create(@RequestBody PostDto dto) { ... }

위 코드는 @RequestBody를 사용하였으므로 요청 시 Body를 함께 보내주어야 한다. 이 때 요청 시 Body가 비어있거나 { title: "hello", content: }처럼 요청값이 잘못된 경우 HttpMessageNotReadableException가 발생한다.

잘못된 JSON 형식으로 요청 시 발생한다.

HttpMediaTypeNotAcceptableException

• 클라이언트의 헤더에 맞는 타입을 서버가 제공하지 못할 때 발생한다.

예를들어 컨트롤러에선 json만 반환이 가능한데, 클라이언트에서 xml형식으로 요청을 하게 될 경우 xml을 제공할 수 없으므로 HttpMediaTypeNotAcceptableException 예외가 발생한다.

클라이언트가 요청한 형식을 서버가 지원하지 못할 때 발생한다.

NoResourceFoundException

• **요청한 경로에 해당하는 Controller가 아예 없을 때 발생한다.
• Spring 6부터 도입된 예외로, 이전에는 404에러만 반환했다.

프로그램의 컨트롤러 중 해당 URL을 처리할 수 있는 핸들러가 없을 때 NoResourceFoundException예외가 발생한다.

존재하지 않는 URL을 요청했을 때 발생한다.

HttpRequestMethodNotSupportedException

• **해당 URL은 특정 HTTP 메서드만 허용하는데, 다른 메섣드로 호출한 경우 발생한다.

@GetMapping("/posts")
public String getPosts() { ... }

위 코드는 @GetMapping을 사용했기 때문에 호출 시 GET 메서드로 호출해야 한다. 이 때 클라이언트에서 GET이 아닌 다른 메서드로 API를 호출할 경우 HttpRequestMethodNotSupportedException예외가 발생한다.

호출 HTTP Method가 일치하지 않을 때 발생한다.

HttpMediaTypeNotSupportedException

• **클라이언트가 보낸 컨텍스트 타입을 서버가 처리할 수 없을 때 발생한다.

@PostMapping("/posts")
public String create(@RequestBody PostDto dto) { ... }

위 코드의 경우 @RequestBody를 사용했으므로 JSON형태로 API를 호출해야 한다. 이 때 컨텍스트 타입이 JSON이 아닌 다른 타입일 경우 HttpMediaTypeNotSupportedException예외가 발생한다.

HTTP 본문의 형식이 서버가 처리할 수 있는 타입이 아닐 때 발생한다.

GlobalExceptionHandler

• 위와 같은 예외들을 각각의 컨트롤러에서 처리하게 될 경우 만일 컨트롤러의 수가 수십가지 이상이라면, 수십가지 이상의 중복된 작업을 해야한다. 따라서 해당 예외들을 한 번에 처리할 수 있는 GlobalExceptionHandler를 생성하여 이곳에서 예외를 관리 및 처리한다.

• @RestControllerAdvice 또는 @ControllerAdvice를 이용한다.

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(MethodArgumentTypeMismatchException.class)
    public ResponseEntity<ErrorResponse> handleTypeMismatch(MethodArgumentTypeMismatchException ex) {
        return buildError("잘못된 타입의 파라미터입니다.", HttpStatus.BAD_REQUEST);
    }

    @ExceptionHandler(HttpMessageNotReadableException.class)
    public ResponseEntity<ErrorResponse> handleUnreadable(HttpMessageNotReadableException ex) {
        return buildError("요청 본문을 읽을 수 없습니다.", HttpStatus.BAD_REQUEST);
    }

    private ResponseEntity<ErrorResponse> buildError(String message, HttpStatus status) {
        return new ResponseEntity<>(new ErrorResponse(status.value(), message), status);
    }

    public static class ErrorResponse {
        private int status;
        private String message;

        public ErrorResponse(int status, String message) {
            this.status = status;
            this.message = message;
        }
        // getter/setter 생략 가능
    }
}

@ExceptionHandler로 처리할 예외 클래스를 지정해준 뒤, 매개변수로 입력받는다.

응답 형식을 통일하고싶다면, 다음과 같은 DTO클래스를 생성한다.

public class ErrorResponse {
    private int status;
    private String message;

    public ErrorResponse(int status, String message) {
        this.status = status;
        this.message = message;
    }
}

이 후 예외 발생 지점에 해당 기능을 예외로 던지면 된다.

스프링 프로젝트를 개발하다 보면 도메인별로 명확하고 통일된 방식의 예외 처리 구조가 필요하다. 이를 위해 CustomException을 활용한 글로벌 예외 처리 구조를 구축할 수 있다. 아래는 지금까지의 구현 내용을 기반으로 커스텀 예외 처리 방식에 대해 정리한 글이다.

왜 커스텀 예외가 필요한가?

도메인에 특화된 명확한 에러 메시지 제공

• 단순한 500 오류나 NullPointerException 같은 시스템 에러 대신, "제목은 필수입니다", "이미지를 삽입해야 합니다" 같은 사용자 친화적인 메시지를 반환할 수 있다.

일관된 API 응답 형식 유지

• 다양한 컨트롤러에서 발생하는 예외를 한 곳에서 처리하여 클라이언트는 예외 응답을 예측 가능하게 처리할 수 있다.

비즈니스 로직과 예외 로직 분리

• 핵심 로직은 비즈니스에 집중하고, 예외 처리는 따로 관리할 수 있어 가독성과 유지보수성이 높아진다.

에러 코드 중심의 흐름 제어

• 개발자는 ErrorCode를 중심으로 흐름을 설계하고 디버깅 및 로깅이 용이하다.

입력 유효성 검사와 명확한 예외 구분

• 유효성 검증 실패, 권한 문제, 데이터 누락 등 다양한 상황을 명확하게 분리하여 처리 가능하다.

스택 트레이스를 줄이고 명확한 원인 파악

• 비즈니스 요구사항에 따라 의도적으로 발생시키는 예외는 CustomException으로 명확하게 추적 가능하다.

응답 상태 코드를 정밀하게 제어 가능

• 상태 코드와 메시지를 조합해 REST API의 신뢰도를 높일 수 있다.

기본 구조 및 클래스 역할 설명

ErrorCode Enum

• 예외 상황을 명확하게 분리하고 코드화하기 위한 열거형. 각각의 예외에 대해 상태 코드와 메시지를 설정한다.

public enum ErrorCode {
    // 게시글 관련
    BOARD_NOT_FOUND(HttpStatus.NOT_FOUND, "해당 게시글을 찾을 수 없습니다."),
    POST_NOT_OWNED(HttpStatus.BAD_REQUEST, "본인의 게시글만 수정 및 삭제할 수 있습니다."),
    POST_NOT_CHANGE(HttpStatus.BAD_REQUEST, "변경할 내용을 입력해야 합니다."),
    POST_NOT_TITLE(HttpStatus.BAD_REQUEST,"제목을 입력해야 합니다."),
    POST_NOT_CONTENTS(HttpStatus.BAD_REQUEST,"내용을 입력해야 합니다."),
    POST_NOT_IMAGE(HttpStatus.BAD_REQUEST,"이미지를 삽입해야 합니다."),
    TITLE_LENGTH_OVER(HttpStatus.BAD_REQUEST, "제목은 255자까지 입력 가능합니다.")
``
    // 기타 예외
    INVALID_PASSWORD(HttpStatus.UNAUTHORIZED, "비밀번호가 일치하지 않습니다.");

    private final HttpStatus status;
    private final String message;

    // 생성자 및 Getter
}

CustomException

• 비즈니스 로직에서 예외 상황이 발생할 경우 이 클래스를 사용해 throw 한다. ErrorCode를 기반으로 상태 코드 및 메시지를 커스터마이징할 수 있다.

public class CustomException extends RuntimeException {
    private final ErrorCode errorCode;

    public CustomException(ErrorCode errorCode) {
        super(errorCode.getMessage());
        this.errorCode = errorCode;
    }

    public HttpStatus getStatus() {
        return errorCode.getStatus();
    }
}

GlobalExceptionHandler

• 모든 Controller에서 발생하는 예외를 한 곳에서 처리. CustomException 외에도 Spring의 유효성 검사 실패 등을 처리할 수 있도록 구성한다.

  @RestControllerAdvice
  public class GlobalExceptionHandler {
  
    @ExceptionHandler(CustomException.class)
    public ResponseEntity<ExceptionDto> handleCustomException(CustomException e) {
        ExceptionDto dto = new ExceptionDto(e.getStatus(), e.getMessage());
        return ResponseEntity.status(e.getStatus()).body(dto);
    }
  
    @ExceptionHandler(MethodArgumentNotValidException.class)
    public ResponseEntity<Object> handleValidationExceptions(MethodArgumentNotValidException ex) {
        List<Map<String, String>> errors = new ArrayList<>();
        for (FieldError fieldError : ex.getBindingResult().getFieldErrors()) {
            Map<String, String> error = new HashMap<>();
            error.put("field", fieldError.getField());
            error.put("message", fieldError.getDefaultMessage());
            errors.add(error);
        }
        Map<String, Object> body = new HashMap<>();
        body.put("message", "입력값이 올바르지 않습니다.");
        body.put("errors", errors);
        return ResponseEntity.badRequest().body(body);
    }
  }

  ExceptionDto

• 예외 발생 시 클라이언트로 반환할 응답 데이터 포맷을 정의하는 DTO 클래스.

  public class ExceptionDto {
    private int status;
    private String message;
  
    public ExceptionDto(HttpStatus status, String message) {
        this.status = status.value();
        this.message = message;
    }
    // Getter, Setter
  }

  사용 예시

게시글 삭제 예외 처리

@Transactional
public void deletePost(Long id, Long currentUserId, String password) {
    Post post = postRepository.findById(id)
        .orElseThrow(() -> new CustomException(ErrorCode.BOARD_NOT_FOUND));

    if (!currentUserId.equals(post.getUser().getId())) {
        throw new CustomException(ErrorCode.POST_NOT_OWNED);
    }

    passwordManager.validatePasswordMatchOrThrow(password, post.getUser().getPassword());
    postRepository.delete(post);
}

비밀번호 검증 내부 예외

public void validatePasswordMatchOrThrow(String input, String actual) {
    if (!passwordEncoder.matches(input, actual)) {
        throw new CustomException(ErrorCode.INVALID_PASSWORD);
    }
}

게시글 생성 시 유효성 검사 예외 처리

@Transactional
public PostResponseDto createPost(Long currentUserId, String title, String contents, String imageUrl) {
    User user = userService.findUserById(currentUserId);
    Post newPost = new Post(user, title, contents, imageUrl);

    if (newPost.getTitle() == null) {
        throw new CustomException(ErrorCode.POST_NOT_TITLE);
    }

    if (newPost.getContents() == null) {
        throw new CustomException(ErrorCode.POST_NOT_CONTENTS);
    }

    if (newPost.getImageUrl() == null) {
        throw new CustomException(ErrorCode.POST_NOT_IMAGE);
    }

    if (newPost.getTitle().length() > 255) {
        throw new CustomException(ErrorCode.TITLE_LENGTH_OVER);
    }

    Post savePost = postRepository.save(newPost);

    return new PostResponseDto(
        savePost.getId(),
        savePost.getUser().getId(),
        savePost.getTitle(),
        savePost.getContents(),
        savePost.getImageUrl(),
        savePost.getUser().getUserUrl(),
        savePost.getPostLikes().size(),
        savePost.getComments().size(),
        savePost.getCreatedAt(),
        savePost.getModifiedAt()
    );
}

4. 사용한 상태코드 정리 및 사용처

400 BAD_REQUEST

• POST_NOT_OWNED: 작성자가 아닌 사용자가 수정/삭제를 시도할 때
• POST_NOT_CHANGE: 변경할 내용이 비어 있을 때
• POST_NOT_TITLE: 제목이 비어 있을 때
• POST_NOT_CONTENTS: 내용이 비어 있을 때
• POST_NOT_IMAGE: 이미지가 없을 때
• TITLE_LENGTH_OVER: 제목 길이가 255자를 초과할 때

401 UNAUTHORIZED

• INVALID_PASSWORD: 비밀번호가 일치하지 않을 때

404 NOT_FOUND

• BOARD_NOT_FOUND: 해당 게시글을 찾을 수 없을 때

결론

CustomException과 GlobalExceptionHandler를 함께 사용하면 REST API의 에러 응답을 일관되고 명확하게 구성할 수 있다. 위 구조를 프로젝트 초기에 설계해두면 이후 유지보수 시에도 매우 유리하다. 각 클래스의 책임과 역할을 분리하면서 사용자에게는 명확한 메시지를, 개발자에게는 유연한 예외처리 체계를 제공할 수 있다.

원래 계획했던건 ResponseDto를 용도별로 분리하는 브랜치를 만들어서 작업한 후 기존에 작업했던 게시글 전체 조회, 단건 조회, 수정 브랜치 순서로 각각 이동하여 하나씩 구현하려 했는데, 이렇게 작업하면 게시글 전체 조회 기능을 구현할 때 단건 조회, 수정까지 함께 수정해야하는 문제가 생겼습니다. 따라서 Dto 용도별 분리 브랜치에서 한 번에 작업했습니다.

두 번째

게시글 전체 조회 기능에 페이징 기능을 추가하는 작업 중 컨트롤러에서

@GetMapping("/pages/{pageId}")
    public ResponseEntity<List<FindAllPostResponseDto>> findAllAPI(
            @PathVariable  int page,
            @RequestParam (defaultValue = "10") int size
    )

위와 같이 사용하려 했는데 MissingPathVariableException이발생했습니다. 말인 즉 @PathVariable 이 문제라 파악되어, 문제점을 찾다보니, 경로 변수와 @PathVariable 의 이름이 다르다는 사실을 확인했습니다.

이 후 다음과 같이 경로 이름을 수정하여, 해결했습니다.

        @GetMapping("/pages/{page}")
    public ResponseEntity<List<FindAllPostResponseDto>> findAllAPI(
            @PathVariable  int page,
            @RequestParam (defaultValue = "10") int size
    )

추가 수정

현재는 다음과 같이 변경되었습니다.

    @GetMapping
    public ResponseEntity<PageResponseDto<PostListResponseDto>> findAllPosts(
            @PageableDefault(page = 1, sort = "createdAt", direction = Sort.Direction.DESC) Pageable pageable
    )
    {
        PageResponseDto<PostListResponseDto> allPost = postService.findAllPosts(pageable);

        return new ResponseEntity<>(allPost, HttpStatus.OK);
    }

@PathVariable을 사용하지 않고, @PageableDefault를 사용해 기본값 할당 및 정렬 기능을 할당했습니다.

• 사용자 신원 확인과 해당 사용자에게 권한을 부여해 할 수 있는 일의 범위를 지정하는 보안의 핵심 개념이다.

인증(Authentication) vs 인가(Authorization)

쿠키 기반 인증 방식

• 가장 기본적인 웹 인증 방식이다.

• 로그인 시 서버가 인증 정보를 담은 쿠키를 클라이언트에게 발급한다.

• 클라이언트는 매 요청마다 이 쿠키를 자동 전송한다.

• 서버는 쿠키의 값을 기반으로 인증 여부를 판단한다.

쿠키 기반 인증 방식의 한계

• 쿠키가 탈취되면 그대로 인증이 뚫린다.

• 따라서 쿠키에 민감한 정보를 직접 담는 것은 매우 위험하다.

• HTTPS 사용은 사실상 필수이다.

세션(Session) 인증 방식

• 쿠키 인증 방식의 보안 문제를 보완한 구조이다.

• 서버가 사용자 정보를 메모리에 저장한다.

• 클라이언트는 해당 정보를 가리키는 세션 ID만 쿠키로 저장한다.

• 요청 시 세션 ID를 보내면 서버가 해당 사용자를 조회해 인증한다.

• 사용자가 많을수록 서버의 메모리 부담이 커진다.

스프링에서의 세션 방식

HttpSession session = request.getSession();
session.setAttribute("user", user);

토큰 인증 방식 (JWT)

• JWT(JSON Web Token) : 가장 널리 사용되는 토큰 기반 인증 방식이다.

• 로그인 시 서버가 서명된 토큰 문자열을 클라이언트에게 발급한다.

• 클라이언트는 이 토큰을 저장하고 요청마다 헤더에 담아 전송한다.

• 서버는 토큰만으로 사용자를 검증한다.

특징

• 서버는 사용자 상태를 저장하지 않는다. (Stateless)

• 인증 정보는 토큰 내부에 Base64 인코딩된 형태로 포함된다.

• 서버는 토큰을 복호화하고 서명을 검증함으로써 인증 여부를 판단한다.

인코딩은 암호화가 아니다.

• 토큰 인증 방식은 단순히 Base64로 인코딩된 문자열일 뿐 암호화된 것이 아니다.

• 누구든지 토큰을 디코딩하면 내용을 볼 수 있다.

• 민감한 정보(ID, 주민번호 등)는 절대 토큰에 넣으면 안된다.

세션 vs 토큰 인증 방식 비교

상황별 인증 방식 가이드

JWT 사용 시 주의사항

+HTTPS 사용은 필수이다.

• 토큰 만료 시간을 짧게 설정해야 한다.

• 리프레시 토큰 전략을 함께 사용하면 보안을 강화할 수 있다.

인증과 인가 요약

• 인증: “너 누구야?”

• 인가: “너 이거 해도 돼?”

• 인증 방식은 쿠키 → 세션 → 토큰 순으로 발전해왔다.

• 세션은 서버가 상태를 기억하고, 토큰은 클라이언트가 들고 다닌다.

• JWT는 암호화가 아닌 인코딩이므로, 노출되면 내용이 그대로 보일 수 있다.

전체 일정 목록을 조회하는 API를 만들어 POSTMAN으로 테스트하는 과정에서 에러가 발생했다.

schedule_id컬럼을 조회할 수 없기 때문에 발생되는 오류로 판명되었다.

컬럼명을 카멜케이스로 사용중이어서 찾지 못 하는 것 같았다.

그래서 데이터베이스 테이블을 모두 삭제하고 스네이크케이스로 변경하여 다시 생성하였다.

정상 출력되는 모습

두 번째 문제

일정을 수정하는 기능을 만든 뒤 확인해보니 수정이 아닌 새로운 일정을 생성하고 있었다. 이는 save()메서드를 사용했기 때문이었고, 제목과 내용을 수정할 수 있는 세터를 만들어서 해결했다.

그러나 이후 POSTMAN에서는 정상적으로 출력되나, 데이터베이스에 반영이 되지 않는 문제가 발생했다.

확인해보니 이는 서비스 레이어에서 @Transactional을 사용하지 않아, 변경 감지를 하지 못 해 생긴 문제였고, @Transactional을 선언하여 문제를 해결했다.

정상적으로 데이터베이스에 반영되는 모습이다.

세 번째 문제

일정 수정 기능에 사용자의 비밀번호를 입력받아 같은 비밀번호인지 검증한 후 일정을 수정할 수 있도록 구조 변경 중 NullPointerException이 발생했다.

에러 문구를 읽어보니 참조중인 getUserEntity의 값이 null로 들어가는것으로 확인되었다.

이후 디버깅모드로 값을 한줄 씩 확인해봤고 문제 지점은 내가 예상한 부분이 아닌 다른 부분에 있었다.

유저 식별자를 함꼐 출력하기 위해 scheduleResponseDto 의 구조를 변경했었는데, 이 때 유저 식별자를 불러오면서, 객체에 유저를 매핑해주지 않아서 NullPointerException이 발생되는 것이었다.

여기서 scheduleResponseDto객체를 만드는 과정에서 scheduleEntity.getUserEntity().getUserId()를 사용했는데,

ScheduleEntity scheduleEntity = new ScheduleEntity(title, schedule);

이 부분에서 객체를 새로 생성하여 유저 객체와의 매핑이 이루어지지 않은 것이었다.

따라서 객체를 생성하는 부분을 없앤 후 scheduleEntity.get이 들어가는 모든 부분을 findSchedule.get으로 변경하였다.