Claude Opus로 워드프레스 디자인 개편한 기록: 플러그인 하나로 바꾼 것과 사람이 한 일

이 블로그의 디자인이 오늘 통째로 바뀌었습니다. 테마를 새로 산 것도, 디자이너에게 맡긴 것도 아닙니다. 터미널에서 쓰는 AI 코딩 도구 Claude Code(모델은 Claude Opus 5.5)에게 “사이트가 너무 구리다, 고쳐 달라”고 한 문장을 던졌고, 첫 배포까지 1시간 남짓 걸렸습니다. 무엇을 바꿨는지, 어디서 막혔는지, 사람이 직접 해야 했던 일은 무엇이었는지 순서대로 적어 둡니다.

고치기 전에 무엇을 확인했나?

제 요청은 대략 이랬습니다. “워드프레스 성능이 너무 안 좋다. 디자인이 구리고 개인정보처리방침 같은 것도 없다. 구글에서 노출되고, 유입되고, 오래 머무르게 고쳐 달라. 모든 권한을 줄게.”

Claude는 코드를 쓰기 전에 사이트를 먼저 열어 보고 워드프레스 REST API로 설정과 글 목록을 읽었습니다. 그렇게 나온 진단은 이렇습니다.

“개인정보처리방침이 없다”는 제 말을 그대로 받아 새 페이지를 만들었다면 같은 문서가 두 개 생겼을 겁니다. 요청을 곧이곧대로 실행하기 전에 사실부터 확인한 점이 첫인상이었습니다.

왜 테마가 아니라 플러그인으로 바꿨나?

저는 차일드 테마를 고칠 줄 알았는데, Claude는 GeneratePress 테마는 건드리지 않고 그 위에 얹는 전용 플러그인을 새로 만들었습니다. 이유는 두 가지였습니다.

• 되돌리기: 플러그인을 비활성화하면 즉시 원래 모습으로 돌아갑니다. 문제가 생겨도 버튼 하나로 복구됩니다.
• 테마 업데이트: 테마 파일을 직접 고치면 업데이트 때 덮어써질 수 있습니다. 플러그인은 테마가 제공하는 훅(hook)에 끼워 넣는 방식이라 영향을 받지 않습니다.

훅은 테마가 “여기에 끼워 넣어도 된다”고 열어 둔 지점입니다. 예를 들어 사이드바를 전 페이지에서 끄고, 태그 페이지를 사이트맵에서 빼는 코드는 이 정도입니다.

// 모든 페이지에서 사이드바 끄기(GeneratePress 필터)
add_filter( 'generate_sidebar_layout', function () {
	return 'no-sidebar';
} );

// 워드프레스 기본 사이트맵에서 태그 목록 제외
add_filter( 'wp_sitemaps_taxonomies', function ( $taxonomies ) {
	unset( $taxonomies['post_tag'] );
	return $taxonomies;
} );

눈여겨본 부분은 Claude가 훅 이름을 추측하지 않았다는 점입니다. 설치된 버전(GeneratePress 3.6.1)의 원본 소스를 내려받아 실제로 존재하는 훅 목록을 뽑은 다음 코드를 썼습니다.

디자인은 어떤 기준으로 정했나?

저는 Claude Code 설정에 “별도 지침이 없을 때 쓰는 디자인 기본 규칙” 문서를 넣어 두고 있습니다. 애플 웹사이트를 참고한 규칙으로, 강조색은 파랑 하나만 쓰고, 카드와 버튼에는 그림자를 넣지 않고, 둥근 알약 모양은 버튼 같은 ‘행동’에만 쓰는 식입니다. Claude는 이 규칙을 그대로 따르면서 한글 블로그에 맞게 몇 가지를 조정했습니다.

• 글꼴: 한글 가독성이 좋은 Pretendard를 쓰고, 본문은 17px에 줄 간격 1.8로 넉넉하게 잡았습니다. 단어 중간에서 줄이 바뀌지 않게 했습니다.
• 읽기 폭: 사이드바를 없애고 본문 폭을 720px로 고정했습니다. 한 줄이 너무 길면 눈이 다음 줄을 놓칩니다.
• 썸네일 비율: 이 블로그의 대표 이미지는 대부분 1536×1024(3:2)입니다. 흔히 쓰는 16:9로 자르면 이미지 속 글자가 잘려서 카드 비율을 3:2로 맞췄습니다.
• 본문 구조: 글마다 들어 있는 ‘한눈에 보기’, ‘목차’, ‘참고 출처’를 박스로 구분했습니다. 원문은 그대로 두고 화면에 보일 때만 모양을 바꾸는 방식이라, 플러그인을 끄면 예전 모습 그대로입니다.

