AI 에이전트 시대, 워크플로는 왜 필요할까?

매일 오전 9시에 에이전트가 주문을 분석하고 보고서를 보내게 하려면 예약 작업으로 시작할 수 있습니다. 이벤트나 Webhook을 연결하면 데이터가 바뀔 때 작업을 시작할 수도 있습니다.

보고서가 기대에 맞고 처리 과정도 단순하다면, 그것으로 충분할 수 있습니다.

운영하다 보면 요구 사항이 더 구체적으로 바뀝니다. 환불률은 합의한 기준으로 계산해야 하고, 지정된 범위의 데이터만 분석해야 합니다. 고객에게 메시지를 보내기 전에는 승인을 받아야 합니다. 계산 규칙을 수정한 뒤에는 어떤 보고서가 이전 버전을 사용했는지도 알아야 합니다.

이제 고민할 문제는 달라집니다. 어떤 판단을 실행 중인 에이전트에게 맡기고, 어떤 단계는 정해진 규칙을 따르게 할까요? 승인 대기 중인 작업의 상태는 어디에 저장할까요? 담당자가 바뀌어도 처리 과정을 이해하고 유지보수할 수 있을까요?

워크플로는 이런 요구 사항을 정리하는 방법입니다. 단계, 데이터 관계, 승인 조건을 명시적으로 저장하고 실행 시스템이 진행 상태를 관리합니다. 에이전트는 워크플로 구성을 돕거나 이해와 판단이 필요한 작업을 맡을 수 있습니다.

합의한 규칙을 일관되게 실행하기

일일 주문 보고서에서 금액 합산, 상태 분류, 기간 필터링에는 명확한 규칙이 있습니다. 환불률의 분모는 전체 주문인가요, 결제된 주문인가요? 주문일과 환불일 중 어느 날짜를 기준으로 집계하나요? 기준이 정해졌다면 코드에 반영해야 합니다.

에이전트도 그 코드를 호출할 수 있습니다. 워크플로는 여기에 다른 단계와의 관계를 저장합니다. 데이터를 어디서 가져오는지, 계산 결과를 어느 노드에 전달하는지, 어떤 조건에서 보고서를 보내는지 하나씩 확인할 수 있습니다.

고객 의견의 의미, 이상 주문의 가능한 원인, 요약에서 강조할 내용은 AI가 판단할 수 있습니다. 예를 들어 코드로 이상 주문을 추린 뒤 해당 기록을 모델 입력으로 전달하고, 생성된 요약을 알림 단계로 보냅니다.

여기서 고정되는 것은 계산 규칙과 실행 구조입니다. 모델의 판단은 달라질 수 있지만, 받는 데이터와 맡은 일, 출력의 용도는 명확해집니다.

승인을 기다리는 동안 진행 상태 유지하기

고객 답변을 예로 들어 보겠습니다. 에이전트가 이메일을 읽고 주문을 확인한 뒤 답변 초안을 작성했습니다. 이제 담당자의 승인을 기다립니다.

담당자는 몇 시간 뒤에 확인할 수도 있습니다. 시스템은 이번 작업의 입력, 작성한 답변, 완료한 단계, 승인 또는 거절 후의 동작을 저장해야 합니다. 다시 시작할 때도 같은 실행의 상태를 사용해 이미 완료한 단계를 반복하지 않아야 합니다.

에이전트 시스템에도 이런 기능을 구현할 수 있습니다. 워크플로 플랫폼을 선택할 때는 어떤 상태 관리 기능을 제공하는지, 중간 대기와 사람의 결정, 이후 실행 재개를 지원하는지 확인해야 합니다.

트리거는 작업을 시작하고, 알림이나 후속 API 호출은 결과를 전달합니다. 일정, 이벤트, Webhook, 폴링은 에이전트와 워크플로 모두를 시작할 수 있습니다. 아래 그림은 시작 이후 규칙, AI, 승인, 알림이 연결되는 방식을 보여 줍니다.

직접 구성할 수 있는 예시 흐름입니다. 작업에 맞는 트리거를 선택하며 승인은 선택 사항입니다. 실행하려면 데이터 소스, 모델 서비스, 알림 계정을 설정해야 합니다.

Open Flow의 Approval 및 Wait 노드는 대기 상태를 영구 저장합니다. 결정 후에는 완료한 단계를 반복하지 않고 같은 실행을 이어갈 수 있습니다. 사람이 개입하는 작업에서 구체적으로 평가할 수 있는 기능입니다. 승인과 실행 설명 보기

