Power BI Translytical, 데이터 수정이 이제 된다고요?

Published on

in

Power BI Translytical, 데이터 수정이 이제 된다고요?

2026.03.15 기준 / Power BI Desktop v2.152.882.0 기준

Power BI Translytical, 데이터 수정이 이제 된다고요?

2026년 3월, Power BI의 Translytical 작업 흐름이 드디어 정식(GA) 출시됐습니다. 보고서를 보다가 그 자리에서 데이터를 바꾸는 게 진짜 가능해졌는데 — 막상 써보면 ‘이 조건은 안 된다’는 게 꽤 많습니다. 공식 문서와 실사용 비교 결과를 같이 놓고 보니 생각과 다른 부분이 보였습니다.

✅ GA 출시일: 2026년 3월 15일
⚠️ Excel write-back: 지원 안 됨
🔗 필수 조건: Microsoft Fabric 용량

Translytical 작업 흐름, 정확히 뭐가 달라진 건가요?

Power BI Translytical 작업 흐름은 2025년 5월 미리 보기로 처음 공개됐고, 2026년 3월 15일 정식(GA) 출시됐습니다. (출처: Microsoft Power BI March 2026 Feature Summary, powerbi.microsoft.com, 2026.03.15) GA 전환이 중요한 이유가 있습니다. 미리 보기 기간에는 서비스 수준 약정(SLA)이 적용되지 않아서 기업 환경에 바로 도입하기 어려웠는데, 이제 그 제약이 풀렸습니다.

핵심 개념은 ‘Translytical’이라는 단어 자체에 있습니다. ‘Transactional'(거래·수정)과 ‘Analytical'(분석)을 합친 말로, 보고서를 보면서 동시에 데이터를 바꾸는 게 목표입니다. 지금까지 Power BI는 철저히 ‘읽기 전용’ 도구였는데, 이 흐름이 그 구조를 바꿉니다.

뒤에서 실질적으로 이 기능을 움직이는 건 Fabric의 사용자 데이터 함수(User Data Function, UDF)입니다. Python 기반 코드 블록으로, 보고서에서 사용자가 버튼을 누를 때 실행됩니다. 데이터 검증, 레코드 수정, 외부 API 호출을 처리합니다.

▲ 목차로 돌아가기

보고서에서 데이터를 바꾼다는 게 어떤 의미인지

공식 문서 예시가 가장 직관적입니다. 영업팀이 Power BI 보고서에서 위험 고객 목록을 보다가, 그 자리에서 할인율을 바꾸고 ‘할인 제출’ 버튼을 누르면 Fabric SQL 데이터베이스의 원본 레코드가 바뀝니다. 보고서를 닫고 ERP나 스프레드시트를 따로 열 필요가 없습니다. (출처: Microsoft Learn — Translytical task flow overview, 2026.03)

또 다른 시나리오로는 Azure OpenAI API 연동이 있습니다. 보고서에서 영향 요인을 선택한 뒤 ‘AI 제안 생성’ 버튼을 누르면, UDF가 Azure OpenAI 응답 API를 호출해 맞춤형 권고문을 그 자리에 돌려줍니다. 분석 + 실행 + AI 응답이 한 화면에서 이뤄지는 구조입니다.

Teams 연동도 가능합니다. 영업 기회 데이터에서 위험 건수를 필터링하고 할인 요청을 누르면 Teams 채널에 승인 메시지가 자동으로 올라갑니다. 보고서 → 승인 → Teams 알림까지 한 흐름으로 연결됩니다.

▲ 목차로 돌아가기

Excel·SharePoint에는 write-back이 안 됩니다

💡 공식 문서와 실제 사용 흐름을 같이 놓고 보니 이런 차이가 보였습니다

“이제 Power BI에서 데이터를 바꿀 수 있다”는 말에 많은 분들이 Excel 파일이나 SharePoint 목록도 된다고 생각하는데, 공식 문서는 다르게 말합니다.

Translytical 작업 흐름의 데이터 쓰기 저장(write-back)이 지원하는 대상은 Fabric SQL 데이터베이스, Fabric 웨어하우스, Fabric 레이크하우스(파일 한정)입니다. Excel, SharePoint, 외부 SQL 서버, 온프레미스 DB는 직접 쓰기 저장 대상이 아닙니다. (출처: Microsoft Learn — Translytical task flow overview, Data write-back 섹션, 2026.03)

