ORM (r1)

객체 지향 프로그래밍 언어로 작성된 애플리케이션의 객체와 관계형 데이터베이스의 테이블 간의 불일치를 해소하는 것이 객체-관계 매핑의 핵심 목적이다. 관계형 데이터베이스는 데이터를 행과 열로 구성된 테이블에 저장하며, 테이블 간의 관계는 기본키와 외래키를 통해 정의된다. 반면, 객체 지향 프로그래밍에서는 데이터와 그 데이터를 처리하는 메서드를 하나의 단위로 묶은 객체를 사용하며, 객체 간의 관계는 상속, 합성, 참조 등을 통해 표현된다. 이처럼 근본적으로 다른 두 패러다임을 연결하기 위해 매핑이 필요하다.

객체-관계 매핑은 일반적으로 메타데이터를 활용하여 이루어진다. 개발자는 클래스와 데이터베이스 테이블, 클래스의 속성과 테이블의 컬럼, 객체 간의 연관 관계와 테이블 간의 조인 관계 등을 XML 설정 파일이나 어노테이션, 데코레이터 등의 형태로 명시적으로 정의한다. 예를 들어, '사용자'라는 클래스는 'users' 테이블에, 해당 클래스의 'id'와 'name' 속성은 테이블의 동일한 이름의 컬럼에 각각 매핑된다. 이러한 매핑 정보를 바탕으로 ORM 프레임워크는 객체의 생성, 조회, 수정, 삭제 작업을 적절한 SQL 문으로 변환하여 데이터베이스에 전달한다.

이 매핑 과정을 통해 개발자는 데이터베이스 스키마의 세부 사항을 크게 의식하지 않고, 익숙한 객체 지향적인 방식으로 비즈니스 로직을 작성할 수 있게 된다. 데이터베이스의 테이블은 애플리케이션에서는 객체로, 테이블의 행은 객체의 인스턴스로, 컬럼 값은 객체의 속성 값으로 자연스럽게 다루어진다. 이는 생산성을 높이고, 데이터 접근 코드의 일관성을 유지하며, 데이터베이스 벤더에 따른 차이를 추상화하는 데 기여한다.

영속성은 ORM의 핵심 개념 중 하나로, 프로그램이 종료되더라도 객체의 상태와 데이터가 사라지지 않고 데이터베이스에 저장되어 유지되는 특성을 의미한다. 이는 객체의 생명주기와 데이터의 저장 주기를 분리하는 중요한 개념이다. 애플리케이션 메모리에서 임시로 존재하는 객체를 영속성 컨텍스트라는 관리 영역에 등록함으로써, 해당 객체의 상태 변화를 추적하고 최종적으로 데이터베이스에 동기화하는 작업을 ORM이 담당한다.

영속성을 관리하는 주요 메커니즘은 영속성 컨텍스트와 더티 체킹이다. 영속성 컨텍스트는 현재 세션에서 관리되고 있는 영속 상태의 객체 집합을 말하며, ORM 프레임워크는 이 컨텍스트 내 객체들의 상태 변화를 감시한다. 더티 체킹은 이 컨텍스트에 있는 객체의 속성이 변경되면, 트랜잭션이 커밋되는 시점에 자동으로 변경 사항을 감지하여 해당하는 SQL 업데이트 문을 생성하고 실행하는 과정이다. 이를 통해 개발자는 반복적인 저장 로직을 직접 작성할 필요 없이, 자연스러운 객체 조작만으로 데이터베이스 조작을 완료할 수 있다.

영속성 상태의 객체는 일반적으로 데이터베이스의 레코드와 일대일로 매핑된다. 객체를 영속 상태로 만드는 일반적인 방법은 새로운 객체를 생성한 후 ORM의 save() 또는 persist() 같은 메서드를 호출하거나, 데이터베이스에서 조회해오는 것이다. 한 번 영속 상태가 된 객체는 트랜잭션이 종료되거나 명시적으로 분리되기 전까지 그 상태 변화가 관리된다. 이는 객체 지향 프로그래밍의 패러다임을 데이터 계층까지 확장시켜, 비즈니스 로직을 보다 객체 중심으로 설계하고 구현할 수 있게 하는 기반이 된다.

