워크플로 (Workflow)

워크플로(Workflow)는 작업을 어떤 순서와 조건으로 진행하고 다음 단계에 무엇을 넘길지 정한 흐름입니다. 단계별 담당자, 입력과 출력, 승인이나 실패 시의 이동 경로를 포함할 수 있습니다. 사람이 수행하는 절차에도 쓰는 개념이며, 이를 소프트웨어가 실행하게 만든 것이 워크플로우 자동화입니다.

단계와 연결 조건의 표현

문의 접수 뒤 담당자를 배정하고 답변을 검토한 다음 발송하는 과정에서는 각 단계의 완료 조건이 다릅니다. 초안을 만들었다고 검토가 끝난 것은 아니며, 검토를 마쳤어도 발송에 실패할 수 있습니다. 작업 흐름을 정할 때는 단계 이름뿐 아니라 다음 단계로 넘어갈 조건과 넘겨줄 결과를 함께 정합니다. 그래야 현재 어디에서 대기하거나 실패했는지 설명할 수 있습니다.

n8n의 워크플로 소개는 자동화할 과정을 노드와 연결로 구성한다고 설명합니다. 노드는 실행할 기능을 나타내고 연결은 그 결과가 이어지는 관계를 표현합니다. 여러 기능을 화면에 배치해도 입력과 출력이 맞지 않으면 다음 단계에서 사용할 데이터가 없습니다. 연결선이 있다는 사실과 실제로 필요한 값을 전달했다는 사실을 함께 확인합니다.

워크플로는 모든 단계를 무조건 한 줄로 실행하는 구조에 한정되지 않습니다. 입력에 따라 서로 다른 경로를 고르거나 여러 작업의 결과를 모으는 흐름도 있습니다. 승인 대기처럼 사람이 개입하는 단계도 전체 과정 안에 둘 수 있습니다. 이렇게 표현한 흐름과 실제 실행 기록을 구분하면, 설계에는 있는 단계가 특정 실행에서 왜 건너뛰어졌는지 확인할 수 있습니다.

실행 도구가 정하는 구체적인 단위

GitHub Actions의 워크플로 문서는 이벤트로 시작하는 작업을 YAML 파일에 정의하며, 워크플로 안에 job과 step을 둔다고 설명합니다. 파일은 저장소의 .github/workflows에 보관합니다. 이 용어들은 GitHub Actions가 실행을 구성하는 구체적인 단위이며, 다른 도구의 노드나 작업 단위와 이름까지 같다고 가정할 수는 없습니다.

AWS의 Amazon States Language 설명은 상태 기계를 JSON 기반 언어로 정의하는 방식을 소개합니다. 작업을 나타내는 Task와 다음 상태를 고르는 Choice 같은 상태를 사용합니다. 같은 업무 절차를 표현하더라도 도구에 따라 파일 형식과 실행 의미가 달라지므로, 그림이나 이름만 옮기기보다 각 단계의 동작을 대응시킵니다.

스크립트는 워크플로의 한 단계에서 실행할 프로그램이 될 수 있습니다. 전체 흐름은 그 스크립트를 언제 호출하고 성공과 실패를 어떻게 처리할지도 정합니다. 반복 업무를 자동으로 실행하는 구체적 방법은 워크플로우 자동화와 연결되고, 여러 구성 요소의 실행을 조율하는 문제는 오케스트레이션과 맞닿습니다. 흐름과 실행 수단을 구분하면 어느 부분을 바꿀지 정하기 쉽습니다.

실패 경로와 재개 지점

외부 서비스의 응답이 늦어지면 어느 단계에서 얼마나 기다리고 어떤 조건에서 실패로 볼지 정합니다. 재시도할 때도 전체 과정을 처음부터 돌릴지 실패한 단계만 다시 실행할지에 따라 결과가 달라집니다. 이미 발송한 알림이나 생성한 주문을 다시 만들지 않도록 앞선 단계의 완료 기록을 활용할 수 있습니다. 구체적인 재개와 중복 방지 기능은 실행 도구의 계약을 확인합니다.

흐름을 수정할 때는 진행 중인 실행이 어느 정의를 사용했는지도 남깁니다. 단계 이름이 같아도 코드를 바꾸거나 입력 형태를 바꾸면 이전 결과와 새 결과가 다를 수 있습니다. 실행 ID에 정의 버전과 입력, 단계별 결과를 연결하면 실패를 다시 조사할 근거가 생깁니다. 전체 완료 표시만 저장하는 것보다 어느 단계까지 성공했는지 남기는 편이 복구 범위를 좁히는 데 도움이 됩니다.

AI 에이전트를 단계에 넣으면 모델이 만든 결과가 다음 작업의 입력이 됩니다. 결과의 형식과 필요한 조건을 확인하고, 사람의 판단이 필요한 지점은 승인 단계로 표현할 수 있습니다. 모델 응답이 왔다는 이유만으로 발송이나 게시까지 자동으로 이어지게 할지는 업무 정책에 따라 결정합니다. 흐름을 검토할 때는 정상 경로와 함께 거절, 취소, 입력 누락이 생긴 실행도 확인합니다.