업무 시스템

AI 자동화에 적합한 업무와 적합하지 않은 업무

실패는 기술이 아니라 대상 선정에서 갈립니다. 빼야 할 업무를 먼저 알면 남은 후보가 분명해집니다.

최종 검토 2026-07-21 자동화 대상 선정승인 게이트기록 체계

한눈에 보는 답변

자동화 가능 여부는 업무가 반복적인지가 아니라 판단 기준이 글로 적히는지, 그리고 그 업무의 기록이 시스템에 남는지로 갈립니다. 반복이 잦아도 담당자의 경험으로 매번 다르게 판단하는 업무는 자동화 대상이 아니고, 종이·구두·개인 엑셀로만 처리되어 데이터가 남지 않는 업무는 자동화 이전에 기록부터 만들어야 합니다. 반대로 처리 규칙이 문서로 존재하고 결과가 시스템에 쌓이고 있다면, 그 업무는 지금 상태로도 자동화 후보입니다.

적합한 경우
처리 규칙이 문서로 적혀 있고 결과가 시스템에 기록으로 남는 업무
주의할 경우
데이터가 없는 업무는 자동화가 아니라 기록 체계 만들기가 먼저입니다
핵심 판단 기준
이 업무를 신입에게 글로만 설명해서 넘길 수 있는가 — 없다면 자동화도 어렵습니다

이 글은 자동화 검토가 기술이 아니라 대상 선정에서 어긋나는 경우를 다룹니다. 후보 목록을 만드는 단계에서 「사람 손이 많이 가는 일」을 기준으로 골라 놓으면, 착수한 뒤에야 그 업무가 자동화에 맞지 않는 형태였다는 것이 드러납니다.

이 글에서 자동화는 규칙대로 처리하는 방식과 AI를 쓰는 방식을 함께 가리킵니다. 둘 중 무엇을 쓸지는 대상 업무가 정해진 뒤의 문제라, 후보를 고르는 단계에서는 같은 기준으로 봅니다.

이 글은 어떤 업무를 자동화 후보에서 빼야 하는지에 무게를 둡니다. 빼고 남은 것이 곧 후보이기 때문에, 부적합을 가리는 쪽이 후보 목록을 더 빨리 확정시킵니다.

밝혀 둘 것이 있습니다. 이 글은 업무 자동화를 만드는 회사가 쓰고 있습니다. 그래서 「자동화하면 좋은 업무」를 늘려 잡을 유인이 있는 쪽이 저희입니다. 아래 다섯 유형은 그 유인의 반대편에 있는 목록이고, 여기 해당하면 지금은 만들지 않는 편이 낫다는 뜻입니다.

반복되는 업무라고 모두 자동화 대상은 아닙니다

반복성은 자동화의 필요조건이지 충분조건이 아닙니다. 매주 돌아오는 업무라는 사실은 그 일을 자동으로 처리할 수 있다는 근거가 되지 못합니다.

같은 이름으로 불리는 업무 안에서도 처리 방식은 갈릴 수 있습니다. 「주간 실적 정리」를 세 사람이 나눠 하고 있다면 세 사람의 산출물이 서로 다른 형태일 수 있고, 어느 것이 맞는지 정해 둔 문서가 없을 수 있습니다. 이 상태에서 자동화를 붙이면 셋 중 하나를 임의로 골라 고정하는 결과가 됩니다.

반복 횟수는 가부를 정하는 값이 아니라 순서를 정하는 값입니다. 후보에 들어갈 자격이 있는지는 다른 기준으로 판단하고, 그다음에 빈도를 보고 무엇을 먼저 할지 정합니다.

참고로 빌드업웍스의 반복 업무 자동화 지면도 「어떤 업무부터 시작하면 좋은가」에는 답하고 있지만, 「어떤 업무를 빼야 하는가」는 다루지 않습니다. 이 글이 그 빈자리를 채웁니다.

먼저 두 가지 질문으로 크게 가릅니다

자동화 가능 여부는 두 가지 질문으로 갈립니다. ① 처리 기준이 글로 적히는가, ② 처리 결과가 시스템에 기록으로 남는가입니다.

두 질문의 조합으로 업무의 위치가 정해집니다.

기록이 시스템에 남는다기록이 남지 않는다
기준이 글로 적힌다지금 자동화 후보기록 체계를 먼저 만든다
기준이 글로 적히지 않는다기준을 먼저 세운다자동화 검토 이전 단계

기준이 적히는지 확인하는 가장 간단한 방법은 이 업무를 신입에게 글로만 설명해서 넘길 수 있는지 스스로 물어보는 것입니다. 옆에 앉혀 두고 몇 건을 같이 처리해 봐야 넘길 수 있는 업무라면, 그 업무의 기준은 아직 사람 안에 있습니다. 자동화는 사람 안에 있는 기준을 꺼내 주지 않습니다.

두 질문에 모두 그렇다고 답할 수 있다면, 그 업무는 별도 준비 없이 지금 상태로 후보에 넣어도 됩니다. 이 경우 남는 논의는 「가능한가」가 아니라 「어디까지 자동으로 진행하고 어디서 사람이 확인하는가」입니다.

자동화 후보에서 빼야 할 업무 다섯 가지

자동화 후보에서 빼야 할 업무는 크게 다섯 가지 유형입니다. 유형마다 왜 어려운지와 대신 무엇을 먼저 해야 하는지가 다릅니다.

앞의 두 질문을 통과한 업무 중에서도 후보에서 빠지는 경우가 셋 더 있습니다. 예외의 비중, 되돌릴 수 있는지, 그리고 얼마나 자주 도는지입니다.

1. 판단 기준이 담당자 안에만 있는 업무

기준이 문서가 아니라 경험에 있는 업무는 자동화 대상이 아닙니다. 「이 건은 느낌이 좋지 않으니 한 번 더 확인한다」는 판단이 실제로는 정확하더라도, 그 정확함의 근거가 밖으로 나와 있지 않으면 옮겨 담을 것이 없습니다.

이 유형은 알아보기 쉽습니다. 최근 처리한 건 열 개를 뽑아 「왜 이렇게 처리했는지」를 담당자에게 물어보면 됩니다. 답이 매번 같은 규칙으로 정리되면 기준이 있는 것이고, 건마다 다른 사정이 나오면 아직 규칙이 아닙니다.

이 경우 먼저 할 일은 자동화가 아니라 기준을 글로 옮기는 일입니다. 그 과정에서 규칙이 실제로는 두세 개의 단순한 조건이었다는 것이 드러나기도 하고, 반대로 조건이 수십 개로 늘어나 애초에 사람이 판단해야 할 일이었다는 결론이 나기도 합니다. 어느 쪽이든 자동화 착수 전에 알아야 할 사실입니다.

2. 처리 기록이 남지 않는 업무

종이·구두·개인 엑셀로만 처리되는 업무는 자동화가 참조할 데이터가 없습니다. 담당자 노트북에만 있는 파일, 회의에서 구두로 정해지고 회의록에 남지 않은 결정, 캐비닛에 보관된 서류는 사람에게는 기록이지만 시스템 입장에서는 존재하지 않는 것과 같습니다.

이 유형도 알아보기 쉽습니다. 지난달 처리 내역을 시스템에서 조회할 수 없고 담당자에게 물어야만 알 수 있다면 이 유형입니다.

이 유형은 「기록이 남지 않는 업무는 자동화보다 기록 체계가 먼저입니다」에서 따로 다룹니다. 자동화 후보에서 빼야 한다는 결론은 같지만, 해야 할 일이 「기준 세우기」가 아니라 「기록 만들기」로 다르기 때문입니다.

3. 예외가 본류인 업무

표준 처리보다 예외 처리가 많은 업무는 자동화 효과가 잘 나지 않습니다. 규칙이 있고 예외가 붙는 구조라면 규칙 부분을 자동으로 처리하고 예외만 사람에게 보내면 됩니다. 그런데 실제로 들여다보면 「예외 처리 방법」이 업무의 본체이고 표준 처리는 이름만 남아 있는 경우가 있습니다.

판단 기준은 비율입니다. 최근 한 달 처리 건 중 정해진 절차대로 끝난 건이 몇 건이고, 중간에 누군가에게 물어보거나 별도 협의를 거친 건이 몇 건인지 세어 보십시오. 예외를 거친 건이 정해진 절차대로 끝난 건보다 많다면 아직 표준이 없는 것으로 봅니다. 예외가 다수라면 자동화를 붙여도 대부분의 건이 사람에게 되돌아옵니다. 오히려 자동 처리와 수동 처리 두 경로를 함께 운영하는 부담만 늘어납니다.

이 유형에서 먼저 할 일은 예외의 종류를 세어 보는 것입니다. 예외가 여러 갈래로 흩어져 있으면 자동화가 어렵지만, 몇 가지 유형으로 묶인다면 그 유형들이 새로운 규칙이 되어 자동화 대상으로 바뀌기도 합니다.

4. 되돌릴 수 없는데 확인할 방법도 없는 업무

되돌릴 수 없는 처리이면서 사후 확인도 불가능한 업무는 자동화 후보에서 제외합니다. 대외로 나가는 발송, 자금 집행, 외부에 공개되는 게시처럼 실행된 뒤에는 원상복구가 어려운 처리가 여기 해당합니다.

다만 되돌릴 수 없다는 사실만으로 제외되지는 않습니다. 실행 직전에 사람이 확인할 수 있고 확인에 필요한 정보가 갖춰진다면, 통과 여부를 사람이 정하는 지점(승인 게이트)을 두어 다룰 수 있습니다. 게이트를 어디에 두고 어떻게 설계하는지는 「판단이 들어가는 업무를 전부 뺄 필요는 없습니다」에서 다룹니다. 진짜 제외 대상은 확인 자체가 불가능한 경우입니다. 확인하려면 담당자가 원래 자료를 처음부터 다시 봐야 한다면, 그 확인은 실무에서 지켜지지 않습니다.

5. 고장 나도 아무도 모를 업무

빈도 자체는 순서를 정하는 값이지만, 한쪽 끝에서는 가부에 영향을 줍니다. 자동화한 처리는 만들어 두면 끝나는 것이 아니라 계속 살아 있어야 합니다. 연동한 시스템이 바뀌거나 양식이 개정되면 함께 손봐야 하고, 그 사이에 아무도 쓰지 않았다면 다음에 쓸 때 동작하지 않는 상태로 발견됩니다.

여기서 실제 비교 대상은 사람의 처리 시간만이 아니라 유지에 드는 관심입니다. 판별식은 이렇습니다. 다음번 실행이 언제인지 지금 말할 수 있는가, 그 사이에 고장 나면 알아차릴 사람이 있는가 — 둘 다 아니면 자동화보다 절차서가 맞습니다.

분기 결산이나 정기 신고처럼 다음 실행 시점이 정해져 있고 매번 같은 절차를 밟아야 하는 업무는 빈도가 낮아도 이 유형이 아닙니다.

기록이 남지 않는 업무는 자동화보다 기록 체계가 먼저입니다

기록이 남지 않는 업무는 자동화보다 기록 체계를 먼저 만드는 편이 결과가 좋습니다. AI는 데이터가 있어야 동작하는데, 수기 장부와 개인 엑셀만 있는 상태에서는 참조할 것도 판단 근거로 삼을 것도 없습니다.

여기서 말하는 기록은 완결된 시스템을 뜻하지 않습니다. 같은 항목을 같은 자리에 남기는 것에서 시작합니다. 언제, 누가, 무엇을, 어떤 결과로 처리했는지가 정해진 형태로 쌓이면 그것이 데이터입니다. 공유 스프레드시트 한 장이라도 항목이 고정돼 있고 모든 담당자가 같은 곳에 적고 있다면 출발점이 됩니다.

반대로 다음과 같은 상태는 기록으로 세기 어렵습니다.

  • 담당자마다 다른 파일에, 다른 항목으로 적는 경우
  • 결과만 남고 그렇게 처리한 이유가 남지 않는 경우
  • 최종본이 어느 것인지 파일 이름으로만 구분되는 경우
  • 처리 후에 원본을 덮어써 이전 상태를 알 수 없는 경우

문서 형태로만 남아 있는 기록이라면 사내 문서 검색처럼 문서를 근거로 답하게 만드는 접근이 먼저 맞을 수 있습니다. 조건으로 걸러내고 집계해야 하는 일이라면 문서 검색이 아니라 항목이 정해진 데이터가 필요합니다.

한 가지 분명히 해 둘 것이 있습니다. 기록이 쌓이면 모델이 알아서 똑똑해지는 것은 아닙니다. 모델 자체를 데이터로 학습시키는 영역은 빌드업웍스가 직접 수행하지 않습니다. 여기서 기록이 필요한 이유는 학습이 아니라, 자동 처리가 참조할 근거와 사후에 확인할 이력이 있어야 하기 때문입니다.

한 가지 더 밝혀 둡니다. 여기서 말한 「기록 체계 만들기」도 저희가 맡는 일에 포함됩니다. 그래서 이 문단은 저희에게 유리한 방향의 조언이기도 합니다. 다만 순서 자체는 뒤집히지 않습니다 — 기록 없이 자동화를 먼저 붙이면 결과를 확인할 방법이 없습니다.

우리 조직의 데이터와 준비 상태를 먼저 확인하고 싶으시면 AI 준비도 진단으로 현재 위치를 점검하실 수 있습니다.

판단이 들어가는 업무를 전부 뺄 필요는 없습니다

판단이 들어가는 업무를 자동화 후보에서 전부 뺄 필요는 없습니다. 나눠야 할 것은 판단의 유무가 아니라 판단의 종류입니다.

기준이 있고 그 기준을 적용하는 판단이라면 자동으로 처리할 수 있습니다. 기준 자체가 매번 새로 만들어지는 판단이라면 사람이 해야 합니다. 「지난달과 같은 조건이면 승인」은 기준을 적용하는 판단이고, 「이 거래처와 계속 갈지」는 기준이 매번 새로 만들어지는 판단입니다. 실제 업무는 두 종류가 한 흐름 안에 섞여 있는 경우가 많고, 그래서 업무 전체를 통째로 넣거나 빼는 대신 단계로 잘라 보는 것이 필요합니다.

자료를 모으고 정리하고 초안을 만드는 앞 단계는 기준을 적용하는 일에 가깝습니다. 최종적으로 나가느냐 마느냐를 정하는 단계는 기준이 새로 만들어지는 일에 가깝습니다. 앞 단계를 자동으로 진행하고 마지막에 사람이 확인하는 구조가 승인 게이트입니다.

게이트를 어디에 둘지는 되돌림 비용으로 정합니다. 실행 후 되돌리기 어려울수록 게이트를 앞에 둡니다. 되돌리는 데 부담이 없는 처리라면 게이트 없이 진행하고 사후 점검으로 대신할 수 있습니다.

게이트를 설계할 때 함께 정할 것이 세 가지 있습니다.

  • 승인 화면에 무엇을 함께 보여줄 것인가 — 판단에 필요한 근거가 같은 화면에 없으면 담당자는 원래 자료를 다시 열게 되고, 게이트는 지켜지지 않습니다.
  • 처리 이력을 어떻게 남길 것인가 — 무엇이 자동으로 처리됐고 누가 무엇을 승인했는지 남아 있어야 사후에 원인을 찾을 수 있습니다.
  • 게이트가 형식만 남았는지 무엇으로 확인할 것인가 — 올라온 건이 사실상 전부 그대로 통과하고 있다면 게이트가 아니라 통과 절차이므로, 승인 기준을 다시 정해야 합니다.

승인 게이트가 필요한 업무는 「자동화하면 안 되는 업무」가 아니라 「설계를 더 해야 하는 업무」입니다. 후보에서 빼지 마시고, 게이트 위치를 정하는 항목으로 옮겨 두십시오.

후보가 여러 개라면 세 가지로 순서를 정합니다

자동화 후보가 여러 개일 때는 빈도, 기준의 명확도, 되돌림 비용 세 가지를 함께 봅니다. 하나만 보면 순서가 어긋납니다.

  • 빈도 — 자주 발생할수록 같은 노력으로 돌아오는 것이 큽니다.
  • 기준의 명확도 — 문서로 적힌 규칙이 이미 있다면 착수가 빠르고, 결과 검증도 쉽습니다.
  • 되돌림 비용 — 잘못 처리해도 되돌릴 수 있는 업무를 먼저 하면, 첫 대상에서 배우는 비용이 작습니다.

세 가지를 놓고 보면 대체로 빈도가 높고, 기준이 이미 적혀 있고, 실수해도 되돌릴 수 있는 업무가 첫 대상으로 남습니다. 반대로 빈도가 높다는 이유만으로 되돌리기 어려운 업무를 첫 대상으로 잡으면, 첫 시도의 실패가 그대로 사고가 됩니다.

첫 대상은 좁게 잡으시길 권합니다. 한 부서의 한 업무, 그중에서도 표준 처리 경로 하나로 시작하면 결과를 사람이 직접 확인할 수 있습니다. 확인 가능한 범위에서 한 번 돌려 본 뒤에 넓히는 편이, 처음부터 여러 업무를 함께 얹는 것보다 되돌리기 쉽습니다.

후보 목록을 정리하기 전에 우리 업무 전반의 상태부터 보고 싶으시면 1분 업무 시스템 진단에서 시작하실 수 있습니다.

빌드업웍스가 하는 일과 하지 않는 일

빌드업웍스가 직접 수행하는 일은 이미 제공되는 AI 모델을 업무 시스템에 통합하는 것입니다. 처리 흐름을 단계로 나누고, 승인 게이트를 두고, 처리 이력이 남도록 설계하는 AI · 앱 개발 범위의 작업입니다. 기록이 흩어져 있다면 그 기록을 모으고 항목을 정리하는 일도 같은 범위에서 함께 진행합니다.

직접 수행하지 않는 영역도 분명히 해 두겠습니다. AI/ML 모델 개발과 학습, 데이터 사이언스 컨설팅, 커스텀 알고리즘 개발은 빌드업웍스가 직접 하지 않고 전문 파트너를 연결해 드립니다. 검토 초기에 어느 쪽이 필요한 과제인지 먼저 가리는 편이, 진행 도중에 범위가 어긋나는 것보다 낫습니다.

구축 범위별 금액 기준은 요금 안내에서 확인하실 수 있습니다.

읽는 것보다 눌러 보는 편이 빠릅니다. 아래 데모에서 자동 처리와 사람 승인이 한 흐름 안에서 어떻게 나뉘는지 먼저 보시고, 우리 업무 목록에 적용할 수 있을지 판단이 필요하시면 상담 신청으로 연락 주십시오.

작성 빌드업웍스 기술팀 최초 작성 2026-07-21 최종 검토 2026-07-21
이 글의 순서
FAQ

자주 묻는 질문

반복 횟수가 많으면 자동화 대상으로 봐도 되나요?

확인해 보시길 권하는 방법이 하나 있습니다. 최근 처리한 건 몇 개를 담당자별로 나란히 놓고 산출물이 서로 같은 형태인지 보는 것입니다. 형태가 갈린다면 그 업무에는 아직 공유된 처리 기준이 없다는 뜻이고, 자동화를 붙인다고 해서 기준이 새로 생기지는 않습니다. 반대로 누가 처리해도 결과가 같은 형태로 나온다면 기준이 이미 작동하고 있는 것이므로, 그 기준을 글로 옮기는 일부터 시작하시면 됩니다.

종이로만 남은 기록은 스캔해서 넣으면 되나요?

스캔은 보관 형태를 바꾸는 일이지 데이터를 만드는 일과는 다릅니다. 이미지 파일이 쌓이면 사람이 열어 읽을 수는 있지만 조건으로 걸러내거나 집계할 수는 없습니다. 지난 기록을 소급해 입력하는 일은 대체로 품이 많이 들기 때문에, 과거를 되살리기보다 앞으로 발생하는 건부터 정해진 항목으로 남기기 시작하는 편이 현실적입니다.

승인 게이트를 넣으면 결국 사람 손이 그대로 남는 것 아닌가요?

게이트에서 사람이 하는 일은 자료를 모으고 정리하는 일이 아니라 확인하고 결정하는 일입니다. 앞 단계에서 필요한 자료가 이미 모여 있고 판단 근거가 정리된 상태로 올라온다면, 같은 결정을 훨씬 짧은 시간에 내릴 수 있습니다. 다만 올라온 모든 건을 사람이 그대로 통과시키고 있다면 게이트가 형식만 남은 것이므로, 승인 기준을 다시 정해야 합니다.

AI 모델을 우리 데이터로 학습시켜 주시나요?

모델을 학습시키는 일과 모델을 가져다 쓰는 일은 다른 과제이고, 업무 자동화 요청의 상당수는 뒤쪽에 해당합니다. 빌드업웍스가 직접 맡는 범위는 뒤쪽입니다. 모델 자체를 개발하거나 학습시키는 영역, 데이터 사이언스 컨설팅, 커스텀 알고리즘 개발은 직접 수행하지 않고 전문 파트너를 연결해 드립니다. 어느 쪽이 필요한 과제인지는 검토 초기에 가려 드리므로, 그 판단을 미리 하셔야 하는 것은 아닙니다.

한 팀에게, 끝까지 맡겨 보세요

개선하고 싶은 업무를 한 줄만 남겨주세요. 무엇을 어떻게 만들 수 있는지 먼저 정리해 알려드립니다.