본문으로 건너뛰기
피드

콘텐츠를 가리는 짜증나는 모달, 이제 ‘딕오버’라고 부르자는 글

frontend 약 5분
vote
0
댓글
북마크

웹사이트와 앱이 콘텐츠를 보여주기도 전에 쿠키 동의, 뉴스레터 가입, 앱 설치 같은 불필요한 모달로 사용자를 막는 디자인 패턴을 강하게 비판한 글이다. 저자는 이런 방해형 모달을 ‘딕오버’라고 부르며, 사용자가 보러 온 페이지를 먼저 보여주는 게 웹의 기본이라고 주장한다.

  • 1

    딕오버는 콘텐츠를 가리면서 불필요한 상호작용을 강요하는 모달·팝오버·커튼형 UI를 가리키는 용어로 제안됨

  • 2

    쿠키 동의, 뉴스레터 가입, 앱 설치 유도, 문자 알림 신청처럼 사용자의 원래 목적과 무관한 요구가 대표 사례임

  • 3

    Substack, 언론사, 개인 블로그, 커머스 사이트까지 이 패턴이 너무 널리 퍼졌다는 비판이 나옴

  • 4

    저자는 필요한 로그인·결제·페이월과 불필요한 방해형 모달은 구분해야 한다고 봄

  • 글쓴이는 웹에서 콘텐츠를 가리는 불필요한 모달을 ‘딕오버(dickover)’라고 부르자고 제안함

    • 정의는 꽤 직설적임: 사이트나 앱이 자기 콘텐츠를 일부러 가리고, 사용자가 원하지 않는 상호작용을 강요하는 모달·팝오버·커튼형 UI임
    • 쿠키 허용, 뉴스레터 가입, 모바일 앱 설치, 약관 동의처럼 사용자가 지금 보려던 내용과 상관없는 요구가 대표적임
    • 요지는 간단함. 웹페이지에 들어갔으면 웹페이지를 보여줘야지, 먼저 방해물을 보여주면 안 된다는 것임
  • 이 패턴이 더 짜증나는 이유는 너무 흔해졌기 때문임

    • 글쓴이는 2022년부터 이런 걸 ‘딕패널’이라고 불렀는데, 최근에는 ‘딕오버’가 더 맞는 말처럼 느껴졌다고 함
    • 유럽 뉴스 사이트의 쿠키 패널, 갤럽의 동의창, 개인 블로그의 뉴스레터 가입창, Field Notes 같은 브랜드 사이트까지 예시로 듦
    • 이제는 웹 어디를 가도 한 번쯤 가로막히는 수준이라, 거의 배경 소음처럼 굳어졌다는 비판임
  • 특히 Substack의 홈 화면은 꽤 악질적인 사례로 언급됨

    • 일반적인 패널처럼 보이지 않고, 화면 전체를 덮는 커튼 형태로 뜸
    • 문구와 배치가 마치 이메일 뉴스레터에 가입해야만 글을 읽을 수 있는 것처럼 느껴지게 만든다고 함
    • 닫기 버튼은 버튼처럼 보이지 않는 작은 텍스트 링크로 숨어 있고, “No thanks” 같은 식으로 사용자가 뭔가 손해 보는 선택을 하는 것처럼 보이게 함

ℹ️참고

