본문 바로가기

AI 개발

AWS Kiro 완전 가이드 — Amazon Q Developer가 죽고 Spec-Driven IDE가 왔다

반응형

Amazon Q Developer 신규 가입이 5월 15일부터 막혔습니다. AWS가 지목한 후계자는 Kiro입니다. Cursor도 Claude Code도 아닌, 코드보다 스펙을 먼저 쓰는 에이전트 IDE입니다.

[핵심 요약]

Kiro는 AWS가 만든 에이전트 IDE + CLI로 Code OSS 기반이며 VS Code와 호환됩니다. Amazon Q Developer는 2026년 5월 15일부터 신규 가입이 차단됐고, 기존 Pro 사용자는 2027년 4월 30일까지 마이그레이션 기간이 주어집니다. 핵심 철학은 "스펙이 소스 오브 트루스, 코드는 빌드 아티팩트"이며, 모델은 추론 집약 작업에 Claude Sonnet, 고처리량 코드 생성에 Amazon Nova를 조합해서 씁니다. 가격은 무료 티어가 있고 Pro는 월 $20입니다. 핵심 기능은 Specs(스펙 주도 개발), Hooks(이벤트 자동화), Steering(영구 컨텍스트) 세 가지이며, AWS 계정 없이 GitHub 또는 Google 로그인으로 바로 시작할 수 있습니다.


왜 갑자기 Q Developer가 사라졌나

2026년 1월, AWS가 조용히 공지했습니다.

"Amazon Q Developer IDE 플러그인과 유료 구독은 2027년 4월 30일에 지원 종료됩니다. 신규 가입은 2026년 5월 15일부터 차단됩니다."

AWS의 개발자 AI 베팅이 Kiro로 완전히 이동했다는 선언입니다.

기존 Q Developer Pro와 Kiro의 차이는 생각보다 큽니다. Q Developer Pro는 월 $20에 약 1,000 요청이 주어지고, 최신 모델 접근이 제한적이며, 매번 컨텍스트를 재설명하는 프롬프트 기반 방식이었습니다. 5월 29일 이후에는 Opus 4.6도 제거될 예정입니다. 반면 Kiro는 동일한 $20에 크레딧 기반으로 요청 수를 유연하게 쓸 수 있고, Opus 4.7을 포함한 최신 모델에 접근 가능합니다. 가장 큰 차이는 스펙 기반 워크플로우로, 한 번 작성한 스펙이 영구 컨텍스트 역할을 하며 Hooks로 반복 작업을 자동화할 수 있다는 점입니다.


실전 1 — 설치 및 첫 번째 스펙 작성

설치

Kiro는 IDE, CLI, 웹 세 가지 방식으로 사용할 수 있습니다. 가장 일반적인 방법은 IDE 설치이며, macOS에서는 Homebrew로 한 줄에 설치가 끝납니다.

# Kiro IDE 다운로드 (kiro.dev)
# macOS
brew install --cask kiro

# 또는 공식 사이트에서 직접 다운로드
# https://kiro.dev

# CLI 설치 (터미널 사용자)
npm install -g @kiro/cli
kiro login  # GitHub 또는 Google 로그인

설치 옵션은 상황에 따라 고르면 됩니다. Kiro IDE는 VS Code 기반 GUI 에디터로 기존 테마와 키바인딩을 그대로 가져올 수 있습니다. Kiro CLI는 SSH 세션이나 스크립트 워크플로우에 적합한 터미널 에이전트이고, Kiro Web은 브라우저에서 설치 없이 바로 쓸 수 있습니다. 세 가지 모두 AWS 계정 없이 GitHub 또는 Google 로그인으로 즉시 시작 가능합니다.

첫 번째 스펙 작성

Kiro의 핵심은 프롬프트가 아닌 스펙입니다. 기능 하나를 만들 때 코드부터 짜지 않습니다. /spec 명령어로 원하는 기능을 설명하면 Kiro가 요구사항, 설계, 구현 체크리스트를 자동으로 나눠서 작성해줍니다.

