데이터베이스에는 어떻게 질문할까? SQL과 SELECT의 원리

정리된 창고가 있다고 해서 필요한 물건이 저절로 손에 들어오는 것은 아니다. 어느 선반에서 무엇을 몇 개 꺼낼지 알려주어야 한다. 데이터베이스도 비슷하다. 고객, 주문, 장비와 정비 기록을 알맞게 나누어 저장해 두었더라도 사용자가 원하는 조건을 전달하지 않으면 화면에 보여줄 결과를 만들 수 없다.

앞선 글에서는 데이터 중복을 줄이고 서로 다른 대상을 나누어 저장하는 정규화를 살펴보았다. 고객 정보는 고객 테이블에, 주문은 주문 테이블에 두면 같은 주소를 여러 번 고치는 문제를 줄일 수 있었다. 대신 지난달 주문이나 특정 고객의 구매내역을 보려면 떨어져 있는 기록 가운데 필요한 것만 골라 다시 연결해야 한다.

이때 관계형 데이터베이스에 원하는 결과를 표현하는 언어가 SQL이다. 사람의 질문을 그대로 알아듣는 것은 아니지만, 무엇을 보고 싶은지, 어느 표에서 찾을지, 어떤 조건을 만족해야 하는지를 일정한 형식으로 적으면 데이터베이스가 그 요청을 처리한다. 이번 글에서는 복잡한 문법을 외우기보다 SELECT가 질문을 결과표로 바꾸는 과정을 따라가 보려 한다.

한줄 요약
SQL의 SELECT문은 저장된 원본을 직접 뒤지는 명령이라기보다, 어느 테이블에서 어떤 열과 행을 가져와 어떤 순서로 보여줄지를 데이터베이스에 전달하는 질문의 형식이다.

화면의 검색창 뒤에서는 질문이 더 구체적으로 바뀐다

쇼핑몰에서 주문내역을 열고 조회 기간을 ‘최근 3개월’로 선택했다고 해보자. 사용자가 한 일은 버튼을 누른 것뿐이지만, 서버는 그 선택을 데이터베이스가 처리할 수 있는 조건으로 바꾼다. 로그인한 고객의 주문이며, 정해진 날짜 이후에 발생한 기록만 가져오고, 가장 최근 주문부터 보여달라는 식이다.

업무체계에서도 사정은 다르지 않다. 장비번호를 입력하고 장애 이력을 검색하면 화면 뒤에서는 장비 식별값이 일치하는 기록만 골라 발생 시각 순으로 정리하는 요청이 만들어진다. 사용자는 표와 버튼을 보지만 데이터베이스는 테이블, 열, 조건과 순서로 이루어진 질문을 받는다.

SQL은 Structured Query Language의 약자다. 흔히 데이터베이스 언어라고 부르지만 하나의 프로그램처럼 순서대로 모든 작업을 지시하는 언어와는 성격이 조금 다르다. 사용자는 대체로 ‘어떤 결과가 필요한가’를 표현하고, 실제로 어느 행부터 읽고 어떤 경로를 이용할지는 데이터베이스가 판단한다.

같은 SQL이라도 데이터베이스 제품에 따라 세부 문법과 기능에는 차이가 있다. 그러나 관계형 데이터베이스에서 데이터를 조회할 때 SELECT로 가져올 내용을 정하고, FROM으로 출처를 지정하며, WHERE로 조건을 거는 기본 생각은 널리 공유된다. 이 뼈대를 이해하면 긴 문장을 보아도 어디에서 무엇을 찾는 질문인지 짚어낼 수 있다.

SELECT는 보고 싶은 열을, FROM은 찾아갈 표를 정한다

고객 테이블에 고객번호, 이름, 전화번호, 주소와 가입일이 들어 있다고 하자. 이름과 가입일만 확인하는 업무라면 모든 열을 가져올 필요가 없다. 이때 질문은 다음처럼 간단하게 시작할 수 있다.

SELECT customer_name, joined_at
FROM customers;

SELECT 뒤에는 결과에서 보고 싶은 열을 적고, FROM 뒤에는 그 열이 들어 있는 테이블을 적는다. 실행 결과는 원본 테이블 전체가 아니라 이름과 가입일 두 열로 이루어진 새로운 결과표가 된다. 원본 자료를 다른 곳으로 옮기는 것이 아니라, 요청한 순간 필요한 모양으로 읽어 보여주는 셈이다.

별표를 사용하면 모든 열을 가져올 수 있다. 연습할 때는 편하지만 실제 업무에서는 필요한 열을 분명히 적는 편이 낫다. 화면에서 쓰지 않는 주소나 연락처까지 매번 읽어오면 전송해야 할 양이 늘고, 접근할 필요가 없는 개인정보가 처리 과정에 포함될 수도 있다. 질문의 범위를 좁히는 일은 속도만이 아니라 데이터 최소 사용과도 연결된다.

