SQL의 종말? AI 시대, 코드는 이제 '읽는' 게 아니라 '확인'하는 거래요

 

데이터 업계의 옛날 전쟁들

5~6년 전쯤이었을까요? 데이터 업계에서 일하는 사람들이 트위터에서 매일같이 싸우던 시절이 있었어요. 뭘 갖고 싸웠냐고요? 바로 "쉼표를 어디에 찍느냐"였죠. 농담 같지만 진짜예요.

SQL 쿼리를 작성할 때 항목들을 여러 줄로 나열하잖아요. 그때 쉼표를 각 줄 끝에 붙일 거냐, 아니면 다음 줄 맨 앞에 붙일 거냐로 진영이 갈렸던 거예요. 끝에 붙이는 사람들은 "일반 문장처럼 자연스럽잖아"라고 했고, 앞에 붙이는 사람들은 "줄을 삭제할 때 고아 쉼표가 안 남잖아"라고 반박했죠.

사실 다들 알았어요. 이게 얼마나 사소한 논쟁인지. 그냥 쿼리 돌리면서 심심할 때 하는 놀이였던 거죠. 하지만 이 논쟁 속에는 꽤 중요한 포인트가 하나 숨어 있었어요. 바로 "쓰기와 읽기는 다르다"는 거요.

쓰기 편한 코드 vs 읽기 편한 코드

개발자 입장에서 보면 앞 쉼표가 압도적으로 편해요. 줄을 추가하거나 삭제할 때 쉼표 때문에 에러 날 걱정이 없거든요. "30분 동안 쿼리 에러 원인 찾았는데 알고 보니 쉼표 하나 때문이었다"는 얘기, 데이터 분석가들 사이에선 레전드급 썰이에요.

하지만 읽는 사람 입장에서는 앞 쉼표가 정말 보기 불편해요. 시각적으로 어색하고, 흐름이 끊기거든요. 개발할 땐 좋은데 이해하기엔 나쁜 거죠.

이건 쉼표뿐만이 아니에요. 함수 축약, 약어, 여러 단계 작업을 한 번에 처리하는 것들... 쓸 때는 엄청 편하지만 나중에 보면 "이게 뭔 소린가" 싶은 코드가 되기 일쑤예요. 추상화라는 이름의 복잡성 레이어가 쌓이고 쌓여서, 결국 본인도 나중엔 못 알아보는 지경까지 가는 거죠.

그래서 5~6년 전까지만 해도 선택의 기로였어요. 쓰기 편한 SQL을 만들 거냐, 읽기 편한 SQL을 만들 거냐. 그런데 어차피 직접 써야 했으니까 대부분 쓰기 편한 쪽을 택했죠.

2026년, AI가 코드를 쓰는 시대

근데 지금은 2026년이에요. 상황이 완전히 바뀌었어요.

코인베이스는 2025년 하반기 기술 블로그에서 매일 작성되는 코드의 약 40%가 AI에 의해 생성된다고 밝혔고요. Y Combinator의 2026년 초 배치 분석 결과, 전체 스타트업 중 약 4분의 1이 코드의 95% 이상을 AI로 작성했다고 해요. 어떤 창업자는 "모든 라인을 Claude Code와 Opus 4.5로 짰다"고 당당하게 말하더라구요.

깃허브의 2025년 개발자 생산성 리포트에 따르면, AI 코드 어시스턴트를 사용하는 개발자의 코드 작성 속도가 평균 55% 증가했다고 해요. 하지만 흥미로운 건, 같은 보고서에서 "코드 리뷰 시간"은 오히려 12% 증가했다는 거예요. 쓰는 건 빨라졌는데 확인하는 건 더 오래 걸린다는 뜻이죠.

개발자들의 일상도 완전히 달라졌어요. 이제는 "YOLO. 코드 변경사항이 쭉 지나가는데, 보든 말든." 이런 식이래요. "요즘은 코드를 거의 안 읽어요"라는 말도 나와요.

소프트웨어 개발의 패러다임이 바뀐 거예요. 코드를 직접 쓰던 시대에서, 코드를 읽던 시대를 거쳐, 이젠 그냥 "테스트만" 하는 시대로요. 영어로는 이걸 "vibe and verify"라고 표현하더라구요. 감으로 체크하고 작동 확인만 한다는 뜻이죠.

데이터 분석가는 왜 못 하는가

그럼 데이터 분석가들도 이렇게 일할 수 있을까요? 음... 솔직히 좀 어려워요.

개발자들은 앱을 클릭해보면서 버튼이 제대로 작동하는지 바로 확인할 수 있어요. 그게 일종의 검증 대리 수단이 되는 거죠. 버튼이 작동하면 코드가 뭘 하는지 "대충" 이해한 셈이 되는 거예요.

하지만 데이터 분석은 다르거든요. 차트를 클릭해봐야 결과가 맞는지 알 수 없어요. 스프레드시트의 숫자가 정확한지 확인하려면 모든 수식을 일일이 체크해야 해요. 결국 코드를 한 줄 한 줄 읽어보거나, 아니면 본인이 직접 처음부터 다시 만들어봐야 하는 거죠. 그럼 대체 뭘 자동화하는 건지 모르겠잖아요?

