SQL 포맷터

포맷이 유지보수 비용인 이유

한 줄로 뭉친 200자짜리 쿼리는 "지금 당장" 읽기만 어려운 게 아닙니다. 진짜 비용은 6개월 뒤에 옵니다. 조건 하나를 추가하려고 커서를 세 번 잘못 놓고, 리뷰어는 어디가 바뀌었는지 몰라 통째로 다시 읽습니다.

절 단위로 줄이 나뉘어 있으면 git diff 가 "WHERE 절에 조건 한 줄이 추가됨"으로 보입니다. 한 줄짜리 쿼리는 같은 변경이 "이 줄이 통째로 바뀜"으로 나옵니다. 코드 리뷰가 되느냐 마느냐가 여기서 갈립니다.

그래서 정렬은 취향 문제가 아니라, 저장소에 커밋할 SQL이라면 팀 안에서 한 가지 설정으로 통일해 두는 편이 이득입니다. 이 도구의 키워드 대소문자·콤마 위치·들여쓰기 설정은 브라우저에 저장되므로, 한 번 맞춰 두면 계속 같은 모양으로 나옵니다.

콤마 앞이냐 뒤냐 — 오래된 논쟁의 실제 근거

보기에는 취향 싸움 같지만, 앞 콤마(leading comma)를 고집하는 쪽에는 구체적인 이유가 있습니다. SQL은 마지막 항목 뒤의 콤마(trailing comma)를 문법 오류로 봅니다. 자바스크립트와 다른 지점입니다.

-- 줄 뒤 콤마: 마지막 줄에 컬럼을 추가하면 앞줄도 함께 고쳐야 한다
SELECT
  id,
  name,        -- 여기에 콤마 추가를 잊으면 문법 오류
  email
FROM users

-- 줄 앞 콤마: 새 줄만 추가하면 끝. 마지막 줄을 주석 처리해도 안전하다
SELECT
  id
  , name
  , email
FROM users

문자열·주석을 건드리지 않는 것이 왜 결정적인가

인터넷에 굴러다니는 SQL 포맷터 중 상당수는 정규식 치환으로 만들어져 있습니다. "select 를 SELECT 로 바꾸고 from 앞에서 줄을 바꾼다" 식입니다. 평범한 쿼리에서는 잘 돌아갑니다.

문제는 데이터에 그 단어가 들어 있을 때입니다. 이 도구는 SQL을 토큰 단위로 쪼갠 뒤 문자열 리터럴과 주석을 통째로 하나의 토큰으로 다루기 때문에, 안에 무슨 글자가 있든 원문 그대로 나옵니다.

• WHERE memo NOT LIKE '%select from where%' — 정규식 포맷터는 문자열 한가운데서 줄을 바꿔 쿼리를 망가뜨립니다.
• WHERE title = 'Order by 판매량' — 한국어 상품명·게시글 제목에 영문 키워드가 섞이는 일은 흔합니다.
• -- 여기는 order by 를 넣지 말 것 — 주석 안의 단어까지 대문자로 바뀌면 리뷰가 지저분해집니다.
• SELECT '3''4' — 작은따옴표 두 개로 이스케이프한 값의 경계를 정확히 잡습니다.

방언 선택은 언제 의미가 있나

표준·MySQL·PostgreSQL 선택은 문법 검증이 아니라 토큰 경계를 잡기 위한 것입니다. 어떤 문자가 식별자 인용이고 어떤 것이 문자열인지가 방언마다 다릅니다. 아래 경우가 아니면 표준으로 둬도 결과가 같습니다.

한계 — 이건 포맷터지 파서가 아닙니다

문법 오류가 있는 SQL도 토큰 단위로는 정렬됩니다. 실행되지 않을 쿼리가 예쁘게 나올 수 있다는 뜻입니다. 다만 따옴표가 안 닫혔거나 괄호 짝이 안 맞아 토큰 경계가 깨지면 경고를 표시합니다.

ORM이 뱉은 로그를 넣을 때는 플레이스홀더에 주의하세요. ? 나 $1 은 그대로 남고, 파이썬 로거가 %s 로 찍은 쿼리도 값이 채워지지 않은 상태입니다. 실제로 실행해 볼 거라면 로그의 파라미터 배열을 보고 직접 채워야 합니다.

결과 통계의 "서브쿼리 깊이"는 점검의 출발점이 됩니다. 깊이가 3을 넘고 IN (SELECT …) 이 섞여 있으면 한 번 들여다볼 만합니다. 다만 이 도구는 실행 계획을 알지 못하므로, 성능 판단은 반드시 실제 DB의 EXPLAIN 으로 하세요.