AI WORK DELEGATION

지침은 네 번 다 뚫렸고 코드는 네 번 다 막았다 — AI 자동화에 게이트가 필요한 이유

junetapa 2026. 9. 3 약 10분

AI 에이전트에게 채널 운영을 맡기고 있다. 오늘 그 자동화가 하루에 네 번 어긋났고, 한 건은 내가 직접 지우고 다시 올려야 했다. 그런데 같은 날 스스로 잡아낸 것도 네 건이었다. 여덟 건을 나란히 놓고 보니 둘을 가르는 선이 하나 있었다.

이 글의 성격

제품 리뷰가 아니다. 여러 사이트에 글을 올리는 자동화를 매일 돌리면서 실제로 멈춰 선 자리를 기록한 것이다. 특정 도구가 좋다·나쁘다를 말하지 않는다. 대신 «이 벽은 어느 층에 있는 문제인가»를 갈라 둔다. 층을 알면 무엇을 바꿔야 풀리는지가 정해진다.

하루에 사고가 네 번 났다

AI 에이전트에게 채널 운영을 맡기고 있다. 글을 쓰고, 이미지를 만들고, 여러 SNS에 올리는 일이다. 오늘은 그 자동화가 하루에 네 번 어긋났다.

순서대로 적으면 이렇다. 페이스북에서는 개인 계정에 올릴 글이 페이지로 나갔다. 같은 페이스북에서 게시 버튼을 누르려던 클릭이 밀려 유료 광고 토글이 켜졌다. 텀블러에는 존재하지 않는 주소 네 개가 링크로 들어갈 뻔했다. 그리고 인스타그램에는 보정하지 않은 원본 사진이, 글도 없이 올라갔다.

네 번째 것은 내가 직접 지우고 다시 올려야 했다. 몸이 안 좋아 누워 있던 날이라 더 그랬다.

그런데 같은 날, 어긋난 것을 스스로 잡아낸 경우도 네 번 있었다. 이 글은 그 여덟 건을 나란히 놓고 본 기록이다. 둘을 갈라 보니 규칙이 하나 나왔다.

잡힌 쪽 — 네 건 모두 «코드»가 막았다

먼저 사고가 되기 전에 걸린 것들이다.

하나. 블로그 글을 발행하는데 검사 스크립트가 항목 하나에서 실패를 냈다. 「공용 스타일시트 참조가 없다」는 것이었다. 화면으로 열어 보면 글은 멀쩡해 보였다. 파고 보니 그 글이 참조하던 통합 스타일시트가 서버에 아예 없었다. 그리고 그 글은 전날 글을 틀로 복제한 것이어서, 전날 글도 하루 내내 같은 상태로 서 있었다.

둘. 기존 글을 복제해 새 글을 만들 때 「원본 주제어가 남아 있는지」를 기계로 세는 검사가 있다. 그게 공유용 메타 태그 두 곳에 옛 제목이 남은 것을 잡았다. 사람 눈으로는 절대 안 보이는 자리다.

셋. 텀블러에 올릴 링크 네 개를 실제로 열어 보는 검증이 있다. 그게 네 개 전부 존재하지 않는 주소라는 것을 잡았다. 주소를 규칙에서 추측해 만들었는데 실제와 달랐던 것이다.

넷. SNS에 올릴 원고를 파일로 먼저 만들고, 화면에 넣은 뒤 글자 수를 파일과 대조하는 절차가 있다. 그게 문단 두 개가 통째로 빠진 것을 잡았다. 490자 근처라 눈으로는 못 봤을 차이다.

네 건에 공통점이 있다. 어느 것도 「조심하자」로 잡힌 게 아니다. 스크립트가 값을 읽어 비교했고, 어긋나면 다음 단계로 못 넘어가게 막았다. 스타일시트 건은 특히 그렇다. 화면으로는 멀쩡해 보였기 때문에, 검사가 없었다면 그 글도 다음 글도 계속 그 상태로 쌓였을 것이다.

