spring data jpa + hibernate 구조가 정말 삽집을 줄일 수 있는지는 내가 장담을 못하겠다. 아무리 좋은 도구를 사용하더라도 지속적으로 개선하고 관심을 가지지 않으면 삽질을 하는 것은 똑같고, 사용하는 도구를 제대로 사용하지 못하면 그 또한 삽질의 연속이기 때문이겠지. 요구사항에 따른 나의 생각을 이야기하면 다음과 같다.

1. DBMS에 종속적이지 않도록 코딩 할것 (ex: oracle, db2, mySql, cubrid 등) => 데이터베이스 변경에 따른 소스 코드 변경 비용이 적은 것은 사실이다. 하지만 100% 변경을 하지 않도록 만들려면 데이터베이스에 특화된 ORM 기능을 쓰면 안된다. 하지만 성능 이슈 때문에 DB 특화된 기능을 쓰는 상황이 발생하는데 이 경우에 대한 관리는 일정 부분 발생한다. ORM 쓴다고 DB가 변경될 경우 소스 코드 변경을 하지 않기는 쉽지 않다. 단지 최소할 가능성이 높다고 본다. 이런 부분은 인터페이스를 통해 철저하게 분리할 필요가 있다.

2. 유지보수가 용이하도록 시스템을 구현 할것 => 이 부분은 1번 요구사항과 관련이 높다고 생각한다. ORM을 제대로 사용해서 구축해 놓는다면 DB 변경에 따른 소스 코드 변경이 최소화되기 때문에 유지보수 비용은 확실히 줄어들 가능성이 있다. 특히 DB 스키마나 쿼리에서 변경이 발생할 경우 SQL 쿼리를 직접 사용하는 경우 중복된 부분이 많기 때문에 이 부분에 대한 변경 및 테스트하는데 많은 비용이 발생할 가능성이 높다고 생각한다. 이런 측면으로만 본다면 유지보수 비용은 일정 부분은 줄일 수 있다고 본다. 하지만 ORM 사용하더라도 중복 코드를 제거하려는 노력과 지속적인 리팩토링 작업이 수반되지 않는다면 유지보수 비용이 많이 발생하는 것은 똑같다고 본다. ORM을 사용하느냐 사용하지 않느냐보다 지속적인 중복 코드 제거와 리팩토링을 통해 clean code를 만들려는 노력이 있느냐 없느냐가 더 중요한 요소라 생각한다.
3. 변경 사항에 대한 개발 기간을 단축(젠장;)할 수 있을것 => 이 내용 또한 변경 사항을 데이터베이스 변경에 따른 부분을 좁혀서 생각했을 때는 충분히 단축할 수 있다고 생각한다. 개발 기간이라는 것이 개발 비용도 있지만 테스트 비용도 무시할 수 없기 때문에 변경이 많은 경우에는 자동화된 테스트 코드가 있다면 개발 기간을 단축하는데 많은 도움을 받을 수 있겠지. 나의 경우 데이터베이스 변경을 제외한 다른 부분(스키마 변경이나 요구사항 변경)에 있어서도 의미가 있다고 생각하는데 이 부분은 직접 경험해 보지 않고서는 확신을 심어주기가 힘들 듯하다.

Spring Data Jpa, Hibernate에 익숙하지 않은 개발자들이 있다면 그들을 설득할 수 있을만한 타당성이 있을까요? => 이 부분은 개발 팀의 문화라고 생각한다. 새로운 것을 도입하고 적용해볼 용의가 있는가? 새로운 것을 도입했을 때 같이 적극적으로 사용하고 문제점을 찾아 개선할 의지가 있는가? 새로운 기술을 도입하면 기존에 발생하지 않던 문제가 발생하는 것은 당연할텐데 이 문제들을 같이 극복할 자세가 되어 있느냐? 기존에는 반대 논리를 설득하기 위해 상당히 과장된 방식으로 설득했는데 내 개인적인 생각으로는 솔직하게 이야기하는 것이 좋지 않을까 생각한다. "이 기술을 도입하면 이런 이런 부분은 좋다. 하지만 초기에 학습 비용이 많이 발생하고, 우리가 예상하지 못한 문제가 발생할 것이다. 하지만 일정 시간이 지나 익숙한 단계에 도달하면 더 큰 효과를 발휘할 수 있다."라고 말하는 것이 더 성공할 가능성이 높다고 본다. 그리고 ORM은 내부에 전문가가 없을 경우 실패할 가능성이 높다. 따라서 초반의 기반 작업이나 일정 수준까지는 ORM에 경험이 있는 사람의 도움을 받는 것이 더 좋다라는 생각이다. ORM에 경험이 없어 개발자들이 삽질하는데 보내는 시간을 생각한다면 전문가의 도움을 받는 것이 비용적인 측면에서도 절감할 수 있는 길이라 생각한다.