데이터베이스 추상화는 ORM의 핵심 목표 중 하나로, 개발자가 사용하는 특정 데이터베이스 관리 시스템에 종속되지 않고 데이터 접근 로직을 작성할 수 있게 해주는 기능이다. 이는 애플리케이션 코드와 데이터베이스 사이에 추상화 계층을 두어, 내부적으로 사용하는 SQL 구문이나 데이터 타입의 차이를 ORM이 자동으로 처리하도록 한다.

예를 들어, MySQL, PostgreSQL, SQLite 등 각기 다른 관계형 데이터베이스는 고유한 SQL 방언이나 기능을 가지고 있다. 데이터베이스 추상화가 없다면 개발자는 애플리케이션에서 사용하는 데이터베이스 종류가 바뀔 때마다 모든 SQL 쿼리를 수정해야 하는 번거로움이 있다. ORM은 이러한 차이를 흡수하여, 개발자는 동일한 객체 지향 코드를 작성하기만 하면 되고, ORM이 현재 연결된 데이터베이스에 맞는 최적의 SQL을 생성해준다.

이러한 추상화는 데이터베이스 마이그레이션을 용이하게 하며, 개발 초기에는 SQLite를 사용하다가 서비스 확장 시 PostgreSQL로 전환하는 것과 같은 유연한 아키텍처 구성을 가능하게 한다. 또한, 벤더 종속성을 줄여주어 소프트웨어의 이식성을 높이는 장점이 있다.

ORM의 핵심 기능 중 하나는 CRUD 자동화이다. CRUD는 데이터 처리의 기본이 되는 생성(Create), 읽기(Read), 갱신(Update), 삭제(Delete) 작업을 의미한다. ORM 프레임워크는 개발자가 이러한 기본적인 데이터베이스 연산을 수행하기 위해 반복적으로 SQL 문을 작성하는 번거로움을 덜어준다. 대신, 프로그래밍 언어의 객체를 생성, 수정, 조회, 삭제하는 간단한 메서드 호출만으로 데이터베이스에 해당 작업이 반영되도록 한다.

예를 들어, 새로운 사용자 정보를 데이터베이스에 저장(Create)하려면, 개발자는 해당 프로그래밍 언어의 클래스에 맞는 객체를 생성하고 필드에 값을 채운 후, ORM이 제공하는 save() 또는 persist()와 같은 메서드를 호출하면 된다. 그러면 ORM은 내부적으로 적절한 INSERT SQL 문을 생성하여 데이터베이스에 전달한다. 조회(Read)의 경우도 마찬가지로, findById()나 findAll() 같은 메서드를 사용하면 ORM이 SELECT 문을 만들어 결과를 객체 형태로 반환한다.

이러한 자동화는 개발 생산성을 크게 향상시킨다. 특히 애플리케이션의 비즈니스 로직을 구현하는 데 더 많은 시간을 집중할 수 있게 해주며, 데이터베이스 스키마가 변경되더라도 관련 객체와 메서드만 수정하면 되므로 유지보수가 용이해진다. 또한, ORM이 생성하는 파라미터화된 쿼리를 사용함으로써, 사용자 입력값을 SQL 문에 직접 연결하여 발생할 수 있는 SQL 인젝션 공격을 효과적으로 방지할 수 있다.

하므로, CRUD 자동화는 ORM이 제공하는 가장 기본적이면서도 실용적인 가치로, 객체 지향 패러다임과 관계형 데이터베이스 사이의 간극을 메우는 출발점이 된다.

