AI 위임 루프: 에이전트 대신 매뉴얼으로 일 넘기기

에이전트를 계속 만들지 말고 일 하나에 매뉴얼 하나를 만들어라

일마다 에이전트를 하나씩 새로 만드는 방식은 그만두는 게 낫다. 대신 일 하나에 매뉴얼 하나를 만들고, 세팅하는 네 개의 프롬프트를 그대로 쓰면 된다.

이 가이드에 담긴 것

• 데모에서는 잘 돌던 에이전트가 2주 안에 죽는 이유
• 매뉴얼을 이루는 세 개의 레이어: 프로세스, 툴박스, 증명
• 한 줄짜리 압축이 아니라 완전한 스펙인, 복사해서 붙여넣는 프롬프트 네 개
• 툴박스에 뭘 넣어야 하는지 — 네 가지 직무의 채워진 예시
• 실제로 실패할 수 있는 검증 항목 — AI가 90%만 완성한 결과를 내밀던 습관을 끊는 방법
• 폴더 템플릿과 주 단위로 풀어낸 전체 실전 예제

요약본이 아니다. 전체 빌드다. 프롬프트 네 개, 레이어마다 들어갈 내용, 흔한 직무 네 개에 대한 실전 예시, 그리고 AI가 반쯤 완성된 결과를 내밀지 못하게 막는 검증 항목까지 담았다. 첫 매뉴얼 하나에는 30분 정도 잡으면 된다. 아래 프롬프트는 완전히 빈 상태에서도 그대로 돌아가도록 쓰여 있다.

왜 에이전트는 계속 죽는가

흔한 조언은 일 하나에 에이전트 하나다. 이메일용 하나, 콘텐츠용 하나, 리드용 하나를 만들고 전부 연결하라는 것. 그런데 에이전트마다 각자의 프롬프트, 각자의 도구, 각자의 배선을 달고 있어서 일이 조금만 바뀌면 배선 어딘가가 부서지는데 그걸 발견하는 사람은 결국 당신이다.

Vercel은 사람들이 에이전트를 만들 때 쓰는 인프라를 파는 회사인데, 자사 데이터 팀에 정확히 이 방식을 적용했다. 전문가 에이전트들을 체인으로 연결해 자기 직원들에게 줬다. 그들의 표현을 빌리면 즉각적인 반응은 “형편없다”였다. 제대로 된 재구축은 더 똑똑한 에이전트가 아니었다. 범용 AI 하나에 자기들 파일의 폴더와 평범한 도구 몇 개를 줬더니 내부 점수가 대략 두 배가 됐다. Anthropic 엔지니어들도 같은 선택을 했다. 일마다 별도의 에이전트를 만드는 걸 멈췄다. 밑에 깔린 범용 에이전트가 그 주위의 배선보다 좋아졌기 때문이다. 처음부터 부족했던 건 지능이 아니라, 글로 적힌 당신의 업무 지식이었다.

시작 전에: 매뉴얼은 어디에 살고, 파일은 누가 쓰나

매뉴얼은 일 하나를 위한 폴더 하나다. 어떻게 굴릴지는 당신의 AI가 파일을 쓸 수 있는지에 달려 있는데, 사람들이 여기서 자주 넘어지니 시작 전에 정확히 정하자.

AI가 내 컴퓨터의 파일을 읽고 쓸 수 있다면(Claude Code, 파일 접근이 되는 아무 에이전트), 실제 폴더를 만들면 된다. 예를 들어 ~/playbooks/weekly-client-update. 아래 프롬프트는 그대로 돌아간다. 폴더 안에 SKILL.md를 만들고 파일을 저장하고 스스로 업데이트한다. 이 버전이 복리로 쌓이는 형태다. 뭔가를 동기화하라고 당신이 기억할 일이 아예 없으니까.

브라우저나 데스크톱 앱의 Claude·ChatGPT를 쓴다면 전부 할 수 있다. 단, 중요한 차이가 하나 있다. Project에 올린 파일을 AI가 다시 쓸 수는 없다. 매뉴얼을 읽고 새 버전을 화면에 출력할 수는 있지만 그 파일을 저장하고 업로드하는 사람은 당신이다. 채팅에 붙여넣은 어떤 것도 Project의 복사본을 업데이트하지 않는다.

