SQL을 몰라도 JPA가 다 해준다고 믿는 개발자에게

by 그릿 | GROWTH_ESSAY | 2026-10-31

멘토링을 시작할 때 1~2년 차 백엔드 개발자들의 이력서와 코드를 열어보면 열에 아홉은 JPA를 메인 기술로 적어둡니다. 메서드 이름 몇 개 조합하면 DB에서 데이터가 척척 나오고, 객체 필드만 바꾸면 수정까지 끝나니 "이제 복잡한 SQL은 배울 필요 없겠다"고 안도합니다. 그런데 면접관이 "이 코드에서 실제로 어떤 쿼리가 몇 번 나가는지 확인해보셨나요?"라고 묻는 순간, 대답은 멈춥니다.

코드가 동작하는 것과 DB가 일하는 것은 다릅니다

멘티 한 분이 1000명 회원 목록에 최근 주문 내역을 붙여 응답하는 간단한 API를 가져왔습니다. 로컬에서는 몇 밀리초 만에 잘 돌아갔지만, 데이터 10만 건을 넣고 부하 테스트를 걸자마자 서버가 멈췄습니다. 쿼리 로그를 켜보니 한 번의 API 호출에 무려 1001번의 SELECT 쿼리가 쏟아지고 있었습니다. 전형적인 N+1 문제였습니다.

개발자는 메서드 하나를 호출했을 뿐이지만, 데이터베이스는 1000번 넘게 네트워크를 오가며 비명을 지르고 있었습니다. DB가 실제로 어떤 비용을 치르고 있는지 보지 못하면, 로컬에서 잘 돌아가는 코드가 프로덕션에서는 시한폭탄이 됩니다.

ORM은 추상화일 뿐, 물리적인 실체를 지우지 못합니다

많은 주니어가 JPA를 "SQL을 몰라도 되게 해주는 마법"으로 오해합니다. 하지만 ORM은 SQL을 대체하는 기술이 아닙니다. 관계형 데이터베이스와 객체 지향 언어 사이의 패러다임 불일치를 줄여서 반복 노동을 덜어주는 도구일 뿐입니다.

결국 데이터가 저장되는 곳은 디스크이고, 데이터를 찾는 것은 인덱스이며, 경합을 통제하는 것은 락과 트랜잭션입니다. 인덱스가 어떻게 타는지, 조인이 어떻게 일어나는지 모른 채 객체만 주무르면 시스템 성능은 운에 맡겨집니다. 엔진의 원리를 모른 채 운전대만 잡는 사람은 차가 멈췄을 때 보닛조차 열지 못합니다.

쿼리를 통제할 수 있을 때 진짜 백엔드 개발자가 됩니다

200명 넘는 멘티들을 지켜보며 확인한 차이가 있습니다. 실력 있는 개발자는 JPA를 쓸 때도 머릿속으로 실행될 SQL을 먼저 그립니다. "이 관계를 조회할 때 패치 조인을 써야 할까, DTO로 직접 프로젝션해야 할까"를 고민하며 실행 계획을 뜯어봅니다.

ORM이 만들어내는 쿼리를 의심하고 검증하는 힘, 바로 그 지점에서 백엔드의 내공이 갈립니다. 프레임워크의 편리함 뒤로 숨지 마세요. 작성한 엔티티 연관관계 뒤에서 실제로 어떤 SQL이 날아가는지, 지금 로그를 켜고 직접 확인해보길 권합니다.