Silurus OOXML, AI 코딩 산물의 실전 기준
AI가 코드를 썼다는 사실만으로는 제품성이 생기지 않는다. 복잡한 문서 포맷을 다루려면 테스트, 번들 크기, 헤드리스 API처럼 사람이 검증할 구조가 필요하다.
AI 뉴스를 놓치지 마세요
매주 핵심 AI 소식을 이메일로 받아보세요.
브라우저 문서 렌더러가 AI 코딩 논쟁의 좋은 샘플인 이유
Silurus의 office-open-xml-viewer는 DOCX, XLSX, PPTX를 브라우저에서 HTML Canvas로 렌더링하는 오픈소스 프로젝트다. README는 Rust 파서, WebAssembly 빌드, TypeScript 렌더러, Canvas 2D API, 헤드리스 엔진을 함께 설명한다. 또한 전체 코드가 Claude와의 반복 프롬프팅으로 구현됐다고 밝힌다. 그래서 이 프로젝트는 "AI가 코드를 썼다"는 구호보다 더 흥미롭다. 복잡한 포맷을 실제로 다루는 산출물이기 때문이다.
문서 렌더링은 데모 앱보다 훨씬 까다롭다. Office Open XML은 ZIP 구조, XML 파트, 스타일 상속, 표, 차트, 수식, 슬라이드 레이아웃이 얽힌다. Microsoft Open XML SDK 문서는 이 포맷을 다루기 위한 강한 타입 API를 제공할 정도로 복잡성이 높다. 이런 영역에서 AI 코딩의 가치는 생성 속도보다 유지보수 가능한 경계 설정에서 나온다.
구조는 꽤 현실적이다
프로젝트는 파서를 Rust로 작성해 WebAssembly로 컴파일하고, 브라우저 런타임에서는 Canvas에 그리는 방식을 택한다. MDN WebAssembly 문서는 WASM이 웹에서 네이티브에 가까운 계산 코드를 실행하게 해준다고 설명한다. MDN Canvas API는 픽셀 단위 렌더링에 적합하다. 문서 포맷 파싱과 화면 그리기를 분리한 선택은 합리적이다.
| 항목 | 일반 웹 뷰어 | Silurus 접근 |
|---|---|---|
| 파싱 | JS 중심 | Rust 파서와 WASM |
| 렌더링 | DOM 또는 iframe 의존 | Canvas 2D |
| 통합 방식 | 내장 UI 중심 | 헤드리스 엔진 제공 |
| 리스크 | 브라우저 호환성 | 포맷 정확도와 WASM 번들 |
| AI 코딩 검증 | 생성 결과 확인 | 테스트와 API 경계 확인 |
README는 MathJax와 STIX Two Math를 쓰는 수식 엔진을 별도 entry로 분리해 약 3MB 부담을 opt-in으로 만든다고 설명한다. MathJax 같은 성숙한 외부 엔진을 선택적으로 붙이는 방식은 AI 생성 코드가 흔히 저지르는 "모든 것을 한 번에 묶기"를 피한다.
AI가 만든 코드라면 더 엄격한 경계가 필요하다
AI 생성 코드의 약점은 첫 구현보다 장기 구조에서 드러난다. 비슷한 함수가 늘어나고, 테스트가 데모 입력에만 맞고, 에러 처리가 흩어진다. 지루한 언어가 AI 코딩에 강한 이유는 예측 가능한 타입과 생태계가 에이전트 코드 품질에 유리하다고 봤다. Silurus도 Rust, TypeScript, Storybook, smoke tests를 통해 비슷한 안전장치를 둔다.
이 프로젝트의 관전 포인트는 "AI가 전부 만들었다"가 아니다. 사람이 AI에게 어떤 인터페이스를 요구했고, 결과를 어떤 테스트로 붙잡았는지다. Zot, 코딩 에이전트 하네스가 제품이 되는 이유에서 말했듯 에이전트 시대의 핵심은 생성기가 아니라 검증 하네스다. 복잡한 문서 포맷은 픽셀 정확도, 회귀 파일, 렌더링 시간, 번들 크기를 계속 측정해야 한다.
한국 SaaS와 문서 업무 자동화의 기회
한국 기업 업무는 여전히 문서 중심이다. 전자결재, 계약서, 제안서, 엑셀 보고서, 교육 자료가 모두 자동화 대상이다. 하지만 서버에 문서를 업로드해야 하는 뷰어는 개인정보와 망분리 문제에 걸린다. 브라우저에서 로컬로 파싱하고 렌더링하는 방식은 보안팀이 받아들이기 쉽다. ktx, 데이터 에이전트에 컨텍스트 계층을 붙이다에서 다룬 데이터 계층과도 결합될 수 있다.
다만 국내 도입에는 한글 글꼴, 표 레이아웃, 메모, 추적 변경, 보안 문서, 대용량 파일 같은 현실 문제가 남는다. tiny-vLLM, 추론 엔진을 직접 짜야 보이는 병목처럼 내부 구현을 이해해야 병목을 잡을 수 있다. 문서 AI 에이전트도 마찬가지다. 문서 내용을 요약하기 전에 문서를 정확히 보는 렌더러가 필요하다.
자주 묻는 질문
Q1: 이 프로젝트의 핵심 기능은 무엇인가요?
A: DOCX, XLSX, PPTX를 브라우저에서 Canvas로 렌더링하고, 앱이 자체 UI를 붙일 수 있는 헤드리스 엔진을 제공하는 것이다.
Q2: AI가 작성했다는 점이 곧 품질을 보장하나요?
A: 아니다. 품질은 테스트, API 설계, 포맷 정확도, 번들 관리로 판단해야 한다.
Q3: WebAssembly를 쓰는 이유는 무엇인가요?
A: 복잡한 파싱 로직을 Rust로 작성하고 브라우저에서 실행하기 위해서다. 성능과 타입 안정성 측면에서 장점이 있다.
Q4: 기업 도입 시 가장 큰 위험은 무엇인가요?
A: 특정 문서 샘플에서는 잘 보여도 실제 업무 문서의 스타일, 표, 수식, 글꼴에서 깨질 수 있다는 점이다.
Q5: 한국 시장에서는 어디에 쓸 수 있나요?
A: 문서중앙화, 전자결재 미리보기, 로컬 문서 요약, 브라우저 기반 교육 콘텐츠 제작에 연결할 수 있다.
관련 토픽 더 보기
📰 원본 출처
github.com이 기사는 AI 기술을 활용하여 작성되었으며, 원본 뉴스 소스를 기반으로 분석 및 해설을 추가한 콘텐츠입니다. 정확한 정보 전달을 위해 노력하고 있으나, 원본 기사를 함께 확인하시기를 권장합니다.