'딕오버(dickover)'라는 단어를 처음 들으면 잠깐 멈칫하게 된다. 하지만 John Gruber가 Daring Fireball에서 명명한 이 개념은, 한 번 알고 나면 웹을 다르게 보게 만든다. 딕오버란 웹사이트나 앱이 모달·팝오버·커튼형 UI로 자기 콘텐츠를 스스로 가리면서 사용자에게 불필요한 상호작용을 강요하는 안티패턴이다. 쿠키 수락, 뉴스레터 가입, 앱 설치 유도—사용자가 읽으러 온 콘텐츠와 아무 관계 없는 요구들이 그 자리를 채운다.
문제는 이 안티패턴이 나쁜 의도에서 나오는 게 아니라는 점이다. Hacker News 댓글에서 한 사람이 정확하게 짚었다. "개발자와 관리자 중 97%는 쿠키 동의를 한 번 완료해버려서 다시는 보지 않는다. 그래서 신규 사용자가 실제로 얼마나 많은 장벽을 마주하는지 모른다." 자기 제품을 이미 알고 있는 사람이 시크릿 창을 열지 않으면, Cloudflare 캡차 → 쿠키 모달 → 뉴스레터 모달 → 앱 설치 모달로 이어지는 온보딩 지옥을 경험하지 못한다. 딕오버는 설계 실수가 아니라 검증 공백의 결과다.
그렇다면 AI 시대에 이 검증 공백을 어떻게 메울 수 있을까. dev.to의 한 솔로 파운더가 흥미로운 실험을 공개했다. 'personalab'이라는 오픈소스 툴로 12개의 LLM 시뮬레이션 페르소나에게 자신의 제품(mcp-doctor)을 5일간 평가하게 한 것이다. 결과는 12명 중 4명 유료 전환 의향(33%), 2명 이탈, 6명 무료 잔류였다. 숫자 자체보다 중요한 건 왜 이탈했는지가 명확하게 드러났다는 점이다. Growth PM 페르소나는 "이 도구의 OKR은 공급망 신뢰, 내 OKR은 전환율—둘은 직교한다"고 판단해 이탈했다. 이건 실제 사용자 인터뷰에서도 쉽게 나오기 어려운 수준의 구체적 이유다.
이 접근이 특히 흥미로운 이유는 딕오버 문제와 맞닿아 있기 때문이다. 딕오버가 생기는 근본 원인 중 하나는 "전환율 올리기"라는 KPI와 "사용자 경험 보호"라는 가치 사이의 충돌을 조기에 검증하지 않는 것이다. LLM 페르소나 시뮬레이션은 그 충돌 지점을 빠르게 드러낸다. "뉴스레터 팝업을 띄우면 전환율이 올라갈까?"가 아니라, "이 팝업이 어떤 페르소나에게 어떤 맥락에서 거부감을 주는가?"를 묻는 방식으로 사고를 전환하게 만든다. 물론 LLM 시뮬레이션은 실제 고객 인터뷰를 대체할 수 없다. 파운더 스스로도 "Claude Haiku 4.5 기반 시뮬레이션이며 PMF 검증이 아닌 하나의 신호로 봐달라"고 명시했다. 하지만 빠른 프로토타이핑 → 가설 검증 → 고도화 흐름에서 초기 신호를 얻는 도구로서의 가능성은 충분히 실용적이다.
한편, AI를 검증 도구로 쓰는 것과 AI를 거버넌스 레이어로 쓰는 것은 완전히 다른 이야기다. dev.to의 또 다른 글은 에이전트 AI 스택에서 흔히 발생하는 치명적 설계 실수를 지적한다. 하나의 LLM 출력을 또 다른 LLM이 검증하는 구조—"당신은 보안 검증자입니다. 안전하지 않으면 RED를 반환하세요"라는 프롬프트로 거버넌스를 구현하는 방식이다. 문제는 이 구조가 프로덕션에서 수백~수천 밀리초의 레이턴시를 추가하고, 같은 입력에 다른 출력을 낼 수 있으며, 클라우드 비용을 급격히 늘린다는 것이다. 저자는 "확률적 시스템이 또 다른 확률적 시스템을 신뢰할 수 있게 거버닝할 수 있는가?"라는 질문을 던지며, 결정론적 거버넌스 레이어(QRL-ACE-DDE 구조)를 대안으로 제시한다. 이 레이어는 서브밀리초 레이턴시로 동일한 구조적 입력에 항상 동일한 결정을 내린다.
이 세 가지 사례는 하나의 맥락으로 수렴한다. 잘못된 레이어에 잘못된 도구를 배치하면 사용자 경험이 망가진다. 딕오버는 전환율 도구를 콘텐츠 레이어에 끼워 넣은 결과다. LLM 감시 레이어는 추론 도구를 거버넌스 레이어에 끼워 넣은 결과다. LLM 페르소나 검증은 반대로, 정성적 인사이트가 필요한 자리에 AI의 시뮬레이션 능력을 적절하게 배치한 사례다. 도구의 우열이 아니라 배치의 적합성이 핵심이다.
프론트엔드 개발자 입장에서 이 흐름이 시사하는 실천은 세 가지다. 첫째, 자기 제품을 항상 시크릿 창에서 본다. 로그인 상태, 캐시 없는 상태의 첫 경험을 주기적으로 확인하는 것이 딕오버를 막는 가장 단순하고 효과적인 방법이다. 둘째, LLM 페르소나 시뮬레이션을 초기 UX 검증 도구로 활용한다. 실제 사용자 테스트 전에 "이 UI가 어떤 페르소나에게 마찰을 만드는가"를 빠르게 탐색하는 용도로 쓸 수 있다. 셋째, AI를 쓰는 레이어와 결정론적 규칙이 필요한 레이어를 구분한다. 창의적 생성과 추론은 LLM에게, 일관성과 예측 가능성이 요구되는 거버넌스는 결정론적 시스템에게 맡기는 하이브리드 아키텍처가 프로덕션 신뢰성의 기반이 된다.
'딕오버'라는 단어가 회의실에서 쓰이기 시작하면 무슨 일이 벌어질까. Hacker News의 한 댓글이 재미있게 묘사했다. "이게 우리 딕오버 디자인입니다"라고 발표하는 순간, 진지하게 제안하기가 훨씬 어려워진다. 언어는 문화를 만든다. AI 시대에 UX 안티패턴을 설계하지 않으려면, 우리가 무엇을 하고 있는지 정확하게 부를 수 있는 언어가 먼저 필요하다. 그리고 그 언어 위에, 빠른 검증 도구와 적절한 거버넌스 레이어를 얹는 것—그게 지금 프론트엔드 개발자가 해야 할 설계다.