Kiro: AWS의 명세 기반 에이전트형 IDE(Spec-Driven Agentic IDE) 실무 가이드

AI 코딩 어시스턴트를 사용해 본 적이 있다면, 그 실패 패턴을 알고 있을 것입니다. 모호한 프롬프트(prompt)를 작성하면, 에이전트(agent)는 그럴듯해 보이는 코드의 벽을 생성하고, 20분 뒤 당신은 자신이 설계하지도 않았고 완전히 이해하지도 못한 무언가를 디버깅하고 있게 됩니다. AWS의 에이전트형 IDE(agentic IDE)인 Kiro는 그 해결책이 더 똑똑한 자동 완성(autocomplete)이 아니라, 프롬프트 대신 _명세(specification)_를 작업 단위로 만드는 것이라는 믿음에 기반하고 있습니다.

저는 Kiro가 실제로 어떻게 작동하는지 깊이 파고들었으며, 이것은 제가 첫날에 가졌으면 좋았을 실무 가이드입니다. 즉, 명세 기반 개발(spec-driven development)이 실제로 무엇을 의미하는지, 에이전트 훅(agent hooks)과 스티어링 파일(steering files)이 워크플로우를 어떻게 바꾸는지, Kiro가 Cursor나 Claude Code와 같은 도구들과 비교했을 때 어디에 위치하는지, 그리고 언제 사용할 가치가 있는지를 다룹니다. 저는 동유럽의 AI 교육 플랫폼인 Cursuri-AI.ro에서 에이전트 공학(agentic engineering)에 대해 쓰고 가르치고 있으므로, 출시 당일의 과장된 홍보보다는 이러한 도구들이 실제 프로젝트에서 어떻게 작동하는지에 초점을 맞추어 설명하겠습니다.

Kiro란 무엇인가?

Kiro는 VS Code의 기반이 되는 오픈 소스 플랫폼인 Code OSS를 바탕으로 구축된 에이전트형 IDE(agentic IDE)입니다. 따라서 에디터 자체는 즉시 익숙하게 느껴질 것입니다. 차이점은 엔진에 있습니다. 각 요청을 일회성 채팅 턴(chat turn)으로 취급하는 대신, Kiro는 고수준의 프롬프트(prompt)를 구조화된 **명세(spec)**로 변환한 다음, 그 명세를 바탕으로 구현, 테스트 및 문서를 실행하도록 설계되었습니다.

Kiro의 자체적인 프레임워크에서 핵심 아이디어는 "AI 코딩을 넘어 에이전트 공학(agentic engineering)으로 이동하는 것"입니다. 이는 그것이 만들어내는 결과물(artifacts)을 보기 전까지는 마케팅 용어처럼 들릴 수 있습니다. 기능 요청(feature request)은 코드 덩어리가 되는 것이 아니라, 검토 가능한 세 가지 파일인 요구사항(requirements), 설계(design), 작업(tasks)으로 변환됩니다. 당신은 각 단계에서 루프(loop) 안에 머물게 됩니다. 에이전트가 타이핑을 하고, 당신은 판단을 유지합니다.

Kiro가 아닌 것에 대해 정확히 짚고 넘어갈 가치가 있습니다. Kiro는 콘솔에서 프로비저닝하는 AWS 클라우드 서비스가 아니며, 코드를 작성하기 위해 당신을 AWS 인프라에 종속시키지도 않습니다. 이것은 데스크톱 IDE입니다. 어떤 프로젝트든 지정하여 사용할 수 있습니다.

명세 기반 개발(Spec-driven development): 핵심 아이디어

대부분의 AI 코딩 도구는 첫 키 입력까지의 속도(speed-to-first-keystroke)를 최적화합니다. 반면, 명세 기반 개발(Spec-driven development)은 의도에 대한 정확성(correctness-to-intent) — 즉, 코드가 당신이 실제로 의도한 바와 일치하는가 — 을 최적화합니다. Kiro는 우리가 빠르게 움직일 때 보통 건너뛰는 엔지니어링의 과정, 즉 무언가를 만들기 전에 무엇을 만들 것인지 기록하는 과정을 공식화함으로써 이를 수행합니다.

당신이 기능을 설명하면, Kiro는 세 단계에 걸쳐 명세(spec)를 생성합니다:

1. 요구사항 (Requirements)

Kiro는 당신의 프롬프트를 명시적인 수락 기준(acceptance criteria)을 포함한 사용자 스토리(user stories)로 변환하며, 이는 **EARS 표기법 (EARS notation, Easy Approach to Requirements Syntax)**으로 작성됩니다. EARS는 테스트 가능한 요구사항을 작성하기 위한 가볍고 실질적인 기법으로, _"[트리거]할 때, 시스템은 [응답]해야 한다"_와 같은 패턴을 사용합니다. 이 방식의 가치는 코드가 존재하기 _전_에 모호함을 드러낸다는 점에 있습니다. 만약 당신의 한 줄짜리 프롬프트가 불충분하게 정의되었다면, 이를 요구사항 초안에서 확인할 수 있으며, 디버깅 세션을 거친 후가 아니라 단 몇 초 만에 수정할 수 있습니다.

2. 설계 (Design)

다음으로, Kiro는 기술 설계(technical design)를 생성합니다: 아키텍처(architecture), 컴포넌트(components), 데이터 흐름(data flow), 그리고 구현 접근 방식(implementation approach)을 포함합니다. 이는 시니어 엔지니어가 코드베이스를 건드리기 전에 통상적으로 작성하는(또는 주니어 엔지니어가 작성해주길 바라는) 문서입니다. 당신은 이를 검토하고, 이의를 제기하며, 정교하게 다듬습니다.

3. 작업 (Tasks)

마지막으로, 설계는 순차적인 작업 목록(task list)이 됩니다. 이는 에이전트가 순서대로 구현할 개별적이고 추적 가능한 작업 단위입니다. 작업이 명시적이기 때문에 책임 소재를 명확히 할 수 있습니다. 즉, 블랙박스를 신뢰하는 대신 무엇이 완료되었고, 무엇이 진행 중이며, 무엇이 남았는지 확인할 수 있습니다.

그 결과로 얻는 보상은 유지보수성(maintainability)입니다. 저장소(repo)에 존재하는 명세는 부식되지 않는 문서가 됩니다. 왜냐하면 그것이 에이전트가 구축한 근간이기 때문입니다. 6개월 후에도 요구사항과 설계 파일은 코드가 왜 그런 모습인지에 대한 _이유(why)_를 설명해 줍니다.

에이전트 훅 (Agent hooks): 스스로 실행되는 자동화

두 번째 기둥은 **에이전트 훅 (agent hooks)**입니다. 이는 IDE에서 특정 상황이 발생했을 때 에이전트 프롬프트(agent prompts)나 셸 명령(shell commands)을 실행하는 자동화된 트리거(triggers)입니다. 린터(linter)를 실행하거나, 테스트를 재생성하거나, 비밀 정보(secrets)를 스캔하는 것을 일일이 기억할 필요 없이, 이러한 작업들을 이벤트(events)에 한 번 연결해 두면 더 이상 신경 쓸 필요가 없습니다.

훅은 다음과 같은 상황에서 트리거될 수 있습니다:

파일 이벤트 (File events) — 파일이 생성, 저장 또는 삭제될 때
프롬프트 및 에이전트 생명주기 이벤트 (Prompt and agent lifecycle events) — 프롬프트 제출, 에이전트 중지, 도구 사용 전/후(pre/post tool use)
스펙 태스크 이벤트 (Spec task events) — 태스크가 실행되기 전 또는 실행된 후
수동 트리거 (Manual triggers) — 필요할 때 직접 누르는 버튼

내부적으로 훅은 단순한 JSON 파일입니다. 워크스페이스 수준(Workspace-level)의 훅은 .kiro/hooks/에 저장되며, 사용자 수준(user-level)의 훅은 ~/.kiro/hooks/에 저장됩니다. 훅을 만드는 방법은 세 가지가 있습니다: 원하는 내용을 평이한 영어로 설명하여 Kiro가 JSON을 생성하게 하거나, 양식을 채우거나, 직접 JSON을 작성하는 것입니다. 이를 실무에 적용하면, 파일을 저장할 때마다 훅이 자동으로 테스트와 보안 스캔을 실행할 수 있어, 문제가 한 시간 뒤 CI(지속적 통합) 단계가 아닌 도입되는 즉시 드러나게 할 수 있습니다.

