Kiro와 함께 Augmented Coding 기반 소프트웨어 개발하기

최근 개발자들이 AI Agent와 함께 소프트웨어를 구축할 때 가장 큰 어려움은 무엇일까요? 많은 개발자들은 프로덕션 레벨의 프로젝트를 AI Agent로 완성하기에 부족하다고 말합니다. 프로젝트가 진행될수록 AI와의 소통이 점점 어려워지고, 일관성 있는 결과물을 얻기 힘들어진다는 점 때문입니다. 매번 새로운 세션에서 같은 컨텍스트를 반복 설명해야 하고, AI가 내린 설계 결정들이 문서화되지 않아 프로젝트의 방향성을 잃기 쉽습니다.

AWS에서 출시한 Kiro는 바로 이러한 근본적인 문제를 해결하기 위해 등장했습니다. 이번 블로그에서는 Kiro의 스펙 중심 개발(Spec-Driven Development)을 기반으로, Kent Beck의 Augmented Coding을 함께 적용하는 방법을 살펴보겠습니다.

AI 시대, 개발 패러다임의 진화

문서화 패러다임의 역사적 변천

1970년, Winston Royce가 체계적으로 정립한 Waterfall 개발 모델이 지배했던 시대에는 문서가 곧 소프트웨어 품질의 지표였습니다. 각 단계마다 포괄적이고 상세한 문서 작성이 필수였으며, 문서 없이는 다음 단계로 진행할 수 없었습니다. 이후 1990년대 들어 Big Design Up Front 방식의 한계가 드러나면서, 2001년 Manifesto for Agile Software Development에서 “포괄적인 문서보다 작동하는 소프트웨어”를 우선시하는 새로운 가치관을 제시했습니다.

애자일은 ‘Just Enough’ 문서화를 추구했지만, 여기서 미묘한 변화가 일어났습니다. ‘필요한 만큼’이라는 기준은 개발자나 팀의 상황에 따라 달랐고, 점차 많은 개발자들이 문서화를 선택사항으로 여기게 되었습니다. 여기에 오픈소스와 온라인 커뮤니티, 고수준 플랫폼의 확산이 맞물리면서, 직접 작성해야 하는 문서의 양은 더욱 줄어들었습니다. 그 결과 많은 개발팀에서 문서화의 우선순위는 동작하는 코드에 비해 크게 낮아졌습니다.

AI가 가져온 역설적 변화: 문서의 부활

최근 AI 코딩 도구의 발전으로 ‘Vibe Coding’이라는 새로운 개발 패러다임이 등장했습니다. AI와 자연스러운 대화를 통해 즉흥적으로 코드를 생성하는 이 방식은 직관적이고 흥미로운, 마치 리듬에 맞춰 주고받는 즉흥 재즈 연주와 같은 경험을 제공합니다. 하지만 간단한 프로토타입 개발에는 효과적이었으나, 프로덕션 환경에서는 유지보수성과 확장성 문제가 발생했습니다. 특히 AI의 의사결정 과정 추적이 어렵고, 대량 생성되는 코드를 충분히 검토하지 못해 디버깅 시간이 기하급수적으로 증가하는 상황이 빈번해졌습니다.

이런 배경에서 ‘Context Engineering‘이 주목받기 시작했습니다. AI는 세션이 종료되면 이전 맥락을 잃어버리기 때문에, 연속성 있는 개발을 위해서는 일관성있게 컨텍스트를 제공할 수 있는 체계적인 문서화가 필수가 되었습니다. Memory Bank, RAG(Retrieval-Augmented Generation), 프롬프트 캐싱 등 다양한 기법이 도입되면서, 아이러니하게도 그동안 소홀했던 문서화의 가치가 AI 시대에 들어 다시 조명받고 있습니다.

Kent Beck의 Augmented Coding

이 흐름 속에서 소프트웨어 공학의 거장 Kent Beck은 ‘Augmented Coding: Beyond the Vibes’라는 글을 통해 통해 새로운 개념을 제시하며 업계의 이목을 집중시켰습니다. 그가 정의한 Augmented Coding은 AI의 도움으로 어떤 아이디어든 즉시 실험해볼 수 있는 자유를 제공하면서도, 동시에 코드 품질을 보장할 수 있는 개발 방식이라고 소개합니다. 그는 특히 이 접근법이 “프로그래밍을 다시 재미있게 만들었다”고 강조하며, AI와의 협업이 가져다주는 가능성에 주목했습니다.

Kent Beck은 AI와의 협업에서 Context Engineering을 적극 활용했습니다. 자신의 개발 철학과 원칙을 문서로 체계화하고, 그 안에 TDD(Test-Driven Development), Tidy First 원칙, 코드 작성 규범 등을 담았습니다. AI는 이를 규칙으로 참조하며 모든 작업을 수행했고, 덕분에 코드의 정확성뿐 아니라 구조적 단순성까지 유지할 수 있었습니다. 이는 단순히 프롬프트만 주고받는 Vibe Coding과 달리, 일관된 기준과 맥락 속에서 코드를 생성하게 만들었습니다.

Kiro, Spec-Driven Development 철학을 제시하다