> 글쓴이가 문제 삼는 건 모달 자체가 아니라, 사용자의 원래 목적과 무관한 행동을 강요하면서 콘텐츠 접근을 막는 방식임.

  • 더 황당한 건 유료 구독자에게도 이런 방해가 나온다는 점임

    • 글쓴이는 필라델피아 인콰이어러에 월 20달러를 내고 로그인한 상태였는데, 기사 보기 전에 저지 쇼어 문자 알림 신청 모달을 봤다고 함
    • 돈을 내고도 시간과 주의력을 뺏기는 구조라, 볼 때마다 구독 해지를 떠올린다고 함
    • Tom’s Hardware에서는 사이트 자체 딕오버가 광고에 가려지는 자바스크립트 Z축 싸움까지 벌어졌다고 비꼼
  • 로딩 직후 뜨는 딕오버도 별로지만, 읽기 시작한 뒤에 튀어나오는 건 더 나쁨

    • 사용자가 이미 글에 집중하고 스크롤을 내리는 순간 갑자기 모달이 등장하는 패턴을 강하게 비판함
    • 글쓴이는 이걸 실제 책이나 잡지를 읽는 사람 손에서 뺏어 들고 다른 요구를 들이미는 것과 비슷하다고 봄
    • 누군가의 주의를 얻는 것 자체가 이미 특권인데, 그걸 스스로 끊어버리는 디자인이라는 얘기임
  • 딕바(dickbar)는 딕오버보다 낮은 단계의 UX 범죄로 분류됨

    • 딕바는 화면 일부만 가리는 비모달형 바나 팝오버임
    • 전체 콘텐츠를 막지는 않으니 딕오버보다는 덜 나쁘지만, 여전히 읽기와 스크롤을 방해함
    • 특히 가로형 바는 스페이스바로 한 화면씩 넘길 때 읽지 않은 텍스트를 가려버리는 문제가 있음
  • 모든 모달 차단이 딕오버는 아니라는 구분도 중요함

    • 페이월 로그인이나 결제 패널은 짜증날 수는 있어도 필요한 절차라서 딕오버가 아니라고 봄
    • 딕오버의 핵심 조건은 ‘불필요함’임
    • 쿠키 허용, 뉴스레터 가입, 앱 설치 유도처럼 페이지를 읽는 데 본질적으로 필요 없는 요구가 콘텐츠를 막을 때 문제가 됨
  • 개발자 입장에서는 이 글을 그냥 욕 많은 에세이로 넘기기 어렵다

    • 모달, 쿠키 배너, 가입 유도창은 전환율 실험이라는 이름으로 쉽게 붙지만, 사용자 신뢰와 읽기 흐름을 갉아먹음
    • 특히 모바일에서는 작은 화면 전체가 막히기 때문에 방해 강도가 훨씬 커짐
    • “일단 띄우고 나중에 닫게 하지”라는 선택이 실제 사용자 경험에서는 서비스 전체의 인상을 망칠 수 있음

이 글은 욕 섞인 UX rant처럼 보이지만, 핵심은 꽤 실무적임. 전환율 몇 퍼센트 올리겠다고 읽기 흐름을 끊는 순간, 제품은 사용자의 시간을 비용으로 태우고 있는 셈임.

댓글

댓글

댓글을 불러오는 중...

frontend

타입스크립트 7.0, Go 네이티브 포팅으로 빌드가 8~12배 빨라졌다

마이크로소프트가 타입스크립트 7.0을 출시하면서 기존 자바스크립트 기반 구현을 Go로 네이티브 포팅했다. 전체 빌드는 평균 8~12배 빨라졌고, VS코드 빌드는 125.7초에서 10.6초로 줄었으며, 슬랙은 CI 타입 검사 시간을 7.5분에서 1.25분으로 낮췄다.

frontend

타입스크립트 7 공개, 고 포팅으로 빌드가 최대 10배 이상 빨라짐

마이크로소프트가 고(Go)로 네이티브 포팅한 타입스크립트 7을 공개했다. 전체 빌드는 보통 8~12배 빨라지고, VS 코드 코드베이스에서는 125.7초가 10.6초로 줄었으며, 편집기 첫 오류 표시도 17.5초에서 1.3초 미만으로 내려갔다.

frontend

“98% 지원”이 생각보다 별로 안 넉넉한 이유

브라우저 기능 지원률 98%는 얼핏 높아 보이지만, 실제 서비스에서는 2%의 사용자를 깨진 화면 앞에 세우는 숫자일 수 있다는 글이다. 특히 일반 통계와 내 서비스 방문자 분포는 다를 수 있고, 실제 사례로 어떤 사이트는 최신 중첩 CSS 기능 지원 브라우저가 방문자의 약 70%뿐이었다.

frontend

메타, AI가 읽고 쓰는 디자인 시스템 ‘Astryx’ 오픈소스로 공개

메타가 내부 디자인 시스템 Astryx를 오픈소스로 공개했다. React와 StyleX 기반의 150개 이상 접근성 지원 컴포넌트, 디자인 토큰, 테마, 템플릿, CLI를 제공하며, 특히 AI 에이전트가 컴포넌트 구조를 이해하고 UI를 생성·수정할 수 있도록 MCP 서버까지 포함한 점이 핵심이다.

frontend

shadcn/ui, 기본 컴포넌트 라이브러리를 Radix에서 Base UI로 변경

shadcn/ui가 새 프로젝트의 기본 컴포넌트 라이브러리를 Radix가 아니라 Base UI로 바꿨어. Radix 지원은 계속되지만, Base UI가 안정화됐고 주간 다운로드 600만 이상, shadcn/create 신규 프로젝트 선택 비율 2대1이라는 이유로 기본값을 바꾼 거야. 동시에 채팅 UI용 MessageScroller와 관련 컴포넌트, headless 패키지인 @shadcn/react도 공개됐어.