Process Modeling 공부해보기

 

왜 이 주제를 다루는가?

새로운 서비스를 기획하거나 기존 업무를 개선하려고 할 때, 가장 먼저 부딪히는 벽은 “과연 지금의 프로세스를 명확히 이해하고 있는가?”입니다. 기획자는 단순히 아이디어를 제시하는 사람이 아니라, 실행 가능한 구조와 흐름을 설계하는 사람입니다.

이때 도움이 되는 도구가 바로 Process Modeling(프로세스 모델링) 입니다. 복잡한 업무 흐름을 시각화하고 병목을 찾거나 자동화를 설계하기 위해선, 막연한 '이렇게 될 거야'가 아닌 명확한 흐름과 책임, 조건, 결과의 구조화된 표현이 필요합니다.

 

이번 글에서는 Process Modeling에 대해서 실무적인 내용을오 알아보고자 한다.

 

Process Modeling: 개념

 

•  

정의

Process Modeling이란, 어떤 목적을 가진 작업(업무 프로세스, 서비스 흐름 등)을 시작부터 종료까지의 단계별 흐름으로 시각화한 구조를 의미합니다. 이 모델은 행위자(Actor), 작업(Task 또는 Activity), 흐름(Flow), 조건(Gateway), 입출력(Input/Output) 등의 요소를 명확하게 표현하여, 기획·개발·운영 전반의 의사소통과 실행 가능성을 높이는 데 목적이 있습니다.

 

주요 구성 요소

구성요소	설명	예시
Actor (행위자)	프로세스를 수행하는 주체. 사람, 팀, 시스템 등	고객, 상담원, 자동화 봇, 내부 DB
Task / Activity (작업)	Actor가 수행하는 구체적인 작업 단위	“회원가입 요청 확인”, “승인 이메일 전송”
Flow (흐름선)	작업 간의 흐름을 연결하는 선 (조건 포함)	“요청 완료 → 확인 작업으로 연결”
Gateway (조건 분기)	조건/결정에 따라 흐름이 나뉘는 지점	“서류 이상 있음?” → 예: 반려, 아니오: 진행
Start / End	프로세스의 시작점과 종료점	“회원가입 시작” → “가입 완료”
Data Object (데이터)	작업 간 전달되거나 사용하는 정보	고객 정보, 문서 파일, 승인 결과
Lane	행위자(Actor) 또는 조직 단위를 나누는 수평 영역입니다	고객, 식당, 배달업체

 

 

💡 실무에서 보는 의미

• 기획자 입장:
  아이디어나 업무 요청을 단순한 메모가 아니라 시스템 흐름 관점에서 논리적으로 정리하고, 기술자에게 정확하게 전달할 수 있는 도구.
• 기술자/개발자 입장:
  구현 가능한 로직 단위로 작업을 나누고, 병렬/순차/예외 흐름을 명확하게 해주는 문서 역할.
  BPM, RPA, API 워크플로우 구현에도 그대로 반영 가능.

 

적용 분야와 효과 요약

적용 분야	기대 효과
업무 분석, RPA 도입	불필요한 단계 제거, 자동화 설계 기반
신규 시스템 기획	요구사항 시각화, 개발 범위 명확화
내부 교육 문서	업무 이해도 향상, 온보딩 속도 향상
API/서비스 플로우 설계	RESTful 구조 설계, 인터페이스 흐름 정의

 

궁금증 : 각 업무/서비스 마다 그려야하는 지?

1. 원칙적으로는 “각 업무/서비스마다 그려야 한다”

 

• 프로세스는 목적·경로·행위자가 다르면 전혀 다른 구조이기 때문입니다.
• 예:
  • 챗봇은 입력 → 처리 → 응답이 핵심이고,
  • 문서 업로드는 파일 → 저장 → 변환/인덱싱 등 전혀 다른 흐름입니다.

 

2. 하지만 모든 걸 처음부터 그리진 않습니다.

📦 실무에서는 보통 이렇게 합니다:(GPT 작성)

방식	설명	예시
① 템플릿화	자주 사용하는 흐름 유형을 템플릿으로 보관	챗봇 템플릿, 업로드/검증 템플릿 등
② 구성요소 라이브러리화	반복되는 Task/Actor를 재사용	“문서 저장”, “벡터화”, “LLM 응답” 등
③ 공통 Process 정의 후 확장	기본 흐름은 공통으로 정의하고 서비스별로 추가	ex. 공통: 파일 업로드 → 분기: OCR, PDF 변환 등
④ 레벨별 정의	상위 프로세스 → 하위 서브프로세스로 분리	Level 0: 전체, Level 1: 상세 업무, Level 2: 구현 로직

