서론

최근 AWS Summit 2026에 참가하고 왔습니다.

그곳에서 CloudShell 상에서 Kiro CLI를 사용하여, 실제로 발생하고 있는 장애를 특정하여 해소하는 등의 수법이 소개되었습니다.

개인적으로 CloudShell에서 간편하게 Kiro CLI를 호출할 수 있고, 이를 통해 실환경에 대한 상호작용이 가능하다는 가벼움이 매우 매력적으로 느껴져서 바로 제 환경에서도 테스트해 보았습니다!

또한, 후반부에서 다루겠지만, Kiro CLI는 권한만 있다면 리소스의 생성부터 삭제까지 실시할 수 있습니다. 따라서 Kiro CLI 이용 시의 IAM 권한에 대해서도 고민할 필요가 있어 보입니다. 최소 권한의 예시에 대해서도 언급하고자 합니다.

이 기사에서 알 수 있는 것

• CloudShell에서 Kiro CLI를 호출하는 절차
• 실환경 내에서의 액션 (본 기사에서는 장애 특정 사례를 예로 들고 있습니다)
• Kiro CLI를 이용할 때의 IAM 권한 설계
• IAM과 Steering, 각각의 역할 분담에 대한 사고방식

CloudShell에서 Kiro CLI 호출하기

매우 간단하며, 다음과 같이 실시할 수 있습니다.

# kiro-cli

로그인 정보 입력하기

위 명령어를 입력한 후, 이용할 계정 정보를 요구받습니다.

Organization에서 관리되는 IAM 유저가 있다면 그것을 이용하거나, 혹은 아래의 계정으로도 이용이 가능하다고 합니다.

In your browser, choose the organization or system through which you will authenticate: Google, GitHub, Builder ID, Your organization — including AWS GovCloud (US)

개인적으로는 Builder ID로도 가능하다는 점이 기쁘네요.

기본적으로는 무료로 생성한 계정으로 이용할 수 있으므로, 간편하게 테스트해 볼 수 있을 것 같습니다.

⚠️ 크레딧 양은 무료 범위인 50 크레딧입니다. 또한 모델은 Claude Sonnet 4.5 정도가 되는 것 같습니다. 실제로 이용하실 때는 아래의 공식 정보를 확인해 주세요.

우선 검증 환경을 생성시키기

이번에는 특정 구성의 장애에 대해 조사를 실시하겠습니다.

이하는 간이 구성을 작성한 것입니다.

• ALB - 타겟 그룹 (Target Group) - 복수의 EC2 - RDS 구성
• 멀티 AZ (Multi-AZ) 구성

장애 일으키기

일부러 서버에 접속할 수 없도록 설정을 변경합니다.

이번에는 EC2에 설정된 보안 그룹 (Security Group)의 HTTP 허용을 삭제하여, 타겟 그룹의 헬스 체크 (Health Check)가 Unhealthy가 되도록 합니다.

조사 의뢰

그럼 Kiro CLI를 통해 장애에 대해 물어보겠습니다.

먼저 어떤 EC2에서 발생하고 있는지 확인해 줍니다.

무사히 원인을 특정하였고, 그 후에 자동 복구까지 진행해 주었습니다.

참고로 이번 데모에서 Kiro가 수행한 조사는 EC2의 상태, 타겟 그룹의 헬스, 보안 그룹의 규칙과 같은 Describe 계열 (구성 확인)이 중심이었습니다. 로그 본체를 읽는 단계까지는 들어가지 않았습니다. 이 점은 후반부의 권한 설계와 관련이 있으므로 머릿속에 담아두시기 바랍니다.

조사 리포트

조사 후에 "리포트로 정리해 줘"라고 지시하여, 실시한 내용을 정리하게 했습니다.

통신 장애 조사 리포트
1. EC2 인스턴스 상태 확인
(3대 모두 running. OS·하드웨어 레벨 문제 없음)
...

편리함 때문에 따르는 위험성

실환경의 생성부터 조사까지 순식간에 수행할 수 있는 것은 매우 편리했습니다. 숙련자라면 한눈에 판별할 수 있는 내용이라도, AWS의 지식이나 운영 경험이 없는 현장에서는 상당히 유효하지 않을까 느꼈습니다. 실제로 서밋에서도 창구에 문의하지 않고 현장에서 즉시 판단·대응할 수 있도록 하려는 취지로 소개되었습니다.

하지만 AI에게 조작을 시키는 데 있어서 확실히 고민해야 할 것이 있습니다.

그것은 바로 AI에게 부여할 권한의 범위입니다.

CloudShell 상에서 Kiro CLI가 실행하는 권한은 현재 로그인 중인 IAM 유저·역할 (Role)의 권한 범위에 의존합니다.

