인프런 커뮤니티 질문&답변

안녕하세요. 한현진님

하나씩 답변 드릴께요.

1. 여러 Repository를 만들어야 하나요? DIP 위배는 괜찮을까요?

결론부터 말씀드리면, 일반적으로 각기 다른 데이터 접근 기술을 사용한다고 해서 MyBatisOrderRepo, JPAOrderRepo처럼 기술 이름을딴 별도의 Repository 인터페이스를 여러 개 만드는 것은 권장하지 않습니다. 이는 DIP(Dependency Inversion Principle, 의존관계 역전 원칙)를 위배할 가능성이 높고, 서비스 계층이 구체적인 구현 기술에 의존하게 만들기 때문입니다.

바람직한 접근 방식:

1. 도메인 중심의 Repository 인터페이스 정의:

   • OrderRepository라는 인터페이스를 만듭니다. 이 인터페이스는 주문(Order) 도메인과 관련된 데이터 접근 기능을 추상화합니다. (예: save(Order order), findById(Long id), findByCustomerName(String name))

   • 서비스 계층은 이 OrderRepository 인터페이스에만 의존합니다.

2. 구현체에서 기술 선택:

   • OrderRepository의 구현체인 OrderRepositoryImpl (또는 Spring Data JPA를 사용한다면 프록시 객체) 내부에서 필요에 따라 JPA, MyBatis, JdbcTemplate 등을 조합하여 사용할 수 있습니다.

   • 예를 들어, 대부분의 CRUD는 Spring Data JPA로 구현하고, 특정 복잡한 통계 쿼리나 벌크 연산은 MyBatis나 JdbcTemplate을 OrderRepositoryImpl 내부의 private 메서드나 별도의 컴포넌트로 만들어 호출하는 방식입니다.

DIP를 지키는 것:

• 이렇게 하면 서비스 계층은 OrderRepository라는 추상화된 인터페이스에만 의존하게 됩니다. 실제 내부 구현에서 JPA를 쓰든 MyBatis를 쓰든 서비스 계층은 알 필요가 없습니다. 이것이 DIP를 지키는 방법입니다.

• 각 repo별로 인터페이스 만드는 것이 이상하게 느껴지신 이유는 아마도 기술별로 인터페이스를 만드려고 생각하셨기 때문일 겁니다. 대신 도메인 작업별로 인터페이스를 정의하고, 그 구현체 안에서 적절한 기술을 조합하는 것이 좋습니다.

만약, 특정 기술에 매우 특화된 기능들이 많고, 도메인적으로 분리된 관심사라면 (예: 매우 복잡한 통계 전용 리포지토리), 별도의 인터페이스와 구현체를 고려할 수는 있지만, 일반적인 CRUD와 일부 복잡 쿼리가 섞인 경우라면 하나의 통합된 Repository 인터페이스 접근법이 더 유지보수하기 좋습니다.

2. JPA 사용 후 MyBatis/JdbcTemplate 사용 시 flush()와 EntityManager 의존성

JPA를 사용한 후 동일 트랜잭션 내에서 MyBatis나 JdbcTemplate으로 DB를 직접 조회할 때 데이터 정합성 문제가 발생할 수 있습니다. JPA의 영속성 컨텍스트에 있는 변경사항이 아직 DB에 반영(flush)되지 않았기 때문입니다.

따라서 JPA 작업 후 MyBatis/JdbcTemplate을 사용하기 전에는 명시적으로 entityManager.flush()를 호출해주는 것이 안전합니다.

Service Layer에서 EntityManager 의존:

• entityManager.flush()를 호출하기 위해 서비스 계층에서 EntityManager를 직접 의존하는 것이 괜찮은지에 대한 고민은 타당합니다.

• 일반적으로 서비스 계층은 비즈니스 로직에 집중하고, 데이터 접근 기술에 대한 직접적인 의존은 최소화하는 것이 좋습니다. @Transactional 어노테이션을 통해 선언적으로 트랜잭션을 관리하는 것도 이러한 관심사 분리를 위한 것입니다.

해결 방안 및 고려사항:

1. Repository 계층에서 flush 호출:

   • 첫번째 방법은 flush가 필요한 작업을 Repository 메서드 내에서 처리하는 것입니다.

   • 예를 들어, OrderRepository의 특정 메서드가 내부적으로 JPA로 कुछ 변경하고, 이어서 JdbcTemplate으로 뭔가를 조회해야 한다면, 해당 Repository 메서드 내부에서 entityManager.flush()를 호출할 수 있습니다. 이 경우 서비스 계층은 EntityManager를 몰라도 됩니다.

      

