들어가며 — 왜 지금 이 비교가 필요한가
공공기관과 기업의 데이터 시각화 환경을 들여다보면 생각보다 솔루션이 다양하다. Google Looker Studio, Oracle Analytics, TIBCO Spotfire, MicroStrategy(MSTR)... 이름만 들어도 머리가 아픈 라인업이다. 그런데 이 중에서 최근 몇 년 사이 시장 점유율과 채용 공고, 자격증 시장 모두에서 압도적으로 양강 구도를 형성한 두 솔루션이 있다. Tableau와 Microsoft Power BI다.
이 글을 쓰는 이유는 단순한 기능 비교가 아니다. 두 솔루션은 현재 경영정보시각화능력 실기 시험의 선택 과목이다. 매 회차 응시생들이 가장 많이 하는 질문이 "저는 어떤 툴로 준비해야 하나요?"인데, 막상 명쾌하게 답해주는 글이 드물다.
나는 태블로 엔지니어로 현업에서 Tableau Server를 온프레미스로 구축·운영하고 있고, 동시에 2024년에 Power BI 2박 3일 집체 교육을 이수한 경험이 있다. 양쪽을 실무에서 다뤄본 사람의 입장에서, 스펙표 비교를 넘어 "실제로 손으로 만져보면 무엇이 다른가"를 솔직하게 정리해보려 한다.
1. Tableau 소개 — 스탠퍼드 연구실에서 시작된 시각화 혁명
탄생 배경
Tableau는 2003년 미국 스탠퍼드 대학교 컴퓨터과학과의 박사과정 연구 프로젝트에서 출발했다. 창업자는 Christian Chabot, Pat Hanrahan, Chris Stolte 세 사람이다. 특히 Pat Hanrahan은 픽사(Pixar)에서 렌더링 기술을 연구했고 이후 2019년 컴퓨터 그래픽 분야 공로로 아카데미 과학기술상을 받기도 한 인물로, "데이터를 어떻게 시각적으로 직관적으로 인코딩할 것인가"라는 학술적 문제의식이 Tableau의 출발점이었다. 이 연구는 스탠퍼드의 VizQL(Visual Query Language) 프로젝트로 이어졌고, 사용자가 드래그 앤 드롭으로 데이터를 조작하면 내부적으로 이것이 SQL과 시각적 인코딩 명세로 자동 변환되는 구조가 핵심 특허 기술이 됐다.
2003년 회사 설립, 2013년 뉴욕증권거래소(NYSE) 상장을 거쳐 2019년 Salesforce가 약 157억 달러(한화 약 18조 원 규모)에 인수하며 현재는 Salesforce 산하 제품군으로 편입돼 있다. 학계 연구에서 출발했다는 태생 덕분에 "데이터를 보는 행위 자체를 설계한다"는 철학이 제품 전반에 깊게 배어 있다.
핵심 철학 — VizQL과 드래그앤드롭
Tableau의 가장 큰 특징은 사용자가 차트를 "선택"하는 게 아니라 데이터를 캔버스(행/열 선반)에 올리면 차트가 "생성"된다는 점이다. 막대그래프, 라인차트, 산점도를 메뉴에서 고르는 게 아니라, 차원과 측정값을 행과 열에 배치하는 행위 자체가 곧 시각화 문법이 된다. 이 직관성 때문에 비전공자도 빠르게 적응하는 반면, 내부적으로는 매우 정교한 쿼리 엔진이 작동한다.
2. Power BI 소개 — 엑셀 제국이 만든 정공법
탄생 배경
Power BI의 뿌리는 2010년 마이크로소프트가 엑셀 추가 기능으로 출시한 PowerPivot이다. 이후 Power Query(데이터 변환), Power View(시각화), Power Map 등 일련의 "Power" 시리즈 애드인이 결합되면서 2013~2014년 사이 독립 제품으로 발전했고, 정식 출시는 2015년 7월이다. SQL Server Analysis Services의 인메모리 컬럼형 엔진인 VertiPaq(현재 명칭 xVelocity)를 기반으로 하는데, 이는 Tableau의 VizQL과는 완전히 다른 계보로, 엑셀의 피벗테이블·DAX 수식 체계를 그대로 계승하면서 대용량 처리가 가능하도록 확장한 구조다.
Power BI는 마이크로소프트 자체 제품이기 때문에 Microsoft 365, Excel, SharePoint, Teams, Azure, 그리고 최근에는 Microsoft Fabric과의 생태계 통합이 가장 강력한 무기다. 2025년은 Power BI 출시 10주년이었고, 마이크로소프트는 이를 기념하며 연중 다양한 커뮤니티 행사와 기능 업데이트를 발표했다.
핵심 철학 — 모델 중심, 엑셀 친화적 UI
Power BI는 "모델(데이터 모델)을 먼저 잘 설계하고, 그 위에 DAX로 측정값을 쌓아 시각화한다"는 흐름을 따른다. 리본 메뉴, 시각화 창, 필드 창으로 구성된 UI는 엑셀이나 파워포인트 사용자에게 매우 친숙하다.
3. 본격 비교 — 스펙, 활용도, 난이도
| 구분 | Tableau | Power BI |
|---|---|---|
| 개발사 | Salesforce (2019년 인수) | Microsoft |
| 최초 출시 | 2003년 (정식 제품 2004년) | 2015년 7월 |
| 핵심 엔진 | VizQL (시각 쿼리 언어) | VertiPaq / xVelocity (인메모리 컬럼 엔진) |
| 수식 언어 | Table Calculation, LOD(Level of Detail) 표현식 | DAX (Data Analysis Expressions) |
| 라이선스 모델 | Creator / Explorer / Viewer 역할 기반 | Pro / Premium / Premium Per User, Fabric 용량 기반 |
| 데스크톱 가격대 | Creator 약 $75~115/월 수준(역할별 상이) | Pro 약 $10/월, Desktop 자체는 무료 |
| 온프레미스 서버 | Tableau Server (자체 구축 가능) | Power BI Report Server (페이지 매김 보고서 중심, 제약 있음) |
| 모바일 앱 | 있음 | 있음, Microsoft 생태계와 통합도 높음 |
| 클라우드 통합 | Salesforce, AWS, Google Cloud 등 범용 | Microsoft 365, Azure, Fabric과 강력 결합 |
| 시각화 커스터마이징 | 매우 높음(셰이프, 색상, 레이아웃 디테일 제어) | 표준 시각화는 빠르지만 세부 커스터마이징은 제약 존재 |
| 대용량 데이터 처리 | Hyper 엔진(인메모리+추출 혼합) | VertiPaq 압축 모델, Direct Lake(Fabric) 등 최신 옵션 다양 |
| 학습 난이도 | 시각화 문법은 직관적, 고급 LOD는 진입장벽 있음 | 엑셀 사용자에게 친숙, DAX는 별도 학습 곡선 존재 |
| 주요 사용자층 | 데이터 분석가, BI 전문 컨설턴트, 시각화 디자인 중시 조직 | 엑셀 기반 현업 부서, MS 생태계 의존 조직, 전사 표준화 추진 기업 |
활용도 측면
Tableau는 "시각화 자체의 완성도"를 요구하는 환경, 즉 경영진 보고용 대시보드나 외부 공개용 데이터 저널리즘, 고객사에 납품하는 인터랙티브 리포트에서 강점이 두드러진다. 반면 Power BI는 이미 Microsoft 365 라이선스를 보유한 조직에서 추가 비용 부담 없이 전사적으로 빠르게 확산시키기 좋고, 엑셀 기반 보고 체계를 가진 조직의 디지털 전환 1단계로 자주 선택된다.
난이도 측면 — 입문은 Power BI, 정교함은 Tableau
처음 차트 하나를 그리는 속도는 Power BI도 결코 느리지 않다. 다만 "필터에 따라 제목이 동적으로 바뀐다"거나 "특정 조건에서만 강조색을 입힌다"처럼 디테일을 요구하는 순간부터 두 툴의 학습 곡선이 갈라지기 시작한다.
이 부분은 다음 장에서 직접 경험을 바탕으로 풀어본다.
4. 태블로 엔지니어가 2박 3일 Power BI 교육을 받고 느낀 것 — 2024년 vs 2026년 검증
2024년에 Power BI 집체 교육을 2박3일 이수하면서 느낀 불편함들을 정리해 뒀었다. 이 글을 쓰면서 "혹시 그새 개선됐을까?" 싶어 2026년 6월 현재 기준으로 하나하나 다시 검색해 검증했다. 결론부터 말하면, 본질적인 구조는 그대로고, 일부는 여전히 DAX나 설정으로 우회해야 한다. 돌려 말하지 않고 있는 그대로 적는다.
① 엑셀과 닮은 UI/UX — 익숙함과 불편함은 한 끗 차이
Power BI의 서식 패널, 셀 단위 조건부 서식, 리본 메뉴 구조는 엑셀 사용자에게 분명 진입장벽을 낮춰준다. 하지만 동시에 엑셀의 고질적인 불편함도 그대로 따라온다. 예를 들어 테이블 시각화에서 텍스트 데이터에 줄 바꿈 문자가 있으면 기본적으로 무시되고, 이를 인식시키려면 시각화 창 설정에서 별도로 "값 텍스트 줄 바꿈" 옵션을 켜줘야 한다. 열 단위로 맞춤(정렬) 방식을 하나밖에 선택할 수 없는 제약도 여전하다. Tableau에서는 마크 카드와 서식 패널에서 훨씬 자유도 높게 셀 단위, 헤더 단위 서식을 독립적으로 건드릴 수 있는 것과 대비된다.
② DAX, 여전히 Tableau의 함수보다 진입장벽이 높다
이건 2026년 현재도 명확히 유효하다. DAX는 엑셀 함수 문법을 빌려왔지만 내부적으로는 행 컨텍스트(Row Context)와 필터 컨텍스트(Filter Context)라는 개념을 이해해야 의도한 대로 동작한다. 이게 익숙해지기 전까지는 똑같은 결과를 내는 측정값인데도 CALCULATE 함수 하나로 결과가 완전히 달라지는 현상에 당황하게 된다. Tableau의 LOD 표현식(FIXED, INCLUDE, EXCLUDE)도 처음엔 까다롭지만, 컨텍스트가 두 종류(행/필터)로 쪼개지는 DAX보다는 학습 범위가 좁다는 게 현업에서 양쪽을 다뤄본 체감이다.
③ 한글 폰트 — "지원 안 됨"은 과장이지만, 여전히 번거롭다
2024년 당시 "Power BI는 영문 폰트만 지원하고 한글을 쓰려면 자바를 건드려야 한다"라고 느꼈던 부분을 다시 확인해 봤다. 정확히 말하면 이렇다.
- Power BI Desktop 자체의 메뉴·버튼 등 UI 언어는 한국어를 포함해 다양한 언어로 번역 제공된다.
- 하지만 시각화·테마의 글꼴 드롭다운 목록은 기본적으로 영문 서체 위주로 노출되며, 한글 폰트를 쓰려면 사용자가 Windows에 설치된 시스템 폰트 중에서 직접 찾아 선택해야 한다. "건드릴 수 없다"기보다는 "기본 추천 목록에 친절하게 떠 있지 않다"가 더 정확한 표현이다.
- 텍스트 상자, 카드, 테이블 등 시각적 개체별로 폰트를 개별 지정해야 하는 구조라, Tableau의 워크북 단위 폰트 일괄 적용이나 글꼴 자동 매핑에 비하면 디테일을 맞추는 데 손이 더 간다.
즉 "한글이 아예 안 된다"는 과장이지만 "Tableau만큼 손쉽게, 일관되게 디자인을 통제할 수는 없다"는 2024년의 체감은 2026년 현재도 본질적으로 유효하다.
④ 요일·날짜 서식 — DAX로 직접 변환해야 하는 건 여전
Power BI에서 날짜 필드를 불러오면 요일명, 월명 등은 기본적으로 영문(Monday, January 등)으로 표시된다. 이를 한글 "월요일", "1월"처럼 표시하려면 FORMAT 함수에 로캘(locale) 인자를 지정하거나(FORMAT(날짜, "dddd", "ko-KR") 형태), 별도의 한글 매핑 테이블/측정값을 만들어야 한다. 이는 마이크로소프트 공식 문서에서도 시각적 개체에 로캘을 추가하는 방법을 별도 페이지로 설명할 만큼 표준 워크플로우로 자리 잡혀 있다는 뜻이기도 하다 — 다르게 말하면, 기본값이 한글이 아니라서 매번 추가 작업이 필요하다는 사실 자체는 변하지 않았다. Tableau는 컴퓨터의 로캘 설정이나 워크북 설정에 따라 요일·월 표기가 한글로 비교적 자연스럽게 따라오는 경우가 많아, 이 지점에서의 체감 격차는 여전하다.
⑤ 날짜의 연속성/불연속성 구분과 시계열 — 별도 날짜 테이블이 사실상 필수
Tableau는 날짜 필드를 선반에 올릴 때 연속형(녹색 알약)과 불연속형(파란색 알약)을 명확히 구분해 제공하고, 드릴다운으로 연-분기-월-일을 자동으로 계층화해 준다. Power BI는 이 구분이 명시적 UI로 드러나지 않고, 제대로 된 시계열 분석(연도 대비 성장률, 이동평균, 전년 동기 대비 등)을 하려면 별도의 "날짜 테이블(Date Table)"을 만들어 모델의 팩트 테이블과 관계(Relationship)를 맺어주는 것이 사실상 표준 모범 사례로 통한다. 이는 DAX의 시간 인텔리전스 함수(SAMEPERIODLASTYEAR, DATEADD 등)가 정상 동작하려면 연속된 날짜 값을 가진 전용 테이블이 필요하기 때문인데, 마이크로소프트 자신도 이를 권장 패턴으로 안내한다. 즉 "날짜 테이블을 굳이 하나 만들어야 한다"는 불편함은 버그가 아니라 설계상 의도된 워크플로우이며, 2026년 현재도 동일하다.
⑥ 필터에 따라 동적으로 바뀌는 제목 — DAX 측정값으로 우회해야
대시보드에서 슬라이서(필터) 선택값에 따라 차트 제목이 자동으로 바뀌게 하는 기능은 Power BI에 "동적 제목"이라는 이름의 자체 기능으로 존재하긴 하지만, 실제로는 DAX로 측정값을 만들고 그 측정값을 시각적 개체 제목의 "필드 값" 옵션에 연결하는 방식으로 구현해야 한다. 예를 들어 SELECTEDVALUE 함수로 현재 선택된 필터값을 텍스트로 반환하는 측정값을 만들고, 이를 제목에 바인딩하는 식이다. UI 토글 하나로 끝나지 않고 함수 작성이 선행돼야 한다는 점에서, Tableau의 동적 제목(필드를 텍스트에 직접 드래그해서 삽입하거나 매개변수와 계산된 필드를 결합하는 방식)에 비해 한 단계 더 거쳐야 하는 구조인 것은 사실이다. 다만 Tableau도 매개변수 액션처럼 복잡한 동적 제목을 구현하려면 계산된 필드가 필요한 경우가 있어, "Tableau는 노코드, Power BI는 무조건 코드"라는 이분법은 과장이고, "기본 동작의 진입장벽 차이" 정도로 표현하는 게 정확하다.
5. 결론 — 경영정보시각화능력 실기, 어떤 툴로 준비할까
스펙과 실무 경험을 종합했을 때, 다음 기준으로 판단하는 걸 권한다.
Power BI를 추천하는 경우
- 엑셀, 피벗테이블에 이미 익숙하고 DAX 학습에 대한 거부감이 적은 경우
- 회사/기관이 Microsoft 365 생태계를 이미 쓰고 있어 실무 연계성을 높이고 싶은 경우
- 시험 준비 기간이 짧아 "표준 차트를 빠르게 만드는 손놀림"부터 익히고 싶은 경우
Tableau를 추천하는 경우
- 시각화의 디테일(서식, 색상, 레이아웃, 모양)을 자유롭게 통제하고 싶은 경우
- BI 컨설턴트, 데이터 시각화 전문가로 커리어를 지향하는 경우 — 현재 채용 시장에서 Tableau 숙련도를 명시적으로 요구하는 공고가 여전히 많다
- LOD 표현식처럼 한 번 익히면 응용 범위가 넓은 개념 학습에 투자할 의향이 있는 경우
개인적인 결론을 솔직히 말하면, 두 툴 모두 결국 "데이터를 다루는 사고방식"을 가르쳐준다는 점에서 본질은 같다. 다만 경영정보시각화능력처럼 제한된 시간 안에 시각적 완성도까지 평가받는 실기 시험이라면, 디테일한 서식 컨트롤이 훨씬 직관적인 Tableau 쪽이 실기 준비 효율 면에서 조금 더 유리하다고 본다. 물론 이는 어디까지나 태블로 엔지니어로서의 경험에 기반한 의견이니, 본인의 학습 스타일과 향후 진로 방향을 함께 고려해 선택하길 권한다.
참고 자료
- Power BI 공식 문서(한국어): https://learn.microsoft.com/ko-kr/power-bi/
- Power BI 시각적 개체 로캘 설정: https://learn.microsoft.com/ko-kr/power-bi/developer/visuals/localization
- Power BI 사용자 지정 서식 문자열: https://learn.microsoft.com/ko-kr/power-bi/create-reports/desktop-custom-format-strings
- Power BI 블로그(2025년 10주년 리캡 등): https://powerbi.microsoft.com/ko-kr/blog/