Power BI Translytical, 3가지 조건 안 맞으면 작동 안 됩니다

2026년 3월 18일, Power BI Translytical 작업 흐름(Translytical Task Flows)이 정식 기능(Generally Available)으로 전환됐습니다. 리포트 안에서 데이터를 직접 수정하고 Teams 승인 요청까지 보낼 수 있다는 공식 발표에 관심이 쏠렸는데, 막상 세팅하면 PBIR 형식 미지원, Fabric 라이선스 필수, 텍스트 슬라이서 99자 제한 등 막히는 지점이 꽤 있습니다. 공식 문서와 실사용 비교 자료를 교차해서 정리했습니다.

Translytical 작업 흐름이란 — 결론부터

Power BI Translytical 작업 흐름은 대시보드 화면을 벗어나지 않고 데이터를 직접 수정하거나 외부 시스템에 작업을 보낼 수 있는 기능입니다. 영문으로는 “Transactional + Analytical”을 합친 개념이고, 예를 들면 판매 보고서에서 특정 거래의 할인율을 바로 바꾸거나, 버튼 하나로 Teams에 승인 요청을 보내는 흐름이 가능합니다. 기존에도 Power Apps 임베드 방식으로 유사한 기능을 만들 수 있었지만, 별도 Power Platform 라이선스가 필요하고 구조가 복잡했습니다.

2026년 3월 18일 공식 블로그에서 Microsoft는 Translytical 작업 흐름이 Generally Available(GA), 즉 정식 기능으로 전환됐다고 발표했습니다. (출처: Power BI March 2026 Feature Summary, powerbi.microsoft.com, 2026.03.18) 프리뷰가 끝났다는 건 프로덕션 환경에서도 써도 된다는 신호입니다. 다만 GA라고 해서 모든 환경에서 바로 쓸 수 있는 건 아닙니다.

기술적으로는 Fabric 사용자 데이터 함수(User Data Functions)와 Power BI 보고서 사이를 연결하는 방식으로 작동합니다. 보고서의 슬라이서와 버튼이 입력값을 받아서 데이터 함수에 전달하고, 함수가 Fabric SQL 데이터베이스나 웨어하우스에 쓰기 작업을 수행하거나 외부 API를 호출합니다.

▲ 목차로 돌아가기

작동하려면 반드시 갖춰야 할 3가지

공식 Microsoft Learn 문서와 Fabric 커뮤니티 자료를 합쳐보면, 이 기능이 제대로 돌아가려면 아래 세 가지를 빠짐없이 충족해야 합니다.

▲ 목차로 돌아가기

PBIR 형식이 기본값인데 Translytical은 안 됩니다

Microsoft는 지금 Power BI Desktop의 기본 저장 형식을 기존 PBIX에서 PBIR로 전환하는 작업을 진행 중입니다. PBIR은 Git 연동과 CI/CD 워크플로에 훨씬 유리한 구조라서, 실제로 Fabric 환경에서 새 보고서를 만들면 PBIR 형식으로 저장하도록 점점 유도되고 있습니다.

실무에서 이 문제가 특히 까다로운 이유가 있습니다. Fabric 포털에서 새로 만든 보고서, Git 연동된 보고서, 혹은 Power BI Desktop에서 “향상된 보고서 형식으로 저장”을 선택했다면 이미 PBIR입니다. 이 보고서에 Translytical 버튼을 붙이려고 하면 세팅 화면 자체가 나타나지 않습니다. 반드시 PBIX 형식으로 다시 저장해야 합니다.

▲ 목차로 돌아가기

Power Apps과 비교했을 때 실제로 다른 점

Translytical 작업 흐름이 GA가 되면서 “이제 Power Apps 없이도 된다”는 반응이 많은데, 실제 비교 결과는 좀 다릅니다. 쓰기 저장 옵션 비교 분석(downhill-data.com, 2025.09.09)에서 둘을 직접 테스트한 결과를 보면, 최종 점수가 Power Apps 3점 대 Translytical 3점으로 타이입니다.

비용 차이가 꽤 큽니다. Power Apps Premium 라이선스는 사용자당 월 $20(약 2만 7,000원)이고, 쓰기 저장만을 위해 팀 전체에 부여하기엔 부담스럽습니다. (출처: downhill-data.com 비교 분석) 반면 Translytical은 Fabric 용량 안에서 추가 라이선스 없이 사용합니다. Fabric을 이미 쓰고 있다면 Translytical이 훨씬 경제적입니다.

