업무 흐름 해부하기: 현재 프로세스를 눈에 보이게 만드는 워크플로 맵

자동화는 도구부터 고르는 일이 아니다. 먼저 해야 할 일은, 지금 내가 어떻게 일하고 있는지를 눈에 보이게 만드는 것이다. 많은 사람이 "이 업무를 자동화하고 싶어요"라고 말하지만, 막상 물어보면 중간 과정이 흐릿하다. 누가 시작하는지, 어디서 멈추는지, 어떤 기준으로 판단하는지, 최종 결과가 어디에 남는지 설명이 안 된다. 이 상태에서는 자동화 도구를 붙여도 오래가지 못한다.

반대로 업무 흐름을 선명하게 설명할 수 있으면 자동화 설계는 훨씬 쉬워진다. 입력이 무엇인지 알면 트리거를 정할 수 있고, 처리 방식이 보이면 AI에게 맡길 부분이 드러난다. 판단 기준이 보이면 규칙을 만들 수 있고, 승인 지점이 보이면 사람 검수를 어디에 둘지 정할 수 있다. 기록 위치가 보이면 결과를 남기는 자동화도 자연스럽게 이어진다.

이번 장에서는 업무를 여섯 단계로 분해한다. 입력, 처리, 판단, 전달, 승인, 기록이다. 이 여섯 칸만 제대로 채워도, 머릿속에 떠다니던 일이 하나의 워크플로 맵으로 바뀐다. 중요한 것은 멋진 다이어그램을 만드는 것이 아니라, "내 업무가 실제로 어떻게 움직이는지"를 말로 설명할 수 있게 되는 것이다.

왜 업무를 먼저 쪼개야 할까

사람은 자기 일을 잘 안다고 생각한다. 그런데 실제로는 "대충 이런 식으로 하지" 수준으로 기억하는 경우가 많다. 특히 반복 업무일수록 더 그렇다. 너무 익숙해서 단계가 생략되어 보이기 때문이다.

예를 들어 고객 문의에 답변하는 업무를 떠올려 보자. 겉으로 보면 단순하다. 메일이 오면 읽고 답장하면 끝이다. 하지만 실제 현장에서는 그 사이에 이런 일이 숨어 있다.

• 문의가 어디로 들어오는지 확인한다

• 고객 정보를 CRM이나 스프레드시트에서 찾는다

• 질문 유형을 분류한다

• 기존 답변 템플릿이 있는지 확인한다

• 환불, 일정 변경, 기술 이슈처럼 기준이 필요한지 판단한다

• 상급자 승인이나 다른 부서 협업이 필요한지 확인한다

• 최종 답변을 보낸다

• 처리 결과를 기록한다

겉보기에는 한 일처럼 보여도, 실제로는 여러 단계가 겹쳐 있다. 자동화는 바로 이 숨은 단계를 찾아내는 작업에서 시작된다.

업무를 쪼개는 이유는 간단하다. 자동화는 "업무 전체"를 한 번에 처리하지 못하는 경우가 많고, 대신 "단계 하나"는 아주 잘 줄여 주기 때문이다. 그러니 먼저 덩어리를 자르고, 그 안에서 자동화할 조각을 찾는 것이 맞다.

워크플로 맵은 그림이 아니라 설명서다

워크플로 맵이라고 하면 복잡한 도형부터 떠올리는 사람이 많다. 하지만 처음에는 그렇게 할 필요가 없다. 박스와 화살표가 없어도 괜찮다. 문장으로 적어도 된다. 핵심은 순서와 조건이 드러나는 것이다.

좋은 워크플로 맵은 다음 질문에 답할 수 있어야 한다.

• 무엇이 이 업무를 시작하게 만드는가

• 누가 어떤 정보를 받아서 처리하는가

• 중간에 어떤 판단이 필요한가

• 결과는 누구에게 어떻게 전달되는가

• 누가 최종 승인하는가

• 작업 흔적은 어디에 남는가

이 질문에 답할 수 있다면 이미 절반은 끝났다. 이제 그것을 여섯 단계 틀에 넣으면 된다.

여섯 단계로 분해하기: 입력, 처리, 판단, 전달, 승인, 기록

이 장의 핵심 도구는 아주 단순하다. 어떤 업무든 다음 여섯 단계로 나눠 본다.

