문서 처리 도구를 하나로 묶은 xberg, HWP부터 OCR·RAG까지 다뤄요

문서 처리 도구를 하나로 묶은 xberg, HWP부터 OCR·RAG까지 다뤄요

IT & AI 뉴스 썸네일

PDF 파서, OCR, 표 추출기, 음성 전사 도구를 따로 연결하다 보면 입력 형식이 하나 늘 때마다 관리할 코드도 함께 늘어요. xberg는 여러 문서 처리 단계를 Rust 기반 코어에 모으고, 같은 결과 형식으로 꺼내 쓰게 만든 오픈소스 프레임워크예요. 1

핵심 요약

구분	내용
입력	PDF, 오피스 문서, 이미지, 오디오, URL, 압축 파일, 소스 트리를 처리해요.
출력	일반 텍스트, Markdown, Djot, HTML, JSON 트리와 구조화 결과를 지원해요.
문서 분석	OCR, 표·레이아웃 복원, 메타데이터 추출, 음성 전사를 한 도구에서 선택할 수 있어요.
개발 연동	라이브러리, CLI, REST API, MCP 서버, Docker와 Helm 형태로 연결할 수 있어요.
주의할 점	URL 수집이나 전사 같은 기능은 빌드 옵션과 배포 패키지에 따라 제공 범위가 달라요.

1. xberg는 문서 입력부터 검색 준비까지 한 코어에서 처리해요

xberg는 파일 형식을 감지한 뒤 텍스트, 표, 이미지, 메타데이터를 추출해요. 스캔 이미지에는 Tesseract, PaddleOCR, Candle 또는 비전 모델 기반 OCR을 붙일 수 있어요. 표가 있는 문서에는 레이아웃 모델과 표 구조 모델을 사용해 읽기 순서와 셀 구조를 복원해요. 공식 저장소의 현재 README는 100개 문서 형식과 120개 확장자를 안내하고, GitHub 저장소 설명은 101개 형식과 115개 확장자로 표기해요. 숫자가 서로 달라 실제 도입 전에는 설치할 버전의 지원 목록을 확인하는 편이 안전해요. 2

한글 문서도 범위에 들어가요. `.hwp`와 `.hwpx`에서 텍스트를 추출할 수 있어 국내 문서 보관함이나 사내 지식 검색을 만들 때 별도 변환 단계를 줄일 수 있어요. 다만 공식 기능표는 두 형식에 대해 텍스트 추출을 명시해요. 복잡한 배치, 도형, 수식까지 원본 모양 그대로 복원한다고 해석하면 안 돼요.

728x90

소스 코드에는 tree-sitter 기반 분석을 적용해요. 공식 문서는 371개 프로그래밍 언어에서 함수, 클래스, 임포트, 심볼과 독스트링을 뽑을 수 있다고 설명해요. 문법 경계를 고려한 청킹도 제공해 코드 검색이나 RAG 색인을 만들 때 단순 글자 수 분할보다 구조를 보존하기 쉬워요.

입력이 달라도 후속 처리를 맞추기 쉬워요

문서 자동화에서 번거로운 지점은 파서마다 결과 모양이 다르다는 점이에요. PDF 파서는 페이지 좌표를 주고, 스프레드시트 도구는 셀 배열을 주며, OCR은 텍스트 조각과 신뢰도를 돌려줘요. xberg는 이런 입력을 텍스트, 표, 메타데이터와 구조화 결과로 정리해 후속 코드가 입력 형식마다 크게 갈라지는 문제를 줄여요.

출력은 일반 텍스트와 Markdown뿐 아니라 Djot, HTML, JSON 트리도 지원해요. 문서에서 정해진 스키마의 JSON을 뽑는 기능은 Ollama, LM Studio, vLLM 같은 로컬 실행 환경이나 외부 LLM과 연결할 수 있어요. 이름, 날짜, 금액처럼 필드가 정해진 계약서나 신청서를 처리할 때 활용하기 좋아요.

웹과 오디오도 같은 흐름에 넣을 수 있어요

URL을 입력하면 한 페이지를 문서처럼 추출하거나 링크를 따라 수집할 수 있어요. Auto, Document, Crawl 모드를 제공하고 웹 수집에는 crawlberg 엔진을 사용해요. 오디오와 영상의 음성 트랙은 Whisper ONNX로 전사할 수 있어요. MP3, M4A, WAV, WebM과 MP4 같은 형식이 지원 목록에 들어가요.

이 기능들은 모두 기본 빌드에 자동으로 들어가는 것은 아니에요. 공식 README는 URL 수집과 음성 전사, 일부 레이아웃·재정렬 기능을 Cargo feature로 구분해요. 미리 빌드된 언어 패키지와 Docker 이미지는 흔히 쓰는 기능을 묶어 제공하지만, 소스에서 직접 빌드하면 필요한 옵션을 골라야 해요. 설치는 됐는데 특정 기능이 보이지 않는다면 해당 feature와 패키지 구성을 먼저 확인해야 해요.

왜 중요한가요

문서 기반 검색이나 AI 서비스를 만들 때 모델보다 앞단의 입력 정리가 더 많은 시간을 쓰기도 해요. PDF, 이메일, 스프레드시트, 이미지마다 다른 라이브러리를 붙이면 오류 처리와 버전 관리 지점도 늘어요. xberg처럼 공통 인터페이스를 둔 도구는 파일 감지, 추출, 청킹, 임베딩으로 이어지는 경로를 한곳에서 관리하게 해요. 2

연동 방식도 넓어요. Rust 코어를 Python, Node.js, Go, Java, C#, Ruby 등 여러 언어에서 호출할 수 있어요. CLI에는 추출, 배치 처리, 형식 감지, 캐시, 임베딩과 청킹 명령이 있고, `xberg serve`로 REST API를 열거나 MCP 서버로 연결할 수도 있어요. 기존 서비스에는 API로 붙이고, 데스크톱 AI 도구에는 MCP로 연결하는 식으로 같은 엔진을 재사용할 수 있어요.

도입 판단에는 세 가지를 직접 시험해 보는 게 좋아요. 첫째, 실제 보유 문서에서 표와 읽기 순서가 얼마나 잘 복원되는지 봐야 해요. 둘째, HWP처럼 중요한 형식은 텍스트 추출 범위가 업무 요구에 맞는지 확인해야 해요. 셋째, OCR과 전사 모델을 켰을 때 필요한 메모리, 처리 시간, 외부 모델 비용을 재야 해요. 지원 형식의 개수보다 자주 쓰는 문서 20~30개로 작은 평가 세트를 만드는 편이 더 정확해요.

프로젝트는 MIT 라이선스를 사용해요. 그래도 외부 OCR 모델, 호스팅 LLM, 임베딩 제공자를 함께 쓰면 각 구성 요소의 라이선스와 데이터 전송 조건은 별도로 확인해야 해요. 개인정보가 든 문서를 다룬다면 로컬 처리 여부와 PII 마스킹 순서도 배포 전에 정하는 게 좋아요.

참고 자료

1. xberg - 다국어 문서 인텔리전스 프레임워크 — GeekNews
2. xberg-io/xberg — GitHub 공식 저장소