interlinear

실무자와 개발자 사이비즈니스 앱과 에이전트 사이자연어와 기계어 사이

Power Query 쓰던 사람을 위한 Dataflow Gen2: 달라진 건 '대상'이에요

Dataflow Gen2는 Power Query 편집기가 그대로예요. 진짜 달라진 건 결과를 어디로 보낼지 정하는 데이터 대상이에요. Gen1과의 차이와 staging 옵션까지 정리했어요.

원문: Dataflow Gen2 data destinations and managed settings 게시일: 2026-08-25

Power BI에서 Dataflow(지금은 Gen1이라고 불러요)를 만들어 본 적 있다면, Fabric의 Dataflow Gen2를 열었을 때 편집기가 낯설지 않을 거예요. Get Data부터 Applied Steps까지, 쓰던 Power Query 그대로예요. 그런데 막상 만들고 나면 한 가지가 헷갈려요. “이 쿼리, 저장은 어디에 되는 거지?”

Gen1에서는 이 질문이 필요 없었어요. Dataflow가 자기 내부 스토리지에 결과를 담아두고, Power BI에서 Dataflow 커넥터로 그걸 다시 불러오는 구조가 전부였거든요. Gen2에서 정말 바뀐 건 여기예요. 결과를 내부에 둘지, 아니면 Lakehouse나 Warehouse 같은 실제 목적지로 바로 보낼지를 쿼리마다 정할 수 있게 됐어요. 이 설정이 **데이터 대상(data destination)**이에요.

Gen1과 뭐가 다른가

편집기는 같아도 몇 가지는 확실히 갈려요.

  • 다중 출력 목적지: Gen1은 내부 저장이 전부였지만, Gen2는 Azure SQL, Fabric Lakehouse(테이블·파일), Fabric Warehouse, KQL 데이터베이스, Fabric SQL 데이터베이스, SharePoint, Snowflake, PostgreSQL 등으로 바로 쓸 수 있어요.
  • 자동 저장과 백그라운드 게시: 작업 중 자동 저장되고, 게시(publish)할 때 백그라운드에서 검증이 돌아가요. Gen1은 이런 흐름이 없었어요.
  • 파이프라인과의 연동: Gen2는 Pipeline 활동으로 바로 이어붙일 수 있어요. 예를 들어 Blob에서 정제한 데이터를 Dataflow Gen2로 변환한 뒤, 파이프라인이 다음 단계를 계속 이어가는 식이에요.
  • 고성능 컴퓨팅: Gen2는 워크스페이스에 Lakehouse·Warehouse 아이템을 만들어서 그 컴퓨팅으로 대용량 데이터를 처리해요.

즉 Gen1을 “Power Query로 데이터를 다듬어서 Power BI에서만 쓰는 도구”라고 생각했다면, Gen2는 “Power Query로 다듬은 데이터를 조직의 여러 저장소로 배달하는 도구”에 가까워요.

데이터 대상은 쿼리마다 따로 설정해요

데이터 대상은 테이블 형태의 쿼리에만 붙일 수 있어요(함수나 리스트는 안 돼요). 한 Dataflow 안에서도 쿼리 A는 Lakehouse로, 쿼리 B는 Warehouse로 보내는 식으로 목적지를 다르게 줄 수 있어요. 설정하는 방법은 세 가지예요.

  • 상단 리본의 Add data destination
  • 오른쪽 쿼리 설정 창의 데이터 대상 버튼
  • 다이어그램 뷰에서 쿼리 옆 아이콘

목적지를 고를 때는 새 테이블 만들기와 기존 테이블 선택 중 하나를 정해요. 새 테이블은 새로고침 때마다 없으면 다시 만들어주고, 기존 테이블은 삭제돼도 Dataflow가 알아서 되살리지 않아요. Lakehouse는 특이하게 파일과 테이블 중 어디에 쓸지도 토글로 고를 수 있어서, 다른 목적지보다 유연해요.

자동 설정과 수동 설정 — 뭐가 다른가

