워크플로우란? 정의, 유형, 병목 찾는 법

워크플로우란 입력을 결과물로 바꾸는 반복 가능한 작업 순서입니다. 작업이 시작되는 순간부터 끝나는 순간까지 각 단계에 담당자나 시스템이 정해져 있습니다. 예를 들어 청구서가 들어오고, 발주서와 대조되고, 승인을 거쳐 지급되는 흐름이 바로 워크플로우입니다. 물려받은 워크플로우가 복잡해서 워크플로우란 무엇인지 찾고 있다면, 더 유용한 질문은 "이것을 어떻게 문서화하나?"가 아니라 "어느 단계가 전체를 제한하나?"입니다. 이 글은 두 질문에 모두 답합니다.

워크플로우란 한 문장으로 무엇인가?

워크플로우는 입력을 출력으로 바꾸는 반복 가능한 작업, 인계, 판단의 경로입니다. TechTarget은 모든 워크플로우를 세 부분으로 나눕니다. 입력(트리거 또는 재료), 변환(수행되는 작업), 출력(다음 단계로 넘어가거나 업무를 마감하는 결과)입니다.

이 세 부분의 틀은 포스트잇에 적어 두기 좋습니다. 어떤 단계의 입력, 작업, 출력을 말할 수 없다면, 그 단계는 아직 정의되지 않은 것입니다.

각 부분이 중요한 실무적 이유는 다음과 같습니다.

• 입력: 단계가 시작되기 전에 반드시 존재해야 하는 것 (서명된 주문서, 티켓, 원자재 부품)

• 변환: 사람이나 시스템이 실제로 하는 일 (확인, 승인, 조립, 라우팅)

• 출력: 단계를 떠나는 것과 그다음으로 받는 담당자

출력을 정의하지 않으면 사무실에서 흔히 생기는 실패가 나옵니다. 한 책상에서는 업무가 "끝났다"고 처리되는데, 다음 단계의 누구도 그 업무를 넘겨받는 방법을 모르는 상황입니다.

워크플로우와 프로세스는 실제로 다른가?

사람들은 두 단어를 섞어 씁니다. 일상 대화에서는 괜찮지만, 운영 업무에서는 구분하면 도움이 됩니다. 프로세스(process)는 정책, 역할, 도구, 지표를 포함해 결과가 만들어지는 전체 체계입니다. 워크플로우는 그 체계 안에서 개별 항목 하나가 밟아 가는 구체적인 경로입니다.

예를 들어 물류센터에는 주문에서 출하까지의 프로세스가 있습니다. 주문 한 건의 워크플로우는 접수, 피킹, 포장, 라벨링, 적재 순서입니다. 프로세스에는 교대 인력 배치, 택배사 마감 시간, 반품 규칙도 들어 있습니다. 이 규칙들은 워크플로우의 모양을 결정하지만, 주문 자체가 거쳐 가는 단계는 아닙니다.

왜 중요할까요? 워크플로우는 항목 단위로(이 주문은 얼마나 걸렸나?), 프로세스는 전체 합계로(이 센터는 시간당 몇 건을 출하하나?) 측정하기 때문입니다. 이 둘을 섞으면 팀은 평균값을 두고 논쟁하는데, 정작 한 건의 주문은 3일 동안 멈춰 있는 상황이 생깁니다.

현장에서 실제로 만나는 워크플로우 유형은 무엇인가?

운영 팀이 마주치는 대부분의 워크플로우는 세 가지 형태로 나뉩니다.

순차형 워크플로우. A 다음 B, 그다음 C입니다. 대출 승인과 발주서 대조가 이 방식입니다. 각 단계는 앞 단계를 기다리므로, 느린 단계 하나가 뒤의 모든 단계를 지연시킵니다.

규칙 기반 워크플로우. 여전히 순차적이지만, 조건에 따라 경로가 갈립니다. 정해진 금액 이하의 경비는 자동 승인되고, 그 이상은 관리자에게 넘어갑니다. 분기가 핵심입니다. 누가 무엇을 보는지를 한 번 문서로 정해 두는 것입니다.

상태 기계형 워크플로우. 항목은 어떤 상태(열림, 검토 중, 차단됨, 완료)에 머물다가 이벤트가 발생하면 다음 상태로 넘어갑니다. 고객지원 티켓과 소프트웨어의 풀 리퀘스트가 이렇게 움직입니다. "검토 중"에서 "열림"으로 되돌아가는 경우가 있어 엄밀하게 직선형은 아닙니다.

대부분의 실제 운영은 세 형태를 섞어 씁니다. 위의 청구서 흐름은 불일치가 나타나기 전까지는 순차형이고, 이후에는 자체 순환 고리를 가진 "분쟁 중" 상태가 있는 상태 기계형이 됩니다. 먼저 정상 경로를 그리고, 그다음 예외를 추가하세요. 첫날부터 모든 예외를 그리려는 팀은 지도를 끝내지 못합니다.