# Kiro에서 새 기능 요청
/spec 사용자 인증 시스템 만들어줘
  - JWT 기반 로그인/로그아웃
  - Refresh Token 자동 갱신
  - 소셜 로그인 (Google)

위 명령어 하나로 Kiro가 세 개의 파일을 자동 생성합니다. 이 파일들이 이후 모든 코드 생성의 기준이 됩니다.

# requirements.md (자동 생성)
## 사용자 인증 시스템

### User Stories
1. 사용자는 이메일/패스워드로 로그인할 수 있다
2. 로그인 성공 시 JWT Access Token(15분)과 Refresh Token(7일)을 받는다
3. Access Token 만료 시 자동으로 갱신된다
4. Google OAuth로 소셜 로그인할 수 있다

### Acceptance Criteria
- [ ] POST /auth/login → 200 + {access_token, refresh_token}
- [ ] POST /auth/refresh → 200 + 새 access_token
- [ ] GET /auth/google → Google OAuth 리다이렉트
- [ ] POST /auth/logout → Refresh Token 무효화
# design.md (자동 생성)
## 아키텍처 설계

### 컴포넌트
- AuthController: HTTP 요청 처리
- AuthService: 비즈니스 로직
- TokenRepository: Redis 기반 토큰 저장
- UserRepository: DB 사용자 조회

### 데이터 흐름
로그인 요청 → AuthController → AuthService
  → UserRepository (사용자 검증)
  → JWT 생성 (Access 15분 / Refresh 7일)
  → TokenRepository (Refresh Token 저장)
  → 응답
# tasks.md (자동 생성)
## 구현 체크리스트

1. [ ] User 엔티티 및 DB 스키마 생성
2. [ ] JWT 유틸리티 함수 구현
3. [ ] AuthService.login() 구현
4. [ ] AuthService.refresh() 구현
5. [ ] Google OAuth 연동
6. [ ] AuthController 라우트 정의
7. [ ] 단위 테스트 작성
8. [ ] 통합 테스트 작성

스펙 기반 개발의 핵심 가치는 이렇습니다. 스펙이 소스 오브 트루스이고 코드는 스펙의 빌드 아티팩트입니다. 스펙을 수정하면 코드가 자동 재동기화되고, 한 달 뒤 돌아와도 "왜 이렇게 짰는지"가 스펙 파일에 남아있습니다. 새 팀원이 합류하면 스펙 파일 세 개만 읽으면 전체 컨텍스트를 파악할 수 있고, 에이전트 모델이 좋아질수록 스펙이 풍부한 코드베이스가 더 유리해집니다.


실전 2 — Hooks로 반복 작업 자동화

Hooks는 Kiro에서 가장 실용적인 기능입니다. 파일 이벤트에 반응해서 에이전트가 자동으로 작업을 실행하는 방식으로, 테스트 생성이나 문서 업데이트 같은 반복 작업을 사람이 직접 프롬프트를 치지 않아도 처리할 수 있습니다.

아래는 React 컴포넌트를 저장할 때마다 테스트 파일을 자동 생성하는 Hook 예시입니다. .tsx 파일이 저장되는 순간 에이전트가 React Testing Library 기반 테스트를 자동으로 작성하고 __tests__ 폴더에 저장합니다.

# .kiro/hooks/auto-test.yaml
name: "React 컴포넌트 저장 시 테스트 자동 생성"
trigger:
  type: file_save
  pattern: "src/components/**/*.tsx"
action:
  prompt: |
    방금 저장된 {file}에 대한 단위 테스트를 작성해줘.
    - React Testing Library 사용
    - 컴포넌트 렌더링 테스트
    - 주요 사용자 인터랙션 테스트
    - 엣지 케이스 포함
  output: "{file.dir}/__tests__/{file.name}.test.tsx"

