요즘 개발자들과 대화를 나누다 보면 이런 말을 자주 듣습니다. “우리 서비스는 전부 ORM이라서 SQL은 잘 안 써요.” 겉으로 보면 자연스러운 흐름입니다. 프레임워크가 이미 ORM(Object Relational Mapping, 객체 관계 매핑)을 기본값처럼 제공하고, 튜토리얼에서도 User.find() 한 줄이면 끝나는 세상을 보여주니까요. 하지만 실무로 들어가면 질문의 방향이 조금 달라집니다. “왜 이 화면은 레이턴시가 이렇게 길지?”, “왜 이 쿼리는 인덱스가 있는데도 풀 스캔이 날까?”, “ORM이 생성한 쿼리, 이거 진짜 괜찮은 건가?”

이때부터는 이야기의 중심이 다시 SQL(Structured Query Language)로 돌아옵니다. ORM은 우리를 SQL로부터 “해방”시켜주는 도구가 아니라, SQL을 모르는 상태로 쓰기 시작하면 오히려 리스크가 커지는 도구에 가깝습니다. 이번 글은 “ORM이냐, SQL이냐” 둘 중 하나를 고르라는 이야기가 아닙니다. 두 가지 사고방식이 어떻게 다른지, 실무에서는 어떻게 공존해야 하는지, 그리고 왜 자격증 공부까지 포함한 ‘탄탄한 SQL 이해력’이 ORM 시대에도 여전히 유효한지 풀어보려고 합니다.

SQL과 ORM, 완전히 다른 사고방식

조금 단순화해서 정리해 보겠습니다. 결정적인 차이는 “누가 책임을 지는가”입니다. SQL은 개발자가 책임을 집니다. ORM은 도구가 대신 SQL을 만들어주고, 개발자는 한 단계 위에서 추상화된 인터페이스를 다룹니다. 그래서 ORM만 쓰다 보면, 어느 순간 “도구는 잘 쓰는데, 그 아래서 무슨 일이 벌어지는지는 모르는 상태”에 빠지기 쉽습니다. 이 공백을 메우는 게 바로 SQL 이해력이고, 그 일부를 공식적으로 증명하는 수단이 자격증입니다.

ORM이 표준이 된 시대, 왜 다시 SQL을 이야기할까요?

한때는 “앞으로는 다 ORM 쓴다”라는 분위기가 강했습니다. 코드가 깔끔해지고, 중복이 줄어들고, 테스트도 쉬워지고, 유지보수성이 좋아 보였기 때문입니다. 그런데 몇 년이 지나면서, 다른 장면들이 보이기 시작했습니다.

ORM이 실무에서 마주치는 문제들

페이지 하나를 불러올 때마다 수십, 수백 개의 쿼리가 나가는 N+1 문제
ORM이 생성한 조인과 조건이 잘못된 탓에 인덱스를 전혀 활용하지 못하는 실행 계획
캐시나 페이징, 통계 쿼리처럼 ORM 추상화에 애매하게 걸리는 영역
특정 DBMS의 기능(힌트, 부분 인덱스, 분석 함수 등)을 쓰기 어려운 답답함

“ORM이 나쁘다는 게 아니라, 우리가 SQL을 모르는 상태에서 ORM만 믿고 있었던 건 아닐까?” 그래서 요즘 흐름은 조금 현실적으로 바뀌었습니다.

그렇다면 현실적인 운영 법칙은 무엇일까요?

평범한 CRUD, 단순 조회: ORM으로 개발 속도 확보
복잡한 통계, 대량 데이터 집계, 성능 주요 구간: 직접 SQL 작성
문제 발생 시: ORM이 만든 SQL 열람, 실행 계획 분석이 가능한 사람의 역할

즉, ORM 위에 서 있는 SQL, 이게 현재 실무의 진짜 구조에 가깝습니다.

실무에서 자주 갈리는 의견들

조금 더 구체적으로, 실무에서 자주 부딪히는 선택 상황을 살펴보겠습니다.

