엑셀, 여전히 1위 셀프서비스 분석 도구… 이제는 문제가 아니다.

Source: Dev.to

엑셀은 여전히 #1 셀프‑서비스 분석 도구다. 이제는 이것이 문제가 되지 않는 이유

귀사는 방금 Tableau 라이선스를 갱신했습니다. 분석가들은 데이터를 엑셀로 내보냈습니다.
이 장면은 전 세계 거의 모든 기업 분석 부서에서 매일 일어나고 있습니다. 그럼에도 불구하고 IT 리더들은 BI 플랫폼, 교육 프로그램, 데이터 거버넌스 이니셔티브에 계속 자금을 투입하고 있습니다 — 한편 비즈니스 사용자는 조용히 스프레드시트를 열고 있습니다.
이는 실패가 아니라 신호이며, 그 의미를 이해하는 것이 실제로 사람들이 사용하는 분석 스택을 구축하는 열쇠입니다.

셀프‑서비스 분석이란 데이터 엔지니어나 BI 개발자가 아니라 비즈니스 사용자가 티켓을 IT에 제출하지 않고도 독립적으로 데이터에 접근·탐색·분석할 수 있는 능력을 말합니다.

시장은 이를 눈여겨보고 있습니다. 분석가들은 2024년 전 세계 셀프‑서비스 분석 시장 규모가 약 5060억 달러였으며, 연평균 성장률(CAGR) 약 16%로 2030년 초에는 170270억 달러에 이를 수 있다고 추정합니다. 성장 자체는 현실이지만, 현장의 상황은 보다 미묘합니다.

CTO와 IT 디렉터에게 셀프‑서비스의 약속은 매력적입니다: 병목 현상 감소, 의사결정 가속화, 데이터 팀 의존도 감소. 문제는 그 약속을 실현하면서 그림자 보고서와 단절된 데이터 소스라는 혼란을 만들지 않는 것입니다.

셀프‑서비스 영역에서 경쟁하면서도 공존하는 도구는 크게 다섯 가지 범주로 나뉩니다:

• 스프레드시트(Excel, Google Sheets) — 원조 셀프‑서비스 레이어. 모든 비즈니스 사용자가 이미 익숙합니다.
• 모던 BI 플랫폼(Power BI, Tableau, Looker) — 시각화 중심 도구로 강력한 거버넌스 기능과 AI 기능이 성장하고 있습니다.
• 임베디드 분석(Metabase, Redash) — 가볍고 종종 오픈소스이며 애플리케이션에 내장됩니다.
• 헤드리스 BI / 시맨틱 레이어(dbt Metrics, Cube.dev) — 시각화와 무관하게 비즈니스 로직을 코드‑first 방식으로 정의합니다.
• OLAP 서버(Microsoft Analysis Services, XLTable) — 전통적·현대적 큐브 기반 엔진으로 데이터베이스와 분석 클라이언트 사이에 위치합니다.

각 카테고리마다 확실한 강점이 있습니다. 문제는 조직이 이들을 경쟁 관계로만 보면서 실제로는 상호 보완적인 존재라는 점을 놓친다는 것입니다.

솔직히 말하자면, 엑셀은 사라지지 않을 겁니다. 전 세계 2억 명 이상의 기업 사용자가 Microsoft 365 라이선스를 보유하고 있으며, 미국만 해도 130만 개 이상의 기업이 사용하고 있습니다. LinkedIn에서 기업 전문가가 가장 많이 선언하는 스킬이며, 직무에 따라 17%에서 32%까지 침투율을 보입니다.

그럼에도 기업 IT에서는 엑셀이 ‘레거시 도구’—‘진짜’ 분석 플랫폼에 제대로 교육받지 못한 사용자를 위한 지팡이—라고 말합니다. 이 프레이밍은 잘못됐으며, 비용이 많이 드는 실수를 초래하고 있습니다.

임원들은 월요일 아침 모델을 Tableau로 만들지 않습니다. 엑셀을 사용합니다. 이는 교육 문제라기보다 제품‑시장 적합성 신호입니다.

엑셀의 지속성은 관성 때문이 아니라 통제 때문입니다. 엑셀 피벗 테이블은 재무 이사가 회의 중에 실시간으로 조작할 수 있어 대시보드 개발자에 대한 의존도가 없습니다. 인지적 부담은 거의 없고, 유연성은 거의 무한합니다.

엑셀 자체가 문제인 것이 아니라 데이터 공급이 문제입니다.

분석가가 Snowflake나 ClickHouse에서 CSV로 내보낸 뒤 엑셀에 가져오면 두 가지 문제가 발생합니다:

1. 파일에 도착하는 순간 데이터가 시들합니다.
2. 분석가는 수동 ETL 파이프라인이 됩니다—본래 역할이 아닌 작업을 수행하게 되는 것이죠.

여기서 아키텍처 논의가 바뀌어야 합니다. 질문은 “어떻게 사용자를 엑셀에서 끌어내릴까?”가 아니라 “엑셀에 실시간·거버넌스된 연결을 어떻게 제공할까?”입니다.

