AWS Well-Architected Agent(프리뷰) 직접 써 보기 – IaC 아키텍처 검토부터 계정 스캔 결과까지

작성자 조 길상 작성일 10월 7, 2026 조회수 30

안녕하세요. GS Neotek 조길상 입니다.
2026년 10월 1일, AWS가 AWS Well-Architected Agent를 프리뷰로 공개했습니다.

지금까지 Well-Architected Review는 아키텍트가 질문지에 답하며 워크로드를 하나씩 점검하는 방식이었다면, 이 에이전트는 계정의 리소스 구성·사용률·애플리케이션 구조를 AI가 직접 분석해 비용·보안·성능·복원력 4개 영역의 개선안을 우선순위와 함께 제시합니다.

이번 글에서는 테스트 계정에서 에이전트를 직접 설정하고, 배포 전 IaC 템플릿을 올려 아키텍처 검토를 받아 본 과정을 정리했습니다.

한눈에 보기

참고: AWS News Blog 발표, What is AWS Well-Architected Agent, Quotas and limits

1. 시작하기 – Well-Architected 콘솔

Well-Architected 콘솔(버지니아 북부)에 들어가면 첫 화면 오른쪽에 “AWS Well-Architected Agent 시작하기” 카드가 보입니다. 기존 질문지 방식의 Well-Architected Tool과 나란히 “서비스 모음”으로 묶여 있습니다.

2. 에이전트 프로필 만들기

에이전트는 프로필 단위로 동작합니다. 프로필에서 “어느 계정·리전을, 어떤 원칙 기준으로, 어떤 목표에 맞춰” 볼지 정합니다.

2-1. 계정과 리전

모니터링할 리전과 계정 ID(최대 100개)를 입력하고, 각 계정에 만들 공통 접근 역할 이름을 정합니다.
기본값 AccessRoleForWellArchitectedAgent를 그대로 썼습니다.

2-2. 최적화 원칙과 목표 — 이 서비스의 핵심

원칙(비용 최적화·보안·복원력·성능)마다 목표를 문장으로 적습니다.
에이전트는 이 목표를 기준으로 권장 사항의 우선순위를 매깁니다. 기본으로 영문 예시 목표가 들어 있는데, 한국어로 바꿔 넣어도 그대로 저장됩니다.
아래내용은 제가 입력한 예시로 목표는 “무엇을 · 얼마나 · 언제까지”가 드러나게 쓰는 것이 좋습니다.
콘솔의 입력칸 예시도 <XX months> 내에 인프라 비용 <XX%> 절감 형태입니다.

2-3. 권한 — 실행 역할과 접근 역할

권한은 역할 2개로 나뉩니다.

콘솔의 “새 역할 생성”을 누르면 실행 역할이 바로 만들어집니다.
권한 정책은 접근 역할을 수임하는 sts:AssumeRole 하나뿐입니다.

생성된 실행 역할의 신뢰 정책에는 aws:SourceAccount·aws:SourceArn 조건이 들어 있어, 우리 계정의 에이전트 프로필만 이 역할을 쓸 수 있습니다(confused deputy 방지).

접근 역할은 콘솔이 만들어 주지 않습니다. 분석 대상 계정이 많아지면 반복 작업이 되므로 CloudFormation 템플릿으로 만들었습니다.

AccessRole:
  Type: AWS::IAM::Role
  Properties:
    RoleName: AccessRoleForWellArchitectedAgent
    AssumeRolePolicyDocument:
      Version: "2012-10-17"
      Statement:
        - Effect: Allow
          Principal:
            AWS: !Sub "arn:aws:iam::${ProfileOwningAccountId}:role/service-role/ExecutionRoleForWellArchitectedAgent"
          Action: sts:AssumeRole
    ManagedPolicyArns:
      - arn:aws:iam::aws:policy/WellArchitectedAgentResourceScanning