1) 스타트업 / 신규 서비스

요구사항이 자주 바뀝니다.
출시가 늦어지면 기회 자체를 잃습니다.
팀원 구성이 자주 바뀌고, 주니어도 많습니다.

이 환경에서는 대부분 ORM을 중심으로 갑니다. 마이그레이션 도구, 스키마 관리, 관계 정의가 코드에 함께 들어와 있어 협업이 쉽습니다. 다만, 초기에 간단해 보였던 조회 로직이 성장하면서 괴물이 되는 경우가 생깁니다. 이때 SQL을 모르는 팀이면, 문제를 인지하고도 손을 못 대는 상황이 벌어집니다.

2) 대규모 트래픽 / 금융 / 커머스 / 로그 시스템

초당 수백~수천 건 이상의 요청
규제, 감사, 정확성, 성능이 모두 중요한 영역
장애가 곧 손실입니다.

이 환경에서 ORM만으로 모든 것을 해결하려 하면 한계가 빠르게 드러납니다. 고급 조인, 서브쿼리, 윈도우 함수, 파티셔닝, 힌트, 복잡한 집계 쿼리 등은 결국 SQL 영역입니다. 그래서 많은 팀이 이렇게 선언합니다. “핵심 구간은 SQL로 직접 관리한다.” 이 선언을 실행으로 옮기려면, 팀 안에 SQL을 읽고, 짜고, 튜닝할 줄 아는 사람이 있어야 합니다.

SQL vs ORM, 핵심 비교

표로 간단히 정리했지만, 실무 기준에서 한 줄로 요약하면 이렇습니다.

“SQL은 힘이 세고, ORM은 빠르다. 오래 가는 팀은 둘을 같이 쓴다.”

“그래서 뭐부터 공부해야 할까?” 자격증과 실무의 연결

여기서 자격증 이야기가 갑자기 끼어드는 건 아닙니다. ORM 시대일수록 “진짜 SQL을 아는가”를 검증할 기준이 필요해졌고, 그 역할을 일부 대신하는 것이 데이터베이스 관련 자격증입니다.

SQLD(SQL 개발자)

한국데이터산업진흥원에서 운영하는 국가공인 자격으로, 과목은 데이터 모델링의 이해와 SQL 기본 및 활용 두 가지로 구성됩니다. 엔터티, 관계, 정규화부터 SELECT, JOIN, 서브쿼리, 윈도우 함수, 트랜잭션 관련 구문까지 폭넓게 다룹니다. 합격 기준은 총점 60점 이상, 과목별 40% 미만 과락 기준이며, 데이터 설계와 SQL 작성 능력을 기본 이상 증명하는 지표로 활용되고 있습니다.

ORM과의 연결
SQLD를 준비하는 과정은, “ORM이 만드는 쿼리가 무엇을 하는지 눈으로 읽고 판단할 수 있는 수준”까지 올라오는 과정과 거의 같습니다. 실무에서 ORM을 쓰더라도, SQLD 수준의 이해가 있으면 성능 이슈를 ‘감으로’가 아니라 ‘근거를 보고’ 이야기할 수 있습니다.

SQL 전문가(국가공인)

같은 기관에서 운영하는 상위 자격으로, 데이터 모델링, SQL 고급 활용, 튜닝까지 포함해 보다 깊이 있는 역량을 검증합니다. 이 수준에 이르면 ORM이 생성한 쿼리를 단순히 읽는 것을 넘어, “이건 ORM으로 두면 안 되고, 별도 SQL로 분리해야 한다”라는 판단을 근거와 함께 내릴 수 있습니다.

Oracle Database SQL Certified Associate

Oracle에서 제공하는 국제 자격으로, 시험(예: 1Z0-071)을 통과하면 관계형 개념, DDL/DML, 조인, 서브쿼리, 집계, 제약조건, 권한 관리 등을 포함한 SQL 전반에 대한 이해를 인증합니다. Oracle 기반 시스템이나 엔터프라이즈 환경에서 커리어를 쌓고자 한다면, “특정 벤더 환경에서 실제로 쓰이는 SQL을 다룰 수 있다”는 증거가 됩니다.