프롬프트 기반 코드 생성 도구에서 컨텍스트 엔지니어링의 중요성이 커지는 가운데, Kiro는 근본적으로 다른 접근법을 제시합니다. Kiro는 단순한 AI 코드 생성기를 넘어, 사용자를 대신해 자율적으로 작업을 수행하는 에이전틱(Agentic) IDE입니다. 그러나 다른 IDE와 달리 Kiro는 사용자의 프롬프트를 곧바로 코드로 바꾸지 않습니다. 대신 먼저 요구사항, 시스템 설계, 구현 태스크를 구조화된 문서로 정의한 뒤 그 결과를 기반으로 코드를 생성합니다. 이 과정을 통해 Kiro는 사용자의 의도를 명확히 드러내고, 모든 설계와 구현 결정을 투명하게 기록하여 Agent가 생성한 결과물의 블랙박스 문제(참고: AI’s mysterious ‘black box’ problem, explained)를 해결합니다.

Kiro의 Spec-Driven Development는 프로덕션 수준의 소프트웨어를 만들기 위해 요구사항 정의, 설계, 태스크 분해를 필수 과정으로 삼습니다. AI는 이 명세를 참조하여 세션이 바뀌어도, 다른 개발자가 작업을 이어받아도 동일한 원칙과 구조를 유지할 수 있습니다.

Spec-Driven Development는 Kent Beck이 제시한 Augmented Coding 철학과 시너지를 손쉽게 이룰 수 있습니다. Kiro는 스티어링(Steering) 파일이라는 독특한 기능을 제공합니다. 마치 차량이 원하는 코스를 따라가게 하는 부품인 스티어링처럼 작업을 원하는 규칙 및 방향으로 진행할 수 있게 도와줍니다. 이를 통해 개발자가 자신만의 개발 원칙과 방법론을 정의할 수 있도록 지원합니다. 이는 Kent Beck이 강조한 Context Engineering의 구체적 실현이며, TDD, Tidy First 같은 검증된 개발 방법론을 AI의 작업 규칙으로 내재화할 수 있게 합니다.

즉, Spec 문서가 ‘무엇을 만들 것인가’를 정의한다면, Steering 파일은 ‘어떻게 만들 것인가’를 규정하여, AI가 단순한 코드 생성기가 아닌 숙련된 개발자의 사고방식을 따르는 진정한 협업자가 되도록 만듭니다.

Kiro를 활용하여 Augmented Coding 해보기

본격적으로 Kiro에서 제공하는 다양한 기능을 활용하여 샘플 프로젝트에 Augmented Coding 방법론을 적용해보겠습니다.

샘플 프로젝트 소개

샘플 프로젝트로 Anki 서비스를 구현해보겠습니다. Anki는 데이미언 엘름스(Damien Elmes)가 개발한 플래시카드 기반의 지능형 암기 프로그램으로, 간격 반복 학습법을 활용해 효율적인 암기를 도와주는 도구입니다. 해당 서비스를 구현하면서 Spec-Driven Development 기반의 Augmented Coding 방법론을 개발 과정에서 어떻게 적용할 수 있는지 차례대로 살펴보겠습니다.

프로젝트 초기 설정을 위한 Spec 만들기

💁 Spec은 개발하고자 하는 기능의 요구사항을 정리하고, 이를 실제 구현 계획으로 발전시켜 나가는 과정을 체계적으로 관리하기 위한 구조화된 문서입니다.

Spec은 프로젝트 전체를 위한 하나의 거대한 문서가 아닙니다. 하나의 저장소에서 필요한 만큼 여러 개의 Spec을 생성할 수 있으며, 프로젝트의 기능이나 작업 단위별로 독립적인 Spec을 분리하여 관리하는 것이 효율적입니다. 전체 코드에 대한 단일 Spec을 만들려고 시도하기보다는, 프로젝트의 다양한 기능에 대해 각각의 전용 Spec을 만드는 것을 권장합니다.

예를 들어, e-commerce 애플리케이션을 개발한다면 사용자 인증, 상품 카탈로그, 장바구니, 결제 시스템, 관리자 대시보드 등 각 기능별로 독립적인 Spec을 생성하여 관리할 수 있습니다. 이러한 방식은 개발 팀이 병렬로 Spec 작업할 수 있게 하고, 각 기능의 복잡성을 관리 가능한 수준으로 유지하는 데 도움이 됩니다.

처음 프로젝트를 설정하는 경우, 서비스를 개발하기 위한 프로그래밍 언어, 프레임워크 등을 제시하고, 프로젝트 구조를 정의하는 것이 필요합니다. 먼저 Kiro의 채팅 UI에 새로운 세션을 생성하고 Spec 요청을 선택하여 아래와 같은 프롬프트를 입력해보겠습니다. 해당 프롬프트는 Kiro를 활용하여 Meta Prompting 방식으로 생성했습니다.

간격 반복(Spaced Repetition) 알고리즘을 활용한 플래시카드 학습 앱 "MyAnki"를 개발합니다. 
완전한 클라이언트 사이드 웹 앱으로, 브라우저 로컬 스토리지를 활용해 오프라인에서도 동작합니다. 
아래 제시한 기술 스택으로 프로젝트의 초기 구조를 생성하려고 합니다. 프로젝트 폴더 구조, 필수 패키지 설치, 기본 설정 파일들(vite.config.ts, tailwind.config.js, tsconfig.json 등), 그리고 기본적인 App 컴포넌트까지 포함해서 바로 개발을 시작할 수 있는 상태로 만들어주세요.

기술 스택
- React 18+ + TypeScript (프론트엔드 프레임워크)
- Vite (빌드 도구 및 개발 서버)
- Tailwind CSS (스타일링)
- Zustand (상태 관리)
- IndexedDB + Dexie.js (로컬 데이터베이스)
- Jest + React Testing Library + MSW (테스팅)

