빠른 시작: 구매 승인 워크플로

이 튜토리얼에서는 최소 구성의 구매 요청을 사용하여 자산 정의, 워크플로 구성, 설계 검사, 런타임 검증까지 전체 흐름을 완성합니다. 완료하면 신청자가 구매 요청을 제출하고 부서 관리자가 승인하며, 고액 구매는 재무 승인 단계로 계속 진행됩니다.

1. 사전 준비

시작하기 전에 다음 항목을 확인합니다.

• 현재 애플리케이션에 DEVELOPING 상태의 편집 가능한 버전이 있습니다.
• Applicant, Department Manager, Finance Approver 테스트 사용자 또는 역할이 준비되어 있습니다.
• 신청자의 부서에서 부서 관리자를 확인할 수 있습니다.
• 프로세스 자산 편집 권한과 애플리케이션 게시 권한이 있습니다.

2. 필드 만들기

Process Designer → Task Configuration → Fields로 이동하여 다음 사용자 정의 필드를 만듭니다.

Label	Field Type	주요 설정
Applicant Department	Department	부서 하나 선택
Amount	Number	필요하면 통화 단위 설정
Category	Select	Hardware, Software, Service
Required Date	Date	날짜
Reason	Text Area	긴 텍스트
Attachments	Attachment	필요에 따라 개수와 파일 유형 제한
Department Review Comment	Text Area	부서 관리자가 입력하는 검토 의견
Department Review Result	Select	Approved, Rejected 옵션. 워크플로가 자동으로 기록
Finance Review Comment	Text Area	재무 승인자가 입력하는 검토 의견
Finance Review Result	Select	Approved, Rejected 옵션. 워크플로가 자동으로 기록

Field Key는 필드를 저장할 때 시스템에서 자동으로 생성합니다. 사용자가 입력할 필요가 없으며 직접 입력할 수도 없습니다. 이후 워크플로 조건, 담당자 규칙 또는 TQL을 구성할 때 Label로 Key를 추측하지 말고 편집기가 제공하는 필드 후보에서 선택합니다.

제목, 상태, 생성자, 담당자, 생성 시간과 같은 속성에는 시스템 필드를 사용합니다. 같은 의미의 사용자 정의 필드를 별도로 만들지 마십시오.

Department Review Result와 Finance Review Result에는 기본값을 설정하지 않고, 신청자나 승인자가 수동으로 선택하게 하지 않습니다. 초기값은 비워 두고 해당 Approve 또는 Reject 전환의 Post Function이 결과를 기록하도록 합니다.

예상 결과: Fields 목록에 시스템 필드와 위의 사용자 정의 필드 10개가 함께 표시됩니다.

3. 폼 만들기

검토 폼을 Task Type의 네 번째 폼으로 잘못 이해하지 않도록 두 가지 바인딩 유형을 먼저 구분합니다.

• Task Type 폼에는 Create Form, Edit Form, View Form 세 위치만 있습니다.
• 전환 폼은 Workflow의 특정 전환에 바인딩되며 사용자가 Approve 또는 Reject를 클릭할 때만 열립니다.

Task Configuration → Forms로 이동하여 다음 폼 자산을 만듭니다.

• purchaseCreate: Create Form. 신청자가 태스크를 만들 때 제목, 부서, 금액, 카테고리, 필요 날짜, 사유, 첨부 파일을 입력합니다.
• purchaseView: View Form. 요청 정보, Department Review Result, Department Review Comment, Finance Review Result, Finance Review Comment를 하나의 읽기 전용 태스크 상세 화면에 표시합니다. 이 예제에서는 제출 후 비즈니스 필드 수정을 허용하지 않으므로 Edit Form에도 purchaseView를 선택합니다. 업무상 신청자가 완료되지 않은 태스크를 수정할 수 있어야 한다면 purchaseCreate를 재사용하거나 별도의 purchaseEdit 폼을 만듭니다.
• managerReview: Department Review의 전환 폼. 요청 정보는 읽기 전용이며, 부서 관리자는 Department Review Comment만 편집할 수 있습니다.
• financeReview: Finance Review의 전환 폼. 요청 정보는 읽기 전용이며, 재무 승인자는 Finance Review Comment만 편집할 수 있습니다.

이 단계에서는 폼 자산만 만들고 Task Type에는 아직 바인딩하지 않습니다. 워크플로와 권한 스키마를 완성한 후 6절에서 모든 참조 관계를 함께 설정합니다.

예상 결과: Forms 목록에 purchaseCreate, purchaseView, managerReview, financeReview 폼 자산 네 개가 표시됩니다.

4. Step과 워크플로 만들기

Task Configuration → Steps에서 다음 항목을 만듭니다.