제대로 돌아가는 워크플로우는 현장에서 어떻게 보이는가?

현장에서 좋은 워크플로우는 따분해 보입니다. 주문이 들어오고, 다음 담당자는 자기가 무엇을 받았는지 알고, 아무도 "이거 누구 건이죠?"라고 묻지 않습니다. 확인 방법은 간단합니다. 스톱워치와 마커를 들고 경로를 따라가면서, 항목이 움직이지 않고 기다리는 지점을 적어 보세요.

기다림이 핵심 신호입니다. 대부분의 워크플로우에서 항목이 실제로 작업되는 시간은 시스템 안에 머무는 전체 시간의 작은 부분입니다. 나머지는 대기열입니다. 트레이, 받은편지함, 임시 적재 라인에 쌓여 있는 시간입니다. 공정 사이클 효율(PCE, 전체 리드타임 중 부가가치를 만드는 작업이 차지하는 비율)이 25% 미만이라면, 설비를 더 사기 전에 낭비를 먼저 찾아야 한다는 뜻인 경우가 보통입니다.

워크플로우가 그냥 존재하는 것과 실제로 돌아가는 것을 구분하는 특징은 네 가지입니다.

• 명확한 트리거 하나. 작업이 누군가 기억해서가 아니라 이유가 있어서 시작됩니다.

• 단계마다 담당자 한 명. 공동 책임은 책임이 없는 것과 같습니다.

• 정의된 "완료". 출력에 확인 가능한 조건이 있어서, 다음 단계가 대화 없이 시작할 수 있습니다.

• 보이는 대기열. 지금 각 단계에서 몇 건이 기다리는지 묻지 않고도 볼 수 있습니다.

워크플로우는 어디서 깨지는가? 전체를 제약하는 단계를 찾으세요

