GenAI 애플리케이션이 실제 업무에 들어가면 모델 호출 한 번으로 끝나는 경우는 드뭅니다. 문서를 추출하고, 요약하고, 안전성을 검사하고, 담당자가 승인한 뒤에야 결과를 게시하는 여러 단계의 흐름이 됩니다. AIP-C01 공식 시험 가이드는 이런 흐름을 설계하는 도구로 AWS Step Functions를 11개 세부 항목에서 반복해서 언급합니다. 이번 포스팅에서는 Bedrock Agents, Amazon Bedrock Flows, Step Functions 중 무엇을 언제 고르는지부터 재시도·폴백·사람 승인·병렬 처리 패턴까지 시험에 나오는 Step Functions 설계를 정리합니다.
세 가지 오케스트레이션 도구: Agents vs Flows vs Step Functions
세 도구 모두 "여러 단계를 이어서 실행한다"는 점은 같지만, 다음 단계를 누가 결정하는지가 다릅니다.
| 구분 | Bedrock Agents | Amazon Bedrock Flows (구 Prompt Flows) | AWS Step Functions | |------|----------------|----------------------------------------|--------------------| | 다음 단계 결정 | 모델이 런타임에 결정 (ReAct) | 개발자가 시각적으로 정의 | 개발자가 상태 머신으로 정의 | | 강점 | 비정형 요청, 도구 선택 자율화 | 노코드 프롬프트 체인, 조건 분기 | 재시도·오류 처리, 장기 실행, 사람 승인, 실행 이력 | | 연동 범위 | Action Group(Lambda, OpenAPI), Knowledge Base | 프롬프트·Knowledge Base·Lambda·Agent 노드 | 200개 이상 AWS 서비스와 직접 통합 | | 시험 키워드 | "스스로 판단해 API 호출" | "비개발자가 프롬프트 흐름 구성" | "정해진 순서, 감사, 승인 대기" |
시험 문제는 보통 요구사항 한 줄로 갈립니다. "처리 순서가 정해져 있고 각 단계의 실행 기록을 감사해야 한다", "검토자가 승인할 때까지 기다려야 한다", "실패한 단계만 재시도해야 한다"는 표현이 나오면 Step Functions입니다. "사용자 요청에 따라 어떤 API를 부를지 모델이 판단한다"면 Bedrock Agents, "개발 지식이 없는 팀이 프롬프트 체인을 시각적으로 만든다"면 Bedrock Flows입니다.
실무에서는 둘을 조합하는 경우가 많습니다. Step Functions가 전체 업무 흐름(접수 → 분석 → 승인 → 게시)을 잡고, 그중 한 단계에서 Bedrock Agent를 호출해 자율적인 도구 사용을 맡기는 구조입니다.
Step Functions 핵심 개념 빠르게 정리
Step Functions 워크플로는 상태(State)를 이어 붙인 상태 머신입니다. GenAI 설계에 자주 쓰는 상태는 다음과 같습니다.
: Lambda, Bedrock, SageMaker 같은 서비스를 호출하는 작업 단계 : 이전 결과 값에 따라 다음 단계를 분기 (예: 품질 점수가 기준 이상인지) : 서로 다른 작업을 동시에 실행하고 결과를 모음 : 배열의 각 항목에 같은 처리를 반복 , , , : 대기, 값 전달, 종료
워크플로 유형은 두 가지이며, 시험에서는 차이를 묻는 문제가 자주 나옵니다.
| 구분 | Standard 워크플로 | Express 워크플로 | |------|------------------|------------------| | 최대 실행 시간 | 1년 | 5분 | | 실행 보장 | 정확히 한 번(exactly-once) | 최소 한 번(비동기) | | 콜백(.waitForTaskToken)·.sync | 지원 | 미지원 | | 실행 이력 | 콘솔에서 단계별 이력 조회 | CloudWatch Logs로 확인 | | 적합한 상황 | 사람 승인, 장기 실행, 감사 필요 | 초당 수천 건의 짧은 이벤트 처리 |
사람의 승인을 기다리는 흐름은 몇 시간에서 며칠이 걸릴 수 있으므로 Standard 워크플로를 선택해야 합니다. 또 하나 기억할 숫자는 상태 사이에 전달되는 데이터 크기 한도 256 KiB입니다. 긴 문서나 큰 모델 응답은 S3에 두고 경로만 넘기는 것이 기본 패턴입니다.
Lambda 없이 Bedrock 호출하기: 최적화 통합
Step Functions는 Amazon Bedrock과 최적화 통합(optimized integration)을 제공합니다. 리소스를 쓰면 Lambda 함수를 따로 만들지 않고 워크플로에서 바로 모델을 호출할 수 있습니다. 파인튜닝 작업도 로 실행하고 완료될 때까지 기다릴 수 있습니다.
InvokeModel 통합에는 Bedrock API에 없는 , 필드가 추가되어 있습니다. 요청 본문이 256 KiB를 넘으면 에 S3 경로를 지정하고, 응답을 의 S3 경로에 쓰게 하면 상태 데이터에는 S3 참조만 남습니다.
여러 프롬프트를 순서대로 이어 앞 단계의 출력을 다음 단계의 입력으로 쓰는 프롬프트 체이닝(prompt chaining)도 이 방식으로 구현합니다. 단계마다 다른 모델을 지정할 수 있어 요약은 경량 모델, 최종 검토는 상위 모델에 맡기는 식으로 비용을 조절할 수 있습니다.
재시도·Catch·타임아웃으로 안전장치 만들기
공식 가이드 2.1.3은 "통제된 FM 동작을 보장하는 안전한 워크플로"를 요구합니다. Step Functions에서는 다음 장치로 구현합니다.
: 오류 이름()별로 재시도 정책을 정합니다. 기본값은 첫 대기 1초(), 최대 3회(), 대기 시간 2배 증가()입니다. Bedrock 스로틀링처럼 여러 실행이 동시에 실패하는 상황에서는 로 대기 상한을 두고 로 재시도 시점을 무작위로 흩어야 재시도가 한꺼번에 몰리지 않습니다.
: 재시도로도 해결되지 않으면 지정한 상태로 넘어갑니다. 경량 모델로 다시 시도하거나 "잠시 후 다시 시도해 주세요" 같은 안전한 응답을 돌려주는 폴백 상태를 둡니다. 를 지정하면 원래 입력과 오류 정보를 함께 다음 상태로 넘길 수 있습니다.
와 : 작업이 너무 오래 걸리거나 진행 신호가 끊기면 오류로 처리합니다.
멈춤 조건(stopping condition): 모델이 초안을 고치고 다시 평가하는 자기 개선 루프는 반복 횟수를 상태에 기록하고 로 "3회 초과 시 종료"를 강제해야 무한 루프와 비용 폭증을 막을 수 있습니다.
서킷 브레이커: 특정 모델 호출이 연속으로 실패하면 DynamoDB에 실패 상태를 기록하고, 이후 실행은 에서 이 상태를 확인해 모델 호출을 건너뛰고 바로 폴백으로 보냅니다. 일정 시간이 지나면 다시 호출을 허용합니다. 공식 가이드 1.2.3이 서비스 장애 대응 방법으로 명시한 패턴입니다.
사람 검토(Human-in-the-loop): .waitForTaskToken 콜백 패턴
의료 안내문, 금융 상품 설명처럼 모델이 만든 결과를 사람이 승인해야 하는 경우 콜백 패턴을 씁니다.
검토 요청 단계의 리소스 이름 끝에 을 붙입니다 (예: ). Step Functions가 발급한 태스크 토큰을 메시지에 담아 검토자에게 전달합니다. SNS 이메일, 사내 검토 화면 등 어떤 채널이든 가능합니다. 워크플로는 이 단계에서 일시 정지하며, 대기 중에는 상태 전환이 일어나지 않아 비용이 거의 들지 않습니다. 검토자가 승인 버튼을 누르면 API Gateway와 Lambda가 를 호출하고, 반려하면 를 호출합니다. 워크플로는 결과를 받아 게시 단계나 수정 단계로 이어집니다.
승인 기한이 필요하면 로 상한을 두고, 기한이 지나면 상급자에게 넘기는 상태로 합니다. 공식 가이드 2.1.5의 "API Gateway로 피드백 수집" 역시 같은 구조로, 검토자의 의견을 함께 저장하면 다음 프롬프트 개선에 활용할 수 있습니다.
Amazon Augmented AI(A2I)와 헷갈리기 쉽습니다. A2I는 Textract나 Rekognition 같은 ML 예측의 신뢰도가 낮을 때 사람 검토 작업을 만들어 주는 서비스입니다. "생성형 AI 결과를 업무 승인 절차에 넣는다"는 요구에는 Step Functions 콜백 패턴이, "추출 신뢰도가 낮은 항목만 사람에게 보낸다"는 요구에는 A2I가 맞습니다.
!사람 검토를 포함한 Step Functions GenAI 워크플로
병렬 처리와 대량 처리: Parallel, Map, Distributed Map
상태는 같은 입력을 여러 분기에 동시에 보냅니다. 하나의 질문을 두 모델에 보내 결과를 비교하거나, 요약·감성 분석·키워드 추출을 동시에 실행한 뒤 합치는 모델 앙상블(공식 가이드 2.1.4)에 적합합니다.
상태는 배열의 항목마다 같은 처리를 반복합니다. 인라인 모드는 실행 하나 안에서 반복하므로 동시 실행 수가 제한적이고, 항목이 수만 개라면 Distributed Map을 씁니다. Distributed Map은 S3에 있는 파일 목록이나 CSV·JSON을 직접 읽어 최대 10,000개의 하위 실행을 병렬로 돌리고, 허용 실패 비율()도 지정할 수 있습니다.
Bedrock Batch Inference와 구분해야 합니다. 같은 모델에 대량의 프롬프트를 보내고 결과를 나중에 받아도 된다면 Batch Inference가 단가가 낮고 간단합니다. 반면 항목마다 Textract 추출, 모델 호출, 검증, DB 저장처럼 여러 서비스를 거쳐야 한다면 Distributed Map이 맞습니다.
이벤트 기반 시작과 콘텐츠 기반 라우팅
S3에 문서가 올라오면 EventBridge 규칙이 Step Functions 실행을 시작하는 구조가 대표적입니다. RAG 수집 파이프라인이라면 Textract로 텍스트를 추출하고, Lambda로 정제한 뒤, AWS SDK 통합으로 Knowledge Base의 을 호출하는 순서로 구성합니다.
공식 가이드 2.4.4의 "콘텐츠 기반 동적 라우팅"도 Step Functions로 설계합니다. 첫 단계에서 경량 모델로 요청 유형을 분류하고, 로 코드 질문은 코드에 강한 모델, 긴 문서는 컨텍스트 창이 큰 모델, 민감한 요청은 사람 상담으로 보냅니다. 같은 방식으로 질문을 다시 쓰고(query transformation) 검색한 뒤 답변을 생성하는 RAG 전처리 흐름(1.5.5), 정보가 부족하면 사용자에게 되묻는 확인 흐름(1.6.2)도 만들 수 있습니다.
시험 핵심 정리
"정해진 순서·감사 이력·재시도가 필요한 다단계 GenAI 처리" -- AWS Step Functions (Standard 워크플로) "모델이 런타임에 어떤 도구를 부를지 스스로 결정" -- Bedrock Agents "노코드로 프롬프트 체인·조건 분기 구성" -- Amazon Bedrock Flows (구 Prompt Flows) "Lambda 없이 워크플로에서 모델 호출" -- Step Functions Bedrock 최적화 통합 (bedrock:invokeModel) "256 KiB를 넘는 모델 입력·출력" -- InvokeModel 통합의 Input/Output S3Uri "스로틀링 시 재시도가 한꺼번에 몰리지 않게" -- Retry + MaxDelaySeconds + JitterStrategy FULL "재시도 실패 시 안전한 대체 응답" -- Catch → 폴백 상태 "검토자가 승인할 때까지 실행 일시 정지" -- .waitForTaskToken + SendTaskSuccess/SendTaskFailure "승인 대기가 길어질 수 있는 흐름" -- Standard 워크플로 (Express는 콜백 미지원) "수만 개 문서를 단계별로 병렬 처리" -- Distributed Map "같은 입력을 여러 모델에 동시에 보내 결과 비교" -- Parallel 상태 "반복 장애 시 모델 호출을 잠시 차단" -- 서킷 브레이커 (DynamoDB 상태 + Choice)