SQL을 못 짜도 괜찮습니다, 못 읽으면 안 됩니다
- AI교육
- 데이터
- SQL
- AI검증
- 일하는방식
들어가며 — SQL 앞에서 작아지던 사람
데이터 일을 하다가 SQL 앞에서 한 번쯤 작아져 본 사람이 많습니다. JOIN이 꼬이고, GROUP BY가 어디까지 묶는 건지 헷갈리고, 서브쿼리에서 길을 잃으면 이런 생각이 듭니다 — “나는 데이터 체질이 아닌가 봐.”
이제 AI가 그 쿼리를 대신 짜줍니다. “지난달 지점별 매출을 큰 순서로 보여줘”라고 말로 하면, SQL이 툭 튀어나오죠. 분명 좋은 소식입니다. 그런데 여기서 한 가지를 먼저 못 박고 시작하겠습니다 — SQL을 못 짜는 건 이제 흠이 아닙니다. 하지만 AI가 짜준 SQL을 못 읽으면, 틀린 숫자를 진실로 믿게 됩니다.
1. AI가 SQL을 대신 짜주는 시대
예전에 데이터 분석의 입구를 막고 있던 건 문법이었습니다. 같은 질문을 하더라도, 그걸 SELECT ... JOIN ... GROUP BY ...로 옮길 줄 알아야 데이터에 닿을 수 있었죠. 그 번역 한 겹 때문에 “데이터를 보고 싶다”는 사람과 “데이터를 볼 줄 아는 사람” 사이에 선이 그어져 있었습니다.
AI는 그 선을 거의 지웠습니다. 자연어로 묻기만 하면 쿼리를 만들어주니까요. 문법을 외우지 못해 데이터 앞에서 돌아섰던 사람에게는 분명한 해방입니다. 짜는 일은, 이제 정말로 AI가 잘하는 일이 됐습니다.
그러니 SQL 문법을 통째로 암기하느라 주눅 들 필요는 없습니다. 거기서 멈추는 글들은 “그래서 SQL은 이제 몰라도 된다”는 결론으로 갑니다. 저는 정반대로 봅니다 — 짜는 수고가 사라진 그 자리에, 더 중요한 능력 하나가 올라섰기 때문입니다.
2. SQL이 필요 없어진 게 아니라, 필요한 능력이 옮겨갔다
AI가 짜준다고 해서 SQL이 필요 없어진 게 아닙니다. 필요한 능력이 바뀐 겁니다. 짜는 능력(문법·암기)에서, 읽고 검증하는 능력(이 쿼리가 내가 물은 걸 맞게 가져왔나)으로요.
이게 왜 중요한지는, 전에 쓴 글 하나와 이어집니다. RAG·MCP·Function Calling 같은 약어는 몰라도 AI를 잘 쓸 수 있다고 한 적이 있습니다. 그건 자동차로 치면 엔진룸의 말이라서, 시스템을 직접 짓는 사람의 언어이지 운전하는 사람이 알아야 할 말은 아니라고요.
그런데 SQL은 다릅니다. SQL은 엔진룸 언어가 아니라 운전석 언어입니다. 차이는 하나예요 — SQL이 돌려준 결과는 그대로 내 보고서의 숫자가 됩니다. RAG가 안에서 어떻게 도는지는 내 보고서에 안 나오지만, “지난달 매출 4억 2천”이라는 숫자는 회의 자료 첫 줄에 올라갑니다. 그 숫자가 맞는지 틀리는지는, 결국 그걸 가져온 쿼리에 달려 있고요.
3. “에러가 없다”와 “답이 맞다”는 다른 말입니다
AI가 짠 SQL은 대개 잘 돕니다. 문제는, 잘 도는 것과 맞는 답을 주는 것이 전혀 다른 말이라는 데 있습니다.
AI가 그럴듯하지만 틀린 쿼리를 줄 때가 있습니다. 엉뚱한 테이블을 조인하거나, WHERE 조건 하나를 빠뜨리거나, 조인 때문에 행이 중복돼 합계가 부풀려지거나. 그런데 이런 쿼리도 에러 없이 잘 돕니다. 빨간 글씨 하나 없이, 깔끔한 숫자가 표로 떨어지죠. 읽을 줄 모르는 사람에게는 이게 정답인지 오답인지 구별할 방법이 없습니다. 그냥 나온 숫자를 진실로 받아들이는 거예요.
예를 들어볼까요. “지점별 월 매출”을 뽑는데 AI가 주문 테이블과 주문상세 테이블을 잘못 묶으면, 주문 한 건이 품목 수만큼 중복돼서 매출이 실제의 두세 배로 잡힙니다. 에러는 없습니다. 숫자도 그럴듯합니다. 다만 틀렸을 뿐이죠. 이 숫자가 그대로 보고서에 올라가면, 잘못된 매출 위에서 잘못된 의사결정이 내려집니다.
이건 사실 SQL만의 이야기가 아닙니다. 얼마 전 AI 답변을 끝까지 읽고, 보이는 형태로 바꿔서 검증하라고 쓴 적이 있는데, SQL은 그 이야기의 가장 날 선 버전입니다. 일반적인 AI 답변의 틀린 한 줄은 그나마 글로 읽히기라도 하지만, 틀린 쿼리는 숫자 하나로 압축돼 보고서에 박히니까요. 가장 위험한 건 틀린 쿼리 자체가 아니라, “AI가 짰으니 맞겠지”라는 한 문장입니다.
4. 그럼 무엇을 읽어야 하나 — 문법이 아니라 의도
오해를 막기 위해 분명히 해두겠습니다. “SQL을 아예 몰라도 된다”는 말이 아닙니다. 문법을 처음부터 끝까지 짤 수 있을 만큼 외우는 부담은 줄었지만, AI가 짠 쿼리를 읽어낼 최소한의 문해력은 오히려 더 중요해졌습니다. 짜기의 문턱은 낮아지고, 읽기의 값어치는 올라간 겁니다.
다행히 읽기는 짜기보다 훨씬 쉽습니다. 빈 화면에서 문법을 떠올려 한 줄씩 쌓는 것과, 이미 있는 쿼리를 보며 “이게 말이 되나” 따지는 건 난이도가 다릅니다. 읽을 때 던질 질문도 몇 개 안 됩니다 — 어느 테이블에서 가져왔나, 무엇을 기준으로 묶었나(GROUP BY), 무엇을 빼고 무엇을 남겼나(WHERE), 합칠 때 중복은 없나. 이 네 가지만 짚어도 앞에서 본 함정 대부분이 걸립니다.
읽기 자신이 없다면, 쿼리 자체를 노려보는 대신 결과를 검증 가능한 형태로 바꿔 보는 방법도 있습니다. 전체 합계가 상식적인 규모인가, 행 수가 말이 되는가(지점이 12개인데 결과가 30줄이면 뭔가 중복된 겁니다), 샘플 몇 줄을 눈으로 훑어 이상한 값이 없는가.
더 직접적인 방법은, 그 숫자를 어떻게 계산했는지 AI에게 말로 풀어달라고 하는 것입니다. “이 매출을 어떤 기준으로 묶고, 무엇을 더하고 무엇을 뺐는지 코드 말고 한국어로 풀어서 설명해줘.” 그러면 JOIN이며 GROUP BY 같은 문법이 아니라 계산의 논리가 평범한 문장으로 풀려 나옵니다 — “지점별로 묶어서, 주문 금액을 모두 더하고, 환불 건은 뺐습니다.” 이제 코드를 읽을 필요 없이, 그게 내가 생각한 계산과 같은지만 따지면 됩니다. “어, 환불을 안 뺐네”, “이건 주문 건수가 아니라 품목 수를 센 거네” 같은 어긋남이 거기서 드러나죠. 풀이를 시켜 보면, 내가 물으려던 것과 AI가 실제로 계산한 것이 다른 경우가 의외로 자주 보입니다.
여기에 가장 손쉬운 한 가지를 더 보태겠습니다 — 계산식 자체를 리뷰 받는 것입니다. 코드를 한 줄도 못 읽어도, 두 번째 눈에게 계산의 논리를 검토시키는 일은 누구나 할 수 있으니까요. 쿼리를 짠 AI에게 “이 집계에 중복이나 누락이 끼었을 수 있으니, 흔한 실수를 스스로 점검해줘”라고 되시키거나, 더 좋게는 아예 다른 AI에게 같은 질문과 쿼리를 던져 “이 계산이 맞는지 봐줘”라고 교차 검토시키는 겁니다. 자기가 짠 걸 자기가 보면 같은 실수를 못 보고 지나치기 쉬우니, 검토는 가급적 다른 눈에게 맡기는 편이 낫습니다. 같은 질문을 방식만 바꿔 두 번 풀어보고 숫자가 똑같이 나오는지 맞춰보는 것 — 회계에서 장부를 두 번 맞춰보듯 — 만으로도, 혼자 튄 오류 대부분이 모습을 드러냅니다.
핵심은 어느 방법이든 나온 숫자를 그냥 믿지 않고, 한 번 더 멈춰 서는 것입니다.
5. 짜기에서 읽기로 — 바뀐 건 일하는 방식입니다
정리하면 이렇습니다. AI가 SQL을 짜주는 시대에, 데이터로 일하는 능력은 사라진 게 아니라 자리를 옮겼습니다. 빈 화면에 문법을 채워 넣는 칸은 AI에게 넘어갔고, 사람의 진짜 자리는 그 양 끝으로 옮겨갔습니다 — 앞쪽의 무엇을 물을지 정하는 일, 그리고 뒤쪽의 답이 맞는지 읽고 검증하는 일.
그래서 SQL이 어려워 데이터를 포기했던 분이라면, 이제 다시 볼 만합니다. 문법을 못 외워 좌절하던 자리는 AI가 가져갔으니까요. 대신 새로 잡아야 할 건 무엇을 물을지 정하고, 나온 답을 끝까지 읽어내는 자리입니다. 그건 암기가 아니라 판단의 영역이고, 비전공자가 자기 업무 감각으로 충분히 해낼 수 있는 일입니다.
저는 “AI로 SQL 짜는 법”을 빨리 익히라고 말하지 않습니다. 짜는 건 이미 AI가 잘합니다. 제가 권하는 건, 무엇을 물을지 정하고 나온 숫자를 읽어내는 눈을 기르는 일입니다. 그게 도구를 하나 더 배우는 게 아니라, 데이터로 일하는 방식을 바꾸는 일이니까요.
본문의 잘못된 쿼리 사례(중복 집계로 매출이 부풀려지는 경우 등)는 실제 현장에서 흔히 나오는 유형을 일반화한 것입니다. 해석과 현장 관점은 박상훈의 견해입니다.