그래서 채팅 전용 도구에서의 루프는 이렇다. 실제 폴더는 컴퓨터나 Drive에 둔다. Project에 파일을 올린다. AI가 업데이트된 SKILL.md나 새 템플릿을 주면, 먼저 실제 폴더에 저장한 뒤 올린 복사본을 교체한다. 예전 걸 지우지 않고 두 번째로 추가하면 안 된다. 같은 파일의 버전이 두 개가 되는 순간, AI는 몇 주 전에 폐기한 지시를 따라가기 시작한다.

클라우드 스토리지에 대한 경고 하나. Dropbox나 Drive에서 업로드하면 링크가 아니라 복사본이 만들어진다. 나중에 Drive에서 파일을 고쳐도 Project가 보는 것은 바뀌지 않는다. 어떤 도구를 쓰든 마스터 복사본은 정확히 하나이며 모든 업로드는 마스터를 고치는 순간 낡아지는 스냅샷일 뿐이다.

첫 일감은 이 세 가지 테스트로 골라라. 주 1회 이상 하는 일이고 나쁜 버전을 한눈에 알아보며 새 직원에게 설명하는 데 20분 안에 끝난다. 가장 복잡한 일로 시작하지 마라. 가장 반복되는 일로 시작해라.

레이어 1: 프로세스

프로세스 레이어는 당신의 판단을 실제로 쓰는 순서 그대로 적어둔 것이다. 직접 타이핑하는 게 아니다. 인터뷰를 받게 된다. 일에서 절대 스스로 적지 않을 부분이야말로 결과물을 당신답게 만드는 부분이기 때문이다.

좋은 SKILL.md에는 일곱 가지가 들어간다. 한 줄짜리 목적, 언제 쓰는지(실제로 입에 담을 말로), 입력과 그 위치, 번호가 붙은 순서, 결정마다 그 근거가 되는 규칙, 완료의 정의, 그리고 예전에 당신을 태운 적 있는 예외 사례들. 아래 프롬프트를 고른 도구의 새 채팅에 붙여넣어라.

붙여넣기 프롬프트 1 — 인터뷰로 SKILL.md 뽑기

너는 내가 반복해서 하는 일을, 나 없이도 네가 돌릴 수 있는 매뉴얼으로 만들어 줄 거다.

일은: [한 줄로 설명].

먼저 나를 인터뷰해라. 한 번에 질문 하나만 하고 답을 기다려라. 최소 여덟 개의 질문을 하고 내가 끝났다고 말하기 전까지 파일을 쓰지 마라. 이걸 전부 다뤄라:
- 이 일을 시작하게 만드는 계기와 빈도
- 입력들과 각각의 정확한 위치
- 실제로 내가 하는 순서대로 한 단계들
- 내가 내리는 모든 결정과 그 뒤의 규칙
- 끝냈다고 부르기 전에 내가 확인하는 것들
- 예전에 잘못됐던 예외 사례들
- 결과물이 만족해야 하는 톤이나 기준
- 나쁜 버전이 어떻게 생겼는지

너 없이 이 일을 돌릴 수 있겠다 싶으면, [job-name]이라는 폴더를 만들고 그 안에 SKILL.md를 써라. 섹션은: 목적(한 줄), 언제 쓰는지, 입력, 순서(번호, 쉬운 말, 전문용어 없이), 결정(X면 Y다), 완료의 정의, 예외 사례.

그리고 파일 전체를 보여주고 두 가지를 물어라: 내가 뭘 잘못 뽑았는지, 내가 알려주지 않은 게 뭔지.

파일을 직접 쓸 수 없다면 쓴 척하지 마라. 전체 파일 내용을 채팅에 출력하고, 정확한 파일명과 폴더 안 위치를 알려주고, 업로드된 예전 복사본을 지우고 새걸로 교체하라고 나에게 상기시켜라.

하는 동안의 요령: 완전한 문장으로 답하고, 추상 설명 대신 실제 예시를 대라. 짜증나는 질문이 나오면 그게 보통 진짜 중요한 질문이다. 첫 버전은 80% 정도 맞을 거라고 기대해라. 고치는 건 채팅이 아니라 파일에서 하라.

레이어 2: 툴박스

툴박스는 그 일에 필요한 재사용 가능한 모든 것을 폴더에 저장하고 SKILL.md가 그 파일들을 가리키게 한다. 이게 없으면 AI는 매번 같은 스크립트, 같은 템플릿, 같은 포맷 규칙을 처음부터 다시 짓는다. 시간과 돈이 나가고 결과는 매번 조금씩 다르다. Anthropic 팀은 Claude가 같은 슬라이드 스타일링 스크립트를 계속 다시 쓰는 걸 보고 그 스크립트를 미래의 자기 자신을 위한 도구로 스킬 안에 저장하게 했다.

