워드프레스 GitHub로 관리하기 with Claude

작성자:

이전 글에서 Claude 와 함께 한 워드프레스 블로그 개설 후기를 이야기 했습니다.

블로그를 시작하기로 결심했습니다. 지난 글에서 보았듯이, 먼저 네이버 블로그로 시작했다가, 좀 더 자유롭게 커스터마이징이 가능한 워드프레스로 옮겨오기로 했습니다. 개인적으로 전산학을 전공했고, 소프트웨어, AI 관련 업무를 오래 해온 터라, 대수롭지 않게 생각했습니다. 예전에 다 해본 일들이었으니까요. 그런데 호스팅을 완료하고 처음 관리자 화면에 들어가는 순간, 잠깐 멘붕이 왔습니다. … 더 읽기
워드프레스 설정 with Claude – 바이브코딩 경험

네이버, 티스토리 같은 플랫폼 대신 워드프레스를 선택했기 때문에,
직접 코드를 수정하고, 발행하고, 버전을 관리할 수 있는 시스템 구축이 필요했습니다.

대학원 시절에는 SVN 같은 시스템을 활용했고, 회사 입사 후 한창 개발을 하던 시기에는 사내 버전관리 시스템을 이용했습니다. 그리고, Git의 경우는 제가 관리자가 된 이후에 활발하게 사용되었던 것 같습니다. 그러다 보니, 필요한 경우 소스코드에 접근하기 위해 git 명령어를 익히고 사용은 해봤지만, 제가 직접 git 기반의 개발 환경을 구축해본 적은 없었습니다.

블로그 설정 때와 마찬가지로 어떻게 해야 하는지 어렴풋이 감은 잡혔으나, 구체적으로 실행을 하기엔 디테일이 좀 부족했죠.
워드프레스 GitHub 관리라는 목표로, 이번에도 Claude를 최대한 활용했고, 상당히 짧은 시간 내에 VScode-GitHub 기반의 개발 및 배포 환경 구축을 완료했습니다.

대략 30분 내외에 모든 작업을 완료했고, 각종 troubleshooting 시간을 감안했을 때, 만약 혼자 작업을 했으면 최소 반나절 에서 하루 이상 걸렸을 것으로 생각됩니다. 이번 글에서는 관련 경험을 기록하고자 합니다.

목차

① 개발환경 구축 목표 — AS-IS vs TO-BE

블로그 구축 초기에는 Terminal이나 FTP를 이용해서 서버에 저장된 파일을 직접 수정했습니다.
당연히 적은 수정사항들을 빠르게 적용하기에 편리하긴 하지만, 어느 순간 수정사항들이 늘어나면서 버전관리의 필요성을 느꼈습니다.

사실 대기업에서 Software Engineering 업무를 맡아온 입장에서 당연히 했어야 하는 일을 안하고 있었던거죠. ㅎㅎ

목표는 아주 단순합니다.
“코드 수정 → push → 서버 자동 반영”의 워크플로우를 만들어 버전관리를 하고, 필요시 롤백도 가능하게 만드는 것입니다.

② 계획 수립

AI를 실제 작업에 활용하면서, 좀 큰 일들은 미리 계획을 수립하도록 요청하면 이후 작업이 원할해집니다.
그래서, Claude에게 처음 던진 요청은 이랬습니다.

서버의 수정할 파일들을 GitHub에 올리고,
집 컴퓨터에 git 환경을 구축하고, 이후 집에서 수정하면 git에 push하고,
서버에서는 pull해서 업데이트하는 환경을 만들고 싶어.
차근차근 순서대로 할 수 있게 계획 세워줘

그랬더니, 호스팅 업체가 어디인지, SSH 접속은 가능한지 등 환경을 먼저 물어보더군요.
저는 작업하면서 공부도 같이 하고 싶었기 때문에, 그런 질문들을 왜 묻는지, 경우에 따라 작업 방식이 어떻게 달라지는지 꼼꼼하게 물어보며 작업을 진행했습니다.

