Codex가 LibreOffice를 품은 이유

1.7GB 캐시는 작은 발견이 아니다

Simon Willison의 기록은 짧지만 의미가 크다. 그는 macOS의 디스크 사용량 도구인 OmniDiskSweeper를 보다가 OpenAI Codex 데스크톱 앱, 현재는 ChatGPT 앱으로 리브랜딩된 앱의 캐시에 약 1.7GB 규모의 codex-primary-runtime 폴더가 있는 것을 발견했다. 그 안에는 Python, Node.js, Poppler, git, 그리고 LibreOffice headless 바이너리가 포함돼 있었다.

이 사실은 "앱이 왜 이렇게 크냐"는 불평으로 끝나지 않는다. 문서 에이전트가 실제 업무를 하려면 PDF, DOCX, PPTX, XLSX, 이미지, 코드 저장소를 다뤄야 한다. 모델이 텍스트를 잘 생성해도 파일을 열고 변환하고 구조화하지 못하면 업무 도구가 되기 어렵다. 그래서 프런티어 앱은 점점 작은 운영체제처럼 변한다.

Accept: text/markdown, 에이전트 웹의 작은 계약은 에이전트가 웹과 문서를 다루기 위해 명시적 포맷 계약이 필요하다고 봤다. 이번 사례는 그 계약의 로컬 버전이다. 앱이 문서를 이해하려면 로컬에 믿을 만한 변환 도구가 있어야 한다.

LibreOffice와 Poppler는 에이전트의 손이다

LibreOffice는 OpenOffice.org에서 갈라져 나온 오픈소스 오피스 제품군이다. GUI 앱으로 익숙하지만 서버와 자동화 환경에서는 headless 모드로 문서 변환에 자주 쓰인다. Poppler는 PDF 렌더링과 텍스트 추출에 널리 쓰이는 라이브러리다. Codex 런타임에 이들이 포함됐다는 것은 에이전트가 단순한 텍스트 챗봇이 아니라 문서 변환 파이프라인을 로컬에서 실행하도록 설계됐다는 뜻이다.

OpenAI 도움말은 Codex 데스크톱 앱이 ChatGPT 데스크톱 앱으로 이동하는 흐름을 설명한다. 브랜드가 바뀌어도 핵심은 같다. 사용자는 파일을 던지고, 모델은 그 파일을 읽고, 필요하면 변환하고, 결과물을 다시 만든다. 이를 안정적으로 하려면 검증된 네이티브 도구가 필요하다.

로컬 번들링은 보안과 재현성의 선택이다

앱이 사용자 머신에 도구를 포함하면 용량은 커진다. 그러나 장점도 분명하다. 사용자의 PATH나 시스템 설치 상태에 덜 의존하고, 버전을 고정할 수 있으며, 네트워크 없이도 일정 작업을 수행할 수 있다. 문서 변환처럼 파일 포맷과 운영체제 차이에 민감한 작업에서는 재현성이 제품 품질을 좌우한다.

보안 관점도 중요하다. 문서를 외부 서버로 보내 변환하면 개인정보와 기업 기밀 문제가 생긴다. 로컬에서 변환하고 필요한 결과만 모델 컨텍스트로 전달하면 위험을 줄일 수 있다. 물론 로컬 바이너리 번들 자체도 업데이트, 취약점 패치, 서명 검증이 필요하다. 추론 엔진 취약점, LLM이 자기 실행 호스트를 노릴 수 있다에서 보았듯, AI 런타임은 새로운 공격면이 될 수 있다.

한국 기업의 내부망 환경에서는 이 선택이 더 중요하다. 외부 패키지 설치가 막혀 있거나, 문서 반출이 제한되거나, 보안 솔루션이 프로세스 실행을 감시하는 경우가 많다. AI 앱이 자체 런타임을 갖추면 초기 사용성은 좋아지지만, 보안팀은 그 런타임의 구성품과 업데이트 정책을 요구하게 된다.

모델 제품은 이제 배포 공학이다

2023년의 AI 제품은 좋은 모델 API를 연결하고 UI를 붙이는 방식으로 빠르게 만들 수 있었다. 2026년의 업무용 AI 제품은 다르다. 파일 변환, 권한, 샌드박스, 캐시, 네이티브 의존성, 문서 보존 정책, 로컬 인덱스까지 묶어야 한다. 모델 능력이 올라갈수록 사용자는 더 지저분한 실제 파일을 맡긴다. 그때 실패하면 모델이 똑똑해도 제품은 실패한다.

자가호스팅 에이전트 공장, 격리가 제품력이다는 에이전트 실행 환경의 격리와 운영이 경쟁력이 된다고 분석했다. Codex 런타임의 1.7GB 캐시도 같은 메시지다. 에이전트 제품의 핵심은 모델 호출 한 줄이 아니라, 모델이 안전하게 사용할 도구 상자를 어떻게 배포하느냐에 있다.

개발자와 기업이 확인해야 할 것

개발자는 이런 번들링을 무조건 부정적으로 볼 필요가 없다. 오히려 문서 자동화가 필요한 앱을 만든다면 LibreOffice, Poppler, pandoc, OCR 도구 같은 검증된 오픈소스 조합을 어떻게 패키징할지 먼저 생각해야 한다. 직접 포맷 파서를 새로 만드는 것보다 기존 도구를 안정적으로 감싸는 일이 더 현실적이다.

기업 구매자는 설치 용량보다 구성 명세를 봐야 한다. 어떤 바이너리가 포함되는지, 라이선스는 무엇인지, 업데이트는 어떻게 되는지, 샌드박스 경계는 어디인지, 파일이 외부로 나가는 조건은 무엇인지 확인해야 한다. AI 문서 자동화의 성패는 프롬프트보다 이런 운영 질문에서 갈린다.

자주 묻는 질문

Q1: Codex 앱에 LibreOffice가 포함된 것이 왜 중요한가요?

A: 문서 에이전트가 Office 파일을 로컬에서 열고 변환하려면 안정적인 문서 엔진이 필요합니다. LibreOffice는 그 역할에 오래 쓰인 도구입니다.

Q2: 1.7GB 런타임은 과한가요?

A: 단순 채팅 앱으로 보면 크지만, Python, Node.js, Poppler, LibreOffice, git을 포함한 자동화 런타임으로 보면 이해 가능한 규모입니다.

Q3: 로컬 변환은 개인정보에 유리한가요?

A: 외부 서버 전송을 줄일 수 있어 유리합니다. 다만 로컬 바이너리의 업데이트와 취약점 관리도 함께 필요합니다.

Q4: 개발자는 무엇을 배워야 하나요?

A: AI 앱의 품질은 모델만이 아니라 파일 포맷 처리, 변환 도구, 샌드박스, 재현 가능한 런타임 설계에서 나온다는 점입니다.

Q5: 기업 도입 시 무엇을 물어봐야 하나요?

A: 번들된 바이너리 목록, 라이선스, 업데이트 주기, 네트워크 전송 조건, 로컬 파일 접근 권한, 감사 로그 제공 여부를 확인해야 합니다.