사전 워크플로
개념

워크플로

gabury1

워크플로는 여러 단계로 나뉜 일을 정해진 규칙에 따라 다음 자리로 넘겨 가며 자동으로 처리하는 것입니다. 무엇을 어떤 차례로 할지는 미리 적어 둡니다. 정해 둔 일이 벌어지면 적어 둔 대로 실행됩니다.

상세

휴가 신청서는 팀장을 거쳐 인사팀으로 넘어갑니다. 자리마다 무엇을 하고 다음에 누구에게 넘길지가 미리 정해져 있습니다.

결재판은 사람이 직접 들고 다닙니다. 넘기는 규칙까지 적어 두고 기계가 대신 넘기는 것이 워크플로입니다. 워크플로 관리 연합(Workflow Management Coalition, WfMC)의 용어집은 워크플로를 업무 프로세스의 전부 또는 일부를 자동화하는 것으로 정의합니다. 그 과정에서 문서·정보·작업이 절차 규칙 한 벌에 따라 처리를 위해 한 참여자에게서 다른 참여자에게로 넘어갑니다.

무엇을 어떻게 넘길지는 프로세스 정의 안에 적습니다. 프로세스 정의는 업무 프로세스를 모델링이나 워크플로 관리 시스템에 의한 실행처럼 자동화된 조작을 지원하는 형태로 표현한 것입니다. 액티비티의 네트워크와 그들 사이의 관계, 프로세스의 시작과 종료를 가리키는 기준, 그리고 참여자·연관된 응용· 데이터 같은 개별 액티비티에 대한 정보로 이루어집니다. 프로세스 정의는 따로 정의된 하위 프로세스를 참조할 수도 있습니다.

액티비티는 프로세스 안에서 하나의 논리적 단계를 이루는 작업 조각입니다. 컴퓨터 자동화를 지원하지 않는 수동 액티비티일 수 있습니다. 자동화된 워크플로 액티비티일 수도 있습니다. 액티비티는 프로세스가 도는 동안 워크플로 엔진이 스케줄하는 가장 작은 작업 단위인 것이 보통입니다. 사람의 손이 필요한 액티비티는 워크플로 참여자에게 할당됩니다.

flowchart TD
    A["프로세스 정의"] --> B["워크플로 엔진"]
    B --> C["액티비티"]
    C --> D["참여자"]
    D --> E["다음 참여자"]

적어 둔 것과 지금 도는 것은 다른 자리입니다. 프로세스가 도는 동안 개별 프로세스 인스턴스가 여럿 살아 있을 수 있습니다. 인스턴스마다 그 인스턴스에만 해당하는 데이터 한 벌이 딸립니다. 용어집은 이 인스턴스를 워크플로 케이스라고도 부릅니다.

절차 규칙을 언제 정하느냐로 느슨한 구분을 짓기도 합니다. 규칙 대부분을 미리 정해 두는 프로덕션 워크플로와, 프로세스가 도는 도중에 규칙을 고치거나 새로 만들 수 있는 애드혹 워크플로입니다.

배경

업무 프로세스는 여러 액티비티로 나뉩니다. 액티비티마다 그것을 맡는 참여자와 다루는 데이터가 따로 있습니다. 이 넘김을 기계에 맡기려면 절차 규칙이 기계가 다룰 수 있는 형태로 적혀 있어야 합니다. 용어집이 프로세스 정의를 자동화된 조작을 지원하는 형태의 표현이라고 못 박는 자리가 여기입니다. 규칙이 사람의 기억과 서류에만 있으면 자동화할 대상이 없습니다.

그 넘김을 대신해 주는 제품은 여럿이었습니다. 용어집 서두는 모든 워크플로 관리 제품이 어떤 공통된 특징을 지닌다는 점이 인식되었고, 여러 기능에 공통 표준을 씀으로써 잠재적으로 상호운용 수준에 이를 수 있다고 적습니다. 이기종 워크플로 제품 사이의 상호운용, 그리고 전자우편·문서 관리 같은 다른 정보기술 서비스와의 통합이 목표였습니다.

그 공통 용어를 만들려고 세운 비영리 조직이 워크플로 관리 연합이고, 연합이 내놓은 용어집의 표제 항목 가운데 하나가 워크플로입니다. 지금 쓰는 정의가 그 자리에서 나왔습니다. 용어집은 워크플로 관리·워크플로 컴퓨팅·케이스 관리를 같은 뜻으로 함께 적어 두었습니다.