API 문서 자동 업데이트와 커밋 전 보안 스캔도 같은 방식으로 구성합니다.

# .kiro/hooks/api-docs.yaml
name: "API 엔드포인트 수정 시 문서 자동 업데이트"
trigger:
  type: file_save
  pattern: "src/routes/**/*.ts"
action:
  prompt: |
    {file}의 API 엔드포인트 변경사항을 감지하고
    docs/api.md를 최신 상태로 업데이트해줘.
    OpenAPI 3.0 형식으로 작성.
  output: "docs/api.md"
# .kiro/hooks/security-scan.yaml
name: "커밋 전 보안 스캔"
trigger:
  type: pre_commit
action:
  prompt: |
    변경된 파일에서 다음 보안 이슈를 스캔해줘:
    - SQL 인젝션 가능성
    - 하드코딩된 시크릿
    - XSS 취약점
    - 안전하지 않은 디시리얼라이제이션
    이슈 발견 시 커밋 차단하고 수정 방법 제안.

Hooks의 트리거 타입은 상황에 따라 골라 쓸 수 있습니다. file_save는 파일 저장 시, file_create는 새 파일 생성 시 보일러플레이트를 자동으로 주입할 때 씁니다. pre_commit은 커밋 직전 보안 스캔이나 품질 게이트를 걸 때, pr_open은 PR이 열릴 때 코드 리뷰 자동화나 문서 업데이트에 활용합니다. 이 외에도 개발자가 직접 이벤트를 정의하는 custom 타입도 있습니다.


실전 3 — Steering 파일로 영구 컨텍스트 설정

Steering 파일은 Claude Code의 CLAUDE.md와 같은 역할입니다. 프로젝트 전체에 적용되는 규칙을 한 번 작성해두면 이후 모든 세션에서 자동으로 적용되며, 에이전트가 매번 같은 컨텍스트를 가지고 코드를 생성합니다.

아래는 TypeScript, NestJS, Next.js 기반 프로젝트에 적용하는 전역 Steering 파일 예시입니다. 언어 및 프레임워크 선택부터 코딩 규칙, 아키텍처 패턴까지 명시합니다.

# .kiro/steering/global.md
## 개발 원칙

### 언어 및 프레임워크
- TypeScript strict mode 필수
- 백엔드: NestJS + Prisma
- 프론트엔드: Next.js 15 + TailwindCSS
- 테스트: Jest + React Testing Library

### 코딩 규칙
- 함수는 단일 책임 원칙 준수
- 에러 처리는 Result 타입 패턴 사용
- 모든 API 응답은 {data, error, meta} 구조
- 환경변수는 절대 하드코딩 금지

### 아키텍처
- 레이어: Controller → Service → Repository
- 의존성 주입 필수 (테스트 가능성 확보)
- AWS Lambda 배포 고려한 무상태 설계

보안 정책은 별도 파일로 분리해서 관리할 수 있습니다. 파일이 분리돼 있어도 모두 자동 로드되기 때문에 도메인별로 나눠서 관리하는 게 훨씬 편합니다.

# .kiro/steering/security.md
## 보안 정책

- 모든 엔드포인트는 인증 필수 (public 명시적 표기)
- SQL 쿼리는 Prisma ORM만 사용 (raw query 금지)
- 사용자 입력은 반드시 zod로 검증
- 민감 데이터는 응답에서 제외 (password, token 등)
- Rate limiting은 모든 API에 적용

Steering과 CLAUDE.md의 차이는 단순합니다. CLAUDE.md는 Claude Code 전용 단일 파일인 반면, Steering은 Kiro 전용으로 global, security, api처럼 여러 파일로 분리할 수 있습니다. 매 세션마다 자동 로드되는 영구 컨텍스트 역할은 동일하지만, 도메인별로 나눠 관리할 수 있다는 점이 Kiro의 장점입니다.


