재편집 전 원문 백업 | SECTION 01 | 2026-10-14
PostgreSQL 프로젝트에 투입되기 전, SQL 작성 습관부터 점검하자.
원리는 몰라도, 이것만은 기억하자!
SQL REMINDER는 PostgreSQL 기반 차세대·신규 구축·전환 프로젝트에 참여하는 개발자를 위한 SQL 실무 준비서입니다. SQL 튜닝 이론을 깊이 배우기 전에, 개발 현장에서 반드시 지켜야 할 작성 규칙과 알아두면 유용한 PostgreSQL 활용 패턴을 정리합니다.
1. 왜 SQL REMINDER인가?
프로젝트가 시작되면 개발자는 짧은 기간에 많은 SQL을 작성합니다. 이때 성능을 충분히 고려하지 않고 작성한 SQL은 데이터가 늘어나거나 여러 사용자가 동시에 실행할 때 문제를 드러낼 수 있습니다.
실제 튜닝 기록에서도 다음과 같은 작성 패턴이 발견되었습니다.
•
WHERE 조건의 컬럼 가공: 날짜 컬럼에 함수나 형변환을 적용해 일반적인 인덱스 검색이 어려워진 사례
•
조인 조건 누락·오류: 필요한 조인 조건이 빠지거나 잘못된 컬럼을 참조해 결과 건수가 불필요하게 증가한 사례
•
비효율적인 반복 처리: 스칼라 서브쿼리나 복잡한 인라인 뷰에서 많은 반복 접근이 발생한 사례
•
SQL 구조와 접근 경로의 불일치: OR 조건, 정렬, 파티션 조건 등의 작성 방식이 검색 효율에 영향을 준 사례
이 중 적지 않은 문제는 SQL 작성 단계에서 미리 점검할 수 있습니다. SQL REMINDER는 문제가 생긴 뒤 고치는 방법보다 문제가 될 만한 SQL을 처음부터 피하는 방법에 초점을 맞춥니다.
그림 제작 메모 ① — 사후 튜닝보다 사전 예방
•
목적: SQL REMINDER가 필요한 이유를 한눈에 전달
•
구성: 왼쪽은 '개발 → 배포 → 성능 문제 발견 → 긴급 튜닝', 오른쪽은 '개발 전 규칙 숙지 → SQL 작성·점검 → 배포'
•
핵심 문구: '고치기 전에, 처음부터 제대로 작성하자'
•
표현: 두 경로를 나란히 비교하는 간단한 흐름도. 실제 통계나 개선율 수치는 넣지 않음
•
상태: 이미지 미삽입, 추후 제작
2. 이 강의의 목표
이 강의의 목표는 SQL 튜너를 양성하는 것이 아닙니다.
개발자가 다음 세 가지를 실천하도록 돕는 것이 목표입니다.
1.
피해야 할 SQL 작성 패턴을 기억한다. 컬럼 가공, 조인 조건 누락, 불필요한 중복 처리 같은 실수를 예방한다.
2.
더 나은 SQL 작성 방법을 선택한다. PostgreSQL의 특성을 고려해 조회·조인·집계·최신 데이터 검색을 작성한다.
3.
작성한 SQL을 스스로 점검한다. 배포 전에 결과의 정확성과 기본적인 성능 위험을 확인한다.
핵심 메시지: 원리를 모두 설명할 수 있을 필요는 없습니다. 다만 어떤 SQL을 작성해야 하고, 어떤 패턴을 조심해야 하는지는 기억해야 합니다.
3. 누가 읽어야 하는가?
주요 대상
•
PostgreSQL 기반 차세대 프로젝트에 새로 투입되는 개발자
•
Oracle·MySQL 등 다른 DBMS에서 PostgreSQL로 전환하는 개발자
•
PostgreSQL로 신규 시스템을 구축하거나 기존 시스템을 고도화하는 개발자
•
SQL 코드 리뷰와 배포 전 품질 점검을 수행하는 개발 리더
학습 전제
기본적인 SELECT, INSERT, UPDATE, DELETE, JOIN 문법을 알고 있다면 학습할 수 있도록 구성합니다. 옵티마이저 내부 원리, 실행계획 심화 분석, 전문 튜닝 경험을 전제로 하지 않습니다.
4. 무엇을 배우는가?
강의 내용은 두 축으로 구성됩니다.
첫째, 반드시 지켜야 할 SQL 작성 규칙
자료형, WHERE 조건, 인덱스 활용, 조인 조건, 불필요한 집계·정렬 등 기존 SQL GUIDE의 규칙을 PostgreSQL 기준으로 재검토합니다.
둘째, 알아두면 유용한 PostgreSQL 작성 노하우
LATERAL, WITH와 MATERIALIZED, 마지막 데이터 검색, DISTINCT ON, 효율적인 페이징 등 현장에서 활용할 수 있는 SQL 패턴을 다룹니다.
설명은 가능한 한 규칙 → BAD SQL → GOOD SQL → 기억할 이유 → 예외·점검 사항 순서로 진행합니다.
그림 제작 메모 ② — 한 가지 규칙을 학습하는 방법
•
목적: 본 강의의 반복 학습 구조를 안내
•
구성: '기억할 규칙' → 'BAD / GOOD SQL 비교' → '왜 그런가?' → '주의할 예외' → '개발 전 체크'
•
형태: 가로형 5단계 흐름도 또는 한 장의 학습 카드
•
핵심 문구: '원리보다 실천, 암기보다 적용'
•
상태: 이미지 미삽입, 추후 제작
실습 데이터 모델 — BIG 계열 테이블
앞으로의 강의에서는 주문·회원·매장·주문상세·이벤트응모로 이루어진 BIG 계열 실습 테이블을 주요 예제로 사용합니다. 테이블명과 컬럼명, PK/FK 표기는 제공된 StartUPTuning_PG_20250616.pdf 5페이지 「ERD for Tuning : Logical & Physical-startdbpg」를 기준으로 정리했습니다.
BIG 계열 ERD
원본 ERD의 물리 테이블명과 PK/FK 표기를 바탕으로 새로 정리한 관계도입니다. 연결선은 논리적 관계를 표시하며, 실제 DB의 FK 제약조건 존재를 의미하지는 않습니다.
주요 테이블과 역할
테이블 | 역할 | PK | 주요 FK |
ms_mbr_big | 회원 마스터 | mbr_id | — |
ms_shop_big | 매장 마스터 | shop_id | — |
tr_ord_big | 주문 | ord_no | mbr_id, shop_id |
tr_ord_det_big | 주문상세 | ord_no, ord_det_no | ord_no, item_id |
tr_event_entry_big | 이벤트응모 | event_id, entry_no | event_id, shop_id, mbr_id |
주요 테이블 관계
•
회원 1 : N 주문 — ms_mbr_big.mbr_id = tr_ord_big.mbr_id
•
매장 1 : N 주문 — ms_shop_big.shop_id = tr_ord_big.shop_id
•
주문 1 : N 주문상세 — tr_ord_big.ord_no = tr_ord_det_big.ord_no
•
회원·매장 1 : N 이벤트응모 — tr_event_entry_big.mbr_id, shop_id가 각각 회원·매장 키를 참조
•
추가 참조 대상 — tr_ord_det_big.item_id는 일반 ms_item을, tr_event_entry_big.event_id는 일반 ms_event를 참조하는 것으로 물리 모델에 표시됨 (BIG 계열 5개 테이블의 관계도에는 미포함)
테이블별 컬럼 확인
tr_ord_big — 주문
ms_mbr_big — 회원
ms_shop_big — 매장
tr_ord_det_big — 주문상세
tr_event_entry_big — 이벤트응모
원본 자료 확인 사항
•
PDF 5페이지 ERD에는 테이블·컬럼명과 논리적인 PK/FK 표기가 있지만, 정확한 PostgreSQL 자료형, NULL 허용 여부, FK 제약조건 정의는 제시되지 않습니다. 따라서 이 페이지에서 임의로 확정하지 않았습니다.
•
함께 제공된 StartUPTuning_PG_SQL_Script.sql에는 tr_ord_big.ord_ymd를 참조하는 SQL이 있으나, 해당 컬럼은 PDF 5페이지 ERD에 표시되지 않습니다. DB의 실제 정의와 비교해 최종 반영해야 합니다.
•
실습 스크립트의 tr_ord_big_p는 별도로 생성하는 파티션 실습용 테이블이므로 tr_ord_big의 원본 DDL과 혼동하지 않습니다.
이 모델로 학습하는 대표 주제: WHERE 조건과 인덱스 검색, 회원–주문 JOIN, 주문–주문상세의 1:N 관계, 반복 서브쿼리, LATERAL, 그룹별 최신 주문 조회, 집계 및 페이징.
5. 전체 강의 구성
PART 0 — 소개
PART 1 — SQL 작성의 필수 규칙
PART 2 — 실전 SQL 작성 노하우
PART 3 — PostgreSQL 실전 개발
PART 4 — 배포 전 최종 점검
•
6. 규칙은 이렇게 구분합니다
•
MUST | 필수 규칙: 개발 단계에서 기본적으로 지켜야 할 SQL 작성 원칙
•
TIP | 실전 노하우: 특정 요구사항을 더 효율적으로 처리할 수 있는 작성 패턴
•
CHECK | 점검 항목: 데이터 분포, 인덱스, 실행계획 등에 따라 유불리가 달라져 확인이 필요한 내용
주의: 어떤 SQL 패턴도 모든 상황에서 무조건 빠르지는 않습니다. SQL REMINDER의 GOOD 예제는 무조건적인 정답이 아니라, 제시한 전제에서 권장하는 작성 방향입니다. 결과의 정확성과 실제 성능은 별도로 검증해야 합니다.
7. 교육 내용은 어디에서 왔는가?
기존 SQL GUIDE for ORACLE / SQL GUIDE for MySQL에 정리된 규칙을 출발점으로 삼고, PostgreSQL 강의·실습 자료와 실제 튜닝 기록을 참고해 내용을 확장합니다.
특히 에는 인덱스, 컬럼 가공 제거, 조인 조건 점검, LATERAL, MATERIALIZED 등 여러 개선 기법이 분류되어 있습니다. 이 사례들은 교육 주제와 실전 교훈을 발굴하기 위한 근거로 활용하되, 개별 기법을 보편적인 성능 규칙으로 단정하지 않습니다.
8. 강의를 마치고 나면
새로운 프로젝트에서 SQL을 작성하거나 리뷰할 때 다음 질문을 먼저 떠올릴 수 있어야 합니다.
•
WHERE 조건이 인덱스 활용을 불필요하게 방해하고 있지는 않은가?
•
조인 조건과 결과 건수가 업무 의도에 맞는가?
•
불필요한 반복 조회, 집계, 정렬이 있는가?
•
마지막 데이터 한 건이나 페이징을 더 적절한 패턴으로 작성할 수 있는가?
•
PostgreSQL 실행계획으로 기본적인 위험 신호를 확인했는가?
SQL REMINDER의 목표는 SQL을 잘 고치는 개발자가 되기 전에, 처음부터 좋은 SQL을 작성하는 개발자가 되는 것입니다.