실무 판단 원칙 상태를 바꾸는 일은 ORM에 두고, 결과를 읽는 일은 복잡해질수록 SQL 쪽으로 이동합니다.

한 기술로 통일하는 것이 목표가 아니라, 트랜잭션 일관성이 중요한지 아니면 조회 결과와 성능이 중요한지에 따라 기본 도구와 예외 지점을 다르게 잡는 것이 핵심입니다.

업무 성격
기본 선택
SQL로 확장되는 지점
운영 의미
Command 상태 변경 CUD, 트랜잭션, 비즈니스 규칙
ORM 엔티티 중심

변경 감지와 생명주기를 활용해 서비스 계층의 규칙을 일관되게 묶습니다.

기본 → 단순 CRUD와 상태 전이는 ORM으로 처리
예외 → 대량 갱신이나 배치 작업만 Native Query / JDBC Batch로 우회
일관성이 우선입니다.

상태 변경 이유와 트랜잭션 경계가 코드에 남아 운영 중 오류 원인을 추적하기 쉽습니다.

Query 결과 조회 검색, 통계, 대시보드, 응답 최적화
단순 조회는 ORM

Fetch Join 수준까지는 모델 일관성을 유지하면서도 충분히 읽을 수 있습니다.

확장 1 → 동적 조건과 복잡한 검색은 QueryDSL로 분리
확장 2 → 집계, 통계, 대시보드는 Native SQL 또는 전용 View로 최적화
응답 형태와 속도가 우선입니다.

읽기 모델을 별도로 다루면 도메인 모델을 과도한 조회 요구로부터 분리할 수 있습니다.

CQRS로 고정
쓰기 모델은 ORM, 읽기 모델은 QueryDSL·Raw SQL로 분리하는 것이 CQRS의 실무 형태입니다.

즉, ORM과 SQL의 균형 전략을 팀 차원의 구조 규칙으로 승격한 형태라고 이해하면 됩니다.