워크플로우

Connect Base 워크플로우 자동화 심화 가이드입니다.

개요

워크플로우를 사용하면 시각적 편집기로 비즈니스 로직을 자동화할 수 있습니다. 코드 없이 복잡한 작업 흐름을 설계하고 실행할 수 있습니다.

트리거 종류

ent 의 workflowexecution.trigger_type enum 은 4가지입니다 (manual, schedule, api, webhook).

수동 (`manual`)

콘솔이나 API 호출(POST /v1/apps/:appID/workflows/:id/run)로 직접 실행합니다.

스케줄 (`schedule`)

정해진 시간에 실행:

Cron 표현식 지원
예: 0 9 * * 1 (매주 월요일 오전 9시)

API (`api`)

워크플로우 별도 엔드포인트 호출. 외부 시스템이 인증 헤더와 함께 POST 합니다.

웹훅 (`webhook`)

웹훅 entity 에 target_type=workflow 로 연결하면 데이터 변경 / 파일 업로드 등의 이벤트가 워크플로우를 트리거합니다.

📌 데이터 변경 자동 트리거는 워크플로우 자체가 아니라 위의 웹훅 → 워크플로우 경유로 구성합니다.

노드 타입

ent 의 functiongroupstep.step_type enum 은 5가지입니다 (function, condition, parallel, merge, delay).

함수 노드 (`function`)

서버리스 함수 호출:

[함수: send-email]
├── 입력: { to, subject, body }
└── 출력: { success, messageId }

조건 노드 (`condition`)

조건식 평가 후 true/false 분기:

[조건: order.amount > 100000]
├── True → [고액 주문 처리]
└── False → [일반 주문 처리]

병렬 노드 (`parallel`)

여러 자식 step 을 동시에 실행. 모든 자식이 완료될 때까지 merge 까지 대기합니다.

[parallel]
├── [함수: charge-card]
├── [함수: send-receipt]
└── [함수: notify-admin]

병합 노드 (`merge`)

parallel 에서 분기된 모든 경로를 합쳐서 다음 step 으로 진행시킵니다.

지연 노드 (`delay`)

지정 시간 동안 대기:

[delay: 7일]
└── 이후 → [리마인드 이메일]

📌 "반복(loop)" / "HTTP" 노드는 워크플로우 빌트인이 아닙니다. 반복은 함수 노드 내부 코드로, HTTP 호출은 함수 노드에서 fetch 등을 사용해 구현합니다.

변수 사용

트리거 데이터

{{ trigger.data }}      // 트리거 데이터 전체
{{ trigger.data.name }} // 특정 필드

이전 노드 결과

{{ nodes.node_1.output }}        // 이전 노드 출력
{{ nodes.send_email.success }}   // 특정 필드

환경 변수

{{ env.SLACK_WEBHOOK_URL }}
{{ env.ADMIN_EMAIL }}

예제: 신규 회원 온보딩

[트리거: user.created]
    │
    ▼
[함수: 환영 이메일 발송]
    │
    ▼
[대기: 1일]
    │
    ▼
[조건: 프로필 완성됨?]
    ├── Yes → [종료]
    └── No → [리마인드 이메일]
             │
             ▼
         [대기: 3일]
             │
             ▼
         [조건: 프로필 완성됨?]
             ├── Yes → [종료]
             └── No → [최종 리마인드]

모범 사례

1. 에러 처리

각 노드에 에러 핸들링 설정:

재시도 횟수 설정
실패 시 대체 경로 지정
에러 알림 설정

2. 테스트 실행

프로덕션 배포 전 테스트:

테스트 데이터로 실행
각 노드 결과 확인
로그 검토

3. 버전 관리

변경사항 추적:

주요 변경 시 새 버전 생성
이전 버전으로 롤백 가능

실행 타임아웃 / Stuck-running 처리 (2026-05-09)

워크플로우 실행이 비정상 종료되어 status: 'running' 상태로 남는 stuck-running 을 방지하기 위해 2-layer 안전망 이 적용됩니다.

in-process defer 안전망: 실행 컨텍스트가 정상 종료되면 자동으로 timeout / failed 로 마감
ExecutionTimeoutScheduler: 5분 주기로 sweep, 1시간 이상 status: 'running' 인 행은 강제 timeout 처리

따라서 트리거 응답이 빠르게 돌아왔더라도 최종 status 는 콘솔의 실행 로그 또는 GET /v1/apps/:appID/workflow-executions/:id 로 비동기 확인하세요. 임계값(5분 / 1시간) 변경은 backend/cmd/core-server/app/scheduler/execution_timeout_scheduler.go 를 참고합니다.

함수 실행도 동일한 스케줄러가 적용됩니다(서버리스 함수 문서 참고).

웹훅

실시간 통신