주의 사항
- 프로젝트의 초기 구조와 관련된 Spec으로 작업 범위를 제한합니다.
- 의사 결정이 필요한 부분은 질문을 통해 답변을 얻고, 최종 문서를 생성합니다.

Kiro에서 Spec을 생성하면 Requirements(요구사항) → Design(설계) → Implementation(구현) 단계로 이어지는 워크플로우에 따라 각 단계에서 핵심 파일을 순차적으로 생성합니다. requirements.md는 구조화된 EARS(Easy Approach to Requirements Syntax) 표기법으로 사용자 스토리와 승인 기준을 정의합니다. design.md는 기술 아키텍처, 시퀀스 다이어그램, 구현 고려사항을 문서화합니다. tasks.md는 명확한 설명과 결과가 있는 세부 작업 계획을 제공합니다.

생성된 문서들은 단계별로 꼼꼼한 검토와 수정 과정을 거쳐야 합니다. 각 단계의 문서를 검토하면서 오버 엔지니어링이 되지 않도록 지시하고 수정하세요. 각 단계의 문서는 다음 단계 문서에 영향을 미치기 때문에 문서를 수정을 지시하면 Kiro는 관련된 문서를 함께 업데이트 해줍니다. 만약 직접 파일을 수정하는 경우에는 Refine 버튼을 통해 전체 Spec 문서를 업데이트할 수 있습니다.

Steering 파일로 Kiro의 반복되는 실수를 줄여보기

Kiro는 Steering 파일이라는 독특한 메커니즘을 통해 프로젝트의 핵심 컨텍스트를 체계적으로 관리합니다. ./kiro/steering/ 폴더에 저장된 이 Markdown 파일들은 개발 패턴, 라이브러리 사용법, 코딩 규칙, 프로젝트 문서 등을 담고 있으며, Kiro는 모든 작업 세션에서 이를 자동으로 참조합니다. 덕분에 개발자는 매번 프롬프트에 동일한 컨텍스트를 반복해서 입력할 필요가 없고, AI는 일관된 기준을 유지하며 작업할 수 있습니다.

Steering 파일은 Kiro의 Agent가 반복하는 실수를 방지하기 위해 사용할 수 있습니다. Agentic AI 도구들은 컨텍스트가 길어지면 성능이 저하되기 때문에, Kiro는 태스크별로 새로운 세션을 열어 작업하는 것을 권장합니다. 하지만 이 경우 각 세션마다 동일한 실수가 반복될 수 있습니다. 예를 들어, Jest가 지원하지 않는 옵션을 계속 시도하거나, 특정 라이브러리의 deprecated API를 사용하는 경우입니다. 물론 작업 과정에서 Kiro가 자체적으로 오류를 감지하고 수정을 시도하지만, 반복된 동일한 시행착오는 불필요한 토큰 소비와 시간 낭비로 이어집니다.

이때 개발자가 Steering 파일에 “작업 주의사항 및 모범사례”와 같은 가이드를 작성해두면, Kiro는 모든 세션에서 이를 참조하여 동일한 실수를 미연에 방지합니다. 이는 마치 팀의 베스트 프랙티스를 신입 개발자에게 전수하는 것처럼, AI에게도 축적된 경험과 지식을 효과적으로 전달하는 방법입니다. 따라서 프로젝트 진행 과정에서 Kiro의 반복적인 실수를 발견할 때마다 Steering 파일로 문서화하는 습관을 들이는 것이 중요합니다. 예를 들어 development-best-practice.md 같은 Steering 파일을 생성하여 실수한 내용과 해결 방법을 명시합니다.

이번 Spec 구현을 통해서 실수한 부분에 대해서 요약해줄래? 
예를 들면 React import 부분이 계속 잘못됐던 것 같아. 
반복된 실수를 줄이기 위해서 너의 잘못된 실수에 대해서 분석하고, 정리해서 Steering 파일로 만들어줘. 
파일 이름은 developement-best-practice.md로 생성해줘.

아래처럼 Steering 파일을 만들어두면, 태스크를 실행할 때 자동으로 development-best-practice.md 를 참고하는 모습을 확인할 수 있습니다.

이렇게 점진적으로 구축된 Steering 파일들은 프로젝트가 성숙해질수록 더욱 정교한 AI 가이드라인으로 진화하며, 결과적으로 Kiro와의 협업 효율성을 극대화합니다.

Steering 파일을 조건별로 컨텍스트에 포함하기

Steering 파일은 조건에 따라 컨텍스트 포함여부를 설정할 수 있습니다. 이를 통해 필요한 시점에만 특정 컨텍스트를 포함함으로써 관련성을 유지하고 불필요한 정보를 줄일 수 있습니다. 이 조건은 Steering 파일 최상단에 3개의 대시(---)로 된 블록을 통해 구성할 수 있습니다. Kiro 에서 제공하는 Steering 파일의 Inclusion Modes 전략은 아래와 같습니다.

1. Always Include: 핵심 표준 문서

developement-best-practice.md 파일과 같이 프로젝트 전반에 걸친 기준이나, 선호 기술 스택, 보안 정책, 코딩 컨벤션 등 모든 Vibe 요청에 글로벌 컨텍스트를 제공해야 하는 경우, 아래처럼 파일 상단에 inclusion: always를 통해 설정이 가능합니다.

