AI가 코드를 고친 것과 실제 방문자가 새 화면을 보는 것은 다른 단계다. 수정본이 저장소에 올라가도 배포가 막히면 서비스는 어제 모습 그대로다. 밤새 일한 AI의 보고서가 화려해도 마지막 확인은 따로 해야 한다.
1. 작업 완료라는데 화면은 왜 옛날 그대로일까
자기 전에 디자인 수정, 광고 배치, 외국어 페이지 공개를 맡겼다고 해 보자. 아침 보고에는 수정 완료, 점검 완료, 저장 완료가 줄줄이 적혀 있다.
그런데 사이트를 열면 옛날 버튼이 인사한다. AI는 야근했는데 웹사이트는 늦잠 잤다.
작업은 작성 → 저장 → 배포 → 실제 화면 확인으로 나눠 봐야 한다. 마지막 단계까지 갔는지 확인해야 방문자 입장에서도 끝난 일이다.
2. 창고는 가득 찼는데 출고문이 잠겼다
소스 저장소는 변경사항을 보관한다. 배포 시스템은 그 변경사항을 인터넷에 올린다. 두 과정은 따로 막힐 수 있다. 새 글을 공개하는 과정과 사이트 프로그램 자체를 교체하는 과정도 분리된 경우가 많다.
그래서 새 글은 올라오는데 디자인은 그대로이고, 번역 원고는 준비됐는데 외국어 페이지는 보이지 않는 상황이 생긴다. 상품은 수천 개, 출고장은 임시 휴업.
문제는 AI가 게을러서가 아니라, 마지막 한 단계의 병목이 완성품 전체를 붙잡고 있다는 데 있다.
3. 무료 한도도 서로 다른 두 종류가 있다
2026년 10월 기준 Cloudflare 무료 요금제의 Workers Builds는 월 3,000분의 빌드 시간을 제공하고, Workers 실행 요청은 하루 100,000회로 제한한다.[1][2]
전자는 새 버전을 만드는 과정의 한도다. 후자는 서비스가 방문자의 요청을 처리하는 과정의 한도다. 둘 다 무료 한도라는 이름으로 묶으면 수리할 곳을 잘못 고르게 된다.
빌드가 막히면 불필요한 재실행을 줄이고 승인된 대체 경로를 준비한다. 요청이 지나치면 Worker를 거쳐야 하는 통신 자체를 줄인다. 주방 불을 다시 켰다고 출입구의 긴 줄이 사라지는 건 아니다.
4. 실패 버튼을 계속 누르다 무료 시간을 다 쓴다
빌드 실패. 이유를 파악하기 전에 다시 실행. 또 실패. 사용 가능 시간이 줄어든다. 원인을 찾아냈을 땐 이달의 몫이 끝났다.
고장 보고서는 열 장인데 공개된 수정은 영 건. 이쯤 되면 서비스가 아니라 실패 보고서 제작소다.
로그를 읽고 원인을 확인한 뒤, 가능하면 로컬에서 재현해 고치고 다시 실행하자. 내용만 바뀐 글 하나 때문에 사이트 전체를 매번 새로 만들 필요가 있는지도 따져야 한다. 한 작업의 실패가 다른 안전한 공개 작업까지 멈춰 세우지 않도록 분리하는 것도 중요하다.
5. AI에게 맡길 것은 수정뿐 아니라 복구까지
좋은 야간 작업자는 성공한 파일 목록뿐 아니라 실제 반영된 것, 막힌 것, 원인, 이어서 처리한 것을 구분해 알려준다. 권한이 허용하는 선에서 오류를 해결하고 배포까지 잇는다.
배포 경로가 여러 개라면 서로 다른 버전을 덮어쓰지 않도록 같은 최신 상태를 공유해야 한다. 계정 권한과 비밀키는 소유자가 관리하고, AI는 허가된 절차로 움직이면 된다.
마지막으로 실제 사이트를 열어 새 화면을 확인한다. 저장 완료와 서비스 반영 완료 사이에는 생각보다 깊은 계곡이 있다.
6. 아침 보고서에서 봐야 할 숫자
밤새 고친 건수보다 방문자에게 전달된 건수, 복구된 실패 건수, 재발을 막은 건수가 중요하다.
사람은 아이디어를 내고 잔다. AI는 고치고, 막힌 길을 뚫고, 실제 화면까지 확인한다.
그때 듣고 싶은 말은 하나다.
“좋은 아침입니다. 사이트도 제대로 깨어났습니다.”
