Amazon Kiro 리뷰: 2026년 AWS의 명세 기반 에이전트형 IDE (Spec-Driven Agentic IDE)

대부분의 에이전트형 IDE (Agentic IDEs)는 동일한 루프를 최적화합니다. 사용자가 프롬프트를 입력하면, 에이전트가 파일을 수정하고, 사용자가 차이점 (diff)을 검토하는 방식입니다. 2025년 7월에 퍼블릭 프리뷰 (public preview)로 출시되어 2025년 말부터 프리뷰를 종료한 AWS의 이 분야 진출작인 Kiro는 완전히 다른 루프에 승부수를 던집니다. 애플리케이션 코드를 작성하기 전에, Kiro는 문서들을 먼저 작성합니다. 즉, 요구사항 파일 (requirements file), 설계 파일 (design file), 그리고 작업 목록 (task list)을 작성합니다. 사용자가 이를 검토하고 편집하면, 그제서야 에이전트가 구현을 시작합니다.

이는 프로세스 오버헤드 (process overhead)처럼 들릴 수 있으며, 때로는 실제로 그렇기도 합니다. 하지만 중간 규모의 TypeScript 코드베이스에서 몇 가지 실제 기능을 통해 Kiro를 실행해 본 결과, 우리는 이 명세 우선 (spec-first) 워크플로우가 모든 Cursor 및 Copilot 사용자가 겪었던 문제, 즉 '에이전트가 잘못된 것을 아주 빠르게, 확신을 가지고 만들어버리는 문제'를 해결한다고 생각합니다.

명세 기반 개발 (Spec-driven development)이 실제로 작동하는 방식

Kiro는 VS Code의 오픈 소스 기반인 Code OSS의 포크 (fork)이므로, 에디터 자체는 익숙한 느낌을 줍니다. 키 바인딩 (keybindings)이 그대로 유지되며, 확장 프로그램 (extensions)은 Microsoft의 마켓플레이스 대신 Open VSX에서 설치됩니다. 이는 일부 독점 확장 프로그램이 누락될 수 있음을 의미하며, 특정 확장 프로그램에 의존하는 워크플로우를 가진 사용자에게는 실제적인 불편함이 될 수 있습니다. 로그인은 AWS Builder ID, Google 또는 GitHub를 통해 가능합니다. AWS 계정이 필요하지 않으며, IDE가 사용자가 반드시 AWS에 배포할 것이라고 가정하지도 않습니다.

핵심 기능은 명세 (spec)입니다. 명세를 시작하면, Kiro는 .kiro/specs/<feature-name>/ 경로 아래에 세 개의 Markdown 파일을 생성합니다:

• requirements.md — EARS 표기법("WHEN a user submits an invalid email, THEN the system SHALL display a validation error")으로 작성된 수락 기준(acceptance criteria)이 포함된 사용자 스토리(user stories). EARS는 시스템 엔지니어링(systems-engineering) 분야에서 유래되었으며, 코드가 존재하기 전에 엣지 케이스(edge cases)를 드러나게 만듭니다.
• design.md — 기술 계획: 아키텍처 노트, 데이터 흐름(data flow), TypeScript 인터페이스, 때로는 시퀀스 다이어그램(sequence diagrams). Kiro는 이를 구체화하기 위해 기존 코드베이스를 읽으며, 저희의 테스트 결과 Kiro는 새로운 패턴을 만들어내는 대신 기존 리포지토리 패턴을 정확하게 파악했습니다.
• tasks.md — 각 단계가 특정 요구사항과 연결된, 의존성 순서대로 정렬된 구현 단계 체크리스트.

각 파일은 체크포인트(checkpoint)입니다. 일반 Markdown으로 요구사항을 수정하고 Kiro에게 정제(refine)하도록 지시하면, 디자인과 작업(tasks)이 그에 맞춰 다시 생성됩니다. 그런 다음 작업을 하나씩 실행하거나 에이전트가 목록을 따라 실행하도록 둡니다. 에이전트는 Anthropic의 Claude 모델에서 실행됩니다. Kiro는 Claude Sonnet 4로 출시되었으며, 이후 최신 Sonnet 버전들을 추적해 왔고 자동 모델 선택(automatic model-selection) 옵션을 제공합니다.

그 결실은 정말 까다로운 요구사항(4개의 모듈에 영향을 미치는 권한 변경)이 있는 기능을 작업할 때 나타났습니다. 처음에는 문서 세 개를 작성하는 것이 느리게 느껴졌습니다. 하지만 구현 단계에서 다른 도구들의 전형적인 '프롬프트 후 기도하기(prompt-and-pray)' 세션보다 훨씬 적은 수정이 필요했는데, 이는 오해의 소지가 requirements.md에서 드러났기 때문입니다. 여기서 문제를 수정하는 데는 여러 파일을 되돌리는 대신 문장 하나를 편집하는 비용만 들었습니다.

한 줄짜리 버그 수정에 이 절차를 따르는 것은 적절하지 않으며, Kiro도 이를 알고 있습니다. Kiro에는 다른 에이전트형 IDE(agentic IDE)와 유사하게 작동하는 표준 "바이브(vibe)" 채팅 모드가 있으며, 여기에는 오토파일럿(autopilot, 에이전트가 스스로 변경 사항을 적용)과 감독(supervised, 사용자가 각 단계를 승인) 변형이 있습니다.

훅(Hooks), 스티어링(steering), 그리고 자동화 레이어

두 가지 지원 기능이 워크플로우를 완성하며, 두 기능 모두 조용하지만 유용합니다.

