Kiro IDE의 스펙 주도 개발과 Agent Hooks 아키텍처

Kiro IDE가 스펙을 중심으로 요구사항·설계·구현을 연결하는 방식과 Agent Hooks 자동화, 모델 라우팅, 운영상 주의점을 분석한다.

2026-08-14 · 최초 발행 2026-05-21

코드를 산출물로 보는 Kiro의 출발점

Amazon Web Services가 개발한 Kiro IDE는 2025년 중반 출시된 뒤 2026년에 빠르게 확산됐다. 기존 AI 코딩 도구가 프롬프트를 코드로 바꾸는 속도에 집중했다면, Kiro는 구현보다 요구사항 스펙을 먼저 만든다. 이후 생성되는 코드와 유지보수 작업도 이 스펙을 기준으로 삼는다.

Kiro는 Amazon Q Developer의 후계 위치에 있지만 작업 모델은 다르다. Amazon Q Developer가 코드 완성, 리뷰, 보안 스캔을 지원하는 도구였다면 Kiro는 개발 워크플로우 전체를 스펙이라는 단일 진실의 원천(Source of Truth)에 맞춰 구성한다.

핵심 관점은 스펙이 소스이고 코드는 빌드 아티팩트라는 것이다. 개발자는 구현 세부사항을 일일이 지시하는 대신 컴포넌트와 서비스, 기능이 수행해야 할 동작을 기술한다. Kiro는 이 스펙에 맞춰 코드를 생성하고 변경된 요구사항을 구현에 반영한다. 이에 따라 버전 관리와 리뷰의 중심도 코드만이 아니라 동작의 근거가 되는 스펙으로 이동한다.

프롬프트에서 코드로 곧장 넘어가지 않는 흐름은 다음과 같다.

거부/수정승인사용자 프롬프트(기능 설명)요구사항 문서 생성(Requirements Doc)설계 아티팩트 생성(Design Artifacts)구조화 태스크 목록(Task List)사용자 검토승인?코드 생성(Claude Sonnet / Nova)스펙 추적(Spec Tracking)변경 영향 분석(Impact Analysis)테스트 자동 실행배포 가능 코드

사용자 검토에서 승인을 받아야 코드 생성으로 넘어가며, 수정이 필요하면 요구사항 문서로 되돌아간다. 생성 이후에도 스펙 추적과 영향 분석, 테스트 실행이 이어진다.

자연어 요구사항을 구현 가능한 스펙으로 바꾸는 과정

Kiro의 에이전트는 자연어 프롬프트를 요구사항 문서, 설계 아티팩트, 태스크 목록으로 구조화한다.

요구사항 문서에는 기능 목표와 함께 성능·보안·확장성 같은 비기능 요구사항이 들어간다. 정상 경로만 적는 것이 아니라 엣지 케이스와 예외 상황을 열거하고, 구현 완료 여부를 판정할 인수 기준(Acceptance Criteria)도 포함한다.

설계 아티팩트는 요구사항을 시스템 구조로 옮긴 결과물이다. API 인터페이스는 OpenAPI나 Protobuf로 명세하고, 데이터 모델 다이어그램과 컴포넌트 의존성 그래프로 구현 경계를 드러낸다.

태스크 목록은 스펙에서 파생한 원자적(atomic) 구현 작업으로 구성된다. 작업 사이의 의존관계는 DAG로 표현하며, 각 태스크에는 우선순위와 예상 복잡도를 붙인다. 이 목록이 승인된 뒤에야 실제 코드 생성 단계가 시작된다.

추론과 반복 생성을 분리하는 모델 라우팅

Kiro는 Amazon Bedrock을 통합 모델 플레인으로 사용한다. 모든 작업을 같은 모델에 맡기지 않고 태스크의 성격에 따라 Claude Sonnet과 Amazon Nova를 라우팅한다.

모델 사용 케이스 특징
Claude Sonnet 스펙 추론, 설계 결정, 영향 분석 깊은 추론, 맥락 이해
Amazon Nova 고처리량 코드 생성, 보일러플레이트 빠른 처리, 비용 효율

요구사항을 해석하거나 설계 선택의 영향을 따지는 작업은 Claude Sonnet이 맡는다. 반복적이고 패턴화된 코드 생성은 Amazon Nova로 넘긴다. Kiro는 이 역할 분담으로 품질과 비용 사이의 균형을 맞춘다.

스펙이 바뀌면 코드와 테스트의 영향 범위를 찾는다

스펙 변경은 문서 수정으로 끝나지 않는다. Kiro는 변경된 스펙에 의존하는 코드 파일과 테스트, 문서를 식별한 뒤 업데이트 제안을 만든다. 이를 위해 AST(Abstract Syntax Tree) 분석으로 의존성 그래프를 구축하고 스펙과 구현 사이의 연결을 추적한다.

처리는 스펙 파일의 변경을 감지하는 데서 시작한다. 이어 스펙-코드 매핑 테이블을 조회해 영향을 받는 파일 목록을 만들고, 파일별 변경 범위를 계산한다. 마지막에는 일괄 업데이트하거나 필요한 항목만 선택해 적용할 수 있도록 사용자에게 제안한다.

이 구조에서는 스펙이 단순한 초기 설계 문서가 아니다. 구현 이후에도 코드가 요구사항에서 벗어났는지 판단하는 운영 기준으로 남는다.

개발 이벤트에 에이전트 작업을 연결하는 Agent Hooks

Agent Hooks는 IDE에서 특정 이벤트가 발생했을 때 미리 정의한 에이전트 액션을 실행하는 자동화 장치다. 개발자가 매번 프롬프트를 입력하지 않아도 코드 품질 점검, 테스트 동기화, 문서 갱신을 이어갈 수 있다.