---
inclusion: always
---

2. Conditional Inclusion: 레이어별 컨텍스트 관리

만약 컴포넌트 패턴이나 API 디자인 규칙 등과 같이 특정 도메인에 특화된 기준을 제공해야하는 경우 fileMatch 방식으로 Steering 파일을 설정할 수 있습니다. 이 경우에는 아래와 같이 별표(*)를 통해서 파일의 패턴에 따라 포함 여부를 지정할 수 있습니다. 예를 들면 API 엔드포인트를 위한 컨트롤러 레이어를 담당하는 코드 파일의 경우 api-specification.md 파일을 fileMatch를 통해 컨텍스트로 추가할 수 있습니다.

---
inclusion: fileMatch
fileMatchPattern: "components/**/*.tsx"
---

3. Manual Inclusion: 필요시 참조 문서

트러블슈팅이나 큰 컨텍스트 사이즈의 문서 등을 제공하는 등 간헐적으로 사용되는 Steering 파일의 경우에는 manual 방식을 통해 필요한 경우에만 참조하도록 할 수 있습니다. 이 때는 Vibe, Spec 요청 시에 #steering-file-name 등과 같이 Steering 파일 이름 앞에 # 기호를 붙여 참조시킬 수 있습니다.

---
inclusion: manual
---

Kiro의 기본 Steering 파일로 전체 프로젝트 필수 내용 정리하기

프로젝트 초기 구조가 완성되면, 이제 전체 서비스의 주요 컨텍스트도 Steering 파일로 체계화할 차례입니다. Spec 문서가 개별 기능이나 마일스톤별 상세 구현을 다룬다면, Kiro의 기본 Steering 파일은 프로젝트 전체의 큰 그림을 담습니다. 서비스 비전, 핵심 기능 목록, 기술 스택, 아키텍처 원칙 등 모든 Spec에서 공통으로 참조해야 할 정보들을 Steering 파일로 정리함으로써, 각각의 기능 개발이 전체 서비스의 일관된 방향성을 유지하도록 보장합니다. 쉽게 생각하면 프로젝트 전반적인 나침반 역할을 하는 것입니다.

이런 용도의 문서는 사용자가 직접 Steering 문서로 추가할 수도 있지만, Kiro는 “Generate project steering documents”라는 기능을 통해 아래의 3가지 주요 Steering 파일을 자동으로 생성해주는 기능을 제공합니다.

product.md – 이 파일에는 만들고자 하는 제품의 목적, 타겟 유저나 주요 기능 등과 같이 비즈니스적인 관점의 정보가 생성됩니다. 이를 통해 Kiro가 여러분이 구축하고자 하는 제품의 목표에 적합한 솔루션을 제안하고, 기술적 결정을 내릴 때 참고할 수 있게 됩니다.
tech.md – 이 파일에는 프레임워크, 라이브러리, 개발 도구나 기술적 제약 사항 등과 같은 기술적인 내용이 생성됩니다. Kiro는 구현 내용을 제안할 때, 이 문서의 내용을 우선적으로 고려하여 제안하게 됩니다.
structure.md – 이 파일에는 파일 구조나 네이밍 컨벤션, 임포트 패턴이나 아키텍쳐 결정 사항 등의 정보가 생성됩니다. 이를 통해 Kiro가 생성하는 새로운 코드가 기존 코드 베이스와 원활하게 통합되도록 할 수 있습니다.

이 3가지 파일은 비즈니스, 기술 그리고 실제 구현에 대한 핵심적인 내용을 정의함으로써 프로젝트 전반에 걸쳐 일관성을 유지하고, AI가 프로젝트의 큰 그림을 파악할 수 있도록 하여 높은 품질의 코드를 생성할 수 있도록 합니다.

Custom Steering 파일로 Agumented Coding 방법론 적용해보기

Kiro에서 실제 구현은 Spec의 태스크 단위로 진행되므로, Augmented Coding 방법론을 효과적으로 적용하려면 태스크 생성 단계부터 개발 원칙을 반영해야 합니다. 이를 위해 Kent Beck의 TDD, Tidy First 같은 개발 철학을 Steering 파일로 문서화하고, Spec 생성 과정에서(정확하게 말하면 tasks.md 생성 시) 이를 참조하도록 설정할 수 있습니다.

예를 들어 kentbeck-augmented-coding.md라는 Steering 파일에 “구조적 변경과 동작적 변경을 분리하라”, “Red-Green-Refactor 사이클을 따르라” 같은 원칙을 명시하면, Kiro는 자동으로 이를 준수하는 세부 태스크를 생성할 수 있습니다. 이렇게 개발 방법론이 태스크 레벨까지 스며들어, 모든 구현 과정이 검증된 엔지니어링 원칙을 따르게 됩니다.

아래는 Kent Beck의 “Augmented Coding: Beyond the Vibes” 글에서 제시된 시스템 프롬프트를 참고하여, Kiro를 활용한 Meta Prompting 방식으로 프롬프트를 생성하고 Steering 파일로 정리한 예시입니다.

---
inclusion: always
---

