Azure SQL | The .NET Blog

NL2SQL는 에이전트 시대의 SQL 인젝션이다

Emiliano Montesdeoca — Wed, 03 Jun 2026 00:00:00 +0000

완벽하게 들리는 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?

Azure SQL이 이제 임베딩을 생성할 수 있습니다 — 순수 T-SQL로, 앱 레이어 없이

Emiliano Montesdeoca — Fri, 22 May 2026 00:00:00 +0000

RAG 파이프라인을 구축해본 적이 있다면 파이프라인 세금을 알 것입니다: 데이터는 SQL에 있지만 임베딩을 생성하려면 데이터를 추출하고, 임베딩 API를 호출하고, 배치 처리와 속도 제한을 처리하고, 벡터 검색이 가능한 곳에 결과를 저장해야 합니다. 종종 완전히 다른 데이터베이스에.

Azure SQL은 현재 일반 공개된 두 가지 기능으로 그 대부분을 제거했습니다: CREATE EXTERNAL MODEL과 AI_GENERATE_EMBEDDINGS.

무엇을 하는가

이 두 T-SQL 기능은 통합 파이프라인으로 작동합니다:

CREATE EXTERNAL MODEL — 외부 AI 모델 엔드포인트를 명명된 데이터베이스 객체로 등록합니다. 위치, API 형식, 모델 유형, 자격 증명을 한 번 설정합니다. 어디서나 재사용하세요.

AI_GENERATE_EMBEDDINGS — 등록된 모델을 호출하고 벡터 값의 JSON 배열을 반환하는 스칼라 T-SQL 함수입니다. SELECT, INSERT, UPDATE, MERGE 문에서 작동합니다.

함께 SQL 엔진을 벗어나지 않고 엔드투엔드 임베딩 파이프라인을 형성합니다.

전체 워크플로우

-- 1단계: 임베딩 공급자를 한 번 등록
CREATE EXTERNAL MODEL MyEmbeddingModel
WITH (
 LOCATION = 'https://your-aoai-resource.openai.azure.com/',
 API_FORMAT = 'Azure OpenAI',
 MODEL_TYPE = EMBEDDINGS,
 MODEL = 'text-embedding-ada-002'
);

-- 2단계: T-SQL에서 인라인으로 임베딩 생성
UPDATE docs
SET embedding = AI_GENERATE_EMBEDDINGS(content USE MODEL MyEmbeddingModel)
FROM documents AS docs;

-- 3단계: 벡터 거리로 검색
SELECT TOP 10 id, content
FROM documents
ORDER BY VECTOR_DISTANCE('cosine', embedding,
 AI_GENERATE_EMBEDDINGS(@query USE MODEL MyEmbeddingModel));

이것이 전체 파이프라인입니다: SQL의 데이터, SQL에서 생성된 임베딩, SQL에서의 유사성 검색. 오케스트레이션 레이어 없음, ETL 없음, 별도의 벡터 데이터베이스 없음.

지원되는 API 형식과 옵션

GA에서 API_FORMAT은 Azure OpenAI와 OpenAI를 지원합니다. MODEL_TYPE은 현재 EMBEDDINGS로 고정되어 있습니다. PARAMETERS JSON을 통해 재시도 횟수를 포함한 모델 수준의 기본값을 설정할 수 있습니다:

PARAMETERS = '{"sql_rest_options":{"retry_count":3}}'

인증은 데이터베이스 자격 증명을 사용하므로 비밀은 애플리케이션 코드 외부에 보관됩니다.

.NET 애플리케이션에서 무엇이 가능해지는가

기존 SQL 데이터 위에 AI 기능을 구축하는 .NET 개발자에게 이것은 중요합니다. 다음이 필요하지 않습니다:

임베딩을 위해 중간 저장소로 데이터 추출
외부 임베딩 파이프라인 관리
별도의 벡터 데이터베이스 설정 (완전한 기능의 벡터 저장소가 필요하면 Azure AI Search를 사용할 수 있지만)
애플리케이션의 데이터 액세스 레이어 변경

