데이터를 그만 복사하세요: Dynamics 365 가상 테이블이 전통적인 동기화보다 나은 이유

By Mirko Peters · 2026-08-27

블로그에 다시 오신 것을 환영합니다. 저희 업무에서는 시스템을 통합하고, 사일로를 허물고, 사용자가 필요한 정보를 손끝에서 바로 확인할 수 있도록 하는 것에 대해 많이 이야기합니다. 그런데 많은 조직이 기업 시스템을 통합할 때 빠지기 쉬운 조용한 함정이 있습니다. 바로 모든 것을 복사하려는 충동입니다. 오늘은 전통적인 데이터 동기화가 왜 큰 골칫거리가 될 수 있는지, 그리고 Microsoft Dataverse에 내장된 기능 하나가 외부 데이터를 다루는 방식을 어떻게 완전히 바꿀 수 있는지 자세히 살펴보겠습니다.

Automatically translated with AI from the original post. Read the English original

Cover: Dynamics 365 Virtual Entities - Simply Explained

자세한 오디오 해설과 실제 사례를 함께 듣고 싶다면 해당 팟캐스트 에피소드 Dynamics 365 Virtual Entities - Simply Explained를 꼭 확인해 보세요.

데이터 중복과 오래된 동기화 작업의 함정

이런 상황을 떠올려 보세요. 영업팀은 하루 종일 Dynamics 365 안에서 편하게 일합니다. 그런데 재고 수준은 별도의 창고 시스템에 있고, 송장은 재무 애플리케이션에서 관리되며, 제품 정보 카탈로그는 완전히 다른 ERP에서 유지됩니다. 많은 IT 팀이 흔히 택하는 전형적이고 기본적인 방식은 통합 파이프라인을 구축하는 것입니다. 이 모든 정보를 주기적으로 Dataverse에 복사하는 예약 작업을 작성하는 것이죠. 꽤 간단해 보이지 않나요?

안타깝게도 이 방식은 중복 레코드, 동기화 지연, 배치 실패, 그리고 무엇보다 최신이 아닌 정보로 가득한 아키텍처를 만들어 냅니다. 야간 동기화 작업 중에 창고 시스템이 재고 10개를 기록했다고 가정해 보세요. 다음 날 아침 Dynamics 365 대시보드에는 그 10개 재고가 자랑스럽게 표시됩니다. 그런데 점심시간에 한 현장 방문 고객이 남은 10개를 전부 구매해 출고해 갑니다. 창고 시스템은 즉시 재고가 공식적으로 0에 도달했다는 것을 알게 됩니다. 하지만 Dynamics 365는 오늘 밤 다음 예약 동기화가 실행되기 전까지 여전히 10개가 재고에 있다고 표시합니다. 영문을 모르는 영업 담당자는 이제 완전히 오래된 정보를 근거로 중요한 업셀링 결정을 내리게 됩니다. 문제는 반드시 동기화 스크립트가 실패했기 때문이 아닙니다. 근본적인 결함은 복사된 정보가 동기화 주기 사이에 necessarily 시간이 지나면서 반드시 오래된 정보가 된다는 데 있습니다.

게다가 정보를 복사하면 악명 높은 아키텍처 질문이 생깁니다. 바로 어느 시스템이 실제로 진실의 소유자인가 하는 문제입니다. 제품이 ERP 시스템에 존재하는데 중복 복사본이 Dataverse에도 있고, 누군가 한쪽에서 설명, 가격 또는 재고 상태를 수정한다면, 어떤 버전이 우선할지를 누군가 또는 무언가가 결정해야 합니다. 전통적인 동기화는 데이터 일관성 악몽을 만들어 냅니다. 가상 테이블은 완전히 다른 접근 방식을 제공합니다. 원래의 비즈니스 시스템이 레코드에 대한 완전한 소유권을 유지하면서, Dynamics 365 사용자는 필요할 때마다 그 정보를 안전하게 조회할 수 있습니다.

