SQL 포맷팅 규칙과 AST 파싱, 쿼리 가독성이 실행 계획에 미치는 영향

SQL(Structured Query Language)은 "어떻게(How)" 데이터를 가져올지가 아니라 "무엇을(What)" 원하는지 선언하는 고수준 선언형 언어입니다. 서비스가 고도화될수록 실무 쿼리는 수십 개의 테이블 조인, 서브쿼리, 윈도우 함수가 얽혀 수백 줄에 달하게 됩니다.

줄바꿈과 들여쓰기가 없는 난독화된 단일 라인 SQL은 데이터베이스 장애의 온상입니다. 조건절의 괄호 우선순위 오판, ON 절의 누락으로 인한 의도치 않은 카테시안 곱(Cartesian Product, Full Cross Join), 인덱스를 타지 않는 조건 등이 코드 리뷰 과정에서 누락되어 프로덕션 DB의 CPU를 100%로 치솟게 만듭니다.

RDBMS(PostgreSQL, MySQL 등) 엔진이 SQL 텍스트를 수신하면 디스크에서 데이터를 읽기 전에 3단계 파싱 과정을 거칩니다:

1. 어휘 분석(Lexical Analysis, Lexer): 원시 SQL 문자열을 키워드(SELECT), 식별자(users), 연산자(=) 등의 토큰 단위로 쪼갭니다.
2. 구문 분석(Syntactic Analysis, Parser): 문법 규칙을 검증하고 계층적인 추상 구문 트리(AST)를 생성합니다.
3. 쿼리 최적화기(Optimizer) 및 플래너: AST를 바탕으로 테이블 통계 정보를 대입하여 논리적/물리적 실행 계획(Execution Plan)을 수립합니다.

공백이나 대소문자 포맷팅 자체가 물리적 실행 속도를 바꾸지는 않지만, 표준화된 포맷팅은 파서의 AST 트리 구조를 시각적으로 그대로 반영하여 개발자가 쿼리의 실행 순서와 카디널리티를 즉각 직관적으로 파악할 수 있게 돕습니다.

• 예약어 대문자 표기: SELECT, FROM, WHERE, LEFT JOIN, GROUP BY 등 SQL 표준 예약어는 항상 대문자로 작성하여, 소문자 스네이크 케이스로 작성된 테이블명 및 컬럼명과 시각적으로 명확히 분리합니다.
• 주요 절(Clause) 들여쓰기: 주 쿼리 절은 컬럼 0번 줄에 맞추고, 조회 컬럼 목록, 조인 조건(ON), 필터 조건(AND, OR)은 2칸 또는 4칸 들여씁니다.
• 심층 서브쿼리 대신 CTE(WITH 절) 활용: 깊게 중첩된 인라인 뷰(FROM (SELECT ...)) 대신 상단에 명명된 공통 테이블 표현식(CTE)을 사용하여 쿼리 파이프라인을 하향식(Top-down)으로 읽히게 재구성합니다.

-- ❌ 나쁜 예시: 가독성이 극도로 떨어져 실수 유발
select u.id,u.name,count(o.id) as orders_cnt,sum(o.amount) from users u left join orders o on u.id=o.user_id where u.created_at >= '2026-01-01' and u.status = 'active' group by u.id,u.name having sum(o.amount) > 1000 order by orders_cnt desc;

-- ✅ 모범 예시: 일관된 들여쓰기와 CTE로 명확한 파이프라인 구성
WITH active_users AS (
    SELECT id, name
    FROM users
    WHERE created_at >= '2026-01-01'
      AND status = 'active'
)
SELECT
    u.id,
    u.name,
    COUNT(o.id) AS orders_cnt,
    SUM(o.amount) AS total_spent
FROM active_users u
LEFT JOIN orders o
    ON u.id = o.user_id
GROUP BY
    u.id,
    u.name
HAVING SUM(o.amount) > 1000
ORDER BY orders_cnt DESC;

복잡한 통계 쿼리에서 사용되는 윈도우 함수(OVER (PARTITION BY ... ORDER BY ...))는 행마다 별도의 들여쓰기로 분리해야 파티션 경계 오류를 방지할 수 있습니다.

또한 CASE WHEN 조건문은 WHEN, THEN, ELSE, END 키워드를 수직으로 정렬하여 누락된 조건 분기가 없는지 한눈에 검증할 수 있도록 작성하는 것이 업계 표준입니다.

팀 내 코드 리뷰에서 소모적인 띄어쓰기 논쟁을 없애려면 자동화된 린터를 도입해야 합니다:

1. SQLFluff: PostgreSQL, MySQL, BigQuery, Snowflake 등 방언(Dialect)을 지원하는 가장 강력한 오픈소스 SQL 린터 겸 포맷터입니다.
2. DevUtils SQL Formatter: 운영 중인 복잡한 쿼리나 ORM이 자동 생성한 난독화 로그를 안전하게 로컬 브라우저에서 즉시 정돈할 수 있습니다. 코드가 외부 서버로 전송되지 않아 보안상 안전합니다.