그리고 하나가 잡히면서 이미 나간 어제 글까지 딸려 나왔다. 검사는 오늘 것만 봤는데, 원인을 따라가니 전날 글이 나왔다. 게이트의 값은 그 자리에서 막는 것에만 있는 게 아니라, 같은 원인으로 이미 벌어진 일을 찾아 주는 데도 있다.

뚫린 쪽 — 네 건 모두 «문장»으로만 적혀 있었다

이제 사고가 된 쪽이다. 공통점이 있다.

네 건 모두 규칙이 이미 문서에 적혀 있었다. 없어서 못 지킨 게 아니다.

인스타그램 계정 운영 문서에는 「사진은 AI로 변환해서 올린다」가 적혀 있다. 그 문장을 읽고도 시간을 아끼려고 그 단계를 건너뛰었다.

「화면이 뒤에 있으면 글이 빈 채로 올라간다」도 이미 적혀 있었다. 그런데 글자 수 표시가 정상으로 보이자 「이번엔 되겠지」 하고 밀어붙였다. 두 번 다 빈 채로 올라갔다.

「페이스북은 올리기 전에 계정을 확인한다」도 적혀 있었다. 확인은 했는데 확인하는 방법이 틀렸다. 작성창에 뜬 이름을 봤는데, 그 이름은 개인 계정과 페이지가 거의 같았다.

「되돌리기 어려운 버튼은 좌표로 누르지 않는다」도 적혀 있었다. 그런데 좌표를 재고 누르는 사이에 화면이 움직여 엉뚱한 토글이 눌렸다. 하필 유료 광고였다.

이 네 건을 다시 읽어 보면 이상한 점이 있다. 규칙을 몰랐다면 차라리 이해가 된다. 그런데 넷 다 알고 있었다. 심지어 그 문서를 그날 열어 봤던 것도 있다.

그러면 왜 안 지켜졌을까. 넷을 놓고 보면 상황이 비슷하다. 시간이 밀려 있었고, 앞 단계에서 이미 한 번 막혔던 참이었다. 그 상태에서 「이건 건너뛰어도 되겠지」 하는 판단이 들어갔다. 그리고 그 판단은 매번 틀렸다.

특히 두 번째 것 — 글이 빈 채로 올라간 건 — 이 성격을 잘 보여 준다. 화면에는 글자 수가 정상으로 표시되고 있었다. 계기가 초록불이었던 것이다. 그런데 그 계기는 「입력창에 글자가 몇 개 있는가」를 셀 뿐, 「그 값이 실제로 제출되는가」는 보지 않는다. 규칙에는 그 차이가 적혀 있었는데, 초록불을 보는 순간 그 문장이 지워졌다.

규칙 하나 — 지켜지는 것은 «막는 것»뿐이다

여덟 건을 나란히 놓으면 규칙이 하나 나온다.

코드로 막은 것은 네 건 모두 잡혔고, 문장으로 적은 것은 네 건 모두 뚫렸다.

이게 왜 중요하냐면, 자동화를 개선하는 방향이 여기서 갈리기 때문이다. 사고가 나면 보통 「지침을 더 자세히 쓰자」로 간다. 그런데 오늘 결과를 보면 그 방향은 효과가 없다. 지침은 이미 자세했고, 정확했고, 그 자리에 있었다.

차이는 지침의 품질이 아니라 강제성에 있었다. 검사 스크립트는 「하세요」라고 말하지 않는다. 조건이 안 맞으면 다음 단계로 못 넘어가게 한다. 문서는 그렇게 못 한다. 읽는 쪽이 급하면 건너뛸 수 있고, 실제로 그렇게 됐다.

사람도 같은 방식으로 실수한다. 「확인하세요」라고 적힌 절차는 바쁠 때 건너뛰지만, 확인 없이는 버튼이 안 눌리는 화면은 건너뛸 수가 없다. 다른 점은 AI는 이 경향이 더 강하고, 더 빠르게 여러 번 어긋난다는 것이다. 하루에 네 번이 그래서 가능했다.

한 가지 더 있다. 문장으로 적힌 규칙은 늘어날수록 약해진다. 지침이 스무 줄이면 스무 줄 다 지킬 것 같지만, 실제로는 그중 어느 것을 건너뛸지 고르게 된다. 반면 게이트는 늘어날수록 강해진다. 하나가 막으면 그 자리에서 멈추기 때문이다.