담당자가 바뀌어도 유지보수할 수 있을까?

처음에는 에이전트에게 몇 차례 작업을 시키며 데이터 소스, 집계 기준, 보고서 형식을 정할 수 있습니다. 다른 사람도 유지보수하게 되면 그 결정을 기록해야 합니다.

유지보수 담당자는 주문을 읽는 단계, 환불률을 계산하는 위치, 모델이 받는 데이터, 메시지 발송 조건을 알아야 합니다. 흐름도, 입력 매핑, 노드 코드가 이를 이해하는 데 도움이 됩니다. 프로젝트의 설명과 설정도 계속 관리해야 합니다.

수정 후에는 각 실행이 어느 버전의 로직을 사용했는지 알아야 합니다. 월요일에 환불률 계산 기준을 바꿨다면 지난주 보고서를 확인할 때는 당시 코드와 입력이 필요합니다. 실행 기록을 특정 버전에 연결하면 결과를 대조할 수 있습니다.

기존 에이전트 시스템이 이런 기능을 제공한다면 계속 사용해도 됩니다. 워크플로 플랫폼은 자주 필요한 기능을 한데 모아 팀이 직접 만들고 관리할 일을 줄여 줍니다.

Open Flow로 흐름을 저장하고 실행하기

Open Flow는 OOMOL의 오픈소스 워크플로 플랫폼입니다. OOMOL Flow에서 공식 호스팅을 이용하거나 GitHub 저장소에서 소스 코드와 자체 호스팅 안내를 확인할 수 있습니다. 에이전트가 Flow를 만들면 시각적 작업 공간인 Workbench에서 같은 흐름을 확인하고 수정할 수 있습니다.

에이전트는 oo flow로 노드를 만들고 초안을 검사하며 테스트 실행과 결과 조회를 수행합니다. Workbench에서는 데이터 소스, 각 단계의 코드, 분기 조건을 확인할 수 있습니다. 호환 클라이언트는 Server의 MCP 도구로도 흐름을 구성하고 실행할 수 있습니다.

일일 보고서에는 Code Task로 JavaScript 계산과 데이터 변환을 수행하고, LLM Task로 요약을 생성할 수 있습니다. 여러 도구 호출이 필요하다면 Agent Task를 사용합니다. 입력과 출력에는 명확한 이름과 타입이 있으며 반복 로직은 하위 흐름으로 정리할 수 있습니다.

배포 후에도 흐름을 수정해야 합니다. Open Flow는 게시할 때 버전이 있는 스냅샷을 만들어 Live 자동화에 사용합니다. 초안을 계속 편집하고 테스트한 뒤 준비되면 새 버전을 게시할 수 있습니다. 실행 이력은 해당 리비전에 연결되어 보고서를 생성한 코드와 흐름을 확인할 수 있습니다.

외부 앱 데이터를 읽고 알림을 보내려면 적절한 계정과 권한을 설정해야 합니다. Open Flow는 OpenConnector 같은 Connector 런타임을 통해 작업을 실행합니다. 계정 자격 증명은 Connector가 보관하며 Flow는 연결 식별자를 참조합니다. Open Flow 기능과 운영 방식 보기

공식 호스팅의 운영은 OOMOL이 담당합니다. 자체 호스팅에서는 팀이 저장소, 백업, 업그레이드, 서비스 연결을 관리합니다. Apache-2.0 라이선스를 사용하며 현재 Beta 단계입니다. 계정 연결과 에이전트 설정은 Flow 시작 가이드를 참고하세요.

실제 작업으로 시작하기

고정 규칙이나 사람의 승인이 필요한 반복 작업을 하나 고르세요. OOMOL Flow를 열고 필요한 데이터 소스와 알림 계정을 연결한 뒤 에이전트에게 요청하세요.

주문 일일 보고서 Flow를 만들어 주세요. 전날 주문을 읽고, 제가 확인한 기준으로 금액과 환불률을 계산한 다음 AI로 이상 사항을 요약해 지정한 팀 채널에 보내 주세요. 먼저 초안을 만들고 테스트한 뒤, 제가 결과를 확인하면 게시해 주세요.

Workbench에서 데이터, 코드, 출력을 확인하세요. 예약 실행하는 에이전트로 충분하면 계속 사용해도 됩니다. 명확한 규칙, 승인, 버전 기록이 필요할 때 이 Flow를 운영할지 판단하세요.

• OOMOL Flow를 열고 첫 워크플로 만들기
• 자체 호스팅이나 개발 참여를 원하나요? Open Flow 소스 코드와 배포 안내 보기.