AI 에이전트에게 블로그 운영을 한 달 맡겨 보니, 실제로 터진 사고 6가지트래픽 한도 초과, 이틀간의 접속 차단, 보이지 않는 버튼, 그럴듯하게 틀린 숫자, 몇 주째 빨간불이던 경보까지. 날짜와 원인, 지금 쓰는 안전장치를 기록했다

01무엇을 맡기고, 무엇을 남겼나

에이전트에게 맡긴 일은 대부분 반복 작업이었다. 워드프레스 편집기나 관리 화면에서 글과 스타일을 저장하고, 바뀐 페이지의 Cloudflare 캐시를 비우고, Search Console과 애널리틱스 수치를 읽어 오고, 사이트맵과 robots.txt가 제대로 나오는지 점검했다.

내가 남겨 둔 일도 분명했다. 무엇을 발행할지 정하는 일, 네이버 블로그 같은 외부 채널에 올리거나 고치는 일, 호스팅과 결제 계정에 로그인하는 일이다. 이 경계는 처음부터 정한 것이 아니라 아래 사고들을 겪으며 조금씩 단단해졌다.

02사고 1: 점검하다 하루 트래픽 한도를 두 번 넘겼다 9월 22일

무슨 일이 있었나. 모바일 화면을 확인하려고 에이전트가 워드프레스의 사용자 정의하기 미리보기를 열자, 화면에 “오늘 일일 방문 한도에 도달했습니다”라는 호스팅 안내가 떴다. 묘한 점은 홈페이지가 여전히 HTTP 200, 즉 ‘정상’ 응답을 돌려줬다는 것이다. 상태 코드만 보면 아무 문제가 없었지만, 본문 자리에는 안내 화면이 들어 있었다.

내가 호스팅 관리 화면에서 한도를 풀어 몇 분 만에 돌아왔다. 그런데 같은 날 저녁, 검색 노출 점검을 맡기자 같은 일이 또 일어났다. 에이전트가 홈, 글 11편, 소개·문의·개인정보 페이지, 카테고리, robots.txt, 사이트맵, ads.txt까지 15개가 넘는 페이지를 연달아 불러오는 사이 한도를 넘겼고, 이후 요청은 모두 연결 시간 초과로 끝났다.

원인. 당시 요금제의 하루 트래픽 한도는 1.6GB였다. 방문자는 거의 없었다. 한도를 쓴 것은 편집 화면 미리보기와 반복 점검, 그러니까 에이전트의 ‘확인’이었다.

03사고 2: 이틀 가까이 브라우저 방문자가 막혔다 9월 26~27일

무슨 일이 있었나. 9월 26일 새벽 2시 40분쯤(토론토 시간), 글 제목을 고치던 에이전트가 이상한 응답을 받았다. 워드프레스 데이터 대신 800바이트쯤 되는 보안 확인 페이지가 돌아온 것이다. 일반 브라우저는 이 확인을 세 번 거친 뒤 “403 Forbidden”으로 끝났다. 로그인한 관리자는 캐시를 거치지 않기 때문에 관리자 화면까지 전부 막혔다. 나도, 에이전트도 사이트를 고칠 수 없는 상태가 됐다.

더 곤란한 점이 있었다. 이 확인 페이지가 ‘정상 응답’처럼 보였기 때문에 Cloudflare가 그대로 캐시에 담아 버렸다. robots.txt, ads.txt, 사이트맵, RSS, 소개·문의·개인정보 페이지가 한동안 확인 페이지로 바뀌어 있었다. 반대로 구글 검색 로봇처럼 허용 목록에 있는 봇은 정상 페이지를 받았다. 그래서 검색 쪽 점검 도구로는 문제가 잘 보이지 않았다.

원인 찾기. 에이전트가 호스팅의 봇 차단, 국가별 차단, 특정 IP 차단, 웹 방화벽 설정을 차례로 확인했지만 모두 원인이 아니었다. 범인은 호스팅 보안 메뉴의 ‘스팸 SHIELD’였다. 기본값은 꺼짐인데, 호스팅 업체 설명으로는 비정상 접속이 많으면 스스로 켜질 수 있다. 차단 기록에는 캐나다 IP 367개가 남아 있었고, 대부분 Cloudflare 토론토 서버로 보였다. 정확히 무엇이 스위치를 켰는지는 지금도 확인하지 못했다.