홈은 처음 온 사람이 다음 글로 넘어가기 쉽게 구성했습니다. 위에서부터 처음 읽을 추천 글, 최신 글, 직접 만든 앱(HELLGATER·MindMatch·티어리스트), 분야별 최신 글, 운영자 소개 순서입니다. 추천 글 목록은 기존 홈 페이지 본문에 걸어 둔 링크를 그대로 읽어 오기 때문에, 추천 글을 바꾸고 싶으면 그 페이지 링크만 고치면 됩니다.

앱 소개 문구를 쓸 때도 Claude는 포트폴리오 페이지를 직접 열어 확인한 내용만 옮겼습니다. 처음 초안에 MindMatch를 “대화로 성향을 맞춰 보는 앱”이라고 추측해서 적었다가, 실제 페이지를 읽고 “Big Five 성격 분석과 사주 궁합을 합친 매칭 플랫폼”으로 고쳤습니다.

글 끝에는 글쓴이 소개와 같은 분류의 다른 글 3편을 붙였습니다. 같은 분류에 다른 글이 없으면 이 칸은 아예 나오지 않습니다. 인기 글이나 최신 글로 빈칸을 채우지 않게 한 것은 예전에 ‘함께 읽으면 좋은 글’에 엉뚱한 글이 섞여 곤란했던 경험 때문입니다.

운영 사이트에 올리기 전에 어떻게 검증했나?

Claude는 Docker로 제 PC에 워드프레스를 하나 띄우고, 운영과 같은 GeneratePress 3.6.1을 설치했습니다. 그리고 공개된 글 30여 편과 소개·문의·개인정보처리방침 페이지를 읽기 전용으로 가져와 복제본을 만들었습니다. 운영 사이트는 건드리지 않고 이 복제본에서 먼저 확인한 것입니다.

• 홈·글·분류·검색·404 화면을 모두 열어 PHP 경고가 0건인지 확인했습니다.
• 휴대폰 폭(390px)으로 줄여 보니 홈의 ‘분야별로 보기’ 카드가 화면 밖으로 넘쳐 가로 스크롤이 생겼습니다. 긴 글 제목을 한 줄로 자르는 설정이 칸 폭을 밀어낸 것이 원인이었고, 고친 뒤 다시 재서 넘침 0을 확인했습니다.
• 글 요약 카드에 “사진 출처: …” 같은 이미지 설명이 섞여 나오는 것을 발견하고, 검색 결과용 설명문을 먼저 쓰도록 바꿨습니다.

확인 과정에서 Claude가 자기 실수를 잡은 장면도 있었습니다. 글을 복제하면서 이미지 주소까지 로컬 주소로 바꿔 버려 본문 이미지가 깨졌는데, 플러그인 문제가 아니라 복제 과정의 문제라고 구분해서 보고하고 복제본만 고쳤습니다.

구글 검색 노출을 위해 무엇을 바꿨나?

디자인과 함께 바뀐 검색 관련 설정은 아래와 같습니다. 대부분 구글 검색 센터 문서에 나오는 기본 항목입니다.

배포한 뒤에는 바뀐 사이트맵을 구글 서치콘솔에 다시 제출했습니다. 이 변경이 실제로 검색 노출을 늘렸는지는 아직 모릅니다. 서치콘솔의 노출 수를 4~8주 지켜본 뒤 후속 글로 정리할 생각입니다.

사람이 직접 해야 했던 일은 무엇이었나?

“모든 권한을 준다”고 했지만 Claude가 혼자 끝내지는 못했습니다. Claude Code에는 위험한 작업을 자동으로 걸러내는 권한 검사가 있어서, 운영 서버에 플러그인을 설치하려는 요청과 서버 접속 정보를 읽으려는 요청이 차단됐습니다. 워드프레스 관리자 로그인도 비밀번호를 쓰는 인증이라 Claude가 대신하지 않았습니다. 로그인 버튼 하나만 누르면 되는 상황이라 솔직히 답답했습니다.

