[Language] SQL

SQL란?

---

SQL(Structured Query Language)은 관계형 데이터베이스에서 데이터를 정의하고 조회하며 변경하기 위한 선언형 언어이다. 개발자가 원하는 결과의 조건과 형태를 SQL로 표현하면, 데이터베이스 관리 시스템(DBMS)은 통계, 인덱스, 제약 조건, 트랜잭션 상태를 바탕으로 실제 실행 계획을 선택한다.

SQL은 단순한 조회 문법이 아니라 데이터 모델, 무결성 제약, 권한, 트랜잭션, 뷰, 함수, 저장 프로시저까지 포괄하는 데이터베이스 인터페이스이다. ISO/IEC 9075 표준은 SQL 문법과 처리 결과의 개념 틀을 정의하며, PostgreSQL, MySQL, Oracle, SQL Server 같은 제품은 표준을 기반으로 각자의 확장과 실행 특성을 제공한다.

SQL의 핵심은 데이터를 어떻게 가져올지 절차적으로 지시하는 것이 아니라, 어떤 관계와 조건의 결과가 필요한지 선언하는 데 있다.

SQL 문이 옵티마이저와 실행 엔진을 거쳐 테이블, 인덱스, 트랜잭션 로그를 사용하는 과정을 단순화한 그림이다.

왜 SQL이 등장했는가

---

초기 데이터베이스 접근은 파일 구조나 탐색 경로에 강하게 묶여 있었다. 애플리케이션이 데이터 저장 방식까지 알아야 했기 때문에 구조 변경은 곧 코드 변경으로 이어졌다. 관계형 모델과 SQL은 데이터의 논리 구조를 테이블, 행, 열, 관계로 표현하고, 물리 저장 방식은 DBMS가 감추도록 만든다.

이 분리는 실무에서 큰 의미가 있다. 테이블 설계, 인덱스 추가, 실행 계획 개선, 파티셔닝 같은 물리 최적화는 애플리케이션의 질의 의도를 유지하면서 수행할 수 있다. 반대로 잘못 작성된 SQL은 DBMS가 아무리 좋아도 불필요한 스캔, 잠금 경합, 과도한 정렬과 조인을 유발한다.

SQL은 애플리케이션과 데이터 저장 구조 사이의 결합을 낮추고, DBMS가 최적화할 수 있는 공통 표현을 제공한다.

핵심 동작 원리

---

SQL 실행은 보통 파싱, 의미 분석, 재작성, 최적화, 실행 순서로 진행된다. 파서는 문법을 해석하고, 분석기는 테이블과 컬럼, 권한, 타입을 확인한다. 이후 옵티마이저는 가능한 실행 계획을 비교해 비용이 낮은 방식을 선택한다. 이때 인덱스 통계, 행 수 추정, 조인 순서, 필터 선택도, 정렬 비용이 중요하게 작동한다.

개발자가 작성한 SELECT의 논리 순서와 실제 실행 순서는 다를 수 있다. 예를 들어 조인은 작성 순서와 다르게 재배치될 수 있고, 조건은 더 이른 단계로 밀려 내려갈 수 있다. 그래서 SQL 성능 튜닝은 문법 암기보다 실행 계획을 읽고 데이터 분포와 인덱스 설계를 함께 보는 능력이 중요하다.

SQL 성능은 문장 자체만으로 결정되지 않고, 데이터 분포, 통계, 인덱스, 조인 전략, 트랜잭션 상태가 함께 결정한다.

트랜잭션과 일관성 모델

---

SQL 기반 DBMS는 여러 사용자가 동시에 데이터를 읽고 쓰는 상황을 전제로 한다. 트랜잭션은 여러 SQL 문을 하나의 작업 단위로 묶고, COMMIT 또는 ROLLBACK으로 결과를 확정하거나 취소한다. PostgreSQL 문서처럼 일반적인 트랜잭션은 BEGIN과 COMMIT 사이의 SQL 명령으로 구성된다.

격리 수준은 동시성과 정확성 사이의 트레이드오프를 만든다. SQL 표준은 Read Uncommitted, Read Committed, Repeatable Read, Serializable 같은 격리 수준을 정의하고, DBMS별 구현은 MVCC, 잠금, 직렬화 검증 방식에 따라 차이가 난다. 높은 격리 수준은 이상 현상을 줄이지만 대기, 재시도, 처리량 감소를 만들 수 있다.

SQL을 운영 환경에서 다룬다는 것은 조회 문법뿐 아니라 트랜잭션 경계, 격리 수준, 잠금 경합, 재시도 전략을 함께 설계한다는 뜻이다.

실무 사용 방식과 아키텍처상 위치

---

