Adobe Reader는 새 기기에 절대 설치하지 않는 첫 번째 앱임. 느리고 버벅거림, 다크 패턴과 팝업창이 난무함, 기본 편집 기능은 구독 없이는 숨겨둠. 사용자를 존중하지 않는 모든 요소가 모여 있음. 정말 끔찍한 소프트웨어임. MS Word도 맥에서 점점 더 무거워지는 걸 보면 비슷한 느낌을 받음
팝업창은 사실 언제나 짜증나는 요소임. 최근 이 점을 많이 고민해봤는데, 사용자 입장에선 팝업이 정말 꼭 필요한 좋은 선택인 경우를 떠올릴 수가 없음. 개발자 입장에선 눈길을 끌기 좋은 쉬운 방법이겠지만, 결국 사용자는 오래 머물지 않음
Adobe Reader를 안 깐다는 말에 정말 공감됨. “전화가 울리지 않으면 그건 나야”라는 노래가 생각남
Adobe Reader(혹은 Acrobat Reader)는 여전히 PDF 업계 표준임. 예전에 OnlyOffice로 만든 PDF가 Chrome에서는 제대로 표시됐는데, Acrobat에서는 폰트가 제대로 표현되지 않아서 문제가 있었음. 그래서 만든 PDF 파일의 호환성 검증용으로 Acrobat을 설치해둠
나도 공감하지만, 결국 설치할 수밖에 없는 게 가끔 Acrobat만 제대로 처리하는 PDF를 계속 받게 됨. 특히 비즈니스 상황에서 많은 사람들이 PDF 기능을 창의적으로 쓰다 보니, 대안 프로그램들은 늘 부족한 점이 있음
Adobe Reader/Acrobat을 사용하는 유일한 용도는 PDF를 텍스트로 변환하는 것임. 어떤 PDF는 이 작업이 pdftotext보다 훨씬 잘 돼서 쓰고 있음
Adobe Reader 설치 전에 Adobe Reader Customization Wizard for Windows로 광고나 온라인 기능, "Upsell" 옵션을 끄는 등 기능들을 미리 제거할 수 있음. macOS 버전도 있을 수 있고, 레지스트리나 환경설정에서 직접 "FeatureLockDown" 옵션을 설정해도 동일한 효과를 볼 수 있음. 관련 문서는 여기, 여기, 여기 참고
이런 작업을 굳이 할 필요 없이 대체 프로그램을 설치하는 것이 더 편리함
요즘 대형 프로그램을 믿지 않게 됨. Kubernetes 클러스터 관리하려고 누가 Lens를 추천했는데, 설치 파일만 600MB에 설치하면 두 배로 불어남. 데스크톱 소프트웨어가 너무 과해진 시대임. Blender가 300MB인 것과 비교하면 참 역설적임. 물론 극도로 최적화된 소프트웨어만 원하는 건 아니지만, 2GB짜리 k8 콘솔은 개발자에 대한 신뢰 자체가 안 생김
모바일도 다르지 않음. 내 아이폰 확인해보니 Instagram, TikTok, Duolingo가 각각 500MB쯤 됨. 앱을 조금만 써도 캐시 때문에 금세 GB 단위 차지함. 거의 안 쓰는 Snapchat도 캐시만 다섯 기가임
난 Octant가 너무 그리움. 정말 80/20 원칙에 맞는 훌륭한 앱이었음. 요즘은 대부분 kubectl을 비유적으로나마 계속 쓰고 있음. k9s도 시도해봤지만 도무지 내 스타일은 아님
y축이 로그 스케일임을 참고할 것임. 현재 Adobe Reader 용량은 Sumatra에 비해 83배 크기로 나타남
로그 스케일은 상대적 크기 차이를 알리려는 의도를 망치는 선택 같음
처음엔 그래프를 보고 버전 번호를 파일 크기(MB)로 착각함. 예를 들어 “25.1MB?”라고 생각했음. 의외로 훨씬 더 클 거라 생각했는데, 혹시 초압축했나 싶기도 했음. Sumatra가 3MB대인 것도 잘 압축했으면 가능한 수치라고 여김. 그치만 요즘 프로그램 용량은 말도 안 되게 커진 게 많음. 예전 Zoom이 업데이트 한 번에 단숨에 두 배 커지던 것도 기억남—웹 브라우저 하나를 패키지 안에 통째로 더 실어 넣으면서 그렇게 됐음
Adobe가 2005년 Macromedia 인수 후 Flash를 Acrobat과 Acrobat Reader 등 여러 제품에 통합했음. 그래서 PDF 안에 SWF(Flash) 컨텐츠를 내장할 수 있었고, 이로 인해 인스톨러 용량과 복잡성이 대폭 증가함. Flash Player 공식 지원 종료(2020년대 초) 이후 Flash 지원은 결국 사라짐. 한편 Acrobat은 대화형 PDF(폼 검증, 자동화 등) 지원을 위해 JavaScript 엔진도 내장함. Flash와 JavaScript는 오랫동안 심각한 보안 리스크를 일으켜 왔음. Flash는 없어졌으나 JavaScript는 여전히 남아 있어서 보안 위험이 상존함. 반면, Sumatra 같은 경량 PDF 리더는 JavaScript나 Flash를 지원하지 않아 훨씬 가볍고 안전함
난 항상 PDF에 JavaScript가 내장된 게 뭔가 아이러니했다고 생각함. 원래 PostScript라는 언어가 있었는데, 이건 렌더링 엔진이 엄청 강력함. 문제는 PostScript가 튜링 완전 언어라 너무 유연해서 문서로 다루기엔 곤란했음. 그래서 Adobe가 엔진은 그대로 두고 튜링 요소를 빼내고 구조를 좀 더해야 PDF를 만들었다는데, 결과적으로 또 JavaScript로 튜링 기능을 되돌려 넣은 꼴이 됨. 굳이 스크립트 언어가 필요했다면 PostScript로 다시 넣는 게 나았을 수도 있다고 생각함
옆길로 새는 이야기긴 하지만, 윈도우용 커스텀 뷰(2페이지 보기, 다크 모드, 툴바 자동 숨김 등)와 부드러운 스크롤이 가능한 PDF 뷰어 아시는 분 계시는지 궁금함. 과거 Adobe Viewer가 유일하게 이걸 지원했는데 이제 단종돼서 아쉬움. Xodo PDF가 그나마 비슷한데 팝업이 너무 많음
Sumatra PDF도 한 번 써보라고 권유함
Okular도 이런 식으로 커스터마이징 가능할지 모름
맥을 쓰고 Preview를 추천함
"상식 있는 사람이라면 scoop으로 깔 것"이라는 관점이 정말 이해하기 어려움. 그래도 글과 그래프는 잘 만듦
윈도우 생태계에 익숙하지 않은데 scoop이 choco, nuget 같은 패키지 매니저 맞는지, 혹시 scoop이 부적절하게 무겁다는 평가도 있는 건지 궁금함
이런 태도는 아쉬움. 모두의 요구가 다 다르단 걸 이해하지 못한 시야라 생각함. winget, chocolatey 같은 용도를 제안도 안 하고, 웹사이트로 다운받는 걸 “비상식적”이라고 보는 건 무리라고 생각함
요즘 브라우저가 PDF 폼 작성, 서명 등에서 Adobe 소프트웨어보다 오히려 더 나은 기능을 제공함. Adobe는 이런 기본 기능조차 쓰려면 업셀만 시도함
언제부터인지는 모르겠지만, Chrome이 이 기능을 정말 잘 처리해줌. 1~2년 전에는 미흡했던 거 같은데 지금은 완벽함
2004~2005년에 Mac으로 넘어갔음. 그때 가장 인상적이었던 건 Preview였음. PDF 처리에 너무 유용해서 Adobe Reader가 더는 필요 없었음. 지금까지도 Adobe Reader가 여전히 무겁고 별로인 건 놀랍지 않음. 그런데 용량이 시디 한 장 크기까지 커질 거라곤 몰랐음. 정말 우스운 상황임
내가 느낀 유일한 차이는 PDF 화면 표시 속도 정도임. 복잡한 기술 문서를 읽을 때는 그리 중요하지 않고, 많은 페이지를 빠르게 넘겨봐야 할 때는 Adobe Reader가 더 빠름
Hacker News 의견