이미 보유한 동일한 T-SQL 도구를 사용하여 기존 SQL 애플리케이션에 의미 검색을 점진적으로 추가할 수 있습니다.

마무리

SQL 데이터에 대한 RAG 패턴이 극적으로 단순해졌습니다. AI_GENERATE_EMBEDDINGS + CREATE EXTERNAL MODEL은 기존 SQL 애플리케이션이 새로운 인프라를 추가하지 않고도 벡터 검색 기능을 얻을 수 있음을 의미합니다.

두 기능 모두 오늘 Azure SQL Database와 Azure SQL Managed Instance에서 GA입니다.

원본 게시물: Generate Embeddings Function and External Model Object Support Are Now Generally Available in Azure SQL

Azure Data Studio 은 폐기되었습니다: Azure SQL 워크플로를 VS Code로 이전하세요

Emiliano Montesdeoca — Sat, 09 May 2026 00:00:00 +0000

이 게시물은 자동으로 번역되었습니다. 원본 버전은 여기를 클릭하세요.

Azure Data Studio는 2025년 2월 6일에 폐기되었습니다. 지원은 2026년 2월 28일에 종료됩니다. 권장 대체 도구는 MSSQL 확장을 갖춘 VS Code입니다.

설치할 항목

시작하기 위한 세 가지:

MSSQL 확장 — VS Code Marketplace에서 “SQL Server (mssql)” 검색
SQL Database Projects 확장 — 코드로서의 스키마, 빌드 유효성 검사, 안내형 게시
.NET 8 SDK — 빌드 시스템에 필요. SDK 누락은 첫 실행 시 가장 흔한 문제

ADS 연결 및 설정 마이그레이션

MSSQL 확장에는 ADS Migration Toolkit이 포함되어 있어 안내형 흐름으로 일회성 마이그레이션을 처리합니다. 저장된 연결, 연결 그룹, 설정, 키 바인딩이 모두 자동으로 가져와집니다.

F5 단축키 감각 복구

ADS 사용자는 쿼리 실행을 위해 F5에 의존합니다. MSSQL Database Management Keymap 확장을 설치하면 F5를 포함한 ADS 스타일 키 바인딩을 복구할 수 있습니다.

SQL Database Projects: 코드로서의 스키마

프로젝트를 마우스 오른쪽 버튼으로 클릭 → 게시 → 대상 구성 → 생성된 T-SQL 스크립트 검토 → 배포. 배포 전 스크립트 미리 보기가 핵심 안전 기능입니다. 항목 템플릿은 테이블, 저장 프로시저, 뷰에 대한 스텁을 생성합니다. SSDT와 동일한 워크플로입니다.

자주 발생하는 문제: .sqlproj 파일의 대상 플랫폼 불일치는 프로젝트가 다른 SQL Server 버전에 대해 생성된 경우 빌드 오류를 유발합니다.

Schema Compare 및 Schema Designer

확장에는 Schema Compare(프로젝트와 배포된 데이터베이스 간의 diff)와 Schema Designer(수동 DDL 작성 없이 시각적 스키마 편집)도 포함되어 있습니다.

Microsoft Fabric 개발자

설정은 동일하지만 VS Code에서 열기 전에 Fabric 포털에서 시작하여 먼저 데이터베이스를 Git에 연결하세요. Microsoft에는 전용 가이드가 있습니다: Azure Data Studio to VS Code — What it means for SQL database in Fabric developers.

마무리

마이그레이션은 수동 재구축이 아닌 일회성 안내형 흐름입니다. 세 가지 도구를 설치하고, ADS Migration Toolkit을 실행하고, 키 바인딩을 복구하면 10분 이내에 정상으로 돌아올 수 있습니다.

단계별 스크린샷과 Fabric 전용 안내는 전체 기사를 참조하세요.

SQL MCP Server를 Azure App Service에서 실행하기 — 컨테이너 불필요

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

이 게시물은 자동으로 번역되었습니다. 원본 버전은 여기를 클릭하세요.

솔직히 말하면, 튜토리얼에서 “컨테이너 필요"라는 말을 볼 때마다 속으로 한숨이 나옵니다. 컨테이너는 훌륭하지만, 팀에 컨테이너 전략이 없으면 단순해 보이는 기능이 예상치 못한 오케스트레이션 복잡성에 막히게 됩니다.