Oracle Certified Professional(OCP)및 기타

OCP는 데이터베이스 설치, 운영, 백업, 성능 튜닝 등까지 포함해 DB를 “서비스 인프라” 관점에서 관리할 수 있는 수준을 요구합니다. 여기까지 가면, 개발자라기보다 “데이터베이스 아키텍트” 또는 “DBA와 개발 사이를 연결하는 사람”에 가깝습니다. ORM과 SQL의 경계를 이해하는 수준을 넘어, “우리 서비스의 데이터 전략 자체를 설계하는 사람”이 되는 길입니다.

ORM 쓰는 개발자를 위한 현실적인 로드맵

이제 “실제 독자를 위한 가이드”로 정리해 보겠습니다. 백엔드·풀스택 개발자, 주니어, 자격증 준비자를 모두 포함한 단계별 제안입니다.

1단계: ORM + 기본 SQL

이미 ORM을 쓰고 있다면, 먼저 ORM이 찍는 실제 SQL 로그를 확인해 보세요.
SELECT, JOIN, WHERE, GROUP BY 정도는 직접 쿼리로 써보고, 실행 계획도 한 번 열어봅니다.
이 단계에서 SQLD 교재 수준의 내용을 자연스럽게 커버할 수 있습니다.

2단계: 실무형 SQL

복잡한 검색 조건, 통계, 페이징, 다중 조인을 직접 SQL로 작성해 봅니다.
ORM이 애매하게 처리하는 쿼리는 “네이티브 SQL”이나 “뷰, 스토어드 프로시저” 등으로 분리하는 연습을 합니다.
Oracle SQL Associate 같은 국제 자격까지 고려하면, DB 벤더별 특성과 표준 SQL의 공통점을 동시에 잡을 수 있습니다.

3단계: 팀의 SQL 레퍼런스로 성장

서비스 특성에 맞는 인덱스 전략, 파티셔닝 전략, 쿼리 튜닝 패턴을 정리합니다.
ORM 설정(지연 로딩, 즉시 로딩, 배치 사이즈 등)을 SQL 실행 결과를 기준으로 조정합니다.
여기서부터는 SQL 전문가, OCP 같은 상위 자격이 실무 설득력을 더해줍니다.

이 로드맵의 핵심은 한 가지입니다. ORM 사용 능력 위에 SQL 이해를 덮어씌우는 것이 아니라, SQL이라는 기반 위에 ORM 활용 능력을 쌓는 것입니다.

마치며: 도구를 믿되, 바닥은 직접 볼 수 있어야 합니다

이제 마지막으로 정리해 보겠습니다. ORM은 분명히 개발을 빠르게 해주는 훌륭한 도구입니다. 하지만 ORM이 만들어 내는 SQL을 이해하지 못하면, 서비스가 성장할수록 문제의 원인을 찾지 못하는 순간이 찾아옵니다. SQLD, SQL 전문가, Oracle SQL Associate, OCP 같은 자격증은 단순한 스펙이 아니라, “나는 ORM 아래에서 돌아가는 구조까지 이해하고 있다”는 신호가 될 수 있습니다.

결국 중요한 것은 ‘무엇을 선택했는가’가 아니라 ‘얼마나 깊이 이해하고 있는가’입니다. “나는 ORM을 쓴다”에서 멈추는 것이 아니라, “그래서 이 코드가 어떤 SQL을 만들고, 그 SQL이 데이터베이스에서 어떻게 실행되는지”까지 설명할 수 있는 개발자가 되는 것. 이번 글이 그 단계로 올라가고 싶은 분들에게 하나의 기준점과 체크리스트가 되었으면 합니다. 그렇다면 오늘 사용하는 ORM 설정을 한 번 열어보고, 그 아래에서 실제로 실행되는 SQL을 직접 읽어보는 것부터 시작해 보면 어떨까요?