@자바지기 // 하긴 세상에 만병통치약이 어디있겠습니까...

ORM이라는 녀석이 과연 많은 학습비용을 지불하고서라도 습득할만한 가치가 있는건지...

경험해보신 분들의 생각이 궁금했습니다.

지금도 충분히 잘 해나가고 있는데, 왜 고생을 사서하냐? 라는 위에 계신분들을 설득하기란 쉽지않군요 ㅠㅠ

제 경험으로 봤을 때는 ORM을 사용하는 것이 테스트,유지보수,개발생산성 모든 면에서 압도적으로 유리합니다. 많은 학습비용을 지불해서 배운 보람을 확실히 느끼실것이라 믿습니다. (저는 Hibernate부터 시작해서 현재 팀에서 재성님이 세팅하신 JPA2/SpringData-JPA까지 7년째 ORM을 사용하고 있습니다)

문제는 ORM을 제대로 모르는 상태에서 도입하면 오히려 피본다라는 점입니다.

도입을 원하시는 본인께서 먼저 ORM을(JPA2를) 잘 이해하고 사용하고 계신지부터 점검하는게 좋습니다. 그리고서 새로운 기능이 추가 되거나 했을 때 혹은 전혀 다른 DB를 다시 구축하기 시작했을 때 해당 부분에 ORM을 적용해가면서 리더 역할을 해주시면 될 것 입니다.

자기 스스로도 제대로 이해 못하고 있는 것을 어디서 좋다는 소리만 듣고 섣불리 도입하면, 나중에 문제 생겼을 때 해결도 안되고 욕만 바가지로 먹고 원복될 가능성이 매우 높고, JPA/Hibernate의 학습 코스트로 봤을 때 어설프게 덤비면 거의 그렇게 됩니다.

경험적인 관점에서 봤을 때...

삽질을 유도하는 기술은 없습니다. 삽질하는 사람이 있는거죠. 느린 언어는 없습니다. 느린 코드를 만드는 개발자가 있는거죠.

그 부분에 맞춰서, 해당 기술이 지향하는 방향으로 만들면, 대부분의 경우에 큰 문제가 없습니다. 문제가 있다면, 지향점이 다른 프로젝트에 지향점이 다른 기술을 섞었겠죠.

이 질문과 관련한 접근 방식이 여러 가지 있을텐데 현재 솔루션 개발의 요구사항과 인적 구성에 따라 달라질 듯하다.

기존 솔루션을 가능한 빠른 시점에 최신 기술로 변경하고자 한다면..(아마도 윗 선에서는 이 부분을 가장 바랄테지) 이 같은 요구사항이 강하다면 spring + mybatis로 가는 것이 좋겠다. 만약 기존 솔루션이 있기 때문에 여유 시간을 가지고 학습해 가면서 새로운 기술을 적용할 여지가 있다면 ORM으로 접근하는 것이 장기적으로는 더 좋겠다.

인적 구성에서 앞에서도 이야기했지만 ORM에 대한 이해가 있고, 주도적으로 ORM을 이끌어줄 개발자가 있다면 ORM 선택도 나쁘지 않다고 생각한다. 하지만 그런 개발자가 없다면 몇 번 시도한 후에 ORM은 역시 아직 멀었다면서 다시 myBatis로 돌아갈 가능성이 크기 때문에 아예 시도하지 않는 것이 좋겠다. 단, ORM을 주도할 개발자가 없더라도 같이하는 개발자들이 새로운 기술을 도입하고 문제가 발생할 경우 같이 해결해 나갈 의지가 있다면 ORM으로 접근하는 것도 좋겠다.

개인적인 생각으로는 현재 요구사항으로 봤을 때 ORM을 적용하는 것이 기술적으로는 가장 좋은 해결책이라고 본다. 특히 다양한 DB를 지원해야 하는 솔루션이기 때문에 더욱더... 하지만 기술적인 관점으로만 접근할 수 없는 것이 우리의 현실이기 때문에 이 부분은 윗 분들이나 주변 동료들과 솔직하게 터놓고 한번 이야기해 보는 것이 좋을 듯하다. 이 솔루션을 앞으로 얼마나 더 가져갈 계획인지 모르겠지만 시간이 지나면 지날수록 ORM을 적용했을 때(물론 잘 사용한다는 가정하에서...) 얻는 효과가 크다고 판단된다. 이를 정량화해서 제시하라고 한다면 나도 못하겠다. 정량화해서 제시하라고 하면 spring + mybatis로 접근했을 때도 그 효과를 측정해야 한다고 생각한다. 아니면 일정 시간을 투자해서 spring + mybatis 구조와 spring + jpa(hibernate)에 대한 장,단점을 비교 분석하는 시간을 가지는 것도 좋을 듯하다. 좋은 선택이 있기를..