Excel write-back이 전혀 불가능한 건 아닙니다. 다만 방식이 다릅니다. Excel을 Fabric 레이크하우스에 연동하거나, REST API를 통해 Excel Online API를 호출하는 우회 구성이 필요합니다. 그 경우에도 ‘네이티브’ 지원이 아니라 커스텀 Python 코드를 짜야 합니다. 직접 연결만 기대하면 바로 막힙니다.

실무에서 가장 중요한 포인트는 Fabric SQL 데이터베이스를 쓰는 게 공식 권장 사항이라는 점입니다. OLTP(온라인 트랜잭션 처리) 최적화 구조라 읽기·쓰기가 동시에 많이 발생하는 보고 환경에 가장 적합합니다. 웨어하우스나 레이크하우스는 읽기 중심 구조라 대규모 write-back에서 성능이 다를 수 있습니다.

데이터 원본 Write-back 지원 비고
Fabric SQL 데이터베이스 ✅ 권장 OLTP 최적화, 공식 권장
Fabric 웨어하우스 ✅ 지원 대규모 쓰기 시 성능 검토 필요
Fabric 레이크하우스 ⚠️ 파일 한정 파일 형태만, 테이블은 제한적
Excel / SharePoint ❌ 직접 불가 API 우회 방식만 가능
외부 REST API ✅ 지원 UDF에서 직접 API 호출

(출처: Microsoft Learn — Translytical task flow overview, 2026.03)

▲ 목차로 돌아가기

“성공” 메시지가 떠도 실제 오류가 숨어 있을 수 있습니다

💡 공식 문서에서 별도 이유를 밝히지 않은 부분인데, 실사용 데이터와 겹쳐 보니 이 패턴이 나왔습니다

버튼을 눌렀을 때 “성공” 팝업이 뜨는 것과 실제 UDF 내부 로직이 성공했다는 것은 다른 이야기입니다.

Translytical 작업 흐름의 팝업 메시지는 UDF 자체가 호출됐는지 여부로 ‘성공/실패’를 판단합니다. UDF가 실행됐지만 내부 로직에서 오류가 났을 경우, 별도의 오류 메시지를 UDF 반환값에 담아 설정하지 않으면 팝업엔 여전히 “성공”이라고 뜰 수 있습니다. (출처: Downhill-Data.com — Comparing write-back options for Power BI/Fabric, 2025.09.09)

실무에서 더 난감한 건 개발 과정입니다. Power BI Desktop에서 UDF를 테스트할 때마다 전체 데이터 모델 메타데이터 새로 고침이 자동으로 돌아갑니다. DirectQuery 모델이라도 예외가 없습니다. 소규모 수정 한 번에 5분 넘게 기다린 사례도 보고됩니다. Fabric 내에서 UDF를 독립적으로 테스트하는 방법을 먼저 익혀두면 시간을 크게 줄일 수 있습니다.

현재 공식 문서에서 이 동작의 상세 이유를 별도로 밝히지 않은 부분입니다. UDF 반환값에 로그와 오류 정보를 반드시 포함시키는 패턴을 처음부터 습관화해야 팝업 메시지만 믿고 넘어가는 상황을 막을 수 있습니다.

▲ 목차로 돌아가기

Power Apps와 비교했을 때 어떤 걸 쓰면 유리한가요?

Translytical이 나오기 전까지 Power BI에서 write-back을 구현하려면 Power Apps 임베디드 비주얼을 쓰는 게 사실상 유일한 현실적 방법이었습니다. 그런데 Power Apps Premium 라이선스는 사용자당 월 $20입니다. (출처: Downhill-Data.com — Comparing write-back options, 2025.09.09) write-back만을 위해 이 비용을 매달 내는 건 규모가 작은 팀에는 부담입니다.

