개발자들이 ORM을 쓰는 이유와 DBA가 ORM을 싫어하는 이유

 

개발자들이 ORM을 쓰는 이유

오랜만에 글을 적네요. 요즘은 포스팅 할 때 무얼 주제로 해야 하나 고민이 좀 많습니다. 너무 초보적인 내용 정리는 안 하려고 하다 보니 , 그렇다고 너무 어려운 주제는 조회수가 안 나오고… 인생은 그런 것이죠.

요즘은  DB운영을 하면서 참 빠르게 업계가 변해가고 있다는 걸 느낍니다. 인프라 엔지니어들은 온프레미스에서 클라우드로 옮겨가면서 DevOps나 SRE라는 포지션으로 바뀌면서 업무에서 역할이 많이 변했습니다. 인프라 영역에서 하드웨어를 다루는 부분이 축소되고 개발이 영역이 추가 되었죠.

그럼 DBA들은 어떻게 변화에 따라가야 할까? 고민이 많은 요즘입니다.

IT 기술뿐만 아니라 소비 트렌드 자체가 변했습니다. 사람들이 많은 것들에 너무 쉽게 질리고, 금방 새로운 것을 찾습니다. 그러다 보니 서비스를 제공하는 업체들도 빠르게 유행을 따라가려고 노력하고 있고, 고객을 잃지 않기 위해 계속 새로운 시도를 하고 있습니다.

그러다 보니 중요한 건 개발의 속도가 무엇 보다 중요해 졌습니다. DevOps라고 불리는 엔지니어들은 빠르고 안정적인 개발 환경을 제공해주는 것이 무엇보다 중요해졌고, 개발자들은 서비스를 위해 좀 더 빠르게 개발을 해야 하는 상황에 놓여 있습니다.

그러다 보니 ORM은 개발자들에 있어 개발 속도와 유지 보수의 편리성을 목적으로 많이 사용하는 것 중 하나입니다.

ORM(Object-Relational Mapping)은 개발자가 원시 SQL 쿼리를 작성하는 대신 객체 지향 프로그래밍(OOP) 개념을 사용하여 데이터베이스와 상호 작용할 수 있도록 하는 프로그래밍 기술입니다. 데이터베이스 테이블을 클래스에 매핑하고 행을 프로그래밍 언어의 개체에 매핑합니다.

ORM을 사용하면 다음과 같은 장점을 얻을 수 있습니다.

  1. 추상화: ORM은 더 높은 수준의 추상화를 제공하여 데이터베이스와의 상호 작용을 단순화합니다. 이를 통해 개발자는 SQL 쿼리 대신 개체 및 클래스로 작업할 수 있으므로 코드를 더 읽기 쉽고 유지 관리할 수 있습니다.
  2. 보일러 플레이트 코드 감소: ORM은 대부분의 일반적인 데이터베이스 작업을 ORM 시스템이 처리하기 때문에 반복적인 보일러 플레이트 코드를 줄일 수 있습니다.
  3. 이식성: ORM 시스템은 일반적으로 여러 데이터베이스 시스템을 지원하므로 개발자는 코드 변경을 최소화하면서 서로 다른 데이터베이스 간에 전환을 쉽게 할 수 있습니다. 이를 통해 다양한 환경이나 요구 사항에 맞게 응용 프로그램을 더 쉽게 조정할 수 있습니다.
  4. 생산성: ORM을 사용하면 개발자는 복잡한 SQL 쿼리를 작성하는 대신 애플리케이션의 비즈니스 논리에 집중할 수 있습니다. 이는 생산성 향상으로 이어질 수 있습니다.
  5. 유지 관리성: ORM은 객체 지향 설계 패턴 사용을 촉진하여 더 잘 구조화되고 유지 관리하기 쉬운 코드베이스를 만듭니다.

이런 이유들로 개발자들은 ORM을 사용하는 경우가 많습니다. 특히 최근 트랜드는 높은 생산성과 MSA를 위한 다양한 DB를 사용하기 위한 이식성도 중요해 졌기 때문에 ORM을 사용하는 것이 일반적이기도 합니다.

 

DBA가 ORM을 싫어하는 이유

