Fall in IT.

[주간 IT 동향] 2026-02-27 ~ 03-02: Lambda Durable Execution, AI 에이전트 불신의 시대, Observability 자동화 본문

Artificial Intelligence

[주간 IT 동향] 2026-02-27 ~ 03-02: Lambda Durable Execution, AI 에이전트 불신의 시대, Observability 자동화

D.Y 2026. 3. 3. 09:30
반응형

TL;DR

  • AWS Lambda Durable Execution SDK for Java가 Developer Preview로 출시되면서, Step Functions 없이도 내구성 있는 멀티스텝 워크플로우를 Lambda 함수 안에서 직접 구현할 수 있게 되었다
  • AI 코딩 에이전트에 대한 불신이 구체적인 엔지니어링 패턴으로 전환되고 있다—"신뢰하지 않는 시스템"을 설계하고, 에이전트 모니터링 레이어를 구축하는 움직임이 뚜렷하다
  • CloudWatch Observability EKS Add-on이 APM을 기본 활성화하면서, Kubernetes 관측성의 진입장벽이 한 단계 낮아졌다
  • LLM 라우터, heartbeat 기반 에이전트 스케줄링, self-healing 파이프라인 등 AI 운영(AIOps)의 실전 패턴이 빠르게 정립되고 있다
  • MCP Apps가 AI 대화 인터페이스를 "텍스트 채팅"에서 "인터랙티브 운영 체제"로 확장하며, 프로토콜 레벨의 변화가 진행 중이다

1. Lambda Durable Execution: 서버리스 워크플로우의 게임 체인저

이번 주 AWS 발표 중 아키텍트에게 가장 의미 있는 것은 Lambda Durable Execution SDK for Java의 Developer Preview 출시다. 이것이 왜 중요한지 이해하려면, 지금까지 서버리스 환경에서 멀티스텝 워크플로우를 구현할 때의 고충을 떠올려보면 된다.

주문 처리 파이프라인, AI 워크플로우, human-in-the-loop 승인 프로세스 같은 것들을 Lambda로 구현하려면, 각 단계의 진행 상태를 외부 저장소에 기록하고 실패 시 복구 로직을 직접 만들거나, Step Functions 같은 외부 오케스트레이션 서비스를 붙여야 했다. 전자는 boilerplate가 끝이 없고, 후자는 ASL(Amazon States Language) 정의와 Lambda 함수 코드가 분리되면서 인지 부하가 커지는 문제가 있었다.

Durable Execution SDK는 이 두 가지 문제를 동시에 해결하려는 시도다. Lambda의 이벤트 드리븐 프로그래밍 모델 위에 내구성 있는 operation들을 얹어서, 함수 코드 안에서 직접 멀티스텝 로직을 작성하되 자동으로 진행 상태가 추적되고 실패 시 복구되는 구조다. 개발자가 커스텀 progress tracking을 구현하거나 외부 오케스트레이션을 통합할 필요가 없어진다. 이건 Azure의 Durable Functions나 Temporal이 제시했던 패턴을 AWS가 네이티브로 수용한 것으로 읽힌다. Java부터 나온 만큼 엔터프라이즈 워크로드를 먼저 공략하겠다는 의도가 명확하다. Python, TypeScript SDK가 뒤따를 것으로 보이며, 그때가 되면 서버리스 아키텍처의 판도가 크게 바뀔 수 있다.

2. AI 에이전트 불신의 엔지니어링: "믿지 않기 위한 시스템"을 만들다

지난 몇 주간 "AI 에이전트를 전면 도입했다", "읽지 않은 코드를 배포한다"는 선언이 화제였다면, 이번 주는 그 반작용이 구체적인 엔지니어링으로 드러난 주간이다. "나는 코딩 에이전트를 믿는 것을 멈추었다. 그래서 믿지 않기 위한 시스템을 만들었다(I stopped trusting my coding agents, so I built a system to not trust them)"라는 제목의 글이 핵심이다.

다수의 대형 프로젝트를 AI 에이전트와 함께 진행하면서, 여러 겹의 문서화에도 불구하고 에이전트가 계속 컨텍스트를 잃고, 변화하는 요구사항을 따라가지 못하는 경험을 한 엔지니어가 내린 결론은 명쾌하다. 에이전트를 더 똑똑하게 만들려 하지 말고, 에이전트를 불신하는 것을 전제로 한 시스템을 설계하라는 것이다. 이것은 분산 시스템 설계에서 "네트워크는 신뢰할 수 없다"는 전제와 정확히 같은 사고방식이다. 에이전트의 출력을 검증하고, 실패를 감지하고, 자동으로 복구하는 파이프라인을 만드는 것이 에이전트 자체를 개선하는 것보다 투자 대비 효과가 크다.

같은 맥락에서 OpenAlerts라는 에이전트 프레임워크용 모니터링 레이어도 등장했다. LLM 프로바이더가 401 에러를 뱉기 시작했는데 아무도 모르거나, 도구 호출이 중간에 실패해서 에이전트가 hallucination을 시작하거나, 게이트웨이가 멈췄는데 알림이 없는 상황—모두 프로덕션에서 실제로 일어나는 일들이다. 기존 APM이나 인프라 모니터링으로는 에이전트 특유의 장애 패턴을 잡기 어렵기 때문에, 에이전트 전용 모니터링이 별도의 레이어로 필요하다는 주장은 설득력이 있다.

