//VALOR BRIDGE
← Insights
2026-09-24

자동화하면 안 되는 업무는 어떻게 가려낼까요?

자동화하면 안 되는 업무는 어떻게 가려낼까요?

자동화할 업무 목록을 받으면 저는 더할 것보다 뺄 것을 먼저 봅니다. 목록에 올라온 업무는 대개 다 그럴듯합니다. 반복되고, 손이 많이 가고, 규칙도 있어 보이고요. 그런데 그중 두어 개는 넣는 순간 나중에 골칫거리가 됩니다. 어떤 게 그런 업무인지 미리 가려내는 일이 구축 범위를 정하는 작업의 절반쯤 됩니다.

처음부터 이렇게 하진 않았습니다. 예전엔 목록을 받으면 다 할 수 있다고 말씀드렸거든요. 할 수 있는 건 사실이니까요. 문제는 할 수 있는 것과 해야 하는 것이 다르다는 걸 몇 번 겪고 나서야 알았다는 겁니다. 지금 빼는 기준이 네 가지인데, 전부 한 번씩 데인 자리입니다.

덧붙이면 목록은 대개 실제보다 깁니다. 자동화 얘기가 나오면 평소 귀찮았던 일이 한꺼번에 떠오르거든요. 그게 잘못은 아닙니다. 다만 귀찮은 것과 자동화가 잘 듣는 것은 다른 얘기라, 목록을 그대로 받아 전부 만들면 절반은 나중에 안 쓰입니다.

첫째는 처리 기준이 곧 바뀌는 업무입니다.

매달 돌아오고 손이 많이 가서 교과서 같은 대상으로 보였던 업무가 있었습니다. 범위에 넣기로 거의 정해진 상태였고요. 그런데 이 기준이 언제부터 이렇게 됐냐고 지나가듯 여쭤보니, 사실은 거래처 쪽 정책이 개편 중이라 반년 안에 또 바뀔 거라고 하시더군요. 목록에는 그런 게 안 적힙니다. 목록에는 업무 이름과 소요 시간만 적히니까요.

만들었으면 두 번 만들었을 겁니다. 그런데 다시 만드는 공수는 사실 큰 비용이 아닙니다. 진짜 비용은 기준이 바뀐 뒤에도 예전 기준으로 계속 결과가 나오는 몇 달입니다. 사람이 하면 어딘가 이상하다는 걸 알아차립니다. 시스템은 의심하지 않고 계속하고요. 그리고 그 몇 달치 결과물은 대개 아무도 다시 안 봅니다. 나중에 발견됐을 때 고쳐야 할 게 시스템 하나가 아니라 그동안 나간 문서 전부가 되는 겁니다.

둘째는 어쩌다 한 번 하는 업무입니다.

분기에 한 번 하는데 할 때마다 이틀이 걸린다는 업무를 자동화해 달라는 요청을 받은 적이 있습니다. 힘든 건 사실이었습니다. 할 때마다 주말을 쓰신다고 했고요. 다만 만들고 난 다음이 문제였습니다.

석 달에 한 번 쓰는 자동화는 쓸 때마다 어딘가 고장나 있습니다. 그 사이에 양식이 바뀌거나, 담당자가 바뀌거나, 연결해둔 파일 위치가 달라져 있거든요. 쓰려고 열었다가 고치는 데 반나절을 쓰면 아낀 게 없습니다. 게다가 석 달 만에 여는 화면은 쓰는 법도 기억이 안 납니다. 자주 도는 것은 쓰이면서 스스로 살아 있고, 가끔 도는 것은 방치되면 죽습니다. 그래서 이런 업무는 자동화 대신 잘 만든 체크리스트 한 장으로 갔습니다. 이틀이 하루 반으로 줄었을 뿐이지만 이건 고장나지 않습니다.

셋째는 사람도 기준을 말로 못 하는 업무입니다.

어떻게 판단하시냐고 여쭤보면 "보면 압니다"라는 답이 돌아오는 일들이 있습니다. 노하우가 없다는 뜻이 아닙니다. 있는데 아직 말이 안 된 상태죠. 15년쯤 하신 분들의 판단이 대개 이 상태입니다.

여기를 성급하게 자동화하면 규칙을 찾는 게 아니라 발명하게 됩니다. 저는 한 번 그랬습니다. 기준이 명확히 안 나오길래 제가 보기에 합리적인 선을 하나 정해서 넣었거든요. 몇 주 지나니 그게 원래 그 회사 기준이었던 것처럼 돌아가고 있었습니다. 무서운 건 그게 틀렸을 때 아무도 모른다는 겁니다. 다들 시스템에 물어보게 되니까 비교할 원본이 사라지거든요.

이런 업무는 순서를 바꿉니다. 먼저 실제로 내리신 판단 사례를 모읍니다. 최근 것 열 건이면 대체로 충분했습니다. 왜 이쪽으로 가셨는지를 건별로 여쭤보면, 본인도 몰랐던 기준이 서너 개쯤 문장으로 나옵니다. 자동화는 그 다음입니다.

넷째는 효율이 목적이 아닌 업무입니다.

