AWS Step Functions

승인, 결제, 후속 통지처럼 여러 단계를 거치는 작업을 코드 안 if/else와 재시도 로직으로만 묶기 시작하면 실패 지점이 보이지 않습니다. 단계가 하나만 늘어나도 흐름 추적과 복구가 급격히 어려워집니다.

서버리스 아키텍처 초기에는 Lambda 함수를 체이닝하거나 SQS를 조합해 워크플로를 만들었습니다. 주문 접수 → 결제 → 재고 확인 → 배송 요청처럼 단계가 이어지면 각 Lambda가 다음 함수를 직접 호출하고, 실패하면 자체 재시도 로직을 돌렸습니다. 문제는 중간 단계에서 실패했을 때 드러났습니다. 결제는 성공했는데 재고 확인 Lambda가 타임아웃으로 죽으면, 그 실행이 어디까지 진행됐는지 추적할 방법이 없었습니다. 재시도 로직도 함수마다 중복으로 들어가고, 분기 조건이 늘수록 코드 안에 if/else가 얽혀 흐름 자체를 파악하기 어려워졌습니다. 실제로 주문 처리 실패가 나면 운영자가 CloudWatch 로그를 하나씩 뒤져가며 어느 단계에서 멈췄는지 수동으로 복구해야 했고, 건당 수십 분에서 수 시간이 걸렸습니다. 이런 다단계 절차를 코드가 아니라 상태 머신으로 선언하고, 각 단계의 성공·실패·재시도를 플랫폼이 추적하게 하려는 요구에서 Step Functions가 등장했습니다.

Step Functions는 상태 머신으로 작업 순서, Choice 분기, 재시도, 타임아웃을 선언합니다. 각 단계는 Lambda, SQS, SNS 같은 다른 AWS 서비스 호출로 연결할 수 있고, 시각 워크플로 콘솔에서 단계별 상태를 추적하며 오류가 나면 어떤 단계에서 멈췄는지 바로 볼 수 있습니다.

Step Functions와 SQS는 둘 다 비동기 흐름에 등장하지만 책임이 다릅니다. Step Functions는 상태·분기·재시도를 가진 절차 오케스트레이션 엔진이고, SQS는 전달 대상이 메시지를 안전하게 소비하기까지 기다리는 큐입니다. 여러 단계의 순서와 실패 처리를 제어해야 하면 Step Functions를 보고, 작업을 쌓아두고 소비자 속도 차이를 흡수해야 하면 SQS를 보면 됩니다.

주문 승인, 배치 파이프라인, 사람이 끼는 절차, 장시간 작업 조율, 재시도와 분기가 많은 프로세스에 적합합니다. 상태나 분기 없이 이벤트를 단순 라우팅하는 경우에는 과합니다.