실전 4 — MCP 서버 연결 (Kiro Powers)

Kiro는 MCP를 네이티브로 지원하며, Kiro Powers라는 이름의 MCP 서버 마켓플레이스를 함께 제공합니다. 기존에 Claude Code에서 쓰던 MCP 설정을 그대로 가져와서 쓸 수 있습니다.

아래는 GitHub, AWS 공식 문서, Figma를 연결하는 설정 파일 예시입니다. JSON 파일 하나로 여러 MCP 서버를 동시에 관리할 수 있습니다.

// .kiro/mcp.json
{
  "servers": {
    "github": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    },
    "aws-docs": {
      "type": "url",
      "url": "https://mcp.aws.amazon.com/docs",
      "description": "AWS 공식 문서 실시간 조회"
    },
    "figma": {
      "type": "url",
      "url": "https://mcp.figma.com/v1",
      "env": {
        "FIGMA_TOKEN": "${FIGMA_API_KEY}"
      }
    }
  }
}

설정 후 바로 활용할 수 있습니다. 이 중 특히 유용한 조합은 Figma MCP와 Hooks를 연동하는 방식으로, 디자인 변경이 감지되면 CSS 자동 검증 Hook이 실행되는 파이프라인을 구성할 수 있습니다. Kiro Powers 마켓플레이스에는 AWS 공식 문서 MCP, Figma MCP, 의료 도메인 특화 HealthOmics MCP 등이 등록돼 있으며, 일반 MCP 서버도 전부 호환됩니다.


Kiro vs Claude Code vs Cursor 한눈에 비교

구분 Kiro Claude Code Cursor

철학 스펙 주도 추론 중심 속도 중심
모델 Claude+Nova Claude Opus 4.7 Composer 2
기반 VS Code (Code OSS) 터미널 VS Code
핵심 기능 Specs+Hooks 컨텍스트 관리 Agents Window
자동화 Hooks (이벤트) 수동 프롬프트 Background Agent
팀 협업 스펙 파일 공유 CLAUDE.md .cursorrules
가격 $20/월 $20/$100/$200 $20/월
AWS 통합 네이티브 없음 없음
MCP 네이티브 네이티브 지원
추천 상황 복잡한 기능 설계 깊은 코드 분석 빠른 반복 개발

마무리

Kiro는 기존 AI 코딩 도구들과 출발점이 다릅니다. Cursor나 Claude Code가 "더 빠르게, 더 정확하게 코드를 생성하는 것"에 집중한다면, Kiro는 "코드를 생성하기 전에 무엇을 만들지 정의하는 것"에 무게를 둡니다. 스펙이 먼저고 코드는 그 결과물이라는 철학이 실제 개발 과정에서 얼마나 유효한지는 팀 규모와 프로젝트 복잡도에 따라 갈립니다.

AWS 스택을 메인으로 쓰는 팀, 여러 개발자가 복잡한 기능을 협업하는 환경, 문서화와 테스트 자동화를 Hook으로 강제하고 싶은 팀, 그리고 Amazon Q Developer Pro를 현재 구독 중이라 마이그레이션을 준비해야 하는 팀에게 Kiro는 자연스러운 선택지입니다. 반면 빠른 프로토타이핑이 중심인 1인 개발자나 이미 Claude Code 또는 Cursor가 팀에 정착된 경우라면 스펙 작성 오버헤드가 오히려 부담이 될 수 있습니다. AWS 생태계를 전혀 쓰지 않거나 요구사항이 자주 바뀌는 초기 스타트업도 마찬가지입니다.

결국 Kiro의 가치는 "지금 이 코드를 왜 이렇게 짰는가"를 나중에도 설명할 수 있는 구조를 처음부터 강제한다는 데 있습니다. 복잡도가 올라갈수록, 팀이 커질수록 그 가치는 더 선명해집니다.

 


관련 글

반응형