SQL
Structured Query Language
SQL이란?
- DB에서 데이터 조회·저장·수정
- 데이터 다루기의 기본기
- 비개발자도 유용
SQL을 다룰 줄 아는 사람이 팀에 한 명 생기면 바뀌는 것은 기술이 아니라 질문과 답 사이의 거리입니다. '지난 분기 재구매 고객이 몇 명이었지?'를 확인하려고 개발팀에 티켓을 올리고 사흘을 기다리던 일이, 본인이 3분 만에 확인하는 일로 바뀝니다. 더 큰 변화는 질문의 횟수가 늘어난다는 점입니다. 한 번 물어보는 데 드는 비용이 낮아지니, 그동안 '그냥 감으로' 넘어가던 가설을 실제로 숫자에 대보게 됩니다.
명령은 크게 셋으로 나뉩니다. 데이터를 읽고 바꾸는 DML(SELECT·INSERT·UPDATE·DELETE), 테이블 구조를 만들고 고치는 DDL(CREATE·ALTER·DROP), 권한을 주고 거두는 DCL(GRANT·REVOKE)입니다. 현업 담당자에게 실제로 필요한 것은 사실상 SELECT 하나여서, 대부분의 회사는 읽기 전용 계정만 발급합니다. 제품별 방언도 다릅니다 — Oracle, MySQL, PostgreSQL, BigQuery는 날짜 함수와 문자열 처리 문법이 제각각이라, 교재를 고르기 전에 우리 회사가 쓰는 DB가 무엇인지부터 확인해야 합니다. 엑셀과의 경계도 분명합니다. 100만 행이 넘어가면 엑셀은 버티지 못하지만, SQL은 수천만 행에 조건을 걸어 수 초 안에 걸러냅니다.
현장에서 가장 자주 터지는 사고는 운영 DB에 직접 붙는 것입니다. 실시간 주문을 처리하는 서버에 전체 집계 쿼리를 던지면 결제 화면이 멈춥니다. 분석은 복제본이나 데이터웨어하우스에서 해야 합니다. WHERE를 빠뜨린 UPDATE 한 줄로 전 고객 등급이 날아간 사례도 드물지 않습니다. 그리고 SQL을 배웠다고 데이터를 아는 것은 아닙니다 — 어려운 쪽은 문법이 아니라 '주문 테이블의 상태값 7이 취소인지 반품인지' 같은 우리 회사 데이터의 정의입니다. 조인 조건을 잘못 걸어 행이 중복되면 매출이 두 배로 집계되는데, 그 숫자가 그대로 보고에 올라가면 아무도 잡아내지 못합니다. AI가 쿼리를 대신 짜주는 지금도, 그 결과가 맞는지 판별하는 일은 여전히 사람 몫입니다.
1970년대 IBM에서 관계형 데이터베이스를 위해 개발됐으며, 이후 데이터 질의의 국제 표준이 됐습니다.
가상의 사례로 살펴보겠습니다. 임직원 320명, 연매출 900억 원 규모의 생활용품 제조·유통 A사입니다. 마케팅팀 6명이 개발팀에 넣는 데이터 추출 요청이 월 40건을 넘었고, 회신까지 평균 5영업일이 걸렸습니다. 캠페인 기획이 다 끝난 뒤에야 고객 명단이 도착하는 일이 반복됐습니다.
- 데이터팀 박 팀장이 최근 6개월 추출 요청 240건을 분류해 봤더니, 183건이 '기간과 조건만 바꾼 같은 조회'였습니다. '이건 현업이 직접 뽑는 게 빠르겠는데요'라는 말이 회의에서 나왔습니다.
- 운영 DB를 건드리지 않도록 매일 새벽에 동기화되는 분석용 복제본을 따로 띄우고, 마케팅·기획 12명에게 조회만 가능한 읽기 전용 계정을 발급했습니다.
- 교육은 문법 강의 대신 자기 업무 질문 3개를 들고 오게 했습니다. 4주간 주 2시간씩, '지난달 첫 구매 고객의 평균 객단가' 같은 쿼리를 각자 짜서 결과를 검증받았습니다.
- 초반에 취소 건을 매출에 포함해 집계한 보고서가 두 번 올라온 뒤, 주문 상태값 7종과 반품·교환 구분을 정리한 한 장짜리 데이터 사전을 사내 위키에 붙였습니다.
- 3개월 뒤 개발팀 추출 요청은 월 40건에서 9건으로 줄었고, 세그먼트 확인은 5영업일에서 당일로 바뀌었습니다. 재구매 캠페인 집행 주기도 월 1회에서 주 1회로 짧아졌습니다.