그래서 오늘 이후로는 사고가 났을 때 질문을 바꾸기로 했다. 「지침에 뭘 더 쓸까」가 아니라 「이걸 막는 검사를 어디에 넣을 수 있나」로 묻는다. 막을 수 없는 종류라면 그때는 지침으로 남기되, 최소한 그것이 「지켜지지 않을 수도 있는 항목」이라는 것을 알고 남긴다.

하루 여덟 건을 코드로 막은 것과 문장으로 적은 것으로 나눈 비교 도해
지침의 «품질»이 아니라 «강제성»이 결과를 갈랐다.

그래서 문장 하나를 코드로 옮겼다

오늘 뚫린 넷 중 하나를 바로 옮겼다. 인스타그램 카드를 만드는 도구에 원본 사진 검사를 넣었다.

배경 이미지의 파일명이 휴대폰 원본 형식이거나, 경로에 원본 사진 폴더가 들어 있으면 도구가 실행을 거부한다. 거부하면서 무엇을 해야 하는지를 그 자리에 출력한다 — 어떤 참조 이미지를 써야 하는지, 프롬프트에 무엇을 넣어야 하는지까지.

시험은 양쪽으로 했다. 원본 파일을 넣으면 종료 코드 3으로 거부하고, 변환한 이미지를 넣으면 정상적으로 카드가 만들어진다. 한쪽만 시험하면 검사기가 죽어 있어도 모른다. 이제 원본을 올리려 해도 도구가 막는다.

덧붙여, 거부 메시지에 «다음에 할 일»을 넣은 것도 의도한 것이다. 막기만 하면 다시 문서를 찾아야 하는데, 그 순간이 또 건너뛰기 쉬운 자리다. 막는 자리에서 바로 알려 주면 우회할 이유가 줄어든다.

중요한 건 이 검사가 「좋은 판단」을 요구하지 않는다는 점이다. 파일명만 본다. 판단이 필요 없는 검사라서 바쁠 때도 똑같이 작동한다. 좋은 게이트는 대개 이렇게 단순하다.

무엇을 코드로 옮길지 고르는 법

모든 지침을 코드로 만들 수는 없다. 오늘 여덟 건을 보며 정리한 기준은 이렇다.

되돌릴 수 없는 것이 먼저다. 잘못 올라간 글은 지울 수 있지만 이미 본 사람은 되돌릴 수 없다. 켜진 광고는 돈이 나간다. 반대로 링크가 틀린 것은 고치면 그만이다. 그래서 게시·결제·삭제 앞에 게이트를 둔다.

「확인했나」로 끝나는 지침은 특히 위험하다. 확인은 건너뛰어도 티가 안 나기 때문이다. 오늘 뚫린 넷 중 셋이 확인 항목이었다. 확인은 문장이 아니라 값을 읽어 비교하는 코드여야 한다.

판단이 필요 없는 것부터 옮긴다. 파일명, 글자 수, 상태 코드, 개수 같은 것들이다. 「이 사진이 어울리는가」는 코드로 못 옮기지만 「이 파일이 원본인가」는 옮길 수 있다.

대조군을 같이 넣는다. 오늘 링크 검증이 잡아낸 것도 대조군 덕이었다. 없는 주소에도 정상 응답을 주는 서버가 있어서, 응답 코드만 보면 다 통과한다. 그래서 「반드시 실패해야 하는 입력」을 같이 넣어 검사기가 살아 있는지부터 확인한다.

어떤 지침을 코드로 옮길지 고르는 네 가지 기준 도해
모든 지침을 게이트로 만들 수는 없다 — 순서가 있다.

남는 생각

AI에게 일을 맡길 때 흔히 기대하는 것은 「알아서 잘하는 것」이다. 오늘 결과는 그 기대를 조금 수정하게 한다.

잘한 것도 많았다. 하루에 글 세 편이 나갔고, 여러 채널에 전파됐고, 잡아낸 것도 네 건이다. 문제는 잘하는 것과 빠뜨리지 않는 것이 다른 능력이라는 점이다. 그리고 빠뜨리지 않는 쪽은 지침으로 채워지지 않았다.