툴박스에 실제로 들어갈 것들:

1. 기계적인 단계를 수행하는 스크립트 — 숫자 뽑기, 파일 이름 바꾸기, 포맷 변환 같은 것
2. 대괄호 자리표시자가 들어간 템플릿 — 골격은 고정되고 내용물만 바뀐다
3. 참조 데이터 — 고객 이름과 표기, 제품 목록, 가격, 링크, 계정 ID
4. 만족했던 완성 작업 예시 — 어떤 설명보다 톤을 빠르게 가르친다
5. 규칙 파일 — 브랜드 보이스, 포맷 표준, 절대 쓰지 않는 단어들
6. 자주 돌리는 하위 단계용으로 저장해둔 프롬프트

들어가면 안 되는 것: 일회성 산출물, 비밀번호나 키가 담긴 것, 반쯤 완성된 초안. 첫날 새 직원에게 주지 않을 것이라면 폴더에도 넣지 마라.

산출물을 손수 만들지 않고 각 아티팩트를 만드는 법: 일을 AI와 한 번 돌리고 뭔가 제대로 나온 순간 그대로 얼려라. 재사용 가능한 버전을 요청해서 — 내 상황에 특화된 부분은 자리표시자로 바꿔서 — 저장해라. 두 번째 실행이 툴박스를 진짜 채우는 때다. 뭐가 다시 지어졌는지 그때 보이니까. 뭔가 통과할 때마다 이 프롬프트를 써라.

붙여넣기 프롬프트 2 — 통과한 산출물을 도구로 저장

방금 만든 [스크립트 / 템플릿 / 이메일 / 체크리스트]를 봐라.

내가 이걸 또 필요로 하게 되면, 다음을 전부 해라:
1. [job-name]/files/에 설명적인 이름으로 저장해라. 예: numbers-pull.py, update-template.md. 이름에 날짜나 버전 번호를 넣지 마라.
2. 내 상황에 특화된 부분을 대괄호 자리표시자로 바꿔 재사용 가능하게 만들고 바로 아래에 채워진 예시 하나를 참조로 남겨라.
3. SKILL.md를 업데이트해서 이게 필요한 단계가 파일을 이름으로 가리키게 하고, 언제 쓰고 언제 안 쓰는지도 적어라.
4. [job-name]/files/INDEX.md에 한 줄 추가해라: 파일명, 용도, 오늘 날짜.

일회성 산출물, 비밀번호나 API 키가 담긴 것, 내가 승인하지 않은 초안은 저장하지 마라.

그리고 전체 일을 처음부터 다시 돌리고, 어떤 저장된 파일을 썼고 무엇을 백지에서 다시 지었는지 알려라. 다시 지은 것은 전부 툴박스 후보니, 다음에 뭘 저장할지 말해라.

파일을 직접 쓸 수 없다면 쓴 척하지 마라. 전체 파일 내용을 채팅에 출력하고, 정확한 파일명과 폴더 안 위치를 알려주고, 업로드된 예전 복사본을 지우고 새걸로 교체하라고 나에게 상기시켜라.

채워진 툴박스의 실전 예시들:

• 주간 고객 업데이트: numbers-pull 스크립트, update-template.md, 고객이 칭찬했던 지난 업데이트 두 개, 정확한 표기가 담긴 client-names.md, tone-rules.md
• 콘텐츠 재활용: hook-bank.md, caption-template.md, brand-voice.md, 잘 나갔던 게시물 세 개와 이유를 적은 메모
• 미수금 독촉: 연체 단계별 이메일 템플릿 세 개, escalation-ladder.md, account-contacts.md, 60일차에도 친절을 유지하기 위한 tone-rules.md
• 채용 서류평가: scorecard.md, role-brief.md, 점수 매긴 예시 답변 다섯 개, rejection-email.md

유지보수: 폴더를 매달 검토해라. 안 쓴 건 지우고, 용도 하나에 파일 하나만 유지해라. 거의 같은 일을 하는 파일이 두 개면 AI가 엉터리를 골라 쓴다.

레이어 3: 증명

거의 모든 사람이 건너뛰는 레이어이고, 90%만 완성된 결과를 내미는 AI와 끝난 결과를 내미는 AI의 차이가 여기서 난다. 증명 레이어는, 무엇이든 당신에게 도달하기 전에 AI가 스스로의 작업을 증거와 함께 검증해야 하는 완료의 정의다.

