LibreOffice, 구형 Word 파일 읽기는 Word보다 나았음

 (eldritch.cafe)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 은퇴 후 오래된 원고를 정리하던 사용자가 구형 문서 복구를 시도하면서, Word보다 LibreOffice가 더 오래된 파일을 열어낸 사례가 확인됨
  • Word는 1994년 이전 파일을 읽지 못했지만, 최신 Mac용 LibreOffice는 1992년·1989년 파일과 1986년 문서까지 대체로 열 수 있었음
  • 변환 품질은 완벽하지 않아 1989년 파일의 소문자 a가 circumflex 문자로 바뀌고, 1986년 문서에는 일부 박스 문자가 나타남
  • 사용자는 원고를 클라우드와 Time Machine에 백업한 뒤 오래된 소설 9편, 미완성 소설 2편, 단편 약 15편을 확인함
  • 오래된 독점 파일 형식은 하위 호환성 유지 비용이 크기 때문에, LibreOffice 같은 외부 도구가 문서 복구용 안전망이 될 수 있음

오래된 원고 정리에서 시작된 복구 작업

  • 은퇴 후 글쓰기 작업에 시간을 쓰게 된 사용자는 수정과 재작성이 필요한 미판매 장편소설을 목록화하기 시작함
  • Mac을 업무용 VPN에서 분리한 뒤 폴더 연결이 꼬여, Finder의 Documents를 클릭하면 네트워크 위치를 찾다 실패하는 문제가 생김
    • 재부팅 후 사용자 디렉터리에서 직접 Documents로 들어가면 접근 가능했음
    • 모든 글쓰기 폴더를 데스크톱으로 복사해 오래된 소설과 단편 원고를 잃지 않았음을 확인함
  • 처음에는 완성된 책이 7권이라고 생각했지만 실제로는 완성본 9권이 있었음
    • 그중 3권은 3부작을 이루고, 한 소설에는 후속편이 섞여 있음
    • 미완성 소설은 2편이었음
  • 단편은 약 15편으로 보였고, 여러 폴더의 제출 기록 때문에 상당수가 완성본으로 판단됨

