AI 자동 작업이 "파일에 접근할 수 없습니다"로 끝날 때 지시서와 받는 쪽에서 고칠 것

블로그 글 초안을 AI가 정해진 시각에 쓰게 맡겨 두었습니다. 2026년 7월 27일 07:00에 작업은 정확히 돌았는데 글이 올라오지 않았습니다. 남아 있던 초안을 열어 보니 AI는 글 대신 “해당 파일에 접근할 수가 없습니다. 이 세션의 샌드박스는 작업 디렉토리로 제한돼 있어서…”라고 적어 두었습니다. 틀린 말도 지어낸 말도 없었고, 뒷단이 그 답을 형식 오류로만 보고 버린 것이었습니다.

고친 방법은 두 가지입니다. 지시서에 참고 자료를 경로 대신 내용으로 넣고, AI가 못 할 때 어떤 형식으로 답할지까지 정해 둡니다. 그리고 형식이 어긋난 결과는 버리기 전에 한 번 읽습니다. 아래는 그때 로그와 실제로 바꾼 지시서 문구입니다.

AI 작업이 결과 대신 설명문을 돌려준 실제 로그

서버 로그에는 이렇게 남아 있었습니다.

2026-07-27T07:03:08 WARN ContentLlmJobResultHandler :
블로그 발행 실패. entryId=blog:10,
reason=Blog publish failed: frontmatter(---) 로 시작하지 않는 문서입니다
saved=/data/content/blog-drafts/blog_10.md

블로그 글 파일은 첫 줄이 ---(frontmatter)로 시작해야 발행 스크립트가 받습니다. AI가 돌려준 문서는 “왜 못 했는지”를 설명하는 문장으로 시작했으니 첫 글자에서 거부됐습니다.

같은 시기 실패로 찍힌 건을 모아 보니 세 건이었고, 원인은 두 종류였습니다.

작업	결과	원인
blog:10	글 대신 설명문 → 거부	지시서가 AI가 못 읽는 파일을 참조
blog:7	본문 앞에 한 줄을 붙임 → 거부	같은 원인 + 서두 문장
blog:5	실제로는 발행됐는데 상태만 실패	지시서와 무관(발행 뒤 단계)

원인은 지시서 한 줄이었습니다

지시서에는 “새로 쓰지 말고 다른 저장소에 있는 이 파일 본문을 그대로 사용하라”는 줄이 있었습니다. 그런데 AI 작업은 작업 폴더(~/llm-worker) 안에서만 파일을 읽을 수 있게 막혀 있어서, 지시서가 AI가 볼 수 없는 곳을 가리킨 셈이었습니다.

AI는 그 사실을 그대로 답했는데, 뒷단은 완성된 글만 기다렸고 글이 아니면 전부 “형식 오류”로 처리했습니다.

절반만 쓰고 한 줄 붙인 경우가 더 찾기 어렵습니다

blog:7은 조금 달랐습니다. AI는 본문을 쓰긴 썼는데 맨 앞에 “원작 파일이 이 워킹 디렉토리에 없어…”로 시작하는 한 줄을 붙였습니다. 원본을 못 본 상태에서 아는 만큼 채운 글이라는 뜻입니다.

이번에는 그 한 줄 때문에 첫 글자가 ---가 아니어서 걸렸지만, 그 줄이 없었다면 그럴듯한 글이 그대로 올라갔을 겁니다. 전부 거부된 경우보다 이쪽이 더 늦게 발견됩니다. 결과물이 멀쩡해 보이니 읽어 보기 전에는 모릅니다.

알림은 왔는데 왜 놓쳤나

이 실패가 조용했던 건 아닙니다. 실패하면 초안을 따로 보존하고, 텔레그램으로 알림을 보내고, 상태를 “실패”로 바꾸는 부분은 설계대로 동작했습니다. 스케줄러도 07:00:04에 작업을 정확히 올렸습니다.

실패 사유로 남은 건 “frontmatter(---)로 시작하지 않는 문서”라는 형식 이유였고, AI가 적어 둔 이유는 보존된 초안 파일을 열어야 보였습니다. 열어 보니 파이프라인 버그가 아니라 지시서 결함이었습니다.

AI에 작업을 맡길 때 바꾼 네 가지

개발이 아니어도 AI에 일을 맡길 때 그대로 쓸 수 있는 것들입니다.