스티어링 파일 (Steering files): 반복되는 작업 멈추기

만약 채팅창에 "기억하세요, 우리는 스페이스 대신 탭을 사용하고, Jest 대신 Vitest를 사용하며, 레거시 모듈에서는 절대 임포트하지 마세요"라는 말을 수백 번 반복해서 붙여넣은 적이 있다면, **스티어링 파일 (steering files)**이 해결책입니다. 스티어링은 마크다운(markdown) 파일을 통해 프로젝트에 대한 지속적인 지식을 Kiro에게 제공하므로, 매 세션마다 다시 설명할 필요 없이 컨벤션(conventions), 라이브러리(libraries), 표준(standards)을 일관되게 적용할 수 있습니다.

스티어링 파일은 두 가지 범위로 지정할 수 있습니다:

**워크스페이스 스티어링 (Workspace steering)**은 .kiro/steering/에 위치하며 해당 프로젝트에만 적용됩니다.
**글로벌 스티어링 (Global steering)**은 사용자가 구축하는 모든 작업에 적용됩니다.

이것은 본질적으로 코딩 에이전트 (coding agent)에 적용되는 컨텍스트 엔지니어링 (context engineering)입니다. 즉, 에이전트가 저장소를 처음 보는 계약직 작업자가 아니라, 당신의 스타일 가이드를 읽은 팀 동료처럼 행동할 수 있도록 에이전트에게 필요한 지속적인 지식 (durable knowledge)을 인코딩하는 것입니다. 만약 이 이면에 있는 규율에 대해 깊이 있게 파고들고 싶다면, 에이전트를 위한 지속성 메모리 (persistent memory) 및 컨텍스트 전략 (context strategy)은 저희의 컨텍스트 엔지니어링 및 에이전트 메모리 코스에서 처음부터 끝까지 다루고 있습니다.

MCP 및 에이전트형 채팅 (agentic chat)

명세 (specs), 훅 (hooks), 스티어링 (steering) 외에도, Kiro는 현대적인 AI 에디터에서 기대할 수 있는 기능들을 제공합니다. Kiro는 외부 도구 및 데이터 소스를 에이전트에 연결하기 위한 **모델 컨텍스트 프로토콜 (Model Context Protocol, MCP)**을 지원하며, 전체 명세를 작성할 만큼은 아니지만 즉석에서 처리해야 하는 작업을 위해 파일, URL, 문서에 대한 컨텍스트 제공자 (context providers)를 포함한 에이전트형 채팅 (agentic chat) 기능을 포함하고 있습니다.

MCP 지원은 들리는 것보다 더 중요합니다. 이는 에이전트가 각 도구마다 별도의 맞춤형 연결 코드 (bespoke glue)를 만들지 않고도 당신의 데이터베이스, 티켓팅 시스템, 내부 문서에 접근할 수 있게 해주는 개방형 표준 (open standard)입니다. MCP가 생소하다면, MCP 서버를 구축하고 통합하는 것 자체가 하나의 기술 영역입니다. 저희의 MCP 코스에서는 실제 서버를 구축하고 이를 에이전트형 워크플로 (agentic workflows)에 연결하는 과정을 안내합니다.

Kiro와 함께하는 첫 한 시간

워크플로를 이해하는 가장 빠른 방법은 실제 작은 기능을 대상으로 루프 (loop)를 한 번 경험해 보는 것입니다. 실제로는 다음과 같은 방식으로 진행됩니다:

기능을 일반 언어로 설명합니다. 단순히 '앱 만들기'가 아니라, '사용자의 최근 5개 주문을 페이지네이션하여 반환하는 엔드포인트를 추가한다'와 같이 구체적인 내용이어야 합니다.
요구사항을 검토합니다. Kiro는 사용자 스토리(user stories)와 인수 조건(acceptance criteria)을 초안 작성합니다. 여기서 모호성을 발견할 수 있습니다. 전체 5개 주문을 의미했는지, 아니면 페이지당 5개를 의미했는지 말이죠? 명세서에서 수정하면 비용이 들지 않습니다.
설계를 검토합니다. 제안된 아키텍처가 코드베이스의 관례와 일치하는지 확인하세요. 만약 그렇지 않다면, 그것은 스티어링 파일(steering files)에 해당 관례를 포착해야 한다는 신호입니다.
작업 목록을 실행하게 합니다. 에이전트가 순차적으로 작업을 구현하고, 사용자는 판단이 필요한 지점에서 지켜보고 개입합니다.
훅 하나를 연결합니다. 단지 '저장 시 테스트 실행'과 같은 하나의 훅만으로도 세션의 느낌이 달라집니다. 피드백이 지연되는 것이 아니라 즉각적으로 오기 때문입니다.