Pages와 Word가 열지 못한 지점

  • 1996년에 작성된 한 소설은 Pages가 열기를 거부함
    • 사용자는 이 작품을 초기 판매 가능성이 높은 재미있는 스페이스 오페라로 봄
  • Word 설치와 오래된 파일을 열 수 있는 프로그램 조사를 계획했지만, 이후 Word가 1994년 이전 파일을 읽지 못한다는 점을 확인함
  • Apple ][ 시절의 장 원본도 보관 중이었지만, PowerPC 시절에 Mac과 새천년대 Word 버전으로 갱신해둔 상태였음

LibreOffice가 실제로 열어낸 파일들

  • 다른 사용자가 “LibreOffice가 오래된 Word 파일을 Word보다 더 잘 읽을 수 있다”고 조언했고, 사용자는 최신 Mac용 LibreOffice를 설치함
  • 1992년 파일은 문제없이 열렸음
  • 1989년 파일도 열렸지만, 모든 소문자 a가 circumflex 문자로 변환됨
    • 사용자는 이 정도 문제는 감수할 수 있다고 봄
  • Mac에서 날짜 검색 방법을 찾은 뒤, 확장자가 없는 The Revenger라는 스토리 트리트먼트를 발견함
    • 날짜는 1986년 3월 25일이었음
    • 몇 개의 박스 문자가 있었지만 전반적으로 읽을 수 있었음
    • 사용자는 이 문서를 Andre Norton류 SF 스페이스 오페라 시도로 봄
  • LibreOffice는 Tree Castle도 열었음
    • 이 문서는 Mac Draw 문서였거나 그랬을 가능성이 있음
    • 날짜는 1986년 1월 1일이었고, 사용자가 가진 가장 오래된 문서였음
  • 사용자는 문서 변환 용도로 LibreOffice를 높게 평가했고, 오래된 문서 내용 일부는 미숙했지만 잃어버린 지식재산은 없었다고 정리함

하위 호환성 유지의 현실적 비용

  • 한 사용자는 업무에서도 LibreOffice를 주 도구로 쓰며, 오래된 Word 파일을 Word보다 더 잘 복구한 경험이 여러 번 있었다고 공유함
  • 원 작성자는 Microsoft가 자체 독점 형식에 100% 하위 호환성을 제공하지 못하는 일이 단순한 무성의만은 아니라고 봄
  • 하위 호환성 유지에는 개발자 비용과 테스트·디버깅 비용이 계속 들어감
    • 대형 회사의 프로그래머는 보너스를 제외하고도 15만 달러 이상이 들 수 있다고 언급됨
    • 관리 방식, 프로그래밍 패러다임, 언어 요구사항, 저장소 접근, 개인정보 보호 기준, 감사 가능성이 바뀔 때마다 코드 유지 부담이 생김
    • 지원 제품 전체에 전담 프로그래머가 필요하거나, 코드 변경 시 계절성 팀과 관리 시간이 필요할 수 있음
  • 대부분의 사용자는 몇 년보다 오래된 파일을 갖고 있지 않으며, 업무에서는 최대 7년 보관이 모범 사례로 언급됨
    • 오래된 파일은 갱신하거나 PDF로 만들어 보관하는 경우가 많음
  • LibreOffice에는 오래된 파일 열기가 설치 기반을 넓히는 기능이 될 수 있고, 기부도 받기 때문에 완전히 무상 노동만으로 보기 어렵다는 해석이 나옴
  • 외부 도구가 실패하면 Microsoft는 그 기술지원 부담이나 소송·불매·나쁜 평판을 외부 도구 쪽에 남겨둘 수 있음

오픈소스 버그 신고와 도구 생태계 경험

  • 1989년 파일에서 소문자 a가 circumflex로 바뀌는 현상은 버그로 보고할 가치가 있다는 의견이 나옴
    • 파일을 버그 리포트에 첨부할 수 있으면 누군가 살펴볼 가능성이 있음
    • LibreOffice Writer의 문단 나누기 대화상자 사용자 경험 문제를 보고했고, 논의 후 수정됐다는 사례도 공유됨
  • 원 작성자는 사용해본 몇몇 오픈소스 프로젝트에서 버그를 보고했지만, 몇 년 뒤 실제 수정된 것은 하나뿐이었다고 회고함
    • 종종 “직접 고치라”는 답을 받았고, 타인의 문제 수정은 우선순위가 낮은 편이라고 느낌
    • Microsoft에서도 비슷한 태도를 경험했으며, Apple은 조금 낫지만 큰 차이는 아니었다고 덧붙임
  • Git과 pull request 같은 오픈소스 기여 절차는 일반 사용자나 일부 개발자에게 장벽이 될 수 있음
    • 원 작성자는 Zowe 관련 오픈소스 작업과 Open Mainframe Project의 의무 적합성 프로젝트에서 .md 지침을 다시 써야 했고, GitHub pull request 요구에서 막힘
    • mainframe, JavaScript, C, Windows 개발자도 GitHub 방식에 익숙하지 않으면 새로 배워야 하는 부담이 생김
  • 다른 사용자는 Git 적응이 어렵고, Mercurial은 비슷한 분산 모델이지만 훨씬 이해하기 쉽다고 느낌
  • WordPerfect 논의에서는 많은 프린터 드라이버를 진입장벽으로 본 전략이 오히려 약점이 됐다는 의견이 이어짐
    • Windows가 프린터 지원을 계속 늘리는 동안, WordPerfect는 더 이상 필요 없는 프린터 드라이버를 불러오느라 10분 넘게 걸렸다는 경험이 공유됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 여러 번 수정하고 댓글이 달린 doc/docx 파일을 LibreOffice에서 5분마다 저장해도, 다음에 다시 열릴 거라고 믿으면 안 됨
    Word 파일을 직접 편집하면 LibreOffice가 언젠가는 문서를 망가뜨릴 수 있음. LibreOffice 형식으로 작업한 뒤 doc/docx로 변환해서 보내는 편이 안전함
    문제는 교묘해서, LibreOffice는 편집 내용을 보여주고 수정도 가능하게 해주지만 실제 저장 파일은 손상될 수 있음. 다음에 열 때야 알게 되며, 내부 XML의 태그 불일치처럼 고칠 수 있는 경우도 있고 문서의 큰 부분이 사라져 복구 불가능한 경우도 있음

    • docx로 작업하지 않는 편이 좋음. 필요하면 가져오기는 하되, 작업은 OASIS OpenDocument 형식으로 해야 함
      MS Office 사용자에게 보내야 한다면 그냥 OpenDocument를 보내면 됨. Office도 열 수 있고, 문제가 생긴다면 LibreOffice보다 Office 쪽 버그일 가능성이 큼
      MS Office 사용자도 표준 문서 형식인 OpenDocument에 익숙해질 필요가 있음
    • 큰 문서를 더 이상 WYSIWYG 불투명 형식으로 작업하는 건 상상하기 어려움. 일반 텍스트 파일 형식과 버전 관리만이 작업물을 잃지 않는 확장 가능한 도구 조합이라고 봄
    • 반대 방향으로도 비슷한 일이 생길 수 있고, 실제로는 그쪽을 더 자주 봤음. 다만 주로 10년 전 일임
      Word에서 변경 추적이 켜진 DOCX를 만들고, LibreOffice에서 여러 번 편집·저장한 뒤 Word에서 다시 열어 수정하고 저장하면 Word가 그 파일을 못 여는 경우가 있었음. LibreOffice에서 열고 다시 저장하면 고쳐졌음
      본 사례들은 모두 변경 추적과 관련 있었고, DOCX의 변경 추적 내부 표현이 “RTF와 잡다한 걸 XML로 덤프한” 나머지 형식보다도 더 엉망이라 놀랍지는 않음
    • LibreOffice가 Word 파일을 언젠가 먹어버린다는 건 맞지만, Word도 먹지는 않을 뿐 결국 문서를 잘게 찢어놓아 실질적으로 차이가 없어짐
      Word 형식 자체를 피하는 게 좋음
    • 어느 애플리케이션이든 어느 정도 복잡한 비네이티브 형식에서는 같은 문제가 생김
      공급업체 A는 형식 A와 자사 애플리케이션을 함께 개발·테스트·수정하고 사용자 데이터와 버그 데이터를 모두 갖고 있음. 공급업체 B는 자기 앱과 형식도 개발해야 하고, A의 조직 지식과 데이터가 없음
      따라서 B의 앱이 A 형식의 복잡한 데이터를 A만큼 안정적으로 처리하기는 어렵고, A 자체에도 버그는 있음. 이 경우 Microsoft Office 팀은 LibreOffice보다 자원도 훨씬 많을 가능성이 큼

  • 예전에 Joel Spolsky가 쓴 것으로 기억하는 XLS 형식 설계 글을 읽었는데, Excel의 내부 메모리 구조를 디스크에 덤프하고 당시 느린 디스크에서 저장·불러오기를 빠르게 하려는 최적화를 더한 수준이었음
    그는 성능에 꽤 만족한 것 같았지만, 나는 “이 파일을 다뤄야 하는 다른 프로그램은 망했다”는 생각만 들었음. 그리고 “다른 프로그램”에는 이후 버전의 Excel도 포함됨
    보관 목적으로 오래된 파일을 복구하려면 예전 DOC와 XLS 내부 문서가 있으면 좋겠지만, Microsoft가 내부적으로라도 제대로 문서화했을 가능성은 낮아 보임

    • DOC도 마찬가지였음. Word의 내부 표현을 그대로 덤프한 형식이었음
      그래서 공개 표준 요구가 들어오자 DOCX/XLSX로 완전히 갈아엎어야 했음. Microsoft가 문서화할 방법이 없었기 때문임
      다만 DOCX/XLSX에도 “Word/Excel의 내부 바이너리 덤프” 태그가 있어서 같은 함정에 빠진다는 점은 도움이 안 됨
    • 맞음, 정말 훌륭한 글임
      https://www.joelonsoftware.com/2008/02/19/why-are-the-micros...
    • Microsoft는 실제로 예전 형식들을 문서화했음. 반독점 소송 때문에 강제로 그렇게 됐기 때문임
      Spolsky 말대로 완전히 난장판이지만, 기술적으로는 문서화되어 있음
    • 아마 헤더 파일만 공개하면 되는 것 아닐까 싶음
      결국 모든 파일 형식은 바이너리로 기록된 메모리 구조일 뿐임

  • Windows 7 업그레이드 시기에 회사가 쓰던 오래된 근태 관리 소프트웨어가 더 이상 작동하지 않는 걸 발견했음
    다행히 IT 부서가 해결책을 냈는데, 회사 전원에게 Ubuntu VM을 지급하고 Wine으로 그 소프트웨어를 실행하게 했음. 결국 웹 기반 솔루션으로 바뀔 때까지 몇 년 동안 그렇게 운영됨

    • 이미 지난 일이지만 Microsoft는 호환성을 매우 진지하게 다루고, 직접 호환성 패치를 만들 수 있는 도구도 제공함
      https://techcommunity.microsoft.com/t5/ask-the-performance-t...
    • 여자친구가 예전 포인트앤클릭 Nancy Drew 게임을 좋아함. 거의 다 Steam에서 팔고 일부는 잘 돌아가지만, 어떤 건 실행조차 안 되거나 바로 깨지는 문제가 있음
      그런데 최신 Windows보다 Linux의 Steam Proton에서 더 잘 돌아간다는 걸 알게 됨. 물론 실제로 플레이하기에 충분히 잘 되는 정도는 아니었음
    • Mac을 요구한 마케팅 사용자 3명에게 Parallels 라이선스를 사준 적이 있음
      주된 이유는 근태 관리 소프트웨어를 쓰게 하려는 것이었음. 생산직 직원처럼 2달러짜리 RFID 카드를 주면 됐지만, 그러면 타임클록까지 걸어가서 출근 찍어야 했음
      결국 Mac 버전에 없던 기능 때문에 Windows용 Outlook도 쓴 것 같음
    • 예전에 일했던 회사의 소프트웨어는 당시 흔하던 큰 모니터 특정 크기에 맞춰 작성됐고, 그 크기에서만 동작했음
      그래서 고객은 소프트웨어를 구매하면 알맞은 크기의 모니터를 무료로 받았음. 실제 이야기임

  • Windows XP 시절 게임을 Ubuntu에서는 실행했지만 Windows 11에서는 못 실행한 비슷한 일이 있음
    게임이 어떤 Direct3D를 쓰는데 Windows 10 이후에서는 작동하지 않았음. 장비에 Windows XP/7/8을 설치하고 싶지는 않았고, 가상 머신은 그래픽 가속 지원이 별로였음
    그런데 실제 Ubuntu 설치 환경에서 Wine을 쓰고 올바른 파일을 조금 찾아 넣으니 실행됐음. 더 웃긴 건 Windows 11의 WSL에서 돌아가는 Ubuntu에 Wine을 설치했더니 그 환경에서도 게임이 실행됐다는 점임. 이렇게 복잡한 방식으로 예전 게임을 돌릴 줄은 몰랐음

    • WSL은 필요 없음
      https://fdossena.com/?p=wined3d/index.frag
      Windows에서 동작하는 컴파일된 wined3d DLL이 있음
      https://github.com/doitsujin/dxvk
      이것도 Windows에서 동작함
      게임 폴더에 넣기만 하면 실제 DirectX 대신 해당 DLL을 로드할 것임. 예전 게임을 계속 실행하기 위한 오래된 API 구현체도 더 있고, 일부는 Wine을 쓰는 Linux 사용자도 사용함. 예를 들어 dgVoodoo가 있음
      http://dege.freeweb.hu/dgVoodoo2/ 는 3dfx 시대 카드의 독점 API인 Glide와 DirectX 1~7, 8.1, 9를 지원함
      https://github.com/FunkyFr3sh/cnc-ddraw 는 오래된 2D API인 DirectDraw 관련 문제를 고쳐주며, Windows 사용자와 Linux에서 Wine을 쓰는 사람 모두에게 유용할 수 있음
      https://github.com/otya128/winevdm 는 64비트 Windows에서 16비트 앱을 실행함
      여기에 Windows 자체의 호환성 모드 조정까지 더하면, VM의 무거운 오버헤드 없이 Windows용으로 출시된 거의 모든 게임을 돌릴 수 있을 것임. 내가 알기로 WSL은 한 번 확보한 메모리를 해제하는 방법도 모름
    • 전혀 놀랍지 않음. Linux의 WINE을 Yabridge와 함께 쓰면 Win98/XP 시절의 아주 오래됐지만 여전히 훌륭한 오디오 플러그인들이 완벽하게 돌아감. 최신 Windows에서는 문제가 있거나 아예 작동하지 않는 것들임
      게임도 이 놀라울 정도로 충실한 호환 계층의 혜택을 받고 있고, 오늘날에는 최신작을 포함한 많은 Windows 게임을 WINE으로 Linux에서 투명하게 설치할 수 있음
      https://www.youtube.com/watch?v=Bg1NiXtrJ6g
      https://www.youtube.com/watch?v=3b50Stm8gu4
    • 이런 방식으로 예전 Photoshop을 실행해보고 싶었음
      과정이 간단했는지 궁금함

  • 아이러니하게도 LibreOffice에서 열어보려 했던 오래된 파일 형식 하나가 StarOffice 5 파일이었는데, 열리지 않았음
    LibreOffice는 OpenOffice에서 갈라졌고, OpenOffice는 StarOffice를 오픈소스로 공개한 것이었음. 변환기는 코드베이스 단순화를 위해 제거됐음

    • 변환기라면, 형식 변환만 수행하는 독립 실행 유틸리티로 만들기 얼마나 어려울지 궁금함. 수동 개입이 필요 없다는 가정하에서임
      복잡도는 있겠지만 StarOffice는 이제 고정된 형식이고, OpenDocument도 대상으로 삼을 수 있는 이전 고정 버전이 있을 것 같음
      누구도 다르게 기대하면 안 되겠지만, Apple도 iWork 형식의 하위 호환성을 보존하지 않았고, 열기 위해 예전 버전을 찾아야 하는 레거시 문서가 몇 개 있음
    • LibreOffice 3.x로 열어보는 게 좋음. StarOffice 지원 상당수가 LO 4에서 제거됐음
      https://wiki.documentfoundation.org/ReleaseNotes/4.0#Feature...
    • 지금 LO에는 libstaroffice가 있어서 읽을 수 있어야 함. 최근 LO에서는 어떻게 되는지 궁금함

  • 2024년인데도 Excel이 CSV를 망치지 않고 열지 못해서, 모든 CSV 파일은 LibreOffice로 엶
    가져오기 마법사가 있다는 건 알지만, 그것도 여전히 가끔은 망쳐놓음

    • LibreOffice의 미리보기가 정말 좋음. 어떤 구분자와 문자 인코딩을 쓸지, 몇 번째 행부터 시작할지 등을 고를 수 있어서 매우 사용자 친화적이고 쓰기 좋음
    • 이 용도라면 Power Query를 쓰는 게 좋음. Get Data, From File 같은 흐름으로 가져오면 됨

  • 1990년대 중후반에 백신 소프트웨어를 만드는 회사에서 일했는데, Word 파일의 매크로 바이러스를 검사하는 일이 필요했음
    그런데 Word 1.0 파일을 열 수 없어서 Microsoft 직원들이 미국에서 직접 와서 도와줬음. 당시엔 비교적 작은 영국 회사였기 때문에 꽤 큰일이었고, 그런 일이 있었던 건 내가 아는 한 그때뿐임
    다소 비밀스럽게 진행됐지만, 내가 들은 이야기는 Microsoft가 Word 1.0 형식 파일을 읽고 쓰는 원본 소스 코드를 잃어버렸고 컴파일된 바이너리만 남아 있어서, 새 코드를 역공학해야 했다는 것이었음

  • LibreOffice는 호환성을 목표로 하지만 MS는 고객이 더 새롭고 수익성 높은 버전으로 업그레이드하길 원하니, 이런 결과는 놀랍지 않음

    • 예전 Microsoft는 하위 호환성을 정말 진지하게 여겼고, 메인프레임을 제외하면 누구보다 더 그랬을지도 모름
      어떤 앱이 버그나 문서화되지 않은 기능에 의존하더라도 계속 작동하도록 특수 처리를 넣을 정도였음
    • 원한다면 표준 공개 형식을 쓰면 됨. 그런데 댓글에는 늘 MS 트롤이 있음
      SharePoint에 올리려고 xls/doc 파일 100GB를 변환했는데, 공개 형식으로 다시 저장하기만 해도 공간이 대략 5배 절약됐음
      LibreOffice가 오래된 파일을 더 잘 여는 건 전혀 놀랍지 않음. Microsoft는 보안 설정에 들어가 허용하지 않으면 열 수 없게 막아둔 파일도 있음. 거의 30년 된 라이브러리를 변환 중이었고 20년 넘은 파일도 많았는데, 오늘날 왜 이런 쓰레기 호환성을 계속 들고 가야 하겠음

  • 작은 퀵 오일 교환 체인에서 쓰던 맞춤형 DOS 앱이 Windows 7 이상에서는 호환성 설정을 어떻게 해도 실행되지 않았지만, Linux의 Wine에서는 잘 돌아간 비슷한 일이 있었음
    앱을 다시 개발할 때까지 임시방편으로 그렇게 썼음. 콘솔 앱을 써본 경험 때문에 대체 앱도 콘솔 앱으로 유지하고, Linux 셸에서 돌아가도록 현대화해서 다시 작성했음. 라이선스 비용도 모두 절약됐고, 결국 꽤 만족해하는 것 같았음
    Microsoft는 10년도 더 전에 회사 전체가 한꺼번에 어떤 대가를 치르더라도 하위 호환성을 지킨다는 핵심 원칙에서 벗어난 듯함

    • 진지하게 궁금한데, 그 핵심 원칙이 악성코드 방어와 양립하기 어려워진 걸까? 오래된 것들을 지원하면서 공격 표면이 너무 커졌던 걸까?
    • 1980년대 이후 출시한 모든 것과 계속 호환되는 건 실현 불가능하고 유지보수도 안 됨
      16비트 DOS와 Windows 애플리케이션은 64비트 Windows에서 실행되지 않음

  • 오래된 일본어 Word 파일을 LibreOffice에서 절대 열면 안 됨. 파일을 망가뜨림
    오래된 일본어 Word 파일은 Shift JIS로 저장되어 있는데, LibreOffice가 UTF-8로 열기 때문임

    • 그 특정 문제에 대한 이슈가 Bugzilla[1]에 있는지 궁금함
      없다면 새로 열어본 적이 있는지, 재현용 샘플을 공유할 수 있는지 궁금함. Bugzilla에서 “Shift JIS”를 검색해봤지만 아무것도 찾지 못했음
      [1] https://bugs.documentfoundation.org/
답변달기