ChatGPT 데스크톱 앱 캐시에 headless LibreOffice 등 1.7GB 런타임 확인
- Simon Willison은 macOS의
~/.cache/codex-runtimes/codex-primary-runtime에서 1.7GB 크기의 ChatGPT, 구 Codex 런타임을 발견함 - 런타임에는 headless LibreOffice가 약 429.7MB 들어 있으며, Poppler 187.9MB, Git 148.1MB, Node.js 446.4MB, Python 440.6MB도 함께 확인됨
plugins/openai-primary-runtime/plugins/documents아래의 skills가 이 바이너리들을 찾고 사용하는 방법을 Codex에 지시함- HN에서는 스크린샷 경로가
libreoffice-headless이므로 "LibreOffice 전체본"이라는 제목은 부정확할 수 있다는 지적이 나옴 - 토론 참가자들은 LibreOffice가 오래된 XLS와 Office 문서를 안정적으로 읽고 변환하는 드문 선택지라고 평가했으며, 설치 패키지 포함인지 필요 시 다운로드인지와 MPL 2.0 라이선스 고지도 확인이 필요하다고 봄
Hacker News opinions
LibreOffice로 MS Office 문서를 렌더링하고 수정하는 거라면 일부 파일이 깨지는 이유도 설명됨. 그래도 통째로 넣기에는 의존성이 너무 큼.
대안 라이브러리가 뭔지 되묻고 싶음. 내 Docker 이미지도 결국 LibreOffice를 넣었고, GUI 없는 버전으로 줄이긴 했음.
스크린샷 경로는 libreoffice-headless라고 되어 있음. 제목의 "전체 LibreOffice"는 부정확할 수 있음.
나는 Codex가 만든 파일을 Mac용 Microsoft Office로 열어 렌더링을 확인하는 스킬을 씀. LibreOffice는 여는 OOXML을 Office가 거부하는 경우도 있어서 둘 다 확인해야 했음.
Rust로 다시 만들거나 네이티브 앱으로 만들면 이런 2GB짜리 앱은 피할 수 있지 않나 싶음. Poppler나 Office 형식을 다루는 빠른 크로스플랫폼 라이브러리도 있는데.
Rust라고 자동으로 낫다는 근거는 없음. 그리고 토큰 응답을 기다리는 시간에 비하면 앱 시작이나 런타임 크기가 우선순위가 아닐 가능성이 큼.
Word나 Google Docs 자동화는 생각보다 훨씬 막혀 있음. 직접 해보면 LibreOffice 말고는 파일을 안정적으로 읽고 처리할 대안이 거의 없어서, 결국 그걸로 제품을 냈음.
이건 문제 제기라기보다 흥미로운 관찰 같음. 그런데 HN 제출 제목은 headless라는 작은 사실을 빼서 오해를 만듦.
처음부터 앱에 포함한 건지, 문서 작업이 처음 필요할 때 내려받은 건지는 아직 모름. 새로 설치한 환경에서 캐시 생성 시점을 확인해야 함.
해시로 고정한 컴포넌트를 필요할 때 내려받아도 보안상 불리할 건 없음. 다만 설치 시점에 저장 공간 부족을 드러내려는 운영 방식일 수는 있음.
Codex로 Word 파일을 읽고 고칠 때 추론 로그에 LibreOffice가 자주 보여서 납득됨. docx와 xlsx를 빨리 다루기 위한 인터페이스였을 듯.
나도 특히 오래된 xls 파일을 읽으려고 앱에 LibreOffice를 넣었음. 그냥 어떤 파일을 넣어도 읽힐 거라는 신뢰를 주는 대체재를 못 찾았음.
Codex 앱의 오픈소스 라이선스 목록에서 LibreOffice 언급을 못 찾았음. 설치 패키지에 함께 배포한다면 MPL 2.0 의무가 있는지 궁금함.
사용자가 이미 설치한 바이너리를 먼저 찾아 쓰지 않고 내려받는 이유가 궁금함. 그냥 대충 바이브 코딩한 결과 같기도 함.
AI가 Office 문서를 생성하고 갱신하는 일이 보편화되면 Microsoft Office는 결국 뷰어가 될 수도 있음.