고급 Dynamics 365 데이터 활용하기: 프로덕션용 사용자 지정 커넥터

By Mirko Peters · 2026-08-11

Power Platform과 Dynamics 365 통합을 한 단계 끌어올리기 위한 심층 가이드에 오신 것을 환영합니다. 기본 제공 구성 요소로 특정 사용자 지정 테이블을 가져오거나, 복잡한 계산 필드를 실행하거나, 정확한 OData 쿼리를 실행하려다 막힌 적이 있다면 여러분만 그런 것이 아닙니다. 표준 도구는 빠른 애플리케이션 개발에 매우 유용하지만, 엔터프라이즈 아키텍처에서는 세밀한 제어, 견고한 오류 처리, 철저한 보안 가드레일이 필요한 경우가 많습니다. 이번 종합 게시물에서는 사용자 지정 커넥터가 Power Platform과 Dataverse Web API 사이의 간극을 어떻게 메우고, 데이터 환경을 완전히 제어할 수 있게 해 주는지 살펴보겠습니다.

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

Titelbild: Unlocking Advanced Dynamics 365 Data with Production Custom Connectors

이 글은 팟캐스트 에피소드에서 다룬 개념을 직접 확장한 것입니다. 오디오 해설을 듣고 세부 내용을 모두 확인하고 실제 구현 사례를 듣고 싶다면 관련 에피소드 Expose Dynamics 365 APIs with Power Platform Custom Connectors를 꼭 확인하세요.

태그라인

표준 커넥터가 멈춰도 자동화까지 멈출 필요는 없습니다.

학습 내용

표준 Dynamics 365 커넥터에서 부족한 기능을 파악하는 방법
필요한 정확한 Dynamics/Dataverse Web API 엔드포인트를 찾는 실용적인 작업 흐름
보안이 적용된 사용자 지정 커넥터 구축(Azure AD 기반 OAuth2, 범위, 서비스 주체)
프로덕션 패턴: 필터링, 페이지 매김, 조절(throttling), 재시도, 스키마 변화 대응
거버넌스: DLP, RBAC, 소유권, 버전 관리, 모니터링, 감사

한 문장으로 요약한 문제

표준 커넥터는 사용자 지정 테이블, 계산 필드, 유연한 필터를 항상 노출하지는 않습니다. 사용자 지정 커넥터를 사용하면 엔터프라이즈 가드레일 안에서 API를 완전히 제어할 수 있습니다.

참조 설계도(엔드 투 엔드)

1) 탐색

필요한 항목(사용자 지정 테이블, 열, 고급 필터, 작업)을 매핑합니다.
Dataverse Web API 메타데이터, 솔루션 탐색기 또는 API Inspector/Postman을 사용하여 엔드포인트와 논리 이름을 확인하십시오.
샘플 페이로드로 OData $filter, $select, $expand 쿼리를 검증합니다.

2) 보호

Azure AD 앱 등록(단일 테넌트, OAuth2)을 만듭니다.
최소 Graph/Dataverse 앱 역할을 부여하고 사용자 위임 방식과 서비스 주체 방식 중 무엇을 쓸지 결정합니다.
사용자 지정 커넥터용 리디렉션 URL을 구성하고 비밀 키 순환 계획을 세웁니다.

3) 구축

Power Platform에서 사용자 지정 커넥터를 만듭니다(OpenAPI 사용 또는 처음부터 작성).
호스트, 기본 경로, 인증, 작업(GET/POST/PATCH)을 정의하고 쿼리/본문 스키마를 포함합니다.
정책을 추가합니다: 지수 백오프 재시도, 페이지 매김, 기본 헤더 설정, 시간 제한.

4) 거버넌스 적용

소유자를 지정하고 환경(개발/테스트/프로덕션)을 설정하며 DLP 정책 분류를 적용합니다.
RBAC/보안 그룹으로 사용을 제한하고 범위와 데이터 도메인을 문서화합니다.
버전 관리(v1, v2…), 변경 로그, 지원 중단 일정을 수립합니다.

5) 운영

흐름 실행과 커넥터 원격 분석을 모니터링하고, 4xx/5xx 급증 및 장시간 실행에 대해 알림을 설정합니다.
회로 차단기를 추가하고, 429 조절에 대해 대기열 재실행을 구성하며, 사용량을 추적합니다.
권한, 비밀 키, API 변경 사항을 분기별로 검토합니다.