🧠 결론

네, 각 서비스/업무에 맞춰 개별적으로 프로세스 모델링을 해야 합니다.
하지만 반복 요소를 추출해 템플릿화하거나, 공통 서브플로우로 구성하면 효율성을 확보할 수 있습니다.

궁금증 : 서비스를 기획할 때 이걸 언제 그려야 하는 지?

 

“기능 아이디어가 정리되고, 시스템 흐름을 팀과 공유하거나 개발/설계에 착수하기 직전”에 그리는 것이 가장 적절

 

단계	모델링 필요도	목적
아이디어 발산	❌	없음
요구사항 도출	⚠ 가볍게	개념 정리용
기능 흐름 설계	✅ 필수	팀 공유용
화면/개발 설계	✅ 명확하게	명세/로직 기반
QA/테스트	✅ 보조적	케이스 도출

 

 

실무 팁

질문	답
"기획자만 그려야 하나요?"	❌ 아니요. 기획자가 초안을 만들고, 개발자/디자이너와 협업해 다듬는 것이 좋습니다.
"처음부터 BPMN으로 그려야 하나요?"	❌ 처음은 화이트보드/Excalidraw로 가볍게 시작, 이후 정식 BPMN 툴로 정리하는 게 실용적입니다.
"기능마다 다 그려야 하나요?"	핵심 기능 또는 예외 케이스 중심으로 먼저 그립니다. 전체 다 그리는 건 비효율일 수 있습니다.

 

궁금증 : 근데 이거 그리다가 언제 개발해?

“모든 걸 다 그리고 나서 개발하는 게 아니라, 필요한 만큼 그리고 곧바로 개발과 병행”하는 게 정답입니다.

 

🧭 실무에서는 이렇게 나눠 움직입니다

1. 핵심 흐름만 먼저 모델링 → 바로 개발 시작

항목	설명
✍️ 가벼운 모델링 먼저	전체 서비스 중 꼭 필요한 핵심 플로우(예: 로그인 → 질문 → 응답)를 먼저 그립니다.
🔨 개발 병행	초안이 나오면 개발 착수 → 이후 세부 기능 모델링은 점진적으로 추가합니다.

 

예: 챗봇의 “질문 → 검색 → 응답” 흐름만 먼저 모델링 → 개발 시작
나중에 “예외 응답 처리”, “모니터링”, “권한 분기” 등을 추가로 그려도 됨.

---

2. 시간 낭비 방지 위한 기준

 

질문	Yes면 그린다 / No면 안 그려도 된다
기능/흐름이 복잡하거나 예외가 많나?	✅ 모델링 필요
여러 팀원이 협업해야 하나?	✅ 모델링 필요
로직이 단순해서 바로 개발 가능한가?	❌ 바로 개발

 

🧭 이상적인 흐름

 

[기획 아이디어]  
   ↓  
[핵심 사용자 흐름 도출]  
   ↓  
[핵심 프로세스 모델링 (Swimlane or BPMN)]  
   ↓  
👉 [개발 착수] ← 병행 → [세부 프로세스/예외 플로우 모델링]  
   ↓  
[테스트/QA]  
   ↓  
[배포 및 운영]

 

 

🎯 실무에서 사용하는 기준

항목	단순 기능	복잡 기능
예시	회원가입, 로그아웃	챗봇 질문 처리, 문서 인덱싱, 파일 업로드 후 인식
모델링 여부	❌ 생략 가능	✅ 반드시 필요
개발 시기	바로 가능	모델링 후 분기 고려 필요

 

 

✅ 개발 시작 판단 체크리스트 (Process 기준)

