JPA OSIV(Open Session In View) - 현업에서는 어떻게 사용할까? 🤔

📌 OSIV란 무엇인가?

**OSIV(Open Session In View)**는 Spring Boot에서 기본적으로 활성화되어 있는 기능으로, HTTP 요청이 시작될 때부터 응답이 완료될 때까지 JPA 영속성 컨텍스트(EntityManager)를 열어두는 전략입니다.

OSIV의 동작 방식

# Spring Boot 기본 설정 (OSIV 활성화)
spring:
  jpa:
    open-in-view: true  # 기본값

// OSIV가 켜져있을 때의 동작
@GetMapping("/api/orders")
public List<OrderDto> getOrders() {
    List<Order> orders = orderService.findAll();
    
    // 🎯 여기서도 지연 로딩 가능! (OSIV 덕분)
    return orders.stream()
        .map(order -> new OrderDto(
            order.getId(),
            order.getMember().getName(),    // 지연 로딩 발생
            order.getOrderItems().size()    // 지연 로딩 발생
        ))
        .collect(toList());
}

🚨 OSIV의 문제점들

1. 커넥션 풀 낭비

@GetMapping("/api/orders")
public List<OrderDto> getOrders() {
    // 1. DB 커넥션 획득 (OSIV 시작)
    List<Order> orders = orderService.findAll();
    
    // 2. 외부 API 호출 (3초 소요) - 여전히 DB 커넥션 점유!
    for (Order order : orders) {
        paymentService.callExternalApi(order);  // 💥 문제!
    }
    
    // 3. DTO 변환 중에도 커넥션 점유
    return convertToDto(orders);
    // 4. 응답 완료 후에야 DB 커넥션 반환
}

문제: 실제 DB 작업은 1초인데, 전체 요청 처리 시간인 5초 동안 커넥션을 점유!

2. N+1 문제 은폐

// OSIV=true일 때 - 조용히 N+1 문제 발생
@GetMapping("/api/orders")
public List<OrderDto> getOrders() {
    List<Order> orders = orderRepository.findAll();  // 1번 쿼리
    
    return orders.stream()
        .map(order -> new OrderDto(
            order.getId(),
            order.getMember().getName(),    // 각 Order마다 Member 조회 (N번 쿼리)
            order.getOrderItems().size()    // 각 Order마다 OrderItems 조회 (N번 쿼리)
        ))
        .collect(toList());
}
// 총 1 + N + N = 2N+1 번의 쿼리 실행! 😱

3. 레이어 분리 원칙 위반

// Controller에서 엔티티의 지연 로딩 속성에 직접 접근
@GetMapping("/api/orders/{id}")
public OrderDetailDto getOrder(@PathVariable Long id) {
    Order order = orderService.findById(id);
    
    // 🚫 Controller에서 지연 로딩 - 레이어 분리 위반
    return OrderDetailDto.builder()
        .orderId(order.getId())
        .memberName(order.getMember().getName())
        .itemNames(order.getOrderItems().stream()
            .map(oi -> oi.getItem().getName())
            .collect(toList()))
        .build();
}

🌏 국내 vs 해외 현업 사용 현황

🇰🇷 국내 현업 트렌드

대용량 트래픽 서비스

# 네이버, 카카오, 쿠팡 등
spring:
  jpa:
    open-in-view: false  # 성능 우선

소/중규모 서비스

# 스타트업, 중소기업
spring:
  jpa:
    open-in-view: true   # 개발 편의성 우선

하이브리드 접근법

# application-api.yml (고객용 API)
spring:
  jpa:
    open-in-view: false

# application-admin.yml (관리자)
spring:
  jpa:
    open-in-view: true

🌍 해외 현업 트렌드

해외 개발 커뮤니티는 압도적으로 OSIV 반대 입장:

"Open Session in View is Evil" 📛

• 안티패턴으로 간주
• 프로덕션에서 절대 사용 금지
• 명시적 코드 > 편의성

Netflix, Amazon 등 글로벌 기업들

// 철저한 fetch 전략 사용
@Repository
public interface OrderRepository extends JpaRepository<Order, Long> {
    @Query("SELECT o FROM Order o " +
           "JOIN FETCH o.member " +
           "JOIN FETCH o.orderItems oi " +
           "JOIN FETCH oi.item")
    List<Order> findAllWithDetails();
}

💡 현업에서 권장하는 해결 방법들

1. Command와 Query 분리 (김영한님 추천)

// Command용 Service (핵심 비즈니스 로직)
@Service
@Transactional
public class OrderService {
    public Long createOrder(OrderCreateRequest request) {
        // 주문 생성 로직
        return order.getId();
    }
}

// Query용 Service (조회 전용)
@Service
@Transactional(readOnly = true)
public class OrderQueryService {
    public List<OrderDto> findOrdersWithDetails() {
        List<Order> orders = orderRepository.findAllWithMemberAndItems();
        return orders.stream()
            .map(this::convertToDto)
            .collect(toList());
    }
    
    private OrderDto convertToDto(Order order) {
        return OrderDto.builder()
            .orderId(order.getId())
            .memberName(order.getMember().getName())    // 이미 fetch join됨
            .itemCount(order.getOrderItems().size())    // 이미 fetch join됨
            .build();
    }
}