해결. 9월 27일 밤, 내가 호스팅 관리 화면에 로그인한 뒤에야 설정을 ‘사용안함’으로 돌릴 수 있었다. 저장하자 바로 일반 브라우저의 접속이 돌아왔다.

04사고 3: 저장은 성공했는데 버튼이 보이지 않았다 9월 22~23일, 세 번

무슨 일이 있었나. 홈의 ‘발행한 글 보기’ 버튼 글자가 사라졌다. 처음 알아챈 것은 에이전트가 아니라 화면을 보던 나였다. 색을 재 보니 글자와 배경이 모두 rgb(37, 39, 34)였다. 명암비 1.00, 읽기 어려운 정도가 아니라 아예 보이지 않는 상태였다.

원인. 테마의 다크 모드와 충돌하지 않게 하려고 에이전트가 넣은 규칙이 문제였다. 링크 색을 주변 글자색으로 강제로 맞추는 규칙이 나중에 만든 버튼까지 덮어 버렸다. 같은 문제가 홈의 ‘지금 주목할 기술’ 카드에서, 다음 날에는 영어 홈의 버튼에서 다시 나왔다. 세 번 모두 저장은 성공했다.

측정에도 함정이 있었다. 버튼 위에 마우스를 올린 상태로 색을 재면 명암비가 5.53으로 나와 정상처럼 보였다. 마우스를 치운 기본 상태에서 다시 재야 문제가 드러났다.

05사고 4: 영리해 보이던 방법이 99% 실패했다 9월 22일

처음에는 한국어 글 하나에 ‘영어 보기’ 버튼을 달려고 했다. 버튼을 누르면 페이지 안의 한국어 문장을 찾아 영어 문장으로 바꿔치기하는 방식이었다. 글을 두 벌 만들 필요가 없어 보여 그럴듯했다.

결과는 실패였다. 워드프레스는 본문을 화면에 내보내면서 문단, 공백, 특수문자 표현을 조금씩 바꾼다. 그래서 미리 준비한 한국어 문장과 실제 화면의 문장이 맞지 않았다. 화면 속 글 조각의 약 99%에서 짝을 찾지 못했다. 결국 영어 글을 따로 만들고 서로 링크하는 단순한 구조로 바꿨다.

06사고 5: 그럴듯하게 틀린 숫자 9월 25일, 10월 20일, 10월 23일

사이트를 멈추게 하지는 않았지만 가장 조심해야 하는 사고다. AI 초안의 오류는 대부분 엉뚱한 문장이 아니라, 맞는 숫자를 잘못된 맥락에 놓는 형태였다.

자동 검사기가 잡은 것. 9월 25일, 모델 가격과 출시일을 한 파일에 모아 기준표를 만들고, 발행한 글을 기준표와 대조하는 검사기를 만들었다. 첫 실행에서 40편 가운데 세 건이 나왔다.

• 이미 판매가 끝난 모델(DeepSeek V4-Flash)의 가격이 두 글에 그대로 남아 있었다.
• 한 모델(Kimi K3)의 출력 가격은 확인된 출처가 없었다.
• “후보 비교까지만 맡기면 결제 위험이 없다”처럼 지나치게 단정적인 표현이 있었다.

셋 다 고쳤고, 이 검사는 GitHub Actions로 매일 돌게 했다. 다만 이 검사기에도 뒤에서 이야기할 문제가 생겼다. 검사기를 만든 과정과 잡아낸 것은 따로 정리했다.

사람의 검토가 잡은 것. 10월 20일 발행한 AI 에이전트 하네스 글은 바깥 검토를 두 번 받았다. 논문 속 “15.1% → 36.0%”는 개선 과정에 쓴 문제만 따로 계산한 결과였고, 전체 결과는 18.0% → 36.7%였다. 비슷한 방식의 연구가 몇 달 먼저 나와 있었는데, 새 연구가 그 방식을 처음 내놓은 것처럼 읽히는 대목도 있었다. 10월 23일 발행한 클로드 듀엣 글도 세 차례 검토를 받으며 고쳤다. 처음 글에는 기존 Claude의 Cowork도 클라우드 실행과 예약 작업을 지원한다는 설명이 빠져 있어서, 듀엣만 할 수 있는 일처럼 읽혔다. 지금은 차이를 ‘먼저 브리핑하고 확인을 요청하는 방식’으로 설명한다. 대기 신청 이메일 조건도 처음에는 ‘둘 중 하나’로 잘못 읽었다가 도움말을 다시 확인해 고쳤다.

