sakyowon 위키

AI와 함께 홈페이지 문구를 고치고 실제 반영까지 확인하기

8 min read

AI와 함께 홈페이지 문구를 고치고 실제 반영까지 확인하기

요약

단체 홈페이지의 안내 문구 하나를 고치는 일도, 실제로는 “어느 파일을 고치나 → 고친 것을 어떻게 올리나 → 방문자에게 진짜 보이나”의 세 관문을 통과해야 끝난다. 망남마을학교 파란교실 페이지의 문구 수정과 신청서 개편을 AI와 함께 진행하면서, 세 관문을 각각 어떻게 넘는지와 중간에 걸린 함정 두 개(낡은 설정값, “올렸는데 안 보임”)를 기록한다.

왜 이 기술인가

활동가가 외주 없이 홈페이지를 운영하면 문구 수정 요청이 일상적으로 들어온다. “참가비 안내 바꿔주세요” 같은 한 줄 요청도, 페이지가 코드로 만들어져 있으면 (1) 그 문구가 어느 파일에 있는지 찾고 (2) 다시 빌드해서 올리고 (3) 실제 사이트에 반영됐는지 확인해야 한다. AI는 세 단계 모두를 대신할 수 있지만, “올렸다”와 “보인다”가 다를 수 있다는 것을 아는 쪽은 사람이어야 한다.

단계별 따라하기

1. 문구가 사는 곳 찾기 — 화면의 문장으로 검색한다

파일 구조를 몰라도 된다. 화면에 보이는 문장 그대로 AI에게 주면 된다.

“https://…/village-school/youth/ 이 페이지인데, ‘1인 1침상이 기본이며,‘를 삭제해”

AI는 저장소 전체에서 그 문장을 검색해 파일을 찾는다. 이때 확인할 것 하나: 로컬 복사본이 최신인가. 이번 작업에서는 로컬이 서버(GitHub)보다 8커밋 뒤처져 있어서, 찾으려는 페이지 자체가 로컬에 없었다. “서버에 있어” 한 마디로 AI가 최신을 받아와(git pull) 해결했다. 수정 전 pull은 습관으로 만들 것.

2. 고치고 올리기 전, 빌드 결과물을 검증한다

정적 사이트는 수정 → 빌드 → 배포 순서다. 여기서 이번 작업의 첫 함정이 나왔다.

  • 신청폼이 데이터를 보내는 주소(엔드포인트)가 예전 방식(Google Apps Script)에서 자체 서버로 바뀌어 있었는데, 로컬의 환경설정 파일(.env.local)에는 옛 주소가 그대로 남아 있었다.
  • 그대로 빌드하면 문구는 새것, 신청폼은 옛 주소로 회귀 — 겉보기에 멀쩡한데 신청 데이터가 엉뚱한 곳으로 가는 사고가 된다.
  • AI가 배포 이력(“신청폼 자체 서버 연결”)을 읽고 충돌을 알아챈 뒤, 옛 설정을 주석 처리하고 빌드했다.

교훈은 단순하다: 빌드 직후, 산출물에서 “있어야 할 것”과 “없어야 할 것”을 둘 다 검색하라. 새 문구가 있는지, 옛 주소가 없는지. AI에게 “빌드 결과물에서 ○○ 검색해서 확인해”라고 요구하면 된다.

3. “올렸다”와 “보인다”는 다르다 — 반영 확인까지가 배포다

배포 저장소(gh-pages)에 push를 마쳤는데도 실제 사이트는 옛 문구였다. 원인 추적에 쓴 도구는 단 하나, 응답 헤더였다.

curl -sI https://사이트주소/ | grep -i last-modified
  • Server: Caddy — 사이트가 GitHub Pages가 아니라 자체 서버에서 서빙되고 있었다. push가 곧 반영이 아닌 구조.
  • Last-Modified 시각을 기록해 두면 “서버가 언제 마지막으로 갱신했나”가 보인다. 이번에는 갱신 시각들을 비교해 자동 동기화가 아니라 관리자가 수동으로 배치 스크립트를 돌리는 구조임을 알아냈고, 16시간 동안 반영이 밀린 구간도 이 헤더로 확인했다.
  • 최종 확인은 문구 검색으로: curl -s 주소 | grep "새 문구" 가 나와야 완료, 지운 문구는 0건이어야 완료.

4. 신청서(폼)를 고쳤다면 눈이 아니라 손으로 검증한다

신청서에 필수 항목 두 개(일정 참가 확인, 고속버스 가능 여부)를 추가한 뒤, AI가 로컬에서 사이트를 띄우고 실제로 빈 채로 제출 버튼을 눌러 차단 문구가 뜨는지, 하나씩 채우면 다음 검증으로 넘어가는지 클릭으로 확인했다. 화면에 보이는 것과 동작하는 것은 다르므로, 폼은 반드시 제출까지 시켜 본다.

교훈

  1. 문구 수정 요청은 세 관문이다: 파일 찾기 → 빌드·배포 → 반영 확인. 마지막 관문을 생략하면 “고쳤는데 그대로예요”가 반복된다.
  2. 낡은 설정값은 최신 코드보다 오래 산다. 환경설정 파일(.env 류)은 저장소에 없어서 AI도 사람도 잊기 쉽다. 구조가 바뀐 직후에는 반드시 대조할 것.
  3. 응답 헤더는 공짜 탐정이다. Server:로 누가 서빙하는지, Last-Modified:로 언제 갱신됐는지 — 접속 권한 없이도 배포 구조를 상당히 알아낼 수 있다.
  4. AI에게 “됐어요”가 아니라 증거를 요구하라. 빌드 산출물 검색 결과, 라이브 문구 검색 결과, 폼 제출 차단 스크린샷 — 이번 작업의 모든 단계는 증거를 남기고 넘어갔다.

참고

이 문서는 연대지능 공동위키에도 같은 내용으로 올라가 있다. 원본: AI와-함께-홈페이지-문구를-고치고-실제-반영까지-확인하기

그래프 뷰