Power BI Desktop v2.152.882.0
IT/AI
Power BI Translytical, GA됐다고 바로 못 씁니다
2026년 3월, Power BI의 Translytical 워크플로우가 드디어 정식 출시(GA)됐습니다. 보고서 화면을 벗어나지 않고 데이터를 직접 수정하고 외부 시스템에 명령을 보내는 기능입니다. 근데 막상 쓰려고 했더니 생각보다 조건이 복잡했습니다. GA가 됐다는 게 “누구나 바로 쓸 수 있다”는 뜻이 아니거든요. 라이선스, 포맷 제한, 실제 UX 수준까지 — 공식 문서 기준으로 직접 따져봤습니다.
Translytical 워크플로우가 정확히 뭔가요?
Power BI Translytical 워크플로우는 Power BI 보고서 화면을 벗어나지 않고 데이터를 직접 추가·수정·삭제하거나 외부 시스템의 작업을 실행할 수 있게 해주는 기능입니다. 기존엔 보고서에서 이상한 숫자를 발견하면 다른 툴을 열고, 데이터베이스에 접속하고, 수정하고, 다시 Power BI로 돌아와 새로고침을 눌러야 했습니다. 그 흐름을 보고서 안에서 끊지 않도록 만든 게 이 기능입니다.
공식 명칭인 “Translytical”은 Transactional(거래·쓰기)과 Analytical(분석·읽기)을 합친 조어입니다. Fabric 사용자 데이터 함수(User Data Function)를 통해 보고서와 백엔드 데이터 원본을 연결하는 방식으로 작동합니다. 실제 사용 시나리오로는 영업 기회에 대한 할인 요청을 보고서에서 바로 승인하고 Teams에 메시지를 보내는 흐름, 고객 레코드 주석 달기, 오래된 항목 삭제 등이 공식 문서에 나와 있습니다.
(출처: Microsoft Learn, Translytical 작업 흐름 이해, 2026.03)
데이터를 쓸 수 있는 백엔드는 세 가지입니다.
- Fabric SQL 데이터베이스 — 읽기/쓰기가 빈번한 보고 시나리오에 공식 권장
- Fabric 웨어하우스
- Fabric 레이크하우스 (파일 형식 한정)
외부 API(예: Azure OpenAI Responses API) 호출도 지원합니다. 보고서에서 버튼 하나로 AI가 권고안을 생성하게 만들 수도 있습니다.
GA가 됐는데 왜 바로 못 쓸까요 — 라이선스 구조 먼저
💡 공식 발표문과 실제 사용 환경을 같이 놓고 보니 이런 차이가 보였습니다
Translytical이 GA가 됐다는 건 “Preview 딱지가 떨어졌다”는 얘기입니다. 쓸 수 있는 사람의 범위가 넓어진 게 아니라, 이제 공식적으로 프로덕션에서 써도 된다는 선언입니다. 그 조건은 이미 정해져 있었습니다.
Translytical 워크플로우는 Fabric 사용자 데이터 함수를 기반으로 합니다. 이 함수를 사용하려면 조직에 Fabric F 용량(F SKU) 또는 Power BI Premium P 용량(P SKU)이 반드시 있어야 합니다. 사용자별 라이선스인 PPU(Power BI Premium Per User)만으로는 Fabric 워크로드를 실행할 수 없습니다.
(출처: Microsoft Learn, Microsoft Fabric 라이선스 이해, 2026.03)
| 라이선스 유형 | Translytical 사용 가능 | 비고 |
|---|---|---|
| Power BI Pro | ❌ | Fabric 워크로드 없음 |
| PPU (사용자 단위 Premium) | ❌ | F 용량 아님, Fabric 항목 생성 불가 |
| Fabric F2~F32 | ✅ | 콘텐츠 뷰어는 별도 Pro 라이선스 필요 |
| Fabric F64 이상 | ✅ | 무료 라이선스 사용자도 뷰어 가능 |
| Power BI Premium P1 이상 | ✅ | Fabric 활성화 시 사용 가능 |
PPU 라이선스 사용자가 많은 조직은 특히 주의해야 합니다. PPU는 대부분의 Power BI Premium 기능을 제공하지만, Fabric 레이크하우스·웨어하우스·사용자 데이터 함수처럼 Fabric 고유의 워크로드는 실행할 수 없습니다. F 용량이 없는 상태에서 Translytical을 쓰려면 별도로 Fabric 용량을 구입해야 합니다.
공식 문서가 밝힌 제한사항 3가지
Microsoft Learn의 Translytical 개요 문서에는 현재 기능에 적용되는 제한사항이 명시돼 있습니다. (출처: Microsoft Learn, 임시 작업 흐름 이해 — 제한점, 2026.03) 이 세 가지는 실제 도입 전에 반드시 확인해야 할 항목입니다.
반환 형식이 str로 고정
사용자 데이터 함수는 보고서에 추가할 응답 형식을 str 타입으로만 반환해야 합니다. 복잡한 JSON 구조나 테이블 형식 데이터를 직접 시각화하는 건 현재 불가능합니다.
PBIR·PBIP 포맷 미지원
Power BI Enhanced Report (PBIR) 및 Power BI Project (PBIP) 파일 형식에서는 Translytical이 작동하지 않습니다. Git 통합이나 버전 관리를 위해 PBIP 포맷으로 보고서를 관리하는 팀은 사용하기 어렵습니다.
Embedded는 보안 포함 시나리오만
Power BI Embedded를 활용하는 ISV나 외부 앱 개발사의 경우, “보안 포함(secure embed)” 시나리오에 한해서만 지원됩니다. 앱 소유 데이터(app-owned data) 방식의 임베딩에서는 사용할 수 없습니다.
이 세 가지 조건은 기능이 예쁘고 편리해 보여도 실제 도입 환경에 따라 처음부터 막히는 지점이 될 수 있습니다. PBIP 방식으로 보고서를 관리하는 팀이라면 지금 당장 GA됐다는 소식이 큰 의미가 없습니다.
실제 쓰는 사람들이 맞닥뜨리는 문제
💡 공식 발표엔 없는데 실제 사용 흐름에서 나온 얘기입니다
TTF(Translytical Task Flow)를 직접 테스트한 개발자들의 사용 후기를 모아보면, GA 이후에도 여전히 불편한 지점 두 가지가 반복됩니다.
첫 실행 때 시간이 걸립니다
사용자 데이터 함수는 Fabric 세션을 시작한 뒤 실행됩니다. 보고서를 열고 처음 버튼을 누르면 세션이 시작되는 시간이 필요합니다. 실사용 후기에서는 수 초에서 길면 수십 초까지 걸렸다고 언급합니다. (출처: Downhill Data 블로그, Comparing write-back options for Power BI/Fabric, 2025.09) 한 번 세션이 살아나면 이후 작업은 빠르지만, “버튼을 눌렀는데 아무것도 안 되는 것처럼 보이는 첫 순간”은 최종 사용자 입장에서 혼란스럽습니다.
“성공” 메시지가 실제 성공을 보장하지 않습니다
Power BI가 화면에 “성공” 알림을 띄우는 조건은 사용자 데이터 함수가 정상적으로 호출됐는지입니다. 함수 내부에서 DB 쓰기가 실패했거나 API 오류가 났어도 “성공”으로 표시될 수 있습니다. 즉, 보고서 화면의 성공 메시지만 보고 데이터가 업데이트됐다고 판단하면 오인할 가능성이 있습니다. 공식 문서가 별도 이유를 밝히지 않은 부분이지만, 이 동작은 UDF 안에서 에러를 정확하게 반환값으로 구성했을 때만 제대로 된 실패 메시지를 사용자에게 전달할 수 있습니다.
입력 슬라이서가 세 종류뿐입니다
현재 Translytical 워크플로우에서 사용자 입력을 받는 슬라이서 타입은 List, Text, Button 세 가지입니다. 날짜 선택기나 슬라이더 같은 UI는 아직 없습니다. Text 슬라이서는 기본값을 설정할 수도 없어서 기존 레코드를 수정하는 시나리오에서 사용자 경험이 떨어집니다.
Translytical vs Power Apps — 어떤 경우에 어느 쪽이 나을까
💡 전문 개발자들이 직접 비교해 본 결과를 항목별로 정리했습니다
Power BI 쓰기 저장 솔루션을 비교한 실사용 후기(Downhill Data, 2025.09)를 보면 5개 항목별 점수가 Power Apps 3 : TTF 2로 나왔습니다. 단, 비용 구조에서만 TTF가 압도적으로 유리합니다.
| 비교 항목 | Translytical TTF | Power Apps 임베딩 |
|---|---|---|
| 최종 사용자 UX | △ 입력 3종 한정 | ✅ 다양한 입력 지원 |
| 개발 편의성 | △ 동기화 지연 있음 | ✅ 모니터 툴 제공 |
| 대량 레코드 처리 | ✅ 네이티브 우세 | △ SP 필요 |
| 아키텍처 단순성 | ✅ Fabric 단일 플랫폼 | ❌ 복수 플랫폼 관리 |
| 추가 비용 | ✅ 용량 내 포함 | ❌ 약 $20/월/사용자 |
Power Apps Premium 라이선스 비용은 사용자당 월 약 $20 수준입니다. (출처: Downhill Data, Solution Architecture & Cost, 2025.09) 팀원 30명이 쓰면 연간 $7,200이 Power Apps 라이선스에만 들어갑니다. 이미 Fabric 용량이 있다면 TTF는 추가 비용이 없습니다. 단, 지금 단계에서는 UI가 단순한 단순 데이터 수정 작업에 TTF가 맞고, 복잡한 다단계 입력 흐름이 필요하면 Power Apps가 낫습니다.
3월 업데이트에서 같이 GA된 Direct Lake on OneLake
Translytical 워크플로우와 함께 이번 3월 업데이트에서 정식 출시된 기능이 하나 더 있습니다. OneLake의 Direct Lake입니다. 기존 Direct Lake on SQL에 더해 이제 OneLake 파일에 직접 연결하는 시멘틱 모델을 Power BI Desktop에서 만들 수 있게 됐습니다. (출처: Microsoft Power BI March 2026 Feature Summary, powerbi.microsoft.com, 2026.03.15)
두 방식의 차이는 명확합니다. Direct Lake on OneLake는 OneLake 보안 호환성, 더 많은 모델링 기능, 빠른 쿼리 성능이 필요할 때 씁니다. Direct Lake on SQL은 SQL 분석 엔드포인트의 보안 규칙을 위임 ID(delegated identity) 방식으로 적용해야 하거나 DirectQuery 폴백이 필요할 때 씁니다. 어느 쪽을 쓸지 결정하기 전에 조직의 보안 모델이 어떻게 설계돼 있는지를 먼저 확인해야 합니다.
참고로 Power BI Desktop에서 Direct Lake 시멘틱 모델을 새로 만들 때 SQL 분석 엔드포인트 페이지에서 두 옵션 중 하나를 직접 선택하게 돼 있습니다. 기본 선택은 워크스페이스 설정에 따라 달라질 수 있으니 처음 설정할 때 확인이 필요합니다.
자주 묻는 질문
마치며 — GA는 시작 조건이지 완성이 아닙니다
Power BI Translytical 워크플로우는 분명히 흥미로운 기능입니다. 보고서 밖으로 나가지 않고 데이터를 바꾸고 Teams에 메시지를 보낸다는 개념 자체는 실무 흐름을 크게 단순화할 수 있습니다. 써본 개발자들의 평가도 “아이디어는 좋다”는 쪽으로 수렴됩니다.
다만 GA됐다는 발표를 보고 바로 도입 계획을 세우기 전에, Fabric 용량 유무부터 확인해야 합니다. 라이선스 구조가 생각보다 엄격하고, PBIP 포맷 미지원과 입력 UI 제한은 실무에서 꽤 크게 걸릴 수 있습니다. 지금 당장 완벽한 솔루션이라기보다는 Microsoft가 방향을 잡은 기능이고, 이후 입력 타입 확대와 포맷 지원 확장이 이뤄지면 상황이 달라질 겁니다.
솔직히 지금은 “Fabric 이미 쓰고 있고, 단순한 쓰기 시나리오가 있다”는 조건을 갖춘 팀에만 실용적인 단계입니다. 그 조건이 아니라면 조금 더 기다려보는 게 합리적입니다.
본 포스팅 참고 자료
본 포스팅은 2026년 3월 31일 기준으로 작성됐습니다. Power BI Desktop v2.152.882.0 (2026.03.15 배포) 및 Microsoft Learn 공식 문서를 참고했습니다. 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. 라이선스 구조 및 기능 지원 여부는 최신 공식 문서에서 반드시 재확인하시기 바랍니다.
댓글 남기기