모든 워크플로우에는 라인 전체의 속도를 정하는 단계가 하나 있습니다. 이것이 병목(전체 라인의 처리량을 제한하는 단계, 즉 goulot d'étranglement)입니다. 다른 단계의 속도를 높여도 전체 산출량은 움직이지 않습니다. 병목을 10% 늦추면 워크플로우 전체가 약 10% 손해를 봅니다.

리틀의 법칙(Little's Law)이 이 계산을 해 줍니다. 먼저 변수를 정의합니다. WIP는 어떤 시점에 워크플로우 안에 있는 항목 수, 처리량은 단위 시간당 완료되는 항목 수, 사이클 타임은 항목 하나가 시작부터 끝까지 걸리는 평균 시간입니다.

WIP = Throughput x Cycle Time

고객지원 큐가 하루 40건의 티켓을 완료하고, 티켓 하나가 열림부터 종료까지 평균 3일 걸린다고 가정해 봅시다. 그러면 진행 중인 티켓(WIP)은 120건입니다. 처리량은 40건으로 그대로인데 WIP가 200건으로 늘어나면, 사이클 타임은 조용히 5일로 늘어납니다. 업무 방식은 바뀌지 않았습니다. 대기열이 처리하지 못하는 단계 앞에서 커진 것입니다.

위 사진이 병목의 전형적인 모습입니다. 한 작업대 앞에는 물건이 쌓여 있고, 그 뒤 작업대는 놀고 있습니다. 같은 패턴은 소프트웨어 파이프라인(리뷰 대기열은 불어나는데 배포 단계는 쉬는 경우)이나 HR 온보딩 흐름(채용 제안은 쌓이는데 신원 조회에서 막히는 경우)에서도 볼 수 있습니다.

컨설턴트 없이 제약 단계를 찾는 순서는 다음과 같습니다.

1. 단계를 순서대로 나열하고, 각 단계의 담당자를 적습니다.

2. 각 단계가 현실적인 속도로 시간당 몇 건을 완료할 수 있는지 기록합니다.

3. 숫자를 비교합니다. 가장 낮은 값이 제약 단계 후보입니다.

4. 대기열을 확인합니다. 그 단계 바로 앞에서 대기 물량이 늘고 있다면 후보가 확정됩니다.

5. 그다음에야 결정합니다. 그 단계에 용량을 더할지, 낭비를 제거할지, 작업을 그 단계에서 빼낼지 정하세요.

이 대목에서 계산기가 힘을 발휘합니다. 단계별 용량을 도구에 입력하면 AI 분석 배지가 결과를 읽고, 제약 단계의 이름을 짚고, 용량을 더하면 효과가 있는 곳과 없는 곳을 평이한 말로 알려 줍니다. 숫자를 입력하세요. AI가 어디에 손을 대야 할지 알려 줍니다.

워크플로우를 돌리려면 소프트웨어가 필요한가?

아닙니다. 화이트보드와 스톱워치만 있어도 첫 번째 병목을 찾을 수 있습니다. 소프트웨어가 빛을 발하는 시점은 워크플로우가 하루에 수백 번 반복되고 인계가 디지털로 이루어질 때입니다. 그 경우 사람이 메시지를 옮겨 전달하는 일 자체가 지연이 되기 때문입니다.

시장도 이 문제에 돈을 쓰고 있습니다. TechTarget이 인용한 2023년 Reportlinker 보고서는 워크플로우 관리 시스템 시장이 2022년 $6.65B 규모였고, 2030년에는 $46.47B에 이를 것으로 전망했습니다. 벤더들이 이 문제를 쫓고 있다는 뜻입니다. 그렇다고 여러분의 문제에 플랫폼이 필요하다는 뜻은 아닙니다.

한 가지 원칙을 기억하세요. 단계가 병목이거나 병목에 가깝다는 것을 확인한 뒤에만 자동화하세요. 여유 용량이 있는 단계를 자동화하면 더 그럴듯해 보이는 프로세스와 같은 산출량을 얻게 됩니다.

운영 팀이 자동화에 나설 때 자주 등장하는 도구는 네 가지입니다.

Zapier는 비개발자 팀이 가장 쉽게 시작할 수 있는 도구입니다. 한 앱에서 트리거가 발생하면 다른 앱에서 액션을 실행합니다. 과금은 작업 건수 기준이라 단계가 많은 워크플로우는 물량이 늘수록 비용이 커집니다. 분기가 많은 고물량 흐름이라면 다른 도구를 고려하세요.

Make는 워크플로우를 라우터와 오류 처리가 있는 캔버스로 그려 줍니다. 경로가 갈라지는 규칙 기반 흐름에 잘 맞습니다. 분기를 상상하는 대신 눈으로 보고 싶다면 가치가 있습니다.

n8n은 단계마다가 아니라 워크플로우 실행 단위로 과금하며, 자체 호스팅도 가능합니다. 약간의 코드를 다룰 줄 아는 사람이 있는 팀에 맞고, 긴 흐름도 비용 부담이 적습니다.

Taskade는 프로젝트 관리와 AI 에이전트를 한 워크스페이스에 묶어 줍니다. 워크플로우가 앱끼리 데이터를 넘기는 것보다 사람들이 서로 업무를 넘기는 형태가 대부분일 때 의미가 있습니다.

네 도구 모두에 해당하는 주의점이 있습니다. 도구는 워크플로우를 구현할 뿐 고쳐 주지는 않습니다. 깨진 인계를 자동화하면 더 빨리, 새벽 3시에, 아무도 지켜보지 않는 상태에서 깨집니다.

워크플로우를 문서화하되 방치된 문서가 되지 않게 하려면?

한 페이지로 줄이고, 단계뿐 아니라 대기열도 그리세요. 좋은 워크플로우 지도는 한눈에 네 가지 질문에 답합니다. 무엇이 시작을 트리거하는가, 각 단계의 담당자는 누구인가, 항목은 어디서 기다리는가, "완료"의 의미는 무엇인가.

실제 팀에서 살아남는 형식은 다음과 같습니다.

• 맨 위에는 트리거, 맨 아래에는 완료된 결과물을 적습니다.

• 그 사이에는 단계마다 상자 하나를 두고, 담당자 이름이 아닌 역할을 적습니다. 사람은 옮겨 가니까요.

• 각 상자 옆에는 지금 그 자리에서 기다리는 항목 수를 숫자로 적습니다.

• 예외는 되돌아가는 두 번째 선으로 표시하고, 가장 흔한 두 가지에서 멈춥니다.

무언가 바뀌면 지도를 다시 검토하세요. 새 제품, 새 교대 패턴, 도구 교체가 그런 경우입니다. 지도를 1년 동안 건드리지 않았는데 업무가 바뀌었다면, 그 지도는 허구입니다.

또한 이상적인 동작을 문서화하려는 충동을 참으세요. 화요일 오후에 두 명이 자리를 비웠을 때 실제로 무슨 일이 일어나는지를 문서화하세요. 그 버전이 개선할 수 있는 버전입니다.

가장 먼저 해볼 일은 무엇인가

지금 워크플로우가 있는데 지도가 없다면, 이번 주에 한 시간을 투자하세요. 단계를 적고, 각 단계에 용량 숫자를 붙이고, 가장 낮은 값을 찾으세요. 그 단계 앞에 대기열도 가장 길다면, 병목을 찾은 것입니다. 다른 곳에 쓰는 돈과 시간은 모두 추측이 됩니다.

가장 낮은 용량의 단계와 가장 긴 대기열이 서로 다른 곳을 가리킨다면, 대기열을 믿고 용량을 다시 측정하세요. PCE가 25% 미만으로 나온다면, 인력이나 도구를 더하기 전에 대기와 재작업부터 찾으세요. 그다음 숫자를 계산기에 넣고, AI 분석이 해결책이 용량 증설인지, 낭비 제거인지, 업무가 들어오는 방식의 변경인지 알려 주게 하세요.