Flow Designer Action vs SubFlow vs Script — 어떤 상황에 무엇을 쓸까

개요

Flow Designer의 빌딩 블록은 세 가지다. Action은 단일 작업의 첫 번째 선택지, SubFlow는 같은 Action 묶음을 여러 Flow에서 재사용할 때, Script는 로우코드로 표현이 불가능할 때 꺼내는 마지막 수단이다. 이전 글(§1 Flow Designer 빠른 정복 4컴포넌트 표)에서 이 세 가지를 한 줄씩 소개했다면, 이번 글은 그 한 줄을 실무 결정 기준으로 확장한다.

OOTB(Out-of-the-Box, 기본 제공) 기준 설명입니다. 인스턴스에 따라 액션명·설정 화면이 다를 수 있습니다.

1. 한 표로 보는 차이

	Action	SubFlow	Script
사용 시점	단일 원자 작업	복합 작업 재사용	로우코드 한계 초과
재사용성	OOTB 팔레트 공유	여러 Flow에서 호출	재사용 어려움
로우코드 친화도	최상	높음	낮음
디버깅 용이성	높음 (단계별 로그)	중간 (SubFlow 내부 로그 별도 확인)	낮음 (스크립트 오류 추적 필요)
실행 컨텍스트	Flow 내 단계	Flow 내 중첩 플로우	Server-side, Glide API 직접 작성 가능

2. Action — “가능하면 Action으로 끝낸다”

Action은 Flow Designer에서 가장 작은 단위의 작업 블록이다. 레코드 업데이트, 이메일 발송, 알림 트리거 같은 작업이 OOTB Action 팔레트에 미리 준비되어 있다. 새 Flow를 짤 때 “이 작업, OOTB Action이 있나?” 를 먼저 확인하는 습관을 들이는 것이 핵심이다.

OOTB Action은 ServiceNow 플랫폼이 테스트·유지보수하므로 버전 업그레이드에 강하다. 직접 짠 코드와 달리 업그레이드 시 깨지는 일이 드물다. Action 팔레트에서 필요한 액션을 검색해 끌어다 쓰는 것만으로 대부분의 단순 자동화는 완성된다.

실무 원칙 — Action 하나로 끝나는 작업을 굳이 SubFlow로 감쌀 이유가 없다. 단순할수록 유지보수가 쉽다.

3. SubFlow — “2개 이상 Flow에서 같은 묶음이 반복되면 신호”

SubFlow는 여러 Action을 묶어 하나의 재사용 가능한 단위로 만든 하위 플로우다. SubFlow 편집 시 좌측 패널의 Inputs / Outputs 탭에서 입출력을 명세할 수 있다. 이 Inputs/Outputs 정의가 곧 SubFlow의 인터페이스가 된다.

SubFlow를 꺼낼 타이밍은 명확하다. 동일한 Action 묶음(예: “담당자 알림 + 티켓 상태 업데이트”)이 2개 이상의 Flow에 반복 등장하기 시작했다면, 그것이 SubFlow로 분리할 신호다. 중복을 하나의 SubFlow로 합치면, 나중에 로직을 수정할 때 한 곳만 고치면 된다.

주의 — SubFlow를 만들 때 Inputs/Outputs를 미정의 상태로 두면, 어떤 데이터를 받아 무엇을 반환하는지 호출 측에서 파악하기 어려워진다. SubFlow 이름과 Inputs/Outputs 주석만으로 의도가 전달되어야 한다.

4. Script — “마지막 수단인 이유”

Script는 Flow Designer 안에서 서버 스크립트를 직접 작성하는 블록이다. GlideRecord, GlideSystem 같은 Glide API에 접근할 수 있어 표현력은 가장 높다. 하지만 그 유연함이 오히려 함정이 된다.

스크립트로 작성한 로직은 Flow Executions 로그에서 단계별 Input/Output으로 추적하기 어렵다. 업그레이드 시 API 변경에 따라 조용히 깨질 수 있고, 로우코드 정책을 준수하는 팀에서는 코드 리뷰 비용도 증가한다.

진짜 Script가 필요한 케이스는 좁다. 복잡한 GlideRecord 쿼리로 다수 레코드를 동적으로 집계하거나, 외부 시스템 응답 JSON을 파싱해 동적으로 필드를 조합해야 할 때가 대표적이다. “OOTB Action으로 표현이 안 된다”는 확신이 생겼을 때만 Script를 선택하자.

5. 결정 트리

아래 흐름에 따라 어떤 블록을 선택할지 판단한다.

결정 트리를 왼쪽에서 오른쪽·위에서 아래로 읽으면 된다. “한 번만 쓰는가?”에서 Yes라면 OOTB Action 가능 여부를 확인하고, OOTB로 되면 Action, 안 되면 Script다. “한 번만 쓰는가?”에서 No라면(재사용 필요) Glide API 필요 여부를 확인하고, 필요 없으면 SubFlow, 필요하면 Script다.

6. 흔한 실수

실수 1

Script 남용

OOTB Action으로 충분한 작업(레코드 업데이트, 이메일 발송 등)을 Script로 작성하는 경우다. 업그레이드마다 깨질 위험이 생기고, Flow Executions 로그에서 단계별 추적이 어려워진다. Action 팔레트를 먼저 살펴보는 것이 원칙이다.

실수 2

Action으로 충분한데 SubFlow로 포장

단 하나의 Action을 감싸는 SubFlow를 만들어 복잡도를 높이는 패턴이다. 재사용이 없다면 SubFlow는 오히려 호출 구조만 늘린다. “지금 당장 2개 이상 Flow에서 쓰이는가?”를 자문하자.

실수 3

SubFlow Inputs/Outputs 미정의

SubFlow를 만들 때 Inputs와 Outputs를 정의하지 않으면, 호출하는 Flow에서 어떤 데이터를 넘기고 무엇을 돌려받는지 파악이 어렵다. SubFlow 이름만 보고 의도를 알 수 있어야 유지보수가 쉬워진다.

마무리

이번 글로 시리즈 세 편이 마무리됐다. 첫 글 Incident state 모델 에서 ITSM 기초를 정리하고, 두 번째 글 Flow Designer 자동 라우팅 에서 그 위에 자동화를 얹었으며, 이번 글에서는 Flow를 구성하는 빌딩 블록 선택 기준을 다뤘다. 세 편을 관통하는 맥락은 하나다 — “가능하면 단순하게, 복잡도는 필요할 때만 올린다.”

다음은 어떤 주제가 좋을까? Flow Designer 밖으로 나가 UI Builder나 Now Assist 연동으로 이어갈 수도 있고, Flow 운영 실무(버전 관리, 환경 간 이관)로 파고들 수도 있다. 궁금한 방향이 있다면 언제든 제안해 주세요.