AWS가 클라우드 아키텍트까지 Agent로 만들었다

Well-Architected Agent — 실제 AWS 환경을 읽고 비용·보안·성능·복원력까지 계속 점검한다

AWS를 오래 운영하다 보면 한 번쯤 Well-Architected Review를 하게 됩니다.

문제는 제대로 하려면 생각보다 일이 많다는 겁니다.

EC2는 적절한 크기인가?

RDS는 장애에 대비되어 있는가?

Multi-AZ가 필요한가?

보안 설정은 괜찮은가?

사용하지 않는 리소스는 없는가?

비용은 어디서 새고 있는가?

이 구조가 앞으로 트래픽을 버틸 수 있는가?

AWS에는 이미 Trusted Advisor와 Well-Architected Tool이 있었지만, 결국 많은 부분을 사람이 살펴보고 판단해야 했습니다.

2026년 10월 1일 AWS가 이 일을 직접 맡는 AWS Well-Architected Agent를 Public Preview로 공개했습니다.

단순히 AWS 문서를 찾아주는 챗봇이 아닙니다.

실제 AWS 환경의 리소스 구성과 사용량, 애플리케이션 관계를 분석하고 회사가 중요하게 생각하는 목표까지 반영해서 개선할 부분을 찾아냅니다. 현재 65개가 넘는 AWS 서비스를 대상으로 분석합니다. :chatgpt-content-reference{index="0"}

---

1. 기존 Well-Architected Review는 왜 귀찮았을까

AWS Well-Architected Framework 자체는 좋은 기준입니다.

Architecture를 크게 보면 보통 이런 항목을 계속 확인해야 합니다.

Cost Optimization

Security

Reliability / Resilience

Performance

문제는 실제 시스템이 커질수록 리소스 하나만 봐서는 판단하기 어렵다는 겁니다.

예를 들어 RDS 하나를 봤다고 해보겠습니다.

RDS
 ↓
Instance Size
 ↓
CPU
 ↓
Memory

정도만 보면 단순합니다.

하지만 실제 Architecture에서는:

ALB
 ↓
ECS
 ↓
API
 ↓
RDS
 ↓
ElastiCache

+

CloudWatch

+

Auto Scaling

+

Multi-AZ

+

Backup

가 같이 움직입니다.

비용 하나를 줄이면 성능이나 복원력이 떨어질 수도 있습니다.

---

2. Well-Architected Agent는 리소스 하나만 보지 않는다

이번 Agent에서 가장 중요한 부분입니다.

AWS는 다음 정보를 같이 봅니다.

Resource Configuration

Utilization Metrics

Application Topology

Business Goals

예를 들어:

EC2 사용률이 낮다.

만 보고:

Instance를 줄이세요.

라고 끝내는 게 아닙니다.

이 EC2가:

어떤 Application에 속하는지

다른 Resource와 어떻게 연결되어 있는지

얼마나 중요한 서비스인지

회사가 지금 무엇을 우선하는지

까지 같이 판단합니다.

---

3. 회사가 무엇을 중요하게 생각하는지도 알려줄 수 있다

Agent Profile을 만들 때 Business Goal을 지정합니다.

예를 들어 회사 상황이:

올해는 비용 절감이 최우선

이라면:

Cost Optimization

에 더 높은 우선순위를 줄 수 있습니다.

반대로 금융서비스라면:

Security

Resilience

가 더 중요할 수 있습니다.

---

4. 같은 AWS 환경이라도 답이 달라질 수 있다

예를 들어 이런 Database가 있다고 해보겠습니다.

RDS
Single-AZ

비용만 보면:

Single-AZ 유지

가 유리합니다.

하지만 서비스 목표가:

Mission Critical

장애 최소화

라면 Agent는:

Multi-AZ

전환을 더 중요한 Recommendation으로 올릴 수 있습니다.

즉:

AWS Best Practice
+
현재 Resource
+
실제 사용량
+
Application 중요도
+
Business Goal

을 함께 봅니다.

---

5. Recommendation도 세 단계로 나뉜다

이번 기능에서 꽤 잘 만든 부분입니다.

Well-Architected Agent는 Recommendation을 세 단계로 나눕니다.

Resource

EC2

Lambda

RDS

같은 개별 Resource 문제입니다.

예를 들어:

