코딩을 넘어 AWS 운영까지 — Kiro 스펙 기반 개발과 Powers 실전 가이드

"프롬프트만 잘 쓰면 앱 하나가 뚝딱 나온다"는 이른바 바이브 코딩(vibe coding)의 시대는 놀라울 만큼 빨리 왔습니다. 하지만 그렇게 만든 코드를 6개월 뒤에 다시 열어 고치는 일, 그리고 그 코드가 도는 AWS 인프라를 구성하고 장애를 추적하는 일은 전혀 다른 문제입니다.

AWS가 내놓은 에이전틱 IDE Kiro는 이 두 가지를 함께 겨냥합니다. 코드 작성 단계에서는 "코드가 아니라 **스펙(spec)**을 작업의 단위로 삼는다"는 철학으로 무분별한 코드 생성을 막고, 운영 단계에서는 셸에서 aws·kubectl을 직접 돌려 실제 리소스 상태를 읽어가며 일합니다. 여기에 더 구조적인 접근이 필요할 때 선택적으로 얹는 것이 Kiro Powers입니다.

먼저 분명히 해둘 점 — Powers는 필수가 아닙니다. 뒤에서 다룰 스펙 기반 개발(Spec)·Steering·Hooks만으로도 Kiro는 충분히 제 역할을 하고, AWS 작업도 자격증명만 있으면 코어 기능(셸 실행)만으로 상당 부분 가능합니다. Powers는 AWS를 깊게 운영하는 팀에게 정확성과 반복성을 더해 주는 선택지일 뿐, "이걸 켜야 Kiro가 AWS를 안다"는 아닙니다.

이 글은 그래서 두 부분으로 나눴습니다. 앞쪽은 누구나 쓰는 기본기, 뒤쪽은 AWS 위에서 일하는 팀이라면 한 번 살펴볼 만한 선택지입니다.

Kiro가 뭔가요

Kiro는 VS Code의 오픈소스 기반인 Code OSS 위에 만들어진 독립 IDE입니다. 평소 쓰던 VS Code와 거의 같은 사용감에, AI 에이전트와 스펙 워크플로우가 얹혀 있다고 보면 됩니다. 그리고 IDE와 별개로 **터미널에서 쓰는 Kiro CLI(kiro-cli)**도 있습니다. Amazon Q Developer CLI에서 진화한 도구로, 서버에 SSH로 붙어 인프라를 만지는 작업처럼 GUI가 없는 환경에서 특히 강력합니다. 이 글의 실전 예시는 대부분 이 CLI 기준입니다.

배경도 알아두면 좋습니다. AWS는 2026년 1월, 기존 Amazon Q Developer의 신규 가입을 종료(2026년 5월 15일부)하면서 IDE 기반 AI 어시스턴트의 후속으로 Kiro를 공식 지목했습니다. 시작에 AWS 계정이 반드시 필요하지는 않으며 — Google, GitHub, AWS Builder ID, AWS SSO 중 편한 방식으로 로그인합니다 — 모델은 Amazon Bedrock을 통해 Claude Opus 4.7·4.6, Sonnet 4.6 등을 사용합니다.

CLI의 기본 사용은 단순합니다. kiro-cli로 대화형 세션을 시작하거나, 한 줄로 바로 물어볼 수도 있습니다.

# 대화형 세션 시작
kiro-cli

# 한 번에 질문 (비대화형)
kiro-cli chat "이 디렉터리에서 가장 큰 파일 5개 알려줘"

세션 안에서는 /save·/load로 대화 상태를 저장·복원하고, /model로 모델을 바꾸고, !로 셸 명령을 바로 실행하고, /usage로 컨텍스트 사용량을 봅니다. IDE에서 만든 Steering 파일과 MCP/Powers 설정은 CLI에도 그대로 이어집니다.

기본기 — Steering과 Spec

본론(AWS 운영)에 들어가기 전에, Kiro의 두 가지 토대를 짧게 짚습니다.

Steering — 프로젝트 규칙을 한 번만 알려주기

Steering은 프로젝트 컨벤션을 마크다운으로 박아두는 장치입니다. .kiro/steering/ 디렉터리에 저장되며, 초기 분석을 요청하면 세 파일이 자동 생성됩니다.

