ORM - ORM 기본 이해하기

안녕하세요.

Hynn 입니다.

 

이번 포스팅에서는 ORM(Object Relational Mapping) 에 대한 기본사항에 대해서 알아보도록 하겠습니다.

ORM 은 MVC Pattern 과도 관계를 가지고 있는 친구이기 때문에, 이에 대해서도 같이 묶어 설명해보도록 하겠습니다.

 

==============

1. ORM 기본 사항 알아보기

2. ORM 장점 및 단점

==============

1. ORM 기본 사항 알아보기

ORM(Object Relational Mapping) 은 아래의 사진으로 한번에 정리가 가능합니다.

기존의 DBMS 와 통신하는 것이 Query 문이라면, 이 ORM 은 이 Query 를 대체해서 사용하는 친구라고 보셔도 무방합니다.

그림상으로 표현하면 아래와 같습니다.

 

Query vs ORM

즉, ORM 은 Object 를 RDBMS, 관계형 데이터베이스와 매핑을 해주는 도구입니다.

즉 ORM 이 없는 상태라면, 데이터를 DB에 삽입하기위해 "INSERT INTO~" query 구문이 실행되도록 작성하거나, 삭제할 경우 "DELETE", 업데이트를 위한 "UPDATE" Query 문을 하나씩 작성했다면, ORM 은 이러한 Query 문을 생략하게 끔 도와주는 도구라고 생각하시면 되겠습니다.

 

즉 Query 문을 직관적인 method 로 구현하고, 사용자가 Query 문을 잘 사용하지 못하더라도, ORM 을 활용하면 구현이 가능합니다.

하지만 이 ORM은 바로 한가지의 전제를 두고 사용이 되어야 합니다.

"OOP", 즉 객체지향 프로그래밍 관점으로 접근해야 합니다.

 

일반적으로 RDBMS는 Table , OOP 는 Class 개념으로 접근하게 됩니다.

하지만 Object 와 Relational 은 불일치가 조금씩 발생할 수 밖에 없습니다. 

즉 이 ORM 을 사용하게 되면, RDBMS 접근을 OOP 관점에서 접근이 가능하게 됩니다. 즉, ORM 을 사용함으로서 Object 간의 관계를 기반하여 SQL Query 문을 사용함으로써 개선할 수 있습니다.

또한 SQL 문을 직접 작성하지 않아도 Object 를 사용해서 간접적으로 RDBMS 를 다룰 수 있습니다. 

 

2. ORM 장점 및 단점

1)ORM의 장점

ORM은, 작성자 본인의 입장에서는 단점보다는 장점이 더 많은 Tool 이라고 생각이 됩니다.

몇가지 정리해보도록 하겠습니다.

 

• 직관적인 코드 작성
• 생산성 향상
• 재사용 및 유지보수 편의성

Query 문을 보면, 적지 않은 구문의 길이를 나타냅니다. 하지만 ORM 은 이를 "method" 화를 시켜서 사용하기 때문에, 작성이나, 사용측면에서 매우 직관적이라고 할 수 있습니다. 

그만큼의 시간, Code Read time 만큼이나, 다른 것에 집중할 수 있으니, 이 점 하나만으로도 직관성+생산성을 모두 잡은 것이라고 할 수 있습니다.

 

SQL Query 문은 절차에 따라 순서에 맞게 접근이 되야하지만, ORM 은 객체지향적인 접근으로 보다 직관적인 사용이 가능합니다.

그리고 ORM 은 특정 DB에 종속성이 있지 않습니다.

즉 MySQL 에 맞는 ORM 은 A, MongoDB 에 맞는 ORM은 "C" 가 아니라, ORM은 어느 DB에서도 독립적으로 동작할 수 있습니다. 그러므로 이를 잘 사용한다면 Design Pattern, 즉 위에서 잠시 언급한 "MVC Pattern" 에서는 Object 와 Model 간의 관계를 보다 손쉽게 정의가 가능합니다.

 

그리고 독립적 작성이니만큼, Object를 재활용 할 수도 있습니다.

이를 통해 OOP 측면에서는 작성자 입장에서는 Object 자체에 집중할 수 있기 때문에, 효율성 측면에서도 장점이 있다고 할 수 있습니다.

 

2)ORM의 단점

사실 이제 막 배우는 단계이기때문에, ORM에 관련된 여러 글을 읽어보고, 이론적인 접근으로 단점을 구술하는 것이라,

제 글이 답이 아닐수 있습니다.

 

1. 설계 단계에서부터 공을 들여야 합니다.

만약 설계단계와 구현단계에서 구현이 어긋날 경우, 일관성이 무너질 뿐 아니라 코드 전체에서 문제가 발생할 수 도 있습니다.

예를들어, 기존의 SQL Query 구문으로 구현된 System 일 경우, ORM 으로 변경할 경우, 완전히 새롭게 설계하는 것 만큼 기존의 Query 구문에 연결된 것들을 Object 로 바꾸는 과정만 해도 생산성저하는 둘째치고, 리스크가 적지 않을 것입니다.

 

2. 단점이라고 보기 어려울수도 있지만, System 을 객체지향적 관점으로 올바르게 보지 못할 경우, Persistence, 즉 영속성의 대한 개념 접근이 이루어지지 않으면 ORM 사용은 쉽지 않은 사용이 될 수 있습니다. 영속성의 대한 개념을 간단하게 정리하면 "데이터를 생성한 Application 이 종료되어도 데이터가 유지되는 특성" 입니다. 즉 Cache 나 Session, Cookie 같은 것이 아니라, DB에 영구히 저장되는 과정이라고 할 수 있습니다.

 

3. 속도적인 문제도 발생할 수 있습니다. 구현자체는 되었더라도, 올바르지 않게 구현된 경우, 속도저하의 문제도 발생할 수 있습니다. 

 

단점의 경우, 제가 깊은 지식을 가지지 않았다 보니, 깊게 설명을 드릴 수는 없지만, 해외에 비해서 한국은 ORM 사용에 대해서 다소 회의적인 게시글 및 토론이 많았습니다.

정답이라는게 존재할 수는 없지만, SQL / ORM 모두 기초적 지식은 있어야 한다고 생각됩니다.

다만 제 개인적인 생각으로는, DB를 사용해 통계/전망/리서치 등의 분야에서는 ORM에 비해 SQL 이 더 나을테고, 그렇지 않은 대부분의 분야에서는 ORM이 더 낫지 않을까 하는 사견이 있습니다.

 

 

사용법의 경우, Sequelize 를 가지고 기초적인 사용법을 별도의 포스팅으로 작성할 예정입니다.

다음 포스팅에서 뵙겠습니다.

 

감사합니다.