AI에게 일 시키기 - 프롬프트로 시킬 때와 에이전트에게 맡길 때 (2026)

경계는 도구 이름이 아니라 왕복 횟수에 있다

AI 도구를 고를 때 흔히 이름으로 나눈다. ChatGPT는 대화, Midjourney는 이미지, Cursor는 코딩. 그런데 막상 일에 붙여 보면 그 분류가 별 도움이 안 된다. 같은 도구가 어떤 날은 손이 덜 가고 어떤 날은 하루를 잡아먹는데, 도구가 바뀐 게 아니라 맡기는 방식이 바뀐 것이기 때문이다.

실제로 갈리는 기준은 하나다. 다음 수를 누가 정하는가.

프롬프트로 시키면 사람이 판단을 쥔다. 지시를 주고, 결과 한 덩어리를 받고, 마음에 안 들면 지시를 고쳐 다시 받는다. 왕복이 한 번씩 끊긴다. 에이전트에게 맡기면 그 왕복을 기계가 돈다. 목표를 주면 도구를 부르고, 결과를 보고, 다음에 무엇을 할지 스스로 정해 또 부른다. 사람은 시작과 끝에만 있다.

이 구분이 도구 이름과 어긋나는 게 중요하다. Cursor의 자동완성은 프롬프트 쪽이고 같은 Cursor의 에이전트 모드는 반대쪽이다. ChatGPT로 대본을 뽑으면 프롬프트 쪽이지만, 같은 모델에 도구를 붙여 루프를 돌리면 에이전트가 된다. 도구를 사는 게 아니라 모드를 고르는 것이다.

프롬프트로 시키는 쪽 — 판단이 매번 다른 일

프롬프트가 맞는 자리는 뚜렷하다. 결과물이 한 덩어리로 나오고, 좋고 나쁨을 사람 눈이 1초 만에 가르는 일이다.

영상 대본이 그렇다. 같은 주제로 열 번을 뽑아도 쓸 만한 건 취향이 정한다. 기계가 판정할 기준이 없으니 자동으로 돌릴 이유도 없다. 이미지와 음악도 마찬가지다. 「좋다」의 정의가 매번 달라지는 일은 사람이 계속 개입하는 편이 빠르다.

그래서 이쪽에서 늘어나는 실력은 프롬프트를 잘 쓰는 법이 아니라 다시 쓰기 쉬운 형태로 만들어 두는 법이다. 통짜로 긴 지시문 하나보다, 바꿀 자리가 분리된 짧은 틀 예닐곱 개가 오래 간다.

• 쇼츠 대본 프롬프트 — 5분에 쓰는 법
• ChatGPT 유튜브 롱폼 대본 작성법 — 실전 프롬프트 7가지
• Claude Sonnet 실전 활용법 — 글쓰기·코딩·업무
• 캔바 AI로 썸네일 10분에 만드는 법
• Stable Diffusion 로컬 설치 가이드
• ComfyUI 입문 — 사양·VRAM 기준부터

이 축은 줄일 이유가 없다. 오히려 에이전트가 늘어날수록 프롬프트를 다루는 감각이 더 필요해진다. 에이전트에게 주는 목표도 결국 글로 쓰기 때문이다.

에이전트에게 맡기는 쪽 — 절차가 정해진 일

반대쪽은 조건이 까다롭다. 사람이 안 붙어 있어도 되려면 중간 결과를 기계가 판정할 수 있어야 한다. 종료 코드, 글자 수, 파일이 있는지 없는지, 검사기가 통과를 냈는지. 이런 게 있어야 다음 수를 스스로 정한다.

코딩이 이 조건을 가장 잘 만족한다. 테스트가 통과했는지 아닌지가 참·거짓으로 나오고, 틀리면 되돌릴 수 있고, 같은 절차가 계속 반복된다. 지금 나와 있는 에이전트가 대부분 코딩 쪽에 몰려 있는 이유가 이것이다.

• Cursor AI 코딩 초보 가이드
• GitHub Copilot vs Cursor 비교
• Windsurf(현 Devin Desktop) vs Cursor 실사용 후기
• Replit AI 코딩 에이전트 활용법
• Claude Code vs Codex 비교

그래서 코딩 밖의 일을 맡기려다 실패하는 자리는 대개 같다. 「잘 됐는지」를 사람만 알 수 있는 일이다. 디자인 시안이 마음에 드는지, 문장이 자연스러운지, 사진 구도가 맞는지. 이런 건 아무리 지시를 잘 써도 기계가 다음 수를 못 정한다. 판정을 못 하니 루프가 안 닫힌다.

코딩 밖으로 나가려면 판정 기준을 직접 만들어야 한다. 글을 쓰게 하려면 「몇 자 이상」이 아니라 「어느 요소가 있는지」를 세는 검사기가 필요하고, 파일을 올리게 하려면 「올렸다」가 아니라 서버에서 다시 받아 바이트를 대조하는 단계가 필요하다. 이 판정기를 만들 수 있으면 그 일은 맡길 수 있고, 못 만들면 아직 아니다.

고르는 기준 — 네 가지 질문

새 일을 앞에 두고 어느 쪽으로 갈지 정할 때 이 넷을 순서대로 묻는다. 하나라도 「아니오」가 나오면 프롬프트 쪽에 남긴다.

맡기기 전에 만들어야 하는 것 — 멈추는 장치

에이전트를 돌려 보면 제일 먼저 부딪히는 게 「안 멈춘다」다. 같은 도구를 계속 부르거나, 실패를 성공으로 읽고 다음으로 넘어가거나, 목표를 못 찾은 채로 계속 시도한다. 그래서 멈추는 조건을 프롬프트가 아니라 코드에 박아야 한다. 프롬프트에 적은 규칙은 지켜질 때도 있고 아닐 때도 있다.