07사고 6: 몇 주째 빨간불이던 경보 9월 30일~10월 24일

이 글을 쓰려고 자동 점검 기록을 다시 열었다가 찾은 사고다. 앞에서 말한 두 안전장치가 모두 실패 상태였다. 3시간마다 도는 접속 점검은 10월 13일 밤 11시 36분부터 10월 24일 밤까지 88번 연속 실패했다. 매일 도는 사실 검사는 그보다 먼저, 9월 30일부터 매일 실패로 끝나고 있었다. 실패 메일은 꼬박꼬박 왔지만 아무도 열어 보지 않았다.

접속 점검이 실패한 이유. 10월 13일 밤 보안 점검을 하면서, 로그인하지 않은 방문자가 워드프레스 데이터 창구(REST API)의 첫 화면을 열면 401(인증 필요)을 돌려주게 바꿨다. 그런데 접속 점검은 바로 그 첫 화면으로 호스팅 차단 여부를 확인하고 있었다. 401을 받자 “호스팅 보안 기능이 다시 켜졌다”고 판단한 것이다. 실제 사이트는 멀쩡했다. 같은 보고서에 “방문자 확인: 모든 페이지 정상”이라는 줄이 함께 찍혀 있었다.

사실 검사가 실패한 이유. 9월 30일부터는 기준표에 없는 숫자, 예를 들어 캐시 할인 가격이나 작업 1건당 비용을 ‘불일치’로 잡아 9건을 보고하고 있었다. 기준표가 모자란 것인지 글이 틀린 것인지 하나씩 가려야 했는데, 그대로 쌓아 두었다. 10월 13일부터는 같은 보안 설정 때문에 글 본문을 아예 읽지 못하게 됐다.

고친 뒤. 10월 24일 밤 두 점검 도구를 고쳤다. 접속 점검은 로그인 없이도 열리는 데이터 창구 주소로 확인하도록 바꿨고, 89번째 실행부터 다시 정상으로 돌아왔다. 사실 검사기는 글을 공개 페이지에서 직접 읽게 바꾸고, 쌓여 있던 9건을 원문과 하나씩 대조했다. 9건 모두 글의 숫자는 맞았다. 기준표에 캐시 할인 가격 같은 항목이 없었거나, 검사기가 숫자를 엉뚱한 모델에 붙인 것이 원인이었다.

08지금 쓰는 규칙 7가지

여섯 사고를 겪고 남은 규칙이다. 에이전트에게 웹사이트 일을 맡긴다면 그대로 가져가도 좋다.

1. 저장 전에 최신 상태부터 확인한다. 마지막 수정 시각과 본문이 내가 읽은 것과 같은지 본다. 오래 열어 둔 다른 편집 화면이 최신 글을 덮어쓰는 일을 막는다.
2. 저장 후 다시 읽는다. 바꾸려던 부분만 바뀌었는지 확인한다.
3. 캐시는 바뀐 주소만 비운다. 전체 비우기는 원본 서버에 부담을 몰아준다.
4. 화면은 캡처로 확인한다. 모바일과 PC, 라이트와 다크 모드를 본다.
5. 상태 코드만 믿지 않는다. 200이어도 본문에 기대한 내용이 있는지 확인한다. 반대로 실패 알림도 실제로 받은 응답을 보고 판단한다.
6. 외부 채널은 승인 후에만 반영한다. 네이버 블로그 발행이나 수정은 내가 확인한 뒤에 한다.
7. 계정과 결제는 사람이 맡는다. 호스팅, 결제, 보안 설정은 내가 로그인해서 열고, 에이전트는 그 화면에서 필요한 일만 한다. 보안 설정을 바꾼 날에는 자동 점검 결과도 함께 확인한다.

한 달 동안 에이전트에게 맡겨서 가장 좋았던 점은 반복 확인과 기록이었다. 원인 후보를 빠르게 좁히고, 무엇을 언제 바꿨는지 빠짐없이 남겼다. 반대로 무엇을 발행할지, 어디까지 고칠지, 어떤 계정을 열지는 끝까지 사람의 일이었다. 에이전트에게 일을 맡길 때 권한을 어떻게 나눌지 더 알고 싶다면 AI 에이전트와 업무 자동화의 차이와 AI 에이전트 하네스 이야기를 이어서 읽어 보자.