Dataverse 표준 테이블과 가상 테이블 비교: 데이터 복사를 언제 중단해야 하는가

By Mirko Peters · 2026-08-22

Dataverse 표준 테이블과 가상 테이블을 비교합니다. 기업 데이터 복사를 언제 중단해야 하는지, 그리고 외부 시스템을 실시간으로 들여다보는 창을 어떻게 구현하는지 알아봅니다.

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

Dataverse 표준 테이블과 가상 테이블 중 무엇을 선택하느냐에 따라 외부 데이터를 얼마나 효율적으로 다루는지가 결정됩니다. 표준 테이블은 레코드를 Dataverse 안에 직접 저장하는 반면, 가상 테이블은 외부 ERP, 창고, 재무 시스템을 실시간으로 들여다보는 창을 만들어 위험한 야간 동기화 작업과 오래된 정보를 없애 줍니다.

핵심 요약

• 표준 Dataverse 테이블은 레코드를 로컬에 영구적으로 저장하는 반면, 가상 테이블은 필요할 때 외부 소스에서 가져온 실시간 레코드를 표시합니다.
• 가상 테이블을 사용하면 야간 동기화 작업이 필요 없어져, 영업팀이 오래된 재고 수량을 기준으로 일하는 위험이 사라집니다.
• 아키텍처를 선택할 때는 핵심 비즈니스 프로세스와 레코드의 수명 주기 관리가 실제로 어디에 속하는지를 우선적으로 고려해야 합니다.
• 외부 데이터에 의존하므로 가상 테이블에서는 성능, 보안 권한, 필터링 기능이 다르게 작동합니다.
• Dynamics 365를 통해 사용자를 권한 있는 외부 애플리케이션에 직접 연결하면 저장 오버헤드와 데이터 중복을 줄일 수 있습니다.

아키텍처 딜레마: 저장과 접근 사이의 선택

Microsoft Dynamics 365나 사용자 지정 Power Apps를 구현할 때 설계자는 근본적인 질문에 끊임없이 직면합니다. 외부 데이터를 Dataverse에 복사해야 할까, 아니면 원래 시스템에 그대로 두고 연결 다리를 만들어야 할까? 수년간 기본 답은 복제였습니다. 사용자가 모든 데이터를 한 곳에서 볼 수 있도록, 조직은 제품 카탈로그, 재고 잔액, 송장 이력을 Dataverse에 그대로 밀어 넣는 야간 통합 루틴을 예약해 왔습니다.

하지만 이런 복제 전략은 심각한 아키텍처 부담을 낳습니다. 저장 한도는 점점 차오르고, 데이터베이스는 빠르게 비대해지며, 무엇보다 데이터가 최신 상태가 아니라는 점이 운영 위험을 키웁니다. 창고 직원이 점심시간에 핵심 품목 10개를 출고하더라도, Dataverse에 복제된 테이블은 다음 예약 일괄 동기화가 실행될 때까지 그 10개를 계속 보여 줍니다. 그러면 영업 담당자는 존재하지 않는 재고를 고객에게 안내하게 되고, 주문 취소와 신뢰 하락으로 이어집니다. 표준 테이블은 자신이 보관하는 데이터에 대한 절대적인 소유권을 요구하므로, 전문화된 기업 시스템이 관리하는 빠르게 변하는 운영 지표에는 적합하지 않은 선택입니다.

표준 테이블과 가상 테이블 비교

표준 Dataverse 테이블과 가상 테이블의 운영상 차이를 이해하면 각 아키텍처를 언제 사용해야 하는지 분명해집니다. 이 차이는 기술적 의미를 넘어, 시스템 소유권, 사용자 워크플로, 유지 관리 부담을 좌우합니다.

표준 Dataverse 테이블

계정, 연락처, 영업 기회와 같은 표준 테이블은 Dataverse 생태계의 기본 구성 요소입니다. Dataverse는 데이터베이스 테이블을 만들고, 물리적 저장소를 관리하며, 테이블 수준 보안 모델을 적용하고, 레코드에 대해 비즈니스 로직, 플러그인, 워크플로를 기본적으로 실행합니다. 사용자가 레코드를 만들거나 업데이트하면 Dataverse가 최종 권한을 가집니다. 애플리케이션 계층과 저장 계층이 완전히 통합되어 있습니다.

