Microsoft Fabric 커넥터로 데이터 소스 연동을 표준화하는 방법

데이터 소스가 늘어날수록 연결 계층이 먼저 흔들린다

Microsoft Fabric 같은 분석 SaaS를 도입할 때 어려운 지점은 Lakehouse나 Warehouse 자체보다, 수백 개의 SaaS·DB·파일 시스템을 일관된 방식으로 연결하는 일이다. 인증 방식, 추출 조건, 증분 기준, 스키마 변경, 실패 복구 정책이 소스별로 흩어지면 운영 복잡도가 빠르게 커진다.

패브릭 커넥터(Fabric Connector)는 이런 연동을 표준화하는 모듈형 연결 구성 요소다. Microsoft Fabric의 Power Query 엔진을 기반으로 여러 데이터 소스에서 데이터를 읽고 변환해 적재하며, Dataflows Gen2, 파이프라인, 노트북 등 Fabric 워크로드에서 공용으로 사용할 수 있다. 빌트인 커넥터와 커스텀 커넥터로 나뉘고, OneLake 기반 Lakehouse와 Warehouse로 데이터를 유입시키는 기반 계층 역할을 맡는다.

연동에 필요한 입력은 인증 정보, 연결 문자열 또는 엔드포인트, 추출 쿼리·필터, 증분 기준이다. 처리 과정에서는 커넥터 드라이버 호출 뒤 인증 핸들러(OAuth2/Key/Basic/On-prem Gateway), 스키마 추론·변환, 페이징·스로틀링, 재시도·체크포인트가 이어진다. 결과는 OneLake의 Lakehouse 테이블·파일, Warehouse 테이블, 데이터플로 엔티티와 라인리지 메타데이터로 남는다.

연결부터 운영까지 한 흐름으로 다루기

커넥터 계층은 JDBC/ODBC, REST, S3/ADLS/SFTP 파일 시스템을 포함한 수백 종의 빌트인 연동을 제공한다. 온프레미스 데이터는 데이터 게이트웨이를 통해 안전하게 연결할 수 있고, 사내 전용 API나 레거시 시스템은 커스텀 커넥터로 연동한다.

인증은 OAuth2, 서비스 프린시펄, Key/Basic 인증, 게이트웨이 자격증명 보관을 중심으로 구성된다. 토큰 갱신과 비밀 관리, 범위 최소화 원칙을 함께 적용하며, 테넌트·워크스페이스·데이터 항목 권한(ABAC/RBAC)과 연결할 수 있다. Purview 라인리지와 데이터 카탈로그로 메타데이터를 통합하는 것도 이 계층의 운영 범위다.

데이터 변환은 Power Query(M) 기반으로 처리한다. 스키마 드리프트, 컬럼 매핑, 형 변환, 타임존 정규화를 다루고, 증분 적재에는 변경 추적 컬럼과 하이워터마크, CDC 로그, API since-cursor를 활용한다.

대량 처리에서는 페이징·배치 처리, 동시성 설정, 스로틀 백오프, 지수 재시도가 필요하다. 스테이징 저장소와 파일 기반 병렬 적재를 사용하면 처리량을 높일 수 있다. 실행 로그와 라인리지, 처리량·지연·오류율 메트릭을 남기고, 실패한 데이터는 DLQ 패턴과 부분 재시작으로 처리하며 알림·티켓 시스템과 연동한다. 스케줄링, 이벤트 트리거, 파라미터화는 여러 소스의 운영 방식을 맞추는 데 쓰인다.

소스 성격에 따라 달라지는 적재 방식

ERP를 OneLake로 증분 적재할 때는 SAP 커넥터로 ODP/ODATA 기반 데이터를 추출하고 하이워터마크 전략을 적용할 수 있다. 데이터플로에서 스테이징한 뒤 Lakehouse Delta 테이블에 커밋하며, 실패한 경우 배치 단위 재시도와 부분 롤백을 수행하면서 라인리지 기록을 유지한다.