2. Service 계층에서 EntityManager 주입 (필요악으로 간주):

   • 만약 서비스 계층에서 JPA 작업과 비 JPA 작업의 흐름을 직접 제어해야 하고, 그 사이에 flush가 반드시 필요하다면, 서비스 계층에 EntityManager를 주입받아 사용하는 것도 현실적인 선택일 수 있습니다.

      

3. @Transactional의 동작 이해:

   • 기본적으로 @Transactional 메서드가 종료될 때 (커밋 시점) flush가 발생합니다.

   • 또한, JPA는 트랜잭션 내에서 JPQL 쿼리가 실행되기 전에 영속성 컨텍스트에 있는 변경사항 중 해당 쿼리 결과에 영향을 줄 수 있는 것들을 flush하는 메커니즘(auto-flush)을 가지고 있습니다.

   • 하지만, MyBatis나 JdbcTemplate은 JPA의 영속성 컨텍스트를 직접 인지하지 못하므로, 이들을 사용한 SQL 실행 전에는 JPA가 자동으로 flush를 해주지 않습니다. 그래서 명시적인 flush()가 필요한 것입니다.

결론적으로, 가능하면 Repository 내부에서 flush를 관리하는 것이 좋지만, 서비스 로직 흐름상 명시적인 flush 호출이 서비스 계층에서 필요하다면 EntityManager를 주입받아 사용하는 것도 데이터 정합성을 위해서는 고려할 수 있는 방법입니다.

더 나은 대안으로는 플러시용 AOP를 하나 만드는 것입니다. 그리고 특정 리포지토리에 해당 애노테이션을 도입할 수 있습니다.

참고로 실무에서는 이 부분이 그렇게 문제가 되지 않는 경우가 많습니다. 왜냐하면 같은 테이블의 데이터를 JPA로 변경하고, 그 다음에 같은 테이블의 데이터를 SQL을 사용해서 조회하는 상황에 이 문제가 발생합니다. 그런데 실무에서 이런 경우가 자주 발생하지는 않습니다.

3. JPA를 이용한 DB 처리 방식은 효율적인가요?

JPA의 효율성은 "상황에 따라 다르다" 가 가장 정확한 답변입니다.

효율적인 측면:

1. 개발 생산성 및 유지보수성: SQL 중심이 아닌 객체 중심으로 개발할 수 있게 해주고, 반복적인 CRUD 코드를 크게 줄여줍니다. 이는 개발 시간 단축과 유지보수 용이성으로 이어져 전체적인 "효율"을 높입니다.

2. 1차 캐시 (영속성 컨텍스트 내 캐시): 동일 트랜잭션 내에서 같은 엔티티를 여러 번 조회할 경우, DB를 다시 조회하지 않고 1차 캐시에서 가져오므로 성능 이점이 있습니다.

3. 쓰기 지연 (Write-behind) 및 변경 감지 (Dirty checking):

   • 엔티티의 변경사항을 즉시 DB에 반영하는 것이 아니라, 트랜잭션 커밋 시점에 모아서 한 번에 UPDATE 쿼리를 생성하여 실행합니다.

   • 이를 통해 불필요한 UPDATE 쿼리를 줄일 수 있고, 최적화된 순서로 SQL을 실행할 수도 있습니다. (예: 여러 엔티티의 여러 필드가 변경되어도 엔티티당 하나의 UPDATE문만 생성)

4. Lazy Loading (지연 로딩): 연관된 엔티티를 실제 사용할 때 조회하여 불필요한 데이터 로딩을 피할 수 있습니다.

5. 객체지향적인 쿼리 (JPQL, Criteria): 특정 DB 벤더에 종속되지 않는 쿼리를 작성할 수 있으며, 동적 쿼리 생성에도 유리합니다.

비효율적일 수 있는 측면 (주의점):

1. N+1 문제: 연관관계 매핑 시 fetch 전략을 잘못 설정하면 (특히 EAGER 로딩 남발 또는 JPQL에서 적절한 fetch join 미사용 시) 의도치 않게 많은 추가 쿼리가 발생하여 성능 저하를 유발합니다.

2. 단순 UPDATE의 경우:

   • 말씀하신 것처럼, 단순히 특정 필드 하나만 업데이트하기 위해 find()로 엔티티를 조회(SELECT)하고, setXXX()로 변경 후 커밋 시점에 UPDATE 쿼리가 나가는 것은 순수 SQL UPDATE문 하나보다 비효율적일 수 있습니다.

   • 대안: 벌크 연산을 사용할 수 있습니다.

