블로그에 구독 유도 장치를 여러 개 달아봤는데 다 효과가 없었던 경험이 있습니다. 사이드바, 글 하단 CTA, 본문 중간 삽입까지 시도해봤지만 공통적으로 독자 반응이 없었습니다. 그러다 상단 고정 알림 바를 달기 시작했고, 달고 나서야 왜 이게 맞는 위치인지 이해했습니다. 이 글은 그 과정에서 직접 겪은 실수와 해결 방법을 정리한 것입니다.
position fixed와 padding-top 보정
처음 알림 바를 달았을 때 글 제목이 보이지 않는 상황이 생겼습니다. 방문자가 페이지에 들어오면 글 제목 첫 줄이 알림 바에 그대로 가려져 있었습니다. 원인은 간단했습니다. position: fixed 속성을 적용했는데 body에 padding-top 보정을 하지 않은 것이었습니다. 이게 문제의 전부인데, 처음엔 왜 제목이 안 보이는지 한참 헤맸습니다. 도입한 기능이 문제를 만들고 있을 거라는 생각을 처음부터 하기 어려웠습니다.
position: fixed란 해당 요소를 일반 문서 흐름(document flow)에서 완전히 분리해 뷰포트, 즉 브라우저 화면 기준으로 고정시키는 속성입니다. 쉽게 말해 다른 요소들은 이 고정 요소가 존재하지 않는 것처럼 자리를 잡기 때문에, 알림 바 높이만큼 본문이 가려지는 현상이 반드시 생깁니다(출처: MDN Web Docs). 이게 CSS 기본 동작이라는 걸 알면 당연한 일인데, 처음 접할 때는 전혀 예상 밖의 결과로 느껴집니다.
해결 자체는 간단합니다. body에 padding-top을 알림 바 높이와 동일하게 설정하면 됩니다. 그런데 제가 처음에는 고정값으로 넣었다가 텍스트 양이 바뀌면서 알림 바 높이가 달라지는 문제를 다시 겪었습니다. 이후에는 JavaScript로 알림 바 요소의 실제 높이를 동적으로 읽어서 padding-top에 적용하는 방식으로 바꿨습니다. 폰트 크기나 문구를 수정할 때마다 CSS를 손댈 필요가 없어져서 훨씬 편해졌습니다. 처음부터 이렇게 했으면 좋았을 텐데, 고정값으로 먼저 해보고 나서야 이 방식의 필요성을 실감했습니다.
모바일에서는 이 문제가 더 심각해질 수 있습니다. 제가 직접 겪었는데, 텍스트가 조금 길면 모바일 환경에서 두 줄로 줄 바꿈이 되면서 알림 바가 예상보다 훨씬 높아집니다. 화면 상단 15~20%를 알림 바가 차지하게 되면 콘텐츠가 심하게 가려지고, 이 정도면 구글이 모바일 인터스티셜(interstitial) 패널티 기준에 근접할 수 있습니다. 여기서 인터스티셜이란 사용자가 원하는 콘텐츠를 보기 전에 화면을 가리는 UI 요소를 말합니다. 구글은 모바일에서 콘텐츠를 방해하는 인터스티셜에 검색 순위 페널티를 부여합니다. 저는 이 위험을 알고 나서부터 모바일에서는 문구를 짧게 유지하는 걸 원칙으로 삼았습니다. "구독하면 최신 글 알림을 받을 수 있습니다" 같은 긴 문장보다 "새 글 알림 받기"처럼 한 줄에 끝나는 문구가 훨씬 안전합니다.
z-index 설정도 빠뜨리면 안 됩니다. z-index란 요소 간 레이어 쌓임 순서를 결정하는 속성으로, 값이 클수록 화면 위쪽에 렌더링됩니다(출처: MDN Web Docs). 알림 바처럼 항상 최상단에 있어야 하는 요소에는 z-index: 9999 정도를 부여하는 것이 일반적입니다. 쌓임 맥락(stacking context)이 복잡하게 얽혀 있는 테마에서는 이 값을 설정해도 다른 요소에 가려지는 경우가 생기는데, 이럴 때는 부모 요소의 position과 z-index를 같이 확인해야 합니다. 저도 한 번 이 문제를 만나서, 알림 바가 분명히 z-index가 높은데도 다른 요소 뒤에 가려지는 상황을 겪었습니다. 원인은 부모 요소가 새로운 쌓임 맥락을 만들고 있었던 것이었는데, 이게 처음엔 왜 그런지 전혀 감이 잡히지 않았습니다.
sessionStorage 연동과 닫기 버튼 설계
닫기 버튼의 중요성은 직접 경험으로 알게 됐습니다. 알림 바를 처음 달았을 때 닫기 버튼이 없었는데, 몇몇 독자들이 게시판에 "상단 띠 광고가 거슬린다"는 반응을 남겼습니다. 닫기 버튼 하나를 추가하고 나서 그런 피드백이 사라졌습니다. 사용자가 선택권을 가진다는 것만으로 부정적인 반응이 줄어드는 걸 직접 확인한 순간이었습니다. 그 이후로 저는 강제로 노출하는 방식에 대해 회의적으로 보게 됐습니다. 선택권을 주는 게 장기적으로 훨씬 낫다는 걸 수치가 아닌 피드백으로 먼저 배웠습니다.
사용자 인터페이스 연구에서도 이 방향을 지지합니다. 사용자가 통제권을 가질 수 있도록 설계된 알림일수록 수용률이 높다는 결과가 있으며, 이는 구독 유도 UI 설계에도 그대로 적용됩니다(출처: Nielsen Norman Group). 거슬리지 않는 방식으로 정보를 전달하는 알림이 더 효과적이라는 원칙은 경험으로도 확인됩니다.
닫기 버튼을 달았다면 sessionStorage 연동은 거의 필수입니다. sessionStorage란 브라우저 탭 단위로 데이터를 저장하는 웹 스토리지로, 탭을 닫으면 저장된 데이터가 사라지는 특성이 있습니다. 닫기 버튼을 눌렀는데 새로고침하면 알림 바가 다시 나타난다면, 독자는 같은 세션 안에서 계속 닫기를 눌러야 합니다. 이 경험이 반복되면 사이트 자체에 피로감을 느끼게 됩니다. sessionStorage에 닫힘 상태를 저장해두면 한 세션 내에서 한 번 닫으면 다시 나오지 않습니다. 이게 없으면 닫기 버튼이 있어도 없는 것과 다름없습니다. 저도 이 부분을 처음엔 빠뜨렸는데, 독자 입장에서 테스트해보다가 "이거 완전 짜증나겠다"는 생각이 들어서 바로 추가했습니다.
localStorage를 쓸지 sessionStorage를 쓸지는 목적에 따라 다릅니다. localStorage란 브라우저에 데이터를 영구 저장하는 웹 스토리지로, 탭이나 브라우저를 닫아도 데이터가 유지됩니다. 구독 유도를 장기간 중단하고 싶다면 localStorage가 적합하고, 매 방문 세션마다 한 번씩 기회를 주고 싶다면 sessionStorage가 맞습니다. 저는 구독 유도 목적이라 sessionStorage를 선택했고, 같은 세션 내에서 알림 바가 반복 노출되는 문제가 해결됐습니다. 이 선택은 운영 방침에 따라 달라지는 문제이지 기술적 우열의 문제가 아닙니다. 어느 쪽을 선택하든 의도가 명확해야 합니다.
한 가지 더 짚고 싶은 부분이 있습니다. 알림 바는 첫 방문자와 재방문자를 구분하지 않습니다. 이미 구독한 독자에게도 "구독하세요"라는 메시지가 반복 노출되는 건 불필요한 노이즈입니다. 이를 해결하려면 구독 완료 여부를 쿠키(cookie)나 localStorage에 저장해두고, 이미 구독한 사람에게는 알림 바 자체를 렌더링하지 않는 로직이 필요합니다. 여기서 쿠키란 브라우저에 소량의 데이터를 저장하는 방식으로, 유효기간을 설정할 수 있어 구독 상태 기록에 적합합니다. 이 부분까지 구현하면 알림 바가 진짜 필요한 사람에게만 보이는 구조가 됩니다. 저는 구독자에게까지 알림 바를 보여주다가 직접 구독을 해제한 분의 피드백을 받고 나서야 이 문제를 인식했습니다. 그 분이 그냥 넘어가줬기 때문에 망정이지, 아닐 수도 있었습니다.
상단 고정 알림 바는 콘텐츠를 방해하지 않으면서 구독 유도 메시지를 전달할 수 있는 위치라는 게 직접 써보고 내린 결론입니다. 하지만 구현 방식이 허술하면 오히려 독자 경험을 해칩니다. padding-top 보정, 동적 높이 처리, sessionStorage 연동, 그리고 닫기 버튼까지 갖춰야 비로소 제대로 된 알림 바라고 할 수 있습니다. 달고 끝이 아니라 달고 나서 모바일에서 직접 확인하고, 독자 반응을 보면서 조정하는 과정이 필요합니다. 처음부터 완벽할 필요는 없지만, 위에서 언급한 실수들은 미리 알고 피할 수 있으면 좋겠습니다. 저처럼 독자 피드백을 받고 나서 수정하는 방식보다는요.
참고: MDN Web Docs – position: https://developer.mozilla.org/ko/docs/Web/CSS/position
MDN Web Docs – z-index: https://developer.mozilla.org/ko/docs/Web/CSS/z-index
Google UX Playbook for News: https://services.google.com/fh/files/misc/ux-playbook-for-news.pdf
Nielsen Norman Group – Notification Design: https://www.nngroup.com/articles/user-interface-notifications
티스토리 스킨 편집 가이드: https://notice.tistory.com