체크 항목	설명	체크
✅ 핵심 사용자 흐름이 정리되었는가?	예: 유저가 어떤 목적을 위해 어떤 경로로 서비스 사용하는지 흐름이 정의되어 있음	☐
✅ 주요 Actor와 시스템 역할이 구분되었는가?	고객, 관리자, 외부 API 등 각 주체가 어떤 Task를 담당하는지 명확함	☐
✅ 주요 Task가 정의되어 있는가?	“질문 수신 → 벡터 검색 → 응답 생성”처럼 단계가 정리되어 있음	☐
✅ 분기 조건(Gateway) 및 예외 흐름이 정리되었는가?	조건(예/아니오)에 따라 어떻게 처리되는지까지 포함되었는가	☐
✅ 입출력 데이터가 대략 정리되었는가?	어떤 데이터가 들어오고, 어떤 결과가 나오는지 (형식/내용 포함)	☐
✅ 화면 흐름 또는 API 흐름이 공유 가능한 상태인가?	개발자가 UI 혹은 API 스펙을 유추할 수 있을 정도로 흐름이 있음	☐
✅ 기술/아키텍처 상의 제약사항이 확인되었는가?	ex. 외부 API 호출 속도, DB 저장 여부, 배치 처리 등	☐
✅ 범위 스코프가 정리되었는가?	MVP인지, 전체인지, 1차 릴리즈 범위인지 구분되어 있음	☐
✅ "이후에도 일부 변경이 가능함"을 개발팀과 합의했는가?	모델링은 80% 상태로 시작, 나머지는 병행하며 개선	☐

 

 

✅ 체크 기준 해석

• 7개 이상 체크 → 개발 시작해도 무방
• 5~6개 → 핵심 흐름은 되고, 세부 보완하면서 진행 가능
• 4개 이하 → 개발 착수는 리스크, 모델링/정의 보완 필요

 

🎯 보너스: 개발팀 입장에서 중요한 3가지

항목	이유
📌 입력/출력 정리	어떤 데이터가 들어오고 나가는지 명확해야 코드가 설계 가능
📌 예외 흐름 표시	실패, 조건 분기, 오류 처리를 코드에서 예외처리 가능하도록 해야 함
📌 API or UI 연동 시나리오	화면 또는 API로 어떤 요청이 오가는지 있어야 연동 개발이 가능

 

🧠 결론

프로세스 모델링은 완벽하지 않아도 되지만,
“타인에게 설명 가능하고 로직 구현할 수 있는 수준”까지는 정리되어야 개발 착수 가능합니다.
이후 세부 분기, 예외, 리팩토링은 병행하면서 지속 개선하는 것이 현실적입니다.

 

 

대표적인 프로세스 모델링 패턴 6가지

패턴명	설명	사용 예시
1. Linear Flow (직선형)	순차적 흐름만 표현	단일 사용자 요청 처리, 단순한 업무 시나리오
2. Swimlane Diagram	주체(Actor)별 책임 구분	고객/상담원/시스템 간 상호작용
3. Gateway Branching (조건 분기형)	조건에 따라 흐름이 달라짐 (if/else)	심사 승인/반려, 로그인 성공/실패
4. Looping Process (반복형)	특정 단계 반복 처리	설문 반복, 서류 보완 요청 등
5. Event-driven Process (이벤트 기반)	특정 이벤트 발생 시 흐름 전환	OTP 인증 만료, 오류 발생 시 복귀
6. Subprocess / Drill-down 구조	상위 프로세스 내 세부 프로세스 포함	회원가입 → 본인확인 → 약관 동의 → 완료 등 단계별 세분화

 

타입 종류

 

BPMN 예시

다양한 이벤트에 타입이 정의되어 있습니다.

 

 

 

🧩 실전 예시 BPMN

 

일반 단일 Flow Diagram을 쓰는 경우

목적: 하나의 Actor(또는 하나의 시스템) 안에서 처리되는 흐름 정리

특징	설명
🧍 하나의 사용자가 전체 흐름 담당	상담원, 운영자, 사용자가 프로세스를 혼자 처리
💻 시스템 내부 로직 중심	API 호출, 내부 기능 설계 등 시스템 단위 설계 목적
🧱 간단한 로직 설명	비즈니스 로직, UI 흐름 등 논리 구조 정리 중심
📋 매뉴얼, 자동화 설계, 테스트 시나리오	프로세스 단위로는 간단하지만 내부 조건은 복잡한 경우도 포함됨

 

고객의 신청을 처리하는 간단한 승인 흐름

 

하나의 Actor 운영 담당자 (또는 상담원) 일 때 신청을 처리하는 흐름

 

 

 

 

 

Swimlane Diagram을 쓰는 경우

 

목적: 여러 Actor(역할 주체) 간의 책임과 데이터 흐름 명확화

특징	설명
🧑‍🤝‍🧑 여러 부서/시스템/조직이 관여	고객, 콜센터, 전산시스템 등 주체가 나뉘어 있을 때
📬 역할 분담이 중요할 때	누가 무엇을 언제 하는지 명확히 해야 할 때
🧾 업무 프로세스 문서화/감사/교육용	"이건 누가 했지?"에 답을 줄 수 있는 시각화 필요
🔁 협업이 많은 프로세스	정보 주고받기, 승인 요청/승인 등 명확한 경계가 필요

 