관계 매핑은 객체-관계 매핑의 핵심 기능 중 하나로, 객체 지향 프로그래밍에서 사용하는 객체 간의 연관 관계(예: 일대일, 일대다, 다대다)를 관계형 데이터베이스의 테이블 간의 외래 키 관계로 변환하는 과정을 의미한다. ORM 프레임워크는 개발자가 객체 모델에 관계를 정의하면, 이를 기반으로 적절한 데이터베이스 스키마를 생성하거나 매핑하고, 관계를 통한 데이터 접근과 조작을 자동화한다.

주요 매핑 유형으로는 하나의 객체가 다른 하나의 객체를 소유하는 일대일(1:1) 관계, 하나의 객체가 여러 하위 객체를 컬렉션으로 가지는 일대다(1:N) 관계, 그리고 양쪽 객체 모두가 서로에 대한 컬렉션을 가지는 다대다(N:M) 관계가 있다. 예를 들어, 고객 객체와 주문 객체 사이에는 하나의 고객이 여러 주문을 가질 수 있는 일대다 관계가 성립하며, ORM은 이를 데이터베이스에서 고객 테이블의 기본 키를 주문 테이블이 외래 키로 참조하는 구조로 구현한다.

이러한 매핑은 객체 그래프 탐색을 가능하게 하여, 개발자가 복잡한 조인 쿼리를 직접 작성하지 않고도 customer.getOrders()와 같은 직관적인 코드로 관련 데이터를 조회할 수 있게 한다. 또한 지연 로딩이나 즉시 로딩 같은 패턴을 통해 관계된 데이터를 필요한 시점에 효율적으로 불러오는 전략을 제공하며, 캐시와 연동하여 성능을 최적화하는 데 기여한다.

ORM은 객체와 데이터베이스 간의 상호작용을 위해 두 가지 주요 방식을 제공한다. 하나는 객체의 메서드를 호출하는 것이고, 다른 하나는 전용 쿼리 언어를 사용하는 것이다. 복잡한 조회나 집계 연산이 필요할 때는 객체 메서드만으로는 한계가 있기 때문에, 대부분의 ORM은 강력한 쿼리 언어를 지원하여 이러한 문제를 해결한다.

가장 널리 알려진 ORM 쿼리 언어는 자바 JPA의 JPQL이다. JPQL은 데이터베이스 테이블이 아닌 엔티티 객체를 대상으로 쿼리를 작성하는 객체 지향 쿼리 언어다. 문법은 SQL과 유사하지만, 데이터베이스에 독립적으로 동작한다는 특징이 있다. 파이썬의 SQLAlchemy는 자체 표현 언어를 제공하며, 장고 ORM은 필드 조회를 위한 특별한 문법을 사용한다.

이러한 ORM 전용 쿼리 언어는 개발자가 네이티브 SQL을 직접 문자열로 작성할 때 발생할 수 있는 SQL 인젝션 보안 문제를 내부적으로 방지해준다. 또한, 특정 데이터베이스 관리 시스템의 고유 문법에 종속되지 않도록 함으로써, 애플리케이션의 데이터베이스 이식성을 높이는 데 기여한다. 그러나 매우 복잡하고 최적화가 중요한 쿼리의 경우, ORM 쿼리 언어로 표현하기 어렵거나 생성된 SQL의 성능이 떨어질 수 있어 네이티브 SQL을 사용해야 하는 경우도 있다.

ORM은 데이터베이스 작업의 핵심 요소인 트랜잭션 관리를 추상화하고 자동화하는 기능을 제공한다. 트랜잭션은 여러 데이터베이스 작업을 하나의 논리적 작업 단위로 묶어, 모든 작업이 성공하거나 실패하는 원자성을 보장하는 것을 말한다. ORM 프레임워크는 개발자가 객체를 조작하는 코드를 작성하면, 이를 적절한 트랜잭션 경계 내에서 실행되도록 관리한다.

