업무에 AI를 붙이는 회사가 처음 부딪히는 질문은 「무엇을 자동화할까」입니다. 메일 초안, 보고서 요약, 견적 계산처럼 후보는 금방 나옵니다. 그런데 몇 주 쓰다 보면 질문이 바뀝니다. AI가 만든 결과를 어디까지 사람이 확인해야 하는가, 그리고 사람이 없는 밤에 실행된 작업이 제대로 끝났는지 어떻게 아는가입니다.

제조 AI 운영체제 VEXPLOR를 만드는 웨이스는 사내 업무에 AI 무인 실행을 매일 사용하면서 이 두 질문의 기준을 정리해 왔습니다. 이 글은 그 기준을 다른 회사도 그대로 적용할 수 있게 옮겨 적은 것입니다. 사람 승인을 남길 곳을 정하는 기준 하나, 무인 실행을 판정하는 규칙 네 가지, 결과를 확인하는 방법 세 가지입니다.

사람 승인을 남길지 정하는 질문은 「사람이 안 정하면 무엇으로 가정하는가」입니다

AI가 일을 맡기 시작하면 확인 요청이 늘어납니다. 처음에는 조심스러워서, 나중에는 습관이 돼서 모든 판단을 사람에게 묻습니다. 문제는 확인 요청이 많아질수록 사람이 읽지 않게 된다는 점입니다. 하루에 확인 요청이 수십 건 쌓이면, 정말 사람이 정해야 할 한 건이 그 안에 묻힙니다.

그래서 「중요한가」를 묻기보다 다음 한 문항으로 판단하는 편이 낫습니다.

사람이 정하지 않으면, 우리는 무엇으로 가정하고 진행하는가.

가정을 적을 수 있다면 그 판단은 사람에게 올리지 않아도 됩니다. 대신 결과물에 가정을 남깁니다. 「가정: 표지 문구는 지난달 판을 따름. 다르면 알려 주세요」처럼 한 줄이면 충분합니다. 사람은 나중에 결과를 보다가 틀린 가정만 고치면 됩니다. 반대로 가정을 적을 수 없거나, 틀렸을 때 되돌릴 수 없다면 그 판단은 사람의 몫입니다.

사람에게 올릴 일은 되돌리기 어려운 5가지로 좁힙니다

위 질문을 실제 업무에 적용해 보면, 사람에게 남겨야 하는 일은 대개 다섯 가지로 모입니다. 공통점은 한 번 일어나면 되돌리기 어렵다는 것입니다.

- 밖으로 나가는 것 — 예: 메일 발송·제출·게시 · 사람이 정하는 이유: 나간 뒤 회수 불가
- 서명 — 예: 계약서·확인서 · 사람이 정하는 이유: 법적 책임 발생
- 가격·계약 조건 — 예: 견적가·할인·납기 · 사람이 정하는 이유: 관계 전체에 영향
- 돈 — 예: 지출·투자 · 사람이 정하는 이유: 금액과 무관하게 회수 어려움
- 사람 — 예: 채용·인사 · 사람이 정하는 이유: 당사자의 삶에 영향

「돈」에서 금액 기준을 두지 않은 데는 이유가 있습니다. 소액이면 자동 승인하자는 규칙은 편해 보이지만, 소액 지출이 쌓이는 속도는 사람이 알아채는 속도보다 빠릅니다. 지출은 금액과 상관없이 사람이 보는 편이 관리하기 쉽습니다.

사람에게 올릴 때의 서식도 정해 두는 것이 좋습니다. 추천안 하나와 기한을 함께 적습니다. 「A안과 B안이 있습니다, 어떻게 할까요」라고 물으면 결정을 사람에게 떠넘기게 됩니다. 「A안을 추천합니다. 이유는 이것이고, 목요일까지 정해 주시면 됩니다」가 사람의 시간을 덜 빼앗습니다.

무인 실행은 종료 코드가 아니라 보고 파일의 첫 줄로 판정합니다

예약 시각에 AI가 혼자 실행되는 작업은 사람이 지켜보지 않습니다. 그래서 끝났을 때 정말 끝까지 했는지를 기계가 판정할 수 있어야 합니다. 여기서 흔한 함정이 있습니다. AI 세션은 일을 다 하지 않아도 정상 종료할 수 있습니다. 오래 걸리는 작업을 뒤로 넘겨 두고 「끝나면 이어서 하겠습니다」라고 답한 뒤, 그대로 세션이 끝나는 경우입니다. 이때 종료 코드는 0이고, 겉으로는 성공입니다.

이 함정은 네 가지 규칙으로 막을 수 있습니다.