은행/카드사에서 고객 본인확인 절차를 수행하는 전체 흐름을 시각화한 것

 

🧩 구성 요소별 상세 설명

참여 주체 (Actor)	역할	주요 활동
고객	본인확인 요청자	시작(Start), 본인확인 요청, 결과 확인
콜센터	고객 요청 수신 및 응대	요청 수신, 전산시스템에 조회 요청, 응답 수신 및 정제
전산시스템	인증 판단 및 응답 제공	고객 DB 조회, 본인인증 판단, 결과 응답 전송

 

 

 예시 : BPMN  2.0기반 RAG 챗봇 프로세스 모델링

아래 예시는 완전히 2.0을 따라서 만든 것은 아닙니다. 부족한 부분이 있지만 저런 흐름이 될 수 있다고 봐주시면 될 것 같습니다.

구조의 목적

이 다이어그램은 사용자가 질문을 입력했을 때, Retrieval-Augmented Generation (RAG) 기반 AI 챗봇이 질문을 처리하고, 문서를 검색하고, LLM으로부터 응답을 생성하며, 그 결과를 사용자에게 제공하고 로그로 남기는 전체 흐름을 BPMN 형식으로 시각화한 것입니다.

 

🧩 구성 요소별 해설

1. 🧑‍🤝‍🧑 Actor (수행 주체)

각 수평 레인은 실제 시스템에서 역할을 맡는 주체(Actor)를 뜻합니다:

 

Lane 이름	의미	예시
사용자	질문을 입력하고 결과를 받는 사람	웹/앱 사용자
웹 프론트엔드	UI 처리 및 API 요청 전달	React, Vue, FastAPI 등
RAG 서버	벡터 검색, 문서 필터링 등	FAISS, Weaviate, Elastic 등
LLM API	GPT 또는 사내 LLM 모델 호출	OpenAI, Claude, KoGPT 등
로그/모니터링 시스템	로그 저장, 모니터링	ElasticSearch, Prometheus 등

2. ⚙️ Task (작업 단위)

네모 상자는 각 Actor가 수행하는 작업(Task 또는 Activity)입니다.

• 질문 입력, 응답 생성 요청, 검색 로그 저장 등이 이에 해당합니다.

3. 🔀 Gateway (조건 분기)

마름모는 조건 분기(Gateway)입니다.

• 입력 오류 여부: 질문이 공백이거나 부적절하면 "입력 오류 안내"로 분기
• 검색 성공 여부: 문서 검색 결과가 없으면 "검색 실패 안내"로 분기

4. 🔁 흐름선 (Flow)

→ 화살표는 작업의 실행 순서를 나타냅니다.

• 직선적 흐름이 기본이며,
• Gateway에 따라 분기된 흐름도 표현됩니다.

5. 🗂️ 로그 및 모니터링

하단의 로그/모니터링 시스템에서는:

• 🔹 검색 단계에서 검색 로그 저장
• 🔹 LLM 응답 단계에서 질문/응답 로그 저장

이렇게 실시간 로그가 저장되어, 운영 상태를 모니터링하거나 이후 분석에 활용됩니다.

 

 

결론

이번에 ChatGPT와 함께 Process Modeling에 대해 이야기하면서 생각을 정리해보았습니다.
개발을 시작하기 전에는 사용자 흐름 정의, 기능 분기 설계, 예외 처리 흐름 등 다양한 사전 작업이 필요하다는 점을 실감했고, 그러한 흐름을 명확히 정의하는 것이 개발의 방향성과 품질을 좌우한다는 사실을 새삼 느꼈습니다.

요구사항이라는 결과물 이전에는 수많은 논리적 정리가 필요하며, 이를 책임지는 기획자의 역할이 얼마나 중요한지 체감할 수 있었습니다.

앞으로는 새로운 기능이나 서비스를 만들 때, 모든 걸 다 구현하려고 하기보다 꼭 필요한 흐름과 조건만 명확하게 정리해서
기획과 개발을 함께 하는 입장에서 스스로 더 효율적으로 움직일 수 있도록 프로세스를 잘 설계하는 습관을 가져가야겠다고 느꼈습니다.

 

 

참고

번호	참고 자료	URL
1	BPMN 2.0	https://forkit10.wordpress.com/2014/06/12/bpmn-2-0/
2	TypesOfEvents	https://training-course-material.com/images/4/40/TypesOfEvents.png