1. 입력: 일이 시작되는 순간 찾기

입력은 업무의 출발점이다. 누가 무엇을 보내거나, 어떤 사건이 발생하거나, 특정 시간이 되면 일이 시작된다. 입력을 정확히 잡지 못하면 자동화는 첫 단추부터 흔들린다.

입력은 대개 이런 형태로 나타난다.

• 메일 수신

• 폼 제출

• 메신저 메시지 도착

• 파일 업로드

• 계약서 수신

• 회의록 생성

• 특정 날짜 도래

• 결제 완료

중요한 것은 "업무 시작 신호"를 하나로 못 박는 것이다. 예를 들어 "고객 요청이 들어오면"은 아직 모호하다. 고객 요청이 어디로 들어오는데? 메일인가, 채팅인가, 문의 폼인가, 전화 메모인가? 입력은 가능한 한 관찰 가능한 형태여야 한다.

좋은 입력 정의는 이렇게 쓴다.

"고객 문의 폼이 제출되면" "지메일에 견적 요청 메일이 도착하면" "매주 월요일 오전 9시에 지난주 매출 데이터를 불러오면"

입력이 선명해지면 자동화 도구에서 어떤 트리거를 써야 할지도 함께 보이기 시작한다.

2. 처리: 사람이 실제로 하는 손동작 적기

처리는 입력을 받은 뒤 실제로 손이 움직이는 단계다. 메일을 읽고, 문서를 열고, 내용을 요약하고, 파일명을 바꾸고, 엑셀에 붙여 넣는 작업이 모두 처리에 들어간다.

여기서 중요한 포인트는 "당연해서 생략하던 행동"까지 적는 것이다. 자동화는 당신의 눈치를 보지 못한다. 말해 준 것만 할 수 있다. 그러니 처리 단계는 친절할수록 좋다.

예를 들어 세금계산서 발행 요청 업무의 처리 단계를 적어 보면 이렇게 된다.

• 메일 제목과 첨부파일을 확인한다

• 거래처명과 사업자등록번호를 읽는다

• 기존 거래처 목록과 대조한다

• 발행 금액과 품목을 확인한다

• ERP나 회계 시스템에 입력한다

• 발행용 초안을 만든다

이 단계에서 특히 자주 발견되는 것은 복붙, 검색, 정리, 요약 같은 반복 행동이다. 이런 부분은 이후 AI나 자동화 도구로 줄이기 좋다.

3. 판단: 사람 머리가 개입하는 기준 찾기

자동화 설계에서 가장 중요한 지점이 판단이다. 많은 사람은 자기 업무의 판단 기준을 머릿속 감각으로 처리한다. "그냥 보면 알아요"라고 말하는 순간, 자동화는 멈춘다.

판단은 이렇게 드러난다.

• 이 문의는 단순 문의인가, 클레임인가

• 이 문서는 계약서인가, 제안서인가

• 이 고객은 VIP인가, 일반 고객인가

• 이 요청은 바로 처리 가능한가, 승인 필요한가

• 이 데이터는 정상 범위인가, 이상치인가

판단 단계에서 해야 할 일은 감각을 기준으로 바꾸는 것이다. 예를 들어 "급한 요청"이 아니라 "오늘 마감이고 담당 임원 참조가 포함된 요청"처럼 바꾸는 식이다. 사람이 하던 판단을 규칙, 조건, 예외로 나눠 적어야 자동화할 수 있다.

판단 기준을 적을 때는 다음처럼 문장으로 써 보면 좋다.

"문의 내용에 '환불', '불만', '법적 조치'가 포함되면 클레임으로 분류한다." "결제 금액이 100만 원을 넘으면 팀장 승인이 필요하다." "첨부파일이 없으면 회신 전에 추가 자료 요청 메일을 보낸다."

이 문장들이 곧 자동화 조건문이 된다.

4. 전달: 결과가 누구에게 가는지 확인하기

전달은 생각보다 자주 빠지는 단계다. 우리는 일을 끝내고 나면 그냥 끝난 것처럼 느끼지만, 실무에서는 결과를 누군가에게 보내야 비로소 일이 닫힌다.

전달은 다음과 같은 모습으로 나타난다.

• 고객에게 답장 메일 발송