이 EC2 Instance가 과하게 크다.

같은 내용입니다.

---

Application

여러 Resource의 관계를 같이 봅니다.

API
 ↓
Lambda
 ↓
RDS
 ↓
S3

하나씩은 문제가 없어도 조합했을 때 생기는 Architecture 문제를 찾는 겁니다.

---

Architecture

가장 범위가 큽니다.

전체 구조

IaC

Architecture Pattern

을 대상으로 합니다.

즉:

Resource
    ↓
Application
    ↓
Architecture

순서로 시야가 넓어집니다.

---

6. 단순 체크리스트와 가장 다른 부분도 여기다

기존 방식은 이런 식이기 쉽습니다.

Multi-AZ 사용?

YES / NO

Encryption 사용?

YES / NO

Auto Scaling 사용?

YES / NO

체크리스트에는 Context가 없습니다.

Well-Architected Agent는:

왜 이 Resource가 존재하는가?

어떤 Application인가?

얼마나 중요한가?

회사가 무엇을 우선하는가?

를 같이 봅니다.

그래서 같은 설정이라도 상황에 따라 우선순위가 달라집니다.

---

7. Impact와 Effort까지 같이 본다

Recommendation은 단순히:

좋음

나쁨

으로 끝나지 않습니다.

AWS에서는 Recommendation을:

Impact

High
Medium
Low

와

Effort

Small
Medium
Large

같은 기준으로 볼 수 있습니다.

그래서:

효과는 큰데
수정은 쉬운 것

부터 처리할 수 있습니다.

---

8. 이게 실제 운영에서는 상당히 중요하다

클라우드 최적화 목록이 100개 생겼다고 해보겠습니다.

이걸 그냥:

1번부터 차례대로 수정

할 수는 없습니다.

실제 팀에서는:

Impact 높음
+
Effort 낮음

을 먼저 처리하고 싶습니다.

그리고:

Impact 낮음
+
Effort 높음

은 뒤로 미룹니다.

Well-Architected Agent가 Business Goal을 같이 보는 이유도 여기 있습니다.

---

9. 단순히 문제만 알려주는 것도 아니다

기존 Cloud 분석 도구는 이런 식으로 끝나는 경우가 많습니다.

이 Resource에 문제가 있습니다.

개발자는 다시 문서를 찾아야 합니다.

어떻게 고치지?

CLI 명령은?

CloudFormation은?

Terraform은?

Production에 적용해도 되나?

이번 Agent는 이 다음 단계까지 들어갑니다.

---

10. 수정 방법까지 준비한다

Recommendation에 따라:

Console Walkthrough

AWS CLI

SSM Runbook

IaC 수정안

등 실제 적용에 가까운 내용을 제공합니다.

예를 들어:

RDS에 Multi-AZ Failover가 필요

하다고 판단했다면 단순 경고 대신 실제 변경 절차까지 같이 보여줄 수 있습니다.

---

11. 그런데 Agent가 Production을 마음대로 수정하는 건 아니다

여기서 중요한 부분입니다.

Well-Architected Agent가 AWS 환경을 분석한다고 해서:

Agent
 ↓
문제 발견
 ↓
Production 자동 변경

구조는 아닙니다.

AWS WA Agent가 환경을 분석할 때 사용하는 Resource 접근 권한은 기본적으로 Read-only입니다.

AWS 문서도 Agent가 Resource를 생성하거나 수정하거나 삭제할 권한은 없다고 명확하게 설명합니다. :chatgpt-content-reference{index="1"}

---

12. Data 자체를 들여다보는 것도 아니다

예를 들어:

S3 Object 내용

RDS Record

Database 내부 고객 데이터

를 읽어서 분석하는 구조가 아닙니다.

주로:

Resource Metadata

Configuration

Telemetry

Usage Pattern

을 분석합니다.

즉:

Database 안의 주문 데이터

를 보는 것이 아니라,

Database 설정과 사용 상태

를 보는 쪽입니다.

---

13. AI가 만든 수정안은 사람이 검토한다

이 부분도 꽤 중요합니다.

AI가 생성한:

CLI Script

IaC 변경

Guided Action

은 검토 없이 Production에 바로 실행되는 게 아닙니다.

기본 흐름은:

Agent 분석
 ↓
Recommendation
 ↓