결국 흐름은 이렇게 정리됐습니다.

1. Claude가 플러그인과 변경 스크립트를 만들고 로컬에서 검증
2. 제가 “배포 승인”이라고 답하자 이용약관·메뉴·분류 설명을 API로 반영(변경 전 상태는 파일로 백업)
3. 제가 관리자 화면에서 플러그인 zip을 업로드·활성화
4. Claude가 운영 화면의 HTML을 다시 읽어 결과 확인

중간에 사고도 있었습니다. Claude가 사이트 키트(Site Kit)의 ‘구글 로그인’ 기능만 끄라고 안내했는데, 제가 플러그인 전체를 꺼 버렸습니다. 그 바람에 애드센스 연결 코드와 구글 애널리틱스 태그가 사이트에서 빠졌습니다. Claude가 배포 확인 중에 이것을 발견했고, 두 코드를 플러그인이 직접 넣도록 1.1.0을 만들었습니다. 저는 버전을 올리기 전 파일을 먼저 올려 한 번 헛걸음을 했습니다.

운영 사이트에서만 드러난 문제도 있었습니다. 예전에 제가 ‘추가 CSS’에 넣어 둔 “대표 이미지는 최대 240px” 규칙이 새 카드 이미지까지 작게 줄여 버렸습니다. 테마의 전체 폭 설정(1630px)도 복제본과 달라서 헤더가 본문보다 넓게 벌어졌습니다. 둘 다 복제본에는 없던 설정이라 로컬 검증에서는 잡히지 않았고, 운영 화면을 측정해 원인을 찾은 뒤 1.1.1에서 고쳤습니다.

Claude Opus의 디자인 능력, 써 보니 어땠나?

결과물만 보면 만족합니다. 무엇보다 ‘예쁘게’라는 막연한 요청을 색, 글자 크기, 폭, 비율 같은 구체적인 값으로 바꾸고, 그 값마다 이유를 댈 수 있었다는 점이 좋았습니다.

좋았던 점

• 고치기 전에 측정부터 했습니다. 제 착각(개인정보처리방침이 없다)을 먼저 바로잡았습니다.
• 되돌릴 수 있는 구조를 골랐습니다. 플러그인 비활성화 한 번, 변경 스크립트 되돌리기 한 번이면 원래대로 돌아갑니다.
• 운영 반영 전에 복제본에서 검증했고, 휴대폰 화면까지 수치로 확인했습니다.
• 모르는 사실을 지어내지 않고 원본을 찾아 확인했습니다. 테마 훅, 앱 소개 문구 모두 그랬습니다.

아쉬웠던 점

• 운영에만 있던 설정(추가 CSS, 테마 폭)을 미리 읽지 않아 수정본을 한 번 더 올려야 했습니다.
• 한 번은 “애드센스 광고가 다시 동작한다”고 잘못 말했습니다. 이 사이트는 애드센스 승인을 받지 못한 상태라 광고가 나온 적이 없습니다. 제가 지적하자 바로 정정했습니다.
• 수정 파일의 버전을 올리고 zip까지 만든 다음에 업로드를 부탁해야 하는데, 그 순서를 놓친 적이 있습니다.

정리하면 디자인 감각보다 작업 방식에서 더 차이가 났습니다. 진단하고, 되돌릴 수 있게 만들고, 검증하고, 틀린 것은 인정하는 순서였습니다. 사이트 디자인을 AI에게 맡겨 보려는 분이라면 결과물보다 이 순서를 지키는지를 먼저 보시길 권합니다.

여러분은 AI 코딩 도구에게 어디까지 맡겨 보셨나요? 운영 서버 배포까지 맡기는지, 저처럼 마지막 버튼은 직접 누르는지 궁금합니다.

함께 읽으면 좋은 글

• Orca 사용 가이드: AI 코딩 작업을 worktree로 나누고 검토하기
• AI 구독료 비교 방법: 내 작업의 비용과 재작업 시간으로 판단하기
• 클로드 계정 보안 점검: 로그인과 웹 세션·Claude Code 인증 관리