"3분기 매출 TOP 10 고객 알려줘"
"지난달 부서별 생산량 보여줘"
이런 질문을 컴퓨터 언어로 변환하지 않고, 일상적 언어로 자연스럽게 AI에게 물어보고 답변을 받을 수 있다면 어떨까요? 바로 이것이 Text2SQL입니다. 사람이 일상 언어로 질문하면 AI가 자동으로 SQL 쿼리를 생성해 데이터베이스를 조회합니다. 요즘 생성형 AI를 통해 많이 경험하고 있는 기술이기도 하죠.
현업 부서는 항상 데이터를 필요로 합니다. 매출 현황을 확인하고, 재고 상태를 점검하며, 고객 구매 패턴을 분석해야 합니다. 하지만 text2SQL이 회사에 도입되지 않은 것이 일반적이기 때문에, SQL을 모르면 IT 팀이나 데이터팀에 요청해야 하고, 결과를 받기까지 며칠이 걸립니다. 회의 중 급하게 필요한 데이터도 "확인해보겠습니다"로 끝나는 경우가 많습니다.
ERP(전사적 자원 관리), DW(데이터 웨어하우스), CRM(고객 관계 관리) 시스템에는 기업의 핵심 데이터가 모두 있습니다. 하지만 정작 이 데이터를 활용하는 데는 큰 병목이 있습니다. 바로 "SQL을 아는 사람만 데이터를 볼 수 있다"는 점입니다.
Text2SQL은 이 병목을 해결할 수 있는 기술입니다. SQL을 모르는 현업 담당자도 자연어로 질문해서 직접 데이터를 확인할 수 있습니다. 의사결정 속도가 빨라지고, IT 팀의 단순 조회 요청도 줄어듭니다.
하지만 기업 환경에서 Text2SQL을 도입하는 것은 개인이 ChatGPT를 쓰는 것과 완전히 다릅니다. "자연어로 질문하면 끝"이 아니라 보안, 권한, 감사, 운영 안정성이라는 복잡한 요구사항이 더해집니다. 편리함만큼이나 통제가 중요하기 때문입니다.
Text2SQL 기업 도입 시 가장 많이 실패하는 네 가지 지점
Text2SQL. 이 기술이 과연 만능일까요? 사실 아닙니다. 많은 기업들이 도입을 시도하고 있지만, 종종 실패하는 사례도 있기 때문입니다. 실제 기업에서 Text2SQL 도입이 실패하는 패턴을 분석해보면 그 원인이 놀랍도록 비슷합니다. 기술 문제가 아니라 구조와 운영 설계의 실패가 대부분이죠.
1. LLM이 SQL을 바로 실행하는 구조의 문제
많은 기업이 처음 Text2SQL을 도입할 때 이렇게 시작합니다. 공개 LLM(ChatGPT, Claude 등)에 DB 스키마를 연결하고, LLM이 생성한 SQL을 바로 실행하는 구조입니다. PoC 단계에서는 "와, 정말 되네요!"라는 반응이 나옵니다.
하지만 실제 운영에 들어가면 문제가 드러납니다. 잘못된 JOIN으로 엉뚱한 데이터가 나오고, 필수 조건이 누락되며, 컬럼을 잘못 이해해 전혀 다른 결과를 보여줍니다. 더 심각한 것은 같은 질문인데 실행할 때마다 결과가 달라진다는 점입니다. LLM의 "그럴듯한 추론"은 비즈니스 의사결정에 필요한 정확성을 보장하지 못합니다.
현업 담당자들은 금방 신뢰를 잃습니다. "이거 맞는 거예요?"라는 질문이 반복되고, 결국 다시 IT 팀에 확인 요청을 합니다. Text2SQL의 존재 이유가 사라지는 순간입니다.
2. 권한 통제 부재로 인한 보안 사고
또 다른 흔한 실패는 권한 관리를 LLM에게 맡기는 경우입니다. "LLM이 알아서 권한도 고려하겠지"라는 막연한 기대로 DB 계정 하나로 모든 쿼리를 실행합니다.
결과는 예상 가능합니다. 실무자가 급여 데이터를 조회하고, 영업팀 직원이 원가 정보를 확인하며, 외주 인력이 임원 보고서를 열람합니다. 보안팀이 발견하는 순간 즉시 사용이 중단됩니다.
권한은 AI의 추론 대상이 아닙니다. LLM은 "이 사람이 볼 수 있는 데이터"와 "보면 안 되는 데이터"를 구분하지 못합니다. 권한은 반드시 LLM 바깥의 강제 레이어에서 통제되어야 합니다.
3. 스키마 정리 없이 도입했을 때 발생하는 혼란
Text2SQL은 DB의 문제를 숨겨주지 않습니다. 오히려 문제를 더 빨리 드러냅니다. 컬럼명이 amt1, amt2, flag_yn, etc_val 같은 약어 투성이고, 테이블 간 관계가 문서화되지 않았다면 LLM은 의미를 추론할 수 없습니다.
같은 질문에도 실행할 때마다 다른 테이블을 참조하고, 다른 컬럼을 사용합니다. 결과의 일관성이 무너지고, 유지보수도 불가능해집니다. Text2SQL을 도입하기 전에 데이터 정리가 선행되어야 하는 이유입니다.
4. PoC는 성공, 운영은 실패하는 이유
특정 팀, 특정 DB에서 파일럿 테스트를 성공적으로 마쳤습니다. 이제 전사로 확산하려고 하는 순간, 품질이 급격히 떨어집니다. 부서별로 같은 용어를 다르게 사용하고, 데이터 정의가 충돌하며, 사용자 불만이 쌓입니다.
파일럿 성공이 전사 성공을 보장하지 않습니다. 확장성을 고려한 설계, 공통 데이터 사전, 용어 체계 정립이 없으면 Text2SQL은 일부 팀의 실험으로 끝납니다.
기업 환경에서 Text2SQL이 반드시 고려해야 할 세 가지 요소
이러한 이유로 text2SQL을 도입하기 전에 기업은 이 기술에 대한 정보를 어느정도 습득을 해야 합니다. 그리고 도입을 위해서는 기준을 마련해야 하죠. Text2SQL 기업 도입의 성공은 대게 세 가지 핵심 요소를 얼마나 잘 설계하느냐에 달려 있습니다.
1. 보안(Security): 데이터는 외부로 나가면 안 된다
기업 데이터는 외부 유출 자체가 리스크입니다. Text2SQL이 편리하다고 해서 보안을 희생할 수는 없습니다.
데이터 외부 전송 차단이 첫 번째 원칙입니다. 자연어 질문, DB 스키마 정보, 쿼리 결과가 외부 LLM 서버로 전송되는 구조는 금융, 제조, 공공기관에서 사용할 수 없습니다. 온프레미스 또는 프라이빗 클라우드 환경에서 모든 처리가 내부에서만 이루어져야 합니다.
위험 SQL 자동 차단도 필수입니다. DROP, DELETE, UPDATE 같은 위험 명령어는 기본적으로 차단하고, SELECT만 허용하는 Read-only 구조여야 합니다. "모든 테이블 삭제해줘" 같은 악의적 입력이나 실수를 원천 차단합니다.
민감 정보 마스킹은 조회 결과 단계에서 작동합니다. 주민번호, 계좌번호, 급여 같은 민감 컬럼은 권한이 있는 사용자만 볼 수 있고, 나머지는 자동으로 비식별 처리됩니다.
2. 권한 관리(Authorization): 자연어 위에서도 권한은 작동해야 한다
기업에서는 "무엇을 볼 수 있는가"가 "얼마나 똑똑한가"보다 중요합니다.
사용자·조직·역할 기반 접근 제어(RBAC)가 기본입니다. 임원, 팀장, 실무자, 외주 인력은 각각 다른 데이터에 접근할 수 있습니다. 사내 계정 또는 SSO(Single Sign-On)와 연동해 사용자를 식별하고, 미리 정의된 역할에 따라 권한을 부여합니다.
행(Row)·열(Column) 단위 권한은 더 세밀한 통제를 가능하게 합니다. 행 단위 권한은 "본인 부서 데이터만 조회"를 의미하고, 열 단위 권한은 "급여, 원가, 개인정보 컬럼 접근 제한"을 뜻합니다.
중요한 것은 자연어 질문과 DB 권한의 분리입니다. 같은 질문 "이번 분기 매출 알려줘"라도 팀원은 본인 팀 데이터만, 팀장은 부서 전체, 임원은 전사 데이터를 봅니다. Text2SQL이 DB 권한을 우회하거나 무너뜨려서는 안 됩니다.
3. 온프레미스(On-Premise) 환경: 규제 산업은 선택이 아니다
대기업, 공공기관, 금융사는 여전히 온프레미스가 기본입니다.
망분리·내부 규정 이슈가 가장 큽니다. 인터넷이 차단된 망분리 환경에서는 클라우드 AI를 사용할 수 없습니다. 내부 보안 규정상 외부 API 호출이 금지된 경우도 많습니다. 데이터 주권(Data Sovereignty) 이슈로 데이터를 국내에서만 처리해야 하는 경우도 있습니다.
클라우드 LLM의 한계는 명확합니다. ChatGPT, Claude 같은 클라우드 LLM은 데이터를 외부로 전송합니다. 아무리 암호화되어 있고 학습에 사용하지 않는다고 해도, 데이터가 회사 밖으로 나가는 것 자체가 규정 위반입니다.
기업이 온프레미스 Text2SQL을 선호하는 이유는 통제입니다. 감사 로그를 사내에 보관하고, 외부 사업자 정책에 의존하지 않으며, 언제든 시스템을 완전히 통제할 수 있습니다.
Text2SQL 기업 도입을 고민 중이라면 체크해야 할 네 가지 질문
Text2SQL 도입에 대한 정보를 습득을 했다면, 기업을 결정하기 전에 다음 네 가지 질문에 명확히 답할 수 있어야 합니다.
1. 우리 회사 데이터는 외부로 나가도 되는가?
금융, 제조, 공공기관처럼 규제가 강한 산업이라면 답은 "아니오"입니다. 온프레미스 또는 프라이빗 클라우드 환경이 필수입니다. 반면 스타트업이나 일반 기업이라면 클라우드 Text2SQL도 선택지가 될 수 있습니다.
2. 사용자별로 조회 범위가 다른가?
모든 직원이 같은 데이터를 조회한다면 권한 관리가 단순합니다. 하지만 부서별, 직급별로 볼 수 있는 데이터가 다르다면 RBAC 기반 권한 시스템이 반드시 필요합니다.
3. DBA와 보안팀이 동의할 수 있는 구조인가?
DBA는 DB 성능과 안정성을 책임집니다. Text2SQL이 Full Scan을 남발하거나 운영 DB에 부하를 주는 구조라면 동의하지 않을 것입니다. 보안팀은 데이터 유출 위험을 책임집니다. 외부 전송 구조라면 승인이 나지 않습니다.
4. PoC 이후 운영까지 고려했는가?
파일럿 테스트는 성공하기 쉽습니다. 하지만 전사 확산, 부서별 확장, 장기 운영을 고려한 설계가 되어 있지 않으면 PoC 이후 사장됩니다. 스키마 정리, 용어 표준화, 확장 전략이 준비되어 있어야 합니다.
디피니트 다비스(DARVIS)의 Text2SQL이 기업에 적합한 이유
디피니트의 다비스(DARVIS)는 Text2SQL을 처음부터 기업 환경을 전제로 설계했습니다.
- 온프레미스 중심 설계
다비스(DARVIS)는 회사 내부 서버에 설치됩니다. 데이터가 외부로 나가지 않고, 인터넷이 차단된 망분리 환경에서도 100% 작동합니다. 질문, 스키마, 쿼리 결과 모두 사내에서만 처리됩니다.
- LLM과 DB 실행의 분리 구조
다비스(DARVIS)의 핵심 차별점은 "LLM이 DB를 직접 만지지 않는다"는 것입니다. LLM은 SQL 초안만 생성하고, 실제 실행 여부는 다비스(DARVIS) 통제 레이어가 결정합니다. 검증 엔진이 컬럼·테이블 접근 권한을 확인하고, 금지된 SQL 문법을 제거하며, 성능 위험 쿼리를 제한합니다. AI의 추론과 DB 실행을 물리적으로 분리한 구조입니다.
- 보안·권한·운영을 전제로 한 Text2SQL
다비스(DARVIS)의 Text2SQL은 보안, 권한, 운영이 선택 사항이 아니라 기본 구조입니다. AI GUARDIA 시스템이 위험한 질문을 자동 차단하고, 민감 컬럼을 마스킹하며, 사용자 Role에 따라 같은 질문도 다른 결과를 반환합니다. DBA 관점의 성능 검증이 포함되어 있어 쿼리 비용이 초과되면 실행 전에 차단됩니다.
- "AI 기능"이 아닌 "기업 데이터 접근 플랫폼" 관점
다비스(DARVIS)의 Text2SQL은 단순히 SQL을 대신 써주는 기능이 아닙니다. 기업이 데이터를 안전하게 대화할 수 있게 만드는 플랫폼입니다. 편리함만큼이나 통제가 중요하고, AI의 똑똑함만큼이나 시스템의 안정성이 중요합니다.
Text2SQL은 기술이 아니라 '기업 데이터 접근 방식'의 변화다
Text2SQL은 SQL을 없애는 것이 목적이 아닙니다. 기업 데이터를 안전하게 대화 가능하게 만드는 구조입니다.
개인이 ChatGPT로 편하게 일하는 것과 기업이 수천 명의 직원에게 데이터 접근 권한을 주는 것은 완전히 다른 문제입니다. 편의성만큼이나 보안이 중요하고, 기능만큼이나 운영이 중요합니다.
Text2SQL 기업 도입의 성공 조건은 명확합니다.
보안: 데이터가 외부로 나가지 않는다.
권한: 자연어 위에서도 권한이 작동한다.
검증: LLM이 생성한 SQL은 반드시 검증을 거친다.
운영: PoC가 아니라 장기 운영을 기준으로 설계한다.
가장 똑똑한 LLM이 아니라, 우리 회사 환경에 맞는 Text2SQL 구조를 선택하세요. 그것이 Text2SQL 기업 도입 성공의 첫걸음입니다.