• 네이티브 dialog를 통해 9개 사이트에서 14KB 용량의 모달 라이브러리를 제거했습니다.
• method=dialog 폼은 JS 없이도 닫히며 값을 반환합니다.
• @starting-style과 closedby="any"를 통해 종료 애니메이션과 라이트 디스미스 (light-dismiss)를 처리합니다.
• 한 가지 사례(중첩된 비모달 팝오버)에서는 여전히 작은 헬퍼가 필요합니다.

지난 분기에 저는 운영 중인 9개 사이트에서 14KB 크기의 모달 라이브러리를 삭제했습니다. 네이티브 <dialog> 요소가 제가 비용을 지불하며 사용하던 모든 기능, 즉 포커스 트랩 (focus trap), 최상위 레이어 스택킹 (top-layer stacking), Esc 키로 닫기 (escape-to-close), 백드롭 스타일링 (backdrop styling)을 대체했습니다. 제가 현재 사용 중인 6가지 패턴과, 여전히 도움을 빌려야 하는 한 가지 상황을 소개합니다.

무료로 제공되는 포커스 트랩 (Focus Trap) 및 최상위 레이어 스택킹 (Top-Layer Stacking)

대부분의 사람들이 모달 라이브러리를 설치하는 이유는 포커스 트랩 (focus trap) 때문입니다. 다이얼로그가 열리면 키보드 포커스가 그 내부에 머물러야 합니다. 마지막 버튼에서 Tab 키를 누르면 뒤에 있는 페이지로 포커스가 넘어가는 것이 아니라, 다시 첫 번째 요소로 돌아와야 합니다. 이를 직접 구현하는 것은 매우 번거로운 일입니다. 포커스 가능한 요소들을 추적하고, Tab 및 Shift+Tab 키 입력을 감지하며, 순환 처리를 직접 해야 합니다. 라이브러리들은 이 기능을 위해 수 킬로바이트(KB)의 용량을 요구합니다.

dialog.showModal()은 이 트랩 기능을 무료로 제공합니다. 이 메서드를 호출하면 브라우저가 Tab 키의 범위를 다이얼로그 내부로 제한하고, Escape 키를 닫기 명령으로 전송하며, 다이얼로그 뒤의 모든 요소를 비활성 (inert) 상태로 만들어 스크린 리더 (screen reader)가 이를 건너뛰도록 합니다. 저는 제 제품 페이지 중 3곳에서 VoiceOver를 통해 이를 테스트했으며, 별도의 ARIA 속성을 추가하지 않고도 읽기 순서가 정확하게 작동하는 것을 확인했습니다.

두 번째 무료 기능은 최상위 레이어 (top layer)입니다. 모달 다이얼로그를 열면 브라우저는 z-index와 상관없이 해당 요소를 다른 모든 요소보다 위에 배치합니다. 예전에는 어떤 조상 요소에 transform이 설정되어 있어 모달이 스티키 헤더 (sticky header) 뒤로 숨어버리는 스택킹 컨텍스트 (stacking context) 버그와 끊임없이 싸워야 했습니다. 최상위 레이어는 이 모든 것을 무시합니다. 모달 다이얼로그는 무조건 가장 위에 그려집니다.

Close

## Your cart

document.querySelector('#cart').showModal();

autofocus 속성에 주목하세요. 다이얼로그 (dialog)가 열릴 때 브라우저가 초기 포커스를 해당 요소로 이동시키는데, 이는 여러분이 원하는 접근성 (accessibility) 측면의 기본 동작입니다. showModal() 대신 show()를 사용하면 비모달 (non-modal) 다이얼로그를 얻을 수 있습니다. 즉, 백드롭 (backdrop)이 없고, 포커스 트랩 (focus trap)이 없으며, 배경이 비활성화 (inert)되지 않습니다. 저는 결정을 요구하는 모든 사항(결제 확인, 연령 확인 등)에는 모달 버전을 사용하고, 페이지를 차단해서는 안 되는 요소에는 비모달 버전을 사용합니다. 만약 이 모든 것에 JavaScript가 필요했던 시대를 거쳐 오셨다면, 2026년까지 JavaScript가 필요했던 5가지 CSS 애니메이션에 대한 제 노트가 동일한 사고방식의 변화를 다루고 있습니다.

단 두 번의 메서드 (method) 호출만으로 사람들이 라이브러리를 설치하던 세 가지 큰 이유 중 두 가지가 사라졌습니다.

