TIL - 20260930

About this offer

0930 운영 자동화/AI 워크플로우 심화 (24/N): Workflow Orchestration, Saga, Compensation과 부분 실패 복구 ✅ 1. 자동화가 길어질수록 ‘한 함수’로 처리하면 문제가 생긴다 처음에는 자동화가 단순하다. 주문 상태 변경 → 알림톡 발송 하지만 기능이 늘어나면: 주문 상태 변경 ↓ Audit Log ↓ NotificationJob 생성 ↓ 알림톡 발송 ↓ 외부 Provider 응답 ↓ Webhook 수신 ↓ 고객 상태 업데이트 ↓ 관리자 알림 ↓ 통계 반영 처럼 여러 단계가 연결된다. AI 자동화도 비슷하다. Git 변경 수집 ↓ LLM 분석 ↓ Markdown 생성 ↓ 파일 저장 ↓ Notion 업로드 ↓ Git Commit ↓ Push 이걸 하나의 함수에서 끝까지 처리하면 운영이 어려워진다. ✅ 2. 긴 작업에서는 ‘전체 성공 / 전체 실패’만으로 부족하다 예를 들어: Step 1 Git 수집 SUCCESS Step 2 LLM Report 생성 SUCCESS Step 3 Markdown 저장 SUCCESS Step 4 Notion Upload FAILED 라고 하자. 이때 전체 Workflow를: FAILED 라고만 기록하면 정보가 부족하다. 이미 앞의 세 단계는 정상 완료됐다. 따라서 중요한 것은: 어디까지 성공했는가? 어디서 실패했는가? 다시 시작할 때 어디부터 시작해야 하는가? 다. ✅ 3. Workflow란? Workflow는 여러 작업을 하나의 업무 흐름으로 묶은 것이다. 예: DailyReportWorkflow 안에: COLLECT_GIT GENERATE_REPORT SAVE_MARKDOWN UPLOAD_NOTION 이 존재한다. 각 Step은 독립적인 상태를 가진다. ✅ 4. Workflow와 Job의 차이 Job은 보통: 하나의 실행 단위 다. 예: Notion에 페이지 업로드 Workflow는: 여러 Job/Step의 실행 순서와 상태를 관리 한다. 예: Report 생성 → 파일 저장 → Notion 업로드 이다. ✅ 5. Orchestration이란? Workflow의 다음 Step을 중앙에서 결정하는 방식이다. 예: Workflow Orchestrator ↓ Step 1 실행 ↓ 성공 확인 ↓ Step 2 실행 ↓ 성공 확인 ↓ Step 3 실행 즉 Orchestrator가: 지금 어느 Step인가? 다음에는 무엇을 해야 하는가? 실패하면 어떻게 해야 하는가? 를 알고 있다. ✅ 6. Orchestration과 Choreography 분산 시스템에서는 흔히 두 방식을 구분한다. Orchestration 중앙 Workflow가 순서를 관리한다. OrderWorkflow ↓ Payment ↓ Notification ↓ Complete Choreography 각 서비스가 Event를 보고 다음 Event를 만든다. ORDER_CREATED ↓ Payment Service PAYMENT_COMPLETED ↓ Notification Service NOTIFICATION_SENT 중앙 지휘자가 없다. ✅ 7. 현재 프로젝트에는 Orchestration이 더 이해하기 쉽다 현재는 1인 개발 환경이고 서비스 규모도 상대적으로 단순하다. Choreography를 과도하게 사용하면: 어떤 Event가 어떤 Event를 발생시키는지 전체 흐름을 어디서 봐야 하는지 실패 시 어느 서비스가 복구해야 하는지 가 복잡해질 수 있다. 따라서 중요한 업무 흐름은: 명시적인 Workflow Orchestrator 를 두는 것이 관리하기 쉽다. ✅ 8. 모든 Event를 없애라는 뜻은 아니다 예: Order Status Changed 같은 Domain Event는 여전히 유용하다. 다만 중요한 장시간 업무를: Event A → Event B → Event C → Event D 에만 맡기지 말고 Workflow의 현재 상태를 별도로 기록하는 것이다. ✅ 9. Workflow Instance Workflow 정의와 실제 실행을 구분한다. 예: Workflow Definition DailyReportWorkflow 실제 실행: Workflow Run 2026-09-30 platform 이다. 0929의 Schedule / ScheduleRun과 같은 사고방식이다. ✅ 10. Workflow Definition과 WorkflowRun Workflow Definition = 실행 절차 WorkflowRun = 실제 한 번의 업무 실행 예: DailyReportWorkflow ├─ 09/28 Run ├─ 09/29 Run └─ 09/30 Run ✅ 11. WorkflowRun 상태 예: PENDING RUNNING WAITING SUCCESS FAILED COMPENSATING COMPENSATED MANUAL_REQUIRED CANCELLED 정도로 둘 수 있다. ✅ 12. WAITING 상태가 중요하다 Workflow는 항상 CPU를 사용하며 실행되는 것이 아니다. 예: 알림톡 발송 ↓ 외부 Webhook 대기 처럼 외부 Event를 기다릴 수도 있다. 이때: RUNNING 으로 계속 Worker를 점유할 필요가 없다. WAITING 상태로 저장해두고 Webhook이 오면 다시 Resume한다. ✅ 13. 긴 Workflow가 Worker를 계속 잡고 있으면 안 된다 예: 상품 신청 ↓ 외부 본인인증 대기 ↓ 최대 30분 이런 Workflow에서 Worker 하나가 30분 동안 기다리는 것은 비효율적이다. 대신: Workflow 상태 저장 ↓ WAITING_EXTERNAL_EVENT ↓ Worker 종료 후 Event가 들어오면 재개한다. ✅ 14. Workflow Step 예: interface WorkflowStep { id: string; workflowRunId: string; name: string; status: | 'PENDING' | 'RUNNING' | 'SUCCESS' | 'FAILED' | 'WAITING' | 'SKIPPED'; attemptCount: number; } ✅ 15. Step은 가능한 한 작고 의미 있게 나눈다 너무 크게: PROCESS_ORDER 하나로 만들면 실패 위치를 알기 어렵다. 반대로: READ_FIELD_1 READ_FIELD_2 CHECK_VALUE 처럼 너무 작게 나누면 오케스트레이션이 복잡해진다. 업무 의미 단위로 나누는 것이 좋다. ✅ 16. 좋은 Step 예시 VALIDATE_ORDER UPDATE_ORDER_STATUS CREATE_NOTIFICATION_JOB WAIT_NOTIFICATION_RESULT FINALIZE_ORDER 처럼 실제 업무 단계가 드러나야 한다. ✅ 17. Step은 상태를 바꾸는 경계가 된다 각 Step이 완료될 때: Checkpoint 를 남긴다. 예: Step 1 SUCCESS ↓ DB 저장 ↓ Step 2 실행 Worker가 Step 2 중간에 죽어도 Step 1은 다시 실행하지 않아도 된다. ✅ 18. Checkpoint의 핵심 Checkpoint는: 이 시점까지는 완료됐다는 확정된 사실 이다. AI Workflow에서 매우 중요하다. 예: CODE_MODIFIED SUCCESS TEST SUCCESS REPORT PENDING 이면 Report부터 재개할 수 있다. ✅ 19. Resume는 Workflow의 핵심 기능이다 긴 작업을 안정적으로 운영하려면: 처음부터 Retry 보다: 마지막 성공 Step 이후부터 Resume 가 훨씬 낫다. ✅ 20. 단 Resume 전에 상태를 재검증한다 예: Step 2에서 파일 생성 완료 라고 DB에 기록되어 있어도 실제 파일이 삭제됐을 수 있다. 그래서 Resume 전: Artifact 존재 여부 Version External State Commit SHA 등을 확인한다. ✅ 21. Workflow는 사실 하나의 State Machine이다 예: PENDING ↓ VALIDATING ↓ PROCESSING ↓ WAITING_EXTERNAL ↓ FINALIZING ↓ SUCCESS 잘못된 상태 전이는 차단한다. ✅ 22. State Machine을 명시하는 이유 예: FAILED → SUCCESS 를 아무 조건 없이 허용하면 문제가 생긴다. 정상 흐름은: FAILED → RETRY_PENDING → RUNNING → SUCCESS 처럼 명확해야 한다. ✅ 23. Workflow에서 가장 까다로운 것은 ‘부분 성공’이다 예: 1. 주문 상태 변경 SUCCESS 2. 알림톡 발송 SUCCESS 3. 관리자 통계 업데이트 FAILED 이때: 전체를 Rollback 할 수 있을까? 알림톡은 이미 고객에게 발송됐다. 되돌릴 수 없다. ✅ 24. DB Transaction으로 해결할 수 없는 영역 DB 내부에서는: BEGIN Order Update Audit Log Outbox Insert COMMIT 처럼 Transaction을 사용할 수 있다. 하지만 외부 API까지 포함하면: DB Commit ↓ 외부 알림톡 전송 을 하나의 DB Transaction으로 묶을 수 없다. ✅ 25. Distributed Transaction 문제 예: 우리 DB 외부 Kakao API Notion S3 GitHub 는 서로 다른 시스템이다. 이 모든 시스템에: BEGIN TRANSACTION 을 걸 수 없다. 그래서 Saga 같은 사고방식이 필요하다. ✅ 26. Saga란? 긴 비즈니스 Transaction을 여러 Local Transaction으로 나누고, 중간에 실패하면 이미 완료된 작업을: Compensation 으로 되돌리거나 보정하는 패턴이다. ✅ 27. 일반 Transaction과 Saga 일반 Transaction: A B C 하나 실패 ↓ 전체 Rollback Saga: A SUCCESS B SUCCESS C FAILED ↓ Compensate B ↓ Compensate A 이다. ✅ 28. Compensation이란? 완벽한 Rollback이 아니라: 이미 일어난 업무 효과를 비즈니스적으로 반대되는 작업으로 보정 하는 것이다. ✅ 29. 예: 예약 시스템 좌석 예약 ↓ 결제 ↓ 티켓 발급 티켓 발급이 실패했다면: 결제 취소 좌석 예약 해제 가 Compensation이 될 수 있다. ✅ 30. 모든 Action에 Compensation이 가능한 것은 아니다 예: 고객에게 카카오톡 메시지 발송 은 이미 전송됐다. 이를: 발송 취소 할 수 없다. 이런 Action은 Irreversible Side Effect 다. ✅ 31. Irreversible Action은 뒤쪽에 배치하는 것이 좋다 가능하다면 Workflow를: 검증 ↓ DB 상태 변경 ↓ 필수 데이터 저장 ↓ 외부 메시지 발송 순으로 둔다. 실패 가능성이 높은 검증을 먼저 한다. 되돌릴 수 없는 Action은 가능한 한 뒤쪽에 둔다. ✅ 32. 하지만 무조건 뒤로 보낼 수 있는 것은 아니다 업무상 메시지 발송이 먼저 필요한 경우도 있다. 이때는 Rollback보다: Forward Recovery 를 고려해야 한다. ✅ 33. Rollback과 Compensation은 다르다 Rollback: 실행 전 상태로 완전히 되돌림 Compensation: 업무적으로 최대한 원상태에 가깝게 보정 이다. 예: 고객에게 잘못된 안내 발송 ↓ 메시지 삭제 불가능 ↓ 정정 메시지 발송 은 Compensation이다. ✅ 34. Forward Recovery 이미 일어난 Side Effect를 되돌리지 않고: 앞으로 진행하면서 정상 상태를 만든다. 예: 주문 완료 알림톡 성공 통계 반영 실패 ↓ 통계 반영 Retry 이다. 이 상황에서는 주문과 알림톡을 되돌릴 필요가 없다. ✅ 35. 실제 운영에서는 Forward Recovery가 더 자연스러운 경우가 많다 특히: 메시지 발송 파일 업로드 외부 API Webhook AI 보고서 같은 작업은 완전 Rollback보다: 실패한 단계만 복구 하는 것이 낫다. ✅ 36. Compensation을 무조건 만들 필요는 없다 각 Step마다 먼저 판단한다. Retry 가능한가? Compensation 가능한가? Forward Recovery가 더 나은가? 사람 판단이 필요한가? ✅ 37. Step Policy 예: interface StepPolicy { retryable: boolean; compensatable: boolean; irreversible: boolean; requiresApproval?: boolean; } 같은 Metadata를 둘 수 있다. ✅ 38. Step 예시 Step Retry Compensation Irreversible DB 상태 변경 가능 가능 X S3 업로드 가능 파일 삭제 가능 X Notion 페이지 생성 가능 삭제/Archive 가능 X 알림톡 발송 제한적 사실상 어려움 O Git Commit 가능 Revert 가능 부분적 Production 배포 가능 Rollback 가능 조건부 ✅ 39. Compensation도 실패할 수 있다 예: Step B 실패 ↓ Compensation A 실행 ↓ Compensation A도 실패 할 수 있다. 그래서 Compensation 자체도 하나의 Job으로 관리해야 한다. ✅ 40. Compensation 상태 예: COMPENSATION_PENDING COMPENSATING COMPENSATED COMPENSATION_FAILED MANUAL_REQUIRED 를 둘 수 있다. ✅ 41. Compensation도 Idempotent해야 한다 예: S3 파일 삭제 가 두 번 실행돼도 최종 상태가 같아야 한다. 이미 파일 없음 → 성공 취급 처럼 처리할 수 있다. ✅ 42. Compensation 순서는 반대 방향 Workflow: A → B → C 가 실행됐고 C에서 실패했다면 일반적으로: Compensate B ↓ Compensate A 순서로 간다. ✅ 43. 예: 파일 기반 Workflow 1. Report 생성 2. S3 업로드 3. DB Record 생성 4. 외부 공유 링크 발송 3번 실패했다고 가정한다. 2번 S3 파일을 삭제할 수 있다면 Compensation을 수행할 수 있다. ✅ 44. 하지만 외부 공유 링크까지 이미 발송됐다면 다르다 발송한 메시지를 되돌릴 수 없다. 따라서: 보정 안내 새 링크 발송 관리자 개입 등이 필요하다. 이게 비즈니스 Compensation이다. ✅ 45. 현재 투게더몰에서 Saga가 필요한 영역 모든 기능에 Saga가 필요한 것은 아니다. 특히 다음처럼 여러 시스템이 연결되는 경우 가치가 있다. 주문 상태 변경 + 알림톡 + 외부 API 대량 Export + S3 AI Report + 파일 + Notion + Git 배포 + Health + Rollback ✅ 46. 단순 CRUD에는 Saga를 쓰지 않는다 예: 관리자 메모 수정 같은 단일 DB 작업은 기존 Transaction이면 충분하다. Saga를 붙이면 오히려 복잡해진다. ✅ 47. Saga를 도입할 기준 대략 다음 조건을 볼 수 있다. 여러 시스템에 Side Effect 발생 Workflow가 오래 실행됨 부분 실패 가능성 높음 Rollback이 단순 DB Transaction으로 불가능 실패 후 복구 과정이 중요 ✅ 48. Order Workflow 예시 예: OrderStatusChangeWorkflow Step 1 Validate Transition Step 2 Update Order Step 3 Create Audit Step 4 Create NotificationJob Step 5 Wait Notification Result Step 6 Complete ✅ 49. 여기서 Step 1~3은 DB Transaction으로 묶을 수 있다 굳이 각각 Workflow Step으로 쪼갤 필요는 없다. 예: DB Transaction Step - Order Update - Audit - Outbox 를 하나의 Local Transaction으로 처리한다. ✅ 50. Workflow 안에서도 Local Transaction을 사용한다 중요한 점이다. Saga가 Transaction을 대체하는 것이 아니다. 구조는: Workflow ↓ Local Transaction A ↓ External Side Effect ↓ Local Transaction B 처럼 된다. ✅ 51. Outbox와 Workflow를 같이 사용 예: Order Transaction - 상태 변경 - Audit - Outbox Event COMMIT 후: Outbox Worker ↓ Workflow 다음 Step 으로 진행할 수 있다. ✅ 52. Workflow Orchestrator가 직접 모든 일을 할 필요는 없다 Orchestrator는: 다음 Step 결정 상태 기록 실행 요청 정도를 담당한다. 실제 작업은 기존 Service/Worker가 한다. ✅ 53. Orchestrator가 Business Logic까지 가지면 비대해진다 좋지 않은 구조: WorkflowService 5000줄 주문 로직 알림톡 로직 DB 로직 Notion 로직 Git 로직 좋은 구조: Workflow Orchestrator ↓ Use Case / Worker 호출 이다. ✅ 54. Workflow Step Executor 예: interface WorkflowStepExecutor { execute(context: WorkflowContext): Promise<StepResult>; } 각 Step을 독립 Executor로 구현할 수 있다. ✅ 55. Step Result 예: type StepResult = | { type: 'SUCCESS'; output?: unknown; } | { type: 'WAIT'; waitFor: string; } | { type: 'RETRY'; errorCode: string; } | { type: 'FAIL'; errorCode: string; }; ✅ 56. WAIT가 매우 중요하다 예: 외부 Webhook 기다리기 Human Approval 기다리기 다른 Job 완료 기다리기 같은 장시간 흐름에서 필요하다. ✅ 57. Human Approval도 Workflow Step이다 예: AI 코드 수정 ↓ Test ↓ Release Risk HIGH ↓ WAITING_APPROVAL ↓ 승인 ↓ Deploy 처럼 모델링할 수 있다. ✅ 58. Approval Timeout 영원히 기다리지 않도록: expiresAt 를 둘 수 있다. 예: 24시간 내 승인 없음 → CANCELLED 또는 MANUAL_REQUIRED로 보낸다. ✅ 59. 외부 Event를 기다리는 Step 예: Notification Provider 발송 ↓ WAITING_PROVIDER_RESULT Webhook 수신 시: workflowRunId 또는 Provider Message ID로 Workflow를 찾아 Resume한다. ✅ 60. Correlation ID가 여기서 중요해진다 Workflow 전체가 하나의: correlationId 를 공유한다. 각 Step에는: workflowRunId stepRunId jobId correlationId 가 연결된다. ✅ 61. Workflow Timeline 운영 화면에서: 09:00 Workflow 시작 09:00 VALIDATE SUCCESS 09:01 UPDATE_ORDER SUCCESS 09:01 NOTIFICATION QUEUED 09:02 WAITING_PROVIDER 09:04 Webhook 수신 09:04 FINALIZE SUCCESS 09:04 Workflow SUCCESS 처럼 볼 수 있다. ✅ 62. Workflow 상태를 로그만으로 복원하지 않는다 중요한 상태는 DB에 저장한다. 로그는 분석용이고, Workflow DB 상태는: 현재 어디까지 진행됐는가? 를 결정하는 Source of Truth다. ✅ 63. WorkflowRun 모델 예시 model WorkflowRun { id String @id @default(cuid()) type String status String correlationId String idempotencyKey String @unique currentStep String? input Json? output Json? startedAt DateTime? completedAt DateTime? createdA