- 몇 명을 줄일 수 있는지부터 묻지 마십시오. 실제 업무에서 시간이 어디서 새는지부터 보십시오.
- 일을 빠르게 만들기 전에 애초에 없어야 할 일부터 없애십시오. 그러지 않으면 필요 없는 일을 빠르게 하는 데 돈을 쓰게 됩니다.
- 인력에 관한 결정은 실제 숫자를 한 주기 동안 온전히 확인한 뒤에만 내리십시오.
1. 10명 팀을 5명으로 줄일 수 있을까
솔직하게 답하면 될 때도 있고 안 될 때도 있습니다. 곧바로 확실히 된다고 답하는 사람은 대개 실제 데이터를 본 적이 없습니다. 먼저 답할 수 있는 질문은 지금 팀의 시간이 어디에 쓰이고 있느냐입니다.
일부 업무 프로세스에서는 가능합니다. 다만 실제 업무가 무엇으로 이루어져 있는지 알기 전에 인원 목표부터 정해서는 안 됩니다. 10명 팀이 시간의 절반을 데이터 복사, 문서 작성, 진행 상황 확인에 쓰고 있다면, 사람 개입(Human Touch)을 50% 줄여 팀 규모를 줄이거나 두 배의 업무량을 감당할 수 있습니다. 반대로 업무 대부분이 협상, 현장 점검, 관계 관리라면 같은 목표는 비현실적일 수 있습니다.
출발점은 줄이고 싶은 인원수보다 필요한 처리량이어야 합니다. 예를 들어 회사가 한 달에 5,000건을 처리하고, 고객에게 15분 안에 답하고, 오류율을 1% 아래로 유지해야 한다고 해 봅시다. 그다음 시스템이 몇 건을 처리하고, 사람이 예외를 몇 건 보며, 사람의 작업 시간이 몇 시간 필요한지 설계합니다. 이렇게 계산하면 비용 절감을 일괄적으로 발표하는 것보다 훨씬 근거 있는 결정을 내릴 수 있습니다.
2. 실제 업무 기록으로 업무 흐름도 그리기
3년 전에 써 둔 문서에서 출발하지 마십시오. 시스템에 남은 흔적을 보고 실제로 일이 어떻게 흘러가는지 확인하십시오. 이 데이터는 팀이 믿고 있던 것과 꽤 다른 경우가 많은데, 바로 그 점 때문에 쓸모가 있습니다.
업무 프로세스 하나를 골라 실제 업무를 처음부터 끝까지 따라가십시오. 담당자, 여는 시스템, 들어오는 데이터, 내리는 판단, 실제 작업 시간, 대기 시간을 기록합니다. "직접 작업 시간(Touch Time)"과 "대기 시간(Wait Time)"은 따로 보십시오. 실제 작업은 40분이면 끝나는데 대기열에서 사흘을 기다릴 수 있기 때문입니다. 같은 승인을 계속 기다려야 한다면 입력 시간을 20분으로 줄여도 고객이 결과를 더 빨리 받지는 못합니다.
직원이 읽고, 요약하고, 복사하고, 형식을 바꾸고, 데이터를 찾고, 비교하고, 알림을 보내는 지점을 모두 표시하십시오. 이런 지점이 AI와 자동화의 후보입니다. 신뢰를 쌓아야 하거나, 결과에 책임을 져야 하거나, 예외를 판단해야 하는 지점은 사람에게 남겨 두십시오.
| 단계 | 확인할 질문 | 처리 방향 |
|---|---|---|
| 업무 접수 | 데이터가 여러 채널로 들어옵니까? | 데이터를 자동으로 모으고 분류 |
| 준비 | 무엇을 찾거나 복사해야 합니까? | AI가 자료를 모아 초안 작성 |
| 판단 | 규칙이 분명합니까, 예외가 많습니까? | 규칙대로 자동 처리하거나 사람에게 전달 |
| 결과물 전달 | 어떤 문서를 만들고 어느 시스템을 업데이트해야 합니까? | 워크플로가 바로 이어서 처리 |
| 후속 관리 | 누가 기억했다가 독촉합니까? | 이벤트에 따라 자동 알림 |
3. 자동화하기 전에 필요 없는 업무부터 없애기
필요 없는 단계를 자동화해 빠르게 만들어도 낭비는 낭비입니다. 모든 보고서에 실제로 읽는 사람이 있는지, 같은 데이터를 몇 번 입력하는지, 여러 단계의 승인이 정말 위험을 줄이는지 아니면 예전부터 해 오던 관행일 뿐인지, 회사에 이미 있는 정보를 고객에게 다시 보내 달라고 하지는 않는지 확인하십시오. AI를 연결하기 전에 없애고, 합치고, 표준화하십시오.
예를 들어 어떤 회사는 직원에게 영업팀, 관리자, 회계팀용으로 세 가지 형식의 요약을 만들게 합니다. 이럴 때는 AI 세 벌을 따로 만들기보다 공통 데이터 한 세트를 정하고 각 부서가 필요한 화면을 열어 보게 해야 합니다. 또 다른 회사는 거래마다 할인 승인을 받는데, 그중 80%는 표준 범위 안에 있습니다. 이 경우에는 자동 승인 범위를 정해 두는 편이 AI로 승인 요청 이메일을 더 빨리 쓰는 것보다 대기 시간을 훨씬 많이 줄입니다.
4. 실제로 통하는 Human + AI 팀 모델
업무를 세 트랙으로 나눕니다. 첫 번째는 Straight-through 트랙으로, 시스템이 표준 사례를 접수부터 완료까지 사람 손을 거치지 않고 처리합니다. 두 번째는 Review 트랙으로, AI가 모든 준비를 마치면 사람이 짧은 시간 안에 확인하고 승인합니다. 세 번째는 Exception 트랙으로, 데이터가 빠졌거나 위험이 크거나 특별 관리가 필요한 고객의 건을 전문가에게 보냅니다.
모든 업무를 억지로 자동 트랙에 넣을 필요는 없습니다. 사람이 처리해야 할 대기열을 줄이면 됩니다. 예를 들어 서비스팀이라면 표준 질문의 60%는 시스템이 종료하고, 25%는 답변을 준비해 사람이 확인하게 하고, 15%는 전문가에게 보낼 수 있습니다. 그러면 고객이 늘어도 지금과 같은 인원이 필요하지 않습니다.
팀장의 역할은 업무를 나눠 주고 진행 상황을 챙기는 일에서, 예외 대시보드를 지켜보고, 시스템이 사람에게 넘긴 이유를 분석하고, 데이터나 규칙을 손봐 자동 완결률(Straight-through Rate)을 높이는 일로 바뀝니다. 직원에게는 품질을 점검하고, 어려운 사례를 해결하고, 체계적인 피드백을 주는 능력이 필요합니다.
5. 감이 아닌 업무량으로 필요 인력 다시 계산하기
간단한 공식을 쓰십시오. 월간 업무 건수 × 건당 사람 개입 시간(분) ÷ 1인당 월간 생산적 작업 시간(분)입니다. 6,000건이 있고 기존에는 건당 12분이 걸렸다면 총 72,000분입니다. 새 시스템을 도입한 뒤 65%는 자동으로 끝나고, 25%는 확인에 3분이 걸리고, 어려운 10%는 20분이 걸린다면 사람의 업무량은 16,500분으로 줄어듭니다. 75%가 넘게 줄어드는 셈입니다.
직원에게 한 달에 160시간의 생산적인 시간이 온전히 있다고 가정하지 마십시오. 회의, 교육, 휴가, 관리 업무를 빼야 합니다. 보통은 생산적인 시간을 100~120시간 정도로 보수적으로 잡고, 성수기와 장애에 대비한 여유분(Buffer)을 더합니다. 너무 빠듯하게 계산한 시스템은 업무량이 늘거나 AI 서비스가 멈추면 무너집니다.
6. 사람들이 문제를 숨기지 않도록 전환 과정 관리하기
AI를 개선하는 데 쓰인 피드백이 곧바로 해고로 이어진다고 팀이 믿으면, 직원들은 지식을 넘기지 않거나 시스템이 제대로 작동하지 않아도 말하지 않을 이유가 생깁니다. 대표는 시범 기간, 판단 기준, 다른 역할로 옮길 기회를 분명히 밝히고 계획을 솔직하게 알려야 합니다. 지킬 수 없는 약속은 하지 말되, 공정하게 대하고 준비할 시간을 주어야 합니다.
개발팀 참고 · 기술 세부 사항
업무량이 늘어도 인원을 새로 뽑지 않는 것부터 시작하고, 가능하면 전환 배치와 자연 감소(Natural Attrition)를 먼저 활용하십시오. Process Owner, AI Quality Reviewer, Customer Specialist, Automation Coordinator 같은 새 역할을 정하고, 실제 업무와 연결된 교육을 제공하십시오. 시스템을 관리할 사람을 남기지 않고 인원을 줄이면 가동 후 몇 달 안에 성과가 떨어집니다.
인센티브는 바빠 보이는 시간 대신 사이클 타임(Cycle Time), 품질, 감당할 수 있는 고객 수 같은 팀 성과를 기준으로 정하십시오. 직원이 시스템 차원의 오류를 찾아내면 그 공을 인정해야 합니다. 그런 정보가 있어야 규모를 키우기 전에 문제를 막을 수 있습니다.
7. 시스템에 더 의존하는 작은 팀의 위험
인원이 줄면 지식과 대체 인력도 함께 사라질 수 있습니다. 시스템 장애에 대비한 런북(장애 대응 절차서), 최소한의 수작업 처리 방법, 시스템별 담당자 명단이 있어야 합니다. 외부 개발자만 전체 워크플로를 아는 상황을 만들지 마십시오. 회사는 자기 데이터를 내보낼 수 있어야 하고 자기 로그에 접근할 수 있어야 합니다.
눈에 띄지 않는 오류를 추적하십시오. AI가 분류를 잘못했는데 아무도 알아차리지 못하거나, 고객이 그럴듯하지만 문제는 해결하지 못하는 답변을 받거나, 시스템이 쉬운 업무만 골라 처리해 어려운 건이 쌓이는 경우입니다. 사람이 자동 처리된 업무를 무작위로 점검하는 샘플링 규칙을 정하고, 위험한 사례를 정기적으로 테스트하고, 처리량이 늘 때 비용도 점검하십시오.
- 시스템이 성수기를 적어도 한 번 안정적으로 넘김
- 데모 말고 몇 주에 걸친 품질 데이터가 있음
- AI, API, 기간 시스템이 멈출 때 일할 계획이 있음
- 팀 개편 후에도 업무 프로세스 책임자와 품질 검토자가 있음
8. 8주 실행 계획
- 1주 차: 업무 프로세스를 고르고 처리량, 시간, 품질, 인원의 기준선을 측정합니다.
- 2주 차: 업무 흐름도를 그리고 필요 없는 단계를 없앤 뒤 세 가지 업무 트랙을 정합니다.
- 3~4주 차: AI가 준비하고 사람이 확인하는 시스템을 만들고 과거 데이터로 테스트합니다.
- 5주 차: 작은 팀에서 시험 운영하며 실제 사람 개입 시간을 재고 예외를 기록합니다.
- 6주 차: 표준 사례에만 Straight-through 트랙을 열고 모니터링과 정지 버튼을 추가합니다.
- 7주 차: 처리 용량을 다시 계산하고 역할과 예비 근무표를 설계합니다.
- 8주 차: 데이터에 근거한 인력 계획을 세우고 확대, 조정, 중단 가운데 하나를 결정합니다.
요약: 10명 팀이 5명이 될 수 있는지는 재설계 후의 표준 업무 비율과 사람 개입 시간에 달려 있습니다. 업무 프로세스와 서비스 수준에서 출발해 반복 업무는 AI에 맡기고, 예외 트랙을 만들고, 실제 데이터로 처리 용량을 계산하십시오. 비용 절감이 오래가려면 품질과 예비 지식, 책임 소재를 함께 지켜야 합니다.
업무 프로세스를 먼저 다시 설계하고, 인원 문제는 그다음에 답합니다
실제로 쓸 수 있는 업무 흐름도는 3년 전에 써 둔 문서가 아니라 일하는 사람에게서 나와야 합니다. 그래서 저희는 과거의 실제 업무 기록으로 업무 흐름도를 만듭니다. 업무가 각 단계에 들어오고 나간 시각, 수정 횟수, 업무가 가장 오래 머문 지점처럼 시스템에 남은 흔적을 봅니다. 이 데이터는 팀이 원래 믿던 것과 꽤 다른 경우가 많은데, 바로 그 점 때문에 쓸모가 있습니다. 인원 감축을 이야기하기 전에 필요 없는 업무부터 없앱니다. 없어야 할 업무를 빠르게 만드는 데 드는 돈은 낭비이기 때문입니다.
저희가 팀장과 함께 진행하는 순서
그다음 시스템이 맡을 부분, 사람이 맡을 부분, 품질을 측정하는 방법을 분명히 정한 Human plus AI 팀 모델을 설계하고, 그 모델을 뒷받침할 시스템을 만듭니다. 작업 대기열, 승인 지점, 팀장이 매주 실제 업무량을 확인하는 대시보드가 여기에 들어갑니다. 업무 프로세스를 바꾼 뒤 적어도 한 주기의 숫자를 온전히 보기 전에는 인력에 관한 결정을 내리지 않기를 권합니다. 팀 안에서 인원을 줄일지 말지 논쟁 중이라면 먼저 실제 업무 프로세스를 한 번 측정해 보십시오.
SOFTWARE ENGINEERING GLOSSARY
소프트웨어 엔지니어링 용어집
업무 프로세스를 측정하고 다시 설계하는 일을 이야기할 때 쓰는 용어입니다.
| 용어 | 의미 | 쉬운 예시 | 개발팀에 물어봐야 할 질문 |
|---|---|---|---|
| Process Map | 담당자와 단계별 소요 시간을 함께 표시한 실제 업무 순서도 | 주문 접수부터 배송까지의 업무 흐름도 | 이 흐름도는 실제 데이터에서 나왔습니까, 인터뷰만으로 만들었습니까? |
| Bottleneck | 처리할 수 있는 양이 제한되어 전체 업무 프로세스를 느리게 만드는 지점 | 모든 업무가 한 사람의 승인을 기다림 | 지금 병목은 어디에 있고, 무엇으로 측정했습니까? |
| Wait Time | 아무도 손대지 않은 채 업무가 그냥 기다리는 시간 | 검토는 10분이면 끝나는데 서류가 이틀 동안 승인을 기다림 | 전체 소요 시간 가운데 실제 작업 시간은 몇 %입니까? |
| Capacity | 팀이나 시스템이 일정 기간에 처리할 수 있는 최대 업무량 | 팀이 일주일에 200건을 처리할 수 있음 | 업무량이 30% 늘면 무엇을 늘려야 합니까? |
| Dashboard | 주요 숫자를 한곳에 모아 현황을 빠르게 볼 수 있게 한 화면 | 팀장이 밀린 업무와 대기 시간을 주 단위로 확인합니다. | 이 화면의 숫자는 얼마나 자주 업데이트되고, 어디서 가져옵니까? |