Remediation 제안
 ↓
사람 Review
 ↓
Test
 ↓
실행

입니다.

일부 Trusted Advisor 기반의 사전 제작된 SSM Runbook은 사용자 동의 후 실행할 수 있지만, AI가 만든 수정안을 무조건 자동 적용하는 제품은 아닙니다.

---

14. 이 점은 오히려 잘 설계한 부분이다

Cloud Architecture Agent가:

비용을 줄이는 게 좋겠어.

라고 판단하고 Production DB를 마음대로 바꿔버리면 곤란합니다.

특히 Architecture에는 Trade-off가 있습니다.

비용 ↓

성능 ↓

일 수도 있고,

Resilience ↑

비용 ↑

일 수도 있습니다.

그래서 마지막 결정은 사람이 해야 합니다.

---

15. Terraform도 직접 리뷰할 수 있다

개발자에게는 이쪽이 더 재미있을 수 있습니다.

Well-Architected Agent는 실행 중인 AWS 환경만 보는 게 아닙니다.

Infrastructure as Code도 분석합니다.

현재 공식적으로:

Terraform

CloudFormation

AWS CDK

를 대상으로 Architecture Review를 할 수 있습니다. :chatgpt-content-reference{index="2"}

---

16. Production에 올리기 전에 Architecture Review를 할 수 있다

예를 들어 Terraform이 있습니다.

main.tf
network.tf
database.tf
ecs.tf

Deployment 전에 Agent에게 분석시킵니다.

Terraform
 ↓
Well-Architected Agent
 ↓
Architecture Review
 ↓
Security
Cost
Performance
Resilience
 ↓
수정된 IaC

이렇게 사용할 수 있습니다.

---

17. 이건 Cloud Architect 역할과 꽤 비슷하다

기존에는 Infrastructure PR이 올라오면 사람이 봅니다.

이 Security Group 너무 열려 있는데?

RDS Multi-AZ 필요하지 않을까?

이 Instance 너무 큰 거 아닌가?

NAT Gateway 비용 괜찮나?

이제 Agent가 1차 Review를 맡을 수 있습니다.

Terraform PR
       ↓
Well-Architected Agent
       ↓
Finding
       ↓
수정안
       ↓
Cloud Architect Review

사람이 없어지는 게 아니라 검토 전에 Agent가 기본적인 분석을 해주는 구조입니다.

---

18. 운영 중인 환경과 IaC를 따로 보는 것도 중요하다

실제 Cloud 환경에는 흔히 이런 문제가 생깁니다.

Terraform에는 A

실제 Production에는 B

사람이 Console에서 직접 설정을 바꿨기 때문입니다.

그래서:

실제 Resource 분석

과

IaC Architecture Review

를 같이 가져가는 방식이 의미가 있습니다.

---

19. 여러 AWS Account도 한 Profile로 볼 수 있다

큰 회사는 AWS Account 하나로 끝나지 않습니다.

Development Account

Staging Account

Production Account

Security Account

Data Account

처럼 나눠져 있습니다.

Well-Architected Agent는 Cross-account 분석을 위해 IAM Execution Role과 Access Role을 사용합니다.

Profile 하나에서 여러 Account를 Scope로 정할 수 있습니다.

현재 설정 문서에서는 Profile당 최대 100개 Account를 등록할 수 있습니다. :chatgpt-content-reference{index="3"}

---

20. 권한도 별도로 관리한다

구조는 대략 이렇습니다.

Well-Architected Agent

        ↓

Execution Role

        ↓

Account A Access Role

Account B Access Role

Account C Access Role

그래서 Agent에게 회사 전체 AWS Administrator 권한을 주는 방식이 아닙니다.

---

21. Application Context도 직접 넣을 수 있다

Agent가 AWS Resource만 보고 모든 걸 알아낼 수는 없습니다.

그래서 사람이 추가 Context를 제공합니다.

예를 들어:

Application Overview

Architecture Description

Criticality

Industry

Application Type

Tags

Additional Context

등입니다.

---

22. 같은 Resource라도 Context가 있으면 판단이 달라진다

예를 들어 EC2 CPU가 10%라고 해보겠습니다.

Context가 없다면:

Instance가 너무 크다.

라고 볼 수 있습니다.

하지만 이 서버가:

월말 정산 때만 CPU 90%

Business Critical

Latency 민감

이라면 이야기가 달라집니다.

AI에게도 결국 좋은 Context가 필요합니다.

---

23. Agent라고 해도 Context Engineering은 그대로 중요하다

요즘 Coding Agent에서도 같은 이야기가 나옵니다.

좋은 Model

+
좋은 Context

+
좋은 Tool

이 필요합니다.

Cloud Agent도 똑같습니다.

AWS Resource 정보

+

Application Context

+

Business Goal

+

Architecture

가 있어야 더 좋은 Recommendation이 나옵니다.

---

24. 한 번 분석하고 끝나는 Tool도 아니다

기존 Architecture Review는 보통 특정 시점에 합니다.

Review
 ↓
Report
 ↓
끝

하지만 실제 AWS 환경은 계속 바뀝니다.

새 EC2

새 Lambda

새 Database

Traffic 증가

Instance 변경

새 Service

가 계속 생깁니다.

Well-Architected Agent는 Resource와 Application Recommendation을 정기적으로 다시 분석하고 갱신하는 방식으로 설계되어 있습니다. Architecture Recommendation은 IaC에 대해 별도로 실행하는 Review입니다. :chatgpt-content-reference{index="4"}

---

25. 그래서 ‘Cloud Architecture Review’가 이벤트에서 프로세스로 바뀐다

기존 방식:

분기별 Architecture Review

또는

큰 Release 전에 Review

였다면,

앞으로는:

Cloud 계속 변경
       ↓
Agent 계속 분석
       ↓
Recommendation 갱신
       ↓
팀이 우선순위대로 처리

하는 방식이 가능합니다.

이 차이는 꽤 큽니다.

---

26. 예를 들어 비용 최적화라면

Agent가 이런 걸 계속 볼 수 있습니다.

CPU Utilization

Memory 사용

Resource Configuration

Resource 관계

Business Criticality

그리고:

비용 절감 효과

수정 난이도

성능 영향

Resilience 영향

까지 같이 보여주는 방식입니다.

---

27. 단순 FinOps Tool보다 범위가 넓다

Cloud Cost Tool은 보통:

얼마나 쓰고 있는가?

어디에서 비용이 나오는가?

가 중심입니다.

Well-Architected Agent는 여기에:

Security

Performance

Resilience

까지 같이 봅니다.

그래서 단순히:

가장 싼 Architecture

를 만드는 게 목표가 아닙니다.

---

28. Cross-pillar Trade-off가 중요한 이유

예를 들어:

Multi-AZ 제거

하면 비용은 줄어듭니다.

하지만:

Cost
✅

Resilience
❌

가 됩니다.

반대로:

Read Replica 추가

하면:

Performance
✅

Resilience
✅

Cost
❌

가 될 수 있습니다.

Agent는 이런 여러 Pillar 사이의 영향을 같이 보여줍니다.

---

29. 개발팀에서는 어떤 식으로 쓸 수 있을까

한 가지 Workflow를 생각해볼 수 있습니다.

Terraform PR
       ↓
Well-Architected Review
       ↓
Agent Recommendation
       ↓
Developer 확인
       ↓
Cloud Architect Review
       ↓
IaC 수정
       ↓
CI
       ↓
Deploy

즉 AI가 Architecture 승인을 대신하는 게 아니라 Architecture Review의 첫 번째 Reviewer가 되는 것입니다.

---

30. Production에서는 조금 다르게 쓸 수 있다

운영환경에서는:

AWS 환경
   ↓
정기 분석
   ↓
Recommendation
   ↓
Impact / Effort 정렬
   ↓
Ticket
   ↓
개발팀 검토
   ↓
Remediation

식으로 연결할 수 있습니다.

Jira 같은 업무 시스템까지 붙이면 Cloud Optimization Backlog를 지속적으로 관리하는 것도 가능합니다.

---

31. 여기서 개발자의 역할도 조금 바뀐다

기존에는 Cloud Engineer가 시간을 많이 쓰던 일이 있습니다.

Resource 확인

Metric 확인

문서 검색

Best Practice 확인

CLI 작성

Terraform 수정

Agent가 일부를 맡게 되면 사람이 더 집중할 부분은:

이 Recommendation이 우리 서비스에 맞는가?