많은 분들의 조언 감사드립니다. 다시 한번 시간을 가지고 천천히 생각할 기회가 되겠네요.

앞으로는 현재 솔루션화 하는 부분은 시간을 가지고 차근차근 접근해 가려고 합니다.

그리고 말씀하신대로, 리더의 고집이나 아집이 아닌 모두 공감하는 형태의 기술을 적용하여 타당성을 기초로 수행해 가려 합니다. (오너나 스폰서는 배제하고, 실제 개발에 참여할 팀원들과 같이 만들거 가고 싶으니까요...)

그리고 제대로 적용해보지 않고 무조건 비난하기 보다는, 실수하는 스텝이더라도 하나하나 고쳐가며 완성해 나가려 합니다 ^^

앞으로 많은 도움 부탁드리겠습니다 ^^

철지난 주제지만 썰을 풀어 봅니다. 윗글에 케니님의 "느린 언어는 없습니다. 느린 코드를 만드는 개발자가 있는거죠."

사실 느린 코드를 만드는 개발자가 있지만, 그 개발자를 느리게 만드는건 느린 환경에 적응해 버려서 아닌가하네요. 사람을 탈락 시키거나 노력을 하게 만들거나 하는 환경이 필요한것 같아요.

2번정도의 JPA 프로젝트를 했지만, 정말 팀의 의지가 없으면 안됩니다.(당연하죠?) 첫번째 프로젝트는 SQL 삽질을 할빠에 JPA를 배워서 하는게 훨빠르겠다는 판단으로 골랐지만, 팀원들이 잘 따라오지 못해서 절반만 성공한듯 해요. 그다음에 이직을 한 관계로 끝은 그냥 저냥 끝난듯.

새로운 팀에서는 저보다 훨 잘하는 사람이 많아서 당연히 JPA로 넘어갔습니다.

아주 쾌적하고 윤택한 환경입니다. JPA를 못받아들이는 팀이라면 팀을 떠나세요. 다른 팀도 그렇다면 회사를 떠나세요. 이상끝!

이런 주제가 나오면 늘 하는 말이지만 JPA나 다른 ORM 자체가 중요한게 아닙니다. 정말 중요한 건 객체지형 분석 설계(OOAD)와 도메인 모델이죠. 꼭 객체지향이 아니라 데이터 구조체를 사용한 모델링이라도 모든 SW 설계의 근본 원칙인 DRY 원칙을 지킬 수만 있다면 어떤 모델링 기법도 상관 없습니다. 그리고 그런 방식으로 개발한다면 자연스럽게 ORM(또는 그 유사한 것)을 찾게 되실 겁니다.

그런 의미에서 위에 소내기님이 말씀하신 팀이나 회사를 옮기라는 얘기는 정말 중요한 얘기입니다.

닭이 먼저냐 달걀이 먼저냐의 문제일 수도 있는데요..

개인적으로는 고민하지 말고 써라!입니다. 신규 솔루션이잖아요. 무서울꺼 있나요? 쓰세요. 쓰면서 ORM이네 Spring data-jpa네 객체설계네 뭐네 고민해 보는거죠.(아 물론 선행 공부나 기타 든든한 쉴드정도는 구비해 두셔야..콜록.)

안써보면 백날 저하늘의 뜬구름이잖아요. 발주사에서 입금받아야 생명유지할 수 있는 2개월 짜리 프로젝트도 아닌듯한데..

라고 제3자 입장에서 기술적인 부분제외하고 댓글달아 봅니다. 제 3자.!

@eclipse4j 제 3자는 뭔가요. ㅋㅋ 지금 시점에서는 방금 말씀하신 것 처럼 유명한 몇몇 ORM을 닥치고 쓰라고 해도 될 정도로 ORM 기술이 성숙했고 검증 절차를 거쳤기 때문에 문제가 없을 수 있습니다. 하지만 제가 처음 ORM을 접하고 시도했던 2005년 언저리에서는 정말 많은 문제가 있었고 고통스러웠어요.

그러니 신규 솔루션이기 때문에 고민 말고 쓰라는 말은 조금 위험한 말 같습니다. ^^

myBatis를 쓰면서 시간을 많이 투자했던 부분을 줄일수 있을꺼라 생각하기 때문에 꼭 공부를 하려합니다. 공부하기전 항상 그 기술에 대해서 찾아보고 공부를 하는데 제가 궁금했던 부분이 다 해결되는 질문과 답변이였던것 같습니다. 고맙습니다.