가트너의 2025년 데이터 분석 트렌드 리포트에 따르면, 데이터 분석 작업의 자동화 시도 중 68%가 검증 프로세스의 부재로 실패한다고 해요. 6개월 전만 해도 이게 그냥 불편한 정도였는데, 지금은 생존의 문제가 됐어요.

다른 직군들이 Claude Code 앞에서 IMAX 영화 보듯이 신나게 일하는 동안, 데이터 분석가들은 여전히 코드를 수동으로 리뷰해야 하거든요. 정량 분석이라는 분야 자체가 이미 입지가 불안한데, 다른 사람들한텐 통하는 마법이 우리한테만 안 통한다면 얼마나 빨리 도태될까요?

해결책은 "쉼표 재배치"

근데 어쩌면 해답은 간단할지도 몰라요. 쉼표를 다시 배치하는 거죠.

AI가 코드를 생성할 때, 우리는 그게 정확히 어떻게 쓰였는지 읽을 필요가 없어요. 그냥 "이해"만 하면 돼요. 한 가지 방법은 쿼리를 ChatGPT에 넣고 설명해달라고 하는 건데요. 이건 솔직히 막다른 길이에요. 쿼리에는 수십 개의 미묘한 계산 디테일이 있는데, 이걸 영어나 한국어로 표현하기도 어렵고 이해하기는 더 어렵거든요.

하지만 선택지가 날것의 SQL이나 장황한 텍스트뿐인 건 아니잖아요? 다른 표현 방법도 있을 수 있어요. 읽기 좋게 재정렬된 포맷, 이해만을 위해 설계된 다른 언어, 주석이 달린 다이어그램, 논리적 실행 계획, 그리고 어쩌면 그림까지요.

사실 새로운 쿼리 언어나 비주얼 SQL 에디터는 예전부터 있었어요. 수많은 BI 툴들이 "우린 절대 저 함정에 안 빠진다"고 선언했다가 나중에 그 언덕에서 죽었죠. 하지만 그런 도구들은 대부분 "SQL을 모르는 사람"이 SQL을 작성하도록 돕기 위해 만들어진 거예요.

지금 우리가 필요한 건 정반대예요. "SQL을 아는 사람"이 SQL을 읽도록 돕는 도구죠. 검증을 위한 거예요. "이 쿼리가 뭘 했지?" 그리고 주석을 위한 거고요. "이런 식으로 업데이트해."

시맨틱 레이어와는 다른 것

겉보기엔 시맨틱 레이어와 비슷해 보일 수 있어요. 둘 다 복잡한 쿼리를 단순하게 표현하는 거니까요. 하지만 시맨틱 레이어는 방향이 반대예요.

시맨틱 레이어는 공식을, 추상화로 가득 찬 것을 구조화된 쿼리로 바꿔줘요. 우리가 필요한 건 그 반대죠. 임의의 복잡한 쿼리를 접근하기 쉬운 다이어그램으로 바꿔주는 거요.

드롭다운 메뉴로 복잡한 쿼리를 생성하는 게 아니라, 로봇한테 내가 생각할 수 있는 아무 쿼리나 작성하라고 시키고, 그 "큰 컴퓨터가 어떻게 숫자를 계산했는지" 알려주는 그림과 설명을 받는 거예요.

맥킨지의 2025년 AI 트렌드 보고서에 따르면, 데이터 분석 업무에서 AI 도구를 도입한 조직의 73%가 "결과물 검증"을 가장 큰 장벽으로 꼽았다고 해요. 생성은 빨라졌는데 신뢰는 오히려 떨어진 거죠.

데이터브릭스가 2025년 발표한 설문조사에서도 비슷한 결과가 나왔어요. AI 기반 데이터 분석 도구를 사용하는 기업 중 61%가 "AI가 생성한 쿼리의 정확성 검증"에 가장 많은 시간을 소비한다고 답했거든요.

프로그래밍 언어 전쟁의 종말

옛날에 데이터 업계에서 쉼표만큼이나 치열하게 싸웠던 게 또 있어요. 바로 "어떤 언어가 최고냐"였죠. Python이냐 R이냐? SQL이냐 Python이냐? Pandas냐 Tidyverse냐?

Pandas를 만든 Wes McKinney는 최근에 이런 말을 했어요. "이제 프로그래밍 언어의 인간 공학적 요소는 훨씬 덜 중요해졌다. Python의 가독성과 단순함이 LLM의 코드 생성에도 도움이 되긴 하지만, 반복적인 에이전트 루프 관점에서 보면 더 빠른 반복이 순생산성 향상으로 이어진다. 더 장황하거나 구문이 복잡한 언어로 코드를 생성하는 오버헤드를 감안하더라도 말이다."

그러면서 그는 이제 승자는 "빌드 시스템, 런타임 성능, 패키징, 배포 문제를 해결한 언어"라고 했어요. 점점 Go나 Rust 같은 언어들이 유력해 보인다고요.

