# 워크플로우란? 운영팀이 바로 쓰는 정의와 구성 요소

URL: https://commandergpt.app/ko/journal/wokeupeulouran
Type: blog
Locale: ko
Published: 2026-10-07
Updated: 2026-10-07

---

> 워크플로우는 트리거, 단계, 인수인계, 결과물을 갖춘 반복 가능한 업무 흐름입니다. 프로세스·SOP와의 차이, 30분 매핑법, 먼저 자동화할 업무를 소개합니다.

워크플로우란 무엇일까요? 업무 한 건을 시작부터 끝까지 옮기는, 반복 가능한 단계의 순서입니다. 명확한 트리거(시작 조건), 사람이나 도구 사이에 정해진 인수인계, 그리고 예상되는 결과물이 있어야 합니다. 이게 핵심 답변입니다. 트리거, 단계, 각 단계의 담당자, 결과를 적을 수 있다면 워크플로우가 있는 것입니다. 적을 수 없다면 그건 습관일 뿐입니다.

저는 초기 단계 GTM(시장 진입, Go-To-Market) 팀을 컨설팅하는데, 이 질문은 생각보다 자주 나옵니다. 운영(ops) 리드들은 매일 이 단어를 쓰지만, 같은 방에 있어도 각자 조금씩 다른 뜻으로 씁니다. 아래는 고객사에 설명할 때 쓰는 버전입니다.

## 운영팀이 실제로 쓸 수 있는 워크플로우의 정의는?

**30초 브리핑: 워크플로우는 네 가지로 이뤄집니다. 트리거, 단계, 인수인계, 결과물.**

영업 딜 리뷰를 예로 들어 보겠습니다. 트리거는 CRM(고객 관리 시스템)에서 딜이 3단계로 넘어가는 순간입니다. 단계는 계정 데이터 조회, 최근 접점 3회 확인, 리스크 요약 작성, 딜 채널에 게시입니다. 인수인계는 업무 담당자가 바뀌는 지점입니다. 예를 들어 AE(영업 담당자, Account Executive)에서 영업 매니저로 넘어가는 순간이죠. 결과물은 진행, 보류, 중단 중 하나를 정하는 결정입니다.

네 요소 중 하나라도 빠지면 워크플로우는 흐려집니다. 트리거가 없으면 누군가 기억해서 시작해야 합니다. 인수인계 규칙이 없으면 주인 없는 대기열에 업무가 쌓입니다. 결과물이 정의되어 있지 않으면 언제 끝났는지 알 수 없습니다.

워크플로우는 그것을 돌리는 도구와 같지 않습니다. 같은 딜 리뷰를 HubSpot에서 해도, Notion 데이터베이스에서 해도, Slack 스레드에서 해도 됩니다. 도구는 바뀌어도 순서는 그대로입니다.

![유리 벽에 포스트잇을 순서대로 붙여 워크플로우 단계를 정리한 모습](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/commandergpt/2026-10/7bb55e-i1.webp)

## 워크플로우, 프로세스, SOP는 어디서 구분될까요?

사람들은 이 세 단어를 계속 섞어 씁니다. 출처마다 경계가 조금씩 다르고, 벤더 용어집은 자기 제품에 맞게 정의를 바꾸기도 합니다. 실무에서 잘 통하는 구분은 이렇습니다.

- 
**프로세스:** 큰 그림입니다. 팀이 무엇을, 왜 하는지 입력에서 비즈니스 결과까지 말합니다. "인바운드 리드 검증"은 프로세스입니다.

- 
**워크플로우:** 업무의 이동입니다. 프로세스 안의 단계, 역할, 인수인계 순서를 뜻합니다. 누가 언제 업무를 넘겨받는지가 핵심입니다.

- 
**SOP(표준 운영 절차, Standard Operating Procedure):** 한 단계를 실행하는 상세한 방법입니다. 누가 하든 같은 결과가 나오도록 만든 문서입니다.

