ORM

Object-Relational Mapping (ORM) is a programming technique for converting data between type systems using object-oriented programming languages.

— 컴퓨터 전산학 데이터 매핑 패턴 정의

SQL을 공부하기 싫어하는 초보 백엔드 주니어들의 도피처이자, 정작 서비스 규모가 커지면 복잡한 네이티브 SQL을 작성해 ORM 코드를 리팩토링하느라 밤을 새워야 하는 모순의 툴. ~~어렵사리 ORM 함수 체이닝을 구구절절 짜는 것보다, 그냥 날것의 SQL 한 줄 쓰는 게 10배는 빠르고 직관적일 때가 아주 흔하다.(...)~~

1. 개요

객체지향 프로그래밍(OOP) 언어의 객체(Object)와 관계형 데이터베이스(RDB)의 테이블(Table)을 중간에서 자동으로 매핑(Mapping)해 주는 가교 기술. 개발자가 자바나 파이썬 등의 코드상에서 데이터 객체를 마음껏 굴리면, ORM 프레임워크가 내부적으로 알맞은 SQL 쿼리를 동적으로 조립해 데이터베이스에 날려준다. 자바 진영의 JPA/Hibernate, 파이썬의 SQLAlchemy, 노드 진영의 Sequelize, Prisma 등이 대표적인 도구다.

2. 패러다임의 불일치와 ORM의 구원

객체지향은 클래스, 상속, 참조 구조를 기반으로 움직이지만, 관계형 데이터베이스는 테이블, 외래 키, 조인(Join)의 수학적 집합을 토대로 동작한다. 이 거대한 공학적 틈새를 '패러다임의 불일치(Paradigm Mismatch)'라 한다. ORM이 없던 시절 개발자들은 데이터 하나를 읽기 위해 무수한 JDBC/ADO.NET 보일러플레이트 코드를 타이핑하고, 자바 객체의 필드값들을 SQL 물음표(?) 파라미터에 대입하는 단순 노동을 반복했다.¹ ORM은 이 끔찍한 코드 노가다를 전면 폐지하고, user.save()나 user.getOrders() 같은 지극히 객체지향적인 메서드 호출만으로 영속성(Persistence) 처리를 완결시키는 가공할 편의성을 선물했다.

3. 지연 로딩(Lazy Loading)과 악명 높은 N+1 문제

그러나 이 달콤함 뒤에는 무시무시한 성능 함정들이 아가리를 벌리고 있다. 대표적인 것이 N+1 문제(N+1 Query Problem)이다. 연관된 두 테이블(예: 회원과 회원의 주문 내역)을 조회할 때, 첫 조회 쿼리(1회)를 날린 후 루프를 돌며 각 회원의 주문 내역을 가져오기 위해 회원의 수(N개)만큼 추가 쿼리가 발생하는 최악의 연산 낭비 현상이다. 또한, 필요할 때 비로소 데이터를 DB에서 긁어오는 지연 로딩(Lazy Loading)이나 영속성 컨텍스트(Persistence Context)의 캐싱 원리를 완벽하게 이해하지 못하고 현업에 뛰어들었다가는, 눈 깜짝할 사이에 성능 저하가 터지고 DB 커넥션이 조기에 고갈되는 업보를 청구받게 된다.

4. 관련 밈 및 드립

4.1. ORM을 쓰면 SQL을 몰라도 된다?

백엔드 부트캠프나 입문서 등에서 자주 외치는 달콤한 유혹. 하지만 이는 업계의 가장 치명적인 거짓말 중 하나로 꼽힌다. 실제 업무에서 성능 장애가 터졌을 때, 결국 ORM이 백그라운드에서 무슨 해괴망측한 SQL을 동적으로 조립해 보내는지를 SQL 로그(show_sql)로 뜯어보며 튜닝해야 하기 때문이다. 고참 시니어들은 신입이 '저는 ORM만 할 줄 알고 SQL은 모릅니다'라고 당당히 고백하는 순간, 그 신입이 작성한 코드를 전사적으로 검사해야 한다는 심각한 경계경보를 발령한다.

4.2. N+1 문제를 겪지 않은 자는 백엔드가 아니다

실무에서 서비스 론칭 첫날, 동시 접속자가 몰리며 서버가 갑자기 기절하는 대포 폭격의 주원인이 대부분 N+1 쿼리 에러라는 점을 풍자한 드립. 개발 머신에서는 테스트 유저가 5명뿐이라 0.001초 만에 실행되어 멀쩡해 보이지만, 회원 수가 10,000명으로 증가하는 순간 10,001번의 SQL 쿼리가 데이터베이스에 따발총처럼 작렬하며 CPU를 불태운다. 밤을 지새우며 Fetch Join 설정을 가동해 쿼리를 단 1줄로 통합하는 감동적인 전율을 겪어야 비로소 진정한 백엔드 전사로 거듭난다는 농담이 유명하다.(...)

5. 여담

Active Record vs Data Mapper: ORM 디자인 패턴은 크게 두 부류로 갈린다. 데이터 클래스 자체가 저장/수정 메서드를 내장하는 액티브 레코드 패턴(Rails의 Active Record, Django ORM 등)과, 도메인 모델과 데이터베이스 매퍼 장치를 철저히 격리하여 엔터프라이즈 아키텍처에 적합한 데이터 매퍼 패턴(JPA/Hibernate, SQLAlchemy 등)이 대표적인 대결 구도를 형성하고 있다.
결국은 Native SQL로 회귀: 통계 작성이나 대용량 배치 처리, 수십 개의 테이블이 얽힌 복잡한 통계 화면을 구현할 때 ORM 코드로 이를 표현하는 것은 거의 정신 고문에 가깝다. 이 때문에 실무진들은 QueryDSL 같은 동적 쿼리 빌더를 섞어 쓰거나, 아예 날것의 SQL 문을 조립해 실행하는 Native Query 기능으로 조용히 후퇴한다.
자동 스키마 생성의 공포: ORM 설정 중 '스키마 자동 생성(ddl-auto: update/create)'을 켜두는 경우가 있다. 로컬 개발계에서는 신성한 치트키처럼 작동하지만, 이를 세팅 값 그대로 실 운영 데이터베이스 서버에 배포했다가는 기존 고객들의 소중한 실서비스 데이터 테이블들이 전부 DROP되어 공중분해되고 9시 뉴스 테러를 장식할 수 있는 살상 도구로 돌변한다.(...)

6. 관련 문서

데이터베이스 컬럼 이름이 하나 바뀔 때마다 소스 코드 전체에서 수백 개의 SQL 하드코딩 텍스트를 검색해 한 땀 한 땀 고치다가 오타 하나로 런타임 에러를 뿜던 시절이 바로 그 암흑기였다. ↩

ORM