대부분의 ORM은 명시적 트랜잭션 관리 방식을 지원한다. 개발자는 트랜잭션의 시작과 커밋(확정), 롤백(취소) 시점을 코드 상에서 직접 제어할 수 있다. 이 과정에서 ORM은 내부적으로 데이터베이스 커넥션을 관리하고, 설정된 격리 수준을 준수하며 작업을 수행한다. 또한, 선언적 트랜잭션 관리 방식을 지원하는 프레임워크도 있어, 애너테이션이나 데코레이터 같은 메타데이터를 통해 트랜잭션 동작을 정의할 수 있다.

ORM의 트랜잭션 관리 기능은 데이터의 정합성을 유지하는 데 필수적이다. 예를 들어, 계좌 이체와 같은 비즈니스 로직은 출금과 입금 두 작업이 반드시 함께 성공해야 한다. ORM은 이러한 작업들을 하나의 트랜잭션으로 묶어 처리함으로써, 중간에 오류가 발생할 경우 모든 변경 사항을 자동으로 롤백시켜 데이터베이스 상태를 일관되게 유지하도록 돕는다. 이는 ACID 속성을 준수하는 안전한 데이터 조작을 가능하게 하는 중요한 장점이다.

데이터베이스 마이그레이션은 애플리케이션의 데이터 모델이 변경됨에 따라, 이를 반영하기 위해 데이터베이스의 스키마를 체계적으로 관리하고 변경하는 과정을 자동화하는 기능이다. ORM은 이 과정을 지원하는 도구를 제공하여, 개발자가 데이터베이스의 테이블 구조를 코드로 정의하고, 그 변경 이력을 버전 관리할 수 있게 한다.

주요 동작 방식은 다음과 같다. 개발자는 ORM이 제공하는 마이그레이션 스크립트 생성 도구를 사용하여, 모델 클래스의 변경사항(예: 새로운 엔티티 추가, 필드 속성 수정)을 기반으로 SQL 변경문을 자동 생성하거나 직접 작성한다. 이 스크립트는 업그레이드(변경 적용)와 다운그레이드(변경 롤백)를 모두 포함하며, ORM의 마이그레이션 엔진이 이를 순차적으로 실행하여 데이터베이스 스키마를 목표 상태로 만든다.

이 기능은 협업과 지속적 통합 환경에서 특히 유용하다. 여러 개발자가 각자의 로컬 개발 환경에서 데이터 모델을 변경하고, 그 변경사항을 버전 관리 시스템을 통해 공유할 수 있다. 또한, 테스트 서버나 운영 서버에 애플리케이션을 배포할 때, 데이터베이스 스키마를 자동으로 최신 상태로 동기화할 수 있어 배포 과정의 안정성과 효율성을 높인다.

대표적인 ORM 프레임워크인 Django ORM의 makemigrations 및 migrate 명령어, Entity Framework의 Code First 마이그레이션, Alembic(SQLAlchemy용) 등이 데이터베이스 마이그레이션을 위한 강력한 도구를 제공한다. 이를 통해 데이터 무결성을 유지하면서 애플리케이션의 진화를 안전하게 지원한다.

ORM을 사용하는 주요 장점은 개발 생산성과 유지보수성을 크게 향상시킨다는 점이다. 가장 큰 이점은 개발자가 객체 지향 프로그래밍 언어의 문법과 사고방식 그대로 데이터베이스를 조작할 수 있게 해준다는 것이다. 이를 통해 비즈니스 로직을 구현하는 데 더 집중할 수 있으며, SQL 문법을 직접 작성하지 않아도 되어 코드가 더 직관적이고 이해하기 쉬워진다.

보안 측면에서도 ORM은 장점을 제공한다. ORM 프레임워크는 사용자 입력을 적절히 이스케이프하거나 파라미터화된 쿼리를 생성하여 데이터베이스에 전달함으로써, SQL 인젝션과 같은 일반적인 보안 취약점으로부터 애플리케이션을 보호한다. 개발자가 수동으로 보안 처리를 할 필요가 줄어들어 실수 가능성이 낮아진다.