고객에게 나가는 응대 중에는 빨라지면 오히려 손해인 것이 있습니다. 답이 3분 만에 오는 것보다 하루 걸려도 사람이 쓴 티가 나는 편이 나은 자리가 있거든요. 특히 오래 거래한 고객일수록 그렇습니다. 빠른 답을 받고 서운해하시는 경우를 실제로 봤습니다.

이건 기술 문제가 아니라 그 회사가 무엇으로 먹고사는지의 문제입니다. 여쭤보면 대표님들은 대체로 어느 쪽인지 아세요. 다만 목록을 만들 때는 그 구분이 잘 안 들어갑니다. 반복되니까 일단 올라오는 거죠. 목록은 업무를 빈도와 소요 시간으로만 보고, 그 업무가 관계를 만드는 자리인지는 안 보니까요.

여기까지 쓰고 보니 빼는 얘기만 했는데, 사실 빼자는 말을 꺼내는 게 파는 쪽에서 쉬운 일은 아닙니다. 범위가 줄면 견적도 줄거든요. 저도 처음 몇 번은 그 말을 못 꺼냈습니다. 그런데 넣었다가 안 쓰이는 기능이 하나 생기면 그 뒤가 더 비쌉니다. 쓰지 않는 기능이 하나 있으면 나머지도 못 미덥거든요. 하나가 틀리면 사람은 나머지도 확인하게 되니까요. 그래서 지금은 첫 미팅에서 뺄 것을 먼저 말씀드립니다.

물론 뺀다고 버리는 건 아닙니다. 뺀 업무는 목록에서 지우지 않고 다시 볼 조건을 적어 남겨둡니다. 기준이 개편되고 나면 그때 넣고, 판단 사례가 열 건 모이면 그때 넣는 식으로요. 이게 없으면 뺀 업무는 그냥 잊힙니다. 그리고 반년쯤 지나서 그건 왜 안 됐냐는 질문이 돌아옵니다. 그때 빼기로 한 이유가 적혀 있지 않으면 저도 기억이 안 나고요.

예외도 있습니다. 기준이 바뀔 걸 뻔히 알면서도 넣어야 하는 업무가 있었습니다. 안 하면 담당자가 그 자리에 매일 몇 시간씩 묶이는 경우였죠. 그럴 땐 넣되 바뀔 부분만 따로 떼어둡니다. 규칙이 개편되면 그 조각 하나만 갈아 끼우게요. 전체를 다시 만드는 것과 조각 하나를 바꾸는 것은 완전히 다른 일이거든요. 다만 이게 되려면 어디가 바뀔지를 미리 알아야 하는데, 그 예상은 틀릴 때가 꽤 있습니다. 틀려도 손해가 조각 하나로 끝나게 만드는 정도가 지금 제가 할 수 있는 최선입니다.

이 넷을 관통하는 게 하나 있습니다. 자동화의 비용은 만드는 데서 끝나지 않고, 틀린 채로 도는 기간에서 발생합니다. 만드는 공수는 견적서에 적히지만 이 비용은 아무 데도 안 적힙니다. 그래서 빼는 판단이 넣는 판단보다 돈이 됩니다. 안 만든 것은 고장나지 않으니까요.

그래서 범위를 정하는 자리에서 이 네 가지를 먼저 확인합니다.

하나. 이 업무의 처리 기준이 1년 안에 바뀔 가능성이 있으세요? 있으면 뺍니다. 안정된 뒤에 넣어도 늦지 않습니다.

둘. 이 업무가 한 달에 몇 번 돌아오세요? 분기에 한 번이면 자동화보다 체크리스트가 낫습니다.

셋. 지금 이 판단을 하시는 분이 기준을 문장으로 말씀하실 수 있으세요? 못 하시면 사례부터 모읍니다.

넷. 이 일이 빨라지면 고객이 좋아하실까요, 아쉬워하실까요. 아쉬워하실 자리면 사람이 계속합니다.

네 개를 다 통과한 업무만 넣습니다. 그러면 첫 구축 범위가 생각보다 작아집니다. 작아서 불안하다는 말씀도 여러 번 들었습니다. 그런데 작게 시작한 쪽이 결과적으로 더 멀리 갔습니다. 첫 구축의 진짜 위험은 기능이 모자란 게 아니라, 안 쓰는 기능이 섞여 들어와 전체가 못 미더워지는 쪽이었거든요. 그리고 작게 시작하면 두 번째 차수를 꺼내기도 쉽습니다. 첫 번째가 실제로 돌아가고 있으면 다음 범위는 설득이 아니라 상의가 되거든요.

이 네 가지가 완성된 목록인지는 저도 아직 모르겠습니다. 처음엔 두 개였고 데일 때마다 하나씩 늘었습니다. 다섯 번째가 나오면 그때 또 늘리겠죠.

밸러브리지(ValorBridge)는 IT 26년·3개국어에 능통한 비즈니스 전문가, 구승회(Kay S. Koo)가 이끄는 AI 워크플로우 회사입니다. IT 담당자가 없는 중소·중견기업의 반복 업무를, 사람이 붙어 있지 않아도 스스로 돌아가는 워크플로우로 바꿉니다.
무료 상담 신청하기Read in English