::backdrop 스타일링 및 method="dialog" 폼 트릭

모달 뒤의 어두워진 오버레이 (overlay)는 자체적인 의사 요소 (pseudo-element)인 ::::backdrop을 가집니다. 이를 다른 선택자 (selector)와 마찬가지로 스타일링할 수 있습니다. 추가적인 div나 콘텐츠 위에 z-index를 높여 배치해야 하는 포지션 오버레이가 필요 없습니다.

dialog::backdrop {  
background: rgb(0 0 0 / 0.6);  
backdrop-filter: blur(4px);  
}

저는 모든 쇼핑몰 사이트의 백드롭에 4px 블러 (blur)를 적용합니다. 단 한 줄의 코드로 비용이 들지만, 모달이 단순히 덧붙여진 것이 아니라 의도된 디자인처럼 느껴지게 만듭니다. ::backdrop 또한 애니메이션을 적용할 수 있으며, 이는 아래의 종료 애니메이션 (exit animation) 패턴에서 중요하게 작작용합니다.

폼 (form) 트릭은 사람들이 놓치는 부분입니다. 다이얼로그 내부의 <form method="dialog">는 JavaScript 없이도 제출 시 다이얼로그를 닫고 어떤 버튼이 사용되었는지 기록합니다.

이 초안을 삭제하시겠습니까?

Cancel
Delete

사용자가 Delete를 클릭하면 다이얼로그가 닫히고 dialog.returnValue는 "delete"가 됩니다. 이를 단일 close 이벤트 리스너 (event listener)에서 읽을 수 있습니다:

confirm.addEventListener('close', () => {  
if (confirm.returnValue === 'delete') removeDraft();  
});

이것은 두 가지 결과(outcomes)를 가지며 스크립트가 거의 필요 없는 완전한 확인 대화상자(confirm dialog)입니다. 저는 Shopify 관리 도구 중 하나에서 파괴적인 작업(destructive action)을 처리하기 위해 정확히 이 방식을 적용했으며, 이는 약 40줄에 달하는 상태 관리(state handling) 코드를 대체했습니다. 만약 Shopify 기반으로 개발하신다면, 이 패턴은 전역(global) 설정이 전혀 필요 없기 때문에 테마 앱 블록(theme app blocks)에 바로 끼워 넣을 수 있습니다.

주의해야 할 점: method="dialog"는 대화상자를 닫기만 할 뿐, 데이터를 어디론가 제출(submit)하지는 않습니다. 실제 네트워크 제출이 필요하다면 일반적인 폼(form)을 유지하고, fetch가 해결(resolve)된 후에 직접 dialog.close()를 호출하세요. 저는 초기에 이 두 가지를 혼동하여 왜 POST 요청이 전혀 발생하지 않는지 20분 동안 헤맨 적이 있습니다. 해결책은 속성(attribute) 하나였습니다. 로직을 JavaScript에서 플랫폼으로 옮기는 더 넓은 패턴에 대해서는, CSS :has() in Production에서 셀렉터(selector) 측면의 동일한 트레이드오프(trade-offs)를 다루고 있습니다.

closedby를 이용한 라이트 디스미스(Light-Dismiss)와 깔끔한 종료 애니메이션

수년 동안 표준적인 요구사항은 "모달 외부를 클릭해서 닫게 해달라"는 것이었습니다. 이는 백드롭(backdrop)에 클릭 리스너(click listener)를 달고, 클릭 타겟(click target)을 확인하기 위한 수학적 계산을 수행하며, 내부를 클릭한 채로 드래그하여 밖으로 나갈 때 실수로 닫히는 예외 상황(edge case)까지 처리해야 함을 의미했습니다. 이제는 속성(attribute)이 있습니다.

`plaintext

...

`

closedby="any"는 라이트 디스미스(light-dismiss) 기능을 제공합니다. 즉, 백드롭을 클릭하거나 Escape 키를 누르면 대화상자가 닫힙니다. closedby="closerequest"는 Escape 키와 플랫폼의 닫기 제스처(close gesture)만 허용합니다. closedby="none"은 두 가지 모두를 차단하며, 저는 결제 진행 중인 모달처럼 트랜잭션 도중에 해제되어서는 안 되는 경우에 이를 사용합니다. 세 가지 값, 리스너는 제로(0)입니다. 이 기능은 안정화된 Chrome에 배포되었으며 다른 엔진들로도 확산되고 있으므로, 저는 기능 감지(feature-detect)를 통해 해당 기능이 없는 경우 아주 작은 백드롭 클릭 핸들러(backdrop-click handler)로 폴백(fall back) 처리합니다.

