AI 에이전트 도입은 모든 반복 업무에 에이전트를 붙이는 일이 아닙니다. 입력이 얼마나 달라지는지, 판단 규칙이 얼마나 명확한지, 잘못 실행했을 때 영향이 얼마나 큰지를 먼저 보고 정해진 워크플로·에이전트·보류 중 하나를 고르는 일입니다. Anthropic은 미리 정한 코드 경로를 따르는 워크플로와, 도구·과정을 동적으로 정하는 에이전트를 구분합니다. effective-anthropic

먼저 답: AI 에이전트 도입은 업무의 변동성부터 본다
고정 양식에서 필드를 옮기는 업무라면 정해진 흐름이 먼저입니다. 원본이 제각각이고, 근거를 찾아 다음 도구를 선택해야 하지만 결과를 사람이 확인할 수 있다면 제한된 에이전트 실험을 검토할 수 있습니다. 둘 다 아니라면 자동화 후보가 아닐 수 있습니다. 이 분류는 제품 우열이 아니라, 필요한 복잡도를 필요한 만큼만 쓰라는 외부 가이드를 Morrow의 운영 질문으로 바꾼 것입니다. effective-anthropic

워크플로와 에이전트의 차이를 업무 언어로 번역한다
| 선택 | 맞는 업무 | 운영자가 지켜볼 것 |
|---|---|---|
| 정해진 워크플로 | 입력·순서·규칙이 안정적 | 누락, 오류, 예외 인계 |
| 제한된 에이전트 | 입력이 다양하고 다음 행동에 판단이 필요 | 도구 사용, 근거, 승인 |
| 보류 | 목표·원본·책임이 불명확 | 업무 표준화부터 |
워크플로는 경로가 미리 정의되고, 에이전트는 과정과 도구 사용을 동적으로 이끈다는 구분이 이 표의 출발점입니다. effective-anthropic 표는 Morrow의 단순화된 실무 판정이며 특정 제품의 성능을 뜻하지 않습니다.

세 가지 질문으로 후보 업무를 판정한다
- 1. 입력: 자료 형식과 누락 방식이 대체로 같은가, 매번 해석이 다른가?
- 2. 판단: “이 경우 다음 단계”를 규칙으로 적을 수 있는가, 근거를 찾아 비교해야 하는가?
- 3. 영향: 틀린 결과가 내부 초안 수준인가, 고객·가격·권한에 영향을 주는가?

에이전트 설계는 모델만이 아니라 도구, 지시, 가드레일을 함께 다룬다는 안내가 있습니다. agents-openai 그래서 세 질문의 답이 애매하면 기술을 더 붙이기보다 입력 기준과 승인 경계를 먼저 문서화하세요.
판정표: 워크플로, 에이전트, 보류
| 관찰 | 권장 다음 행동 | 첫 검증 |
|---|---|---|
| 정형 입력 + 명확한 규칙 | 워크플로 프로토타입 | 예외 3건의 인계 확인 |
| 비정형 입력 + 제한된 판단 | 승인형 에이전트 파일럿 | 정상·예외·금지 사례 평가 |
| 목표·출력·책임 불명확 | 보류 | 업무 담당자와 출력 정의 |

여기서 ‘에이전트’라고 판정해도 자율 실행을 의미하지는 않습니다. OpenAI의 가드레일 관점 agents-openai을 적용하면, 첫 범위는 읽기·분류·초안처럼 되돌릴 수 있는 행동에 머무르는 편이 낫습니다.

에이전트로 갈 때 먼저 고정할 통제
NIST는 생성형 AI 위험 관리가 각 조직의 목표와 위험 허용도에 맞아야 한다고 설명합니다. rmf-nist Morrow의 운영 체크리스트는 다음과 같습니다.
- 에이전트가 읽을 자료와 쓰지 못할 자료를 나눈다.
- 고객 발송, 권한·가격 변경은 지정 승인자가 없으면 실행하지 않는다.
- 근거가 없거나 입력이 모호하면 수기 대기열로 인계한다.
- 같은 업무를 AI 에이전트 평가 방법의 정상·예외·금지 사례로 시험한다.

