개발 기록

[Nbcam] 유저 검색 조회 속도 개선

limitation01 — Mon, 22 Dec 2025 08:37:33 +0900

전제

데이터: 500만건
조건: nickname 정확히 일치
결과: 중복 없기 때문에 단건 조회
테스트 환경:
- 조회 성능 측정 시 캐시 효과를 배제하기 위해 매번 MySQL 서버를 재시작해 동일한 스타트 환경에서 측정

최초 조회 속도

인덱스가 없는 상태에서 500만건중 쿼리파라미터로 들어온 값과 일치하는 단건 조회를 수행한 결과

-> Filter: (u.nickname = 'zi0')  
(cost=529242 rows=499163) 
(actual time=0.0548..2733 rows=1 loops=1)
    -> Table scan on u  
    (cost=529242 rows=4.99e+6) 
    (actual time=0.0494..2589 rows=5.03e+6 loops=1)

소요 시간
- DB 실행시간: 약 2.6s
- API 전체 응답 시간: 약 3.53s
전체 테이블 스캔 발생

조회 속도 개선 아이디어

1. 엔티티 조회방식 대신 DTO projection 사용

불필요한 엔티티 로딩을 피하고 필요한 컬럼만 조회하기 위해 DTO Projection 방식을 고려했다.

@Query("""
            select new org.example.expert.domain.user.dto.response.UserSearchResponse(
                u.id,
                u.email,
                u.nickname
            )
            from User u
            where u.nickname = :nickname
        """)
    UserSearchResponse findFirstByNickname(@Param("nickname") String nickname);

예상

인덱스가 없는 상황에서 테이블 스캔 비용이 크다고 생각해 DTO Projection 단독으로는 유의미한 성능 개선은 없을 것이라 예상했다.
다만, 인덱싱과 함께 사용시 테이블 접근 비용 감소에 기여할 수 있을 것이라고 판단했다.

결과

-> Filter: (u.nickname = 'zi0')  
(cost=530220 rows=499163) 
(actual time=1.88..3016 rows=1 loops=1)
    -> Table scan on u  
    (cost=530220 rows=4.99e+6) 
    (actual time=1.87..2510 rows=5.03e+6 loops=1)

DB실행 시간: 약 2.5s
예상과 동일하게 조회 성능에 유의미한 변화 없음

2. 인덱스 적용에 따른 성능 변화

2-1. nickname 필드에 인덱스 추가

@Getter
@Entity
@NoArgsConstructor
@Table(name = "users", indexes = @Index(name = "idx_user_nickname", columnList = "nickname"))

