실무에서 SQL을 다루다 보면 누구나 한 번쯤은 이런 경험이 있을 겁니다. 한 줄짜리 쿼리로 시작한 게 어느새 80줄짜리 괴물이 되어 있고, 두 달 전에 내가 짠 쿼리를 열어보면 대체 무슨 의도였는지 감이 안 잡히는 상황. 저도 주니어 시절에 SELECT * FROM 으로 시작하는 한 줄짜리 쿼리를 무한히 늘려가며 개발했던 기억이 납니다.
SQL 포매팅은 단순히 예쁘게 보이려는 게 아닙니다. 잘 정리된 쿼리는 디버깅 시간을 줄여주고, 코드 리뷰를 수월하게 만들고, 결정적으로 버그를 예방합니다. 조건 하나 빠뜨려서 전체 테이블을 UPDATE 해버린 경험이 있다면 공감하실 거예요.
기본 원칙: 키워드는 왼쪽 정렬
가장 먼저 챙겨야 할 규칙은 SQL 키워드를 왼쪽에 정렬하는 것입니다. SELECT, FROM, WHERE, GROUP BY, ORDER BY 같은 주요 키워드가 같은 열에 오면 쿼리의 구조가 한눈에 들어옵니다.
흔히 보는 안 좋은 예시가 모든 걸 한 줄에 쓰는 것입니다. SELECT u.id, u.name, u.email FROM users u WHERE u.created_at > '2024-01-01' AND u.status = 'active' ORDER BY u.created_at DESC 이런 식으로요. 이걸 키워드 기준으로 줄을 나누면 어디서 필터링하고 어떤 순서로 정렬하는지 바로 보입니다.
들여쓰기는 스페이스 2칸이든 4칸이든 상관없지만, 팀 내에서 하나로 통일하는 게 중요합니다. 저희 팀은 4칸을 쓰는데, 이건 순전히 취향의 문제예요.
JOIN을 깔끔하게 쓰는 법
JOIN이 3개 이상 들어가면 슬슬 쿼리가 복잡해지기 시작합니다. 이때 제가 쓰는 방법은 각 JOIN을 같은 들여쓰기 레벨에 두고, ON 조건을 바로 아래에 한 단계 들여서 쓰는 겁니다.
특히 LEFT JOIN과 INNER JOIN이 섞여 있을 때, 각 JOIN 타입을 명시적으로 써주는 습관이 좋습니다. 그냥 JOIN이라고만 쓰면 나중에 "이게 INNER였나 LEFT였나" 고민하게 되거든요. 귀찮아도 INNER JOIN이라고 풀어 쓰세요.
ON 조건이 여러 개일 때는 AND를 줄바꿈해서 쓰면 좋습니다. 한 줄에 우겨넣으면 조건 하나를 놓치기 쉬워요. 실제로 ON 조건을 빠뜨려서 카테시안 곱이 발생하는 사고가 생각보다 자주 일어납니다.
서브쿼리, 어디까지 허용할 것인가
서브쿼리는 SQL의 강력한 기능이지만, 중첩이 3단계를 넘어가면 읽기가 매우 힘들어집니다. 직접 써보니 서브쿼리가 2단계 이상이면 CTE(Common Table Expression)로 바꾸는 게 거의 항상 낫더군요.
WHERE 절 안에 있는 서브쿼리는 괄호와 들여쓰기로 범위를 명확히 해야 합니다. WHERE id IN (SELECT ...) 형태라면 서브쿼리의 SELECT를 다음 줄에 써서 시각적으로 분리하세요.
SELECT 절의 스칼라 서브쿼리는 특히 위험합니다. 행 수가 많아지면 성능이 급격히 나빠지는데, 포매팅이 안 되어 있으면 이런 서브쿼리가 숨어 있는 걸 놓치기 쉬워요.
CTE로 가독성 한 단계 올리기
CTE는 SQL 가독성의 게임체인저입니다. WITH 문으로 임시 결과셋에 이름을 붙여두면, 메인 쿼리가 놀라울 만큼 깔끔해집니다.
좋은 CTE 이름은 그 자체로 문서 역할을 합니다. active_users, monthly_revenue, recent_orders처럼 결과가 뭔지 바로 알 수 있는 이름을 쓰세요. temp1, sub_query 같은 이름은 아무 정보도 주지 않습니다.
CTE가 여러 개일 때는 각 CTE 사이에 빈 줄을 넣어 구분하고, 의존 관계가 있다면 위에서 아래로 순서대로 나열합니다. 마지막 CTE를 참조하는 메인 SELECT가 가장 아래에 오는 구조가 읽기 편합니다.
팀에서 스타일 통일하는 현실적인 방법
혼자 개발할 때는 자기만의 스타일이면 되지만, 팀 프로젝트에서는 통일이 필수입니다. 그런데 SQL 포매팅 규칙을 문서로 정리해놓고 모두가 따르게 하는 건 현실적으로 어렵습니다.
가장 효과적인 방법은 자동 포매터를 도입하는 것입니다. 코드 저장 시 자동으로 포매팅되게 해두면 스타일 논쟁 자체가 사라져요. SQL 포매터 도구를 팀 전체가 같은 설정으로 사용하면, 누가 작성했든 동일한 스타일로 통일됩니다.
코드 리뷰에서도 포매팅 얘기는 빼고 로직에만 집중할 수 있으니 일석이조입니다. 처음에 "이 스타일 좀 별로인데"라는 불만이 나올 수 있지만, 2주만 쓰면 다들 적응합니다.
실수를 줄이는 포매팅 습관들
콤마를 앞에 쓸지 뒤에 쓸지도 자주 나오는 논쟁거리입니다. SELECT 절에서 컬럼을 나열할 때, 저는 콤마를 뒤에 쓰는 편인데 앞에 쓰는 것도 장점이 있어요. 앞에 쓰면 컬럼 추가/삭제 시 diff가 깔끔합니다.
WHERE 1=1 트릭도 실무에서 꽤 유용합니다. 동적 쿼리를 만들 때 모든 조건을 AND로 시작할 수 있어서 조건 추가/제거가 편해요. 포매팅 관점에서도 각 조건이 동일한 형태를 유지합니다.
주석도 적극적으로 쓰세요. 특히 비즈니스 로직이 담긴 조건에는 왜 그 조건이 필요한지 한 줄 주석을 달아두면, 나중에 "이 조건 왜 있지?" 하고 고민하는 시간을 아낄 수 있습니다. 다만 너무 당연한 것에 주석을 달면 오히려 노이즈가 되니까, 의도가 불명확한 부분에만 달아주세요.
정리하며
SQL 포매팅은 작은 습관이지만 쌓이면 큰 차이를 만듭니다. 당장 내일 출근해서 할 수 있는 것부터 시작해보세요. 키워드 줄바꿈, JOIN 정리, 서브쿼리 대신 CTE 쓰기. 이 세 가지만 지켜도 쿼리 품질이 확 달라집니다. 자동 포매터를 활용하면 이런 규칙을 의식하지 않아도 일관된 스타일을 유지할 수 있으니, 팀 도입을 적극 추천합니다.