Power BI Translytical, GA됐는데 즉시 반영 안 됩니다

Power BI Translytical 작업 흐름(Translytical Task Flow)이 2026년 3월 15일부로 정식 출시(GA)됐습니다. 드디어 Power BI 보고서 안에서 데이터를 직접 수정하고 저장할 수 있게 된 겁니다. 그런데 써보니까 “즉시 반영”이라는 기대와 실제 동작 사이에 꽤 큰 간격이 있었습니다. 공식 문서와 실사용 후기를 교차해서 정리했습니다.

Translytical이 뭔지부터 — 용어 풀이

Translytical은 ‘Transactional(트랜잭션)’과 ‘Analytical(분석)’을 합성한 단어입니다. 쉽게 말하면, 지금까지 Power BI는 데이터를 “보기만” 했는데, 이제 “보면서 바꾸기”까지 가능해진 겁니다. 보고서 화면을 떠나지 않고 레코드를 수정하거나, 승인 버튼을 누르거나, 외부 API를 호출할 수 있습니다.

기술적으로는 Microsoft Fabric의 사용자 데이터 함수(User Data Function, UDF)를 중간 다리로 씁니다. UDF는 Python 기반의 재사용 가능한 로직 블록인데, Power BI 보고서의 버튼이나 슬라이서와 연결되어 “버튼 눌림 → UDF 실행 → Fabric 데이터 변경 → 보고서 갱신” 흐름으로 동작합니다.

DAX의 사용자 정의 함수(User-Defined Function)와 이름이 비슷해서 헷갈리기 쉽지만, 공식 문서에서도 둘을 명확히 구분합니다. DAX UDF는 모델 내 계산 로직을 재사용하는 것이고, Fabric UDF는 외부 시스템에 실제로 데이터를 쓰고 읽는 역할입니다. (출처: nimblelearn.com, Translytical Task Flows 6가지 핵심 정리, 2025.10.31)

▲ 목차로 돌아가기

2026년 3월 GA, 달라진 게 뭔가요?

Translytical 작업 흐름은 2025년 5월 퍼블릭 프리뷰로 처음 등장했고, 2026년 3월 15일 Power BI Desktop v2.152.882.0 업데이트와 함께 공식적으로 GA(General Availability) 상태가 됐습니다. 프리뷰에서 GA로 전환된다는 건 기능 지원 약속이 생기고, 엔터프라이즈 환경에서 안심하고 쓸 수 있다는 의미입니다.

이번 GA와 함께 주목할 변화는 두 가지입니다. 첫째, 데이터 쓰기저장 대상으로 Fabric SQL Database, Fabric Warehouse, Fabric Lakehouse(파일) 세 가지가 공식 지원됩니다. 둘째, Azure OpenAI 등 외부 API 호출도 지원해서 보고서 안에서 AI 제안을 생성하는 것도 가능합니다. (출처: Microsoft Power BI March 2026 Feature Summary, powerbi.microsoft.com, 2026.03.15)

GA 전에 프리뷰 상태에서 이미 도입했다면 한 가지 확인이 필요합니다. PBIR(Power BI 고급 보고서) 및 PBIP(Power BI 프로젝트) 포맷은 현재 지원되지 않습니다. 공식 문서에 그대로 나와 있는 제한 사항입니다. (출처: Microsoft Learn, Translytical 작업 흐름 이해, learn.microsoft.com)

▲ 목차로 돌아가기

쓰기저장 가능한 대상, 딱 3가지입니다

공식 문서 기준으로, Translytical 작업 흐름에서 데이터 쓰기저장이 가능한 Fabric 데이터 원본은 현재 Fabric SQL Database, Fabric Warehouse, Fabric Lakehouse(파일 한정) 세 가지뿐입니다. 이 세 가지 외의 외부 데이터 원본(예: Azure SQL DB, SQL Server 온프레미스)은 UDF에서 REST API 호출로 간접 연결은 가능하지만, 네이티브 쓰기저장 연결 관리는 지원되지 않습니다.