또한 ORM은 데이터베이스 벤더 간의 차이를 추상화하여 이식성을 높여준다. 특정 데이터베이스 관리 시스템에 종속적인 SQL 문법을 사용하지 않고, ORM이 각 DBMS에 맞는 적절한 SQL로 변환해주기 때문에, 애플리케이션의 데이터베이스를 MySQL에서 PostgreSQL로 변경하는 것과 같은 작업이 상대적으로 용이해진다.

코드의 재사용성과 유지보수성도 개선된다. 엔티티나 도메인 모델과 같은 객체 정의를 중앙에서 관리하고, 이에 기반한 CRUD 작업을 자동으로 생성할 수 있어 반복적인 코드 작성을 줄여준다. 데이터베이스 스키마가 변경되면 관련 객체의 매핑 설정만 수정하면 되므로, 여러 곳에 흩어져 있는 SQL 문을 일일이 찾아 수정해야 하는 번거로움을 크게 덜 수 있다.

ORM은 개발 편의성을 크게 향상시키지만, 모든 상황에 적합한 만능 도구는 아니다. 특히 복잡한 데이터베이스 시스템이나 성능이 중요한 상황에서는 몇 가지 명확한 단점이 드러난다.

가장 큰 문제는 성능 오버헤드와 복잡한 쿼리 처리의 한계다. ORM이 생성하는 SQL 쿼리는 자동화 과정에서 종종 비효율적이거나 과도하게 복잡해질 수 있다. N+1 쿼리 문제가 대표적인 예로, 객체 그래프를 탐색할 때 예상치 못하게 많은 수의 쿼리가 발생하여 시스템 성능을 심각하게 저하시킨다. 또한 다중 테이블 조인이나 복잡한 집계 함수를 사용하는 고급 쿼리를 ORM의 추상화된 방법으로 표현하는 것은 매우 어렵거나, 결국 네이티브 SQL을 사용해야 하는 상황을 초래하기도 한다.

두 번째 단점은 학습 곡선과 추상화로 인한 제어력 상실이다. 개발자는 ORM 프레임워크 자체의 동작 방식을 깊이 이해해야 하며, 이는 새로운 학습 부담으로 작용한다. 더욱이 데이터베이스에 직접 접근하는 것이 아닌, ORM이라는 중간 계층을 통해 작업하기 때문에 발생하는 문제를 디버깅하기 어려울 수 있다. 프로시저나 특정 데이터베이스 관리 시스템의 고유 기능을 많이 사용하는 레거시 시스템에서는 ORM을 도입하거나 적용하는 것 자체가 현실적으로 불가능한 경우도 있다.

마지막으로, 지나친 추상화는 때로는 설계를 왜곡시킬 위험이 있다. 객체 지향의 상속 모델을 관계형 데이터베이스의 테이블 구조에 매핑하는 것은 선험적으로 어려운 문제다. 이를 해결하기 위해 ORM은 여러 전략을 제공하지만, 이 과정에서 데이터베이스 스키마가 비즈니스 도메인보다는 ORM의 기술적 요구사항에 맞춰 설계되는 역전 현상이 발생할 수 있다. 결과적으로 데이터 모델의 순수성과 유연성이 훼손될 수 있다.

자바 생태계에서는 ORM 기술이 매우 성숙해 있으며, 하이버네이트와 JPA가 대표적인 구현체 및 표준으로 자리 잡았다. JPA는 자바 진영의 공식 ORM 표준 명세로서, 인터페이스의 모음으로 구성되어 있다. 이 표준을 구현한 실제 라이브러리가 하이버네이트, EclipseLink, DataNucleus 등이며, 이 중 하이버네이트가 사실상의 표준 구현체로 가장 널리 사용된다.

