• Object-relational mapping

• Select 절을 항상 재활용 가능하다. ibatis 류를 사용할 경우 select 부분을 재활용하려고 where 절에 온갖 조건문을 남발하게 된다. 이 경우 where 조건에 잘못된 값이 들어와도 거르지 않고 실행되는 경우가 생겨서 자칫 큰 문제로 발전할 수 있다. 특히, update,delete 문에서 조건이 잘못 걸리면 대형사고로 이어진다.

Facebook spring 사용자모임에서 내가 쓴 ORM으로는 DB의 성능을 제대로 이끌어낼 수 없다는 얘기에 대한 나의 반론.

JPA가 Native SQL보다 성능이 안나온다고 하셔서 나름대로 반론을 적어봅니다. 즉, Native SQL로 쉽게 가능한 것들인데 ORM으로는 잘 안되는 것들에 대해서 제 나름의 생각을 정리해 보았습니다. 나름은 SQL 사용시의 주의점 같은 거라 봐도 될 듯합니다.

1. 힌트 대부분의 경우 index hint 를 줘야 하는 상황이 온다면 사실 DB 데이터 구조와 인덱스 설계에 문제가 있는게 보통입니다. 인덱스 힌트로 해결하려는 것은 좋지 않고 근본적으로 힌트없이 가능한 인덱스를 생성하고 데이터 구조를 잡는 것이 ORM 사용 여부와 상관없이 중요합니다. 힌트 남발은 index가 바뀌었을 때 힌트를 사용한 모든 쿼리를 찾아 고치지 않으면 곧바로 장애로 이어지는 치명적인 습관입니다.

2. Join 또 다른 것으로 불필요한 Join 남발 입니다. 먼저, ORM 사용한다고 Join 안되는거 아니고, 보통은 JPA가 명백히 관계가 맺어져 있는 상태여야 Join을 허락하는데, 이게 엔티티간 명백한 관계도 없는데 Join을 하는 경우는 ORM을 안 써서 코드 짤 때도 십중팔구는 나중에 유지보수성에 문제를 일으킵니다. 현재 제가 있는 회사도 별로 연관 관계도 없는 테이블들 간의 Join 남발로 도저히 SQL의 의미 파악이 힘들어지고 데이터량 증가로 DB 분리해야하는데 이걸 할 수 가 없어 Join 푸느라 엄청난 시간을 쏟아부었습니다.

정말 필요할 때만 정말 관계를 맺은 테이블들 끼리만 Join 해야 합니다. 특히 도메인 영역이 다른 테이블은 Join을 가능한 피하고 더 가능하다면 도메인이 다르면 DB 스키마 자체도 Join 불가능하게 분리하는게 좋습니다.

3. 복잡하고 로직이 들어간 쿼리 쿼리 복잡도 문제도 비슷합니다. SQL기반으로 일하시던 분들이 불필요하게 쿼리 그 자체에 로직을 넣어 버리는데 이 또한 유지보수성을 매우 떨어뜨립니다. 나중에 코드 분석하는 사람들은 코드만 보고 간단하네? 했다가 SQL보고는 기겁을 합니다. 그리고 이해가 잘 안되니 쿼리 한번 잘못 고쳤다가 큰 장애 일으킵니다. 로직은 SQL이 아니라 코드에 있을 때 훨씬 유지보수성이 높고 안전하게 변경하기 쉽습니다.

결론적으로 ORM으로 하기 힘든 행위들은 대부분 Native SQL로 물론 다 되지만 된다고 해서 해도 좋은 것들이 아니라는 것입니다.

제가 Native SQL을 안 좋아하는 이유 중의 하나는 소프트웨어의 복잡성을 증가시키는 매우 안 좋은 행위들을 너무 쉽게 양산해서 소프트웨어가 죽어가는 것을 부추길 수 있다는 점입니다.

그리고 최악의 경우에도 정 필요하면 그 부분만 Native SQL로 작성하는 것을 JPA도 잘 지원합니다. 절대로 Native SQL을 사용하지 말라는게 아니라, 위의 그 안 좋다는 행위들을 안하려고 최대한의 노력을 했음에도 어쩔 수 없을 때 충분히 JPA내에서 Native SQL을 사용하시면 됩니다.

ORM을 사용하던 말던 위 3가지는 최대한 주의해서 개발하는 것이 좋을 것 같습니다.