주의: 콘솔의 “새 역할 생성”으로 만든 실행 역할은 service-role/ 경로에 생깁니다. 신뢰 정책의 Principal ARN에 이 경로를 빠뜨리면 수임이 실패합니다.

접근 역할의 관리형 정책, 어디까지 읽을 수 있을까?

접근 역할에 붙이는 AWS 관리형 정책 WellArchitectedAgentResourceScanning(v2)을 직접 열어 봤습니다.

• 허용 Action 1,121개 / 262개 서비스, 모두 List·Get·Describe 등 조회 계열이며 리소스를 변경하는 권한은 없습니다.
• S3 객체 내용, Secrets Manager 비밀 값, SSM 파라미터 값, KMS 복호화, DynamoDB 항목 조회처럼 대표적인 데이터 본문 조회 권한은 빠져 있습니다.
• 다만 일부 서비스는 Get* 와일드카드로 허용되어 있어(예: CloudWatch Logs, CodeCommit, Athena, ECR) 로그 내용·소스 코드·쿼리 결과처럼 데이터에 닿는 조회도 범위에 포함됩니다. 민감한 계정에 적용할 때는 이 점을 보안 검토에 포함하는 것이 좋습니다.

2-4. 프로필 생성 완료

“시작하기”를 누르면 프로필이 만들어지고, “계정 액세스가 올바르면 24시간 이내에 권장 사항이 생성되며, 그동안 아키텍처 검토를 수행할 수 있다”는 안내가 나옵니다. 종료 방지(Termination protection)는 기본 활성화인데, PoC라 정리를 쉽게 하려고 껐습니다. 운영 환경이라면 켜 두는 것을 권장합니다.

3. 배포 전 IaC 아키텍처 검토

계정 스캔 결과는 하루 정도 걸리지만, IaC 아키텍처 검토는 바로 실행할 수 있습니다.
배포 전 템플릿을 올려 Well-Architected 관점의 지적을 받는 기능입니다(프로필당 하루 5회, zip 25MB 이하).

3-1. 테스트용 템플릿 — 일부러 문제를 심었습니다

ALB + EC2 + RDS + S3로 된 간단한 웹 앱 CloudFormation 템플릿에 흔히 보는 문제를 넣었습니다.

3-2. 검토 요청

“아키텍처 검토 수행”에서 렌즈(Well-Architected Framework)와 검토할 원칙을 고르고 IaC 파일을 지정합니다.

알아 둘 점: 항목 이름은 “파일 업로드”지만, 콘솔에서는 zip을 S3에 올린 뒤 S3 URI와 객체 버전을 지정하는 방식이었습니다. 그리고 “에이전트가 해당 S3 위치의 파일 내용에 일회성으로 접근하는 것에 동의” 체크가 필요합니다. 검토용 버킷은 퍼블릭 차단·암호화·HTTPS 강제·30일 만료를 적용해 따로 만들었습니다.

“검토 시작”을 누르면 대시보드의 검토 목록에 “대기 중” 상태로 올라가고, 처리가 끝나면 결과가 표시됩니다.

검토는 10:18에 시작해 10:41에 완료됐습니다(약 23분). 진행 화면에는 “생성형 AI 에이전트가 검토를 완료하는 데 필요한 모든 관련 질문에 답변하고 있습니다”라는 문구와 함께 단계 진행률(5 of 5)이 표시됩니다. 기존 Well-Architected Tool에서 사람이 답하던 질문지를 에이전트가 IaC를 읽고 대신 답하는 구조로 보입니다.

4. 검토 결과 — 추천 8건

완료되면 대시보드의 모든 추천 탭에 결과가 올라옵니다. 이번 검토에서는 8건이 나왔고, 모두 “아키텍처” 유형입니다. 배포된 리소스가 아니라 IaC를 본 것이라 “영향을 받는 리소스 수”는 0으로 표시됩니다.

추천 하나를 열어 보면