Morrow의 관점: RPA 비교와는 다른 선택
RPA와 AI 에이전트 비교는 기술 특성을 고르는 독자 과제를 다룹니다. 이 글은 그 전 단계인 “내 업무 경로가 얼마나 고정돼 있는가”를 판단합니다. Morrow는 복잡한 구조가 자동으로 더 좋은 결과를 만든다고 보지 않습니다. 실제 업무에 필요한 도구와 통제만 남긴 뒤, 승인 기반 파일럿으로 검증하는 편이 안전합니다. 이는 외부 설계 안내를 바탕으로 한 Morrow의 해석입니다. agents-openai

선택을 위한 15분 업무 분해
도구 데모를 보기 전에 최근 업무 한 건을 펼쳐 보세요. 시작 신호, 입력, 사람이 하는 판단, 다음 행동, 완료 기준, 되돌릴 수 없는 행동을 순서대로 적습니다. 이는 시스템을 설계하는 일이 아니라 후보의 복잡도를 보이는 진단입니다. Anthropic이 워크플로의 미리 정한 경로와 에이전트의 동적 선택을 구분한 것을 Morrow가 현장 질문으로 바꾼 것입니다. effective-anthropic
- 시작 신호를 한 개로 고릅니다. “매주 받은 양식”처럼 관찰 가능해야 합니다.
- 입력 종류를 셉니다. 같은 CSV와 같은 필드가 반복되면 워크플로 쪽이고, 이메일·PDF·자유 서술처럼 형식이 달라도 같은 결론이 필요하면 판단 경계가 생깁니다.
- 사람이 멈춰 생각하는 순간을 표시합니다. 규칙을 읽는지, 근거를 비교하는지, 정책 결정을 기다리는지 구분합니다.
- 고객 발송, 금액, 계약, 접근 권한, 공개 게시처럼 되돌리기 어려운 행동은 후보의 끝에서 분리합니다.
- “담당자가 검토할 초안 레코드가 만들어짐”처럼 완료 문장을 씁니다. 완료를 쓸 수 없으면 보류가 더 빠른 선택입니다.
| 관찰된 장면 | 가장 작은 선택 | 이유 | 첫 안전장치 |
|---|---|---|---|
| 정해진 양식에서 필드를 옮김 | 워크플로 | 경로와 규칙을 문서화할 수 있다 | 누락 필드면 대기열 |
| 이메일별 근거를 찾아 분류 | 제한된 에이전트 | 입력과 다음 도구 선택에 판단이 있다 | 근거 링크와 사람 검토 |
| 부서마다 좋은 결과가 다름 | 보류 | 목표와 승인 기준이 없다 | 결과 정의 회의 |
| 고객에게 조건을 확정해 보냄 | 보류 또는 초안만 | 판단보다 권한 영향이 크다 | 발송 권한 차단 |
이 표는 제품 비교표가 아니라 Morrow의 운영 판정표입니다. 같은 기술이라도 입력과 승인 경계가 바뀌면 결론이 바뀝니다.
워크플로가 더 좋은 반례를 먼저 찾는다
‘에이전트’라는 말이 붙었다고 더 유연한 구조를 고르면 비용과 검토점이 늘어날 수 있습니다. 매일 같은 공급사 파일에서 재고 수량을 읽고 값이 비면 담당자에게 알리는 업무는 도구를 스스로 선택할 이유가 거의 없습니다. 날짜 형식 변환, 필드 검증, 대기열 생성처럼 고정 경로를 쓰는 워크플로가 실패를 찾고 재현하기 쉽습니다. AI를 쓰더라도 문서 요약 한 단계에만 제한할 수 있습니다.
반대로 모든 일을 워크플로 규칙으로 고정하는 것도 반례입니다. 계약 문의처럼 첨부 문서와 이메일 문맥을 함께 읽고, 허용된 지식베이스에서 조항 후보를 찾아 근거와 초안을 만들어야 할 수 있습니다. 이때는 읽을 자료, 사용할 검색 도구, 초안을 승인할 사람을 제한한 에이전트 실험이 더 알맞을 수 있습니다. 동적 과정 선택은 외부 실행 권한까지 정당화하지 않습니다. effective-anthropic
에이전트를 고를 때도 행동은 좁게 시작한다
OpenAI는 모델뿐 아니라 도구, 지시, 가드레일을 에이전트 설계의 구성 요소로 설명합니다. agents-openai 따라서 첫 파일럿에서는 무엇을 할 수 있는가보다 무엇을 준비하고 어디서 멈추는가를 적습니다. 다음은 Morrow의 운영 체크리스트입니다.
- 읽기 범위는 승인된 폴더·지식베이스·레코드로 제한하고 개인 드라이브 전체나 임의 웹 검색을 기본값으로 두지 않습니다.
- 쓸 수 있는 행동은 분류 태그, 내부 초안, 검토 대기열처럼 되돌릴 수 있는 항목부터 엽니다.
- 결과에는 사용한 근거와 확실하지 않은 항목을 남기며, 근거가 없으면 매끈한 문장 대신 인계합니다.
- 고객 발송, 거래 단계 변경, 가격 제안, 권한 변경은 준비물만 만들고 지정 승인자 없이는 실행하지 않습니다.
- 정상·예외·금지 사례를 AI 에이전트 평가 방법으로 확인한 뒤에만 범위를 유지하거나 바꿉니다.
NIST는 생성형 AI 위험 관리가 조직 목표와 위험 허용도에 맞아야 한다고 설명합니다. rmf-nist 다른 회사가 에이전트를 쓴다는 사실은 판정 근거가 아닙니다. 우리 팀의 검토 시간, 데이터 범위, 실패 시 되돌리는 방법이 함께 준비되어야 합니다.
제한된 파일럿과 첫 주 확인
콘텐츠 문의를 분류하는 팀은 들어온 이메일에서 업종, 요청 유형, 답변에 필요한 내부 자료를 찾아 내부 검토용 브리프를 만들 수 있습니다. 에이전트는 승인된 지식베이스를 읽고 근거 링크를 붙이며, 자료가 없으면 추가 확인 대기열을 만듭니다. 고객에게 답을 보내거나 가격을 제안하지 않습니다. 이는 성과나 고객 결과가 아닌 Morrow의 제한된 운영 예시입니다.
에이전트가 필요한 이유는 이메일 형식과 근거 문서가 매번 다르기 때문이지만, 최종 행동은 브리프 생성, 근거 기록, 인계로 고정됩니다. 나중에 대부분의 문의가 고정 양식이라는 사실을 발견하면 그 구간은 워크플로로 낮추는 편이 낫습니다. 반대로 근거 비교가 늘어나면 도구는 하나씩 추가하되 각 도구의 입력·출력·금지 행동을 운영 카드에 적습니다.
첫날에는 입력 샘플과 완료 기준을 확인합니다. 둘째 날에는 세 건을 손으로 따라가며 예외를 표시합니다. 셋째 날에는 가장 작은 내부 초안을 실행합니다. 넷째 날에는 실패를 고치기보다 안전하게 인계됐는지 봅니다. 다섯째 날에는 업무 책임자가 계속·축소·보류를 기록합니다. 이 순서는 일정이나 성과를 보장하지 않는 Morrow의 파일럿 제안입니다. 첫 주에는 처리량보다 원본이 모호할 때 멈췄는지, 승인 없는 외부 행동이 없었는지, 담당자가 결과를 고칠 수 있었는지를 확인합니다.
선택을 뒤집을 신호도 미리 적어 둡니다. 워크플로에서 예외 대기열이 계속 늘고 담당자가 매번 근거를 찾아 판단한다면 그 한 단계만 제한된 에이전트 후보가 됩니다. 반대로 에이전트가 수행하는 판단이 사실상 정해진 규칙과 같은 입력으로 반복된다면 워크플로로 낮춥니다. 둘 중 어느 쪽도 책임자와 완료 기준이 없다면 보류합니다. 이것은 기술 성숙도 점수가 아닌 Morrow의 재판정 규칙입니다.
FAQ
에이전트 활용 사례가 많으면 우리도 에이전트를 써야 하나요?
아닙니다. 공개 사례나 기술 명칭은 후보를 떠올리는 힌트일 뿐, 우리 업무의 입력·판단·영향을 대신 판정하지 않습니다. 위험 관리는 조직별 목표와 허용도에 맞춰야 합니다. rmf-nist
워크플로로 시작하면 나중에 확장할 수 있나요?
가능합니다. 예외 기록이 쌓여 규칙만으로 처리하기 어려운 지점이 확인될 때, 그 한 경계에 한해 에이전트 실험을 추가하세요. 그 전에는 현재 흐름의 예외 인계와 승인 기록을 먼저 안정화합니다.

반복 업무 한 개의 경계를 함께 점검하려면 4주 승인 기반 파일럿을 검토하세요.