답은 수십 년 전부터 존재했습니다—XMLA입니다. Microsoft가 바로 이 시나리오를 위해 만든 프로토콜로, 엑셀 피벗 테이블을 표준화된 인터페이스를 통해 분석 데이터베이스에 연결합니다. Analysis Services가 사용했고, Power BI도 사용합니다. 현대 OLAP 서버는 ClickHouse, Snowflake, BigQuery, StarRocks, Databricks 등 어떤 백엔드에도 XMLA를 노출할 수 있습니다.

올바르게 모델링된 OLAP 큐브에 엑셀을 연결하면 동시에 여러 변화가 일어납니다:

• 사용자는 실시간 데이터를 받으며, 내보내기가 필요 없습니다.
• 비즈니스 로직(측정값, 계층, 접근 규칙)은 시맨틱 레이어에 한 번만 정의됩니다.
• 재무 부서는 엑셀에 머무르고, IT는 데이터를 통제합니다.
• 최종 사용자는 SQL이 필요 없으며, 좌석당 BI 라이선스도 필요 없습니다.

대부분의 분석 인프라 검토는 잘못된 질문에 초점을 맞춥니다: “어떤 BI 도구를 표준화할까?” 보다 아래와 같은 질문이 더 유용합니다:

• 데이터는 실제 어디에서 소비되는가? 대시보드가 아니라 스프레드시트를 따라가 보세요.
• 내보내기‑가져오기 루프의 총 비용은? 라이선스 비용만이 아니라 분석가의 시간도 포함하세요.
• 시맨틱 레이어가 있는가? 비즈니스 로직이 보고서에 흩어져 있다면, 도구와 무관하게 거버넌스 문제가 존재합니다.
• 우리 스택이 기술 사용자와 비기술 사용자를 동일한 진실의 원천에서 서비스할 수 있는가? “아니오”라면 두 개의 평행 데이터 문화가 유지되고 있는 겁니다.
• BI 투자 도입률은? 30% 미만이면 도구 자체가 답이 아닙니다.

현대 분석 스택은 엑셀과 BI 중 하나를 선택할 필요가 없습니다. 데이터 레이어가 제대로 설계된다면 두 가지를 모두 지원할 수 있습니다.

아래는 사용자가 신뢰하는 도구를 포기하게 하지 않으면서 엑셀 패러독스를 해결하는 실용적인 아키텍처입니다:

1. 분석 데이터베이스 위에 시맨틱 레이어를 구축하고, 측정값·차원·계층·접근 규칙을 한 번 정의합니다.
2. 그 레이어를 XMLA로 노출해 엑셀이 플러그인·확장 없이 네이티브 연결하도록 합니다.
3. 대시보드·알림·공유 뷰는 BI 도구에 맡깁니다—이 분야에선 뛰어납니다.
4. 엑셀은 즉석 분석·재무 모델링·경영 보고에 전념하게 합니다.

그 결과 데이터 거버넌스와 사용자 자유가 충돌하지 않는 스택이 완성됩니다. IT는 모델을 소유하고, 비즈니스는 분석을 소유합니다.

AI 챗 인터페이스가 엑셀과 BI 도구를 완전히 대체한다는 이야기가 늘어나고 있습니다. 사용자는 이미 ChatGPT에 대시보드를 요청하고 정적 차트를 받기도 합니다. CTO가 묻는 질문은 “구조화된 분석의 종말인가?” 입니다.

솔직히 말하면, AI 챗과 엑셀은 같은 일을 두고 경쟁하지 않습니다.

AI 챗 인터페이스는 한 번의 질문에 빠르게 답변하는 데 강점이 있습니다. “지난 분기 최고의 실적을 낸 지역은 어디인가?” 같은 질문은 채팅창에서 바로 해결됩니다. 하지만 그 답변을 반복 가능하고, 감사 가능하며, 부서 간 일관성을 유지하고, 매일 업데이트되는 데이터와 연결해야 할 때는 챗만으로는 부족합니다.

그 이유는 다음과 같습니다:

• 데이터가 실시간이 아니다. 사용자는 어제의 CSV를 업로드하고, 내일은 새로운 파일을 업로드합니다. 내보내기‑가져오기 루프가 이메일에서 채팅으로 옮겨가도 여전히 루프입니다.
• 단일 진실의 원천이 없다. 각 직원이 자신의 데이터에서 답을 얻어 재무와 영업이 같은 지표에 대해 다른 수치를 제시합니다.
• 감사 추적이 없다. CFO는 추적 가능성 없이 언어 모델이 만든 보고서를 승인할 수 없습니다.
• 보안 문제—대부분의 기업 데이터 거버넌스 정책은 민감한 비즈니스 데이터를 외부 AI 제공업체에 전송하는 것을 금지합니다.

AI 챗은 일회성 질문을 위한 인터페이스이고, 엑셀·BI는 **반복 가능하고, 거버