public class User extends Timestamped {

결과

-> Index lookup on u using idx_user_nickname (nickname='zi0')  
(cost=1.1 rows=1) 
(actual time=0.257..0.258 rows=1 loops=1)

소요 시간:
- DB 실행시간: 약 0.26s
- API 전체 응답 시간: 약 0.36s
테이블 스캔이 제거되며 조회 성능이 크게 개선됨을 확인

2-2.nickname 필드로 unique index scan

닉네임 중복이 없는 요구사항을 반영해 유니크 제약 조건을 적용했다.

@Getter
@Entity
@NoArgsConstructor
@Table(name = "users",
        uniqueConstraints = {
            @UniqueConstraint(
                    name="unique_users_nickname",
                    columnNames = "nickname"
            )
})
public class User extends Timestamped {

예상

유니크 인덱스 스캔을 사용하면 옵티마이저가 논리적으로 LIMIT 1을 보장한다고 한다.
결과가 항상 1건이므로 일반 인덱스보다 더 빠를 것이라 예상했다.

결과

-> Rows fetched before execution  
(cost=0..0 rows=1) 
(actual time=119e-6..187e-6 rows=1 loops=1)

소요 시간:
- DB 실행시간: 약 0.19s
- API 전체 응답 시간: 약 0.46s

유니크 인덱스를 적용했음에도 BTREE 인덱스와 조회 속도 차이는 없었다.

도출한 인사이트

두가지 종류의 인덱스 적용 아이디어로 테스트해 다음과 같은 실행 흐름을 확인했다.

B-Tree 인덱스 탐색 (BTREE vs UNIQUE 동일한 탐색을 함)
PK로 테이블 row를 접근
결과 반환

인덱스 스캔의 종류보다 2번 문제 즉 테이블의 접근 문제를 생각해야 유의미한 조회 속도 개선을 할 수 있을 것이라고 판단했다.

랜덤 I/O 관점으로의 변화

참고 도서에서 언급된

SQL 튜닝은 랜덤 I/O와의 전쟁이다

라는 문장은 본 실험 결과와 정확히 일치하였다.

인덱스 탐색 자체에서는 병목이 발생하지 않았다.
PK 기반 테이블 접근으로 인한 랜덤 I/O가 조회 성능 저하의 주된 원인이었다.

3. 커버링 인덱스

앞서 언급했듯 성능 개선의 핵심은 어떤 인덱스를 사용하냐가 아니라 테이블 접근을 어떻게 제거하느냐 였다. 인덱스 탐색 이후 발생하는 테이블 row접근(랜덤 I/O)을 제거할 수 있다면 조회 성능을 유의미하게 개선할 수 있을 것이라고 생각해 커버링 인덱스를 사용하게 되었다.

커버링 인덱스는

WHERE 절에 사용되는 컬럼이 인덱스에 포함되어 있고
SELECT 절에서 조회하는 컬럼 또한 인덱스에 포함되어 있어
테이블(row)에 접근하지 않고 인덱스만으로 결과를 반환할 수 있는 경우

의 조건을 만족하면 PK를 통해 테이블 데이터를 다시 조회하는 과정을 생략할 수 있다

구성

@Table(
        name = "users",
        indexes = {
                @Index(
                        name = "idx_users_nickname_covering",
                        columnList = "nickname, id, email"
                )
        }
)

WHERE 조건
- nickname
SELECT 컬럼
- id
- email
- nickname

이 컬럼들을 모두 포함하도록 커버링 인덱스를 구성했다. 이 인덱스를 통해

WHERE 조건은 인덱스에서 바로 필터링
SELECT 컬럼 역시 인덱스에 포함
테이블 row 접근 없이 결과 반환이 가능

결과

-> Covering index lookup on u using idx_users_nickname_covering (nickname='zi0')  
(cost=1.1 rows=1) 
(actual time=0.0294..0.0335 rows=1 loops=1)

소요 시간: 약 0.03ms
PK 기반 테이블 접근이 제거되며 가장 유의미한 성능 개선을 보였다.
테이블 접근 없이 인덱스만으로 조회가 수행됨을 확인하였다.

조회 성능 비교 결과

단계	개선 아이디어	주요 목적	DB 실행 시간	API 응답 시간
1	DTO Projection	엔티티 로딩 제거	2500ms	3040ms
2	기본 인덱스	테이블 스캔 제거	0.26ms	360ms
3	UNIQUE 인덱스	논리적 단건 보장	0.19ms	460ms
4	커버링 인덱스	테이블 접근 제거	0.03ms	360ms

DB 실행 시간 vs API 응답 시간 차이

눈에띄게 차이났던 DB 실행시간과 달리 커버링 인덱스 적용 이후에도 API 응답시간이 더 이상 크게 줄지 않았다.
그 이유를 생각해보았을 때

DB 실행 시간은 쿼리 처리 시간만 측정
API 응답 시간에는 컨트롤러, 서비스 호출 및 네트워크 전송 비용 등 다음과 비용이 추가로 포함됨

잘못 적용했나 처음에 생각했었는데 인덱스가 제대로 동작하지 않은 것이 아니라 앱단의 오버헤드에 의한 시간의 차이가 있었다.

이후에 생각해본 것

커버링 인덱스를 적용함으로써 단건 조회에 대한 DB 쿼리 최적화는 충분히 달성했다고 판단했다.
실제로 EXPLAIN ANALYZE 기준으로 인덱스 탐색 및 테이블 접근이 제거되었고, 조회 시간 또한 수 ms 단위까지 감소했다.

다만 지금까지의 성능 측정은 항상 MySQL 서버를 재시작한 후 진행했기 때문에, 실제 운영 환경에서 자연스럽게 발생하는 캐시 효과를 고려하지 않은 상태였다.

현실적인 서비스 환경에서는 동일한 조회 요청이 반복적으로 발생할 가능성이 있으며,
이 경우 DB 내부 캐시또는 앱단의 캐시를 통해 데이터 접근 비용을 더욱 줄일 수 있다고 생각했다.

캐시 전략 도입 배경

이번에는 다음과 같은 상황을 가정했다.

동일한 닉네임 조회 요청이 반복적으로 들어온다
매 요청마다 DB에 접근하는 것은 불필요한 비용이다
조회 결과가 자주 변하지 않는 데이터라면 캐시로 충분히 대응 가능하다

이에 따라 DB 접근 횟수 자체를 줄이기 위한 캐시 전략을 추가로 적용했다.
구현 단계에서는 캐시 개념을 빠르게 검증하기 위해 Spring Cache 추상화를 사용했다.

DB 캐시

커버링 인덱스가 적용된 상태에서의 실행 계획은 다음과 같다.

-> Covering index lookup on u using idx_users_nickname_covering (nickname='zi0')  
(cost=1.1 rows=1) 
(actual time=0.0169..0.0193 rows=1 loops=1)

테이블 접근 없이 인덱스만으로 조회
DB 레벨에서 매우 빠른 응답 시간
하지만 여전히 매 요청마다 DB 접근은 발생

Spring Cache 적용

동작 방식

첫 요청(Cache Miss)
- 캐시에 값이 없으므로 DB 조회 수행
- 콘솔에 DB 접근 발생 로그 출력
- SQL 쿼리 실행됨
두 번째 요청(Cache Hit)
- 캐시에 저장된 값 반환
- 서비스 메서드 자체가 호출되지 않음
- 콘솔 로그 및 SQL 쿼리 출력 안됨

처음에 요청을 보내면 캐시에 저장된 값이 없으니 결과 사진과 같이 DB에서 직접 조회라는 로그가 찍히며 쿼리가 날라간다.
이후 바로 동일한 요청을 보내면 콘솔에 로그와 쿼리가 찍히지 않는다.

이를 통해 DB 접근이 완전히 제거되었음을 확인할 수 있었다.

참고 도서
친절한 SQL 튜닝

[Spring] QueryDSL Projection 방식 비교

limitation01 — Wed, 17 Dec 2025 19:58:47 +0900

개요

QueryDSL로 검색 API를 구현하면서 엔티티가 아닌 검색 전용 DTO로 결과를 조회해야 했다.

DTO 매핑방식으로 두가지 선택지가 있다는 것을 알게되었다

Projections.constructor()
@QueryProjection

두 방식은 결과는 같아 보이지만,
안전성 · 유지보수성 · 오류 발견 시점에서 큰 차이가 있었다.

Projections.constructor 방식

.select(Projections.constructor(
    TodoSearchResponse.class,
    todo.title,
    manager.id.countDistinct(),
    comment.id.countDistinct()
))

특징

DTO에 QueryDSL 의존성 X
생성자만 있으면 바로 사용 가능
설정이 간단

단점

생성자 파라미터 순서가 바뀌어도 컴파일 통과
타입이 애매하면 런타임 에러
DTO 생성자 변경 시 IDE가 쿼리 오류를 잡아주지 못함

쿼리 오류를 실행해보기 전까지 알 수 없다

@QueryProjection 방식

DTO

@Getter
public class TodoSearchResponse {

