AI 업무 자동화, 어디까지 맡기고 언제 사람이 확인해야 할까?

안녕하세요. 사랑받는 IT 프로덕트의 첫걸음, 똑똑한개발자입니다.

오늘의 인사이트 요약

- 초안 작성과 외부에 영향을 주는 행동을 나눕니다.

- 승인자가 근거와 변경 내용을 한 화면에서 확인하게 합니다.

- 승인 대기와 실행 실패까지 운영 규칙에 포함합니다.

AI가 업무를 대신 처리하도록 만들었는데, 담당자는 여전히 결과를 하나씩 확인하느라 바쁠 수 있습니다. 반대로 확인 단계를 줄이자니 고객에게 잘못된 안내가 나가거나 사내 데이터가 바뀔까 걱정되는데요. 자동화의 범위를 정할 때 사람이 어디서 개입해야 하는지가 고민되는 이유입니다.

모든 단계에 승인 버튼을 붙이면 처리 속도가 느려지고, 마지막 결과만 보면 이미 벌어진 일을 놓칠 수 있습니다. 업무를 작은 행동으로 나눈 뒤 영향과 복구 가능성을 살펴야 합니다.

오늘은 AI 업무 자동화에서 사람의 승인을 어디에 남기고, 실제로 작동하는 검토 절차를 어떻게 설계할지 알아보겠습니다.

1. 업무 이름보다 실제로 하는 행동을 나눕니다

‘고객 문의 자동화’라는 이름만으로 승인 필요 여부를 정하기는 어렵습니다. 문의를 분류하고 답변 초안을 만드는 일, 고객에게 발송하는 일, 환불을 처리하는 일은 같은 흐름에 있어도 결과가 다릅니다. 먼저 자동화가 읽는 정보와 바꾸는 정보를 구분하고, 회사 밖으로 전달되는 내용이 있는지 살펴보세요.

가령 배송 문의를 처리한다고 가정해 보겠습니다.

주문 상태를 조회해 내부 메모를 만드는 단계는 허용된 데이터 안에서 자동으로 처리하고, 보상 금액을 제안하거나 고객에게 확정 안내를 보내는 단계는 담당자가 확인하도록 설계할 수 있습니다. 이는 모든 회사에 적용할 정답이 아니라, 행동별로 권한을 나누는 예시입니다. 실제 범위는 회사의 업무 정책에 맞춰 정해야 합니다.

똑똑한개발자팀은 AI가 얼마나 자연스럽게 답하는지보다, 그 답이 어떤 행동으로 이어지는지를 먼저 살펴야 한다고 생각하는데요. 매끄러운 문장도 잘못된 수신자에게 전송되면 문제가 됩니다. 외부 발송, 비용 집행, 원본 변경처럼 영향을 되돌리기 어려운 행동부터 승인 지점을 검토하는 편이 좋습니다.

이때 승인 정책을 프롬프트에만 적어두지 않습니다.

초안 작성용 도구와 발송용 도구의 권한을 나누고, 필요한 승인이 없으면 실행 도구가 동작하지 않도록 시스템에서 확인해야 합니다. 자동 처리 범위를 늘릴 때도 이 경계부터 다시 점검합니다.

2. 승인자가 판단할 수 있는 화면을 만듭니다

승인 요청에는 ‘진행할까요?’보다 구체적인 정보가 필요합니다.

무엇을 누구에게 실행하는지, 어떤 자료를 참고했는지, 기존 내용과 무엇이 달라지는지를 함께 보여줘야 합니다. 검토자가 다른 화면을 여러 번 열어야 한다면 승인 단계가 있어도 내용을 충분히 확인하기 어렵습니다.

고객 안내문이라면 수신 대상과 최종 문안, 답변의 근거가 되는 주문 정보, 정책에서 벗어난 조건을 묶어 보여줄 수 있습니다. 데이터 수정이라면 바꾸기 전 값과 바꾼 뒤 값을 나란히 제시합니다. 확인할 수 없는 내용은 그럴듯하게 채우지 말고 누락된 항목으로 표시해 추가 확인을 요청하도록 만듭니다.

