SQL MCP 서버와 데이터 API 빌더: 도구 7개로 데이터베이스를 AI 에이전트에 연결하기

핵심 메시지

• 데이터 API 빌더와 SQL MCP 서버는 이름만 둘일 뿐 같은 엔진이며, 설정 파일 하나로 REST·GraphQL·MCP 엔드포인트를 동시에 열 수 있다.
• 테이블마다 CRUD 도구를 만들면 100개 테이블에 도구가 400개가 되어 모델이 감당하지 못한다. SQL MCP 서버는 이를 도구 7개로 압축했다.
• MCP에서는 테이블과 칼럼의 설명이 결정적이다. REST와 달리 에이전트는 사전에 정해진 화면이 없어 설명만 보고 질의를 만들어야 하기 때문이다.
• 직접 짠 CRUD API 계층은 프로젝트마다 복사·붙여넣기로 이어지며 버그와 유지보수 부담만 늘린다. 이 계층을 통째로 지우는 것이 이 도구의 목표다.
• 오픈소스이자 무료이며 컨테이너로 배포되어 애저 밖에서도 돌아간다. 마이크로소프트 패브릭의 API가 이 엔진 위에서 동작한다.

쉽게 이해하기

NDC 토론토 2026 무대에 선 제리 닉슨은 마이크로소프트 SQL 서버 팀 소속이다. 그는 발표 초반에 지난 세월 SQL 제품이 DBA는 충분히 잘 지원해왔지만 개발자는 오랫동안 소홀히 대했다고 인정하면서, 최근 4년 동안 방향과 개발 속도를 바꿨다고 말했다. 이날 소개한 데이터 API 빌더(DAB)와 SQL MCP 서버는 그 변화의 결과물이자, 사실 같은 엔진에 붙은 두 개의 이름이다. 이름이 두 개인 이유는 순전히 검색 때문이라고 그는 농담처럼 설명했다. 아무도 'MCP를 지원하는 데이터 API 빌더'를 검색하지 않고 다들 'SQL MCP 서버'를 검색한다는 것이다.

그가 지적한 문제는 익숙하다. 3계층 구조에서 애플리케이션과 데이터베이스 사이의 API 계층은 개념적으로는 옳지만, 실제로 코드베이스에 들어가면 가장 골치 아픈 부분이 된다. CRUD API를 짜는 일은 지루해서 다들 빨리 끝내려 하고, 다음 프로젝트에서는 앞 프로젝트의 코드를 그대로 복사해 이름만 바꾼다. 그러면 앞에서 운 좋게 문제가 되지 않았던 실수까지 함께 복사되고, 단위 테스트와 CI/CD 파이프라인 설정도 똑같이 따라온다. 특별할 것 없는 코드를 위해 위험과 분량만 늘어난다는 것이 그의 결론이다.

데이터 API 빌더는 이 계층을 컨테이너 하나와 JSON 설정 파일 하나로 대체한다. 설정에는 연결 문자열과 노출할 테이블·뷰·저장 프로시저 목록이 들어가고, 어떤 엔드포인트를 켤지도 여기서 정한다. REST만 켤 수도, GraphQL만 켤 수도, 셋 다 켤 수도 있다. 마이크로소프트가 직접 만들고 유지하는 오픈소스이며 무료이고, SQL 서버는 2016 버전까지, 그 밖에 PostgreSQL·MySQL·코스모스 DB를 지원한다. 애저에서 돌릴 수 있지만 강제는 아니어서 AWS나 온프레미스에서도 동작하고, 컨테이너가 없으면 크로스 플랫폼 CLI로 직접 실행할 수도 있다. 확장성에 대한 근거로는 마이크로소프트 패브릭의 API가 이 엔진 위에서 돌아간다는 사실을 들었다.

에이전트 이야기로 넘어가면서 그는 흔한 오해를 짚었다. 에이전트에 연결 문자열만 건네면 데이터베이스와 대화할 수 있으리라 생각하지만 그렇지 않다는 것이다. 개발 도구 안에서라면 터미널로 명령을 실행해 어떻게든 붙겠지만, 운영 환경에서 사용자를 상대하는 상황이라면 클라우드에서 헤드리스로 돌면서 에이전트가 요구하는 규격을 지키는 무언가가 필요하다. 그것이 MCP 서버의 자리다. MCP 자체는 구현이 단순한 표준이지만, 그는 새 코드를 더하지 말고 이미 있는 데이터 API 빌더에 MCP 엔드포인트를 켜는 쪽을 권했다.

가장 흥미로운 설계 결정은 도구 개수다. 테이블마다 생성·조회·수정·삭제 도구를 만들면 테이블 3개에 도구가 12개, 테이블 100개면 400개가 된다. 그는 앤스로픽이 도구가 20~40개를 넘어가면 모델이 선택지에 압도된다고 이미 알려왔다는 점을 근거로 들며, SQL MCP 서버는 이를 7개로 압축했다고 밝혔다. 먼저 '엔티티 설명' 도구가 무엇을 할 수 있는지와 노출된 테이블 목록을 페이지 단위로 알려주고, 모델이 이름만 먼저 훑은 뒤 필요한 것만 상세 정보를 받아갈 수 있다. 나머지는 생성·조회·수정·삭제, 저장 프로시저 실행, 그리고 그룹화와 집계를 처리하는 도구다. 데이터베이스가 아무리 커져도 도구 수는 7개로 고정된다.

주요 인사이트

• MCP에서는 스키마 설명이 문서가 아니라 기능이다. REST 엔드포인트는 애플리케이션이 하드코딩해 쓰므로 테이블 설명이 없어도 상관없지만, 에이전트는 화면도 사전 지식도 없이 설명만 읽고 질의를 조립하기 때문에 칼럼 하나하나의 의미를 적어두는 일이 정확도를 좌우한다.
• 노출 이름을 바꿀 수 있다는 점은 보안 측면에서 의미가 있다. 테이블 이름을 그대로 드러내면 내부 시스템 구조가 새어 나갈 수 있어, API 계층에서 별칭을 붙여 실제 스키마를 감출 수 있다.
• 데이터베이스를 고칠 권한이 없어도 API 계층에서 대안을 만들 수 있다. 테이블 간 관계를 데이터베이스에 정의하지 않고 API 설정에만 정의해 GraphQL 조인을 쓸 수 있고, 행 수준 보안도 API 계층으로 끌어올려 같은 효과를 낼 수 있다.
• 인증은 익명부터 엔트라 ID, 옥타 같은 외부 발급 토큰까지 지원하고, 사용자의 토큰을 데이터베이스까지 그대로 전달하는 방식도 가능하다. 이렇게 하면 감사 로그에 에이전트가 아니라 실제 사용자가 실행한 것으로 남는다.
• 설정 파일을 여러 개 물리면 클라우드와 온프레미스, 관계형과 NoSQL을 한 번의 호출로 함께 조회해 하나의 응답으로 받을 수 있다. 다만 서로 다른 데이터베이스를 가로질러 조인하는 것은 메모리와 시간 문제로 이 도구의 몫이 아니며, 그런 작업은 별도 도구를 쓰라고 선을 그었다.

자주 묻는 질문

관련 AI 소식