Kiro가 다루는 이벤트에는 파일 저장 시 발생하는 file.save, Pull Request가 열릴 때의 pr.open, 스펙 변경을 나타내는 spec.change가 있다. 빌드와 테스트 실패는 각각 build.fail, test.fail로 처리하며, 필요한 경우 custom 이벤트를 정의할 수 있다.

파일 저장(file.save)PR 오픈(pr.open)스펙 변경(spec.change)빌드 실패(build.fail)Hook 엔진(Event Dispatcher)Hook 설정(.kiro/hooks/)에이전트 액션테스트 갱신에이전트 액션문서화 동기화에이전트 액션스펙 캐스케이드에이전트 액션자동 리팩토링품질 모니터링대시보드

Hook 엔진은 이벤트와 .kiro/hooks/의 설정을 연결한다. 실행 결과는 테스트 갱신, 문서 동기화, 스펙 캐스케이드, 자동 리팩토링 같은 에이전트 액션으로 이어지고 품질 모니터링 대시보드에 반영된다.

Hook을 정의하고 반복 작업에 적용하는 방법

Hook은 자연어로 요청하거나 설정 파일을 직접 작성할 수 있다. 자연어 방식에서는 “파일을 저장할 때마다 관련 테스트를 자동으로 업데이트해줘”와 같이 원하는 동작을 설명하면 Kiro가 YAML 또는 JSON 설정을 생성한다. 직접 관리하려면 .kiro/hooks/ 디렉토리에 YAML 파일을 둔다.

설정에는 감지할 이벤트, 대상 경로와 제외 경로, 액션 타입, 에이전트에 전달할 프롬프트가 들어간다.

이벤트: file.save
경로 필터: src/**/*.ts
제외 경로: **/*.test.ts
액션 타입: agent_prompt
프롬프트: "변경된 파일의 단위 테스트를 검토하고 누락된 테스트 케이스를 추가하라"

소스 파일 저장 이벤트에는 관련 테스트 검토를 연결해 커버리지 갭을 찾고 테스트 추가를 제안할 수 있다. API 엔드포인트 파일이 바뀌면 OpenAPI 스펙과 README를 동기화하도록 구성할 수 있으며, 스펙 변경 이벤트에는 의존 서비스의 스펙과 계약(contract)을 갱신하는 작업을 붙일 수 있다.

Pull Request가 열릴 때 변경 파일에 SAST(Static Application Security Testing)를 실행하는 보안 스캔 Hook도 가능하다. 빌드 실패 이벤트에는 오류 메시지를 분석하고 수정안을 생성하는 리팩토링 작업을 연결한다.

Cursor와 Claude Code 사이에서 Kiro가 택한 위치

2026년 AI 코딩 도구 시장은 Cursor의 속도·UX, Claude Code의 추론·품질, Kiro의 스펙·구조를 축으로 하는 3강 구도로 재편됐다. 각 도구의 차이는 사용하는 모델뿐 아니라 개발 흐름에서 무엇을 일급 객체로 취급하는지에 있다.

항목 Kiro Cursor Claude Code
핵심 차별화 스펙 드리븐 개발 속도·UX 추론 깊이
모델 Claude Sonnet + Nova GPT-4o / Claude Claude 4.x
이벤트 훅 내장(Agent Hooks) 제한적 수동 구성
스펙 관리 일급(first-class) 없음 없음
가격 무료(50회/월) / Pro $19 $20/월 사용량 기반
주요 대상 구조화 개발, 팀 협업 개인 개발자 속도 AI 에이전트 파이프라인

Cursor가 개인 개발자의 빠른 작성 경험에 무게를 두고 Claude Code가 깊은 추론과 에이전트 파이프라인에 강점을 둔다면, Kiro는 팀이 합의한 스펙을 구현과 변경 관리의 중심에 놓는다.

이 방식은 명확한 설계 없이 AI에게 즉흥적으로 코드를 생성시키는 바이브 코딩(Vibe Coding)의 반대편에 있다. 기술 부채가 누적되고 요구사항을 추적하기 어려워지는 문제를 스펙과 구현 사이의 연결로 다루려는 접근이다.

기업 환경에서는 규제 준수(compliance) 문서화를 자동화하고, 대규모 팀의 코드 표준을 스펙으로 일관되게 유지하는 데 활용할 수 있다. 새로 합류한 팀원도 구현 코드만 추적하는 대신 스펙을 통해 시스템의 의도와 구조를 파악할 수 있다.

프로덕션 적용에는 승인 경계가 필요하다

2026년 2월에는 Kiro가 생성한 코드가 AWS 서비스 장애를 일으켰다는 사건이 보도됐다. AWS는 Kiro와의 연관성을 공식적으로 부인했다. 이 사건은 확정된 원인과 별개로, AI 생성 코드가 프로덕션 인프라와 상호작용할 때 어떤 가드레일을 둘 것인지 다시 묻게 했다.

Kiro의 자동화 범위가 넓을수록 실행 권한과 승인 경계도 함께 설계해야 한다. 특히 프로덕션 인프라에 접근하는 에이전트에는 별도의 승인 게이트가 필요하다.

Kiro의 특징은 코드 생성 모델 자체보다 스펙, 코드, 테스트, 문서를 하나의 변경 흐름으로 묶는 데 있다. Agent Hooks는 명시적인 프롬프트가 없는 순간에도 이 흐름을 이어가며, Claude Sonnet과 Amazon Nova의 모델 라우팅은 추론과 반복 생성을 분담한다. 조직에서 사용하려면 도구 도입에 앞서 스펙을 작성하고 검토하며 변경 책임을 관리하는 방식부터 합의해야 한다.

Sources

Kiro IDE스펙 주도 개발AI 코딩 에이전트Agent HooksAmazon Bedrock