Cloud by Yeon

MSP 회사에 다니면 얻을 수 있는 특권 중 하나는 aws ambassdor를 지원해볼 수 있다는 것

aws ambassdor의 경우는 오직 MSP 회사를 다니는 사람에게만 주어지는 기회이기 때문에 지원을 해보기로 했다 

다행히도 하고 싶다고 떠들고 다니니까 후보자 승인을 위해 회사가 추천서를 작성해주셨고

2026년 07월 24일 드디어 aws 글로벌에서 후보자 승인이 났다 얏호

이제는 후보자 신분으로 정식 aws ambassdor가 되기 위해서 과정을 수행해야한다

아직 후보자이지만 감사하게도 aws 코리아에서 aws ambassdor Meetup행사에 초대해주셨다

korea aws ambassdor끼리 인사하고 친목을 다지는 목적의 Meetup이였다

샌터필드에서 진행되었고 신규 후보자들(나)의 인사와 기존 aws ambassdor분들의 자기소개를 진행하였다 

그리고 시작된 먹부림

사실 js가든이라는걸 봤을때 저 음식점이 무슨 음식점인지 미리 찾아보았다

북경오리 맛집이라고라?

저의 목적은 북경오리를 시켜주시려나 먹어볼 수 있으려나 였는데 넘좋았습니다

북경오리가 끝이 없이 나오고요? 

탕수육 난자완스 유산슬 등등 요리가 끊임없이 나와서 행복했어요,,ㅎ

일단 사실 아는 사람이 많이 없어서 조금 뻘쭘하긴했는데

음식먹으면서 이런저런 이야기 많이 나눠볼 수 있어서 좋았다 다들 링크드인에서 한번씩 본 분들이라서 신기했고 내가 여기에 있어도 되는건가? 싶은 느낌도 살짝 들었다ㅎ

aws ambassdor 모임답게 이야기 대부분이 aws 기술에 대한 이야기인데 재미있는 이야기를 많이 듣고 올 수 있어서 좋았고

후보자이긴하지만 나도 이들 사이에서 꿀리고 싶지 않다라는 생각을 했습니다

다들 너무 멋진분들이라서 기가 살짝 죽긴했음

근데 뭐 회사도 생각이 있으니까 나를 aws ambassdor로 올려줬겠지(?)하는 생각으로 뻔뻔하게 자리에서 밋업 자리를 즐기고 왔고요

많은분들을 알아볼 수 있는 자리여서 넘 좋았답니다

1. 들어가며: 하나의 EKS, 세 개의 에이전트

서울 리전에는 devops-agent-test라는 EKS 클러스터가 있습니다. 이 클러스터에 AWS DevOps Agent와 AWS Security Agent를 붙여 운영·보안 관점을 자동화해 왔고, 이번 글은 세 번째 축인 비용 관점을 다루려고 합니다.

AWS FinOps Agent는 2026년 6월 퍼블릭 프리뷰로 공개된 Amazon Bedrock 기반 비용 분석 에이전트입니다. 프리뷰 기간에는 us-east-1(버지니아)에서만 생성할 수 있는데, 그럼에도 서울 리전의 EKS 비용을 그대로 분석할 수 있었습니다. 실제로 만들어 자연어로 질의해보니 월 누적(MTD) 비교의 함정을 스스로 인지해 일평균으로 환산하고 결과를 Slack으로 배포하는 등 기대 이상이었는데, 그 응답을 CLI로 교차 검증하는 과정에서 8월 총액이 12배나 다르게 나왔습니다. 에이전트의 오류인 줄 알고 CloudTrail까지 뒤졌지만, 원인은 에이전트가 아니라 검증하는 쪽에 있었습니다. 이 글은 그 과정을 "왜 리전이 달라도 되는가"라는 질문에서 출발해, 사전 준비, 비용 격리 설계, 생성, 실제 질의 결과, 그리고 교차 검증에서 배운 것 순으로 정리한 기록입니다.

먼저 세 에이전트의 차이부터 짚겠습니다.

세 에이전트는 같은 클러스터를 보지만, "무엇을 통해 보는가"가 완전히 다릅니다. 이 차이를 먼저 이해해야 뒤에 나오는 리전 문제와 IAM 설계가 자연스럽게 읽힙니다.

에이전트 관찰 대상 연동 실체 관점

2. 왜 "서울 워크로드"인데 "버지니아 에이전트"인가

FinOps Agent는 프리뷰 기간에는 us-east-1에서만 생성됩니다. 처음 이 제약을 봤을 때 자연스럽게 드는 의문은 "그럼 서울 리전 비용은 못 보는 것 아닌가?"였습니다.

결론부터 말하면 볼 수 있습니다. 이유는 데이터의 성격에 있습니다.

Cost Explorer, Cost Optimization Hub, Compute Optimizer가 다루는 비용·사용 데이터는 리전에 묶여 있지 않습니다.

서울에서 EC2가 돌든 도쿄에서 EBS가 붙든, 그 비용은 결국 하나의 계정 청구로 집계됩니다.

FinOps Agent는 이 계정 전역 데이터를 읽는 것이지, 서울 리전의 API 엔드포인트에 접속해 리소스를 나열하는 것이 아닙니다.

즉 이 구성은 "크로스 리전 연동"이 아닙니다. 애초에 리전 개념이 없는 데이터를 읽는 서비스를 리전 제약이 있는 곳에 배치한 것뿐입니다. 이 관점을 갖고 나면 "어느 리전에 에이전트를 둘 것인가"는 중요하지 않고 어느 리전에 위치해 있더라도 FinOps Agent를 활용하여 비용 관리를 할 수 있습니다.

3. FinOps Agent가 하는 일과 읽는 데이터

FinOps Agent는 Amazon Bedrock 위에서 동작하며, 프리뷰 기준 핵심 기능은 다섯 가지입니다.

기능 설명

읽어오는 데이터 소스와 각각의 역할은 다음과 같습니다.

• AWS Cost Explorer — 비용/사용 조회, 예측, Savings Plans/RI 분석
• AWS Cost Anomaly Detection — 비용 이상 탐지 이벤트 (이벤트 기반 조사의 트리거)
• AWS Cost Optimization Hub — 계정 전역 최적화 권고 집계
• AWS Compute Optimizer — EC2/ASG/EBS/Lambda/ECS 등 리소스 단위 rightsizing 권고
• AWS CloudTrail — 이상 발생 시점 전후의 인프라 변경 추적 (Event History는 기본 활성·무료)

여기서 중요한 설계적 함의가 하나 있습니다. 에이전트에 IAM 권한을 주는 것만으로는 부족하고, 각 데이터 소스 서비스가 계정에서 실제로 활성화되어 있어야 합니다. 권한이 있어도 Cost Optimization Hub가 opt-in되지 않았다면 에이전트는 "권고 없음"만 돌려줍니다. 그래서 에이전트를 만들기 전에 데이터 소스 상태 점검이 먼저입니다.

4. 사전 준비 ①: 로컬 CLI에는 아직 없다

첫 번째로 확인한 사실입니다. 현재 AWS CLI(2.36.29)에는 finops-agent 서비스가 존재하지 않습니다.

$ aws finops-agent help
aws: [ERROR]: An error occurred (ParamValidation): argument command: Found invalid choice 'finops-agent'

프리뷰라서 그렇습니다. 따라서 에이전트 생성은 콘솔 wizard가 표준 경로입니다. 다만 에이전트가 읽을 데이터 소스의 활성화 상태와 실제 비용 데이터는 CLI로 미리 확인·조치할 수 있고, 그것이 다음 절의 내용입니다.

5. 사전 준비 ②: 데이터 소스 상태 점검

5-1. Cost Explorer — 활성 확인

$ aws ce get-cost-and-usage \
    --time-period Start=2026-08-01,End=2026-09-01 \
    --granularity MONTHLY --metrics "UnblendedCost" --region us-east-1

{ "ResultsByTime": [ { "Total": { "UnblendedCost": { "Amount": "18.9787055977", "Unit": "USD" } } } ] }

Cost Explorer가 데이터를 반환하므로 활성 상태입니다. 처음 활성화한 계정이라면 데이터가 채워지는 데 최대 24시간이 걸립니다.

5-2. Compute Optimizer — 이미 opt-in

$ aws compute-optimizer get-enrollment-status --region us-east-1

{ "status": "Active", "memberAccountsEnrolled": false, "numberOfMemberAccountsOptedIn": 0 }

status: Active이므로 rightsizing 권고를 바로 받을 수 있습니다.

5-3. Cost Optimization Hub — 미활성 → CLI로 opt-in

처음 조회하면 아래처럼 거부됩니다.