Salesforce나 ServiceNow 같은 CRM/SaaS API는 REST 커넥터와 동적 페이징·백오프를 함께 사용한다. CDC 이벤트가 제공되지 않으면 수정일자 기반 폴링과 최종 커서 저장으로 중복을 방지한다.

로그와 반정형 데이터는 S3/ADLS 파일 커넥터를 통해 JSON 또는 Parquet로 읽어 들인다. 스키마 추론 뒤에는 스키마 레지스트리 패턴으로 컬럼 추가를 관리하고, ingestion_date=YYYY-MM-DD 형태의 파티션 경로를 표준화해 쿼리 성능을 최적화한다.

온프레미스 SQL Server와 Oracle은 게이트웨이를 통해 연결해 네트워크 분리 환경을 준수한다. 자격증명 로테이션 자동화와 감사 로깅 활성화는 컴플라이언스 요구사항에 대응하는 방식이다.

커넥터가 놓이는 처리 경로

⤢✕

빌트인·커스텀·일회성 스크립트의 운영 차이

구분	성능	확장성	일관성	안정성	운영 편의
빌트인 커넥터	최적화된 드라이버로 높은 수준	커넥터 수평 확장 용이	표준 스키마/정책 준수	백오프·재시도 내장	UI 기반 관리 용이
커스텀 커넥터	설계에 따라 상이	기능 확장 유연	사내 표준 반영 가능	추가 테스트 필요	배포·버전 관리 필요
일회성 스크립트	단건 최적화 가능	재사용성 낮음	표준화 미흡	스크립트별 편차 큼	인력 의존도 높음

커스텀 REST 커넥터의 M 스켈레톤

개발 환경은 VS Code와 Power Query SDK(v1.6+), .mez 빌드를 전제로 한다. 대상은 Microsoft Fabric 워크스페이스의 Dataflows Gen2이며, 인증 방식은 OAuth2 Client Credentials 예시다.

section MyRestConnector;

[DataSource.Kind="MyRestConnector", Publish="MyRestConnector.Publish"]
shared MyRestConnector.Contents = (baseUrl as text, optional since as nullable text) =>
let
    Token = MyRestConnector_GetToken(),
    PageSize = 1000,
    Source = MyRestConnector_Paged(baseUrl, since, Token, PageSize),
    Json = List.Transform(Source, each Json.Document(_)),
    Table = Table.FromList(Json, Splitter.SplitByNothing(), {"record"}),
    Expanded = Table.ExpandRecordColumn(Table, "record", {"id","updatedAt","payload"}, {"id","updatedAt","payload"})
in
    Expanded;

