AWS Step Functions로 워크플로를 ‘눈에 보이게’ 만드는 방법

마이크로서비스·서버리스가 복잡할수록, ‘오케스트레이션’이 답이다
– AWS Step Functions 입문 가이드

---

AWS Step Functions 한눈에 보기
- 목적: 여러 AWS 서비스·Lambda·마이크로서비스를 순서대로, 조건별로 실행해 주는 서버리스 오케스트레이션 서비스
- 핵심 장점: 시각적인 상태 머신(Workflow) 편집기, 재시도·오류 처리·분기·병렬 실행을 코드 대신 JSON 정의로 관리
- 대표 용도: ETL 파이프라인, 배치·대량 데이터 처리, 보안 인시던트 대응, 비동기 비즈니스 프로세스(주문 승인·결제 등)

1. Step Functions가 뭔가요? – “작업 순서를 관리해 주는 두뇌”

AWS 공식 설명에 따르면, AWS Step Functions는 여러 AWS 서비스와 자체 코드를 여러 단계(스텝)로 묶어 실행·관리하는 서버리스 워크플로 서비스입니다. Datadog은 이를 “Lambda·EC2·Batch·SQS·SNS·Glue 등 다양한 컴포넌트를 연결해 멀티스텝 워크플로를 만드는 오케스트레이션 레이어”라고 정의합니다. 핵심는, 마이크로서비스·Lambda를 각각 띄워놓고 애플리케이션 코드에서 직접 호출 순서·에러 처리·재시도 로직을 얽어 쓰는 대신, 상태 머신(State Machine)이라는 JSON 정의로 흐름을 빼내어 관리한다는 점입니다. 이렇게 하면 비즈니스 프로세스 흐름을 콘솔에서 시각적으로 확인하고, 특정 단계 실패·재시도·대기·분기·병렬 처리 등을 서비스 단에서 통일된 방식으로 다룰 수 있습니다.

2. 언제 쓰면 좋은가? – 대표적인 용도들

AWS 공식 유스케이스 페이지와 Datadog 정리 글에서 제시하는 Step Functions 대표 활용 사례는 대략 다음 네 가지 범주로 묶을 수 있습니다.

1) 서버리스·마이크로서비스 오케스트레이션
- 예: 주문 생성 → 결제 승인 → 재고 차감 → 배송 요청 같은 플로우를 Lambda, SNS, SQS, DynamoDB 호출로 나누고, Step Functions가 순서를 관리.

Microservice Orchestration(이미지 출처 : AWS)

2) 데이터 처리·ETL 파이프라인
- 예: S3에 새 데이터가 들어오면 Step Functions가 AWS Batch 또는 Glue, EMR, Athena 등을 호출해 ETL 작업을 돌리고, 마지막에 Redshift를 리프레시.

Data Processing and ETL Orchestration(이미지 출처 : AWS)

3) 보안·운영 인시던트 대응
- 예: IAM 정책이 생성되면 Step Functions가 트리거되어 정책 내용을 검사하고, 위험한 권한이면 일단 롤백 후 관리자 승인 요청 → 승인이면 반영, 아니면 정책 폐기.

Security and IT Automation(이미지 출처 : AWS)

4) 대규모 병렬 처리·배치 작업
- 예: S3 버킷 안 수천 개 객체 리스트에 대해 Map (Distributed) 상태로 수천 개 자식 워크플로를 병렬 실행, 각 객체를 별도의 Lambda·컨테이너 작업으로 처리.

Parrel ETL(이미지 출처 : AWS)

공통점은, “단일 함수·컨테이너로 끝나지 않고, 여러 단계가 연결되는 작업”이라는 점입니다. 이런 시나리오는 애플리케이션 코드 안에 순서를 직접 짜 넣으면 복잡해지고 디버깅이 어려워지기 때문에, Step Functions에 흘려보내는 게 관리 측면에서 유리합니다.

3. 어떻게 생겼나? – 상태 머신(State Machine) 구조

Step Functions 워크플로는 “상태 머신(State Machine)”이라는 JSON 정의 파일로 표현됩니다. JSON 안에는 상태(State)들이 나열되고, 각 상태는 어떤 서비스를 호출할지, 성공·실패 시 어디로 넘어갈지, 재시도·타임아웃·병렬 수행 여부 등을 담습니다. 대표적인 상태 타입으로는 다음이 있습니다.

- Task – Lambda 실행, Batch Job 시작, Glue Job 실행 등 실제 작업 호출
- Choice – 조건 분기(if-else) 처리
- Parallel – 여러 분기를 동시에 실행
- Map – 배열 항목 각각에 대해 같은 작업을 반복(대량 처리에서 핵심)
- Wait – 일정 시간 대기(예: 5분 후 재시도)
- Fail / Succeed – 워크플로를 실패·성공으로 종료