하이버네이트는 JPA 명세를 충실히 구현하면서도 풍부한 확장 기능을 제공한다. 개발자는 JPA 인터페이스를 사용해 코드를 작성하면, 실제 구동 시점에 하이버네이트와 같은 구현체가 동작하여 객체-관계 매핑, 영속성 관리, 캐싱 등의 작업을 처리한다. 이는 특정 ORM 프레임워크에 종속되지 않고 표준에 맞춰 개발할 수 있는 이점을 제공한다.

이러한 자바 ORM들은 엔터프라이즈 애플리케이션 개발에서 객체 지향 프로그래밍의 장점을 관계형 데이터베이스 활용에 결합하는 핵심 도구로 자리매김했다. 스프링 프레임워크와의 긴밀한 통합을 통해 의존성 주입과 트랜잭션 관리를 편리하게 구성할 수 있어 현대 자바 백엔드 개발의 기본 구성 요소가 되었다.

파이썬 생태계에서는 SQLAlchemy와 장고 ORM이 가장 널리 사용되는 ORM 도구이다. 이들은 파이썬의 객체 지향적 특성을 활용하여 데이터베이스 작업을 추상화하지만, 설계 철학과 사용 방식에서 뚜렷한 차이를 보인다.

SQLAlchemy는 강력한 유연성과 세밀한 제어를 제공하는 것이 특징이다. 이는 두 개의 계층, 즉 핵심 ORM 기능을 담당하는 ORM 계층과 독립적으로 사용 가능한 저수준 SQL 표현 언어를 제공하는 Core 계층으로 구성된다. 개발자는 복잡한 쿼리를 작성하거나 특정 데이터베이스의 고급 기능을 활용해야 할 때 Core 계층을 직접 사용할 수 있어, 높은 자유도를 보장한다. 따라서 대규모이거나 복잡한 데이터 모델을 다루는 애플리케이션에서 선호되는 경향이 있다.

반면, 장고 ORM은 장고 웹 프레임워크에 깊이 통합된 구성 요소로, "배터리 포함" 철학을 따른다. 장고의 모델, 뷰, 템플릿 구조와 자연스럽게 연동되어 있으며, 선언적 문법을 통해 빠르게 데이터베이스 스키마를 정의하고 CRUD 작업을 수행할 수 있다. 사용법이 직관적이고 학습 곡선이 비교적 완만하여, 장고로 웹 애플리케이션을 빠르게 구축하는 데 최적화되어 있다. 그러나 장고 프레임워크 외부에서 독립적으로 사용하기는 어려운 단점이 있다.

이처럼 두 ORM은 파이썬 개발자가 객체 지향 프로그래밍 방식으로 관계형 데이터베이스를 다룰 수 있게 해주지만, 프로젝트의 규모, 복잡도, 그리고 사용하는 웹 프레임워크에 따라 적합한 선택이 달라진다.

.NET 플랫폼에서 가장 널리 사용되는 ORM 프레임워크는 Entity Framework이다. 마이크로소프트에서 개발한 이 프레임워크는 ADO.NET을 기반으로 하여 C#이나 VB.NET 같은 .NET 언어로 객체 지향 프로그래밍을 하면서 관계형 데이터베이스를 쉽게 다룰 수 있도록 지원한다. 개발자는 SQL 문을 직접 작성하기보다는 LINQ 쿼리를 사용하거나 DbSet 객체를 조작하는 방식으로 데이터 접근 로직을 구현할 수 있다.

Entity Framework는 크게 Database First, Model First, Code First라는 세 가지 접근 방식을 제공한다. Database First는 기존 데이터베이스 스키마로부터 모델 클래스를 자동 생성하는 방식이고, Code First는 개발자가 먼저 모델 클래스를 작성하면 프레임워크가 이를 바탕으로 데이터베이스 스키마를 생성하거나 변경하는 방식이다. Entity Framework Core는 오픈 소스로 개발된 경량화된 크로스 플랫폼 버전으로, .NET Core 및 이후의 .NET 5 이상과 호환되며 리눅스나 macOS에서도 실행된다.