Trade-off를 받아들일 수 있는가?

Production Risk는?

언제 적용할까?

정말 이 Architecture가 필요한가?

같은 판단입니다.

---

32. 즉 Cloud Architect가 없어지는 이야기는 아니다

오히려 반대에 가깝습니다.

Agent가:

문제 탐색

기본 분석

수정안 작성

을 많이 해줄수록 사람은:

Architecture Decision

Business 판단

Risk

우선순위

에 집중할 수 있습니다.

Coding Agent와 비슷합니다.

AI가 코드를 더 많이 작성할수록 Senior Developer의 Code Review와 Architecture 판단이 더 중요해지는 것과 같습니다.

---

33. 그런데 왜 AWS가 지금 이런 Agent를 만들었을까

최근 AI Agent 방향을 보면 이유를 쉽게 볼 수 있습니다.

Agent가 처음에는:

Chat

에 있었습니다.

그다음:

Coding

으로 들어왔고,

이제:

Cloud Operations

까지 내려오고 있습니다.

AWS 입장에서는 자신들이 이미 가지고 있는:

AWS Resource Data

CloudWatch Metrics

Trusted Advisor

Well-Architected Framework

SSM

IAM

CloudFormation

을 Agent가 사용할 수 있습니다.

상당히 자연스러운 조합입니다.

---

34. AWS에서는 같은 날 Ambient Agent도 공개했다

그리고 이번 흐름과 같이 보면 재미있는 발표가 하나 더 있습니다.

AWS는 Amazon Bedrock AgentCore를 이용해 Ambient Agent를 만드는 방법도 공개했습니다.

Ambient Agent는 Chat창에서:

이거 처리해줘.

라는 말을 기다리지 않습니다.

대신 이벤트를 기다립니다.

S3 File Upload

Database Change

Schedule

System Alert

같은 이벤트입니다. :chatgpt-content-reference{index="5"}

---

35. 이벤트 자체가 Prompt가 된다

기존 Agent:

사람
 ↓
Prompt
 ↓
Agent

Ambient Agent:

Event
 ↓
Agent

입니다.

예를 들어:

CloudWatch Alert
       ↓
Agent 시작
       ↓
Log 분석
       ↓
원인 후보 정리
       ↓
수정 필요
       ↓
사람에게 질문

같은 구조입니다.

---

36. 사람이 필요할 때만 멈춘다

AWS의 예제에는 ask_human Tool이 있습니다.

Event
 ↓
Agent
 ↓
분석
 ↓
사람 판단 필요?
 ↓
YES
 ↓
ask_human
 ↓
Agent 정지
 ↓
사용자 답변
 ↓
이어 실행

입니다.

Always-on Agent나 dots에서 봤던 흐름과도 비슷합니다.

---

37. Well-Architected Agent와 Ambient Agent를 같이 보면 방향이 보인다

둘은 같은 제품은 아닙니다.

하지만 AWS가 Agent를 어디까지 가져가려는지는 보입니다.

Well-Architected Agent
→ Cloud 환경을 계속 분석

Ambient Agent
→ Infrastructure Event가 발생하면 자동 시작

앞으로는:

CloudWatch Alert
       ↓
Agent
       ↓
문제 조사
       ↓
Well-Architected Context
       ↓
Remediation 준비
       ↓
사람 승인

같은 Architecture도 자연스럽게 생각할 수 있습니다.

---

38. 중요한 건 ‘AI가 Production을 알아서 고친다’가 아니다

이런 발표를 보면 쉽게:

이제 AWS 장애도 AI가 알아서 고치겠네.

라고 생각하기 쉽습니다.

하지만 현재 구조는 그보다 보수적입니다.

관찰

분석

추천

수정안 준비

사람 검토

가 중심입니다.

Production을 자동으로 바꾸는 권한과 분석 권한을 분리하는 건 좋은 선택입니다.

---

39. Agent에게 Cloud 권한을 줄수록 IAM이 더 중요해진다

앞으로 Cloud Agent가 많아질수록:

무슨 Model인가?

만큼 중요한 질문이 생깁니다.

무슨 권한을 가지고 있는가?

입니다.

그래서 AWS WA Agent도 Customer-managed IAM Role을 사용합니다.

Agent에게 필요한 범위만 보여줄 수 있습니다.

---

