AI가 우리 회사 데이터베이스에 자연어로 묻는 일이 가능해지기까지, 세계는 어디까지 왔고 한국의 답은 무엇인가.
회사가 가진 거대한 엑셀 더미에 사람 말로 질문하면 답이 나오는 세상. 그 꿈은 얼마나 현실에 가까워졌을까요.
모든 회사에는 거대한 데이터베이스가 있습니다. 매출 기록, 고객 명단, 재고 현황, 직원 정보 같은 것들이 수백, 수천 개의 표 형태로 쌓여 있습니다. 엑셀 파일 수만 개가 한 곳에 모여 있다고 상상하면 됩니다.
그런데 이 데이터에서 무언가를 꺼내려면 SQL이라는 특수한 언어를 써야 합니다.
"지난 분기에 가장 많이 팔린 제품은?"이라고 한국어로 물어볼 수가 없고,
SELECT product, SUM(sales) FROM orders WHERE quarter='Q3' GROUP BY product ORDER BY 2 DESC LIMIT 1
같은 외계어를 써야 합니다.
문제는 SQL을 쓸 줄 아는 사람이 회사에 그리 많지 않다는 점입니다. 그래서 데이터 분석가가 모든 질문을 받아 SQL로 옮기느라 시간을 다 씁니다. 이걸 AI가 대신해 주면 어떨까요? 이게 바로 Text-to-SQL이라는 기술입니다. "한국어로 묻기, AI가 SQL로 옮겨주기"가 한 줄 정의입니다.
Text-to-SQL은 회사의 거대한 엑셀 더미에 한국어로 질문하면 AI가 답을 찾아주는 통역사입니다. 통역사가 얼마나 잘 알아듣느냐가 핵심이고, 우리 회사 사정을 얼마나 잘 아느냐가 더 중요합니다.
이 기술의 발전 정도를 측정하는 시험 문제집이 있습니다. Spider 2.0이라는 벤치마크입니다. 이번 발표는 두 가지를 다룹니다. 하나는 세계가 이 시험에서 어디까지 왔는지, 다른 하나는 한국 LG AI Research가 그 풍경 속에서 만든 답인 ReSQL입니다.
이야기는 다소 의외의 곡선을 그립니다. "거의 풀 수 없는 문제"가 1년 만에 "거의 풀린 문제"가 되었고, 그 풀이의 핵심은 모델 자체가 아니라 그 옆에 붙은 *방법론*이었다는 사실이 점차 드러납니다.
Spider 2.0은 단순한 시험이 아닙니다. "AI가 학교 문제는 잘 풀던데, 진짜 회사 데이터로 가면 왜 멍해지는가"라는 불편한 진실을 정면으로 측정하는 자리입니다.
AI가 SQL을 잘 쓰는지 평가하는 시험은 2017년부터 있었습니다. WikiSQL, Spider 1.0, BIRD 같은 이름들입니다. ChatGPT가 등장하면서 이 시험들의 점수가 빠르게 90%를 넘었고, "이제 Text-to-SQL은 풀렸다"는 분위기가 잠시 돌았습니다.
그런데 막상 회사들이 ChatGPT를 데이터베이스에 붙여보니 작동하지 않았습니다. 이유가 점점 분명해졌습니다. 학교 시험이 너무 쉬웠던 것이지, AI가 똑똑해진 게 아니었습니다. Spider 2.0 팀은 의도적으로 현실 회사의 데이터로 시험을 다시 만들었습니다.
벤치마크 한 데이터베이스당 평균 컬럼 수(파란 막대)와 한 정답 SQL의 평균 토큰 수(주황 막대). WikiSQL의 6.3개 컬럼에서 Spider 2.0의 743개 컬럼까지, 약 118배의 도약입니다. 같은 게임이 아니라는 신호입니다.
가장 명백한 차이는 크기입니다. 이전 시험들은 "주문 정보 5개 컬럼" 같은 장난감 표였습니다. Spider 2.0은 한 데이터베이스에 평균 743개 컬럼을 가진, Google Analytics 같은 실제 클라우드 시스템에서 추출됐습니다.
예전 시험이 5칸짜리 작은 엑셀 표에서 답을 찾는 거였다면, Spider 2.0은 743칸짜리 거대 엑셀 시트에서 그것도 표 안에 표가 또 들어 있는 중첩 구조에서 답을 찾는 일입니다.
게다가 컬럼 안에 또 다른 컬럼들이 들어 있는 중첩 구조도 흔합니다.
예를 들어 Google Analytics의 한 컬럼 totals 안에는
방문 수, 페이지뷰, 거래 횟수 같은 12개의 하위 항목이 들어 있습니다.
AI가 이걸 풀어 헤쳐서 다루는 법을 알아야 합니다.
더 충격적인 어려움이 있습니다. 회사의 비즈니스 규칙은 데이터베이스 안에 들어 있지 않습니다. 바깥의 문서에 적혀 있습니다.
예를 들어 어느 쇼핑몰에서 "PDP 페이지 비율이 얼마인가"를 묻습니다. PDP가 뭘까요? Product Detail Page(상품 상세 페이지)의 약자입니다. 그런데 데이터베이스 어디에도 "이 페이지는 PDP다"라고 표시된 컬럼이 없습니다. 대신 사내 문서에 이렇게 적혀 있습니다.
PDP 정의 (사내 문서):
- URL이 최소 5개 세그먼트로 나뉘어야 한다
- 첫 세그먼트에 '+' 기호가 있어야 한다
- 4번째 또는 5번째 세그먼트가
Accessories, Apparel, Brands 등의 카테고리명을 포함해야 한다이걸 알아야 SQL을 짤 수 있습니다. 회사마다 자기들만의 약속이 있고, 그 약속은 데이터베이스 바깥에 사람이 쓴 문서에 있습니다. AI는 데이터베이스만 보는 게 아니라 그 문서까지 읽어야 답을 낼 수 있습니다.
어느 식당에 가서 "VIP 손님 매출이 얼마인가"를 묻는다고 합시다. 식당 컴퓨터 어디에도 'VIP'라는 표시가 없습니다. VIP의 정의는 식당 매뉴얼에 적혀 있습니다. "3개월에 5번 이상 방문하고 평균 객단가 5만원 이상인 손님". AI가 이 매뉴얼까지 읽지 못하면 답을 못 냅니다.
또 하나의 함정이 있습니다.
잘 운영되는 회사는 raw 데이터를 직접 쿼리하지 않습니다.
미리 만들어둔 정제된 뷰(view), 변환된 테이블, 미리 계산된 집계를 씁니다.
이걸 관리하는 도구가 dbt(data build tool)입니다.
회사가 "영업담당자별 분기 실적"을 묻는다면, 정답은 raw 테이블에서 직접 계산하는 게 아니라
이미 만들어둔 int_salesforce__opportunity_aggregation_by_owner.sql 같은
중간 모델을 재사용하는 것입니다.
회사가 이미 정의해둔 비즈니스 로직을 무시하고 새로 짜면, 답이 미묘하게 틀립니다.
결국 Spider 2.0이 측정하는 것은 SQL 실력이 아닙니다. 회사의 데이터 환경 전체를 이해하고 다루는 능력입니다.
이 세 가지 어려움이 합쳐지자 점수가 폭락했습니다. 이전 시험에서 90점이 넘던 GPT-4가 Spider 2.0에서는 6%를 받았습니다. "AI가 SQL을 잘 짠다"는 통념이 무너진 순간입니다.
같은 GPT-4 모델이 시험에 따라 받는 정답률. 장난감 스키마 시험에서 86.6%였던 점수가 실제 회사 환경 시험에서 6%로 추락합니다. 모델이 멍청해진 게 아니라, 시험이 진짜 어려워진 것입니다.
"ChatGPT가 SQL 잘 짜는데, 우리 회사 DB에도 그냥 자연어로 물으면 되지 않을까요?"
장난감 스키마와 회사 스키마는 같은 게임이 아닙니다. 컬럼 743개, 사내 약어 정의, dbt 코드베이스가 동시에 걸리면 프론티어 모델조차 한 자릿수 정답률로 떨어집니다. "ChatGPT가 잘 한다"는 직관은 5컬럼짜리 토이 환경에서 만들어진 환상에 가깝습니다.
"거의 풀 수 없는 문제"는 어떻게 1년 만에 "거의 풀린 문제"가 됐을까요. 그리고 그 풀이의 진짜 주인공은 누구일까요.
Spider 2.0이 발표된 2024년 11월부터 2026년 3월까지, 약 16개월 동안 SOTA(최고 점수)는 다음과 같이 변했습니다. 이건 모델이 그냥 좋아진 게 아닙니다. 접근 방식 자체가 바뀌었기 때문에 가능한 도약입니다.
Spider 2.0 변종별 SOTA 점수의 시간 추이. 2024년 11월 GPT-4의 6%에서 시작해 2026년 3월 Genloop의 96.7%까지. 점수 곡선의 기울기가 2025년 11월 이후 가팔라진 것이 이 이야기의 핵심입니다.
처음에는 다들 GPT-4 같은 거대 모델 자체에 기대를 걸었습니다. 그런데 모델 단독으로는 한계가 분명했습니다. 판이 바뀐 건 ReAct라는 패러다임이 들어왔을 때입니다.
ReAct는 Reasoning(추론)과 Acting(행동)의 합성어입니다. 한 번에 답을 짜내라고 시키는 게 아니라, AI가 마치 사람 분석가처럼 시행착오를 하며 답에 도달하게 하는 방식입니다.
실제 데이터 분석가가 SQL을 짤 때 어떻게 하는지 떠올려 봅시다. 먼저 테이블 목록을 봅니다. 다음에 관심 컬럼에 어떤 값이 있는지 살펴봅니다. 쿼리를 짜서 돌려봅니다. 에러가 나면 메시지를 읽고 수정합니다. ReAct는 AI에게 정확히 이런 식으로 일하라고 시키는 방식입니다.
EXA-SQL이라는 시스템이 이 패러다임의 모범생입니다. AI에게 4가지 행동을 정의해 줍니다.
이 네 행동을 최대 20번까지 반복합니다. 매 단계마다 결과를 보고 다음 행동을 결정합니다. 같은 GPT-5를 쓰더라도 이렇게 시킨 결과가, 한 방에 답을 짜낸 결과보다 훨씬 좋습니다. 모델이 아니라 모델을 둘러싼 틀이 점수를 만들어 낸 것입니다.
그리고 결국 한계처럼 보이던 점수가 깨졌습니다. Genloop이라는 미국 스타트업이 자기네 시스템 Sentinel Agent v2 Pro로 Spider 2.0-Snow에서 96.70점을 받았습니다. Tencent, AT&T, ByteDance, Snowflake 같은 거대 기업들을 제쳤습니다.
96점짜리 시스템들의 명단을 보면 묘한 패턴이 보입니다. 한 줄 요약: 다 회사 제품들입니다. Genloop, Native, Tencent Cloud, Paytm. 대학이나 연구소가 아닙니다.
그리고 아무도 어떻게 만들었는지 공개하지 않습니다. 논문도, 코드도 없습니다. "우리 점수 1등이다, 우리 플랫폼 사라"는 마케팅만 있습니다. 이게 1년 전과 결정적으로 다른 점입니다.
이건 학술 풍경이 상업 풍경으로 바뀌었다는 신호입니다. 모델은 똑같은 GPT-5인데 같은 모델로도 점수가 30점에서 96점까지 갈리는 이유 ― 그 안에 들어가는 *Harness Engineering*(틀 짜는 기술)이 회사의 영업 비밀이 된 것입니다.
96점이 화려해 보이지만, 함정이 셋 있습니다.
첫째, 이건 Snowflake 환경의 점수입니다. 메타데이터가 잘 정돈되어 있고, 문서가 같이 제공됩니다. 이런 친절한 환경 밖, 즉 사내에 흩어진 Oracle DB나 한글 컬럼명이 섞인 환경에서는 다른 게임입니다.
둘째, 풀버전이 아닙니다. Spider 2.0-DBT(코드베이스까지 봐야 하는 풀버전)는 여전히 40% 미만입니다. 96.7%는 가장 다루기 쉬운 변종 점수입니다.
셋째, 우리는 그 시스템을 살 수 없습니다. Genloop의 비결은 영업 비밀입니다. 외국 클라우드 회사의 솔루션을 한국 대기업이 사내에 들이는 일은 비용, 보안, 데이터 주권 측면에서 큰 결정입니다.
그래서 한국에서는 다른 길이 필요했습니다. 바로 다음 챕터의 이야기입니다.
96점짜리 거대 시스템을 살 수 없다면 어떡할까요. LG AI Research가 ACL 2026에서 발표한 답은 직관적입니다. "큰 모델 대신 작은 모델, 단 영리하게 가르치자."
여기서 잠시 용어를 정리합니다. 모델의 크기는 매개변수(parameters) 개수로 셉니다. GPT-4 같은 거대 모델은 1조 개가 넘습니다. 반대로 1B, 3B, 8B 같은 모델들은 10억, 30억, 80억 개입니다. 이런 작은 모델을 SLM(Small Language Model)이라고 부릅니다.
점수: 96점급
호출당 비용 발생
데이터를 외부 회사 서버로 보냄
한국 보안 정책과 충돌
오라클 DB 미지원
점수: 잘 가르치면 거대 모델급
한 번 사면 무한 사용
회사 GPU에서 직접 운영
데이터 외부 송출 없음
한글, 사내 약어 학습 가능
문제는 작은 모델이 그냥 두면 SQL을 잘 못 쓴다는 점이었습니다. ReSQL은 이걸 어떻게 끌어올렸을까요?
ReSQL의 발상은 의외로 평범합니다. "작은 모델에게 오답노트를 쓰게 하고, 그 오답노트로 다시 가르친다." 이게 전부입니다.
수학을 잘 못하는 학생이 있습니다. 문제집을 풀게 합니다 — 틀립니다. 그 다음, 정답을 보여주면서 "왜 처음에 틀렸는지 글로 적어봐"라고 시킵니다. 학생이 자기 손으로 적은 그 오답노트를 다시 학습 자료로 만들어 학생에게 가르칩니다. ReSQL이 AI에게 시키는 일도 정확히 이것입니다.
구체적으로 보면 다음 흐름입니다.
1단계: 학생(작은 AI)에게 SQL 문제를 풀라고 시킨다
→ 틀린 SQL을 만든다
2단계: 그 SQL을 데이터베이스에서 실행한다
→ 에러 메시지가 나온다
3단계: 학생에게 다음을 한꺼번에 보여준다
- 원래 질문
- 자기가 만든 틀린 SQL
- 에러 메시지
- 정답 SQL (선생님이 미리 만든 모범답안)
4단계: 학생에게 묻는다 — "왜 처음에 틀렸는지 설명해봐"
→ 학생이 자연어로 추론(reasoning)을 적는다
5단계: 그 추론을 학습 데이터에 추가한다
→ 작은 모델을 다시 학습시킨다 (fine-tuning)여기서 "정답 SQL"의 정체가 중요합니다. 이걸 학계에서는 Gold Query라고 부릅니다. *"황금 표준"*이라는 뜻입니다. 사람이 직접 만들고 검증한 정답지입니다.
ReSQL이 자동으로 만드는 건 오답노트(reasoning)뿐입니다. 오답노트가 닻을 내리는 *정답 SQL*은 여전히 사람이 만들어야 합니다. 이게 나중에 한계 부분에서 다시 등장할 핵심 사실입니다.
이게 정말 효과가 있을까요? 한 사례로 보면 명확해집니다. 똑같은 질문, 똑같은 첫 시도, 똑같은 에러에서 두 모델의 행보가 갈립니다.
에러 메시지를 보자마자 SQL 구조를 통째로 바꿔서 다시 짭니다. 그런데 진짜 문제(컬럼명 표기)는 그대로 들고 갑니다. 두 번째 실행도 같은 에러.
에러를 보고 먼저 자연어로 진단을 적습니다. "공백 있는 컬럼명은 backtick으로 감싸야 한다". 구조는 그대로 두고 표기 한 군데만 고칩니다. 한 번에 정답.
똑같은 모델입니다. 똑같은 자원, 똑같은 시도 횟수입니다. 바뀐 건 단 하나, "진단을 글로 적게 했는가"입니다. 이 한 단계가 정답과 오답을 가릅니다.
이건 사실 사람에게도 똑같이 일어납니다. 문제를 풀다 막혔을 때, *말로 설명해 보면* 갑자기 길이 보이는 경험이 있습니다. AI도 마찬가지입니다.
ReSQL에는 두 번째 장치가 있습니다. 비슷한 과거 사례 가져오기입니다. 학계에서는 RAG(Retrieval-Augmented Generation)라고 부릅니다.
새 문제를 풀다가 막혔을 때, 학생이 비슷한 과거 오답노트 3개를 꺼내 봅니다. "아, 지난번에도 이런 식의 문제였는데 그땐 이렇게 풀었지" 하고 적용합니다. RAG는 정확히 이걸 자동화한 것입니다.
그런데 ReSQL 논문이 학회 동료심사를 통과한 이유는, 이 RAG의 효과를 정직하게 분해해서 보여줬기 때문입니다. 흔한 마케팅 자료라면 "RAG로 점수가 폭증했다"고 했을 겁니다. 실제로는 그렇지 않았습니다.
오류 카테고리별 RAG 적용 전후의 발생 비율 변화율. 흔한 오류(노란 막대)는 변화 미미하고 일부는 오히려 악화됩니다. 반면 드문 오류(녹색 막대)는 30~100%까지 줄어듭니다. RAG는 만능약이 아니라 희귀 케이스용 정밀 도구임이 드러납니다.
전체 점수 향상은 약 2.1%에 불과했습니다. "RAG 붙이면 점수 폭증"이라는 통념과 달리, RAG는 평균 정답률을 크게 올리는 도구가 아닙니다. 희귀 케이스의 신뢰도를 올리는 정밀 부품이라는 게 정확한 평가입니다.
이제 결정적 결과입니다. ReSQL을 적용한 작은 모델이 거대 모델에 어떻게 견주었을까요?
같은 Llama 모델에 학습 방식만 바꿔본 결과. Llama 1B는 baseline 3.78%에서 ReSQL 적용 후 24.84%로 6.6배 올랐습니다. 그리고 Llama 8B + ReSQL의 48.83%는 GPT-4의 49.67%와 사실상 동일합니다. 모델은 1/100 크기인데 점수는 같습니다.
이 결과의 의미는 큽니다. 한국 회사가 외부 데이터 송출 없이 사내 GPU에서 돌리는 작은 모델로 해외 거대 모델급 점수를 낼 수 있다는 첫 번째 학술적 증거입니다.
ReSQL은 모든 문제에서 똑같이 좋은 게 아닙니다. 어려운 문제일수록 더 강합니다. "Correction Rate"라는 지표로 측정한 결과입니다. 첫 시도에 틀렸을 때 결국 맞추는 비율을 봅니다.
SPIDER 시험 난이도별 Correction Rate(첫 시도 실패 후 결국 맞춘 비율). 쉬운 문제(Easy)에서는 1.6배 차이지만, 가장 어려운 문제(Extra)에서는 4.83% → 39.32%로 8.1배 차이입니다. ReSQL의 진가는 어려운 문제에서 드러납니다.
이건 직관적으로도 말이 됩니다. 쉬운 문제는 첫 시도에 거의 맞으니 "회복력"이 발동할 일이 없습니다. 어려운 문제일수록 첫 시도가 자주 틀리고, 여기서 *오답노트의 가치*가 결정적이 됩니다.
ReSQL에는 여러 부품이 들어 있습니다. Reasoning(오답노트), RAG(과거 사례 가져오기), Multi-pass(여러 번 시도하기). 이 중 어느 게 진짜 엔진일까요?
ReSQL에서 부품을 하나씩 빼봤을 때의 점수 손실. Reasoning을 빼면 17.6점 손실입니다(BIRD 기준). 반면 RAG를 빼도 1.2점만 떨어집니다. ReSQL의 본 게임은 오답노트 학습이고, 나머지는 보조 부품임이 정량적으로 드러납니다.
여기서 본질적인 의심이 한 번 더 생깁니다. AI가 만든 오답노트로 AI를 가르친다고? 그러면 AI의 오류가 강화되는 것 아닌가?
ReSQL 저자들은 이 질문에 두 단계 게이트로 답합니다.
1단계 — 자동 검증(G-Eval): 더 큰 AI에게 "이 오답노트가 정확한가?"를 묻습니다. Llama 8B가 만든 오답노트는 97.2%가 통과합니다. 반면 Llama 1B는 85.8%만 통과합니다. 작은 모델이 만든 오답노트일수록 검증을 더 자주 못 통과한다는 정직한 사실이 드러납니다.
2단계 — 사람 검증(Human Evaluation): 200건을 사람이 직접 봅니다. 정확성(Correctness)과 유용성(Helpfulness) 두 차원으로 점수를 매깁니다.
오답노트의 정확성과 유용성을 사람이 평가한 결과. 완벽 정답(Correct/Helpful, 진한 색)은 약 절반이지만, 최소 부분적으로라도 도움 되는 경우가 97%입니다. 해로운 오답노트는 단 3%로, 학습 데이터로 쓰기에 충분히 깨끗합니다.
흥미로운 디테일은 *완벽함을 요구하지 않는다*는 점입니다. Helpfulness 3점(완벽)이 51.5%고, 2점(어느 정도 도움)이 45.5%입니다. 사람 학습도 똑같습니다. 선생님 설명이 100% 명료할 필요는 없습니다. 방향이 맞으면 학습이 일어납니다.
마지막 슬라이드의 짧은 세 줄이 어쩌면 가장 중요합니다. 자기 작업의 한계를 정직하게 노출하는 자리입니다.
ReSQL의 가장 큰 한계는 발표자가 직접 짚었습니다. "Self-improving framework is not label free". 자기 개선 시스템이지만 완전 자동은 아니라는 인정입니다.
자동으로 만들어지는 건 오답노트뿐입니다. 그 닻이 되는 정답 SQL(Gold Query)은 여전히 사람이 만들어야 합니다. SPIDER나 BIRD 같은 공개 시험은 정답 SQL이 미리 만들어져 있어서 ReSQL이 잘 돌아갔습니다. 회사 환경에는 그게 없습니다.
한국 회사가 ReSQL 같은 시스템을 도입하려면, 가장 먼저 할 일은 "우리 회사의 자주 묻는 질문 200개와 그 정답 SQL을 사람이 직접 만드는 작업"입니다. 모델 선택도, GPU 확보도 아닙니다. 정답지 만들기가 1순위입니다.
두 번째 한계는 "Benchmark metrics needs improvement"입니다. 현재 시험 채점 방식이 너무 단순하다는 인정입니다.
현재 채점은 *실행 결과가 정답과 같은가*만 봅니다. 그런데 이게 함정을 만듭니다. 어떤 SQL은 의미가 틀렸는데 우연히 맞은 행이 나옵니다. 어떤 SQL은 거의 다 맞았는데 1픽셀 차이로 0점입니다. 회사 환경에서는 "실무에서 쓸 수 있는가"가 더 중요한데, 이 차원이 측정에 안 들어갑니다.
세 번째 한계는 미래 과제 선언입니다. "Modeling agentic Text-to-SQL using SLM". 앞서 본 EXA-SQL의 ReAct 같은 환경 상호작용형 접근은 거대 모델에서만 검증됐고, 작은 모델에서는 아직 안 됐다는 인정입니다.
새 데이터베이스에 적응하려면 재학습 필요
1년에 1회 재학습 모델 운영 필요
새 환경에 즉시 적응 가능
아직 연구 진행 중
이 발표 시리즈가 던지는 큰 그림은 이렇게 정리됩니다.
먼저, 환상은 깨야 합니다. "ChatGPT 같은 거 가져오면 우리 회사 데이터에 자연어로 묻기 가능"이라는 통념은 옛 시험 기준입니다. 실제 회사 환경에서는 6%부터 시작해서 끌어올려야 합니다.
다음, 96점 거대 시스템은 우리 손에 잡히지 않습니다. Genloop의 비결은 영업 비밀입니다. 그리고 그것을 들이는 일은 비용·보안·데이터 주권 면에서 큰 결정입니다. 한국 회사 입장에서 그대로 갖다 쓰기엔 마찰이 큽니다.
그래서 한국에서는 작은 모델 + 영리한 학습 방식이 답입니다. LG AI Research의 ReSQL은 그 방향의 한 학술적 답입니다. Llama 8B 크기로 GPT-4와 어깨 동무하는 것을 보여줬습니다. 비결은 모델 자체가 아니라 "틀린 시도에서 오답노트를 자동 생성하고 그것으로 다시 학습"입니다.
도입을 검토한다면, 가장 먼저 할 일은 정답지 만들기입니다. "AI가 알아서 다 한다"는 게 아닙니다. 회사가 자주 묻는 질문 200개와 정답 SQL 200개, 그리고 그걸 검증할 도메인 전문가의 시간 ― 이 세 가지가 PoC의 입장권입니다.
"AI 모델이 좋으면 자연어로 우리 회사 DB에 묻는 일이 가능해진다."
부분적으로만 맞습니다. 96점을 만든 건 GPT-5의 똑똑함 35%, 데이터 환경의 정돈 25%, 학습/추론 방법론(harness) 40%의 조합입니다. 한국 회사가 통제할 수 있는 변수는 뒤의 두 가지이고, 모델 발전은 시간이 해결합니다. 그래서 도입 작업의 본 게임은 "우리 데이터 환경을 정돈하고, 좋은 학습 방법론을 적용하는 일"입니다. 모델 고르기가 아닙니다.