[ClickUp의 작업 지침과 SOP 비교 글](https://clickup.com/blog/work-instruction-vs-sop/)도 업무의 흐름과 개별 작업의 지침 사이에 비슷한 선을 긋습니다. 용어 논쟁은 건너뛰세요. 단어 하나에 뜻 하나만 정해서 팀 위키에 적어 두면 충분합니다.

제 원칙은 이렇습니다. 가격 승인이나 데이터 삭제처럼 일관성이 중요한 곳에만 SOP를 씁니다. 나머지는 워크플로우를 매핑하고 멈춥니다. 아무도 열어 보지 않는 SOP는 없는 것보다 나쁩니다. 잘 관리되고 있다는 잘못된 확신을 주기 때문입니다.

## 정의가 왜 중요할까요? 매핑되지 않은 업무는 비쌉니다

팀이 암묵지에 의존하면 그 비용은 조율 비용으로 나타납니다. Asana의 Anatomy of Work Index는 지식노동자를 대상으로 한 설문인데, 사람들이 [업무 시간의 약 60%를 '일에 관한 일'](https://www.nasdaq.com/press-release/asana-anatomy-of-work-index-2021:-work-about-work-is-dominating-in-a-distributed)에 쓴다고 답했습니다. 상태 업데이트, 정보 찾기, 앱 전환이 여기에 해당합니다. 이 설문은 2021년 자료이고 응답자가 직접 적은 자기보고 방식이라서, 이 숫자는 방향을 보는 용도로만 쓰세요. 우리 팀의 벤치마크로 쓰면 안 됩니다.

제가 현장에서 본 것도 이 방향과 같습니다. 여섯 명짜리 GTM 팀이 있던 한 고객사는 Notion 위키가 세 개였고, SDR(영업개발 담당자, Sales Development Rep)과 AE 사이에 문서화된 인수인계가 없었습니다. 단계와 단계 사이에서 리드가 2~3일씩 식었습니다. 누구도 게을렀던 게 아닙니다. 다음 단계의 주인이 누구인지 아무도 몰랐던 것입니다.

그 인수인계 하나를 매핑하는 데 약 90분이 걸렸습니다. 트리거, 담당자, 24시간 이내 응답이라는 기준을 적었습니다. 대단해 보이지 않지만 효과는 있었습니다. 그게 워크플로우입니다.

![사람 기준으로 흩어진 문서와 엉킨 케이블이 보이는 두 개의 모니터, 수작업 워크플로우를 나타낸 장면](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/commandergpt/2026-10/1a8765-i2.webp)

## 워크플로우의 주요 유형은 무엇인가요?

운영팀이 돌리는 업무의 대부분은 세 가지 유형으로 설명됩니다.

**순차형 워크플로우.** B 단계는 A 단계가 끝나야 시작합니다. 계약 승인이 전형적인 예입니다. 법무, 재무, 서명자 순서로 진행하죠. 그리기는 쉽지만, 한 사람이 휴가를 가면 쉽게 멈춥니다.

**병렬형 워크플로우.** 여러 단계가 동시에 진행되고 나중에 합쳐집니다. 고객 온보딩이 대개 이런 식입니다. 결제 설정, 데이터 가져오기, 킥오프 콜이 나란히 진행되고, 세 가지가 모두 끝나야 서비스 시작이 됩니다.

**조건형 워크플로우.** 경로가 규칙에 따라 달라집니다. 점수가 80점을 넘는 리드는 AE에게 가고, 그 아래는 육성 흐름으로 갑니다. 실제 워크플로우 대부분이 조건형이라서, 화이트보드에 처음 그린 초안은 늘 틀립니다.

더 복잡한 분류(상태 머신, 규칙 기반, 케이스 기반)는 실제로 돌아가는 워크플로우가 최소 다섯 개 생기기 전까지 건너뛰세요. 초보자는 업무를 보기도 전에 이름부터 고릅니다.

## 워크플로우를 30분 만에 매핑하는 방법은?

관리자가 아니라 업무를 실제로 돌리는 사람과 함께 하세요. 관리자는 문서에 적힌 프로세스를 설명하고, 실무자는 화요일에 실제로 무슨 일이 일어나는지 설명합니다.

- 
**트리거에 이름 붙이기.** 무엇이 시작시키나요? 폼 제출, 단계 변경, 월요일 캘린더 슬롯 같은 것입니다. "누군가 기억해서"라는 답이 나오면 그게 첫 번째 발견입니다.

- 
**실제 발생 순서대로 단계 나열하기.** 포스트잇이나 Notion 페이지를 씁니다. 단계마다 동사 하나만 씁니다. 조회, 확인, 작성, 발송처럼요.

- 
**인수인계 모두 표시하기.** 업무의 담당자나 도구가 바뀌는 지점마다 동그라미를 치세요. 업무가 멈추는 곳이 바로 여기입니다.

- 
**결과물 쓰기.** 한 문장으로 씁니다. "15분 이내에 딜 채널에 리스크 요약이 게시된다."

- 
**시간 재기.** 각 단계가 지금 얼마나 걸리는지 적으세요. 모르겠다면 "우리 환경에서 측정 필요"라고 쓰고 일주일 동안 재 보세요.

한 페이지에서 멈추세요. 세 페이지짜리 문서가 필요한 워크플로우는 아무도 따르지 않습니다.

![노트북 화면을 가리키며 동료와 워크플로우를 검토하는 운영 팀원](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/commandergpt/2026-10/94df8d-i3.webp)

## 워크플로우는 보통 어떻게 깨지나요?

제가 수정하러 불려 가는 경우의 대부분은 네 가지 실패 패턴으로 설명됩니다.

**문서상 경로와 실제 경로가 다릅니다.** 위키에는 다섯 단계라고 적혀 있는데 사람들은 세 단계만 하고 나머지는 건너뜁니다. 팀이 워크플로우를 우회한다면 문제는 워크플로우에 있습니다. 리마인더를 더 보내도 소용없습니다. 다시 설계하세요.

**인수인계의 주인이 없습니다.** 각 단계에는 담당자가 있는데, 단계 사이의 공백에는 주인이 없습니다. 보내는 사람만 지정하지 말고 받는 사람도 지정하세요.

**예외가 규칙이 됩니다.** 정상 경로만 매핑하고 맞지 않는 30%의 경우는 무시합니다. "이 단계가 실패하면 어떻게 하는가"를 한 줄이라도 적으세요. 답이 "운영 리드에게 핑 보내기"여도 괜찮습니다.

**목적이 사라진 워크플로우가 남습니다.** 나빴던 한 분기 뒤에 추가된 단계는 영원히 남습니다. 분기마다 워크플로우를 검토하고 단계 하나를 삭제하세요. 대부분의 팀은 10분 안에 죽은 단계를 찾아냅니다.

## 워크플로우를 적은 뒤 도구는 어디에 맞을까요?

도구를 먼저 고르고 워크플로우는 나중에 생각하는 것이 가장 흔한 실수입니다. 플랫폼을 사고 나서야, 단계에 합의한 적이 없어서 설정할 수 없다는 걸 알게 됩니다.

순서가 종이 위에 올라오면 도구는 쉽게 평가할 수 있습니다. 운영 스택에서 자주 보이는 카테고리는 네 가지입니다.

**워크스페이스와 데이터베이스.** 워크플로우가 주로 사람이 레코드를 상태별로 옮기는 것이고 템플릿과 보드 뷰가 필요하다면 Notion이 잘 맞습니다. Notion의 커스텀 에이전트(2026년 2월 업데이트에서 추가)는 크레딧 기반으로 여러 단계 작업을 자동화할 수 있으니, 팀 전체에 도입하기 전에 크레딧 사용량부터 확인하세요.

**CRM 스위트.** HubSpot은 단계 기반 워크플로우를 잘 처리합니다. 트리거(딜 단계 변경)가 이미 HubSpot 안에 있기 때문입니다. 워크플로우가 CRM에서 시작해서 CRM에서 끝난다면 가치가 있습니다. 단계의 절반이 다른 도구에서 일어난다면 건너뛰세요.

**데이터와 보강(enrichment).** Clay는 주요 업무가 계정 데이터를 수집하고 풍부하게 만드는 일인 워크플로우에 맞습니다. 무료 요금제로 프로스펙팅 워크플로우 하나를 테스트하기에 충분합니다. 유료 요금제는 월 $185부터 시작하는데, 소규모 팀에게는 실제로 부담되는 금액입니다.

**에이전트.** Lindy는 받은편지함 분류나 미팅 준비처럼 반복 작업 하나를 맡는 작은 상시 에이전트를 만듭니다. 트리거가 명확하고 결과물이 반복 가능한 워크플로우에 어울립니다. 단계가 매주 바뀐다면 잘 맞지 않습니다.

이 중 어느 것도 첫 단계를 대신하지 않습니다. 워크플로우를 먼저 쓰세요. 도구는 그것을 실행할 뿐입니다.

## 어떤 워크플로우를 먼저 자동화해야 할까요?

가장 짜증나는 업무가 아니라, 다음 세 가지 테스트를 통과하는 업무입니다.

- 
최소 주 1회 실행된다.

- 
열 번 중 아홉 번은 단계가 같다.

- 
잘못된 결과물을 고치는 비용이 싸다.

주간 미팅 준비, 리드 라우팅 규칙, CRM 필드 정리는 모두 통과합니다. 가격 예외 처리나 이탈 방지 콜은 판단이 필요하니 통과하지 못합니다. 이런 업무에는 사람이 계속 참여해야 합니다.

첫 자동화는 측정 가능한 차이를 목표로 하세요. 40분짜리 복사-붙여넣기 작업을 8분짜리 검토로 줄이면 상사에게 보여줄 수 있는 결과가 됩니다. "시간을 아꼈다"는 결과가 아닙니다.

## AI 명령은 워크플로우에 어떻게 들어가나요?

AI 명령은 워크플로우 자체가 아니라 워크플로우 안의 한 단계입니다. 재사용할 수 있는 동사라고 생각하세요. 매번 긴 프롬프트를 쓰는 대신, 통화 녹취록에 `/summarize` 같은 저장된 명령을 실행하면 매번 같은 구조의 결과를 얻습니다.

명령 세 개를 연결하면 작은 워크플로우가 됩니다. 계정에 `/research`를 실행하고, 결과를 `/summarize`로 정리하고, 첫 연락 메일은 `/draft-email`로 씁니다. 트리거는 첫 명령을 입력하는 당신입니다. 결과물은 보내기 전에 검토하는 초안입니다. 한계도 분명합니다. 연결은 각 단계의 정의만큼만 잘 작동하고, 사람에게 넘기는 인수인계의 책임은 여전히 당신에게 있습니다.

AI 워크플로우를 판단하는 솔직한 기준도 여기에 있습니다. 모델 이름을 말하지 않고는 단계를 설명할 수 없다면, 그것은 워크플로우가 아니라 데모입니다.

## 다음 명령: 이번 주 워크플로우 한 개부터

팀이 매주 돌리는 워크플로우를 하나 고르세요. 30분을 비워 두고 트리거, 단계, 인수인계, 결과물을 한 페이지에 적으세요. 그다음 5영업일 동안 각 단계의 시간을 재세요.

아직 아무것도 자동화하지 마세요. 그 한 페이지와 시간 기록이 생기면, 어떤 단계를 도구에 넘기고 어떤 단계를 사람 손에 남길지 정확히 알게 됩니다. 그것이 정의를 실제로 쓰는 방법입니다.

## FAQ

### 워크플로우와 프로세스는 어떻게 다른가요?

프로세스는 팀이 무엇을, 왜 하는지 보여 주는 큰 그림입니다. 워크플로우는 그 안에서 단계와 역할, 인수인계가 어떤 순서로 이어지는지를 다룹니다. 누가 언제 업무를 넘겨받는지가 워크플로우의 핵심입니다.

### 워크플로우는 어디서부터 만들면 좋을까요?

팀이 매주 반복하는 업무 하나를 고르세요. 30분 동안 트리거, 단계, 인수인계, 결과물을 한 페이지에 적고, 5영업일 동안 각 단계의 시간을 재면 됩니다.

### 워크플로우를 Notion에 만들어도 되나요?

사람이 레코드를 상태별로 옮기는 흐름이라면 Notion으로 충분합니다. 다만 Notion의 커스텀 에이전트는 크레딧을 쓰므로, 팀 전체에 도입하기 전에 사용량을 확인하세요.

### 모든 워크플로우에 SOP가 필요한가요?

아닙니다. 가격 승인이나 데이터 삭제처럼 결과의 일관성이 중요한 곳에만 SOP를 쓰세요. 나머지는 워크플로우를 매핑하고 멈추는 것이 낫습니다. 아무도 열어 보지 않는 SOP는 잘못된 확신만 줍니다.

### AI 명령을 워크플로우 단계로 쓰려면 무엇이 필요한가요?

단계의 입력과 출력 형식, 결과를 검토할 담당자, 다음 단계로 넘기는 기준이 필요합니다. 모델 이름을 말하지 않고도 단계를 설명할 수 있어야 실제 워크플로우입니다.

### 워크플로우는 얼마나 자주 점검해야 하나요?

분기마다 한 번 검토하세요. 더 이상 쓰이지 않는 단계가 있으면 하나씩 삭제합니다. 대부분의 팀은 짧은 점검만으로도 죽은 단계를 찾아냅니다.