문제점
이전 프로젝트에서 트랜잭션 처리가 정상적으로 동작하지 않아 문제를 파악하던 중, 튜터님께 몇 가지 조언을 받은 후 문제를 파악해 보았고, 그 과정에서 중요한 두 가지 포인트를 알게 되었다
- Spring Legacy와 Spring Boot에서 @Transactional의 생성 방식 차이.
- MyBatis와 JPA를 혼용하는 상황에서 JpaTransactionManager가 제대로 작동하는지 확인.
이 두 가지를 중점적으로 확인하기 위해 시도한 방법들을 정리해보려고 한다.
시도해본 방법들
1. Proxy 객체 생성 확인
@Transactional이 정상적으로 작동하려면 프록시 객체가 생성되어야 한다. 프록시 객체의 생성 여부와 생성된 프록시의 종류에 따라 트랜잭션이 제대로 실행되는지 확인할 수 있다.
로그에서 확인한 결과, 현재 JDK 동적 프록시를 사용하고 있는 것으로 나타났다. Spring Legacy 환경에서는 인터페이스 기반으로 호출되지 않으면 트랜잭션이 적용되지 않을 수 있기 때문에, 프록시 객체가 정상적으로 생성되는지 확인하는 것이 중요하다.
2. JpaTransactionManager가 정상적으로 작동하는지 확인
MyBatis와 JPA를 혼용할 경우, JPA와 MyBatis의 트랜잭션 관리가 충돌할 수 있다. 특히, 지정된 **JpaTransactionManager**가 제대로 사용되고 있는지 확인해야 했다.
logback.xml에 콘솔 출력을 적용하여, JpaTransactionManager가 정상적으로 사용되는지 확인할 수 있었다. 이를 통해 JPA 트랜잭션 관리가 올바르게 적용되는지 모니터링할 수 있었다.
알게된 점.
1. Spring Legacy의 복잡성 문제
- Spring Legacy 환경에서 프로젝트를 구성하는 데 있어 독립적인 버전과 의존성 관리가 많아져 설정 관리가 어려웠다. 프로젝트 규모가 커지면서 설정 관리의 복잡성이 문제로 다가왔고, 이로 인해 트랜잭션 처리와 같은 기능이 예상대로 동작하지 않는 상황이 발생했다.
- 최근 MSA(마이크로서비스 아키텍처)를 배우면서, 모놀리식 아키텍처의 한계를 실감했고, MSA의 유연성과 분산 시스템이 좋은 대안이 될 수 있다는 점을 몸소 느끼게 되었다.
2. 완벽하지 못했던 체제 전환
- 프로젝트 기간이 끝난 후, 고도화 기간에 일부 MyBatis 코드를 JPA로 변경하고, 사용하지 않는 의존성을 제거하려고 했으나, 성능 최적화에 집중하다 보니 체제 전환을 소홀히 했다는 점을 깨달았다.
- 체제 전환 시, 모든 시스템이 제대로 작동할 수 있도록 세심한 검토와 조정이 필요했으나, 이를 간과하고 넘어간 부분이 있었다. 이 경험을 통해 체제 전환에서 중요한 점은 단순한 성능 최적화만큼이나 시스템 전반에 대한 검토가 필요하다는 점을 절실히 느꼈다.