• Department Review
• Finance Review

Step은 현재 워크플로 노드의 표시 이름에 그치지 않고 여러 Workflow에서 참조할 수 있는 재사용 가능한 비즈니스 단계 자산입니다. Human Activity를 Step에 바인딩하면 런타임 태스크에 안정적인 stepCode가 기록됩니다. 따라서 여러 Workflow에 걸친 보고서, TQL, 처리 시간, SLA 통계에서 동일한 비즈니스 단계를 집계할 수 있습니다.

예를 들어 Purchase Approval과 Expense Reimbursement 프로세스 모두 재무 승인이 필요하다면, 두 워크플로의 재무 Human Activity가 여기에서 만든 Finance Review Step을 함께 참조하도록 합니다. 그러면 두 워크플로 전체에서 Finance Review의 태스크 수, 평균 처리 시간, SLA 위반율을 집계할 수 있습니다. 이름만 같은 임시 노드를 각 워크플로에 따로 만들지 마십시오. 공통 Step 식별자가 없으면 동일한 재사용 비즈니스 단계로 안정적으로 집계할 수 없습니다.

Department Review도 같은 원칙을 적용합니다. 다른 워크플로에 비즈니스 의미가 같은 부서 검토 단계가 있으면 이 Step을 재사용합니다. 책임 범위, 통계 기준 또는 SLA 정의가 다르면 서로 다른 비즈니스 단계를 잘못 합치지 않도록 별도의 Step을 만듭니다.

그다음 Task Configuration → Workflows로 이동하여 다음 항목을 만듭니다.

• Name: Purchase Approval
• Key: 화면 규칙을 따르는 안정적인 식별자(예: PURCHASEAPPROVAL)를 입력합니다. 저장한 후 표시 이름을 바꾸기 위한 목적으로만 Key를 변경하지 마십시오.
• Category: Procurement
• Allow Revoke: 업무 요구에 따라 활성화합니다.

캔버스를 다음과 같이 구성합니다.

Start → Department Review → Amount Gateway
                         ├─ 소액 → Approved
                         └─ 고액 → Finance Review → Approved

Department Review / Finance Review에서 거절 → Rejected

위 구성은 라우팅, 담당자, 폼, 검증, 결과 기록의 다섯 부분으로 이루어집니다.

1. Task Type의 Create Form에 purchaseCreate, View / Edit Form에 purchaseView를 바인딩합니다.
2. Department Review 담당자는 Applicant Department에서 부서 관리자를 확인합니다. Finance Review 담당자에는 Finance Approver 역할을 선택합니다.
3. Department Review 승인 후 Amount Gateway로 이동합니다. 소액 연결에는 Amount < 10000을 설정하여 Approved로 바로 이동하고, 고액 연결에는 Amount >= 10000을 설정하여 Finance Review로 이동합니다.
4. Department Review에서 나가는 Approve 및 Reject 전환을 선택한 후 오른쪽 패널의 Transition Form에서 managerReview를 선택합니다.
5. Finance Review에서 나가는 Approve 및 Reject 전환을 선택한 후 오른쪽 패널의 Transition Form에서 financeReview를 선택합니다.
6. Show Button을 활성화한 상태로 유지하고 각 전환에 명확한 이름, 확인 메시지, 안내 문구를 설정합니다.
7. 검토 의견에 필수 검증을 추가합니다. 부서 전환에서는 Department Review Comment를, 재무 전환에서는 Finance Review Comment를 검증합니다.
8. Department Review의 Approve 전환에 Functions → Set Task Field를 추가합니다. Field Name으로 Department Review Result를 선택하고 Field Value에 Approved를 입력합니다.
9. Department Review의 Reject 전환에 Functions → Set Task Field를 추가합니다. Field Name으로 Department Review Result를 선택하고 Field Value에 Rejected를 입력합니다.
10. Finance Review의 Approve / Reject 전환에도 같은 방법으로 Finance Review Result를 설정하고 각각 Approved / Rejected를 기록합니다.

같은 검토 폼을 한 노드의 Approve와 Reject 전환 모두에 바인딩할 수 있습니다. 담당자가 승인하거나 거절할 때 Spark는 먼저 해당 전환 폼을 열고 검토 의견을 입력하도록 합니다. 검증을 통과하고 전환이 성공하면 Set Task Field가 실제로 선택한 전환에 맞는 결과를 자동으로 기록합니다. 마지막으로 purchaseView에서 의견과 결과를 읽기 전용으로 함께 표시합니다.

Result 필드를 승인자가 직접 편집하는 Select로 만들지 말고, 폼 버튼으로 화면 표시만 바꾸는 방식에 의존하지 마십시오. 저장된 필드 값이 실제 Approve 또는 Reject 경로와 항상 일치하도록 해당 전환의 Functions에서 결과를 설정해야 합니다.

