AI 에이전트에게 일감을 줄 때는 프롬프트보다 런북이 먼저입니다

프롬프트가 요청이라면 런북은 작업을 다시 실행할 수 있게 만드는 운영 문서입니다.

AI 에이전트에게 일을 맡길 때 처음에는 문장을 길게 쓰게 됩니다.
배경을 설명하고, 조심할 점을 붙이고, 원하는 결과를 말합니다.
그런데 몇 번 반복해 보면 이상한 지점이 보입니다.
프롬프트는 길어졌는데 결과는 안정되지 않습니다.
같은 말을 했는데 어떤 날은 잘하고, 어떤 날은 중요한 순서를 건너뜁니다.

그때 필요한 것은 더 멋진 프롬프트가 아니라 런북입니다.
런북은 “이 일을 어떤 순서로 처리하고, 어디를 확인하고, 무엇을 완료 증거로 볼 것인가”를 적은 실행 문서입니다.
에이전트는 글을 잘 이해하는 도구이지만, 작업의 책임 경계까지 저절로 정해 주지는 않습니다.

먼저 진입점을 고정합니다

좋은 런북은 첫 문장부터 다릅니다.
“이 일을 해줘”가 아니라 “이 파일에서 시작한다”로 출발합니다.
저장소라면 entrypoint 문서, 블로그라면 manifest, 배포라면 runbook, 데이터라면 읽기 전용 쿼리부터 정합니다.
진입점이 흔들리면 에이전트는 눈에 먼저 들어온 파일을 중심으로 세상을 해석합니다.

제가 가장 경계하는 상황은 에이전트가 맞는 말을 하는데 현재 시스템과 맞지 않는 경우입니다.
오래된 문서, 예전 스크립트, 비슷한 이름의 다른 폴더가 있으면 충분히 그럴 수 있습니다.
그래서 런북에는 “여기부터 읽어라”와 함께 “여기는 보조 자료일 뿐이다”도 적어야 합니다.

완료 조건을 문장 밖으로 꺼냅니다

“잘 정리해줘”는 완료 조건이 아닙니다.
“초안 6개, 각 1,200자 이상, 이미지 경로 manifest 연결, dry-run 통과”처럼 세어 볼 수 있어야 합니다.
에이전트가 일을 끝냈다고 말했을 때 사람이 확인할 수 있는 단위가 있어야 합니다.

이 기준이 없으면 대화는 금방 감상문이 됩니다.
결과가 그럴듯하면 넘어가고, 찝찝하면 다시 시킵니다.
런북은 이 감정의 흔들림을 줄입니다.
잘했는지 못했는지를 사람의 기분이 아니라 산출물의 조건으로 판단하게 만듭니다.

완료 조건은 숫자만으로 끝나지 않습니다.
“6개 만들기”보다 “기존 발행 글 제외, 다른 에이전트 주제 제외, 새로 만든 글만 6개”가 더 정확합니다.
에이전트는 숫자를 채우는 데 능숙하지만, 숫자에 들어가면 안 되는 항목까지 알아서 배제하지는 못합니다.
그래서 카운트 기준은 작업 중간에도 계속 보이는 곳에 있어야 합니다.

예외 처리도 작업의 일부입니다

런북에는 정상 경로만 있으면 부족합니다.
세션이 끊기면 어떻게 할지, 이미 올라간 글은 다시 올리지 않을지, 다른 사람이 만든 파일은 건드리지 않을지, 실패한 예약은 어떤 상태로 표시할지까지 있어야 합니다.
에이전트에게 가장 위험한 순간은 막혔을 때가 아니라 막혔는데 계속 진행할 때입니다.

저는 그래서 런북을 “AI에게 일을 시키는 문서”라기보다 “AI가 멈춰야 할 위치를 알려 주는 문서”에 가깝게 봅니다.
멈출 곳이 있는 도구는 다시 시작할 수 있습니다.
멈출 곳이 없는 도구는 그럴듯한 결과를 만들며 엉뚱한 쪽으로 계속 갑니다.

런북은 한 번 쓰고 끝나는 문서가 아닙니다

작업을 하다 보면 처음 정한 기준이 틀릴 때가 있습니다.
그때 대화에서만 바로잡으면 다음 배치에서 같은 실수가 반복됩니다.
기준이 바뀌면 런북이나 tracker 같은 SSOT 문서가 같이 바뀌어야 합니다.
특히 “무엇을 세지 않을 것인가”는 나중에 더 중요해집니다.
제외 기준이 문서에 없으면 오래된 산출물과 새 산출물이 쉽게 섞입니다.

저는 런북을 작업 설명서라기보다 운영 장부에 가깝게 씁니다.
어떤 결정을 했고, 어떤 예외가 생겼고, 어떤 증거를 완료로 인정했는지 남깁니다.
그래야 다음 세션에서 같은 질문을 다시 하지 않습니다.

프롬프트는 요청입니다.
런북은 운영입니다.
둘의 차이를 구분하기 시작하면 에이전트에게 맡길 수 있는 일의 크기가 달라집니다.