웹 개발을 배울 때 부터 접근성에 관심이 있었는데 겉핥기 말고 한번 제대로 배워봐야겠다는 생각이 들어서 관련 자격증을 따보려고 공부를 시작했습니다. 그리고 오늘 DHS Trusted Tester Certification 시험에 합격했습니다. 그 과정에 대해 소소하게 적어보겠습니다.
Trusted Tester for Web Certification이란?
DHS Trusted Tester for Web Certification는 미국 국토안보부(DHS, Department of Homeland Security)에서 제공하는 웹 접근성(Web Accessibility) 공식 인증 제도 및 교육 과정입니다.
장애가 있는 사람들도 웹사이트와 디지털 콘텐츠를 원활하게 이용할 수 있도록 보장하는 미국의 법적 기준인 ‘Section 508(재개정된 제508조)’ 및 WCAG(웹 콘텐츠 접근성 지침) 표준에 따라, 웹사이트의 접근성을 표준화된 방법으로 테스트하고 검증할 수 있는 능력을 인증합니다.
주요 특징
목적: 웹사이트나 디지털 문서가 접근성 표준을 준수하는지 반복 가능하고 신뢰성 있게 평가(Manual Testing)할 수 있는 전문 테스터를 양성하기 위함입니다.
교육 및 비용: DHS에서 전액 무료로 제공하며, 온라인 자기주도형 학습과 실습으로 진행됩니다.
주요 테스트 도구: 정부 승인 도구인 ANDI, Axe DevTools, WAVE, 스크린 리더(NVDA, VoiceOver) 및 키보드 네비게이션 등을 활용하는법을 배웁니다.
시험 방식: 실제 웹페이지의 접근성 결함(대체 텍스트 누락, 키보드 접근성 문제, 낮은 색상 대비 등)을 찾아내는 실기 및 이론 시험을 통과해야 합니다.
요즘 직접 웹사이트를 만들기 시작하신분들이 많은데요, 제작하면서 웹접근성 측면에서 놓칠 수 있는 부분들을 체크리스트로 정리해봤습니다.
이 체크리스트는 접근성 높은 디자인을 위한 출발점일 뿐, 최종 목적지가 아닙니다. 여기에는 가장 중요한 개념들이 담겨 있습니다. 단순히 최소 기준을 충족하는 수준을 넘어, 당사자가 실제로 만족하고 유용하게 활용할 수 있고 필요에 꼭 맞는 디자인을 구현하기 위해 더욱 고민해 보시기 바랍니다.
페이지 제목
페이지 제목(브라우저에 표시되는 페이지 제목이며, 본문 내 주요 제목이나 <h1> 요소는 아님)이 해당 페이지의 주제나 목적을 설명하고 있나요?
헤딩
제목처럼 보이고 기능하는 모든 텍스트가 제목 태그(<h1>-<h6>)로 돼있나요?
제목 레벨은 스타일을 고려해서가 아니라, 콘텐츠 내의 올바른 위계를 나타낼 수 있도록 선택되었나요?
내비게이션
반복적인 탐색 과정을 건너뛰고 바로 본문 콘텐츠로 이동할 수 있는 방법이 제공되나요? 이를 위한 주요 기법으로는 HTML/ARIA 랜드마크(예: header, navigation, main, footer)를 설정하거나 ‘스킵 링크(skip navigation links)’를 제공하는 것 등이 있습니다.
코드 순서에 따라 결정되는 콘텐츠의 읽기 순서 및 포커스 이동 순서가 논리적이고 직관적인가요?
링크
링크 텍스트가 링크의 목적이나 목적지를 명확하게 설명하고 있나요?
색상/대비
정보가 색상 이외의 다른 수단을 통해서도 전달되나요? 예를 들어 폼에 오류가 있음을 나타낼 때 색상과 텍스트를 함께 사용하거나, 차트 항목을 표시할 때 색상과 텍스트를 병기하는 경우가 이에 해당합니다.
모든 텍스트는 배경색과 최소 4.5:1(큰 텍스트의 경우 3:1)의 색상 대비를 갖추고 있나요?
링크 텍스트를 일반 텍스트와 구분할 수 있는 요소가 색상 외에도 존재하나요?
마우스를 사용하지 않는 사용자가 Tab 키나 화살표 키를 사용하여 상호작용 가능한 요소로 이동했을 때, 해당 요소에 명확하고 눈에 띄는 포커스가 표시되나요?
콘텐츠에 접근하거나 이를 이해하는 데 중요한 모든 비텍스트 요소(사용자 인터페이스 구성 요소 및 그래픽 객체)는 최소 3:1의 충분한 색상 대비를 갖추고 있나요?
확대 기능과 반응형 디자인
저시력 사용자가 데스크톱, 모바일 등 어떤 기기에서든 브라우저 내 콘텐츠를 확대하거나 크게 볼 수 있나요?
디자인이 모든 확대 수준에 최적화되어 있나요? 가로 스크롤이 발생하지 않도록 디자인을 최대한 단순화하세요.
사용자가 원하는 방향(가로 또는 세로)으로 기기를 설정한 상태에서 웹사이트를 이용할 수 있나요?
이미지
정보 전달용 이미지에 대한 대체 텍스트가 해당 이미지와 동일한 정보를 제공하나요?
링크, 버튼, 이미지 맵 영역 등 사용자가 상호작용할 수 있는 이미지의 대체 텍스트가 연결 대상이나 버튼의 목적을 명확히 나타내나요?
복잡한 이미지나 인포그래픽의 경우, 페이지 본문에서 충분히 설명하고 있으며 짧은 대체 텍스트도 함께 제공되나요?
장식용 이미지는 대체 텍스트가 필요 없는 것으로 올바르게 처리되어 있나요?
이미지 내부에 텍스트를 포함하는 대신 일반 텍스트를 사용했나요? (로고 내 텍스트나 장식용 텍스트 이미지 등은 예외입니다.)
표
페이지에 데이터 표가 포함된 경우, 해당 표에 캡션(이름/제목)이 있고, 마크업상에서 열이나 행이 적절하게 식별되어 있나요?
복잡한 표를 단순화해, 복합적인 열 또는 행 헤더를 사용해야 할 필요성을 최소화하거나 제거했나요?
양식(Forms)
모든 양식 필드에 항상 표시되는 라벨이 있나요?
모든 양식 라벨은 설명이 충분하고 지침을 잘 전달하고 있나요? 사용자가 양식을 작성하는 데 필요한 모든 정보가 해당 페이지에 제공되어 있나요?
모든 양식 레이블과 지침이 관련 양식 요소 바로 옆에 배치되어, 사용자(화면 확대 기능을 사용하는 사용자 포함)가 양식 요소와 그 레이블 또는 지침을 쉽게 연결할 수 있나요?
모든 제어 요소(버튼 등)가 자신이 제어하는 콘텐츠와 가까운 곳에 배치되어 있나요? 예를 들어, ‘수정’ 과 ‘삭제’ 버튼이 수정하거나 삭제하려는 콘텐츠 바로 옆에 있나요?
오류 메시지가 사용자가 오류를 수정할 수 있도록 충분한 정보를 제공하나요?
양식이 ‘자동 완성(Autofill)’ 기능을 사용할 수 있도록 구성되어 있나요?
동적 콘텐츠
페이지에 동적으로 삽입되는 콘텐츠가 있을 경우, 사용자가 이를 인지할 수 있나요? 또는 해당 콘텐츠가 논리적 읽기 순서나 탭 순서상, 그것을 발생시킨 요소 바로 다음에 나타나나요?
키보드 전용 조작이나 터치스크린 상호작용이 모두 예상 가능한 방식으로 이루어져, 사용자가 페이지 내의 모든 위젯을 어떻게 다루어야 할지 알 수 있나요?
모든 상호작용에 성공 또는 실패에 대한 피드백을 설계하세요. 사용자가 스크립트로 구현된 기능(버튼 클릭, 양식 제출 등)을 실행했을 때, 성공/오류 메시지나 기능이 실제로 작동하는 모습(예: ‘재생’ 버튼을 누른 후 동영상이 재생되기 시작함) 등을 통해 해당 작업이 성공했는지 여부를 사용자가 알 수 있어야 합니다. 이러한 피드백은 비장애인 사용자, 화면 읽기 프로그램(스크린 리더) 사용자 등 모든 유형의 사용자에게 제공되어야 합니다.
사용자 정의 위젯(Custom Widgets)
가능한 경우 표준 HTML 위젯(링크, 버튼, 폼 요소, 컨트롤 등)을 사용하고 있나요? 네이티브(기본) 위젯에는 접근성 기능이 내장되어 있지만, 사용자 정의 위젯에는 그렇지 않습니다.
사용자 정의 위젯을 사용하는 경우, 해당 위젯은 키보드만으로 완전히 조작할 수 있도록 구현되었고 WAI-ARIA 작성 지침을 준수하고 있나요?
터치기기
주요 링크와 버튼의 터치 영역 크기가 충분히 크고, 손가락으로 쉽게 조작할 수 있도록 서로 충분한 간격을 두고 배치되어 있나요?
스와이프 동작이나 제스처를 사용하는 기능에 대해, 이를 대신하여 실행할 수 있는 다른 방법이 마련되어 있나요? 터치 기기에서 화면 읽기 프로그램(스크린 리더)이 활성화되면, 기존에 설정된 모든 사용자 지정 스와이프 동작이나 제스처는 무시된다는 점에 유의하세요.
마치며
홈페이지의 접근성이 좋으면 많은 사람들이 쉽게 이용할 수 있습니다. 여러분의 홈페이지는 체크리스트를 지키고 있나요? 직접 확인하셔도 되고 이 체크리스트를 AI에게 줘도 될거 같아요. 확인하고 수정할게 있어도 요즘은 AI가 잘 수정할 것 같습니다.
예쁜 웹폰트는 웹사이트를 보기 좋게 만들 수 있지만 동시에 많은 문제를 일으킬 수 있다는 사실을 알고 계셨나요? 특히 한글 폰트는 다른 폰트에 비해 용량이 더 커서 문제가 생기기 쉬운데요, 대표적으로 FOUT(Flash of Unstyled Text)와 FOIT(Flash of Invisible Text)이 있습니다.
FOUT는 웹 페이지가 로드될 때, 지정한 커스텀 웹폰트(Web Font)가 아직 불러와지지 않아 기본 시스템 폰트로 먼저 텍스트가 표시되다가 웹폰트 로딩이 완료되면 뒤늦게 폰트가 교체되면서 글자가 깜빡이는 현상을 말합니다.
FOIT는 웹 페이지가 로드될 때 텍스트가 전혀 보이지 않다가 이후 의도한 서체로 렌더링되는 현상을 말합니다. 이러한 지연은 웹 폰트가 사용자의 기기로 다운로드되는 과정에서 발생합니다.
속도가 느리면 방문자들에게 불편함을 줄 수 있고 Lighthouse 점수에도 좋지 않죠. 요소가 로딩되는데 시간이 오래 걸릴 수 있습니다.
그러면 좋은 폰트를 쓰면서도 속도 저하를 걱장하지 않을 수 있는 방법이 있을까요?
구글 폰트의 문제점
첫번째는 구글 폰트를 쓰지 않는 것입니다.
구글 폰트는 다양한 폰트를 쉽게 쓸 수 있게 해주고 예쁜 폰트들이 많이 있죠. 하지만 여러 폰트를 쓰기 시작하면 웹사이트가 느려질 수 있습니다.
유럽 방문자가 있다면 GDPR(유럽 개인정보 보호법) 문제도 있습니다. Usercentrics에 의하면 Google의 콘텐츠 전송 네트워크(CDN)를 통해 구글 폰트를 사용하는 것은 기본적으로 GDPR을 준수하지 않는 방식입니다. 이는 브라우저의 요청 과정에서 개인정보로 분류되는 사용자의 IP 주소가 적절한 법적 근거 또는 사전 동의 없이 구글의 서버로 전송되기 때문입니다.
물론 GDPR만 생각한다면 직접 폰트를 호스팅 하는 방법도 있습니다. 워드프레스는 테마 편집기에서 폰트를 쉽게 업로드 할 수 있게 합니다. 하지만 제가 생각하기에는 더 좋은 대안이 있습니다.
시스템 폰트
컴퓨터와 스마트폰에는 다양한 폰트들이 이미 설치되어 있습니다. 그 중 시스템 기본 폰트로 설정돼있는 폰트를 불러올 수 있는 속성이 있습니다. 바로 system-ui입니다.
body {
font-family: system-ui;
}
글 작성 시점 기준으로 메이저 브라우저는 모두 지원합니다.
body{
font-family: 'Apple SD Gothic Neo', 'Malgun Gothic', "맑은 고딕", 'Noto Sans CJK KR', 'Noto Sans KR', sans-serif;
}
이렇게 폴백 폰트를 추가할 수 도 있습니다. 현재 제가 이 웹사이트에서 쓰는 방식이기도 합니다. 저는 각 시트템들의 기본 고딕 폰트들을 각각 넣어놨습니다.
시스템 폰트는 추가로 다운로드 되는 요소가 없기 때문에 어떤 기기에서든 로딩속도를 올려줄 수 있다는 장점이 있습니다. 폰트들의 모든 굵기까지 로딩하면서 까지도 말이죠.
시스템 폰트 기반 다른 폰트 스택
명조체
font-family: AppleMyungjo, Batang, "바탕", "Noto Serif KR", "Noto Serif CJK KR", AppleMyungjo, Batang, "바탕";
영문 폰트
한글 폰트는 고정폭, 궁서, 손글씨등을 폰트 스택으로 만들기에는 다양성이 떨어지긴 합니다. 하지만 영문 폰트 같은 경우에는 꽤 다양한 조합을 만들 수 있습니다.
Bootstrap은 문서에서 시스템 폰트 스택을 사용한다고 설명합니다. 시스템 폰트는 오늘날의 기기 환경을 고려하여 특별히 설계되었으며, 화면 렌더링 개선, 가변 폰트(variable font) 지원 등의 특징을 갖추고 있다고 설명합니다.
tailwindcss
Stack Overflow
다양한 곳에서 시스템 폰트 스택을 사용하고 있습니다.
아이콘
<button><i class="fa fa-bars"></i></button>
아이콘도 위 코드처럼 웹에서 로딩하는 경우가 많습니다. Font Awesome, 구글 폰트 아이콘을 많이 사용하죠. 하지만 아이콘도 텍스트 폰트와 비슷하게 cdn으로 웹 폰트를 불러오게 되면 다운로드 해야할 요소가 많아지고 속도가 느려집니다. 폰트가 로드되지 않거나 CSS가 적용되지 않을 경우, 아이콘이 표시되지 않을 위험도 있습니다.
SVG
좋은 대안은 SVG를 활용하는 것 입니다. SVG는 굉장히 작은 용량을 차지합니다. SVG를 사용하면 이미지 파일을 불러오기 위한 HTTP 요청이 필요하지 않습니다. 크기가 달라져도 품질 저하 없이 화면에 띄울 수 있습니다. 또한 성능 외의 장점으로도
SVG 요소에는 텍스트가 포함되어 있어 웹사이트의 접근성이 크게 향상됩니다. 그러나 가장 큰 장점은 이 텍스트가 검색 엔진에 의해 색인화된다는 것입니다. 그리고 사용자는 Google을 통해 SVG 파일을 찾을 수 있습니다.
벡터 이미지는 전용 벡터 드로잉 프로그램뿐만 아니라 텍스트 편집기에서도 직접 편집할 수 있습니다. 또한 CSS를 사용하여 SVG 아이콘의 색상이나 크기를 직접 수정할 수도 있습니다. SVG에 애니메이션을 적용할 때는 SMIL, Web Animations API, WebGL 또는 CSS 애니메이션을 활용할 수 있습니다.
W3C에 따르면, SVG는 “X/HTML, CSS, JavaScript와 같은 다른 주요 오픈 웹 플랫폼 기술들과 통합되고 이를 확장하기 위해” 설계되었습니다. 따라서 다른 이미지 형식들과 달리, 이 형식은 다른 문서나 기술들과 쉽게 통합될 수 있습니다.
이처럼 다양한 장점들이 있습니다.
구글 폰트를 포함에 대부분 아이콘 웹사이트에서 SVG를 다운로드해서 사용할 수 있습니다.
워드프레스에서 SVG를 넣을려면 커스텀 HTML 블록을 쓰거나 플러그인을 설치하면 됩니다. 저는 Safe SVG 플러그인을 설치했고 필요하면 커스텀 HTML 블록도 씁니다.
웹사이트 속도를 올려야할 이유
그럼 꼭 웹사이트 속도가 빨라야 할까요?
Cloudflare의 연구에 따르면 페이지 속도가 빠르면 전환율이 향상됩니다.즉, 웹 페이지가 더 빨리 로드될수록 사용자가 해당 웹 페이지에서 대상 작업을 수행할 가능성이 높아집니다.
제 워드프레스 포트폴리오 사이트에는 구글 애널리틱스 4(GA4), 허브스팟, 쿠키 동의 배너가 설치돼 있었습니다. 이 상태에서 모바일 PageSpeed 점수는 68이었습니다. 특히 최대 콘텐츠 렌더링 시간(LCP, 화면에서 가장 큰 요소가 표시되는 시간)이 7.8초로, 구글의 “좋음” 기준인 2.5초의 세 배가 넘었습니다.
원인은 대부분 서드파티 스크립트였습니다. 그래서 구글 태그 매니저(GTM)와 Cookiebot을 걷어내고, 모든 도구를 Cloudflare의 Zaraz로 옮겼습니다. 그 결과 모바일 PageSpeed 점수는 68에서 99로, LCP는 7.8초에서 1.9초로 개선됐습니다.
이 글에서는 다음 내용을 다룹니다.
Zaraz가 무엇이고, 왜 빨라지는지
GA4, 허브스팟, 쿠키 동의 배너를 Zaraz로 옮기는 방법
구글 동의 모드 v2가 제대로 작동하는지 확인하는 방법
전환 전후 측정 결과와 속도가 빨라진 원인
전환 전에 알아야 할 점
Zaraz란 무엇이고, 왜 빨라질까?
Zaraz는 Cloudflare가 제공하는 태그 관리 도구입니다. GTM과 하는 일은 같지만, 결정적인 차이가 하나 있습니다. 서드파티 스크립트를 방문자의 브라우저가 아니라 Cloudflare 서버에서 실행합니다.
GTM을 쓰면 방문자의 브라우저가 GTM 스크립트를 내려받습니다. 그다음 GTM에 설정된 GA4, 허브스팟 같은 스크립트를 하나씩 다시 내려받아 실행합니다. 스크립트가 늘어날수록 브라우저가 처리할 일이 늘고, 페이지도 그만큼 늦게 표시됩니다.
Zaraz는 브라우저에 작은 스크립트 하나만 넣습니다. 페이지뷰나 이벤트가 발생하면 이 스크립트가 정보를 Cloudflare로 보냅니다. GA4 등으로 데이터를 전송하는 일은 Cloudflare 서버가 처리합니다. 브라우저가 무거운 스크립트를 실행하지 않으니 페이지가 빨라집니다.
비용: 모든 Cloudflare 계정에 월 100만 이벤트가 무료로 제공되고, 이를 넘으면 100만 이벤트마다 월 5달러가 부과됩니다. 페이지뷰 1회, zaraz.track() 호출 1회가 각각 이벤트 1개입니다. (Cloudflare 공식 문서)
전환 전 사이트 상태
제 사이트는 워드프레스로 만든 개인 포트폴리오 사이트이고, Cloudflare를 거쳐 서비스합니다. 방문자 분석에는 GA4를, 문의 폼으로 들어온 연락처 관리에는 허브스팟을 씁니다. 방문자가 많지 않아서 Zaraz 무료 사용량으로 충분합니다.
전환 전에는 서드파티 코드가 세 가지 있었습니다.
용도
전환 전
전환 후
방문자 분석
GA4 (GTM으로 설치)
Zaraz의 Google Analytics 4 도구
마케팅 자동화
허브스팟 추적 코드
Zaraz의 HubSpot 도구
쿠키 동의 배너
Cookiebot
Zaraz 동의 관리(CMP)
Zaraz로 전환하는 방법
1단계: 기존 태그 목록 정리하기
GTM 컨테이너에 있는 태그와 트리거를 모두 적어 두세요. 전환 후 빠진 태그가 없는지 확인할 때 이 목록이 기준이 됩니다.
2단계: Zaraz에 GA4 추가하기
Cloudflare 대시보드에서 Tag management → Zaraz → Tag Setup으로 이동합니다.
Third-party tools → Add new tool을 선택합니다.
목록에서 Google Analytics 4를 고르고 Continue를 선택합니다.
GA4 측정 ID(G-XXXXXXX)를 입력합니다.
Actions에서 Pageviews를 켜고 저장합니다.
Zaraz는 Cloudflare를 거치는 페이지에 스크립트를 자동으로 넣습니다. 워드프레스에 따로 코드를 추가할 필요가 없습니다.
3단계: 허브스팟 추가하기
2단계와 같은 방법으로 Add new tool에서 HubSpot을 선택하고, 허브스팟 계정 ID(Hub ID)를 입력합니다.
전환하면서 가장 걱정한 부분은 허브스팟이 유입 경로를 제대로 기록하는지였습니다. 그래서 UTM 파라미터를 붙인 링크로 들어가 문의 폼을 직접 제출해 봤습니다.
캠페인(zaraztest)과 소스/매체(test / test)가 그대로 남았습니다. Zaraz로 옮긴 뒤에도 허브스팟의 유입 경로 추적과 폼 연결은 정상적으로 작동합니다.
4단계: Cookiebot을 Zaraz 동의 관리(CMP)로 바꾸기
Zaraz에는 쿠키 동의 배너 기능이 들어 있어서 별도의 동의 관리 플랫폼(CMP)이 필요 없습니다.
Tag management → Consent로 이동해 Enable Consent Management를 켭니다.
Consent modal text에 배너 문구를 입력합니다. HTML도 쓸 수 있습니다.
Purposes에서 Add new Purpose를 선택해 목적을 만듭니다. 저는 “분석”과 “마케팅”을 만들었습니다.
Assign purpose to tools에서 GA4는 “분석”에, 허브스팟은 “마케팅”에 지정합니다.
저장하면 사이트에 동의 배너가 표시됩니다.
허브스팟을 “마케팅”으로 따로 나눈 이유가 있습니다. GA4는 익명으로 방문 통계를 내지만, 허브스팟 추적 쿠키는 방문 기록을 폼을 제출한 실명 연락처에 연결합니다. 성격이 다른 추적이라서, 방문자가 “통계는 허용하고 마케팅 추적은 거부”할 수 있게 했습니다. 대신 마케팅을 거부한 방문자는 폼을 제출해도 허브스팟에 유입 경로가 남지 않습니다.
주의: 새로 추가한 도구에는 목적이 자동으로 지정되지 않습니다. 목적이 없는 도구는 동의와 관계없이 실행됩니다. 도구를 추가할 때마다 Consent 페이지에서 목적을 지정하세요.
배너는 첫 방문 때만 표시됩니다. 방문자가 나중에 동의를 바꿀 수 있도록, 푸터 등에 동의 창을 다시 여는 링크를 넣어 두세요.
GA4나 구글 광고를 쓴다면 구글 동의 모드 v2(Consent Mode v2)도 함께 설정하세요. 유럽(EEA) 방문자가 있다면 필수입니다. 기본값은 코드 없이 설정할 수 있습니다.
Tag management → Settings로 이동합니다.
Set Google Consent Mode v2 state를 체크합니다. 모든 google_consent_default 항목이 denied(거부)로 설정됩니다.
이제 방문자가 동의하기 전까지 모든 항목이 거부 상태로 구글에 전달됩니다.
여기에 함정이 있습니다. 이 설정은 기본값만 정합니다. 방문자가 배너에서 동의해도 구글에 전달되는 상태는 바뀌지 않습니다.
배너에서 동의한 뒤 Zaraz 디버거에서 GA4 요청을 열어 보니, gcd 파라미터 값이 11p1p1p1p5였습니다. p는 “기본값 거부, 업데이트 없음”이라는 뜻입니다. 방문자는 동의했는데, 구글은 계속 거부 상태로 받고 있었습니다.
공식 문서에 따르면 동의 업데이트는 google_consent_update 속성으로 직접 보내야 합니다. 아래 코드를 사이트 푸터에 추가하세요. 워드프레스라면 WPCode 같은 코드 삽입 플러그인을 쓰면 됩니다.
<script>
function syncGoogleConsent() {
const analytics = zaraz.consent.get("분석_목적_ID") ? "granted" : "denied";
const marketing = zaraz.consent.get("마케팅_목적_ID") ? "granted" : "denied";
zaraz.set("google_consent_update", {
analytics_storage: analytics,
ad_storage: marketing,
ad_user_data: marketing,
ad_personalization: marketing,
});
}
// 페이지를 열 때마다 저장된 동의 상태를 반영
document.addEventListener("zarazConsentAPIReady", syncGoogleConsent);
// 방문자가 동의를 바꿀 때 반영
document.addEventListener("zarazConsentChoicesUpdated", syncGoogleConsent);
</script>
분석_목적_ID와 마케팅_목적_ID는 실제 목적 ID로 바꾸세요. 목적 ID는 브라우저 콘솔에서 zaraz.consent.purposes를 실행하면 확인할 수 있습니다. 광고 관련 목적이 없는 사이트라면 marketing 줄을 지우고 광고 항목 3개를 "denied"로 고정해도 됩니다.
코드를 추가한 뒤 상황별로 gcd 값을 다시 확인했습니다. r은 “기본값 거부 → 업데이트로 허용”, q는 “기본값 거부 → 업데이트도 거부”라는 뜻입니다.
상황
gcd 값
의미
기본값 설정만 켬
11p1p1p1p5
동의해도 업데이트가 전달되지 않음
업데이트 코드 추가, “분석” 목적만 있음
11q1r1q1q5
분석만 허용
“마케팅” 목적 추가, 모두 동의
11r1r1r1r5
모든 항목 허용
“마케팅” 목적 추가, 분석만 동의
11q1r1q1q5
분석만 허용, 광고 항목은 거부
이제 방문자의 선택이 구글 동의 모드에 그대로 전달됩니다. 분석만 동의했을 때는 Zaraz 디버거에 허브스팟 요청도 나타나지 않았습니다. gcd 값은 구글 쪽 동의 상태만 보여 주므로, 허브스팟 같은 다른 도구는 디버거에서 요청이 실제로 막혔는지 따로 확인하세요.
5단계: 기존 코드 제거하기
Zaraz 설정을 마쳤으면 기존 코드를 지우세요. 기존 코드와 Zaraz가 함께 실행되면 데이터가 중복으로 집계됩니다.
GTM 스니펫 (테마의 header.php나 코드 삽입 플러그인에 넣은 코드)
허브스팟 플러그인 또는 추적 코드
Cookiebot 플러그인 또는 스크립트
WP Consent API 플러그인 (Cookiebot 연동에만 쓰고 있었다면)
저는 GTM 스니펫과 허브스팟 추적 코드를 WPCode로 넣어 두었기 때문에, WPCode의 Code Snippets 목록에서 두 스니펫을 정리했습니다. 바로 삭제하지 않고 비활성화만 해 두면, 문제가 생겼을 때 다시 켜서 되돌릴 수 있습니다. 4단계의 동의 모드 업데이트 코드도 WPCode에 넣으면 코드를 한곳에서 관리할 수 있습니다.
Cookiebot 플러그인과 함께 WP Consent API 플러그인도 지웠습니다. WP Consent API는 Cookiebot의 동의 상태를 다른 플러그인에 전달하는 데만 쓰고 있었습니다. 그런데 전환 전 PageSpeed 보고서를 보니, 이 플러그인의 스크립트도 렌더링을 570ms 동안 막고 있었습니다. CMP를 바꿀 때는 기존 CMP와 함께 설치한 연동 플러그인이 남아 있지 않은지 확인하세요.
6단계: 제대로 작동하는지 확인하기
Zaraz 디버그 모드:Tag management → Settings의 Web API 섹션에서 Debug Key를 복사합니다. 브라우저 콘솔에서 zaraz.debug("디버그키")를 실행하면 이벤트와 트리거 처리 과정을 팝업으로 볼 수 있습니다. 확인이 끝나면 zaraz.debug()로 종료합니다.
GA4 실시간 보고서: 사이트에 접속한 뒤 내 방문이 잡히는지 확인합니다.
허브스팟 유입 경로: UTM 파라미터를 붙인 링크로 폼을 제출하고, 연락처의 Original Traffic Source에 캠페인이 기록되는지 확인합니다. (3단계 참고)
가장 크게 바뀐 지표는 LCP입니다. 7.8초에서 1.9초로 줄어 구글의 “좋음” 기준(2.5초 이하)을 통과했습니다. 메인 스레드가 막힌 시간(TBT)도 130ms에서 0ms가 됐습니다.
측정 기준: PageSpeed Insights 모바일 측정값입니다. 실험실 측정이라 실제 방문자가 느끼는 속도와는 차이가 있을 수 있습니다. 실제 사용자 데이터(Search Console의 Core Web Vitals)는 약 28일 뒤에 반영됩니다.
왜 이렇게 빨라졌을까?
전환 전 PageSpeed 보고서의 진단 항목에서 원인을 찾을 수 있었습니다. 원인은 크게 두 가지였습니다.
1. 렌더링을 막던 Cookiebot 스크립트
“렌더링 차단 요청(Render-blocking requests)” 항목의 예상 절감 시간은 1,220ms였습니다. 가장 오래 걸린 스크립트는 Cookiebot의 uc.js로, 혼자서 1,200ms 동안 페이지 표시를 막았습니다. Cookiebot 플러그인의 연동 스크립트와 WP Consent API 플러그인의 스크립트도 각각 570ms씩 렌더링을 막았습니다.
렌더링 차단 스크립트
크기
차단 시간
Cookiebot uc.js
37.2 KiB
1,200ms
Cookiebot 플러그인 연동 스크립트
1.2 KiB
570ms
WP Consent API 스크립트
1.5 KiB
570ms
쿠키 배너 스크립트는 동의를 받기 전에 다른 스크립트를 막아야 하므로 페이지에서 가장 먼저 실행됩니다. 이 스크립트가 끝날 때까지 화면이 표시되지 않았습니다.
2. 약 440 KiB의 서드파티 JavaScript
“사용하지 않는 JavaScript 줄이기” 항목에는 GTM과 Cookiebot이 내려받는 스크립트가 나와 있었습니다.
스크립트
전송 크기
사용하지 않는 코드
GTM gtm.js
122.8 KiB
60.0 KiB
GA4 gtag/js (GTM이 불러옴)
175.2 KiB
73.2 KiB
Cookiebot uc.js + cc.js
141.8 KiB
61.5 KiB
합계
약 440 KiB
약 195 KiB
GTM은 컨테이너 스크립트(gtm.js)를 받은 뒤 GA4 스크립트(gtag/js)를 한 번 더 받습니다. PageSpeed는 모바일을 느린 4G 네트워크로 가정하고 측정하므로, 이 정도 용량을 내려받고 실행하는 데만 몇 초가 걸립니다.
Zaraz로 옮긴 뒤에는 이 스크립트가 모두 사라지고 작은 Zaraz 스크립트 하나만 남았습니다. 렌더링 차단 시간은 대부분 Cookiebot에서 나왔습니다. 그래서 속도 개선 효과는 GTM보다 Cookiebot을 걷어낸 쪽이 더 컸습니다.
LCP 요소는 쿠키 배너가 아니라 페이지의 이미지였습니다. 이미지는 그대로인데 LCP가 7.8초에서 1.9초로 줄었습니다. 이미지가 무거웠던 것이 아닙니다. 렌더링 차단 스크립트가 끝나기를 기다리고, 440 KiB의 스크립트와 네트워크를 나눠 쓰느라 늦게 표시됐던 것입니다.
전환 전에 알아야 할 점
Zaraz가 모든 사이트에 맞지는 않습니다. 직접 써 보며 확인한 주의할 점입니다.
Cloudflare를 쓰는 사이트에 가장 잘 맞습니다. Cloudflare는 도메인을 Cloudflare 프록시(주황색 구름)로 연결하는 구성을 권장합니다. 프록시하지 않는 도메인에서도 쓸 수 있지만 설정이 더 복잡합니다.
GTM의 기능을 모두 옮길 수는 없습니다. 주요 도구는 Zaraz와 기본으로 연동됩니다. 하지만 복잡한 트리거나 변수를 많이 쓰는 GTM 컨테이너는 옮기는 데 손이 많이 갑니다. Custom HTML 도구도 있지만, 이 도구는 브라우저에서 실행되므로 속도 이점이 줄어듭니다.
GA4 수치가 이전과 다르게 나올 수 있습니다. 수집 방식이 바뀌기 때문입니다. 전환 직후 몇 주간은 이전 기간과 단순 비교하지 마세요.
동의 설정은 운영자가 직접 확인해야 합니다. Zaraz는 도구별 목적을 추천하거나 자동으로 지정하지 않습니다. GDPR 등 규정에 맞게 목적을 지정하는 것은 운영자의 몫입니다. 구글 동의 모드 v2도 업데이트가 제대로 전달되는지 직접 확인하세요.
이런 사이트에 추천합니다
Cloudflare를 이미 쓰는 워드프레스 사이트, 개인 블로그, 포트폴리오, 소규모 비즈니스 사이트
GA4, 허브스팟, 메타 픽셀처럼 널리 쓰는 도구 몇 개만 쓰는 사이트
Cookiebot 같은 유료 CMP 비용을 줄이고 싶은 사이트
이런 사이트라면 신중하게 검토하세요
GTM에 복잡한 트리거, 변수, 커스텀 태그가 많은 사이트
마케팅팀이 GTM으로 작업하는 데 익숙한 조직
마무리
GTM과 Cookiebot을 Zaraz로 옮긴 뒤 모바일 PageSpeed 점수는 68에서 99로, LCP는 7.8초에서 1.9초로 개선됐습니다. 속도를 늦추던 주범은 GTM보다 Cookiebot이었고, 동의 모드 v2는 기본값 설정만으로는 부족했습니다. 서드파티 도구가 몇 개뿐이고 Cloudflare를 쓰고 있다면, 들이는 노력에 비해 효과가 큰 속도 개선 방법입니다.
워드프레스 사이트 속도 개선이나 Zaraz 전환이 필요하다면 문의하기로 편하게 연락 주세요.
2026년 10월 기준 · 워드프레스 6.9 이상 필요 (이 글은 워드프레스 7.1.3에서 테스트했습니다)
AI 어시스턴트는 AI가 접근 가능한 도구 만큼만 유용합니다. 대부분의 워드프레스 사이트 운영자에게는 채팅창과 wp-admin 사이를 복사해서 붙여넣는 것에 불과했죠. 워드프레스의 공식 MCP 어댑터는 클로드 같은 클라이언트가 포스트 작성, 설정 확인 같은 작업을 웹사이트에 직접 작업할 수 있게 합니다.
이 가이드는 AI 워크플로우를 시도해보고 싶은 워드프레스 운영자, 개발자, 그리고 콘텐츠 팀을 위한 가이드입니다.
이 글에서는 MCP Adapter 설치, 어플리케이션 비밀번호 생성, 그리고 클로드 데스크탑 연결하는 방법을 살펴봅니다.
MCP 어댑터가 뭐고 왜 중요한가요?
이 구조는 세 가지 요소로 이루어져 있습니다
MCP(Model Context Protocol)는 클로 같은 AI 애플리케이션이 외부 도구와 데이터에 일관되게 연결할 수 있도록 해주는 개방형 표준입니다. 모든 앱이 개별적으로 통합을 구축하는 대신, 워드프레스를 하나의 MCP 서버로 노출하면, 호환되는 클라이언트라면 누구나 사용할 수 있습니다.
Abilities API는 워드프레스가 플러그인과 코어에 사이트가 할 수 있는 기능들, 예를 들어 ‘게시물 작성’이나 ‘사이트 정보 가져오기’ 같은 기능을 등록할 수 있도록 제공하는 내장 방식입니다(버전 6.9 기준). 각 기능은 이름, 설명, 그리고 정의된 입력 및 출력 집합을 가지고 있습니다.
MCP 어댑터는 이 둘을 연결하는 공식 플러그인입니다. 사이트에 등록된 기능들을 MCP를 통해 노출하여 AI 클라이언트가 이를 인식하고 호출할 수 있게 합니다.
기본적으로 어댑터는 클라이언트에게 세 가지 도구를 제공합니다. 하나는 기능을 발견하는 도구, 하나는 특정 기능의 세부 정보를 얻는 도구, 그리고 마지막으로 실행하는 도구입니다. 어댑터가 AI가 무엇을 할 수 있는지 결정하지는 않습니다. 등록한 기능이 그렇습니다.
중요한 이유
AI가 ‘wp-admin에서 이렇게 하세요’라고 안내만 하는 대신, 사이트에서 직접 작업을 수행합니다
범위를 제어합니다. AI는 등록된 기능만 수행할 수 있으며, 로그인한 워드프레스 사용자의 권한이 있어야만 가능합니다. 예를 들어, 기본값이 초안으로 설정된 게시물 생성 기능은 실제로 게시물이 올라가기 전에 사람이 반드시 확인하도록 합니다.
표준을 기반으로 만들어졌습니다. MCP와 워드프레스 자체 API를 사용하기 때문에, 이 설정은 클로드뿐만 아니라 다른 호환 클라이언트에서도 동일하게 작동합니다.
WP_API_URL에는 본인 사이트 주소를, WP_API_USERNAME에는 2단계에서 사용한 사용자 이름을, WP_API_PASSWORD에는 복사해 둔 애플리케이션 비밀번호를 넣습니다. 이미 다른 MCP 서버 설정이 있다면 mcpServers 안에 wordpress 항목만 추가하세요.
저장한 뒤 클로드 데스크탑을 완전히 종료하고 다시 실행합니다.
4. 테스트
클로드에게 아래처럼 요청합니다.
mcp-adapter-discover-abilities를 호출해서 이 사이트에 등록된 기능 목록을 보여줘.
정상적으로 연결되었다면 사이트에 등록된 기능 목록이 표시됩니다. 기본 상태에서는 사이트 정보, 사용자 정보, 환경 정보를 읽어 오는 읽기 전용 기능 몇 개만 보입니다.
문제 해결: 401 오류
제 경우에는 플러그인이 작동했는데도 첫 시도에서 401 오류가 발생했습니다. 원인은 http:// URL이었습니다. 워드프레스는 비 HTTPS 사이트에서 애플리케이션 비밀번호를 비활성화하며, 리디렉션은 Authorization 헤더를 손실시킬 수 있습니다. WP_API_URL을 https://로 변경하니 문제가 해결되었습니다. 그래도 401이 뜬다면, 사용자 이름, 전체 비밀번호, 그리고 인증 헤더를 제거하는 보안 플러그인이나 호스트 규칙을 확인해 보세요.
5. 실제 기능 추가하기
어댑터는 기능을 연결해 줄 뿐입니다. 플러그인이나 직접 작성한 코드가 이를 등록해야 합니다. 예를 들어, 초안 게시물을 작성하는 create-post 기능이 그렇습니다.
워드프레스를 최근에 설정했다면 사이트를 디자인하는 방식이 두 가지라는 걸 느꼈을겁니다. 어떤 테마는 사용자 정의(Customizer)로 이동합니다. 실시간 미리보기가 있는 설정 패널이죠. 다른 테마는 사이트 편집기(Site Editor)로 이동해요. 여기서 블록으로 헤더, 푸터, 페이지 레이아웃을 만들수 있습니다.
둘 다 워드프레스 테마이고, 둘 다 멋진 사이트를 만들 수 있어요. 하지만 작동 방식이 많이 달라서 잘못 고르면 시간을 낭비할 수 있어요. 이 글에서는 클래식 테마와 블록 테마의 차이, 각각의 장점, 그리고 선택하는 방법을 설명합니다.
클래식 테마란?
클래식 테마는 PHP 템플릿 파일로 사이트 모습을 결정합니다. index.php, single.php, header.php 같은 파일이 페이지의 각 부분을 제어합니다. PHP는 워드프레스가 실행되는 프로그래밍 언어입니다.
클래식 테마에는 다음 도구가 함께 제공됩니다.
사용자 정의: 색상, 글꼴, 로고, 메뉴를 실시간 미리보기와 함께 바꾸는 패널입니다.
위젯: 사이드바와 푸터에 배치하는 작은 콘텐츠 상자입니다.
메뉴: 내비게이션을 만드는 별도 화면입니다.
테마 파일 편집기: 대시보드에서 테마 코드를 직접 수정하는 곳입니다.
워드프레스는 2005년부터 이 방식을 지원해 왔고, 지금도 완전히 지원합니다. 워드프레스를 오래 써 왔다면 익숙한 방식입니다.
블록 테마란?
블록 테마는 사이트 전체를 블록으로 만듭니다. 글을 쓸 때 이미 블록을 쓰고 있어요. 문단, 이미지, 버튼, 컬럼이 모두 블록입니다. 블록 테마에서는 헤더, 푸터, 내비게이션, 페이지 템플릿도 블록으로 만듭니다.
블록 테마는 워드프레스 5.9(2022년)에서 처음 나왔습니다. 테마 파일은 대부분 HTML이고, theme.json 파일에 색상, 글꼴, 간격 같은 전역 설정을 저장합니다. 디자인 작업은 주로 사이트 편집기에서 합니다. 사이트 제목, 태그라인, 로고처럼 블록으로 설정할 수 있는 항목이 많아서 사용자 정의는 기본적으로 숨겨져 있습니다.
클래식 테마 vs 블록 테마: 핵심 차이
클래식 테마
블록 테마
템플릿 파일
PHP(index.php, single.php)
블록 마크업이 들어간 HTML(templates/index.html)
주요 디자인 도구
사용자 정의하기
사이트 편집기
헤더와 푸터
코드, 사용자 정의하기, 위젯으로 설정
블록으로 편집하는 템플릿 파트
위젯
지원
블록으로 대체
전역 색상과 글꼴
사용자 정의하기 또는 코드
theme.json과 스타일 패널
필수 파일
style.css, index.php
style.css, templates/index.html
필요한 코드
기본 PHP, HTML, CSS
기본 변경에는 거의 필요 없음
적합한 사용자
맞춤 로직이 필요한 개발자
시각적 제어가 필요한 사이트 운영자
구성 요소는 어떻게 연결되나요?
블록 테마는 사이트를 여러 구성 요소로 나눕니다. 각 요소의 역할은 다음과 같습니다.
페이지 또는 글: 직접 작성하는 콘텐츠입니다.
템플릿: 특정 유형의 콘텐츠에 쓰는 레이아웃이에요. 예를 들어 단일 글, 페이지, 404 오류 페이지가 있습니다.
템플릿 파트: 헤더나 푸터처럼 여러 템플릿에서 재사용하는 부분입니다. 한 번만 수정하면 이를 사용하는 모든 템플릿에 반영됩니다.
패턴: 콘텐츠에 바로 삽입할 수 있도록 미리 만들어 둔 블록 묶음입니다.
블록: 템플릿과 콘텐츠를 채우는 요소입니다.
스타일: 색상, 글꼴, 간격이에요. 워드프레스 기본값, 테마의 theme.json 파일, 스타일 패널에서 바꾼 내용에서 와요. 사용자가 바꾼 내용이 가장 우선됩니다.
이 요소들은 함께 작동합니다. 독자가 블로그 글을 열면 워드프레스는 단일 글 템플릿(Single Posts)을 선택합니다. 그다음 헤더와 푸터 파트를 추가하고, 글 내용으로 블록을 채운 뒤, 스타일을 적용합니다. 그래서 글이 사이트의 색상과 글꼴에 맞게 보입니다.
클래식 테마에서는 보통 single.php를 수정하거나 사용자 정의에서 CSS를 추가해서 블로그 글 레이아웃을 바꿉니다. 사용자 정의하기 미리보기로 색상과 글꼴은 쉽게 확인할 수 있습니다. 레이아웃을 바꿀 때는 대개 코드나 플러그인이 필요합니다.
블록 테마에서는 편집기를 열고 단일 글 템플릿을 선택합니다. 헤더를 클릭해서 수정하고, 스타일에서 버튼 스타일을 바꿉니다. 변경 사항은 모든 글에 적용됩니다. 특정 페이지만 다른 레이아웃이 필요하다면 사용자 지정 템플릿을 만든 뒤, 페이지 설정에서 그 템플릿을 선택하면 됩니다.
블록 방식은 더 시각적이에요. 다만 블록, 패턴, 템플릿 파트가 어떻게 맞물리는지 배워야 합니다.
코드, 플러그인, 호환성
클래식 테마는 개발자에게 더 많은 자유를 줘요. PHP로 맞춤 로직을 실행하고, 워드프레스의 훅(hook, 코드를 특정 시점에 끼워 넣는 지점)에 연결해서 거의 무엇이든 만들 수 있어요. 대부분의 기존 플러그인이 이 구조에 맞춰 만들어져서 보통 잘 작동합니다.
블록 테마는 HTML과 JSON을 주로 씁니다. 기본적인 변경에는 코드가 필요 없어요. 하지만 사용자 정의하기 설정을 추가하거나, 위젯 영역에 의존하거나, PHP 템플릿에 연결하는 플러그인은 다르게 작동하거나 아예 작동하지 않을 수 있습니다. 전환하기 전에 호환성을 확인해 보세요.
테마 선택이 SEO에 영향을 줄나요?
기본적으로는 어떤 테마 유형도 순위를 자동으로 올려주지 않습니다. 구글은 콘텐츠 품질, 페이지 속도, 모바일 환경, 명확한 페이지 구조를 보기 때문이에요. 테마는 이런 요소에 영향을 주므로 다음 세 가지에 집중하세요.
속도: 홈페이지와 중요한 글 하나를 Google PageSpeed Insights로 테스트해 보세요. 무거운 테마와 플러그인이 많으면 페이지가 느려집니다.
제목 구조: 페이지마다 H1 제목은 하나만 쓰세요. 일부 블록 템플릿은 제목을 추가로 넣기도 하니, 전환 후 사이트 제목과 템플릿 제목을 확인해 보세요.
모바일 레이아웃: 휴대폰에서 사이트를 미리 보세요. 두 테마 모두 반응형으로 만들 수 있지만, 설정이 잘못되면 레이아웃이 깨질 수 있습니다.
어떤 테마를 선택해야 할까?
블록 테마를 고르면 좋은 경우:
새 사이트를 시작하는 경우
코드 없이 헤더, 푸터, 레이아웃을 바꾸고 싶은 경우
블록 편집기가 익숙한 경우
필요한 플러그인이 블록 테마를 지원하는 경우
클래식 테마를 고르면 좋은 경우:
맞춤 PHP 로직이나 깊은 테마 훅이 필요한 경우
위젯, 사용자 정의하기, 또는 클래식 테마에서만 작동하는 플러그인에 의존하는 경우
지금 쓰는 클래식 테마가 잘 작동하고 계속 관리되는 경우. 블록 테마가 새것이라는 이유만으로 바꿀 필요는 없습니다.
일부 테마는 두 방식을 섞습니다. 이런 “하이브리드” 테마는 클래식 PHP 템플릿과 theme.json, 템플릿 파트 같은 블록 기능을 함께 씁니다.
나중에 바꿀 수 있을까?
바꿀 수는 있지만 계획이 필요합니다. 글, 페이지, 댓글은 데이터베이스에 저장되어 있어서 전환 후에도 그대로 남습니다. 이미지는 미디어 라이브러리에 그대로 남아요. 보통 다시 작업해야 하는 부분은 다음과 같습니다.
위젯: 블록으로 다시 만들어야 합니다.
사용자 정의하기 설정: 스타일 패널에서 다시 설정해야 합니다.
맞춤 PHP 템플릿: 블록 템플릿으로 다시 만들어야 합니다.
테마 전용 숏코드: 이를 사용한 레이아웃은 새 블록이나 패턴으로 바꿔야 합니다.
전환 전에 사이트를 백업하고, 실제 사이트를 건드리기 전에 스테이징 사이트에서 먼저 테스트해 보세요.
결론
워드프레스 개발자 핸드북은 블록 테마를 “워드프레스 프로젝트의 미래”라고 소개합니다. 그렇다고 클래식 테마가 사라지는 건 아니입니다. 여전히 작동하고 완전히 지원합니다. 결국 선택은 어떻게 작업하고 싶은지에 달려 있습니다. 블록으로 시각적으로 제어하고 싶다면 블록 테마를 고르세요. 코드 수준의 제어가 필요하거나 이미 잘 작동하는 클래식 환경이 있다면 클래식을 유지하세요.