승인의 대상도 고정해야 합니다.

담당자가 문안 A를 승인한 뒤 AI가 내용을 고쳐 문안 B를 보내면 처음의 검토가 의미를 잃습니다. 승인한 내용과 실행할 내용을 연결하고, 수신자나 금액 같은 주요 값이 바뀌면 다시 확인하는 규칙을 두세요. 일정 시간이 지난 요청은 정보가 달라졌는지 확인한 뒤 재검토하게 할 수도 있습니다.

승인, 수정 요청, 반려는 서로 다른 상태로 기록하는 편이 좋습니다.

반려된 요청을 자동으로 다시 올리면 같은 검토가 반복됩니다. 수정 요청에는 고쳐야 할 내용을 남기고, 수정본에서 달라진 부분을 보여주면 다음 판단이 수월해집니다. 담당자에게 AI의 내부 추론을 길게 보여주기보다 검증 가능한 원문과 실행 내용을 제공하는 데 집중하세요.

3. 기다리거나 실패했을 때의 처리도 정합니다

승인자가 자리를 비웠다는 이유로 요청이 자동 실행되어서는 안 됩니다.

업무별로 대기 기한과 대체 담당자를 정하고, 기한을 넘겼을 때 알림을 보낼지 요청을 종료할지 합의해야 합니다. 급한 요청과 다음 업무일에 처리해도 되는 요청을 나누면 알림이 쌓이는 문제도 줄일 수 있습니다.

승인을 받았더라도 외부 시스템 실행은 실패할 수 있습니다. 특히 응답이 늦거나 연결이 끊긴 경우에는 실제로 처리됐는지 먼저 확인해야 합니다. 발송이나 결제를 무조건 재시도하면 같은 행동이 중복될 수 있으므로, 처리 상태와 요청 식별값을 확인해 중복 실행을 막는 방식이 필요합니다.

똑똑한개발자팀은 승인 버튼을 누른 기록과 실제 처리 결과를 함께 남기는 일이 중요하다고 보는데요. 어떤 자료를 바탕으로 누가 무엇을 승인했고, 최종적으로 무엇이 실행됐는지 연결되어야 담당자가 바뀌어도 문제를 추적할 수 있기 때문입니다. 기록에는 업무상 필요한 정보만 남기고 접근 권한과 보관 기간도 정합니다.

도입 전에는 정상 승인뿐 아니라 반려, 담당자 부재, 승인 후 내용 변경, 외부 시스템 응답 지연을 시험해 보세요. 처리 시간과 함께 사람이 수정한 이유, 중복 요청, 장기 대기 건을 살펴보면 어디를 개선해야 할지 알 수 있습니다. 중간 점검과 종료 조건을 포함한 에이전트 설계를 더 살펴보고 싶다면 Anthropic의 Building effective agents를 참고해 보세요.

4. 실제 업무에 맞춰 사람의 역할을 연결합니다

승인 절차는 개발 화면을 만든 뒤 덧붙이기보다 업무 담당자와 함께 정하는 편이 좋습니다. 같은 문서라도 작성자, 확인자, 최종 실행자가 다를 수 있기 때문입니다. 자주 처리하는 업무 하나를 골라 자동으로 끝낼 행동과 사람이 판단할 행동을 적고, 작은 범위에서 실제 검토가 가능한지 확인해 보세요.

똑똑한개발자는 내부 시스템 ‘똑빌더’와 영업·프로젝트 관리·콘텐츠 제작 업무에 AI와 자동화를 적용해 왔습니다. AI가 초안을 만들고 검토한 뒤 사람이 최종 판단하는 운영 경험을 바탕으로, 업무 분석부터 시스템 개발과 운영 개선까지 연결합니다.

위 소개서는 기획과 설계, 구현 과정에 사람의 판단을 배치하는 접근을 보여줍니다. 실제 승인 담당자와 권한, 예외 처리는 각 조직의 업무에 맞춰 구체화해야 합니다.

우리 업무에 맞는 AI 자동화 범위와 승인 절차를 함께 설계하고 싶다면 아래 똑똑한개발자 링크로 문의해 주세요! 감사합니다.