- Published on
AWS Quick Flows와 Strands Agents: 에이전트는 챗봇이 아니라 워크플로 런타임이 된다
- Authors
- Name
- Kyunghyun Park
- @devkhpark
AWS Quick Flows · Strands Agents · Agent Runtime
2026년 4월 27일 AWS가 같은 날 내놓은 두 개의 글은 겉으로 보면 서로 다른 제품 이야기처럼 보인다. 하나는 Amazon Quick Flows로 반복 업무를 자연어로 자동화하는 글이고, 다른 하나는 Strands Agents를 SageMaker AI 모델과 MLflow 관측/평가 체계에 붙이는 기술 글이다.
하지만 두 글을 같이 읽으면 메시지는 꽤 선명하다. 에이전트 경쟁의 중심은 더 이상 “챗봇이 얼마나 똑똑한가”가 아니라, 업무를 어떤 런타임 위에서 실행하고 관측하고 반복 개선할 것인가로 이동하고 있다.
이 글은 AWS의 Amazon Quick Flows 글과 Strands Agents + SageMaker + MLflow 글을 중심으로, OpenAI의 Symphony, Choco 에이전트 사례, Google/Kaggle의 AI Agents Vibe Coding Course까지 함께 보면서 지금 에이전트 시장이 어디로 움직이는지 정리한다.
기준 시점: 이 글은 2026-04-28에 확인한 공식/1차 자료 기준이다. 제품명, API, 지원 모델, 가격, 권한 정책은 빠르게 바뀔 수 있으니 실제 도입 전 각 공급자의 최신 문서를 다시 확인해야 한다.
핵심 thesis: 에이전트는 “대화 인터페이스”에서 “업무 실행 단위”로 바뀌고 있다
초기 AI 에이전트 논의는 대부분 대화창에서 시작했다. 사용자가 요청하고, 모델이 답하고, 필요하면 도구를 호출하는 구조다. 이 방식은 데모에는 좋지만 조직 운영에는 곧 한계가 온다.
실제 업무에는 다음 요소가 필요하기 때문이다.
- 입력을 어디서 받을 것인가
- 어떤 데이터 소스와 연결할 것인가
- 어떤 조건에서 분기할 것인가
- 누가 승인하고 누가 결과를 검토할 것인가
- 실패하면 어디서 재시도할 것인가
- 어떤 모델이 더 싸고 정확한지 어떻게 비교할 것인가
- 실행 로그와 평가 지표를 어디에 남길 것인가
AWS의 이번 두 글은 이 질문에 서로 다른 높이에서 답한다. Quick Flows는 비개발자/현업 사용자가 자연어로 반복 업무 플로우를 만들 수 있게 하고, Strands Agents + SageMaker + MLflow는 개발자/플랫폼 팀이 에이전트 실행과 평가를 생산 시스템으로 끌어올리는 방법을 보여준다.
즉 하나는 업무 자동화의 상단 UX이고, 다른 하나는 에이전트 운영의 하단 control plane이다.
Quick Flows: 자연어 프롬프트가 업무 플로우 스펙이 된다
AWS는 Quick Flows를 “AI workflows”로 반복 업무를 자동화하는 기능으로 소개한다. 사용자는 코드나 ML 전문 지식 없이 자연어로 자동화하고 싶은 일을 설명하고, Quick Flows는 그 설명을 바탕으로 연결된 workflow를 만든다.
AWS가 예로 든 첫 시나리오는 Financial Performance Analyzer다. 사용자가 회사명이나 티커를 입력하면, 플로우는 시장 데이터, 재무 지표, 뉴스, 애널리스트 평가를 모아 구조화된 보고서를 만든다. 중요한 점은 이 과정이 단순한 “답변 생성”이 아니라는 것이다. Quick Flows는 요구사항을 분석하고, web search, AI 분석, 포맷팅, 출력 단계를 연결된 workflow로 조립한다.
글에서 특히 실무적으로 중요한 포인트는 네 가지다.
자연어가 workflow builder의 입력이 된다.
사용자는 “무엇을 모으고, 어떤 판단을 하고, 어떤 액션을 하고, 어떤 결과물을 만들지”를 설명한다. 프롬프트가 곧 초기 업무 스펙이 된다.각 단계가 변수로 연결된다.
입력 단계에서 받은 값이 이후 단계의 변수로 전달된다. 이건 단순 챗봇과 다르다. 플로우 안에서 데이터가 이동하고, 다음 단계가 이전 단계의 결과를 명시적으로 사용한다.reasoning group이 조건/분기 역할을 한다.
AWS는 온보딩 예시에서 reasoning group을 if-then처럼 설명한다. 예컨대 직원 이메일이 기존 시스템에 없을 때만 새 레코드를 만들도록 분기할 수 있다.회사 데이터와 액션 시스템에 붙는다.
문서 저장소, 스프레드시트, 데이터베이스, S3, SharePoint, OneDrive, Google Drive, custom integration 등이 언급된다. 결국 플로우의 가치는 모델 답변보다 기존 업무 시스템과 얼마나 잘 연결되는지에서 나온다.
이 관점에서 Quick Flows는 “또 하나의 챗봇”이 아니다. 더 정확히는 현업 사용자가 반복 업무를 실행 가능한 플로우로 바꾸는 자연어 workflow compiler에 가깝다.
Strands Agents + SageMaker + MLflow: 운영팀이 보는 에이전트의 진짜 문제
Quick Flows가 업무 자동화의 상단 UX라면, Strands Agents + SageMaker + MLflow 글은 플랫폼 팀의 고민을 다룬다. AWS는 기업이 에이전트를 만들 때 managed foundation model 서비스만으로 충분하지 않은 경우가 많다고 말한다. 이유는 분명하다.
- 성능 튜닝
- 비용 최적화
- compliance와 data residency
- 모델 선택권
- 네트워크/보안 아키텍처 통합
- 확장 정책
- 관측과 평가
AWS가 제시한 구조는 꽤 상징적이다. Strands Agents SDK로 agent를 만들고, SageMaker AI endpoint에 배포된 foundation model을 붙이며, SageMaker Serverless MLflow로 tracing과 평가를 한다. 또 여러 모델 variant를 A/B test하고 MLflow metrics로 성능을 비교하는 흐름도 포함한다.
이건 에이전트를 “프롬프트 + 모델 호출”로 보지 않는다는 뜻이다. 운영 환경에서는 다음 질문이 더 중요하다.
| 질문 | 왜 중요한가 |
|---|---|
| 어떤 모델 endpoint를 쓸 것인가 | 비용, latency, data residency, 하드웨어 요구사항이 달라진다 |
| 어떤 tool을 붙일 것인가 | 에이전트가 실제 업무를 수행하려면 외부 시스템 접근이 필요하다 |
| trace를 어디에 남길 것인가 | 실패 원인 분석, 감사, 성능 개선에 필요하다 |
| 모델 variant를 어떻게 비교할 것인가 | “느낌상 더 좋다”가 아니라 지표 기반으로 바꿔야 한다 |
| 배포 후 어떻게 계속 평가할 것인가 | 에이전트는 prompt와 tool, 데이터 변화에 민감하다 |
특히 MLflow를 agent tracing과 평가에 붙이는 대목은 중요하다. 모델 학습/배포에서 쓰던 MLOps 관성이 에이전트 운영으로 넘어오고 있기 때문이다. 앞으로 AI 플랫폼 팀의 일은 모델 API 키를 발급하는 데서 끝나지 않는다. agent run, trace, evaluation, rollback, prompt/tool 변경 이력까지 운영해야 한다.
OpenAI Symphony와 같은 날 나온 이유: 인간의 attention이 병목이다
AWS만 이런 방향을 보는 것은 아니다. OpenAI도 같은 날 Symphony를 공개했다. Symphony는 Linear 같은 issue tracker를 coding agent의 control plane으로 바꾸는 open-source spec이다. OpenAI는 각 열린 task가 agent workspace에 매핑되고, agent가 계속 실행되며, 멈추거나 실패하면 다시 시작하고, 사람이 결과를 review하는 구조를 설명한다.
OpenAI가 글에서 짚은 병목은 매우 현실적이다. interactive coding agent를 여러 개 띄우면 처음에는 생산성이 올라가지만, 곧 사람이 세션을 관리하고, 어느 agent가 무엇을 하는지 기억하고, 중간에 nudging하는 일이 병목이 된다. OpenAI는 이를 “human attention”의 병목으로 본다.
Symphony의 핵심은 세션이 아니라 ticket이다. 사람은 터미널 세션을 직접 몰고 다니는 대신, issue tracker에 업무 단위를 남긴다. 시스템은 task 상태를 state machine처럼 보고 agent를 붙인다. OpenAI는 일부 팀에서 landed PR이 3주 만에 500% 증가했다고 적었다.
이 숫자 자체보다 중요한 것은 구조다.
- Quick Flows는 반복 업무를 자연어 workflow로 만든다.
- Strands + SageMaker + MLflow는 agent 실행을 관측/평가 가능한 운영 스택으로 만든다.
- Symphony는 issue tracker를 agent orchestration control plane으로 만든다.
- Choco는 주문, 음성, 이미지, 문서 입력을 실제 ERP-ready order로 바꾸는 vertical agent 사례를 보여준다.
- Google/Kaggle은 AI agents와 vibe coding을 교육 과정으로 묶어 “agent 만들기” 자체를 대중화한다.
다른 회사, 다른 제품처럼 보이지만 공통점은 하나다. 에이전트는 사람이 계속 대화로 몰고 가는 도구가 아니라, 업무 단위와 상태, 데이터, 평가 체계에 붙는 실행 레이어가 되고 있다.
실무 해석: 한국 개발팀과 운영팀이 지금 봐야 할 체크리스트
이 흐름을 한국 개발자/빌더 관점에서 보면, 당장 “AWS Quick Flows를 써야 하나?”보다 더 중요한 질문이 있다. 바로 우리 조직이 에이전트를 어떤 운영 단위로 받아들일 준비가 되어 있느냐는 점이다.
1) 프롬프트보다 업무 스펙을 먼저 정리해야 한다
에이전트 도입이 실패하는 흔한 이유는 “무엇을 자동화할지”가 아니라 “어디까지 자동화할지”가 불명확하기 때문이다. Quick Flows식 접근은 프롬프트를 잘 쓰는 것처럼 보이지만, 실제로는 업무 스펙을 잘 쓰는 문제다.
좋은 시작점은 다음 네 가지를 한 문장씩 정의하는 것이다.
- 어떤 입력을 받는가
- 어떤 데이터 소스에서 확인하는가
- 어떤 조건에서 분기하는가
- 어떤 결과물 또는 액션을 생성하는가
이 네 가지가 없으면 어떤 모델을 써도 자동화는 챗봇 데모에서 멈춘다.
2) agent trace를 제품 로그처럼 다뤄야 한다
Strands + MLflow 글이 중요한 이유는 에이전트의 실행 과정을 추적 가능한 대상으로 본다는 점이다. 챗봇 로그만 저장하는 수준으로는 부족하다. 실제 agent runtime에서는 다음 로그가 필요하다.
- 어떤 tool이 언제 호출됐는가
- 어떤 입력과 출력이 다음 단계로 전달됐는가
- 어느 단계에서 실패했는가
- 어떤 모델 variant가 더 나은 결과를 냈는가
- 사람이 어디서 개입했는가
- 배포 이후 prompt/tool 변경이 성능에 어떤 영향을 줬는가
이 기록이 없으면 에이전트는 개선 가능한 시스템이 아니라 “가끔 잘되는 마법 상자”가 된다.
3) 모델 선택은 성능표보다 운영 제약으로 결정된다
기업 환경에서는 최고 성능 모델 하나로 모든 것을 해결하기 어렵다. 어떤 워크플로는 latency가 중요하고, 어떤 워크플로는 비용이 중요하고, 어떤 워크플로는 data residency나 network isolation이 중요하다. AWS가 SageMaker endpoint와 Strands를 묶어 설명한 이유도 여기에 있다.
실무적으로는 agent workflow를 다음처럼 분해해서 봐야 한다.
- 고난도 추론 단계: 더 강한 frontier model
- 반복 분류/추출 단계: 더 작고 싼 모델
- 민감 데이터 처리 단계: 별도 endpoint 또는 내부망 배포
- 검증/요약 단계: trace와 평가 지표가 잘 남는 모델
에이전트는 하나의 모델이 아니라 여러 실행 단계를 가진 시스템이다. 따라서 비용 최적화도 “토큰 단가 비교”가 아니라 “workflow 전체의 모델 라우팅” 문제가 된다.
4) 현업 사용자를 agent orchestrator로 볼 준비가 필요하다
OpenAI Choco 사례에서 흥미로운 표현은 non-engineers가 “agent orchestrators”가 된다는 대목이다. 이는 꽤 큰 변화다. 업무를 가장 잘 아는 사람은 개발자가 아닐 수 있다. 주문, 물류, 영업, 회계, HR 담당자가 업무 조건과 예외를 더 잘 안다.
따라서 좋은 agent platform은 개발자만 쓰는 도구가 아니라, 현업 사용자가 업무 스펙을 만들고, 개발자/플랫폼 팀이 권한·연결·평가·배포를 관리하는 구조로 가야 한다.
이 점에서 Quick Flows와 Symphony는 같은 방향의 다른 표현이다. 하나는 현업 업무 플로우를 자연어로 만들고, 다른 하나는 개발 업무 티켓을 agent에게 맡긴다. 둘 다 사람의 역할을 “세션 조작자”에서 “작업 설계자/검토자”로 바꾼다.
검색 의도별로 보면 이 주제는 세 갈래다
이 글을 찾는 독자는 대체로 세 그룹일 가능성이 높다.
“Amazon Quick Flows가 뭐지?”를 찾는 현업/자동화 관심 독자
이들에게 핵심은 자연어로 workflow를 만들 수 있다는 점보다, 기존 데이터와 액션 시스템에 붙는 방식이다.“Strands Agents, SageMaker, MLflow로 agent 운영을 어떻게 하지?”를 찾는 개발자
이들에게 핵심은 모델 endpoint, tool, tracing, A/B testing, evaluation을 하나의 agent ops 패턴으로 보는 것이다.“AI agent 시장이 어디로 가고 있나?”를 보는 빌더/창업자
이들에게 핵심은 에이전트 제품의 차별화 포인트가 모델 자체보다 workflow primitive, control plane, observability, domain integration으로 이동한다는 점이다.
그래서 AWS의 이번 발표를 단순 기능 업데이트로 읽으면 놓치는 것이 많다. 이건 agent UX와 agent ops가 동시에 성숙하고 있다는 신호다.
짧은 결론: 다음 경쟁은 “누가 더 말을 잘하나”가 아니라 “누가 더 일을 끝내나”다
AI 에이전트 시장은 이제 챗봇 데모의 언어에서 벗어나고 있다. Quick Flows는 자연어를 실행 가능한 업무 플로우로 바꾸고, Strands Agents는 모델·도구·관측·평가를 운영 스택으로 묶으며, Symphony는 issue tracker를 agent control plane으로 바꾼다.
이 흐름의 실무적 결론은 단순하다.
앞으로 에이전트의 가치는 “한 번의 답변 품질”보다 업무 단위를 끝까지 실행하고, 실패를 기록하고, 비용과 품질을 비교하며, 사람이 검토 가능한 상태로 넘겨주는 능력에서 결정된다.
한국 개발팀이 지금 준비해야 할 것도 거창한 AGI 전략이 아니다. 반복 업무를 ticket/workflow 단위로 쪼개고, 데이터 연결과 권한을 정리하고, trace와 evaluation을 먼저 설계하는 것이다. 그 위에 모델을 얹어야 에이전트가 데모를 넘어 운영 시스템이 된다.
참고한 주요 출처
- AWS, Automate repetitive tasks with Amazon Quick Flows, 2026-04-27.
- AWS, Build Strands Agents with SageMaker AI models and MLflow, 2026-04-27.
- OpenAI, An open-source spec for Codex orchestration: Symphony, 2026-04-27.
- OpenAI, Choco automates food distribution with AI agents, 2026-04-27.
- Google, Join the new AI Agents Vibe Coding Course from Google and Kaggle, 2026-04-27.