그래서 이것이 눈에 띄었습니다. SQL MCP Server가 이제 Azure App Service에서 실행될 수 있습니다 — Docker도, Kubernetes도 없이, MCP, REST, GraphQL을 통해 SQL 데이터베이스를 공개하는 동일한 Data API Builder(DAB) 구성 파일만으로 동작합니다.

SQL MCP Server란?

아직 모르신다면 간단히 설명드립니다. SQL MCP Server는 AI 에이전트와 SQL 데이터베이스 사이에 위치합니다. 에이전트에게 직접적인 데이터베이스 접근 권한을 주는 것(끔찍한 아이디어) 대신, 테이블과 뷰를 정의된 권한이 있는 엔티티 추상화 레이어로 공개합니다.

Data API Builder 위에 구축되어 있어, 단일 구성 파일이 MCP 와 REST 와 GraphQL을 동시에 관리합니다. 에이전트는 MCP 엔드포인트와 통신하고, 기존 애플리케이션은 REST 또는 GraphQL과 통신합니다. 동일한 설정, 동일한 런타임, 다른 인터페이스.

이것은 정말 유용합니다. 두 개의 별도 API 레이어를 관리할 필요가 없습니다.

컨테이너 문제 (및 해결책)

SQL MCP Server의 원래 배포 모델은 컨테이너였습니다. 많은 팀에서는 잘 작동하지만, 모든 팀에 해당하지는 않습니다. 많은 .NET 팀이 Azure App Service나 VM을 표준으로 사용합니다. SQL 엔드포인트 하나를 공개하기 위해 컨테이너 런타임이 필요하다는 것은 불필요한 마찰을 만듭니다.

새로운 연습 가이드는 컨테이너를 완전히 건너뛰는 방법을 보여줍니다. 모든 것이 dab start 명령으로 실행되며, 표준 .NET 8 웹 프로세스로 App Service에 호스팅됩니다.

# Data API Builder 설치
dotnet tool install microsoft.dataapibuilder --prerelease -g

# 구성 초기화
dab init --database-type mssql --host-mode Development --connection-string "@env('SQL_CONNECTION_STRING')"

# 엔티티 추가
dab add products --source dbo.products --permissions "authenticated:*"

# App Service 인증 공급자 구성
dab configure --runtime.host.authentication.provider AppService

# 서버 시작
dab start

이 시점에서 /mcp에 MCP, 동일한 프로세스에서 REST와 GraphQL을 사용할 수 있으며, 컨테이너에서 실행되는 것은 아무것도 없습니다.

공유 API 키 없는 인증

제가 가장 좋아하는 부분입니다. App Service에 배포할 때 Microsoft Entra ID를 인증 공급자로 구성합니다. 구성 파일에 공유 비밀이 없고, API 키를 교체할 필요도 없습니다.

연결 문자열은 App Service 환경 변수에 보관되며(dab-config.json에는 없음), MCP 엔드포인트는 플랫폼 인증으로 보호됩니다. Azure 워크로드에서 이미 Entra ID를 사용하고 있다면 자연스럽게 통합됩니다.

로컬 개발 시에는 Simulator 모드와 STDIO 전송으로 전환합니다. 배포 전에 AppService 모드로 돌아옵니다. 깔끔하고 명확합니다.

App Service에 배포

az appservice plan create \
 --name <plan-name> \
 --resource-group <resource-group> \
 --sku B1 \
 --is-linux

az webapp create \
 --name <app-name> \
 --resource-group <resource-group> \
 --plan <plan-name> \
 --runtime "DOTNETCORE:8.0"

az webapp config set \
 --name <app-name> \
 --resource-group <resource-group> \
 --startup-file "dab start"

그런 다음 팀이 이미 사용하는 코드 배포 방법으로 DAB 프로젝트를 배포합니다. 핵심 사항: 코드 배포이지, 컨테이너 배포가 아닙니다.

.NET 개발자에게 중요한 이유

