Univer가 Microsoft 365의 완전한 대체재가 아니라, AI 에이전트 기반 문서 자동화 개발을 위한 오픈소스 코어 엔진임을 명확히 구분해야 합니다. 혹시 엑셀 파일 하나 열기 위해 신규 SaaS를 구축하려 고민 중이시라면, 이 글이 현실적인 판단 기준을 제시합니다. Univer는 '도구'가 아니라 '재료를' 제공합니다.
핵심 요약 - Univer는 Microsoft 365 사용자 인터페이스(UI)를 그대로 제공하는 앱이 아닙니다. - AI 에이전트가 스프레드시트/문서를 직접 조작할 수 있는 프로그래매틱 API에 강점이 있습니다. - 자체 UI를 구축하거나 기존 앱에 임베드하는 개발자가 타겟입니다. - 일반 사용자가 바로 설치해 쓸 수 있는 데스크톱 앱은 현재 공식적으로 제한적입니다. - 'AI가 문서를 만든다'는 기능보다 'AI가 문서를 만드는 기반을 제공한다'는 점을 이해해야 합니다.
문제와 배경: 왜 갑자기 Univer가 화두인가?
Q. Microsoft 365 대안이 왜 필요한가?
비용과 데이터 주권 문제 때문입니다. Microsoft 365 구독료는 팀 규모가 커질수록 지출이 비선형적으로 증가합니다. 또한 기업 데이터가 클라우드에 저장되는 것에 대한 보안 우려가 늘고 있습니다. 여기에 AI 트렌드가 겹쳤습니다. 단순한 문서 작성 도구가 아니라, AI 에이전트가 데이터를 분석하고 문서를 생성하는 '작업 공간'을 원하게 된 것입니다.
기존 오피스 스위트들은 AI와 연동하기 위해 외부 API를 호출해야 하는 구조가 많습니다. 반면 Univer는 처음부터 '프로그래머블 오피스'를 목표로 설계되었습니다. 즉, 코드 한 줄로 셀 값을 변경하거나 차트를 생성할 수 있는 구조입니다. 이게 바로 AI 에이전트가 문서 작업을 수행할 수 있는 물리적 기반이 됩니다.
정보획득 갭: 많은 블로그 글들이 Univer를 '무료 엑셀'로 소개합니다. 하지만 Univer는 설치형 앱이 아닌 웹 기반 라이브러리입니다. '설치해서 쓰겠다'는 기대치를 갖고 접근하면 실망합니다.
현재 상황과 확인 가능한 근거
Q. Univer의 기술적 특징은 무엇인가?
Univer는 TypeScript와 Vue 기반의 오픈소스 프로젝트입니다. 스프레드시트, 문서, 슬라이드 편집 기능을 하나의 코어 엔진으로 통합했습니다. 가장 중요한 특징은 'Headless' 모드 지원입니다. UI 없이 순수하게 데이터 모델만 조작할 수 있어, 백엔드 서버나 AI 에이전트가 문서 상태를 직접 제어할 수 있습니다.
GitHub 공개 저장소를 보면, API 문서가 상대적으로 잘 정리되어 있어 개발 진입 장벽이 기존 오픈소스 오피스 대비 낮은 편입니다. 다만, 커뮤니티 활성화 수준은 LibreOffice나 OnlyOffice보다는 아직 초기 단계라는 점은 인지해야 합니다.
| 항목 | Univer | 기존 오픈소스 |
|---|---|---|
| AI 연동성 | 높음 | 낮음 |
| UI 완성도 | 중간 | 높음 |
| 설치 편의성 | 개발자용 | 사용자용 |
Q. 실제 개발 사례는 어디에 있는가?
공식 문서와 GitHub 이슈 트래커를 통해 확인 가능한 사례는 주로 '다크 모드 지원', '셀 병합 기능', '수식 엔진 최적화' 등 개발 단계의 기능 구현입니다. 완성된 SaaS 서비스 사례를 공개적으로 찾기 어려운 것은, Univer가 '플랫폼'이지 '제품'이기 때문입니다. 사용자가 직접 Univer를 웹페이지에 삽입하거나, Univer API를 호출하는 AI 챗봇을 만들어야만 비로소 '서비스'가 됩니다.
이 부분이 일반 사용자 입장에서는 가장 큰 진입 장벽입니다. 'AI가 문서를 만들어주는 앱'을 기대하고 Univer 웹사이트에 접속하면, 코드 에디터와 API 문서만 보게 됩니다.
비유: Univer는 식당(완성된 앱)이 아니라, 주방의 조리 도구 세트(라이브러리)입니다. 셰프(개발자)가 있어야만 요리(서비스)가 나옵니다.
독자에게 중요한 이유
Q. AI 자동화 시대에 이 도구가 왜 핵심인가?
AI 에이전트의 한계는 '생성'이 아니라 '실행'입니다. ChatGPT가 문장을 잘 쓰지만, 그 문장을 엑셀의 특정 셀에 넣거나, 그래프를 수정하는 행동을 직접 수행하지는 못합니다. Univer는 바로 이 '실행' 단계를 코드화할 수 있는 인터페이스를 제공합니다.
만약 독자분들이 'AI가 보고서 초안을 쓰고, 내가 수정해서 최종본을 저장한다'는 워크플로우를 구축하고 싶다면, Univer 기반의 커스텀 도구가 가장 효율적인 경로가 될 수 있습니다. Microsoft 365의 Graph API를 사용할 수도 있지만, 오픈소스 특성상 데이터가 제3자 클라우드를 거치지 않고 로컬 또는 자체 서버에 유지될 수 있다는 점은 데이터 민감도가 높은 기업에겐 결정적 장점입니다.
선택지와 실제 적용 시 고려 사항
Q. Univer를 도입할 때 체크리스트는?
다음 기준을 충족하는 경우에만 Univer 도입을 고려하세요.
- 개발 인력 보유: 최소 1~2명의 프론트엔드/백엔드 개발자가 HTML/JS/TypeScript를 다룰 수 있어야 합니다.
- 커스텀 UI 필요: 표준 오피스 UI가 아니라, 자사 브랜드나 업무 프로세스에 맞춰 화면을 직접 그려야 할 때.
- AI 연동 계획: LLM의 출력 결과를 구조화된 데이터로 변환해 문서에 반영하는 로직을 직접 구현할 의지가 있을 때.
반대로, '지금 당장 엑셀 파일을 열고, AI가 문장을 써주는 챗봇 창이 옆에 있으면 됩니다'라면 Univer는 과잉 엔지니어링입니다. Microsoft 365 Copilot이나 Notion AI, 혹은 기존 SaaS 도구의 유료 플랜이 훨씬 비용-편의성 측면에서 유리합니다.
Q. 라이선스와 유지보수는?
Univer는 AGPLv3 라이선스를 사용합니다. 상업적 SaaS로 서비스할 경우 소스 코드 공개 의무가 발생할 수 있으므로 법률 검토가 필수입니다. MIT 라이선스보다는 제약 조건이 더 많습니다. 또한, 오픈소스 프로젝트 특성상 버그 수정이나 기능 추가는 커뮤니티 의존도가 높습니다. 긴급한 장애 발생 시 공식 지원 SLA(서비스 수준 협약)가 없는 점을 감수해야 합니다.
정리하면: Univer는 '즉시 사용 가능한 도구'가 아니라 'AI 시대의 오피스 인프라'입니다. 개발 리소스가 없다면 도입을 보류하세요.
핵심 요약과 다음 단계
Univer는 Microsoft 365의 단순 대체재가 아닙니다. AI 에이전트가 문서와 스프레드시트를 직접 조작할 수 있게 해주는 오픈소스 코어 엔진입니다.
- 도입 전 질문: '우리는 AI가 문서를 만드는 과정을 코드 단위로 제어해야 하는가?'
- 개발 준비: TypeScript 스택에 익숙한 인력이 있는가?
- 라이선스 확인: AGPLv3의 상업적 제약 조항을 검토했는가?
이 세 질문에 모두 '예'가 아니라면, 기존 SaaS 도구 업그레이드가 더 합리적입니다. Univer는 장기적인 AI 업무 자동화 전략의 일환으로, 작은 프로젝트(예: 내부 데이터 대시보드용 스프레드시트 뷰어)부터 점진적으로 테스트해 보는 것을 권장합니다.
탭을 닫고 남는 한 줄: AI는 생각하지만, Univer는 움직이게 한다.
자주 묻는 질문
Q. Univer는 무료인가요? A. 코어 라이브러리는 오픈소스(AGPLv3)라 무료입니다. 하지만 이를 앱으로 만들어 배포하려면 개발 비용과 라이선스 준수 비용이 발생합니다.
Q. Microsoft 365 파일(.xlsx,.docx)을 완벽히 지원하나요? A. 기본 형식 입출력은 지원하지만, 복잡한 수식이나 매크로, 특수 서식 요소의 호환성은 Microsoft 365보다 낮을 수 있습니다. 크리티컬한 업무에서는 반드시 파일 호환성 테스트를 진행해야 합니다.
Q. AI 에이전트 연동 예제가 있나요? A. 공식 레포지토리에 샘플 코드(Starter Kit)가 제공되며, LangChain이나 LlamaIndex와 같은 프레임워크를 통해 LLM과 연동하는 커뮤니티 가이드를 참고할 수 있습니다.
Q. 모바일 앱으로 쓸 수 있나요? A. 웹 기반 라이브러리이므로 모바일 웹에서는 사용할 수 있으나, 네이티브 모바일 앱(아이폰/안드로이드)으로의 직접적인 배포 사례는 공식적으로 제한적입니다. PWA(Progressive Web App) 형태로 적용하는 것이 일반적입니다.
Q. 데이터는 어디에 저장되나요? A. Univer 자체는 데이터베이스가 아닙니다. 개발자가 MySQL, PostgreSQL, MongoDB 등 원하는 DB에 연결해 데이터 저장을 구현해야 합니다. 즉, 데이터 주권은 개발자의 아키텍처 설계에 달려 있습니다.
여러분은 현재 업무에서 AI를 문서 작업의 어떤 단계에 활용하고 계신가요? 초안 작성, 데이터 분석, 아니면 최종 검토?
출처:
댓글