종료 애니메이션(Exit animations) 또한 라이브러리가 처리하던 또 다른 요소였습니다. 문제는 display: none을 설정하면 요소가 즉시 사라져 버리기 때문에, 애니메이션을 통해 사라지는 효과를 줄 수 없다는 점이었습니다. 새로운 조합은 진입(entry)을 위한 @starting-style과 종료(exit)를 위한 transition-behavior: allow-discrete입니다.

dialog {  
opacity: 1;  
transition: opacity 0.2s, overlay 0.2s allow-discrete, display 0.2s allow-discrete;  
}  
dialog:not(\[open\]) { opacity: 0; }  
@starting-style {  
dialog\[open\] { opacity: 0; }  
}

@starting-style은 다이얼로그가 열리기 전 시작되는 값을 정의하여 페이드 인(fade in) 효과를 줍니다. display와 overlay에 적용된 allow-discrete는 속성이 사라지는 즉시 요소를 끊어버리는 대신, 종료 트랜지션(exit transition)이 진행되는 동안 요소가 계속 그려지도록 유지합니다. overlay 속성은 페이드가 완료될 때까지 요소를 최상위 레이어(top layer)에 머물게 하는 역할을 합니다. 저는 이제 모든 다이얼로그에 200ms의 페이드와 8px의 이동(translate)을 적용하고 있는데, 단 한 번의 requestAnimationFrame 호출 없이도 매우 세련되게 느껴집니다.

이는 제가 CSS Scroll-Driven Animations: 6 Patterns I Ship in 2026에서 다루었던 플랫폼 애니메이션 작업과 같은 계열이며, 불연속 트랜지션(discrete-transition) 트릭 또한 그곳에서 등장합니다. 만약 JS 없이 전체 애니메이션 스토리를 확인하고 싶다면, View Transitions API: 5 Patterns가 전체 화면 경로 변경(route changes)을 위해 다이얼로그와 깔끔하게 결합될 수 있습니다.

라이브러리가 여전히 승리하는 단 한 가지 사례

한계점에 대해 솔직하게 말씀드리고 싶습니다. 네이티브가 모든 것을 해결할 수 있다고 가장하는 것은 여러분의 오후 시간을 디버깅에 허비하게 만들 수 있기 때문입니다. 이 요소는 단일 모달(single modals)은 훌륭하게 처리합니다. 하지만 여러 개의 플로팅 패널(floating panels)이 공존해야 하고 특정 순서로 닫혀야 하는, 깊게 중첩된 비모달 스택(non-modal stacks)에서는 어려움을 겪습니다.

선택(select) 요소를 포함하는 비모달 대화상자(non-modal dialog)를 상상해 보세요. 그 선택 요소는 커스텀 드롭다운(custom dropdown)을 열고, 그 드롭다운의 한 옵션에는 툴팁(tooltip)이 달려 있습니다. show() (비모달)를 사용하면 포커스 트랩(focus trap)도 없고 배경을 비활성화(inert)하는 기능도 없기 때문에, 세 개의 독립적인 레이어에 걸쳐 포커스 순서와 외부 클릭 해제(outside-click dismissal)를 다시 관리해야 하는 상황에 놓이게 됩니다. 네이티브 최상위 레이어(top layer)가 이들을 쌓아주기는 하지만, 어떤 레이어를 Escape 키로 먼저 닫아야 하는지 또는 포커스가 체인을 따라 어떻게 되돌아가야 하는지를 조율(orchestrate)해주지는 않습니다. 그러한 조율이야말로 포커스 관리 헬퍼(focus-management helper)와 같은 작은 라이브러리가 제공하는 핵심 기능이며, 바로 그 좁은 사례를 위해서라면 4KB 정도의 용량은 충분히 투자할 가치가 있습니다.