예시

GitHub Actions

GitHub Actions 공식 문서는 워크플로를 하나 이상의 잡을 돌리는 설정 가능한 자동 프로세스로 정의합니다. 워크플로는 저장소에 체크인된 YAML(YAML Ain't Markup Language) 파일로 정의하고 저장소의 .github/workflows 디렉터리에 둡니다. 저장소에서 이벤트가 발생하면 돌고, 수동으로 돌리거나 정해진 스케줄에 돌릴 수도 있습니다. 저장소 하나가 워크플로를 여럿 가질 수 있고, 각각이 풀 리퀘스트를 빌드하고 테스트하는 일, 릴리스가 만들어질 때마다 애플리케이션을 배포하는 일, 새 이슈가 열릴 때마다 레이블을 다는 일처럼 서로 다른 작업 묶음을 수행합니다.

문서는 워크플로가 반드시 갖춰야 할 기본 구성요소를 셋으로 적습니다. 워크플로를 촉발할 이벤트 하나 이상, 각각 러너 머신에서 실행되며 하나 이상의 스텝을 차례로 도는 잡 하나 이상, 그리고 각 스텝이 실행할 스크립트 또는 액션입니다. 액션은 워크플로를 단순하게 만들 수 있는 재사용 가능한 확장입니다.

flowchart TD
    A["이벤트"] --> B["워크플로"]
    B --> C["잡"]
    C --> D["러너"]
    C --> E["스텝"]
    E --> F["스크립트 또는 액션"]

공식 문서의 퀵스타트 예제는 스텝이 여덟입니다. 그중 여섯은 메시지를 찍기만 하는 스텝입니다. 아래는 그 여섯과 실행 이름을 정하는 run-name 을 덜어낸 축약본입니다.

YAML
name: GitHub Actions Demo
on: [push]
jobs:
  Explore-GitHub-Actions:
    runs-on: ubuntu-latest
    steps:
      - name: Check out repository code
        uses: actions/checkout@v6
      - name: List files in the repository
        run: |
          ls ${{ github.workspace }}

on: [push] 가 이 워크플로를 촉발할 이벤트를 정합니다. jobs: 아래의 Explore-GitHub-Actions 가 잡 하나입니다. runs-on: ubuntu-latest 는 그 잡이 도는 러너를 정합니다. steps: 아래 남긴 두 항목이 스텝입니다. 앞은 actions/checkout@v6 이라는 액션을 씁니다. 뒤는 ls 명령을 직접 실행합니다.

Apache Airflow

Airflow 공식 문서는 DAG(Directed Acyclic Graph, 방향성 비순환 그래프)를 워크플로를 실행하는 데 필요한 모든 것을 감싼 모델로 적습니다. DAG 속성으로 드는 것은 워크플로가 언제 돌아야 하는지를 정하는 schedule, 워커에서 실행되는 작업의 개별 단위인 tasks, 태스크가 실행되는 순서와 조건인 태스크 의존관계, 워크플로 전체가 끝났을 때 취할 동작인 callbacks, 그 밖의 운영 세부입니다.

DAG 를 선언하는 방법은 셋인데, 그중 하나가 컨텍스트 관리자인 with 문을 쓰는 것입니다. 그 안에 넣은 것은 암묵적으로 그 DAG 에 딸립니다.

Python
import datetime

from airflow.sdk import DAG
from airflow.providers.standard.operators.empty import EmptyOperator

with DAG(
    dag_id="my_dag_name",
    start_date=datetime.datetime(2021, 1, 1),
    schedule="@daily",
):
    EmptyOperator(task_id="task")

dag_id 가 이 워크플로의 이름입니다. schedule="@daily" 가 도는 주기입니다. 안쪽의 EmptyOperator(task_id="task") 가 태스크 하나입니다. 문서는 돌릴 태스크가 없는 DAG 는 아무것도 아니라고 적습니다. 태스크는 대개 오퍼레이터·센서·태스크플로의 형태로 옵니다.

AWS Step Functions

AWS(Amazon Web Services) Step Functions 문서는 워크플로를 상태 머신이라고도 부른다고 적습니다. 분산 애플리케이션을 만들고, 프로세스를 자동화하고, 마이크로서비스를 오케스트레이션하고, 데이터와 머신러닝 파이프라인을 만드는 데 워크플로를 씁니다. 여기서 워크플로는 이벤트로 움직이는 스텝의 연속이고, 워크플로의 각 스텝을 상태라고 부릅니다. 태스크 상태는 다른 서비스가 수행하는 작업 단위를 나타냅니다. 태스크를 수행하며 도는 워크플로의 인스턴스는 실행이라고 부릅니다.

워크플로 종류는 둘입니다. 스탠다드 워크플로는 실행 이력과 시각적 디버깅을 보여주고, 정확히 한 번 실행되며, 최대 1년까지 돌 수 있습니다. 각 스텝이 정확히 한 번 실행된다는 뜻입니다. 익스프레스 워크플로는 스트리밍 데이터 처리나 사물인터넷 데이터 수집처럼 이벤트 발생률이 높은 작업 부하에 맞춰져 있고, 최소 한 번 실행됩니다. 각 스텝이 한 번 넘게 돌 수도 있고, 적어도 한 번은 돕니다.

경계

GitLab 의 파이프라인도 워크플로인가. 맞습니다.

이름이 다를 뿐 정의가 요구하는 것을 그대로 갖췄기 때문입니다. 정의는 셋을 요구합니다. 적어 둔 절차 규칙, 여러 단계로 나뉜 일, 그리고 사람 손을 떠난 실행입니다. GitLab 공식 문서는 파이프라인을 .gitlab-ci.yml 파일에 YAML 키워드로 설정한다고 적습니다. 규칙이 적혀 있습니다. 파이프라인은 잡으로 이루어집니다. 잡은 컴파일·테스트·배포 같은 작업을 수행하는 명령을 실행합니다. 일이 여러 단계로 나뉘어 있습니다. 파이프라인은 브랜치에 푸시하거나 머지 리퀘스트를 만들거나 스케줄에 걸리는 등 특정 이벤트에 자동으로 돕니다. 사람이 결재판을 들고 다니지 않습니다. 셋을 다 갖췄으니 용어집의 정의 안에 듭니다.

반대로 잡 하나, 스텝 하나는 워크플로가 아닙니다. 용어집은 액티비티를 프로세스 안에서 하나의 논리적 단계를 이루는 작업 조각이자 워크플로 엔진이 스케줄하는 가장 작은 작업 단위로 둡니다. 단계는 워크플로를 이루는 부품이지 워크플로 자신이 아닙니다. 넘길 다음 자리와 그 넘김을 정하는 절차 규칙이 없으면 정의가 성립하지 않습니다.

관련 항목

워크플로를 이루는 단위

프로세스 정의 · 액티비티 · 태스크 · 잡 · 스텝 · 상태 · 하위 프로세스 · 워크 아이템 · 오퍼레이터 · 센서 · 스테이지 · 액션

실행에 관여하는 역할·참여자

워크플로 엔진 · 워크플로 관리 시스템 · 러너 · 워커 · 워크플로 참여자

도는 인스턴스를 가리키는 이름

프로세스 인스턴스 · 실행 · 워크플로 케이스

실행 시점을 정하는 조건

트리거 · 이벤트 · 스케줄 · 태스크 의존관계 · 콜백 · 수동 실행 · 브랜치 · 머지 리퀘스트

워크플로의 하위 종류

프로덕션 워크플로 · 애드혹 워크플로 · 스탠다드 워크플로 · 익스프레스 워크플로

실행이 지키는 보장

정확히 한 번 실행 · 최소 한 번 실행 · 재시도

워크플로를 실제로 구현·채택한 제품과 기업

GitHub Actions · Apache Airflow · GitLab · AWS Step Functions · AWS

다른 제품에서 이 개념을 나타내는 이름과 형식

파이프라인 · 상태 머신 · DAG · YAML

워크플로를 쓰는 목적

자동화 · 오케스트레이션 · 머신러닝

실행이 남기는 산출물

아티팩트 · 배포

워크플로 표준화가 비롯된 배경

워크플로 관리 연합 · 상호운용성

다른 이름: workflow · 워크플로우 · 워크 플로우