    private final String title;
    private final long managerCount;
    private final long commentCount;

    @QueryProjection
    public TodoSearchResponse(
            String title,
            long managerCount,
            long commentCount
    ) {
        this.title = title;
        this.managerCount = managerCount;
        this.commentCount = commentCount;
    }
}

쿼리 사용

.select(new QTodoSearchResponse(
    todo.title,
    manager.id.countDistinct(),
    comment.id.countDistinct()
))

특징

생성자 시그니처가 컴파일 타임에 검증
파라미터 개수/순서/타입이 틀리면 즉시 컴파일 에러
DTO 변경 시 쿼리 코드에서 바로 오류 발생

쿼리 오류를 컴파일 시점에 잡을 수 있다

@QueryProjection을 선택한 이유

이번 검색 API는 다음 조건을 만족해야 했다.

QueryDSL 기반 복잡한 검색
집계(countDistinct) 포함
DTO 구조 변경 가능성 있음

이 상황에서는
실행 전에 오류를 잡을 수 있는 안정성이 가장 중요하다고 판단했다.

[HTTP] HTTP 메서드 멱등성

limitation01 — Wed, 10 Dec 2025 09:04:38 +0900

DELETE 메서드는 멱등해야한다.

HTTP DELETE 메서드는 원칙적으로 멱등(Idempotent) 해야 한다. 즉,

“같은 DELETE 요청을 여러 번 보내도 서버의 최종 상태는 동일해야 한다.”

예를 들어 /todos/1/managers/10 을 삭제할 때:

첫 번째 요청 → manager 정상 삭제
두 번째 요청 → 이미 삭제된 상태지만
- 서버의 최종 상태는 동일(삭제됨)
- 실패가 아니라 성공처럼 처리

내가 받은 피드백의 핵심 - 두 번째 DELETE 요청이 실패하면 UX가 깨진다

다음과 같은 피드백을 받았다.

ManagerController delete 메소드의 인증된유저 처리 문제 에서 HTTP Method중 DELETE는 멱등성을 준수합니다. 제공하는 기능에 따라 멱등성을 준수하지 않도록 만들어야 할 수 도 있지만 기본적으로는 같은 값으로 요청을 보내도 동일한 결과를 주어야합니다. 모종의 이유로 인해 사용자가 보낸 요청이 빠르게 두번 연속으로 서버로 보내질 경우 두번째 요청으로 인해 유저가 보는 화면에서는 결국 오류가 발생했다고 느낄 수 있기 때문이죠. API 기능 설계 UX도 고려가 되면 좋겠습니다

문제가 발생할 수 있는 내코드는

Todo todo = todoRepository.findById(todoId)
        .orElseThrow(() -> new InvalidRequestException("Todo not found"));

문제

첫 번째 요청 → Todo와 Manager 모두 존재 → 정상 삭제
두 번째 요청 → Manager는 이미 삭제됨, 심지어 Todo도 존재하지 않을 수 있음

→ 결과적으로 예외 터짐
→ 사실은 이미 삭제된 것이므로 정상 상태인데도 사용자는 삭제가 실패한 것처럼 느낌 (UX가 깨짐)

DELETE 멱등성을 지키기 위해서는
두 번째 요청에서도 예외가 나지 않게 설계해야 한다.

개선 방향

1. Todo 조회가 중요할까?

DELETE의 목적은 Manager 삭제
Todo가 존재하는지는 두 번째 요청 이후에는 중요하지 않다.

Manager manager = managerRepository.findById(managerId)
        .orElse(null);

if (manager == null) {
    return; // 이미 삭제됨 → 멱등성 충족
}

manager만 먼저 조회해 이미 삭제되었을시 바로 리턴
delete 호출은 1번만 일어남

2. 조회 실패는 조용히 넘어감

DELETE는 같은 요청을 여러 번 보내도 정상처럼 보이는 게 규약
권한이 잘못되면 Forbidden이 맞지만 이미 삭제된 리소스(NotFound)는 멱등성이 보장된 정상 종료여야 함

배운점

서비스 로직을 만들때 이 코드가 UX에 어떤 영향을 미치는가도 함께 고민해야 한다는 사실을 리마인드 하게되었다.

[Spring] Spring Security + JWT로 로그인 기능 구현

limitation01 — Tue, 9 Dec 2025 09:07:05 +0900

전체적인 흐름

클라이언트가 /auth/login 으로 이메일/비밀번호 전송
서버에서 사용자 검증 후 JWT 발급
이후 요청들은 Authorization: Bearer token헤더에 JWT를 담아서 호출
커스텀 JwtAuthFilter가 토큰을 검증하고 userId를 꺼냄
@AuthUser 파라미터로 컨트롤러에 userId를 바로 주입
→ 컨트롤러/서비스는 JWT 구조를 모른 채 로그인된 사용자 ID만 다룸

설계

JwtUtil - JWT 생성 및 검증

역할

토큰 생성
토큰 검증
Claims / subject 추출

설계 기준

subject에는 userId를 넣음 (주 식별자)
claim으로 email 정도만 추가
validate()는 예외 캐치로 단순 처리

@Component
public class JwtUtil {