따라서 admin 권한으로 무분별하게 실행하면, 불필요한 리소스의 생성이나 의도하지 않은 리소스의 삭제도 발생할 수 있다는 것을 의미합니다.

실제로 앞선 데모에서 Kiro는 보안 그룹 (Security Group)을 재작성하여 자동 복구까지 수행했습니다. 이는 엄연한 **변경 작업 (Modification operation)**입니다. 데모로서는 화려하고 이해하기 쉽지만, 뒤집어 생각하면 "넓은 권한을 부여했기 때문에 AI의 판단에 따라 리소스가 변경된 것"입니다. 여기서부터는 이러한 위험성을 바탕으로, 장애 조사를 안전하게 수행하기 위한 권한 설정을 고민해 보겠습니다.

IAM을 통한 제어

무엇을 하게 할 것인가

장애 조사 (RCA: Root Cause Analysis, 근본 원인 분석)는 리소스의 구성이나 상태, CloudWatch Logs · 메트릭 (Metrics) · CloudTrail 등을 횡단하여 읽고, 원인까지 거슬러 올라가는 작업입니다. 리소스를 변경할 필요는 없습니다. 즉, 부여하는 권한은 읽기 권한 (Read-only permission)이 중심이 됩니다.

여기서 읽기 역할 (Read-only role)의 토대를 어떻게 선택하느냐에 따라 세 가지 선택지가 있습니다.

• 기본 관리 정책 (Managed Policy) — ViewOnlyAccess와 같이 List / Describe 중심. 리소스의 존재나 구성은 볼 수 있지만, 로그 본체 (logs:GetLogEvents 등)를 읽을 수 없기 때문에 조사에는 부족합니다.
• 풀 커스텀 허용 목록 (Full custom allow list) — 필요한 Describe / Get을 직접 나열하는 방식. 최소 권한 원칙에는 부합하지만, RCA는 "어떤 서비스가 원인인지 사전에 알 수 없기" 때문에, 막상 상황이 닥쳤을 때 권한이 부족한 사고가 발생합니다.
• ReadOnlyAccess — 읽기 액션 (Action)을 포괄적으로 허용하는 관리 정책. 구조상 변경 계열의 액션을 일절 포함하지 않습니다.

RCA에서는 조사 대상을 사전에 좁힐 수 없으므로 (어떤 리소스에 대한 권한이 필요한지 파악하기 어렵기 때문에), 읽기를 포괄하는 ReadOnlyAccess를 토대로 삼습니다. 변경 계열을 포함하지 않으므로, "환경 전체를 변경시키지 않는다"라는 요구사항은 이것만으로도 충족할 수 있습니다.

추가로 명시적인 Deny를 작성하기

ReadOnlyAccess가 지키는 것은 무결성 (Integrity, 멋대로 바꾸지 못하게 함) 뿐입니다. **기밀성 (Confidentiality, 데이터를 읽어낼 수 있음)**은 지키지 못합니다.

예를 들어 s3:GetObject나 dynamodb:GetItem과 같이 "내용을 읽는" 액션이 읽기 권한에 포함되어 있기 때문에, 기밀 정보가 읽힐 수 있으며 경우에 따라서는 그 자체로 인시던트 (Incident)로 이어질 수 있습니다.

RCA에 필요한 것은 조작 상태나 텔레메트리 (Telemetry, 로그 · 메트릭 · 이벤트)이지, 업무 데이터 그 자체가 아닙니다. 그리고 업무 데이터 본체에는 개인정보나 민감 정보가 포함될 수 있으므로, 조사라는 명목으로 이를 읽을 수 있는 상태로 두는 것은 최소 권한 원칙에 어긋납니다.

따라서 RCA에 불필요하면서 기밀성 (Confidentiality)을 노출하기만 하는 읽기 권한을, 명시적인 Deny로 제외합니다. 명시적 Deny는 Allow에 항상 우선하므로, ReadOnlyAccess가 가지고 있는 이러한 액션들을 확실하게 상쇄할 수 있습니다.

차단 대상을 두 계통으로 나누어 생각하면 정리하기 쉽습니다.

• 데이터 계열 — 데이터 스토어의 내용을 추출할 수 있는 액션. S3의 오브젝트 본체, DynamoDB의 아이템 가져오기 · 쿼리 (Query) · 스캔 (Scan), SQS의 메시지 수신, Kinesis의 레코드 가져오기, RDS Data API의 SQL 실행. 이것들이 정보 유출의 핵심입니다.
• 시크릿 계열 — 시크릿 그 자체를 가져오는 액션. Secrets Manager의 값 가져오기, SSM Parameter (SecureString 포함) 가져오기.

이하는 어디까지나 참고용이지만, 이미지로 표현하자면 다음과 같은 Deny를 추가하는 형태입니다.