1. 오래 걸리는 작업을 뒤로 넘기지 않습니다 — 무인 세션은 응답이 끝나는 순간 종료됩니다. 기다렸다가 이어서 하는 동작이 없으므로, 긴 작업은 몇 분 단위로 잘라 세션 안에서 차례로 실행합니다.
2. 밖으로 나가는 동작은 1건마다 그 자리에서 기록합니다 — 신청·발송·등록을 끝에 몰아서 기록하면, 도중에 멈췄을 때 무엇이 나갔는지 알 수 없습니다.
3. 보고 파일은 상태 줄로 시작합니다 — 시작하자마자 「상태: 진행 중」으로 파일을 만들고, 끝날 때 「상태: 완료」나 「상태: 중단(사유)」로 바꿉니다.
4. 스크립트는 상태 줄을 검사합니다 — 종료 코드가 0이어도 보고 파일이 없거나 「진행 중」으로 남아 있으면 중단으로 판정하고 알림을 띄웁니다.

보고 파일 첫머리에 요약 한 줄과 사람이 판정할 건수를 함께 적어 두면 효과가 하나 더 있습니다. 무인 작업이 늘어날수록 아침에 보고서를 읽는 시간이 병목이 되는데, 이렇게 해 두면 사람은 첫 세 줄만 읽고 넘어갈 수 있습니다.

결과는 도구의 출력이 아니라 바깥에서 다시 확인합니다

무인 실행이 「완료」로 끝났다고 해서 결과가 맞는 것은 아닙니다. 도구가 성공이라고 출력하는 것과, 실제로 원하는 일이 일어난 것은 다릅니다. 그래서 결과는 도구 밖에서 한 번 더 봅니다.

- 메일은 보낸편지함에서 확인합니다 — 메일 프로그램이 「보냈다」고 답해도 첨부가 빠지는 일이 있습니다. 대표적인 예가 클라우드 동기화 폴더에 있는 파일입니다. 그 파일을 그대로 붙이면 메일 프로그램이 오류 없이 첨부를 빼고 본문만 보내는 일이 있습니다. 첨부할 파일은 로컬 디스크로 복사해 붙이고, 발송 뒤 보낸편지함에서 첨부 이름을 대조합니다.
- 업로드는 주소를 열어서 확인합니다 — 「10건 성공」이라는 출력보다, 올린 주소 10개를 실제로 열어 정상 응답이 오는지가 판정 기준입니다. 성공 건수가 기대한 건수와 같은지부터 셉니다.
- 값의 변경은 원본과 대조합니다 — 문서의 수치를 고쳤다면 그 수치의 원본과 다시 맞춰 봅니다. 같은 수치가 여러 문서에 있으면 하나만 고쳐지고 나머지가 남는 일이 가장 흔합니다.

세 가지 모두 실행할 때와 다른 방법으로 확인한다는 점이 같습니다. 같은 도구에게 「잘 됐는지 확인해」라고 묻는 것은 확인이 아닙니다.

검사는 막는 것과 알리는 것을 나눠 둡니다

무인화에서 검사를 늘리다 보면 또 하나의 함정이 생깁니다. 모든 검사가 작업을 멈추게 하면, 틀린 판정이 조금만 섞여도 사람이 검사를 끄게 됩니다. 믿지 못하는 검사는 없는 검사보다 나쁩니다.

- 되돌리기 어려운 일 앞의 검사는 막습니다 — 발송·제출·지출 직전 검사는 확인이 안 되면 멈추는 쪽으로 짭니다. 이런 검사는 틀린 판정이 나와도 사람이 한 번 확인하면 끝나므로 비용이 작습니다.
- 나머지는 알리기만 합니다 — 문장 길이, 표기 규칙, 권장 서식처럼 틀려도 되돌릴 수 있는 것은 경고로 남기고 작업을 계속합니다.
- 검사기 자체를 시험합니다 — 일부러 틀린 입력을 넣어 검사기가 실제로 잡는지 정기적으로 확인합니다. 한 번도 울리지 않는 검사기는 잘 되고 있는 것인지 고장 난 것인지 구분되지 않습니다.

무인화를 시작하기 전에 확인할 체크리스트

- 사람에게 올릴 일이 다섯 가지 안에 있는가 — 밖으로 나가는 것·서명·가격과 계약 조건·돈·사람
- 나머지 판단에 가정을 적고 진행하는 서식이 있는가 — 「가정: ○○로 진행, 다르면 알려 주세요」
- 승인 요청에 추천안 하나와 기한이 붙는가
- 무인 실행의 보고 파일이 상태 줄로 시작하는가 — 스크립트가 그 줄을 검사하는가
- 결과를 실행과 다른 방법으로 확인하는가 — 보낸편지함·주소 열기·원본 대조
- 막는 검사와 알리는 검사가 나뉘어 있는가

업무를 무인화할 때 AI가 맡는 범위를 넓히는 것보다 먼저 할 일은 사람이 정할 결정을 좁혀 적어 두는 것입니다. 그 경계가 분명해야 나머지를 안심하고 AI에게 맡길 수 있습니다. 웨이스는 이 기준을 사내에 먼저 적용했고, 공장에 AI를 넣을 때도 같은 순서를 따를 계획입니다.

WACE(웨이스)는 공장이 스스로 판단하고 멈추지 않게 하는 제조 AI 운영체제 VEXPLOR를 만드는 회사다.

(이 글은 웨이스 기술블로그에 먼저 실린 글입니다. 원문: https://blog.vexplor.com/post/where-to-keep-human-approval-in-ai-automation)