추천 상세는 개요 → 인사이트(감지한 신호) → 원칙 간 영향·트레이드오프 → 수정 단계 순서로 구성됩니다. HTTPS 추천을 예로 들면, 템플릿의 Listener가 Protocol: HTTP, Port: 80이고 인증서·SslPolicy가 없다는 구체적인 근거를 들고, Well-Architected 모범 사례 SEC09-BP02(전송 중 암호화) 위반으로 분류합니다.

문제 해결 — IaC 수정 코드까지

“문제 해결 시작”을 누르면 업데이트된 IaC 템플릿과 AWS CLI 중 방식을 고를 수 있고, 7단계 SOP(전제 조건 확인 → 수정 → 변경 세트 배포 → 검증)가 나옵니다. 전체 SOP는 다운로드할 수 있습니다.

인상적인 부분은 제안 코드가 우리 템플릿의 리소스 이름(Listener, LoadBalancer, TargetGroup)을 그대로 써서 작성된다는 점입니다. 기존 리스너는 같은 논리 ID를 유지한 채 301 리다이렉트로 바꾸고, TLS 1.3 보안 정책(ELBSecurityPolicy-TLS13-1-2-2021-06)을 쓰는 HTTPS 리스너를 추가합니다. 배포에 필요한 IAM 권한, 리스너 교체 시점(트래픽이 적은 시간대 권장), 관련 Control Tower 통제(CT.ELASTICLOADBALANCING.PR.1)까지 함께 안내합니다.

심어 둔 문제를 얼마나 찾았나