세 가지 중에서 공식적으로 가장 권장하는 건 Fabric SQL Database입니다. 이유는 OLTP(온라인 트랜잭션 처리) 방식에 최적화되어 있어서, 보고서처럼 읽기·쓰기가 빈번하게 발생하는 환경에서 성능이 가장 안정적이기 때문입니다. 이 차이가 실제 응답 속도에 직결됩니다. (출처: Microsoft Learn, Translytical 작업 흐름 이해, learn.microsoft.com)

Fabric Warehouse에 쓰기저장을 시도할 때 삼중 파트 명명 규칙(Three-part naming convention)을 지키지 않으면 UDF가 오류 없이 실행됐다는 메시지를 띄우면서도 실제로는 저장에 실패하는 상황이 생깁니다. Fabric SQL Database와 달리 이 규칙이 필수라는 점이 공식 문서에 명시되지 않아 실제 현장에서 혼란을 일으킨 사례가 여럿 있었습니다. (출처: downhill-data.com, Comparing write-back options, 2025.09.09)

▲ 목차로 돌아가기

“즉시 반영” 기대했다면 이 부분 먼저 보세요

마케팅 자료나 소개 영상에선 “보고서에서 버튼 누르면 데이터가 즉시 반영된다”는 인상을 줍니다. 기대했던 것과 달랐습니다. 실제로는 데이터 반영 속도가 어떤 시맨틱 모델 모드를 쓰느냐에 따라 크게 달라집니다.

Fabric SQL Database를 쓸 경우, 실사용자 기준으로 약 1초 내외에 반영이 됩니다. 반면 Direct Lake on OneLake 모드를 사용하는 환경에서는 30~45초, 심한 경우 수 분이 걸리거나 수동으로 “시각 개체 새로 고침” 버튼을 눌러야 갱신됩니다. UDF가 시맨틱 모델 새로 고침을 직접 강제할 수 없는 구조적 한계 때문입니다. (출처: Reddit r/PowerBI, “Translytical Task Flows – Are they the answer?”, 실사용자 RickSaysMeh 코멘트, 2025.11.03)

▲ 목차로 돌아가기

Power Apps와 비교하면 실제로 어떤가요?

“Translytical이 GA됐으니 이제 Power Apps 쓰기저장 안 써도 되겠다”는 반응이 많습니다. 막상 비교해보면 다릅니다. 개발자 비교 분석(downhill-data.com, 2025.09)에서 UI/UX, 개발 편의성, 성능, 아키텍처·비용 네 가지 항목을 1점씩 배점해 평가한 결과, 최종 스코어는 Power Apps 3점 vs Translytical Task Flows 3점으로 동점이었습니다. “무조건 Translytical이 낫다”고 말하기 어렵습니다.

항목별로 보면, Translytical이 앞서는 건 아키텍처 단순성과 비용입니다. Power Apps는 별도의 Power Platform 라이선스(현재 사용자당 월 $20 이상)가 필요하고 두 플랫폼을 병행 관리해야 하지만, Translytical은 Fabric 용량 하나로 끝납니다. (출처: downhill-data.com, Comparing write-back options, 2025.09.09)

반면 Translytical이 뒤처지는 건 사용자 입력 옵션입니다. 현재 목록 슬라이서, 텍스트 슬라이서, 버튼 세 가지만 제공되고, 날짜 선택기나 슬라이더는 지원하지 않습니다. 텍스트 슬라이서는 기본값 설정도 불가능해서, 기존 레코드를 수정하는 편집 폼을 만들기가 까다롭습니다. Power Apps는 이런 UI 컴포넌트를 폭넓게 지원합니다. (출처: downhill-data.com, 2025.09.09)

▲ 목차로 돌아가기

비용 구조 — Fabric 없으면 못 씁니다

Translytical 작업 흐름을 쓰려면 Microsoft Fabric 용량(Capacity)이 전제 조건입니다. 현재 가장 저렴한 Fabric 용량은 F2 SKU로, 가격은 월 약 $156입니다. (출처: azure.microsoft.com/en-us/pricing/details/microsoft-fabric/, Reddit u/SQLGene 확인, 2025.11.03) 이미 Fabric Premium이나 Fabric 용량을 사용 중이라면 Translytical에 별도 비용이 추가되지 않습니다. 저장 비용도 OneLake 스토리지 기준으로 소규모 레코드라면 사실상 무시할 수 있는 수준입니다.