# 역할 및 전문성
귀하는 Kent Beck의 테스트 주도 개발(TDD) 및 Tidy First 원칙을 따르는 선임 소프트웨어 엔지니어입니다. 귀하의 목적은 Spec-Driven Development 철학을 기반으로 이러한 방법론을 정확하게 따르도록 개발을 안내하는 것입니다.
특히 Spec 문서는 이러한 방법론을 기반으로 작성되어야 합니다. 특히 Task를 위한 문서를 작성하는 경우, 아래 핵심 개발 원칙을 준수할 수 있도록 작은 단위의 작업으로 구성합니다.
# 핵심 개발 원칙
- 항상 TDD 주기(Red → Green → Refactor)를 따르세요.
- 가장 간단한 실패하는 테스트를 먼저 작성하세요.
- 테스트를 통과하는 데 필요한 최소한의 코드를 구현하세요.
- 테스트가 통과된 후에만 리팩터링하세요.
- Beck의 "Tidy First" 접근 방식을 따라 구조적 변경과 동작적 변경을 분리하세요.
- 개발 전반에 걸쳐 높은 코드 품질을 유지하세요.
# TDD 방법론 안내
- 기능의 작은 증분을 정의하는 실패하는 테스트를 작성하는 것부터 시작하세요.
- 동작을 설명하는 의미 있는 테스트 이름을 사용하세요(예: "shouldSumTwoPositiveNumbers").
- 테스트 실패를 명확하고 유익하게 만드세요.
- 테스트를 통과시키는 데 필요한 만큼의 코드만 작성하세요. 그 이상은 안 됩니다.
- 테스트가 통과되면 리팩터링이 필요한지 고려하세요.
- 새 기능에 대해 주기를 반복하세요.
# Tidy First 접근 방식
- 모든 변경 사항을 두 가지 유형으로 분리하세요.
    1. 구조적 변경: 동작을 변경하지 않고 코드를 재구성합니다(이름 바꾸기, 메서드 추출, 코드 이동).
    2. 동작적 변경: 실제 기능을 추가하거나 수정합니다.
- 구조적 변경과 동작적 변경을 같은 커밋에 혼합하지 마세요.
- 둘 다 필요한 경우 항상 구조적 변경을 먼저 하세요.
- 구조적 변경을 수행한 전후에 테스트를 실행하여 동작이 변경되지 않았는지 확인하세요.
# 커밋 규율
- 다음 경우에만 커밋하세요.
    1. 모든 테스트가 통과되었습니다.
    2. 모든 컴파일러/린터 경고가 해결되었습니다.
    3. 변경 사항이 단일 논리적 작업 단위를 나타냅니다.
    4. 커밋 메시지에 구조적 변경인지 동작적 변경인지 명확하게 명시합니다.
- 대규모의 드문 커밋보다는 작고 빈번한 커밋을 사용하세요.
# 코드 품질 표준
- 중복을 철저히 제거하세요.
- 이름과 구조를 통해 의도를 명확하게 표현하세요.
- 종속성을 명시적으로 만드세요.
- 메서드를 작고 단일 책임에 집중하도록 유지하세요.
- 상태와 부작용을 최소화하세요.
- 가능한 가장 간단한 솔루션을 사용하세요.
# 리팩터링 가이드라인
- 테스트가 통과된 후에만 리팩터링하세요("Green" 단계).
- 올바른 이름의 확립된 리팩터링 패턴을 사용하세요.
- 한 번에 한 가지 리팩터링 변경을 하세요.
- 각 리팩터링 단계 후에 테스트를 실행하세요.
- 중복을 제거하거나 명확성을 개선하는 리팩터링을 우선시하세요.
# 예시 워크플로
새로운 기능에 접근할 때:
1. 기능의 작은 부분에 대한 간단한 실패 테스트를 작성하세요.
2. 이를 통과시키는 데 필요한 최소한의 코드를 구현하세요.
3. 테스트를 실행하여 통과하는지 확인하세요(Green).
4. 필요한 구조적 변경(Tidy First)을 수행하고 각 변경 후 테스트를 실행하세요.
5. 구조적 변경 사항을 별도로 커밋하세요.
6. 기능의 다음 작은 증분에 대한 추가 테스트를 추가하세요.
7. 기능이 완료될 때까지 반복하고, 구조적 변경과 별도로 동작적 변경을 커밋하세요.
이 프로세스를 정확하게 따르고, 빠른 구현보다 항상 깨끗하고 잘 테스트된 코드를 우선시하세요.
항상 한 번에 하나의 테스트를 작성하고, 실행시킨 다음, 구조를 개선하세요. 항상 모든 테스트(장기 실행 테스트 제외)를 실행하세요.

Kiro 에게 서비스 구현을 위한 마일스톤 제안받기

이제 본격적인 서비스 구현 단계에 진입합니다. 전체 서비스를 한 번에 개발하는 대신, 여러 개의 마일스톤으로 나누어 각각을 독립적인 Spec으로 관리하는 것이 Spec-Driven Development의 권장사항입니다. Kiro에게 프로젝트의 복잡도와 의존성을 분석하여 적절한 크기의 마일스톤을 제안해달라고 요청해보겠습니다. 아래의 프롬프트는 Meta Prompting 방식으로 Kiro가 제안한 마일스톤 계획 생성을 위한 프롬프트입니다.

현재 MyAnki 서비스의 전체 기능을 분석하여 실행 가능한 마일스톤 계획을 수립해주세요. 마일스톤 설계 기준은 아래와 같습니다.
- 하나의 마일스톤이 하나의 Spec으로 관리될 수 있도록 명확한 경계를 설정합니다.
- 마일스톤 간 순서와 의존성을 명확히 파악하여 순차적/병렬 진행 가능 여부 표시합니다.