$ aws cost-optimization-hub get-preferences --region us-east-1
aws: [ERROR]: An error occurred (AccessDeniedException) when calling the GetPreferences
operation: AWS account is not enrolled for recommendations.

AccessDeniedException이지만 IAM 권한 문제가 아니라 서비스 enrollment 문제입니다. 이 구분이 중요합니다. IAM 정책을 아무리 손봐도 해결되지 않고, 계정을 enroll해야 풀립니다. 콘솔에 갈 필요 없이 CLI로 바로 opt-in할 수 있습니다.

$ aws cost-optimization-hub update-enrollment-status --status Active --region us-east-1
{ "status": "Active" }

$ aws cost-optimization-hub get-preferences --region us-east-1
{ "savingsEstimationMode": "AfterDiscounts", "memberAccountDiscountVisibility": "None", "preferredCommitment": {} }

opt-in 직후에는 권고 데이터가 쌓이는 데 24시간 내외가 걸리므로, 활성화 직후 "권고 없음"이 나오는 것은 정상입니다.

5-4. (선택) Cost Anomaly Detection 모니터

이벤트 기반 자동 조사를 쓰려면 비용 이상 탐지 모니터를 1개 이상 만들어야 합니다. 자연어 질의만 먼저 검증할 목적이라면 이 단계는 건너뛰어도 됩니다.

점검 결과 요약

데이터 소스 상태 조치

6. 비용 격리 설계: "클러스터"라는 개념이 없는 에이전트에게 클러스터를 알려주기

FinOps Agent에는 클러스터라는 개념이 없습니다. 계정 전체 비용을 보기 때문에, 서울 EKS 하나의 비용만 좁혀 보려면 에이전트 쪽이 아니라 데이터 쪽에서 리소스를 묶어줘야 합니다. 도구는 두 가지입니다. 비용 할당 태그(Cost Allocation Tag)와 Cost Category입니다.

EKS 워커 노드에 한해서는 사실 별도 태그 작업이 필요 없습니다. AWS가 EKS 클러스터에 참여하는 모든 EC2 인스턴스에 aws:eks:cluster-name 이라는 AWS 생성 태그를 자동으로 붙이기 때문입니다. 관리형 노드그룹이든, Karpenter가 띄운 노드든, 직접 만든 EC2든 상관없이 붙습니다. Billing 콘솔의 Cost allocation tags에서 이 키를 활성화하기만 하면 Cost Explorer에서 EC2 비용을 클러스터별로 바로 나눠 볼 수 있습니다.

다만 이 태그가 커버하는 범위는 EC2 인스턴스 비용까지입니다. EKS 컨트롤 플레인 요금, Kubernetes가 만들어낸 로드밸런서와 EBS 볼륨은 이 태그로 잡히지 않습니다. 그래서 나머지 리소스에는 사용자 태그(예: cost-center = devops-agent-test)를 붙여 보완해야 하고, 생성 주체가 제각각이라 태그를 붙이는 경로도 다릅니다.

여기서 놓치기 쉬운 점은 노드그룹 태그가 EC2 인스턴스로 전파되지 않는다는 것입니다. EKS 문서는 "태그는 연관 리소스로 전파되지 않는다"고 명시하고, 인스턴스까지 태그하려면 launch template을 쓰라고 안내합니다. 노드그룹 콘솔에서 태그를 붙였는데 Cost Explorer에서 안 잡힌다면 이 때문입니다.

태그를 붙인 뒤에는 Billing 콘솔에서 해당 키를 비용 할당 태그로 활성화해야 Cost Explorer 차원에서 필터로 쓸 수 있습니다. 활성화가 늦었더라도 Billing 콘솔의 "Backfill tags"(CLI: aws ce start-cost-allocation-tag-backfill)로 최대 12개월까지 소급할 수 있으며, 요청은 24시간에 한 번, 반영은 다음 일일 갱신 때 이뤄집니다. 단, backfill은 Organizations 관리 계정(management account)에서만 요청할 수 있습니다. 그리고 backfill이 살려주는 것은 "리소스에 태그는 있었는데 활성화만 늦은" 경우뿐입니다. 리소스에 태그 자체가 없던 기간의 비용은 backfill해도 "미할당"으로 남습니다. 청구 데이터는 그 시점에 리소스에 실제로 달려 있던 태그만 기록하기 때문입니다. 그래서 사용자 태그를 리소스에 붙이는 작업은 클러스터 생성 시점에 끝내는 것이 좋고, 활성화가 늦은 것은 backfill로 복구하면 됩니다.

결국 "이 클러스터 비용"의 단일 정의는 Cost Category로 만듭니다. aws:eks:cluster-name = devops-agent-test(워커 노드) OR cost-center = devops-agent-test(컨트롤 플레인·LB·EBS)를 묶은 Cost Category 하나를 정의해 두면, 에이전트에게 "Cluster 카테고리가 devops-agent-test인 리소스의 이번 달 비용"처럼 클러스터 단위로 질의할 수 있습니다. 바꿔 말하면, FinOps Agent의 답변 품질은 에이전트 설정이 아니라 태그 위생에 의해 상한이 정해집니다. DevOps Agent의 품질이 EKS access 설정에 좌우되는 것과 정확히 대칭입니다.

7. FinOps Agent 생성 (us-east-1 콘솔 wizard)

사전 권한

wizard를 실행하는 IAM 자격증명에 FinOpsAgentSetupPolicy가 있어야 합니다. 이 정책은 에이전트 생성(finops-agent:CreateAgentSpace 등)과, wizard가 역할을 자동 생성할 때 필요한 iam:CreateRole / iam:AttachRolePolicy / iam:PassRole을 포함합니다.

5단계 wizard

Step 1 — 이름. 예) seoul-eks-finops. 문자·숫자·공백·하이픈만 사용할 수 있고, 최대 128자입니다.

Step 2 — Agent role (에이전트가 접근할 AWS 리소스). 에이전트가 Cost Explorer·Compute Optimizer 등을 읽을 때 assume하는 역할입니다. Auto-create를 선택하면 FinOpsAgentAgentPolicy가 부착된 역할이 자동 생성됩니다. 중앙에서 IAM을 관리하는 조직이라면 finops-agent.amazonaws.com을 신뢰하는 역할을 미리 만들어 지정할 수 있습니다.

Step 3 — Operator role (웹앱 접근). 대화·태스크·리포트 같은 웹앱 동작을 수행할 때 assume하는 역할입니다. Auto-create 시 FinOpsAgentOperatorPolicy가 부착됩니다.

Step 4 — 서드파티 연동 (선택). Slack 채널 ID 또는 Jira 프로젝트 키를 지정합니다. 계정 레벨에 통합이 먼저 설치되어 있어야 선택 가능하며, 생성 후 상세 페이지에서 붙여도 됩니다.

Step 5 — 검토 후 생성. 자동 생성 역할 프로비저닝, 통합 연결, 웹앱 생성이 함께 진행됩니다.

두 개의 역할이 분리된 이유

Step 2와 Step 3에서 역할이 둘로 나뉘는 점은 그냥 넘기기 쉽지만, 권한 모델 관점에서 의미가 있습니다. Agent role은 데이터 읽기 경계이고, Operator role은 사용자 동작 경계입니다. 이 둘을 분리하면 "에이전트가 어떤 비용 데이터에 접근할 수 있는가"와 "누가 에이전트를 통해 무엇을 실행할 수 있는가"를 독립적으로 제어할 수 있습니다. 생성 후 IAM에 실제로 두 역할이 생긴 것을 확인했습니다.

$ aws iam list-roles \
    --query "Roles[?contains(RoleName,'FinOps')].[RoleName,Arn]" --output text
FinOpsAgentOperatorRole-xxxxxxxx  arn:aws:iam::123456789012:role/service-role/FinOpsAgentOperatorRole-xxxxxxxx
FinOpsAgentRole-xxxxxxxx          arn:aws:iam::123456789012:role/service-role/FinOpsAgentRole-xxxxxxxx

둘 다 service-role/ 경로에 생성되고, 이름 뒤 접미사는 자동 부여됩니다. wizard가 신뢰 정책까지 붙이므로 별도 IAM 작업은 없었습니다.

직접 역할을 만들 경우의 Trust Policy

IAM을 직접 관리한다면 두 역할 모두 아래 신뢰 정책을 씁니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "finops-agent.amazonaws.com" },
      "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity" ],
      "Condition": {
        "StringEquals": { "aws:SourceAccount": "123456789012" },
        "ArnLike": { "aws:SourceArn": "arn:aws:finops-agent:*:123456789012:agentspace/*" }
      }
    }
  ]
}

세 가지를 짚고 넘어갈 만합니다.