Conditions, Validators, Functions를 구성할 때는 편집기의 후보에서 필드를 선택합니다. Field Label이나 시스템이 생성한 Field Key를 수동으로 복사하면 Designer가 올바르게 확인하거나 다시 표시할 수 없는 참조가 저장될 수 있습니다.

다음 이미지는 실제로 구성된 워크플로입니다.

예상 결과: 워크플로를 저장한 후 연결되지 않은 노드가 없고 Start에서 모든 종료 노드까지 완전한 경로가 있습니다.

Codex 또는 Claude Code로 워크플로 구성

Spark CLI 설치 및 인증을 완료하고 Codex 통합 또는 Claude Code 통합을 설치했다면 워크플로 요구사항을 AI에 직접 설명할 수 있습니다. AI는 Spark CLI의 의미 기반 명령을 사용하여 노드를 만들고 경로를 연결하며 Step과 폼을 바인딩하고 Conditions, Validators, Post Functions를 구성할 수 있습니다.

요청에는 대상 App, 설계 버전, 노드, 분기 조건, 담당자, 전환 폼, 검증 규칙, 필드 기록 규칙을 명확히 포함하십시오. 예:

spark-sample의 현재 DEVELOPING 버전에 Purchase Approval을 구성한다.
Department Review와 Finance Review Step을 재사용한다. 부서 승인 후 Amount로
분기하여 10000 미만이면 바로 승인하고 10000 이상이면 재무 승인으로 이동한다.
어느 승인에서든 거절되면 Rejected로 종료한다. 부서 및 재무 전환에 각각
managerReview와 financeReview를 바인딩하고 검토 의견을 필수로 한다.
Approve / Reject 후 해당 Review Result에 Approved / Rejected를 기록한다.
기록 전에 대상 App, 버전, 워크플로, 전체 변경 목록을 보여 주고 내 확인을 기다린다.
확인 후 변경을 적용하고 마지막으로 워크플로 검사를 실행한다.

AI 지원 구성은 설계 검토를 대신하지 않습니다. 확인하기 전에 대상 App, 버전, 워크플로를 검증하십시오. 변경 후에는 Process Designer에서 그래픽 구조를 확인하고 적절한 런타임 환경에서 실제 사용자, 권한, 조직 데이터, 분기를 검증합니다. 명령과 전체 예제는 워크플로 의미 기반 편집을 참고하십시오.

5. 권한 스키마 만들기

권한을 처음 구성할 때 빈 스키마에서 모든 부여 규칙을 하나씩 만들 필요는 없습니다. Data & Permission → Permissions에서 Import System Default를 클릭하여 편집 가능한 기본 권한 스키마를 복사합니다.

가져온 후 Configure를 열고 부여 규칙을 검토합니다. 여러 Task Type을 구분하기 쉽도록 Edit를 사용하여 스키마 이름을 Purchase Request Permission으로 바꿀 수 있습니다. 이 예제의 화면에는 가져올 때의 이름인 Default Task Permission이 그대로 표시됩니다. 이미 빈 스키마를 수동으로 만들었다면 Configure를 열고 빈 상태에서 같은 기본 규칙을 가져올 수 있습니다.

스키마의 각 행은 Permission Item + Grant Type + 선택적 Grant Parameter 부여 규칙입니다. 이 예제에서 가져온 기본 스키마에는 다음 주요 규칙이 이미 포함되어 있습니다.

Permission Item	Grant Type	구매 워크플로에서의 역할
Create Task	System User	로그인한 사용자가 구매 요청을 만들 수 있음
View Task	Task Creator	Applicant가 자신이 만든 요청을 볼 수 있음
View Task	Current Assignee	Department Manager 또는 Finance Approver가 배정된 태스크를 볼 수 있음
View Task	Historical Assignee	이미 태스크를 처리한 승인자가 해당 태스크를 계속 볼 수 있음
Transition Task	Current Assignee	현재 담당자만 Approve / Reject 등의 전환을 실행할 수 있음
Revoke Task	Task Creator	Applicant가 워크플로 규칙에 따라 자신이 만든 요청을 철회할 수 있음
Log Work	Current Assignee	현재 담당자가 작업 시간을 기록할 수 있음. Approve / Reject 제어에는 사용하지 않음

