ORM ORm Orm omg...

 

현대의 개발에 필수 요소는 아마 ORM일 것이다.

 

ORM, Object Relational Mapping.

 

이름 그래도 객체 관계형 맵핑을 지원하는 모든 라이브러리를 ORM이라고 한다.

 

객체 관계란 무엇인가?

 

객체간의 관계, 즉, 1:1, 1:N 등의 객체간 관계를 의미한다.

 

Database의 테이블간 1:1, 1:N의 관계와 동일하다.

 

그리고 가장 중요한 요소가 있는데, ORM이라고 불릴려면 프로그램밍 객체가 직접적으로 SQL로 번역되어야 한다.

 

우리가 흔히 아는 Dapper, Mybatis는 ORM이 아니라 객체 맵퍼다. 즉, 객체간 관계 상태나 프로그램밍을 통한 직접적 SQL 번역 작업이 포함되지 않는 라이브러리는 맵퍼로 칭한다.

 

대부분의 ORM, 즉, Entity Framework, Hiberate, JPA는 모두 아래와 같은 절차를 거친다.

 

1. 작성된 ORM 쿼리 표현식을 해석한다.

2. 해석된 표현식 Tree를 쿼리로 변경한다.

3. 해석된 쿼리는 DB에 전송한다.

4. 전송된 쿼리를 DB에서 실행한다.

5. 조회 쿼리라면 결과를 반환해야 하는 정보를 List-Dictionary형태로 반환한다.

6. 선언된 객체 정보에 맵핑한다.

 

자, 이번에는 직접 쿼리를 작성하는 경우를 생각해 보자. 일반적인 경우는 DataReader를 사용한다면 아래와 같을 것이다.

 

1. 선언된 쿼리 Command를 DB에 전송한다.

2. 전송된 쿼리를 DB에서 실행한다.

3. 실행된 결과를 List-Dictionary 형태로 반환한다.

 

단순히 비교해 봐도 ORM은 2~3단계의 과정이 더 필요하다.

따라서 필연적으로 ORM이 Raw Sql을 사용하는 것에 비해 더 많은 리소스를 요구하는 것은 당연하다.

 

그런데, 현대에 대부분의 개발은 ORM을 지향해야 한다고 이야기 한다.

왜 그런가?

 

그건 현재 시대의 개발이 에자일 원칙과 TDD에 따른 매우 빠른 개발 과정과 테스트를 요구하기 때문이다.

 

현재의 개발은 과거 80~90년대의 개발 구성요소가 필요한 것이 아니다.

비즈니스는 매우 빠르게 변화하고 고객의 니즈는 매우 변덕스럽다.

자본의 경우는 어떠한가? 아무리 돈이 많은 사업가라도 결과물이 보이지 않는 제품에 1,2년을 투자할 미친 사람은 없을 것이다.

 

따라서, 현재의 개발자에게 요구되는 능력은 최적화와 성능에 대한 요구 사항이 아니다.

 

빨리 개발되어야 하고 6개월 또는 1년 이내에 어떻게든 결과물을 만들어야 하는 것이다.

 

그리고 그 부분을 돕기 위해 ORM이라는 것이 있는 것이다.

 

필자의 경험으로 ORM을 사용할 때와 사용하지 않을 때의 개발 시간은 적어도 8시간의 차이가 난다고 생각한다.

 

ORM을 사용하는 순간 Database는 작업대상이 아니며 모든 요구사항을 프로그래밍 레벨에서 처리할 수 있기 때문이다.

 

극적인 생산성 향상이라고 볼 수 있다.

 

하지만, 불행하게도 ORM은 만능이 아니다.

 

ORM을 사용하게 되는 순간 Database Native 기능을 포기하게 되고 Table에 필요한 사항들을 누락하게 될 수 있다. 또한 복잡한 시나리오의 개발이 진행될 때 ORM으로 작성하기 어려운 경우도 발생한다.

그리고 DBA들은 ORM을 매우 싫어하는데 이는 Raw 쿼리를 프로그래밍 레벨에서 직접 볼 수 있는 것이 아닌 프로파일러로 확인해야 하는데 상대적으로 매우 귀찮은 일이다. 이 경우 로깅에 신경쓰지 않은 시스템이라면 반드시 양자간에 욕설이 난무할 수 있다.

 

자, 필자가 제안하는 것은 아래와 같다.

 

1. 처음 개발은 ORM으로 하라. 이것보다 더 빨리 개발할 수는 없다.

2. 프로덕션 레벨에 간다면 반드시 로깅에 신경써라.

3. 운영중에 DB의 속도 문제가 발생한다면 반드시 Index부터 확인하라.

4. 그래도 문제가 해결되지 않는다면 Raw Sql로 변경하고 사용할 수 있는 모든 성능 힌트를 사용하라.

 

모든 회사에 DBA가 있는 것도 아니고 성능 이슈가 발생할 정도의 시스템이라면 이미 어느 정도의 수익은 발생했을 것이다. 이러한 타이밍에 DBA를 영입할 수도 있겠고 외부 전문가에게 아웃 소싱을 할 수도 있다.

또한, 대부분의 유능한 개발자라면 자신이 ORM을 작성하는 순간부터 문제가 어떻게 발생할지 예측하고 있을 것이고 그에대비해 미리 Raw Sql을 작성해 놓을 수도 있겠다.

 

만약, 이러한 시기에 회사 또는 대표가 이러한 문제 해결 또는 인재 영입에 소극적이고 방치하는 조직이라면 뒷 일은 상상에 맡긴다.

 

마지막으로 ORM으로 개발하더라도 반드시 Raw Query에 대해서 공부해야 한다.

ORM은 만능이 아니며 성능에 대한 문제와 DB를 이해하기 위해서도 Database에 대한 학습도 반드시 필요하다.