3. 복잡한 쿼리: 매우 복잡하고 통계적인 쿼리는 JPQL이나 Criteria로 작성하기 어렵거나, 생성된 SQL이 비효율적일 수 있습니다. 이런 경우 Native Query, MyBatis, JdbcTemplate 등을 사용하는 것이 더 나을 수 있습니다.

4. ORM 자체의 오버헤드: SQL을 직접 사용하는 것보다 ORM 프레임워크를 거치면서 발생하는 약간의 오버헤드는 존재합니다.

결론:

• JPA는 개발 생산성과 유지보수성, 그리고 객체지향적인 데이터 처리에 큰 강점이 있습니다. 많은 일반적인 웹 애플리케이션 시나리오에서 충분히 효율적입니다.

• 그러나 JPA의 내부 동작 원리(영속성 컨텍스트, fetch 전략 등)를 잘 이해하고 사용해야 하며, 때로는 성능 최적화를 위해 JPQL 벌크 연산이나 다른 기술(MyBatis, JdbcTemplate)을 함께 사용하는 유연성이 필요합니다.

• 단순히 "JPA가 SELECT 후 UPDATE를 하니 비효율적이다"라고 단정하기보다는, 어떤 상황에 어떤 기능을 사용하는 것이 적합한지 이해하고 활용하는 것이 중요합니다. 대부분의 경우, JPA가 제공하는 이점이 이러한 오버헤드를 상쇄하고도 남습니다.

감사합니다.

안녕하세요, 인프런 AI 인턴입니다. 한현진님. 질문해주신 내용은 JPA와 다양한 DB 접근 기술을 함께 사용할 때의 구조와 효율성에 관한 부분이네요. 이해를 돕기 위해 관련된 답변들을 정리해드리겠습니다.

1. 여러 Repository 사용 시 구조 결정:

   • 다양한 기술을 사용할 때, 각각의 기술에 맞는 Repository를 만들 수 있습니다. 각 기술에 특화된 Repository를 만든다면, 구조가 명확해지고 유지보수성이 높아지지만, DIP(Dependency Inversion Principle)를 고려하는 것이 중요합니다.
     
   • 각 Repository 별로 인터페이스를 만들어 의존성을 주입받도록 설계하면 유연성을 가지면서 DIP를 준수할 수 있습니다. 서비스 계층에서는 인터페이스에 의존하도록 하고, 실제 구현은 필요에 따라 결정합니다.
     
   • 관련 질문: 여러방식의 데이터접근기술을 같이 사용하는 경우에서는 다양한 DB 기술 사용 시의 구조 제안을 확인할 수 있습니다.
     

2. JPA와 다른 DB 접근 기술 혼용 사용:

   • JPA를 사용하면서, MyBatis나 JdbcTemplate 등을 사용할 경우, 데이터 정합성을 유지하려면 JPA의 영속성 컨텍스트 상태에 유의해야 합니다. JPA에서의 변경사항이 DB에 확정되지 않은 경우, 다른 기술을 사용할 때 문제가 발생할 수 있습니다.
     
   • 이 경우, EntityManager.flush()를 사용하여 변경 사항을 DB에 반영한 후 다른 DB 접근 기술을 사용하도록 설계하는 것이 일반적입니다.
     
   • 트랜잭션 관리 및 영속성 컨텍스트 관리가 필요한 경우, 서비스 레이어에 EntityManager를 의존하는 것은 적절한 접근 방식입니다.
     
   • 관련 질문: 스프링 데이터 JPA와 JPQL을 함께 사용할 경우 Repository에 대해 질문 드립니다.
     

3. JPA의 효율성:

   • JPA는 영속성 컨텍스트를 통해 객체 상태를 관리하고, 변경 사항을 추적하여 최종 쿼리를 정리하여 실행해주는 장점이 있습니다. 이는 비즈니스 로직의 복잡성을 줄이고, 코드 가독성과 유지보수성을 높이는 데 기여합니다.
     
   • 그러나 단순한 업데이트의 경우 두 번의 쿼리(finding 및 updating)를 수행하므로 과도한 추가 작업이 있을 수 있습니다. 이 경우, JPA의 비용을 고려하여 필요에 따라 최적화된 다른 DB 기술을 혼합하여 사용할 수 있습니다.
     
   • 관련 질문: 순수 JPA 기반 리포지토리와 스프링 데이터 기반 리포지토리 비교
     

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.