저는 꽤 오랫동안 블로그 글의 신뢰도가 '내용'에서만 나온다고 생각했습니다. 그런데 지인에게 "정보는 있는데 누가 쓴 건지 모르겠다"는 말을 들었을 때 처음으로 의심이 생겼습니다. 내용이 아무리 좋아도, 읽는 사람이 '차갑다'고 느끼면 결국 신뢰는 생기지 않는다는 걸 그때 처음 실감했습니다. 그 이후로 CSS 디자인으로 글에 시각적 온기를 더하는 실험을 시작했고, 예상보다 훨씬 뚜렷한 변화를 경험했습니다.
손글씨 폰트가 독자의 시선을 붙잡는 이유
여러분도 블로그를 읽다가 어떤 섹션에서 유독 스크롤이 멈춘 경험이 있으신가요? 저는 그 원인을 한동안 '글의 내용' 때문이라고만 생각했는데, 실제로 Hotjar 히트맵을 통해 확인해보니 조금 달랐습니다. Hotjar 히트맵이란 웹페이지 위에서 사용자의 스크롤 흐름과 클릭 위치를 시각적으로 보여주는 UX 분석 도구입니다. 쉽게 말해, 독자가 어느 부분에서 멈추는지를 '열지도' 형태로 확인할 수 있습니다.
제가 인용문 섹션에 Nanum Pen Script 폰트를 적용했을 때, 그 영역 위에서 스크롤이 멈추는 비율이 다른 섹션보다 눈에 띄게 높았습니다. 글씨체 하나 바꿨을 뿐인데 체류 시간이 달라진 겁니다. UX 연구들이 반복적으로 확인하는 것처럼, 손글씨 폰트는 인간의 고유한 흔적을 암시하는 시각적 신호 역할을 합니다. 독자는 의식하지 못해도, '이 글을 직접 쓴 사람이 있다'는 느낌을 무의식적으로 받는 것 같았습니다.
Nanum Pen Script는 Google Fonts에서 제공하는 한글 손글씨 계열 웹 폰트로, @import 한 줄로 바로 불러와 쓸 수 있습니다. 다만 저는 본문 전체에 적용하는 실수를 초반에 한 번 했습니다. 결과는 처참했습니다. 모바일에서 가독성이 크게 떨어졌고, 오히려 읽기 불편하다는 피드백이 들어왔습니다. 손글씨 폰트는 인용문이나 필자 개인 노트처럼 제한된 영역에서만 써야 효과가 유지됩니다.
형광펜 하이라이트 효과, 왜 이렇게 반응이 좋을까
형광펜 효과를 처음 적용했을 때, 솔직히 이건 예상 밖이었습니다. CSS 속임수 하나가 이 정도 반응을 만들 줄은 몰랐거든요. 핵심 문장 5~7개에 반투명 노란 하이라이트를 넣었더니, 독자들이 스크롤을 내리다 그 부분에서 멈추는 패턴이 히트맵에서 선명하게 보였습니다.
이 효과는 CSS의 linear-gradient() 속성으로 구현합니다. linear-gradient()란 두 가지 이상의 색상을 직선 방향으로 점진적으로 혼합하는 CSS 그라디언트 함수로, 배경에 적용하면 형광펜으로 칠한 것 같은 반투명 색상 띠를 만들 수 있습니다. 핵심은 투명 구간(40%)과 색상 구간(40~100%)을 같은 위치에서 전환시켜 경계선을 날카롭게 만드는 것입니다. 이렇게 하면 실제 형광펜처럼 텍스트 아래쪽에만 색이 깔리는 효과가 납니다(출처: MDN Web Docs).
왜 이 효과가 통할까 생각해보면, 결국 '독서 흔적'의 문제입니다. 형광펜 표시는 누군가가 이 글을 직접 읽고 중요한 부분을 골라냈다는 물리적 증거처럼 보입니다. AI가 자동 생성한 느낌이 아니라, 한 사람이 정말로 이 텍스트를 읽었다는 시각적 신호인 셈입니다. 하지만 여기서 한 가지 주의할 점이 있습니다. 모든 문장에 하이라이트를 넣으면 아무것도 강조되지 않는 것과 같습니다. 제 경험상 전체 본문의 10~15% 이내 문장에만 적용해야 효과가 살아납니다.
Core Web Vitals와 웹 폰트 성능, 놓치기 쉬운 함정
손글씨 폰트와 형광펜 효과가 좋다고 해서 무턱대고 적용하면 뒤통수를 맞습니다. 제가 실제로 맞았습니다. 폰트를 추가한 직후 Core Web Vitals 점수 중 LCP가 눈에 띄게 떨어진 겁니다. Core Web Vitals란 Google이 웹페이지의 사용자 경험을 측정하는 세 가지 핵심 지표의 묶음으로, 여기서 LCP(Largest Contentful Paint)는 페이지에서 가장 큰 콘텐츠 요소가 화면에 표시되는 데 걸리는 시간을 의미합니다. 쉽게 말해, 독자 눈에 글이 실제로 보이기까지 얼마나 걸리느냐입니다. Google은 이 지표를 검색 랭킹 평가에 직접 반영합니다(출처: Google Search Central).
이 문제를 해결하는 방법은 두 가지입니다.
- font-display: swap 속성 추가: 웹 폰트가 로딩되기 전에 시스템 폰트를 먼저 보여주고, 폰트가 준비되면 교체하는 방식입니다. 독자는 폰트가 바뀌는 것을 거의 느끼지 못하면서 빠른 초기 렌더링을 경험합니다.
- preconnect 힌트 삽입: HTML의 head 태그 안에 Google Fonts 서버에 미리 연결을 시도하는 링크를 추가해 폰트 요청 시간을 단축합니다.
이 두 가지를 함께 적용하고 나서 LCP가 회복됐습니다. 시각적 온기를 더하면서도 로딩 성능을 지키는 균형점은 결국 작은 설정 하나에 있었습니다.
포스트잇 메모 박스, 인간적 흔적을 더하는 마지막 퍼즐
손글씨 폰트, 형광펜 다음으로 제가 실험한 것은 포스트잇 스타일 메모 박스였습니다. 그런데 이게 세 가지 중에서 독자 반응이 가장 좋았습니다. 솔직히 CSS 구현 자체는 어렵지 않습니다. 살짝 노란 배경, 미세하게 기운 transform: rotate(-0.5deg), 상단에 테이프처럼 보이는 ::before 가상 요소까지 조합하면 실제 포스트잇처럼 보입니다.
여기서 transform: rotate()란 CSS로 요소를 지정한 각도만큼 회전시키는 변환 함수입니다. 0.5도처럼 아주 작은 값을 주면 인간이 손으로 붙인 것 같은 미세한 기울기가 생겨 기계적인 느낌을 지우는 데 효과적입니다.
이 메모 박스가 통하는 이유는 단순합니다. 포스트잇은 '내가 이 내용을 읽으면서 따로 적어둔 메모'라는 맥락을 자연스럽게 전달합니다. AI가 자동으로 생성한 글에서는 절대 나올 수 없는 형식이기 때문에, 독자가 무의식중에 '이 사람이 직접 읽고 정리했구나'라고 느끼게 됩니다. 제 경험상 이 세 가지 요소를 함께 쓸 때 가장 효과적인 배치는 다음과 같습니다.
- 손글씨 폰트: 직접 인용문 또는 필자의 개인 노트 섹션
- 형광펜 하이라이트: 본문 핵심 문장 5~7개 이내
- 포스트잇 메모 박스: 섹션 마지막에 '한 줄 요약' 또는 '필자 생각' 형태로 1회
세 가지를 동시에 남발하면 오히려 시끄럽게 보입니다. 각각의 역할을 명확히 구분해서 쓰는 것이 포인트입니다.
결국 이 모든 실험이 가르쳐 준 것은 하나입니다. 독자는 정보를 읽는 동시에, 이 글을 쓴 사람이 실제로 존재하는지를 무의식적으로 확인하고 있다는 것입니다. 손글씨 폰트 한 줄, 형광펜 표시 몇 개, 포스트잇 메모 하나가 그 확인에 답해주는 시각적 신호가 됩니다. 지금 운영 중인 블로그가 있다면, 인용문 하나에 Nanum Pen Script를 적용해보는 것부터 시작해 보시길 권합니다. 작은 변화인데 독자의 반응이 달라지는 순간을 직접 확인하게 될 겁니다.
참고:
Google Fonts — Nanum Pen Script: https://fonts.google.com/specimen/Nanum+Pen+Script
MDN Web Docs — CSS linear-gradient(): https://developer.mozilla.org/en-US/docs/Web/CSS/gradient/linear-gradient
Google Web Fundamentals — Font Best Practices: https://web.dev/font-best-practices/