{
"Version": "2012-10-17",
"Statement": [
...

이 권한을 CloudShell의 Kiro에 어떻게 사용하게 할 것인가

여기서 한 가지 문제가 있습니다. 서두에 썼듯이, CloudShell은 로그인 중인 콘솔 ID의 권한으로 동작하기 때문에, admin으로 로그인해 있다면 위의 Deny 정책을 가진 "조사용 역할"을 준비하는 것만으로는 의미가 없습니다.

따라서 ~/.aws/config에 조사용 역할을 AssumeRole 하는 프로파일 (Profile)을 정의하고, Kiro가 해당 프로파일을 사용하도록 하는 방식을 취합니다.

[profile kiro-readonly]
role_arn = arn:aws:iam::<ACCOUNT_ID>:role/kiro-readonly
source_profile = default
...

다만 주의할 점은, CloudShell의 기본 권한은 어디까지나 콘솔 ID(즉, 경우에 따라서는 admin) 상태라는 것입니다. 프로파일 지정은 어디까지나 운영상의 전환일 뿐이며, 엄격한 경계를 설정하려면 애초에 이 조사용 역할(Role)만 가진 전용 IAM Principal로 작업하는 것(전용 사용자, 혹은 EC2 인스턴스 프로파일이나 SSO의 권한 세트(Permission Set)를 기점으로 하는 방식)이 확실합니다. '가벼운 CloudShell'과 '엄격한 경계'는 트레이드오프(Trade-off) 관계이므로, 용도에 따라 선택해야 합니다.

조사와 변경을 분리하기

눈치가 빠른 분이라면, "그렇다면 첫 번째 데모와 같은 자동 복구는 이 읽기 전용 역할(Read-only Role)로는 불가능한 것 아닌가?"라고 깨달았을 것입니다. 맞습니다. 그리고 그것이 의도한 바입니다.

조사(읽기)와 변경을 동일한 강력한 권한에 공존시키기 때문에 위험한 것이므로, 평소에는 읽기 전용으로 조사하게 하고, 변경이 필요해지면 명시적으로 승인하거나 변경용 역할(Role)로 전환하는 방식으로 분리합니다. 데모의 "조사하고 마음대로 고친다"를 "조사 → 사람이 확인 → 고친다"로 나누는 이미지입니다. 읽기 전용 역할로 원인까지 특정하고, 수정 단계에서 게이트(Gate)를 하나 두는 운영 방식이 현실적입니다.

Steering을 통한 제어

마지막으로 Steering을 통한 제어에 대해서도 언급하겠습니다.

Steering에서는 IAM과 같은 강제력을 가진 제어는 할 수 없지만, AI의 행동을 미리 정해둘 수는 있습니다. 규칙을 명시해 둠으로써 의도하지 않은 리소스 생성이나 delete 계열의 동작을 자제시키는 등의 설정이 가능합니다.

예를 들어, 다음과 같이 작성할 수 있을 것입니다.

① AWS API를 사용할 때, Create / Delete / Update 실행을 무단으로 수행하지 말 것.
② 기본적으로는 읽기 계열의 API 조작으로 실시할 것. 도저히 작업을 계속할 수 없는 경우에는 반드시 승인을 얻을 것.
③ 망설여질 때는 반드시 확인을 받을 것.

다만 반복해서 말씀드리지만, Steering은 LLM이 무시할 수 있으므로 이것 자체를 방어의 주축으로 삼을 수는 없습니다. 어디까지나 "불필요하거나 위험한 조작을 스스로 멈추게 하는 보조" 역할로 위치시켜야 합니다.

요약

Kiro CLI를 이용할 때의 IAM 설정에 더해, 에이전트 측(Steering) 설정에 대해서도 다루었습니다. 어느 한쪽이 아니라 양쪽을 모두 도입함으로써 더욱 안전해집니다.

여기서 역할의 순서를 혼동하지 않는 것이 중요하다고 생각합니다. 확실한 경계는 IAM으로 긋는다(주). Steering은 그 안쪽에서 불필요한 조작을 줄이는 보조(종). Steering은 깨질 수 있으므로, "규칙을 썼으니 괜찮다"가 아니라 "깨지더라도 IAM으로 넘어갈 수 없다"는 상태를 먼저 만드는 순서입니다. IAM을 토대로 삼고, 그 위에서 Steering이 사고의 씨앗을 줄여주는 이미지입니다.

또한, 이번에는 IAM 권한에 집중했지만, 실제 운영을 고려하면 이것만으로는 불충분해 보입니다. AI 에이전트를 사용한 "누가, 무엇을 조작했는가"를 추적할 수 있는 설계(감사, Audit)도 필요하게 됩니다. 자세한 내용은 아래에서 설명되어 있으며, 별도로 정리해 보도록 하겠습니다.

Discussion