@Transactional.kt에 대한 효용성 질문

Question

강사님 안녕하세요. 코틀린을 자바처럼 쓴 제 자신을 혼내면서(?) 열심히 청강 중입니다.   강의에서 작성하신 Transactional.kt 코드를 보면 스프링의 TransactionTemplate을 활용한 명시적 트랜잭션 제어 방식과 큰 차이점이 없어 보입니다.   코틀린 래핑방식으로 사용했을때 어떤 장점이 있는걸까요? 제가 생각한 래핑 방식의 장점은 다음과 같습니다. 코드 스타일, 네이밍, optional 옵션 추가 등에서 약간 더 자유로움 예를 들어 여러 종류의 트랜잭션 처리 규칙(특정 로그, 메트릭, 롤백 조건 등)을 한곳 에 구현해서 공용유틸로 쓰기 좋고, 내부 구현을 추후 TransactionTemplate, PlatformTransactionManager 등 다양한 방식으로 손쉽게 변경 가능   트랜잭션 코드에 특별히 넣어야 할 커스텀 공통로직"이 없다면, 웬만하면 @Transactional / TransactionTemplate만으로 충분하다는 생각입니다.   정답은 없고 팀의 규칙마다 다를것 같아요. 강사님 팀에서는 어떤 방식으로 사용중이신가요?   강의 찍어주셔서 감사합니다앗~! (개인적인 사견인데 말씀하시는 중에 '죄송합니다'는 안하셔도 될것 같아요~!)

Hong · Answer

안녕하세요 좋은 질문 감사합니다! 또한 추가적으로 좋은 의견 주셔서 감사합니다!! @Transactional 어노테이션은 AOP의 대표적인 어노테이션으로 데이터의 일관성을 처리하는데에 있어서 처음과 끝을 담당합니다. 하지만 Spring에 익숙하신 분들은 아시겠지만 해당 Spring에서의 AOP에 대해서는 치명적인 단점이 있습니다. 1. 컴파일에서 에러 파악이 어렵다 문법적인 에러에 한해서 컴파일 및 빌드하는 과정에서 문제 파악이 어렵고 반드시 실행을 하고 확인해야 합니다.   사용하기 어렵다 어디까지나 저의 개인적인 의견이지만, 저는 대표적으로 @PointCut과 같은 어노테이션에 들어가는 Path를 지정하는것이 너무 보기 어렵고 분석하기 어렵더라고요   Self Invocation 아실만한 분들은 아시겠지만, Proxy 클래스가 자신을 호출하며 AOP가 동작하지 않는 부분입니다.   이런 문제들을 해결하고 싶었고, 처음과 끝에 특정 행위를 담당하고 내부적으로 익명함수를 전달받아 처리하는 형태를 고민하고 구현을 해보았습니다.   실제로 팀에서 사용하고 있는 형태기이는 해요 ㅎㅎ 해당 형태를 따르게 된다면 Self Invocation도 걱정할 필요가 없고, 문법적인 에러에 대해서도 큰 문제를 아직은 발견하지 못한 상황입니다!! 저 로직은 사실 카카오 다니시는 분이 도움을 조금 주셔서.. 구현한 형태입니다.   물론 Spring을 사용한다면, 팀마다 어느정도의 규칙을 두고 사용을 하겠지만, 함수형 프로그래밍의 장점을 세워서 Kotlin에서는 이러한 형태로 사용하면 좋지 않을까 싶습니다.   혹시 질문에 대해서 대답이 되었을까요?? 추가적인 질문 있으시다면 남겨주세요!! 감사합니다.