Claude는 SSH 가능 여부에 따라 작업 방향이 달라진다고 하더군요.
SSH가 되면 서버에서 직접 git pull 또는 GitHub Actions을 쓸 수 있고, 안되면 Webhook으로 우회해야 한다고 합니다.

이후 몇가지 질문을 더 한 후에 아래와 같은 작업 계획을 수립했습니다.

Github 기반 개발환경 구축 계획

  1. GitHub 저장소 생성
  2. 서버 → GitHub SSH 연결
  3. 서버에서 git init 및 push
  4. 집 PC → GitHub 연결
  5. 자동 배포(GitHub Actions) 설정

제가 생각하기엔 이 순서를 잡는 일이 무척 중요했습니다. 순서가 바뀌면 중간에 막히거나 다시 해야 하는 일이 생깁니다.
실행 전에 전체 그림을 잡는 것, 이게 Claude와 일하는 방식의 출발점이었습니다.

③ 저장소 생성 및 범위 결정

가장 먼저 GitHub 저장소를 생성했습니다. 사실 이 정도는 그냥 해도 되지만, 왜 저장소를 private으로 만드는 게 좋은지, 어떤 이름으로 할지, 구조를 어떻게 잡을지 등 Claude와 지속적으로 대화를 하면서 작업을 했습니다.

그리고 결정해야 하는 것이 바로 관리 대상을 정하는 일이었습니다.
처음 든 생각은 워드프레스 전체를 넣는 것이었습니다. “어차피 서버 파일들이니까 다 넣으면 안전하지 않나”라는 생각이 들었고, Claude에게 질문을 했고, 돌아온 답은 명확했습니다.

아래의 3가지 이유로, child theme만 관리하는 것을 추천했습니다.

  • 워드프레스 코어 파일 수천 개는 관리 대상이 아님. 업데이트는 워드프레스가 알아서 진행하게 됨.
  • wp-content/uploads/ 에는 대량의 이미지들이 존재하고, 저장소를 불필요하게 거대하게 만들게 됨.
  • wp-config.php에는 DB 접속 정보가 포함되어 있음.

생각해보니, 일리가 있다고 판단되었고, child theme만 저장하기로 했습니다.

저장소 루트에 파일이 바로 보이는 것보다, generatepress-child 폴더가 명시적으로 보이는 구조가 낫다고 판단했습니다. 꼭 필요한 폴더들만 Git에 포함될수 있도록 .gitignore로 차일드 테마 외 나머지를 모두 제외했습니다.

Remote Serve 폴더 구조
GitHub 폴더구조
.gitignore 설정

이 과정을 진행하면서 Claude 는 여러 선택지들의 장단점을 정리해 주었고, 필요한 구조 설계도 제안해 주었습니다.
저는 이를 바탕으로 의사결정을 진행하는 역할을 수행하면서 작업을 진행했습니다.

④ 서버 환경 설정 및 Git 초기화

제가 이용중인 Cafe24 매니지드 워드프레스서비스는 SSH 접속이 가능하고, git, ssh-keygen도 지원이 됩니다.
이 환경 하에서 Claude와 함께 순차적으로 아래 작업들은 진행했습니다. 

# 서버에서 GitHub용 SSH 키 생성
ssh-keygen -t ed25519 -C "<구분자>"

# 공개키 확인 후 GitHub에 등록
cat ~/.ssh/id_ed25519.pub

# 연결 확인
ssh -T git@github.com

GitHub 연결 확인 후, themes/ 디렉토리에서 git init → commit → push 까지 진행했습니다.

이 단계에서는 Claude를 통해서 명령어를 확인하고, 필요한 설명을 듣고, 제시하는 절차대로 진행을 했습니다.
워낙 뻔한 절차라서 그런지 순조롭게 진행이 되었습니다.

