# Dickover란 무엇인가?

> Clean Markdown view of GeekNews topic #30022. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=30022](https://news.hada.io/topic?id=30022)
- GeekNews Markdown: [https://news.hada.io/topic/30022.md](https://news.hada.io/topic/30022.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-05-30T20:37:21+09:00
- Updated: 2026-05-30T20:37:21+09:00
- Original source: [daringfireball.net](https://daringfireball.net/2026/05/what_is_a_dickover)
- Points: 1
- Comments: 1

## Topic Body

- **dickover**는 웹사이트나 앱이 모달 패널·팝오버·커튼형 UI로 자기 콘텐츠를 가리고, 불필요한 상호작용을 강요하는 방해물임
- 쿠키 수락, 뉴스레터 가입, 앱 설치, 약관 동의처럼 사용자가 읽으려던 콘텐츠와 직접 관련 없는 요구가 대표적임
- **Substack** 홈의 전체 화면 커튼, Philadelphia Inquirer의 SMS 가입 요구, Tom’s Hardware의 Z축 충돌이 주요 사례임
- **dickbar**는 페이지 일부만 가리고 필수 행동을 덜 요구하지만, 텍스트를 덮고 스페이스바 스크롤을 방해해 경험을 해침
- 페이월의 가입·로그인은 콘텐츠 접근에 필요한 절차라 dickover와 다르며, 핵심 기준은 **불필요성**과 관심 차단 여부임

---

### Dickover의 정의와 문제
- **dickover**는 웹사이트나 앱이 자기 콘텐츠를 의도적으로 가리는 모달 패널, 팝오버, 커튼형 UI를 뜻함
- 사용자가 원하지 않고 필요하지도 않은 상호작용을 강요해 콘텐츠 접근을 방해함
- 대표적인 요구는 **쿠키 수락**, 뉴스레터 구독, 모바일 앱 설치, 서비스 약관 동의처럼 사용자가 읽으려던 콘텐츠와 직접 관련 없는 것들임
- 웹과 모바일 앱에서 점점 더 자주 보이며, 일반 팝오버보다 더 직접적으로 사용자의 읽기 흐름을 끊음

### 흔한 유형과 사례
- 쿠키 허용을 요구하는 dickover는 매우 흔하며, [Euronews 사례](https://daringfireball.net/misc/2026/05/dickover-euronews.jpeg)와 [Gallup 사례](https://daringfireball.net/misc/2026/05/dickover-gallup-cookie.png)가 있음
- 뉴스레터 가입 요구도 같은 패턴으로 쓰이며, 개인 블로그인 [Om Malik 사례](https://daringfireball.net/misc/2026/05/dickover-om-newsletter.png)와 브랜드 사이트인 [Field Notes 사례](https://daringfireball.net/misc/2026/05/dickover-field-notes.jpeg)가 포함됨
- **Substack**이 호스팅하는 블로그 홈페이지에는 특히 악질적인 형태의 dickover가 표시됨
  - 패널처럼 보이지 않는 **전체 화면 커튼**으로 글을 읽으려면 이메일 뉴스레터에 가입해야 하는 것처럼 강하게 암시함
  - 닫기 버튼은 버튼처럼 보이지 않는 작은 텍스트 링크로 배치됨
  - [Paul Krugman](https://daringfireball.net/misc/2026/05/dickover-substack-krugman.jpeg)과 [Matt Yglesias](https://daringfireball.net/misc/2026/05/dickover-substack-yglesias.jpeg) 사례는 “No thanks” 같은 문구를 사용함
  - [Volts](https://daringfireball.net/misc/2026/05/dickover-substack-volts.jpeg) 사례는 “Just gimme that content!”처럼 지나치게 달콤한 문구를 씀
- [The Philadelphia Inquirer 사례](https://daringfireball.net/misc/2026/05/dickover-inquirer-shore-texts.jpeg)는 월 **20달러** 구독자가 로그인한 상태에서도 Jersey shore 관련 SMS 수신에 가입해야 기사를 볼 수 있게 함
- [Tom’s Hardware 사례](https://daringfireball.net/misc/2026/05/dickover-dickover-tomshardware.png)는 사이트의 dickover가 자체 광고에 다시 가려지는 JavaScript Z축 충돌을 보여줌

### 웹페이지가 해야 할 일
- 웹사이트에 방문하면 사용자는 **웹사이트 콘텐츠**를 바로 볼 수 있어야 함
- 기사 페이지에서 “뉴스레터 구독”이나 “쿠키 수락” dickover를 먼저 보여주는 것은 웹페이지의 기본 목적과 어긋남
- 웹페이지는 웹페이지를 보여줘야 하고, 이메일은 이메일 내용을 보여줘야 함
- 기사, 스토리, 제품 페이지에 주어진 사용자의 관심은 사이트가 얻은 특권이며, 그 관심을 의도적으로 끊는 행위는 부적절함

### 표시 타이밍이 만드는 더 큰 방해
- 일부 사이트는 페이지 로드 직후 dickover를 띄우며, 사용자는 오늘날 웹페이지 로딩 때 이런 장애물을 어느 정도 예상함
- 더 나쁜 경우는 사용자가 이미 읽기 시작하고 스크롤을 내린 뒤에 **갑자기 dickover**를 띄우는 방식임
- 읽는 도중의 방해는 사용자가 이미 부여한 관심 외의 다른 것을 요구하려고 실제 책이나 잡지를 손에서 빼앗는 행위와 다르지 않음
- 물리적 출판물을 독자의 손에서 빼앗는다면 얼굴을 맞을 수 있다는 비유처럼, 읽기 경험을 끊는 행위는 그만큼 공격적임

### Dickbar와의 차이
- [Dickbar](https://daringfireball.net/linked/2011/03/06/dickbar)는 dickover와 관련 있지만 디자인과 사용자 경험 측면에서는 더 가벼운 위반으로 분류됨
- **dickbar**는 비모달 팝오버로, underlying content 전체가 아니라 일부만 가림
  - 보통 짧은 가로 막대 형태이며, [데스크톱 예시](https://daringfireball.net/misc/2026/05/dickbar-ruxton.jpeg)와 [모바일 예시](https://daringfireball.net/misc/2026/05/dickbar-storm-type.png)가 있음
  - [Apple Newsroom 사례](https://daringfireball.net/misc/2026/05/dickbar-apple-newsroom.png)는 비교적 보기 좋은 형태임
  - [Acquired podcast 사례](https://daringfireball.net/misc/2026/05/dickbar-corner-acquired.jpeg)는 화면 모서리에 배치되어 덜 방해함
  - [Four Seasons 사례](https://daringfireball.net/misc/2026/05/dickbar-big-fourseasons.jpeg)는 너무 커서 dickover에 가까운 수준임
- dickbar가 상대적으로 덜 나쁜 이유는 페이지 전체를 가리지 않고, 닫기 위한 **필수 행동**을 요구하지 않기 때문임
- 그래도 dickbar는 콘텐츠를 가리고 주의를 분산시켜 사용자 경험을 해침
- 특히 가장 흔한 가로형 dickbar는 스페이스바로 한 화면씩 넘길 때 문제를 만듦
  - 페이지는 dickbar 높이를 제외하지 않고 전체 웹페이지 높이만큼 스크롤됨
  - 그 결과 다음 화면으로 이동할 때마다 dickbar가 아직 읽지 않은 텍스트를 가림

### 모달 차단기와 Dickover의 경계
- 모든 **dickover**는 모달 차단기지만, 모든 모달 차단기가 dickover는 아님
- 유료 콘텐츠의 가입 또는 로그인 패널은 dickover가 아님
- 페이월은 때로 성가실 수 있지만, dickover의 핵심 조건 중 하나는 **불필요성**임
- 쿠키 권한 요청과 이메일 뉴스레터 가입 요청은 콘텐츠를 읽기 위해 필요하지 않음
- 반면 페이월 콘텐츠에서는 가입이나 로그인이 필요하므로 dickover와 구분됨

### 용어가 만들어진 배경
- 2022년에는 이런 UI를 [dickpanel](https://daringfireball.net/linked/2022/08/02/banish)이라고 부르기 시작했지만, 이후 dickover가 더 적합한 표현으로 자리 잡음
- 새 용어는 Mac용 드래그앤드롭 “선반” 유틸리티 [Dropover](https://dropoverapp.com/)에 대해 [쓰려던 과정](https://daringfireball.net/linked/2026/05/15/dropover)에서 떠오름
- 그 직전 Euronews의 특히 우스운 쿠키 모달 차단기에 대해 [불평한 항목](https://daringfireball.net/linked/2026/05/14/vestager-ai-safety-institute)이 있었고, 기존 **dickpanel**이라는 표현이 잘 붙지 않는다고 느끼게 됨
- [Mastodon 설문](https://mastodon.social/@gruber/116575825801893849)에서는 “웹사이트와 일부 앱이 콘텐츠를 덮는 창 안의 가짜 대화상자”를 무엇이라 부르는 게 나은지 물었고, 1,130개 응답에서 dickover가 **51대 49**로 근소하게 이김
- 신조어가 자리 잡는 기준은 설명성이나 명확성보다 사용 여부이며, dickover는 날카롭고 쓰기 재미있는 표현으로 보임

## Comments



### Comment 58620

- Author: neo
- Created: 2026-05-30T20:37:22+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48330882) 
- 내 경험은 아마 의도한 그대로였던 것 같음. “What is a dickover?” 링크를 누르며 이게 뭘까 상상하고 있었는데, 페이지가 뜬 뒤 아주 짧은 멈춤이 지나자마자 “This is a Dickover”라는 크고 짜증 나는 팝업이 얼굴을 때렸고 바로 이해됨  
  이제 다음에 **Substack**에 갈 때 이걸 뭐라고 부르면 되는지는 알게 됨

- 개발자와 관리자 중 **97%** 쯤은 5년 전에 자기 제품의 쿠키 동의 같은 걸 한 번 완료해버려서 다시는 보지 않고, 그래서 신규 고객 경험이 실제로 얼마나 나쁜지 모른다는 가설이 있음  
  개발자와 상사들은 자신들이 훌륭히 하고 있고 홈페이지도 잘 다듬었다고 생각하지만, 일반 사용자는 Cloudflare 캡차, 쿠키 모달, 뉴스레터 모달, 앱 설치 모달을 차례로 맞고, 전부가 ‘제품 구매’ 버튼 접근을 막고 있음
  - 거절하면 다음 페이지에서 다시 묻는 것들이 최고임  
    아마 **기능성 쿠키**가 뭔지 모르는 듯함. 마케팅 어휘에는 YES밖에 없을지도 모름
  - “다시는 보지 않는다”면 내가 마주치는 **dickover**의 99.9%보다 나은 구현처럼 들림  
    대부분은 닫아도 나중에 또 보이고, 어떤 건 사이트 방문할 때마다 나오는 느낌임
  - 고객이 어떻게 생각하는지 신경 쓰지 않는다는 가설도 있음
  - 개발자는 사용자 경험에 뭐가 최선인지 판단하는 데 능숙하지 않음. 디자이너와 PM이 그 아름답고 성능 좋은 첫 화면 디자인과 이어지는 자동 로드 모달에 쏟아부은 업계 연구 수십만 시간을 어떻게 정당화하겠나  
    제발 **전문가**에게 맡기라는 말임
  - 웹사이트는 항상 **시크릿 창**에서 테스트해야 함

- **Kagi Small Web**에 포함되는 기준 중 하나가 dickover가 없는 것임. 이름을 제대로 붙여줘서 고마움, John  
  [1] [https://kagi.com/smallweb](<https://kagi.com/smallweb>)
  - Small Web 글의 **원본 링크**를 더 쉽게 공유할 수 있게 해주면 좋겠음. 지금은 너무 어려워서 Kagi 버전 URL을 공유하도록 강제하려는 것처럼 느껴질 정도임
  - 이 특정 페이지에는 예외를 두면 좋겠음
  - 참고로 “next”를 세 번 누르자 **쿠키 dickover**가 있는 페이지가 나왔음. 필터를 좀 조정해야 할 듯함
  - 진짜 dickover 순간은 서비스를 쓰기 시작한 뒤 그들이 **Yandex**와 거래한다는 걸 깨닫는 때임

- 자바스크립트를 켜고 끌 수 있는 **브라우저 확장 기능**을 설정해두면 대부분의 팝업, 잔소리 화면, 쿠키 요구를 막을 수 있음. 그런 확장은 여러 개 있음  
  대안으로 자바스크립트를 영구적으로 끈 다른 브라우저를 트레이나 백그라운드에 최소화해 두는 방법도 있음  
  구독을 요구하거나 잔소리 화면을 띄우거나 다른 차단을 쓰는 많은 웹사이트는 자바스크립트만 끄면 읽을 수 있음  
  웹사이트의 자바스크립트는 기업이 우리를 조작·통제하고 잔소리 화면을 띄우거나 구독을 요구하는 수단이 되어버림  
  로드 전에 자바스크립트를 요구하는 사이트를 만나면 그냥 버리고 영원히 보지 않음

- 이 이름을 지지함. 이 기법의 표준 이름이 되면 회의에서 진지하게 제안할 때 사람들이 그 단어를 써야 하고, 그러면 진지하게 제안하기가 더 어려워짐  
  “이게 우리 Dickover 디자인입니다”  
  “여러분, 고객에게 Dickover를 씌우는 건 좀 아닌 것 같습니다”  
  “그렇게 말하니까 좀 그렇네요…”  
  에필로그: 6개월 뒤, 뉴스레터 전환이 전혀 안 돼서 사이트는 망함
  - 대체 그런 사람들은 누구임? dickover가 얼굴에 붙어도 전혀 분노하지 않고 계속 즐거워하며, 그 dickover에 **이메일 주소**를 입력하는 걸 진지하게 고려하는 사람들 말임

- 이 **북마클릿**은 가지고 있으면 아주 좋음  
  ```  
  javascript:(function()%7B let i%2C elements %3D document.querySelectorAll('body *')%3B for (i %3D 0%3B i < elements.length%3B i%2B%2B) %7B if(getComputedStyle(elements%5Bi%5D).position %3D%3D%3D 'fixed' %7C%7C getComputedStyle(elements%5Bi%5D).position %3D%3D%3D 'sticky')%7B elements%5Bi%5D.parentNode.removeChild(elements%5Bi%5D)%3B %7D %7D %7D)()  
  ```  
  가끔은 위걸 쓴 뒤 **스크롤**을 고치려고 이 두 번째 것도 필요함  
  ```  
  javascript:var r="html,body{overflow:auto !important;}"; var s=document.createElement("style"); s.type="text/css"; s.appendChild(document.createTextNode(r)); document.body.appendChild(s); void 0;  
  ```

- Substack에서 이것들을 명시적으로 꺼도 내 글에 어쨌든 붙음. 버그인지 의도대로 동작하는 건지는 모르겠지만, 그걸로 충분히 **Substack 사용을 그만두게** 됨  
  독자들에게 그런 짓을 하고 싶지 않음
  - Substack의 수상한 관행은 그들의 수상한 정치성만큼 나쁘지는 않음  
    [https://www.theguardian.com/media/2026/feb/07/revealed-how-s...](<https://www.theguardian.com/media/2026/feb/07/revealed-how-substack-makes-money-from-hosting-nazi-newsletters>)

- 나처럼 웹사이트를 읽으려고 **확대**해서 보는 사람에게는 이런 것들이 특히 짜증 남  
  닫기 버튼을 찾으려면 다시 축소해야 함. 매번 추격전이고, 때로는 그냥 포기하게 됨  
  **EU Web Accessibility Directive**가 있는데 이런 게 어떻게 허용되는지 모르겠음
  - HN 자체도 **UI 배율**이 1.0보다 크면 형편없음  
    텍스트를 읽으려고 계속 가로 스크롤을 하게 됨

- 이게 영리한 **keming** 말장난이라고 생각한 사람이 또 있었는지 궁금함  
  다행히 콘텐츠에 자바스크립트가 필요하거나 dickover를 제거하는 데 자바스크립트가 필요한 사이트에서도, 브라우저의 요소 검사 도구로 이런 것들과 다른 성가신 요소를 삭제하는 건 그리 어렵지 않고 꽤 후련함
  - Safari의 **Hide Distracting Items** 기능은 내가 Chrome을 쓰지 않는 큰 이유임
  - dickover의 소문자 버전을 처음 봤을 때는 **clickover**라고 읽었음

- 나에게는 dickover가 가능하다는 사실 자체가 모든 **자바스크립트 인터프리터**의 버그임  
  제대로 된 브라우저라면 dickover뿐 아니라 웹페이지가 우클릭 메뉴를 바꾸거나 텍스트 선택을 막는 것 같은 관련 적대적 동작도 불가능하게 만들어야 한다고 봄  
  안타깝게도 스크립트를 완전히 끄는 건 많은 사이트가 아예 동작하지 않아서 해결책이 되기 어렵지만, 위에서 말한 행동들은 사용자에게 유용한 목적이 전혀 없으므로 효과가 없어야 하고, 적대적 사이트가 그 동작이 먹히는지 아닌지 알아낼 방법도 없어야 함  
  모달 창은 내가 제어하는 애플리케이션에서는 가끔 유용할 수 있지만, 인터넷 사이트를 탐색할 때처럼 외부가 제어하는 애플리케이션에서는 항상 **무시하거나 우회**할 수 있어야 함
  - 진짜 궁금한데, 원하는 모달 팝오버 콘텐츠인 드롭다운 메뉴, 툴팁, 떠 있는 내비게이션 바는 허용하면서 somehow dickover만 막기 위해 **자바스크립트 구현**이나 DOM, 브라우저 쪽에서 뭘 할 수 있을까?