완벽하게 들리는 NL2SQL 피치의 버전이 있습니다: 사용자가 자연어로 질문하고, 에이전트가 SQL을 생성하고, 데이터가 반환됩니다. 화면 더 적게, 쿼리 더 적게, 코드 더 적게. 단순합니다.
그런 다음 5분 더 생각합니다.
데모에서 아무도 이야기하지 않는 문제들
스키마는 사물을 설명하도록 설계되지 않았습니다. 암호화된 테이블 이름, 일관성 없는 열 이름, 추가 술어 없이는 의미적으로 유효하지 않은 기술적으로 유효한 관계들 — 이것은 기업 데이터베이스에서 일반적입니다. 버그가 아니라 비즈니스 변경의 누적된 역사입니다. 하지만 의도를 전달하도록 설계되지 않은 스키마에서 의도를 추론하도록 모델에게 요청하면, 모델은 어떻게든 시도할 것입니다. 포기하지 않습니다. 최선의 쿼리를 생성하고 자신감 있게 결과를 반환합니다.
모델은 결정론적이지 않습니다. 같은 데이터베이스에 같은 질문을 두 번 하면 다른 SQL을 얻을 수 있습니다. 모델은 확률을 계산하고 있으며, 컨텍스트의 약간의 변화가 다른 출력을 만들어냅니다. 에이전트가 항상 올바른 쿼리를 생성한다는 보장을 테스트로 달성할 수 없습니다.
사용자 검토는 확장되지 않습니다. “실행 전에 모든 쿼리를 검토하기만 하면 됩니다"는 안전하게 들립니다. 하지만 이는 사용자가 데이터 모델과 SQL 모두의 전문가라고 가정합니다 — 정확히 자연어 인터페이스가 필요하지 않았던 사람들입니다. 또한 인지 과부하와 새로운 종류의 확증 편향을 초래하며, 쿼리 복잡성에 압도된 사용자들이 조사하는 대신 유효하지 않은 쿼리를 승인합니다.
그리고 인젝션이 있습니다. 전통적인 SQL 개발에서 매개변수화가 인젝션을 해결했습니다. 사용자 입력이 SQL 구조가 아니라 매개변수를 채웠기 때문입니다. NL2SQL에서는 모델이 SQL 자체를 생성합니다. 프롬프트, 스키마 컨텍스트, 대화 기록, 검색된 데이터 모두 실행되는 것에 영향을 미칩니다. 누군가가 모델이 생성하는 것을 변경하는 프롬프트를 만든다면, 그것은 인젝션입니다 — 매개변수 수준이 아니라 쿼리 생성 수준에서. 그리고 테이블 삭제(명백하고, 복구 가능)와 달리 NL2SQL 인젝션은 눈에 보이는 오류 없이 잘못된 결과를 반환하는 쿼리를 생성합니다. 비즈니스 결정이 잘못된 데이터에 기반하여 이루어집니다.
SQL MCP Server가 실제로 해결하는 것
여기서 기사가 가장 유용한 실용적인 요점을 제시합니다. 에이전트에게 임의의 스키마 접근을 주고 최선을 바라는 대신, SQL MCP Server는 Data API builder 위에 구축된 엄선된 API 표면을 노출합니다.
차이가 중요합니다: 에이전트는 SQL을 생성하지 않습니다. 사전 정의된 결과 형태를 반환하는 이름 있는 엔드포인트를 호출합니다. SQL은 개발자가 한 번 작성하며 결정론적입니다. 에이전트의 비결정성은 임의의 쿼리를 구성하는 것이 아니라 어떤 엔드포인트를 호출할지 선택하는 것으로 제한됩니다.
이것은 전통적인 앱 모델에서 매개변수화가 SQL 인젝션에 대해 한 것 — 신뢰할 수 없는 입력에서 임의의 쿼리를 구성하는 능력을 제거하는 것 — 과 유사합니다.
올바른 질문
기사는 “NL2SQL을 절대 사용하지 마세요"라고 말하지 않습니다. 어디에 적용하고 무엇을 노출할지에 대해 신중하게 생각하라고 말합니다. 범위가 제한된 스키마와 읽기 전용 접근이 있는 통제된 환경에서의 탐색적 분석에는 NL2SQL이 괜찮을 수 있습니다. 비즈니스 결정이 결과에 의존하는 프로덕션 시스템에는 엄선된 API 레이어가 훨씬 더 안전합니다.
솔직히 말하면: 어떤 문제는 자연어에서 SQL보다 이름 있는 엔드포인트 뒤의 구조화된 쿼리로 진정으로 더 잘 해결됩니다. SQL MCP Server는 에이전트 인터페이스를 완전히 포기하지 않고 그 옵션을 제공합니다.
원본 게시물: Considering NL2SQL? Should your database really be the prompt? How can SQL MCP Server help?