Finance Approver에 대해 System Role의 View Task 또는 Transition Task 권한을 별도로 추가할 필요가 없습니다. Finance Approver 역할은 Workflow에서 Finance Review 노드의 담당자를 배정하는 데 사용됩니다. 고액 요청이 해당 노드로 이동하여 배정되면 실제로 태스크를 받은 사용자가 Current Assignee가 되고 위 표의 보기 및 전환 권한을 자동으로 얻습니다. Finance Approver 시스템 역할 전체에 View Task를 직접 부여하면 고액 분기의 대상 태스크뿐 아니라 이 권한 스키마에 바인딩된 모든 구매 태스크를 해당 역할의 모든 사용자가 볼 수 있게 됩니다.

제출 후 Applicant가 태스크를 수정해야 한다면 Edit Task + Task Creator를 추가합니다. 특정 상태에서 실제로 편집할 수 있는지는 워크플로 상태와 사용 가능한 작업에서도 함께 제어해야 합니다. 실제 Permission Item, Grant Type, Grant Parameter 후보는 현재 시스템에 등록된 확장에서 제공되므로 반드시 UI 후보에서 선택하십시오.

6. Task Type 만들기

Task Configuration → Task Types로 이동하여 다음 항목을 만듭니다.

• Task Type Key: PURCHASE
• Task Type Name: Purchase Request
• Category: Procurement
• Default Workflow: Purchase Approval
• Permission Schema: 5절에서 검토한 스키마를 선택합니다. 화면 예제에서는 Default Task Permission을 사용합니다.
• Create Form: purchaseCreate
• View Form: purchaseView
• Edit Form: purchaseView

managerReview와 financeReview는 Task Type에 바인딩하지 않습니다. 이미 Transition Form을 통해 Workflow의 특정 전환에 바인딩되어 있습니다.

예상 결과: Task Type 목록에 Purchase Request가 표시되고 완전성 검사를 통과하며 기본 워크플로, 권한 스키마, 세 개의 폼 위치가 모두 바인딩됩니다.

7. 설계를 검사하고 검증 환경 선택하기

Designer Overview로 돌아가 현재 DEVELOPING 버전을 선택하고 readiness check를 실행합니다. 연결되지 않은 노드, 누락된 담당자, 바인딩되지 않은 자산, 불완전한 권한과 같은 차단 문제를 해결합니다.

구조 검사가 끝나면 현재 단계에 맞는 검증 환경을 선택합니다.

• 빠른 구성과 개인 디버깅은 DEV 런타임 환경을 직접 열어 현재 DEVELOPING 버전을 검증할 수 있습니다. 이 빠른 시작은 이 방식을 사용하며 아래 화면은 모두 DEV 환경에서 캡처했습니다.
• 팀 통합, 공식 인수 테스트 또는 출시 전 검증에서는 현재 버전과 TEST에 게시된 버전 사이의 자산 차이를 확인한 후 승인되면 TEST에 게시할 수 있습니다. TEST 게시는 선택 사항이며 이 빠른 시작을 완료하기 위한 필수 조건이 아닙니다.

readiness check는 구조적인 문제만 발견할 수 있습니다. 실제 조직 데이터, 역할, 권한, 런타임 레코드를 사용한 검증을 대신할 수 없습니다. TEST를 사용하는 경우 게시 방법은 테스트 및 게시를 참고하십시오.

8. DEV에서 런타임 검증하기

이 절의 화면은 DEV 환경에서 캡처했습니다. 준비된 테스트 사용자로 다음 시나리오를 실행합니다.

1. Applicant로 Amount가 10000 미만인 구매 요청을 만듭니다. Department Manager가 승인하면 태스크가 바로 Approved로 이동해야 합니다.
2. Applicant로 Amount가 10000 이상인 요청을 만듭니다. 부서 승인 후 Finance Review로 이동하고 Finance Approver가 승인하면 Approved로 이동해야 합니다.
3. 다른 태스크를 만들고 부서 또는 재무 단계에서 Reject를 선택합니다. Rejected로 이동하는지 확인합니다.
4. Applicant, Department Manager, Finance Approver로 My Created, My Pending, 처리된 태스크를 확인합니다. 대상 사용자만 각 태스크를 보고 처리할 수 있는지 확인합니다.
5. purchaseView를 엽니다. Approve 또는 Reject를 실행한 후 해당 Review Result가 Approved 또는 Rejected로 표시되고 검토 의견에 담당자가 입력한 내용이 유지되는지 확인합니다.

완료 기준: DEV에서 태스크를 만들 수 있고 담당자가 올바르게 확인되며 두 금액 분기와 거절 분기가 예상대로 동작하고 폼, 권한, 검토 결과를 확인할 수 있습니다. TEST에 게시했다면 TEST에서도 같은 시나리오를 반복하고 게시 기록을 확인합니다.

9. 다음 단계

• 필드 상세 구성
• 라우팅과 담당자 이해하기
• Spark CLI로 워크플로 편집하기
• 런타임 문제 해결