이 프레임워크는 강력한 데이터베이스 마이그레이션 도구를 내장하고 있어, 모델 클래스의 변경 사항을 데이터베이스 스키마에 체계적으로 반영할 수 있다. 또한 트랜잭션 관리, 지연 로딩, 즉시 로딩 같은 영속성 관련 기능과 함께, 복잡한 관계 매핑 (일대일, 일대다, 다대다)을 지원한다. 성능 최적화를 위해 컴파일된 쿼리 사용이나 로우 SQL 쿼리 실행 같은 기능도 제공한다.

자바스크립트와 타입스크립트 생태계에서는 Node.js 환경에서 주로 사용되는 여러 ORM 프레임워크가 존재한다. 대표적으로 TypeORM과 Prisma가 널리 사용되며, 각각 다른 철학과 특징을 가지고 있다.

TypeORM은 자바의 Hibernate나 파이썬의 SQLAlchemy와 유사한 전통적인 Active Record 패턴과 Data Mapper 패턴을 모두 지원하는 ORM이다. 데코레이터를 활용한 선언적인 방식으로 엔티티를 정의할 수 있어 타입스크립트와의 통합이 뛰어나다는 장점이 있다. 다양한 관계형 데이터베이스를 지원하며, 쿼리 빌더와 원시 SQL 실행 기능도 제공한다.

반면 Prisma는 기존 ORM과는 차별화된 접근 방식을 취한다. Prisma는 별도의 스키마 정의 파일을 사용하며, 타입 안전성이 매우 강력한 쿼리 클라이언트를 자동으로 생성해준다. 이 클라이언트를 통해 데이터베이스에 접근하는 방식으로, 개발자는 생성된 타입 안전한 메서드를 사용하여 직관적으로 CRUD 작업을 수행할 수 있다. 데이터베이스 마이그레이션 도구인 Prisma Migrate와 데이터베이스 GUI 툴인 Prisma Studio를 내장하고 있어 개발 경험을 중시한다.

이 외에도 Sequelize나 MikroORM 같은 다른 라이브러리들도 사용되지만, 현대적인 타입스크립트 프로젝트에서는 TypeORM과 Prisma가 가장 큰 점유율을 차지하고 있다. 각 프레임워크는 프로젝트의 규모, 복잡도, 개발 팀의 선호도에 따라 선택된다.

마이크로 ORM은 전통적인 ORM 프레임워크에 비해 가볍고 단순한 접근 방식을 제공하는 도구이다. 완전한 기능을 갖춘 ORM이 제공하는 영속성 관리, 캐싱, 복잡한 관계 매핑과 같은 고급 기능 대신, 객체와 데이터베이스 테이블 간의 기본적인 매핑과 SQL 쿼리 실행을 단순화하는 데 초점을 맞춘다. 주로 POJO나 간단한 데이터 구조를 데이터베이스 레코드와 쉽게 변환하는 기능을 제공한다.

이러한 도구들은 애플리케이션에 최소한의 오버헤드만 추가하며, 개발자가 작성한 SQL 쿼리나 프로시저를 실행하고 그 결과를 객체로 매핑하는 데 주로 사용된다. 따라서 복잡한 객체-관계 매핑 설정이나 학습 곡선 없이도 데이터베이스 작업을 보다 편리하게 수행할 수 있다. 마이크로서비스 아키텍처나 소규모 프로젝트, 또는 성능을 극대화해야 하는 상황에서 선호되는 경향이 있다.

대표적인 마이크로 ORM의 예로는 닷넷 생태계의 Dapper, 파이썬의 SQLObject, 자바스크립트/타입스크립트의 Knex.js 등이 있다. 이들은 애플리케이션과 데이터베이스 사이의 간단한 연결 계층 역할을 하여, 개발자가 네이티브 SQL에 가까운 수준으로 제어력을 유지하면서도 반복적인 보일러플레이트 코드 작성을 줄일 수 있게 돕는다.