Cron에서 Heartbeat로 전환한 사례도 같은 결을 따른다. 자율 AI 에이전트 운영을 6개월간 cron 스케줄로 돌렸더니 낭비적이고, 깨지기 쉽고, 때로는 파괴적이었다는 경험담이다. 에이전트 작업은 고정 시간이 아니라 이벤트 기반으로 트리거되어야 하며, heartbeat 패턴이 에이전트의 비결정적 특성에 훨씬 잘 맞는다는 결론이다. AI 에이전트 운영이 충분히 성숙해지면서, "어떻게 쓸까"에서 "어떻게 안정적으로 운영할까"로 논의가 이동하고 있음을 보여주는 사례들이다.

3. Observability 자동화와 비용 최적화: 운영의 새로운 기준

CloudWatch Observability EKS Add-on 5.0.0이 Application Signals(APM)를 기본 활성화로 전환했다. 이전에는 수동 opt-in이 필요했던 것이 자동 활성화로 바뀌면서, EKS에 add-on을 설치하거나 업그레이드하면 즉시 APM이 켜진다. 작은 변화처럼 보이지만 의미는 크다. Kubernetes 환경에서 관측성 설정은 항상 "나중에 하자"고 미루다가 장애 때 후회하는 영역이었는데, 기본 활성화는 이 관성을 깨트린다. opt-in에서 opt-out으로의 전환은 플랫폼 엔지니어링에서 반복적으로 효과가 증명된 패턴이다.

비용 최적화 측면에서는 NadirClaw라는 오픈소스 LLM 라우터가 흥미롭다. 간단한 프롬프트는 저렴한 모델로, 복잡한 프롬프트는 프리미엄 모델로 자동 라우팅해서 AI API 비용을 40~70% 절감한다는 컨셉이다. 코드 변경 없이 프록시처럼 동작하는 것이 핵심인데, 지난주 위시켓이 "AI 비용의 10배를 수익으로 만든다"고 선언한 맥락에서 보면, AI 비용 최적화가 더 이상 선택이 아닌 필수가 되었음을 보여준다. 자체 AI 플랫폼을 AWS 위에 직접 구축한 사례—Lambda 함수 수십 개에 걸쳐 월 $5,000 이상의 AI 추론 비용이 발생하면서 자체 플랫폼으로 전환한 이야기—도 같은 맥락이다.

MCP Apps가 AI 대화 인터페이스를 인터랙티브 UI로 확장한다는 분석도 주목할 만하다. 지금까지 AI 어시스턴트의 출력은 결국 텍스트였고, 그걸 Excel, Jira, Figma에 수동으로 옮기는 "컨텍스트 스위칭 비용"이 발생했다. MCP Apps는 AI 대화 안에서 직접 인터랙티브 UI 컴포넌트를 렌더링하는 프로토콜 레벨의 변화인데, 이게 본격화되면 AI 도구의 UX 패러다임이 근본적으로 바뀔 수 있다.


이번 주 주목할 기술 동향

  • AWS Config, 30개 신규 리소스 타입 지원: Amazon Bedrock AgentCore, Amazon Cognito 등이 포함되면서 에이전트 기반 인프라의 감사·추적 커버리지가 확대되었다.
  • Amazon ECS Managed Instances, EC2 Capacity Reservations 통합: 예약 용량과 ECS 관리형 인프라를 결합해 미션 크리티컬 워크로드의 가용성을 높일 수 있다.
  • MoltSocial 오픈소스 공개: 인간과 AI 에이전트가 공유 피드에서 공존하는 소셜 플랫폼. Agent API 설계와 셀프 호스팅 가이드가 포함되어 있어, 에이전트 소셜 인터랙션의 실험장으로 참고할 만하다.
  • n8n + Gemini AI 기반 Self-Healing 웹 스크래핑 파이프라인: 33개 이상 사이트의 HTML 구조 변경을 AI가 자동 감지·대응하는 아키텍처. self-healing 패턴의 실전 적용 사례다.

참고 자료

  1. AWS Lambda Durable Execution SDK for Java now available in Developer Preview — AWS Blog
  2. I stopped trusting my coding agents, so I built a system to not trust themdev.to
  3. OpenAlerts - Monitoring layer for Agentic frameworksdev.to
  4. Why I Switched from Crons to Heartbeats for My Autonomous AI Agent Operationsdev.to
  5. Application Performance Monitoring Enabled by Default in CloudWatch Observability EKS Add-on — AWS Blog
  6. NadirClaw: Getting Started in 5 Minutesdev.to
  7. Why I Built My Own AI Platform on AWS (and Why You Might Too)dev.to
  8. MCP协议2026深度解析:MCP Apps如何让AI对话中嵌入交互式UIdev.to
  9. AWS Config now supports 30 new resource types — AWS Blog
  10. Amazon ECS Managed Instances now integrates with Amazon EC2 Capacity Reservations — AWS Blog
  11. Building a Social Platform Where Humans and AI Agents Coexistdev.to
  12. Building a Self-Healing Web Scraping Pipeline with n8n and Gemini AIdev.to
반응형
Comments