2025년 7월 AWS가 Kiro를 공개했을 때, 가장 많이 등장한 표현이 “바이브 코딩의 한계를 넘는다”였습니다. 실제로 기존 AI 에디터는 자연어로 요청하면 코드를 생성해 주는 방식이 전부였습니다. Kiro는 여기서 한 단계를 더 앞에 놓았는데, 바로 요구사항 설계(Spec)를 먼저 확정한 뒤 코드를 생성하는 구조입니다.

Cursor나 Windsurf가 “일단 만들어봐”에서 출발한다면, Kiro는 “뭘 만들지 문서로 정리해”에서 시작합니다. Kiro 공식 블로그에는 이를 Spec-Driven Development(SDD)라고 부릅니다. 요구사항 → 태스크 → 코드 구현 → 검증이 하나의 흐름으로 연결됩니다. (출처: AWS Korea 블로그, Kiro GA 발표, 2025.11.18)

Code OSS(VS Code 기반)를 포크해 만들었기 때문에 기존 VS Code 확장 기능을 그대로 쓸 수 있습니다. Vibe 모드와 Spec 모드를 UI에서 전환할 수 있어서, 간단한 수정은 채팅으로, 복잡한 신규 기능은 Spec으로 처리하는 방식이 가능합니다.

Kiro의 요금 이야기는 한 번 제대로 짚어볼 필요가 있습니다. 출시 초기에는 Vibe 요청과 Spec 요청을 분리 계산했습니다. The Register가 보도한 바에 따르면, 당시 Spec 요청 1건은 $0.20이었고 Vibe 요청은 $0.04였습니다. Spec이 Vibe보다 5배 비쌌습니다. (출처: The Register, 2025.08.18)

2025년 9월 AWS는 Vibe/Spec 구분을 폐지하고 단일 크레딧 풀로 통합했습니다. 현재 공식 요금표는 다음과 같습니다. (출처: kiro.dev/pricing/, 2025.11 GA 기준)

처음 가입하면 30일 내 사용 가능한 보너스 500 크레딧을 지급합니다. 크레딧은 0.01 단위로 소수점 과금되고, 간단한 수정은 1 크레딧 미만도 소비됩니다. 초과 사용은 기본적으로 비활성화되어 있으며, 설정에서 직접 켜야 적용됩니다. (출처: kiro.dev/blog/new-pricing-plans-and-auto/, 2025.09.15)

한 가지 더 확인해야 할 점이 있습니다. 기본 모드인 Auto와 Claude Sonnet 4를 직접 선택했을 때 소비량이 다릅니다. 동일한 작업에서 Sonnet 4를 직접 선택하면 Auto 대비 1.3배 크레딧이 소비됩니다. 정밀 제어보다 효율을 원한다면 Auto를 그대로 두는 것이 낫습니다.