쿼리 빌더는 SQL 쿼리를 프로그래밍 방식으로 구성하고 생성할 수 있게 해주는 도구 또는 라이브러리이다. ORM이 객체와 데이터베이스 테이블 간의 매핑을 추상화하는 것과 달리, 쿼리 빌더는 SQL 문법 자체를 코드 형태로 추상화하여 제공한다. 개발자는 문자열을 연결하여 SQL을 직접 작성하는 대신, 메서드 체이닝과 같은 방식으로 조건, 조인, 정렬 등을 지정하여 최종 쿼리를 조립할 수 있다.

쿼리 빌더의 주요 기능은 동적 쿼리 생성과 데이터베이스 벤더 독립성을 들 수 있다. 애플리케이션 로직에 따라 조건이 변하는 복잡한 동적 쿼리를 안전하고 가독성 있게 작성할 수 있으며, 특정 데이터베이스(MySQL, PostgreSQL, SQLite 등)에 종속되지 않는 추상화된 문법을 제공함으로써 데이터베이스 교체 시 발생할 수 있는 호환성 문제를 줄여준다. 또한, 사용자 입력값을 매개변수화하여 처리함으로써 SQL 인젝션 공격을 방지하는 보안 장치를 내장하고 있는 경우가 많다.

따라서 쿼리 빌더는 순수 ORM이 제공하는 객체 중심 접근법과 네이티브 SQL의 완전한 제어 사이에서 균형을 잡는 중간 지점의 솔루션이다. 복잡한 보고서 쿼리나 대량 데이터 처리와 같이 ORM으로는 표현하기 어려운 작업을 수행해야 하지만, 네이티브 SQL 문자열의 보안 취약점과 유지보수 어려움을 피하고자 할 때 널리 사용된다. 많은 현대의 ORM 프레임워크는 내부적으로 쿼리 빌더를 포함하거나, 개발자가 필요시 쿼리 빌더 방식으로 세밀한 쿼리를 작성할 수 있는 기능을 함께 제공한다.

네이티브 SQL은 ORM이나 쿼리 빌더와 같은 추상화 도구를 사용하지 않고, 데이터베이스가 이해할 수 있는 순수한 SQL 문장을 직접 애플리케이션 코드 내에 작성하여 데이터베이스를 조작하는 방식을 의미한다. 이는 가장 기본적이고 직접적인 데이터 접근 방식으로, 개발자가 데이터베이스 스키마와 SQL 문법에 대한 깊은 이해를 필요로 한다.

네이티브 SQL을 사용하는 주된 이유는 ORM이 생성하는 쿼리가 복잡한 조인이나 데이터베이스 특정 기능을 효율적으로 처리하지 못하는 경우가 있기 때문이다. 특히 대용량 데이터를 다루는 복잡한 쿼리, 저장 프로시저 호출, 데이터베이스 고유의 윈도우 함수나 계층형 쿼리를 사용해야 할 때 네이티브 SQL은 최적의 성능과 유연성을 제공할 수 있다. 대부분의 ORM 프레임워크는 이러한 필요성을 인지하고, 특정 ORM 기능을 벗어난 네이티브 SQL을 실행할 수 있는 인터페이스를 함께 제공하는 경우가 많다.

그러나 네이티브 SQL 사용은 SQL 인젝션과 같은 보안 취약점에 직접적으로 노출될 위험이 크며, 쿼리 문자열을 하드코딩함으로써 유지보수성을 떨어뜨릴 수 있다. 또한 데이터베이스 벤더에 종속적인 쿼리를 작성하게 되면, 향후 데이터베이스 마이그레이션 시 큰 비용이 발생할 수 있다는 단점이 있다. 따라서 현대적인 소프트웨어 개발에서는 네이티브 SQL을 최소화하고, ORM이나 쿼리 빌더를 주로 사용하되, 성능이 결정적으로 중요한 부분이나 ORM으로 표현하기 어려운 복잡한 로직에 대해서만 선택적으로 적용하는 것이 일반적인 관행이다.