예전에는 데이터베이스에 접근해 테이블을 뽑고, 쿼리를 짜고, 여러 테이블을 조인해 원하는 값이 나오는지 검증하고, 통계로 결론을 내는 일이 소수 전문가의 영역이었다. 그런데 Claude Code 같은 CLI 기반 LLM이 등장하면서 그 판이 통째로 바뀌었다. AI 데이터분석의 기술 장벽이 무너진 지금, 진짜 경쟁력은 쿼리 실력이 아니라 “무엇을, 왜 봐야 하는가”를 아는 도메인 지식으로 옮겨갔다.
이 글에서는 AI 데이터분석이 실제로 어떤 장벽을 없앴는지, 완전 초보가 남이 짜놓은 쿼리에서 어떻게 출발하는지, 그리고 왜 결국 도메인 지식이 최후의 경쟁력이 되는지를 순서대로 짚는다. 코딩이 막혀서 데이터를 만지지 못했던 현장 사람에게 특히 필요한 이야기다.
예전엔 왜 데이터 분석이 고난도 작업이었나
데이터로 뭔가를 확인하려면 넘어야 할 관문이 한둘이 아니었다. 우선 DB에 붙을 권한을 받아야 하고, 어느 테이블에 원하는 값이 들어 있는지 알아야 했다. 하나의 지표를 뽑는 데도 여러 테이블을 조인해서 엮어야 했고, 그렇게 나온 결과가 정말 내가 원한 데이터가 맞는지 매번 검증해야 했다.
여기까지 와도 끝이 아니다. 뽑은 숫자를 해석하려면 통계 지식을 동원해 결론을 도출해야 했다. 상관과 인과를 구분하고, 표본이 충분한지 따지고, 분포를 읽어야 했다. 결국 데이터 분석은 “쿼리 언어 + 데이터 구조 + 통계”라는 세 겹의 진입장벽을 동시에 넘어야 하는, 공수 큰 전문 작업이었다. 현장에서 문제의 답을 이미 알고 있는 사람조차 이 장벽 앞에서 멈춰 섰다.
AI 데이터분석이 바꾼 것 — 기술 장벽이 무너졌다
CLI 기반 LLM은 이 세 겹의 장벽 중 앞의 두 개를 거의 걷어냈다. 쿼리를 분석하고, 새로 짜주고, 테이블 구조를 파악하고, 결과를 가공하는 일에서 AI 데이터분석은 이미 수준급이다. “이 지표를 이렇게 뽑고 싶다”고 자연어로 말하면 쿼리 초안이 나오고, 에러가 나면 원인을 짚어 고쳐준다.
핵심은 이게 단순한 자동완성이 아니라는 점이다. Claude Code처럼 터미널에서 파일과 데이터를 직접 읽는 도구는, 실제 테이블을 열어보고 맥락을 반영해 답한다. 예전에는 “기술의 문제”로 시작조차 못 했던 일을, 이제는 충분히 굴릴 수 있는 상황이 됐다. 장벽이 낮아진 게 아니라, 장벽이 있던 자리가 통째로 사라진 것에 가깝다.
그렇다면 남는 질문은 하나다. 누구나 쿼리를 짤 수 있게 됐다면, 무엇이 사람을 구분하는가.
초보는 백지에서 짜지 않는다 — 남의 쿼리에서 출발하는 법
여기서 흔한 오해를 하나 짚어야 한다. 완전 노베이스가 AI에게 “데이터베이스에서 이걸 뽑아줘”라고 백지에서 시작하는 건 여전히 무리다. 무엇을 요청해야 할지 자체를 모르기 때문이다. 그런데 현업에는 대개 누군가 이미 짜놓은 쿼리 자산이 굴러다닌다. 진짜 출발점은 백지가 아니라 바로 그 자산이다.
실제로 주고받는 흐름은 이렇게 흘러간다.
| 단계 | 나의 요청 | AI가 하는 일 |
|---|---|---|
| 1 | 쓸 만해 보이는 쿼리문을 통째로 붙여넣고 “여기서 쓰인 테이블 추출해줘” | 쿼리에 등장한 테이블 목록을 뽑아준다 |
| 2 | “그 테이블 몇 개만 간단히 호출해줘” | 샘플 데이터를 불러온다 — 훑다 보면 어디에 뭐가 있는지 감이 잡힌다 |
| 3 | 잘 짜인 쿼리를 주고 “이 구조 분석해줘” | 로직을 해설하고, 오히려 더 효율적으로 리팩토링까지 제안한다 |
이렇게 몇 번 주고받다 보면 가공 과정이 자연스럽게 몸에 들어온다. DB부터 쿼리를 백지에서 고민하는 게 아니라, 쓸 만한 레퍼런스를 찾아 뜯어보는 방식으로 접근이 바뀐다. AI 데이터분석의 진짜 강점은 “정답을 대신 써주는 것”이 아니라, 이렇게 남의 결과물을 빠르게 내 것으로 소화하게 해주는 데 있다. 그래서 이제는 구현이 가능하다.
F1 엔진 온도로 보는 데이터 설계 — 무엇을 볼지가 핵심
쿼리가 공짜가 되면, 병목은 곧바로 “무엇을 물어볼 것인가”로 옮겨간다. 가상의 예를 하나 들어보자. F1 경기에서 매 랩마다 엔진룸 온도 데이터를 가져온다고 하자. 데이터는 넘치게 쌓인다. 문제는 그다음이다.
어느 시점의 온도가 결과를 좌우하는가? 직선 구간의 값이 결정적인가, 아니면 후반부로 갈수록 누적된 값이 중요한가? 하나의 피처에 얼마만큼의 가중치를 줄 것인가? 이 질문에 답하는 것이 곧 데이터 설계이고, 여기서부터는 AI가 대신 정해주지 못한다. 온도가 언제 어떻게 성능을 갉아먹는지는 그 도메인을 아는 사람만 안다.
한 걸음 더 들어가 보자. 엔진 온도만 보다가, 냉각수 라인의 재사용 주기라는 변수가 이미 결과에 영향을 주고 있다는 걸 알아챘다고 하자. 그러면 그 변수를 마킹해서 함께 끌어와야 한다. 어떤 요소가 서로 얽혀 있는지 짚어내고, 어디에 포인트를 줄지 정하는 것 — 이 데이터 설계가 분석의 성패를 가른다. AI 데이터분석에서 성패를 가르는 건 쿼리 문법이 아니라 바로 이 지점이다.
이 시나리오는 개념 설명을 위한 가상의 상황입니다. 실제 F1 팀의 전략과 다를 수 있습니다.
코딩 장벽에 막혔던 도메인 전문가의 시대가 온다
정리하면 흐름은 분명하다. 기술 장벽은 AI가 걷어갔고, 그 자리에 남은 것은 “무엇을 왜 볼 것인가”를 아는 도메인 지식이다. LLM은 How를 해결하지만, What과 Why는 여전히 사람의 몫이다.
이 변화의 진짜 수혜자는 그동안 코딩 장벽 때문에 자기 지식을 데이터로 펼치지 못했던 사람들이다. 현장에서 수천 번 장비를 만져 원인을 직관으로 아는 엔지니어, 공정의 미묘한 상관을 몸으로 아는 사람들 말이다. 이들이 이제 그 벽을 넘어 직접 데이터를 만지는 엔지니어로 건너오고 있다. 발 빠른 사람들은 이미 움직였다. AI 데이터분석은 전문가의 자리를 없애는 게 아니라, 도메인을 아는 사람에게 데이터라는 무기를 쥐여주는 쪽으로 판을 바꾸고 있다.
핵심 요약
- 예전의 데이터 분석은 쿼리 언어, 데이터 구조, 통계라는 세 겹의 장벽을 동시에 넘어야 하는 고난도 작업이었다.
- CLI 기반 LLM은 쿼리 작성·테이블 파악·가공을 대신 해주며 앞의 두 장벽을 사실상 없앴다.
- 초보는 백지가 아니라 남이 짜놓은 쿼리에서 출발한다 — 테이블 추출 → 샘플 호출 → 구조 분석·리팩토링의 순서로 소화한다.
- AI 데이터분석 시대의 병목은 “무엇을 왜 볼 것인가”를 정하는 데이터 설계, 곧 도메인 지식이다.
- 코딩에 막혀 있던 도메인 전문가가 데이터를 직접 다루는 엔지니어로 넘어오는 흐름이 이미 시작됐다.
함께 읽으면 좋은 글
AI에게 “이 쿼리 구조 분석해줘”라고 시켰을 때 내부에서 실제로 무슨 일이 벌어지는지 궁금하다면 이 글이 도움이 된다.
도메인을 아는 사람이 AI를 쥐어야 하는 이유를 조직 관점에서 더 파고들고 싶다면 이어서 읽어볼 만하다.