세 겹으로 두면 대체로 선다. 턴 한도로 위를 막고, 예산으로 총량을 막고, 같은 호출이 반복되는지를 본다.

const matched = report.match(/(\d+)점/);
const score   = matched ? parseInt(matched[1]) : 0;   // 못 읽으면 0점

if (score < PASS_SCORE) {
  return { blocked: true, reason: report };           // 여기서 끝난다
}

중요한 건 기본값이다. 검사기가 고장 나서 점수를 못 읽었을 때 통과로 처리하면, 검사기가 죽은 날부터 모든 게 통과한다. 못 읽으면 0점, 즉 차단이어야 한다. 게이트를 만들 때 가장 자주 틀리는 자리가 여기다.

하나 더. 게이트는 통과할 당사자가 판정하면 장치가 아니다. 모델에게 「다 됐으면 통과라고 말해」라고 하면 그건 검사가 아니라 자기신고다. 판정은 바깥 코드가 해야 한다.

• AI 에이전트 구축 — 루프부터 운영까지
• AI 하네스 구축 — 무인으로 돌리는 법
• MCP 서버 직접 만들기 — 설계와 함정
• 에이전트 툴 콜링 설계
• CrewAI · AutoGen 비교
• 로컬 에이전트 비교

비용은 토큰이 아니라 되돌리는 시간이다

무인으로 돌리기 시작하면 비용이 궁금해진다. 실제 실행 기록을 열어 보면 생각보다 갈래가 크다. 자료를 모아 화면을 다시 만드는 가벼운 루프는 회당 0.05달러 안팎이고, 글 한 편을 처음부터 만들어 검사까지 통과시키는 무거운 루프는 한 번에 3달러를 넘는다. 70배 가까이 차이가 난다. 누적으로는 열한 번 돌려 6.4달러, 회당 평균 0.58달러였다. 같은 「자동화」라도 무슨 일을 시키느냐에 따라 자릿수가 달라진다.

평균값이 별 의미가 없다는 게 요점이다. 평균 0.58달러는 0.05달러짜리 열 번과 3.4달러짜리 한 번을 섞어 놓은 숫자다. 예산을 잡을 때 평균으로 잡으면 무거운 루프 하나에 한 달치가 날아간다. 루프별로 따로 세야 한다.

여기서 나오는 결론이 모델을 나눠 쓰는 것이다. 판정·집계처럼 답이 정해진 일에 큰 모델을 쓸 이유가 없다. 반대로 글을 쓰고 스스로 고치는 일에 작은 모델을 쓰면 통과를 못 해 재시도가 늘고 결국 더 비싸진다.

그런데 실제로 아픈 비용은 토큰이 아니었다. 잘못 나간 결과를 되돌리는 시간이다. 파일 하나가 엉뚱하게 올라가면 그걸 찾아 내리고, 무엇이 딸려 갔는지 확인하고, 다음부터 안 그러도록 절차를 고치는 데 반나절이 든다. 토큰은 몇 백 원이고 복구는 반나절이다.

정리 — 두 갈래로 본 글 지도

이 사이트의 AI 글은 이제 두 갈래로 읽을 수 있다. AI 도구 리뷰 허브에서 「어떻게 시키나」 축을 고르면 같은 기준으로 걸러진다.

둘 중 하나를 고르는 문제가 아니다. 같은 일 안에서도 층이 갈린다. 무엇을 만들지는 프롬프트로 정하고, 만든 뒤 검사와 배포는 에이전트에게 맡기는 식이다. 경계를 어디에 그을지가 실력이고, 그 경계는 「기계가 판정할 수 있는가」에서 갈린다.

자동화는 낡는다 — 다시 손볼 때를 아는 법

한 번 맡기면 끝나는 일은 드물다. 자동화가 기대던 조건은 조용히 바뀐다. 양식이 바뀌고, 담당자가 바뀌고, 예외로 취급하던 경우가 어느새 절반이 된다. 문제는 이 낡음이 에러로 나타나지 않는다는 점이다. 절차는 끝까지 돌고 결과만 조금씩 어긋난다.

그래서 맡길 때 «잘 도는지»가 아니라 «어긋나면 티가 나는지»를 같이 만들어 둔다. 실무에서 값을 하는 신호는 세 가지다. 첫째, 손으로 고친 횟수. 결과를 사람이 매번 손보고 있다면 그 자동화는 이미 절반만 살아 있는 것이다. 둘째, 예외 처리로 빠진 비율. 예외가 늘어나는 것은 규칙이 현실과 벌어졌다는 뜻이다. 셋째, 마지막으로 손댄 날짜. 반년 넘게 아무도 안 본 자동화는 지금 맞는지 아무도 모르는 상태다.

점검 주기는 길게 잡아도 된다. 다만 날짜를 정해 두는 것이 중요하다. "이상하면 그때 보자"로 두면, 이상해진 뒤에도 한참을 모른다. 분기에 한 번 결과 몇 건을 무작위로 뽑아 사람이 직접 검산해 보는 것만으로 대부분의 낡음이 드러난다.

낡은 것을 발견했을 때 반사적으로 프롬프트부터 고치게 되는데, 순서를 하나 앞에 두는 편이 낫다. 먼저 «이 일이 아직 자동화할 만한 일인가»를 다시 묻는다. 예외가 절반이 됐다면 그건 규칙이 틀린 것이 아니라 일 자체가 판단의 영역으로 옮겨 간 것일 수 있다. 그때는 프롬프트를 아무리 다듬어도 원래 자리로 돌아오지 않는다. 자동화를 걷어내고 사람에게 돌려보내는 것도 정상적인 결말이다.

자주 묻는 것