• 슬랙 채널에 처리 결과 공유

• 팀장에게 초안 전달

• 담당 부서에 작업 요청 등록

• 구글 드라이브 폴더에 산출물 업로드

전달 단계가 중요한 이유는, 자동화의 최종 체감 효과가 여기서 발생하기 때문이다. 작성한 결과가 자동으로 메일로 가고, 요약이 자동으로 메신저에 공유되고, 후속 작업이 자동으로 생성되면 비로소 "일이 줄었다"는 감각이 생긴다.

전달 단계에서는 수신자, 전달 방식, 전달 시점을 함께 적는 것이 좋다. "보낸다"보다 "고객에게 이메일로, 확인 즉시 보낸다"가 훨씬 설계하기 쉽다.

5. 승인: 사람이 마지막에 개입하는 문 찾기

모든 업무를 100퍼센트 자동화할 필요는 없다. 오히려 많은 실무에서는 마지막 승인 한 번만 사람이 맡고, 나머지를 자동화하는 방식이 훨씬 현실적이다.

승인은 리스크를 통제하는 문이다. 돈이 오가거나, 외부로 발송되거나, 법적 책임이 생기거나, 고객 경험에 직접 영향을 주는 일이라면 승인 단계를 남겨 두는 편이 좋다.

예를 들어 이런 경우다.

• 고객 클레임 답변은 발송 전 팀장 확인

• 100만 원 이상 지출은 대표 승인

• 외부 제안서 발송 전 최종 문구 검토

• 채용 불합격 안내 메일은 인사 담당 확인

승인을 워크플로 맵에 넣는다고 해서 자동화 수준이 낮아지는 것은 아니다. 오히려 현실적인 설계가 된다. 중요한 것은 "어디까지는 자동"이고 "어디서부터는 사람 확인"인지 경계를 분명히 하는 것이다.

6. 기록: 일이 끝난 흔적 남기기

기록은 종종 가장 마지막에 생각나지만, 자동화에서는 매우 중요하다. 기록이 없으면 나중에 추적이 안 되고, 개선도 어렵다. 무엇이 처리됐는지, 누가 승인했는지, 예외는 몇 건이었는지 남아 있어야 자동화가 쌓인다.

기록은 단순 저장이 아니다. 다음 행동을 위한 기반이다. 처리 시간을 측정하고, 자주 생기는 오류를 찾고, 나중에 다시 참고할 수 있게 만든다.

기록 위치는 보통 다음 중 하나다.

• 스프레드시트

• CRM

• 프로젝트 관리 도구

• 노션 데이터베이스

• 회계 또는 ERP 시스템

• 메일 라벨이나 폴더

좋은 기록은 최소한 세 가지를 남긴다. 언제 처리했는지, 어떤 결과였는지, 누가 확인했는지다. 이 세 가지만 있어도 나중에 자동화 효과를 측정하기 훨씬 쉬워진다.

여섯 칸만 채우면 워크플로 맵이 된다

이제 실제로 하나의 업무를 여섯 칸으로 바꿔 보자. 예시로 "고객 문의 답변" 업무를 들어 보겠다.

예시 1. 고객 문의 답변 업무

입력은 고객 문의 폼 제출이다. 고객이 웹사이트 문의 페이지에 내용을 남기면 일이 시작된다.

처리 단계에서는 문의 내용을 읽고, 주문번호나 고객 정보를 확인하고, 문의 유형을 분류한다. 배송 문의인지, 환불 요청인지, 제품 사용 질문인지 나누고, 기존 답변 템플릿이 있는지 찾는다.

판단 단계에서는 환불 가능 여부, 긴급도, 담당 부서 이관 필요 여부를 결정한다. 예를 들어 환불 요청이면서 결제 후 7일 이내면 환불 프로세스로 보내고, 제품 불량 키워드가 포함되면 품질 담당자에게 이관한다.

전달 단계에서는 고객에게 1차 답변을 메일로 보내거나, 내부 담당자에게 슬랙으로 후속 조치를 요청한다.

승인 단계에서는 환불 금액이 일정 기준 이상일 때 팀장 확인을 받는다.

기록 단계에서는 CRM에 문의 유형, 처리 시간, 결과 상태를 저장한다.

