정답부터 말하면, Cloudflare Workflows의 human-in-the-loop 구성은 “자동으로 처리할 단계”와 “사람이 승인해야 넘어갈 단계”를 먼저 나누고, 각 단계의 입력값·상태·재시도 기준을 Workflows 인스턴스 단위로 남기는 방식으로 설계하는 것이 안전합니다. 단순히 Worker 코드 안에 확인 버튼을 붙이는 문제가 아니라, 승인 대기 중에도 흐름이 끊기지 않고, 승인 뒤 다음 단계가 같은 문맥으로 이어지도록 durable execution 구조를 잡는 것이 핵심입니다.
요약: Cloudflare Workflows는 Workers 기반의 durable execution 엔진입니다. 긴 업무 흐름, 재시도, 상태 유지, 사람 승인 대기 단계를 한 흐름으로 묶을 수 있습니다. 이 글은 고객 요청 승인, 운영 변경 승인, 문서 처리 확인처럼 “자동화는 하고 싶지만 마지막 확인은 사람이 해야 하는” 업무를 기준으로 설정 순서를 정리합니다. Cloudflare의 화면, 기능명, 제공 범위, 플랜, 요금, 제한값은 바뀔 수 있으므로 실제 적용 전 공식 문서와 대시보드의 현재 안내를 다시 확인해야 합니다.
1. Cloudflare Workflows를 쓰는 상황부터 구분하기
Cloudflare Workflows는 짧은 요청 하나를 처리하는 일반 Worker와 다르게 여러 단계가 이어지는 작업을 다루는 데 맞춰져 있습니다. 예를 들어 폼 접수, 데이터 검증, 담당자 승인, 외부 API 호출, 완료 알림처럼 중간에 시간이 걸리거나 실패 가능성이 있는 단계를 한 흐름으로 묶을 때 유용합니다. 특히 human-in-the-loop는 자동화가 모든 결정을 대신하지 않고, 사람이 확인해야 하는 지점에서 멈춘 뒤 승인 결과를 받아 다음 단계로 진행하는 방식입니다.
먼저 업무를 “즉시 자동 처리 가능한 단계”, “검토가 필요한 단계”, “승인 후 실행할 단계”로 나눕니다. 이 구분이 흐리면 Workflows를 써도 승인 대기 상태가 어디에 남는지, 누가 어떤 값을 확인해야 하는지, 실패 시 어디서 다시 시작해야 하는지 모호해집니다. 시작 전에는 업무 담당자, 승인 기준, 대기 시간, 알림 채널을 문서로 적어두는 것이 좋습니다.
2. 승인 지점을 코드보다 먼저 설계하기
human-in-the-loop 자동화의 첫 번째 설계 대상은 코드가 아니라 승인 지점입니다. 승인자는 무엇을 보고 판단하는지, 승인과 반려 외에 보류가 필요한지, 승인 뒤 어떤 작업이 실행되는지를 먼저 정해야 합니다. 고객 문의 접수라면 문의 요약, 고객 구분, 요청 종류, 처리 우선순위가 승인 화면에 필요할 수 있습니다. 서버 설정 변경이라면 변경 대상, 예상 영향, 되돌리기 방법, 실행 예정 시간이 필요합니다.
승인 화면은 별도 내부 페이지, 관리용 Worker 라우트, 팀 메신저 링크, 운영 대시보드 등으로 만들 수 있습니다. 중요한 것은 Workflows 인스턴스 ID와 승인 요청 ID가 서로 연결되어야 한다는 점입니다. 그래야 승인 버튼이 눌렸을 때 어떤 흐름을 다시 깨워야 하는지 명확해집니다. 승인 링크만 보내고 상태 저장을 외부 메모에 의존하면 재시도나 감사 기록이 약해집니다.
3. Cloudflare Docs 기준으로 Workflows의 기본 역할 이해하기
공식 문서에서 Workflows는 신뢰성 있는 AI 애플리케이션, 데이터 파이프라인, 사용자 생명주기 관리, 자동 이메일, trial expiration, human-in-the-loop approval systems 같은 사례에 쓰이는 것으로 설명됩니다. 핵심은 “durable multi-step execution without timeouts”입니다. 긴 흐름이 네트워크 지연이나 일시 실패 때문에 처음부터 무너지는 것을 줄이고, 단계별 상태를 유지하면서 진행할 수 있다는 의미입니다.
따라서 approval automation을 만들 때는 Worker 하나가 모든 일을 즉시 끝내는 형태보다, Workflow가 전체 진행표를 들고 있고 Worker나 REST API, Wrangler CLI가 시작·조회·트리거 역할을 맡는 구조가 안정적입니다. 운영자는 Workflows를 “긴 업무 흐름의 진행 관리자”로 보고, Worker는 “외부 요청을 받아 Workflows를 시작하거나 승인 결과를 전달하는 입구”로 보는 편이 이해하기 쉽습니다.
4. 트리거 방식: Worker binding, REST API, Wrangler CLI 중 고르기
Cloudflare의 Trigger Workflows 문서는 Workflows를 Workers bindings, REST API, Wrangler CLI에서 시작할 수 있다고 안내합니다. 실제 업무에서는 세 방식의 쓰임이 다릅니다. 웹폼이나 내부 도구에서 요청이 들어오면 Worker binding으로 바로 Workflow instance를 만드는 방식이 자연스럽습니다. 외부 시스템에서 승인 결과를 보내거나 관리 백엔드가 흐름을 시작해야 한다면 REST API가 맞을 수 있습니다. 개발·테스트·운영 점검 중에는 Wrangler CLI로 수동 트리거를 해보는 것이 편합니다.
| 트리거 방식 | 적합한 상황 | 확인할 점 |
|---|---|---|
| Workers binding | 웹폼, 내부 페이지, Worker 라우트에서 즉시 시작 | 입력값 검증과 인스턴스 ID 저장 |
| REST API | 외부 백엔드, SaaS 연동, 승인 콜백 처리 | 인증, 요청 서명, 실패 재전송 정책 |
| Wrangler CLI | 개발 테스트, 운영 점검, 샘플 실행 | 환경 구분과 테스트 데이터 삭제 기준 |
처음 구축할 때는 Wrangler로 작은 샘플을 실행해 흐름 구조를 확인하고, 그 다음 Worker binding으로 접수 라우트를 만들며, 마지막에 필요한 외부 콜백만 REST API로 연결하는 순서를 권장합니다.
5. human-in-the-loop 흐름 예시: 접수, 검토, 승인, 실행
가장 단순한 구조는 4단계입니다. 첫째, 사용자가 폼이나 내부 시스템에서 요청을 제출합니다. 둘째, Worker가 요청을 검증하고 Workflow instance를 만듭니다. 셋째, Workflow가 승인 대기 상태를 만들고 승인자에게 링크나 메시지를 보냅니다. 넷째, 승인 결과가 들어오면 Workflow가 다음 실행 단계로 진행하고 완료 알림을 남깁니다.
이때 승인 대기 상태를 어떻게 표현할지가 중요합니다. 승인자가 오래 응답하지 않는 경우 자동 알림을 다시 보낼지, 일정 시간이 지나면 반려 처리할지, 다른 담당자에게 넘길지 정해야 합니다. Workflows의 장점은 이런 중간 대기와 재시도 정책을 흐름 설계에 포함시킬 수 있다는 점입니다. 단, 승인 UI 자체와 권한 확인은 별도로 신중하게 구현해야 합니다.
6. 입력값과 상태 저장 기준
Workflows에 넘기는 입력값은 작고 명확해야 합니다. 전체 문서 원문이나 민감한 내부 데이터를 무분별하게 넣기보다, 승인 판단에 필요한 요약, 원본 위치, 요청자, 변경 대상, 추적 ID를 중심으로 구성합니다. 큰 파일이나 장기 보관 데이터는 R2, D1, KV, 외부 데이터베이스 같은 별도 저장소와 연결하고, Workflow에는 참조 키를 넘기는 방식이 관리하기 쉽습니다.
- 요청 ID: 외부 시스템과 Workflow instance를 연결합니다.
- 승인 상태: pending, approved, rejected, expired처럼 단순하게 둡니다.
- 승인자 정보: 누가 언제 어떤 결과를 남겼는지 기록합니다.
- 실행 결과: 승인 뒤 실행한 작업의 성공·실패와 재시도 횟수를 남깁니다.
- 사용자 안내 문구: 완료, 보류, 반려 시 알림 내용을 미리 정의합니다.
이 구조를 먼저 정하면 나중에 알림 채널을 Slack, 이메일, 내부 관리자 페이지 중 어디로 바꾸더라도 핵심 상태 모델은 유지할 수 있습니다.
7. 승인 화면과 권한 확인 체크리스트
human-in-the-loop에서 가장 자주 놓치는 부분은 승인 화면의 권한입니다. 승인 링크를 아는 사람이라면 누구나 누를 수 있는 구조는 피해야 합니다. 승인자는 로그인된 내부 사용자여야 하고, 요청 유형에 따라 승인 가능한 역할이 달라질 수 있습니다. 또한 승인 화면에는 “승인하면 무엇이 실행되는지”를 한눈에 보여줘야 합니다. 그렇지 않으면 자동화가 빠르더라도 운영 리스크가 커집니다.
아래 체크리스트를 최소 기준으로 두면 안전합니다.
- 승인 링크에는 추적 ID가 있지만 단독 인증 수단으로 쓰지 않습니다.
- 승인 전 요청 내용, 변경 대상, 예상 결과, 되돌리기 방법을 표시합니다.
- 승인·반려 버튼을 누른 뒤 중복 클릭을 막습니다.
- 승인 결과와 메모를 별도 로그로 남깁니다.
- 승인 완료 후 Workflow instance 상태를 다시 조회해 화면에 표시합니다.
8. 실패, 재시도, 보류 시간을 미리 정하기
자동화는 성공 흐름보다 실패 흐름을 먼저 설계해야 운영에서 덜 흔들립니다. 외부 API가 일시적으로 실패했을 때 다시 시도할지, 승인자가 응답하지 않을 때 알림을 다시 보낼지, 반려된 요청을 수정 후 재제출할 수 있을지 정해야 합니다. Cloudflare Workflows는 durable execution과 재시도 문맥을 다루기 좋지만, 재시도 횟수와 간격은 업무 성격에 맞게 제한해야 합니다.
예를 들어 고객 문의 자동 배정은 몇 번 재시도해도 괜찮지만, 서버 설정 변경 승인 후 실행은 중복 실행이 문제가 될 수 있습니다. 따라서 실행 단계에는 idempotency key를 두고, 이미 실행된 요청이 다시 들어오면 새 작업을 만들지 않도록 처리해야 합니다. 승인 대기 시간이 길어지는 업무라면 만료 상태를 두고, 만료 뒤에는 새 승인 요청을 만들도록 안내하는 편이 깔끔합니다.
9. Cloudflare 환경 구성 시 확인할 항목
실제 설정 전에는 Cloudflare 계정의 Workers, Workflows, Wrangler, 바인딩 설정, 배포 환경을 확인합니다. 개발 환경과 운영 환경을 나누고, 테스트용 Workflow와 실제 Workflow의 이름을 다르게 두는 것이 좋습니다. Wrangler 설정 파일에는 Workflow binding 이름, Worker entrypoint, 환경별 변수, 필요한 저장소 바인딩을 정리합니다. 이름 규칙은 나중에 로그를 볼 때 중요하므로 처음부터 일관되게 잡습니다.
또한 공식 문서의 예시는 시간이 지나며 바뀔 수 있습니다. Cloudflare는 개발자 플랫폼 기능을 계속 확장하고 있으므로, 이 글의 흐름을 그대로 복사하기보다 현재 문서의 코드 예시, 제한값, 배포 명령, 요금 안내를 확인한 뒤 적용해야 합니다. 특히 팀 계정, 권한, 로그 보관, 외부 API 호출 제한은 조직마다 다르게 운영될 수 있습니다.
10. 운영 로그와 모니터링 기준
승인 자동화는 “누가 승인했는가”뿐 아니라 “승인 뒤 무엇이 실행됐는가”까지 보여야 합니다. 운영 로그에는 요청 생성 시각, Workflow instance ID, 승인 요청 ID, 승인자, 승인 결과, 실행 결과, 오류 메시지, 재시도 횟수를 남깁니다. 사용자가 문의했을 때 담당자가 이 로그만 보고 현재 상태를 설명할 수 있어야 합니다.
모니터링은 세 가지를 봅니다. 첫째, pending 상태가 너무 오래 쌓이는지 확인합니다. 둘째, approved 뒤 실행 실패가 반복되는지 확인합니다. 셋째, 같은 요청이 여러 번 실행되는지 확인합니다. 이 세 지표가 안정되면 자동화가 단순히 빠른 것을 넘어 운영자가 신뢰할 수 있는 흐름이 됩니다.
11. 처음 만드는 팀을 위한 적용 순서
처음부터 복잡한 승인 시스템을 만들기보다 작은 업무 하나로 시작하는 것이 좋습니다. 예를 들어 “문서 처리 요청을 접수하고 담당자가 승인하면 완료 알림을 보내는 흐름”처럼 외부 영향이 낮은 작업을 선택합니다. 그 다음 승인 UI, 상태 저장, 재시도, 로그 조회를 하나씩 붙입니다. 이 과정에서 업무 담당자가 실제로 이해할 수 있는 화면 문구와 상태명을 쓰는 것이 중요합니다.
- 업무 흐름을 접수·검토·승인·실행·알림으로 나눕니다.
- Workflow 입력값과 승인 결과 스키마를 정합니다.
- Wrangler 또는 샘플 Worker로 Workflow를 작게 실행합니다.
- 승인 화면과 권한 확인을 붙입니다.
- 실패 재시도, 만료, 중복 실행 방지를 추가합니다.
- 로그 화면 또는 운영 리포트를 만들어 담당자가 확인하게 합니다.
이 순서로 진행하면 Cloudflare Workflows를 단순 코드 예제가 아니라 실제 업무 자동화 시스템으로 확장하기 쉽습니다.
12. 적용 전 최종 체크리스트
마지막으로 아래 항목을 확인합니다. 이 체크리스트를 통과하지 못하면 자동화 적용보다 설계 보완을 먼저 하는 편이 낫습니다.
- 승인자가 무엇을 보고 결정하는지 한 문장으로 설명할 수 있습니다.
- Workflow instance ID와 업무 요청 ID가 서로 연결됩니다.
- 승인 대기, 승인, 반려, 만료, 실행 완료 상태가 구분됩니다.
- 승인 화면은 권한 확인을 거치며 중복 클릭을 막습니다.
- 외부 API 실패와 재시도 기준이 정해져 있습니다.
- Cloudflare 공식 문서의 현재 기능, 화면, 플랜, 요금, 제한값을 확인했습니다.
- 운영자가 로그만 보고 현재 요청 상태를 설명할 수 있습니다.
FAQ
Q1. Cloudflare Workflows는 일반 Worker와 무엇이 다른가요?
일반 Worker는 요청을 받아 빠르게 처리하는 데 초점이 있고, Workflows는 여러 단계가 이어지는 긴 작업을 안정적으로 진행하는 데 초점이 있습니다. 승인 대기, 재시도, 상태 조회가 필요한 업무라면 Workflows가 더 적합합니다.
Q2. human-in-the-loop는 꼭 별도 승인 화면이 필요한가요?
반드시 같은 형태일 필요는 없지만, 승인자가 내용을 보고 결과를 남길 수 있는 안전한 접점은 필요합니다. 내부 관리자 페이지, Worker 라우트, 팀 도구 링크 등 무엇을 쓰든 권한 확인과 로그 기록은 포함해야 합니다.
Q3. 승인자가 응답하지 않으면 어떻게 해야 하나요?
업무마다 만료 시간을 정해야 합니다. 일정 시간 뒤 재알림을 보내거나, 다른 담당자에게 넘기거나, expired 상태로 닫고 새 요청을 만들게 하는 방식이 있습니다. 이 기준을 코드 작성 전에 정하는 것이 좋습니다.
Q4. Cloudflare Workflows만 쓰면 모든 자동화가 해결되나요?
아닙니다. Workflows는 긴 흐름을 안정적으로 관리하는 도구입니다. 승인 화면, 권한 확인, 데이터 저장소, 알림 채널, 운영 로그는 업무 구조에 맞춰 함께 설계해야 합니다.
Q5. 실제 적용 전에 가장 먼저 확인할 것은 무엇인가요?
현재 Cloudflare 공식 문서와 대시보드에서 Workflows 제공 범위, Workers binding 방식, REST API 사용 조건, Wrangler 명령, 플랜과 요금, 제한값을 확인해야 합니다. 기능명과 화면은 업데이트될 수 있습니다.
