Dify의 Chatflow와 Workflow를 분리하는 기준: 대화 기억을 업무 확정 상태로 만들지 않기

def normalize_request(raw, allowed_items):
if not isinstance(raw, dict) or set(raw) != {

를 전달하고, 반환된 `workflow_run_id`
을 업무의 신청 ID 및 버전에 연관시킵니다. **대화 ID, 플로우 실행 ID, 업무 신청 ID는 용도가 다릅니다.** 실행 ID를 얻을 수 있다면, 실행 상세 API로 상태와 출력을 대조할 수 있습니다. Run Workflow, Get Workflow Run Detail

다음 표는 업무 측 DB에 보관할 독자적인 상태(State) 방안입니다. Dify의 실행 상태와 별도로 관리합니다.

| 상태 | 의미 | 다음 동작 |
|---|---|---|
`pending_review` | 검증되었으나 미승인 | 대상 버전을 확인하고, 승인 또는 반송 처리 |
`ready` | 승인된 버전이 현재 버전과 일치 | 실행 권한을 원자적으로(atomically) 획득 |
`running` | 실행 권한을 획득함 | 동일 신청/버전의 병렬 실행을 거부 |
`succeeded` | 업무 측 반영 결과까지 확인됨 | 저장된 결과를 반환 |
`failed` | 반영되지 않았음을 확인함 | 원인 수정 후, 재실행 조건을 판정 |
`unknown` | 반영 여부를 확인할 수 없음 | 대조(照合)로 진행하고, 쓰기 전송을 중단 |
`cancelled` | 업데이트 전에 중단을 확정 | 재개하려면 새로운 실행 판단이 필요 |

`ready → running`
은 DB의 조건부 업데이트로 획득하며, 신청 ID와 버전의 조합에 하나의 실행 레코드를 만듭니다. 외부 API가 Idempotency Key를 수용한다면, 이 조합에서 만든 동일한 키를 재전송 시에도 사용합니다. 상대방 측이 대응하지 않는다면, 참조 번호에 의한 대조나 수동 확인이 필요합니다. 로컬의 고유 제약 조건만으로는 외부 작업이 단 한 번일 것이라고 보장할 수 없습니다.

화면 연결 끊김은 취소(Cancellation)가 아닙니다. 업무 업데이트 직전에도, 저장된 취소 상태와 승인 대상을 재확인합니다. 그럼에도 불구하고 전송 후 중단된 경우 반영이 완료되었을 가능성이 있으므로, 결과가 불분명하면 `unknown`
으로 이동시킵니다. Dify의 실행이 성공했더라도, 업무 업데이트까지 성공했다고 간주하지 않는 것이 핵심입니다.

- '수량을 2에서 3으로 정정한 후, 이전 버전을 승인'하는 작업을 거부합니다.
- 동일한 승인을 두 개의 처리가 동시에 획득해도, 한쪽만 실행으로 진행됩니다.
- 다른 이용자의 신청 ID/대화 ID를 전달해도, 소유자 검증으로 거부합니다.
- Workflow 실패 시에는 업무 업데이트로 진행하지 않고, 이용자가 확인 가능한 상태를 반환합니다.
- 외부 API가 반영 후에 응답을 잃은 경우,
`unknown`
으로 하여 대조(照合)에 보냅니다. - 업데이트 전의 취소와 업데이트 후의 취소에 따라 남는 기록과 안내가 달라집니다.

이것들은 향후 필요한 결합/장애 주입 테스트이며, 이번에는 실시되지 않았습니다. 로그에는 신청 ID, 버전, 허용된 상관관계 ID, Dify 실행 ID, 처리 단계, 결과 구분을 남깁니다. 입력 전체 내용이나 자격 정보를 남기는 설계는 하지 않습니다. 승인 대기 지연 시간, 결과 불명 건수, 중복 거부 건수를 모니터링하면, 사람이 개입해야 할 장소를 파악할 수 있습니다.

비용 측면에서는, Chatflow의 각 턴에서 무거운 처리를 반복하는 구조를 피합니다. 부족 항목 확인 단계에서 발주 후 처리까지 실행하지 않고, 승인된 입력만 Workflow로 전달합니다. 다만 플로우를 분리한다고 해서 토큰이 줄어드는 것은 아닙니다. 대화 턴 수, 전송 이력, Workflow 재실행 횟수, DB/운영비를 종합하여 비교해야 합니다. 절감률이나 ROI는 미측정입니다.

다음 검증에서는 Dify의 버전과 플로우 정의를 고정하고, 정정, 중복 승인, 통신 단절, 외부 반영 후 응답 누락을 재현할 것입니다. 첫 번째 도달점은 '접수 및 승인된 신청 저장'까지로 하고, 대조와 중복 방지를 확인한 후에 업무 업데이트를 연결할 계획입니다.

이 분리를 통해 목표하는 업무 효과는, 재확인과 이중 처리를 줄이는 것입니다. 평가한다면, 확인에 소요된 시간과, 결과 불명을 해소하기까지의 시간을 도입 전후로 비교합니다. 대화가 성립하는 것뿐만 아니라, 실패 후에 무엇이 확정되고 누가 다음 판단을 할 수 있는지까지 설명할 수 있는 설계를 목표로 합니다.

- Dify Key Concepts
- Variable Assigner
- Human Input API Integration Flow
- Send Chat Message
- Run Workflow
- Get Workflow Run Detail