HTML5는 단순한 버전 업그레이드가 아니라, 웹 문서를 구조화하는 방식 자체를 근본적으로 바꾼 패러다임의 전환이었습니다. 이전까지 개발자들은 <div>와 <span>만으로 페이지를 구성하며 레이아웃을 클래스 이름에 의존했지만, HTML5는 문서의 의미를 태그 자체에 담을 수 있는 풍부한 시맨틱 요소들을 새롭게 도입했습니다. 이 변화는 브라우저, 검색 엔진, 스크린 리더가 페이지의 구조를 더 정확하게 이해할 수 있게 만들었고, 개발자가 의도를 명확하게 표현하는 코드를 작성할 수 있는 토대를 마련해 주었습니다. HTML5의 구조적 변화를 이해하면 단순히 새로운 태그를 배우는 것을 넘어, 왜 그 변화가 필요했는지 그 배경과 원리를 파악할 수 있습니다.
핵심 특징
- HTML4/XHTML 시대의
<div>남용 문제와 그 한계를 해소하기 위해 시맨틱 구조 요소가 등장했습니다 <header>,<nav>,<main>,<article>,<section>,<aside>,<footer>등 문서 구조를 표현하는 전용 요소들이 표준화되었습니다- 아웃라인 알고리즘(Outline Algorithm) 개념이 도입되어 섹셔닝 요소들이 문서 계층 구조를 형성하는 방식이 정의되었습니다
- HTML5는 마크업 언어를 넘어 애플리케이션 플랫폼으로서의 역할을 추구하며, 미디어·폼·API 영역까지 대폭 확장되었습니다
- 브라우저 간 상호운용성과 웹 접근성을 공식 표준의 핵심 목표로 명시적으로 채택했습니다
실무에서의 영향
HTML5의 구조적 변화를 이해하면 코드베이스의 가독성과 유지보수성이 크게 향상됩니다. 팀 협업 시 <article>과 <section>의 차이를 공유된 언어로 소통할 수 있어 코드 리뷰와 설계 논의가 효율적으로 이루어집니다. 또한 Google, Bing 같은 검색 엔진은 시맨틱 요소를 통해 콘텐츠의 중요도와 역할을 파악하므로, HTML5 구조를 올바르게 활용하면 SEO 성과에도 직접적인 영향을 미칩니다. 스크린 리더와 같은 보조 기술은 시맨틱 마크업을 기반으로 페이지를 탐색 랜드마크로 인식하기 때문에, HTML5 구조를 제대로 사용하면 접근성 기준을 자연스럽게 충족할 수 있습니다. 결과적으로 HTML5의 변화를 이해하는 것은 현대 웹 표준의 출발점을 아는 것이며, 이를 토대로 CSS, JavaScript, 접근성, SEO 등 모든 프론트엔드 영역을 더 깊이 있게 다룰 수 있게 됩니다.
핵심 개념
div 중심 마크업에서 시맨틱 구조로의 전환
입문
HTML4 시대에는 웹페이지를 만들 때 거의 모든 것을 <div>라는 상자로 쌓았어요. HTML5는 각 역할에 맞는 이름표가 붙은 상자들을 새로 만들어 주었답니다!
📦 HTML4 시대의 웹페이지는 어떻게 생겼을까요? 예전에는 웹페이지의 모든 부분이 이름 없는 똑같은 상자(div)들로만 이루어져 있었어요. 마치 모든 물건을 “상자”라고만 적힌 박스에 넣어두는 것과 같아요. 나중에 박스를 열어보기 전까지는 안에 뭐가 있는지 알 수 없죠.
🏷️ HTML5에서는 무엇이 달라졌나요? HTML5는 상자에 제대로 된 이름표를 붙여줬어요. “이 상자는 머리말(header)”, “이건 메뉴(nav)”, “이건 주요 내용(main)“처럼요. 택배 상자에 “깨지는 물건”, “냉장 보관” 같은 스티커를 붙이면 누구나 어떻게 다뤄야 할지 바로 아는 것과 같은 원리예요.
🤔 div를 쓰면 왜 문제가 됐나요?
<div class="header">, <div class="nav"> 같은 코드가 넘쳐났어요. 문제는 사람은 “header”라는 단어를 읽고 이해하지만, 구글 같은 검색 엔진이나 장애인을 돕는 화면 읽기 프로그램은 그냥 이름 없는 상자로만 인식했어요. 이름표의 의미를 이해하지 못한 거죠.
💡 시맨틱(Semantic)이란 무슨 뜻인가요? “시맨틱”은 “의미가 있는”이라는 뜻이에요. 태그 자체가 그 내용의 의미를 설명한다는 거예요. 도서관 책꽂이에 “소설”, “역사”, “과학” 같은 분류 라벨이 붙어 있으면 책을 꺼내지 않아도 무슨 내용인지 알 수 있는 것처럼, 시맨틱 태그는 안을 보지 않아도 그 역할을 알려줘요.
중급
HTML4/XHTML 시대에는 레이아웃 구성을 위해 <div> 요소에 class나 id 속성을 부여하는 방식이 사실상 표준이었습니다. 이 방식은 class 이름에 의미 전달을 의존했기 때문에, 마크업 자체에는 구조적 의미가 없었습니다. HTML5는 이 문제를 해결하기 위해 구조를 표현하는 전용 시맨틱 요소들을 표준화했습니다.
div soup 문제
div 기반 마크업에서는 동일한 <div> 태그가 헤더, 사이드바, 콘텐츠 등 전혀 다른 역할을 수행했습니다. 코드를 보는 사람(사람이든 기계든)은 class 이름을 해석해야만 그 의미를 파악할 수 있었고, class 이름은 개발자마다 달랐기 때문에 일관성이 없었습니다.
<!-- HTML4 방식 -->
<div id="header">
<div id="nav">...</div>
</div>
<div id="main">
<div class="article">...</div>
<div class="sidebar">...</div>
</div>
<div id="footer">...</div>
<!-- HTML5 방식 -->
<header>
<nav>...</nav>
</header>
<main>
<article>...</article>
<aside>...</aside>
</main>
<footer>...</footer>시맨틱 전환의 실질적 효과 시맨틱 요소는 브라우저의 접근성 트리(Accessibility Tree)에 ARIA 랜드마크 역할을 자동으로 부여합니다. 스크린 리더는 이 랜드마크를 통해 페이지 탐색 단축키를 제공하고, 검색 엔진은 콘텐츠의 중요도를 더 정확하게 판단합니다.
심화
HTML4에서 HTML5로의 전환은 마크업 언어의 역할론에 대한 근본적 패러다임 변화를 반영합니다. HTML4는 표현(Presentation)과 구조(Structure)의 분리를 추구했지만, 의미론적 어휘(Semantic Vocabulary)가 빈약했습니다. HTML5는 WHATWG HTML Living Standard를 통해 구조적 의미를 언어 수준에서 내재화했습니다.
WHATWG HTML Living Standard 기반 설계 철학
HTML5 명세(https://html.spec.whatwg.org/)는 각 요소의 “의미(meaning)“를 명시적으로 정의합니다. 예를 들어, <header> 요소는 단순히 “페이지 상단”이 아니라 “가장 가까운 섹셔닝 콘텐츠 또는 섹셔닝 루트 요소에 대한 소개적 콘텐츠의 컨테이너”로 정의됩니다. 이는 CSS 표현 계층과 완전히 분리된 순수 의미론적 정의입니다.
접근성 트리와 ARIA 암묵적 역할
W3C WAI-ARIA 명세에 따르면, HTML5 시맨틱 요소들은 암묵적 ARIA 역할(Implicit ARIA Role)을 가집니다. <header>는 role="banner", <nav>는 role="navigation", <main>은 role="main" 등으로 자동 매핑됩니다. 이는 마크업과 접근성 계층이 통합된 설계로, 별도의 role 속성 없이도 AT(Assistive Technology)가 올바르게 해석합니다.
레거시 코드베이스에서의 마이그레이션 고려사항
div soup을 시맨틱 마크업으로 마이그레이션할 때, CSS 선택자 특이성(Specificity)과 JavaScript DOM 쿼리 의존성을 반드시 점검해야 합니다. document.querySelector('#header')와 같은 id 기반 쿼리는 document.querySelector('header')로 변경 가능하지만, 중첩 구조에서 여러 <header>가 존재하는 경우 예상치 못한 동작이 발생할 수 있습니다.
HTML5 시맨틱 구조 요소
입문
HTML5가 새로 만든 구조용 태그들을 알아볼까요? 각 태그는 웹페이지의 특정 부분을 담당하는 전용 자리예요.
🏠 웹페이지를 집에 비유하면? 웹페이지를 집이라고 생각해보세요. 집에는 현관(header), 복도(nav), 거실(main), 서재(article), 창고(aside), 화장실(footer) 같은 각기 다른 공간이 있어요. HTML5의 구조 태그들은 바로 이 공간들에 이름을 붙여준 거예요.
📰 article과 section은 어떻게 다른가요? article은 그 자체로 완결된 글이에요. 신문 기사처럼 다른 사이트에 그대로 옮겨도 말이 되는 내용이죠. section은 책의 챕터처럼 전체 글의 한 부분을 나누는 역할이에요. 혼자 독립하면 의미가 약해지는 부분들이에요.
📌 nav와 aside는 어디에 쓰이나요? nav는 사이트 곳곳을 안내하는 메뉴판이에요. “여기 누르면 홈으로”, “여기 누르면 소개 페이지로” 같은 길 안내 역할이죠. aside는 책의 옆면에 적힌 “더 알아보기” 박스 같아요. 주요 내용과 관련 있지만 없어도 되는 부가 정보를 담아요.
🎯 header와 footer는 어디에나 쓸 수 있나요? 네! header와 footer는 페이지 전체뿐 아니라 article이나 section 안에서도 각각의 머리말과 꼬리말로 쓸 수 있어요. 신문에서 기사마다 제목과 기자 이름이 따로 붙어 있는 것처럼, 각 콘텐츠 블록이 자신만의 header와 footer를 가질 수 있어요.
중급
HTML5는 페이지 구조를 표현하는 7개의 핵심 시맨틱 요소를 표준화했습니다. 각 요소는 명세에서 구체적인 사용 기준을 정의하며, 역할이 겹치는 것처럼 보이는 요소들 사이에도 명확한 구분이 있습니다.
핵심 구조 요소와 사용 기준
| 요소 | 역할 | 사용 기준 |
|---|---|---|
<header> | 소개/탐색 콘텐츠 | 페이지 또는 섹션의 머리말 |
<nav> | 탐색 링크 모음 | 주요 탐색 블록에만 사용 |
<main> | 페이지 주요 콘텐츠 | 페이지당 1개, 반복 콘텐츠 제외 |
<article> | 독립적 완결 콘텐츠 | 단독으로 배포 가능한 단위 |
<section> | 주제별 콘텐츠 그룹 | 제목이 있는 논리적 구분 |
<aside> | 부가 콘텐츠 | 주요 흐름과 간접적 연관 |
<footer> | 콘텐츠 마무리 정보 | 저작권, 연락처, 관련 링크 |
<!-- article: RSS 피드로 배포해도 의미가 통하면 article -->
<article>
<header>
<h2>JavaScript 호이스팅이란?</h2>
<time datetime="2024-01-15">2024년 1월 15일</time>
</header>
<section>
<h3>개념 정의</h3>
<p>호이스팅은...</p>
</section>
<section>
<h3>예시 코드</h3>
<p>다음 코드를 보면...</p>
</section>
</article>
<!-- section: 페이지 컨텍스트 없이는 의미 전달이 약하면 section -->
<section>
<h2>관련 강의</h2>
<!-- 이 섹션은 해당 페이지 맥락에서만 의미가 있음 -->
</section>main 요소의 유일성 규칙
<main> 요소는 페이지당 하나만 존재해야 하며, <header>, <footer>, <nav>, <aside> 안에 배치할 수 없습니다. hidden 속성을 사용하면 비활성 상태로 여러 개 존재할 수 있으나, 활성 상태는 반드시 하나여야 합니다.
심화
HTML5 시맨틱 구조 요소들은 단순한 시각적 레이아웃 도구가 아니라, WHATWG HTML Living Standard에서 정의한 콘텐츠 모델(Content Model)과 섹셔닝 알고리즘의 핵심 어휘입니다.
섹셔닝 콘텐츠와 섹셔닝 루트의 구분
HTML5 명세는 요소를 섹셔닝 콘텐츠(Sectioning Content)와 섹셔닝 루트(Sectioning Root)로 구분합니다. <article>, <section>, <nav>, <aside>는 섹셔닝 콘텐츠로, 각각 독립적인 아웃라인 컨텍스트를 생성합니다. 반면 <blockquote>, <details>, <fieldset>, <figure>, <td>는 섹셔닝 루트로, 내부 아웃라인이 외부에 영향을 주지 않습니다.
article 요소의 마이크로데이터/RDFa 연동
<article> 요소는 Schema.org의 Article 타입과 자연스럽게 연동됩니다. 검색 엔진은 <article> 내부에서 itemscope, itemtype="https://schema.org/Article" 속성을 발견하면 구조화 데이터(Structured Data)로 인식하여 리치 스니펫(Rich Snippet) 생성에 활용합니다.
접근성 API 매핑과 AT 동작 차이
각 시맨틱 요소는 Accessibility API(MSAA, IAccessible2, AX API)에서 서로 다른 역할로 매핑됩니다. <main>은 role="main"으로 매핑되어 스크린 리더에서 “주요 콘텐츠로 건너뛰기” 랜드마크 탐색을 지원합니다. 그러나 <section> 요소는 접근 가능한 이름(Accessible Name)이 없을 때 일부 스크린 리더에서 role="generic"으로 처리되어 랜드마크 탐색에서 제외됩니다. 따라서 <section aria-labelledby="section-heading">처럼 명시적 레이블을 부여하는 것이 권장됩니다.
아웃라인 알고리즘과 문서 계층 구조
입문
HTML5는 웹페이지에 “목차”를 자동으로 만들 수 있는 규칙을 만들었어요. 이 규칙 덕분에 페이지가 얼마나 잘 구조화되어 있는지 기계도 알 수 있게 됐답니다.
📚 책의 목차처럼 생각해봐요 잘 만들어진 책에는 목차가 있어요. 1장, 1.1절, 1.2절, 2장… 이런 식으로 계층이 명확하죠. HTML5 아웃라인 알고리즘은 웹페이지에서 자동으로 이런 목차를 만들어내는 규칙이에요.
🔢 제목 태그는 어떤 역할을 하나요? h1은 책 제목, h2는 챕터 제목, h3는 소제목처럼 계층을 나타내요. 그런데 HTML5에서는 섹션 태그(section, article 등)를 쓰면 각 섹션 안에서 제목 번호가 다시 시작될 수 있어요. 마치 각 챕터가 독립된 소책자처럼 자신만의 번호 체계를 가질 수 있는 것과 비슷해요.
⚠️ 실제로 이 기능을 쓸 때 주의할 점이 있나요? 이 자동 목차 기능은 아이디어는 좋았지만, 브라우저들이 완전히 지원하지 않았어요. 그래서 지금은 이 기능에 너무 의존하기보다, 여전히 h1~h6 순서를 직접 잘 지키는 게 더 안전해요. HTML5가 의도했던 것과 실제로 구현된 것 사이에 차이가 있는 흥미로운 역사랍니다.
🌳 구조가 왜 중요한가요? 나무가 줄기, 가지, 잎으로 나뉘듯이, 잘 구조화된 웹페이지는 검색 엔진과 스크린 리더가 “이 페이지에서 가장 중요한 정보는 여기, 다음 중요한 정보는 저기”라고 파악할 수 있어요. 구조가 명확할수록 더 많은 사람과 기계가 여러분의 페이지를 잘 이해할 수 있어요.
중급
HTML5는 섹셔닝 콘텐츠 요소(<article>, <section>, <nav>, <aside>)가 각자의 독립적인 아웃라인(문서 개요)을 생성한다는 개념을 도입했습니다. 이를 통해 섹션 내부에서 <h1>을 반복 사용해도 각 섹션의 맥락 안에서 최상위 제목으로 해석될 수 있다는 아이디어였습니다.
아웃라인 알고리즘의 이론적 동작
이론상으로 아래 코드는 두 개의 독립적인 아웃라인을 가집니다.
<body>
<h1>사이트 제목</h1> <!-- 레벨 1 -->
<article>
<h1>기사 제목</h1> <!-- 이 article의 레벨 1 -->
<section>
<h2>소제목</h2> <!-- 이 article의 레벨 2 -->
</section>
</article>
<article>
<h1>다른 기사 제목</h1> <!-- 이 article의 레벨 1 -->
</article>
</body>현실의 한계: 브라우저 미구현 아웃라인 알고리즘은 명세에만 존재했고, 주요 브라우저들이 끝내 구현하지 않았습니다. 스크린 리더도 지원하지 않아 실제 접근성에 기여하지 못했습니다. W3C는 2022년 이 알고리즘을 명세에서 제거했고, 현재는 제목 레벨(h1~h6)을 문서 전체 맥락에서 순차적으로 사용하는 방식이 권장됩니다.
실무 권장 패턴
<article>안에서도<h1>을 반복 사용하지 않고 적절한 레벨(h2, h3…)을 사용- 제목 레벨은 시각적 크기가 아닌 논리적 계층을 반영
- 한 페이지에
<h1>은 하나만 사용하는 것이 접근성과 SEO에 유리
심화
아웃라인 알고리즘(HTML5 Outline Algorithm)은 HTML5 명세의 가장 야심찼던 기능 중 하나였지만, 명세와 구현 사이의 괴리를 보여주는 대표적인 사례이기도 합니다.
명세의 설계 의도와 섹셔닝 컨텍스트
WHATWG HTML Living Standard는 섹셔닝 콘텐츠 요소가 새로운 섹셔닝 컨텍스트(Sectioning Context)를 생성하며, 각 컨텍스트 내의 <h1>~<h6>은 해당 컨텍스트 기준으로 상대적 레벨을 가진다고 정의했습니다. 이는 컴포넌트 기반 개발에서 각 컴포넌트가 독립적인 헤딩 계층을 가질 수 있게 하려는 의도였습니다.
구현 실패와 명세 개정 2022년 W3C는 아웃라인 알고리즘이 어떤 주요 브라우저에서도 구현되지 않았음을 공식 인정하고 HTML 명세에서 해당 알고리즘을 제거했습니다. 이는 명세 주도 설계(Spec-Driven Design)의 한계를 드러낸 사건으로, 이후 WHATWG는 구현 가능성(Implementability)을 명세 채택 기준에 더 엄격하게 적용하기 시작했습니다.
현행 접근성 표준과의 정합성
WCAG 2.2 Success Criterion 1.3.1 (Info and Relationships)과 2.4.6 (Headings and Labels)은 제목 구조가 콘텐츠의 계층을 정확하게 반영할 것을 요구합니다. NVDA, JAWS, VoiceOver 등 주요 스크린 리더는 <h1>~<h6>의 절대적 레벨에 의존하여 페이지 탐색을 지원하므로, 아웃라인 알고리즘 의존 없이 전통적 헤딩 계층을 유지하는 것이 현행 접근성 표준에 부합합니다.
HTML5의 웹 애플리케이션 플랫폼으로의 확장
입문
HTML5는 단순히 문서를 만드는 언어에서 앱을 만들 수 있는 플랫폼으로 크게 성장했어요. 이 변화가 어떤 의미인지 살펴봐요!
📱 HTML4 시대의 한계는 무엇이었나요? 예전에는 웹에서 동영상을 보려면 Flash, 음악을 들으려면 RealPlayer 같은 별도의 프로그램을 설치해야 했어요. 마치 냉장고 안에 음식을 보관하는 작은 냉장고를 또 설치하는 것처럼 비효율적이었죠.
🎬 HTML5에서 미디어가 달라진 점은?
HTML5에서는 <video>와 <audio> 태그가 생겼어요. 이제 유튜브나 넷플릭스처럼 별도 프로그램 없이 브라우저에서 바로 동영상을 볼 수 있게 됐어요. 마치 냉장고에 기본으로 냉동실이 생긴 것처럼, 따로 설치할 필요가 없어졌죠.
📝 폼(Form)이 더 똑똑해진 건 무슨 뜻인가요? 예전에는 “이메일 주소를 입력하세요” 라고 해도 아무 글자나 입력할 수 있었어요. HTML5에서는 이메일 형식인지, 숫자인지, 날짜인지를 자동으로 검사해줘요. 카페에서 주문할 때 “아메리카노 주세요”라고 하면 자동으로 커피 종류인지 확인해주는 스마트한 직원이 생긴 것과 같아요.
🌐 오프라인에서도 쓸 수 있게 됐다고요? HTML5의 새로운 기능들 덕분에 인터넷이 없어도 웹 앱이 동작할 수 있게 됐어요. 비행기 안에서 인터넷 없이 구글 독스를 쓰거나, 지하철에서 넷플릭스 다운로드 영상을 보는 것처럼요. 이건 HTML5 이전에는 불가능했던 일이에요.
중급
HTML5는 구조적 시맨틱 개선 외에도, 브라우저를 네이티브 앱에 준하는 애플리케이션 플랫폼으로 만들기 위한 다양한 API와 요소를 도입했습니다. 이 확장은 Flash, Silverlight 같은 서드파티 플러그인 의존도를 제거하려는 명확한 목표를 가지고 있었습니다.
HTML5가 추가한 주요 기능 영역
| 영역 | 추가 요소/API | 해결한 문제 |
|---|---|---|
| 멀티미디어 | <video>, <audio>, <canvas> | Flash 플러그인 의존 제거 |
| 폼 유효성 | type="email/date/number", required | 서버 검증 전 클라이언트 검증 |
| 오프라인 | Service Worker, Cache API | 인터넷 없이 앱 동작 |
| 로컬 저장소 | localStorage, sessionStorage | 쿠키 한계 극복 |
| 실시간 통신 | WebSocket, WebRTC | 서버-클라이언트 양방향 통신 |
| 그래픽 | Canvas 2D, SVG 통합 | 네이티브 그래픽 렌더링 |
<!-- HTML5 이전: JavaScript로 직접 검증 필요 -->
<!-- HTML5 이후: 브라우저가 기본 제공 -->
<form>
<input type="email" required placeholder="이메일 주소">
<input type="number" min="1" max="100" value="1">
<input type="date" min="2024-01-01">
<input type="url" placeholder="https://example.com">
<button type="submit">제출</button>
</form>
<!-- 브라우저가 형식 검증 후 오류 메시지 자동 표시 -->Progressive Web App(PWA)의 기반 HTML5 API들(Service Worker, Web App Manifest, Push API)은 PWA의 기술적 기반이 되었습니다. 이를 통해 웹앱이 홈 화면 설치, 오프라인 동작, 푸시 알림 등 네이티브 앱과 유사한 경험을 제공할 수 있게 되었습니다.
심화
HTML5의 애플리케이션 플랫폼화는 WHATWG, W3C, 브라우저 벤더들의 협력과 갈등이 교차하는 복잡한 표준화 과정의 산물입니다. 이는 단순한 기능 추가가 아니라, 웹의 실행 환경(Runtime Environment)으로서의 정체성을 재정립한 과정입니다.
WHATWG 설립 배경과 HTML5 추진 HTML5는 2004년 WHATWG(Web Hypertext Application Technology Working Group)가 Apple, Mozilla, Opera의 주도로 설립되면서 시작되었습니다. W3C가 XHTML 2.0에 집중하는 동안 WHATWG는 Web Forms 2.0과 Web Applications 1.0 명세를 개발했고, 이것이 HTML5의 원형이 됐습니다. 2007년 W3C가 HTML5 작업그룹을 공식 발족하며 두 조직이 협력하게 됐지만, 2019년 WHATWG의 HTML Living Standard가 유일한 공식 표준으로 인정되었습니다.
Canvas API와 WebGL의 렌더링 파이프라인
<canvas> 요소는 JavaScript를 통한 즉각적(Immediate) 렌더링 모드를 제공합니다. 이는 SVG의 보존(Retained) 렌더링 모드와 대조됩니다. Canvas 2D API는 CPU 렌더링 기반이지만, WebGL(Web Graphics Library)은 GPU 가속을 통해 OpenGL ES 2.0/3.0 명세를 브라우저에서 직접 실행합니다. Three.js, Babylon.js 같은 3D 라이브러리들이 이 위에 구축되어 있으며, WebGPU가 차세대 그래픽 API로 표준화 진행 중입니다.
Storage API의 진화와 보안 모델 localStorage/sessionStorage는 동일 출처 정책(Same-Origin Policy)에 의해 격리됩니다. IndexedDB는 비동기 트랜잭션 기반으로 대용량 구조화 데이터를 저장할 수 있으며, Origin Private File System(OPFS)은 가상 파일 시스템을 제공합니다. Service Worker의 Cache API는 HTTP 캐시와 별개로 동작하는 프로그래머블 캐시를 제공하여 오프라인 PWA의 핵심 메커니즘을 구성합니다. 이 모든 저장소 API는 Storage Quota API를 통해 용량 제한을 관리받습니다.