40. 결국 Cloud Agent에서도 가장 중요한 건 Guardrail이다

앞으로 Agent가:

AWS

GitHub

Database

CI/CD

Monitoring

Deployment

까지 연결되면 편리합니다.

하지만 권한이 커질수록 문제가 생겼을 때 피해도 커집니다.

좋은 구조는:

Agent에게 충분한 정보

+

최소한의 권한

+

명확한 Approval

+

Audit

+

자동 Test

를 같이 가져가는 겁니다.

---

마치며

AWS Well-Architected Agent를 처음 보면:

Well-Architected 체크리스트에 AI를 붙였네.

정도로 생각할 수 있습니다.

하지만 실제 방향은 조금 더 큽니다.

기존에는 사람이:

AWS Console 열기

Metrics 확인

Resource 확인

Best Practice 검색

Architecture 판단

수정 방법 검색

을 했습니다.

앞으로는 Agent가 먼저:

실제 Infrastructure 확인
       ↓
Metrics 확인
       ↓
Application 관계 파악
       ↓
Business Goal 반영
       ↓
Recommendation
       ↓
수정안 준비

까지 합니다.

그리고 사람은:

이 변경이 우리 서비스에 맞는가?

비용과 안정성 중 무엇을 우선할 것인가?

Production에 적용해도 되는가?

를 결정합니다.

특히 개발자 입장에서 재미있는 건 Terraform·CloudFormation·CDK를 Deployment 전에 Architecture Review할 수 있다는 점입니다.

Coding Agent가:

Source Code

를 Review하기 시작했다면,

Well-Architected Agent는:

Infrastructure Architecture

를 Review하기 시작한 셈입니다.

최근 Agent 흐름을 보면 계속 같은 방향이 보입니다.

Coding Agent
→ 코드를 본다

Security Agent
→ 취약점을 본다

Cloud Agent
→ Infrastructure를 본다

Ambient Agent
→ Event를 기다렸다 스스로 움직인다

AI가 새로운 화면 하나를 만드는 데서 끝나는 게 아니라 기존 개발환경과 운영 시스템 안으로 점점 깊게 들어오고 있습니다.

그래서 앞으로 Cloud Engineer나 Architect에게 중요한 능력도 조금 달라질 수 있습니다.

AWS 서비스 이름을 많이 외우는 것만큼,

Agent에게 어떤 Context를 줄 것인지, 어떤 권한까지만 허용할 것인지, 그리고 AI가 제안한 Architecture를 어떻게 검증할 것인지

가 더 중요해질 가능성이 큽니다.

Cloud Architecture까지 Agent가 보는 시대가 시작됐습니다.

하지만 최종 Architecture를 결정하는 일은 아직,

사람의 몫입니다.

참고자료

AWS — Announcing AWS Well-Architected Agent

AWS Well-Architected Agent의 Public Preview 공식 발표입니다. 65개 이상의 AWS 서비스 분석, Business Goal 기반 Recommendation, Resource·Application·Architecture 3단계 분석과 Remediation 방식을 설명합니다.

AWS Well-Architected Agent 공식 발표

AWS — What is AWS Well-Architected Agent

Well-Architected Agent와 기존 Well-Architected Tool의 차이, AI 기반 Recommendation과 Infrastructure as Code 분석 방식을 설명하는 공식 문서입니다.

AWS Well-Architected 공식 문서

AWS — Well-Architected Agent Concepts and terminology

Agent Profile, Business Goal, Application Context, IAM Execution·Access Role, Resource·Application·Architecture Recommendation과 IaC Review 구조를 자세히 설명합니다.

Well-Architected Agent 개념 문서

AWS — Security in AWS Well-Architected

Agent가 사용하는 Read-only 권한, 실제 데이터 저장소의 내용에는 접근하지 않는다는 점, AI가 생성한 Remediation의 검토와 실행 책임을 설명합니다.

Well-Architected Agent 보안 문서

AWS — Building ambient agents with Amazon Bedrock AgentCore

S3 업로드·Schedule·System Alert 같은 이벤트를 Prompt로 받아 자동으로 움직이고, 필요한 시점에 ask_human으로 사람에게 판단을 요청하는 Ambient Agent 구조를 설명합니다.

Amazon Bedrock AgentCore Ambient Agent 공식 글