안녕하세요, AI 서비스 & 솔루션 프로바이더 베스핀글로벌입니다.
AWS re:Invent 2025의 [Spec-driven development with Kiro]를 확인해보시기 바랍니다.

Spec-driven development with Kiro

Spec-driven development with Kiro는 AI 에이전트 개발의 새로운 패러다임을 제시합니다.

1. 소프트웨어 개발의 진화와 AI 에디터의 등장 

Nick Hill이 kiro의 역사와 소프트웨어 빌딩의 진화에 대해 설명합니다. 

• IDE의 등장 (1세대) :  IDE는 통합 컴파일러, 린트(linting) 문제 확인, 디버깅, 중단점 설정 등 단일 툴체인을 제공하여 전통적인 텍스트 편집기보다 많은 이점을 제공하며 널리 채택되었습니다. 
• AI 에디터의 등장 (최근 2년)
  • 코드 완성(Code Completions): 파일에 코드를 입력할 때 함수 등을 자동으로 생성하는 방식에서 시작되었습니다. 
  • 에이전틱 경험: 자연어를 입력하면 에이전트가 여러 파일을 편집할 수 있는 ChatGPT와 유사한 경험으로 빠르게 발전했습니다. 
• 개발자 역할의 변화: 이전에는 개발자가 주도하고 코드를 제공했지만, AI 에디터 시대에는 개발자가 AI 에이전트를 조종하여 코드를 작성하고 검토하는 방식으로 변화했습니다. 개발자가 여전히 주도권을 가지지만, AI를 사용하여 워크플로우를 가속화하며, 개발자는 생성된 코드에 대해 여전히 책임을 집니다. 

1-1. Vibe Coding의 한계 

• Vibe Coding 정의: 개발자가 프롬프트를 작성하면 AI가 코드를 생성하고, 다시 프롬프트를 작성하는 루프를 반복하는 워크플로우를 의미합니다.
• Vibe Coding의 장점: 몇 주가 걸릴 작업을 프로토타이핑하는 데 매우 유용했습니다.
• Vibe Coding의 도전 과제:맥락 손실: 슬랙(Slack) 대화 스레드가 길어지면 결정의 근거와 맥락이 손실되는 것과 유사하게, Vibe Coding은 전통적인 SDLC(소프트웨어 개발 수명 주기)를 완전히 건너뛰는 문제가 있습니다. 전통적
• SDLC: 역사적으로 기능 개발은 요구사항, 설계 문서, 트레이드오프 논의 등 아티팩트(Artifacts)로 시작되었습니다. 
• Spec-driven development의 탄생:내부 및 외부 파워 유저들을 분석한 결과, 이들은 코드를 생성하기 전에 계획(Planning)을 세우는 유기적인 변화를 이미 만들고 있었으며, 사전 계획이 모델의 집중도를 높여 더 나은 출력을 생성한다는 것을 발견했습니다. 이에 따라 Kiro는 계획을 위한 1세대 워크플로우인 Spec-driven development를 구축했습니다.

1-2. Spec-driven development 워크플로우 및 Hooks

• Spec-driven development의 구조: 초기 요구사항부터 최종 결과물까지 도달하는 구조화된 워크플로우를 제공합니다. 
• 단계별 흐름:
  • 요구사항(Requirements) 시작
  • 요구사항 완료 후 설계(Design) 검토. 
  • 태스크 리스트(Task List) 도달. 
  • 태스크 리스트 구현. 
  • 이 루프를 반복하여 만족스러운 결과에 도달할 때까지 앞뒤로 이동할 수 있습니다.
• AI Slop 방지 및 Hooks:
  • AI가 코드를 많이 생성하는 현상(AI slop)을 방지하기 위해, Kiro는 Hooks(후크) 기능을 내장하고 있습니다. 
  • Hooks는 파일 저장, 파일 생성 등 IDE 내의 수명 주기 이벤트(lifecycle events)에 트리거되어 변경 사항을 검증할 수 있게 합니다. 
  • Hook 예시:문서 저장 시 톤과 스타일을 확인하는 맞춤법 검사기 역할.
  • UI 컴포넌트가 단일 책임 원칙(Single Responsibility Principle)을 따르도록 강제하는 기능