    @Value("${jwt.secret}")
    private String secret;

    @Value("${jwt.expiration}")
    private long expiration;

    private SecretKey key;

    @PostConstruct
    public void init() {
        this.key = Keys.hmacShaKeyFor(secret.getBytes());
    }

    public String generateToken(Long userId, String email) {
        long now = System.currentTimeMillis();
        return Jwts.builder()
                .subject(String.valueOf(userId))
                .claim("email", email)
                .issuedAt(new Date(now))
                .expiration(new Date(now + expiration))
                .signWith(key)
                .compact();
    }

    public Claims getClaims(String token) {
        return Jwts.parser().verifyWith(key).build()
                .parseSignedClaims(token)
                .getPayload();
    }

    public boolean validate(String token) {
        try {
            getClaims(token);
            return true;
        } catch (Exception e) {
            return false;
        }
    }
}

subject를 userId로 통일해서 로그인한 사용자 = Long userId로만 단순하게 생각
나머지 email, role 같은 것들은 필요해지면 claim으로 점진적으로 추가

PrincipalDetails - UserDetails 구현체

역할

Spring Security가 인식하는 인증된 사용자 객체
Authentication.getPrincipal() 로 접근 가능
컨트롤러에서 @AuthenticationPrincipal 로 직접 꺼내 사용 가능

설계 기준

User 엔티티를 그대로 들고 있게 함
- 필요한 모든 유저 정보는 전부 User 엔티티에서 꺼낼 수 있음
- 서비스나 컨트롤러가 userId만 필요한 경우에도 편리함
권한(authorities)은 최소 ROLE_USER만 설정

@Getter
public class PrincipalDetails implements UserDetails {

    private final User user;

    public PrincipalDetails(User user) {
        this.user = user;
    }

    @Override
    public Collection<? extends GrantedAuthority> getAuthorities() {
        return List.of(new SimpleGrantedAuthority("ROLE_USER"));
    }

    @Override public String getPassword() { return user.getPassword(); }
    @Override public String getUsername() { return user.getEmail(); }

    @Override public boolean isAccountNonExpired() { return true; }
    @Override public boolean isAccountNonLocked() { return true; }
    @Override public boolean isCredentialsNonExpired() { return true; }
    @Override public boolean isEnabled() { return true; }
}

PrincipalDetailsService - UserDetailsService 구현체

역할

JWT에서 userId를 꺼낸 뒤 → DB에서 유저를 다시 조회하는 단계
User not found, disabled 등 상태 체크 가능

설계 기준

username 파라미터를 userId로 사용
- JWT subject = userId이므로 userIdString을 username처럼 사용

@Service
@RequiredArgsConstructor
public class PrincipalDetailsService implements UserDetailsService {

    private final UserRepository userRepository;

    @Override
    public UserDetails loadUserByUsername(String userIdString) throws UsernameNotFoundException {
        Long userId = Long.valueOf(userIdString);

        User user = userRepository.findById(userId)
                .orElseThrow(() -> new UsernameNotFoundException("Not Found User"));

        return new PrincipalDetails(user);
    }
}

JwtAuthenticationFilter - 핵심 필터

역할

토큰 파싱 → 검증 (Authorization → Bearer 토큰만 허용)
토큰 유효시
- JWT subject(userId) 추출
- DB에서 사용자 정보(UserDetails) 조회
- Authentication 생성
SecurityContextHolder에 Authentication 등록

설계 기준

shouldNotFilter()로 인증 제외 경로 관리
- 로그인/회원가입은 인증 필요 없음
Authentication을 직접 만들어 넣음
- Spring Security는 SecurityContextHolder에 인증 객체가 존재하는가를 기준으로
  요청이 인증되었다고 판단

@Component
@RequiredArgsConstructor
public class JwtAuthenticationFilter extends OncePerRequestFilter {

    private final JwtUtil jwtUtil;
    private final PrincipalDetailsService principalDetailsService;

    @Override
    protected boolean shouldNotFilter(HttpServletRequest request) {
        String uri = request.getRequestURI();
        return uri.startsWith("/auth/login") || uri.startsWith("/auth/signup");
    }

    @Override
    protected void doFilterInternal(
            HttpServletRequest request,
            HttpServletResponse response,
            FilterChain filterChain
    ) throws ServletException, IOException {

        String token = resolveToken(request);

        if (token != null && jwtUtil.validate(token)) {

            Claims claims = jwtUtil.getClaims(token);
            String userId = claims.getSubject();

            UserDetails userDetails = principalDetailsService.loadUserByUsername(userId);

            UsernamePasswordAuthenticationToken authentication =
                    new UsernamePasswordAuthenticationToken(
                            userDetails,
                            null,
                            userDetails.getAuthorities()
                    );

            SecurityContextHolder.getContext().setAuthentication(authentication);
        }

        filterChain.doFilter(request, response);
    }

    private String resolveToken(HttpServletRequest request) {
        String bearer = request.getHeader("Authorization");

        if (bearer != null && bearer.startsWith("Bearer ")) {
            return bearer.substring(7);
        }
        return null;
    }
}

SecurityConfig - 필터 연결

역할

Spring Security의 필터 체인에 JwtAuthenticationFilter 추가
세션 사용 안 함 (stateless)
인증이 필요한 URL만 보호
나머지는 permitAll

@Configuration
@EnableWebSecurity
@RequiredArgsConstructor
public class SecurityConfig {

    private final JwtAuthenticationFilter jwtAuthenticationFilter;

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {

        http.csrf().disable()
            .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)
            .and()
            .authorizeHttpRequests(auth -> auth
                    .requestMatchers("/auth/login", "/auth/signup").permitAll()
                    .anyRequest().authenticated()
            )
            .addFilterBefore(jwtAuthenticationFilter, UsernamePasswordAuthenticationFilter.class);

