📅 2026.03.22 기준 / Power BI Desktop v2.152.882.0 (03/15/2026)
Power BI Translytical, GA됐다는 말이
절반만 맞습니다
2026년 3월 드디어 정식 출시(GA)된 Translytical 워크플로우. 보고서 안에서 데이터를 직접 수정한다는 말은 사실이지만, 실제로 써보면 “Fabric 전용”이라는 벽이 먼저 보입니다. 도입 결정 전에 이 조건부터 확인하는 게 순서입니다.
Translytical이 뭔지 30초 요약
Power BI는 지금까지 읽기 전용 도구였습니다. 보고서를 보고 이상한 숫자를 발견해도, 수정은 다른 시스템에서 해야 했고, 그 결과가 반영되는 걸 다시 보려면 보고서로 돌아와야 했습니다. 이 불편함을 없애는 게 Translytical 워크플로우의 핵심입니다.
‘Translytical’은 Transactional(트랜잭션)과 Analytical(분석)을 합친 단어입니다. 보고서를 보면서 레코드를 직접 수정하거나, 승인 버튼을 누르거나, 외부 API를 호출하는 동작을 Power BI 보고서 안에서 바로 실행할 수 있도록 합니다. 2025년 5월 프리뷰로 처음 등장한 이 기능이 2026년 3월 15일 공식 GA(Generally Available)로 전환됐습니다.
(출처: Microsoft Power BI 공식 블로그, 2026.03.18)
💡 공식 발표문에서 “보고서를 떠나지 않고 작업을 수행할 수 있다”는 설명을 실제 작동 흐름과 함께 놓고 보면, ‘떠나지 않는다’의 의미가 의외로 좁다는 걸 바로 알 수 있습니다. 이건 뒤에서 구체적으로 풀겠습니다.
GA가 됐다는데 — 실제로 뭐가 달라졌나
GA 전환의 실질적 의미는 “이제 공식 SLA와 엔터프라이즈 지원을 받을 수 있다”는 겁니다. 프리뷰 상태였을 때는 기능이 언제 바뀌거나 없어질지 모른다는 불안이 있었는데, GA부터는 Microsoft가 공식적으로 유지·지원합니다.
3월 업데이트에서 Translytical과 함께 GA가 된 건 Direct Lake on OneLake도 있습니다. 두 기능 모두 Fabric 기반 구조 위에서 작동하고, 두 기능 모두 Fabric 용량(Capacity)이 없으면 쓸 수 없습니다. GA됐다는 뉴스만 보고 “이제 바로 쓸 수 있겠다”고 생각했다면, 라이선스 조건을 먼저 확인해야 합니다.
한편 같은 업데이트에서 프리뷰로 올라온 것들도 있습니다. Custom totals(사용자 지정 합계), Modern visual defaults(최신 시각 기본값), TMDL View on web, DAX 사용자 정의 함수 업데이트가 이번 달 미리보기로 들어왔습니다. GA와 Preview는 엄연히 다르고, 현재 이 네 가지는 Production 보고서에 쓰기에 이릅니다.
Fabric에 없으면 아예 쓸 수 없는 이유
이게 핵심 제약입니다. Translytical 워크플로우는 내부적으로 Fabric User Data Functions(UDF)를 통해 작동합니다. UDF는 Python 기반의 로직 블록인데, 이게 Fabric 환경에서만 생성·실행됩니다. 즉, 아무리 Power BI Pro 라이선스가 있어도 Fabric 용량이 없으면 UDF를 만들 수 없고, UDF가 없으면 Translytical 워크플로우를 만들 수 없습니다.
데이터 라이트백(write-back) 대상도 세 가지 Fabric 데이터 소스로 제한됩니다. 공식 문서에 딱 이렇게 나옵니다: Fabric SQL Database, Fabric Warehouse, Fabric Lakehouse(파일 전용). 온프레미스 SQL Server나 Azure SQL Database, 외부 PostgreSQL 등은 직접 쓰기 대상이 아닙니다.
(출처: Microsoft Learn — Translytical task flow overview, 2026.03)
💡 Fabric Community 포럼에서 “온프레미스 SQL 서버에도 라이트백 되어야 한다”는 요청이 2025년 5월부터 지금까지 활발합니다. Microsoft가 공식 답변을 내놓지 않은 부분입니다. 현재로서는 외부 시스템 연동은 API 호출 방식을 우회해야 합니다.
(출처: Microsoft Fabric Community, 2025.05)
단, 외부 REST API 호출은 가능합니다. Azure OpenAI, Teams, CRM 등 네트워크로 접근 가능한 API라면 UDF 안에서 호출할 수 있습니다. 이 경우엔 Fabric DB가 직접 쓰기 대상이 아니라도 됩니다. 하지만 여전히 UDF가 필요하고, UDF는 Fabric 용량이 있어야 만들 수 있습니다.
첫 번째 호출에서 20초가 걸리는 구조적 이유
실사용자들이 가장 당황하는 부분이 여기입니다. Translytical 워크플로우의 버튼을 처음 눌렀을 때 응답이 수십 초까지 걸리는 사례가 실제로 다수 보고되고 있습니다. Reddit Power BI 커뮤니티에서 한 사용자는 “Translytical로 항목을 생성하면 Fabric 테이블에 나타나는 데 20초 이상 걸리고, Direct Query로 Power BI에 반영되는 데 추가로 1분이 걸린다”고 밝혔습니다.
(출처: Reddit r/PowerBI, 2025년 하반기)
이게 버그가 아닌 구조적 이유가 있습니다. UDF는 Fabric 용량에서 실행되는데, 첫 호출 시 세션을 새로 시작해야 합니다. 이 세션 초기화 시간이 원인입니다. 세션이 살아 있는 동안에는 이후 호출이 빠르지만, 세션이 종료된 뒤 다시 첫 번째 버튼을 누르면 또 기다려야 합니다. 이 점은 “실시간 대화형 도구”라는 기대와 다를 수 있습니다.
💡 공식 블로그 발표문과 실제 커뮤니티 사용 흐름을 같이 놓고 보면 이런 차이가 보입니다. GA 발표 이후에도 세션 워밍업 시간 문제는 공식 로드맵에서 별도 언급이 없습니다.
또 한 가지 확인이 필요한 것은 PBIR(Power BI 고급 보고서) 미지원입니다. 공식 제한 사항에 “PBIR 및 PBIP 형식은 지원되지 않습니다”라고 명시돼 있습니다.
(출처: Microsoft Learn — Translytical task flow overview, 2026.03)
최근 Power BI 현대화 작업에서 PBIR 형식을 권장하는 흐름과 충돌합니다. 신규 보고서를 PBIR 형식으로 만들고 있다면 현재 Translytical을 쓸 수 없습니다.
개발 과정에서도 불편함이 있습니다. UDF를 수정하고 Power BI Desktop에 반영되기까지 5분 이상 기다려야 하는 경우가 실사용자 사이에서 보고됐습니다. UDF 편집기 자체가 사실상 Notebook 수준이고, 에러 메시지가 구체적이지 않아 디버깅이 어렵다는 평가도 있습니다.
(출처: Downhill Data 블로그, 2025.09)
Power Apps랑 뭐가 다른가 — 직접 비교
많은 팀에서 이미 Power BI 보고서에 Power Apps를 임베드하는 방식으로 라이트백을 구현해 왔습니다. Translytical이 GA된 지금, 어떤 걸 선택해야 하나요? 실측 비교를 정리해봤습니다.
| 항목 | Translytical TTF | Power Apps 임베드 |
|---|---|---|
| 입력 컴포넌트 | 목록·텍스트·버튼 3종 | 슬라이더·날짜선택기 등 다양 |
| 추가 라이선스 비용 | Fabric 용량만 있으면 됨 | Power Apps Premium 약 $20/월/인 |
| 대량 레코드 처리 | 네이티브 우수 | 1,000행 한도 (저장프로시저 우회 필요) |
| CI/CD 파이프라인 지원 | Fabric 배포 파이프라인 미지원 | Power Platform 파이프라인 지원 |
| 디버깅 편의성 | 에러 메시지 비구체적 | Power Apps Monitor 제공 |
| Power BI 네이티브 알림 | UDF 반환값으로 팝업 지원 | 앱 내부 알림만 가능 |
출처: Downhill Data 실사용 비교 분석 (2025.09), NimbleLearn 블로그 (2025.10)
요약하면 이렇습니다. Fabric 용량이 이미 있고, 단순한 승인·수정 작업 중심이라면 Translytical이 비용 측면에서 확실히 유리합니다. 반면 사용자 인터페이스가 복잡하거나 다양한 입력 컴포넌트가 필요한 경우엔 지금 시점에서는 Power Apps가 완성도가 높습니다.
한 가지 놓치기 쉬운 점이 있습니다. Power Apps 임베드 방식에서 PowerBIIntegration.Refresh() 함수는 Power BI 내부에서 “Create New” 버튼으로 만든 앱에서만 작동합니다. 외부에서 만든 앱을 임베드하면 이 함수가 없습니다. 이 점은 Power Apps를 쓰면서 잘 안 알려진 함정입니다.
(출처: Downhill Data, 2025.09)
이 조건에 해당하면 도입을 미뤄야 합니다
GA가 됐다고 해서 모든 환경에서 바로 쓸 수 있는 건 아닙니다. 아래 조건 중 하나라도 해당된다면 지금 당장 도입하기보다 시점을 조율하는 게 맞습니다.
Fabric 용량이 없는 경우. Power BI Pro나 Premium Per User(PPU)만으로는 UDF를 만들 수 없어서 Translytical 자체가 불가능합니다. F SKU 또는 P SKU의 Fabric 용량이 필요합니다.
PBIR(Power BI 고급 보고서) 형식으로 보고서를 운영 중인 경우. 공식 제한 사항에 명시된 대로 PBIR 및 PBIP 형식은 현재 지원되지 않습니다. 이유는 아직 공개되지 않았습니다.
CI/CD 배포 파이프라인이 핵심인 환경. Fabric 배포 파이프라인 지원이 아직 없어서, 개발→스테이징→프로덕션 환경 간 배포 시 데이터 함수 버튼 재연결 등 수동 작업이 필요합니다.
(출처: NimbleLearn, 2025.10)
Power BI Embedded를 사용 중인 경우. 보안 포함(Secure Embed) 시나리오만 지원됩니다. 퍼블릭 임베드나 비보안 시나리오에서는 동작하지 않습니다.
(출처: Microsoft Learn, 2026.03)
라이트백 대상 DB가 온프레미스 SQL Server인 경우. 네이티브 연결이 지원되지 않습니다. 외부 API를 통한 우회는 가능하지만 구조가 복잡해집니다.
💡 솔직히 말하면, GA 전환이 “모든 준비가 끝났다”는 의미는 아닙니다. CI/CD 미지원, PBIR 미지원, 첫 호출 지연 — 이 세 가지만 봐도 엔터프라이즈 수준의 즉시 도입은 아직 체크리스트가 남아 있습니다.
자주 묻는 질문
마치며 — GA됐다고 다 된 게 아닙니다
Power BI Translytical 워크플로우는 방향성만큼은 분명히 올바릅니다. “보고서를 보다가 바로 수정”이라는 흐름은 데이터 기반 의사결정 속도를 실제로 줄여줍니다. 특히 Fabric 환경을 이미 갖추고 있고, 단순한 승인·레코드 수정 작업이 중심이라면 Power Apps 대비 비용이 훨씬 낮습니다.
하지만 GA 발표 뒤에 가려진 조건들이 있습니다. Fabric 용량 필요, PBIR 미지원, CI/CD 미지원, 첫 호출 지연, 제한된 입력 UI. 이 다섯 가지 중 하나라도 현재 환경에 해당된다면 지금 당장 프로덕션에 올리기보다 1~2개 분기 더 지켜보는 전략도 합리적입니다.
GA는 “더 이상 바뀌지 않는다”가 아니라 “이제 공식 지원을 시작한다”는 의미입니다. 로드맵이 빠르게 채워지고 있는 건 사실이지만, 현재 상태의 제약을 알고 쓰는 것과 모르고 쓰는 것은 차이가 큽니다.
본 포스팅 참고 자료
- Microsoft Power BI March 2026 Feature Summary (공식 블로그, 2026.03.18)
- Microsoft Learn — Translytical 작업 흐름 이해 (공식 문서)
- Downhill Data — Translytical Task Flows vs Power Apps 비교 (2025.09)
- NimbleLearn — 6 Things You Should Know About Translytical Task Flows (2025.10)
- Microsoft Learn — Power BI 새로운 기능 2026년 3월 (공식 문서)
본 포스팅은 2026년 3월 22일 기준으로 작성됐습니다. 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. 정확한 현재 사양은 위 참고 자료의 공식 Microsoft 문서를 통해 직접 확인하시기 바랍니다.
댓글 남기기