2. Kiro IDE 기본 기능 둘러보기 

2-1. Job Seekers App 기획 및 초기 환경 설정

• 앱 기획: Eric과 Nick은 Job Seekers App을 구축하기 위해 Figma를 통해 아이디어를 구체화했습니다. 
• Job Seekers App의 핵심 아이디어:
  • 문제: 구직자들이 인터뷰 준비 외에도 자신의 스타일, 톤 등에 대한 피드백을 받을 수 있는 소프트웨어 도구가 부족합니다.
  • MVP 흐름: 사용자가 로그인 후 프로필을 설정하고, 인터뷰 준비를 시작하면 질문-응답 흐름으로 진행됩니다. 
  • 결과: 녹음된 응답을 바탕으로 정량적 점수와 정성적 개요를 제공합니다. 
• 초기 환경:
  • Eric은 새로 생성한 VIT 앱(Hello World)을 기반으로 시작하며, 당분간은 프론트엔드에 집중합니다. 
  • Tailwind CSS가 디자인 그래픽을 위해 설치되어 있습니다.

2-2. Kiro의 주요 기능 패널 소개 

• Kira House: 베네시안에 있는 Kiro House를 방문하면 500 또는 1000 무료 크레딧을 받을 수 있는 코드를 얻을 수 있습니다.
• 사이드바 메뉴: Agent hooks, Agent steering, Specs, MCP 메뉴로 구성되어 있습니다
• Agent Hooks (에이전트 후크):
  • 파일 저장/삭제와 같은 특정 이벤트에 트리거되어 백그라운드에서 작동하게 하는 기능입니다. 
  • 활용 예시: 파일 저장 시 문서 업데이트, 지역화(localization) 수행 등이 가능하며, 커뮤니티에서는 Git 워크플로우나 테스트 등에 창의적으로 사용되고 있습니다. 
  • Agent Steering (에이전트 스티어링): 코딩 표준이나 디자인 표준을 포함할 수 있는 규칙 파일을 설정하는 곳입니다. 
  • Kiro가 애플리케이션 폴더를 스캔하여 product 파일과 tech 파일을 자동으로 생성하며, 이 파일들은 IDE와 대화할 때 컨텍스트로 추가됩니다. 
  • 생성된 파일 내용: 현재 앱은 Vue3 웹 애플리케이션이며 TypeScript와 Vit을 사용하고, script setup 방식을 사용합니다. 

2-3. MCP (Model Configuration Protocol)

• MCP 서버를 설정하는 곳입니다.
• AWS는 Bedrock Agent Core를 포함하여 다양한 서비스에 대한 MCP 서버를 지속적으로 추가하고 있습니다. 
• 설치 편의성: 최근에는 원클릭 설치 기능이 추가되어 curro.dev에서 버튼 클릭만으로 MCP 서버를 Kiro 내에 자동으로 설치할 수 있습니다. 
• 현재 Brave Search, Bedrock Agent Core 등의 MCP 서버가 설정되어 있습니다. 

3. Spec-driven development 워크플로우 시작

3-1. Spec 모드 선택 및 초기 요구사항 생성 

• 모드 선택: 오른쪽에는 Vibe 모드와 Spec 에이전트 모드가 있으며, 현재는 Spec 에이전트를 선택합니다. 
• 지원 모델: 현재 Claude Sonnet, 4.5 Opus, Haiku, Opus 등을 지원하며, 시작 시에는 최적의 모델을 자동으로 선택하는 Auto 모드를 권장합니다. 
• 초기 프롬프트: Eric은 미리 준비한 Figma 스크린샷을 붙여넣고, "이 그림을 사용하여 Job Seekers 앱을 만들어 달라. 그림을 디자인으로 사용해 달라"고 요청합니다. 
• 결과: Kiro는 스티어링 문서(steering docs)를 참고하여 요구사항 문서(Requirements Document) 생성을 시작합니다. 

