코드 리뷰 전문가 역할을 맡기는 프롬프트

주요 문제는 주문 수만큼 고객 조회가 반복되는 N+1 쿼리입니다.

for (Order o : orders) {
    customerRepository.findById(o.getCustomerId());
}

주문이 1,000개면 최소 1번의 주문 조회와 1,000번의 고객 조회가 발생할 수 있어 성능이 크게 저하됩니다.

개선 방향은 다음과 같습니다.

• Order와 Customer를 조인한 조회 사용
• 대량 데이터에 대한 페이지네이션 적용
• 필요한 컬럼만 조회하는 DTO projection 사용
• 조회 로직을 서비스 계층으로 이동
• 읽기 전용 트랜잭션 적용
• orElseThrow()의 예외를 명시적으로 처리

예를 들어 Spring Data JPA에서는 DTO projection을 사용할 수 있습니다.

public interface OrderRepository extends JpaRepository<Order, Long> {

    @Query("""
        select new com.example.api.OrderDto(
            o.id,
            c.name,
            o.total
        )
        from Order o
        join Customer c on c.id = o.customerId
        order by o.id desc
    """)
    Page<OrderDto> findOrderDtos(Pageable pageable);
}

서비스와 컨트롤러는 다음처럼 분리할 수 있습니다.

@Service
@RequiredArgsConstructor
@Transactional(readOnly = true)
public class OrderService {

    private final OrderRepository orderRepository;

    public Page<OrderDto> getOrders(Pageable pageable) {
        return orderRepository.findOrderDtos(pageable);
    }
}

@GetMapping("/orders")
public Page<OrderDto> getOrders(
        @PageableDefault(size = 50, sort = "id", direction = Sort.Direction.DESC)
        Pageable pageable
) {
    return orderService.getOrders(pageable);
}

추가로 확인할 사항입니다.

• findAll()은 주문이 많아질수록 메모리를 과도하게 사용할 수 있습니다.
• 엔티티 전체를 조회한 뒤 DTO로 변환하기보다 DB에서 필요한 값만 조회하는 편이 효율적입니다.
• orElseThrow()는 고객 데이터가 없을 때 기본 예외가 노출될 수 있으므로 도메인 예외와 적절한 HTTP 상태 코드로 변환하는 것이 좋습니다.
• customerId를 직접 보유하는 구조라면 조인 조건을 명확히 관리해야 합니다. 가능하다면 Order와 Customer의 JPA 연관관계 및 join fetch 또는 projection 사용을 검토할 수 있습니다.
• 인증·인가가 필요한 API라면 현재 코드만으로는 접근 제어가 보이지 않으므로 서비스 권한 검사를 별도로 확인해야 합니다.

가장 우선순위가 높은 개선은 findById() 반복을 제거하고, 페이지 단위의 조인 기반 DTO 조회로 변경하는 것입니다.