제안된 동기화 계획에는 상자가 스무 개 있습니다. 일곱 번째 상자는 상태를 스프레드시트에 복사합니다. 여덟 번째는 이메일 플랫폼에 맞게 형식을 바꿉니다. 아홉 번째는 가져오기를 승인해 달라고 관리자에게 이메일을 보냅니다. 계획은 일곱 번째부터 아홉 번째까지 어느 에이전트가 맡을지 묻습니다.
첫 질문은 그 상자들이 왜 존재하는가입니다. 실제 팀을 감사한 결과가 아니라 설명을 위한 예시입니다.
워크플로 설계에 관한 대화는 업무를 네 가지로 나눕니다. 단계를 삭제하거나, 일반 코드를 쓰거나, 에이전트를 쓰거나, 사람의 결정을 남깁니다. 유용한 전환은 모델을 고르기 전에 일어납니다. 단계를 지우면 그 주변의 모든 장치가 필요 없어질 수 있습니다.
고객이 보는 결과에서 시작하기
워크플로가 만들어야 할 결과를 명시하세요. 매장과 이메일을 연결한다면 “구매한 고객에게 장바구니 알림을 더 이상 보내지 않는다”일 수 있습니다. 이 결과에는 상태, 시점, 제외 규칙이 필요합니다. 스프레드시트, 매일 밤 전체 내보내기, 관리자의 받은편지함이 반드시 필요한 것은 아닙니다.
아래 Tajo 그림은 제안된 매핑과 활성화 전 경계를 검토합니다. 장바구니 알림 중단 기능을 구현한 것은 아닙니다. 그 결과를 얻으려면 먼저 구매 신호와 중단 규칙을 정해야 합니다. 매핑 필드를 하나 더 늘려도 두 결정을 대신할 수 없습니다.
실행 전 동기화 검토
고객 업데이트를 이메일 플랫폼에 동기화해 주세요.
고객 동기화
| 원본 필드 | 대상 필드 | 규칙 |
|---|---|---|
email | EMAIL | 직접 복사 |
first_name | FIRSTNAME | 직접 복사 |
last_name | LASTNAME | 직접 복사 |
합성 데이터 미리보기 통과
필드 3개 매핑 · 대상에 쓰기 없음
Tajo 매핑 도구를 바탕으로 한 예시 화면입니다. 합성 데이터 미리보기와 저장된 초안은 동기화를 활성화하지 않습니다.
결과에서부터 기존 경로를 거꾸로 따라가세요. 각 단계가 사라지면 무엇이 실패할지 묻습니다. 실제 통제에는 답이 있습니다. 동의 정보가 사라지거나, 결제 분쟁이 무시되거나, 허용되지 않은 발송이 일어날 수 있습니다. 관성적인 인계에는 과거의 이유만 남았을 수 있습니다. 예전 시스템에는 파일이 필요했다는 것입니다.
삭제 분류가 안전장치를 지워도 된다는 허가가 아닙니다. 분류 전에 각 단계의 목적을 살펴보세요.
- 필요한 결과고객 결과거꾸로 추적
- 단계 점검목적과 통제불필요한 단계 제거
- 남은 업무소유자와 테스트가 있음
점검을 통해 산출물과 그것을 실제로 보호하는 의존성을 확인합니다. 스프레드시트가 다른 곳에는 없는 비즈니스 판단을 담고 있다면 파일을 없애더라도 판단은 보존해야 합니다.
| 단계 유형 | 질문 | 설명용 장바구니 흐름의 예 |
|---|---|---|
| 제거 | 필요한 결과를 보호하거나 만들나요? | 아무도 읽지 않는 중복 내보내기 |
| 일반 코드 | 규칙이 정확하고 안정적인가요? | 확인된 구매가 있으면 알림을 제외 |
| 모델 판단 | 범위가 정해진 해석이 필요한가요? | 자유 형식 요청을 담당 팀으로 분류 |
| 사람 또는 승인된 정책 | 권한을 부여하거나 중대한 결과를 낳나요? | 고객 데이터 접근 승인 |
이 표는 설계 도구입니다. 실제 기업의 단계가 어떻게 분류됐는지를 보고하지 않습니다.
정확한 규칙은 코드에 넣기
API 호출, 필드 검증, 타임스탬프 비교, 권한 검사는 모델이 즉흥적으로 처리한다고 더 좋아지지 않습니다. 코드는 불변 조건을 표현하고, 두 번 실행해도 같게 동작하며, 살펴볼 수 있는 실패를 남깁니다. 규칙을 명시할 수 있다면 코드를 쓰세요.
장바구니 사례에서 구매 이벤트가 늦거나 두 번 도착할 수 있습니다. 프로그램은 주문을 식별하고 현재 상태를 비교하며 구매가 확인됐으면 알림을 거부해야 합니다. 구매 여부를 확인할 수 없다면 불확실성 상태가 필요합니다. 고객이 구매하지 않았다고 추측할 권한을 모델이 스스로 얻을 수는 없습니다.
정확한 규칙에 잘 맞지 않는 일도 있습니다. 고객 지원 요청이 “어제 구매했는데 영수증에 예전 주소가 나와요”라고 할 수 있습니다. 메시지를 분류하는 데 범위가 정해진 의미 판단이 유용할 수 있습니다. 출력은 알려진 담당 팀 또는 “불확실”이어야지 주문을 변경하라는 무제한 지시가 되어서는 안 됩니다. 모델 결정과 접근 제어를 적용하고 상태를 쓰는 코드를 분리하세요.
에이전트 하나가 단계를 감출 수 있는 이유
“에이전트 하나가 워크플로를 읽고 전부 처리하면 됩니다.” 데모에서는 더 단순해 보일 수 있습니다. 프로덕션에서는 여전히 누군가 에이전트가 왜 레코드를 볼 수 있고, 무엇을 할 수 있으며, 잘못된 동작을 어떻게 되돌릴지 설명해야 합니다. 범위가 넓은 에이전트는 같은 단계를 프롬프트 안에 숨기고 감사할 수 있던 이름표를 없앨 때가 많습니다.
두 번째 반론은 네 가지 분류를 점검하는 데도 시간이 든다는 것입니다. 맞습니다. 짧게 하세요. 고객 결과 하나를 고르고 필요한 단계를 적은 다음 각 단계의 기여를 물어보세요. 일이 줄거나 소유권이 명확해질 때만 가치가 있습니다. 인접 시스템을 모두 정교하게 감사하면 상자 하나가 더 생깁니다.
정상 사례와 실패 사례로 분류를 시험하세요. 삭제한 단계가 숨은 통제였다면 테스트에서 드러나야 합니다. 모델 판단을 예시로 평가할 수 없다면 범위를 좁히거나 사람에게 돌리세요. 고객 예외마다 코드를 바꿔야 한다면 안정적인 기계적 부분과 각 업무의 비즈니스 규칙을 분리하세요.
점검에도 중단 기준이 필요합니다. 모든 업무를 끝없이 쪼개다 보면 분류 비용이 절약한 일보다 커집니다. 남은 각 단계에 소유자, 트리거, 검증 가능한 존재 이유가 생겼다면 멈추세요. 설계를 바꿀 수 있는 불확실성 한 가지를 기록하고 가장 작은 실제 범위에서 시험하세요. 동기화라면 구매 이벤트가 대기 중인 알림을 제외할 만큼 빨리 도착하는지가 그 질문일 수 있습니다. 연동 가이드는 더 넓은 계획 순서를 제공합니다. 네 가지 분류는 그 순서가 불필요한 단계를 보존하지 않게 합니다. 워크플로나 권한이 바뀌면 분류를 다시 살펴보세요.
가장 비용이 적은 단계는 결과에 처음부터 필요 없었던 단계입니다.
자주 묻는 질문
자동화 전에 무엇을 없애야 하나요?
제거 가능한 인계, 중복 레코드, 아무도 쓰지 않는 보고서를 보완하려고만 존재하는 단계는 후보입니다. 삭제 전에 후속 이용 주체와 통제 기능을 확인하세요.
어떤 단계에 모델이 필요한가요?
안정적인 정확 규칙으로 표현할 수 없는 좁은 의미적 판단에 모델을 쓰세요. 관찰 가능한 입력, 타입이 정해진 출력, 불확실할 때의 경로가 있어야 합니다.
어떤 결정은 사람에게 남겨야 하나요?
동의가 필요하거나 권한을 부여하거나 시스템의 허용 범위를 넘는 결과를 낳는 선택은 책임 있는 사람 또는 명시적으로 승인된 정책에 맡기세요.