AWS 문서 예시에서, Map(Distributed) 상태는 S3 객체 리스트를 받아 각 객체에 대한 하위 워크플로를 수천 개 병렬로 띄우는 데 쓰입니다. 각 Task는 Lambda, Batch, ECS, Glue 등 220개 이상 AWS 서비스 API와 연결할 수 있고, Step Functions가 각 단계의 상태·로그·실패 지점을 추적해 줍니다.

4. 기본 사용 방법 – “간단한 ETL 워크플로”를 예로

AWS 공식 예시 중 하나인 “S3 → ETL → Redshift 갱신” 흐름을 기준으로, Step Functions를 어떻게 쓰는지 단계별로 정리해 보면 다음과 같습니다.

① 설계 – 어떤 단계를 거칠지 정의
- 예: 　
  1) S3에 새 데이터가 도착했는지 확인 (Lambda) 　
  2) ETL Batch Job 실행 (AWS Batch/Glue/EMR 중 택일) 　
  3) 작업 상태 모니터링 　
  4) 성공 시 Redshift 리프레시, 실패 시 알림(SNS)

② 상태 머신 JSON 정의 작성
- AWS 콘솔의 Step Functions → State machine 생성에서, 시각 편집기(Workflow Studio)를 사용하거나 JSON을 직접 작성.
- 각 단계(Task)의 ARN, 입력·출력 경로, 재시도 정책, 오류 처리(OnError → 어떤 상태로 갈지) 등을 정의.

③ 트리거 연결
- “S3 버킷에 새 객체가 올라오면 Step Functions 실행”이 되도록, EventBridge나 S3 Event로 상태 머신을 트리거.
- API Gateway·CLI·SDK로도 직접 실행(startExecution) 가능.

④ 실행·모니터링
- 콘솔에서 실행 이력을 보면, 각 단계가 언제 시작·종료·실패했는지 타임라인과 다이어그램으로 확인 가능.
- CloudWatch Logs·Metrics와 연동해 에러율·소요시간 등을 모니터링.

⑤ 에러·재시도 정책 튜닝
- Task 상태에 Retry 블록을 정의해 특정 에러 유형에 대해 지수 백오프 재시도 설정.
- Catch 블록으로 실패 시 다른 상태(예: Rollback, Cleanup, Notify Admin)로 분기.

이런 식으로 설계하면, 애플리케이션 코드에서는 “이 워크플로를 실행해라” 정도만 요청하고, 세부 단계·재시도·에러 처리는 Step Functions에 맡기는 구조가 됩니다.

5. 보안·운영 측면에서의 장점

AWS 공식 유스케이스에서는 특히 보안 인시던트 대응 예제를 강조합니다. 예를 들어, 새로운 IAM 정책이 생성될 때 Step Functions 워크플로가 자동으로 트리거되어 다음을 수행합니다.

1) 새로 생성된 정책의 액션 목록을 가져옴 (Lambda Task)
2) 사전에 정의한 “위험 액션 리스트”와 비교
3) 위험하다면 정책을 임시 롤백하고, 관리자에게 SNS·이메일로 알림 발송
4) 관리자가 승인·거부하는 동안 Wait 상태로 대기
5) 승인 시 다시 적용, 거부 시 영구 삭제

이처럼 Step Functions는 사람의 승인 단계(Manual approval)가 포함된 프로세스를 쉽게 표현할 수 있고, 나중에 누가·어떤 조건에서 어떤 결정을 내렸는지 실행 이력에서 추적하기 좋습니다. Datadog 또한 “보안·결제·크레딧 승인 같은 민감한 비즈니스 워크플로에 Step Functions를 쓰면, 오류 처리와 감사(audit)가 쉬워진다”고 평가합니다.

6. 정리 – 어떤 팀에 Step Functions가 특히 잘 맞는가?

AWS·Datadog 자료를 종합해 보면, Step Functions가 특히 잘 맞는 상황은 다음과 같습니다.
AWS Step Functions 가이드 URL : https://docs.aws.amazon.com/step-functions/latest/dg/integrate-services.html

- Lambda·ECS·Batch·Glue·SQS 등 여러 AWS 서비스를 이미 섞어 쓰고 있는 팀
- 업무 프로세스가 “여러 단계 + 조건 분기 + 사람 승인 + 재시도” 구조를 가지는 경우
- ETL·데이터 파이프라인·배치 처리에서, 실패 지점을 추적하고 재시도 정책을 일관되게 적용하고 싶은 팀
- 코드 안에 비즈니스 플로우가 얽혀 있어 유지보수·디버깅이 어려운 모놀리식/레거시 시스템을 쪼개고 싶은 경우

반대로, 단일 Lambda·단일 웹 서비스만으로 끝나는 간단한 시스템이라면 Step Functions까지 쓸 필요는 없습니다. “여러 서비스·단계를 연결하는 순간부터” Step Functions 도입을 고민할 만한 가치가 생깁니다. 즉, 이 서비스는 새로운 컴퓨팅 자원을 추가하는 도구라기보다, 복잡해진 AWS 인프라 위에 “눈에 보이는 워크플로 계층”을 하나 더 얹는 도구라고 이해하면 가장 현실에 가깝습니다.