비교 분석 결과는 생각보다 복잡합니다. 항목별로 나눠서 보면: UI/UX와 입력 옵션은 Power Apps 우위입니다. 날짜 선택기, 슬라이더, 라디오 버튼, 기본값 설정 등 Translytical에서 아직 지원하지 않는 입력 형태가 Power Apps에는 있습니다. 반면 비용과 아키텍처는 Translytical 우위입니다. Fabric 용량만 있으면 추가 라이선스 없이 구성됩니다. 대량 레코드 처리도 Translytical이 낫습니다. Power Apps는 기본 데이터 커넥터로 대량 write-back을 처리할 때 성능이 크게 떨어지는데, Translytical은 UDF의 Fabric 컴퓨팅 파워를 그대로 씁니다.

비교 항목 Translytical TTF Power Apps
UI/UX 입력 다양성 제한적 우위
비용 (추가 라이선스) 없음 (Fabric 포함) 월 $20/인 (Premium)
단일 레코드 성능 세션 시작 시 지연 빠름
대량 레코드 처리 우위 성능 저하 (기본)
솔루션 복잡도 단순 (Fabric 내) 복잡 (2플랫폼 관리)
배포 파이프라인(CI/CD) 미지원 (현재) 지원

(출처: Downhill-Data.com — Comparing write-back options for Power BI/Fabric, 2025.09.09 / NimbleLearn.com, 2025.10.31)

현재 Translytical에는 Fabric 배포 파이프라인 지원이 없습니다. 개발·스테이징·프로덕션 환경 간 이동 시 버튼 다시 연결 같은 수동 작업이 남아 있습니다. (출처: NimbleLearn.com, 6 Things You Should Know About Translytical Task Flows, 2025.10.31) 이유는 아직 공개되지 않았으나, GA 이후 업데이트에서 해결될 가능성이 높습니다.

▲ 목차로 돌아가기

공식 발표문과 실제 사용 흐름을 같이 놓고 보니 이런 차이가 보였습니다

💡 두 자료를 교차해서 봤더니 이런 패턴이 나왔습니다

Microsoft 공식 발표는 기능의 가능성을 보여주고, 실사용 비교 데이터는 그 기능의 현재 한계를 보여줍니다. 이 둘을 같이 보면 ‘지금 바로 쓸 수 있는 조건’이 보입니다.

Translytical이 지금 당장 효과적인 상황은 명확합니다. Fabric 용량을 이미 쓰고 있고, Power Apps Premium 라이선스 비용이 부담스럽고, 간단한 레코드 편집이나 승인 버튼 수준의 write-back이 필요한 경우입니다. 복잡한 다단계 입력 양식이나 오프라인 데이터 입력이 필요한 경우라면 아직 Power Apps가 현실적입니다.

흥미로운 구조적 포인트가 하나 있습니다. Translytical의 UDF는 보고서의 DAX 측정값을 파라미터로 직접 받을 수 있습니다. 즉, 보고서의 필터 컨텍스트 — 슬라이서 선택값, 날짜 범위, 특정 행 선택 — 를 계산식으로 감싸서 UDF에 자동으로 넘길 수 있습니다. (출처: Microsoft Power BI March 2026 Feature Summary) 이 구조가 Power Apps 임베드 방식의 1,000행 제한과 근본적으로 다른 점이고, 대량 데이터 처리에서 TTF가 앞서는 이유입니다.

솔직히 말하면, 지금 시점에서 Translytical은 ‘가능성을 입증한 GA’이지 ‘완성된 앱 개발 플랫폼’은 아닙니다. 날짜 선택기 하나 없는 입력 방식은 실무에서 분명히 불편합니다. 하지만 라이선스 비용 없이 Fabric 환경 안에서 write-back을 돌린다는 아키텍처 이점은 뚜렷합니다. 기능이 채워지는 속도에 따라 Power Apps 임베드 방식을 대체할 현실적 대안이 될 거라고 봅니다.

▲ 목차로 돌아가기

Q&A