반면 Power BI Premium Per User(PPU)나 일반 Pro 라이선스만 있는 환경에서는 Translytical을 사용할 수 없습니다. Fabric 용량이 없으면 UDF 자체가 동작하지 않기 때문입니다. 이 점을 가과하면 기능 자체는 보고서에서 설정했는데 실제 배포 환경에서 아무것도 작동하지 않는 상황이 생깁니다.

Power BI Embedded 환경의 경우, 보안 포함(Secure Embed) 시나리오에서만 지원됩니다. 공개 포함이나 익명 포함은 현재 지원하지 않습니다. (출처: Microsoft Learn, Translytical 작업 흐름 이해, 제한점 섹션, learn.microsoft.com)

▲ 목차로 돌아가기

실제로 쓸 수 있는 시나리오 vs 한계 시나리오

공식 소개 자료에서 제시하는 대표 시나리오는 크게 세 가지입니다. 영업팀이 보고서 안에서 할인 값을 직접 수정하는 경우, 판매 기회 승인 요청을 Microsoft Teams에 자동 게시하는 경우, Azure OpenAI를 호출해 선택한 항목에 대한 AI 분석 제안을 바로 받는 경우입니다. 모두 “빠른 인컨텍스트 액션”에 해당합니다. (출처: Microsoft Learn, Translytical 작업 흐름 이해, learn.microsoft.com)

반면 Translytical이 불리한 시나리오도 분명합니다. 여러 단계로 구성된 승인 프로세스, 부서 간 협업이 포함된 복잡한 워크플로, 오프라인 데이터 입력이 필요한 상황입니다. 이런 경우에는 전용 비즈니스 애플리케이션이 여전히 더 적합합니다. Translytical은 “대시보드보다는 기능적이지만, 전용 앱보다는 단순한” 중간 레이어로 설계된 것이 맞습니다. (출처: nimblelearn.com, 6 Things You Should Know About Translytical Task Flows, 2025.10.31)

솔직히 말하면, 현재 상태의 Translytical은 간단한 레코드 추가·수정·삭제나 단순 외부 API 호출에는 충분히 쓸 만합니다. 다만 복잡한 UI 흐름이 필요하거나, 여러 입력 단계를 거쳐야 하는 시나리오라면 아직 Power Apps 쪽이 더 완성도 있는 선택입니다. GA됐다고 해서 모든 쓰기저장 시나리오를 대체할 수 있는 건 아닙니다.

▲ 목차로 돌아가기

자주 묻는 질문 Q&A

▲ 목차로 돌아가기

마치며 — 총평

Power BI Translytical 작업 흐름은 Power BI가 오랫동안 갖고 있던 “읽기 전용” 한계를 뛰어넘는 의미 있는 진전입니다. 2026년 3월 15일 GA로 전환되면서 비로소 엔터프라이즈 환경에서 안정적으로 사용할 수 있는 기능이 됐습니다.

다만 막상 써보면 챙겨야 할 게 여럿 있습니다. 즉각 반영을 원한다면 Fabric SQL Database를 기본 데이터 원본으로 쓰고, Warehouse 쓴다면 삼중 파트 명명 규칙을 반드시 확인해야 합니다. 성공 팝업이 뜬다고 무조건 저장됐다고 믿지 말고, UDF 안에 에러 핸들링을 넣는 것도 기본입니다.

Power Apps를 완전히 대체하기보다는 “비용 효율적인 단순 쓰기저장 레이어”로 포지셔닝하는 게 현재로선 현실에 맞습니다. 입력 UI가 더 다양해지고, Fabric 배포 파이프라인 지원이 추가된다면 그 판단은 달라질 것 같습니다.

📎 본 포스팅 참고 자료

1. Microsoft Power BI March 2026 Feature Summary — powerbi.microsoft.com
2. Translytical 작업 흐름 이해 — Microsoft Learn — learn.microsoft.com
3. 6 Things You Should Know About Translytical Task Flows — NimbleLearn — nimblelearn.com
4. Comparing write-back options for Power BI/Fabric — Downhill Data — downhill-data.com
5. r/PowerBI — Translytical Task Flows real-world experience — reddit.com/r/PowerBI