정보를 복사하는 것은 두 개의 서로 다른 서류 캐비닛에 똑같은 문서를 보관하는 것과 같다고 생각해 보세요. 한 캐비닛은 영업부서의 것이고, 다른 하나는 창고의 것입니다. 한쪽 캐비닛의 문서를 누군가 바꿀 때마다, 그 사람은 직접 걸어가서 다른 쪽 캐비닛의 사본도 고쳐야 합니다. 업데이트 하나라도 놓치면 두 캐비닛의 내용은 즉시 어긋나게 됩니다. 전통적인 동기화가 바로 이 패턴을 따릅니다. 가상 테이블은 더 나은 방법을 제공합니다. 취약한 두 번째 사본을 유지하는 대신, 팀에 원본 캐비닛을 향한 안전하고 실시간인 창을 제공하는 것입니다.

Dynamics 365 가상 테이블 이해하기

많은 조직이 "하나의 시스템"으로 모든 것을 통합하고 싶다고 말합니다. 하지만 일선 직원들과 이야기해 보면 실제로 필요한 것은 일할 수 있는 한 곳입니다. 영업 담당자는 Dynamics 365를 열어 둔 채로 ERP로 alt-tab 전환해 재고를 확인하고, 세 번째 레거시 애플리케이션을 열어 송장 상태를 확인한 뒤, 마침내 고객 레코드로 돌아가야 해서는 안 됩니다. 직원들이 원하는 것은 통합된 작업 공간입니다. 가상 테이블은 선택된 외부 정보를 기본 Dynamics 365 환경에 직접 가져오는 동시에, 전문 시스템은 각자의 비즈니스 프로세스를 계속 관리하도록 합니다.

Microsoft 비즈니스 애플리케이션 스택을 오래 다뤄 왔다면, 레거시 문서나 기술 포럼, 숙련된 개발자와의 대화에서 "가상 엔터티(Virtual Entities)"라는 오래된 용어를 여전히 접하실 수 있습니다. 현재 Microsoft가 사용하는 용어는 가상 테이블(Virtual Tables)입니다. 명칭과 관계없이 핵심 개념은 동일합니다. Dynamics 365와 Dataverse는 사용자가 기본 Dataverse 테이블과 상호 작용하는 것처럼 외부 정보를 노출할 수 있으며, 실제 레코드는 Dataverse 외부에 안전하게 저장된 상태로 유지됩니다.

차이를 이해하려면 일반 Dataverse 테이블과 가상 테이블을 비교해 보시기 바랍니다. 일반 Dataverse 테이블에서는 레코드가 Dataverse 데이터베이스 안에 직접 저장됩니다. 계정, 연락처, 영업 기회, 사용자 지정 테이블이 대표적인 예입니다. 가상 테이블에서는 Dataverse가 외부 정보가 어떻게 표시되어야 하는지와 이를 어떻게 가져오는지만 정의하며, 레코드는 전혀 다른 곳에 저장됩니다. 도서관 목록에 비유해 보겠습니다. 도서관 목록에는 책의 제목, 저자, 실제 서가 위치 같은 정보가 담겨 있습니다. 하지만 목록이 곧 책은 아닙니다. 가상 테이블도 이와 똑같이 작동합니다. Dataverse는 구조를 이해하고 레코드를 요청하는 방법을 알고 있지만, 실제 데이터는 외부 시스템에 있습니다.

가상 테이블이 외부 데이터를 실시간으로 보여 주는 방식

가상 테이블은 런타임 데이터 액세스 모델에서 작동합니다. 외부 레코드를 모두 가져와 로컬에 영구적으로 저장하는 대신, 애플리케이션이 실제로 필요로 할 때 정보를 동적으로 검색합니다. 사용자가 특정 뷰를 열거나, 특정 레코드를 검색하거나, 필터를 적용하거나, 개별 행을 선택할 수 있습니다. 그러면 Dataverse는 바로 그 시점에 필요한 정보만 외부 시스템에 요청합니다.