• product.md — 제품의 목적·사용자·핵심 기능·비즈니스 목표
• tech.md — 프레임워크·라이브러리·도구와 기술적 제약
• structure.md — 파일 구성·네이밍·import 방식·아키텍처 패턴

전역 규칙은 ~/.kiro/steering/에 두며, 워크스페이스 규칙과 충돌하면 워크스페이스가 우선합니다. 로딩 방식은 Always(항상) · Conditional(파일 패턴 매칭 시) · Manual(#파일명 호출 시) · Auto(요청이 설명과 맞을 때) 중에 고를 수 있습니다.

Spec — 요구사항 → 설계 → 작업

복잡한 기능은 곧장 코딩하지 않고 세 문서를 단계적으로 만듭니다.

1. requirements.md — 유저 스토리와 수용 기준
2. design.md — 기술 아키텍처와 구현 접근
3. tasks.md — 실행 가능하고 추적되는 작업 목록

IDE라면 Kiro 패널의 Specs에서 +를 눌러 시작하고, CLI라면 대화 세션에서 "스펙부터 잡아줘"라고 말하면 됩니다. 단계 사이에는 승인 게이트가 있어 사람이 검토·승인해야 다음으로 넘어가고, 실행 단계에서는 작업 의존성을 분석해 독립적인 작업을 "웨이브" 단위로 병렬 처리합니다. 스펙은 코드와 함께 갱신되어, "문서 따로 코드 따로" 문제를 구조적으로 막습니다.

실제로는 이런 식입니다. 바로 코드를 시키는 대신, 먼저 스펙을 요청합니다.

kiro-cli chat "관리자 페이지에 '월별 정산 리포트 내보내기' 기능을 추가하려고 해.
바로 코딩하지 말고 requirements부터 잡아줘."

그러면 Kiro가 requirements.md에 유저 스토리와 수용 기준(어떤 형식으로 내보낼지, 권한은 누구까지, 빈 데이터 처리 등)을 정리해 보여줍니다. 검토 후 승인하면 design.md(데이터 흐름·라이브러리 선택·기존 구조와의 정합성)로, 다시 승인하면 tasks.md(체크박스로 추적되는 작업 목록)로 넘어갑니다. 이후 "1번 작업부터 진행해줘"라고 하면 해당 작업만 구현하고 체크합니다. 한 번에 다 쏟아내지 않고 합의 지점을 끼워 넣는 것 — 이게 바로 바이브 코딩과 갈리는 지점입니다.

여기까지가 AWS 계정 없이도 쓰는 Kiro의 기본기입니다. 여기에 AWS 운영까지 묶고 싶을 때 선택적으로 얹는 것이 다음에 다룰 Powers입니다.

선택 — Kiro Powers로 AWS까지 확장하기

다시 강조하지만 이 절은 AWS 위에서 인프라를 구성하고 서비스를 운영하는 팀에게만 의미가 있습니다. 로컬 앱이나 AWS와 무관한 프로젝트라면 건너뛰어도 됩니다.

오해 정리 — Power 없이도 AWS는 다룹니다

먼저 흔한 오해부터 바로잡겠습니다. Kiro가 AWS 리소스를 알려면 Power를 꼭 켜야 하는 건 아닙니다. Kiro CLI는 기본적으로 셸 명령을 실행하는 도구를 갖고 있어서, AWS 자격증명만 설정돼 있으면 aws·kubectl을 직접 돌려 실제 리소스의 현재 상태를 그대로 읽어옵니다. 앞·뒤에 나오는 트러블슈팅 예시 대부분도 사실 이 코어 능력만으로 됩니다.

Kiro Powers는 AWS 도메인별 MCP(Model Context Protocol) 서버를 원클릭으로 설치하는 사전 패키지입니다. Powers가 더하는 건 '접근 가능 여부'가 아니라 '접근의 질' — 문서 근거, 사전 검증, 구조적 상관분석, 운영 가이드입니다. 단계별로 무엇이 더해지는지 정리하면 이렇습니다.

즉 급할 땐 코어만으로도 충분하고, 정확성·반복성·규모가 중요해질수록 위 단계를 하나씩 얹는 그림입니다. Power는 CDK·CloudFormation·가격·관측성 등 도메인별로 나뉘어 있어 필요한 것만 골라 켜면 됩니다. 아래 두 절은 그중 가장 손이 많이 가던 환경 구성과 모니터링을 각각 어떻게 끌어올리는지 보여줍니다.

AWS 환경 구성 — IaC를 제대로 짜기

Kiro는 조직의 표준에 맞춰 CloudFormation·CDK·Terraform 중 원하는 형태로 Infrastructure as Code를 생성합니다. 단순 생성이 아니라 보안·모니터링·운영 우수성(operational excellence) 모범 사례가 반영된 템플릿을 만든다는 점이 핵심입니다.

여기에 AWS Infrastructure as Code(IaC) MCP Server가 더해지면 작업의 정확도가 달라집니다.

• 문서 검색 — CloudFormation·CDK 공식 문서를 맥락에 맞게 즉시 참조
• 템플릿 검증 — 작성한 IaC가 유효한지 사전 검사
• 배포 트러블슈팅 — 실패한 스택의 원인을 추적
• 로컬 실행 — 검증·실행이 로컬에서 이뤄져 보안을 유지

즉 "대충 그럴듯한 CDK"가 아니라, 문서로 검증되고 모범 사례를 따르는 인프라 코드를 짜는 데 초점이 맞춰져 있습니다. 마이그레이션·모더나이제이션처럼 손이 많이 가던 작업을 자동화·표준화하는 방향입니다.

특히 빛을 발하는 건 구성 요소가 많이 얽힌 환경입니다. 예를 들어 EKS에 새 서비스를 올리면서 ALB Ingress·IRSA·시크릿 주입까지 한 번에 엮어야 한다면, 손으로 짜는 매니페스트는 어디 한 군데서 꼭 막힙니다.

kiro-cli chat "이 서비스를 EKS에 올릴 매니페스트를 만들어줘.
이미지는 우리 ECR을 쓰고, ALB Ingress로 노출하고, 시크릿은 IRSA로 주입해야 해."

이런 작업은 애너테이션 하나, 포트 하나만 어긋나도 배포가 통째로 막힙니다. Steering에 "우리 표준은 이렇다(레지스트리·네이밍·노출 방식)"를 한 번 박아두면, Kiro가 그 규칙을 매번 반영해 매니페스트를 만들어 줍니다. 그리고 배포가 실패했을 때 — 가령 ALB에 주소가 안 잡힐 때 — 컨트롤러 로그를 그대로 붙여넣고 원인을 물으면, 백엔드 포트 불일치나 그룹 설정 충돌 같은 흔한 원인을 짚어줍니다.

kiro-cli chat "Ingress를 만들었는데 ALB 주소가 안 잡혀. 아래 컨트롤러 로그 보고 원인 찾아줘:
$(kubectl -n kube-system logs deploy/aws-load-balancer-controller --tail=30)"

AWS 모니터링 — 자연어로 장애를 조사하기

운영 팀이라면 이쪽이 더 와닿을 수 있습니다. AWS Observability power(2026년 2월 제공)는 네 개의 MCP 서버를 하나로 묶습니다.

• CloudWatch MCP — 관측성 데이터(메트릭·로그)
• Application Signals MCP — 애플리케이션 성능 모니터링(APM)
• CloudTrail MCP — 보안 분석·컴플라이언스
• AWS Documentation MCP — 맥락에 맞는 공식 문서 참조

이 묶음 덕분에 쿼리 언어를 몰라도 자연어로 운영 이슈를 조사할 수 있습니다. CloudWatch Application Signals 통합(2026년 1월)으로, 평소처럼 한국어 질문을 던지면 Kiro가 발생 중인 알람을 살피고, 로그 이상을 조사하고, 메트릭을 배포 이력과 상관 분석한 뒤 문제를 일으킨 지점까지 좁혀줍니다. 도구를 갈아타거나 대시보드를 헤맬 필요가 줄어듭니다.

가장 체감이 큰 건 변수가 많이 얽힌 장애 조사입니다. 예컨대 어느 EC2에서 CloudWatch로 로그가 올라오지 않는 상황을 떠올려 봅시다.

kiro-cli chat "이 서버에서 CloudWatch로 로그가 안 올라와.
에이전트는 떠 있는데 logs 엔드포인트로 i/o timeout이 나. 원인이 뭘까?"

같은 증상이라도 막힌 지점은 매번 다릅니다 — 에이전트 IAM 권한일 수도, 보안그룹 아웃바운드일 수도, 프라이빗 서브넷이라면 CloudWatch Logs로 나가는 경로(NAT 또는 VPC 엔드포인트)가 없는 것일 수도 있습니다. Kiro는 에러 메시지와 환경을 함께 읽고 가능성을 순서대로 좁혀, "이 서브넷에서 logs 엔드포인트로 나가는 경로가 있는지부터 확인하라"는 식으로 짚어줍니다. 메트릭이 안 잡히거나(익스포터 포트·노드 SG 아웃바운드·스크랩 설정) 트레이스가 안 보일 때(OTel 엔드포인트 포트, VPC 엔드포인트, IRSA 권한)도 같은 방식으로, 체크리스트를 사람이 외우는 대신 대화로 풀어갈 수 있습니다.

여기까지의 추론은 코어 능력(에러 읽기 + aws·kubectl 실행)만으로도 됩니다. Observability power를 얹으면 달라지는 건 그다음입니다 — 추측에 기대지 않고 CloudWatch·Application Signals에서 실제 지표와 로그를 끌어와 배포 이력과 상관 분석하므로, 후보를 더 빠르고 정확하게 좁힐 수 있습니다.

운영을 더 탄탄하게 만드는 두 기능도 있습니다.

• 관측성 갭 분석 — 코드를 훑어 누락된 계측을 찾아냅니다. 로깅되지 않는 에러, 빠진 correlation ID, 분산 트레이싱 부재 같은 것을 짚고 개선안을 제시합니다.
• 8종 운영 가이드(steering) — 인시던트 대응, 알림 설계, 성능 모니터링, 보안 감사, 갭 분석 등 실무 가이드가 내장되어, 인시던트를 조사할 때 그 상황에 필요한 맥락만 동적으로 로드됩니다.

여기에 클라우드 운영을 위한 AWS DevOps Agent power까지 더하면, Kiro는 개발 도구를 넘어 DevOps·SRE 작업의 보조 도구로도 자리합니다.

가격은 어떻게 되나요

2026년 3월 기준, 크레딧 기반 요금제입니다.

• Free — 월 50 크레딧
• Pro — $20/월, 1,000 크레딧
• Pro+ — $40/월, 2,000 크레딧
• Power — $200/월, 10,000 크레딧

한도 초과분은 크레딧당 $0.04로 월말 실사용량만큼 청구됩니다.

몇 가지 현실적인 메모를 더하면 — Powers를 켠다고 더 비싼 요금제가 필요한 건 아닙니다. 크레딧은 모델 호출량으로 소모되므로, 개인이나 작은 팀은 Pro($20)·Pro+($40) 선에서 대부분 충분합니다. 스타트업이라면 AWS Activate 같은 크레딧 지원 프로그램으로 비용 부담을 더 낮출 수도 있습니다. 일단 Free로 감을 잡고, 매달 한도에 부딪힐 때 한 단계씩 올리는 편이 합리적입니다.

정리하며

Kiro의 토대는 어디까지나 스펙 기반 개발입니다. requirements·design·tasks 문서로 "무엇을 왜 만드는지"를 남기는 것 — 이것만 제대로 써도 충분히 값을 합니다. Powers는 그 위에 AWS 운영을 얹고 싶은 팀을 위한 선택지일 뿐입니다.

• 코드 중심 팀 → Spec·Steering·Hooks만으로 시작
• AWS 작업이 섞인 팀 → 코어(셸 + 자격증명)로 충분히 시작, aws·kubectl을 대화로 굴리기
• 정확성·반복성·규모가 중요해지면 → IaC·Observability Power를 필요한 만큼 추가

물론 만능은 아닙니다. 에이전트가 만든 IaC나 장애 분석도 사람이 검토해야 하고, 도구 자체가 빠르게 바뀌고 있어 어제의 사용법이 오늘 달라지기도 합니다. 크레딧도 쓰는 만큼 나갑니다. 그래도 "대시보드·쿼리 언어 사이를 오가던 장애 조사"가 IDE 안의 대화로 줄어드는 경험은, 한 번 써보면 왜 AWS가 Q Developer의 후속으로 이걸 밀었는지 납득이 갑니다.

가장 좋은 평가 방법은 직접 써보는 것입니다. Free 플랜으로 작은 기능 하나, 혹은 작은 스택 하나를 끝에서 끝까지 돌려보세요. ZZARI 팀도 같은 방식으로 도구를 검증하고 실제 프로젝트에 들이고 있습니다.