.NET에서 AI 에이전트를 구축하고 있다면, 에이전트는 결국 데이터베이스와 통신해야 합니다. SQL MCP Server는 원시 연결 문자열을 노출하거나 커스텀 API 레이어를 작성하지 않고도 이를 수행하는 구조화된 방법을 제공합니다.

원본 블로그 게시물과 GitHub 샘플 저장소에서 전체 가이드를 확인하세요.

마무리

App Service의 SQL MCP Server는 컨테이너 전략 없이 에이전트에게 구조화된 SQL 데이터 접근을 제공하려는 .NET 팀에게 실용적인 선택입니다. 직접 사용해 보세요 — 에이전트가 깔끔한 API 인터페이스를 좋아할 것입니다.

SQL Server 2025: 에이전트 준비 데이터베이스 — 하나의 엔진에서 보안, 백업, MCP

Emiliano Montesdeoca — Sun, 26 Apr 2026 00:00:00 +0000

이 게시물은 자동 번역되었습니다. 원본 버전은 여기를 클릭하세요.

Aditya Badramraju의 Polyglot Tax 시리즈를 많은 관심으로 팔로우해왔습니다. 파트 4는 이 아키텍처를 프로덕션에서 신뢰할지 실제로 결정하는 부분으로 시리즈를 마무리합니다.

모든 데이터 모델을 위한 단일 보안 모델

하나의 Row-Level Security 정책으로 모든 데이터 모델을 커버. 감사인에게 하나의 정책, 하나의 증명.

통합 백업 = 원자적 복구

폴리글롯 스택에서 5개 데이터베이스의 특정 시점 복구를 조율하는 것은 일관성 악몽입니다. 하나의 데이터베이스로는 정의상 원자적입니다.

MCP 통합: 수동 코딩된 미들웨어 없이

SQL Server 2025는 SQL MCP 서버를 직접 지원합니다. 에이전트가 도구를 호출하면, 엔진이 자동으로 테넌트 격리와 컬럼 마스킹을 강제합니다.

Aditya Badramraju의 원본 포스트: The Polyglot Tax – Part 4.

SQL MCP Server — AI 에이전트에게 데이터베이스 접근을 제공하는 올바른 방법

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

이 글은 자동 번역되었습니다. 원문은 여기에서 확인하세요.

솔직히 말합시다: 오늘날 사용 가능한 대부분의 데이터베이스 MCP 서버는 무섭습니다. 자연어 쿼리를 받아서 즉석에서 SQL을 생성하고 프로덕션 데이터에 대해 실행합니다. 뭐가 잘못될 수 있을까요? (전부요. 전부 잘못될 수 있습니다.)

Azure SQL 팀이 방금 SQL MCP Server를 발표했는데, 근본적으로 다른 접근 방식을 취합니다. Data API builder(DAB) 2.0의 기능으로 구축되어, AI 에이전트에게 구조화되고 결정론적인 데이터베이스 작업 접근을 제공합니다 — NL2SQL 없이, 스키마 노출 없이, 매 단계마다 완전한 RBAC와 함께.

왜 NL2SQL이 아닌가?

이것이 가장 흥미로운 설계 결정입니다. 모델은 결정론적이지 않으며, 복잡한 쿼리가 미묘한 오류를 생성할 가능성이 가장 높습니다. 사용자가 AI가 생성해주길 바라는 바로 그 쿼리가 비결정론적으로 생성될 때 가장 많은 검토가 필요한 쿼리이기도 합니다.

대신, SQL MCP Server는 NL2DAB 접근 방식을 사용합니다. 에이전트는 Data API builder의 엔티티 추상화 레이어와 내장 쿼리 빌더로 작업하여 정확하고 잘 형성된 T-SQL을 결정론적으로 생성합니다. 사용자에게는 같은 결과이지만, 환각된 JOIN이나 우발적인 데이터 노출 위험이 없습니다.

7개의 도구, 700개가 아닌

SQL MCP Server는 데이터베이스 크기에 관계없이 정확히 7개의 DML 도구를 노출합니다:

