버튼 하나 없어서 지인이 URL을 손으로 복사해 카카오톡에 붙여넣었다는 얘기를 전해 들었다. 그 순간 마찰이라는 게 눈에 보이는 것이 아니라 행동으로 드러난다는 걸 실감했다. 공유하고 싶었는데 버튼이 없어서 그 의지가 행동으로 연결되지 못한 것이다. 나는 이게 내 문제라는 생각이 들었다. 독자의 의지가 있었는데 내가 길을 막은 셈이었으니까.
플러그인을 먼저 찾아봤다. 설치는 간단했지만 블로그 디자인과 이질감이 생겼고, Lighthouse 성능 점수가 적용 전보다 눈에 띄게 떨어졌다. 외부 플러그인은 대부분 자체 JavaScript 번들을 포함하는데, 이 번들이 페이지 초기 렌더링을 지연시키는 렌더 블로킹 현상을 일으킨다. 렌더 블로킹이란 브라우저가 HTML을 파싱하다가 외부 스크립트를 만나면 해당 스크립트가 완전히 로드될 때까지 페이지 표시를 멈추는 현상이다. 공유 버튼 하나 때문에 전체 페이지가 느려지는 건 맞지 않다고 판단했다. 결국 직접 구현 쪽으로 방향을 틀었다.
버튼이 없어도 공유는 일어난다, 문제는 마찰이다
독자가 URL을 직접 복사해서 붙여넣는 행동을 한다는 건 공유 의지가 있다는 뜻이다. 그런데 버튼이 없으면 그 의지가 행동으로 이어지는 중간에 불필요한 단계가 끼어든다. UX에서 말하는 마찰의 전형적인 사례다. 마찰이란 사용자가 원하는 행동을 완료하기까지 겪는 불필요한 저항인데, 클릭 한 번으로 줄일 수 있는 단계가 다섯 단계가 되는 순간 절반 이상의 사용자는 그냥 포기한다.
나는 여기서 한 가지 더 생각하게 됐다. 마찰을 줄이는 것과 공유를 강요하는 것은 다르다. 화면 중간을 가로막는 팝업 공유 유도나, 스크롤을 따라다니는 거대한 공유 버튼 묶음은 마찰을 줄이는 게 아니라 독자를 불편하게 만든다. 글 끝에 조용히 놓여 있는 버튼이 독자의 선택을 가장 자연스럽게 돕는다.
세 채널의 구현 방식은 본질적으로 다르다
카카오, 네이버, X를 선택한 데는 이유가 있다. 국내 메신저 점유율 1위인 카카오톡, 국내 검색 1위 플랫폼 네이버 블로그, 그리고 기술·미디어 분야에서 여전히 영향력 있는 X. 이 세 채널이면 국내 독자가 콘텐츠를 퍼나를 수 있는 경로를 대부분 커버할 수 있다고 판단했다. 세 채널을 구현해보니 방식이 제각각이었다. 이 차이를 이해하지 못하면 디버깅할 때 방향을 잃는다.
카카오는 JavaScript SDK를 공식 제공한다. SDK란 특정 플랫폼의 기능을 외부 개발자가 사용할 수 있도록 묶어둔 도구 모음인데, 카카오의 경우 앱 키를 초기화하고 공유 함수를 호출하면 카카오톡 공유창이 열린다. Kakao Developers에서 앱을 등록하고 JavaScript 키를 발급받는 과정 자체는 10분이면 끝난다. 진짜 함정은 그 이후에 있었다. 썸네일 이미지를 설정하지 않으면 카카오톡 공유 미리보기가 텍스트만 덩그러니 나온다. 이걸 실제로 공유해보고 나서야 발견했다. 미리보기 이미지 없이 공유된 링크는 클릭률이 현저히 낮다는 건 직접 눈으로 확인해야 실감할 수 있다. 나중에는 오픈그래프 메타 태그를 활용하는 방식으로 개선했다. 오픈그래프는 페이지의 제목·이미지·설명 정보를 SNS가 읽어갈 수 있도록 HTML head에 삽입하는 메타데이터 표준이다.
네이버와 X는 URL 파라미터 방식이다. 공유 URL에 제목과 링크 파라미터를 붙여서 팝업을 열면 된다. 여기서 반드시 필요한 것이 encodeURIComponent다. URL에 포함될 수 없는 한글, 공백, 특수문자 등을 퍼센트 인코딩 방식으로 변환해주는 함수인데, 처음에 이걸 빠뜨렸다가 한글 제목이 깨진 채로 공유되는 걸 테스트 중에 발견했다. 인코딩 한 줄 빠진 것치고는 결과물 차이가 컸다.
X는 트위터가 브랜드를 바꾸면서 공유 URL 구조도 변경된 적 있다. 이런 외부 API 변화는 직접 구현 방식이든 플러그인 방식이든 결국 추적해야 한다는 점에서 본질적으로 같은 유지보수 부담을 안고 있다.
색상과 팝업 크기에 신경 쓴 이유
버튼 색상은 각 서비스의 브랜드 컬러를 그대로 유지했다. 처음에는 블로그 전체 색상 톤에 맞춰 통일하는 게 깔끔할 것 같다고 생각했다. 그런데 직접 올려보고 나서 생각이 바뀌었다. 독자는 버튼을 읽지 않고 색으로 인식한다. 브랜드 컬러를 유지했더니 버튼 위에 마우스를 올리기도 전에 어느 채널인지 바로 알아봤다. 색이 곧 언어인 셈이다. 통일감을 위해 그 언어를 지우는 건 손해다.
팝업 창 크기는 실제 테스트를 통해 조율해야 한다. 네이버 공유창은 600×500 정도가 모바일 환경에서도 잘렸다는 피드백 없이 안정적으로 작동했다. 이 수치에 정답은 없다.
직접 구현의 한계와 솔직한 비교
직접 구현의 한계도 분명히 있다. 카카오 API 정책이 바뀌면 JavaScript 키 재발급이나 코드 수정이 필요하고, X처럼 브랜드 자체가 바뀌는 경우엔 URL 구조까지 달라진다. 플러그인은 이런 변화를 자동으로 처리해주는 경우가 많다. 그러나 플러그인도 외부 스크립트를 불러오는 구조상 서드파티 API에 의존한다는 점은 직접 구현과 본질적으로 다르지 않다. 차이는 유지보수 주체가 나인가, 플러그인 개발자인가 하는 것뿐이다.
속도와 커스터마이징이 우선이라면 직접 구현, 유지보수 편의성이 우선이라면 플러그인이 현실적인 선택이다. 나는 전자를 택했고 지금까지 만족하고 있다. 다만 1년에 한 번 정도는 각 플랫폼의 공유 URL 구조가 변경됐는지 확인하는 루틴이 생겼다. 이게 부담이라면 플러그인이 나을 수도 있다.
X의 hashtags 파라미터를 활용해 블로그 주제 관련 태그를 기본으로 넣어두면, 공유된 게시물이 검색 노출되는 빈도가 올라가는 걸 직접 확인했다. 작은 설정 하나가 콘텐츠 도달 범위를 넓혀주는 부분이라 꼭 챙기길 권한다.
카카오 SDK 설정을 마치고 처음 공유 테스트를 했을 때 미리보기가 제대로 나왔던 순간이 생각보다 만족스러웠다. 공유 버튼 하나가 독자의 행동을 얼마나 바꾸는지, 직접 달아보고 나서야 실감할 수 있다.
참고:
카카오 JavaScript SDK 공식 문서: https://developers.kakao.com/docs/latest/ko/javascript/getting-started Kakao Share API: https://developers.kakao.com/docs/latest/ko/message/js-link Twitter(X) Web Intent 공식 문서: https://developer.twitter.com/en/docs/twitter-for-websites/tweet-button/overview 네이버 공유 URL: https://share.naver.com MDN Web Docs – encodeURIComponent: https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent