Q1업무 자동화, 어디서부터 시작해야 하나요?
도구를 고르는 것이 아니라, 지금 어떻게 일하고 있는지를 그리는 것에서 시작합니다.
무엇을 자동화할지 정하려면 무엇을 하고 있는지부터 알아야 합니다. 업무를 활동 단위로 나누고, 각 활동마다 네 가지를 적습니다 — 무엇이 들어오는가(입력), 무엇이 나가는가(산출), 어떤 규정·기준이 그 판단을 묶는가(통제), 누가 또는 무엇으로 수행하는가(수단). 이 네 칸이 채워지면 자동화 후보는 대부분 저절로 드러납니다.
- 대상 범위 정하기 — 회사 전체가 아니라 업무 한 갈래부터. 넓게 잡으면 끝나지 않습니다.
- 현행 프로세스 모델링 — 지금 어떻게 일하는지를 몇 장의 그림에 담습니다.
- 후보 발굴·우선순위 — 그림 위에서 적용 지점과 기대효과를 짚습니다.
- 작게 검증(PoC) — 한 활동에 먼저 얹어 실제로 되는지 확인합니다.
- 구축·내재화 — 확산하고, 직원이 스스로 이어가도록 정착시킵니다.
이 순서를 건너뛰고 도구부터 고르면, 도구는 들어왔는데 놓을 자리가 없는 상태가 됩니다. 아래 Q2가 그 이야기입니다.
Q2AI를 도입했는데 현장에서 쓰지 않습니다. 왜 그런가요?
기술이 부족해서가 아니라, 그 AI가 업무 구조의 어느 자리에 놓여야 하는지가 정해지지 않았기 때문인 경우가 대부분입니다.
요즘 AI는 어지간한 문서는 읽고, 요약하고, 분류합니다. 그런데도 겉도는 이유는 자리 때문입니다. 전체 구조가 그려져 있지 않으면 AI는 ‘어딘가 편해 보이는 자리’에 놓이는데, 그런 자리는 대개 정말로 바꿔야 할 자리가 아닙니다.
또 하나 흔한 원인은 기존 승인·검증 절차와의 관계를 정하지 않은 것입니다. AI가 1차 처리를 해도 결재선이 그대로면 담당자가 결과를 다시 확인하게 되고, 결국 일이 하나 더 늘어납니다. “쓰긴 쓰는데 결국 사람이 다시 본다”는 말이 나오는 자리가 여기입니다.
더 자세한 이야기는 인사이트 왜 프로세스가 먼저인가에 정리했습니다.
Q3업무 절차서나 매뉴얼이 없는데도 자동화가 가능한가요?
가능합니다. 문서가 없으면 담당자의 말에서 시작합니다.
실제로 (재)벤처캐피털타운의 기업 IR 지원 업무는 참고할 절차서가 전혀 없는 상태에서 시작했습니다. 대표와 수석 컨설턴트를 인터뷰하며 활동 하나하나와 그 입력·통제·산출·수단을 확인해 모델을 세웠습니다. 사람 머릿속에만 있던 일하는 법도, 절차만 있다면 그림이 됩니다.
오히려 문서가 없는 조직일수록 먼저 그려 둘 이유가 큽니다. 업무 지식이 사람에게만 붙어 있으면 담당자가 떠날 때 함께 사라지기 때문입니다.
이미 절차서가 있다면 그것을 읽혀 초안 모델을 만듭니다. 국토교통부 「공항 비상계획 업무매뉴얼」(약 6.5만 자)을 바탕으로 비상 대응 체계를 모델링한 사례가 그렇습니다. 두 사례 모두 모델링 사례에서 보실 수 있습니다.
Q4데이터가 정리되어 있지 않은데 AI부터 도입해도 되나요?
데이터가 문제인 것은 맞지만, 대개 원인이 아니라 결과입니다.
데이터는 언제나 어떤 일의 결과로 생깁니다. 그 일이 무엇이고 누가 어떤 기준으로 하는지가 정의돼 있지 않으면, 데이터는 쌓여도 무엇을 뜻하는지 알 수 없는 숫자가 됩니다. 같은 이름의 항목이 부서마다 다른 뜻으로 쓰이는 일이 흔한 것도 그 때문입니다.
따라서 데이터 정비와 프로세스 정의는 함께 가되, 뜻을 정하는 쪽이 앞섭니다. 활동의 산출이 무엇인지 정해지면 그 산출이 곧 데이터의 정의가 됩니다.
Q5어떤 업무를 먼저 자동화해야 하나요? 우선순위 판단 기준이 있나요?
프로세스 모델의 네 면(입력·통제·산출·수단)을 단서로 읽습니다.
규정·기준서·체크리스트가 이미 글로 있는 일입니다. 판단의 근거가 밖에 나와 있으므로 AI가 1차 판단을 맡기에 가장 안전합니다.
같은 일을 사람이 매번 손으로 하는 자리입니다. 다만 Q6의 단서를 반드시 함께 봅니다 — 반복이 곧 자동화 후보는 아닙니다.
세 부서가 각자 만들던 같은 보고서가 그림 위에서 겹쳐 보이는 순간, 통합이 곧 개선입니다. AI를 얹기 전에 없앨 수 있는 일입니다.
연결이 끊긴 자리입니다. 여기는 AI를 얹을 곳이 아니라 프로세스를 고쳐야 할 곳입니다. 끊긴 채로 자동화하면 끊김이 굳어집니다.
네 번째 단서가 중요합니다. 프로세스를 그리는 일의 성과는 AI를 얹을 자리를 찾는 것만이 아닙니다. 오히려 AI 없이도 당장 고칠 수 있는 것들이 먼저 드러나는 경우가 많습니다.
Q6자동화하면 안 되는 업무도 있나요?
있습니다. 특히 반복이 곧 자동화 후보는 아닙니다 — 그 반복이 실은 검증 장치인 경우가 있습니다.
| 이런 자리 | 왜 손대면 안 되나 |
|---|---|
| 반복이 곧 검증인 일 | 사람이 매번 손으로 옮겨 적는 과정에서 오류가 걸러지고 있었다면, 없애는 순간 오류가 그대로 흘러갑니다. 무엇을 검증하고 있었는지 먼저 확인합니다. |
| 연결이 끊긴 자리 | 산출을 받는 곳이 없거나 입력이 어디서 오는지 모르는 활동. 자동화 대상이 아니라 프로세스를 고쳐야 할 곳입니다. |
| 책임이 사람에게 있어야 하는 판단 | 결과에 대한 책임 소재가 명확해야 하는 승인·판정. 보조는 시키되 결정은 남깁니다. |
| 빈도가 아주 낮은 일 | 반기 1회짜리 업무를 자동화하면 만드는 비용과 유지하는 비용이 절감분을 넘습니다. |
빌 게이츠가 남긴 말입니다 — 효율적인 업무에 자동화를 적용하면 효율이 커지고, 비효율적인 업무에 적용하면 비효율이 커진다. 자동화는 잘못을 없애 주지 않고, 더 빨리 더 많이 저지르게 만듭니다. 결재가 세 단계 겹친 절차를 그대로 자동화하면 겹친 결재가 자동으로 세 번 돌고, 이제는 왜 세 번인지 묻는 사람조차 없어집니다.
Q7RPA·챗봇·LLM·AI 에이전트는 무엇이 다르고 언제 쓰나요?
도구를 비교해서는 고를 수 없습니다. 그 활동의 어느 면을 대신할 것인지가 정해져야 도구가 정해집니다.
| 도구 | 하는 일 | 맞는 자리 |
|---|---|---|
| RPA | 사람이 하던 화면 조작을 정해진 순서대로 대신함 | 규칙이 고정된 반복 입력·전송. 화면이 바뀌면 다시 만들어야 합니다. |
| 챗봇 | 정해진 범위의 문의에 응답 | 질문 유형이 반복되는 안내·접수 창구. |
| LLM | 문서를 읽고 쓰고 분류·요약 | 서류 검토, 초안 작성, 자료 정리. 통제가 문서로 있는 활동에 특히 강합니다. |
| AI 에이전트 | 여러 단계를 스스로 판단하며 도구를 호출 | 절차가 길고 분기가 있는 업무. 대신 절차가 정의되어 있어야 맡길 수 있습니다. |
공통점이 보이실 겁니다. 어느 도구든 그 일이 무엇을 받아 무엇을 내놓고 어떤 기준을 따르는지가 정해져 있어야 붙습니다. 그래서 도구 선정은 언제나 프로세스 정의 다음입니다.
Q8그냥 AI에게 “우리 회사 업무를 자동화해 줘”라고 물으면 안 되나요?
일반론은 나오지만 그 회사의 답은 나오지 않습니다.
AI가 그 조직의 활동이 무엇을 받아 무엇을 내놓는지, 어떤 규정이 그 판단을 묶는지, 누가 수행하는지를 모르기 때문입니다. 모르는 상태에서 나오는 답은 어느 회사에나 해당되는 말이고, 어느 회사에도 그대로 적용되지 않습니다.
반대로 그 구조를 기계가 읽는 형식으로 건네주면 AI는 아주 잘합니다. 그래서 프로세스 모델은 그림이 목적이 아니라 AI에게 줄 입력이 됩니다. 지도를 먼저 주어야 내비게이션이 길을 안내할 수 있는 것과 같습니다.
Q9업무 프로세스 모델링, IDEF0란 무엇인가요?
업무를 활동 단위로 나누고, 각 활동의 입력·통제·산출·수단을 정해진 문법으로 적는 국제표준 업무 설계 표기법입니다.
| 네 면 | 뜻 | 예 |
|---|---|---|
| 입력 (I) | 변환되는 대상 | 입고 원자재, 고객 요청서 |
| 통제 (C) | 지켜야 할 규칙·기준 | 검사 기준서, 사내 규정, 법령 |
| 산출 (O) | 만들어진 결과 | 검사 성적서, 승인 결과 |
| 수단 (M) | 수행하는 사람·시스템 | 품질관리 담당자, ERP |
1970년대 미 공군이 채택한 SADT에서 출발해 1993년 미 연방표준 FIPS PUB 183, 1998년 IEEE 표준을 거쳐 2012년 국제표준 ISO/IEC/IEEE 31320-1이 되었습니다. 자유로운 그림이 아니라 문법이 있기 때문에 사람도 읽고 기계도 읽습니다 — 그 점이 자동화의 토대가 됩니다.
계보와 원칙은 IDEF0란 무엇인가, 실행 절차는 백서 IDEF0 기능 모델링에 자세히 정리했습니다.
Q10플로우차트나 BPMN과는 무엇이 다른가요?
플로우차트·BPMN은 순서를 그리고, IDEF0는 변환과 통제를 그립니다.
자동화 후보를 가릴 때 결정적인 정보는 “다음에 무엇을 하는가”가 아니라 “무엇이 이 판단을 묶고 있는가(통제)”와 “누가·무엇으로 하고 있는가(수단)”입니다. 그래서 어디에 무엇을 얹을지 정하는 앞단에서는 IDEF0가 유리합니다.
둘은 배타적이지 않습니다. 전체 구조를 IDEF0로 잡고, 개별 절차의 실행 순서를 BPMN으로 상세화하는 조합이 자연스럽습니다. 지도를 먼저 그리고 그 위에 노선을 얹는 셈입니다.
Q11기간과 비용은 얼마나 드나요?
범위에 따라 크게 다릅니다. 크기를 가늠하는 단위는 도메인 수입니다.
부서 하나의 핵심 업무 한 갈래를 최상위 구조(A-0)와 그 아래 한 단계(A0)까지 그리는 것이 최소 단위입니다. 실제 사례에서는 담당자 인터뷰 두세 시간과 그 내용을 반영해 정리하는 기간으로 한 갈래가 완성되었습니다. 여러 부서에 걸치거나 규정·기준이 복잡하면 그만큼 늘어납니다.
비용은 어느 길을 택하느냐로 갈립니다. AIMS로 직접 그리면 도구 사용료만 들고, 컨설턴트가 현장을 함께 보는 경우에는 대상 범위를 확인한 뒤 산정합니다. 먼저 업무 한 갈래로 작게 시작해 보시길 권합니다 — 그 한 갈래에서 나오는 개선점만으로 판단이 서는 경우가 많습니다.
Q12컨설팅을 받아야 하나요, 직접 할 수 있나요?
두 가지 길이 있고, 규모와 복잡도로 갈립니다.
| 선택 | 이런 경우에 |
|---|---|
| 직접 그린다 (AIMS) | 업무 한 갈래를 먼저 정리해 보고 싶다 / 절차서가 이미 있다 / 사내에서 반복해 쓰고 싶다. 절차서를 올리면 초안 모델이 나오고, 없으면 대화로 설명하면 AI가 받아 적습니다. |
| 컨설턴트와 함께 한다 | 여러 부서에 걸쳐 있다 / 규정·기준이 복잡하다 / 모델을 근거로 조직의 의사결정을 해야 한다 / AI 전환 로드맵과 구축까지 이어가야 한다. |
IDEF0는 문법이 있는 표기라 혼자 익혀 표준에 맞는 모델을 그리기가 쉽지 않습니다. 그래서 유명소프트는 AI가 대신 받아 적는 길을 열어 두었습니다 — 그것이 AIMS(idef0.ai)입니다.
Q13프로세스 모델을 만들고 나면 그다음엔 무엇을 하나요?
그리는 데서 끝나지 않습니다. 얹고, 검증하고, 남는 데까지 갑니다.
- 프로세스 정형화 — 현행 업무를 모델로 그립니다. 산출물 · A-0 / A0 다이어그램
- AI 전환 진단 — 모델 위에서 적용 지점과 기대효과를 발굴합니다. 산출물 · AI 기회 리포트
- 로드맵 · PoC — 우선순위와 투자를 정하고 작게 만들어 검증합니다. 산출물 · 전환 로드맵
- 구축 · 내재화 — 실행하고, 직원이 스스로 이어가도록 정착시킵니다. 산출물 · 사내 역량
잘 그려진 모델이 아무도 열어 보지 않는 캐비닛에 들어가는 결말이 가장 흔한 실패입니다. 그래서 IDEF0는 모델의 첫 장에 목적과 관점을 반드시 적게 합니다. 무엇에 쓸지 적지 못하면 아직 그릴 때가 아니라는 뜻입니다. 또한 모델은 개인의 산출물로 두지 않고 조직이 검토·합의·승인해 공식본으로 확정해야 비로소 자산이 됩니다.
Q14지금 당장 해 볼 수 있는 첫걸음은 무엇인가요?
업무 한 갈래를 골라 30분만 적어 보십시오.
활동을 다섯에서 일곱 개로 나누고, 각 활동마다 네 칸을 채웁니다 — 무엇이 들어오는가 / 무엇이 나가는가 / 어떤 규정·기준을 따르는가 / 누가 또는 무엇으로 하는가.
이때 채워지지 않는 칸이 바로 문제 지점입니다. 산출을 아무도 받지 않거나, 따르는 기준을 아무도 말하지 못하는 자리가 나오면 그곳은 자동화할 자리가 아니라 먼저 고쳐야 할 자리입니다. 그 한 장이 AI를 어디에 얹을지 정하는 첫 근거가 됩니다.
AIMS와 대화만 하셔도 됩니다. 어떻게 일하는지 이야기하면 AI가 받아 적어 국제표준 모델로 만들어 드립니다. 준비물은 필요 없습니다.
AI를 어디에 얹을지 고민 중이시라면, 먼저 지도부터 그려 보시길 권합니다.
업무 절차서가 없어도 괜찮습니다 — 설명만 하시면 AI가 받아 적습니다.