3-2. 요구사항 문서 검토 및 수정

• 요구사항 문서의 형식: Kiro는 초기 스크린샷을 요구사항 세트로 풀어서 작성했습니다. 
• 요구사항 정의: Kiro에서 요구사항은 사용자 스토리(User Story)로 정의되며, 각 사용자 스토리에는 수용 기준(Acceptance Criteria)이 포함됩니다. 
  • 이 형식은 Amazon 내부 팀에서 사용하던 워크플로우를 기반으로 만들어졌습니다. 
  • 사용자 스토리: 지원할 기능(예: 로그인)에 대한 인간이 읽기 쉬운 설명입니다. 
  • 수용 기준: 기능을 빌드할 때 고려해야 할 세부적인 사항(nitty-gritty details)입니다.
• 초기 요구사항 목록:
  • 로그인, 프로필 관리, 인터뷰 준비 세션 시작, 답변 보기 및 응답, 다중 질문 탐색, 분석 및 결과 보기, 추세 분석 등 8가지 요구사항이 생성되었습니다. 
• 요구사항 단순화:
  • Eric은 8번 요구사항("깨끗하고 직관적인 인터페이스")이 모호하다고 판단하고, MVP 범위를 위해 요구사항 1, 2, 7, 8을 제거하고 3, 4, 5, 6만 남기도록 요청합니다. 
  • 반복의 중요성: 한 번에 완벽한 결과를 얻기 어려우므로, AI IDE와 앞뒤로 반복(go back and forth process)하는 것이 중요하다고 강조합니다. 
• 추가 수정: 인터뷰 질문 수를 3개로 제한하도록 요구사항을 추가 수정합니다. 
• 다음 단계: 요구사항이 확정되었으므로 설계(Design) 단계로 넘어갑니다. 

3-3. 설계 문서 생성 및 검토

kiro는 업데이트된 요구사항을 기반으로 설계 문서를 생성합니다. 

• 설계 문서 생성: Kiro는 요구사항을 기반으로 기존 코드베이스를 참고하여 설계 문서를 생성합니다. 
• 설계 문서 내용
  • 요약 및 아키텍처: 생성된 설계 문서의 요약과 함께 ASCII 아트로 표현된 고수준 아키텍처를 제공하며, Mermaid 다이어그램도 지원합니다. 
  • 주요 컴포넌트: 시작 화면(start screen), 질문(question), 결과(results) 화면 등이 포함됩니다. 
  • 기술 스택: 로컬 스토리지를 사용한 데이터 공유, 오디오 녹음을 위한 Web Audio API 사용 등이 명시되어 있습니다. 
  • 인터페이스: 컴포넌트(예: question response, component start screen view)와 세션 상태 캡처(session state capture)에 대한 인터페이스가 개략적으로 정의되어 있습니다. 
  • 질문 은행: MVP를 위해 미리 정의된 일반적인 인터뷰 질문 배열을 사용할 예정입니다. 
• 누락된 기능 추가 요청:
  • Eric은 노트북에서 녹음된 오디오를 전사(transcribe)하는 방법과, 결과 분석에 대한 정보가 부족하다고 지적합니다. 
  • 추가 요청: 사용자가 말하는 텍스트를 전사할 수 있는 기능 추가. 결과에 대한 추가 분석 기능 추가. 
  • 분석 도구: 결과 분석에는 Amazon Bedrock 대신 Claude AI SDK를 사용하기로 결정합니다. 