이렇게 적으면 벌써 자동화 포인트가 보인다. 문의 분류는 AI가 도울 수 있고, 템플릿 추천도 자동화할 수 있다. 고객 정보 조회와 CRM 기록도 연결할 수 있다. 고액 환불만 사람 승인으로 남기면 된다.

예시 2. 회의록 정리 업무

이번에는 직장인에게 더 익숙한 회의록 정리 업무를 보자.

입력은 회의가 끝나고 녹음 파일이나 화상회의 녹화본이 생성되는 순간이다.

처리 단계에서는 음성을 텍스트로 바꾸고, 발언자를 구분하고, 핵심 안건과 결정 사항, 할 일을 정리한다.

판단 단계에서는 어떤 항목이 실제 액션 아이템인지 가려내고, 누가 담당자인지 추출한다. 또 외부 공유가 가능한 내용인지 내부 한정인지도 구분해야 한다.

전달 단계에서는 회의 요약본을 팀 메신저에 공유하고, 담당자별 할 일을 프로젝트 도구에 등록한다.

승인 단계에서는 팀장이 최종 요약 문장을 확인하거나 민감한 표현을 수정한다.

기록 단계에서는 회의록을 노션이나 드라이브 폴더에 저장하고, 태그와 날짜를 붙인다.

이 업무 역시 아주 좋은 자동화 후보다. 음성 전사, 요약, 액션 아이템 추출, 담당자별 전달, 기록까지 자연스럽게 이어진다.

예시 3. 프리랜서 견적서 작성 업무

프리랜서나 창업자에게 자주 나오는 견적서 작성도 같은 방식으로 볼 수 있다.

입력은 잠재 고객이 메일이나 문의 폼으로 작업 요청을 보내는 것이다.

처리 단계에서는 요청 내용을 읽고, 작업 범위와 일정, 산출물을 정리한다. 기존 단가표와 유사 사례를 찾아 참고한다.

판단 단계에서는 이 작업을 수주할지, 추가 질문이 필요한지, 범위가 불명확한지 판단한다. 긴급 프로젝트인지도 확인한다.

전달 단계에서는 견적 초안을 메일로 보내거나, 추가 질문 리스트를 회신한다.

승인 단계에서는 본인이 최종 금액과 조건을 검토한다. 혼자 일하는 경우에도 승인 단계는 의미가 있다. 감정적으로 급하게 보내지 않도록 마지막 체크 지점이 되기 때문이다.

기록 단계에서는 견적 발송 일자, 제안 금액, 수주 여부를 스프레드시트에 남긴다.

이 예시를 보면 AI는 요청 요약, 범위 정리, 견적 초안 문구 작성에서 도움을 줄 수 있고, 자동화 도구는 문의 접수와 기록 저장을 맡을 수 있다.

실습: 내 업무를 워크플로 맵으로 바꾸기

이제 직접 해 보자. 너무 거창한 업무를 고르지 말고, 일주일에 두 번 이상 반복되는 업무 하나를 선택하면 좋다. 메일 답변, 회의록 정리, 자료 취합, 청구서 발행, 견적서 발송, 지원자 분류 같은 것이 좋다.

먼저 아래 문장을 빈칸 채우듯 적어 보자.

워크플로 맵 작성 템플릿

업무 이름:

이 업무는 언제 시작되는가?

입력: 무엇이 들어오면 시작되는가?

처리: 받은 정보를 가지고 내가 실제로 무엇을 하는가?

판단: 어떤 기준으로 나누거나 결정하는가?

전달: 결과를 누구에게 어떤 방식으로 보내는가?

승인: 누가 마지막 확인을 하는가? 혹은 어떤 경우에만 확인이 필요한가?

기록: 결과를 어디에 남기는가?

이렇게만 적어도 된다. 처음부터 완벽할 필요는 없다. 오히려 첫 버전은 거칠수록 좋다. 쓰다 보면 빠진 단계가 보이기 때문이다.

실습 팁: "나는 그냥 한다"를 금지하기

워크플로 맵을 만들 때 가장 흔한 실패는 단계를 뭉개는 것이다. "확인한다", "정리한다", "처리한다" 같은 표현만 잔뜩 쓰면 자동화 포인트가 보이지 않는다. 조금 더 구체적으로 써야 한다.

