AI 에이전트가 하던 SNS 게시 자동화를 프로그램으로 내렸는데, 검토는 버리지 않았습니다

블로그 글을 SNS 에 올리는 일을 개인 비서 에이전트가 맡고 있었습니다. 하루 열 개 시간대마다 AI 가 깨어나 다음 원고를 고르고 올렸습니다. 전환하기로 한 날 아침, 지난 회차 기록에 한 회차가 AI 사용량 한도 초과로 실패해 조용히 빠져 있었습니다.

이 글은 그 일을 프로그램으로 내리면서 그 안에 섞여 있던 판단을 어디로 옮겼는지에 대한 기록입니다. 검토를 없앤 것이 아니라 원고를 쓰는 단계로 올렸습니다.

올리는 일 자체에는 판단이 거의 없었습니다

올리는 일을 쪼개 보면 다음 차례를 고르고, 올리고, 올렸다고 표시하는 세 동작입니다. 정해진 순서를 도는 일이라 AI 가 아니어도 되는데, AI 로 두면 사용량 한도에 걸릴 때 멈춥니다.

이 약점은 품질 문제가 아니라 가용성 문제였습니다. AI 가 원고를 잘못 고른 적은 없었습니다. 정해진 시각에 반드시 돌아야 하는 일인데 그날 한도 상황에 따라 한 회차가 빠졌고, 올라간 회차와 겉으로 구분되지 않았습니다.

같은 시기에 다른 브랜드의 SNS 게시를 돌릴 공용 게시 엔진이 이미 있었습니다. 콘텐츠는 브랜드별로 나누고 올리는 기계만 공용으로 두는 구조라, 블로그 쪽을 하나 더 붙이면 되는 상황이었습니다.

그런데 올리기 직전에는 판단이 있었습니다

에이전트는 올리기 직전에 원고를 한 번 봤습니다. 원문과 어긋나지 않는지, 과장이 섞였는지, 익명화가 됐는지입니다. 이 셋은 규칙 몇 줄로 대신할 수 없습니다. 올리는 동작은 프로그램이 더 잘하는데 이 확인은 못 합니다.

그래서 선택지가 세 개로 갈렸습니다.

C 를 고른 근거는 횟수였습니다. 게시 직전은 매번 검토가 필요한 자리고, 원고를 쓰는 시점은 한 번이면 되는 자리입니다. 올리는 시점의 AI 는 같은 원고에 같은 검토를 열 번 다시 하고 있던 셈입니다.

흐름은 이렇게 갈라졌습니다.

[전]  원고 작성 → (게시 시각) AI: 고르기 + 검토 + 올리기 + 표시
[후]  원고 작성 + 검토 → (게시 시각) 프로그램: 고르기 + 기계 검사 + 올리기 + 표시

프로그램에 남긴 것은 기계가 셀 수 있는 것뿐입니다

게시 시점에 남긴 검사는 다섯 개입니다. 전부 참·거짓으로 끝나는 것들입니다.

본문이 비어 있으면 올리지 않습니다

플랫폼이 정한 글자 수 상한을 넘으면 올리지 않습니다

같은 본문이 이미 올라가 있으면 올리지 않습니다

예정 시각에서 두 시간 넘게 밀린 건은 건너뜁니다

원본을 못 읽으면 아무것도 올리지 않습니다

마지막 항목이 가장 중요합니다. 조회에 실패한 것인지 올릴 것이 정말 없는 것인지 프로그램은 구분하지 못합니다. 구분이 안 되면 멈추는 쪽을 기본으로 둡니다. 읽기 실패를 비어 있다고 보면 그 회차를 조용히 넘기게 됩니다.

고르는 규칙도 두 개 더 뒀습니다. 게시 기록이 있는데 표시가 안 된 원고는 또 올리지 않고 표시만 하고 다시 고르며, 실패 기록이 있는 원고는 건너뜁니다. 같은 기준으로 일일 정리의 본문 생성도 AI 에서 코드로 되돌렸습니다.

올리는 기계가 도메인을 모르게 뒀습니다

공용 엔진은 어느 브랜드의 글을 올리는지 모릅니다. 브랜드마다 설정 파일 하나에 원본 위치, 계정과 토큰 키의 짝, 올리기 전 검사, 알림을 적어 두고 엔진이 그 파일을 읽어 돕니다.

그런데 이번에 붙이는 쪽은 원본이 달랐습니다. 다른 브랜드는 구글시트인데 블로그 쪽은 데이터베이스입니다. 엔진이 데이터베이스를 직접 읽으면 엔진 안에 블로그 사정이 들어옵니다. 그래서 정해진 명령 네 개로만 주고받게 했습니다.

'시간대 목록 보기' — 오늘 올려야 할 시간대를 돌려줍니다

'다음 것 고르기' — 올릴 원고 하나를 돌려줍니다

'올렸다고 표시하기' — 방금 올린 것을 기록합니다

'상태 보기' — 지금 몇 개가 남았는지 돌려줍니다

엔진이 아는 것은 이 네 개뿐입니다. 원본이 시트든 데이터베이스든 이 네 개에 답할 수만 있으면 같은 엔진에 하나씩 더 붙일 수 있습니다. 주고받는 것을 필요한 만큼으로 줄이는 판단은 에이전트 쪽에서도 했습니다.

