Ruby, Java, TypeScript, 어떤 언어가 승자일까?
DOCX 플러그인을 Ruby, Java, TypeScript로 구현한 경험을 공유하며, 각 언어의 장단점과 기술적 선택에 대한 고찰을 제시함
Java는 Zip 파일 및 XML 처리에 강점을 보이며, 성숙한 라이브러리를 제공하여 안정성을 확보함
TypeScript는 MCPB(Multi-Component Plugin Binary) 지원 가능성으로 인해 최종 선택되었으며, 번(Bun)을 사용하여 단일 실행 파일로 빌드함
Codex 플러그인의 제한적인 기능과 Bun의 소스 맵(Source Map) 업로드 문제 등, 개발 환경(Dev Environment)의 기술적 제약에 대한 언급도 포함됨
언어별 Zip 및 XML 처리 능력 비교
저자는 Ruby, Java, TypeScript로 DOCX 플러그인을 구현하면서 각 언어의 Zip 파일 및 XML 처리 능력을 비교했다. Java는 표준 라이브러리를 통해 문제없이 처리할 수 있었으며, TypeScript는 `fflate`와 `xmldom` 라이브러리를 사용했다. 특히, `xmldom`은 XML pretty-print 기능 부재로 인해 불편함을 겪었다고 언급하며, 이는 XML의 직렬화/전송 목적에 기인한다고 설명했다.
타입 시스템(Type System)의 중요성
저자는 Ruby의 타입 시스템 부재로 인한 문제점을 지적하며, Java와 TypeScript의 정적 타입(Static Typing)이 코드 작성의 용이성을 높인다고 강조했다. Ruby에서는 `each` 메서드 누락, `children` 속성 누락 등, 타입 힌트 부재로 인한 오류를 겪었다고 언급했다. 반면, Java와 TypeScript는 컴파일 시 오류를 발견하여 개발 생산성을 향상시켰다.
MCPB(Multi-Component Plugin Binary) 지원과 기술 선택
저자는 MCPB 지원 가능성을 고려하여 TypeScript를 최종 선택했다. MCPB를 사용하면 Node 런타임을 포함하지 않아 바이너리 크기를 99% 줄일 수 있다. 하지만, 현재 Claude 플러그인은 MCPB를 지원하지 않아 Bun을 사용하여 단일 실행 파일을 빌드했다. 또한, Bun의 소스 맵(Source Map) 업로드 문제로 인해 PostHog 연동에 어려움을 겪었다.
플랫폼별 기술적 제약 및 트레이드오프
저자는 Claude와 Codex 플러그인 메커니즘의 차이점을 언급하며, Codex의 제한적인 기능을 지적했다. 특히, `CLAUDE_PLUGIN_ROOT` 환경 변수 미지원으로 인해 단일 실행 파일 실행에 어려움을 겪었다고 밝혔다. Java는 성숙한 런타임 환경을 제공하지만, 단일 실행 파일의 크기가 크다는 단점이 있다. TypeScript는 MCPB 지원 가능성이 높지만, Bun의 소스 맵 업로드 문제가 존재한다.
