AI 에이전트 업무 자동화, 업무 나누기와 지시 순서 5단계
AI 에이전트 업무 자동화의 지시 순서는 다섯 단계로 짭니다. 먼저 업무를 작은 단계로 나누고, 단계를 잇는 방식을 고르고, 단계별 지시서를 씁니다. 이어서 단계 사이에 검사 지점을 두고, 작은 표본으로 시험한 뒤 범위를 넓힙니다.
핵심은 단계마다 무엇이 나와야 끝나는지를 먼저 정하는 것입니다. 완료 조건이 없으면 에이전트도 검수자도 그 단계가 끝났는지 판단할 수 없습니다.
업무는 어떤 단위로 나누어야 에이전트에게 맡길 수 있나요?
실무에서는 한 단계에 목표 하나, 확인할 수 있는 산출물 하나를 기준으로 나누는 방법을 권합니다. 사람이 하던 순서대로 업무를 적은 뒤, 단계마다 입력·산출물·완료 조건을 붙입니다. 세 칸 중 하나라도 비면 그 단계를 더 쪼개거나 앞뒤 단계와 합칩니다.
이 방식은 문서가 설명하는 연결 구조와도 맞습니다. Anthropic의 에이전트 설계 글은 프롬프트 체이닝(앞 단계의 결과를 다음 단계가 이어 처리하는 방식)을 설명합니다. 이 방식은 고정된 하위 작업으로 깔끔하게 나눌 수 있는 업무에 맞는다고 설명합니다.
예를 들어 가상의 B2B 기업이 오래된 안내 글의 개정을 맡긴다면 다음처럼 나눌 수 있습니다. 아래 표의 1~5는 업무 단계 번호입니다.
| 업무 단계 | 입력 | 산출물 | 끝난 것으로 보는 조건 |
|---|---|---|---|
| 1. 대상 선정 | 게시 글 목록과 작성일 | 개정 후보 목록 | 글마다 선정 이유가 한 줄씩 있음 |
| 2. 변경 사항 조사 | 후보 글 1편, 공식 문서 | 바뀐 내용 목록 | 항목마다 근거 문서 이름과 확인일이 있음 |
| 3. 개정안 작성 | 원문, 변경 목록 | 개정 원고 | 변경 목록의 모든 항목이 원고에 반영됨 |
| 4. 사실·메타데이터 점검 | 개정 원고 | 점검 결과표 | 제목·설명까지 점검했고 미해결 항목이 없음 |
| 5. 게시 승인 | 원고, 점검 결과표 | 승인 또는 반려 기록 | 담당자와 결정 내용이 기록됨 |
4단계에 제목과 설명을 넣은 데는 이유가 있습니다. Google 검색 센터의 생성형 AI 콘텐츠 안내는 게시 전에 AI가 만든 내용의 사실을 확인하라고 설명합니다. 검색 결과에 보일 수 있는 제목·설명 같은 메타데이터도 검토 대상으로 듭니다.
업무 나누기의 점검 기준은 간단합니다. 표의 모든 행에서 입력·산출물·완료 조건 세 칸이 채워져 있으면 됩니다.
나눈 단계는 어떤 방식으로 이어 붙이나요?
연결 방식은 단계 사이의 의존 관계를 보고 고릅니다. Anthropic 글은 가장 단순한 해법에서 시작하고 필요할 때만 복잡도를 높이라고 권합니다. 같은 글이 구분한 연결 방식은 다음과 같습니다.
| 방식 | 문서의 설명 | 업무 예 |
|---|---|---|
| 순차 연결 | 앞 단계 결과를 다음 단계가 처리하며, 고정된 하위 작업에 맞음 | 조사, 개정안, 점검 순서로 진행 |
| 분기(라우팅) | 입력을 분류해 전용 후속 작업으로 보내며, 분류가 정확할 때 맞음 | 요청을 기술 오류와 콘텐츠 요청으로 나눔 |
| 병렬 분할 | 독립된 하위 작업을 동시에 실행하고 결과를 합침 | 글 10편의 변경 사항을 글별로 동시에 조사 |
| 지휘·작업자 | 중심 모델이 하위 작업을 정해 나눠 주고 결과를 합침 | 하위 작업 수를 미리 알 수 없는 주제 조사 |
| 평가·개선 반복 | 한쪽이 만들고 다른 쪽이 평가와 피드백을 반복하며, 평가 기준이 분명할 때 맞음 | 원고를 기준표로 검토하고 고침 |
OpenAI 에이전트 개발 도구 문서는 흐름을 모델이 정하게 할 수도, 코드로 정할 수도 있다고 설명합니다. 코드로 정하면 속도·비용·성능을 예측하기 쉽다고 덧붙입니다.
여러 에이전트를 동시에 쓰는 방식은 비용부터 따집니다. Anthropic은 자사 연구 시스템에서 다중 에이전트가 일반 대화보다 약 15배의 토큰을 썼다고 밝혔습니다. 모든 에이전트가 같은 맥락을 공유해야 하거나 에이전트 사이에 의존이 많은 업무에는 아직 잘 맞지 않는다고도 설명합니다.
실무에서는 순차 연결로 시작하고, 서로 기다릴 필요가 없는 단계만 병렬로 바꾸는 방법을 권합니다.
점검 기준: 모든 업무 단계 옆에 연결 방식과 그 이유가 한 줄씩 있습니다.
단계마다 에이전트에게 주는 지시서에는 무엇을 적나요?
Anthropic은 다중 에이전트 연구 시스템을 만든 경험을 공개했습니다. 하위 에이전트마다 목표, 산출 형식, 쓸 도구와 자료에 대한 안내, 명확한 작업 경계가 필요하다고 설명합니다. 지시가 모호했을 때는 에이전트끼리 같은 일을 중복했다고 밝혔습니다.
Claude 프롬프트 작성 문서는 지시의 이유를 함께 알려 주면 목표를 더 잘 이해한다고 설명합니다. 순서나 빠짐없음이 중요하면 번호 목록으로 단계를 주라고도 안내합니다.
이를 반영한 지시서 문안은 다음과 같습니다. 업무 단계마다 한 장씩 만들고 괄호 안만 바꿔 씁니다.
- 목표: 「(글 제목)」에서 공식 문서 기준으로 바뀐 내용을 찾습니다.
- 이유: 개정 원고는 이 목록만 보고 쓰므로, 목록에서 빠진 항목은 원고에서도 빠집니다.
- 입력: 원문 글 1편, 확인할 공식 문서 목록
- 산출 형식: 표 한 개(항목, 원문 표현, 현재 공식 설명, 근거 문서 이름, 확인일)
- 자료와 도구: 공식 문서만 근거로 씁니다. 블로그·커뮤니티 글은 후보를 찾는 데만 씁니다.
- 경계: 원고는 고치지 않고 변경 목록 작성까지만 합니다.
- 완료 조건: 모든 항목에 근거 문서와 확인일이 있습니다. 근거를 찾지 못한 항목은 따로 표시합니다.
- 멈추고 묻는 경우: 원문과 공식 문서를 서로 다르게 해석할 여지가 있을 때
하위 에이전트를 쓸지도 지시서에 적습니다. Claude 문서는 하위 에이전트를 지나치게 쓰는 경우가 있다고 설명합니다. 병렬 실행이나 독립된 맥락이 필요할 때만 쓰고 순차 작업은 직접 처리하게 하는 문안을 예로 듭니다.
같은 문서는 되돌리기 어렵거나 다른 사람에게 보이는 작업은 실행 전에 확인을 받게 하는 문안도 제시합니다. 게시·발송이 여기에 해당합니다.
지시서 작성은 처음 보는 동료가 읽고 같은 산출물을 만들 수 있을 때 마무리된 것으로 봅니다.
단계와 단계 사이에서는 무엇을 확인하고 넘기나요?
Anthropic 글은 순차 연결의 중간 단계에 프로그램으로 검사하는 관문(gate)을 둘 수 있다고 설명합니다. 에이전트는 단계마다 도구 실행 결과처럼 실제 환경에서 나온 결과로 진행 상황을 판단해야 한다고도 적습니다.
Claude 문서는 중간 산출물을 살펴야 하거나 정해진 흐름을 지켜야 할 때 단계를 나눈 실행이 유용하다고 설명합니다. 단계를 따로 실행하면 어느 지점에서든 기록·평가·분기할 수 있다는 점도 듭니다. OpenAI 문서는 구조화된 출력을 쓰면 코드가 결과를 살펴 다음 에이전트를 고를 수 있다고 설명합니다.
실무에서는 관문을 다음 세 가지로 나누는 방법을 권합니다.
| 관문 | 확인할 것 | 통과하지 못하면 |
|---|---|---|
| 형식 | 산출 형식의 칸이 모두 채워졌는가 | 같은 업무 단계를 다시 실행 |
| 근거 | 사실 항목마다 문서 이름과 확인일이 있는가 | 근거 없는 항목만 조사 단계로 되돌림 |
| 범위 | 지시서의 경계를 벗어난 변경이 없는가 | 결과를 버리고 지시서의 경계 문구를 고침 |
업무 단계 사이에는 인계 기록을 남깁니다. Claude 문서는 작업 상태처럼 구조가 있는 정보는 JSON 같은 정형 형식으로, 전반적인 진행 메모는 자유 서술로 남기라고 안내합니다. 따라 쓸 인계 기록 양식은 다음과 같습니다.
- 업무 단계: 2. 변경 사항 조사
- 상태: 완료, 보류, 실패 중 하나
- 입력 출처: 사용한 원문과 문서 이름
- 산출물 위치: 파일 이름 또는 문서 위치
- 관문 결과: 형식 통과, 근거 1건 미해결, 범위 통과
- 다음 단계 주의점: 근거가 해결되지 않은 항목은 원고에 반영하지 않음
관문 설계의 완료 기준은 모든 업무 단계 끝에 관문 결과가 적힌 인계 기록이 생기는 것입니다.
처음 맡길 때 시험과 확대는 어떤 순서로 하나요?
Anthropic은 작은 표본으로 평가를 바로 시작하라고 권합니다. 자사 연구 시스템 초기에는 실제 사용 형태를 대표하는 질문 약 20개로 평가를 시작했습니다. 초기 변경은 효과가 커서 적은 사례로도 차이가 드러났다고 설명합니다.
같은 글은 모델에게 기준표로 채점하게 한 방식이 사람의 판단과 대체로 일치했다고 밝힙니다. 기준은 사실 정확성, 인용 정확성, 완전성, 출처 품질, 도구 효율입니다.
사람의 검토는 자동 평가가 놓친 문제를 찾았다고도 적습니다. 초기 에이전트가 권위 있는 자료보다 검색 최적화에 치중한 콘텐츠를 고르는 경향이 그 예였습니다. 검색 업무를 맡기는 담당자가 특히 살펴야 할 부분입니다.
Anthropic의 초기 평가 규모를 참고해, 실무에서는 지난 실제 업무 20건 안팎으로 시작하는 방법을 권합니다. 시험과 확대는 다음 순서로 진행합니다.
- 지난 업무 20건 안팎을 골라 업무 1단계만 실행합니다. 사람이 했던 결과와 나란히 놓고, 빠지거나 다른 항목을 건별로 적은 뒤 다음 단계를 붙입니다.
- 업무 단계를 하나씩 붙여 실행하고, 관문에서 걸린 건을 실패 유형별로 셉니다.
- 위 다섯 기준으로 채점표를 만들어 모든 건을 채점합니다. 사람은 그중 일부를 직접 읽어 출처 품질을 따로 봅니다.
- 실패 유형마다 지시서의 어느 줄을 고칠지 정하고, 고친 뒤 같은 표본으로 다시 실행합니다. 반복 횟수 상한에 닿으면 사람이 판단합니다.
- 같은 실패가 되풀이되지 않으면 실제 업무로 넓힙니다. 게시 승인은 사람에게 남깁니다.
Anthropic 글도 반복 횟수 상한 같은 중단 조건이 통제에 도움이 된다고 설명합니다. Google 안내는 사용자에게 가치를 더하지 않고 AI로 페이지를 대량 생성하면 스팸 정책 위반이 될 수 있다고 설명합니다.
따라서 확대 여부는 처리량이 아니라 관문 통과율과 사람의 검토 결과로 판단합니다. 시험 단계는 비교 기록, 실패 유형 집계, 채점표가 모두 남았을 때 끝납니다.
정리
- 맡길 업무 하나를 골라 업무 단계마다 입력·산출물·완료 조건 세 칸을 채웁니다.
- 업무 단계마다 연결 방식과 이유를 적습니다. 순차 연결로 시작하고 독립된 단계만 병렬로 바꿉니다.
- 단계별 지시서를 목표, 이유, 입력, 산출 형식, 자료, 경계, 완료 조건 순서로 씁니다.
- 형식·근거·범위 관문과 인계 기록 양식을 정한 뒤 지난 업무 20건 안팎으로 시험합니다.
- 채점표와 사람 검토로 실패 유형을 찾아 지시서를 고치고, 같은 실패가 멈추면 범위를 넓힙니다.
참고 자료
- Building effective agents (Anthropic, 확인일 2026-10-17)
- How we built our multi-agent research system (Anthropic, 확인일 2026-10-17)
- Prompting best practices (Anthropic Claude 개발자 문서, 확인일 2026-10-17)
- Orchestrating multiple agents (OpenAI Agents SDK 문서, 확인일 2026-10-17)
- Google Search's Guidance on Generative AI Content on Your Website (Google 검색 센터, 확인일 2026-10-17)