가상 테이블

가상 테이블은 도서관 카탈로그나 보안 영상 피드에 더 가깝게 작동합니다. Dataverse에는 모델 기반 앱에서 익숙한 사용자 인터페이스를 표시하는 데 필요한 스키마, 열 정의, 메타데이터가 저장되지만, 실제 레코드는 저장하지 않습니다. 사용자가 뷰를 열거나 필터를 적용하면 Dataverse는 요청을 변환하여 데이터 공급자를 통해 외부 시스템에 쿼리하고, 실시간 응답을 즉시 표시합니다. 레코드의 수명 주기에 대한 최종 권한은 여전히 외부 애플리케이션에 있습니다.

운영상의 장단점과 제약 사항 평가

가상 테이블은 동기화의 번거로움을 해결하지만, 개발자와 관리자가 신중하게 검토해야 할 고유한 제약도 따릅니다. 기본 데이터가 Dataverse에 존재하지 않기 때문에, 일부 플랫폼 기능은 표준 테이블에서와 다르게 동작합니다.

고급 찾기, 복잡한 서버 쪽 플러그인, 롤업 필드, 백그라운드 비동기 워크플로는 로컬 데이터 지속성을 전제로 하면 예측할 수 없이 동작하거나 완전히 실패할 수 있습니다. 또한 성능은 외부 API 또는 데이터 소스의 상태와 응답성에 직접적으로 좌우됩니다. 외부 ERP나 창고 애플리케이션에 지연이 발생하거나 오프라인 상태가 되면, Dynamics 365의 해당 가상 테이블은 멈추거나 연결 오류를 발생시킵니다.

보안 모델링에도 신중한 계획이 필요합니다. Dataverse 보안 역할로 가상 테이블 정의를 보거나 편집할 수 있는 사용자를 제어할 수 있지만, 사용자가 권한이 있는 레코드에만 접근하도록 하려면 행 수준 보안을 외부 API 수준에서 적용하거나 사용자 지정 데이터 공급자를 통해 구현해야 하는 경우가 많습니다.

결론

표준 Dataverse 테이블과 가상 테이블 중 무엇을 선택할지는 결국 데이터의 수명 주기를 누가 소유하는지, 그리고 사용자에게 지속적인 로컬 저장소가 필요한지 아니면 단순한 상황별 가시성만 필요한지에 따라 달라집니다. 외부 데이터 소스를 복제하지 않고 명확하게 매핑하면, 조직은 중복된 데이터베이스 테이블로 Dataverse를 어지럽히지 않고 Dynamics 365에서 깔끔한 작업 공간을 유지할 수 있습니다. 이 통합 접근 방식의 기본 구성 요소를 알아보려면 전체 에피소드를 들어보시고 실용적인 클라우드 인사이트를 더 얻으려면 팟캐스트를 구독하시기 바랍니다.

자주 묻는 질문

가상 테이블도 Dataverse 저장 용량을 사용하나요?

아니요. 가상 테이블은 Dataverse에 테이블 정의, 메타데이터, 스키마만 저장하고 실제 레코드는 외부 시스템에 두기 때문에, 조직의 Dataverse 데이터베이스 저장 용량을 사용하지 않습니다.

사용자가 가상 테이블을 통해 표시된 레코드를 편집할 수 있나요?

예, 기본 데이터 공급자와 외부 시스템이 쓰기 작업을 지원하는 경우에는 가능합니다. 기본 제공 OData v4 공급자와 Finance and Operations 통합은 만들기, 업데이트, 삭제 작업을 지원할 수 있지만, 외부 시스템은 자체 유효성 검사 규칙을 계속 적용합니다.

외부 데이터 소스가 오프라인이 되면 어떻게 되나요?

외부 애플리케이션이나 해당 API를 사용할 수 없게 되면, Dynamics 365 내에서 가상 테이블을 보고 있는 사용자는 로드 오류가 발생하거나 빈 그리드가 표시됩니다. 실시간 쿼리로 외부 레코드를 가져올 수 없기 때문입니다.

가상 테이블과 가상 엔터티는 같은 것인가요?

예. 가상 엔터티는 이전 Microsoft 문서와 구성에서 사용되던 기존 용어이고, 가상 테이블은 현재 공식 용어입니다. 기본 아키텍처와 개념은 동일합니다.