ORM 을 우리가 쓰지 않는 도메인

ORM 에 대한 우리 팀의 기본 입장

우리는 ORM을 부정하지 않는다. CRUD 중심의 어드민 기능이나 간단한 마스터 데이터 관리에서 ORM은 생산성을 높여준다. 반복적인 SQL을 줄이고, 타입 안전성을 확보하고, 마이그레이션을 구조화하는 데 분명히 기여한다.

그러나 팀이 운영하는 서비스 중 일부 도메인에서는 ORM을 쓰지 않기로 명시적으로 결정했다. 이 글은 그 이유를 설명한다.

ORM 을 쓰지 않는 도메인: 금융 계산과 정산

정산 및 금융 계산 도메인에서는 SQL을 직접 작성한다.

이유는 두 가지다.

첫 번째는 정밀도 제어다. 금액을 다루는 쿼리에서는 소수점 반올림 규칙, ROUND 함수의 적용 시점, DECIMAL vs BIGINT 처리 방식이 결과에 직접 영향을 준다. ORM은 이런 세부 동작을 추상화하는데, 그 추상화가 우리가 원하는 방식과 미묘하게 다를 때 디버깅 비용이 매우 커진다. SQL로 작성하면 실행 계획과 결과가 1:1로 눈에 보인다.

두 번째는 집계 쿼리의 복잡성이다. 정산은 필연적으로 GROUP BY, WINDOW FUNCTION, 여러 테이블의 조인이 맞물린다. ORM으로 이 쿼리를 표현하면 코드가 SQL보다 오히려 읽기 어려워진다. 팀원 모두 SQL을 읽을 수 있기 때문에 SQL이 명시적으로 남아 있는 것이 유지보수에 유리하다.

발생하는 트레이드오프

물론 대가가 따른다.

ORM이 제공하는 마이그레이션 툴, 자동 타입 매핑, N+1 감지 같은 편의 기능을 직접 관리해야 한다. 마이그레이션은 별도 스크립트로 버전 관리하고, 결과 매핑은 수동으로 작성한다.

또한 도메인마다 접근 방식이 달라지므로 팀 내에서 “이 모듈은 ORM, 저 모듈은 네이티브 SQL”이라는 규칙을 명확하게 공유해야 한다. 암묵적으로 섞이면 혼란이 생긴다.

결론: 선택의 기준은 가시성

ORM을 쓸지 말지를 결정하는 우리 팀의 기준은 단순하다. “이 쿼리의 실행 결과를 내가 예측할 수 있는가?” 예측이 쉬운 경우에는 ORM의 생산성을 취한다. 예측이 어렵거나 결과가 틀렸을 때 비용이 큰 도메인에서는 SQL을 직접 쓴다.

기술 선택은 트렌드가 아니라 문제의 성격이 결정해야 한다.

— by slecs