⑤ 로컬 환경 설정 및 VScode 연결

집 PC(Windows)에서도 동일하게 SSH 키를 생성해 GitHub에 등록하고, 저장소를 clone했습니다.

git clone git@github.com:<github-id>/<github-repo>.git

VS Code에서 clone한 폴더를 열면 기본적인 준비가 완료 됩니다. Git은 VSCode에 내장되어 있어 별도 익스텐션이 필요 없습니다. 시스템에 Git이 설치되어 있으면 Source Control 패널이 자동으로 활성화됩니다.

이제 코드 수정, 커밋, 동기화 까지 UI로 처리가 가능합니다.

⑥ 자동 배포 환경 설정 — GitHub Actions

수정한 파일들을 GitHub에 저장하면, 해당 수정사항들을 Remote Server에 자동으로 반영할 수 있는 체계가 필요합니다. 즉, git push 후 Server에서 자동으로 git pull이 실행되도록 GitHub Actions를 설정하는 과정이 필요합니다.

외부 호스팅 업체의 제약사항으로 인해 이 부분에 시간이 좀 걸렸습니다.

먼저, 호스팅 업체의 기본 설정 상, 기본적으로 국내IP에서만 SSH 접속을 허용하고 있었습니다.
이 부분은 Claude가 모르고 있던 부분이었고, TCP연결을 테스트 하는 과정에서 발견을 해서 변경하였습니다.

두 번째로, 외부로 나가는 접속에서는 ssh-keygen으로 생성한 키를 이용할 수 있었지만, 외부에서 호스팅 서버로 접속하는 경우의 SSH 인증은 업체가 발급한 key 만 허용하는 구조였습니다. 역시 Claude는 알 수 없었고, 제가 추가 정보를 제공함으로써 해결하였습니다.

마지막으로, git 명령어의 위치가 통상적인 서버 구조와 달라서 그 부분을 추가로 반영했습니다.

그렇게 해서 아래와 같은 아주 기본적인 수준의 deploy.yaml 파일을 작성할 수 있었고, 현재 원할하게 작동합니다. 

name: Deploy to Server

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: SSH and pull
        uses: appleboy/ssh-action@v1.0.3
        with:
          host: ${{ secrets.SSH_HOST }}
          username: ${{ secrets.SSH_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          port: 22
          script: |
            cd ~/www/wp-content/themes
            ~/bin/git pull

⑦ 맺음말

중간 관리자 역할을 맡은 이후로 이번처럼 처음부터 끝까지 핸즈온으로 직접 해본 경험은 거의 없었습니다.
대부분은 방향을 잡고 지시를 하면 팀원들이 실행하는 구조였으니까요.

아직까지는 제가 중간에 개입해서 각 과정을 직접 살펴보고 있지만, 이게 점점 더 익숙해지면, AI에게 위임하는 역할이 자연스럽게 더 커질것으로 예상됩니다.

이러한 경험을 통해서 인간 개발자의 역할도 더 명확히 이해하게 되었습니다. 기술적 맥락을 이해하고 방향을 판단하는 것, Claude가 제시한 방향을 무조건 수용하기 보다는 그 내용을 이해하고, 필요한 부분은 수정해 가면서 단계를 밟아가는 것이 중요했습니다. 역시 제가 관련 기술들을 대부분 잘 알고 있었기 때문에 가능했다고 생각합니다.

분명한 건, 지난 글과 이번 글을 통해서 살펴보았듯이, AI를 통해 상당한 생산성 개선 효과가 있는 것은 분명합니다.
최대 효과를 내기 위해서 인간 개발자와 AI와 어떻게 역할을 나누고, 어떤 절차로 일을 하는 게 더 좋은지 고민해볼 때입니다.

AI를 이끄는 건 여전히 사람입니다.

ChulJoo Kim (김철주).

ckarch.kr © 2026 is licensed under CC BY-NC-SA 4.0 CC BY NC SA

댓글 남기기