Databases | The .NET Blog

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의 규범적 접근 방식입니다. 시작하려면 전체 게시물과 문서를 확인하세요.

SQL MCP Server, SSMS의 Copilot, AI 에이전트가 포함된 Database Hub: SQLCon 2026에서 실제로 중요한 것

Emiliano Montesdeoca — Sat, 28 Mar 2026 00:00:00 +0000

Microsoft가 애틀랜타에서 FabCon과 함께 SQLCon 2026을 시작했는데, 풀어봐야 할 내용이 정말 많습니다. 원래 발표는 비용 절감 플랜부터 엔터프라이즈 컴플라이언스 기능까지 전부 다룹니다. 저는 엔터프라이즈 가격 슬라이드는 건너뛰고 Azure SQL과 AI로 무언가를 만들고 있는 개발자에게 중요한 부분에 집중하겠습니다.

SQL MCP Server 퍼블릭 프리뷰 출시

이게 저에게는 헤드라인입니다. Azure SQL Database Hyperscale에 SQL MCP Server 퍼블릭 프리뷰가 추가되어 Model Context Protocol을 사용해 SQL 데이터를 AI 에이전트와 Copilot에 안전하게 연결할 수 있게 되었습니다.

MCP 물결을 따라오고 계셨다면 — 솔직히 지금은 안 보이는 게 더 어려운데 — 이건 큰 뉴스입니다. 데이터베이스에서 AI 에이전트에 컨텍스트를 제공하기 위해 커스텀 데이터 파이프라인을 구축하는 대신, SQL 데이터를 직접 노출하는 표준화된 프로토콜을 얻게 됩니다. 에이전트가 라이브 데이터베이스 정보를 쿼리하고, 추론하고, 행동할 수 있습니다.

Semantic Kernel이나 Microsoft Agent Framework로 AI 에이전트를 구축하는 우리에게 이건 깔끔한 통합 경로를 열어줍니다. 에이전트가 재고를 확인해야 하나요? 고객 레코드를 조회해야 하나요? 주문을 검증해야 하나요? MCP가 시나리오마다 맞춤형 데이터 가져오기 코드를 작성하지 않아도 되는 구조화된 방법을 제공합니다.

SSMS 22의 GitHub Copilot GA 출시

SQL Server Management Studio에서 시간을 보내신다면 — 솔직히 대부분이 아직 그렇죠 — GitHub Copilot이 SSMS 22에서 정식 출시되었습니다. VS Code와 Visual Studio에서 이미 사용하고 있는 것과 동일한 Copilot 경험을 T-SQL에서 사용할 수 있습니다.

실용적 가치는 명확합니다: 쿼리 작성, 저장 프로시저 리팩터링, 성능 문제 트러블슈팅, 관리 작업을 위한 채팅 기반 지원. 개념적으로 혁명적이진 않지만, SSMS 안에 바로 있다는 것은 데이터베이스 작업에서 AI 도움을 받기 위해 다른 에디터로 컨텍스트 스위치할 필요가 없다는 뜻입니다.

벡터 인덱스가 대폭 업그레이드

Azure SQL Database에 insert, update, delete를 완전히 지원하는 더 빠르고 강력한 벡터 인덱스가 추가되었습니다. 벡터 데이터가 실시간으로 최신 상태를 유지합니다 — 배치 재인덱싱이 필요 없습니다.

새로운 기능은 다음과 같습니다:

양자화로 정확도를 크게 잃지 않으면서 인덱스 크기 축소
반복 필터링으로 더 정밀한 결과
쿼리 옵티마이저와의 긴밀한 통합으로 예측 가능한 성능

Azure SQL을 벡터 스토어로 사용해서 Retrieval-Augmented Generation (RAG)을 하고 있다면, 이 개선 사항들은 직접적으로 유용합니다. 관계형 데이터와 동일한 데이터베이스에 벡터를 유지할 수 있어서, 별도의 벡터 데이터베이스를 운영하는 것에 비해 아키텍처가 크게 단순화됩니다.

동일한 벡터 개선 사항은 Fabric의 SQL Database에서도 사용할 수 있습니다. 둘 다 같은 SQL 엔진 위에서 동작하기 때문입니다.

Fabric의 Database Hub: 에이전트 기반 관리

이건 좀 더 미래지향적이지만 흥미롭습니다. Microsoft가 Microsoft Fabric의 Database Hub(얼리 액세스)를 발표했는데, Azure SQL, Cosmos DB, PostgreSQL, MySQL, SQL Server via Arc를 하나의 통합 뷰로 제공합니다.

흥미로운 점은 단순히 통합 뷰가 아니라 에이전트 기반 관리 접근 방식입니다. AI 에이전트가 데이터베이스 환경을 지속적으로 모니터링하고, 무엇이 변경되었는지 알려주고, 왜 중요한지 설명하고, 다음에 무엇을 해야 할지 제안합니다. 에이전트가 사전 작업을 하고 여러분이 결정을 내리는 human-in-the-loop 모델입니다.

여러 데이터베이스를 관리하는 팀에게 이건 운영 노이즈를 실질적으로 줄여줄 수 있습니다. 포털 사이를 오가며 수동으로 메트릭을 확인하는 대신, 에이전트가 신호를 가져다줍니다.

.NET 개발자에게 의미하는 것

이 모든 발표를 관통하는 흐름은 명확합니다: Microsoft는 데이터베이스 스택의 모든 레이어에 AI 에이전트를 내장하고 있습니다. 기믹이 아니라 실용적인 도구 레이어로서요.

Azure SQL 기반 .NET 앱을 구축하고 있다면, 제가 실제로 할 일은 이렇습니다:

SQL MCP Server를 사용해 보세요 — AI 에이전트를 구축하고 있다면. 커스텀 배관 없이 에이전트에 데이터베이스 접근을 제공하는 가장 깔끔한 방법입니다.
SSMS에서 Copilot을 활성화하세요 — 아직 안 했다면. 일상적인 SQL 작업에 무료 생산성 향상입니다.
벡터 인덱스를 살펴보세요 — RAG을 하고 있고 현재 별도의 벡터 스토어를 운영 중이라면. Azure SQL로 통합하면 관리할 서비스가 하나 줄어듭니다.

마무리

전체 발표에는 더 많은 내용이 있습니다 — 비용 절감 플랜, 마이그레이션 어시스턴트, 컴플라이언스 기능 — 하지만 개발자를 위한 스토리는 MCP Server, 벡터 개선, 에이전트 기반 관리 레이어에 있습니다. 이것들이 예산이 아니라 구축 방식을 바꾸는 부분입니다.

전체 그림은 Shireesh Thota의 전체 발표를 확인하시고, 새로운 관리 경험을 시도하고 싶다면 Database Hub 얼리 액세스에 등록하세요.