새 테이블로 로드할 때는 기본적으로 **자동 설정(Use automatic settings)**이 켜져 있어요. 이걸 켜두면 세 가지가 자동으로 처리돼요.

  • 업데이트 방식은 항상 replace: 새로고침마다 대상의 기존 데이터를 지우고 Dataflow 출력으로 통째로 바꿔요.
  • 매핑을 알아서 관리: 쿼리에 열을 추가하거나 타입을 바꿔도, 다음 게시 때 매핑이 자동으로 맞춰져요. 매번 데이터 대상 화면에 들어가서 다시 연결할 필요가 없어요.
  • 테이블을 지우고 다시 만듦: 스키마 변경을 반영하기 위해 매 새로고침마다 테이블을 drop하고 recreate해요. 그래서 대상 테이블에 걸어둔 관계나 측정값이 새로고침 후 사라질 수 있어요.

자동 설정은 지금은 Lakehouse와 Azure SQL 데이터베이스에서만 지원돼요. 이걸 끄면 수동 설정이 되는데, 여기서는 업데이트 방식을 append(누적)로 바꿀 수 있고, 스키마 옵션도 직접 고를 수 있어요. Replace일 때만 고를 수 있는 스키마 옵션이 두 가지예요.

  • Dynamic schema: 쿼리가 바뀌면 다음 게시 때 대상 스키마도 같이 바뀌어요. 대신 매핑은 자동이 아니라서 변경 때마다 직접 손봐야 하고, 스키마 차이가 감지되면 테이블이 drop-recreate돼요.
  • Fixed schema: 스키마 변경 자체를 막아요. 새로고침 때는 행만 지우고 다시 채우기 때문에 관계·측정값이 안전해요. 대신 쿼리 스키마가 대상과 안 맞으면 게시 자체가 실패해요.

Warehouse나 Snowflake로 로드할 때는 fixed schema만 지원돼요. 스키마가 자주 안 바뀌고 관계·측정값을 지키고 싶다면 fixed를, 스키마가 계속 진화하는 초기 단계라면 dynamic이나 자동 설정을 쓰는 게 맞아요.

staging 옵션의 의미

Dataflow Gen2를 쓰다 보면 워크스페이스에 DataflowsStagingLakehouse나 DataflowsStagingWarehouse라는, 만든 적 없는 아이템이 보일 때가 있어요. 이건 Dataflow가 쿼리를 처리할 때 쓰는 내부용 임시 저장소예요. 직접 열어볼 필요는 없고, 손댈 것도 아니에요.

staging을 켜면 데이터가 이 내부 Lakehouse에 먼저 실리고, 이후 단계는 Fabric의 SQL 컴퓨팅으로 처리돼요. 메모리에서 바로 처리하는 것보다 SQL analytics endpoint1로 쿼리를 넘겨(폴딩2해서) 처리하는 게 더 빠른 경우에 유리해요.

기본값은 상황마다 달라요.

  • Lakehouse처럼 Warehouse가 아닌 목적지로 바로 쓸 때는 성능을 위해 기본적으로 staging이 꺼져 있어요. 데이터가 대상으로 바로 쓰여요.
  • Warehouse로 로드할 때는 staging이 필수예요. staging 없이 Warehouse를 목적지로 고르면 먼저 켜라는 경고가 떠요.

즉 “느린 것 같으면 무조건 staging을 켜라”가 아니라, 반대로 “이미 꺼져 있는 게 기본이고, 폴딩 이득이 클 때만 켜서 시험해 본다”에 가까워요. 쿼리를 마우스 오른쪽 버튼으로 눌러 Enable staging을 고르면 쿼리 색이 파란색으로 바뀌면서 켜진 걸 확인할 수 있어요.

정리

Dataflow Gen2는 편집기만 보면 Power Query 그대로지만, 실무에서 다루는 대상은 완전히 달라졌어요. Gen1처럼 내부 저장에 갇혀 있지 않고 Lakehouse·Warehouse 등으로 직접 쓸 수 있고, 그 설정을 쿼리 단위로 자동/수동, replace/append, dynamic/fixed 스키마까지 세밀하게 고를 수 있어요. staging은 기본적으로 꺼져 있는 성능 옵션이고, Warehouse로 갈 때만 필수라는 것만 기억해두면 헷갈릴 일이 없어요.


어휘 주석

  1. SQL analytics endpoint: Lakehouse의 Delta 테이블을 T-SQL로 읽기 전용 조회할 수 있게 해주는 Fabric의 자동 생성 엔드포인트.
  2. 쿼리 폴딩(query folding): Power Query의 변환 단계를 원본 소스(예: SQL 엔진)가 처리할 수 있는 쿼리로 바꿔서, 메모리 대신 소스 쪽 연산 능력을 쓰게 하는 최적화 방식.