SQL 포맷터

여러 SQL 방언을 지원하며 SQL 쿼리를 읽기 좋게 정리합니다.

SQL 쿼리의 줄바꿈과 들여쓰기를 정리하고, 방언과 키워드 대소문자를 골라 읽기 좋은 형태로 바꿉니다.

사용 순서

방언 목록에서 DB에 맞는 항목을 고릅니다. 특정 DB 문법이 아니면 Standard SQL을 씁니다.
키워드 대소문자(UPPERCASE, lowercase, Preserve)와 들여쓰기 방식(Standard, Tabular left, Tabular right)을 고릅니다.
SQL 쿼리 칸에 쿼리를 붙여 넣고 서식이 적용된 쿼리 칸에서 결과를 복사합니다.

예시

기본 예시 select field1,field2,field3 from my_table where my_condition; 는 SELECT 아래에 field1, field2, field3이 각각 들여써진 여러 줄로 나오고, FROM과 WHERE가 대문자로 바뀝니다.

한계

문법 검사를 하지 않으므로 틀린 SQL도 가능한 범위에서 서식이 적용됩니다. 선택한 방언의 규칙으로 줄을 나누므로 방언을 잘못 고르면 줄바꿈이 어색해질 수 있습니다. 모든 DB 확장 문법을 완벽하게 나누지는 못합니다.

보안 주의

서식 도구는 쿼리의 의미를 바꾸지 않도록 설계되어 있지만, 실행 전에 확인할 부분은 남습니다. 운영 DB에서 실행할 UPDATE나 DELETE라면 서식 전후의 WHERE 절이 그대로 있는지 비교하세요.

배경 지식

SQL은 선언형 언어라 줄바꿈과 들여쓰기가 실행 결과를 바꾸지 않습니다. 그래서 긴 쿼리를 읽기 쉽게 정리하는 서식 도구가 많이 쓰입니다. SELECT, FROM, WHERE, JOIN 같은 절마다 줄을 나누면 쿼리의 구조가 한눈에 들어옵니다. 들여쓰기는 서브쿼리나 조건식이 어디서 시작하고 끝나는지 보여 주는 역할을 합니다.

방언은 같은 SQL이라도 날짜 함수, 식별자 따옴표, 행 개수 제한 문법이 DB마다 달라서 생기는 차이입니다. 서식 도구는 방언에 따라 키워드 목록과 구문 규칙을 바꿔 적용합니다. BigQuery의 백틱 식별자와 PostgreSQL의 큰따옴표 식별자가 대표적인 예입니다.

팀에서 쿼리 형식을 통일하면 코드 리뷰에서 로직 변화에만 집중할 수 있습니다. 리뷰 전에 서식을 맞추는 습관이 있으면 서식만 바뀐 불필요한 diff가 줄어듭니다. 저장소에 포맷 규칙을 문서로 남겨 두면 도구마다 결과가 달라지는 문제도 줄어듭니다. 핵심은 같은 방언과 설정을 팀 전체가 공유하는 것입니다.

자주 묻는 질문

키워드 대소문자는 어떤 것을 고르는 게 좋나요?

관례상 SELECT, FROM 같은 키워드는 대문자로 쓰고 열과 테이블 이름은 소문자로 두는 방식이 많습니다. 기존 프로젝트에 규칙이 있으면 그것을 따르고, 없으면 Preserve로 원본 대소문자를 유지하는 방법도 있습니다.

PostgreSQL과 MySQL 쿼리를 같은 설정으로 정리해도 되나요?

문법 차이에 따라 줄 나눔이 달라질 수 있으므로 쿼리에 맞는 방언을 골라야 합니다. 식별자를 감싸는 따옴표 처리가 DB마다 다르기 때문에, 방언을 잘못 고르면 결과가 어색해집니다.

이 도구로 쿼리가 실행 가능한지 확인할 수 있나요?

아니요. 이 도구는 문법을 검사하지 않고 서식만 적용합니다. 실행 가능 여부는 DB 클라이언트에서 실행하거나 EXPLAIN으로 계획을 확인해야 알 수 있습니다.