SQL은 백엔드 애플리케이션, 배치 작업, 데이터 분석, 운영 리포트, BI 도구, 마이그레이션 스크립트에서 공통적으로 사용된다. OLTP 시스템에서는 짧고 예측 가능한 트랜잭션, 적절한 인덱스, 제한된 결과 집합, 명확한 제약 조건이 중요하다. 분석성 질의에서는 대량 스캔, 집계, 윈도 함수, 파티션, 컬럼형 저장소와의 조합이 더 중요해진다.

• 애플리케이션 계층에서는 ORM을 사용하더라도 핵심 SQL과 실행 계획을 이해해야 한다.
• 운영 계층에서는 느린 쿼리 로그, 락 대기, 인덱스 사용률, 커넥션 풀, 복제 지연을 관찰해야 한다.
• 데이터 계층에서는 스키마 변경, 마이그레이션, 백필, 파티션 관리가 서비스 가용성과 직접 연결된다.

SQL은 애플리케이션 코드 뒤에 숨은 세부 구현이 아니라, 서비스 성능과 데이터 무결성을 좌우하는 핵심 계약이다.

선택 기준과 트레이드오프

---

SQL 기반 관계형 DBMS는 정규화된 데이터, 강한 일관성, 복잡한 조인, 명확한 제약 조건, 트랜잭션이 중요한 시스템에 적합하다. 주문, 결제, 계정, 재고, 권한, 정산처럼 데이터 정합성이 서비스 신뢰도와 직결되는 영역에서 특히 강하다.

반면 스키마가 매우 자주 바뀌거나, 단순 키-값 접근만 필요하거나, 초대형 쓰기 처리량을 위해 강한 일관성을 일부 포기해야 하는 시스템에서는 NoSQL, 로그 기반 저장소, 검색 엔진, 스트리밍 저장소가 더 적합할 수 있다. 또한 SQL은 벤더별 방언과 확장이 존재하므로 이식성이 항상 보장되지는 않는다.

SQL을 선택할 때는 표준 문법의 친숙함보다 데이터 무결성 요구, 쿼리 패턴, 운영 역량, 벤더 확장 의존도를 함께 판단해야 한다.

성능, 보안, 마이그레이션 고려사항

---

성능 측면에서는 인덱스가 가장 흔한 개선 수단이지만, 모든 컬럼에 인덱스를 붙이는 방식은 쓰기 비용과 저장 공간을 증가시킨다. PostgreSQL 문서도 인덱스가 조회를 빠르게 하지만 시스템 전체에 오버헤드를 추가하므로 신중하게 사용해야 한다고 설명한다. 실행 계획 확인, 통계 갱신, N+1 쿼리 제거, 페이지네이션 방식 개선, 배치 크기 조절이 함께 필요하다.

보안 측면에서는 SQL 인젝션 방지를 위해 문자열 결합 대신 바인딩 파라미터와 준비된 문을 사용해야 한다. 권한은 최소 권한 원칙으로 분리하고, 운영 계정과 애플리케이션 계정을 나누는 것이 좋다. 마이그레이션은 락을 오래 잡는 DDL, 대량 백필, 인덱스 생성, 컬럼 타입 변경이 장애로 이어질 수 있으므로 온라인 변경 전략과 롤백 경로를 준비해야 한다.

SQL 운영의 품질은 쿼리 작성 능력뿐 아니라 관찰, 권한 설계, 변경 관리, 장애 시 재시도와 복구 절차에서 드러난다.

사례

---

• ISO/IEC 9075 SQL 표준: ISO는 SQL 구현의 문법과 처리 결과를 설명하기 위한 개념 틀을 ISO/IEC 9075 시리즈로 정의한다. 표준은 제품별 SQL 방언을 비교할 때 기준점이 된다. ISO/IEC 9075-1:2023
• PostgreSQL SQL Language 문서: PostgreSQL은 SQL 문법, 테이블 생성, 데이터 조작, 타입, 함수, 성능 튜닝 관련 내용을 공식 문서의 SQL Language 파트에서 다룬다. SQL이 제품 구현에서 어떻게 확장되는지 확인하기 좋은 사례이다. PostgreSQL Documentation: The SQL Language
• PostgreSQL 트랜잭션과 격리 수준: PostgreSQL 공식 문서는 트랜잭션을 BEGIN, COMMIT으로 묶는 방식과 SQL 표준의 격리 수준을 설명한다. 실무에서 동시성 문제를 설계할 때 확인해야 하는 대표 문서이다. Transactions, Transaction Isolation
• Use The Index, Luke: Markus Winand의 SQL 성능 자료는 개발자 관점에서 인덱스와 실행 계획을 설명한다. ORM을 쓰는 팀도 SQL 성능 병목을 이해해야 하는 이유를 보여주는 널리 알려진 참고 사례이다. Use The Index, Luke