비록 모든 데이터베이스 관리자(DBA)들이 ORM(객체 관계 매핑)을 싫어하지는 않지만, 일부 DBA들이 ORM에 대해 강한 반감을 가지고 있는 몇 가지 이유가 있습니다. 다음은 DBA들이 ORM을 좋아하지 않는 주요 이유입니다.

  1. 성능 문제: ORM에서 생성된 쿼리는 때때로 신중하게 작성된 SQL 쿼리보다 효율이 떨어질 수 있습니다. 이로 인해 리소스 사용량이 증가하고 응답 시간이 느려져 데이터베이스의 성능에 부정적인 영향을 미칠 수 있습니다.
  2. 제어력 상실: ORM은 데이터베이스 작업의 많은 세부 사항을 추상화하여 데이터베이스에 대한 세밀한 제어력을 상실하게 합니다. DBA들은 쿼리 최적화와 데이터베이스의 성능 관련 측면에 대한 제어력이 덜한 것처럼 느낄 수 있습니다.
  3. 복잡성: ORM은 응용 프로그램에 추가적인 복잡성을 도입하여, DBA가 데이터베이스 상호 작용과 관련된 문제를 이해하고 문제를 해결하는 것이 어렵게 만듭니다. 이로 인해 데이터베이스 문제를 해결하는 데 필요한 시간과 노력이 증가할 수 있습니다.
  4. 데이터베이스 기능 지원 제한: ORM은 특정 데이터베이스 시스템의 모든 기능을 완전히 지원하지 않을 수 있어 DBA가 이러한 제한을 해결하거나 원시 SQL 쿼리(Raw Query)를 작성해야 할 수 있습니다. 이는 DBA가 선택한 데이터베이스 시스템의 기능을 완전히 활용하는 데 방해가 될 수 있습니다.
  5. 적절하지 않은 데이터베이스 설계: ORM은 개발자들이 객체 지향 설계에 집중하도록 유도하기 때문에, 때로는 최적의 데이터베이스 설계 하는데 있어 희생을 감수 할 수 있습니다. 이로 인해 최적화되지 않은 데이터베이스 스키마와 데이터 모델이 발생할 수 있고, 성능 및 확장성 문제를 초래할 수 있습니다.
  6. 데이터베이스 문제 숨기기: ORM은 데이터베이스 작업의 복잡성을 많이 추상화하기 때문에 개발자들은 잠재적인 문제나 모범 사례에 대해 인식하지 못할 수 있습니다. 이로 인해 숨겨진 문제와 성능 병목 현상이 발생하며, 이러한 문제는 응용 프로그램이 높은 부하가 발생하는 시기 혹은 서비스를 확장할 시기가 되서야 문제가 나타날 수 있습니다.

 

정말 개발자들이 좋아 하고 DBA가 싫어 하는 이유가 명확하게 ORM의 장단점에서 갈립니다. 특히 DB에 대해서 전체을 통제하지 못한다는 문제와 SQL의 성능 이슈 시 튜닝 쿼리의 적용 여부를 두고 조율이 어려운 경우가 있는 것이 가장 큰 이유입니다.

ORM이 개발에 있어 많은 이점을 제공한다는 것은 누구나 알고 있을 겁니다.

따라서 급변하는 트렌드를 따라가기 위해 빠른 개발 속도가 보장되어야 하는 시점에, 생산성 향상, 코드 유지 관리성 및 이식성과 같은 이점을 포기 할 수 없기 때문에 ORM사용은 선택이 아닌 필수가 될 수도 있습니다. 하지만 ORM를 사용하는데 있어 이를 성공적으로 구현하기 위한 핵심은 그 장점을 활용하고 제한 사항을 해결하는 것 사이에서 적절한 균형을 찾는 것이죠.

개발자와 DBA가 긴밀하게 협력하여 응용 프로그램 코드와 데이터베이스 시스템이 성능과 확장성을 위해 최적화 할 수 있는 방안을 찾는 것이 중요합니다.

결국 일을 잘한다는 건  커뮤니케이션을 잘하고, 타협점을 잘 찾고, 빠르고 안정적으로 성능을 끌어낼 수 있는 합의점을 찾는 것이 아닐까? 싶네요.

소셜 미디어로 공유하기

You may also like...

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다