• sts:SetSourceIdentity — 웹앱 사용자의 IAM 식별자를 세션에 새겨, CloudTrail에서 "누가 에이전트를 통해 무엇을 했는지" 추적되게 합니다. 없어도 assume은 되지만 CloudTrail 이벤트에서 sourceIdentity가 빠집니다. 감사 요건이 있는 조직이라면 필수입니다.
• aws:SourceAccount + aws:SourceArn 조건 — 서비스 프린시펄을 신뢰할 때의 confused deputy 방어입니다. 이 조건이 없으면 다른 계정의 FinOps Agent가 이 역할을 assume할 수 있는 경로가 이론적으로 열립니다.
• agentspace/* 와일드카드 — 계정 내 모든 에이전트를 허용합니다. 생성 후 특정 agent ID로 좁힐 수 있습니다.

DevOps Agent Operator의 신뢰 주체는 pods.eks.amazonaws.com(클러스터 안에서 동작)이었지만, FinOps Agent는 클러스터 밖의 계정 데이터를 보므로 신뢰 주체가 finops-agent.amazonaws.com입니다. 세 에이전트를 함께 운영한다면 이 신뢰 주체의 차이가 각 에이전트의 "위치"를 가장 정확히 설명해줍니다.

Slack 연동에서 만난 두 가지 (실제 사례)

Step 4에서 Slack을 붙일 때 두 번 막혔습니다. 둘 다 FinOps Agent가 아니라 Slack 워크스페이스 쪽 이슈였습니다.

1. "Bot is not a member of this channel" — FinOps Agent 봇을 대상 채널에 초대하지 않아서 발생합니다. 채널에서 @AWS FinOps Agent로 멘션해 추가하면 해결됩니다. DevOps Agent용 Slack 앱과 FinOps Agent 앱은 별개의 앱이라, 이미 DevOps Agent를 채널에 넣어뒀더라도 새로 초대해야 합니다.
2. "이 앱은 Slack에서 승인하지 않았습니다" — 워크스페이스가 앱 설치에 관리자 승인을 요구하는 정책일 때 발생합니다. 관리자가 앱 관리 → 승인 대기 목록에서 승인하면 통과합니다.

Slack은 선택 사항이므로, 이슈 시 Step 4를 건너뛰고 에이전트를 먼저 만든 뒤 상세 페이지 → Integrations에서 나중에 붙이는 편이 빠릅니다.

해당 이슈 발생 시 해당 채널 선택 -> 채널 설정편집 -> 에이전트 및 앱 에서 AWS FinOps Agent를 추가합니다. 

8. 테스트: 무엇을 물어보고, 무엇이 나오는가

먼저 CLI로 기준선을 만들고, 에이전트에게 두 가지를 물은 뒤, 응답을 기준선과 대조했더니 맞지 않았고, CloudTrail과 에이전트 자신에게 되물어 원인을 찾았습니다.

생성 후 콘솔 Agents 페이지에서 Open agent로 웹앱을 엽니다(콘솔 세션으로 인증).

8-1. 기준선: CLI로 본 이 계정의 8월 비용

에이전트에게 묻기 전에 CLI로 8월 서비스별 비용을 뽑아 기준선을 만들었습니다.

$ aws ce get-cost-and-usage \
    --time-period Start=2026-08-01,End=2026-09-01 \
    --granularity MONTHLY --metrics UnblendedCost \
    --group-by Type=DIMENSION,Key=SERVICE --region us-east-1

서비스 8월 비용 (USD)

이 표를 보고 두 가지를 생각했습니다. 비용의 대부분(약 $17.2)이 Bedrock 모델 호출 비용이니 "에이전트로 EKS를 운영하는 비용"이 "EKS 자체 비용"을 압도하는 구조라는 것, 그리고 EKS 컨트롤 플레인과 워커 EC2가 $0인 것은 노드가 최근 생성돼 청구 반영 전이라서일 것이라는 추측이었습니다. 앞의 해석은 절반만 맞았고, 뒤의 추측은 틀렸습니다. 그 이유는 8-4에서 드러납니다.

8-2. 실제 응답: MTD 함정을 스스로 잡다

첫 번째 프롬프트를 물었을 때 에이전트가 돌려준 결과입니다.

• 단순 합계: 9월 MTD $109.73 vs 8월 $227.58 → 겉보기엔 감소
• 일평균: 9월 $12.19/day vs 8월 $7.34/day → 실제로는 +66% 증가

에이전트는 단순 합계로 비교하면 안 된다는 점을 먼저 짚었습니다. 9월은 9일치(MTD)뿐이라 8월 한 달과 총액만 비교하면 "비용이 줄었다"고 오해하게 되는데, 이를 스스로 인지하고 일평균으로 다시 계산해 "9월 $12.19/day vs 8월 $7.34/day, +66% 증가"라는 결론을 냈습니다. 상위 항목으로는 EC2-Compute $80.22, EKS $67.47, EC2-Other $16.77, CloudWatch $28.20, VPC $12.23(8월 기준)을 꼽았고, 8월 총액을 $227.58로 제시했습니다.

MTD 정규화는 Cost Explorer 콘솔이 대신 해주지 않는 판단이고, 묻지 않은 변화(8월에 있던 Bedrock 비용이 9월엔 아직 없다는 점)까지 짚어준 것은 "조회 도구"가 아니라 "분석 파트너"의 동작입니다. 그런데 8월 총액 $227.58은 8-1에서 CLI로 본 $18.98과 12배 차이가 났고, 상위에 오른 EC2-Compute와 EKS는 CLI에서 $0이었습니다.

8-3. 두 번째 질의: EKS 비중을 묻고, 결과를 Slack으로 받기

두 번째 프롬프트는 질문과 전달을 한 문장에 묶어서 던졌습니다.

Slack 채널에 도착한 메시지는 아래와 같습니다.

에이전트는 웹앱에 요약을 보여주는 동시에 Step 4에서 연결해 둔 Slack 채널에 같은 결과를 게시했습니다. 9월 MTD 총비용 $109.73 중 $90.98(82.9%)가 EKS 관련 인프라라는 답이었습니다.

배포 동작에서 확인되는 것들이 있습니다.

첫째, "EKS 관련"이라는 모호한 범주를 에이전트가 스스로 정의했습니다.

질문에서는 EC2·EBS·로드밸런서만 예시로 들었는데 EKS 컨트롤 플레인까지 포함해 네 개를 "EKS-Related"로 묶었고, CloudWatch와 VPC는 "Other Services"로 분류했습니다. 태그가 없으면 에이전트는 서비스 이름으로 범주를 추정할 수밖에 없고, 그 경계는 질문마다 달라질 수 있습니다. 6장의 태그 격리가 필요한 이유입니다.

둘째, Slack 게시물이 웹앱 응답보다 더 완전합니다.

Other Services와 Total 행이 추가되어 있고, 하단에 "Metric: UnblendedCost, Credits/Refunds excluded" 라는 산출 기준이 각주로 붙어 있으며, 상하단에 에이전트 이름·Agent ID·Conversation ID가 링크로 달려 있어 어느 대화에서 나온 숫자인지 웹앱으로 되짚어갈 수 있습니다.

셋째, 응답 끝에 "인스턴스 타입이나 노드 수 변화를 더 파고들 수 있다"는 후속 조사를 제안했습니다.

한 문장으로 "질문 + 전달 채널"을 지정하면 분석과 배포가 한 번에 끝난다는 점은 사람이 리포트를 복사해 옮기던 운영과 비교해 실질적인 차이입니다. 그런데 바로 그 점 때문에 이 숫자가 맞는지가 더 중요해집니다. 검증 없이 채널로 흘러간 숫자는 그대로 의사결정에 쓰이기 때문입니다. 그리고 이 시점에 저는 이 숫자를 믿지 않고 있었습니다.

8-4. 교차 검증: 12배 차이의 원인을 찾기까지

에이전트가 제시한 수치와 8-1의 CLI 기준선을 나란히 놓으면 이렇습니다.

첫 인상은 "숫자가 맞지 않는다는 것이었습니다"였습니다. 서비스 이름은 진짜인데 금액은 CLI와 하나도 맞지 않았고, 실제 비용의 대부분인 Bedrock은 에이전트의 표에 없었습니다.

1단계 — CloudTrail로 호출 여부 확인. 에이전트가 데이터를 읽지 못한 채 응답을 생성한 것인지 확인하기 위해, 7장에서 만든 에이전트 역할의 Cost Explorer 호출 기록을 CloudTrail Event History에서 조회했습니다.

$ aws cloudtrail lookup-events --region us-east-1 \
    --lookup-attributes AttributeKey=EventName,AttributeValue=GetCostAndUsage \
    --start-time 2026-09-09T00:00:00Z --end-time 2026-09-10T00:00:00Z --output json \
  | python3 -c "
import sys, json
for e in json.load(sys.stdin)['Events']:
    if e.get('Username') != 'FinOpsAgentRole': continue
    ev = json.loads(e['CloudTrailEvent'])
    print(ev['eventTime'], ev.get('errorCode'))
"
2026-09-09T04:53:10Z None
2026-09-09T02:02:09Z None
2026-09-09T02:02:09Z None

FinOpsAgentRole이 GetCostAndUsage를 실제로 호출했고 모두 성공했습니다. 02:02Z(11:02 KST)의 연속 두 번은 첫 번째 질의에서 8월과 9월을 각각 조회한 것입니다. 에이전트는 데이터를 읽었습니다. 그렇다면 왜 다른가.

2단계 — 에이전트에게 출처를 되묻기. 웹앱에서 직접 물었습니다.

에이전트는 호출 조건(8월: 2026-08-01~2026-09-01, 9월: 2026-09-01~2026-09-10, MONTHLY, group_by=SERVICE)과 응답 원문의 값("Amount":"67.473957735")을 제시하고, 자신은 Credit과 Refund 레코드 타입을 제외하고 조회했으니 CLI에서 같은 필터를 적용했는지 확인해 보라고 답했습니다. 호출 조건은 CloudTrail의 두 번 호출과 정확히 맞아떨어졌습니다.

3단계 — 같은 필터로 CLI 재조회. RECORD_TYPE에서 Credit과 Refund를 제외하고 다시 돌렸습니다.

$ aws ce get-cost-and-usage --region us-east-1 \
    --time-period Start=2026-08-01,End=2026-09-01 \
    --granularity MONTHLY --metrics UnblendedCost \
    --group-by Type=DIMENSION,Key=SERVICE \
    --filter '{"Not":{"Dimensions":{"Key":"RECORD_TYPE","Values":["Credit","Refund"]}}}'

소수점까지 일치했습니다. 에이전트는 처음부터 맞았습니다.

4단계 — 크레딧 총액 확인. 차이를 만든 크레딧이 실제로 얼마인지 RECORD_TYPE으로 8월을 묶어 확인했습니다.

$ aws ce get-cost-and-usage --region us-east-1 \
    --time-period Start=2026-08-01,End=2026-09-01 \
    --granularity MONTHLY --metrics UnblendedCost \
    --group-by Type=DIMENSION,Key=RECORD_TYPE

Usage $225.85 + Tax $1.73 = $227.58로 에이전트가 제시한 gross와 일치하고, 여기서 Credit $208.60을 빼면 $18.98로 8-1에서 CLI가 보여준 net과 일치합니다. 두 숫자의 관계가 산수로 닫혔습니다.

이 계정에는 8월에 $208.60의 프로모션 크레딧이 적용되고 있었습니다.

Cost Explorer는 크레딧을 음수 라인 아이템으로 기록하므로, 기본 조회(크레딧 포함)로 서비스별로 묶으면 크레딧이 적용된 서비스는 상쇄되어 $0으로 보입니다. RECORD_TYPE 조회로 확정할 수 있는 것은 계정 전체 크레딧 총액까지이고 서비스별 배분은 이 조회로 알 수 없지만, 정황은 분명합니다. gross에서 EC2-Compute $80.22, EKS $67.47, EC2-Other $16.77(합계 약 $164)이 net에서 모두 $0 근처로 내려갔으니 EKS·EC2 계열은 사실상 전액 상쇄된 것이고, Bedrock의 "Claude (Amazon Bedrock Edition)" $16.25는 net에 그대로 남았으니 크레딧이 거의 적용되지 않은 것으로 보입니다.

8-1에서 "EKS가 $0인 건 청구 반영 전이라서"라고 했던 추측은 틀렸고, "Bedrock이 비용의 대부분"이라는 해석도 순청구액 기준에서만 맞는 말이었습니다. 총사용 기준으로는 8월에도 EKS 인프라가 $160 이상 소비되고 있었습니다.

정리하면 두 숫자는 모두 진짜 데이터입니다.

CLI 기본값은 순비용(net, 실제 청구액) 이고, 에이전트가 보여준 것은 총사용 비용(gross, 크레딧 적용 전) 입니다. 그리고 에이전트는 이 사실을 Slack 게시물 각주에 "Credits/Refunds excluded"라고 처음부터 적어 두었습니다. 검증하는 사람이 그 각주를 읽지 않은 것입니다.

FinOps 관점에서 어느 쪽이 맞는가.

둘 다 맞고, 질문이 다릅니다. "이번 달 얼마를 내는가"는 net이고, "이 워크로드가 얼마를 소비하는가"는 gross입니다. 크레딧은 소진되거나 만료되는 것이라, 크레딧이 사라진 다음 달의 청구액을 예측하려면 gross를 봐야 합니다. 이 계정의 경우 net으로는 EKS가 비용의 0%이지만 gross로는 82.9%이고, 크레딧이 끝나는 순간 청구서는 후자의 모양이 됩니다. 에이전트가 gross를 기본으로 보여준 것은 비용 관리 도구로서는 오히려 옳은 선택이고, 그 대신 각주로 기준을 명시한 것입니다.

8-5. 결과 형태와 "권고 없음"의 해석

• 자연어 요약: 비용 상위 항목, 증감, 이상 여부를 문장으로 설명
• 표/차트: 서비스별·기간별 분해
• 권고 목록: rightsizing·유휴 리소스
• 리포트 파일: HTML/PDF/PPT 다운로드
• (Slack 연동 시) 결과를 채널로 게시

프리뷰 + 소규모 신규 워크로드 조합에서는 최적화 권고가 "권고 없음"으로 나올 수 있습니다. 이것은 오류가 아니라, Compute Optimizer가 권고를 만들려면 최근 14일 안에 최소 30시간의 CloudWatch 메트릭이 필요하고 분석에 최대 24시간이 더 걸리기 때문에, 신규 워크로드에서는 아직 조건이 충족되지 않았다는 정상적인 결과입니다. 권고가 비어 있을 때 "왜 비어 있는지"를 데이터 소스 상태(5장)로 되짚어 설명할 수 있어야 합니다.

9. Slack 전송 시 알아둘 점 

• 단방향입니다. 봇은 채널에 게시만 하고, Slack에서 멘션하거나 명령을 보내도 읽거나 응답하지 않습니다. 대화는 웹앱에서 하고, 결과물만 Slack으로 흘려보내는 구조입니다.
• 봇은 connection에 등록된 채널에만 게시할 수 있습니다. 다른 채널로 보내려면 그 채널로 connection을 추가해야 합니다.
• Integration은 계정 레벨(워크스페이스 인증), connection은 에이전트 레벨(어느 채널에 쏠지)의 2단계 구조입니다. 여러 에이전트가 같은 워크스페이스를 공유하되 채널은 나눌 수 있게 설계된 것입니다.

(해당 내용은 FinOps Agent가 프리뷰 상태였던 2026.09월 기준으로 작성되었습니다.)

10. 세 에이전트를 함께 운영할 때의 설계 원칙

FinOps Agent를 붙여보고 나서, 세 에이전트를 하나의 EKS에 함께 운영할 때 정리되는 원칙이 있습니다.

연동 방식이 곧 신뢰 경계입니다.

DevOps Agent는 클러스터 안(pods.eks.amazonaws.com), Security Agent는 앱 URL, FinOps Agent는 계정 비용 데이터(finops-agent.amazonaws.com)를 봅니다. 각 에이전트의 IAM 신뢰 주체와 접근 범위가 이 차이를 그대로 반영하므로, "이 에이전트가 무엇을 볼 수 있는가"를 설명할 때 연동 방식부터 말하면 됩니다.

FinOps Agent에는 EKS access 설정이 필요 없습니다.

대신 비용 할당 태그와 Cost Category가 클러스터 비용 격리의 전부입니다. 워커 노드는 aws:eks:cluster-name 활성화만으로 잡히지만, 컨트롤 플레인·LB·EBS는 사용자 태그가 필요하고, 노드그룹 태그는 인스턴스로 전파되지 않습니다. 태그 활성화는 12개월까지 backfill로 소급되지만 리소스에 태그가 없던 기간은 복구되지 않으므로, 태그 부착은 클러스터 생성 시점에 끝내야 합니다.

에이전트 자체의 비용을 FinOps 항목으로 잡아야 합니다.

이 계정에서 8월 비용의 대부분이 Bedrock 추론 비용이었듯, 에이전트 도입 후에는 "에이전트가 아끼는 돈"과 "에이전트가 쓰는 돈"을 같은 대시보드에서 봐야 합니다. FinOps Agent는 프리뷰 기간에는 추가 요금 없이 제공되지만, Bedrock 위에서 동작하는 만큼 GA 이후 과금이 시작되면 예외가 아닐 것입니다.

리전 제약은 프리뷰의 임시 조건입니다.

us-east-1 제약은 에이전트 배치 위치에만 영향을 주고, 분석 대상 범위에는 영향을 주지 않습니다. GA 이후 리전이 확장되더라도 계정 전역 데이터를 보는 구조 자체는 변하지 않을 것이므로, 지금 설계한 태그·역할 구조는 그대로 가져갈 수 있습니다.

에이전트의 숫자를 검증할 때는 산출 기준부터 맞춰야 합니다.

8장에서 CLI와 에이전트의 8월 총액이 12배 차이 났던 원인은 에이전트의 오류가 아니라 크레딧 포함 여부였습니다. 에이전트는 각주에 "UnblendedCost, Credits/Refunds excluded"라고 기준을 명시했고, 그 기준으로 CLI를 돌리자 소수점까지 일치했습니다. 크레딧이 있는 계정에서 순비용(net)과 총사용 비용(gross)은 다른 질문에 대한 답이며, 이 둘을 구분하지 않으면 정확한 응답을 오류로 오판하게 됩니다. 에이전트 응답을 Slack으로 자동 배포하기 전에 같은 질의를 CLI로 재현하는 검증 단계는 여전히 필요하지만, 그 검증은 에이전트가 적어둔 메트릭·기간·레코드 타입 조건을 그대로 따라야 의미가 있습니다. 검증이 틀리면 에이전트를 의심하기 전에 검증 조건을 먼저 의심해야 합니다.

11. 정리

• FinOps Agent는 프리뷰이며 us-east-1 콘솔 wizard로만 생성됩니다. 로컬 CLI는 아직 지원하지 않습니다.
• 비용 데이터는 계정 전역이라, 버지니아 에이전트로 서울 워크로드 비용을 그대로 분석할 수 있습니다. 실제 응답에서 서울 EKS의 EC2-Compute·EKS 비용이 상위 항목으로 정확히 잡혔습니다.
• 사전 준비의 핵심은 IAM이 아니라 데이터 소스 enrollment입니다. 이 계정은 Cost Optimization Hub만 CLI로 opt-in하면 됐습니다.
• 실제 질의해보면 에이전트가 MTD 함정을 스스로 잡아 일평균으로 환산(9월 $12.19/day vs 8월 $7.34/day, +66%)하는 등 단순 조회를 넘어선 분석을 보여줍니다.
• EKS 하나의 비용을 격리하려면 워커 노드는 aws:eks:cluster-name 활성화로, 컨트롤 플레인·LB·EBS는 사용자 태그로 잡고 Cost Category로 묶어야 합니다. 노드그룹 태그는 인스턴스로 전파되지 않으며, 활성화는 backfill로 소급되지만 리소스에 태그가 없던 기간은 복구되지 않습니다.
• 에이전트는 MTD 정규화, 범주 정의, Slack 배포 포맷 구성, 그리고 되물었을 때 호출 조건과 응답 원문을 제시하는 것까지 분석 파트너로서 기대 이상이었습니다.
• 에이전트와 CLI의 8월 총액이 12배 달랐던 원인은 크레딧 포함 여부였습니다. 에이전트는 총사용 비용(gross)을 각주와 함께 제시했고, CLI 기본값은 순비용(net)이었습니다. 크레딧이 있는 계정에서 이 둘은 다른 질문이며, 검증은 에이전트가 명시한 산출 기준을 그대로 따라야 합니다.

참고 자료

• What is AWS FinOps Agent (preview)?
• Creating an agent
• AWS FinOps Agent IAM setup guide
• Getting started with AWS FinOps Agent

본문의 CLI 출력과 비용 수치는 2026-09월 기준으로 실제 계정에서 조회한 값이며, 계정 ID와 역할 접미사 등 식별 정보는 마스킹했습니다. AWS FinOps Agent는 프리뷰 서비스로, 본문 내용은 GA 시점에 달라질 수 있습니다.

들어가며: 침투 테스트, 사람 대신 AI가 하면 얼마나 걸릴까

침투 테스트는 보안 전문가가 Burp Suite 같은 도구를 들고 수동으로 공격 시나리오를 짜는, 수일에서 수주가 걸리고 건당 수천만 원이 드는 작업이었습니다. AWS Security Agent는 이걸 AI에게 맡깁니다. 코드를 던져주면 정적으로 취약점을 찾고, 그중 실제로 뚫리는지 서버를 직접 공격해서 검증합니다.
 
궁금한 게 두 가지였습니다.
첫째, 실제로 얼마나 걸리고 얼마나 정확한가.
둘째, AWS Security Agent가 2026년 8월 현재 서울 리전(ap-northeast-2)을 지원하지 않는데, 그럼 서울 워크로드는 아예 쓸 수 없는 건가.
 
버지니아에 Agent Space를 만들고 서울 EKS 위의 테스트 앱을 대상으로 코드 리뷰와 침투 테스트를 직접 돌려봤습니다. 코드 리뷰는 약 50분, 침투 테스트는 약 2시간 50분 만에 끝났고, 6개 취약점이 실제 공격으로 실증됐습니다. 이 글은 그 검증 과정을 정리한 기록입니다.
 

1. AWS Security Agent란?

한 문장으로 정리하면, 보안 전문가가 하던 일을 AI가 대신 해주는 서비스입니다.
설계 문서를 검토하고, 코드에서 취약점을 찾고, 실제로 서버를 공격해서 그 취약점이 진짜 뚫리는지 확인하는 것까지 지금까지는 전문 인력이 며칠에서 몇 주씩 붙어야 했던 작업을, AI 에이전트가 자동으로 수행합니다.
re:Invent 2025에서 프리뷰로 처음 공개됐고, 2026년 3월 침투 테스트 기능이 GA되면서 정식 서비스가 됐습니다.
 
왜 이런 서비스가 필요한가부터 짚고 가면, 보통 보안 검증은 "개발이 다 끝난 뒤에" 별도 팀이 뒤늦게 들어와서 하는 경우가 많습니다. 그러다 보니 배포 직전에야 큰 취약점이 발견되고, 그때 가서 코드를 갈아엎느라 일정이 밀리는 일이 흔합니다. Security Agent는 이 검증을 설계 단계부터 배포 단계까지 전 구간에 걸쳐 계속 돌릴 수 있게 만들어서, "다 만들고 나서 검사"가 아니라 "만드는 중간중간 계속 검사"가 가능하게 하는 게 목적입니다. 흔히 말하는 "시프트 레프트(shift-left) 보안"을 AI로 실현한 서비스라고 볼 수 있습니다.
같은 "보안"이라는 키워드 때문에 GuardDuty와 자주 혼동되는데, 겹치는 부분이 거의 없습니다.
 

 
 
핵심 기능은 네 가지입니다.

• 침투 테스트 (Penetration Testing): 실제 운영 중이거나 배포 예정인 애플리케이션에 AI가 자동으로 공격 시나리오를 실행합니다. Command Injection, SQL Injection, XSS 같은 공격을 실제로 시도해보고, 정말로 뚫리는지까지 확인해줍니다. 이 글의 검증 대상이 바로 이 기능입니다.
• 코드 보안 리뷰 (Code Security Review): GitHub, GitLab, S3에 있는 소스 코드를 정적으로 분석해서 취약점을 찾아냅니다. 사람이 코드를 한 줄씩 읽어가며 하던 시큐어 코딩 리뷰를 AI가 대신합니다.
• 위협 모델링 (Threat Modeling): 아직 코드를 쓰기 전, 설계 문서만 가지고도 STRIDE 프레임워크(위협을 6가지 유형으로 분류하는 표준 방법론) 기준으로 어떤 위협이 있을 수 있는지 미리 짚어줍니다.
• 설계 보안 리뷰 (Design Security Review): 아키텍처 설계 문서를 검토해서, 코드를 쓰기도 전에 구조적인 보안 문제를 찾아냅니다.

즉 개발 라이프사이클을 "설계 → 코드 → 배포" 순서로 본다면, Security Agent는 그 세 단계 모두에 각각 대응하는 기능을 갖추고 있습니다. 실제로 이 기능들을 쓰려면 Agent Space라는 작업 공간을 먼저 만들어야 하는데, 코드 저장소·AWS 계정 리소스·대상 도메인 같은 것들을 연결해두는 컨테이너 개념입니다. 이후 코드 리뷰나 침투 테스트를 생성할 때는 이 Agent Space를 기준으로 실행됩니다.
 
기존에 보안 전문가가 Burp Suite 같은 도구로 수일에서 수주(건당 수천만 원)에 걸쳐 하던 수동 침투 테스트를, AI가 몇 시간 안에 대체하고 무료 체험까지 열어준 게 이 서비스가 주목받는 이유입니다. 다만 침투 테스트는 실제로 서버를 공격하는 행위라, 시작 전 대상 도메인 소유권을 반드시 검증합니다. 남의 서버를 공격하는 사고를 막기 위한 안전장치인데, 이 검증 과정에서 겪은 삽질은 뒤에서 다룹니다.
 
아키텍처: 서울 EKS + 버지니아 Security Agent

지원 리전 (2026-08 기준): us-east-1, us-west-2, eu-west-1, eu-central-1, ap-southeast-2, ap-northeast-1, ap-south-1, ap-southeast-1, sa-east-1
 
공식 문서에는 이렇게 설명되어 있습니다.

"AWS Security Agent is available in the following Regions ... It uses cross-region inference. In Asia Pacific (Mumbai), Asia Pacific (Singapore), and South America (São Paulo), AWS Security Agent uses global cross-region inference, which routes inference requests to any commercial AWS Region. In all other Regions, it uses geographic cross-region inference, which keeps data processing within specific geographic boundaries." — Resilience in AWS Security Agent

 
즉 Agent Space가 어느 지원 리전에 있든, 실제 분석 대상(URL·코드·계정 리소스)은 그 리전에 종속되지 않고 크로스 리전 추론 방식으로 처리됩니다. 이게 GuardDuty Investigation Agent와 갈리는 지점이기도 합니다. GuardDuty Investigation Agent는 GuardDuty detector라는 리전 종속 리소스를 대상으로 동작해서, Finding이 어느 detector(=어느 리전)에 있는지가 곧 접근 가능 여부를 결정합니다. 반면 Security Agent는 URL·소스 코드·AWS 계정 리소스를 직접 대상으로 삼기 때문에, 서울에 있는 리소스든 어디에 있든 접근 권한만 있으면 분석이 가능합니다.
 

실습: 전체 셋업 과정

1. Agent Space 생성 (버지니아)

aws securityagent create-agent-space \
  --name "seoul-eks-security-test" \
  --region us-east-1 --profile kiro

 
2. 코드 리뷰용 IAM Role 생성

aws iam create-role --role-name SecurityAgentCodeReviewRole \
  --assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"securityagent.amazonaws.com"},"Action":"sts:AssumeRole"}]}'

 
3. Agent Space에 Role + S3 연결

aws securityagent update-agent-space \
  --agent-space-id <AGENT_SPACE_ID> \
  --name "seoul-eks-security-test" \
  --aws-resources '{"iamRoles":["<CODE_REVIEW_ROLE_ARN>"],"s3Buckets":["<SOURCE_CODE_BUCKET_ARN>"]}' \
  --region us-east-1 --profile kiro

 
4. 테스트 대상 취약 코드
의도적으로 취약점을 심어둔 Flask 앱 일부입니다. 코드 리뷰와 침투 테스트 모두 이 코드를 대상으로 진행했습니다.

# Command Injection 취약 지점
@app.route("/ping")
def ping():
    host = request.args.get("host")
    result = os.popen(f"ping -c 1 {host}").read()  # 사용자 입력을 그대로 셸에 전달
    return result

# SQL Injection 취약 지점
@app.route("/user")
def get_user():
    user_id = request.args.get("id")
    query = f"SELECT * FROM users WHERE id = {user_id}"  # 파라미터 바인딩 없이 문자열 결합
    return db.execute(query).fetchone()

# Path Traversal 취약 지점
@app.route("/file")
def read_file():
    filename = request.args.get("name")
    with open(filename) as f:  # 경로 검증 없이 그대로 open
        return f.read()

셋 다 "사용자 입력을 검증 없이 그대로 실행/조회/파일 접근에 쓰는" 전형적인 취약 패턴입니다. 앞서 본 root 응답은 이 중 첫 번째 코드가 뚫린 결과입니다.
 
5. 코드 리뷰 생성 및 실행

aws securityagent create-code-review \
  --title "Seoul-EKS-Vulnerable-App-Review" \
  --agent-space-id <AGENT_SPACE_ID> \
  --assets '{"sourceCode":[{"s3Location":"s3://<BUCKET>/source-code/vulnerable-code.zip"}]}' \
  --service-role <CODE_REVIEW_ROLE_ARN> \
  --region us-east-1 --profile kiro

aws securityagent start-code-review-job \
  --agent-space-id <AGENT_SPACE_ID> \
  --code-review-id <CODE_REVIEW_ID> \
  --region us-east-1 --profile kiro

 
6. 서울 EKS에 침투 테스트 대상 앱 배포

eksctl create cluster --name security-test-cluster \
  --region ap-northeast-2 --nodegroup-name test-nodes \
  --node-type t3.medium --nodes 2 --managed

kubectl apply -f vulnerable-web-app.yaml
# LoadBalancer URL 발급 확인

 
7. 대상 도메인 소유권 검증
검증 방식은 두 가지가 있는데, 실제로 붙여보니 결과가 갈렸습니다.
방식 요구사항 결과

 
커스텀 도메인 + DNS_TXT 조합으로 진행했습니다.

# 타겟 도메인 등록
aws securityagent create-target-domain \
  --target-domain-name "test.seungly.cloud" \
  --verification-method DNS_TXT \
  --region us-east-1 --profile kiro

# Route53에 TXT 레코드 추가
aws route53 change-resource-record-sets --hosted-zone-id <HOSTED_ZONE_ID> \
  --change-batch '{"Changes":[{"Action":"UPSERT","ResourceRecordSet":{
    "Name":"_aws_securityagent-challenge.test.seungly.cloud.",
    "Type":"TXT","TTL":60,
    "ResourceRecords":[{"Value":"\"aws-securityagent-domain-verification=<TOKEN>\""}]
  }}]}'

# 도메인 검증
aws securityagent verify-target-domain \
  --target-domain-id <TARGET_DOMAIN_ID> \
  --region us-east-1 --profile kiro

 
검증이 성공한 것을 콘솔에서도 확인할 수 있습니다.

 
 
8. Agent Space에 도메인 연결 + 침투 테스트 실행

aws securityagent update-agent-space \
  --agent-space-id  \
  --name "seoul-eks-security-test" \
  --target-domain-ids '[""]' \
  --region us-east-1 --profile kiro

aws securityagent create-pentest \
  --title "Seoul-EKS-Pentest" \
  --agent-space-id  \
  --assets '{"endpoints":[{"uri":"http://test.seungly.cloud"}],"sourceCode":[{"s3Location":"s3:///source-code/vulnerable-code.zip"}]}' \
  --service-role  \
  --region us-east-1 --profile kiro

aws securityagent start-pentest-job \
  --agent-space-id  \
  --pentest-id  \
  --region us-east-1 --profile kiro

결과: 코드 리뷰 + 침투 테스트

코드 리뷰 (정적 분석) — 약 50분 소요
17개 취약점이 나왔습니다.
 
심각도 건수 예시

AI는 항목마다 즉시 조치(shell 명령 제거, parameterized query, debug 끄기, 인증 추가) / 단기 조치(시크릿 외부화, SSRF allowlist, DB 권한 분리) / 중기 조치(감사 로그, CSRF, TLS, bcrypt, CSP 헤더)로 나눈 대응 우선순위까지 함께 제시했습니다.

 
침투 테스트 (동적 실증) — 약 2시간 50분 소요
17개 중 6개가 실제 공격으로 실증됐습니다.
 
심각도 유형 상태 AI가 실제로 한 것

 
가장 심각했던 Critical 등급 Command Injection이 어떻게 뚫렸는지 조금 더 들여다보면, 서버 안에서는 이런 코드가 돌고 있었습니다.

result = os.popen(f"ping -c 1 {host}").read()

 
host 자리에 사용자가 보낸 값이 그대로 들어가서, 최종적으로 서버가 실행하는 명령어 문자열이 만들어집니다. 정상적인 경우라면 host=8.8.8.8을 보냈을 때 서버 안에서 실제로 실행되는 명령어는 이렇게 완성됩니다.

ping -c 1 8.8.8.8

 
문제는 셸(리눅스 명령어를 실행하는 프로그램)에서 세미콜론(;)은 "여기까지 한 문장, 이어서 다음 문장 실행"이라는 뜻으로 해석된다는 점입니다. 예를 들어 사람이 터미널에 echo hi; echo bye라고 치면 hi와 bye가 순서대로 둘 다 출력되는 것과 같은 원리입니다.
AI는 host 값을 검증 없이 그대로 명령어에 끼워 넣는 이 코드를 찾아내고, host 자리에 ;id를 넣어봤습니다. 그러면 서버 안에서 실제로 실행되는 명령어는 이렇게 바뀝니다.

ping -c 1 ;id

셸 입장에서는 "ping -c 1까지 한 문장, 그 다음 id라는 새로운 문장"으로 읽힙니다. 즉 원래 의도한 ping 명령어 뒤에 전혀 다른 명령어(id — 지금 이 프로그램이 어떤 사용자 권한으로 실행되고 있는지 확인하는 명령어)를 몰래 끼워 넣어 실행시킨 것이고, 그 결과가 표에 있는 uid=0(root) 응답입니다. 이 애플리케이션 프로세스가 최고 권한인 root로 돌아가고 있었다는 뜻으로, 이 취약점 하나로 서버를 완전히 장악할 수 있는 수준의 공격이 가능했다는 걸 의미합니다.
 
나머지 10건은 배포 코드와 정적 분석 대상 소스 코드 간 차이로 인한 false positive, 1건은 미확인으로 분류됐습니다. 코드 리뷰는 S3에 올려둔 소스 코드를 정적으로 분석한 것이고, 침투 테스트는 실제로 서울 EKS에 배포되어 돌아가고 있는 앱을 공격한 것이라, 두 대상 사이에 배포 시점 차이나 설정 차이가 있으면 정적 분석에서만 잡히고 실제로는 뚫리지 않는 항목이 생깁니다. 정적 분석이 짚어낸 걸 동적 검증이 다시 한번 걸러준 셈이라, 두 기능을 함께 쓰는 게 오탐을 줄이는 데 확실히 도움이 됐습니다.

침투 테스트 진행한 내용을 보고서 생성이 가능합니다. 

트러블슈팅: 실제로 겪은 문제들

문제  HTTP_ROUTE 도메인 검증이 계속 실패함

증상: ELB 기본 도메인으로 HTTP_ROUTE 방식 검증을 시도했는데 계속 실패했습니다.
원인: HTTP_ROUTE는 유효한 SSL 인증서가 붙은 HTTPS가 전제 조건인데, self-signed 인증서로는 통과가 안 되고 ELB 기본 도메인에는 애초에 ACM 인증서 발급이 불가능했습니다.
해결: 커스텀 도메인을 구매해 Route53에 연결하고, DNS_TXT 방식으로 전환했습니다.
 
 

정리: 도입 순서

1단계 Agent Space 생성 (지원 리전 중 택1)

2단계 코드 리뷰용 IAM Role + 소스코드 S3 연결

3단계 코드 리뷰 실행 → 정적 취약점 목록 확보

4단계 대상 도메인 등록 + DNS_TXT 검증

5단계 침투 테스트 실행 → 정적 결과를 동적으로 실증
 

결론

"서울 리전 미지원"이라는 제약에서 출발했지만, Agent Space가 어느 리전에 있든 URL과 코드를 대상으로 동작하는 구조 덕분에 서울 EKS를 대상으로 코드 리뷰와 침투 테스트 모두 성공적으로 수행할 수 있었습니다.
 
한국 고객사 입장에서 정리하면, AWS Security Agent는 서울 리전 GA를 기다리지 않고 지금 바로 도입 검토가 가능합니다. 다만 이번 검증은 처음부터 뚫리도록 설계한 테스트 앱을 대상으로 했다는 점은 감안해야 합니다. 실제 운영 중인 애플리케이션에 적용할 때는 침투 테스트가 실 트래픽·DB에 영향을 줄 수 있으니 스테이징 환경에서 먼저 검증하는 절차, 그리고 대상 도메인·리소스 범위를 명확히 제한하는 IAM 정책 설계가 함께 필요합니다.
 
 
참고 자료

• AWS Security Agent 공식 페이지
• GA 발표 블로그 - AWS Security Agent on-demand penetration testing is now generally available
• 프리뷰 발표 블로그 - New AWS Security Agent secures applications proactively from design to deployment
• Create a penetration test - AWS Security Agent 공식 문서
• Resilience in AWS Security Agent (크로스 리전 추론 방식)
• Enable an application domain for penetration testing

※ 본문의 계정 ID, IAM Role ARN 등 식별자는 공개 포스팅 기준으로 일부 마스킹했습니다. 실제 운영 환경 적용 시에는 IAM 권한 범위와 네트워크 노출 범위를 별도로 검토해야 합니다.
 

들어가며: 서울에 없는 서비스를, 서울 워크로드에 어떻게 붙일까

AWS DevOps Agent는 2026년 8월 현재 서울 리전을 지원하지 않습니다. 워크로드를 해외 리전으로 옮길 수는 없으니, 질문은 하나로 좁혀집니다 [서울 EKS를, 서울에 없는 서비스에 어떻게 연결할 것인가]

이를 해결하기 위해서 버지니아에 Agent Space를 만들고 크로스 리전으로 서울 EKS의 관측 데이터를 읽어오도록 구성한 다음, 실제로 장애를 발생시켜 에이전트가 원인을 찾아내고 Slack으로 결과를 전달하는 과정까지 확인했습니다. kubectl describe와 로그를 뒤져가며 원인을 찾는 데 한두 시간씩 걸리던 조사를, 이 구조에서는 2~3분 만에 끝냈습니다.

1. AWS DevOps Agent란?

DevOps Agent는 Amazon Bedrock 위에서 동작하는 완전관리형 자율 AI 온콜 엔지니어입니다. 

핵심은 에이전트가 조사를 시작하기 전에 애플리케이션 토폴로지(리소스 관계도)를 스스로 구축한다는 점입니다. EKS 환경이라면 어떤 Pod가 어떤 Deployment에 속하는지, 어떤 Service가 트래픽을 라우팅하는지, 어떤 ConfigMap이 설정을 제공하는지까지 미리 파악해두고, 그 관계 위에서 인시던트를 조사합니다. 그래서 "이 Pod가 왜 죽었지?"에서 끝나지 않고 "이 Pod가 죽으면 어떤 Service, 어떤 다운스트림까지 영향을 받는지"까지 짚어낼 수 있습니다.

이 토폴로지는 OpenTelemetry 데이터와 서비스 간 통신 패턴을 지속적으로 분석해서 갱신되기 때문에, 사람이 구성도를 직접 그리거나 유지보수할 필요가 없습니다.

한 문장으로 요약하면, 24시간 항상 켜져 있는 자율적 AI 온콜 엔지니어입니다. 알림이 들어오면 사람 대신 메트릭·로그·배포 이력·코드를 상관 분석하고, 근본 원인을 찾아 복구 방법까지 제안합니다.

핵심 기능은 세 가지로 요약됩니다.

자율적 인시던트 대응 : 알람 발생 시 자동으로 RCA(근본 원인 분석) 수행

사전 예방적 인시던트 예방 : 과거 패턴을 학습해 "이거 또 터질 것 같다"고 사전 알림

온디맨드 SRE 채팅 : "CPU 높은 서버 5개 보여줘" 같은 자연어 질의

다만 중요한 건 어디까지 자동인가입니다.

에이전트는 문제를 자동으로 감지하고 원인을 분석하며, 완화 방안을 "제안"하고, 크로스 리전으로 EKS를 read-only로 조회해서 Slack으로 결과까지 보내줍니다. 반면 kubectl apply 같은 변경을 직접 실행하거나, 스스로 낸 제안을 자동으로 "실행"하거나, 리소스를 생성·수정·삭제하거나, 사람 없이 롤백하는 일은 하지 않습니다.

"제안까지만 자동, 실행은 사람이 승인"이 설계 원칙입니다. 프로덕션에서 AI가 멋대로 설정을 바꾸면 더 큰 장애로 이어질 수 있기 때문입니다.

2. 아키텍처: 서울 EKS + 버지니아 DevOps Agent

한국 사용자의 워크로드는 서울 리전에 있지만, DevOps Agent는 아직 서울을 지원하지 않습니다(2026.08 기준). 그래서 버지니아에 Agent Space를 만들고 크로스 리전으로 연결하는 구조를 택했습니다.

지원 리전 (2026.08 기준): us-east-1, us-west-2, eu-central-1, eu-west-1, ap-southeast-2, ap-northeast-1

3. 실습: 전체 셋업 과정

3-1. 서울 리전에 EKS 클러스터 생성

VPC 준비

• Private subnet 2개(AZ 분리) + Public subnet 2개
• NAT Gateway 또는 NAT 인스턴스(Private → 인터넷 아웃바운드)

EKS 클러스터 생성

콘솔 → EKS(ap-northeast-2) → [Create cluster]

항목 값 비고

노드 그룹용 IAM 역할

Trust Policy:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "ec2.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}

연결할 정책 4개:

AmazonEKSWorkerNodePolicy          ← Full 버전 필수 (Minimal 아님!)
AmazonEKS_CNI_Policy
AmazonEC2ContainerRegistryReadOnly
CloudWatchAgentServerPolicy         ← Container Insights용

노드 그룹 추가

항목 값

노드가 Ready 상태로 올라오면 성공입니다.

$ kubectl get nodes
NAME                                              STATUS   ROLES    AGE   VERSION
ip-10-0-131-49.ap-northeast-2.compute.internal    Ready    <none>   5m    v1.36.2
ip-10-0-144-118.ap-northeast-2.compute.internal   Ready    <none>   5m    v1.36.2

3-2. 테스트 워크로드 배포

정상 워크로드(nginx)부터 올립니다.

kubectl create namespace demo
kubectl -n demo create deployment nginx-test --image=nginx:latest --replicas=3

그리고 OOMKilled를 의도적으로 유발하는 워크로드를 하나 추가합니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: memory-hog
  namespace: demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: memory-hog
  template:
    metadata:
      labels:
        app: memory-hog
    spec:
      containers:
      - name: stress
        image: polinux/stress
        command: ["stress"]
        args: ["--vm", "1", "--vm-bytes", "256M", "--vm-hang", "1"]
        resources:
          limits:
            memory: "128Mi"
          requests:
            memory: "64Mi"

128Mi 제한인데 256M을 쓰도록 만들었으니, OOMKilled → CrashLoopBackOff가 무한 반복됩니다.

$ kubectl -n demo get pods
NAME                          READY   STATUS             RESTARTS      AGE
memory-hog-786f76f66f-wv7d8   0/1     CrashLoopBackOff   4 (18s ago)   3m
nginx-test-d677b4b5b-btxkg    1/1     Running            0             5m
nginx-test-d677b4b5b-lsmwc    1/1     Running            0             5m
nginx-test-d677b4b5b-tjx6k    1/1     Running            0             5m

3-3. Container Insights 활성화

aws eks create-addon \
  --cluster-name devops-agent-test \
  --addon-name amazon-cloudwatch-observability \
  --region ap-northeast-2

활성화 후 5분쯤 지나면 CloudWatch에 1,200개 이상의 EKS 메트릭이 쌓이기 시작합니다.

3-4. CloudWatch 알람 생성

aws cloudwatch put-metric-alarm \
  --alarm-name "EKS-Pod-CrashLoopBackOff" \
  --alarm-description "memory-hog Pod 재시작 감지 시 알람" \
  --namespace "ContainerInsights" \
  --metric-name "pod_number_of_container_restarts" \
  --dimensions Name=PodName,Value=memory-hog \
               Name=ClusterName,Value=devops-agent-test \
               Name=Namespace,Value=demo \
  --statistic Maximum \
  --period 60 \
  --threshold 0 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 1 \
  --treat-missing-data notBreaching \
  --region ap-northeast-2

memory-hog가 재시작될 때마다 알람 상태가 ALARM으로 전환됩니다.

3-5. 버지니아에 Agent Space 생성

1. AWS 콘솔 → 리전을 us-east-1로 전환 → DevOps Agent
2. [Create Agent Space] 클릭
3. 아래와 같이 설정

생성 후 [웹앱 실행] → "IAM을 통해 시작"으로 접속이 되는지 확인합니다. 

3-6. Slack 연동

1. AWS 콘솔(버지니아) → DevOps Agent → Agent Space → 기능제공자 탭에서 Slack 연결

2. 커뮤니케이션 섹션 → 통합 추가 → Slack

3. Devops agent를 slack 채널에 연결

3-7. EKS Access Entry에 DevOps Agent 역할 등록

마지막으로, DevOps Agent가 서울 EKS에 kubectl(read-only)을 실행할 수 있도록 권한을 부여합니다.

1. 기능 탭 → 클라우드 → Primary Source → [Edit] → Role ARN 확인
   • 예: arn:aws:iam::12345678900:role/service-role/DevOpsAgentRole-AgentSpace
2. 서울 콘솔 → EKS → devops-agent-test → 액세스 탭
3. [IAM 액세스 항목 생성]
   • IAM 보안 주체: 위 Role ARN
   • 정책: AmazonAIOpsAssistantPolicy
   • 범위: 클러스터(전체)

4. 실제 조사 결과

정상 워크로드 확인

웹앱 채팅에 다음과 같이 물어봤습니다.

"devops-agent-test 클러스터의 demo 네임스페이스에 있는 Pod 상태를 보여줘"

에이전트 응답

인시던트 조사 (수동 트리거)

"demo 네임스페이스의 memory-hog Pod가 반복적으로 재시작되는 원인을 조사해줘"

약 2분 30초 만에 다음과 같은 순서로 조사가 진행됐습니다.

단계 수행 내용

에이전트 분석 요약

이렇게 자동으로 탐지를 시작합니다

조사 결과를 한눈에 볼 수 있습니다.

근본 원인 분석도 진행합니다

문제를 해결하기 위한 완화 계획도 제공합니다

알람 기반 조사 + Slack 알림

CloudWatch 알람이 ALARM 상태가 되면 DevOps Agent 웹앱의 인시던트 대응 대시보드에 나타납니다. [조사 시작]을 누르면 에이전트가 자동으로 조사를 수행하고, Slack으로 실시간 알림을 보냅니다.

이번 테스트에서는 [조사 시작] 버튼을 수동으로 눌렀지만, 프로덕션에서는 웹후크나 PagerDuty·Datadog 같은 네이티브 통합으로 이 단계까지 자동화할 수 있습니다.

[테스트]     알람 발생 → 사람이 [조사 시작] 클릭 → 조사 → Slack
[프로덕션]   알람 발생 → 웹후크 자동 트리거      → 조사 → Slack

5. 비용

리소스 비용

DevOps Agent는 월 정액이 아니라 "에이전트가 일한 시간만큼" 과금되는 구조입니다.

시스템이 안정적이면 비용도 적게 들고, 장애가 잦으면 그만큼 더 쓰게 됩니다.

6. 트러블슈팅: 실제로 겪은 문제들

문제 1. Container Insights 메트릭이 안 쌓임

증상: 애드온 설치 후에도 CloudWatch에 ContainerInsights 네임스페이스가 보이지 않았습니다.

원인: 노드 IAM 역할에 CloudWatchAgentServerPolicy가 빠져 있어서 CloudWatch Agent가 메트릭을 전송하지 못했습니다.

해결

aws iam attach-role-policy --role-name EKSNodeGroupRole \
  --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
kubectl -n amazon-cloudwatch rollout restart daemonset cloudwatch-agent

문제 2. CloudWatch 알람이 ALARM으로 안 바뀜

증상: memory-hog가 OOMKilled를 반복하고 있는데 알람은 계속 OK 상태였습니다.

원인: CrashLoopBackOff의 백오프 간격이 점점 길어지면서, 분당 재시작 횟수가 0으로 잡히는 순간이 생깁니다.

해결: kubectl rollout restart deployment memory-hog로 강제 재배포하면 즉시 재시작이 발생해 알람이 트리거됩니다.

7. 정리: 도입 순서

1단계  Agent Space 생성 + AWS 계정 연결        
2단계  EKS Access Entry 등록                    
3단계  최근 인시던트를 수동 조사 → 결과 확인    
4단계  Slack 연동 → 알림 흐름 확인              
5단계  Container Insights + CloudWatch 알람     → 자동 트리거 연결

8. 결론

Devops Agent는 온콜 피로도를 실질적으로 줄여주는 도구입니다. 사람이면 한두 시간 걸릴 RCA를 2분 만에 끝내고, 한국어 응답을 지원해 Slack 연동도 바로 됩니다. 크로스 리전 구조라 서울 EKS를 조회하는 데도 문제가 없고, 초 단위 과금이라 부담 없이 시작할 수 있습니다. 다만 아직 서울리전은 지원하고 있지 않아서 EKS는 서울리전에 위치하고 Devops Agent는 버지니아리전에 있다는 가정으로 진행해 보았습니다. 지금까지 공유한 내용처럼 효과적으로 활용하여 고객에게 안정적인 서비스를 제공 하는데 도움이 되었으면 좋겠습니다.

참고 자료

• AWS DevOps Agent 공식 페이지
• GA 발표 블로그 (2026.03)
• AWS EKS access setup (DevOps Agent)
• Container Insights EKS Add-on
• Kiro/Claude Code MCP 연동 (re:Post)
• 프로덕션 배포 모범 사례
• Building knowledge graphs for EKS using DevOps Agent