왜 Microsoft는 기존 이벤트 중심의 서버리스를 넘어 ‘에이전트 기반 서버리스’라는 새로운 패러다임을 제시했을까요? 2026년 6월, 혁신적인 런타임이 우리에게 던지는 큰 질문입니다. 핵심은 단순합니다. 이제 Serverless는 “함수 몇 개를 이벤트에 붙이는 방식”만으로는 AI·실시간·복합 워크플로를 감당하기 어려워졌고, Microsoft는 그 해법으로 Azure Functions Serverless Agents Runtime(퍼블릭 프리뷰)을 꺼내 들었습니다.
Serverless 관점에서 무엇이 달라졌나: FaaS에서 ‘에이전트 런타임’으로
기존 Azure Functions를 포함한 전통적 Serverless/FaaS는 보통 다음 전제를 갖습니다.
- 트리거(이벤트) 가 오면
- 짧게 실행되는 함수 가 처리하고
- 상태는 외부 저장소(DB/캐시/큐 등)에 둔다
반면 Microsoft가 Build 2026에서 공개한 Azure Functions Serverless Agents Runtime은 Azure Functions를 “에이전트 중심 플랫폼”으로 확장하려는 시도입니다. 의미는 “함수 호출”이 애플리케이션의 중심이 아니라, 목표를 가진 에이전트가 여러 이벤트와 리소스를 관찰·판단·행동하며 작업을 완수하는 형태까지 Serverless가 포괄하겠다는 선언에 가깝습니다.
즉, 설계 질문이 이렇게 바뀝니다.
- 이전: “이 이벤트가 오면 어떤 함수를 실행하지?”
- 이후: “이 목표를 담당할 에이전트는 무엇이고, 어떤 이벤트·도구·데이터를 엮어 어떻게 의사결정하지?”
Serverless가 에이전트를 필요로 하게 된 배경: AI·IoT·실시간의 압력
2026년의 Serverless는 더 이상 “백엔드 유틸리티”에 머물지 않습니다. 실시간 AI 애플리케이션, IoT 이벤트 처리, 다단계 자동화처럼 연속적인 맥락과 다수의 작업 조합이 필요한 워크로드가 폭증했고, Microsoft 역시 2026년 5월 Azure에서 실시간 AI·IoT 처리를 위한 이벤트 기반 서버리스 역량 강화 흐름을 함께 보여줬습니다.
여기서 문제가 생깁니다.
- 이벤트는 많아지고(스트림/센서/사용자 상호작용)
- 작업은 길어지고(분석 → 판단 → 실행 → 검증)
- 호출 체인은 복잡해지고(툴 호출, 데이터 조회, 후속 작업 분기)
- 그런데도 운영은 Serverless처럼 자동 확장·탄력 과금을 유지하고 싶다
결국 “짧은 함수들의 조합”만으로는 표현력과 운영 모델 모두에서 한계가 오고, 이를 애플리케이션 레벨의 추상화(에이전트)로 끌어올릴 필요가 생긴 겁니다.
Serverless Agents Runtime의 기술적 함의: ‘이벤트 기반 + 에이전트’의 결합
공개된 정보가 제한적이더라도, Azure Functions의 본질(이벤트 기반 컴퓨트)과 업계 흐름을 놓고 보면 다음 구조를 예상할 수 있습니다.
- 이벤트 기반 실행 모델은 유지: 여전히 이벤트가 기폭제가 된다
- 그 위에 에이전트 레이어를 추가: 단일 이벤트 처리로 끝나지 않고, 에이전트가 목표 달성을 위해
- 여러 이벤트를 연속적으로 다루고
- 필요한 도구/서비스를 호출하며
- 작업을 오케스트레이션한다
이 조합이 중요한 이유는, AI 에이전트가 실제로 필요한 것이 “모델 호출 1회”가 아니라 상황 인지 → 계획 수립 → 툴 실행 → 결과 검증 → 다음 액션으로 이어지는 루프이기 때문입니다. 그리고 그 루프를 Serverless의 자동 확장/과금 모델 안에서 안정적으로 운영하려면, 에이전트를 1급 객체로 다루는 런타임이 훨씬 자연스럽습니다.
Serverless 설계 방식의 변화: ‘함수 분할’에서 ‘에이전트 경계’로
이 전환이 실무에 던지는 메시지는 명확합니다.
- 기능을 “함수 단위로 쪼개는” 최적화만으로는 부족해지고,
- 앞으로는 “에이전트의 책임 범위를 어떻게 나누고(경계), 어떤 상태를 어디에 두며(기억), 어떻게 관찰 가능하게 만들지(트레이싱/로그 상관관계)”가 설계의 중심이 됩니다.
정리하면, Azure Functions Serverless Agents Runtime은 Serverless의 중심축을 ‘이벤트 처리 함수’에서 ‘목표 지향 에이전트’로 옮기려는 시도입니다. 2026년의 Serverless가 AI·실시간 시스템의 핵심 런타임으로 진화하는 과정에서, 이 변화는 단순한 기능 업데이트가 아니라 아키텍처 사고방식 자체를 바꾸는 전환점이 될 가능성이 큽니다.
Serverless 컴퓨팅, 짧은 함수에서 복잡한 에이전트로 진화하다
단순한 Function 호출을 넘어서, AI와 IoT가 결합된 복잡한 워크플로도 서버리스로 관리하는 시대가 열리고 있습니다. 이제 “이벤트가 오면 함수 하나 실행”이라는 공식은 여전히 유효하지만, 현실의 시스템은 그보다 훨씬 복잡해졌습니다. 실시간 스트리밍 데이터, 수천 개 동시 세션의 AI 에이전트, 다단계 승인·검증·후처리 파이프라인까지—이 모든 것을 Serverless 방식으로 다루려는 요구가 폭발적으로 커지고 있습니다.
Serverless의 중심이 “함수 실행”에서 “애플리케이션 운영”으로 이동
전통적 FaaS(Function-as-a-Service)는 강력했지만 전제가 명확했습니다.
- 트리거(HTTP, 큐, 이벤트 등)가 들어오면
- 짧고 결정적인 작업을 수행하고
- 빠르게 종료한다
문제는 현대 애플리케이션이 “짧고 단발성”으로 끝나지 않는다는 점입니다. AI가 도구를 호출하고(검색, DB, 외부 API), 결과를 종합해 다음 행동을 결정하는 루프가 생겼고, IoT는 다수 장치 이벤트를 지속적으로 관찰·상관분석해야 합니다. 결국 서버리스는 단순 실행 모델을 넘어 복잡한 비즈니스 로직과 데이터 흐름을 ‘서버 없이’ 운영하는 방식으로 확장되는 중입니다.
Serverless 에이전트 런타임이 등장한 이유: AI·IoT의 “지속성”과 “오케스트레이션”
최근 흐름을 보면, 서버리스의 진화 방향은 크게 두 갈래 요구를 동시에 만족해야 합니다.
1) 실시간 이벤트를 대규모로 처리하는 능력
- IoT 텔레메트리, 로그/메트릭, 사용자 행동 이벤트처럼 입력이 끊이지 않습니다.
- 이벤트는 단발성 처리가 아니라, 여러 신호를 엮어 “상황”을 이해해야 의미가 생깁니다.
2) AI 에이전트가 만드는 긴 실행 체인
- LLM 기반 에이전트는 한 번의 호출로 끝나지 않고, 도구 호출 → 검증 → 재시도 → 후속 작업 같은 체인을 만듭니다.
- 이 과정은 사실상 “작은 워크플로 엔진”이 애플리케이션 내부에 들어오는 형태에 가깝습니다.
이런 배경에서 Microsoft가 Build 2026에서 공개한 Azure Functions Serverless Agents Runtime(퍼블릭 프리뷰)은 상징적입니다. 기존 Azure Functions를 단순 FaaS가 아니라, 에이전트 중심 애플리케이션을 위한 Serverless 플랫폼으로 확장하려는 시도로 해석할 수 있습니다. 핵심은 “함수 몇 개를 어떻게 쪼갤까?”보다 “어떤 목표를 가진 에이전트가 이벤트와 도구를 조합해 어떻게 행동할까?”로 설계의 중심이 이동한다는 점입니다.
Serverless 업계 동향: 데이터·분석·실행 환경까지 전방위 서버리스화
이 변화는 Azure만의 단독 움직임이라기보다, 업계 전체가 “스택 전반의 서버리스화”로 가속 중이라는 신호와 맞물립니다.
- AWS는 OpenSearch를 서버리스 모델로 제공하며 검색·로그 분석 워크로드까지 완전 관리형 형태로 넓히고 있습니다.
- Databricks는 노트북·잡 실행을 위한 serverless compute를 강화하며, 데이터/AI 워크로드의 운영 부담을 줄이는 방향으로 진화 중입니다.
- EMR Serverless Spark처럼 빅데이터 처리 엔진도 “클러스터 운영”보다 “필요할 때만 실행”에 초점을 맞추고 있습니다.
즉, 이제 Serverless는 “웹훅 처리 같은 자잘한 백엔드 자동화”에 머무르지 않고, 검색·분석·AI·데이터 파이프라인까지 포괄하는 실행 모델이 되어가고 있습니다. 이런 환경에서는 애플리케이션이 자연스럽게 더 복잡한 오케스트레이션을 요구하고, 그 결과 “에이전트”가 런타임의 1급 구성요소로 올라오는 흐름이 만들어집니다.
기술적으로 무엇이 달라지나: 이벤트 기반 위에 “에이전트 레이어”를 올리는 설계
에이전트 기반 Serverless를 이해하는 좋은 방법은, 기존 이벤트 기반 모델 위에 판단·기억·행동을 묶은 논리적 개체(Agent)가 추가되는 것으로 보는 것입니다.
- 이벤트 수집: IoT 신호, 사용자 요청, 메시지 큐, 변경 데이터 캡처 등 다양한 입력을 받음
- 컨텍스트/상태 관리: 대화 기록, 작업 진행 상태, 정책, 벡터 검색 결과 등 “논리적 상태”를 활용
- 도구 호출과 오케스트레이션: DB·검색·외부 API·다른 함수 호출을 조합해 목표를 달성
- 관찰 가능성 강화 필요: 호출 체인이 길어져 트레이싱·로그 상관관계·재현(replay)이 중요해짐
결국 설계 질문이 바뀝니다.
- 과거: “이 이벤트는 어떤 함수로 처리하지?”
- 현재: “이 목표(예: 이상 징후 탐지, 고객 응대 자동화, 주문 예외 처리)를 담당하는 에이전트가 어떤 이벤트를 관찰하고, 어떤 도구를 어떤 순서로 호출해야 하지?”
이 관점 전환이 바로, 서버리스 컴퓨팅이 “짧은 함수 실행”에서 “복잡한 에이전트 기반 애플리케이션 운영”으로 진화하고 있음을 보여줍니다.
Serverless 전통적 FaaS와 에이전트 기반 서버리스의 결정적 차이점
‘함수 하나 실행’이 전부였던 서버리스가 ‘목표 지향적 에이전트’가 되어 작동한다면 어떤 차이가 있을까요? 단순히 “더 똑똑해진 Functions” 정도가 아니라, Serverless 아키텍처의 설계 단위 자체가 바뀌는 변화가 시작됩니다. 핵심은 함수 호출 중심에서 목표 달성 중심으로 무게중심이 이동한다는 점입니다.
Serverless 실행 단위: “함수 호출”에서 “에이전트”로
전통적 FaaS(Function-as-a-Service)의 실행 모델은 명확합니다.
- 트리거(HTTP, 큐, 이벤트 등)가 발생하면
- 함수 1개가 짧게 실행되고
- 끝나면 종료됩니다.
반면 에이전트 기반 서버리스는 논리적 실행 단위가 “함수”가 아니라 에이전트(Agent)입니다. 에이전트는 보통 다음을 전제로 설계됩니다.
- 목표(Goal): 예) “고객 문의를 해결하라”, “장애 조짐을 탐지하고 조치하라”
- 관찰(Observe): 이벤트/로그/메시지를 지속적으로 해석
- 판단(Reason/Plan): 다음 행동을 선택(워크플로 분기 포함)
- 행동(Act): 여러 도구/서비스 호출을 조합해 목표에 접근
즉, 같은 Serverless라도 “요청 1번 → 함수 1번”이 아니라, 목표 1개 → 다단계 실행(함수/도구 호출의 연쇄)가 자연스러운 기본 패턴이 됩니다.
Serverless 상태 모델: “무상태(stateless)”에서 “논리적 상태”로
FaaS는 원칙적으로 무상태입니다. 상태가 필요하면 DB, 캐시, 큐 같은 외부 저장소에 위임하죠. 문제는 AI·업무 자동화·운영 대응 같은 현실의 작업이 대부분 “맥락”을 필요로 한다는 점입니다.
에이전트 기반 서버리스가 다루는 상태는 보통 다음 성격을 가집니다.
- 대화/작업 맥락(Context): 사용자 요구, 이전 결정, 진행 단계
- 작업 메모리(Working Memory): 지금까지 수집한 정보와 중간 결과
- 장기 기억(Long-term Memory): 정책, 매뉴얼, 과거 이력(종종 벡터 스토어 포함)
중요한 차이는, 에이전트 서버리스에서 상태는 “있으면 좋은 것”이 아니라 행동의 품질을 좌우하는 핵심 설계 요소라는 점입니다. 따라서 스토리지 선택(키-값/문서DB/큐/벡터DB)과 TTL, 동시성 제어, 재시도 시 상태 일관성 같은 주제가 아키텍처의 중심으로 올라옵니다.
Serverless 오케스트레이션: 워크플로 엔진 “외부 호출”에서 “내장형 의사결정”으로
전통적 Serverless에서 복잡한 프로세스는 보통 이렇게 구성됩니다.
- 워크플로 엔진(예: Step Functions/Logic Apps 등)이 흐름을 관리
- 각 단계에서 FaaS를 호출해 작업을 수행
에이전트 기반 서버리스는 이 경계를 흔듭니다. 에이전트가 다음을 자체적으로 수행하기 때문입니다.
- 이벤트에 따라 단계를 재배열하거나 우회
- 실패 원인에 따라 재시도 전략 변경
- 상황에 따라 추가 데이터 수집 후 재판단
- 도구 호출을 동적으로 선택(API, 검색, DB 질의, 티켓 발행 등)
결과적으로 “정적인 DAG(고정된 단계)”보다, 상황 적응형 실행 모델에 가까워집니다. 이때 관건은 에이전트의 자율성이 커진 만큼, 실행 경로가 다양해져 추적(Tracing)과 재현(Reproducibility)이 더 어려워진다는 점입니다.
Serverless 관찰 가능성(Observability): “함수 로그”에서 “에이전트 추론/행동 추적”으로
FaaS에서는 대개 다음만으로도 운영이 가능했습니다.
- 함수별 로그
- 호출 횟수/에러율/지연 시간
- 트리거 단위의 메트릭
하지만 에이전트 기반 서버리스는 “왜 이런 결정을 했는가?”가 중요합니다. 따라서 관찰 가능성도 한 단계 확장됩니다.
- 상관관계 ID로 에이전트 실행 전체를 연결(여러 함수/도구 호출 체인)
- 어떤 이벤트를 근거로 어떤 판단을 거쳐 어떤 도구를 호출했는지 결정 로그/추론 로그
- 재시도/타임아웃/보상 트랜잭션이 얽힌 흐름에서 리플레이(재실행) 가능성
즉, Serverless 운영의 단위가 “함수 1개”에서 “에이전트 1개(그리고 그 여정 전체)”로 바뀌면서, 관측 데이터의 스키마와 수집 전략도 달라져야 합니다.
Serverless 비용과 성능: “짧은 실행 최적화”에서 “불필요한 깨어 있음 최소화”로
FaaS 최적화는 주로 다음에 집중합니다.
- cold start 줄이기
- 실행 시간 단축
- 호출 수에 따른 비용 관리
에이전트 기반 서버리스에서는 비용/성능 포인트가 추가됩니다.
- 에이전트가 불필요하게 오래 유지되는 시간(유휴 대기, 과도한 폴링)을 줄이는 구조
- 장기 작업을 이벤트/큐 기반으로 쪼개고, 상태를 외부화해 필요할 때만 깨어나게 하는 패턴
- 도구 호출(LLM 추론, 검색, DB, 외부 API) 비용까지 포함한 총 실행 비용(TCO) 모델링
결국 “컴퓨트 비용”만 보던 Serverless 관점에서, 에이전트가 호출하는 도구 생태계 전체 비용으로 시야가 넓어집니다.
정리하면, 전통적 FaaS는 Serverless를 “이벤트에 반응하는 실행 환경”으로 만들었다면, 에이전트 기반 서버리스는 Serverless를 목표를 달성하는 실행 주체(Agent)를 운영하는 플랫폼으로 확장합니다. 이 차이를 이해하면, 앞으로 서버리스 설계에서 무엇을 우선순위로 바꿔야 하는지(상태, 관찰 가능성, 비용 모델, 보안 경계)가 선명해집니다.
Serverless 기술적 해부: Azure Serverless Agents Runtime이 의미하는 혁신적 설계
단순 함수 호출에 ‘에이전트’ 개념을 더하는 이 런타임, AI와 실시간 이벤트를 어떻게 오케스트레이션할까요? 핵심은 이벤트 기반 FaaS의 장점(확장·격리·과금 모델)을 유지하면서, 그 위에 “목표 지향적 실행 단위(Agent)”를 1급 시민으로 올려 애플리케이션 설계의 중심을 함수에서 에이전트로 이동시킨다는 점입니다.
Serverless 관점에서의 구조 변화: “함수 호출”에서 “에이전트 실행”으로
기존 Azure Functions는 “트리거 → 함수 실행”의 직선 구조가 기본이었습니다. 반면 Serverless Agents Runtime이 지향하는 모델은 다음과 같이 바뀝니다.
- 핵심 추상화가 함수(Function)가 아니라 에이전트(Agent)
에이전트는 단일 이벤트에 반응하는 조각 코드가 아니라, 여러 이벤트를 관찰하고 판단해 연속적인 행동을 수행하는 논리적 주체입니다. - 실행의 초점이 ‘처리’가 아니라 ‘목표 달성’
“이 이벤트가 오면 이 함수”가 아니라, “이 목표를 가진 에이전트가 들어오는 이벤트와 도구를 이용해 다음 행동을 결정”하는 패턴이 됩니다. - Serverless의 장점은 그대로, 조립 방식만 바뀜
자동 확장, 이벤트 기반, 관리 부담 감소 같은 Serverless 특성은 유지하되, 애플리케이션을 쪼개는 단위가 함수 중심에서 에이전트 중심으로 재편됩니다.
이 변화는 단순히 개발 편의성 개선이 아니라, AI·IoT·실시간 시스템에서 요구하는 ‘연속적 의사결정’을 Serverless 런타임 내부로 끌어들이는 설계적 전환입니다.
Serverless 이벤트 모델 + 에이전트 레이어: “관찰 → 판단 → 행동”의 반복 루프
에이전트 기반 설계의 기술적 본질은, 이벤트 기반 시스템 위에 제어 루프(control loop)를 얹는 것입니다.
- 관찰(Observe): 이벤트 스트림(HTTP, 큐, IoT 텔레메트리, DB 변경 등)을 수신
- 판단(Decide): 현재 컨텍스트(상태/기억)와 정책에 따라 다음 액션 결정
- 행동(Act): 함수 실행, 툴 호출(API), 워크플로 단계 진행, 알림/명령 발행 등 수행
- 그리고 다시 새로운 이벤트를 관찰하며 루프 반복
이 구조가 중요한 이유는, 실시간 시스템에서 “하나의 이벤트 처리”는 대부분 더 큰 작업의 일부이기 때문입니다. 예를 들어 IoT 이상 탐지나 고객 응대 AI는 단발성 호출이 아니라, 여러 신호를 종합해 단계적으로 결론에 도달합니다. Serverless Agents Runtime은 이 반복 구조를 애플리케이션 코드가 아니라 런타임 설계 레벨에서 자연스럽게 만들려는 시도로 읽힙니다.
Serverless에서 가장 어려운 지점: 에이전트의 “상태(기억)”를 어떻게 다루나
전통적인 Serverless는 stateless를 기본 전제로 했습니다. 그러나 에이전트는 본질적으로 컨텍스트(대화 이력, 작업 진행도, 정책, 도구 사용 결과)가 중요합니다. 따라서 “에이전트 기반 Serverless”는 상태를 다음처럼 재정의합니다.
- 인프라 상태(stateful infrastructure)가 아니라 논리 상태(logical state)
런타임이 긴 프로세스를 고정 유지하는 방식이 아니라, 필요할 때마다 실행을 재개할 수 있도록 외부 저장소에 상태를 위임하는 형태가 유력합니다. - 상태 저장소의 역할 분화
- 작업 진행/체크포인트: DB 또는 durable storage
- 단기 컨텍스트: 캐시/세션 스토어
- 의미 기반 기억: 벡터 스토어(검색/회상)
- 이벤트 동기화: 메시지 큐/스트림
결국 설계 포인트는 “에이전트가 오래 살아있다”가 아니라, 에이전트가 오래 ‘일관되게’ 존재하는 것처럼 동작하도록 상태를 분리·복원하는 데 있습니다. 이때 Serverless 특유의 스케일링과 장애 복원성이 오히려 강점이 됩니다(언제든 다른 실행 인스턴스에서 재개 가능).
Serverless에서 AI 오케스트레이션이 쉬워지는 이유: “툴 호출”과 “워크플로”의 내장화
AI 에이전트가 복잡해지는 지점은 모델 호출 그 자체가 아니라, 모델이 외부 도구를 호출하고 결과를 반영해 다음 행동을 정하는 과정입니다. 즉, AI는 자연스럽게 오케스트레이션을 필요로 합니다.
Serverless Agents Runtime이 의미 있는 이유는 다음 두 축을 한데 묶기 때문입니다.
- 이벤트 기반 처리(현실 세계의 신호): 실시간 요청, 센서 데이터, 메시지, 변경 이벤트
- 툴 기반 실행(행동 수행): 데이터 조회, 티켓 발행, 결제/환불, 자동화 작업, 알림 전파
이 조합이 성숙하면, 기존에는 별도 제품(워크플로 엔진)과 FaaS를 함께 엮어야 했던 구성이 “에이전트 = 실행 단위이자 미니 오케스트레이터”로 수렴할 가능성이 생깁니다. 결과적으로 아키텍처는 더 단순해지되, 런타임은 더 지능적인 실행 모델을 제공해야 합니다.
Serverless 운영 관점의 핵심: 관찰 가능성과 비용 제어가 아키텍처를 결정한다
에이전트 기반으로 가면 호출 체인이 길어지고, 이벤트·도구·모델 호출이 얽히면서 운영 난도가 급격히 올라갑니다. 따라서 기술 혁신의 실제 가치는 “새로운 실행 모델”뿐 아니라, 이를 운영 가능하게 만드는 메커니즘에서 갈립니다.
- 관찰 가능성(Observability)
에이전트 단위의 트레이싱(한 목표 달성까지의 전체 흐름), 로그 상관관계, 재현/리플레이가 중요해집니다. 함수 단위 모니터링으로는 “왜 이런 결정을 했는지”를 추적하기 어렵습니다. - 비용 모델 최적화
Serverless는 사용량 기반 과금이 강점이지만, 에이전트는 설계에 따라 “불필요한 각성 시간”이 생길 수 있습니다.
따라서 이벤트 처리 빈도, 상태 저장 주기, 모델 호출 횟수, 도구 호출 비용을 아키텍처 단계에서 제어해야 합니다. - 보안과 권한 위임
에이전트는 여러 리소스에 접근하므로 최소 권한 원칙, 비밀 관리, 감사 로그가 설계의 중심이 됩니다. “함수 하나의 권한”이 아니라 “에이전트가 수행할 수 있는 행동의 범위”를 정의해야 합니다.
Serverless 설계 결론: “함수의 집합”이 아니라 “에이전트의 생태계”로 설계하라
Azure Functions Serverless Agents Runtime이 던지는 메시지는 명확합니다. 앞으로의 Serverless는 단순 백엔드 유틸리티가 아니라, AI·실시간 이벤트·워크플로를 한 런타임에서 조립하는 애플리케이션 플랫폼으로 진화한다는 것.
따라서 설계의 질문도 바뀝니다.
- “어떤 함수를 만들까?”가 아니라
- “어떤 목표를 가진 에이전트를 만들고, 어떤 이벤트를 관찰하며, 어떤 도구로 행동하게 할까?”
이 전환을 먼저 이해하는 팀이, 다음 세대의 Serverless 아키텍처 경쟁에서 가장 빠르게 앞서갈 가능성이 큽니다.
Serverless 실무자는 어떻게 대비해야 할까? 에이전트 서버리스 도입 점검 리스트
기존 Serverless가 “이벤트 → 함수 1회 실행”에 최적화되어 있었다면, 에이전트 기반 Serverless는 “목표를 가진 실행 주체(Agent)가 여러 이벤트·도구·데이터를 엮어 일을 끝내는 방식”으로 중심축이 이동합니다. 이 전환은 생산성을 크게 올릴 수 있지만, 아키텍처 설계·비용·보안·운영 관점의 실패 포인트도 함께 늘어납니다. 아래 체크리스트로 도입 리스크를 선제적으로 줄이세요.
Serverless 아키텍처 설계: “함수 분할”에서 “에이전트 경계”로
에이전트의 책임 범위를 먼저 자르기
- “고객 문의 처리 에이전트”, “주문 이상 탐지 에이전트”처럼 업무 목표 중심으로 정의합니다.
- 한 에이전트가 너무 많은 도메인을 맡으면, 도구 호출과 상태가 엉키며 장애 시 영향 범위가 커집니다.
이벤트 모델을 ‘트리거’가 아니라 ‘신호(signal)’로 재정의
- 과거:
Queue 메시지 1건 → 함수 실행 → 종료 - 전환 후:
여러 신호(이벤트/상태 변화/타임아웃) → 에이전트가 판단 → 다음 행동 선택 - 따라서 이벤트 스키마는 단순 페이로드가 아니라, 상관관계(correlation id), 원인(cause), 재시도 힌트, 우선순위 같은 메타데이터를 포함해야 합니다.
- 과거:
오케스트레이션 위치를 명확히
- 기존에는 워크플로 엔진이 오케스트레이션을 맡고 FaaS는 “작업자(worker)” 역할이었습니다.
- 에이전트 기반 Serverless에서는 에이전트가 오케스트레이션을 일부 흡수합니다.
- 체크 포인트:
- “장기 실행·분기·보상 트랜잭션”이 많다면 워크플로 엔진 유지가 유리할 수 있음
- “판단/계획/도구 호출” 비중이 크면 에이전트 중심이 더 자연스러움
