Claude Code가 DOCX 양식을 채우지 못하는 이유에 대한 사후 분석

커뮤니티 반응

Claude Code가 자신의 한계를 명확하게 기술적으로 분석해낸 점에 대해 긍정적인 반응이 예상됩니다.

주요 논점

01중립다수

Claude Code는 현재의 아키텍처상 Microsoft Word 없이 DOCX VML 양식을 완벽히 처리하는 것이 불가능하다.

합의점 vs 논쟁점

합의점

시각적 렌더링 엔진 없이는 문서 자동화의 최종 품질을 보장할 수 없다.
VML은 현대적인 AI 코딩 에이전트가 다루기에 매우 까다로운 레거시 포맷이다.

실용적 조언

DOCX 양식 자동화가 필요한 경우 Windows 환경에서 COM 자동화를 사용하거나, 포맷을 PDF로 변경하여 텍스트를 덮어쓰는 방식을 권장한다.

섹션별 상세

Claude Code는 시각적 렌더링 레이어가 결여되어 있어 문서를 시각적으로 확인하며 필드를 채우는 인간의 방식을 재현하지 못한다. 내부적으로 XML 바이트를 읽고 쓰거나 명령줄 도구를 실행할 수는 있지만, 문서의 최종 출력물을 실시간으로 확인하며 상호작용하는 기능이 없어 맹목적인 XML 조작에 의존한다. 결과적으로 수정 후 변환 단계를 거쳐야만 파손 여부를 확인할 수 있는 구조적 한계를 가진다.

Microsoft Word의 VML 텍스트 박스는 라이브 XML 데이터와 미리 렌더링된 비트맵 썸네일(o:gfxdata)을 동시에 저장하는 이중 구조를 취한다. Claude Code가 XML 데이터에 텍스트를 주입하더라도 비트맵 썸네일이 업데이트되지 않아 LibreOffice와 같은 도구에서는 빈 필드로 표시된다. 썸네일 데이터를 강제로 삭제하면 렌더링을 시도하지만, 오픈소스 도구의 VML 지원 미비로 인해 텍스트 위치가 어긋나거나 잘리는 현상이 발생한다.

DOCX 포맷 내에서 VML 양식을 완벽하게 채우기 위해서는 Microsoft Word 엔진이나 Windows의 COM 자동화 프레임워크가 필수적이다. 현재 오픈소스 생태계에는 o:gfxdata 썸네일을 정확하게 업데이트할 수 있는 도구가 존재하지 않으며, 이는 단순한 엔지니어링 문제가 아닌 플랫폼 차원의 제약 사항이다. 따라서 DOCX 출력을 고집하기보다는 PDF 오버레이 방식과 같은 대안을 고려하는 것이 현실적이다.

향후 개선 방향으로 문서의 XML을 열어 양식 타입을 식별한 뒤 즉각적인 제약 사항을 사용자에게 고지하는 프로세스가 필요하다. 특히 VML 기반 양식의 경우 DOCX 출력이 불가능함을 알리고 PDF 전환 여부를 먼저 확인해야 하며, 작업 완료 전 PNG 렌더링을 통해 시각적 검증 단계를 거쳐야 한다. 단순한 텍스트 주입 성공 여부가 아니라 인간이 작성한 것과 동일한 시각적 품질을 확보했는지가 검증의 핵심이다.

용어 해설

벡터 마크업 언어(VML): — Microsoft Word에서 텍스트 상자와 도형을 정의하는 레거시 XML 포맷이다. 라이브 XML 데이터와 미리 렌더링된 비트맵 썸네일을 동시에 저장하며, 외부 도구로 XML만 수정할 경우 썸네일과 불일치가 발생하여 내용이 보이지 않거나 위치가 어긋나는 문제가 발생한다.
DOCX: — Microsoft Word에서 사용하는 개방형 XML 기반 문서 포맷이다. 내부적으로 여러 XML 파일이 압축된 구조로 되어 있어 프로그래밍 방식으로 조작이 가능하지만, 레이아웃 렌더링 엔진 없이는 시각적 정확성을 보장하기 어렵다.
COM 자동화(COM Automation): — Windows 환경에서 소프트웨어 구성 요소 간에 통신하고 제어할 수 있게 해주는 기술이다. Microsoft Word를 직접 실행하여 문서를 조작하므로 VML 썸네일 업데이트 등 복잡한 렌더링 문제를 완벽하게 해결할 수 있는 유일한 방법이다.

언급된 도구

LibreOffice중립

오픈소스 문서 렌더링 및 변환 도구

Microsoft Word추천

DOCX 및 VML 양식의 표준 렌더링 엔진