**에이전트 후크 (Agent hooks)**는 이벤트 기반 자동화입니다. 파일이 저장되거나 생성될 때, 사용자가 정의한 자연어 지침(natural-language instruction)에 따라 백그라운드 에이전트가 실행됩니다. AWS가 제시하는 예시들은 매우 적절합니다. React 컴포넌트가 변경될 때 테스트 파일을 업데이트하거나, 저장 시 실수로 커밋된 자격 증명(credentials)을 스캔하거나, API 시그니처가 변경될 때 README를 새로고침하는 등의 작업입니다. 후크는 프로젝트별로 정의되며 버전 관리 시스템(version control)에 포함되므로, 팀 전체가 이를 상속받아 사용할 수 있습니다. 이는 다른 IDE들이 가장 먼저 모방할 것으로 예상되는 기능입니다.

**스티어링 파일 (Steering files)**은 .kiro/steering/ 경로에 위치하며, CLAUDE.md나 Cursor rules 파일과 동일한 역할, 즉 지속적인 프로젝트 컨텍스트(project context) 역할을 수행합니다. Kiro는 저장소(repo)를 분석하여 제품 컨텍스트(product context), 기술 스택(tech stack), 프로젝트 구조(project structure)라는 세 가지 파일을 부트스트랩(bootstrap)할 수 있으며, 사용자는 조건부 포함 규칙(conditional inclusion rules)을 사용하여 자신만의 파일을 추가할 수 있습니다 (예를 들어, 에이전트가 *.test.ts 파일을 다룰 때만 로드되는 테스트 컨벤션 파일 등). MCP 지원이 내장되어 있어, 외부 도구와 문서들도 동일한 컨텍스트 시스템에 연결됩니다.

스펙 세션(Spec sessions)은 토큰 소모가 심하며, Kiro의 가격 책정 방식은 이를 측정합니다. 요구사항 생성, 두 번의 정교화(refine), 디자인 생성, 수십 개의 작업 실행으로 이어지는 전체 스펙 사이클은 저희를 놀라게 할 정도로 빠른 속도로 크레딧을 소비합니다. 특정 요금제(tier)를 결정하기 전, 첫 주 동안 사용량 대시보드(usage dashboard)를 주의 깊게 살펴보십시오.

가격 책정: 프리뷰 이후의 크레딧 시스템

Kiro의 가격 책정은 계속 변해왔습니다. 무료 프리뷰가 몇 달간 지속되었고, 초기 요금제 발표 당시 상당한 반발이 있어 AWS가 이를 수정했으며, 최종적으로 정착된 구조는 크레딧 기반입니다. 이 글을 쓰는 시점 기준: 월 50 크레딧을 제공하는 Free 티어, 월 20달러에 225 크레딧을 제공하는 Pro 티어, 월 40달러에 450 크레딧을 제공하는 Pro+ 티어, 그리고 월 200달러에 2,250 크레딧을 제공하는 Power 티어가 있습니다. 유료 티어에서는 크레딧당 과금되는 종량제(pay-as-you-go) 초과 사용을 활성화할 수 있습니다.

단순한 채팅 상호작용은 대략 1크레딧이 소요되며, 복잡한 명세 실행 (spec executions)은 에이전트가 수행하는 작업량에 따라 더 많은 비용이 발생하며 비례하여 증가합니다. 이것이 AI 가격 책정의 솔직한 버전입니다. 즉, 고도의 에이전트 작업 (agentic work)은 어디에서나 실제 비용이 발생합니다. 하지만 이 방식은 Cursor의 요청 기반 (request-based) 티어보다 Kiro의 예산 계획을 세우기 어렵게 만들며, 무료 티어의 50크레딧은 실제 사용 시 하루 이틀 만에 소진됩니다. 사용을 결정하기 전에 Kiro의 가격 페이지를 확인하십시오. 과거 사례를 고려할 때, 위의 수치들은 다시 변경될 수 있습니다.

2026년 Kiro의 위치

Kiro는 LLM으로부터 코드를 뽑아내는 가장 빠른 방법은 아니며, 그렇게 되려고 노력하지도 않습니다. Kiro는 프롬프트 기반 (prompt-driven) 도구들이 건너뛰는 소프트웨어 작업 단계, 즉 '구축하기 전에 무엇을 구축할 것인지 합의하는 단계'를 위해 구축되었습니다. 이미 설계 문서 (design docs)를 작성하는 팀이라면, 명세 워크플로우 (spec workflow)가 자신들의 프로세스와 거의 정확하게 일치한다는 것을 알게 될 것입니다. 다만 이제는 문서가 위키 (wiki)에서 방치되는 대신 코드와 동기화된 상태로 유지된다는 점이 다릅니다.

만약 당신의 작업이 주로 빠른 프로토타이핑 (rapid prototyping), 작은 수정, 또는 개인적인 실험 위주라면, 명세 절차 (spec ceremony)는 당신의 속도를 늦출 것이며 대화형 도구가 여전히 더 나은 기본 선택지일 것입니다. 확장 프로그램 마켓플레이스 (extension-marketplace)의 공백과 가격 변동성 또한 실제적인 비용입니다.

우리의 의견: 요구사항이 정말로 모호하여 보통 재작업 (rewrite)을 유발하는 기능 하나를 골라 Kiro를 시도해 보십시오. 만약 요구사항-설계-작업 (requirements-design-tasks) 루프가 구현 전에 오해를 잡아낸다면, 당신은 즉시 이 제품의 가치를 이해하게 될 것입니다. 만약 그렇지 않다면, 당신은 오후 시간과 약간의 무료 크레딧을 써서 그 사실을 확인한 셈이 됩니다.