대형 고객과 대규모 잠재 거래를 논의하는 영업 담당자를 가정해 보겠습니다. 고객은 다음 달에 500개 제품을 주문하려고 합니다. 익숙한 Dynamics 365 인터페이스를 벗어나지 않은 채로 담당자는 관련 제품 재고 정보를 엽니다. 품목 번호, 창고 위치, 사용 가능 수량, 예상 입고 날짜를 확인할 수 있습니다. 이 정보는 어제 가져온 재고 스프레드시트에 의존하는 대신 외부 창고 또는 ERP 시스템에서 실시간으로 바로 전달됩니다. Dynamics 365는 통합 작업 공간의 역할을 하고, 재고에 관한 최종 기준은 여전히 창고 시스템입니다.

이러한 런타임 아키텍처는 데이터 중복의 위험을 없앱니다. 사용자가 쿼리를 실행하면 애플리케이션은 간결한 순서로 처리합니다. 영업 담당자가 제품 목록을 열고 판매 가능한 품목으로 필터링합니다. Dataverse는 대상이 가상 테이블임을 인식합니다. 기반 데이터 공급자는 요청을 받아 데이터 원본의 연결 정보를 사용해 외부 서비스에 연결하고, 사용자의 필터를 외부 시스템이 이해할 수 있는 형식으로 변환합니다. 일치하는 레코드를 가져오고, 결과를 표준 Dataverse 행으로 변환한 뒤 사용자 인터페이스에 즉시 표시합니다. 사용자는 끊김 없는 경험을 하는 반면, 데이터는 권한 있는 원래 위치를 벗어나지 않습니다.

핵심 구성 요소 세 가지: 데이터 공급자, 데이터 원본, 테이블

이 기능이 내부에서 작동하도록 하기 위해, 모든 가상 테이블은 세 가지 핵심 아키텍처 구성 요소에 의존합니다. 바로 데이터 공급자, 데이터 원본, 그리고 가상 테이블 정의 자체입니다. 견고한 통합 전략을 설계하려면 이 세 가지 구성 요소를 이해하는 것이 필수적입니다.

데이터 공급자란 무엇인가요?

데이터 공급자는 아키텍처에서 핵심 변환기 역할을 합니다. Dynamics 365와 Dataverse는 자체 내부 개념인 테이블, 열, 필터, 레코드 ID를 사용해 요청을 보냅니다. 그러나 외부 시스템은 전혀 다른 API, 프로토콜 또는 데이터 형식을 사용할 가능성이 큽니다. 공급자는 이 두 측 사이를 변환합니다. 사용자는 이 복잡한 과정을 이해할 필요가 없으며, 표준 Dynamics 365 애플리케이션 인터페이스를 통해 결과 레코드와 상호 작용하기만 하면 됩니다.

Microsoft는 OData 버전 4 공급자를 기본으로 지원합니다. OData는 웹을 통해 데이터를 노출하고 조회하는 표준화된 방식으로, 업계에서 널리 인정받고 있습니다. 외부 서비스가 OData로 제품 번호, 설명, 단가, 재고 수량 같은 필드를 가진 제품 데이터를 노출한다면, 기본 제공 공급자가 해당 레코드를 요청해 Dataverse가 기본적으로 이해하는 구조로 반환할 수 있습니다. 최신 클라우드 애플리케이션이라면 이런 방식으로 통합이 놀랍도록 간단해집니다.

물론 모든 레거시 또는 사용자 지정 비즈니스 애플리케이션이 OData를 지원하는 것은 아닙니다. 아키텍처상 다른 통합 방식이 필요하다면 조직은 사용자 지정 데이터 공급자를 구현할 수 있습니다. 숙련된 개발자라면 Dataverse와 독자적인 REST API, SQL 데이터베이스, 또는 내부 기업 웹 서비스를 연결하는 사용자 지정 공급자를 작성할 수 있습니다. 기반 기술과 관계없이 사용자 지정 공급자가 수행하는 기본 역할은 같습니다. Dataverse 요청을 받고, 외부 시스템과 통신하고, 응답을 변환한 뒤, 레코드를 끊김 없이 반환하는 것입니다.