API 탐색 빠른 가이드

논리 이름 찾기: 솔루션에서 테이블/열의 논리 이름을 확인합니다(예: new_pricetierlevelid).
Postman으로 쿼리 테스트:
- GET .../api/data/v9.2/new_warrantyclaims?$select=...&$filter=modifiedon ge {timestamp}
- 조회에는 $expand를 사용하고, $count와 페이지 매김(@odata.nextLink)을 함께 사용합니다.
계산/롤업 필드: 실체화되어 있고 필터링 가능한지 확인합니다. 그렇지 않다면 서버 측(FetchXML)이나 하위 단계에서 계산합니다.
작업/함수: CRUD만으로 부족할 때 바인딩된/바인딩되지 않은 작업(예: CalculatePrice)을 호출합니다.

보안 및 개인정보 보호 가드레일

OAuth2(Azure AD)를 사용하고 API 키는 사용하지 않습니다.
최소 권한: 앱 역할을 특정 테이블과 작업으로 제한하며, 백그라운드 작업에는 서비스 주체를 우선 사용합니다.
사용자 귀속: 비즈니스상 사람 단위의 감사 추적이 필요하면 위임된 권한을 사용합니다.
DLP: 커넥터를 Business로 분류하고, 개인용 서비스로 향하는 경계 간 흐름은 차단합니다.
데이터 최소화: 필요한 열만 $select로 가져오고, 하위 단계에서 PII를 마스킹하며, 필요한 경우 환경 RLS를 적용합니다.

실무 패턴(바로 복사해 쓸 수 있는 예시)

429/5xx에 대한 지수 백오프

초기 지연은 2~5초로 설정하고, 상한(예: 60초)까지 두 배씩 늘립니다. 최대 재시도는 5~7회로 설정하고, 상관 ID(correlation ID)를 로그에 기록합니다.

페이지 나누기

@odata.nextLink를 따릅니다. 가능한 경우 서버 측에서 페이지를 집계하고, 제한 범위 안에서 페이지 크기(예: $top=5000)를 설정합니다.

델타 로드

modifiedon ge {lastRunUtc}로 필터링합니다. 마지막으로 성공한 워터마크를 저장하고, 시계 오차(clock skew)를 처리합니다.

멱등성

중복을 피하려면 업서트(PATCH와 If-Match 또는 대체 키 사용)를 사용하고, 원본 ID를 저장합니다.

스키마 변화 대응

누락되거나 추가된 필드를 감지하고, 알 수 없는 항목은 소프트 실패(soft-fail)로 처리합니다. 마이그레이션 기간에는 v1/v2 커넥터를 함께 유지합니다.

사용 사례 예시(그리고 사용자 지정 커넥터가 이를 해결하는 방법)

사용자 지정 테이블 동기화(WarrantyClaims)

작업: GET /new_warrantyclaims?$select=claimid,status,amount&$filter=modifiedon ge {ts}
흐름: 반복 → 클레임 가져오기 → 각 항목에 대해 → Dataverse/ERP에 업서트

"VIP 계정"에 대한 고급 필터

작업: GET /accounts?$filter=new_vipstatus eq true and statuscode eq 1
흐름: 일정에 따라 트리거 → VIP이면서 활성 상태인 계정만 처리 → CSM에게 알림

서버 작업 호출(재계산)

작업: 매개 변수(날짜 범위, 세그먼트)를 포함한 POST /CalculateRevenue(unbound)
흐름: 필요 시 또는 런북에서 실행 → 작업 호출 → 결과를 보고 테이블에 저장

모니터링 및 안정성

대시보드: 작업별 성공률, 평균 지연 시간, 재시도 횟수, 주요 오류 코드, 처리량을 표시합니다.
경고: 지속적인 429 응답, 인증 실패, P95 지연 시간 초과, 스키마 불일치를 감시합니다.
로그: 재실행에 대비해 텔레메트리에 요청 ID, 파티션 키, 워터마크를 포함합니다.
복원력: 반복 실패 시 대기열 오버플로 경로(예: Dataverse 테이블 또는 Azure Queue)를 마련합니다.

거버넌스 및 수명 주기