• 설계 업데이트: Kiro는 설계 문서뿐만 아니라, 변경 사항을 반영하여 요구사항 문서까지 스마트하게 업데이트합니다.
• 새로운 기능 반영:
  • 마이크 버튼이 추가되어 오디오를 녹음하고 전사할 수 있게 됩니다. 
  • 체크포인트(Checkpointing) 기능이 언급됩니다. 이 기능을 사용하면 예상과 다를 경우 이전 상태로 쉽게 복원할 수 있어 버전 관리 시스템에 의존할 필요가 줄어듭니다. 
• 최종 설계 확인
  • 전사된 텍스트가 인터페이스에 표시되고, 더 나은 분석 결과가 캡처될 수 있도록 결과 인터페이스가 추가됩니다. 
  • 시스템 다이어그램에 Speech Detect와 Claude AI가 추가된 것을 확인하고, 아키텍처가 만족스러워 다음 단계로 진행합니다. 

4. 태스크 리스트 생성 및 구현 단계 

4-1. 태스크 리스트 생성 및 유연성 

• Markdown 기반 유연성: 이 워크플로우는 모두 Markdown 기반으로 구축되어 있어 유연합니다.
• Refine 버튼: 수동 편집을 한 경우, 상단의 Refine 버튼을 클릭하여 해당 편집 내용을 설계 문서나 태스크 리스트에 통합할 수 있습니다.
• 태스크 업데이트: 구현 중 변경 사항이 생기면, Update Tasks를 클릭하여 Kiro가 코드베이스를 확인하고 남은 태스크를 새로 고치도록 할 수 있습니다.
• 태스크 옵션: 태스크 리스트에는 선택적(optional) 태스크와 필수 태스크가 있으며, 속성 기반 테스트(property-based testing)는 현재 선택 사항으로 설정되어 있습니다. 
• MVP 우선순위 지정:
  • Eric과 Nick은 MVP를 빠르게 보여주기 위해 처음 5개 태스크를 우선시하도록 Kiro에게 요청합니다. 
  • 제품 개발 비유: 자동차를 만들 때 스케이트보드, 자전거를 거쳐 완성하는 것처럼, 중간 단계(interim steps)를 항상 작동 가능하게 만드는 것이 중요하다고 설명합니다. 
  • 태스크 압축: 필요하다면 Kiro에게 25개의 태스크를 10개로 압축해달라고 요청할 수도 있습니다.

4-2. 태스크 구현 시작 및 Property Testing 개요

• MVP 태스크 확인: MVP 범위에 해당하는 5개 태스크를 확인합니다.
  • Phase 1 태스크: 종속성 설정, 핵심 데이터 유형 생성, 애플리케이션 상태 관리 구현, 오디오 녹음/음성 테스트 구현, 응답 유효성 검사/저장, 시작 화면 컴포넌트 생성 등이 포함됩니다.
•  UI 추가 요청: 초기 5개 태스크에 UI가 포함되지 않은 것을 확인하고, 시각적으로 테스트할 수 있도록 UI를 초기 단계에 추가해달라고 요청합니다.
• 태스크 구현 시작:
  • 구현 방법: UI에서 클릭하거나 채팅으로 Start Task를 명령하여 태스크를 시작할 수 있습니다. 
  • 순차 실행: Kiro는 터미널에서 명령을 실행하며, 태스크는 순서대로 진행되어야 하므로 큐(cued) 상태로 처리됩니다. 
  • 진행 상황: 태스크 1과 2가 빠르게 완료되는 것을 확인합니다.

• Property Testing으로 전환: 태스크 구현에 시간이 걸리므로, 잠시 Property Testing(속성 기반 테스트)에 대해 논의합니다. 

5. Property Testing (속성 기반 테스트) 상세 설명 

5-1. Gherkin 형식의 중요성

• 요구사항에서 사용자 스토리/수용 기준 형식을 사용한 이유는 Gherkin 형식으로 구조화되어 있기 때문입니다.
• Gherkin은 "이것을 하면 시스템은 Y를 해야 한다(When you do this, the system shall do Y)"와 같이 정의되어 논리적 동치성(logical equivalence)을 생성하고 요구사항에 대한 형식적 추론을 가능하게 합니다. 