저는 1,200개의 SKU(재고 관리 단위)가 있는 카탈로그의 필터 패널을 구축할 때 이 문제에 부딪혔습니다. 쇼핑객들이 그리드를 계속 스크롤할 수 있도록 패널을 비모달로 만들었지만, 패널 내부에는 자체적인 팝오버(popover)를 가진 중첩된 확장 그룹들이 있었습니다. 네이티브 대화상자(dialog)와 팝오버 API(popover API)를 사용해 90%까지는 해결했습니다. 나머지 10%, 즉 중첩된 팝오버들 사이에서 예측 가능한 Escape 순서를 보장하는 작업이 너무 불안정하여, 포커스 복귀만을 위한 3KB 크기의 헬퍼를 추가했습니다. 그 외의 모든 것은 네이티브 상태를 유지했습니다.

제가 사용하는 솔직한 규칙은 다음과 같습니다. 한 번에 하나의 모달만 띄운다면 네이티브가 압도적으로 유리하며, 동작을 위한 자바스크립트(JavaScript)를 전혀 작성하지 않습니다. 만약 해제와 포커스를 조정해야 하는 상호작용 가능한 플로팅 레이어(floating layers)가 두 개 이상이라면, 아주 작은 헬퍼를 유지하되 렌더링이 아닌 오직 그 조정(coordination) 작업만을 맡깁니다.

여러분이 같은 실수를 반복하지 않도록 제가 기록한 몇 가지 작은 주의사항들을 알려드립니다. autofocus가 없고 포커스 가능한 자식 요소가 없는 대화상자는 대화상스 자체에 포커스를 두는데, 이는 괜찮지만 Escape 키는 작동하고 Tab 키는 눈에 보이는 변화가 없어 테스트 시 혼란을 줄 수 있습니다. 긴 대화상스는 스크롤 없이 뷰포트(viewport)를 벗어날 수 있으므로 max-height를 설정하는 것이 중요합니다. 그리고 기본 dialog는 margin: auto를 통해 중앙에 배치되는데, 아마 여러분은 이를 재정의(override)하게 될 것입니다. 이와 관련된 레이아웃 문제로, 작은 패널을 트리거(trigger)에 고정(anchoring)해야 하는 경우라면 저는 대화상자를 사용하는 대신 CSS Anchor Positioning Is Production-Ready를 활용합니다.

결론

네이티브 <dialog> 요소는 제가 수년간 안고 왔던 의존성을 제거해 주었습니다. 포커스 트랩 (Focus trap), 최상위 레이어 스택 (Top-layer stacking), 백드롭 스타일링 (Backdrop styling), Esc 키로 닫기 (Escape-to-close), 라이트 디스미스 (Light-dismiss), 반환 값 (Return values), 그리고 종료 애니메이션 (Exit animations)이 이제 모두 플랫폼 내에 존재합니다. 저는 6가지 패턴 중 5가지를 동작을 위한 JavaScript 없이 구현하며, 여러 개의 플로팅 레이어 (Floating layers)가 서로 조정되어야 할 때만 3KB 크기의 헬퍼 (Helper)를 사용합니다.

만약 여러분이 여전히 모달 라이브러리를 불러오고 있다면, 컴포넌트 하나를 열어 교체를 시도해 보세요. open 호출을 showModal()로 바꾸고, 포커스 트랩 (Focus-trap) 코드를 삭제한 뒤, ::backdrop 규칙을 추가하고, close 리스너 하나를 연결하기만 하면 됩니다. 제가 운영하는 사이트들에서 이 교체 작업은 컴포넌트당 오후 한나절이 걸렸으며, 모달을 렌더링하는 모든 페이지의 실제 바이트 (Bytes) 수를 줄여주었습니다.

저는 이러한 '라이브러리 대신 플랫폼을 사용하는 (Platform-over-library)' 호출들을 구현할 때마다 문서화합니다. 의존성을 줄이는 것이야말로 1인 스튜디오가 속도를 유지하는 핵심 방법이기 때문입니다. 무엇을 만들지, 무엇을 삭제할지, 그리고 어떻게 여러 리포지토리 (Repos)에서 일관성을 유지하는지에 대해 제가 사용하는 시스템이 궁금하다면, Claude Blueprint에서 전체 워크플로우를 확인할 수 있습니다. 다이얼로그 교체부터 시작하여, 줄어든 바이트 수를 측정해 보고, 플랫폼의 기능이 진정으로 부족한 곳에만 헬퍼를 남겨두세요.

이 기사에는 제휴 링크가 포함되어 있습니다. 이 링크를 통해 가입하시면, 귀하에게 추가 비용 부담 없이 저에게 소정의 수수료가 지급될 수 있습니다. (광고)