Dechive Logo
Dechive
Data#SQL#database#query#Supabase

데이터를 묻는다는 것

AI의 도움으로 서비스를 만들든, 직접 코드를 짜든, 어느 순간 Supabase 대시보드를 열게 된다.

처음에는 테이블을 만들고, 데이터를 확인하고, 인증 설정을 만지는 정도로 충분해 보인다.
그러다 한 번쯤은 왼쪽 메뉴에 있는 SQL Editor를 마주친다.

그곳에는 짧은 문장들이 있다.

SELECT, FROM, WHERE.

처음 보면 코드 같기도 하고, 명령문 같기도 하다.
하지만 SQL은 단순히 데이터베이스를 조작하는 주문이 아니다.

SQL은 데이터에게 질문을 던지는 방식에 가깝다.

데이터는 스스로 말하지 않는다

테이블에 데이터가 쌓이는 것과, 그 데이터를 읽는 것은 다른 일이다.

Supabase 대시보드에서 테이블을 클릭하면 행과 열이 보인다. 숫자와 문자가 있다. 하지만 그 상태로는 아무것도 알 수 없다. 누가 가장 많이 방문했는지, 어떤 항목이 자주 조회되는지, 최근 일주일간 무슨 일이 있었는지 — 테이블은 그 질문에 스스로 답하지 않는다.

데이터를 읽으려면 먼저 질문해야 한다.

SQL은 그 질문을 구조화하는 언어다.

보고 싶은 것을 정한다 — SELECT

SQL 문장은 보통 SELECT로 시작한다.

SELECT name, email
FROM users;

이 문장은 users 테이블에서 nameemail 열을 보여달라는 뜻에 가깝다.

SELECT는 "무엇을 볼 것인가"를 정한다. 테이블에 열이 열 개 있어도, 지금 필요한 두 가지만 선택할 수 있다. 나머지는 이 질문 안에서는 영향력이 없다.

이것은 조건으로 걸러내는 일이 아니다. 화면에 어떤 열을 남길지 정하는 일이다.

데이터에서 원하는 부분만 바라보겠다고 선언하는 것이 SELECT다.

어느 기록장을 볼지 정한다 — FROM

FROM은 어디서 볼지를 정한다.

데이터베이스에는 여러 테이블이 있다. 사용자 정보가 있는 테이블, 주문 기록이 있는 테이블, 게시글이 있는 테이블. FROM은 그 중 어느 기록장을 열지 가리키는 역할이다.

FROM users는 "users라는 기록장에서"라는 뜻에 가깝다.

SELECT는 무엇을, FROM은 어디서. 이 두 가지만으로 가장 기본적인 질문이 완성된다.

질문의 범위를 좁힌다 — WHERE

데이터 전체가 필요한 경우는 드물다.

대부분의 질문에는 조건이 붙는다. 오늘 가입한 사용자, 주문이 완료된 항목, 특정 카테고리에 속한 게시글. WHERE는 그 조건을 정한다.

SELECT name, email
FROM users
WHERE created_at >= '2026-05-01';

이 문장은 2026년 5월 1일 이후에 가입한 사용자의 이름과 이메일을 꺼낸다.

WHERE가 없으면 선택한 테이블의 행을 모두 대상으로 삼는다. WHERE가 있으면 질문의 범위가 좁아진다. 좁아진 만큼 답이 선명해진다.

질문이 구체적일수록, 데이터는 더 또렷하게 말한다.

데이터를 읽는 태도

SELECT, FROM, WHERE. 이 세 가지가 SQL의 가장 기본적인 뼈대다.

하지만 이것은 문법의 문제만은 아니다. 데이터를 대하는 방식의 문제다.

SQL을 배운다는 건 명령어를 외우는 일이 아니다. 데이터에게 어떻게 질문할지를 배우는 일이다. 무엇을 보고 싶은지 정하고, 어디서 찾을지 가리키고, 어떤 범위로 좁힐지 결정하는 것. 그 구조가 SQL이다.

Supabase SQL Editor에서 처음 SELECT를 입력했을 때 막막했다면, 당연한 일이다. 아직 무엇을 묻고 싶은지 정리되지 않은 상태에서, 질문의 언어를 먼저 마주했기 때문이다.

데이터는 스스로 말하지 않는다. 읽을 준비가 된 사람에게만, 조금씩 답한다.

사서Dechive 사서