@RestController
public class OrderController {
    private final OrderService orderService;           // Command
    private final OrderQueryService orderQueryService; // Query
    
    @PostMapping("/api/orders")
    public ApiResponse<Long> createOrder(@RequestBody OrderCreateRequest request) {
        Long orderId = orderService.createOrder(request);
        return ApiResponse.success(orderId);
    }
    
    @GetMapping("/api/orders")
    public ApiResponse<List<OrderDto>> getOrders() {
        List<OrderDto> orders = orderQueryService.findOrdersWithDetails();
        return ApiResponse.success(orders);
    }
}

2. Repository에서 모든 연관관계 해결

@Repository
public interface OrderRepository extends JpaRepository<Order, Long> {
    
    // 필요한 연관관계를 미리 모두 fetch join
    @Query("SELECT DISTINCT o FROM Order o " +
           "JOIN FETCH o.member m " +
           "JOIN FETCH o.orderItems oi " +
           "JOIN FETCH oi.item i")
    List<Order> findAllWithMemberAndItems();
    
    // 특정 상태의 주문만 조회
    @Query("SELECT o FROM Order o " +
           "JOIN FETCH o.member " +
           "WHERE o.status = :status")
    List<Order> findByStatusWithMember(@Param("status") OrderStatus status);
    
    // 페이징과 함께 사용
    @Query(value = "SELECT DISTINCT o FROM Order o " +
                   "JOIN FETCH o.member",
           countQuery = "SELECT COUNT(o) FROM Order o")
    Page<Order> findAllWithMember(Pageable pageable);
}

3. QueryDSL 활용한 동적 쿼리

@Repository
public class OrderQueryRepository {
    
    private final JPAQueryFactory queryFactory;
    
    public List<OrderDto> findOrdersWithCondition(OrderSearchCondition condition) {
        return queryFactory
            .select(Projections.constructor(OrderDto.class,
                order.id,
                member.name,
                order.orderDate,
                order.status))
            .from(order)
            .join(order.member, member)
            .where(
                statusEq(condition.getStatus()),
                memberNameContains(condition.getMemberName())
            )
            .fetch();
    }
    
    private BooleanExpression statusEq(OrderStatus status) {
        return status != null ? order.status.eq(status) : null;
    }
    
    private BooleanExpression memberNameContains(String memberName) {
        return StringUtils.hasText(memberName) ? 
               member.name.contains(memberName) : null;
    }
}

⚖️ 선택 기준과 권장사항

📊 서비스 특성별 권장 설정

서비스 유형 OSIV 설정 이유 추가 고려사항

대용량 API	false	커넥션 풀 절약 필수	철저한 fetch 전략
Admin 페이지	true	개발 편의성, 낮은 트래픽	성능 모니터링
배치 작업	false	대량 데이터 처리	메모리 효율성
소규모 서비스	true	빠른 개발 속도	확장성 대비

🎯 새 프로젝트 권장사항

# 처음부터 OSIV=false로 시작 (권장)
spring:
  jpa:
    open-in-view: false
    show-sql: true  # 개발 중 쿼리 확인

장점:

• 성능 문제 조기 발견
• 명시적인 fetch 전략 강제
• 확장성 있는 구조 구축
• 레이어 분리 원칙 준수

🚨 OSIV 사용 시 주의사항

1. 성능 모니터링 필수

// 애플리케이션 시작 시 경고 로그 확인
// WARN: spring.jpa.open-in-view is enabled by default.
// Therefore, database queries may be performed during view rendering.

1. N+1 문제 적극적 탐지

# 개발 환경에서 쿼리 로깅
spring:
  jpa:
    show-sql: true
    properties:
      hibernate:
        format_sql: true
        use_sql_comments: true

1. 커넥션 풀 모니터링

// HikariCP 모니터링
@Component
public class DatabaseMonitor {
    
    @Autowired
    private HikariDataSource dataSource;
    
    @Scheduled(fixedRate = 30000)
    public void logConnectionPoolStatus() {
        HikariPoolMXBean poolBean = dataSource.getHikariPoolMXBean();
        log.info("Active connections: {}, Idle connections: {}, Total connections: {}",
            poolBean.getActiveConnections(),
            poolBean.getIdleConnections(),
            poolBean.getTotalConnections());
    }
}

🏆 결론

현업 트렌드 요약

• 국내: 실용주의적 접근 (상황에 따라 선택)
• 해외: 원칙주의적 접근 (OSIV 완전 금지)

최종 권장사항

1. 새 프로젝트: OSIV=false로 시작
2. 기존 프로젝트: 점진적 마이그레이션
3. 성능 중요: 무조건 OSIV=false
4. 개발 속도 중요: OSIV=true + 모니터링

핵심은 선택의 이유를 명확히 알고, 트레이드오프를 인지하는 것입니다!

성능과 확장성을 위해서는 다소 복잡하더라도 명시적인 fetch 전략을 사용하는 것이 장기적으로 더 안전한 선택이라는 것이 해외 개발 커뮤니티의 일반적인 의견입니다. 🚀