전환 직후의 중복은 미리 알 수 있는 사고였습니다

전환 시각은 그날 오전이었고, 그때 이미 세 회차는 에이전트가 올려 둔 상태였습니다. 새 프로그램은 그 사실을 모릅니다. 새 쪽 기록이 비어 있으니 지나간 세 시간대를 전부 빈자리로 봅니다.

그대로 켰으면 첫 바퀴에서 같은 원고가 세 번 더 올라갔을 겁니다. 그래서 전환 전에 지나간 시간대의 게시분을 새 쪽 기록에 미리 넣어 그 자리가 채워진 것으로 보이게 했습니다. 중복 게시는 나오지 않았습니다. 새 쪽은 과거를 모른다는 한 가지만 기억하면 어느 전환에서든 같은 처방이 나옵니다.

옛 경로를 지우지 않고 멈춤으로 뒀습니다

옛 에이전트 쪽에는 예약 작업이 세 개 걸려 있었습니다. 정시 회차, 30분 회차, 토큰 갱신입니다. 전환하면서 삭제하지 않고 멈춤 상태로 두고, 되돌리는 명령을 그날 완료 기록에 같이 적었습니다.

프로그램은 모르는 상황을 만나도 규칙에 맞으면 그대로 통과시킵니다. AI 라면 뭔가 이상하다고 멈춰 세울 자리입니다. 그 차이가 어디서 드러날지를 하루 만에 알 수는 없어서, 며칠을 나란히 지켜본 뒤에 지우기로 했습니다.

멈춤으로 둔 작업은 다시 켜는 데 한 줄이면 됩니다. 지워 두고 문제가 생기면 급한 상황에서 다시 만들어야 합니다.

상태 화면이 게시 경로에 끼어들지 않게 했습니다

에이전트를 떼면 '왜 안 올라갔나'를 물어볼 상대가 없어집니다. 그래서 상태 화면을 따로 만들었습니다. 이 화면은 엔진이 회차마다 남기는 요약 파일과 최근 게시 기록만 봅니다. 요약 파일에는 예약 수, 대기 수, 토큰 만료일, '확인 필요' 건이 들어 있습니다.

보기 위한 장치가 올리는 경로에 들어가면 화면 쪽 문제가 게시를 멈추게 합니다. 그래서 화면이 데이터베이스를 직접 보지 않게 했고, 기록 쓰기가 실패해도 게시는 막히지 않습니다.

AI 를 부르지 않으니 토큰 비용도 0 이 됐습니다. 5분마다 도는 예약 작업 하나가 열 개 시간대를 집습니다. 비용보다 큰 변화는 걸릴 한도가 없어져 회차가 빠지는 일이 구조적으로 사라진 쪽입니다.

같은 전환을 검토할 때 보는 것

AI 가 하던 일을 프로그램으로 내리는 판단을 할 때 다음 다섯 개를 봅니다.

그 일 안에서 정해진 순서를 도는 부분과 무엇이 맞는지 보는 부분을 갈라 적었는가

판단에 해당하는 부분을 버리는 것이 아니라 옮길 자리를 정했는가 — 기준은 그 판단을 몇 번 해야 하는가다

게시 시점에 남긴 검사가 전부 참·거짓으로 끝나는 것인가, 애매한 상황에서는 멈추는 쪽이 기본인가

전환 시각 이전에 이미 한 일을 새 쪽 기록에 미리 넣었는가

옛 경로를 삭제하지 않고 멈춤으로 뒀는가, 되돌리는 명령을 기록에 같이 남겼는가

이번 전환에서 가장 버리기 쉬웠던 것이 두 번째였습니다. 프로그램으로 내리는 쪽이 짧고 깔끔해서 그 안에 섞여 있던 확인을 같이 들고 나오게 됩니다.

이 결정이 통하지 않는 자리

올리는 일에 판단이 남아 있는 쪽이면 이 전환이 틀립니다. 플랫폼마다 다르게 다듬거나 반응을 보고 다음 글을 고르는 운영이면 고르는 자리에 사람이 필요합니다. 검토를 앞으로 옮기는 것도 공짜가 아닙니다. 원고 작성이 무거워지고, 거기서 빠뜨리면 게시 직전에 잡아 줄 사람이 없습니다.

전환 비용이 운영 기간보다 클 수도 있습니다. 하루 한 번 올리는 쪽이면 호출 비용이 미미해 프로그램을 쓸 이유가 약합니다. 열 회차였다는 것이 전제입니다. 공용 엔진의 한도도 모릅니다. 쓰는 쪽이 늘면 각자의 예외가 엔진 안으로 들어오는데, 몇 개까지 버티는지는 지금 둘일 때의 기록으로 말할 수 없습니다.

마무리

AI 에이전트를 떼는 결정에서 가장 신경 쓴 것은 무엇을 넘길지가 아니라 무엇을 넘기지 않을지였습니다. 올리는 동작은 프로그램이 더 정확하고 싸지만, 올리기 직전의 확인은 프로그램이 못 합니다. 판단은 없애는 것이 아니라 옮기는 것이고, 기준은 그 판단을 몇 번 해야 하는가입니다.