많이 도움되는 세미나였고 좋은 발표 감사드립니다. :)
질문이 하나 있는데 자신감 결여로 현장에서는 따로 물어보질 못했어요;;;; 저 같은 경우 Spring/Mybatis를 사용 중인데 일단 Spring->Spring Boot로 변경보다는 Mybatis -> JPA 도입을 먼저 시도해 보고자 생각 중입니다. (시도 후 전파에 대한 확신이 들어야 되기 전까진 엎을 수가 없는 상태이구요.) 이럴 경우 안전하게 기존 SQL매퍼와 ORM을 동시에 적용하면서 차근차근 바꿔나가면서 적용을 하고 싶은데 이런 사례는 별로 존재하질 않는거 같아요. 혹시 추천해 주실 만한 접근 방법이 있을지 조언을 부탁드려도 될까요?
P.S 마음 같아서는 갈아 엎고 다시 적용하고 싶지만 혼자서 다 뒤엎기엔 너무 멀리 와 있는 상태라 쉽지가 않네요... 휴... 아참 그리고 JPA 도입을 원하는 이유 중에 하나는 특정 DBMS 종속성 제거를 위해 어느정도 ANSI-SQL문법대로 적용은 했으나 발표에서 느낀바대로 다소 SQL에 의존적인 비즈니스 로직도 많이 존재하고 이를 변경할 때 사이드이펙트도 많이 존재하는 부담감을 느꼈기 때문입니다. JPA 도입 시 DBMS 종속성도 어느정도는 해결이 되겠죠?
2개의 의견 from SLiPP
@날아랏흰둥이
쉽지 않은 작업이 되겠네요. 저도 점진적으로 개선하는 것을 추천하고 싶습니다. 하지만 이와 관련해서는 MSA 발표도 그러했지만 하나의 도메인 모델을 JPA 분리하기 위해 여러 단계를 거치면서 분리할 수 밖에 없다고 봐요. 저도 이와 관련한 경험은 없는데 다음과 같은 단계로 진행할 수 있지 않을까요?
위와 같은 과정을 반복할 수 밖에 없으리라 생각됩니다. 이 시간이 길고 지루하겠지만 이 방법이 정석이라고 생각합니다. 이 작업은 한, 두명이 아니라 모든 팀원이 참여해야 가능할테고요.
어느 정도가 아니라 상당 부분 해결된다고 생각해요. 다양한 DB를 지원해야 되는 Solution이라면 당연히 JPA로 갈 것을 추천드립니다. 만약 DB별로 다르게 갈 수 밖에 없는 부분은 interface로 만들고 각 DB에 대한 구현체를 만든 후 Spring의 Profile 기능 활용해서 각 DB별로 동작하도록 할 수 있다고 생각합니다.
@자바지기 답변 감사합니다. 부디 많은 삽질 끝에 성공의 결과를 얻고 전파까지 성공할 수 있었으면 좋겠습니다 :) 무리해서 변화를 다 수용하기엔 긴 설득과 타협의 과정이 필요할거 같아서 일단 혼자 희생(?)을 좀 하면서 좋은 점을 슬며시 인지시켜야 겠습니다 ㅎㅎ 다음 스터디 세미나도 기대하겠습니다.
의견을 남기기 위해서는 SLiPP 계정이 필요합니다.
안심하세요! 회원가입/로그인 후에도 작성하시던 내용은 안전하게 보존됩니다.
SLiPP 계정으로 로그인하세요.
또는, SNS 계정으로 로그인하세요.