본 기사의 결론은 Dataverse MCP Server가 Custom API를 지원하게 되었다는 점입니다(2026-10-26). 이로 인해 Copilot 에이전트는 여러 개의 쓰기 작업을 하나의 원자적 트랜잭션으로 실행할 수 있게 되었습니다. 다만, Custom Actions (Power Automate의 사용자 지정 액션)은 현재 비지원 상태입니다.
다음과 같은 분들에게 유용합니다:
- Copilot Studio 또는 Copilot Chat에서 에이전트를 설계하는 사람
- Dataverse 테이블에 대한 CRUD 작업을 MCP 또는 커스텀 커넥터로 호출하는 사람
- '에이전트가 여러 테이블에 걸쳐 쓰기하는 시나리오'에서 트랜잭션 관리에 어려움을 겪었던 사람
Copilot Studio에서 에이전트를 설계할 때, '화면 뒤에서 AI가 여러 테이블에 데이터를 쓰는' 설계 상황이 발생합니다. 케이스를 생성하고 거기에 주석(annotation)을 추가하며 후속 작업(follow-up task)까지 만드는 경우—단 하나의 사용자 요청만으로 3개의 쓰기 작업이 실행됩니다.
대기업 환경에서는 이 부분이 문제가 되기 쉽습니다. 만약 단계 2에서 오류가 발생하면, 단계 1에서 생성된 케이스는 어떻게 될까요? 아무 조치도 취하지 않으면 고립된 레코드가 남게 됩니다. 후속 작업도 추가되지 않은 채 시간이 지나면 '처리 누락'으로 떠오르게 됩니다.
Power Automate 플로우에서도 오류 처리의 범위를 정확하게 작성하지 않으면 같은 일이 발생합니다. '쓰기를 3번에 나누어 진행하고, 실패하면 되돌리는(rollback) 보상 로직'을 직접 구현하는 것은 본래 있어서는 안 될 수고입니다. 데이터베이스 트랜잭션은 원래 이를 무료로 해결해 주는 기능이기 때문입니다.
2026년 10월 26일, Power Platform 블로그에서 이 문제와 직접적으로 관련된 발표가 있었습니다. Dataverse MCP Server가 Custom API를 지원하게 되었습니다.
Custom API는 Dataverse의 기존 기능입니다. 'Win Opportunity'나 'Qualify Lead' 같은 내장 액션과 마찬가지로, 사용자가 자체적인 First-class 서버 측 작업을 정의할 수 있습니다.
일반적인 Dataverse Custom API는 다음 요소들로 구성됩니다.
- 고유 이름:
api/_CreateCaseWithFollowUp와 같이 다른 Dataverse 메시지와 동일하게 검색 및 식별 가능합니다.
- 바인딩 유형: 비바인딩(글로벌), 엔티티 바인딩, 엔티티 컬렉션 바인딩의 3가지 종류가 있습니다.
- 타입 지정 요청 계약 (Typed Request Contract): 호출자가 전달해야 할 입력 매개변수(Guid, String, DateTime 등)를 정의합니다.
- 타입 지정 응답 계약 (Typed Response Contract): 호출자가 받게 될 출력 속성을 정의합니다.
- 플러그인: 실제로 실행되는 C# 코드입니다. Dataverse의 조직 서비스에 완벽하게 접근할 수 있습니다.
중요한 점은, 이 플러그인이 Dataverse 내에서 단일 트랜잭션으로 실행된다는 것입니다. 플러그인의 어느 곳에서든 InvalidPluginExecutionException이 발생하면, Dataverse가 그 시점까지의 모든 쓰기를 롤백(rollback)합니다. 고립된 케이스도, 공중에 떠 있는 노트도 남지 않습니다.
에이전트(AI 모델)가 보는 것은 '케이스를 생성해라', '노트를 추가해라', '작업을 넣어라'와 같은 3개의 개별 작업이 아니라, '_CreateCaseWithFollowUp을 호출해라'라는 단 하나의 작업입니다. 호출자의 관점에서 보면, 단일 입력 계약과 단일 출력 계약만 존재합니다.
MCP(Model Context Protocol)는 AI 모델이 도구를 발견하고 호출하기 위한 표준 프로토콜입니다. Dataverse MCP Server는 Dataverse의 테이블이나 API를 MCP 도구로 공개합니다.
이번 발표 이전에는, Dataverse MCP Server가 Dataverse의 표준 테이블에는 대응했지만 Custom API에는 대응하지 않았습니다. 에이전트가 커스텀 비즈니스 로직을 호출하려면 Power Automate 플로우를 거치거나 자체적인 API 엔드포인트를 구축하는 수밖에 없었습니다.
이번 지원으로, Custom API를 Dataverse MCP Server를 통해 직접 호출할 수 있게 되었습니다. 이는 '기존의 커스텀 비즈니스 로직을 새로운 구현 없이 에이전트가 호출할 수 있다'는 것을 의미합니다.
또 한 가지, 설계상 중요한 변화가 있습니다. MCP의 search 도구 자체 지침에 "먼저 여기에 Custom API가 존재하는지 확인하라. 있다면 직접 수행하지 말고 그것을 사용하라"고 명시되어 있다는 것입니다. 이는 에이전트가 독자적으로 로직을 구성하기 전에 반드시 기존 Custom API를 우선하여 사용하도록 유도하는 설계입니다.
블로그 설명에 따르면, Dataverse MCP Server가 Custom API를 호출하기까지의 흐름은 3가지 MCP 도구 호출로 구성됩니다.
에이전트는 처음에 Custom API가 존재한다는 사실을 알지 못합니다. 에이전트는 프롬프트에서 키워드("케이스 생성", "후속 조치", "손상" 등)를 추출하여 MCP 서버의 search 도구를 호출합니다.
Dataverse MCP Server는 테이블, 스킬, 스코프와 함께 Custom API도 인덱싱하며, api/_CreateCaseWithFollowUp과 같은 경로를 반환합니다. 파일 시스템의 경로 형식으로 반환된다는 점이 특징입니다.
여기서 중요한 것은 search 도구의 지침이 에이전트에게 "먼저 Custom API를 확인하라"고 명시적으로 전달하고 있다는 것입니다. 에이전트가 직접 테이블을 수정하는 것이 아니라, 기존에 존재하는 커스텀 오퍼레이션을 우선적으로 사용하게 되는 동작입니다.
이름을 알더라도 호출하기 위해서는 입력 매개변수의 계약(contract)이 필요합니다. 에이전트는 describe 도구를 호출하여 _CreateCaseWithFollowUp의 완전한 요청 스키마를 가져옵니다.
반환되는 것은 Custom API 등록 시 정의된 메타데이터 그 자체입니다. 즉, 각 입력 매개변수의 이름, 타입(string, Guid 등), 필수 여부, 설명문입니다. 수동으로 도구 정의를 할 필요 없이, Dataverse 측에서 정규화된 메타데이터가 그대로 MCP의 도구 정의로 사용됩니다.
이는 실제 운영 환경에서 큰 장점입니다. Custom API를 업데이트하면, MCP 서버를 통해 에이전트가 보는 스키마도 자동으로 업데이트됩니다. 별도로 도구 정의를 관리할 필요가 없습니다.
스키마에 맞춰 입력을 갖추면, 에이전트는 Custom API를 호출합니다. Dataverse 측에서 C# 플러그인이 작동하여 케이스 생성, 노트 추가, 작업(task) 생성이 1개의 트랜잭션으로 완료됩니다. 어느 하나라도 실패하면 모두 롤백되고, 성공하면 Copilot이 일반 텍스트로 결과를 보고합니다.
3단계 중 step 1(search)과 step 2(describe)는 에이전트가 내부적으로 수행하는 것이므로 사용자에게는 보이지 않습니다. 사용자가 입력한 것은 "Adventure Works의 케이스를 만들고, 손상 설명을 노트에 추가하고, 금요일 오후에 후속 조치 작업도 넣어줘"라는 한 문장입니다. 이에 대해 에이전트는 3가지 MCP 도구 호출을 거쳐 하나의 원자적(atomic) 작업을 실행합니다.
여기서 주의해야 할 점이 있습니다. 블로그에 명시된 바와 같이: Custom Actions는 현시점에서 Dataverse MCP Server를 지원하지 않습니다.
Custom Actions와 Custom API는 혼동하기 쉽지만, 별개의 개념입니다. Custom Actions는 주로 Power Automate 플로우나 모델 기반 앱에서 호출하기 위한 것이며, Custom API와는 정의 방식 및 바인딩 방식이 다릅니다.
Power Automate의 커스텀 액션을 많이 사용하는 환경에서는, 이를 Copilot에서 직접 호출하는 것은 현시점에서는 불가능합니다. 향후 Custom Actions가 지원될지는 현재로서는 확인되지 않았습니다.
이번 발표를 계기로 기업 환경에서 Copilot Agent나 MCP를 설계할 때 사고방식을 바꿀 필요가 있습니다.
바로 트랜잭션 경계(Transaction Boundary)를 Dataverse 측에 두는 것입니다. 이전에는 "에이전트 → 여러 Dataverse 쓰기 작업 → 보상 로직"과 같은 설계가 필요했지만, Custom API를 사용하면 "에이전트 → Custom API (내부적으로 원자적 실행)"으로 충분합니다.
실제 설계 변경으로는 다음과 같은 방향을 고려할 수 있습니다.
만약 기존 비즈니스 로직이 C# 플러그인으로 구현되어 있다면, Custom API로 공개하는 것만으로 에이전트가 자동으로 발견하고 호출할 수 있게 됩니다.
아직 Custom API가 없는 경우, 여러 테이블에 걸친(cross-table) 쓰기가 발생하는 처리를 파악하여 Custom API로 정의하는 것을 고려해 볼 가치가 있습니다.
Power Automate 플로우를 통한 처리는 계속해서 커스텀 커넥터나 HTTP 액션을 통해 이루어질 것입니다 (Custom Actions 미지원으로 인해).
기업 환경에서 주의해야 할 점은 Custom API의 등록 및 관리 거버넌스입니다. 어떤 Custom API가 MCP 서버를 통해 공개되고 있는지 파악하고 있지 않으면, 에이전트가 의도하지 않은 작업을 호출할 위험이 있습니다. 특히 프로덕션 데이터에 영향을 미치는 로직이 여러 에이전트로부터 호출되는 상황에서는 접근 권한 설계와 함께 관리해야 합니다.
기존 Dataverse 환경에 Custom API가 얼마나 많이 존재하는지는 조직마다 다릅니다. Copilot Studio를 도입하는 단계에서 Custom API의 재고 조사(inventory)를 함께 진행하는 것이 향후 베스트 프랙티스가 될 수 있습니다. 적어도 '에이전트로부터 호출될 가능성이 있는 Custom API는 무엇인가'라는 관점은 앞으로 필요할 것입니다.
- Dataverse MCP Server가 Custom API를 지원하게 됨 (2026-10-26 공식 발표)
- Custom API는 C# 플러그인으로 구현된 처리를 원자적(atomic) Dataverse 트랜잭션으로 공개하는 메커니즘입니다.
- MCP 서버가 Custom API를 자동으로 인덱싱하기 때문에, 에이전트는 search → describe → invoke의 3단계로 호출할 수 있습니다.
- Custom Actions (Power Automate의 Custom Actions)는 현재 미지원입니다. 여러 테이블에 걸친 쓰기가 있는 시나리오에서는 Custom API로 설계 변경을 고려해 볼 가치가 있습니다.
- 거버넌스 관점에서 'MCP 서버를 통해 공개된 Custom API 목록'을 파악하는 시스템을 구축해 두는 것이 좋습니다.
이러한 변경 사항과 관련하여, 실제 Copilot Studio에의 배포가 어떻게 달라질지는 아직 내부적으로 검증되지 않았습니다 (방금 출시되었기 때문입니다). 하지만 설계 단계에서 통합할 가치가 있는 기능이라고 판단하고 있습니다.
WSL2 자동화 기반은 별도로 정리하겠습니다.