아래는 Kiro가 제시한 마일스톤 계획입니다. 이 마일스톤 계획을 Steering 파일로 저장하고, 향후 각 마일스톤에 해당하는 Spec을 생성할때 활용합니다. 항상 참조하는 문서는 아니기 때문에 inclusion은 manual 타입으로 생성합니다.

---
inclusion: manual
---

MyAnki 서비스 완성을 위한 마일스톤 계획

마일스톤 1: 플래시카드 데이터 모델 및 기본 CRUD 기능
의존성: 프로젝트 설정 완료 (✅ 완료됨) 예상 기간: 1-2주

핵심 데이터 모델(Deck, Card, StudySession)을 설계하고 기본적인 생성, 읽기, 수정, 삭제 기능을 구현합니다.

마일스톤 2: 덱 관리 시스템
의존성: 마일스톤 1 완료 예상 기간: 1-2주

사용자가 플래시카드 덱을 생성, 편집, 삭제할 수 있는 관리 인터페이스를 구현합니다.

마일스톤 3: 카드 편집 시스템
의존성: 마일스톤 2 완료 예상 기간: 1-2주

Basic 타입 노트(앞면/뒷면)를 생성하고 편집할 수 있는 카드 에디터를 구현합니다.

마일스톤 4: 간격 반복 알고리즘 엔진
의존성: 마일스톤 1 완료 (마일스톤 2, 3과 병렬 진행 가능) 예상 기간: 2-3주

SM-2 또는 유사한 간격 반복 알고리즘을 구현하여 학습 스케줄링을 담당합니다.

마일스톤 5: 학습 세션 시스템
의존성: 마일스톤 3, 4 완료 예상 기간: 2-3주

실제 학습 인터페이스를 구현하여 사용자가 카드를 학습하고 답변을 평가할 수 있게 합니다.

마일스톤 6: 학습 통계 및 진행률 추적
의존성: 마일스톤 5 완료 예상 기간: 1-2주

학습 진행률, 통계, 성과 분석 기능을 구현합니다.

첫 번째 마일스톤 Spec 생성하기

Kiro는 자신이 생성한 마일스톤을 기반으로 첫 번째 마일스톤을 위한 Spec 생성을 제안합니다. 즉, “마일스톤 1: 플래시카드 데이터 모델 및 기본 CRUD 기능”에 대해서 requirements.md, design.md 파일을 순차적으로 생성하는 워크플로우를 실행합니다. 다시 강조하지만 이 과정에서 생성되는 모든 문서는 꼼꼼하게 검토해야 합니다. 문서의 내용이 잘못됐는지, 혹은 오버 엔지니어링 측면이 없는지 살펴봅니다.

마지막 단계인 tasks.md 파일을 작성하기 전에는 명시적으로 Kiro에게 우리가 생성한 kentbeck-agumented-coding.md 파일의 내용을 바탕으로 태스크를 만들어달라고 요청해보겠습니다. 채팅 입력칸에 # 입력 후 특정 파일을 지정할 수 있습니다. Kiro는 해당 Steering 파일을 참고해서 태스크 그룹을 만들어줍니다.

아래처럼 Kent Beck의 TDD 및 Tidy First 방법론을 적용하여 태스크를 분리한 구현 계획이 tasks.md 파일로 완성됐습니다. 구조적 변경과 동작적 변경이 잘 구분됐는지, TDD 주기(Red → Green → Refactor)를 따르도록 세부 태스크가 정리됐는지 꼼꼼하게 검토를 합니다.

# Implementation Plan
- [ ] 1.1 플래시카드 기본 타입 정의 (구조적 변경)
  - src/types/flashcard.ts 파일 생성
  - Deck, Card, StudySession, StudyQuality 인터페이스 정의
  - 기본 타입 검증을 위한 간단한 테스트 작성
  - _Requirements: 1.2_
- [ ] 1.2 서비스 인터페이스 정의 (구조적 변경)
  - CRUDService 제네릭 인터페이스 정의
  - 각 서비스별 특화 인터페이스 정의 (IDeckService, ICardService, IStudyService)
  - 타입 안전성 검증을 위한 컴파일 테스트 작성
  - _Requirements: 6.1_
- [ ] 1.3 에러 타입 시스템 정의 (구조적 변경)
  - MyAnkiError 클래스 및 ErrorCode enum 정의
  - 에러 타입별 생성자 테스트 작성
  - 에러 메시지 포맷 검증 테스트 작성
  - _Requirements: 5.3_

... 생략 ...

AGENT HOOK을 활용하여 구현 과정에 필요한 자동화 프로세스 구축하기

Kiro에서 제공하는 Agent Hook 기능은 IDE에서 특정 이벤트(파일 저장, 생성, 삭제 등)가 발생할 때 미리 정의된 에이전트 작업을 자동으로 실행하는 강력한 자동화 도구입니다. Hook을 통해 코드 품질 유지, 보안 취약점 예방, 팀 프로세스 표준화 등을 실현할 수 있으며, 작은 프로젝트부터 대규모 코드베이스까지 일상적인 작업을 자동화하고 일관성 있게 처리할 수 있습니다. Agent Hook 기능은 On File Create(파일 생성 시), On File Save(파일 저장 시), On File Delete(파일 삭제 시), Manual Trigger(수동 트리거) 등 다양한 트리거 타입을 지원하여 각각의 자동화 시나리오에 맞게 설계되어 있습니다.