열의 이름을 바꾸어 보여주는 별칭도 사용할 수 있다. 데이터베이스 안에서는 축약된 영문 이름을 쓰더라도 화면이나 보고서에서는 사람이 이해하기 쉬운 이름으로 표시할 수 있다. 저장 구조와 표현 화면이 항상 같은 모양일 필요는 없다는 뜻이다.

WHERE가 빠지면 테이블의 모든 행이 질문의 대상이 된다

SELECT와 FROM만 적으면 지정한 테이블의 모든 행이 결과 후보가 된다. 직원이 열 명인 작은 명부라면 별문제가 없겠지만 주문이 수백만 건 쌓인 테이블에서는 이야기가 달라진다. 필요한 기록이 몇 건뿐인데 전체를 요청하면 데이터베이스가 읽고 서버가 전달하며 화면이 처리해야 할 양이 불필요하게 커진다.

WHERE는 어떤 행이 결과에 들어올 수 있는지를 정한다. 예를 들어 상태가 ‘완료’인 주문만 보거나, 특정 장비의 장애 기록만 고를 수 있다. 여러 조건을 함께 쓸 때에는 모두 만족해야 하는지, 하나만 만족해도 되는지도 구분해야 한다.

SELECT equipment_id, occurred_at, fault_type
FROM equipment_faults
WHERE equipment_id = 'EQ-2048';

이 문장은 장비 장애 테이블에서 지정한 장비와 관련된 식별값, 발생 시각과 장애 유형을 가져오라는 요청이다. 예시의 식별번호는 설명을 위해 만든 값이다. 실제 체계에서는 사용자가 입력한 값을 SQL 문자열에 그대로 붙이지 않고 매개변수로 안전하게 전달해야 한다. 그렇지 않으면 입력값이 질문의 구조를 바꾸는 SQL 삽입 공격으로 이어질 수 있다.

조건을 적었다고 원하는 행이 언제나 빠르게 나오는 것은 아니다. 데이터가 많다면 자주 검색하는 열에 적절한 인덱스가 있는지, 조건이 그 인덱스를 활용할 수 있는지도 영향을 준다. SELECT는 원하는 결과를 표현하고, 인덱스는 그 결과로 가는 길을 줄이는 장치다. 질문과 길찾기는 서로 관련되어 있지만 같은 역할은 아니다.

정렬 조건이 없으면 먼저 보이는 행을 믿을 수 없다

검색 결과에 최신 기록이 먼저 보였다고 해서 데이터베이스가 항상 그 순서를 보장하는 것은 아니다. 저장 위치, 실행 계획이나 여러 작업의 상태에 따라 결과의 순서는 달라질 수 있다. 최근 장애부터 보여주어야 한다면 발생 시각을 기준으로 내림차순 정렬하라고 명시해야 한다.

SELECT equipment_id, occurred_at, fault_type
FROM equipment_faults
WHERE equipment_id = 'EQ-2048'
ORDER BY occurred_at DESC;

ORDER BY는 결과를 어떤 열의 순서로 보여줄지 정한다. ASC는 작은 값에서 큰 값으로, DESC는 반대 방향으로 정렬한다. 날짜라면 오래된 순서와 최신 순서를 나눌 수 있고, 우선순위나 수량처럼 숫자로 관리되는 값에도 적용할 수 있다.

정렬은 화면을 보기 좋게 만드는 장식이 아니다. 운용자가 가장 최근 상황부터 확인해야 하는지, 오래된 미처리 항목부터 보아야 하는지에 따라 판단의 출발점이 달라진다. 같은 행을 가져왔더라도 배열 순서가 업무의 의미를 바꿀 수 있다.

나누어 둔 테이블은 JOIN으로 다시 하나의 문맥이 된다

정규화된 데이터베이스에서는 한 화면에 필요한 값이 여러 테이블에 나뉘어 있을 수 있다. 주문 테이블에는 고객번호가 있고 고객의 이름은 고객 테이블에 있다. 주문내역에 고객 이름을 함께 보여주려면 두 테이블에서 같은 고객을 가리키는 값을 기준으로 기록을 연결해야 한다.

이때 사용하는 대표적인 방법이 JOIN이다. 기본키와 외래키가 관계를 남겨 두었기 때문에 주문의 고객번호와 고객 테이블의 고객번호를 맞추어 하나의 결과로 만들 수 있다. JOIN이 표를 영구히 합치는 것은 아니다. 질문을 처리하는 동안 필요한 관계를 따라 결과를 구성한다.

연결 조건을 빠뜨리거나 잘못 적으면 전혀 다른 고객의 정보가 붙거나 행 수가 예상보다 크게 늘어날 수 있다. 그래서 긴 SQL을 읽을 때에는 열 이름보다 먼저 어떤 테이블이 어떤 값으로 연결되는지를 보는 편이 좋다. 데이터 모델에서 관계가 분명해야 질문도 정확해진다.