심어 둔 11개 중 8개를 찾았고, 심지 않았지만 타당한 지적(#5 예산·이상 탐지·비용 태그)도 1건 추가로 나왔습니다.

5. 계정 스캔 결과 — 실제 리소스에 대한 추천 25건

프로필을 만든 다음 날(10월 7일) 대시보드를 다시 열어 보니, 계정 스캔 기반 추천이 생성되어 있었습니다.
추천 상세의 “다음에서 감지됨”은 10월 6일, “다음을 통해 생성됨”은 scheduled-generation으로, 프로필을 만든 당일 안에 첫 스캔이 돌았습니다(안내 문구는 “24시간 이내”). 접근 역할의 마지막 사용 시각도 프로필 생성 약 3시간 뒤로 찍혀 있었습니다.

전체 추천은 33건으로 늘었는데, 이 중 8건은 앞에서 본 IaC 아키텍처 검토 결과이고 25건이 계정 스캔에서 나온 것입니다.

우선순위 “높음”으로 올라온 3건은 모두 애플리케이션 유형이었습니다.

애플리케이션 추천 하나를 열어 보면

백업 추천의 상세에는 대상 리소스 3개, 위반한 모범 사례(REL09-BP01), 인사이트 2건, 트레이드오프, 4단계 수정 절차(즉시 스냅샷 → 일일 스냅샷 수명 주기 정책 → PITR 35일 → 삭제 방지)가 정리되어 있었습니다. 눈에 띈 점은 두 가지입니다.

• 주변 리소스와 비교합니다. “같은 계정의 다른 DynamoDB 테이블은 이미 PITR 35일이 켜져 있으니 백업 기준을 맞추라”는 식으로, 개별 설정 점검이 아니라 계정 안의 일관성까지 봅니다.
• 기존 점검 결과를 근거로 씁니다. 인사이트에 Trusted Advisor의 EBS 스냅샷 점검 결과(CRITICAL)가 신호로 인용되어 있었습니다. 새로 스캔한 것과 기존 도구의 결과를 엮어 설명하는 구조입니다.

계정 스캔에서 확인한 것

• 애플리케이션 컨텍스트를 따로 정의하지 않았는데도 애플리케이션 유형 추천이 나왔습니다. 모두 Default Application으로 묶여 있고, 대시보드에는 “애플리케이션 컨텍스트를 추가하면 더 정확한 추천을 받는다”는 안내가 붙어 있습니다. 워크로드가 여러 개 섞인 계정이라면 컨텍스트를 나눠 정의하는 것이 좋겠습니다.
• 워크로드의 용도까지 추론합니다. 실습용 IDE 인스턴스의 SSH 개방을 “Session Manager로 바꾸라”고 짚는 등, 리소스 이름·구성으로 용도를 파악해 설명했습니다.
• 목표와 연결됩니다. 프로필에 적은 목표 중 “단일 AZ·백업 없는 구성 제거”가 백업 추천을 우선순위 높음으로 끌어올린 것으로 보입니다(콘솔 문구: “목표와 잠재적 영향을 기반으로 동적 순위”).
• 비용 추천은 적었습니다. 계정 스캔 25건 중 비용 최적화는 2건(미사용 EBS 볼륨 삭제, 미완료 멀티파트 업로드 정리)뿐이었습니다. 테스트 계정 규모가 작은 영향도 있어 보입니다.

6. 써 보고 느낀 점

좋았던 점

• 1. 목표를 실제로 읽습니다.
  비용 통제 추천(#5)에는 “이대로면 20% 비용 절감 목표를 검증할 수 없다“는 문장이 들어 있고, HTTPS 추천의 효과에도 “암호화되지 않은 데이터를 없애 보안 기본선을 맞춘다”는 우리 목표가 그대로 언급됩니다. 목표를 문장으로 잘 써 두는 것이 결과 품질에 직접 영향을 줍니다.
• 2. 근거가 구체적입니다.
  모든 추천이 “어느 리소스의 어떤 속성이 문제인지”와 Well-Architected 모범 사례 번호를 함께 보여 줘서, 사람이 검증하기 쉽습니다.
• 3. 바로 고칠 수 있게 줍니다.
  템플릿에 맞춘 수정 코드, 필요한 권한, 배포 시 주의점, 검증 단계까지 한 번에 나옵니다.
• 4. 배포 전에 쓸 수 있습니다.
  계정에 리소스를 만들지 않고 IaC만으로 리뷰를 받을 수 있어, 설계 리뷰·PR 리뷰 단계에 넣기 좋습니다.

아쉬웠던 점 (프리뷰 기준)

• 1. 일부 놓친 항목
  IMDSv1, S3 퍼블릭 액세스 차단·버전 관리·수명 주기는 관점의 차이인지 지적되지 않았습니다.
  기존 다른 분석 도구(cfn-lint, cfn-guard, Security Hub 등)와 함께 쓰는 것이 필요할 수 있습니다
• 2. “파일 업로드”가 실제로는 S3 지정:
  로컬 zip을 바로 올리는 것이 아니라 S3에 먼저 올려야 해서, 검토용 버킷 관리가 필요합니다.
• 3. 소요 시간 측면
  즉시 피드백 보다는 비동기 리뷰에 가깝습니다.
  템플릿 1개(리소스 8개 규모)에 약 23분이 걸렸습니다.
• 4. AI 생성 결과
  콘솔에도 “오류 또는 불완전한 정보를 포함할 수 있다”는 안내가 붙어 있습니다.
  적용 전 사람의 검토는 필수입니다.

7. 정리

Well-Architected Review를 “필요할 때 마다 진행하는 리뷰”에서 “배포 전마다 받는 자동 리뷰”로 바꿀 수 있는 가능성을 보여 준 서비스였습니다. 아직 프리뷰라 빈틈도 보이지만, 목표 기반 우선순위와 템플릿 맞춤 수정 코드는 기존 점검 도구에서 보기 어려웠던 부분입니다.

계정 스캔까지 보고 나니, 템플릿 검토와 계정 스캔이 배포 전(IaC)과 배포 후(실제 리소스)를 함께 덮는 구조라는 점이 가장 큰 장점으로 느껴졌습니다. 다만 추천은 AI가 생성한 것이므로, 적용 전에는 대상 리소스와 영향을 사람이 직접 확인해야 합니다.