단점에 대한 저의 생각을 추가해 보면 재미있겠네요. ㅋㅋ

• SQL로 할 수 있는 전부를 지원해주는건 아니라서 Native SQL로 작성해야 하는 경우가 많다.
  • 내 경험으로는 Native SQL로 작성하는 경우는 극히 드물다. Native SQL로 작성하는 경우가 많다면 객체 모델링을 잘못했거나 Hibernate를 최대한 활용하지 못하고 있다.
• 레퍼런스가 적다, 다양한 상황의 쿼리를 하이버네이트로 어떻게 적용해야 할지 감이 안옴
  • 국내 자료가 적은 것은 사실이다. 단, 해외 자료는 IBatis, MyBatis보다 Hibernate가 더 많지 않을까라는 생각이 든다. 그렇다고 실제 데이터가 있는 것은 아니다.
• 하면 할 수록 SQL은 정말 편리한 언어였구나라는 생각이 든다.
  • SQL은 편리한 언어, 좋은 언어 맞다. 하지만 매번 반복되는 SQL문을 구현하는 것은 상당히 짜증나는 작업이다. 또한 Spring JDBC, IBatis, MyBatis를 활용해 객체 지향적으로 구현하는데는 상당한 어려움이 있다.
• 데이터를 제대로 가져오나 테스트 해보려면 컴파일 시간을 기다려야합니다.
  • 이것은 개발 도구에서 SQL을 직접 실행해 결과를 확인해 보는 것을 의미하는 것으로 판단되네요. 의도하는 바가 맞는지 모르겠지만 Hibernate에서 자동으로 생성되는 SQL을 활용해 쿼리를 실행해 보는 방법도 있다. SQL을 작성하는 시간에 Junit 같은 도구로 실행한 후 자동 생성 쿼리 구할 수 있으리라 생각된다.
• 간단한 쿼리문의 경우 HQL의 파싱하는 시간이 쿼리해서 데이터 가져오는 시간보다 더 길다.
  • 간단한 쿼리문의 경우 HQL을 사용하는 경우는 거의 없다. 대부분의 경우 HQL을 사용하지 않아도 가능하다. HQL을 사용하는 경우는 당연히 복잡한 쿼리일 경우이다. 이 경우 HQL의 성능이 나쁠 수도 있다는 생각이 들지만 어느 정도의 비용 차이인지 모르겠다. 항상 성능상에서 이슈가 되는 극히 일부분에 해당될지는 미지수이다.
• 하이버네이트를 한다는 사람은 많다, 하지만 실제로 개발에 필요한 수준까지 써본 사람은 거의 없다.
  • 이건 국내 개발자에 한해서 인정한다. 해외의 경우 자바의 경우 Hibernate, 다른 언어의 경우는 프레임워크에 포함되어 있는 ORM 프레임워크를 사용하는 비율이 더 높다. 국내의 경우 기존의 익숙함, 새로운 프레임워크 학습에 대한 거부감, 기득권 등등의 이유 때문에 Hibernate를 도입하는데 한계가 있다. 경험이 부족하다고 해서 지금과 같이 중간에서 포기하다보면 ORM은 우리에게는 요원한 일이 될 수도 있겠다.

일단 지금까지 Hibernate(JPA 기반)를 상당 시간 사용해 본 개발자의 입장에서 정리해 봤어요. 위 내용은 제 개인적인 생각이라 틀린 부분이 있을 수도 있어요. 기존의 익숙함을 버리는 것은 힘든 듯 합니다. 하지만 처음부터 너무 부정적인 모습부터 보면 새로움에 익숙해 지기 힘든 만큼 긍정적인 부분을 찾으면서 학습하시기 바랍니다.