그래서 먼저 정해야 할 게 있다. 무엇이 증거로 인정되는가. Anthropic 엔지니어들이 명시적으로 말하는 부분인데, AI가 자기 초안을 읽고 “괜찮아 보인다”고 하는 건 아무 가치가 없다. 진짜 검증은 초록 바깥의 무언가를 만들어낸다. 원본 파일까지 거슬러 올라가는 숫자, 살아있는 페이지를 돌려주는 링크, 렌더링 결과의 스크린샷, 실제로 도는 테스트, 인용문과 대조한 주장, 단어 수, 참조 파일과 대조한 표기. 실패할 수 없는 검증은 검증이 아니다.

붙여넣기 프롬프트 3 — 실패할 수 있는 검증 항목 만들기

[job-name]의 SKILL.md에 완료의 정의 섹션을 추가해라.

이 일에 특화된 검증 항목 5~10개를 써라. 모든 항목은 네 자기 의견 바깥의 증거로 확인 가능해야 한다: 원본 파일까지 추적되는 숫자, 로드되는 링크, 렌더링 결과의 스크린샷, 도는 테스트, 인용문과 대조된 주장, 개수, 참조 파일과 대조된 값. "명확한", "전문적인", "고품질" 같은 애매한 품질 단어는 쓰지 마라.

이제부터 이 일을 마칠 때마다, 내게 아무것도 보여주기 전에:
1. 모든 검증 항목을 돌려라.
2. 실패한 걸 고쳐라.
3. 다시 돌려라.
4. 항목마다 근거와 함께 한 줄짜리 통과/실패를 내놔라.
5. 확인할 수 없는 것은 뭔지, 왜인지를 말해라. 통과한 걸로 가정하지 마라.

첫 패스에서 두 개보다 많은 항목이 실패하면 멈추고, 결과물을 땜질하지 말고 어느 프로세스 단계가 원인이었는지 말해라.

파일을 직접 쓸 수 없다면 쓴 척하지 마라. 전체 파일 내용을 채팅에 출력하고, 정확한 파일명과 폴더 안 위치를 알려주고, 업로드된 예전 복사본을 지우고 새걸로 교체하라고 나에게 상기시켜라.

직무별 좋은 검증의 예:

• 주간 고객 업데이트: 모든 수치가 뽑힌 데이터 파일에 존재할 것, 숫자 없는 형용사 금지, 200단어 이하, 고객 이름이 client-names.md의 표기와 일치, 지난주에 약속한 액션이 언급됨
• 콘텐츠 재활용: 훅이 12단어 이하, brand-voice.md의 금지 단어 없음, 주장이 원본 전사의 인용과 일치, 캡션 첫 줄이 결론이 아님
• 미수금 독촉: 금액이 인보이스 기록과 일치, 만기일이 정확, 톤이 단계에 맞음, 결제 링크가 열림
• 채용 서류평가: 모든 점수가 지원자 답변의 한 줄을 인용, 근거 없는 점수 금지, 요약이 전사와 모순되지 않음

루프: 채팅이 아니라 매뉴얼을 고쳐라

AI가 뭔가 틀렸을 때의 본능은 채팅에서 고치고 넘어가는 거다. 채팅이 닫히면 교훈도 함께 사라지고, 다음 주에 같은 수정을 또 타이핑한다. 루프는 모든 수정을 폴더에 다시 넣는 습관이다. 이 시스템이 쓸수록 좋아지고 에이전트는 쓸수록 나빠지는 이유가 이거다.

진단 단계가 있고, 이게 중요하다. 어느 레이어가 실패했는지 물어라. 순서에 단계가 빠져 있으면 프로세스다. 이미 있는 걸 다시 지었거나 저장된 파일이 틀렸으면 툴박스다. 아직 없는 검증이 잡았을 실수면 증명이다.

붙여넣기 프롬프트 4 — 잘못된 결과를 레이어 진단으로 고치기

그 결과물이 틀렸다. 이유는: [무엇이 어떻게 잘못됐는지 정확히].

먼저 어느 레이어가 실패했는지 진단해라:
- 프로세스: 단계가 빠졌거나 순서가 틀렸거나 결정 뒤의 규칙이 적히지 않았다
- 툴박스: 이미 있는 걸 다시 지었거나, 저장된 파일이 낡았거나 틀렸다
- 증명: 이걸 잡았을 검증이 존재하지 않는다

어느 것이었고 왜인지 두 문장으로 말해라.

그리고 그 레이어에 가장 작은 내구성 있는 수정을 해라. 매뉴얼 전체를 다시 쓰지 마라. 같은 실수가 이제 두 번 일어났다면 부드러운 리마인더가 아니라 그걸 막는 명시적 규칙을 추가해라.