등록된 소유자(앱 및 커넥터), 문서화된 목적, 데이터 영역, 소비자를 기록합니다.
승격 워크플로: PRD에는 승인된 산출물만 배포하고, 환경별 비밀은 연결 참조를 통해 관리합니다.
검토 주기: 분기별 액세스 검토, 비밀 키 교체, API 지원 중단(deprecation) 여부 점검을 수행합니다.
사용 중지: 사용 중지 예정으로 표시하고, 새 연결을 차단한 뒤 마이그레이션이 끝나면 종료합니다.

10단계 빠른 시작(주간 계획)

표준 커넥터의 공백(테이블/필드/필터/작업)을 나열합니다.
Postman에서 Web API 엔드포인트와 쿼리를 확인합니다.
Azure AD 앱을 등록하고, 위임 방식과 앱 전용 방식 중 무엇을 쓸지 정합니다.
사용자 지정 커넥터를 개발 환경에서 만들고 작업과 스키마를 정의합니다.
정책을 추가합니다: 재시도, 페이지 나누기, 헤더, 제한 시간.
환경별로 연결 참조를 만듭니다.
파일럿 흐름을 배포하고 볼륨, 필터, 멱등성을 검증합니다.
모니터링과 경고를 추가하고 런북을 문서화합니다.
테스트/프로덕션으로 승격하고 DLP/RBAC로 잠급니다.
v1 문서를 게시하고 v2를 계획합니다(알려진 제한 사항, 로드맵).

흔한 실수와 해결 방법

429 제한 → 백오프와 일괄 처리를 구현하고 일정을 분산합니다.
과도한 권한 → 최소 권한 앱 역할을 사용하고 도메인별로 커넥터를 나눕니다.
하드코딩된 비밀 → 서비스 주체와 관리되는 비밀을 사용하고 분기마다 교체합니다.
커넥터 난립 → 중앙 카탈로그, 소유자, 버전 관리 정책을 둡니다.
스키마 단절 → 개발 환경에서 계약 테스트를 수행하고, API 변경 중에는 v1/v2를 병행 실행합니다.

자주 묻는 질문

Q: 사용자 지정/ISV 테이블에 접근할 수 있나요?
A: 네. Web API를 통해 논리 이름을 사용하고, 적절한 스키마를 갖춘 작업을 커넥터에 추가하면 됩니다.

Q: 위임 방식과 앱 전용 방식 중 무엇을 써야 하나요?
A: 백엔드나 예약 작업에는 앱 전용을 쓰고, 사용자 단위의 감사나 제어가 필요하면 위임 방식을 씁니다.

Q: DLP 규정 준수는 어떻게 유지하나요?
A: Business로 분류하고, 경계 간 커넥터를 차단하며, 보안 그룹별로 사용을 제한하고 내보내기를 기록합니다.

Q: 대규모에서의 성능은 어떤가요?
A: 읽기를 일괄 처리하고, 델타 쿼리를 사용하고, 429 응답에는 백오프를 적용하며, 병렬 처리는 신중하게 사용합니다. $top과 필터를 모니터링하며 조정합니다.

결론

Power Platform에서 커스텀 커넥터를 능숙하게 다루면, 개발자와 아키텍트는 일반적인 솔루션의 한계를 넘어 Dynamics 365 Web API의 강력한 기능을 직접 활용할 수 있습니다. 검색, 보안, 거버넌스, 운영 복원력을 위한 체계적인 설계 기준을 따르면, 조직의 보안 기준을 해치지 않으면서도 원활하게 확장되는 자동화 파이프라인을 구축할 수 있습니다. 기본 제공 블록에서 커스텀 API로 옮겨 갈 때는 인증, 조절(throttling), 수명 주기 관리를 신중하게 계획해야 한다는 점을 기억하십시오. 그만큼 얻는 보상은 비즈니스 데이터에 대한 완전한 통제력입니다.

실제 사례를 더 깊이 살펴보고, 전문가들의 토론을 듣고, 다음 Power Platform 구현을 성공으로 이끌 실용적인 팁을 찾으려면 관련 팟캐스트 콘텐츠를 꼭 들어 보십시오. 팟캐스트는 Expose Dynamics 365 APIs with Power Platform Custom Connectors에서 확인할 수 있습니다.