        return http.build();
    }
}

컨트롤러에서 사용자 정보 받기

@GetMapping("/me")
public UserResponse me(@AuthenticationPrincipal PrincipalDetails principal) {
    return new UserResponse(principal.getUser());
}

[Spring] Transactional 사용시 자가호출(Self-Invocation)이슈

limitation01 — Mon, 8 Dec 2025 13:10:49 +0900

문제

다음과 같은 코드에서,
한 메서드 안에서 다른 @Transactional 메서드를 호출하면
나는 REQUIRES_NEW가 적용되어 별도 트랜잭션이 만들어질 것이라고 기대했다.

그러나 실제 동작은 전혀 달랐다.

@Service
@Slf4j
@RequiredArgsConstructor
public class OrderService {

    private final StockService stockService;
    private final PaymentService paymentService;
    private final PaymentRepository paymentRepository;
    private final OrderRecordService orderRecordService;

    @Transactional
    public void processOrder() {

        // 1. 재고 감소
        stockService.save();
        // 2. 결제 처리
        pamentSave();
        // 3. 주문 기록 s
        orderRecordService.save();

        throw new RuntimeException("예외 발생");

    }

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void paymentSave() {
        paymentRepository.save(new Payment(1L,"GOOD"));
        log.info("결제 처리 저장 완료");
    }
}

왜 REQUIRED_NEW가 동작하지 않았을까?

프록시를 통과한건가 라고 생각해 질문을 했는데 세션에서 프록시 객체가 이미 생성되어있어서라는 답을 들었지만 의미를 한번에 이해하기 힘들었다.

이후 또 한번의 질문을 통해 이 문제의 핵심은 자가 호출 이라는 것을 알게되었다.

자가호출 (Self Invocation)

같은 객체 안에서 자기 자신의 메서드를 직접 호출하는 경우 = 프록시를 다시 거치지 않는 호출

@Transactional
public void processOrder() {
    paymentSave();   //자가 호출
}

@Transactional(propagation = REQUIRES_NEW)
public void paymentSave() {
    생략
}

같은 클래스
자기 자신의 메서드 호출
새로운 호출도 아님
프록시가 아닌 실제 객체 호출

→ 전형적인 Self-invocation

이 때문에 Spring AOP는 다음처럼 판단하게 된다

이 호출은 내가 가로챌 수 있는 종류의 호출이 아니네

왜 자가 호출에서는 @Transactional이 안먹힐까

왜 AOP가 개입하지 못할까 라고도 생각해볼 수 있었다.

Spring의 @Transactional은 AOP 프록시 방식으로 동작한다.

proxy는 입구에만 존재한다.

스프링은 Bean을 만들 때 다음 순서로 생성한다

호출자
OrderServiceProxy
OrderService 실제 객체

외부에서 서비스 메서드를 호출할 때만 프록시가 개입해 트랜잭션을 시작하거나 종료가 가능하다.

자가 호출은 프록시 외부 호출이 아니다

사진 구조대로 보면 자가 호출시(Object의 되돌아가는 화살표) 프록시를 호출하지 못함 = AOP가 적용될 수 없음
프록시는 외부 호출만 가로챌 수 있는데 이미 프록시 안쪽으로 들어와있다.

⇒ AOP가 개입할 수 없는 호출이기 때문에 @Transactional(propagation = REQUIRES_NEW) 설정이 적용되지 않는다.

배운점

REQUIRES_NEW가 동작하지 않은 이유는 트랜잭션 옵션이 잘못된 것이 아니라 AOP가 paymentSave() 호출 자체를 볼 수 없었기 때문이다.
자가 호출(self-invocation)은 프록시를 우회한 호출 → AOP 적용 불가 이 구조적 한계 때문에 @Transactional 설정이 무시된다.
processOrder() 내부에서 같은 클래스의 다른 @Transactional 메소드를 호출하면 기대한 트랜잭션 경계가 절대 적용되지 않는다.

[Spring]왜 Security 의존성을 추가하면 API 호출시 401이 뜰까

limitation01 — Sat, 6 Dec 2025 19:37:51 +0900

기존에 잘 돌아가던 demo 프로젝트에 Security 의존성을 추가하니 모든 API 호출시 401에러가 떴다. 왜 의존성 추가 하나만으로 잘 돌아가던 서버가 에러를 뱉는걸까?

Security의 기본 보안 정책 자동 활성화

Spring Security는 의존성 추가만으로도 다음 설정을 자동 적용

모든 요청은 인증 필요
인증되지 않은 요청은 → 401 Unauthorized
Form 로그인 페이지가 자동 생성됨
기본 사용자 계정이 자동 생성됨 (username=user, password=콘솔에 출력)

즉 security가 추가되며 모든 요청을 가로막은 것이다.

Security를 추가한 후의 동작 흐름

왜 401일까?

Spring Security가 요청을 Controller로 보내기 전에 차단하기 때문 , 컨트롤러에 도달하지도 않았다.

해결 방법 - 허용할 요청 명시

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        return http
            .csrf(AbstractHttpConfigurer::disable)  // .csrf().disable() 방식은 더 이상 사용 안함.
            .httpBasic(AbstractHttpConfigurer::disable) // BasicAuthenticationFilter 비활성화
            .formLogin(AbstractHttpConfigurer::disable) // UsernamePasswordAuthenticationFilter, DefaultLoginPageGeneratingFilter 비활성화
            .addFilterBefore(jwtFilter, SecurityContextHolderAwareRequestFilter.class)
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/api/login").permitAll()
                .anyRequest().authenticated()
            )
            .build();
    }