예를 들어, 태스크를 실제로 실행하여 구현을 완료한 후 파일의 변경사항을 커밋하는 워크플로우를 구성하려고 합니다. 태스크 자체에는 커밋 동작에 대한 내용이 포함되어 있지 않기 때문에, 이를 별도의 Hook으로 정의하여 수동으로 실행할 계획입니다. 먼저 일관된 커밋 메시지 작성을 위해 “Conventional Commit Messages Specification” 문서를 Steering 문서로 작성하겠습니다. 이 문서는 커밋을 수행할 때만 참고하면 되므로, inclusion 조건을 manual로 설정하여 필요시에만 활용하도록 구성합니다.

---
inclusion: manual
---

# Conventional Commit Messages Specification
## 기본 구조
```
<타입>[선택적 범위]: <설명>
[선택적 본문]
[선택적 푸터]
```
## 주요 타입
| 타입 | 설명 | 시맨틱 버저닝 |
|:---|:---|:---|
| `feat` | 새로운 기능 추가 | MINOR |
| `fix` | 버그 수정 | PATCH |
| `BREAKING CHANGE` | 호환성을 깨는 변경사항 | MAJOR |
## 기타 권장 타입
- `build`: 빌드 시스템 관련
- `chore`: 기타 작업 
- `ci`: CI 설정 관련
- `docs`: 문서 관련
- `style`: 코드 스타일 (포맷팅, 세미콜론 등)
- `refactor`: 리팩토링
- `perf`: 성능 개선
- `test`: 테스트 관련
## 핵심 규칙
... 생략 ...

실제 Kiro의 Hook을 하나 생성해보겠습니다. 잘 활용되는 액션은 설명 하단에 기본으로 제공되고, 그 외 액션은 직접 설명을 자연어로 입력하게 됩니다. 설명을 작성할 때 # 을 통해 프로젝트 파일을 참조하게 할 수 있습니다. 설명을 작성한 이후에 엔터를 입력합니다.

놀랍게도 Kiro는 해당 사용자가 작성한 설명을 분석하여 Hook 에이전트를 위한 명령(instruction) 프롬프트를 만들어줍니다. 사용자는 어떤 이벤트에 Hook을 트리거할 지 결정하고, 프롬프트를 검토하면 됩니다. 이번 예제에서는 Git 커밋이 필요할 때 수동으로 트리거하기 위해 이벤트 타입은 Manual Trigger로 설정하겠습니다.

간단하게 Hook 동작을 테스트 해보겠습니다. 태스크 하나를 실행하여 작업을 수행하고, 완료된 상태에서 수동으로 Hook을 실행합니다. 아래처럼 Hook 에이전트는 필요한 git 명령어(add, status, diff)를 터미널을 통해 수행하면서, 변경사항을 파악합니다.

결과적으로 Kiro는 아래와 같은 커밋 메시지를 작성하고 commit 명령어를 실행하게 됩니다.

git commit -m "feat(flashcard): 플래시카드 데이터 모델 및 기본 구조 구현

- Deck, Card, StudySession 엔티티 타입 정의
- MyAnkiDB에 플래시카드 관련 테이블 추가
- 서비스 레이어 인터페이스 구조 설계
- 에러 처리를 위한 커스텀 에러 타입 추가
- 데이터베이스 및 타입에 대한 테스트 코드 작성
- 스펙 문서 업데이트 및 개발 컨벤션 추가"

손쉽게 태스크 구현 작업 시작하기

본격적인 태스크 작업을 시작해보겠습니다. Kiro는 완성된 tasks.md 파일을 분석하여 각 태스크에 “Start task” 버튼을 자동으로 UI에 표시합니다. 사용자는 이 버튼을 클릭하여 손쉽게 태스크 작업을 시작할 수 있습니다.

효율적인 개발 워크플로우를 위해서는 작업 단위를 최대한 작게 나누고, 검토와 커밋을 체계적으로 진행하는 것이 중요합니다. 이러한 작업 방식을 고려할 때 태스크를 순차적으로 실행하는 것을 권장합니다.

각 태스크는 하위 세부 태스크로 분해되어 나열됩니다. 세부 태스크는 위에서 설정한 Agumented Coding을 위한 지시사항을 따르도록 구성됩니다. 사용자가 태스크 시작을 실행하면 필요한 코드 생성과 수정 작업이 Agentic 모드로 자동 처리됩니다. 테스트와 같은 쉘 명령어는 터미널에서 실행되며, 그 결과는 채팅 UI와 자동으로 연동되어 끊김없는 작업 환경을 제공합니다. 태스크가 완료되면 시스템에서 자동으로 완료 상태로 표시됩니다.

개별 태스크 단위로 작업할 수 있지만, 때로는 여러 태스크를 연속해서 모두 실행하고 싶은 경우가 있습니다. 이런 상황에서는 Kiro의 채팅 UI에서 새로운 세션을 열고 해당 tasks.md 파일을 지정하여 작업 범위를 설정할 수 있습니다. 다만 각 작업이 오래 걸리는 경우 하나의 세션에 과도한 컨텍스트가 누적될 수 있으므로, 적절한 수준에서 태스크 수행을 분할하여 지시하는 것이 중요합니다.

MCP(Model Context Protocol) 활용하기