1. 참고할 내용은 위치 대신 본문에 붙여 넣습니다

“지난번 그 메일 참고해서”가 아니라 그 메일 내용을 지시서에 그대로 넣습니다. 사람이라면 찾아보겠지만 AI는 닿을 수 있는 자리가 정해져 있습니다. 붙여 넣기에 너무 큰 자료라면 그 작업은 이런 식으로 맡기지 않는 편이 낫습니다.

2. 원하는 형식을 첫 글자까지 정합니다

“잘 정리해 줘”가 아니라 “첫 줄은 제목, 그다음 세 문단, 마지막에 한 줄 요약”처럼 씁니다. 형식이 정해져 있어야 어긋났을 때 바로 보입니다. 실패 직후 큐에 남아 있던 지시서 세 건은 이 문구를 넣어 다시 썼습니다.

[출력 규칙 · 필수] 응답의 첫 글자는 반드시 --- 로 시작한다.
설명·서두·사과·메모 문장을 앞에 붙이면 발행이 실패한다.
[자료 규칙] 외부 레포·파일 접근 불가. 메모에 적힌 사실만 사용.

3. 못 할 때 어떻게 답할지도 정해 줍니다

제가 빠뜨렸던 부분입니다. 예를 들어 “확인할 수 없으면 지어내지 말고 맨 앞에 ‘확인 불가’라고만 적어 주세요”처럼 씁니다. 못 한다는 답에도 정해진 모양이 있어야 뒷단이 그걸 실패 사유로 받아 줄 수 있습니다. 모양이 없으면 그냥 형식 오류로 섞여 버려집니다.

4. 형식이 어긋난 결과는 버리기 전에 한 번 읽습니다

이번에는 실패한 초안이 보존돼 있어서 열어 볼 수 있었고, 답은 거기 있었습니다. 형식이 틀렸다고 내용까지 틀린 건 아닙니다. 자동으로 돌리는 작업이라면 실패 결과를 지우지 않고 남겨 두는지부터 확인합니다.

결과를 받는 쪽에서 바꾼 세 가지

지시서만 고치면 다음에 같은 실수를 다시 할 수 있어서, 받는 쪽도 손봤습니다.

• AI에 주는 기본 안내문에 “첫 글자는 ---”, “앞에 설명 붙이지 말 것”, “외부 저장소·파일은 못 읽으니 메모 내용만 쓸 것” 세 문구를 넣었습니다.
• 결과 앞에 --- 이전 텍스트가 붙어 오면 바로 실패시키지 않고 잘라낸 뒤 다시 검사합니다. 잘라낸 일은 경고 로그로 남깁니다.
• 실패 알림에 발행 스크립트의 종료 코드를 같이 붙였습니다. 알림만 보고 스크립트에서 난 문제인지, 그 뒤 기록 단계에서 난 문제인지 가릴 수 있게 하려는 것입니다.

두 번째 항목은 주의할 점이 있습니다. 잘라낸 한 줄이 blog:7처럼 “원본이 없어서 아는 만큼 썼다”는 내용이라면 글은 통과하니까, 그 경고 로그는 꼭 봐야 합니다.

지시서로는 못 막는 것

blog:5는 글이 정상으로 올라갔는데 상태만 “실패”로 찍혔습니다. 발행이 끝난 뒤 기록하는 단계에서 생긴 일이라 지시서를 아무리 고쳐도 막을 수 없었습니다. 그 날짜 로그도 컨테이너를 다시 만들면서 사라져 바로 재현하지 못했고, 나중에 발행이 성공한 뒤의 오류는 실패로 표시하지 않도록 따로 고쳤습니다.

지시서를 볼 때는 두 가지를 물어봅니다. 이 문서 하나만 들고 아무 사정도 모르는 사람이 결과를 만들 수 있는가. 만들 수 없을 때 그 사람이 어디에 대고 그 말을 할 수 있는가. 두 번째 질문에 답이 없으면 “안 된다”는 정확한 답도 실패로 처리됩니다.

지시서를 자기완결로 쓰는 쪽은 AI에 작업을 시킬 때 지시서를 자기완결로 쓰는 법에, 실패가 아무 소리 없이 지나가는 경우는 조용한 실패가 제일 비싸다에 따로 적었습니다.