지금까지 본 SQS·SNS·Kinesis는 컴포넌트를 떼어놓는 도구였다. 그런데 현실의 비즈니스 프로세스는 떼어놓은 조각들을 다시 순서대로 엮어야 한다. "주문을 검증하고 → 재고를 확인하고 → 결제하고 → 실패하면 환불하고 → 성공하면 알림을 보낸다." 이걸 Lambda 안에 if-else와 try-catch로 짜 넣으면, 그 함수는 곧 비대해지고 상태는 코드 깊숙이 숨어버려 "지금 어느 단계에서 멈췄는지" 알 수 없게 된다. AWS Step Functions는 이 흐름(workflow)을 코드 밖으로 꺼내 명시적인 상태 기계로 만든다. 그리고 AppSync는 비슷한 정신을 데이터 계층에 적용해, 여러 백엔드에서 데이터를 모으는 "흐름"을 GraphQL 한 쿼리로 선언하게 한다.
DVA-C02에서 Step Functions는 "Lambda를 어떻게 오케스트레이션하나", "Standard와 Express의 차이", "외부 시스템 응답을 어떻게 기다리나"로 자주 나온다. AppSync는 "실시간 구독", "다중 데이터 소스", "API Gateway와의 차이"로 출제된다. 이번 글은 워크플로를 코드에서 분리하는 것이 왜 가치 있는지, 상태 기계라는 이론적 토대, 서비스 통합 패턴(.sync, .waitForTaskToken)이 푸는 문제, 그리고 GraphQL이 REST와 근본적으로 다른 지점을 깊이 들여다본다.