AI 업무 자동화 설계: 초안·검토·실행을 분리하는 5단계

자동화보다 먼저 정해야 할 경계

AI 업무 자동화의 첫 질문은 “어떤 도구를 쓸까”가 아니라 “AI가 어디까지 해도 되는가”입니다. 같은 요약 기능이라도 내부 회의록 초안과 고객 계약 조건 정리는 위험이 다릅니다. 내부 회의록은 잘못 정리해도 원문으로 돌아갈 수 있지만, 계약 금액이나 납기를 잘못 안내하면 신뢰와 비용 문제가 생깁니다.

따라서 업무를 자동화할 때는 결과의 편리함보다 외부 영향, 금액 영향, 개인정보 포함 여부, 되돌릴 수 있는지를 먼저 봐야 합니다. 이 네 가지 중 하나라도 위험도가 높으면 AI는 실행자가 아니라 보조자로만 둡니다.

실제 제작·검증 근거

Biz2Lab 운영자는 Commerce Automation Control Center 공개 저장소에서 콘텐츠 생성 제어 화면과 Python 작업자를 분리하고, 외부 게시·업로드를 기본적으로 잠그는 구조를 구현했습니다. 공개 저장소의 기본 실행 모드는 generate_only이며, 준비되지 않은 공급자·권한·자산은 차단 사유만 보여 주고 실행하지 않습니다.

이 프로젝트에서 가장 중요했던 것은 AI나 자동화 도구가 결과를 만들었다는 사실이 아니라 입력과 결과를 추적할 수 있고, 승인되지 않은 외부 동작은 발생하지 않으며, 준비 실패 이유를 운영자가 확인할 수 있는가였습니다. 이 글의 입력 → 초안 → 검토 → 승인 → 실행 기록 구조는 공개 코드에서 사용한 경계를 일반 업무용으로 풀어 쓴 것입니다.

확인하지 않은 것도 분명합니다. 저장소는 공개 업로드를 기본 경로로 구현하지 않았고 실제 고객 문의나 결제를 실행한 성과 사례도 아닙니다. 따라서 절감 시간이나 매출 효과를 주장하지 않으며, 그런 수치는 실제 운영 전후 기록이 생기기 전까지 본문에 추가하지 않습니다.

입력에서 기록까지 다섯 칸으로 나누기

작은 자동화도 다음 다섯 단계를 분리하면 사고 원인을 찾기 쉬워집니다.

한 화면에서 모든 단계를 처리하려고 하면 초안과 확정 정보가 섞입니다. 특히 “AI 결과”라는 열 하나만 만들면 누가 확인했는지, 어떤 문장이 바뀌었는지 알 수 없습니다. 초안 열과 승인 상태 열을 분리하고, 외부 발송은 승인 상태가 승인일 때만 가능하도록 막는 편이 좋습니다.

샘플 업무: 문의 분류 자동화

예를 들어 하루에 문의가 30건 들어오는 팀을 가정합니다. AI는 문의를 가격, 배송, 환불, 기타로 분류하고 답변 초안을 만들 수 있습니다. 이때 바로 고객에게 답변하지 않고 다음 순서로 운영합니다.

1. 원문을 수정하지 않은 상태로 보관합니다.
2. AI 분류 결과와 신뢰가 낮은 이유를 별도 열에 적습니다.
3. 환불, 금액, 개인정보가 포함된 문의는 무조건 검토 대기로 보냅니다.
4. 담당자가 분류와 초안을 확인한 뒤 발송 여부를 결정합니다.
5. 잘못 분류된 사례를 일주일에 한 번 모아 규칙을 수정합니다.

이 구조의 성과는 “AI가 30건을 처리했다”가 아닙니다. 담당자가 원문을 다시 읽는 시간이 얼마나 줄었는지, 잘못된 분류를 수정하는 데 몇 분이 들었는지, 긴급 문의가 누락되지 않았는지를 봐야 합니다.

자동 실행을 막아야 하는 세 가지 상황

첫째, 금액·계약·결제 상태를 변경하는 작업입니다. 숫자 하나가 틀려도 복구 비용이 큽니다. 둘째, 고객에게 메시지를 보내거나 공개 글을 발행하는 작업입니다. 문맥 오류와 과장 표현을 사람이 확인해야 합니다. 셋째, 원본 데이터를 덮어쓰는 작업입니다. 새 열이나 별도 시트에 결과를 만들고, 검토 전에는 원본을 보존합니다.

이 세 영역은 자동화를 하지 말라는 뜻이 아닙니다. 초안 생성과 실행 권한을 분리하라는 뜻입니다. 자동화의 속도보다 승인 경계가 명확할 때 운영자가 안심하고 계속 사용할 수 있습니다.

바로 쓰는 통제표

AI 자동화 통제표 CSV 내려받기

샘플 파일에는 업무명, 입력자료, AI 역할, 사람 검토 항목, 외부 실행 차단 여부, 실패 시 조치가 들어 있습니다. 처음에는 세 개 업무만 기록하고, 실제로 일주일 운영한 뒤 재작업이 줄어든 업무만 다음 단계로 옮기면 됩니다.

2주 시험 운영안

첫 주에는 외부 발송과 데이터 변경을 모두 막고 초안 품질만 확인합니다. 매일 잘못된 분류, 빠진 정보, 검토에 오래 걸린 항목을 기록합니다. 둘째 주에는 위험이 낮은 내부 상태 변경 하나만 승인 후 실행해 봅니다. 예를 들면 검토가 끝난 문의에 처리완료 상태를 붙이는 정도입니다.

시험이 끝났을 때 다음 질문에 답할 수 있어야 합니다.

• 사람이 실제로 덜 반복했는가?
• 오류를 발견하고 되돌리는 방법이 분명했는가?
• 특정 담당자가 없어도 기록을 이해할 수 있는가?
• 고객과 금액에 영향을 주는 실행은 승인 없이 발생하지 않았는가?

한 항목이라도 답하기 어렵다면 기능을 더 붙이기보다 입력과 승인 기록을 먼저 고치는 것이 낫습니다.