SQL이 읽기 좋아져도 같은 쿼리인지는 별도 확인
SQL Formatter는 입력 텍스트의 줄바꿈과 키워드를 정리하는 도구입니다. 현재 구현은 SQL 문법을 분석하는 파서 대신 문자열 치환을 사용합니다. 그 결과 따옴표 안의 값이나 비교 연산자가 달라질 수 있어, 복사한 결과를 곧바로 실행용 쿼리로 사용하기에는 한계가 있습니다.
이 글은 2026-09-23 현재 코드의 동작과 비교 방법을 정리합니다. 문법 검사·쿼리 최적화·데이터베이스 실행 기능이 있다는 뜻은 아니며, 알려진 변형 문제를 고친 버전의 안내도 아닙니다.
먼저 원본을 남기고 단순 예제로 비교
표·컬럼 이름이 가상인 다음 조회문으로 시작할 수 있습니다.
select id,title from demo_posts where id=1;
키워드 대문자 옵션으로 정렬하면 SELECT·FROM·WHERE가 나뉘어 읽기 쉬워집니다. 이때 비교할 것은 모양뿐 아니라 demo_posts, id, title, 조건 값 1이 유지됐는지입니다. 도구는 이 테이블이 실제로 존재하는지 확인하지 않습니다.
전체 선택 후 원본을 덮어쓰기보다 원본과 결과를 따로 두고 확인합니다. 눈으로 찾기 어려우면 텍스트 비교 도구를 사용할 수 있지만, 텍스트 차이가 작다는 사실도 SQL 의미가 같음을 보증하지는 않습니다.
현재 구현에서 확인해야 하는 네 가지 사례
1. 따옴표 안의 연속 공백
SELECT 'A B';
원본의 A와 B 사이에는 공백이 두 개 있습니다. 현재 정렬 전처리는 연속 공백을 한 개로 줄이므로 결과의 문자열이 'A B'로 바뀝니다. 화면 정리가 데이터 값 변경으로 이어지는 사례입니다.
2. 문자열 안의 키워드
SELECT 'from';
키워드 대문자 변환은 따옴표 안의 단어도 바꿀 수 있어 'FROM'이 됩니다. 이것은 SQL의 FROM 절을 대문자로 정리한 것과 다릅니다. 로그 메시지, 대소문자 구분 값, 식별 코드라면 변경이 중요할 수 있습니다.
3. 문자열 안의 주석 표식
SELECT 'a--b';
주석 제거 함수는 -- 뒤를 주석으로 처리해 현재 결과가 SELECT 'a처럼 잘릴 수 있습니다. /* ... */도 따옴표 안과 밖을 구분하지 않는 방식입니다. 또한 현재 압축 함수는 주석 제거 옵션과 별개로 내부에서 주석 제거를 호출하므로, 옵션을 끄면 압축에서도 항상 보존된다고 생각하면 안 됩니다.
4. 비교 연산자 사이의 공백
SELECT 2>=1;
현재 정렬 전처리는 =와 >를 각각 치환하는 순서 때문에 > =처럼 연산자를 분리할 수 있습니다. 문자열이 없는 짧은 SQL에서도 문제가 발생할 수 있다는 뜻입니다. 이런 결과는 실행 전에 원문으로 되돌리고, 단순한 보기용 정리 결과로도 정확성을 다시 확인해야 합니다.
주석과 문자열을 구분해야 하는 이유
SQL에서 따옴표, 주석, 식별자, 연산자는 서로 다른 문법 요소입니다. PostgreSQL에는 달러 인용 문자열 같은 문법도 있어 모든 경우를 몇 개의 정규식으로 동일하게 다루기 어렵습니다. 구체적인 구분은 PostgreSQL 어휘 구조 문서를 참고할 수 있습니다.
도구를 개선하려면 지원할 SQL 방언을 정하고 문법 요소를 구분하는 방식으로 바꾼 뒤, 위 예제들의 값과 연산자가 유지되는지 검사해야 합니다. 단순히 공백 치환 한 줄만 바꾸면 키워드·주석·압축의 다른 문제까지 모두 해결되지는 않습니다.
결과를 사용할 때의 확인 순서
- 원본을 별도 파일이나 편집기 탭에 보관합니다.
- 사용한 정렬·압축·키워드·주석 옵션을 기록합니다.
- 따옴표 안의 값, 주석 경계, 비교 연산자를 원문과 대조합니다.
- 실제 사용할 DB 방언을 지원하는 도구와 개발 환경에서 문법을 확인합니다.
- 실행이 필요하다면 별도 테스트 데이터와 권한 범위에서 확인합니다.
다운로드되는 .sql 파일도 같은 변환 결과입니다. 파일로 저장됐다는 이유로 검증이 추가되는 것은 아닙니다. 현재 문제가 있는 입력은 원본을 유지하고 다른 방식을 선택해야 합니다. 이 글의 보강은 결과를 과신하지 않도록 사용 범위를 설명하는 작업이며 SQL Formatter 기능 개선과 전체 검증은 별도로 남아 있습니다.
첫 댓글을 남겨보세요.