존 워녹의 PostScript와 PDF가 데스크톱 출판, 인쇄, 현대 문서 워크플로우를 어떻게 신뢰할 수 있게 만들었는지 평이하게 설명합니다.

PostScript와 PDF 이전에는 “문서를 보낸다”는 말이 종종 제안서를 보내는 것과 같았습니다. 동일한 페이지가 컴퓨터, 프린터, 설치된 폰트, 심지어 상대편의 용지 처리 하드웨어에 따라 다르게 보일 수 있었습니다.
문서를 특히 취약하게 만든 몇 가지 요인이 있었습니다:
이 문제는 존 워녹이 집중한 지점입니다: 신뢰 가능한 페이지 출력. ‘대충 비슷한’ 것이 아니라 예측 가능한 결과—한 시스템에서 디자인한 페이지가 다른 시스템에서 같은 모양, 간격, 타이포그래피로 인쇄되게 하는 것.
간단히 말하면:
이 가이드는 비전문 독자에게 현대 문서의 배경을 설명합니다: 출판과 인쇄가 어떻게 신뢰성을 얻었는지, “PDF로 저장”이 왜 자주 작동하는지, 그리고 PostScript와 PDF가 파일을 어디서나 동일하게 동작하게 만드는 것에 대해 무엇을 가르쳐 주는지.
존 워녹은 컴퓨터 과학자로, 초기 경력에서 아주 실용적인 문제에 대해 많이 생각했습니다: 페이지를 어떻게 기술하면 매번, 어떤 종류의 기기에서든 동일하게 인쇄되는가.
어도비 이전에는 제품이 나오기 훨씬 전에 아이디어를 탐구하던 연구 환경에서 일했습니다. 1970년대 Xerox PARC에서는 네트워크 프린터, 그래픽 인터페이스, 복잡한 페이지를 표현하는 방법을 실험하던 팀들이 있었습니다. 인쇄는 단순히 “프린터에 텍스트를 보내는 것”이 아니었고, 폰트, 선, 도형, 이미지 등을 섞어 신뢰성 있게 처리해야 했습니다.
핵심 문제는 불일치였습니다. 한 시스템에서 만든 문서는 화면에서는 올바르게 보이지만 해상도, 폰트, 기능이 다른 다른 장치에서 인쇄하면 망가지는 일이 잦았습니다. 기업, 출판사, 디자이너에게 그 불일치는 곧 비용—재인쇄, 지연, 수작업 수정—으로 이어졌습니다.
장치 비종속 출력은 특정 프린터가 어떻게 그려야 하는지를 설명하지 않고, 페이지가 무엇인지(예: “이 문단을 이 위치에 이 폰트로 배치”, “0.5포인트 선을 그려라”, “이 색으로 채워라”)를 설명한다는 뜻입니다. 프린터(또는 다른 인터프리터)는 그 설명을 받아 자신이 실제로 찍을 수 있는 도트로 변환합니다.
워녹은 이 접근법을 연구에서 일상 도구로 밀어 넣었습니다. 1982년 어도비를 공동 설립하면서 그는 동료들과 함께 서로 다른 시스템에서 실행되고 다양한 프린터를 구동할 수 있는 소프트웨어로 페이지 설명 아이디어를 패키지화했습니다. 중요한 것은 단일 발명 그 자체가 아니라—기술적 개념을 컴퓨터와 인쇄 페이지 사이의 신뢰할 수 있는 다리로 바꿨다는 점입니다.
PostScript는 페이지 설명 언어로, 호환 가능한 어떤 프린터라도 같은 방식으로 페이지를 그릴 수 있도록 완성된 페이지를 기술하는 방법입니다.
간단한 비유: 워드 프로세서 파일이 부엌에서 만든 초안(편집 가능하고 노트와 스타일이 많은 것)이라면, PostScript는 전문 요리사에게 건네는 레시피입니다. “보기 좋게 만들어라”가 아니라 어디에 무엇을, 어떤 순서로, 어떤 분량으로 놓을지 정확히 말해줍니다.
PostScript는 인쇄 페이지의 구성 요소를 다음과 같이 기술할 수 있습니다:
매우 문자 그대로 동작하는 그리기 로봇에게 주는 지침이라고 생각하세요. 지침이 같다면 출력 장치가 데스크톱 프린터이든 고급 이미세터이든 결과는 같아야 합니다.
PostScript의 큰 혁신 중 하나는 많은 부분이 벡터 기반이었다는 점입니다: 그래픽을 픽셀 격자가 아닌 수학(선, 곡선, 채우기)으로 설명합니다.
그 결과 로고나 헤드라인, 도표는 포스터용으로 키우거나 명함용으로 줄여도 선명함을 유지합니다—픽셀을 ‘늘려서’ 생기는 흐릿한 가장자리 문제가 없습니다.
PostScript는 워드 프로세서 형식이 아닙니다. 협업 편집, 변경 추적, 텍스트의 쉽고 유연한 재배치는 목적이 아닙니다. 오히려 신뢰 가능한 인쇄를 위해 최적화된 최종 출력 기술에 가깝습니다.
PostScript 이전에는 “보이는 것이 곧 얻는 것”이란 말이 종종 “보이는 것은 희망사항”을 의미했습니다. 돌파구는 컴퓨터와 프린터가 동일한 지시를 납득할 수 있는 공유된 페이지 설명 방식이었습니다.
데스크톱 출판은 빠르게 예측 가능한 체인으로 자리잡았습니다: 작성 → 레이아웃 → 출력.
작성자는 워드 프로세서로 텍스트를 작성했습니다. 디자이너는 그 텍스트를 페이지 레이아웃 앱에 넣어 칼럼, 간격, 이미지를 배치했습니다. 그런 다음 레이아웃은 PostScript 프린터(또는 서비스 뷰로)로 보내졌고 동일한 페이지 설명을 해석해 최종 페이지를 그렸습니다.
PostScript가 페이지를 장치 비종속적으로 기술했기 때문에—도형, 텍스트, 위치, 곡선—프린터는 화면을 ‘추정’하는 대신 정밀한 그리기 명령을 실행했습니다.
PostScript를 지원하는 프린터는 사실상 소형 출판 엔진이었습니다. 벡터 그래픽을 깔끔하게 렌더링하고 요소를 정확히 배치하며 작업 간 일관된 페이지를 출력할 수 있었습니다.
그 일관성 덕분에 레이아웃 결정은 신뢰할 만해졌습니다: 화면에 머리글이 맞으면 인쇄물에서도 머리글이 맞을 가능성이 훨씬 높았습니다. 이런 신뢰성이 브로셔, 뉴스레터, 매뉴얼, 광고 등에서 데스크톱 출판을 실용적으로 만들었습니다.
타이포그래피는 전문 출판에서 핵심이며, PostScript는 다양한 크기에서 선명하게 인쇄되는 스케일러블 아웃라인 폰트를 지원했습니다.
하지만 오류는 여전히 발생했습니다:
그럼에도 PostScript는 가장 큰 혼란 원인을 줄였습니다: 프린터가 더 이상 문서를 ‘자기 방식대로’ 해석하지 않고 페이지 설명을 따랐습니다.
상업 인쇄는 단순히 “파일을 보내고 인쇄 버튼을 누른다”가 아닙니다. 프리프레스는 문서를 검사하고 준비해 프레스가 안정적으로 재현할 수 있는 형태로 변환하는 단계입니다. 가장 큰 우선순위는 예측 가능성입니다: 같은 작업이 오늘, 내일, 다른 기계에서도 동일하게 보여야 합니다.
인쇄소는 몇 가지 실용적인 결과를 중요하게 생각했습니다:
이 요구들은 페이지를 장치 비종속적으로 기술하는 형식으로 모두를 몰아갔습니다. 페이지 설명이 완전하면—폰트, 벡터, 이미지, 색상 지시까지—프린터는 더 이상 ‘어떻게 렌더링할지’ 추측하지 않습니다.
수년간 전형적인 패턴은 다음과 같았습니다: 디자인 앱이 PostScript를 생성하면 인쇄소는 이를 RIP을 통해 처리했습니다. RIP(래스터 이미지 프로세서)는 페이지 설명을 특정 프린터나 이미세터가 출력할 수 있는 픽셀 기반 데이터로 변환하는 소프트웨어나 하드웨어입니다.
이 중간 단계는 해석을 중앙집중화했기 때문에 중요했습니다. 프린트 제공자는 특정 프레스, 용지, 스크리닝 방식, 잉크에 맞추어 조정된 통제된 RIP 환경에서 작업을 실행할 수 있었습니다.
예측 가능성이 목표라면 반복성은 사업적 이점이 됩니다: 재인쇄 감소, 분쟁 축소, 빠른 턴어라운드—전문 인쇄가 요구하는 바로 그것입니다.
PostScript는 인쇄에 큰 혁신을 가져왔지만 ‘아무에게나 보내기 쉬운’ 문서 형식으로 설계되지는 않았습니다. PostScript 파일은 본질적으로 페이지를 기술하는 프로그램입니다. 프린터(또는 이미지세터)가 올바른 인터프리터를 갖추고 있다면 잘 작동하지만, 일상적인 공유에서는 보기 일관성이 떨어지고 장치마다 출력이 달라질 수 있으며 파일이 어디서나 신뢰되게 열리는 자급식 문서처럼 행동하지 않았습니다.
PDF는 문서를 실용적으로 휴대 가능하게 만들기 위해 만들어졌습니다: 배포하기 쉽고, 열기 쉽고, 렌더링이 예측 가능하도록. 목표는 단순히 ‘인쇄된다’가 아니라 ‘어디서나 동일하게 보인다’였습니다—다른 화면, 다른 프린터, 다른 운영체제에서.
중요한 변화는 문서를 단일 패키지로 취급한 점입니다. 외부 요소에 의존하는 대신 PDF는 (또는 통제된 방식으로 참조하는) 재현에 필요한 것을 포함할 수 있습니다:
이 패키징이 바로 PDF가 수년 후에도 페이지 수, 간격, 타이포그래피를 정확히 보존할 수 있는 이유입니다.
PDF는 두 세계를 잇습니다. 화면 표시를 위해 빠른 렌더링, 검색, 하이퍼링크, 주석을 지원하고, 인쇄를 위해서는 정밀한 기하 정보와 전문 워크플로우에 필요한 정보(폰트, 스팟 컬러, 트림 박스 등)를 담을 수 있습니다. 결과적으로 PDF는 ‘최종 문서’처럼 동작하며, 단순히 장치에 따라 다르게 해석되는 명령어 집합이 아닙니다.
PostScript와 PDF는 둘 다 페이지를 기술한다는 점에서 같은 맥락에서 자주 언급됩니다. 하지만 서로 다른 목적을 위해 만들어졌습니다.
PostScript는 페이지 설명 언어입니다—“이 폰트를 사용하라”, “이 곡선을 그려라”, “이 이미지를 여기 배치하라”, “이 크기로 인쇄하라” 같은 명령의 집합입니다. PostScript를 지원하는 프린터(또는 RIP)는 그 명령을 실행해 최종 출력물을 만듭니다.
이 때문에 PostScript는 역사적으로 인쇄 분야에 잘 맞았습니다: 단순한 컨테이너가 아니라 페이지를 어떻게 렌더링할지에 대한 정밀한 레시피입니다.
PDF는 문서를 보고, 교환하고, 주석 달고, 보관할 때 일관된 모양을 유지하도록 설계된 파일 형식입니다. 프로그램처럼 ‘실행’되는 대신 PDF는 보통 뷰어(아크로뱃, 브라우저, 모바일 앱)에 의해 표시를 위해 해석되며 인쇄도 가능합니다.
일상적으로 말하면: PostScript는 ‘프린터 지시서’에 가깝고 PDF는 ‘보내는 문서’에 가깝습니다.
PostScript는 특히 전용 RIP와 프린트 서버가 들어오는 작업을 처리하는 전문 인쇄 및 프리프레스 워크플로우의 배후에서 여전히 사용됩니다.
PDF는 레이아웃을 보존해야 하는 최종 문서(계약서, 매뉴얼, 양식, 교정본)를 공유하기 위한 기본 형식입니다—어디서나 쉽게 열 수 있기 때문입니다.
| 항목 | PostScript | |
|---|---|---|
| 무엇인가 | 언어(그리기/인쇄 명령의 집합) | 파일 형식(패키지화된 문서) |
| 주된 목적 | 프린터/RIP에서의 신뢰 가능한 페이지 출력 | 일관된 보기, 교환, 보관 |
| 강점 | 렌더링에 대한 정밀 제어; 인쇄 지향 | 휴대성; 뷰어 친화적; 양식, 링크, 접근성 지원 |
| 일반 사용자 | 인쇄소, 프리프레스, 프린트 서버 | 모든 사람: 기업, 디자이너, 출판사, 고객 |
한 가지만 기억하세요: PostScript는 페이지를 생산하도록 만들어졌고, PDF는 페이지를 전달하도록 만들어졌습니다.
PDF는 조용히 문서의 “최종 형태”가 되었습니다: 다른 사람에게 정확히 보이는 것을 보여주고 싶을 때 보내는 버전입니다. 많은 직장에서 워드 파일과 슬라이드 덱이 초안 도구로 남아 있지만, PDF는 승인, 이메일 첨부, 포털 업로드, 또는 기록 보관의 체크포인트가 되었습니다.
큰 이유는 예측 가능성입니다. PDF는 레이아웃, 폰트, 벡터 그래픽, 이미지를 하나의 패키지로 묶어 장치와 앱 간에 대개 동일하게 동작합니다. 이는 동일한 환경을 공유하지 않는 팀 간의 인수인계를 이상적으로 만들어주었습니다.
조직들이 Mac과 Windows(나중에는 서버와 대학의 Linux 시스템)를 섞어 사용하면서 PDF는 “내 컴퓨터에서는 다르게 보인다” 문제를 줄였습니다. 한 도구로 문서를 만들고 다른 도구로 검토하며 또 다른 곳에서 인쇄하더라도 의도치 않은 변경이 줄어들었습니다.
이로 인해 워크플로우를 표준화하기 쉬워졌습니다:
‘휴대 가능하고 예측 가능한 출력’이라는 동일한 아이디어는 현재 견적서, 송장, 감사 보고서, 배송 라벨, 온보딩 팩 등 필요시 생성되는 내부 앱에도 나타납니다.
팀이 이러한 시스템을 구축한다면 PDF 생성을 일급 워크플로우로 취급하는 것이 도움이 됩니다: 일관된 템플릿, 임베디드 폰트, 반복 가능한 내보내기 설정, 템플릿 업데이트로 레이아웃이 깨질 때 되돌릴 수 있는 방법 등을 갖추세요. 이런 맥락에서 Koder.ai와 같은 플랫폼은 자연스럽게 어울릴 수 있습니다: 채팅 인터페이스로 내부 문서 포털이나 PDF 생성 마이크로서비스를 빠르게 코드화하고, 플래닝 모드와 스냅샷/롤백을 이용해 안전하게 반복하며 필요 시 소스 코드를 내보내 완전한 소유권을 확보할 수 있습니다.
PDF는 많은 양의 양식과 통지서를 처리하는 기관에 도움이 되었습니다. 정부는 신청서와 공문에 PDF를 채택했고, 학교는 강의계획서와 제출물, 패킷에 사용했으며, 기업은 송장, 매뉴얼, 준수 기록에 의존했습니다. 중요한 문서라면 ‘PDF가 있다’는 기대가 형성되었습니다.
PDF가 자동으로 접근성을 보장하지는 않습니다. 화면 낭독기는 적절히 태그된 구조, 의미 있는 읽기 순서, 그래픽에 대한 대체 텍스트를 필요로 합니다. 양식도 사용하기 쉽게 설계되어야 합니다—채울 수 있는 필드, 검증, 호환성 테스트 등이 필요합니다. PDF는 문서를 완벽하게 보존할 수 있지만, 그 문제점도 그대로 보존하므로 사용성을 고려해 설계해야 합니다.
대부분의 “파일이 다른 기기에서 다르게 보인다” 문제는 레이아웃 자체가 아니라 보이지 않는 재료들, 즉 폰트, 색 정의, 이미지 데이터 때문입니다. PostScript와 이후의 PDF는 이러한 요소들을 더 통제할 수 있게 했지만, 올바르게 패키징할 때만 효과적입니다.
과거엔 문서가 폰트를 참조만 하고 따라오지 않아 골칫거리였습니다. 프린터나 다른 컴퓨터에 동일한 폰트 버전이 없으면 텍스트가 재배치되거나 대체 폰트가 들어가곤 했습니다.
PDF는 폰트 임베딩을 허용해 이 문제를 많이 해결했습니다: 폰트(또는 필요한 글자 집합)를 파일 안에 포함하면 폰트가 문서와 함께 이동해 문서가 안정적으로 유지됩니다.
화면은 빛을 혼합하므로 RGB(빨강, 초록, 파랑)를 사용합니다. 인쇄는 잉크를 혼합하므로 보통 CMYK(시안, 마젠타, 옐로, 블랙)를 사용합니다. 화면에서 아주 밝은 색은 잉크로 재현할 수 없을 수 있어 RGB를 CMYK로 변환하면 색이 탁해지거나 이동할 수 있습니다.
예측 가능한 워크플로우에서는 이 변환을 ‘언제’와 ‘어떻게’ 할지 결정합니다. 자동으로 마지막 순간에 변환되게 두지 마세요.
인쇄용 이미지는 최종 크기에서 충분한 해상도를 가져야 합니다. 너무 낮으면 흐릿하고 블록 현상이 발생하고, 너무 높으면 파일이 무거워 작업이 느려집니다.
압축도 마찬가지입니다:
인쇄소에 파일을 보내기 전에 확인하세요: 폰트 임베딩, 의도한 색상 모드(RGB vs CMYK), 최종 크기에서의 이미지 해상도, 중요한 사진이나 그라데이션에서 압축 아티팩트가 보이지 않는지.
PostScript가 페이지를 정밀하게 기술할 수 있음을 증명했다면, PDF는 문서가 일관되게 해석되도록 필요한 규칙들을 함께 담을 수 있다는 점을 한 단계 더 끌어올렸습니다. 표준화는 “내 컴퓨터에서 열리나?”와 “수년 후에도 신뢰할 수 있게 보일까?”의 차이입니다.
표준은 기본적으로 공유된 계약입니다: 폰트를 참조하는 방식, 색상을 정의하는 방식, 이미지를 임베드하는 규칙, 허용되는 기능들 등. 모두가 동일한 계약을 따를 때 문서는 앱, 운영체제, 프린터, 서비스 제공자 간의 인수인계를 무사히 통과합니다.
이 예측 가능성은 원 작성자, 소프트웨어 버전, 폰트 라이브러리가 더 이상 없을 때 특히 중요합니다.
조직은 시간이 지나도 읽기 쉽고 시각적으로 안정적인 기록을 보관해야 할 때가 많습니다: 서명된 양식, 보고서, 기술 매뉴얼, 송장, 라벨, 규제 통신 등. 표준은 ‘준수를 보장’하지는 않지만, 파일을 자급식으로 만들어 검증하기 쉽게 해 모호함을 줄입니다.
PDF/A는 아카이빙에 초점을 맞춘 PDF 버전입니다. 화려한 기능보다 장기 가독성을 우선하는 규칙 집합으로 생각하세요. 일반적으로 폰트 임베딩, 신뢰할 수 있는 색상 정의를 요구하고 외부 리소스나 동적 콘텐츠(예: 특정 암호화나 동적 요소)를 피합니다.
다음 상황에서 표준화된 PDF 접근을 고려하세요:
실용적 다음 단계는 내부 내보내기 체크리스트를 정의하고 실제 문서 몇 건으로 테스트해 정책화하기 전 문제를 잡는 것입니다.
PDF는 ‘최종’처럼 느껴지지만 대부분의 문제는 예측 가능한 몇 곳에서 옵니다: 이미지, 페이지 기하, 색상 설정, 폰트. 이를 초기에 잡으면 시간, 재인쇄, 당황스러운 막판 수정을 줄일 수 있습니다.
거대한 PDF는 보통 압축되지 않은 이미지나 실수로 임베드된 중복 이미지 때문에 발생합니다.
흐릿함은 거의 항상 작은 이미지의 확대 때문입니다.
페이지 박스는 혼동을 줍니다: PDF는 화면에서 올바르게 보여도 트림/블리드 설정이 틀릴 수 있습니다.
재사용 가능한 단계별 내보내기 체크리스트는 /blog/pdf-export-checklist를 참조하세요.
PostScript와 PDF는 단순한 ‘파일 형식’이 아니었습니다. 그것들은 약속이었습니다: 페이지를 충분히 명확히 기술하면 다른 프린터, 다른 컴퓨터, 그리고 수십 년 후에도 충실히 재현될 수 있다는 약속입니다.
두 가지 아이디어는 특히 오래 견뎌냈습니다: 장치 비종속성(문서를 한 기기에 묶지 마라)과 충실성(당신이 승인한 것이 다른 사람에게도 보이고 인쇄되도록 하라). 모든 것이 ‘디지털’이더라도, 이런 보장들은 비싼 반복 작업, 재작업, 오해를 줄여줍니다.
많은 콘텐츠가 이제 웹 우선입니다: 반응형 레이아웃, 지속적 업데이트, 협업 중심. 동시에 접근성(실제 텍스트, 태그된 구조, 읽기 순서)과 채널 간 재사용 가능한 구조화된 콘텐츠에 대한 기대가 높아지고 있습니다.
그렇다고 PDF가 사라지는 것은 아닙니다—언제를 사용하는지가 바뀔 뿐입니다.
PDF는 신뢰할 수 있는 인수인계 형식이기 때문에 웹 도구와 공존합니다: 승인, 계약, 규제 기록, 최종 디자인 패키지, 또는 프린터에 보낼 파일 등에서 유용합니다. 웹 페이지는 읽기와 공유에 좋고, PDF는 의도를 고정(freeze)하는 데 좋습니다.
확실치 않다면 ‘순간(모멘트)’에 가장 잘 맞는 형식을 선택하세요: 초안, 협업, 승인, 게시, 보관. 이 간단한 프레임은 워녹의 페이지 설명 유산에서 얻을 수 있는 지속 가능한 교훈입니다.
문서가 수신자의 환경에 의존했기 때문입니다.
장치 비종속 출력은 특정 프린터의 특성(어떻게 찍는지)을 설명하지 않고, 페이지가 무엇인지(폰트, 도형, 좌표, 색상 등)를 기술한다는 뜻입니다.
호환되는 프린터나 인터프리터가 그 설명을 받아 자신이 찍을 수 있는 도트로 변환해도 의도한 배치와 기하학적 형태는 유지됩니다.
PostScript는 페이지를 그리기 위해 프린터나 RIP에게 정확히 무엇을 할지 지시하는 페이지 설명 언어입니다.
텍스트, 벡터 도형, 이미지의 정밀 배치를 잘 다루어 신뢰할 수 있는 인쇄 출력을 목표로 하지만, 협업용 편집 가능한 문서 형식으로 설계되지는 않았습니다.
벡터 그래픽은 픽셀 그리드 대신 수학(선, 곡선, 채우기)으로 기술됩니다.
그래서 로고나 도형, 활자는 크기를 키우거나 줄여도 선명함이 유지되어 데스크톱 출판과 전문 인쇄에서 큰 이점이었습니다.
RIP(Raster Image Processor)는 PostScript나 PDF 같은 페이지 설명을 받아 특정 이미세터나 프린터가 출력할 수 있는 픽셀 기반 래스터 데이터로 변환하는 장치(하드웨어 또는 소프트웨어)입니다.
인쇄소는 RIP을 통해 해석을 통제된 환경에서 수행해 작업 간 반복성을 높이고 비용이 큰 예상치 못한 문제를 줄였습니다.
PostScript가 이미 있었지만 PDF는 문서를 누구에게나 쉽게 보내고 예측 가능한 방식으로 렌더링되게 하기 위해 만들어졌습니다.
PostScript가 페이지를 그리는 ‘프로그램’인 반면, PDF는 인쇄와 화면 표시를 안정적으로 재현하는 데 필요한 요소들을 번들로 담아 배포하기 쉬운 문서 패키지입니다.
요약하자면: PostScript는 ‘프린터를 위한 지시서’에 가깝고, PDF는 ‘보내는 문서’에 가깝습니다.
실무적으로:
폰트 임베딩은 폰트 데이터(또는 필요한 글자들)를 PDF 내부에 포함시키는 것입니다.
폰트가 문서와 함께 이동하면 대체가 발생하지 않아 간격과 줄 바꿈이 변하는 일을 막아 문서의 페이지 구성과 타이포그래피를 유지합니다.
프린터의 요구사항을 우선 확인한 뒤 보이지 않는 요소들을 점검하세요.
재사용 가능한 프로세스를 만들려면 /blog/pdf-export-checklist를 참고하세요.
장기적인 일관성이 대화형 기능보다 더 중요할 때 PDF/A를 고려하세요.
아카이빙용으로 설계되어 폰트 임베딩, 신뢰할 수 있는 색상 정의 등을 요구하고 외부 리소스나 동적 동작에 의존하는 요소를 피합니다.