여기서 앞선 글의 내용이 다시 이어진다. 기본키는 각 행을 구별하고, 외래키는 다른 테이블의 행을 가리키며, 정규화는 사실의 책임을 나눈다. SELECT는 그렇게 나뉜 자료에서 필요한 열과 행을 고르고, JOIN은 관계를 따라 필요한 문맥을 복원한다.

데이터베이스는 문장을 위에서 아래로 그대로 읽기만 하지 않는다

SQL 문장은 사람이 읽기 쉬운 순서로 적혀 있지만 데이터베이스가 실제로 자료를 찾는 과정은 다를 수 있다. 먼저 조건으로 행의 범위를 줄이고, 테이블을 연결한 뒤, 필요한 열을 만들고 정렬하는 식으로 처리된다. 어떤 인덱스를 사용할지, 어느 테이블부터 읽을지 또한 데이터의 양과 분포에 따라 달라진다.

같은 결과를 요구하는 SQL도 여러 형태로 적을 수 있고, 같은 SQL도 데이터가 쌓이면서 다른 실행 경로를 선택할 수 있다. 따라서 문장이 짧다고 항상 빠른 것은 아니며 길다고 반드시 느린 것도 아니다. 중요한 것은 요청한 결과가 정확한지, 불필요한 행과 열을 지나치게 읽지 않는지, 데이터베이스가 어떤 경로를 선택했는지 확인하는 일이다.

현장에서는 화면이 느리면 서버 성능부터 의심하기 쉽다. 그러나 검색 기간이 지나치게 넓거나 조건 없이 대량의 행을 가져오고, 화면에서 그중 몇 건만 쓰는 경우도 있다. 장비를 늘리기 전에 질문 자체가 필요한 범위로 작성되었는지 살펴야 하는 이유다.

짧은 생각
정보체계에서 좋은 검색은 많은 자료를 보여주는 기능과 같지 않다. 운용자가 지금 판단하는 데 필요한 기록을 정확한 조건과 순서로 꺼내 주어야 한다. 데이터를 모으는 체계에서 데이터를 쓰는 체계로 넘어가는 경계에, 의외로 평범해 보이는 SELECT 한 문장이 놓여 있다.

여러 체계가 같은 대상을 다르게 부르면 정확한 질문도 답을 잃는다

C4I 환경에서는 센서, 지휘통제체계와 군수·장비관리체계처럼 서로 다른 출처의 정보가 함께 사용된다. 한 체계에서 함정을 이름으로 기록하고 다른 체계에서 식별번호로 관리한다면, 문법상 올바른 SQL만으로는 두 기록이 같은 대상을 뜻하는지 판단하기 어렵다.

시각의 기준도 맞아야 한다. 어느 체계는 현지시각을 사용하고 다른 체계는 협정세계시를 쓴다면 ‘최근 10분’이라는 같은 조건이 서로 다른 구간을 가리킬 수 있다. 위치, 부대, 장비상태와 사건유형의 의미가 체계마다 다르면 정확하게 실행된 조회가 운용자가 기대한 답과 어긋난다.

SQL은 저장된 값에 충실하게 답한다. 그 값이 어떤 대상을 뜻하며 어느 기준으로 만들어졌는지까지 스스로 바로잡지는 못한다. 정보체계 사이에서 데이터를 공유하려면 식별체계, 코드와 시간 기준, 데이터 정의가 함께 관리되어야 한다. 데이터베이스의 질문 능력은 결국 질문할 수 있도록 정리된 데이터의 품질을 넘어서기 어렵다.

질문하는 법을 알면 저장 구조의 부족한 부분도 보이기 시작한다

SELECT, FROM, WHERE와 ORDER BY는 짧은 단어지만 각자 분명한 역할을 맡는다. SELECT는 결과에 담을 열을 고르고, FROM은 자료의 출처를 정하며, WHERE는 필요한 행을 걸러낸다. ORDER BY는 그 결과를 업무에 맞는 순서로 배열한다. 여러 테이블의 정보가 함께 필요하면 키의 관계를 따라 JOIN으로 연결한다.

조회문을 만들다 보면 저장 당시에는 보이지 않던 문제가 드러난다. 찾고 싶은 조건에 필요한 열이 없거나, 같은 대상을 연결할 식별값이 빠져 있을 수 있다. 현재 상태만 남겨 과거 시점의 모습을 되살리지 못하는 경우도 생긴다. 질문은 단지 데이터를 꺼내는 수단이 아니라 데이터 구조가 현실의 업무를 제대로 담았는지 시험하는 과정이기도 하다.

다음 글에서는 질문의 속도를 좌우하는 데이터베이스 인덱스를 살펴보려 한다. 필요한 행이 수백만 건 가운데 몇 건뿐일 때 데이터베이스가 처음부터 끝까지 모두 읽지 않고 목적지에 도달하는 원리를 이해하면, SELECT와 저장 구조가 어떻게 맞물리는지도 더 선명하게 보일 것이다.