예를 들어 "문의를 확인한다" 대신 이렇게 쓸 수 있다.

• 메일 본문에서 주문번호를 찾는다

• 고객명으로 CRM을 검색한다

• 문의 내용을 배송, 환불, 제품문의 중 하나로 분류한다

• 기존 답변 템플릿 폴더를 연다

이 정도로 적으면 어떤 부분을 AI가 맡을 수 있는지, 어떤 부분은 시스템 연결이 필요한지가 분명해진다.

좋은 질문은 이것이다. "내가 지금 손으로 하는 행동을 화면 녹화로 찍는다면 무엇이 보일까?" 그 장면을 그대로 적으면 처리 단계가 훨씬 선명해진다.

병목 찾기: 어디서 가장 자주 멈추는가

워크플로 맵을 그렸다면 다음으로 해야 할 일은 멈춤 지점을 찾는 것이다. 자동화의 우선순위는 보통 가장 자주 막히는 곳에서 나온다.

업무가 느려지는 지점은 대개 세 종류다.

• 기다림이 많은 곳

• 반복 입력이 많은 곳

• 판단이 애매한 곳

기다림이 많은 곳은 예를 들어 승인 대기, 자료 도착 대기, 다른 부서 회신 대기 같은 것이다. 반복 입력이 많은 곳은 복붙, 이중 입력, 여러 시스템에 같은 내용 넣기가 대표적이다. 판단이 애매한 곳은 기준이 사람마다 달라 결과가 흔들리는 영역이다.

워크플로 맵 옆에 다음 질문을 붙여 보자.

"여기서 자주 멈추는가?" "같은 행동을 하루에 여러 번 반복하는가?" "사람마다 처리 방식이 다른가?"

셋 중 하나라도 그렇다면, 그 단계는 자동화 후보가 된다.

자동화 가능성이 높은 단계 구분하기

모든 단계를 자동화할 필요는 없다. 현실적으로는 자동화 가능성이 높은 부분부터 건드리는 것이 좋다.

보통 다음 단계는 자동화하기 좋다.

• 입력 수집: 메일, 폼, 파일, 메시지 가져오기

• 처리 보조: 요약, 분류, 초안 작성, 정보 추출

• 전달 자동화: 메신저 알림, 메일 발송, 작업 등록

• 기록 저장: 스프레드시트, CRM, 데이터베이스 업데이트

반면 다음 단계는 처음부터 완전 자동화하기보다 반자동으로 시작하는 편이 좋다.

• 판단 기준이 아직 불명확한 업무

• 실수 비용이 큰 승인 업무

• 예외가 지나치게 많은 고객 대응

• 법무, 인사, 재무처럼 민감한 결정

핵심은 "자동화할 수 있는가"보다 "지금 자동화해도 안전한가"를 함께 보는 것이다.

워크플로 맵에서 바로 자동화 설계로 넘어가는 법

워크플로 맵을 만들었다면 이제 한 단계만 더 가면 된다. 각 단계를 다음 세 가지 질문으로 바꾸는 것이다.

첫째, 이 단계는 무엇으로 시작되는가? 이것은 트리거가 된다.

둘째, 여기서 어떤 규칙이 필요한가? 이것은 조건문이 된다.

셋째, 결과를 어디에 보내거나 남기는가? 이것은 액션이 된다.

예를 들어 이런 식이다.

"문의 폼 제출"은 트리거다. "환불 관련 키워드가 있으면 환불 문의로 분류"는 조건이다. "고객에게 접수 메일 보내고 CRM에 저장"은 액션이다.

이제 업무가 자동화 도구가 이해할 수 있는 언어로 바뀌었다. 바로 다음 장에서 다룰 도구 선택과도 자연스럽게 연결된다.

자주 하는 실수 1: 예외를 숨기기

워크플로 맵을 만들 때 사람들은 이상하게도 정상 흐름만 쓰려 한다. 하지만 실무를 어렵게 만드는 건 예외다. 첨부파일이 없는 요청, 정보가 빠진 신청, 담당자 부재, 형식이 다른 문서, 중복 요청 같은 것들이다.

예외를 감추면 자동화가 실제 운영에서 자주 깨진다. 그래서 워크플로 맵에는 반드시 "예외가 생기면 어떻게 하는가"를 한 줄이라도 적어야 한다.

