에이전트 워크플로우란 무엇인가: 분류부터 실행까지 잇는 자동화 흐름 완전 정리

에이전트 워크플로우란, 문서 분류와 정보 추출, 문서 간 검증, 조건 판단, 담당자 승인, 시스템 실행까지를 각각의 기능으로 두지 않고 하나의 업무 흐름으로 이어 붙여 한 건이 끝까지 처리되도록 구성한 자동화 설계입니다.

흐름으로 묶어야 하는 이유

기능이 다 있어도 업무는 끊깁니다.

문서 자동화를 도입한 조직에서 인식과 추출은 잘 돌아가는데 담당자의 일이 줄지 않는 경우가 있습니다. 각 기능이 따로 놀기 때문입니다. 분류 결과를 담당자가 확인해서 추출로 넘기고, 추출 결과를 화면에서 읽어 심사 시스템에 입력하고, 승인 여부를 다시 다른 화면에서 기록합니다. 자동화된 구간 사이마다 사람이 다리 역할을 합니다.

이 상태에서는 각 기능의 정확도를 아무리 올려도 총 처리 시간이 크게 줄지 않습니다. 사람이 화면을 옮겨 다니는 시간이 그대로 남기 때문입니다. 에이전트 워크플로우는 이 다리를 없애는 설계입니다. 한 건이 접수되면 정상 건은 사람 손을 거치지 않고 시스템 등록까지 도달하고, 예외 건만 담당자에게 올라옵니다.

에이전트 워크플로우의 정확한 정의: RPA와 무엇이 다른가

RPA와 에이전트 워크플로우, 세 가지 축의 차이

첫째, 대상이 다릅니다. RPA는 정해진 화면과 입력 절차를 대상으로 삼습니다. 무엇을 어디에 넣을지가 이미 정해진 상태에서 그 동작을 반복합니다. 에이전트 워크플로우는 아직 무엇인지 모르는 문서를 대상으로 삼습니다. 어떤 서식인지 판별하고 어떤 값을 꺼낼지 정하는 단계부터 흐름 안에 들어 있습니다.

둘째, 목표가 다릅니다. RPA의 목표는 정해진 절차를 사람보다 빠르고 정확하게 반복하는 것입니다. 에이전트 워크플로우의 목표는 한 건의 업무를 끝까지 완료하는 것입니다. 그래서 중간에 판단이 필요한 지점이 있으면 규칙과 근거를 근거로 스스로 판정하고, 판정할 수 없으면 사람에게 넘깁니다.

셋째, 성과지표가 다릅니다. RPA는 처리 건수와 오류율로 측정합니다. 에이전트 워크플로우는 사람 개입 없이 처리된 비율인 무개입률과 업무가 끝까지 완료된 비율인 업무 완료율로 측정합니다. 자동으로 처리된 건이 많아도 시스템 등록에서 끊기면 업무 완료율은 오르지 않습니다.

두 방식은 대체 관계가 아닙니다. 문서를 판독하고 판단하는 앞단은 에이전트가 맡고, 화면 조작이 필요한 뒷단은 RPA가 맡는 조합이 실무에서 널리 쓰입니다.

업무에 투입할 수 있는 에이전트 워크플로우의 6단계

실제 운영에 들어가는 에이전트 워크플로우의 6단계

첫째, 분류입니다. 접수된 파일을 문서 단위로 나누고 각 조각이 어떤 서식인지 판정합니다. 여러 서류가 하나로 병합되어 들어오는 환경에서는 이 단계가 흐름 전체의 진입점이 됩니다.

둘째, 추출입니다. 서식이 정해지면 그 서식에 맞는 항목 스키마를 불러와 값을 꺼냅니다. 값과 함께 원문의 위치와 신뢰도가 따라옵니다.

셋째, 검증입니다. 형식이 맞는지, 항목 사이의 관계가 성립하는지, 여러 문서에서 같은 항목의 값이 일치하는지를 확인합니다. 문서 간 대조가 여기에 들어갑니다.

넷째, 판단입니다. 검증 결과와 업무 규칙을 근거로 이 건을 진행할지 보완을 요청할지 정합니다. 신뢰도가 낮거나 규칙으로 판정할 수 없는 건은 예외로 분리합니다.

다섯째, 승인입니다. 업무 정책에 따라 사람의 확인이 필요한 지점을 통과합니다. 정상 건은 자동 승인으로 지나가고 예외 건만 담당자 화면에 올라옵니다.

여섯째, 실행입니다. 승인된 결과를 기존 시스템에 등록합니다. 전사자원관리와 고객관계관리, 전자문서관리시스템, 자동화 도구가 연동 대상이 되며, 판단 근거와 처리 이력이 함께 기록됩니다.

에이전트 워크플로우의 실제 적용 방법

예외 경로를 먼저 설계합니다

흐름을 설계할 때 정상 경로보다 먼저 정해야 할 것은 예외 경로입니다. 어떤 조건에서 사람에게 넘길지가 정해져야 나머지가 자동으로 흐를 수 있기 때문입니다.

예외 조건은 세 종류로 나눕니다. 값의 신뢰도가 기준 아래인 경우, 문서 간 대조에서 불일치가 나온 경우, 업무 규칙상 사람의 판단이 필요한 경우입니다. 각 경우에 어느 화면으로 올라가고 담당자가 무엇을 보고 무엇을 고칠 수 있는지까지 정의해 두어야 운영에서 막히지 않습니다.

시스템 연계를 흐름 안에 포함시킵니다

추출과 검증까지만 자동화하고 시스템 입력을 사람에게 남기면 절감 효과의 상당 부분이 사라집니다. 실제 운영에서 마지막 구간이 가장 오래 걸리는 경우가 많기 때문입니다.

연계를 설계할 때는 어떤 시스템에 어떤 형식으로 넣을지, 실패하면 어떻게 되돌릴지, 그리고 무엇을 이력으로 남길지를 함께 정합니다. 금융과 공공에서는 판단 근거와 처리 이력이 감사 대응의 근거가 되므로 이 부분을 나중에 붙이면 재작업이 커집니다.

자산을 다음 업무로 옮깁니다

한 업무에서 흐름을 완성하면 그 과정에서 만들어진 것들이 자산으로 남습니다. 분류 체계와 항목 스키마, 검증 규칙, 예외 정의가 여기에 해당합니다.

이 자산을 운영 체계에 축적해 두면 다음 업무에서는 차이 나는 부분만 조정해 적용할 수 있습니다. 같은 심사 업무 안에서 대상 문서군이 늘어나는 경우라면 조정 폭이 크지 않습니다. 이 방식이 새 업무마다 처음부터 구축하는 부담을 줄이는 핵심입니다.

국내 환경에서의 에이전트 워크플로우

국내 금융과 공공에서는 흐름 전체가 내부망 안에서 동작해야 합니다. 인식과 판단만 내부에서 하고 워크플로우 엔진을 외부에 두는 구성은 망분리 규정에서 걸립니다.

승인 단계의 설계도 국내 조건을 따릅니다. 자동 승인이 허용되는 범위가 내부 규정으로 정해져 있는 경우가 많고, 전결 규정에 따라 금액 구간별로 승인권자가 달라집니다. 이 규칙을 흐름 안에 넣어 두어야 자동화가 실제 업무 절차와 어긋나지 않습니다.

기록 요건도 함께 봅니다. 어떤 근거로 판단했고 누가 언제 승인했는지가 남아야 감사와 내부통제 요구에 대응할 수 있습니다.

자주 묻는 질문