이렇게 한 번 해보면, '작업 단위로서 명세서(specs as the unit of work)'라는 추상적인 개념이 구체화됩니다. 이 규율은 무겁지 않습니다. 다만 선행 작업(front-loaded)이 필요하며, 그 선행 작업이야말로 배포되지 않은 버그들을 조용히 회피하게 해주는 부분입니다.

Kiro 대 바이브 코딩 (vibe coding)

'바이브 코딩(Vibe coding)'이란 느낌에 의존하여 앱을 만들기 위해 프롬프트를 사용하는 방식이며, 모델이 생성하는 모든 것을 받아들이는 것입니다. 이는 프로토타입, 일회성 스크립트, 그리고 학습에는 진정으로 유용합니다. 하지만 이 '프로토타입'이 조용히 운영 환경(production)이 될 때 많은 팀들이 어려움을 겪기도 합니다.

Kiro는 어떤 면에서 구조화된 반대 개념입니다. 명세 단계는 바이브 코딩이 건너뛰는 요구사항 및 설계 사고방식을 강제합니다. 이것이 바이브 코딩을 잘못되었다고 만드는 것은 아닙니다. 단지 서로 다른 순간을 위한 도구로 만들어줄 뿐입니다. 일회성 스크립트를 만들기 위해 명세를 찾는 것은 과도한 조치(overkill)이며, 결제 흐름에 대해 바이브 코딩하는 것은 문제를 일으키기 쉽습니다. 어떤 모드가 어떤 작업에 적합한지 아는 것이 실제 기술이며, 이는 프롬프트-앱 속도와 구조화된 엔지니어링을 경쟁자가 아닌 보완적인 철학으로 다루는 저희의 vibe coding course의 핵심 주제입니다.

Kiro만이 유일한 존재는 아닙니다. 에이전트형 IDE (agentic IDE) 분야는 이미 포화 상태이며, 도구 간의 기능이 겹치기도 합니다. 몇 가지 솔직한 차이점을 정리하자면 다음과 같습니다:

Cursor는 빠른 에디터 내 생성 (in-editor generation), 다중 파일 편집 (multi-file edits), 그리고 에이전트 모드 (agent mode)를 중심으로 구축된 AI 네이티브 에디터 (AI-native editor)입니다. 이 도구의 핵심은 흐름을 끊지 않는 유연한 코딩 (fluid, in-the-flow coding)에 있습니다.
Claude Code는 터미널 우선 (terminal-first) 에이전트 도구로, 명령줄 (command line)에서 다중 파일 변경, git 작업, 그리고 CI 인지 작업 (CI-aware work)에 탁월한 성능을 보입니다.
Kiro는 구현 전 요구사항과 설계를 앞단에 배치함으로써, '명세 (spec)' 자체를 결과물 (artifact)로 만든다는 점에서 차별화됩니다.

이 도구들은 서로 배타적인 관계가 아닙니다. 많은 엔지니어들이 여러 도구를 사용하며 작업에 따라 전환하여 사용합니다. 중요한 메타 기술 (meta-skill)은 특정 에디터에 대한 충성도가 아니라, 이 카테고리 전체에 대한 능숙함입니다. 만약 이러한 도구들을 체계적으로 배우고 싶다면, 저희는 Claude Code를 활용한 에이전트형 코딩 (agentic coding with Claude Code)과 전문가 수준의 Cursor 활용 (Cursor as a pro)에 대한 전용 실습 과정을 운영하고 있습니다. 두 과정 모두 단순한 데모가 아닌, 실제 다중 파일 및 실제 리포지토리 (real-repo) 워크플로우를 중심으로 구성되었습니다.