Spec 모드를 써보면 확실히 편합니다. 요구사항을 자연어로 입력하면 Kiro가 태스크로 분해해 주고, 태스크 단위로 코드를 생성합니다. 그런데 실사용자들이 GitHub Issue에 남긴 내용을 보면 크레딧 소진 속도가 예상보다 빠릅니다. 어떤 경우에는 Pro+ 플랜의 월간 크레딧 2,000개가 단일 세션 15분 만에 소진됐다는 보고도 있었습니다. (출처: GitHub kiro 이슈 #2171)

결론적으로 Spec 모드는 단순 파일 수정이나 1~2줄 변경에는 오히려 크레딧 낭비가 됩니다. 크레딧을 효율적으로 쓰려면, 작은 수정은 Vibe 모드(채팅)로 처리하고, 새로운 기능 설계나 대형 리팩토링에만 Spec 모드를 투입하는 것이 맞습니다. “Spec이 좋다니까 무조건 Spec으로”라는 접근은 생각보다 빨리 한도를 소진합니다.

또한 초과 사용 설정이 기본으로 꺼져 있습니다. 한도 도달 시 작업이 중단되므로, 장시간 Spec 작업 전에 크레딧 잔량을 확인하는 습관이 필요합니다.

Kiro IDE와 CLI 모두에서 사용할 수 있는 Subagent 기능이 있습니다. 하나의 AI 에이전트에게 코드 작성, 리뷰, 테스트, 문서화를 전부 맡기는 것과, 각 역할에 특화된 에이전트를 분리해서 운영하는 것은 결과가 다릅니다.

Kiro의 Subagent는 Dev → Review → QA → Docs 4개 Agent로 구성하는 것이 AWS 공식 권장 구조입니다. Dev Agent가 코드를 작성하고, 변경이 생길 때마다 Review Agent를 자동 호출합니다. 마일스톤 완료 시 QA Agent가 실제 시스템을 테스트하고, Docs Agent가 변경 이력을 기록합니다. 각 Agent가 독립된 컨텍스트를 갖기 때문에 단일 에이전트에서 발생하는 컨텍스트 과부하를 막을 수 있습니다. (출처: AWS 기술 블로그, Kiro Subagent 워크플로우, 2026.02.10)

단, Subagent는 CLI 환경에서 활용도가 가장 높습니다. IDE에서도 동일한 개념이 적용되지만, Kiro CLI로 터미널에서 구동할 때 병렬 실행과 흐름 제어가 더 자유롭습니다.

Kiro GA 발표와 함께 추가된 기능 중 눈에 띄는 것이 속성 기반 테스트(Property-Based Testing, PBT)입니다. 일반 단위 테스트는 개발자가 직접 생각한 시나리오만 검증합니다. 예를 들어 “사용자 A가 차량 #5를 즐겨찾기에 추가하면 목록에 표시된다”처럼 특정 케이스만 확인합니다.

PBT는 접근 방식이 다릅니다. Kiro가 Spec 문서에서 속성(property)을 추출하고, 수백~수천 개의 랜덤 입력을 자동 생성해 코드가 일반적으로 그 속성을 만족하는지 검증합니다. “어떤 사용자와 어떤 차량 조합에서도, 즐겨찾기 추가 후 목록에 표시돼야 한다”는 방식입니다. (출처: AWS Korea 블로그, Kiro GA 발표, 2025.11.18)

AI가 생성한 코드는 테스트를 통과하기 위해 테스트 코드를 조작하는 패턴이 종종 나옵니다. PBT는 속성 자체가 Spec에서 도출되기 때문에 이 조작 가능성을 줄입니다. 완전한 검증은 아니지만, “개발자가 직접 생각하지 않은 경계 케이스”를 잡아낼 확률이 높아집니다.

세 도구를 비교하면 실질적인 포지션 차이가 있습니다. Cursor는 일반 코딩 작업에서 가장 안정적이고 성숙한 도구로 평가받습니다. 여러 AI 모델을 직접 선택할 수 있고 파일 단위 수정 가시성이 높습니다. Windsurf는 대형 리포지토리와 엔터프라이즈 환경에 강점을 가지며, 가격은 세 도구 중 가장 낮습니다. Kiro는 클라우드(특히 AWS) 환경과 체계적인 설계가 필요한 프로젝트에 적합합니다. (출처: devlycan.com, AI IDE 비교 분석, 2025~2026)

Kiro를 단순히 “Cursor 경쟁 제품”으로 보면 아쉬움이 생깁니다. Cursor가 더 빠르고 유연한 일상 코딩에 강하기 때문입니다. Kiro의 강점은 AWS IAM Identity Center를 통한 팀 관리, 중앙 청구, 엔터프라이즈 보안 정책 적용에 있습니다. 소규모 개인 프로젝트보다는 팀 단위 클라우드 프로젝트에서 가치가 더 드러납니다.

한 가지 더 짚고 넘어갈 부분이 있습니다. 2025년 8월 Kiro에서 프롬프트 인젝션 취약점이 발견됐습니다. MCP 연동 상태에서 외부 악성 컨텐츠가 Kiro를 통해 의도치 않은 명령을 실행하도록 유도할 수 있는 구조였습니다. AWS는 2025년 8월 1일 Kiro 0.1.42 버전에서 감독 모드(Supervised Mode) 내 HITL 확인을 필수화하는 패치를 배포했습니다. (출처: AWS 보안 공지 AWS-2025-019, 2025.10.07) 현재는 수정됐지만, MCP 연동을 쓴다면 감독 모드 설정을 직접 확인하는 것이 좋습니다.

Kiro는 분명히 독특한 포지션에 있습니다. 바이브 코딩의 “일단 만들고 보자”에서 벗어나 설계를 먼저 잡고 싶은 팀에게는 실제로 가치가 있습니다. 특히 AWS 환경에서 여러 명이 함께 작업하는 구조라면, 엔터프라이즈 플랜의 중앙 관리와 IAM 통합은 Cursor나 Windsurf가 대체하기 어렵습니다.

반면, 개인 개발자나 소규모 프로젝트에서 빠른 피드백 루프가 필요하다면 Cursor가 더 현실적입니다. Spec 모드를 기본으로 쓰면서 크레딧 소진 속도를 과소평가하면 예상보다 빨리 요금이 올라갑니다. Kiro를 쓴다면 Auto 모드 유지, 소규모 수정은 Vibe 모드 활용, 크레딧 대시보드 정기 확인 세 가지를 루틴으로 가져가는 것이 현명합니다.