Kiro에서도 MCP (Model Context Protocol) 서버와 연결을 지원하고 있습니다. 다양한 MCP 서버를 활용하여 Kiro의 기능을 확장할 수 있습니다. Kiro에서 MCP 서버 연결은 다른 MCP 호스트 애플리케이션에서 구성하는 방식과 유사하게 아래와 같이 JSON 형식으로 configuration 파일을 작성하면 됩니다. configuration은 모든 워크스페이스에 활용해야 하는 경우, ~/.kiro/settings/mcp.json 경로에 작성하고, 현재 워스페이스에만 적용하고 싶은 경우, ./kiro/settings/mcp.json 경로에 작성하면 됩니다. 또한, 2025년 8월 기준, Kiro는 local stdio 방식의 연결만 지원하며, 만약 리모트 서버와 연결해야하는 경우 mcp-remote를 활용하여 연결할 수 있습니다.

{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": [
        "run", 
        "-i", 
        "--rm", 
        "-e", 
        "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "YOUR_GITHUB_ACCESS_TOKEN"
      },
      "disabled": false,
      "autoApprove": []
    }
  }
}

위 방법을 통해서 GitHub MCP 서버를 Kiro에 연결해보겠습니다. 그럼 GItHub MCP 서버를 위한 컨테이너가 로컬 환경에서 실행되고, Kiro가 이 서버와 연결됩니다. 연결이 성공적으로 이뤄지면, 아래와 같이 GitHub MCP 서버에서 제공하는 도구들을 확인할 수 있습니다.

테스트를 위해서 GitHub 레포지토리를 생성하여 코드를 푸시하고, README.md 파일에 sequence diagram을 생성해달라는 issue를 생성해두었습니다. 이후에 Kiro 채팅창에 “GitHub mcp tool을 활용하여 kiro-sample-myanki의 issue를 찾고 해결해줘.”라는 요청을 하게되면, 왼쪽 아래 그림과 같이 GitHub MCP 서버의 도구를 사용하여 레포지토리의 이슈를 조회하고, 이슈의 내용을 파악하여 필요한 코드를 스스로 작성하게 됩니다.

이처럼 MCP 서버를 활용하여 GitHub, Jira, Figma 등 다양한 외부 도구와 Kiro를 유연하게 연결할 수 있습니다. 이를 통하여 단순한 AI 코딩 어시스턴트의 기능을 확장하여 개발 워크플로우와 통합하여 생산성을 크게 향상 시킬 수 있습니다.

완성된 MVP 서비스를 Vibe 요청으로 완성도 높이기

💁 아래 그림은 Kiro로 완성된 서비스의 최종 산출물입니다.

소프트웨어는 끊임없이 발전해야 합니다. 이를 위해 UI/UX를 지속적으로 개선하고, 기존 테스트가 커버하지 못하는 영역을 찾아 보완해야 합니다. Kiro 사용자는 Vibe 요청을 통해 현재 UI/UX에 대한 피드백을 수집하고 논의할 수 있으며, 현 버전을 기반으로 새로운 아이디어를 제안하거나 개선점을 요청할 수도 있습니다. 아래는 Vibe 요청을 통해 피드백을 받는 예시입니다.

다행히 Kiro의 개발 철학과 워크플로우 덕분에 이러한 지속적인 개선 작업을 자연스럽게 이어갈 수 있습니다. Spec 작성부터 태스크 분해, 자동화된 코드 생성, 그리고 TDD 원칙을 적용한 테스트까지 전체 사이클을 반복하며, Vibe 요청을 통해 새로운 개선 사항을 논의하고 반영함으로써 서비스를 한층 더 완성도 있게 발전시킬 수 있습니다. 아래는 현재까지 구축된 코드베이스에서 생성된 673개의 테스트 결과입니다.

결론

Kiro는 단순한 개발 도구를 넘어, AI를 활용한 새로운 개발 패러다임을 제시했습니다. Spec 작성부터 태스크 분해, 자동화된 코드 생성까지 이어지는 체계적인 워크플로우를 통해 개발자는 보다 체계적인 소프트웨어 개발에 집중할 수 있습니다. 개발자들은 새로운 워크플로우 적응에 시간이 걸릴 수 있지만(또는 시간이 소요된다고 느낄 수 있지만), 소프트웨어가 성장하고 복잡해질수록 체계적인 아키텍처, 정돈된 문서, 일관된 코드 품질은 큰 힘을 발휘합니다.

그러나 아무리 꼼꼼히 Spec을 작성하더라도 오류 가능성을 완전히 배제할 수는 없습니다. 이때 Augmented Coding과 같은 개발 방법론을 함께 활용하면 Kiro의 진가가 더욱 발휘됩니다. 개발자의 의도와 아이디어는 명확한 Spec으로 표현되고, AI는 이를 바탕으로 견고하고 확장성 있는 코드를 생성합니다. TDD 기반의 테스트 작성과 검증, 커밋까지 이어지는 전 과정에서 개발자는 주도권을 유지합니다. 동시에 새로운 기능 추가와 리팩토링 속도는 놀라울 만큼 빨라지며, 안정적인 개발 흐름은 개발 자체를 즐거운 경험으로 바꿉니다.

결국 Kiro는 개발자가 더 나은 소프트웨어를 더 견고하게, 그리고 더 즐겁게 만들 수 있도록 돕는, 모든 것을 대신해주는 만능 도구보다는 개발자의 창의성과 전문성을 증강해주는 보조자입니다. 여러분의 잠재력을 최대한 발휘할 수 있도록 지원하는 Agent IDE, 지금 Kiro를 경험해보시기를 권합니다.

AWS 기술 블로그