Q1. Translytical 작업 흐름을 쓰려면 어떤 라이선스가 필요한가요?
Microsoft Fabric 용량이 필요합니다. Power BI Pro 또는 Premium Per User(PPU) 라이선스만으로는 Translytical 작업 흐름을 구성하기 어렵습니다. Fabric 용량(F SKU 또는 P SKU)이 있어야 사용자 데이터 함수(UDF)를 만들고 실행할 수 있습니다. 개인 사용자 수준의 무료 Fabric 체험 용량으로 테스트는 가능합니다.
Q2. Power BI Embedded 환경에서도 Translytical을 쓸 수 있나요?
공식 문서 기준으로 Power BI Embedded는 보안 포함(Secure Embed) 시나리오에서만 지원됩니다. (출처: Microsoft Learn — Translytical task flow overview, 제한 사항 섹션, 2026.03) 일반적인 앱 토큰 기반 임베딩에서는 현재 지원되지 않습니다.
Q3. 사용자 데이터 함수(UDF)를 작성하려면 Python을 알아야 하나요?
네, UDF는 Python 기반입니다. 기본적인 Python 문법과 REST API 호출 방식을 이해하고 있어야 UDF를 직접 작성할 수 있습니다. 다만 Microsoft가 GitHub Gist에 공개한 샘플 코드가 있어서, 그걸 수정해 쓰는 방식으로 Python 경험이 적어도 시작할 수 있습니다. (출처: Microsoft Learn — Translytical task flow examples, github.com/Sujata994)
Q4. PBIP(Power BI Project) 파일 형식과 함께 쓸 수 있나요?
현재는 지원되지 않습니다. 공식 문서 제한 사항에 PBIR(Power BI Enhanced Report Format)과 PBIP(Power BI Project) 형식 모두 Translytical 작업 흐름과 함께 쓸 수 없다고 명시되어 있습니다. (출처: Microsoft Learn — Translytical task flow overview, 2026.03) Git 기반 버전 관리와 연동하는 최신 방식을 쓰는 팀이라면 이 제한이 당장 걸릴 수 있습니다.
Q5. 보고서 사용자가 UDF를 직접 수정하거나 건드릴 수 있나요?
아닙니다. UDF는 개발자나 데이터 엔지니어가 Fabric 작업 영역에서 만들고 게시합니다. 보고서 최종 사용자는 버튼을 눌러 UDF를 트리거할 뿐, 내부 코드에는 접근하지 않습니다. 이 구조가 거버넌스와 감사(audit) 측면에서 Power Apps 임베드 방식보다 단순하게 관리되는 이유이기도 합니다.

▲ 목차로 돌아가기

마치며

Translytical 작업 흐름의 GA 출시는 Power BI가 ‘읽기 전용 시각화 도구’라는 오랜 틀을 공식적으로 벗어나는 전환점입니다. 그것만으로도 이번 3월 업데이트에서 가장 주목할 변화라고 생각합니다.

다만 ‘이제 Power BI에서 뭐든 바꿀 수 있다’는 식으로 받아들이면 막히는 지점이 금방 생깁니다. Excel·SharePoint write-back 직접 지원 안 됨, PBIP 형식 미지원, CI/CD 파이프라인 미완성, 입력 위젯 부족 — 이건 지금 쓰려는 분들이 바로 마주칠 수 있는 현실적인 제약입니다.

Fabric 환경을 이미 운영 중이고 라이선스 비용 없이 간단한 write-back을 넣고 싶은 팀에게는 지금 당장 써볼 가치가 있습니다. 복잡한 UI가 필요하거나 Power Apps를 이미 잘 쓰고 있다면, Translytical이 조금 더 성숙해질 때까지 기다리는 게 현실적입니다. 기능이 채워지는 속도를 보면서 전환 시점을 재는 게 맞다고 봅니다.

▲ 목차로 돌아가기

본 포스팅 참고 자료

  1. Microsoft Power BI March 2026 Feature Summary —
    powerbi.microsoft.com
  2. Microsoft Learn — Translytical task flow overview —
    learn.microsoft.com
  3. Downhill-Data.com — Comparing write-back options for Power BI/Fabric (2025.09.09) —
    downhill-data.com
  4. NimbleLearn.com — 6 Things You Should Know About Translytical Task Flows (2025.10.31) —
    nimblelearn.com
  5. Microsoft Learn — Power BI 새로운 기능: 2026년 3월 업데이트 —
    learn.microsoft.com


본 포스팅은 2026년 3월 27일 기준으로 작성됐습니다. 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. Power BI 및 Microsoft Fabric의 기능 업데이트는 Microsoft 공식 릴리스 노트에서 최신 정보를 확인하시기 바랍니다.

댓글 남기기


최신 글


아이테크 어른경제에서 더 알아보기

지금 구독하여 계속 읽고 전체 아카이브에 액세스하세요.

계속 읽기