콘텐츠 자동화에서 가장 위험한 것은 AI가 문장을 잘못 쓰는 일만이 아니다. 과도한 관리자 권한, 노출된 비밀번호, 검토 없는 공개, 중복 발행과 삭제 같은 운영 사고가 더 큰 피해를 만들 수 있다. 자동화가 편리할수록 무엇을 할 수 있고 무엇은 할 수 없는지 경계를 먼저 정해야 한다.
이 글은 개인 워드프레스 사이트에서 AI를 활용해 글을 작성하고 예약할 때 필요한 최소 보안 원칙을 정리한다. 목표는 모든 위험을 없애는 것이 아니라 문제가 생겨도 범위가 제한되고 원인을 추적하며 되돌릴 수 있는 구조를 만드는 것이다.
1. 최고 관리자 계정을 자동화에 사용하지 않는다
사이트 소유자의 관리자 계정은 플러그인 설치, 테마 변경, 사용자 생성과 삭제까지 수행할 수 있다. 글 등록만 필요한 자동화에 이 권한을 제공하면 자격 증명이 노출되었을 때 피해 범위가 지나치게 커진다.
자동화 전용 계정을 만들고 필요한 역할만 부여한다. 글 작성과 예약이 목적이라면 콘텐츠 관련 권한만으로 가능한지 확인한다. 다른 작성자의 글 수정이나 사용자 관리가 꼭 필요한지 별도로 판단한다.
2. 일반 로그인 비밀번호를 코드에 저장하지 않는다
REST API 자동화에는 애플리케이션 비밀번호를 사용한다. 자동화 도구별로 별도 발급하면 어느 도구에서 문제가 생겼는지 구분하고 해당 비밀번호만 폐기할 수 있다.
- 비밀번호를 소스코드와 Git 저장소에 넣지 않는다.
- 화면 캡처, 작업 기록, 글 예제에 실제 값을 노출하지 않는다.
- 환경변수 또는 운영체제의 비밀 저장소를 사용한다.
- 사용 목적을 알아볼 수 있는 이름으로 발급한다.
- 더 이상 쓰지 않는 값은 즉시 폐기한다.
3. 초안 작성과 공개 권한을 분리한다
가장 안전한 흐름은 AI가 초안을 등록하고 사람이 승인하는 방식이다. 자동화 계정이 draft 상태로만 글을 만들고, 편집자가 검토 후 예약하거나 공개한다면 잘못된 글이 바로 노출될 가능성이 줄어든다.
완전 자동 발행이 필요하다면 공개 전 검증 단계를 코드로 둔다. 제목과 본문이 비어 있거나 출처 링크가 없고 금지된 정보가 감지되면 요청을 중단한다. 검증 실패를 자동으로 무시하고 계속 진행하지 않는다.
4. 자동화가 다루지 말아야 할 정보
- 워드프레스 로그인 비밀번호와 애플리케이션 비밀번호
- API 키, OAuth 토큰, 데이터베이스 접속 정보
- 개인 이메일, 전화번호, 주소 등 공개 의도가 없는 정보
- 비공개 초안과 내부 메모 전체
- 서버 로그에 포함된 IP·세션·오류 세부정보
AI 서비스에 자료를 보낼 때는 해당 자료가 외부 처리 시스템으로 전송되어도 되는지 먼저 판단한다. 글 작성에 필요하지 않은 개인정보와 관리자 정보를 프롬프트에 포함하지 않는다.
5. 작업 허용 목록을 만든다
자동화가 사용할 수 있는 기능을 문장으로 명시한다. 예를 들어 글 생성, 본인이 만든 글 수정, 카테고리와 태그 지정, 미래 날짜 예약만 허용하고 플러그인 설치, 사용자 변경, 댓글 삭제, 기존 글 삭제는 금지한다.
API에서도 같은 원칙을 적용한다. 필요한 엔드포인트와 HTTP 메서드만 사용하고, 삭제 요청은 자동 흐름에서 제외하는 편이 안전하다. 기능을 추가할 때마다 권한 범위를 다시 검토한다.
6. 로그에는 결과를 남기고 비밀은 남기지 않는다
문제가 생겼을 때 다음 정보를 확인할 수 있어야 한다.
- 작업 ID와 실행 시각
- 생성하거나 수정한 워드프레스 글 ID
- 요청한 상태: draft, future, publish
- 예약 날짜와 사이트 시간대
- 성공 또는 오류 코드
- 검토하고 승인한 단계
반면 인증 헤더와 비밀번호, 본문에 포함된 개인정보는 로그에서 제거한다. 모든 내용을 기록하면 안전하다는 생각은 오히려 새로운 유출 지점을 만든다.
7. 중복과 폭주를 막는다
네트워크 오류 뒤 무제한 재시도를 하면 같은 글이 여러 개 생기거나 서버에 부담을 줄 수 있다. 작업마다 고유 ID를 사용하고 이미 성공한 요청인지 확인한다. 재시도 횟수와 간격을 제한하며 연속 오류가 발생하면 자동화를 중단하고 알림을 남긴다.
- 한 번의 실행에서 생성할 최대 글 수를 정한다.
- 같은 슬러그와 작업 ID의 존재 여부를 확인한다.
- HTTP 429와 5xx 오류에 무한 재시도하지 않는다.
- 오류가 일정 횟수를 넘으면 사람이 확인할 때까지 멈춘다.
8. 백업과 되돌리기 절차를 먼저 시험한다
자동화를 시작하기 전에 워드프레스의 글 리비전과 호스팅 백업 상태를 확인한다. 복구 방법을 실제로 시험하지 않은 백업은 안심 자료일 뿐 운영 절차가 아니다.
글 수정 자동화에서는 변경 전 글 ID와 기존 상태를 기록하고, 새 글은 처음에 비공개 또는 초안으로 만든다. 삭제보다 휴지통 이동을 사용하더라도 자동 삭제 기능은 별도의 승인 없이는 실행하지 않는 편이 좋다.
9. 정기 점검 항목
- 전용 계정의 역할과 활성 상태
- 애플리케이션 비밀번호의 마지막 사용 시각과 IP
- 예약 실패와 중복 발행 기록
- 워드프레스·플러그인·테마 보안 업데이트
- 사이트 건강과 백업 성공 여부
- 자동 생성 글의 품질과 내부 링크
사용하지 않는 자동화 계정과 비밀번호를 그대로 두지 않는다. 운영 주기가 끝나면 접근권한을 회수하는 것까지 자동화 프로젝트의 완료 조건으로 삼는다.
10. 검색과 애드센스를 위한 대량생산을 경계한다
보안이 기술 권한만의 문제는 아니다. 확인되지 않은 글을 대량 발행하면 사이트의 신뢰와 검색 품질도 훼손될 수 있다. Google은 검색 유입만을 목적으로 여러 주제의 콘텐츠를 광범위하게 자동 생성하는 방식을 경고하며, 독창적인 경험과 분석, 정확한 작성자 정보를 강조한다.
자동화의 성공 기준을 몇 편을 발행했는가가 아니라 검토 시간을 얼마나 줄였고 오류 없이 얼마나 유용한 글을 공개했는가로 잡아야 한다.
최종 운영 체크리스트
- 전용 계정에 최소 권한만 부여했는가?
- 일반 비밀번호 대신 폐기 가능한 인증 수단을 사용하는가?
- 초안과 공개 사이에 승인 단계가 있는가?
- 비밀정보를 프롬프트와 로그에서 제거했는가?
- 재시도, 중복 방지와 자동 중단 조건이 있는가?
- 문제가 생겼을 때 되돌릴 백업과 글 ID가 있는가?
- 자동화 종료 후 권한 회수 절차가 있는가?
정리
- 콘텐츠 자동화는 전용 계정과 최소 권한에서 시작한다.
- 비밀정보는 코드, 프롬프트와 로그에 남기지 않는다.
- 초안 생성과 공개 승인을 분리하면 사고 범위를 크게 줄일 수 있다.
- 로그, 재시도 제한, 백업과 권한 회수까지 포함해야 운영 가능한 자동화가 된다.
이 글로 AI·자동화의 첫 연재를 마친다. 이후에는 공공데이터 API와 지도 프로젝트처럼 실제 구축 사례를 중심으로 확장할 예정이다.
참고자료
- WordPress REST API Authentication
- WordPress Application Passwords
- Google Search Central, 사람 중심 콘텐츠와 AI 자동화
- Google AdSense, 독창적인 콘텐츠와 사용자 경험