Codex가 LibreOffice를 번들하는 이유와 한계
Codex의 문서 기능은 파일 생성에 그치지 않는다. DOCX를 PDF나 이미지로 변환해 결과가 올바르게 표시되는지도 확인해야 한다. 이를 위해 Documents 플러그인은 화면 없이 문서를 처리하는 LibreOffice의 soffice 실행 파일을 런타임에 포함한다.
이 방식은 별도 설치 없이 일관된 도구를 사용할 수 있다는 장점이 있다. 그러나 실행 파일을 번들했다고 해서 외부 환경으로부터 완전히 독립되는 것은 아니다.
번들 LibreOfficeDev가 우선되는 구조
Documents 플러그인은 시스템에 설치된 LibreOffice보다 번들된 LibreOfficeDev를 우선 사용한다. macOS에서 관찰된 번들 버전은 26.8.0.0.alpha0이며, 사용자가 설치한 안정판 LibreOffice 26.2.4.2보다 먼저 선택된 사례가 보고됐다.1
번들 soffice의 위치는 다음과 같다.1
~/.cache/codex-runtimes/codex-primary-runtime/dependencies/bin/sofficeCodex는 이처럼 실행 경로와 버전을 통제해 문서 변환 환경을 일정하게 유지할 수 있다. 반면 번들 빌드에 문제가 생기면, 사용자가 정상 작동하는 시스템 LibreOffice를 설치해 두었더라도 이를 대신 사용하기 어렵다.
번들링만으로 이식성이 보장되지는 않는다
macOS용 번들 LibreOfficeDev가 /opt/homebrew 아래의 동적 라이브러리를 요구해 실행되지 않는 문제도 보고됐다. 누락된 의존성에는 little-cms2의 liblcms2.2.dylib가 포함됐으며, 번들 libvcllo.dylib는 fontconfig의 libfontconfig.1.dylib와 freetype의 libfreetype.6.dylib에도 연결돼 있었다.2
해당 경로와 라이브러리가 없는 Mac에서는 soffice가 시작되지 않을 수 있다. Codex를 재설치하고 런타임 캐시를 다시 생성해도 절대 Homebrew 경로가 유지된 사례가 보고됐다.2 이 경우 문서 변환과 시각적 렌더링을 통한 품질 검사가 실패할 수 있다.
핵심은 번들링이 단순히 실행 파일을 함께 배포하는 작업이 아니라는 점이다. 필요한 라이브러리까지 포함하고, 특정 패키지 관리자나 로컬 경로에 대한 의존성을 제거해야 재현성과 이식성을 확보할 수 있다.
사용자가 확인할 실전 기준
Codex에서 문서 변환 문제가 발생한다면 다음 순서로 범위를 좁힐 수 있다.
번들
soffice --version이 정상적으로 실행되는지 확인한다.같은 문서를 PDF로 변환할 수 있는지 테스트한다.
변환 결과를 이미지로 렌더링할 수 있는지 확인한다.
시스템 LibreOffice는 작동하지만 번들 버전만 실패하는지 비교한다.
캐시 수정은 업데이트나 런타임 재생성 때 사라질 수 있으므로 임시 대응으로만 취급한다.1
요약
Codex가 LibreOffice를 번들하는 것은 일관된 문서 자동화 환경을 제공하기 위한 합리적인 선택이다. 다만 진정한 이식성을 확보하려면 번들 버전의 안정성, 외부 라이브러리 의존성 제거, 시스템 LibreOffice를 선택할 수 있는 대안까지 함께 고려해야 한다.
1Allow Documents plugin to use system LibreOffice instead of bundled LibreOfficeDev #27797
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.