첫 번째 호출 때 세션 시작 대기 시간이 수 초에서 길면 몇 분까지 걸릴 수 있다는 점도 실사용에서 자주 거론됩니다. 세션이 한번 열리면 이후 작업은 빠르지만, 사용 빈도가 낮은 보고서에 붙여두면 첫 클릭마다 기다림이 생깁니다. 운영 대시보드처럼 상시 접속이 많은 환경에서 써야 체감 속도가 좋습니다.

▲ 목차로 돌아가기

공식 발표문과 실제 세팅 흐름을 같이 놓고 보니

공식 블로그에서 소개된 대표 시나리오는 판매 보고서에서 할인율을 입력하고 “요청 제출” 버튼을 누르면 Teams에 메시지가 날아가는 흐름입니다. 제법 멋있어 보이는데, 실제로 이걸 구현하려면 Fabric SQL 데이터베이스 생성 → 사용자 데이터 함수 작성(Python 또는 PySpark) → Power BI 보고서와 연결의 순서가 필요합니다. 단계마다 Fabric 포털과 Power BI Desktop을 오가야 합니다.

또 하나 주목할 점은 데이터 함수 디버깅 경험입니다. Power BI Desktop에서 버튼을 누를 때마다 모델 메타데이터 새로고침이 강제 실행됩니다. DirectQuery 모델이어도 마찬가지입니다. 함수 쪽 오류가 생기면 Power BI에서는 “성공”이라고 뜨는데 실제로는 실패한 경우도 있어서, 함수 단독 테스트를 먼저 충분히 해두는 게 좋습니다.

반면 Azure OpenAI API 호출은 생각보다 잘 됩니다. 사용자 데이터 함수 안에서 외부 REST API를 부르는 방식이라, 예를 들어 테이블에서 특정 요인을 선택하고 “AI 제안 생성” 버튼을 누르면 Azure OpenAI 응답이 보고서 안에 바로 표시됩니다. 이 흐름은 공식 문서의 예제 코드(github.com/Sujata994)에서 직접 확인할 수 있습니다. (출처: powerbi.microsoft.com/blog, 2026.03.18)

▲ 목차로 돌아가기

실무 적용 전 체크리스트

GA 전환 발표를 보고 바로 적용을 검토하고 있다면, 아래 항목을 순서대로 확인해두는 것이 좋습니다. 하나라도 빠지면 세팅 화면이 아예 안 뜨거나, 버튼 클릭 후 조용히 실패하는 상황이 생깁니다.

▲ 목차로 돌아가기

Q&A

▲ 목차로 돌아가기

마치며 — 총평

Power BI Translytical 작업 흐름은 대시보드가 “보는 도구”에서 “행동하는 도구”로 바뀌는 변화의 시작점입니다. GA로 전환된 건 분명히 의미 있는 진전이고, 특히 Fabric 환경에서 Power Platform 라이선스 없이 쓰기 저장을 구현할 수 있다는 점은 비용 면에서 매력적입니다.

다만 PBIR 형식 미지원, 텍스트 슬라이서 99자 제한, 첫 세션 시작 지연처럼 현재 버전에서 막히는 지점들이 실무에서는 꽤 크게 체감됩니다. 솔직히 말하면, 발표 자료만 보고 바로 프로덕션에 올리기엔 아직 테스트가 더 필요한 기능입니다. Fabric을 이미 쓰고 있고 Power Apps 라이선스 비용이 부담스러운 팀이라면, 간단한 쓰기 저장 시나리오부터 파일럿으로 시도해보는 것이 현실적인 접근입니다.

앞으로 PBIR 지원 추가와 입력 옵션 다양화가 이뤄지면 Power Apps를 대체할 수 있는 진짜 경쟁 기능이 될 것 같습니다. 그 시점이 언제일지는 Microsoft 로드맵을 계속 확인하는 수밖에 없습니다.

▲ 목차로 돌아가기

본 포스팅 참고 자료

1. Power BI March 2026 Feature Summary — Microsoft Power BI 공식 블로그 (2026.03.18)
2. Translytical 작업 흐름 개요 — Microsoft Learn 공식 문서
3. Translytical 작업 흐름 만들기 자습서 — Microsoft Learn
4. Translytical Task Flows vs Power Apps 비교 — Downhill Data (2025.09.09)
5. Power BI March 2026 Update 분석 — MG Analytics Consultants (2026.03.19)