AI에게 블로그 발행을 맡길 때, 어디까지 맡기고 무엇을 직접 확인해야 할까?
다섯 편의 발행 운영 기록에서 뽑은 위임 판단표. 작업별로 AI에게 줄 입력, 기계로 확인할 증거, 사람이 승인할 조건, 멈출 조건을 나눠 정리한다. 완전 자동화 성공담이 아니라 위임 범위를 정하는 기준에 대한 글이다.
AI 도움으로 개인 블로그나 팀 기술 블로그를 운영하려고 한다고 하자. 초안은 AI가 쓰고, 링크는 스크립트가 검사하고, 발행은 예약하고, 소셜 공유까지 자동으로 이어 붙일 수 있다면 — 어디까지 맡기고 어디서부터는 직접 확인해야 할까? 이 글은 이 블로그의 실제 발행 운영 기록에서 뽑은 판단 기준, 위임 판단표를 작업 단위로 정리한다. 이 표 하나에서 AI에게 줄 입력, 기계로 확인할 증거, 사람이 승인할 조건, 멈출 조건을 함께 볼 수 있게 하는 것이 이 글의 목표이자 기존 글들과의 차이점이다.
기대: 파이프라인을 만들면 발행이 알아서 돌아갈 것
기대는 단순했다. 초안 → 검사 → 발행 → 공유로 이어지는 흐름을 한 번 조립해 두면, 사람은 마지막에 승인만 하면 된다. 각 단계의 도구가 알아서 결과를 내고, 문제가 있으면 파이프라인이 알려줄 것이라 생각했다.
설명용 개념 일러스트이며 기존 발행 글의 그림을 재사용했다. 이번 운영의 측정 화면이 아니다. 그림과 달리 실제 운영에는 사람의 승인·확인 지점이 있고, 이 글은 그 지점을 정하는 방법을 다룬다.
실제 관측: 파이프라인이 멈추거나 틀렸던 세 기록
운영 기록이 쌓이면서 기대와 실제가 갈린 지점이 보였다. 세 사례만 추린다. 각 사례의 상세 조건과 날짜는 링크한 공개 글에 있고, 여기서는 위임 범위를 정하는 데 필요한 결론만 쓴다.
1. 원고가 맞아도 화면이 틀릴 수 있다. 숫자 범위 표기(3~4개월)가 렌더러의 취소선 문법과 충돌해 공개 페이지 본문에만 가로줄이 생겼다. 표기 관행과 빌드 설정의 충돌이며, AI가 글을 썼기 때문에 생겼다는 근거는 없다. 위임 관점의 교훈은 이것이다: 원고 검토만으로는 ‘공개 확인’ 작업이 끝나지 않는다. 렌더링 결과(HTML 태그 개수)처럼 공개 화면 수준의 기계 증거가 따로 필요하다. → 블로그 글에 갑자기 취소선이 생겼다면
2. 예약됨은 준비됨이 아니다. 2026-09-18 07:00(KST) 예약 슬롯이 지나갔는데 블로그에도 소셜에도 글이 올라오지 않았다. 스케줄러 고장이 아니라 그 시각에 발행할 수 있는 완성본이 없었던 준비 실패였다. ‘예약됨 / 준비됨 / 공개됨 / 공유됨’은 각기 다른 상태이고, 상태마다 닫는 증거가 달라야 한다. → 블로그 자동 발행을 예약했는데 글이 안 올라왔다
3. 검사 실패는 내용 부재가 아니다. 2026-09-24 자동 링크 검사가 한 URL에서 HTTP 403을 받았는데, 같은 주소를 브라우저로 열면 기사가 표시됐다. 403은 ‘이 조건에서 이 요청이 거부되었다’는 기록이지 페이지가 사라졌다는 증거가 아니다. 자동 검사 결과만으로 ‘출처 삭제’까지 위임했다면 살아 있는 출처를 지울 뻔했다. → 자동 검사에서 오류가 난 링크, 바로 지워도 될까?
바꾼 판단: 위임의 단위는 단계가 아니라 ‘작업 + 증거’다
세 사례는 같은 지점을 가리킨다. 질문은 “AI가 어디까지 할 수 있는가”가 아니라 “각 작업을 어떤 증거가 닫고, 그 증거의 해석 기준을 누가 정하는가” 다. AI는 증거를 만드는 작업(검사 실행, 대조, 기록)을 대체로 그대로 넘겨받을 수 있다. 반면 증거의 해석 — 403을 삭제로 볼 것인지, 슬롯 경과를 실패로 볼 것인지 — 은 기준의 문제이고, 기준은 사람이 미리 정해 두어야 한다.
그래서 위임의 선을 ‘단계’가 아니라 ‘작업’에 그었다. 작업마다 네 가지를 정한다: AI에게 줄 입력, 기계로 확인할 증거, 사람이 승인할 조건, 멈출 조건.
한 가지는 분명히 해 둔다. 이 블로그의 발행은 사람이 매 게시물을 개별 승인하는 구조가 아니다. 사전 승인된 예약 게시와, 예외가 생겼을 때의 확인·복구로 굴러간다. 아래 판단표의 ‘승인 조건’은 매 게시 확인이 아니라 어떤 예외가 사람의 판단으로 올라오는가를 뜻한다.
독자 적용: 위임 판단표
참고: 아래 표는 복사해서 쓰는 설명용 양식이다. 작업 구분과 증거 항목은 이 블로그의 운영 기록에서 정리했지만, 독자의 상황에 맞게 고쳐 써야 한다. 표 안의 횟수·조건 수치는 실측 성과가 아니라 예시 설정이다. 괄호 안의 검사 예시는 링크한 공개 글에 기록된 실측 사례다.
| 작업 | AI에게 줄 입력 | 기계로 확인할 증거 | 사람이 승인할 조건 | 멈출 조건 |
|---|---|---|---|---|
| 초안 작성 | 주제·독자 한 문장, 사용할 수 있는 출처 목록(직접 URL), 금지 주장 목록 | 분량·금지어·표 구조 검사, 출처 URL 존재 여부 | 금지 목록 밖의 주장이나 URL 없는 출처가 등장할 때 | 핵심 주장에 직접 URL을 찾을 수 없을 때 |
| 사실 확인 | 초안의 주장 목록과 출처 직접 URL | URL 접근성(상태 코드 + 본문 바이트 수 — 2026-09-24 기록에서 같은 주소가 클라이언트에 따라 403/17바이트와 200/34,459바이트로 갈렸다), 주장-출처 대응 기록 | 접근성과 본문 내용이 갈리는 결과(예: 403)의 해석 | 같은 주장의 대조를 반복해도 결론이 갈릴 때 — 삭제 대신 ‘확인 필요’로 기록 |
| 이미지 | 본문 맥락, 기존 스타일 참조 | 파일 크기·해시, 대체 텍스트 존재 (예: PNG 4.95MB→WebP 360KB 변환 실측 기록) | 그림의 사실 요소나 화풍을 바꿔야 할 때 | 그림 내용을 본문과 일치시킬 수 없을 때 |
| 공개 확인 | 발행 체크리스트(공개 URL, 본문·이미지 표시, 발행 시각) | 공개 URL의 정상 응답, 표시 결과와 원고의 일치 (예: 공개 HTML에서 의도치 않은 <del> 태그 개수 세기 — 취소선 수정 후 9개→0개 기록) | 공개 화면이 원고와 다를 때 | 공개 여부를 확정할 수 없을 때 — 재시도하지 않고 상태만 기록 |
| 소셜 공유 | 공개된 URL, 플랫폼별 분량 제한 | 기존 게시 중복 여부, 게시 접수 기록(아이디·시각) | 결과가 불확실한 공유를 다시 보낼지 판단 | 접수 기록이 없거나 같은 URL의 게시가 이미 있을 때 |
한 가지 보충: 링크가 ‘열리는가’와 목록이 ‘완전한가’도 별개 작업이다. 이 블로그에서는 링크가 살아 있는데도 추천 목록에서 글이 사라진 경우가 있었다. 공개 확인의 기계 증거에는 URL 응답뿐 아니라 글이 노출되어야 하는 목록의 완전성 확인이 들어간다. → 글은 있는데 독자가 찾을 수 없다면: 블로그 추천 목록 점검하기
검사의 세 성격을 표현한 설명용 일러스트이며 기존 발행 글의 그림을 재사용했다. 측정 화면이 아니다. 왼쪽처럼 규칙이 명확한 검사는 기계 증거로 닫기 쉽고, 가운데·오른쪽처럼 해석이 필요한 확인일수록 사람의 승인 조건을 먼저 정해야 한다.
표를 읽는 방법: 왼쪽 두 열은 AI에게 넘기는 것, 가운데 열은 기계가 닫는 것, 오른쪽 두 열은 사람에게 남는 것이다. 가장 중요한 열은 ‘멈출 조건’ 이다. 작업마다 멈출 조건을 먼저 써 보면, 나머지 열에서 자동화해도 안전한 범위가 저절로 좁혀진다. 예를 들어 ‘결과가 불확실할 때 재시도하지 않는다’를 소셜 공유의 멈출 조건으로 못 박아 두면, 공유 자동화의 안전 범위는 ‘중복 여부 확인 후 첫 게시’까지만 남는다.
예시 입력 요청 양식
참고: 아래는 설명용 입력 요청 양식이다. 실제 작업 명령이 아니며, 항목은 예시다.
주제와 독자: (한 문장)
이번 글에서 하면 안 되는 주장: (예: 완전 무인 운영, 측정 없는 시간 절감)
사용 가능 출처: (직접 URL 목록만)
만들어야 할 증거: (상태 코드, 본문 바이트 수, 해시 등)
결과가 불확실할 때 기록 형식: (시각·조건·결과·판단 한 줄)승인 / 보류 판단
| 관측된 상태 | 판단 |
|---|---|
| 기계 증거가 전부 있고 체크리스트와 일치 | 승인 — 사전 승인된 범위에서 다음 작업 진행 |
| 증거는 있는데 해석이 갈림 (예: 403, 시각 불일치) | 보류 — 조건과 결과를 기록한 뒤 사람이 결정 |
| 증거 자체가 없음 (응답 없음, 접수 기록 없음) | 보류 — 재시도하지 않고 공개 상태부터 확인 |
한계
- 이 글의 근거는 공개가 완료된 5건의 게시 운영이지, 5회의 완전 자동 성공 사이클이 아니다. 발행·검증 과정에는 사람의 승인과 수동 복구가 포함됐고, 대조군이나 시간·비용 절감 측정도 없다.
- 세 사례는 특정 렌더러·빌드·검사 조건을 가진 한 사이트의 과거 관측이다. 모든 도구에 일반화할 수 없으며, 조건별 상세는 각 공개 글에 남겼다.
- 위임 판단표의 항목과 수치는 예시 양식이다. 표가 실제로 작동하는지는 각자 운영에서 ‘보류 → 사람 확인’ 건수를 기록해야 알 수 있다. 이 글은 그 실측값을 제시하지 않는다.
확인한 출처 / 근거
- 블로그 이미지 용량 줄이기: 같은 그림을 4.95MB에서 360KB로 (발행 2026-09-16, Threads 게시) — 발행 운영 기록의 범위 근거 및 판단표 ‘이미지’ 행의 변환 실측 예시(4.95MB→360KB는 이미지 3장 합계 기준).
- 블로그 글에 갑자기 취소선이 생겼다면: 숫자 범위 표기부터 확인하세요 (발행 2026-09-20, Threads 게시) — 사례 1(원고-공개 화면 불일치, 렌더러 설정 원인)과 판단표 ‘공개 확인’ 행의
<del>9개→0개 실측 예시의 근거. - 블로그 자동 발행을 예약했는데 글이 안 올라왔다: 무엇을 확인해야 할까 (발행 2026-09-23, Threads 게시) — 사례 2(2026-09-18 슬롯 미발행, 준비 실패)의 근거.
- 자동 검사에서 오류가 난 링크, 바로 지워도 될까? (발행 2026-09-25, Threads 게시) — 사례 3(2026-09-24 자동 검사 403과 브라우저 관측 불일치)과 판단표 ‘사실 확인’ 행의 403/17바이트 vs 200/34,459바이트 실측 예시의 근거.
- 글은 있는데 독자가 찾을 수 없다면: 블로그 추천 목록 점검하기 (발행 2026-09-29, Threads 게시) — 링크 접속 검사와 목록 완전성 검사가 서로 다른 작업이라는 구분의 근거.
- 참고: 멀티에이전트 작업 인계(A2A) 기록과 발행 접수 영수증은 운영자가 확인한 내부 운영 기록이며 공개 URL이 없어 링크를 만들지 않는다. 공개 결과물은 위 5건의 게시다.
- 참고: 본문 그림 2장은 기존 발행 글의 개념 일러스트를 재사용한 것이며, 이번 운영의 측정 화면이 아니다.
- 참고: 판단표에 추가한 검사 예시 수치(403/17바이트·200/34,459바이트,
<del>9개→0개, 4.95MB→360KB)는 모두 위 공개 글에 기록된 실측값이며, 이 글에서 새로 측정한 값이 아니다.