[작성자:] GWA

  • DHS Trusted Tester Certification 합격 후기

    DHS Trusted Tester Certification 합격 후기

    웹 개발을 배울 때 부터 접근성에 관심이 있었는데 겉핥기 말고 한번 제대로 배워봐야겠다는 생각이 들어서 관련 자격증을 따보려고 공부를 시작했습니다. 그리고 오늘 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) 및 키보드 네비게이션 등을 활용하는법을 배웁니다.
    • 시험 방식: 실제 웹페이지의 접근성 결함(대체 텍스트 누락, 키보드 접근성 문제, 낮은 색상 대비 등)을 찾아내는 실기 및 이론 시험을 통과해야 합니다.

    https://training.section508testing.net에서 자세한 과정을 확인하실 수 있습니다.

    배우는 것

    크게

    • Section 508이 무엇이고 왜 중요한지
    • Section 508 스탠다드
    • 테스팅 도구
    • Trusted Tester 트레이닝
    • 연습 시험
    • 시험

    으로 구성됩니다.

    저는 웹 개발 기초는 있고 Sara Soueidan의 Practical Accessibility 강의를 통해 접근성을 배우기도 해서 내용은 크게 어렵진 않았습니다.

    다만 영어로만 돼있는데 저는 큰 문제는 없었지만 여기서 어려움을 느끼실 수 도 있겠네요.

    연습 시험

    Trusted Tester 연습 시험 81점으로 실패.

    내용이 어렵지는 않다고 했지만 그래도 막히는 부분이 있었습니다. 연습 시험인데요 연습 시험에서도 무조건 85점을 넘어야 본 시험으로 넘어갈 수 있습니다. 2번 실패하면 일부 교육을 다시 들어야 하고 3번째도 실패하면 과정을 처음부터 다시 들어야 합니다.

    Trusted Tester 연습 시험 86점 통과.

    다행이 저는 3번째에서는 통과했습니다.

    본 시험

    본 시험도 마찬가지로 3번 안에 통과를 못하면 과정을 처음부터 다시 시작해야 합니다. 또 다행이 본 시험은 한번에 통과했습니다.

    마치며

    과정을 통해 공부하면서 테스트를 하는 방법을 배울 수 있었습니다. IAAP의 CPACC도 접수를 해놨는데 이제 CPACC 준비를 해야겠네요.

    Deque University CPACC 연습 시험 74점 실패.

    현재 Deque University 과정을 통해 공부하고 있습니다. 연습 시험을 한번 봤는데 1점이 모잘랐습니다. 안정적으로 합격할 수 있도록 준비해야겠네요.

  • 디자이너를 위한 웹접근성 체크리스트

    디자이너를 위한 웹접근성 체크리스트

    요즘 직접 웹사이트를 만들기 시작하신분들이 많은데요, 제작하면서 웹접근성 측면에서 놓칠 수 있는 부분들을 체크리스트로 정리해봤습니다.

    이 체크리스트는 접근성 높은 디자인을 위한 출발점일 뿐, 최종 목적지가 아닙니다. 여기에는 가장 중요한 개념들이 담겨 있습니다. 단순히 최소 기준을 충족하는 수준을 넘어, 당사자가 실제로 만족하고 유용하게 활용할 수 있고 필요에 꼭 맞는 디자인을 구현하기 위해 더욱 고민해 보시기 바랍니다.

    페이지 제목

    • 페이지 제목(브라우저에 표시되는 페이지 제목이며, 본문 내 주요 제목이나 <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;
    }
    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, "바탕";

    영문 폰트

    한글 폰트는 고정폭, 궁서, 손글씨등을 폰트 스택으로 만들기에는 다양성이 떨어지긴 합니다. 하지만 영문 폰트 같은 경우에는 꽤 다양한 조합을 만들 수 있습니다.

    참고하기 좋은 웹사이트로 Modern Font Stacks 라는 웹사이트가 있습니다.

    Modern Font Stacks 웹사이트 화면.

    15종류의 폰트 스택을 소개하고 프리뷰도 가능한 웹사이트 입니다.

    시스템 폰트를 쓰는 예시

    Bootstrap

    Bootstrap 폰트 부분 문서

    깃허브 즐겨찾기 17만5천개를 받은 프론트엔드 프레임워크 Bootstrap입니다.

    Bootstrap은 문서에서 시스템 폰트 스택을 사용한다고 설명합니다. 시스템 폰트는 오늘날의 기기 환경을 고려하여 특별히 설계되었으며, 화면 렌더링 개선, 가변 폰트(variable font) 지원 등의 특징을 갖추고 있다고 설명합니다.

    tailwindcss

    tailwindcss 폰트 부분 문서

    Stack Overflow

    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를 다운로드해서 사용할 수 있습니다.

    워드프레스에서 SVG를 넣을려면 커스텀 HTML 블록을 쓰거나 플러그인을 설치하면 됩니다. 저는 Safe SVG 플러그인을 설치했고 필요하면 커스텀 HTML 블록도 씁니다.

    웹사이트 속도를 올려야할 이유

    그럼 꼭 웹사이트 속도가 빨라야 할까요?

    Cloudflare 사이트 속도 전환율 영향

    Cloudflare의 연구에 따르면 페이지 속도가 빠르면 전환율이 향상됩니다.즉, 웹 페이지가 더 빨리 로드될수록 사용자가 해당 웹 페이지에서 대상 작업을 수행할 가능성이 높아집니다.

    여려분은 어떤 폰트를 사용하시나요? 궁금하신 점이 있으시면 댓글을 남겨주세요.

  • 워드프레스 속도 개선: GTM·Cookiebot을 Zaraz로 옮긴 후기

    워드프레스 속도 개선: GTM·Cookiebot을 Zaraz로 옮긴 후기

    제 워드프레스 포트폴리오 사이트에는 구글 애널리틱스 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 도구
    쿠키 동의 배너CookiebotZaraz 동의 관리(CMP)
    전환 전 PageSpeed

    Zaraz로 전환하는 방법

    1단계: 기존 태그 목록 정리하기

    GTM 컨테이너에 있는 태그와 트리거를 모두 적어 두세요. 전환 후 빠진 태그가 없는지 확인할 때 이 목록이 기준이 됩니다.

    2단계: Zaraz에 GA4 추가하기

    1. Cloudflare 대시보드에서 Tag management → Zaraz → Tag Setup으로 이동합니다.
    2. Third-party tools → Add new tool을 선택합니다.
    3. 목록에서 Google Analytics 4를 고르고 Continue를 선택합니다.
    4. GA4 측정 ID(G-XXXXXXX)를 입력합니다.
    5. Actions에서 Pageviews를 켜고 저장합니다.
    Cloudflare Zaraz 설정 화면.

    Zaraz는 Cloudflare를 거치는 페이지에 스크립트를 자동으로 넣습니다. 워드프레스에 따로 코드를 추가할 필요가 없습니다.

    3단계: 허브스팟 추가하기

    2단계와 같은 방법으로 Add new tool에서 HubSpot을 선택하고, 허브스팟 계정 ID(Hub ID)를 입력합니다.

    전환하면서 가장 걱정한 부분은 허브스팟이 유입 경로를 제대로 기록하는지였습니다. 그래서 UTM 파라미터를 붙인 링크로 들어가 문의 폼을 직접 제출해 봤습니다.

    mustbethecode.com/contact?utm_source=test&utm_medium=test&utm_campaign=zaraztest

    허브스팟에 생성된 연락처에는 다음과 같이 기록됐습니다.

    속성값
    Original Traffic SourceOther campaigns
    Original Traffic Source Drill-Down 1zaraztest
    Original Traffic Source Drill-Down 2test / test

    캠페인(zaraztest)과 소스/매체(test / test)가 그대로 남았습니다. Zaraz로 옮긴 뒤에도 허브스팟의 유입 경로 추적과 폼 연결은 정상적으로 작동합니다.

    4단계: Cookiebot을 Zaraz 동의 관리(CMP)로 바꾸기

    Zaraz에는 쿠키 동의 배너 기능이 들어 있어서 별도의 동의 관리 플랫폼(CMP)이 필요 없습니다.

    1. Tag management → Consent로 이동해 Enable Consent Management를 켭니다.
    2. Consent modal text에 배너 문구를 입력합니다. HTML도 쓸 수 있습니다.
    3. Purposes에서 Add new Purpose를 선택해 목적을 만듭니다. 저는 “분석”과 “마케팅”을 만들었습니다.
    4. Assign purpose to tools에서 GA4는 “분석”에, 허브스팟은 “마케팅”에 지정합니다.
    5. 저장하면 사이트에 동의 배너가 표시됩니다.

    허브스팟을 “마케팅”으로 따로 나눈 이유가 있습니다. GA4는 익명으로 방문 통계를 내지만, 허브스팟 추적 쿠키는 방문 기록을 폼을 제출한 실명 연락처에 연결합니다. 성격이 다른 추적이라서, 방문자가 “통계는 허용하고 마케팅 추적은 거부”할 수 있게 했습니다. 대신 마케팅을 거부한 방문자는 폼을 제출해도 허브스팟에 유입 경로가 남지 않습니다.

    주의: 새로 추가한 도구에는 목적이 자동으로 지정되지 않습니다. 목적이 없는 도구는 동의와 관계없이 실행됩니다. 도구를 추가할 때마다 Consent 페이지에서 목적을 지정하세요.

    배너는 첫 방문 때만 표시됩니다. 방문자가 나중에 동의를 바꿀 수 있도록, 푸터 등에 동의 창을 다시 여는 링크를 넣어 두세요.

    <a href="#" onclick="zaraz.showConsentModal(); return false;">쿠키 설정</a>

    구글 동의 모드 v2 설정하기

    GA4나 구글 광고를 쓴다면 구글 동의 모드 v2(Consent Mode v2)도 함께 설정하세요. 유럽(EEA) 방문자가 있다면 필수입니다. 기본값은 코드 없이 설정할 수 있습니다.

    1. Tag management → Settings로 이동합니다.
    2. 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단계 참고)
    • 동의 배너: 시크릿 창에서 배너가 뜨는지, 거부하면 GA4와 허브스팟 요청이 나가지 않는지 확인합니다.

    결과: 모바일 PageSpeed 68 → 99

    지표전후
    성능 점수6899
    First Contentful Paint2.4초1.7초
    Largest Contentful Paint7.8초1.9초
    Total Blocking Time130ms0ms
    Cumulative Layout Shift00
    Speed Index5.1초2.1초
    전환 후 PageSpeed 99점

    가장 크게 바뀐 지표는 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.js37.2 KiB1,200ms
    Cookiebot 플러그인 연동 스크립트1.2 KiB570ms
    WP Consent API 스크립트1.5 KiB570ms

    쿠키 배너 스크립트는 동의를 받기 전에 다른 스크립트를 막아야 하므로 페이지에서 가장 먼저 실행됩니다. 이 스크립트가 끝날 때까지 화면이 표시되지 않았습니다.

    2. 약 440 KiB의 서드파티 JavaScript

    “사용하지 않는 JavaScript 줄이기” 항목에는 GTM과 Cookiebot이 내려받는 스크립트가 나와 있었습니다.

    스크립트전송 크기사용하지 않는 코드
    GTM gtm.js122.8 KiB60.0 KiB
    GA4 gtag/js (GTM이 불러옴)175.2 KiB73.2 KiB
    Cookiebot uc.js + cc.js141.8 KiB61.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를 사용하기 때문에, 이 설정은 클로드뿐만 아니라 다른 호환 클라이언트에서도 동일하게 작동합니다.

    준비사항

    • 워드프레스 6.9 이후, HTTPS 적용된 웹사이트
    • 클로드 데스크탑과 Node.js (for npx)
    • 어드민 계정

    1. 플러그인 설치

    플러그인 디렉터리에서 MCP 어댑터를 설치하고 활성화합니다.

    플러그인 검색 결과

    WordPress.org가 게시한 “MCP Adapter”을 찾습니다.

    WP-CLI로도 가능합니다:

    wp plugin install https://github.com/WordPress/mcp-adapter/releases/latest/download/mcp-adapter.zip --activate

    2. 애플리케이션 비밀번호를 만듭니다

    애플리케이션 비민번호

    사용자 → 프로필 → 애플리케이션 비밀번호로 이동해 이름을 로 정하고 비밀번호를 복사하세요. 비밀번호가 해당 사용자의 권한을 담고 있으니, AI에 부여할 권한만 가진 전용 사용자를 사용합니다.

    3. 클로드 데스크탑 설정

    클로드 데스크탑 설정
    1. 클로드 데스크탑에서 설정 → 개발자로 이동해 설정 변경 버튼을 누릅니다. claude_desktop_config.json 파일이 들어 있는 폴더가 열립니다.
    2. 이 파일을 텍스트 편집기로 열어 아래 내용을 추가합니다.

    이 코드를 claude_desktop_config.json에 추가합니다

    {
      "mcpServers": {
        "wordpress": {
          "command": "npx",
          "args": ["-y", "@automattic/mcp-wordpress-remote@latest"],
          "env": {
            "WP_API_URL": "https://your-site.com/wp-json/mcp/mcp-adapter-default-server",
            "WP_API_USERNAME": "your-username",
            "WP_API_PASSWORD": "your application password"
          }
        }
      }
    }

    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 기능이 그렇습니다.

    플러그인 저장소에서 가져온 예시입니다

    https://github.com/WordPress/mcp-adapter/blob/trunk/docs/getting-started/basic-examples.md

    <?php
    // Register the ability
    add_action( 'wp_abilities_api_init', function() {
        wp_register_ability( 'my-plugin/create-post', [
            'label' => 'Create Post',
            'description' => 'Creates a new WordPress post with the specified content',
            'category' => 'site',
            'input_schema' => [
                'type' => 'object',
                'properties' => [
                    'title' => [
                        'type' => 'string',
                        'description' => 'The post title',
                        'minLength' => 1,
                        'maxLength' => 200
                    ],
                    'content' => [
                        'type' => 'string',
                        'description' => 'The post content (HTML allowed)',
                        'minLength' => 1
                    ],
                    'status' => [
                        'type' => 'string',
                        'description' => 'Post status',
                        'enum' => ['draft', 'publish'],
                        'default' => 'draft'
                    ],
                    'category' => [
                        'type' => 'string',
                        'description' => 'Category name (optional)'
                    ]
                ],
                'required' => ['title', 'content']
            ],
            'output_schema' => [
                'type' => 'object',
                'properties' => [
                    'post_id' => [
                        'type' => 'integer',
                        'description' => 'The ID of the created post'
                    ],
                    'post_url' => [
                        'type' => 'string',
                        'description' => 'The URL of the created post'
                    ],
                    'edit_url' => [
                        'type' => 'string',
                        'description' => 'The admin edit URL'
                    ]
                ]
            ],
            'execute_callback' => function( $input ) {
                if ( empty( $input['title'] ) ) {
                    return new \WP_Error( 'missing_title', 'Post title is required.' );
                }
    
                $post_data = array(
                    'post_title'   => sanitize_text_field( $input['title'] ),
                    'post_content' => wp_kses_post( $input['content'] ),
                    'post_status'  => in_array( $input['status'], array( 'draft', 'publish' ), true ) ? $input['status'] : 'draft',
                    'post_type'    => 'post',
                );
                
                // Handle category if provided
                if ( ! empty( $input['category'] ) ) {
                    $category = get_category_by_slug( sanitize_title( $input['category'] ) );
                    if ( ! $category ) {
                        // Create category if it doesn't exist
                        $category_id = wp_create_category( $input['category'] );
                    } else {
                        $category_id = $category->term_id;
                    }
                    $post_data['post_category'] = [ $category_id ];
                }
                
                $post_id = wp_insert_post( $post_data );
                
                if ( is_wp_error( $post_id ) ) {
                    throw new Exception( 'Failed to create post: ' . $post_id->get_error_message() );
                }
                
                return [
                    'post_id' => $post_id,
                    'post_url' => get_permalink( $post_id ),
                    'edit_url' => get_edit_post_link( $post_id, 'raw' )
                ];
            },
            'permission_callback' => function() {
                return current_user_can( 'publish_posts' );
            },
            'meta' => [
                'public' => true, // Expose to clients, including MCP
                'annotations' => [
                    'priority' => 2.0,
                    'readOnlyHint' => false,
                    'destructiveHint' => false
                ]
            ]
        ]);
    });

    이 코드를 플러그인으로 만들어 사이트에 추가하면 클로드가 게시물 초안을 직접 작성할 수 있습니다.

    마무리

    여기까지 따라 오셨다면 클로드로 워드프레스 사이트를 관리할 준비가 끝났어요. 다만 아직은 새로운 기능이라 어댑터에 연결할 수 있는 플러그인 생태계가 크지 않습니다. 기능이 필요하다면 직접 등록하는 방법도 함께 고려해 보세요.

    더 자세한 내용은 MCP Adapter 저장소에서 확인할 수 있습니다. 막히는 부분이 있다면 댓글로 남겨 주세요.

  • 워드프레스 클래식 테마 Vs 블록 테마: 어떤 테마를 써야 할까?

    워드프레스 클래식 테마 Vs 블록 테마: 어떤 테마를 써야 할까?

    워드프레스를 최근에 설정했다면 사이트를 디자인하는 방식이 두 가지라는 걸 느꼈을겁니다. 어떤 테마는 사용자 정의(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.phpstyle.css, templates/index.html
    필요한 코드기본 PHP, HTML, CSS기본 변경에는 거의 필요 없음
    적합한 사용자맞춤 로직이 필요한 개발자시각적 제어가 필요한 사이트 운영자

    구성 요소는 어떻게 연결되나요?

    블록 테마는 사이트를 여러 구성 요소로 나눕니다. 각 요소의 역할은 다음과 같습니다.

    • 페이지 또는 글: 직접 작성하는 콘텐츠입니다.
    • 템플릿: 특정 유형의 콘텐츠에 쓰는 레이아웃이에요. 예를 들어 단일 글, 페이지, 404 오류 페이지가 있습니다.
    • 템플릿 파트: 헤더나 푸터처럼 여러 템플릿에서 재사용하는 부분입니다. 한 번만 수정하면 이를 사용하는 모든 템플릿에 반영됩니다.
    • 패턴: 콘텐츠에 바로 삽입할 수 있도록 미리 만들어 둔 블록 묶음입니다.
    • 블록: 템플릿과 콘텐츠를 채우는 요소입니다.
    • 스타일: 색상, 글꼴, 간격이에요. 워드프레스 기본값, 테마의 theme.json 파일, 스타일 패널에서 바꾼 내용에서 와요. 사용자가 바꾼 내용이 가장 우선됩니다.

    이 요소들은 함께 작동합니다. 독자가 블로그 글을 열면 워드프레스는 단일 글 템플릿(Single Posts)을 선택합니다. 그다음 헤더와 푸터 파트를 추가하고, 글 내용으로 블록을 채운 뒤, 스타일을 적용합니다. 그래서 글이 사이트의 색상과 글꼴에 맞게 보입니다.

    테마의 파일 구조를 간단히 비교하면 다음과 같습니다(간략화한 예시).

    클래식 테마

    my-classic-theme/
    ├── style.css
    ├── index.php
    ├── functions.php
    ├── header.php
    ├── footer.php
    ├── single.php
    ├── page.php
    └── sidebar.php

    블록 테마

    my-block-theme/
    ├── style.css
    ├── theme.json
    ├── functions.php
    ├── templates/
    │   ├── index.html
    │   ├── single.html
    │   └── page.html
    ├── parts/
    │   ├── header.html
    │   └── footer.html
    ├── patterns/
    └── styles/

    편집 방식 비교

    클래식 테마에서는 보통 single.php를 수정하거나 사용자 정의에서 CSS를 추가해서 블로그 글 레이아웃을 바꿉니다. 사용자 정의하기 미리보기로 색상과 글꼴은 쉽게 확인할 수 있습니다. 레이아웃을 바꿀 때는 대개 코드나 플러그인이 필요합니다.

    블록 테마에서는 편집기를 열고 단일 글 템플릿을 선택합니다. 헤더를 클릭해서 수정하고, 스타일에서 버튼 스타일을 바꿉니다. 변경 사항은 모든 글에 적용됩니다. 특정 페이지만 다른 레이아웃이 필요하다면 사용자 지정 템플릿을 만든 뒤, 페이지 설정에서 그 템플릿을 선택하면 됩니다.

    단일 글 템플릿을 보여주는 사이트 편집기 화면.

    블록 방식은 더 시각적이에요. 다만 블록, 패턴, 템플릿 파트가 어떻게 맞물리는지 배워야 합니다.

    코드, 플러그인, 호환성

    클래식 테마는 개발자에게 더 많은 자유를 줘요. PHP로 맞춤 로직을 실행하고, 워드프레스의 훅(hook, 코드를 특정 시점에 끼워 넣는 지점)에 연결해서 거의 무엇이든 만들 수 있어요. 대부분의 기존 플러그인이 이 구조에 맞춰 만들어져서 보통 잘 작동합니다.

    블록 테마는 HTML과 JSON을 주로 씁니다. 기본적인 변경에는 코드가 필요 없어요. 하지만 사용자 정의하기 설정을 추가하거나, 위젯 영역에 의존하거나, PHP 템플릿에 연결하는 플러그인은 다르게 작동하거나 아예 작동하지 않을 수 있습니다. 전환하기 전에 호환성을 확인해 보세요.

    테마 선택이 SEO에 영향을 줄나요?

    기본적으로는 어떤 테마 유형도 순위를 자동으로 올려주지 않습니다. 구글은 콘텐츠 품질, 페이지 속도, 모바일 환경, 명확한 페이지 구조를 보기 때문이에요. 테마는 이런 요소에 영향을 주므로 다음 세 가지에 집중하세요.

    • 속도: 홈페이지와 중요한 글 하나를 Google PageSpeed Insights로 테스트해 보세요. 무거운 테마와 플러그인이 많으면 페이지가 느려집니다.
    • 제목 구조: 페이지마다 H1 제목은 하나만 쓰세요. 일부 블록 템플릿은 제목을 추가로 넣기도 하니, 전환 후 사이트 제목과 템플릿 제목을 확인해 보세요.
    • 모바일 레이아웃: 휴대폰에서 사이트를 미리 보세요. 두 테마 모두 반응형으로 만들 수 있지만, 설정이 잘못되면 레이아웃이 깨질 수 있습니다.

    어떤 테마를 선택해야 할까?

    블록 테마를 고르면 좋은 경우:

    • 새 사이트를 시작하는 경우
    • 코드 없이 헤더, 푸터, 레이아웃을 바꾸고 싶은 경우
    • 블록 편집기가 익숙한 경우
    • 필요한 플러그인이 블록 테마를 지원하는 경우

    클래식 테마를 고르면 좋은 경우:

    • 맞춤 PHP 로직이나 깊은 테마 훅이 필요한 경우
    • 위젯, 사용자 정의하기, 또는 클래식 테마에서만 작동하는 플러그인에 의존하는 경우
    • 지금 쓰는 클래식 테마가 잘 작동하고 계속 관리되는 경우. 블록 테마가 새것이라는 이유만으로 바꿀 필요는 없습니다.

    일부 테마는 두 방식을 섞습니다. 이런 “하이브리드” 테마는 클래식 PHP 템플릿과 theme.json, 템플릿 파트 같은 블록 기능을 함께 씁니다.

    나중에 바꿀 수 있을까?

    바꿀 수는 있지만 계획이 필요합니다. 글, 페이지, 댓글은 데이터베이스에 저장되어 있어서 전환 후에도 그대로 남습니다. 이미지는 미디어 라이브러리에 그대로 남아요. 보통 다시 작업해야 하는 부분은 다음과 같습니다.

    • 위젯: 블록으로 다시 만들어야 합니다.
    • 사용자 정의하기 설정: 스타일 패널에서 다시 설정해야 합니다.
    • 맞춤 PHP 템플릿: 블록 템플릿으로 다시 만들어야 합니다.
    • 테마 전용 숏코드: 이를 사용한 레이아웃은 새 블록이나 패턴으로 바꿔야 합니다.

    전환 전에 사이트를 백업하고, 실제 사이트를 건드리기 전에 스테이징 사이트에서 먼저 테스트해 보세요.

    결론

    워드프레스 개발자 핸드북은 블록 테마를 “워드프레스 프로젝트의 미래”라고 소개합니다. 그렇다고 클래식 테마가 사라지는 건 아니입니다. 여전히 작동하고 완전히 지원합니다. 결국 선택은 어떻게 작업하고 싶은지에 달려 있습니다. 블록으로 시각적으로 제어하고 싶다면 블록 테마를 고르세요. 코드 수준의 제어가 필요하거나 이미 잘 작동하는 클래식 환경이 있다면 클래식을 유지하세요.

    어느 쪽을 고르든, 결정하기 전에 꼭 테스트해 보세요.