MyRestConnector_Paged = (baseUrl as text, since as nullable text, token as text, pageSize as number) as list =>
let
    GetPage = (url as text) =>
        let
            Options = [ Headers = [ Authorization = "Bearer " & token ],
                        ManualStatusHandling = {429, 500, 502, 503, 504} ],
            Response = Web.Contents(url, Options),
            Retry = if Value.Metadata(Response)[Response.Status] = 429 then
                        Function.InvokeAfter(()=>Web.Contents(url, Options), #duration(0,0,0,5))
                    else Response,
            Body = Binary.ToText(Retry)
        in
            Body,
    InitialUrl = baseUrl & "?" & (if since <> null then "since=" & since & "&" else "") & "limit=" & Number.ToText(pageSize),
    Pages = List.Generate(
                ()=> [url = InitialUrl, i = 0, last = ""],
                each [url] <> null,
                each [
                    last = GetPage([url]),
                    i = [i] + 1,
                    url = let next = Json.Document(Text.ToBinary([last]))?[next] in if next <> null then next else null
                ],
                each [last]
            )
in
    Pages;

MyRestConnector_GetToken = () as text =>
let
    clientId = Extension.CurrentCredential()[Username],
    clientSecret = Extension.CurrentCredential()[Password],
    tokenUrl = "https://login.example.com/oauth2/token",
    body = "grant_type=client_credentials&client_id=" & clientId & "&client_secret=" & clientSecret,
    response = Json.Document(Web.Contents(tokenUrl, [Headers=[#"Content-Type"="application/x-www-form-urlencoded"], Content=Text.ToBinary(body)]))
in
    response[access_token];

MyRestConnector = [
    Authentication = [
        UsernamePassword = []
    ],
    Label = "My REST API Connector"
];

MyRestConnector.Publish = [
    Beta = true,
    Category = "Other",
    ButtonText = { "My REST API Connector", "Connect to My REST API" },
    SourceImage = MyRestConnector.Icons,
    SourceTypeImage = MyRestConnector.Icons
];

MyRestConnector.Icons = [
    Icon16 = { Extension.Contents("Icon16.png"), Extension.Contents("Icon16.png") },
    Icon32 = { Extension.Contents("Icon32.png"), Extension.Contents("Icon32.png") }
];

이 스켈레톤에서는 스로틀링과 오류 코드별 재시도 정책을 분리하고, 429/5xx에는 백오프를 적용한다. updatedAt 하이워터마크를 기준으로 since 파라미터를 저장해 멱등 적재를 보장한다. 응답이 큰 경우에는 압축 전송과 증분 컬럼 인덱스를 활용하고, JSON을 Parquet로 변환한 뒤 Delta 테이블에 머지한다.

보안과 운영 기준이 만드는 선택지

읽기 전용 스코프와 서비스 프린시펄을 사용하고 토큰 수명을 단축하면 위험 표면을 줄일 수 있지만, 토큰 갱신 오버헤드는 증가한다. 온프레미스 게이트웨이와 프라이빗 링크·IP 필터링은 데이터 유출 리스크를 낮추는 대신 초기 네트워크 설정을 복잡하게 만든다.

비밀은 Key Vault 또는 자격증명 저장소에 두고 롤링 주기를 자동화한다. 컴플라이언스 충족에는 유리하지만, 실패 시 의존성으로 인한 연결 장애가 발생할 수 있다. 스키마 레지스트리와 호환성 규칙(추가 허용/삭제 금지)은 파이프라인 안정성에 도움이 되지만 스키마 정리가 늦어질 수 있다.

실행 로그·메트릭·알림을 일원화하고 SLO 기반 에스컬레이션을 두면 Mean Time To Restore를 단축할 수 있다. 그 대가로 모니터링 비용은 증가한다.

입력부터 실패 복구까지 설계할 범위

시작 단계에서는 소스 인벤토리와 인증 스킴을 정의하고, 증분 기준·SLA·데이터 분류 정책을 수립한다. 이후 커넥터를 선택하거나 개발하고, Power Query 변환을 설계한 뒤 파이프라인의 스케줄과 파라미터를 구성한다. 게이트웨이와 네트워크 설정도 이 흐름에 포함된다.

테스트에서는 429/5xx와 스키마 변경을 포함한 실패 주입 시나리오를 검증한다. 운영 결과는 OneLake에 적재하고 Lakehouse Delta 테이블에 머지한 뒤, 라인리지를 등록하고 데이터 카탈로그에 공개한다. 오류는 DLQ 분기, 부분 재시작 체크포인트, 재시도·백오프·경보 기준으로 처리하며 운영 대시보드에서 상시 관제한다.

파이프라인 개발 시간은 30~~50% 단축되고, 커스텀 스크립트 대비 장애율은 60% 감소하는 정량 효과가 제시된다. 대량 적재에서는 스테이징 병렬화로 처리량이 2~~5배 향상되고 비용 대비 운영 생산성은 40% 향상된다. 데이터 거버넌스와 라인리지를 한곳에서 관리하고 소스 변경·증분 정책을 표준화하면 팀 간 재사용성이 높아지며, 온보딩과 운영 교육 비용을 줄일 수 있다.

빌트인 커넥터를 우선 적용하고 필요한 지점만 커스텀 커넥터로 보완하면, 데이터 소스 다양성과 변화 속도에 맞춰 연결 계층을 확장할 수 있다.