가격 (Pricing)

이 글을 작성하는 시점을 기준으로, Kiro는 에이전트 상호작용 (agent interactions) 횟수로 측정되는 크레딧 기반 모델을 사용합니다. 일일 또는 주간 제한이 없으며, 작업 도중 갑자기 차단되는 상황을 방지하기 위해 초과 사용량은 선불로 결제됩니다:

Free — 사용자당 월 50회의 에이전트 상호작용 (실험용으로는 적합하나, 본격적인 일상 업무용으로는 부족함)
Pro — 사용자당 월 $19, 1,000회의 에이전트 상호작용 제공
Pro+ — 사용자당 월 $39, 3,000회의 에이전트 상호작용 제공

이 카테고리에 속하는 도구들의 가격과 등급은 자주 변경되므로, 팀 예산을 세우기 전에 Kiro의 공식 가격 페이지에서 현재 수치를 확인하시기 바랍니다. 위의 수치는 계약 내용이 아닌 현재 상태를 보여주는 스냅샷으로 간주하십시오.

Kiro가 가치 있는 경우 — 그리고 그렇지 않은 경우

명세 기반 개발 (Spec-driven development)에는 비용이 따릅니다. 즉, 명세 단계가 오버헤드 (overhead)로 작용합니다. 이 오버헤드는 작업 내용이 지속 가능하고 공유될 때 보상을 받지만, 일회성 작업일 경우에는 순수한 마찰 (friction)이 됩니다.

Kiro가 빛을 발하는 경우:

지속적으로 운영되고 유지보수될 기능을 구축 중이며, 버려질 프로토타입을 만드는 것이 아닐 때
한 명 이상의 사람(또는 한 명의 에이전트)이 코드베이스를 다루며 컨벤션 (conventions)이 중요할 때
코드가 왜 그렇게 작성되었는지에 대한 감사 가능한 추적 경로 (auditable trail)를 원할 때
매 세션마다 표준을 다시 설명하는 것에 지쳤을 때

다음과 같은 경우에는 더 가벼운 도구를 사용하세요:

탐색, 프로토타이핑, 또는 내일 바로 삭제할 스크립트를 작성 중일 때
작업 규모가 너무 작아서 명세 (spec)를 작성하는 비용이 코드를 작성하는 비용보다 더 클 때
단순히 빠른 답변이나 단일 파일 수정이 필요할 때

솔직한 견해를 말씀드리자면: 명세 기반 개발 (spec-driven development)은 하나의 규율 (discipline)이며, Kiro는 그 규율을 따르는 비용을 낮춰주는 도구입니다. 이 도구가 엔지니어링적 판단 (engineering judgment)을 대신 제공하지는 않지만, 그 판단을 적용하지 않을 핑계를 제거해 줍니다.

더 깊이 알고 싶으신가요?

Kiro와 같은 도구들은 제대로 된 엔지니어링을 수행하는 비용을 낮춰주지만, 이미 명세 (specs), 에이전트 아키텍처 (agent architecture), 컨텍스트 관리 (context management), 그리고 그 밑단의 MCP 생태계를 이해하고 있는 사람들에게 보상을 제공합니다. 그러한 기초가 바로 에이전트형 IDE (agentic IDE)를 단순한 빠른 자동 완성 도구에서 진정한 레버리지 (leverage)로 탈바꿈시키는 핵심입니다.

동유럽의 AI 교육 플랫폼인 **Cursuri-AI.ro**에서는 바로 이 스택 — 에이전트형 코딩 (agentic coding), MCP, 컨텍스트 엔지니어링 (context engineering), 그리고 현대적인 AI 네이티브 IDE 워크플로우 — 에 대한 실무적이고 프로젝트 기반의 코스를 구축하고 있습니다. 저희는 슬라이드 자료가 아닌, 실제 리포지토리(repositories)를 중심으로 대화형 AI 강사와 함께 수업을 진행합니다. 만약 Kiro를 통해 '에이전트형 엔지니어링 (agentic engineering)'이 단순한 유행어가 아닌 하나의 기술 (craft)로서 궁금해지셨다면, 저희 카탈로그가 바로 그 탐구의 시작점이 될 것입니다.