llms.txt(머신 리더블 인덱스)를 먼저 가져온 후, 필요한 개별 .md 파일을 순차적으로 조회하는 방식으로 활용할 수 있음commands-index.md)와 개별 커맨드 문서(commands/content/commands/)로 구성되며, github.com/redis/docs의 미러임xmax 값만 설정해 데드 튜플(Dead Tuple) 이 누적됨pgstattuple 익스텐션의 dead_tuple_percent로 측정할 수 있으며, 인덱스도 데드 튜플을 가리키는 항목이 남아 인덱스 블로트가 별도로 발생함REINDEX INDEX CONCURRENTLY로 해결할 수 있으며, 일반 REINDEX는 테이블을 완전히 잠그므로 운영 중에는 CONCURRENTLY 옵션 사용을 권장함autovacuum_vacuum_scale_factor, autovacuum_vacuum_threshold 등을 개별 튜닝해야 함pg_repack을 활용할 수 있음try / finally 패턴에 의존했으며, 이는 장황하고 실수하기 쉬운 코드를 만들어 왔음using 키워드를 사용하면 스코프를 벗어날 때 리소스가 자동으로 정리되며, try / finally 없이도 누락 없는 정리가 보장됨Symbol.dispose(동기)와 Symbol.asyncDispose(비동기) 심볼을 구현하는 방식으로 활성화(opt-in)되며, 각 라이브러리의 정리 방식을 표준화함await using을 사용하며, 스코프 종료 시 정리 완료까지 대기한 후 다음 코드로 진행함using으로 선언하면 정리가 역순(스택 방식) 으로 자동 수행되어, 기존의 수동 정리 순서 관리 부담이 사라짐using이 적합하지 않은 유연한 상황에서는 DisposableStack / AsyncDisposableStack을 사용하여 동일한 안전성을 확보할 수 있음try / finally를 완전히 대체하는 것이 아니라 더 나은 기본값을 제공하며, 보일러플레이트 감소, 리소스 누수 방지, 코드 가독성 향상에 기여함value += (target - value) * factor 수식을 매 프레임 적용해 목표값이 실시간으로 바뀌는 상황에서도 자연스러운 감속 곡선을 만들 수 있음stiffness와 damping 두 파라미터만으로 탄성 있는 다양한 움직임을 구현함(t % period) / period로 0→1 단방향 반복을 구현하며, 펄스·핑 등 "시작→끝→즉시 리셋" 패턴에 활용됨Content-Type 및 Accept 헤더를 사용하거나 URL에 출력 형식을 명시하여 다양한 방식으로 API 호출 가능함fract() 함수로 UV 좌표를 타일링하여 각 셀이 자체 원을 그리도록 구현ColorOut = (Ir, 0, 0) + (0, Ig, 0) + (0, 0, Ib))ColorOut = White * (1.0 - C) * (1.0 - M) * (1.0 - Y))brew install 또는 curl 스크립트로 설치 가능하며, 전역 또는 프로젝트 로컬 설치 모드 지원peon toggle/pause/resume: 음성 알림 일시 정지/재개peon packs use/next/list: 음성 팩 전환 및 목록 조회peon notifications on/off: 데스크톱 알림 토글peon preview: 특정 카테고리 또는 전체 사운드 미리듣기peon relay --daemon)를 통해 오디오와 알림을 전송peon mobile ntfy <topic>)config.json)을 통해 볼륨, 카테고리별 활성화, 팩 로테이션, 짧은 작업 무음 기간 등 세부 조정 가능● project: done), 데스크톱 알림(터미널이 포커스되지 않을 때만), 반복 방지 로직, 스팸 감지(10초 내 3회 이상 프롬프트 시 user.spam 음성 재생) 등 부가 기능 제공/peon-ping-toggle 슬래시 명령 또는 자연어로 설정 변경 가능("enable round-robin pack rotation", "set volume to 0.3" 등)postcode.map.daum.net에서 확인 가능하며, 2026년 3월 10일(화) 이후 postcode.map.kakao.com으로 이전 예정t1.daumcdn.net에서 t1.kakaocdn.net으로 변경 완료되었으며, 기존 도메인도 당분간 사용 가능하나 신규 도메인 사용 권장postcode.map.daum.net에서 postcode.map.kakao.com으로 변경되며, 변경 후 일정 기간 병행 운영 예정daum.Postcode에서 kakao.Postcode로 변경됨daum.Postcode는 강제 변경되지 않으며 오랜 기간 호환성 유지 목표로 지원하지만, 신규 개발 시 kakao.Postcode 사용 권장dmaps.daum.net, ssl.daumcdn.net은 2026년 4~5월 도메인 최종 전환 시점에 종료 예정sibling-index(), sibling-count(): 크롬과 사파리에서 안정적으로 사용 가능하며, 형제 요소 간 상대적 위치를 값으로 활용할 수 있음. transition-delay와 결합해 순차적 애니메이션 효과를 쉽게 구현 가능@starting-style과 함께 사용하면 요소가 처음 등장할 때 시간차 애니메이션 효과를 간단하게 적용할 수 있음scroll-state(): 스크롤러의 네 가지 상태(stuck, snapped, scrollable, scrolled)를 쿼리할 수 있으며, 스크롤 기반 애니메이션에 적합한 점진적 향상 기능container-type: scroll-state 지정 후 자식 요소에서 @container scroll-state()로 상태 쿼리 가능 (요소는 자기 자신은 쿼리할 수 없지만 가상 요소는 가능)position: sticky 요소가 고정되는 시점 감지, snapped 상태로 scroll-snap 정렬 활성화 시점 파악, scrollable로 콘텐츠 오버플로우 방향 감지, scrolled로 스크롤 방향에 따른 UI 제어 가능text-box: 텍스트 박스의 위아래 줄 간격을 깔끔하게 제거하여 글리프 위아래의 안전한 여백을 없애고, 베이스라인이나 x-height에 픽셀 단위로 정확한 정렬 가능text-box: trim-both cap alphabetic 한 줄로 대문자 높이 위 여백과 알파벳 기준선 아래 여백을 제거할 수 있어, 타이포그래피와 그리드 정렬에 최적화됨attr(): 타입 안정적이며 HTML 속성을 CSS에서 직접 사용 가능. 타입 체크와 기본값 포함하여 색상, 숫자 등 다양한 타입 전달 가능type() 함수로 속성 값을 허용된 키워드 목록과 비교 검증하며, 유효하지 않은 값은 자동으로 안전한 기본값으로 대체되어 HTML과 CSS 간 강력한 연결 고리 생성process-compose.yaml 파일에 간단한 YAML 스키마로 워크플로우를 정의하고 process-compose up 명령으로 실행favicon.ico (32×32, 레거시 브라우저용), icon.svg (라이트/다크 테마 지원, 현대 브라우저용), apple-touch-icon.png (180×180, Apple 기기용), PWA용 웹 매니페스트에 icon-192.png, icon-512.png, icon-mask.png (512×512, maskable) 포함@media (prefers-color-scheme: dark)를 활용해 하나의 파일로 라이트/다크 테마 모두 지원 가능rel="shortcut" (유효하지 않은 링크 관계), Opera Coast (2017년 단종)HtmlWebpackPlugin으로 캐시 버스터(파일명에 해시 추가) 생성, copy-webpack-plugin으로 favicon.ico 복사, webpack-pwa-manifest 플러그인으로 매니페스트 자동 생성favicon-dev.ico, icon-dev.svg)을 만들어 NODE_ENV에 따라 조건부로 사용while :; do cat PROMPT.md | claude-code ; done)임require-trusted-types-for CSP 정책 위반 없이 HTML 조작 가능하며, 대부분의 비동기 스크립트 요청을 <script> 태그로 전환하여 CSP 오류 방지<script type=module>과 호환되도록 개선jQuery.isArray, jQuery.parseJSON, jQuery.trim, jQuery.type, jQuery.now 등 여러 함수 제거되었으며, 네이티브 대체 함수(Array.isArray(), JSON.parse(), String.prototype.trim(), Date.now() 등) 사용 권장push, sort, splice 등 배열 메서드가 제거되었으며, 필요시 [].push.call($elems, elem) 형태로 대체 가능npm install jquery@4.0.0)을 통해 다운로드 가능하며, 업그레이드 가이드 및 jQuery Migrate 플러그인을 통해 마이그레이션 지원 제공pydantic-settings라는 별도의 패키지로 분리되었습니다/etc/.env, .env), 환경 변수, 그리고 수동 매개변수Path, HttpUrl)으로 자동으로 역직렬화하고 포괄적인 검증(범위, 허용된 값 등)을 수행합니다PydanticBaseSettingsSource를 상속하여 사용자 정의 로더를 만들 수 있습니다ConfigDict에 cli_parse_args=True를 추가하기만 하면 되는 CLI 인수 파싱 기능이 있어 argparse/click/typer가 필요 없습니다--no-flag, 위치 인수, 상호 배타적 그룹, argparse 통합이 포함됩니다SecretStr과 같은)을 표시하고 출력에서 검열하며, 접근하려면 명시적으로 get_secret_value() 호출이 필요합니다margin-top: 3px 같은 "매직 넘버" 해킹으로 취약하고 유지보수 어려운 코드 생성clamp(), rem, CSS Container Queries 등 유연한 단위와 도구 활용--spacing-large 같은 논리적 값 공유, 디자이너-개발자 간 값이 아닌 로직 동기화<|editable_region_start|> 같은 경계 마커가 7개 토큰으로 분할됨)original/updated 블록 형식이 unified diff보다 LLM이 파싱하기 쉬움을 발견.vscode/tasks.json 파일 히스토리를 조사한 결과 원격 서버에서 스크립트를 다운로드하고 실행하는 악성 명령어들을 발견함curl과 wget을 사용해 Vercel에 호스팅된 여러 도메인에서 셸 스크립트를 다운로드하고 실행하도록 설계됨/llms.txt 엔드포인트 추가 PR이 제출되었으나 거부됨llms.txt는 제안된 표준일 뿐, OpenAI, Google, Anthropic 등 주요 AI 기업들이 공식적으로 따르고 있지 않음uncompressedSize 필드에 과장된 크기(예: 실제 1KB인데 1MB로 표시)를 보내면, 서버는 큰 버퍼를 할당하지만 실제 압축 해제 후 크기를 검증하지 않아 초기화되지 않은 힙 메모리(이전 작업의 민감한 데이터 포함 가능)가 메시지에 포함됨<Tooltip> 컴포넌트는 존재해서는 안 된다는 것이 이 글의 주요 논지임<Tooltip> 컴포넌트는 너무 저수준의 추상화로, 개발자들이 의도대로 사용하지 않을 가능성이 높으며, 문서를 읽는 사람이 적고 AI도 기존 안티패턴을 재생산할 수 있음<Tooltip>이 어떤 요소에나 추가 가능하면, 문장 중간 텍스트에 표시 없이 추가되거나, 반대로 아이콘 버튼에 필요한 설명이 누락되는 등 일관성 없는 사용 사례 발생<Button>이나 <Link> 같은 상호작용 컴포넌트에 선택적 title prop 제공<IconButton>에는 필수 title prop을 요구하여 아이콘 설명 강제<InfoIcon> 컴포넌트 노출 (물음표/정보 아이콘 + 툴팁, 포커스 가능 보장)<InfoText> 컴포넌트 (점선 밑줄 등으로 시각적 구별, 키보드 상호작용 가능)<Tooltip> 컴포넌트를 공개하는 대신, 일관된 UX와 접근성을 보장하는 고수준 패턴 컴포넌트들을 제공하는 것이 더 나은 접근법이라고 강조pipx install tldr)pages/ 폴더에서 페이지를 생성하거나 편집하고 pull request를 제출하여 기여 가능rm -rf tests/ patches/ plan/ ~/ 명령어로 확인되었으며, 이는 홈 디렉토리를 나타내는 ~/ 와일드카드를 잘못 포함한 것이었습니다.--dangerously-skip-permissions 플래그나 유사한 설정의 사용이 주요 위험 요인으로 확인되었습니다.<input type="file">로 서버 업로드 없이 브라우저에서 직접 파일 열기/처리 가능하며, JavaScript로 다운로드 가능한 파일도 생성 가능query() 메서드 하나로 익숙한 CSS 문법을 사용하여 요소를 검색 가능 (예: doc.query("div.container > p.intro"))html5lib, BeautifulSoup보다 우수)pip install justhtml로 설치 가능하며, CLI 도구로 HTML 파싱, CSS 선택자 필터링, 텍스트/마크다운/HTML 형식 출력 지원react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack 패키지가 영향을 받음react-dom 사용 시에만 영향받는 패키지만 업데이트하면 되며, react와 react-dom은 업데이트하지 않아도 됨feColorMatrix, feDisplacementMap 등 SVG 필터가 cross-origin iframe에서도 작동한다는 사실을 발견feDisplacementMap을 이용한 가짜 CAPTCHA 생성으로 사용자가 민감한 코드를 재입력하도록 유도feComposite, feMorphology, feColorMatrix 등을 조합하여 텍스트 입력창의 회색 placeholder 텍스트를 숨기고 검은 텍스트만 표시feBlend와 feComposite로 모든 논리 게이트(NOT, AND, OR, XOR 등)를 구현하여 SVG 필터가 기능적으로 완전(functionally complete)해짐math.pi(ALL_CAPS 아님), unittest.setUp()(camelCase 사용), int/str(대문자 시작 안 함), re.IGNORECASE(단어 구분 없음) 등 수많은 예시가 존재하며, 역사적 이유로 "수정"하는 것은 비용 대비 효과가 없음jsonformatter.org/{id}, jsonformatter.org/{formatter-type}/{id}, codebeautify.org/{formatter-type}/{id} 등 단순하고 예측 가능한 구조satisfies is my favorite TypeScript keyword
satisfies 키워드는 타입 시스템에서 매우 유용한 기능으로, 최근 TypeScript 작업을 하며 발견한 저자의 favorite 키워드임string으로 추론됨(객체가 변경 가능하기 때문)satisfies 키워드가 더 나은 대안이 될 수 있음satisfies는 값이 특정 타입에 "최소한 할당 가능해야 함"을 보장하면서도, TypeScript가 실제 값을 기반으로 더 구체적인 타입을 추론하도록 허용함satisfies의 핵심 장점: 명시적 타입 어노테이션과 달리 TypeScript가 제공된 값을 기반으로 더 specific한 타입을 추론할 수 있게 함Person 타입을 만족하면서도 isCool: true라는 더 구체적인 literal 타입을 유지해야 하는 경우, satisfies Person을 사용하면 간단히 해결됨satisfies는 타입 안전한 방식으로 값을 캐스팅하는 것과 유사하며, 타입 체크와 정밀한 타입 추론을 동시에 달성할 수 있음satisfies에 제공된 타입이 아니라 실제 값의 타입을 기반으로 결정됨~/.config/gitlogue/config.toml를 통해 기본 테마, 타이핑 속도, 배경 설정 등 구성 가능이 글은 과거 사내 세미나에서 발표했던 내용을 다듬은 것입니다.
기획팀, 디자인팀 동료들이 폰트를 사용하면서 궁금했던 점들을 질문해 주었고, 이를 바탕으로 폰트의 기본 개념과 기술적 내용을 정리했습니다. 저 자신도 폰트에 대해 정확히 알지 못했던 부분이 많았기에, 공부하는 마음으로 준비한 발표였습니다.
발표 자료를 인터랙티브하게 만들어 실제 프레젠테이션에서 직접 텍스트를 수정하고 폰트의 다양한 특성을 시각적으로 확인할 수 있도록 구성했는데, 이 부분을 블로그 포스트로 다듬어 공개하면 많은 분께 도움이 될 것 같아 글로 옮기게 되었습니다.
세미나에서 발표한 원본 내용을 블로그 포스트 하나로 담기에는 분량이 많아, 내용을 두 개의 글로 나누어 다루기로 했습니다. 이 글에서는 폰트에 대한 기본적인 개념과 특징에 대해서만 알아볼 것이며, 웹 환경에서의 활용법과 팁 등은 별도의 글에서 소개할 예정입니다. 그러므로 이 글에서 소개하는 내용은 웹 환경에 국한되지 않고, 폰트를 사용할 수 있는 대부분의 환경에 적용될 수 있는 일반적인 내용을 다룹니다.
이 글의 내용에는 타이포그래피에 관한 내용이 포함되어 있지만, 디자인적인 측면보다는 기술적인 정의, 특징, 활용법을 중심으로 다룹니다. 또, 타이포그래피나 폰트에 대한 전문적인 지식을 바탕으로 작성된 글이 아니므로, 심도 있는 내용을 원하시는 분들께는 다소 부족할 수 있습니다.
우리는 다양한 환경에서 다양한 목적으로 폰트를 사용합니다. 폰트를 선택하고 적용하는 과정에서, 폰트의 기본 개념과 특성을 이해하지 못하면 원하는 결과를 얻기 어렵습니다. 폰트는 단순히 문자를 표시하는 도구가 아니라, 시각적 표현과 의사소통의 중요한 수단이기 때문입니다.
우리가 폰트에 대해 더 잘 이해하면 더 나은 디자인 결정을 내리고, 텍스트의 가독성과 미적 품질을 향상할 수 있습니다. 폰트로 어떤 일을 할 수 있는지, 그리고 어떻게 활용할 수 있는지 알아보겠습니다. 이를 위해 먼저 폰트의 기본 개념부터 살펴보겠습니다.
먼저 서체, 글꼴 가족, 글꼴이 무엇인지 알아보겠습니다.
일반적으로 '폰트'라고 하는 것은 서체, 글꼴 가족, 글꼴을 구분하지 않고 통칭하는 경우가 많습니다. 그러나 엄밀히 말하면, 서체와 글꼴 가족, 글꼴은 서로 다른 개념입니다.
서체란 문자의 디자인 스타일을 의미합니다. 어떠한 디자인 원칙과 미적 기준에 따라 만들어진 문자 모양의 전체 집합을 말한다고도 할 수 있습니다. 예를 들어 '나눔명조', 'Noto Sans KR' 등은 서체의 이름입니다.
나눔명조
Noto Sans KR
텍스트를 직접 수정하며 확인해 보세요.
글꼴 가족은 서체의 하위 개념으로, 동일한 서체 내에서 굵기(Weight), 이탤릭(Italic) 등을 포함한 다양한 스타일의 집합을 의미합니다. '나눔명조' 서체에는 '나눔명조 Regular', '나눔명조 Bold', '나눔명조 Extra Bold' 등을 통틀어 '나눔명조' 글꼴 가족이라고 부릅니다.
글꼴은 서체의 특정 크기와 스타일의 실제 구현체를 의미합니다. 예를 들어, '나눔명조 Bold 14px'나 'Noto Sans KR Regular 16px' 같은 것들이 글꼴에 해당합니다.
앞서 언급한 것처럼 디지털 타이포그래피에서는 이들을 엄밀하게 구분하지 않고, 모두 '폰트'라는 용어로 통칭하는 경우가 많습니다. 활판 인쇄나 사진 식자에서는 이러한 구분이 더 엄격했지만, 디지털 환경에서는 용어 간의 경계가 모호해졌기 때문입니다. 이 글에서도 앞으로 서체, 글꼴 가족, 글꼴을 구분하지 않고 '폰트'라는 용어로 통칭할 것입니다.
문자는 텍스트의 기본 단위입니다. 로마자 알파벳 'A', 'B', 'C'나 한글 'ㄱ', 'ㄴ', 'ㄷ' 같은 것들이 문자에 해당합니다.
글리프는 이러한 문자를 시각적으로 표현하는 구체적인 모양입니다. 우리가 'A'라는 문자를 화면에 표시한다고 할 때, 어떤 폰트를 사용하느냐에 따라 서로 다른 모양으로 나타납니다. 이것은 서로 다른 폰트에서는 같은 문자를 표현하는 글리프가 다르기 때문입니다.
같은 폰트 안에서도 동일한 문자를 여러 개의 글리프로 표현할 수 있다는 점에 유의하세요. 왜냐하면 같은 폰트 내에서도 글꼴에 따라 글리프의 모양이 다를 수 있기 때문입니다.
위 예시는 Wanted Sans에서 동일한 문자 'Q'와 'a'를 서로 다른 글리프로 표현한 것입니다. 강조한 문자의 모양이 확연히 다른 것을 볼 수 있습니다.
폰트마다 지원하는 문자 집합이 다르기 때문에, 특정 폰트로 표현할 수 없는 문자가 있을 수 있습니다. 이 경우 운영체제나 애플리케이션은 대체 폰트를 사용하여 해당 문자를 표현하려고 시도합니다. 그러나 대체 폰트가 없거나, 대체 폰트에서도 해당 문자를 지원하지 않을 때는 빈 사각형이나 물음표와 같은 대체 기호로 표시될 수 있습니다.
세상에는 수많은 폰트가 존재하며, 디자인 스타일, 용도, 기술적 특성 등에 따라 다양하게 분류됩니다. 여기서는 이러한 분류 중 가장 대표적인 분류인 세리프(Serif)와 산세리프(Sans Serif), 가변폭(Variable-width)과 고정폭(Monospace)에 대해서만 알아보겠습니다.
세리프 폰트는 글리프의 획 끝에 작은 장식(삐침, 꼬리)이 있는 폰트로, 전통적이고 격식 있는 느낌을 줍니다. 우리나라에서 '바탕', '명조' 등으로 부르는 폰트가 세리프 폰트에 해당합니다.
반대로 산세리프 폰트는 이러한 장식이 없는 폰트로, 현대적이고 깔끔한 느낌을 줍니다. 우리나라에서 '돋움', '고딕' 등으로 부르는 폰트가 산세리프 폰트에 해당합니다.
가변폭 폰트는 각 글리프의 너비가 일정하지 않은 폰트입니다. 대부분의 폰트가 가변폭 폰트에 해당하며, 일반적인 문서 작성이나 웹 페이지에서 사용됩니다.
고정폭 폰트는 글리프의 너비가 균일한 폰트입니다. 주로 코드 편집기나 터미널에서 사용되며, 금액을 표에 표시하는 것처럼 텍스트가 세로로 정렬되어야 하는 상황에 적합합니다. 한중일 글리프를 지원하는 고정폭 폰트는 일반적으로 한중일 글리프를 다른 글리프 대비 2배의 너비로 디자인합니다.
위 예시에서 가변폭 폰트는 각 행의 너비가 다르지만, 고정폭 폰트는 모든 행의 너비가 같은 것을 볼 수 있습니다. 특히 'D2 Coding' 폰트에서는 한글 글리프가 다른 글리프 대비 2배의 너비로 디자인된 것을 확인할 수 있습니다.
아래는 폰트의 주요 종류와 특징을 정리한 표입니다.
| 구분 | 세리프 (Serif) | 산세리프 (Sans Serif) | 가변폭 (Variable-width) | 고정폭 (Monospace) |
|---|---|---|---|---|
| 설명 | 글리프의 획 끝에 장식이 있음 | 글리프의 획 끝에 장식이 없음 | 각 글리프의 너비가 일정하지 않음 | 글리프의 너비가 균일함 |
| 예시 | 나눔명조, Times New Roman | 나눔고딕, Arial | 대부분의 일반 폰트 | D2 Coding, Consolas |
| 용도 | 인쇄물, 책, 신문 | 웹, 모바일, 현대적 디자인 | 문서 작성, 웹 페이지 | 코드 편집기, 터미널, 표 |
폰트 파일에는 여러 형식이 있지만, 가장 널리 사용되는 형식은 TrueType(TTF), OpenType(OTF), WOFF/WOFF2(Web Open Font Format)입니다.
TTF와 OTF는 웹을 제외한 대부분의 환경에서 사용되는 기본 폰트 파일 형식입니다. 두 형식 모두 OpenType 표준을 따르며, 일반적인 사용 환경에서는 체감 차이가 거의 없습니다. 어떤 형식을 선택해도 무방하지만, 폰트 제작자가 의도한 형식을 사용하는 것이 좋습니다.
두 형식 간의 장단점을 비교하자면, 저해상도에서 가독성과 곡선의 정밀도에서 약간의 차이를 보입니다. TTF는 TrueType 곡선을 사용하여 곡선 처리가 더 단순하고, 저해상도 환경에서 더 나은 가독성을 제공하는 경우가 있습니다. 반면 OTF는 CFF(Compact Font Format)라는 PostScript 기반의 곡선을 사용하여, 더 정밀한 곡선 표현을 지원하여 고해상도 환경에서 더 나은 품질을 제공합니다.
웹에서는 WOFF(Web Open Font Format)와 WOFF2를 주로 사용합니다. WOFF/WOFF2는 TTF나 OTF를 압축한 형식으로, 네트워크를 통한 전송에 최적화되어 있습니다. WOFF2는 WOFF보다 약 30% 더 나은 압축률을 제공하는 최신 형식입니다. 이전에는 웹에서 다른 형식의 폰트를 사용해야 했지만, 현재는 모든 주요 웹 브라우저가 WOFF2를 지원하므로 이 형식을 사용하는 것이 권장됩니다.
| 구분 | TrueType(TTF) | OpenType(OTF) | WOFF/WOFF2 |
|---|---|---|---|
| 특징 | TrueType 곡선 사용, 저해상도 가독성 우수 | CFF 곡선 사용, 고해상도 품질 우수 | TTF/OTF 압축 형식, 웹 최적화 |
| 적용 범위 | 데스크톱, 모바일 | 데스크톱, 모바일 | 웹 브라우저 |
폰트를 사용하면서 많이 변경하는 속성 중 하나가 바로 '크기'입니다. 그러나 우리가 폰트의 크기를 조절할 때, 실제로 어떤 기준으로 크기가 결정되는지 직관적으로 이해하기 어려운 경우가 많습니다.
폰트의 크기와 관련된 주요 개념으로는 Em Square, Baseline, x-height, Ascender, Descender, Cap height, Line height 등이 있습니다. 각 용어가 무엇을 의미하는지, 그리고 폰트의 시각적 표현에 어떤 영향을 미치는지 살펴보겠습니다.
Em Square1는 폰트에서 글리프의 크기를 정의하는 기준 길이입니다.
활판인쇄에서는 대문자 'M'의 활자 크기를 의미했기 때문에 'Em'이라는 이름이 붙었지만, 디지털 폰트에서는 더 이상 활자가 사용되지 않기 때문에 Em Square가 반드시 대문자 'M'의 크기와 일치하지는 않습니다.
Em Square의 크기는 폰트 디자이너가 설계 시 결정하며, 일반적으로 1000, 1024, 2048 같은 값을 사용합니다. Em Square의 크기는 폰트 내부의 좌표 단위로 사용되는 값입니다. 그 자체가 단위이므로, Em Square의 값에는 단위가 붙지 않습니다.
위 예시에서 직접 텍스트를 수정해 보면 Em Square의 위치가 글리프의 위치와 일치하지 않는다는 것을 알 수 있습니다. 폰트에서 Em Square는 길이 단위를 정의하는 추상적인 개념으로, 실제 Em Square의 구체적인 위치를 정의하지는 않습니다. 따라서 앞으로 이 문서에서 예시로 사용하는 Em Square의 위치는 시각적 이해를 돕기 위한 편의적인 표현이고, 실제 글리프의 Em Square의 위치를 나타내지 않습니다.
Baseline은 글리프가 배치되는 가상의 수평 기준선입니다.
대부분의 글리프는 이 선을 기준으로 정렬되지만, 일부 글리프는 Baseline 아래로 내려가기도 합니다. 소문자 'g', 'j', 'p', 'q', 'y' 같은 글리프는 Baseline 아래로 내려가는 부분(Descender)을 가지고 있습니다. 이에 대해서는 뒤에서 더 자세히 설명하겠습니다.
한편, 둥근 모양의 글리프('o', 'd', 'e' 등)는 시각적 균형을 위해 Baseline을 약간 넘어갑니다. 글리프가 Baseline에 정확히 맞춰지면 시각적으로 떠 있거나 작아 보이기 때문입니다. 이러한 디자인 기법을 Overshoot이라고 합니다.
x-height는 소문자 'x'의 높이를 의미하며, 소문자의 기본 높이를 나타냅니다.
소문자 'x'는 소문자 중에서 위아래로 돌출된 부분이 없고, 글리프가 사각형에 가까운 안정적인 모양이기 때문에 소문자의 높이를 정의하는 데 적합합니다.
x-height는 baseline부터의 거리로 정의되며, Em Square 값을 기준으로 그 수치를 결정합니다. 앞으로 설명할 Ascender, Descender, Cap height 등 다른 높이 값들도 Em Square를 기준으로 거릿값을 정하게 됩니다.
x-height가 큰 폰트는 글리프가 커 보이고 가독성이 향상되는 경향이 있습니다. 동일한 폰트를 사용하되, x-height 값을 다르게 설정한 예시를 아래에서 확인할 수 있습니다. x-height 변화에 따른 가독성 차이를 직접 확인해 보세요.
Ascender, Descender, Cap height도 x-height와 마찬가지로 Em Square를 기준으로 정의되는 높이 값입니다. 여기서는 간략히 각각을 소개하고 예시를 통해 살펴보겠습니다.
| 구분 | Ascender | Descender | Cap height |
|---|---|---|---|
| 설명 | 소문자에서 x-height를 넘어 위로 올라가는 부분의 높이 | 소문자에서 Baseline 아래로 내려가는 부분의 높이 | 대문자의 높이 |
| 예시 | 소문자 'b', 'd', 'h', 'k' 등 | 소문자 'g', 'j', 'p', 'q', 'y' 등 | 대문자 'H', 'A', 'T' 등 |
폰트에서 한중일(CJK) 문자의 글리프는 라틴 문자와 달리 Baseline과 같은 기준선이 명확하지 않습니다. 한중일 글리프의 크기와 위치는 폰트 디자이너가 라틴 문자와 시각적으로 균형 있게 보이도록 조정하며, 주로 Em Square의 중심에 맞추어 디자인됩니다.
행간은 인접한 행의 Baseline 사이 거리를 의미합니다. 폰트의 기본 행간은 Ascent, Descent, Line gap의 합으로 결정됩니다.
Line gap은 폰트 디자이너가 폰트 파일에 지정하는 이전 행의 Ascender와 다음 행의 Descender 사이의 추가 간격입니다. 폰트마다 다르게 설정되며, 0으로 설정된 폰트도 있습니다.
행간은 텍스트의 가독성과 밀접한 관련이 있습니다. 줄 간격이 넓을수록 가독성이 향상되지만, 지나치면 행 간 연결성이 떨어집니다.
위 예시에서 행간값이 변화함에 따라 실제 Baseline 간의 간격이 달라지는 것을 확인할 수 있습니다.
파란색 선으로 표시된 Line box 기준선들은 한 행의 시작 위치와 끝 위치를 나타냅니다. Line box는 Line gap을 절반으로 나누어 위아래에 추가한 영역이 됩니다. 만약 Line gap이 0이라면 Line box는 Ascender와 Descender에 딱 맞게 설정됩니다.
지금까지 알아본 용어를 정리하면 다음과 같습니다.
| 용어 | 설명 |
|---|---|
| Em Square | 폰트 내부 좌표계의 기준 격자 (1000, 1024, 2048 등) |
| Baseline | 글리프가 배치되는 가상의 수평 기준선 |
| x-height | 소문자 'x'의 높이 (소문자의 기본 높이) |
| Ascender | 소문자에서 x-height를 넘어 올라가는 부분 |
| Descender | 소문자에서 Baseline 아래로 내려가는 부분 |
| Cap height | 대문자의 높이 (보통 Ascender보다 낮음) |
| 행간 | 인접한 행의 Baseline 사이 거리 (Ascent + Descent + Line gap) |
이제 이러한 개념들을 바탕으로 폰트에서 조절할 수 있는 다양한 속성들에 대해 살펴보겠습니다.
먼저 우리가 가장 일반적으로 조절하는 속성인 크기, 굵기, 기울임부터 알아보겠습니다.
폰트의 크기를 16px로 지정한다는 것은 어떤 값을 16px로 설정한다는 뜻일까요?
폰트의 크기는 Em Square의 크기를 의미합니다. 즉, 폰트 크기를 지정한다는 것은 Em Square의 크기를 지정하는 것과 같습니다. 따라서 폰트 크기를 16px로 지정하면, Em Square의 크기가 16px로 설정됩니다.
Em Square 자체에는 단위가 없으므로, 폰트 크기를 지정할 때는 반드시 단위를 함께 명시해야 합니다. 디지털 환경에서는 주로 px 단위를 사용하지만, 인쇄물에서는 pt 단위를 일반적으로 사용합니다. 각 단위에 대한 설명은 대략적인 다음과 같습니다.
| 단위 | 이름 | 설명 |
|---|---|---|
| px | Pixel | 화면 기준 단위 |
| pt | Point | 1/72 inch, 주로 인쇄물에서 사용 |
또, 서로 다른 두 폰트를 모두 동일한 크기로 지정한다고 하더라도 글리프의 시각적 크기가 동일하다고 보장할 수는 없습니다. Em Square는 폰트 디자이너가 임의로 정하는 값이고, x-height, Ascender, Descender 등의 비율도 폰트마다 다르기 때문입니다.
위 예시에서는 Wanted Sans와 Tangerine 폰트를 각각 동일한 100px 크기로 지정했습니다. 그러므로 Em Square의 크기가 100px로 동일하지만, 글리프의 시각적 크기는 매우 다르게 나타나는 것을 볼 수 있습니다.
폰트의 굵기는 숫자로 표현되며, 일반적으로 100부터 900까지 100단위로 조절됩니다.
우리가 기본적으로 사용하는 굵기 값은 400으로, 보통(Regular) 굵기에 해당합니다. 만약 우리가 굵은(Bold) 굵기를 사용한다고 하면, 보통 700 값을 사용하게 됩니다. 하지만 만약 폰트가 제공하는 굵기 값이 더 다양하다면, 100부터 900까지 원하는 굵기를 자유롭게 선택할 수 있습니다.
반대로, 만약 폰트가 특정 굵기 값만 제공한다면, 우리가 지정한 굵기 값이 존재하지 않을 경우 가장 가까운 굵기 값으로 대체됩니다. 만약 폰트에 굵은 굵기를 제공하지 않는다면, 웹 브라우저나 운영체제 등에서는 임의로 만들어낸 가짜 굵은(Faux Bold) 굵기를 사용하게 된다는 점을 유의해야 합니다.
글리프를 오른쪽으로 기울여 표현하기 위해 우리는 보통 이탤릭으로 표현한다고 말합니다. 그러나 사실 글리프를 단순히 기울이는 방식은 오블리크라고 부르며, 이탤릭과는 구분되는 개념입니다.
이탤릭은 글리프의 형태 자체를 변경하는 별도의 스타일입니다. 15세기 이탈리아에서 유래한 이탤릭체는 필기체의 영향을 받아 글리프의 형태가 독특하게 디자인되었습니다.
그러나 일반적으로 폰트를 사용할 때는 두 가지 스타일을 구분하지 않고 모두 이탤릭이라고 부르는 경우가 많습니다. 실제로 웹 브라우저나 운영체제에서도 오블리크와 이탤릭을 구분하지 않고 모두 이탤릭 스타일로 처리하는 경우가 많습니다.
만약 폰트에 오블리크와 이탤릭 스타일 둘 다 존재하지 않는다면, 웹 브라우저나 운영체제에서는 임의로 만들어낸 가짜 이탤릭(Faux Italic) 스타일을 사용하게 됩니다.
위 예시에서 Geologica에서 제공하는 일반, 오블리크, 이탤릭2 스타일의 차이점을 확인할 수 있습니다. 특히 소문자 'a'와 'g'에서 스타일별로 글리프 형태가 어떻게 달라지는지 비교해 보세요.
OpenType은 1990년대에 Adobe와 Microsoft가 공동 개발한 폰트 기술입니다. 우리가 흔히 사용하는 크기, 굵기, 기울임 외에도 다양한 타이포그래피 기능을 지원합니다.
OpenType에서 지원하는 타이포그래피 기능들은 폰트 디자이너가 폰트 파일에 직접 정의하며, 폰트마다 다르게 지원하는 기능들이 다릅니다. 따라서 앞으로 설명하는 OpenType 기능들이 모든 폰트에서 동일하게 지원되지 않는다는 점에 주의하세요.
그런데도, OpenType으로 지원되는 기능을 사용하면, 더욱 풍부하고 미려한 타이포그래피를 구현할 수 있습니다. 여기서는 먼저 대표적으로 사용되는 OpenType 기능들을 소개하고, 예시를 통해 살펴보겠습니다.
합자는 연속된 문자를 하나의 새로운 글리프로 표현하는 기능입니다. 'ff', 'fi', 'fl', 'ffi', 'ffl' 같은 조합에서 자주 사용됩니다.
OpenType에서 합자는 네 가지로 구분되지만, 여기서는 자주 사용되는 두 가지 유형을 소개하겠습니다.
D2 Coding은 프로그래밍 연산자('>=', '!=' 등)를 합자로 처리하여 코드 가독성을 높입니다. 폰트의 목적상 기본적으로 합자가 적용되어야 하므로, Standard Ligature로 적용된 것을 확인할 수 있습니다. Wanted Sans는 Discretionary Ligature로 'ff', 'fi', 'fl' 조합을 더 미려하게 표현할 수 있도록 합자를 제공합니다.
커닝은 특정 글리프 쌍 사이의 공백을 조절하여 시각적으로 균형 있게 표현하는 기능입니다. 'AV', 'Te', 'W.' 등의 문자 조합에서 자주 사용되며, 기본적으로 활성화되어 있습니다. 커닝은 폰트 디자이너가 글리프 쌍마다 개별적으로 설정하는 값이기 때문에, 폰트마다 커닝이 적용되는 글리프 쌍이 다를 수 있습니다.
커닝을 토글 하면서 위 예시를 확인해 보세요. 커닝이 적용되지 않았을 때는 'AV', 'Te' 등의 글리프 쌍 사이 간격이 지나치게 넓어져서 어색하게 보이는 것을 알 수 있습니다.
주제에서는 약간 벗어나지만, 커닝을 주제로 하는 웹 게임도 있습니다. 커닝이 적용되지 않은 글리프 사이 간격을 직접 조절하고, 실제 정확한 커닝 값과 얼마나 가까운지 점수를 매기는 게임입니다. Kern Type에서 플레이할 수 있으니, 관심 있다면 한번 플레이해 보세요!
합자와 커닝을 포함하여, OpenType은 다양한 고급 타이포그래피 기능을 제공합니다. 위에서도 언급했던 것처럼, 폰트별로 실제로 사용할 수 있는 기능들은 폰트 디자이너가 정의하기 때문에, 폰트마다 지원하는 기능들이 다릅니다. 따라서 각 폰트의 문서나 설명을 참고하여 어떤 OpenType 기능들을 지원하는지 확인하는 것이 좋습니다.
OpenType 기능들은 4자리로 된 태그(tag)로 구분됩니다. 예를 들어, 합자 기능은 'liga', 커닝 기능은 'kern' 태그로 표현됩니다. 또, 미리 정의된 태그 외에도 폰트 디자이너가 원하는 경우 임의로 태그를 정의하여 추가 기능을 구현할 수도 있습니다.
만약 소유한 폰트가 어떤 OpenType 기능들을 지원하는지 확인하고 싶다면, FontDrop! 웹사이트를 이용해 보세요. 폰트 파일을 올리면, 해당 폰트에서 지원하는 OpenType 기능들을 확인할 수 있습니다.
여기서는 예시를 통해 몇 가지 OpenType 기능들을 살펴보겠습니다.
위 예시에서는 Wanted Sans에서 다음 네 가지 OpenType 기능들을 사용해 볼 수 있습니다.
이외에도 정말로 다양한 OpenType 기능들이 존재합니다. 더 많은 기능을 살펴보고 싶다면, Registered features (OpenType 1.9.1) - Typography | Microsoft Learn 문서를 참고하세요.
가변 폰트는 OpenType Font Variations이라고도 불리며, 2016년에 도입되어 비교적 새로운 폰트 기술입니다. 하나의 폰트 파일에 굵기, 너비, 기울기 등의 다양한 속성들을 포함할 수 있도록 설계되었으며, 폰트를 사용할 때 원하는 속성값을 지정하여 사용할 수 있습니다.
기존에는 각각의 속성값마다 별도의 폰트 파일이 필요했지만, 가변 폰트는 하나의 파일에서 다양한 속성값을 지원할 수 있기 때문에, 폰트 파일의 크기를 줄이고 관리하기 쉽게 만드는 장점이 있습니다.
가변 폰트에서는 조절할 수 있는 속성을 축(Axis)이라고 부릅니다. 각 축은 OpenType 기능과 유사하게 4자리 태그로 구분됩니다. 이러한 축 중 미리 정의된 축은 다음의 5가지가 있습니다.
| 이름 | 설명 | 축 태그 | 범위 | 기본값 |
|---|---|---|---|---|
| Weight | 굵기 | wght | 1~1000 | 400 (필수) |
| Width | 너비 | wdth | 1~ | 100 (필수) |
| Slant | 기울기 | slnt | -90~90 | 0 (필수) |
| Italic | 이탤릭 | ital | 0~1 | 0 (필수) |
| Optical Size | 시각적 크기 | opsz | 0~ | 10~16 (권장) |
위 다섯 가지 축은 가변 폰트에서 자주 사용되지만, 모든 가변 폰트가 반드시 이 축들을 모두 지원하는 것은 아닙니다. 예를 들어, 어떤 가변 폰트는 굵기 축만 지원할 수도 있고, 또 다른 폰트는 굵기 축과 너비 축만 지원할 수도 있습니다. 또, 범위와 기본값도 폰트마다 다를 수 있습니다. 따라서 사용하기 전에 해당 폰트의 문서를 참고하는 것이 좋습니다.
OpenType 기능들과 마찬가지로, 소유한 폰트가 어떤 축들을 지원하는지 확인하고 싶다면, FontDrop! 웹사이트를 이용해 보세요. 폰트 파일을 올리면, 해당 폰트에서 지원하는 축들을 확인할 수 있습니다.
폰트 디자이너는 이 외에도 필요에 따라 추가적인 축을 정의할 수 있습니다. 예를 들어 Cursive ('CRSV'), Grade ('GRAD') 등 폰트마다 고유한 축이 존재할 수 있습니다. 여기서는 위에서 소개한 다섯 가지 축을 중심으로, 가변 폰트에서 조절할 수 있는 속성들을 살펴보겠습니다.
굵기 축은 글리프의 굵기를, 너비 축은 글리프의 수평 너비(장평)를 조절하기 위한 축입니다. 아래 예시에서 굵기 축과 너비 축을 각각 조절해 보세요.
기울기 축은 글리프의 기울기(오블리크)를 조절하고, 이탤릭 축은 글리프의 이탤릭 형태를 조절합니다. 아래 예시에서 기울기 축과 이탤릭 축을 각각 조절해 보세요.
Jost*에서는 이탤릭 축 값이 0.50을 초과하면 소문자 'a'의 형태가 급격히 변경됩니다. 가변 폰트의 축 값이 연속적이더라도, 특정 임곗값에서 글리프 형태가 변경되도록 디자인할 수 있음을 알 수 있습니다.
시각적 크기 축은 폰트 크기에 따라 글리프 디자인을 최적화하기 위한 축입니다. 글리프가 작은 크기에서는 더 두껍고 명확하게, 큰 크기에서는 더 섬세하게 보이도록 조절합니다.
대부분의 환경에서는 별도로 시각적 크기 축을 조절하지 않아도 폰트 크기에 따라 자동으로 시각적 크기가 조절됩니다. 그러나 폰트를 사용할 때 시각적 크기 축을 수동으로 조절할 수도 있습니다.
두 번째 예시에서 폰트 크기가 변경될 때 자동으로 적용되는 시각적 크기 조절을 켜고 끌 수 있습니다. 시각적 크기 조절이 활성화되어 있을 때, 작은 크기와 큰 크기에서 글리프의 굵기가 비슷하게 유지되는 것을 알 수 있습니다.
위에서 설명한 축 외에도, 폰트 디자이너는 커스텀 축을 자유롭게 정의할 수 있습니다. 예를 들어, Roboto Flex는 다음과 같은 커스텀 축이 정의되어 있습니다.
이러한 커스텀 축은 다양하게 활용될 수 있으며, 폰트 디자이너가 창의적으로 정의할 수 있습니다. 더 다양한 가변 폰트의 예시를 살펴보고 싶다면, Variable Fonts를 참고하세요.
일반적으로 폰트는 텍스트를 표현하기 위해 사용되지만, 특이한 목적을 위해 설계된 폰트들도 존재합니다. 여기서는 그런 특이한 폰트 중 몇 가지를 소개하겠습니다.
색상 폰트는 글리프에 여러 색상을 적용할 수 있는 폰트입니다. 일반적인 폰트는 모든 글리프를 단색으로 표현하지만, 색상 폰트는 둘 이상의 색상을 사용하여 더 다양한 시각적 효과를 제공합니다.
가장 널리 알려진 색상 폰트의 예시는 이모지(Emoji)를 지원하는 폰트입니다.
Noto Color Emoji
텍스트를 직접 수정하며 확인해 보세요.
위 예시에서는 Noto Color Emoji를 사용하여 이모지를 표시하고 있습니다. Noto Color Emoji는 이모지에 해당하는 글리프만 포함하는 폰트이므로, 일반 텍스트를 입력하면 표시되지 않습니다.
이모지 외에도 팔레트(Palette)를 사용하여 다양한 색상을 표현하는 색상 폰트도 존재합니다.
Rocher Color는 11가지 팔레트를 제공하며, 팔레트 축을 조절하여 다양한 색상 조합을 확인할 수 있습니다. 만약 가지고 있는 색상 폰트가 어떤 팔레트를 지원하는지 확인하고 싶으시다면 Wakamai Fondue에서 폰트 파일을 올려 확인해 보세요.
아직 이모지가 널리 사용되기 전, 폰트를 텍스트 대신 그림으로 활용하는 방법이 있었습니다. 딩뱃(Dingbat) 폰트는 특정 문자를 다양한 그림으로 표현하는 폰트입니다. 예를 들어, 소문자 'a'를 입력하면 우리가 알고 있는 소문자 'a'가 아닌, 다른 그림을 글리프로 표시합니다.
동일한 텍스트가 Wanted Sans에서는 일반적인 문자의 글리프로 표시되지만, Auseklis에서는 완전히 다른 형태의 그림 글리프로 표시되는 것을 알 수 있습니다.
딩뱃과 유사하게, 특정 문자 코드에 아이콘을 매핑하여 아이콘을 표시하는 폰트도 있습니다. 이를 아이콘 폰트라고 부르며, 과거 웹에서 널리 사용되었습니다.
SVG가 웹 브라우저에서 널리 지원되기 전에는 아이콘을 다양한 크기와 색상으로 표현하기 어려웠습니다. 그래서 Font Awesome으로 대표되는 아이콘 폰트가 대중적으로 사용되었습니다. 그러나 최근에는 모든 주요 웹 브라우저가 SVG를 지원하고, SVG가 더 다양한 효과를 적용할 수 있어 아이콘 폰트의 사용이 줄어들고 있습니다.
Material Icons Round
위 예시에서는 Material Symbols & Icons - Google Fonts에서 구글이 제공하는 아이콘 폰트를 확인할 수 있습니다.
아이콘 폰트는 일반적인 키보드로 바로 입력하기 어려운 문자 코드에 대응하는 글리프로 아이콘을 표시하는 경우가 많습니다. 따라서 아이콘 폰트를 사용할 때는 아이콘의 문자 코드를 직접 입력하기보다는 해당 폰트를 제공하는 사이트의 아이콘 목록에서 복사하거나 전용 도구를 사용하는 것이 좋습니다.
그렇다고 키보드로 입력하는 것이 완전히 불가능한 것은 아닙니다. Material Icons Round의 'Home' 아이콘에 해당하는 문자는 'U+E88A'3 입니다. 직접 입력을 시도해 보고 싶다면 Unicode input 문서를 참고하여 입력해 보세요.
단순한 그림이나 아이콘을 표현하는 것이 아니라, 다른 목적으로 글리프를 특수하게 표현하는 폰트들도 있습니다.
Libre Barcode 39 Text
Libre Barcode 39 Text는 바코드 문자를 글리프로 표현하여, 바코드 스캐너로 읽을 수 있는 바코드를 생성할 수 있습니다. 위 예시에 입력된 텍스트는 '*9791158392048*'로, 바코드 39 규격에 맞게 시작과 끝에 '*' 문자가 포함되어 있습니다.
Libre Barcode 39 Text를 사용하면 특별한 바코드 생성 도구 없이도, 간단히 텍스트 입력으로 바코드를 생성할 수 있습니다.
Hymnus FG
Hymnus FG는 악보를 표현하기 위해 만들어진 폰트입니다. 특정 문자 조합으로 악보에 사용하는 음표와 쉼표 등을 글리프로 표현할 수 있습니다. 위 예시에 입력된 텍스트는 '!—-c--d--e--f-\-G-----G----\'로, 간단한 멜로디를 표현하고 있습니다.
이 외에도 Fontemon처럼 OpenType 기능(합자 등)을 활용하여 폰트 파일 안에 포켓몬 게임을 구현한 사례도 있으니, 더 흥미로운 특수 폰트를 찾아보세요!
지금까지는 폰트 자체에서 제공하는 기능들에 대해 살펴보았습니다. 하지만 동일한 폰트를 사용하는데도 불구하고, 폰트가 사용되는 환경에 따라 다르게 보이는 경우가 있습니다. 예를 들어, 동일한 폰트를 사용하는 웹 사이트에 접속할 때, macOS와 Windows에서 글리프가 다르게 보일 수 있습니다.
이러한 현상이 발생하는 이유는 운영체제, 브라우저, 디스플레이에 따라 폰트의 글리프를 화면에 그리는 방식, 즉 렌더링이 달라지기 때문입니다. 렌더링은 폰트 파일의 글리프 정보를 화면에 실제로 표시하는 과정입니다. 이 과정에서 텍스트의 크기, 스타일, 위치 등을 계산하여 디스플레이에 픽셀 단위로 표시합니다.
폰트는 글리프의 모양을 벡터로 정의합니다. 벡터는 점과 선의 수학적 좌표로 구성되어 있어, 확대하거나 축소해도 품질이 유지되어 폰트 디자이너가 의도한 글리프의 모양을 정확히 표현할 수 있습니다.
하지만 우리가 사용하는 디스플레이는 이미지를 픽셀 단위로 표시합니다. 아무리 폰트가 글리프의 모양을 정확하게 정의하더라도, 디스플레이에 표시하려면 픽셀 단위로 변환하는 과정이 필요합니다. 이 과정을 래스터화라고 부릅니다.
래스터화 과정에서 어떤 픽셀이 어떤 색으로 채워질지 결정하면서 글리프의 모양을 디스플레이에 맞게 조정합니다. 이 과정에서 운영체제와 소프트웨어마다 래스터화 방식이 달라, 동일한 폰트를 사용하더라도 래스터화된 글리프의 모양이 다르게 보일 수 있습니다.
위 예시에서 래스터화된 글리프의 모양을 확인할 수 있습니다.
위쪽 영역에는 16px 크기로 래스터화된 글리프 크게 확대하여 볼 수 있습니다. 아래쪽에서는 동일한 글리프를 100px 크기로 표시하고, 실제로 문자를 입력하며 테스트해 볼 수 있습니다.
래스터화된 글리프가 원본 글리프와 어떻게 다른지 확인해 보세요.
래스터화에서 단순히 어떤 픽셀을 채우고 비울지만 결정하면, 글리프의 경계가 거칠게 보이는 계단 현상(Aliasing)이 발생합니다. 이러한 계단 현상은 특히 곡선이나 대각선에서 두드러지게 나타나고, 글리프의 가독성을 저하합니다. 이러한 계단 현상을 완화하기 위한 기술이 안티앨리어싱입니다.
안티앨리어싱은 여러 가지 방법이 있지만, 가장 일반적인 방법은 회색조 안티앨리어싱(Grayscale Anti-aliasing)입니다. 회색조 안티앨리어싱은 글리프의 경계에 중간 밝기의 픽셀을 추가하여 계단 현상을 부드럽게 만듭니다.
위 예시에서는 회색조 안티앨리어싱이 적용된 래스터화된 글리프를 확인할 수 있습니다. 안티앨리어싱이 적용되기 전과 비교해 보면 글리프의 경계가 훨씬 부드럽게 표현된다는 것을 알 수 있습니다.
서브픽셀 렌더링은 하나의 픽셀을 구성하는 빨강, 초록, 파랑 서브픽셀을 개별적으로 제어하여 더 세밀하게 표현하는 안티앨리어싱 기법입니다.
전통적인 LCD 디스플레이의 각 픽셀은 물리적으로 RGB 세 개의 서브픽셀로 구성되어 있습니다. 서브픽셀 렌더링은 이를 독립적으로 제어하여 수평 해상도를 이론적으로 3배 증가시킵니다. 예를 들어, 글리프의 왼쪽 경계가 픽셀 중간에 위치하면, 빨강 서브픽셀만 켜서 더 정밀한 위치를 표현할 수 있습니다.
위 예시에서는 서브픽셀 렌더링이 적용된 래스터화된 글리프를 확인할 수 있습니다.
위쪽에서는 일반적인 서브픽셀 렌더링이 적용된 글리프를 확인할 수 있습니다. 래스터화된 글리프의 왼쪽 경계는 빨간색으로, 오른쪽 경계는 파란색으로 약간 번져 보이는 것을 알 수 있습니다. 중간에서는 실제 각 픽셀을 RGB 서브픽셀로 나누고 실제 LCD 디스플레이에서 보이는 것과 유사하게 표현했습니다.
이 경우, 래스터화된 글리프의 곡선이 눈에 띄게 부드럽게 표현된다는 것을 확인할 수 있습니다. 이처럼 서브픽셀 렌더링은 저해상도 디스플레이에서 글리프의 가독성을 크게 향상합니다.
하지만 서브픽셀 렌더링은 색상 번짐 현상을 유발할 수 있습니다. 텍스트 경계에 미세한 색상 테두리가 보일 수 있으며, 특히 검은 배경에 흰색 텍스트에서 두드러집니다. 또한 RGB 배열이 아닌 PenTile이나 RGBW 같은 서브픽셀 구조를 가진 OLED 디스플레이에서는 오히려 글리프가 왜곡될 수 있으므로 주의해야 합니다.
저해상도 디스플레이에서는 래스터화 시 왜곡이 심하게 발생할 수 있습니다. 특히 글리프가 픽셀 경계에 걸치면 형태가 크게 왜곡됩니다.
힌팅은 글리프가 픽셀에 잘 맞도록 조정하는 정보를 폰트 파일에 포함하는 기술입니다. 힌팅 정보는 특정 크기에서 글리프의 줄기 두께, 대칭성, 정렬 등을 유지하도록 지시합니다.
힌팅은 주로 저해상도 디스플레이나 작은 폰트 크기에서 효과가 큽니다. 고해상도 디스플레이에서는 픽셀 밀도가 높아 힌팅의 영향이 상대적으로 적습니다.
위 예시에서는 위쪽 영역에는 힌팅을 적용하여 래스터화된 글리프를, 중간에는 힌팅을 적용하지 않은 글리프를 확인할 수 있습니다. 힌팅이 적용된 글리프가 픽셀 경계에 더 잘 맞춰져서 형태가 더 명확하게 유지되는 것을 알 수 있습니다.
폰트 형식에 따라 힌팅 지원 수준이 다릅니다. TTF 폰트가 OTF 폰트보다 힌팅 정보를 더 잘 지원합니다. TrueType은 힌팅을 위한 명령어 세트를 제공하는 반면, PostScript 기반 OTF는 더 간단한 힌팅 방식을 사용합니다. 따라서 저해상도 환경을 고려해야 하는 경우라면 TTF 폰트를 선택하는 것이 좋습니다.
렌더링 엔진은 폰트를 화면에 표시하는 소프트웨어입니다. 운영체제나 브라우저의 렌더링 엔진이 렌더링 방식을 결정합니다. 여기서는 Windows와 macOS의 렌더링 방식을 비교해 보겠습니다.
Windows는 클리어타입(ClearType)이라는 서브픽셀 렌더링을 사용하여 가독성을 최적화합니다. 1998년 Microsoft가 개발한 ClearType은 RGB LCD 디스플레이의 서브픽셀을 활용하여 텍스트를 더 선명하게 표현합니다. 특히 저해상도 디스플레이나 작은 폰트 크기에서 가독성이 크게 향상되며, 힌팅 정보를 적극적으로 활용합니다.
하지만 ClearType은 RGB 배열에 최적화되어 있어, 다른 서브픽셀 배열을 가진 디스플레이에서는 색상 번짐이나 왜곡이 발생할 수 있습니다. 또한 가독성을 우선시하기 때문에 글리프의 원래 형태가 다소 변형될 수 있습니다.
macOS는 Mojave 이후 서브픽셀 렌더링을 중단하고, 회색조 안티앨리어싱을 사용합니다. 이전 버전에서는 서브픽셀 렌더링을 사용했지만, Retina 디스플레이의 보급과 함께 단순한 회색조 방식으로 전환했습니다.
macOS의 렌더링 철학은 폰트의 원래 모양을 최대한 유지하는 것입니다. 디자이너가 의도한 글리프 형태를 충실히 재현하며, 고해상도 디스플레이에 최적화되어 있습니다. 따라서 힌팅 정보가 포함된 폰트라도 macOS에서는 힌팅이 적용되지 않습니다.
결과적으로 Windows는 가독성과 선명함을, macOS는 디자인 충실도를 우선시합니다. Windows에서는 작은 크기의 텍스트가 더 읽기 쉽지만, macOS에서는 폰트 본연의 아름다움이 더 잘 드러납니다.
| 구분 | Windows | macOS |
|---|---|---|
| 렌더링 방식 | 클리어타입 | 회색조 안티앨리어싱 |
| 서브픽셀 렌더링 | 사용 | 미사용(Mojave 이후) |
| 힌팅 적용 | 적용 | 미적용 |
| 렌더링 철학 | 가독성 우선 | 디자인 충실도 우선 |
| 특징 | 선명하고 읽기 쉬움, 형태 변형 가능 | 폰트 본연의 형태, 고해상도 최적화 |
폰트에 대해 더 깊이 이해하려면 텍스트를 빼놓고 설명할 수 없습니다. 폰트는 텍스트를 시각적으로 표현하는 도구이기 때문입니다. 여기서부터는 디지털 환경에서 텍스트가 어떻게 표현되고 처리되는지에 대해 간단히 살펴보겠습니다.
컴퓨터는 모든 데이터를 숫자로 처리합니다. 컴퓨터가 문자를 다룰 때도 마찬가지로, 각 문자에 고유한 숫자를 할당하여 컴퓨터가 인식하고 처리할 수 있도록 해야 합니다.
문자와 숫자의 대응 관계를 정의하여 컴퓨터가 문자를 이해할 수 있도록 하는 체계가 바로 문자 인코딩입니다. 예를 들어, ASCII라는 문자 인코딩에서 대문자 'A'는 65라는 숫자에 대응하도록 정의되어 있습니다.
이러한 문자 인코딩은 여러 가지가 존재하며, 인코딩마다 문자를 숫자로 매핑하는 방식이 다릅니다. 한글을 지원하는 주요 문자 인코딩으로는 CP949, UTF-8이 있습니다. 같은 문자라도 문자 인코딩에 따라 다른 숫자 값으로 표현되므로, 어떤 텍스트를 컴퓨터가 해석할 때는 텍스트가 어떤 문자 인코딩으로 작성되었는지 알아야 합니다.
| 문자 | ASCII | CP949 | UTF-8 |
|---|---|---|---|
| A | 0x41 | 0x41 | 0x41 |
| B | 0x42 | 0x42 | 0x42 |
| 1 | 0x31 | 0x31 | 0x31 |
| 2 | 0x32 | 0x32 | 0x32 |
| 안 | - | 0xBE 0xC8 | 0xEC 0x95 0x88 |
| 녕 | - | 0xB3 0xE7 | 0xEB 0x85 0x95 |
위 표는 각 문자가 ASCII, CP949, UTF-8 문자 인코딩에서 어떻게 숫자로
표현되는지 보여줍니다. 각 인코딩에서 대응하는 숫자는 16진수(Hexadecimal)로
표기되어 있습니다.
따라서 위 표에서 0x41은 16진수로, 10진수 65를 의미합니다.
알파벳과 숫자는 ASCII, CP949, UTF-8 모두에서 동일한 숫자로 표현된다는 점이 우선 눈에 띕니다. 이는 대부분의 문자 인코딩이 ASCII와 호환되도록 설계되었기 때문입니다. 따라서 로마자 알파벳과 숫자는 대부분의 문자 인코딩에서 동일한 숫자로 표현됩니다.
반면, 한글은 문자 인코딩마다 다른 숫자로 표현됩니다.
ASCII에서는 한글을 표현할 수 없습니다. 따라서 한글은 CP949와 UTF-8에서만
표현할 수 있습니다.
CP949에서는 한글을 표현하기 위해 숫자 2개를 사용해야 합니다. 위 표에서는
'안'을 표현하기 위해 0xBE, 0xC8 두 개의 숫자를 사용하고 있습니다.
그런데 UTF-8에서는 한글을 표현하기 위해 숫자 3개를 사용합니다. 똑같이 '안'을
표현하기 위해 0xEC, 0x95, 0x88을 사용하고 있습니다.
아마 자기소개서처럼 텍스트 길이의 제한이 있는 글을 작성할 때, 한글은 2바이트로 알파벳이나 숫자보다 더 많은 공간을 차지한다는 사실을 경험해 보셨을 것입니다. 이는 문자 인코딩에서 한글을 나타내기 위해 알파벳과 숫자보다 더 많은 숫자를 사용하도록 정의되어 있기 때문에 그렇습니다. 만약 입력받는 텍스트의 문자 인코딩으로 CP949를 사용하는 경우라면 한글 한 문자는 2바이트로, UTF-8을 사용하는 경우라면 3바이트로 계산하게 되는 것입니다.
현재는 대부분의 상황에서 UTF-8 문자 인코딩을 사용하고 있지만, Windows 환경에서 한국어를 사용할 때 CP949 문자 인코딩으로 작성된 텍스트를 접할 가능성이 여전히 있습니다. 따라서 텍스트를 다룰 때는 해당 텍스트가 어떤 문자 인코딩으로 작성되었는지 반드시 확인해야 합니다.
UTF-8 문자 인코딩을 설명하면서 UTF-8에서는 한글 한 문자를 표현하기 위해 숫자 3개를 사용한다고 설명했습니다. 하지만 이는 엄밀히 말하면 틀린 설명입니다. UTF-8에서 문자와 숫자를 대응하는 과정에서, 1바이트보다 큰 숫자를 사용해야 하는 경우에 처리하기 위한 규칙이 따로 존재할 뿐입니다.
UTF-8 문자 인코딩은 유니코드라고 하는 문자와 숫자의 대응 체계를 기반으로 합니다. 유니코드는 각 문자에 고유한 코드 포인트(Code point)를 할당합니다. 그리고 이 코드 포인트를 실제로 저장하고 전송하기 위한 인코딩 방식 중의 하나가 UTF-8인 것입니다. 유니코드의 코드 포인트를 사용하는 문자 인코딩은 UTF-8 외에도 UTF-16, UTF-32 등이 있지만, 대부분의 상황에서는 UTF-8이 사용되고 있습니다.
위에서 예를 들었던 '안', '녕' 이라는 문자는 유니코드에서 각각 0xC548,
0xB155라는 코드 포인트가 할당되어 있습니다.
유니코드에는 2025년 11월 현재 297,334개의 문자가 할당되어 있으며, 사실상
전 세계의 모든 문자, 기호, 이모지 등을 모두 포함하고 있습니다.
현재 대부분의 시스템에서 텍스트를 표현할 때 인코딩은 약간 달라도 유니코드를 사용하므로 문자가 깨지는 현상을 거의 발생하지 않습니다. 예를 들어, Windows와 macOS 모두 파일을 저장할 때, 파일명에 유니코드를 사용하여 저장합니다. 그런데, macOS에서 Windows로 한글 파일명을 가진 파일을 전송해 보면 Windows에서 파일명이 이상하게 표현되는 현상을 확인할 수 있습니다. 두 운영체제 모두 동일하게 유니코드를 사용하는데 왜 이런 일이 발생하는 걸까요?
유니코드에서는 한글을 표현하는 다음의 두 가지 방법이 존재합니다.
0xC548(안)0xB155(녕)0x110B(ᄋ) + 0x1161(ᅡ) + 0x11AB(ᆫ)0x1102(ᄂ) + 0x1167(ᅧ) + 0x11BC(ᆼ)macOS는 한글 파일명을 조합형으로 저장하고, Windows는 한글 파일명을 완성형으로 저장합니다. 따라서 Windows에서 macOS에서 작성한 한글 파일명을 볼 때에는 Windows에서는 사용하지 않는 조합형 한글로 보이게 되는 것입니다.
그런데, 이상한 점이 있습니다. 조합형 한글도 유니코드 표준에 정의된 문자이므로, Windows에서도 조합형 한글을 정상적으로 표시할 수 있어야 합니다. Windows 탐색기의 파일명에서는 왜 조합형 한글을 합쳐서 하나의 문자로 표시하지 않고 모든 자모를 풀어서 보여주는 걸까요?
Microsoft 개발 블로그의 글에서 그 이유를 짐작해 볼 수 있습니다. Windows 탐색기에서는 KS X 1026 표준을 이유로 조합형 한글을 합쳐서 표시하지 않는다고 합니다.4 따라서 Windows 탐색기에서 조합형 한글을 제대로 표시하려면, 조합형 한글을 완성형 한글로 변환하는 과정을 거쳐야 합니다.
유니코드에서는 이러한 과정을 정규화(Normalization)라는 방법으로 제공하고 있습니다. 유니코드 정규화는 같은 문자를 표현하는 여러 방법이 있을 때, 해당 문자를 특정 방법으로 표현하도록 변환하는 방법입니다. 유니코드 정규화 중 NFC(Normalization Form C)를 사용하면 조합형 한글을 완성형 한글로 변환할 수 있고, NFD(Normalization Form D)를 사용하면 완성형 한글을 조합형 한글로 변환할 수 있습니다.
따라서 서로 다른 운영체제 간의 파일 교환이 빈번한 환경이라면, 파일명을 유니코드 정규화(NFC)로 변환하여 저장하는 것이 좋습니다. 이를 통해 조합형 한글과 완성형 한글로 인한 파일명 깨짐 현상을 방지할 수 있습니다.
폰트를 사용할 때, 텍스트에 사용하는 모든 문자에는 대응하는 글리프가 존재할 것이라고 생각할 수 있습니다. 그러나, 디지털 환경에서 텍스트에 사용하는 문자 중에는 글리프로 표현되지 않고, 특수한 역할을 하는 문자들이 존재합니다.
가장 대표적인 예가 줄바꿈입니다. 여러 줄에 걸쳐 텍스트를 작성하기 위해서는 줄바꿈이 필수적입니다. 그러나 이러한 줄바꿈은 우리 눈에 글리프라는 형태로 보이지 않습니다. 하지만 컴퓨터는 이러한 줄바꿈을 특정한 문자로서 인식하고 처리합니다.
이러한 특수한 문자들을 제어 문자라고 부릅니다. 줄바꿈과 관련된 제어 문자는 아래의 두 가지입니다.
위 두 문자를 적절히 사용하면 텍스트의 줄바꿈을 표현할 수 있습니다.
여기서 두 문자를 '적절히' 사용한다고 표현한 이유는, 텍스트를 사용하는 환경에 따라 어떤 제어 문자를 사용해야 하는지가 달라지기 때문입니다. 대부분의 상황에서는 줄바꿈을 표현하기 위해 LF 문자 하나만 사용하면 충분합니다. 그러나 Windows의 텍스트 파일에서는 줄바꿈을 표현하기 위해 CR 문자와 LF 문자를 함께 사용해야 합니다.
이러한 이유로 인해 위에서 설명한 macOS와 Windows 간의 파일명 깨짐 현상과
마찬가지로 다른 운영체제에서 작성한 텍스트 파일(.txt)을 열 때 줄바꿈이 제대로
표시되지 않는 현상이 발생할 수 있습니다.5
위에서 언급했던 아이콘 폰트처럼 특수한 글리프를 표현하기 위해서는 어떤 문자에 아이콘 글리프를 대응시켜야 할까요? 집 모양 아이콘을 글리프로 사용할 때는 집 이모지(🏠)에 할당하면 될까요?
물론 집 모양 아이콘을 집 이모지에 대응시켜 사용할 수도 있습니다. 그러나 표현하고자 하는 모든 아이콘에 대응하는 이모지는 존재하지 않을 것이고, 아예 아이콘이 아니라 완전히 다른 기호, 새로운 언어 등을 표현하기 위한 폰트를 만들어야 한다면 완전히 다른 코드 포인트를 사용하는 게 더 좋을 것입니다.
유니코드에는 Private Use Area라는 영역을 만들어두고, 개인이 자유롭게 원하는 용도로 사용할 수 있도록 하고 있습니다. PUA 영역은 유니코드 표준에서 공식적으로 할당된 문자가 아니므로, 시스템이나 소프트웨어마다 다르게 해석될 수 있습니다.
Material Icons Round
실제로 Material Icons Round는 PUA 영역의 코드 포인트에 아이콘 글리프를 할당한
아이콘 폰트입니다.
위 예시에서는 0xE8B6, 0xE88A, 0xE5D2, 0xE5CD 코드 포인트에 각각
아이콘을 할당하여 표시하고 있습니다.
폰트를 사용하여 어떠한 작업을 할 때에는 해당 폰트를 사용할 수 있는 권한이 있는지 반드시 확인해야 합니다. 폰트는 저작권법으로 보호되는 저작물이며, 폰트 제작자나 배포처가 정한 라이선스 조건에 따라 사용해야 합니다.
폰트의 라이선스는 폰트마다 다르며, 동일한 폰트라도 사용 목적에 따라 다른 조건이 적용될 수 있습니다. 따라서 폰트를 사용하기 전에 반드시 해당 폰트의 라이선스를 확인하고, 자신이 사용하고자 하는 목적과 방법 등에 맞는지 꼼꼼히 살펴보아야 합니다.
주의: 이 글에서는 폰트 라이선스에 대한 일반적인 정보를 제공할 뿐, 법적인 조언을 제공하지 않습니다. 특정 폰트의 라이선스 조건에 대해 궁금한 점이 있거나, 법적인 문제가 발생한 경우에는 반드시 전문가의 조언을 구하시기 바랍니다.
폰트를 사용할 때 가장 주의 깊게 살펴보아야 할 라이선스 조건은 다음과 같습니다.
각 폰트의 라이선스 조건은 매우 다양하므로, 위 사항들에 대해 꼼꼼히 확인하는 것이 중요합니다.
다행히도 많은 무료 폰트는 널리 알려진 라이선스를 채택하고 있으므로, 해당 라이선스에 대한 정보를 찾아보는 것도 좋은 방법입니다. 여기서는 몇 가지 대표적인 폰트 라이선스를 소개합니다.
이 글에서 설명하는 내용은 라이선스의 주요 특징을 간략히 요약한 것이며, 정확한 라이선스 조건은 각 라이선스의 공식 문서를 반드시 참고하시기 바랍니다.
지금까지 폰트의 기본 개념부터 렌더링, 인코딩, 라이선스에 이르기까지 다양한 주제를 다루어보았습니다. 웹 폰트와 관련된 더 자세한 내용을 추후 작성될 별도 글에서 다룰 예정이니, 많은 관심 부탁드립니다.
Em Square는 Em Quad라고도 불리며, 단순히 Em이라고도 합니다. 이 글에서는 더 익숙하고 시각적으로 이해하기 쉬운 Em Square라는 용어를 사용하겠습니다. ↩
사실 Geologica는 별도의 이탤릭 스타일을 별도로 제공하지 않지만, Cursive 기능을 사용하여 유사한 효과를 낼 수 있습니다. 이 예시에서는 Cursive 기능과 오블리크를 함께 적용하여 이탤릭 스타일을 표현했습니다. ↩
'U+E88A'는 더 뒤에서 설명할 유니코드 문자를 나타내는 방식이며, Private Use Area (PUA) 영역에 속하는 문자입니다. ↩
사실 Microsoft 포스트에 작성된 댓글의 내용을 참고해 보면, Microsoft가 표준의 내용을 잘못 이해한 것일 수도 있다는 의혹이 제기되고 있습니다. KS X 1026-1 표준과 Unicode UAX #29 표준에 따르면 조합형 한글을 합쳐서 표시하는 것이 맞습니다. ↩
Windows 11의 메모장은 이제 자동으로 어떤 줄바꿈 문자를 사용했는지 인식하여 올바르게 표시합니다. 그러나 여전히 일부 텍스트 편집기에서는 줄바꿈 문자를 올바르게 처리하지 못하는 경우가 있으므로 주의해야 합니다. ↩
2^53-1보다 큰 정수는 정밀도를 잃지만, Python과 Java는 큰 정수를 올바르게 처리함. Go는 interface{}로 언마샬할 때 정밀도를 잃지만 명시적 타입 사용 시 정확함null, undefined, 없는 키를 구분하지만 Python과 Go는 null과 없는 키를 모두 None/nil로 처리하여 의미적 차이를 구분할 수 없음id와 id_str 둘 다 제공, PostgreSQL의 JSON은 원본 유지하지만 JSONB는 정규화, MongoDB는 Extended JSON으로 추가 타입 지원@font-face 등장(포맷/라이선스 혼란) → Typekit/Google Fonts 등장으로 편의성 확보, 하지만 성능/프라이버시 문제 발생font-display 설정에 따라 FOIT/FOUT 발생unicode-range로 실제 사용하는 글리프만 제공(수백 KB 절약 가능)font-display: swap 기본 사용, size-adjust/ascent-override/descent-override로 폴백 폰트 메트릭 조정하여 CLS 제거<link rel="preload" as="font" crossorigin>로 중요 폰트를 즉시 요청, @font-face 선언은 <head>에 인라인-apple-system, BlinkMacSystemFont, Segoe UI, Roboto 등 시스템 폰트로 빠르고 안정적인 렌더링 가능. 폴백 설계도 신중히Apple Color Emoji, Noto Color Emoji 등)font-display: swap, 시스템 폴백 메트릭 조정, SVG 아이콘 전환, 글로벌 스크립트 테스트, DevTools/Lighthouse로 성능 측정main을 호출함extract_kernel 함수가 커널을 압축 해제(gzip, xz, zstd 등)하고 ELF 헤더를 읽어 각 섹션을 올바른 위치에 복사하며, 커널이 다른 주소에 로드된 경우 relocation을 적용하여 포인터와 주소를 수정함start_kernel 함수로 점프하여 본격적인 초기화가 시작되며, 문서 말미에 hexadecimal, register, segment, BIOS/UEFI, paging, ELF 등 핵심 용어에 대한 북마크 가능한 glossary를 제공함SELECT ... FOR UPDATE SKIP LOCKED 기능으로 큐로 활용하고, 데이터베이스 특성상 상태 저장에도 사용할 수 있음ctx.sleep()으로 특정 시간 동안 대기하거나, ctx.waitForEvent()로 이벤트를 기다릴 수 있으며, 이벤트는 캐시되어 race-free 보장.sql 파일만 데이터베이스에 적용하면 되고, SDK는 언어별 편의성을 제공하는 얇은 래퍼 역할만 수행npm install mediabunny로 설치하거나 script 태그로 직접 포함 가능uv에 새로운 uv format 명령어가 추가되어, 내부적으로는 ruff의 포매터를 실행하는 기능이 제공된다ruff와 uv의 병합이 아니라, Rust의 cargo fmt가 rustfmt를 실행하는 것과 유사하게, 사용자에게 보다 간소화된 경험을 제공하는 것이 목적이다uv format은 실험적 기능으로, 실행 시 ruff를 자동으로 다운로드·설치하기 때문에, 사용하지 않을 경우 영향이 없는 설계이다uv)로 "프로젝트 초기화, 실행, 포맷"을 완결할 수 있는 개발 경험을 목표로 하고 있다uvx ruff나 uv tool run ruff로 충분하다는 의견이 있다Arc<Mutex<T>>로 대부분의 케이스에 대응할 수 있다uv lint나 uv test와 같은 추가 명령어도 검토될 가능성이 있으며, Python의 "Cargo화"가 진행 중이다vite new: 프로젝트 스캐폴딩 및 모노레포 생성, 코드 생성 지원vite test: Vitest 기반 단위 테스트 (Jest 호환 API, 브라우저 모드, 시각적 회귀 테스트 등)vite lint: Oxlint 기반 린팅 (ESLint보다 최대 100배 빠름, 600+ 규칙 지원)vite fmt: Oxfmt 기반 코드 포맷팅 (Prettier 99%+ 호환)vite lib: tsdown과 Rolldown 기반 라이브러리 번들링vite run: 지능형 캐싱을 갖춘 모노레포 태스크 러너vite ui: 모듈 분석, 번들 크기 분석 등을 제공하는 GUI 개발도구npx chrome-devtools-mcp@latest 명령어로 간단히 구성 추가 가능