데이터 원본이란 무엇인가요?

데이터 공급자가 통신 방식을 안다면, 데이터 원본에는 목적지에 도달하는 데 필요한 구체적인 주소와 자격 증명이 들어 있습니다. 데이터 원본에는 서비스 엔드포인트 주소, 인증 매개 변수, API 키, 연결 관련 조절(throttling) 설정 등 외부 서비스의 모든 연결 정보가 포함됩니다. 공급자를 언어 전문가로, 원본을 주소록으로 생각하면 이해하기 쉽습니다.

외부 열 매핑과 고유 레코드 ID

연결이 설정되면 외부 열을 가상 테이블 스키마에 매핑해야 합니다. 예를 들어 창고 애플리케이션에서는 "Available Quantity"라는 필드를 쓰는 반면, Dynamics 365 사용자는 "Stock on Hand"라고 보기를 원할 수 있습니다. 필드 매핑은 이 두 이름이 같은 정보를 가리킨다고 Dataverse에 알려 줍니다. 이를 통해 외부 시스템에 비용이 많이 드는 스키마 이름 변경을 요구하지 않고도 Dynamics 365 안에서 사용자에게 친숙한 용어를 제공할 수 있습니다.

또한 Dataverse는 각 레코드를 구분할 수 있도록 신뢰할 수 있는 고유 식별자를 요구합니다. 가상 테이블 레코드에는 Dataverse가 인식할 수 있는 안정적인 고유 키가 있어야 합니다. 견고한 ID가 없으면 Dataverse는 사용자가 선택한 제품, 청구서, 고객이 정확히 무엇인지 확실하게 판단할 수 없습니다. 따라서 특정 외부 데이터 원본이 가상 테이블로 효과적으로 작동할 수 있는지 평가할 때, 레코드 식별은 매우 중요한 기술적 전제 조건입니다.

아키텍처에서 가상 테이블을 사용하는 시점

가상 테이블은 아키텍처 관점에서 강력한 패러다임 전환입니다. 마스터 데이터의 소유권이 특정 외부 전문 시스템에 있으면서도, Dynamics 365 사용자가 일상 업무 중에 그 정보를 맥락에 맞게 봐야 하는 상황에서 가장 효과적입니다. 대표적인 예로 실시간 재고 추적, 복잡한 제품 카탈로그, 구매 주문 상태, 실시간 청구서 상태, 재무 원장 요약, 공급업체 디렉터리, 타깃 마케팅 인사이트 등이 있습니다.

비즈니스 레코드의 수명 주기 관리는 외부 애플리케이션이 맡고, Dynamics 365 사용자에게는 맥락에 맞는 가시성을 제공하면 데이터 중복의 위험을 없앨 수 있고, Dataverse의 저장 공간 낭비도 줄일 수 있으며, 팀이 항상 실시간의 정확한 정보를 바탕으로 결정하도록 할 수 있습니다. 이제 데이터를 복사하는 일은 그만두고, 최신 가상화의 힘을 활용할 때입니다.

정리하자면, 기존의 데이터 동기화 방식에서 벗어나 가상 테이블을 도입하면 Microsoft 365 아키텍처를 크게 간소화할 수 있습니다. 단일 정보 원본(single source of truth)을 그대로 유지하면서 오래된 데이터가 머무는 시간을 없애고, 사용자가 오랫동안 원해 온 통합된 작업 공간을 제공할 수 있습니다. 이 주제를 더 깊이 알고 싶다면 Dynamics 365 Virtual Entities - Simply Explained 에피소드 전체를 꼭 들어 보시기 바랍니다.