분석용 코드에 대한 언어 논쟁은 거의 전부 "쓰기 편함"에 관한 거였어요. 대부분의 사람들이 한 언어를 선호한 이유는 작성하는 느낌이 좋았기 때문이죠. 충분히 손을 보면 Python이든 SQL이든 R이든 Julia든 MATLAB이든 SAS든, 거의 모든 언어로 원하는 수학 계산을 할 수 있거든요.

이제는 쓰는 건 로봇이 해요. 우리가 시키는 대로 지루한 걸 다 작성해주죠. 하지만 분석 작업에서 사람이 여전히 해야 하는 건 "읽기"예요.

다이어그램이 답일지도

만약 이 언어들 중 하나라도 더 읽기 쉽게 만들어주는 다이어그램이나 앱이 있다면 어떨까요? ChatGPT가 수학 계산하는 속도만큼 빠르게 검산할 수 있다면요? 우리도 "vibe and verify"를 할 수 있다면요?

Stack Overflow의 2025년 개발자 설문조사에 따르면, AI 코드 생성 도구를 사용하는 개발자 중 62%가 "시각적 코드 리뷰 도구"를 가장 필요한 보완재로 꼽았다고 해요. 코드 생성은 빨라졌지만 이해는 여전히 병목이라는 거죠.

상상해보세요. SQL 쿼리를 돌리면 자동으로 논리 흐름도가 나오고, 각 단계별로 뭘 하는지 한글로 친절하게 설명해주는 거요. 테이블 조인이 어떻게 이뤄지는지, 집계 함수가 정확히 어떤 범위에서 작동하는지 시각적으로 보여주는 거죠.

그럼 우리도 AI한테 "이런저런 분석 좀 해줘" 하고 던져놓고, 나온 결과물을 5분 만에 다이어그램으로 검증할 수 있을 거예요. 지금처럼 1시간씩 코드 뜯어보지 않아도요.

실제로 이런 방향으로 움직이는 스타트업들이 생기고 있어요. 2025년 하반기부터 SQL 쿼리를 자동으로 시각화해주는 도구들이 하나둘 나오기 시작했거든요. 아직은 초기 단계지만, 시장의 니즈가 명확하니까 곧 더 많은 솔루션이 나올 거예요.

AI 시대에 살아남는 법

결국 핵심은 이거예요. 쓰는 건 기계한테 맡기고, 읽고 이해하는 건 사람이 압도적으로 빠르게 할 수 있어야 한다는 거요.

데이터 분석가의 가치는 "얼마나 많은 쿼리를 작성할 수 있느냐"에서 "얼마나 빠르게 결과를 검증하고 인사이트를 도출할 수 있느냐"로 이동하고 있어요. 앞으로는 코드를 한 줄도 안 쓰고 일하는 분석가가 나올 수도 있죠. 대신 AI가 만든 분석을 검증하고, 비즈니스 맥락을 부여하고, 의사결정으로 연결하는 게 주 업무가 되는 거예요.

보스턴컨설팅그룹의 2025년 보고서에서도 비슷한 전망이 나왔어요. 향후 3년 내에 데이터 분석가의 업무 중 코드 작성이 차지하는 비중이 현재 60%에서 25% 이하로 줄어들 것이라고요. 대신 "결과 해석 및 검증", "비즈니스 인사이트 도출", "이해관계자 커뮤니케이션"이 핵심 역량으로 떠오를 거래요.

그러려면 "읽기"가 압도적으로 쉬워져야 해요. 지금처럼 날것의 SQL 코드를 줄줄이 읽는 게 아니라, 한눈에 이해되는 비주얼로 바뀌어야 하는 거죠. 쉼표를 어디에 찍을지 고민하던 시대는 끝났어요. 이제는 "어떻게 하면 5분 만에 이해할 수 있게 보여줄까"를 고민해야 하는 시대가 온 거죠.

어쩌면 SQL의 종말이 아니라, SQL의 진화일지도 몰라요. 쓰는 언어에서 보는 언어로요.

핵심 정리

이 모든 논의가 시사하는 건 명확해요. AI 시대에 데이터 분석가로 살아남으려면 코드 작성 능력보다 '코드 이해 능력'과 '결과 검증 능력'이 훨씬 중요해진다는 거예요. 그리고 그걸 가능하게 해줄 도구들이 조만간 나타날 거고, 그 도구를 먼저 익히고 활용하는 사람이 다음 시대의 승자가 될 거예요.

지금 당장은 AI가 만든 코드를 일일이 리뷰하느라 시간을 쏟고 있지만, 곧 시각화 도구들이 이 과정을 획기적으로 단축시켜줄 거예요. 그때를 대비해서 지금부터 "빠르게 검증하는 능력"과 "비즈니스 인사이트를 도출하는 능력"을 키워놓으세요. 코드를 잘 쓰는 분석가가 아니라, 코드를 빠르게 이해하고 가치로 전환하는 분석가가 되는 거죠. 여러분은 준비되셨나요?