csrf : JWT 기반 인증에서는 필요하지 않으니 CSRF 보호를 비활성화
httpBasic : HTTP Basic 인증 방식 비활성화
formLogin : 기본 로그인 폼과 관련된 필터 비활성화
addFilterBefore : 필터의 순서를 지정해주는 역할
- .addFilterBefore(jwtFilter, SecurityContextHolderAwareRequestFilter.class) = jwtFilter 뒤에 SecurityContextHolderAwareRequestFilter 를 위치 시킬 것
authorizeHttpRequests : 어디에 어떻게 권한 검사를 할 것인지에 대한 구체적인 내용

.authorizeHttpRequests(auth -> auth
                .requestMatchers("/api/login").permitAll()
                .requestMatchers("/api/admin/**").hasRole("ADMIN")
                .requestMatchers("/api/user/**").hasRole("USER")

[Nbcam] Level6 정의하고 해결한 문제

limitation01 — Fri, 5 Dec 2025 00:14:21 +0900

1. ManagerController delete 메소드의 인증된유저 처리 문제

문제

기존 deleteManager 메서드 에서는

컨트롤러가 JWT 구조를 알고있음
Authorization Header를 직접 읽고 jwtUtil을 직접 사용

@DeleteMapping
public void deleteManager(
    @RequestHeader("Authorization") String bearerToken,
    @PathVariable long todoId,
    @PathVariable long managerId
) {
    Claims claims = jwtUtil.extractClaims(...);
    long userId = Long.parseLong(claims.getSubject());
}

Controller가 JWT를 알아야 해서 인증 책임이 컨트롤러단 까지 내려왔다고 생각했다.

해결

인증된 사용자가 Todo의 담당자를 삭제한다는 의미에 맞게 인증된 유저(AuthUser)만 전달 받는 구조가 맞다고 판단했다.

결과

@DeleteMapping("/todos/{todoId}/managers/{managerId}")
    public void deleteManager(
            @Auth AuthUser authUser,
            @PathVariable long todoId,
            @PathVariable long managerId
    ) {
        managerService.deleteManager(authUser, todoId, managerId);
    }

컨트롤러에서 JWT 의존 제거
인증 책임을 인증 계층으로 위임

2. CommentAdminService delete 메소드 검증 누락 문제

문제

deleteComment 메서드에서 댓글 존재 여부나 삭제 가능 여부에 대한 검증 없이 바로 deleteById를 호출했다. 존재하지 않는 ID 삭제할경우 삭제가 실패했는데, 실패했다는 사실을 아무도 모르는 상태가 된다.

해결

서비스단에서 도메인 행위의 유효성을 검증하고 실패 케이스에 대한 예외처리를 해주는것이 서비스 레이어의 책임이라고 생각했다.

@Transactional
public void deleteComment(long commentId) {
   commentRepository.deleteById(commentId);
}

결과

@Transactional
public void deleteComment(long commentId) {
   Comment comment = commentRepository.findById(commentId)
          .orElseThrow(() -> new InvalidRequestException("댓글이 존재하지 않습니다."));
   commentRepository.delete(comment);
}

3. 페이지네이션 책임 위치 개선

문제

기존코드는 디폴트 페이지 값이 사용자 관점에서 1로 지정되어있고 서비스단에서 page - 1 보정 로직을 수행했다. 그럼으로써 서비스가 사용자 요청 포맷을 알고 있고 page 보정에 대한 책임이 하위 레이어까지 내려왔다고 판단했다.

    // controller
    @GetMapping("/todos")
    public ResponseEntity<Page<TodoResponse>> getTodos(
            @RequestParam(defaultValue = "1") int page,
            @RequestParam(defaultValue = "10") int size
    ) {
        return ResponseEntity.ok(todoService.getTodos(page, size));
    }
    
    //service
    @Transactional(readOnly = true)
    public Page<TodoResponse> getTodos(int page, int size) {
        Pageable pageable = PageRequest.of(page - 1, size);

        Page<Todo> todos = todoRepository.findAllByOrderByModifiedAtDesc(pageable);

        return todos.map(todo -> new TodoResponse(
                todo.getId(),
                todo.getTitle(),
                todo.getContents(),
                todo.getWeather(),
                new UserResponse(todo.getUser().getId(), todo.getUser().getEmail()),
                todo.getCreatedAt(),
                todo.getModifiedAt()
        ));
    }

해결

spring은 pageable 항상 0-base로 처리, 우리가 사용자 관점으로 맞출 필요 없다
페이징 디폴트 값 처리는 컨트롤러 책임

결과

	//controller
    @GetMapping("/todos")
    public ResponseEntity<Page<TodoResponse>> getTodos(
            @PageableDefault(page = 0, size = 10, sort = "modifiedAt", direction = Sort.Direction.DESC)
            Pageable pageable
    ) {
        return ResponseEntity.ok(todoService.getTodos(pageable));
    }
    
    //service
    @Transactional(readOnly = true)
    public Page<TodoResponse> getTodos(Pageable pageable) {
        Page<Todo> todos = todoRepository.findAll(pageable);

        return todos.map(todo -> new TodoResponse(
                todo.getId(),
                todo.getTitle(),
                todo.getContents(),
                todo.getWeather(),
                new UserResponse(todo.getUser().getId(), todo.getUser().getEmail()),
                todo.getCreatedAt(),
                todo.getModifiedAt()
        ));
    }

4. Signup Response DTO 설계 문제

문제

회원가입,로그인 응답이 다음과 같이 토큰만 반환하고 있었다.

{
    "bearerToken": "Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIyIiwiZW1haWwiOiJ6aXkwaW5nMUBuYW1lci5jb20iLCJ1c2VyUm9sZSI6IlVTRVIiLCJleHAiOjE3NjQ3NDYyNjIsImlhdCI6MTc2NDc0MjY2Mn0.cbI5KQxPWg9oAB1PTff5EkM8evwPFNEofeK9BGzBfuY"
}

해결

signup은 계정 생성, signin은 인증 및 토큰 발급의 책임으로 각각 응답의 구조가 달라야 한다고 생각했다. 바뀌어야 할 곳은 책임에 따라 signup이라고 판단했다.

토큰 발급은 signin 역할로 분리했다.

결과

{
    "id": 1,
    "email": "abab@example.com"
}

[Nbcam] 심화 주차 Level5 AOP를 활용해 특정 API 로깅 구현

limitation01 — Thu, 4 Dec 2025 00:03:42 +0900

Interceptor 또는 AOP를 활용하는 부분이라 나는 AOP 구현을 선택했다.

조건

AOP를 사용하여 구현하기

어드민 API 메서드 실행 전후에 요청/응답 데이터를 로깅합니다.
로깅 내용에는 다음이 포함되어야 합니다:
- 요청한 사용자의 ID
- API 요청 시각
- API 요청 URL
- 요청 본문(RequestBody)
- 응답 본문(ResponseBody)
@Around 어노테이션을 사용하여 어드민 API 메서드 실행 전후에 요청/응답 데이터를 로깅합니다.
요청 본문과 응답 본문은 JSON 형식으로 기록하세요.
로깅은 Logger 클래스를 활용하여 기록

변경 파일 상세 설명

AccessCheckAOP

역할

어드민 전용 API 접근 시점에 실행되는 AOP
요청 정보 수집 로그로 기록
컨트롤러/서비스 로직과 로깅 관심사를 명확히 분리

Pointcut

@Pointcut("@annotation(org.example.expert.config.OnlyAdmin)")
public void adminApi() {}

@OnlyAdmin 어노테이션이 붙은 메서드만 타겟
URL, 패키지명에 의존하지 않고 선언적으로 어드민 API 식별
어드민 API가 추가되더라도 AOP 수정 없이 어노테이션만 부착하면 확장 가능

Around Advice (accessLogToInfo 메서드)

@Around("adminApi()")
public Object executionTime(ProceedingJoinPoint joinPoint) throws Throwable

HttpServletRequest

HttpServletRequest request = ((ServletRequestAttributes) RequestContextHolder.getRequestAttributes()).getRequest();

AOP에서는 메서드 시그니처만 접근 가능하므로 HTTP 정보(userId, URI 등)는 RequestContextHolder를 통해 획득
Filter/인증 단계의 request attribute 재사용

유저 정보

Long userId = (Long) request.getAttribute("userId");

request attribute 에서 userId 가져옴

메타 데이터 정보

요청 시각 : LocalDateTime.now()
요청 URI : request.getRequestURI()

RequestBody

AOP는 @RequestBody 어노테이션을 직접 인식 X -> args 배열 순회하며 RequestBody 찾음
String,Number, AuthUser(인증 객체)제외 후 dto.request에 속한 객체가 RequestBody라고 판단
DTO를 JSON으로 직렬화해 로그 기록 추가

OnlyAdmin

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface OnlyAdmin {
}

어드민 전용 API를 식별하기 위한 커스텀 메서드 어노테이션
AOP Pointcut 기준
METHOD 레벨에서만 사용

CommentAdminController / UserAdminController

@OnlyAdmin
@DeleteMapping("/admin/comments/{commentId}")

@OnlyAdmin
@PatchMapping("/admin/users/{userId}")

@OnlyAdmin 적용

AccessCheckAOP 전체 코드

@Aspect
@Component
@Slf4j
public class AccessCheckAOP {
    @Pointcut("@annotation(org.example.expert.config.OnlyAdmin)")
    public void adminApi() {}

    @Around("adminApi()")
    public Object accessLogToInfo(ProceedingJoinPoint joinPoint) throws Throwable {
        StringBuilder logInfo = new StringBuilder();

        //유저 ID, 요청 URI 정보는 시그니처에 없어서 RequestContextHolder의 getRequestAttributes 메서드를 사용
        HttpServletRequest request = ((ServletRequestAttributes) RequestContextHolder.getRequestAttributes()).getRequest();

        Long userId = (Long) request.getAttribute("userId");
        logInfo.append(String.format("유저 ID : %s/ ",userId));

        LocalDateTime accessTime = LocalDateTime.now();
        logInfo.append(String.format("요청 시각: %s/ ",accessTime));

        logInfo.append(String.format("요청 URI : %s/ ",request.getRequestURI()));

        //request body 가져오기
        Object[] args = joinPoint.getArgs();
        for (Object arg : args) {
            if (arg == null) continue;
            if (arg instanceof String || arg instanceof Number) continue;
            if (arg instanceof AuthUser) continue;
            //이 시점에는 @RequestBody 확률 올라감
            String packageName = arg.getClass().getPackageName();
            if (packageName.contains("dto.request")) {
                logInfo.append(String.format("Request Body : %s",getRequestBody(arg)));
            }
        }
        log.info(logInfo.toString());
        // 실제 메서드 실행 -> Filter에서 doFilter 와 비슷함.
        return joinPoint.proceed();
    }

    public String getRequestBody(Object arg) throws IOException {
        //JSON으로 직력화해서 로그로 남김
        ObjectMapper objectMapper = new ObjectMapper();
        return objectMapper.writeValueAsString(arg);
    }

}

[Spring] AOP 정리

limitation01 — Wed, 3 Dec 2025 08:58:41 +0900

AOP란

AOP (Aspect Oriented Programming) 는 여러 곳에 반복되는 공통 관심사를 비즈니스 로직과 분리해서
한 곳에서 관리하기 위한 프로그래밍 기법

AOP가 왜 필요할까?

예를들어 기획자가 개발자님 성능 측정을 위해 모든 메서드에 시작 시간과 종료 시간을 남기는 기능 추가해주세요

라고 요청을 했을 때

public void save() {
    log.info("start");
    // 비즈니스 로직
    log.info("end");
}

다음과 같은 코드가 모든 서비스 메서드마다 중복되면

로깅, 트랜잭션, 권한 체크 코드가 모든 메서드에 흩어짐
수정하려면 전체 코드를 다 건드려야 함
비즈니스 로직이 더러워짐

AOP 도입 후에는

시간 측정은 AOP가 알아서 처리한다.

AOP는 어디에 적용되는걸까?

AOP는 HTTP 요청 흐름과는 무관하다.

Service 메서드
Repository 메서드
Scheduler
내부 메서드 호출

AOP 용어

용어	설명
Join Point	메서드 실행 시점
Pointcut	어떤 메서드(Join Point)에 끼어들지 정하는 조건
Advice	끼어들어서 실행할 실제 AOP 로직 @Before @After @Around
Aspect	공통 관심사를 담는 모듈(로깅, 트랜잭션, 권한 체크)

AOP 어노테이션

@Before : 메서드 실행 전
@After : 메서드 종료 후
@AfterReturning : 정상 종료 후
@AfterThrowing : 예외 발생 시
@Around : 실행 전·후 모두 제어

실습- 실행 시간 측정 AOP 만들기

package org.example.nbcam_addvanced_1.common.aspect;

import lombok.extern.slf4j.Slf4j;
import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.springframework.stereotype.Component;

@Aspect
@Component
@Slf4j
public class TimeCheckAop {

    @Around("execution(* org.example.nbcam_addvanced_1.user.service..*(..))")
    public Object executionTime(ProceedingJoinPoint joinPoint) throws Throwable {

        long start = System.currentTimeMillis();

        Object result = joinPoint.proceed(); // 실제 메서드 실행 -> Filter에서 doFilter 와 비슷함.

        long end = System.currentTimeMillis();
        log.info("[AOP] {} 실행됨 in {}ms" , joinPoint.getSignature() , end - start);

        return result;
    }
}

[Spring] Interceptor 정리

limitation01 — Tue, 2 Dec 2025 00:23:10 +0900

Interceptor란

Spring MVC에서 컨트롤러(Controller) 호출 전·후에 요청을 가로채서 공통 로직을 수행하는 도구

JWT 기반 인증이 끝난 후, 인증된 사용자 정보(SecurityContext)를 활용해

자원 소유자 검증
역할 기반 접근 제어
API 사용 제한
등의 부가 검증 수행

Spring MVC 요청 흐름

[사용자 요청]
    ↓
[JwtFilter]
    ↓
[SecurityContextHolder에 인증 저장]
    ↓
[Interceptor]
    ↓
[인증 사용자 검증]
    ↓
[Controller]

Interceptor가 왜 필요할까?

예를 들어 컨트롤러 마다 다음과 같은 코드가 반복된다면

if (!isLogin(request)) {
    throw new UnauthorizedException();
}

컨트롤러 코드가 지저분해짐
인증/권한 로직이 비즈니스 로직과 섞임
수정 시 모든 컨트롤러를 건드려야 함

공통 로직을 컨트롤러 밖으로 빼기 위해 Interceptor를 사용

HandlerInterceptor

Filter와 마찬가지로 구현되어있는 HandlerInterceptor를 활용

메서드	설명
preHandle	컨트롤러 실행 전에 동작 ( false 반환 시 흐름 중단 가능)
postHandle	컨트롤러 실행 후, 뷰 렌더링 전
afterCompletion	응답 완료 후, 예외 처리 포함

preHandle

@Override
public boolean preHandle(HttpServletRequest request,
                         HttpServletResponse response,
                         Object handler) {
    // 인증, 권한 체크
    return true;
}

역할

컨트롤러에 들어가기 전에 실행
인증 / 권한 / 로그인 여부 검사

리턴 값

true → 요청 계속 진행 (Controller 실행)
false → 요청 중단 (Controller 실행 X)

구현 예시 - 인증 체크

@Component
public class AuthInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request,
                             HttpServletResponse response,
                             Object handler) {

        Long userId = (Long) request.getAttribute("userId");

        if (userId == null) {
            throw new UnauthorizedException("로그인이 필요합니다.");
        }

        return true;
    }
}

Interceptor 등록 방법

Interceptor는 자동으로 적용되지 않는다.
WebMvcConfigurer에 명시적으로 등록해야 한다.

@Configuration
@RequiredArgsConstructor
public class WebMvcConfig implements WebMvcConfigurer {

    private final AuthInterceptor authInterceptor;

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(authInterceptor)
                .addPathPatterns("/api/**")
                .excludePathPatterns("/api/auth/**");
    }
}

addPathPatterns : 적용할 URL
excludePathPatterns : 제외할 URL
interceptor는 URL 기준으로 동작

그래서 언제 사용해야할까?

로그인 / 인증 / 권한 체크
특정 URL 접근 제어
요청 로깅 (URI, IP)