describe_entities — 사용 가능한 엔티티 및 작업 발견
create_record — 행 삽입
read_records — 테이블 및 뷰 쿼리
update_record — 행 수정
delete_record — 행 삭제
execute_entity — 저장 프로시저 실행
aggregate_records — 집계 쿼리

이것은 현명합니다. 컨텍스트 윈도우는 에이전트의 사고 공간이기 때문입니다. 수백 개의 도구 정의로 채우면 추론을 위한 공간이 줄어듭니다. 7개의 고정 도구는 에이전트를 탐색이 아닌 사고에 집중하게 합니다.

각 도구는 개별적으로 활성화하거나 비활성화할 수 있습니다:

"runtime": {
 "mcp": {
 "enabled": true,
 "path": "/mcp",
 "dml-tools": {
 "describe-entities": true,
 "create-record": true,
 "read-records": true,
 "update-record": true,
 "delete-record": true,
 "execute-entity": true,
 "aggregate-records": true
 }
 }
}

세 가지 명령으로 시작

dab init \
 --database-type mssql \
 --connection-string "@env('sql_connection_string')"

dab add Customers \
 --source dbo.Customers \
 --permissions "anonymous:*"

dab start

이것으로 Customers 테이블을 노출하는 SQL MCP Server가 실행됩니다. 엔티티 추상화 레이어는 이름과 열에 별칭을 지정하고, 역할별로 필드를 제한하며, 에이전트가 보는 것을 정확히 제어할 수 있게 합니다 — 내부 스키마 세부 정보를 노출하지 않으면서.

보안 이야기는 탄탄합니다

여기서 Data API builder의 성숙도가 빛을 발합니다:

모든 계층에서 RBAC — 각 엔티티가 어떤 역할이 읽기, 생성, 업데이트, 삭제할 수 있는지, 어떤 필드가 표시되는지 정의
Azure Key Vault 통합 — 연결 문자열과 비밀을 안전하게 관리
Microsoft Entra + 커스텀 OAuth — 프로덕션 등급 인증
Content Security Policy — 에이전트는 원시 SQL이 아닌 통제된 계약을 통해 상호작용

스키마 추상화는 특히 중요합니다. 내부 테이블 및 열 이름은 에이전트에게 절대 노출되지 않습니다. AI 상호작용에 의미 있는 엔티티, 별칭, 설명을 정의합니다 — 데이터베이스 ERD 다이어그램이 아니라.

멀티 데이터베이스 및 멀티 프로토콜

SQL MCP Server는 Microsoft SQL, PostgreSQL, Azure Cosmos DB, MySQL을 지원합니다. DAB의 기능이므로 동일한 구성에서 REST, GraphQL, MCP 엔드포인트를 동시에 얻을 수 있습니다. 동일한 엔티티 정의, 동일한 RBAC 규칙, 동일한 보안 — 세 가지 프로토콜 모두에서.

DAB 2.0의 자동 구성은 빠른 프로토타이핑을 위해 추상화를 줄이고 싶다면 데이터베이스를 검사하고 구성을 동적으로 빌드할 수도 있습니다.

제 의견

이것이 AI 에이전트를 위한 엔터프라이즈 데이터베이스 접근이 작동해야 하는 방식입니다. “LLM아, SQL 좀 써줘, 프로덕션에 YOLO 할게"가 아닙니다. 대신: 잘 정의된 엔티티 레이어, 결정론적 쿼리 생성, 매 단계의 RBAC, 캐싱, 모니터링, 텔레메트리. 최고의 의미로 지루합니다.

.NET 개발자에게 통합 이야기는 깔끔합니다 — DAB는 .NET 도구이고, MCP Server는 컨테이너로 실행되며, 대부분이 이미 사용하고 있는 Azure SQL과 함께 작동합니다. 데이터 접근이 필요한 AI 에이전트를 구축한다면 여기서 시작하세요.

마무리

SQL MCP Server는 무료, 오픈소스이며 어디서나 실행됩니다. AI 에이전트에게 안전한 데이터베이스 접근을 제공하기 위한 Microsoft의 규범적 접근 방식입니다. 시작하려면 전체 게시물과 문서를 확인하세요.