Power BI Desktop v2.152.882.0 기준
Power BI Translytical 작업 흐름,
보고서에서 직접 데이터를 바꿀 수 있는 게 맞나요?
결론부터 말씀드리면, 맞습니다. 그런데 조건이 있습니다. 2026년 3월 15일, Power BI Translytical 작업 흐름이 정식 출시(GA)됐습니다. 이제 보고서를 벗어나지 않고도 데이터를 수정하고 외부 시스템에 액션을 보낼 수 있습니다. 그런데 써보면 기대와 다른 부분이 몇 군데 있습니다. 공식 문서와 실사용 비교 자료를 교차해서 뜯어봤습니다.
Translytical 작업 흐름이 뭔지 먼저 짚고 넘어갑니다
Power BI Translytical 작업 흐름은 말 그대로 “Transactional + Analytical”을 합친 기능입니다. 지금까지 Power BI는 데이터를 보는 도구였습니다. 대시보드에서 문제를 발견해도, 수정은 다른 시스템에서 해야 했습니다. 스프레드시트를 열거나, ERP에 로그인하거나, 팀즈에 메시지를 남기거나. 이 흐름이 끊기는 게 오랜 문제였습니다.
Translytical 작업 흐름은 이 흐름을 한 화면 안에서 끝냅니다. 보고서 안에 버튼 하나를 달면, 그 버튼을 누를 때 데이터베이스 레코드가 수정되고, Teams에 메시지가 날아가고, Azure OpenAI API가 호출됩니다. 데이터를 보는 사람이 행동까지 하는 구조입니다. (출처: Microsoft Power BI 공식 블로그, 2026.03.15)
💡 공식 발표문과 실제 사용 흐름을 나란히 놓고 보니 이런 차이가 보였습니다 — GA 출시 직전까지 이 기능은 Fabric 사용자 데이터 함수(UDF)라는 Python 코드 블록을 보고서에 연결하는 방식인데, 정작 보고서 제작자 입장에서는 Python 코드를 직접 짜야 한다는 걸 공식 소개 페이지에서 잘 강조하지 않습니다.
작동 방식은 이렇습니다. ① 보고서 제작자가 Fabric에서 Python 기반 사용자 데이터 함수(UDF)를 작성합니다 → ② Power BI Desktop에서 버튼 시각적 요소에 해당 UDF를 연결합니다 → ③ 보고서 사용자가 버튼을 누르면 필터 컨텍스트와 입력값이 UDF로 전달되어 데이터가 처리됩니다. 겉으로는 버튼 하나지만 안에는 코드가 돌아갑니다.
보고서가 왜 오랫동안 ‘읽기 전용’일 수밖에 없었나
Power BI가 수년간 읽기 전용이었던 건 구조적 이유가 있습니다. 분석(Analytics) 시스템은 쿼리 성능을 위해 데이터를 열 기반으로 최적화합니다. 반면 데이터를 수정하는 트랜잭션(Transactional) 시스템은 행 단위로 빠르게 쓰고 읽어야 합니다. 두 가지는 애초에 설계 목적이 다른 엔진입니다. 하나의 보고서 안에서 둘을 동시에 돌리는 게 기술적으로 복잡했습니다.
기존에 쓰던 우회책은 크게 두 가지였습니다. 첫째, Power BI 보고서 안에 Power Apps를 임베드해서 데이터 입력을 처리하는 방법. 둘째, 서드파티 시각적 요소(Write-Back 전용 마켓플레이스 앱)를 구매하는 방법. 둘 다 별도 라이선스가 필요하거나 추가 비용이 발생했습니다. Power Apps Premium 라이선스는 사용자당 월 $20입니다. (출처: Microsoft Power Apps 공식 가격 페이지)
💡 “쓰기 저장은 Power BI가 원래 안 되는 기능”이라고 알려져 있는데, 사실 Microsoft는 2023년 5월부터 Fabric과 함께 Direct Lake 스토리지 모드를 출시하면서 이미 그 방향을 준비하고 있었습니다. Translytical 작업 흐름은 그 연장선에 있습니다. 갑자기 나온 기능이 아니라 3년의 설계 방향이 집약된 결과입니다. (출처: Microsoft Power BI 블로그, 2023.05)
데이터 원본이 Fabric 3종뿐이라는 게 핵심 조건입니다
여기서 많은 분들이 놓치는 부분이 있습니다. Translytical 작업 흐름의 데이터 쓰기 저장(writeback)이 지원하는 데이터 원본은 지금 이 세 가지뿐입니다.
| 데이터 원본 | 추천 시나리오 | 쓰기 성능 |
|---|---|---|
| Fabric SQL 데이터베이스 | 대부분의 쓰기 저장 시나리오 | 최우선 권장 |
| Fabric 웨어하우스 | 대량 데이터 배치 처리 | 조건부 권장 |
| Fabric 레이크하우스 | 파일 기반 데이터 처리 | 파일 전용 |
공식 문서에도 명시돼 있습니다 — “대부분의 쓰기 저장 시나리오에서는 SQL 데이터베이스를 기본 데이터 원본으로 사용하는 것이 좋습니다. SQL 데이터베이스는 보고 시나리오에 필요한 많은 읽기/쓰기 작업으로 잘 작동합니다.” (출처: Microsoft Learn, Translytical 작업 흐름 이해, 2026.03)
⚠ 주의: 기존 Azure SQL Database, SQL Server, Snowflake, BigQuery 등 외부 데이터베이스는 writeback 대상에서 제외됩니다. 외부 시스템 연동은 REST API 호출 방식으로만 가능하며, 이 경우 별도 API 엔드포인트 구성이 필요합니다. Fabric을 쓰지 않는 조직은 이 기능을 바로 활용하기 어렵습니다.
또한 지원되지 않는 형식도 공식 문서에 명시됩니다. PBIR(Power BI 고급 보고서)과 PBIP(Power BI 프로젝트) 형식은 현재 지원되지 않으며, Power BI Embedded는 보안 포함 시나리오에서만 작동합니다. (출처: Microsoft Learn, Translytical 작업 흐름 제한사항)
Power Apps랑 비교했더니 스코어가 이렇게 나왔습니다
Power BI 커뮤니티에서 가장 많이 나오는 질문 중 하나가 “그래서 기존 Power Apps 임베드 방식이랑 뭐가 다르냐”입니다. 직접 비교한 자료를 기반으로 정리하면 이렇습니다. (출처: Microsoft Power BI 커뮤니티 블로그, 2025.09)
| 비교 항목 | Translytical TTF | Power Apps 임베드 |
|---|---|---|
| 입력 옵션 종류 | 목록·텍스트·버튼 3종 | 날짜선택·슬라이더 포함 다양 |
| 추가 라이선스 비용 | 없음 (Fabric 용량에 포함) | $20/사용자/월 (Premium) |
| 대량 레코드 처리 | UDF로 고성능 가능 | 행 수 늘수록 성능 저하 |
| 솔루션 복잡도 | Fabric 단일 플랫폼 | Power Platform 별도 관리 |
| UI/UX 완성도 | 낮음 (북마크 등 우회 필요) | 높음 (멀티 스크린 지원) |
실무 비교를 정리한 결과, 최종 스코어는 Power Apps 3 : Translytical TTF 3으로 동점입니다. Power Apps가 사용자 경험 측면에서 앞서지만, Translytical TTF가 비용과 솔루션 단순성에서 확실한 우위를 가집니다. (출처: Microsoft Power BI 커뮤니티 비교 분석, 2025.09)
💡 공식 발표에서는 잘 보이지 않는 부분인데, 첫 번째 TTF 버튼 클릭 시 Fabric 세션이 시작되기 때문에 초기 응답이 수 초에서 수십 초 지연될 수 있습니다. 세션이 유지된 이후의 작업은 빠르지만, 첫 번째 클릭의 지연은 사용자 경험에서 중요한 변수입니다. 이 부분은 공식 제품 페이지에서 별도로 안내하지 않았습니다.
3월 업데이트에서 같이 나온 기능들이 조합하면 달라집니다
Translytical 작업 흐름의 GA만 보면 그림이 반쪽입니다. 이번 2026년 3월 업데이트(v2.152.882.0)에서 함께 나온 기능들과 조합하면 실제 활용 폭이 달라집니다. (출처: Microsoft Power BI 3월 2026 기능 요약, 2026.03.15)
① OneLake의 Direct Lake 정식 출시
OneLake의 Direct Lake도 이번 달 GA가 됐습니다. 기존 Direct Lake on SQL 방식에 비해 OneLake 보안과의 호환성이 강화됐고, 모델링 기능과 쿼리 성능이 향상됩니다. Translytical 작업 흐름으로 데이터를 수정하면, Direct Lake on OneLake로 연결된 보고서가 그 변경을 거의 즉시 반영합니다. 데이터를 고치고 결과를 같은 화면에서 바로 확인하는 루프가 완성됩니다.
② 입력 슬라이서 조건부 서식 지원
Translytical 작업 흐름의 가장 큰 약점이 입력 UI였습니다. 3월 업데이트에서 입력 슬라이서가 조건부 서식(Fx)을 지원하기 시작했습니다. 데이터 상태에 따라 텍스트 색상, 테두리, 강조 바 색상이 동적으로 바뀌게 설정할 수 있습니다. 여전히 Power Apps만큼은 아니지만, 한 단계 개선됐습니다.
③ DAX 사용자 정의 함수 파라미터 256개로 확대
DAX UDF의 최대 파라미터 수가 12개에서 256개로 늘었습니다. 단순한 수치 변화처럼 보이지만, Translytical 작업 흐름에서 복잡한 필터 컨텍스트를 UDF로 넘길 때 이 제한이 실제로 걸렸던 사례가 있었습니다. 256개로 확대되면서 실무에서 마주치는 제약이 상당 부분 해소됩니다. (출처: Microsoft Learn, DAX 사용자 정의 함수 모범 사례)
지금 바로 쓰면 안 되는 경우가 있습니다
GA가 됐다고 해서 무조건 쓸 수 있는 건 아닙니다. 아래 경우에 해당하면 지금 도입을 서두르는 게 오히려 역효과입니다.
❌ 현재 적용하면 어려운 상황
- Fabric 외부 데이터베이스만 쓰는 조직 — Azure SQL, Oracle, Snowflake 등은 writeback 대상이 아닙니다. REST API 연동으로 우회는 가능하지만 개발 공수가 늘어납니다.
- PBIR/PBIP 형식을 쓰는 팀 — Power BI 고급 보고서·프로젝트 형식은 현재 미지원입니다. 공식 문서에 이유는 공개되지 않았습니다.
- 복잡한 다단계 승인 워크플로가 필요한 경우 — 여러 부서가 개입하는 프로세스, 오프라인 입력 시나리오는 별도 비즈니스 앱이 더 적합합니다.
- CI/CD 파이프라인이 필수인 팀 — 아직 Fabric 배포 파이프라인 지원이 없습니다. 환경 간 보고서를 이동할 때 버튼 재바인딩 등 수동 작업이 남습니다. (출처: Nimble Learn 기술 블로그, 2025.10)
- Power BI Embedded를 퍼블릭 임베드 방식으로 쓰는 경우 — 보안 포함 시나리오에서만 지원됩니다.
솔직히 말하면, 지금 상태의 Translytical 작업 흐름은 “Fabric 올인” 조직에 가장 잘 맞는 기능입니다. Fabric을 이미 쓰고 있고, 단순한 인플레이스 데이터 수정이나 승인 버튼, 외부 API 트리거 정도가 필요하다면 도입할 가치가 충분합니다. 아직 Fabric을 도입하지 않은 조직이라면, 이 기능 하나를 위해 마이그레이션을 서두를 이유는 없습니다.
자주 나오는 질문 5가지
Q1. Translytical 작업 흐름을 사용하려면 Fabric 용량이 반드시 필요한가요?
네, 필요합니다. UDF(사용자 데이터 함수)는 Fabric 용량 위에서 실행됩니다. Power BI Premium Per User(PPU)나 Power BI Pro 라이선스만으로는 작동하지 않습니다. Fabric 용량 SKU가 있어야 하며, Trial 용량으로도 테스트는 가능합니다. (출처: Microsoft Learn, Fabric 사용자 데이터 함수 서비스 제한)
Q2. Python을 모르는 보고서 제작자도 만들 수 있나요?
UDF 자체는 Python으로 작성해야 합니다. 보고서 제작자가 Python을 모른다면, 데이터 엔지니어나 개발자가 UDF를 먼저 만들고 배포하면 보고서 제작자는 그걸 가져다 버튼에 연결하는 방식으로 역할을 나눌 수 있습니다. 완전 노코드는 아닙니다.
Q3. Azure OpenAI 같은 외부 API를 연동할 수 있다는데, 비용은 어떻게 되나요?
UDF에서 Azure OpenAI API를 호출하면, 그 API 호출 비용은 별도로 발생합니다. Power BI 보고서를 통해 버튼을 누를 때마다 Azure OpenAI 요금이 청구됩니다. 사용량에 따라 달라지므로 사전에 API 호출량 예측이 필요합니다. UDF 자체 실행 비용은 Fabric 용량에서 소모되지만, 외부 API 비용은 별도입니다.
Q4. 데이터를 수정하면 보고서에 바로 반영되나요?
Fabric SQL 데이터베이스와 Direct Lake on OneLake를 함께 쓰면 수정 후 거의 즉각적으로 보고서에 반영됩니다. 단, Import 모드를 쓰는 경우에는 데이터 새로 고침 후에 반영됩니다. UDF가 성공적으로 실행되면 Power BI에 확인 팝업이 뜨고, 그 시점에 보고서 시각적 요소가 자동 새로 고침됩니다.
Q5. 기존 Power Automate 시각적 요소와 차이가 무엇인가요?
Power Automate 시각적 요소는 사전에 만들어둔 플로를 트리거하는 방식이고, 실시간 데이터 쓰기 저장 기능이 없습니다. Translytical 작업 흐름은 UDF를 통해 보고서 내 필터 컨텍스트와 사용자 입력값을 실시간으로 데이터베이스에 반영할 수 있습니다. 트리거 방식은 비슷해 보이지만, 데이터 처리 깊이와 실시간성에서 차이가 납니다.
마치며 — 총평
Power BI Translytical 작업 흐름이 GA로 나왔다는 건, 이제 “언제 쓸 수 있나요?”가 아니라 “우리 조직에 맞나요?”를 따져야 할 단계가 됐다는 뜻입니다. Fabric 기반 환경이 갖춰진 조직이라면, 추가 라이선스 없이 보고서에 쓰기 기능을 얹을 수 있는 건 분명한 장점입니다. Power Apps Premium 라이선스 $20/월 절감 가능성은 사용자 수가 많을수록 실질적 차이가 납니다.
반면, 프론트엔드 입력 옵션의 한계(3종), 첫 번째 버튼 클릭 시 세션 시작 지연, CI/CD 파이프라인 미지원은 지금 시점에서 실무 도입을 가로막는 현실적인 장벽입니다. 이 부분들은 Microsoft가 공식 이슈로 인지하고 있으며, 향후 업데이트에서 개선이 예상되지만 일정은 공개되지 않았습니다.
Fabric을 이미 쓰고 있고 단순한 인플레이스 편집이나 Teams 알림 트리거가 목표라면, 지금 바로 튜토리얼 한 번 돌려볼 만한 기능입니다. 복잡한 멀티 스텝 프로세스를 원한다면, 한 발짝 더 기다리는 게 맞습니다.
📚 본 포스팅 참고 자료
본 포스팅은 2026년 3월 25일 기준으로 작성됐습니다. Power BI 및 Microsoft Fabric 서비스 정책·UI·기능은 업데이트에 따라 변경될 수 있습니다. 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있으므로, 최신 정보는 Microsoft 공식 문서를 통해 확인하시기 바랍니다.
댓글 남기기