반복 업무보다 예외 업무가 진짜 비용입니다

자동화 과제를 시작할 때 반복 업무 목록부터 만드는 팀이 많습니다. 매일 하는 데이터 입력, 매주 만드는 마감 보고서, 시간이 고정된 정산 처리. 눈에 잘 들어오고 절감 기대치도 숫자로 재기 쉬워서입니다. ERP를 직접 만들고 운영하면서 저도 처음에는 이 순서로 시작했습니다. 그리고 얼마 지나지 않아 예상하지 못한 곳에서 시간이 새고 있음을 확인했습니다.

반복 업무 옆에 붙어 있는 예외 처리였습니다. 예외는 보고서에 잘 찍히지 않습니다. 갑자기 바뀐 배차, 기준이 애매한 정산 건, 늘 하던 것과 조금 다른 요청. 각각은 작아 보이지만 담당자의 오전 절반을 끊어 먹습니다. 반복 업무 목록만 들여다보고 자동화 대상을 고르면 이 비용은 처음부터 보이지 않습니다. 자동화를 도입한 뒤에야 예외가 사고로 터집니다.

예외는 반복 업무보다 비쌉니다

반복 업무는 시간을 재기 쉽습니다. 보고서 한 건에 몇 분, 입력 한 행에 몇 초. 월 총량도 계산되고 절감 예상치도 나옵니다. 그래서 자동화 후보 목록에 제일 먼저 오릅니다.

예외는 처리 구조가 다릅니다. 담당자가 기억을 더듬고 이력을 확인합니다. 맥락을 아는 동료에게 전화하고, 사안에 따라서는 상사에게 결재를 구합니다. 이 시간은 시스템 로그에 남지 않습니다. 결과만 보면 정산이 오래 걸린 것처럼 보이고, 그 원인이 예외 처리였다는 사실은 보고서에서 사라집니다.

어느 팀에서든 담당자에게 어제 하루를 돌아보게 하면 예외 처리 이야기가 전체의 절반을 넘는 경우가 많습니다. 재 본 적이 없어서 비교하기 어려울 뿐입니다. 측정되지 않는 비용은 없애야 할 비용으로 인식되지 않고, 그래서 자동화 설계에서 빠집니다.

화면 설계보다 규칙 정하기가 더 오래 걸렸습니다

ERP를 직접 만들 때 화면 설계에 앞서 담당자 인터뷰를 먼저 진행했습니다. 업무 흐름을 물으면 답이 늘 같은 모양으로 시작됐습니다. "보통은 이렇게 처리하는데요, 그런데 이런 경우에는..." 업무 하나에 예외 갈래가 줄줄이 달려 나왔습니다.

처음에는 담당자가 설명을 잘 못 하는 것이라고 생각했습니다. 막상 개발을 진행해 보니 틀린 판단이었습니다. 코드 작성 시간보다 예외 처리 규칙을 정하는 회의 시간이 더 길었습니다. 어떤 경우에 어느 규칙을 쓸지, 판단을 시스템이 내릴지 사람에게 남길지를 결정하는 것이 사실상 개발의 본체였습니다. 패키지 ERP를 버리고 직접 만들며 배운 것도 결국 여기서 나왔습니다. 시스템의 진짜 산출물은 코드보다 업무 규칙이었습니다.

정산 마감날이 이를 잘 보여줍니다. 마감 계산 자체는 시스템이 몇 분이면 끝냅니다. 그런데 마감날 담당자는 하루 종일 자리를 지킵니다. 들여다보면 예외를 잡고 있습니다. 운행 기록이 누락된 건, 계약 내용과 다르게 운행된 건, 어느 규칙을 적용해야 할지 기준이 없는 건. 각각은 몇 분짜리 일인데 확인 전화와 이력 조회가 붙으면 30분이 됩니다. 이 시간은 어느 보고서에도 예외 처리로 기록되지 않습니다. 정산이 느린 팀으로만 보입니다.

예외의 상당수는 기준을 정하면 일반 업무가 됩니다

개발을 마치고 나서 보니 예외 목록이 처음보다 많이 줄어 있었습니다. 없앤 것이 아니라 일반 업무로 올라간 것이었습니다. 담당자 재량에 맡기던 판단에 기준이 생기면서 시스템이 처리할 수 있게 됐습니다.

담당자마다 조금씩 다르게 처리하고 있었던 항목들이 기준 하나로 정리됐습니다. 예외처럼 보였던 이유가 애초에 기준이 없어서였습니다. 이 발견이 이후 업무 설계 방식을 바꿨습니다. 자동화 후보를 찾기 전에 업무 흐름에서 예외와 병목부터 먼저 보는 것이 순서라는 것을 그때 확인했습니다.

물론 없앨 수 없는 예외도 있습니다. 고객 사정을 봐줘야 하는 경우, 관행적으로 처리해온 특이 건. 이것들은 예외로 남겨야 합니다. 급한 요청을 받아주는 유연함이 경쟁력인 업무도 있습니다. 없애는 것이 목적이 아닙니다. 어떤 예외가 존재하고 얼마나 자주 나오는지 조직이 파악하는 것이 목적입니다. 담당자가 즉석에서 알아서 처리하는 것과, 조직이 판단하고 남겨둔 것은 결과가 같아 보여도 다릅니다.

예외를 다루는 순서가 있습니다

자동화나 AI 도입 전에 예외부터 먼저 정리하는 순서를 저는 세 단계로 나눕니다.

1. 1기록: 한 달만 예외를 적게 합니다. 처리 규칙이 없어도 됩니다. 어떤 종류가 얼마나 자주 나오는지 빈도를 파악하는 것이 목적입니다. 이 목록이 예외 지도의 첫 번째 초안입니다.
2. 2승격 또는 제거: 자주 나오는 예외는 규칙을 만들어 일반 업무로 올립니다. 만들 가치가 없는 예외는 업무 자체를 없애거나 거절 기준을 정합니다. 이 단계에서 예외 목록이 절반 가까이 줄어드는 팀이 많습니다.
3. 3잔여만 사람에게: 규칙으로 만들 수 없는 진짜 예외만 사람이 판단하게 남깁니다. 이 잔여에 AI를 붙이는 경우도 있습니다만, 예외 지도 없이 여기까지 오면 AI가 무엇을 처리해야 할지 범위가 정해지지 않습니다.

AI와 자동화는 이 정리가 끝난 다음에 붙이는 것이 순서입니다. 예외 지도 없이 시스템을 올리면 예외를 만날 때마다 사람이 수습해야 합니다. 자동화율이 높아질수록 수습 빈도도 높아집니다. 이것보다 더 심각한 문제도 있습니다. 예외 지도가 없으면 시스템이 예외를 잘못 처리해도 알아채는 사람이 없습니다. 이렇게 해서 조직이 자동화를 못 믿게 됩니다.

지금 추진하는 자동화 과제에 예외 지도가 있습니까

반복 업무 목록만 가지고 자동화를 설계하면 예외 비용은 도입 뒤에야 수면 위로 올라옵니다. 그때는 시스템이 이미 돌고 있어서 수정 비용이 처음 설계할 때와 다릅니다. 착수 품의서가 올라가기 전에 예외 지도를 먼저 그리는 것이 그래서 순서입니다.

지금 추진 중인 자동화 과제에서 가장 자주 나오는 예외 세 가지를 현장 담당자에게 물어본 적이 있습니까. 그 세 가지에 지금 처리 기준이 있는지 확인해 보시겠습니까.