[job-name]/notes.md에 오늘 날짜, 무엇이 잘못됐는지, 무엇을 바꿨는지 한 줄을 추가해라.

그리고 같은 작업을 처음부터 다시 돌리고 수정 전과 후를 보여줘라. 고침이 통했는지 내가 볼 수 있게.

파일을 직접 쓸 수 없다면 쓴 척하지 마라. 전체 파일 내용을 채팅에 출력하고, 정확한 파일명과 폴더 안 위치를 알려주고, 업로드된 예전 복사본을 지우고 새걸로 교체하라고 나에게 상기시켜라.

notes.md는 한 달에 한 번 읽어라. 같은 레이어에 반복되는 기록은 그 일이 진짜 어렵다는 뜻이다. 보통 그게 다음으로 제대로 자동화할 가치가 있는 일이다.

다 만들어진 폴더의 모습

[job-name]/
  SKILL.md              목적, 언제 쓰는지, 입력, 순서, 결정, 완료의 정의, 예외 사례
  files/
    INDEX.md            저장된 파일마다 한 줄: 이름, 용도, 날짜
    numbers-pull.py     기계적 단계를 수행하는 스크립트
    update-template.md  [자리표시자]가 든 템플릿
    tone-rules.md       네 표준, 네 말로
  examples/
    2026-09-08-good.md  만족했던 완성 작업
    2026-09-01-good.md
  notes.md              수정 기록, 최신이 위로

모든 일을 위한 폴더 하나가 아니라 일 하나당 폴더 하나다. 두 일이 계속 섞이면 문제는 각 SKILL.md의 첫 줄이다. “언제 쓰는지” 섹션을, 그 일을 시키고 싶을 때 실제로 칠 말 그대로 적어라.

전체 실전 예제: 주간 고객 업데이트

프로세스: 인터뷰에서 드러나는 건 — 지난주 숫자를 광고 대시보드에서 뽑고, 계획과 비교하고, 뭐가 바뀌었는지와 왜인지를 짚고, 과장 없는 짧고 정직한 톤으로 쓰고, 항상 가장 크게 움직인 숫자로 시작한다. 마지막 디테일은 아무도 쓴 SOP에 없는데, 업데이트를 당신답게 만드는 게 바로 그거다.

툴박스: 첫 실행이 numbers-pull 스크립트와 마음에 드는 구조를 만들어내니 둘 다 저장한다. 2주차에 보낸, 고객이 답장해준 그 업데이트는 examples에 들어간다. 고객 이름 표기와 계획 목표는 참조 파일로.

증명: 검증 다섯 개 — 모든 수치가 뽑힌 파일로 추적될 것, 수치 없는 형용사 금지, 200단어 이하, 고객 이름이 참조와 일치, 지난주 약속 액션이 언급됨.

루프: 4주차에 데이터에 없는 숫자를 지어낸다. 증명 실패로 진단하고, 모든 수치가 뽑힌 파일에 존재해야 한다는 검증을 추가하고 기록한다. 그 뒤로 한 번도 안 일어났다. 6주차엔 쓰는 게 아니라 읽고 보낸다.

피해야 할 실수 다섯 가지

1. 순서를 직접 적는 것. 인터뷰가 당신의 판단을 머리 밖으로 꺼내는 것이고, 짜증나는 질문이 중요한 질문이다.
2. 모든 걸 담은 거대 폴더 하나. AI는 어떤 일인지 구분 못 하고 그냥 찍는다.
3. 애매한 설명. “콘텐츠 도와줘”는 필요할 때 절대 로드되지 않는다. “언제 쓰는지”는 실제로 칠 말로 적어라.
4. 증명 레이어 없음. 검증이 없으면 품질 관리는 당신 몫인데, 그게 바로 넘기려던 일이었다.
5. 채팅에서 고치는 것. 수정이 폴더에 없으면 다음 주에 또 타이핑한다.

첫 30분

가장 자주 하는 일감을 골라라. 프롬프트 1을 돌리고 인터뷰에 정직하게 답한다 — 15분쯤 걸린다. 일을 한 번 돌리고, 제대로 나온 걸 프롬프트 2로 저장한다. 프롬프트 3으로 검증 항목을 추가한다. 두 번째로 돌리고 설명이 얼마나 줄었는지 지켜봐라. 두 번째 실행에서 이게 클릭되니까, 한 번으로 멈추지 마라.