그래서 지금은 이렇게 생각한다. 자동화의 품질은 지침의 두께가 아니라 게이트의 개수로 정해진다. 오늘 여덟 건이 그 말을 정확히 반으로 갈라 보여 줬다.

글을 쓰는 지금도 몸이 편하지는 않다. 사고 후유증으로 누워 있는 날에 자동화까지 손이 가야 했던 것은 계획에 없던 일이다. 그런데 그 덕에 한 가지는 분명해졌다. 내가 붙어서 지켜봐야만 굴러가는 자동화는 자동화가 아니다. 오늘 잡힌 네 건은 내가 안 봐도 잡혔고, 뚫린 네 건은 내가 봐야만 막을 수 있는 것들이었다.

내일도 같은 자동화를 돌릴 것이다. 다만 문장 하나가 코드 한 줄이 됐으니, 적어도 그 하나는 다시 나지 않는다. 나머지 셋도 같은 자리로 옮길 생각이다.

덧붙이면, 오늘 잡힌 네 건도 처음부터 게이트였던 것은 아니다. 대부분 한 번 사고가 난 뒤에 만들어진 것이다. 스타일시트 검사도, 원본 주제어 검사도, 링크 검증도 그렇다. 그러니까 오늘 뚫린 네 건도 같은 경로를 밟는 중이라고 보면 된다. 하나는 이미 코드가 됐고, 나머지 셋이 남았다.

자주 묻는 것

지침을 더 자세히 쓰면 나아지지 않나요?

이 사례에서는 아니었습니다. 뚫린 네 건 모두 지침이 이미 있었고, 내용도 정확했습니다. 차이는 품질이 아니라 강제성이었습니다. 문서는 「하세요」라고 말할 수 있을 뿐, 안 했을 때 멈추게 하지는 못합니다.

모든 지침을 코드로 만들어야 하나요?

그럴 수도 없고 그럴 필요도 없습니다. 되돌릴 수 없는 동작(게시·결제·삭제) 앞부터, 그리고 판단이 필요 없는 검사(파일명·글자 수·상태 코드·개수)부터 옮기는 편이 효율이 좋습니다. 「이 사진이 어울리는가」 같은 것은 코드로 옮길 수 없습니다.

「확인했나」 항목이 왜 특히 위험한가요?

확인은 건너뛰어도 겉으로 티가 안 나기 때문입니다. 결과물은 똑같이 나오고, 문제는 나중에 드러납니다. 그래서 확인은 문장이 아니라 값을 읽어 비교하는 코드여야 합니다.

검사가 통과했는데도 문제가 있을 수 있나요?

있습니다. 검사기 자체가 죽어 있으면 「문제 0건」이 나옵니다. 그래서 반드시 실패해야 하는 입력을 같이 넣어 검사기가 살아 있는지부터 확인합니다. 실제로 없는 주소에도 정상 응답을 주는 서버가 있어서, 대조군이 없었다면 그냥 통과했을 건이 있었습니다.

AI 자동화를 계속 쓸 만한가요?

같은 날 잘 돌아간 일이 훨씬 많았습니다. 글 세 편이 나갔고 여러 채널에 전파됐습니다. 다만 「잘하는 것」과 「빠뜨리지 않는 것」은 다른 능력이고, 후자는 지침이 아니라 게이트로 채워야 한다는 점을 감안하고 쓰는 것이 낫습니다.

이 글은 실제로 운영 중인 개인 채널 자동화에서 2026년 9월 3일 하루에 겪은 것을 정리한 기록이다. 여기 적은 여덟 건은 그날 실제로 일어난 일이고, 수치와 순서는 작업 로그에서 옮겼다. 특정 도구나 서비스의 성능을 평가하려는 글이 아니며, 화면 구성과 동작은 서비스 개편에 따라 달라질 수 있다.
AI자동화AI에이전트게이트설계검증설계자동화실패브라우저자동화파이프라인회고
junetapa
junetapa
AI 도구를 직접 굴려 보고 남은 기록을 정리한다.
Twitter Facebook URL 복사