ORM은 레거시가 될까?

어느덧 개발자들 사이에서 JPA같은 ORM 기술은 언어를 가리지 않고 선택이 아닌 필수 교양이 되었다. 개발자 면접에서도 영속성 컨텍스트의 원리나 N+1 문제의 해결책을 묻는 것이 당연한 코스가 되었다. 하지만 문득 의문이 들었다. 당연하게 믿고 있는 이 도구가 사실은 레거시가 되어가지 않을까?

 

1. ORM은 왜 대세가 되었을까?

ORM을 배우는 이유는 명확했다. 지루하고 반복적인 CRUD 쿼리 작성을 자동화하여 개발 효율을 높이고, 테이블 중심이 아닌 객체지향적인 사고로 비즈니스 로직을 구현하기 위함이다.

 

하지만 지금은 AI가 코딩하는 시대다. 과거에는 수십 개의 컬럼을 매핑하고 쿼리를 짜는 것이 '고비용 작업'이었지만, 이제는 AI에게 스키마만 던져주면 최적화된 SQL과 DTO 매핑 코드를 1초 만에 뱉어낸다. 반복적인 코드 작성이 더 이상 개발자의 발목을 잡는 '비용'이 아니게 된 것이다.

 

객체지향적인 사고? 내가 본 실무를 기반으로 얘기해보자면 판타지에 가깝다. 우리가 만드는 대부분의 엔티티(Entity)는 결국 DB 테이블과 1:1로 매핑되어 사용된다. 이름만 엔티티일 뿐, 사실상 DB의 데이터를 담아 나르는 DTO 역할에 그친다. 누군가는 DTO가 아니라고 말하며 엔티티내에 캡슐화된 메서드 몇개 넣었다고 그것을 객체지향프로그래밍이라고 부를지 모르겠지만 나는 아니라고 본다. 이미 테이블 주도 개발을 한뒤에 객체지향 특성을 일부 넣는다고 그것이 객체지향 프로그래밍이라고 하기 어렵다. ORM으로 객체지향프로그래밍이 불가능하다고 말하는것이 아니다. 현실적으로 엔티티를 정말 객체지향적으로 설계하기 어렵다는 말이다.

 

엔티티와 도메인 객체를 완벽히 분리하여 순수한 도메인 주도 설계(DDD)를 실천하는 프로젝트는 너무 드물다. 만약 그 정도로 철저히 분리할 수 있는 구조라면, 역설적으로 그 매핑의 브릿지 역할을 굳이 무거운 ORM이 맡을 필요도 없다.

 

2. 편의를 가장한 문제 발생기, 그리고 비정상적인 학습 비용

ORM은 개발을 편하게 해준다고 약속하지만, 그 대가로 개발자의 머릿속을 복잡하게 만든다. 단순히 쿼리 몇 줄 안 쓰는 대가로 우리가 지불해야 하는 학습 비용은 과연 정당한가?

 

JPA를 제대로 쓰기 위해 우리는 '영속성 컨텍스트'라는 거대한 블랙박스를 공부해야 한다.

N+1문제, OSIV(Open Session In View), 더티 체킹, 1차 캐시.. 이름만 들어도 머리 아픈 이 개념들은 사실 DB의 기본 동작과는 거리가 먼, ORM이라는 도구가 만들어낸 인위적인 규칙들이다.

 

이렇게 JPA를 열심히 학습한 다음에 시니어들은 뭐라고 말하는가?

'결국 DB를 잘 알아야지..'

DB에 대한 학습도 추가적으로 해야한다. 그것도 ORM 이전시대와 다를바 없는 수준으로..

 

ORM이 뒤에서 어떤 쿼리를 생성하고 있는지 로그를 뒤져보며 성능을 튜닝하고, 영속성 컨텍스트의 복잡한 생명주기를 공부할 시간에 차라리 AI를 활용해 명시적인 SQL을 작성하는 것이 훨씬 생산적이지 않을까?

 

AI는 SQL뿐만 아니라 그 SQL을 담을 매핑 코드까지 완벽하게 짜준다. JPA 구현을 학습할 필요가 없어진 것이다. 예측 가능성은 개발자를 학습의 굴레에서 해방시키고 코드를 가볍게 만든다. 내가 쓴 쿼리만 나간다는 확신, 그것이 주는 심리적 안정감은 ORM의 마법보다 훨씬 값질수 있다.

 

대충 마무리 하자면..

기술은 시대의 요구에 따라 변한다. 한때 SQL의 지옥에서 우리를 구원해준 ORM은 분명 고마운 존재였다. 하지만 AI가 SQL을 대신 써주고, 도구의 복잡도가 본질인 비즈니스 로직을 압도하는 지금, 우리는 다시 단순함과 명확함으로 회귀해야 할 때가 아닐까.

마법 뒤에 숨어 ORM 철학을 공부하기보다, 투명한 코드로 시스템을 완전히 장악하는 것. 그것이 AI 시대를 살아가는 백엔드 개발자의 경쟁력이 되지 않을까 조심히 예측해본다.

 

다음 프로젝트에 JPA를 과감히 버리고 Spring JDBC를 사용해보고 싶다. 이에 대한 회고를 할수 있으면 좋겠다.