챗봇 다음 단계: 에이전트를 넣기 전에 업무 흐름을 그려야 한다

답변이 끝나도 실제 업무는 남아 있을 수 있습니다

납기 문의에 답하는 챗봇과 납기 변경을 처리하는 에이전트는 요구사항이 다릅니다. 후자는 주문을 식별하고 재고와 생산 일정을 확인한 뒤, 변경 가능 여부를 판단하고 관련 시스템에 결과를 반영해야 합니다. Blackbold는 ‘어떤 질문에 답할 것인가’와 함께 ‘어떤 상태가 되면 업무가 완료된 것인가’를 적을 것을 제안합니다. 자연스러운 답변만 평가하면 실제 처리가 빠진 상태도 성공으로 오인하기 쉽습니다.

에이전트가 실행할 행동은 작은 범위부터 정해야 합니다

가상의 구매 지원 에이전트라면 처음에는 견적 자료 수집과 비교표 작성까지만 맡길 수 있습니다. 발주 확정이나 지급 조건 변경은 담당자가 확인하도록 남겨 두는 방식입니다. 도구 호출 권한은 업무 목적에 맞게 좁히고, 승인 전과 후의 상태를 분명히 나눕니다. 중간에 자료가 부족하거나 시스템이 응답하지 않으면 멈춘 이유와 다음 담당자가 해야 할 일을 보여줘야 합니다. 성공 경로만 매끄러운 시연은 운영 설계의 충분한 근거가 되지 않습니다.

실패 후 재시도까지 하나의 업무로 설계해야 합니다

같은 요청을 다시 실행했을 때 주문이나 티켓이 중복 생성되지 않는지도 확인해야 합니다. 요청 식별자, 실행 기록, 이미 완료된 단계에 대한 확인 절차가 필요합니다. 첫 파일럿에서는 정상 처리율뿐 아니라 사람이 인계받는 빈도와 복구에 걸리는 시간을 보세요. 이 기록이 쌓여야 어느 구간에 자율성을 더 줄 수 있는지 판단할 수 있습니다. 에이전트의 범위를 넓히는 기준은 기능 수보다 검증된 업무 완료 능력이어야 합니다.

자동으로 해야 할 일을 동사로 적습니다

‘계약 업무를 처리한다’는 말은 너무 넓습니다. 계약 파일을 읽는다, 누락 항목을 표시한다, 담당자에게 확인을 요청한다, 승인된 정보를 저장한다처럼 행동을 나눕니다. 각 행동에는 사용할 자료와 바꿀 수 있는 대상을 붙입니다. 이를 정하지 않으면 모델은 대답을 만들었지만 담당자는 실제로 무엇이 처리됐는지 알기 어렵습니다.

처음부터 모든 단계를 AI가 판단하게 할 필요도 없습니다. 일정한 계산이나 정해진 조건의 분류는 기존 프로그램으로 처리하고, 문서 해석처럼 다양한 입력을 다루는 부분에 AI를 쓰는 편이 단순할 수 있습니다.

사람은 매번 지시하는 역할에서 예외를 다루는 역할로 이동합니다

정상적인 요청은 시스템이 순서대로 진행하고, 정보가 부족하거나 허용 범위를 벗어난 요청은 사람이 확인합니다. 이때 ‘확인 필요’라는 알림만 보내지 말고 원문, 판단 이유, 미확인 항목과 가능한 다음 행동을 함께 보여줘야 합니다. 담당자가 다시 처음부터 자료를 찾는다면 자동화의 이득이 줄어듭니다.

Blackbold는 승인 화면도 에이전트의 일부로 봅니다. 사람이 승인하거나 수정한 결과가 실행 기록에 남고, 이후 같은 오류를 줄이는 시험 자료가 되어야 합니다. 담당자는 예외 판단과 업무 규칙 개선에 시간을 쓰게 됩니다.

한 번 끝났다는 응답보다 저장된 결과를 검사합니다

AI가 ‘등록했습니다’라고 말해도 실제 시스템에 항목이 생겼는지 확인해야 합니다. 요청이 중간에 끊겼다가 다시 실행되면 같은 항목이 두 번 만들어질 수도 있습니다. 작업 번호로 중복 실행을 막고, 최종 상태를 조회하는 절차를 둡니다.

시작은 조회나 초안 생성처럼 되돌리기 쉬운 기능이 좋습니다. 데이터 변경과 외부 발송은 승인·중단·복구를 점검한 뒤 늘립니다. 성과는 도구 호출 횟수보다 정확히 완료된 업무의 비율과 사람이 다시 손댄 시간으로 평가합니다.