5-2. 속성(Property)의 정의

• 시스템의 모든 실행에서 참이어야 하는 특성 또는 동작입니다.

5-3. 테스트 과정

• Kiro는 Gherkin 형식의 요구사항에서 속성을 추출합니다. 
• Fast Check 프레임워크를 사용하여 이 속성들을 테스트합니다. 
• 단위 테스트와의 차이점: 단위 테스트는 제한된 입력만 사용하지만, 속성 기반 테스트는 범위 내의 많은 값들을 퍼징(fuzzing)하여 더 많은 증거를 생성합니다. 

5-4. 목표

• 생성된 코드가 사용자의 의도(requirement)와 일치하는지 확인하는 최초 원칙적 접근 방식입니다.

5-5. 체스 앱 예시

• Nick은 자신이 체스 앱을 만들 때 사용했던 속성 기반 테스트 목록을 보여줍니다. 
• 테스트 내용: "AI가 생성한 이동에 대해 모든 속성 기반 테스트가 통과해야 한다"는 테스트가 있으며, 이는 npm에서 FC from fast check를 임포트하여 작성됩니다. 
• Fuzzy Testing: 테스트 끝에 있는 num runs 파라미터는 퍼지 테스트를 수행하며, 테스트 파일을 무작위로 변경하여 100회 이상 실행하여 예상대로 작동하는지 확인합니다. 
• 결과: 속성 기반 테스트를 추가하면 코드 품질이 훨씬 높아지고 버그가 줄어듭니다. 

6. 태스크 구현 진행 상황 및 진단 도구

• 구현 진행: 태스크 5가 완료되고 태스크 6이 시작된 것을 확인합니다. 
• 구현 계획 업데이트: 태스크가 완료되면 구현 계획(implementation plan)에서도 완료 표시가 됩니다. 
•  진단 도구(Diagnostics Tool):
  • Kiro가 최근 출시한 기능으로, IDE 인터페이스를 소유하고 있기 때문에 문제 발생 시 문제 탭(problems tab)에서 린팅 이슈 등을 보고하면 에이전트가 이를 읽을 수 있습니다. 
  • 이 도구 덕분에 스펙 생성 시 발생하던 많은 이슈들이 크게 개선되었습니다. 
• 시간 제약: 태스크 6이 진행되는 동안, Eric은 남은 시간을 고려하여 질문 시간을 확보하기 위해 npm run dev를 실행하여 최종 앱을 보여주기로 결정합니다. 
• 남은 태스크 큐잉: 나머지 태스크들을 큐에 넣고 진행을 계속하도록 설정합니다.

6-2. 최종 앱 시연 및 결과 확인 

• 완성된 앱 구조: Spec, Design, Requirement, Task 단계가 모두 완료된 상태입니다. 
•  Job Seekers App 기능:
  • 카테고리: 행동 질문(behavioral questions), 기술 질문(technical questions), 리더십 질문(leadership questions)으로 구성되어 있습니다. 
  • 모델 연결: Claude Sonnet 3.7 모델에 연결되어 있습니다.
• 기술 질문 시연:
  • 질문: "당신의 분야에서 복잡한 기술 개념을 누군가에게 설명해 보세요." 
  • 응답: "웹사이트에 대해 설명하겠습니다. 서버와 클라이언트가 상호작용하며, 로컬에서 실행하거나 SPA, SSR 앱으로 만들 수 있습니다." 
  • 점수: 이전 실행에서 낮은 점수를 받았으나, 이번에는 10점 만점에 4점을 받았습니다. 
  • 피드백: "후보자는 관련 기술 지식과 업계 참여를 보여주지만, 응답에 구조, 명확성, 깊이가 부족합니다." 
• 데모 마무리: 이 앱을 만드는 데 오랜 시간이 걸리지 않았음을 강조하며 시연을 마칩니다.