예를 들어 이렇게 쓸 수 있다.

"주문번호가 없으면 자동 회신으로 추가 정보 요청" "첨부파일 형식이 다르면 수동 검토 폴더로 이동" "판단 불가 문의는 담당자 확인 큐로 보낸다"

정상 흐름만큼 예외 흐름도 중요하다.

자주 하는 실수 2: 사람 이름으로 설계하기

"민지가 확인한다", "지훈이 메일 보낸다"처럼 사람 이름으로 업무를 적으면, 자동화 설계가 금방 흔들린다. 담당자가 바뀌면 흐름도 함께 무너진다.

가능하면 역할 중심으로 적는 편이 좋다. 예를 들면 "고객지원 담당자", "팀장", "회계 담당", "최종 승인자"처럼 쓰는 식이다. 그래야 업무가 사람에게 묶이지 않고 구조로 남는다.

이 원칙은 나중에 자동화 권한을 나누거나 승인 단계를 설계할 때도 큰 도움이 된다.

자주 하는 실수 3: 너무 큰 업무를 한 장에 담기

"영업 전체", "마케팅 운영 전체", "고객 경험 전체"처럼 범위가 큰 업무는 처음 워크플로 맵으로 다루기 어렵다. 이럴 때는 한 장면만 잘라야 한다.

예를 들어 "리드 수집부터 계약까지" 전체를 그리기보다, 먼저 "리드 문의 접수 후 1차 응답" 하나만 그리는 것이 좋다. 작은 흐름 하나를 정확하게 그리면, 나중에 그것들을 연결해 큰 자동화로 확장할 수 있다.

자동화는 큰 꿈보다 작은 명확함에서 시작한다.

15분 실전 과제: 오늘 바로 그려 보기

오늘 이 장을 읽고 바로 해 볼 과제를 드리겠다. 타이머를 15분 맞추고, 지금 내 업무 하나를 아래 순서로 적어 보자.

먼저 업무 이름을 쓴다. 그다음 입력 한 줄, 처리 세 줄, 판단 두 줄, 전달 한 줄, 승인 한 줄, 기록 한 줄을 적는다. 문장이 어색해도 괜찮다. 빠진 게 있으면 화살표를 추가해도 된다. 그리고 마지막으로 가장 시간이 많이 걸리는 단계 하나에 동그라미를 친다.

그 동그라미가 다음 자동화 후보가 된다.

한 번 더 정리: 좋은 워크플로 맵의 조건

좋은 워크플로 맵은 복잡한 그림이 아니다. 실제 일이 어떻게 시작되고, 굴러가고, 멈추고, 끝나는지를 말해 주는 설명서다. 특히 다음 조건을 만족하면 좋다.

• 시작 신호가 분명하다

• 사람이 하는 손동작이 구체적이다

• 판단 기준이 문장으로 적혀 있다

• 전달 대상과 방식이 보인다

• 승인 지점이 명확하다

• 결과가 남는 위치가 정해져 있다

이 여섯 가지가 보이면 자동화는 더 이상 막연한 아이디어가 아니다. 설계 가능한 프로젝트가 된다.

마무리: 설명할 수 있어야 자동화할 수 있다

자동화는 똑똑한 도구를 찾는 싸움이 아니다. 내 일을 얼마나 선명하게 설명할 수 있느냐의 싸움이다. 설명이 흐리면 자동화도 흐리고, 설명이 명확하면 자동화도 단단해진다.

이번 장에서 한 일은 거창하지 않다. 단지 일을 여섯 칸으로 쪼갰을 뿐이다. 하지만 바로 이 작업이, 감으로 하던 업무를 구조로 바꾸는 첫걸음이다. 이제 당신은 "그냥 바쁜 사람"이 아니라, "내 일이 어떻게 움직이는지 말할 수 있는 사람"이 되었다.

다음 장에서는 이렇게 분해한 업무 흐름을 실제 도구에 연결하기 위해, 어떤 자동화 플랫폼을 선택해야 하는지 살펴본다. Zapier, Make, n8n, Power Automate 중에서 내 상황에 맞는 조합을 고르면, 오늘 만든 워크플로 맵은 곧 실행 가능한 자동화 설계도가 된다.