castomFLOW

설명해 주세요

문장 한 줄이 들어가면 워크플로가 나와요

자동화를 만들 때 가장 어려운 부분은 결코 만드는 일이 아니었어요. 텅 빈 캔버스, 검색창에 나열된 400개의 연동 서비스, 그리고 10분이면 될 일에 오후를 통째로 쓰게 될지 모른다는 막연한 불안감이 문제였죠. 여기서는 그 부분을 없앴어요.

입력하시는 내용

하려는 작업에 대해 여러분의 언어로, 평범한 문장으로 적어 주세요. 고를 템플릿도, 맞혀야 할 키워드도 없어요. 사람들이 실제로 쓰는 문장은 이런 모습이에요:

“주문이 결제되면 송장을 발행하고, 재고 수량을 차감하고, 배송이 시작되는 즉시 고객에게 배송 추적 링크를 문자로 보내 줘.”

“매주 월요일 아침 7시에 지난주 예약 내역을 가져와서, 절반도 채워지지 않은 공연장을 찾아내고, 상황이 가장 안 좋은 순서로 정렬한 목록을 이메일로 보내 줘.”

“작업 인력이 있는 지역에 악천후 경보가 발령되면, 밤이라도 작업반장들에게 문자를 보내고 당직 관리자용 메모를 열어 줘.”

짧게 쓰는 것보다 길게 쓰는 게 좋고, 깔끔하게 쓰는 것보다 구체적으로 쓰는 게 좋아요. 대기 시간이 하루가 아니라 이틀이어야 한다면 그렇게 적어 주세요. 메시지를 폴란드어로 보내야 한다면 그것도 적어 주세요. 적지 않은 부분은 나중에 바꾸게 될 기본값이 될 뿐인데, 큰일은 아니에요. 그냥 안 쓰도록 되어 있던 1분일 뿐이에요.

그 2분 동안 일어나는 일

문장이 의도로 해석돼요. 무엇이 이것을 시작하는지, 무엇이 일어나야 하는지, 어떤 순서로, 각 지점에서 무엇이 참이어야 하는지요. 그 의도는 실제로 존재하는 단계 목록과 대조돼요. 연결된 계정, 요금제에 포함된 castomAPI 서비스, 그리고 나머지 모든 것을 위한 일반 HTTP이요.

그다음 워크플로가 조립돼요. 순서대로 정렬된 단계들, 정말로 판단이 필요한 곳의 분기, 문장이 기다림을 암시하는 곳의 대기. 필드 매핑은 데이터 구조를 바탕으로 추정되고, 확신이 없던 추정은 추정으로 표시돼요.

마지막으로 검증돼요. 모든 단계의 필수 입력에 출처가 있는지, 모든 분기에 양쪽 경로가 정의되어 있는지, 모든 연결이 이미 존재하거나 아직 만들어야 하는 것으로 표시되어 있는지요. 여러분 앞에 도착하는 워크플로는 실행될 수 있는 워크플로지, 다이어그램이 아니에요.

결과물

편집 가능한 워크플로, 꺼져 있는 상태로, 할 일 목록이 붙어서 나와요. 필요한 연결, 내려진 추정, 추론하지 못한 값들이요. 목록을 하나씩 처리하면 바로 사용할 수 있어요.

문장 한 줄에서 만들어진 워크플로1분 51초
  • ⚡선택된 트리거웹훅 · order.paid. 서명 검증이 기본으로 켜져 있어요.
  • 2단계배송 주소를 참조 데이터와 대조하여 검증해요.
  • 3단계송장을 발행해요. 필드는 주문에서 매핑돼요.
  • 4단계재고를 차감해요. 멱등성 키는 주문 ID로 설정돼요.
  • 5대기배송 웹훅이 도착할 때까지, 또는 5일 중 먼저 오는 때까지.
  • 6단계짧은 링크가 포함된 SMS, 리디렉션 횟수 집계됨.
  • !여러분의 확인이 필요해요연결 2개를 승인해야 해요. 확인이 필요한 추정 필드 1개: 부가가치세율.

여러분이 허가하기 전까지는 꺼져 있어요아직 아무것도 실행되지 않았어요

2분 후면, 이것은 작동하는 프로세스가 돼요.

그다음은 여러분의 차례예요

원하는 방식 그대로 설정하세요

이것이 정말 중요한 부분이고, 바로 그 2분이 시간을 벌어다 준 부분이에요.

무엇이든 바꾸세요

단계를 추가하고, 삭제하고, 순서를 바꾸고, 분기를 나누고, AI 단계를 결정론적 단계로 바꾸세요. 어차피 규칙이 간단하다는 걸 깨달았다면요.

여러분의 말로 표현하세요

워크플로가 보내는 모든 메시지는 여러분이 편집할 수 있는 텍스트예요. 초안은 출발점이고 그렇게 읽혀요. 실제로 발송되는 버전은 여러분의 목소리로 들려야 하죠.

시뮬레이션해 보세요

실제 레코드를 통과시키고 정확한 경로, 모든 값, 전송되었을 모든 메시지를 그대로 읽어보세요. 시뮬레이션 중에는 아무것도 외부로 나가지 않아요.

시뮬레이션과 실행의 차이 →

직접 만드는 것도 여전히 자연스러운 방법이에요

많은 분들이 문장을 직접 입력하지 않아요. 빈 워크플로를 열고, 트리거를 넣고, 단계를 추가해 진행하죠 — 세 단계짜리 작업이라면 설명하는 것보다 이 편이 더 빠를 때가 많아요. 설명이 진가를 발휘하는 곳은 네 갈래 분기와 대기가 있는 열두 단계짜리 작업, 즉 미루고 계셨던 바로 그 작업이에요.

이미 존재하는 워크플로의 변경 사항도 설명으로 만들 수 있어요: "주문이 천 즐로티를 넘으면 창고에도 알림을 보내줘"는 제안된 편집으로 전달되어, 현재 내용과의 차이점(diff)으로 표시되고 수락하거나 거부하시면 돼요. 말씀하시지 않으면 라이브 워크플로에는 아무것도 적용되지 않아요.

2분에 대해: 이는 일반적인 경우에 대한 설명이지 보장이 아니에요. 짧은 워크플로는 더 빠르고, 낯선 연결이 많은 긴 워크플로는 더 걸려요. 확실한 것은 거래의 형태예요 — 문장을 쓰시면 동작하는 결과물을 돌려받고, 오직 본인만 결정할 수 있는 부분에 주의력을 쓰시게 돼요.