Kiro를 최대한 활용하는 방법

저는 몇 달 전인 2025년 10월, Kiroween이라는 해커톤을 통해 Kiro를 시작했습니다.

그것은 기본적으로 Kiro IDE를 접하는 시작점이었으며, AWS가 이 제품을 통해 무엇을 하려 하는지 이해할 수 있는 기회였습니다. 저의 목표는 Kiro를 사용해 보고 당시 제가 사용하던 다른 도구들과 무엇이 다른지 확인하는 것이었습니다.

당시에는 Kiro에 대한 가이드가 많지 않았습니다. 그래서 제가 한 일의 대부분은 탐색적인 것이었습니다. 새로운 프로젝트를 생성하고, "바이브코딩 (vibecoding)"을 시도하며, 이 "사양 주도 개발 (Spec-Driven Development)"이 무엇인지, 그리고 이것이 IDE와 어떻게 통합되는지 이해하는 과정이었습니다.

몇 달이 지나면서 저는 Kiro 커뮤니티에 더 깊이 참여하게 되었고, IDE 이면에 있는 모든 것을 발견하기 시작했습니다. 이것은 단순히 옆에 AI가 붙어 있는 IDE가 아닙니다. 작동 방식에 대한 전체 시스템이 존재합니다.

그 지점에서 다음과 같은 개념들이 나타나기 시작합니다:

스티어링 (steerings)
훅 (hooks)
MCPs
파워 (powers)
에이전트 (agents)
프롬프트 (prompts)
스킬 (skills)

이미 Kiro를 사용 중이거나 사용할 계획이 있지만, 이 모든 요소가 어떻게 서로 맞물려 돌아가는지 아직 모른다면 이 글이 도움이 될 것입니다.

요약 (TLDR): Kiro 설치하기

아직 Kiro를 설치하지 않았다면, 다음 링크를 확인하세요:

이 과정을 거치면 몇 분 안에 IDE를 실행할 수 있을 것입니다.

이제부터 흥미로운 내용이 시작됩니다.

스티어링 (Steerings)

스티어링 (Steerings)은 단순히 Kiro가 프로젝트 작업을 수행할 때 고려하기를 원하는 지침, 규칙 또는 컨텍스트를 정의하는 Markdown 파일입니다.

이것들은 단순히 지침을 주는 용도로만 유용한 것이 아닙니다. 프로젝트에 대한 구조적 정보를 포함할 수도 있습니다.

예를 들어:

리포지토리 (repository)의 구조 및 조직
코드 및 명명 규칙 (naming conventions)
프로젝트 아키텍처 (architecture)
문서화 (documentation) 생성 방법

가장 흔한 사례 중 하나는 Kiro에게 기초 (Foundational) 스티어링 (Steerings)을 생성하도록 요청하는 것입니다.

이렇게 하면 Kiro가 프로젝트를 스캔하여 Kiro의 설정 디렉토리 내에 여러 파일을 생성합니다. 일반적으로 다음 항목들이 포함됩니다:

product
structure
tech

이 모든 것은 Kiro가 리포지토리에서 감지한 컨텍스트 (context)를 사용하여 생성됩니다. 이는 AI가 코드를 작업할 때 사용할 수 있는 문서화 기반을 제공하므로 좋은 시작점이 됩니다.

사용을 권장하는 스티어링 (Steerings)

기초 스티어링 외에도 실제 프로젝트에 추가하면 매우 유용한 몇 가지 유형이 있습니다.

프로젝트 작업 규칙 (Project working rules)

해당 리포지토리에서 팀이 작업하는 방식입니다. 여기에는 다음과 같은 내용이 포함될 수 있습니다:

명명 규칙 (naming conventions)
폴더 구조 (folder structure)
프로젝트의 비전 (vision) 및 미션 (mission)

이는 Kiro가 프로젝트의 스타일에서 벗어나는 것을 생성하기 시작하지 않도록 하는 데 큰 도움이 됩니다.

문서화 스타일 (Documentation style)

코드가 어떻게 문서화되는지, 어떤 섹션이 나타나야 하는지, 또는 README가 어떻게 작성되는지를 정의할 수 있습니다.

아키텍처 규칙 (Architecture conventions)

프로젝트가 특정 패턴(헥사고날 (hexagonal), 이벤트 기반 (event driven), 클린 아키텍처 (clean architecture) 등)을 따르는 경우, 이를 스티어링에 정의해 두면 일관성을 유지하는 데 큰 도움이 됩니다.

프로젝트가 어떻게 작동하는지 Kiro에게 명확하게 알려줄수록 더 좋은 결과를 얻을 수 있습니다.

훅 (Hooks)

훅 (Hooks)은 Kiro 내부의 또 다른 매우 강력한 요소입니다. 기본적으로 훅은 이벤트 (event)가 발생할 때 자동으로 실행되는 프롬프트 (prompts)입니다.

이러한 이벤트의 몇 가지 예는 다음과 같습니다:

파일이 생성, 수정 또는 삭제될 때
작업을 시작하거나 완료할 때
수동으로

꽤 간단한 예시를 들어보겠습니다:

Markdown 파일을 수정하고 있다면, 다음과 같은 작업을 수행하는 훅 (hook)을 설정할 수 있습니다:

린트 (lint) 실행
Markdown 포맷팅 (formatting)
깨진 링크 확인

또 다른 예시:

코드를 수정하고 있다면, 변경된 사항에 대한 문서를 자동으로 생성하는 훅 (hook)을 가질 수 있습니다.

이는 개발 흐름 (development flow) 내부의 상당히 많은 것들을 자동화할 수 있는 문을 열어줍니다.

훅 (hooks) 시작하는 방법

훅 (hooks)은 트리거되는 방식이 다양합니다: 훅 트리거 (hook triggers)

저의 권장 사항은 항상 수동 훅 (manual hooks)부터 시작하는 것입니다.

먼저 훅 (hooks)이 무엇을 하는지 테스트하고, 결과가 예상과 일치하는지 확인하며, 이상한 동작을 하지 않는지 검증하십시오.

결과에 만족하게 되면, 그때부터 자동화를 시작할 수 있습니다.

훅 (hooks)은 Kiro 내에서 태스크 (task)를 실행한다는 점을 기억하십시오. 자동화된 훅 (hooks)이 너무 많으면 크레딧 (credits) 비용이 높아질 수 있습니다. 이것은 제가 훅 (hooks)을 통해 배운 첫 번째 교훈 중 하나였습니다.

MCPs

MCPs는 Kiro 내부와 일반적인 AI 분야에서 또 다른 중요한 요소입니다.

매우 간단하게 설명하자면, MCP는 기본적으로 AI가 사용할 수 있는 API와 같습니다. MCPs를 통해 AI를 외부 서비스와 연결할 수 있습니다. 이는 프로젝트 컨텍스트 (project context) 내에 평소에는 존재하지 않을 정보나 도구에 대한 접근 권한을 부여합니다.

꽤 흔한 예시들은 다음과 같습니다:

AWS 문서 (documentation)
기술 문서용 Context7
Jira 또는 Confluence와 같은 Atlassian과의 통합

Kiro를 문서, 외부 도구 또는 팀의 내부 시스템과 연결하여 AI가 그 모든 것과 함께 작업할 수 있도록 만들 수 있습니다.

Powers

MCP (Model Context Protocol)의 그리 좋지 않은 점은 AI 세션 내부에 컨텍스트 (Context)를 추가한다는 것입니다. 활성화된 MCP가 많아질수록 더 많은 컨텍스트를 소비하게 되며, 이로 인해 작업 비용이 더 많이 발생하게 됩니다.

많은 경우, 모든 MCP를 항상 활성화해 둘 필요는 없습니다. 바로 이 지점에서 Kiro의 Powers가 등장합니다.

Powers를 사용하면 자주 반복되는 작업이나 도메인을 캡슐화 (Encapsulate)할 수 있습니다. 여기에는 MCP를 사용하는 작업도 포함됩니다.

Supabase 데이터베이스를 위한 MCP가 있다고 가정해 봅시다. 하지만 이번 작업에서는 데이터베이스가 필요하지 않다는 것을 알고 있습니다. 만약 이를 Power로 캡슐화한다면, Kiro는 데이터베이스가 필요할 때만 이를 호출할 것이며, 사용하지 않을 때 이 MCP가 사용할 컨텍스트로부터 여러분을 자유롭게 해줄 것입니다.

얼마 전 저는 저의 첫 번째 Power를 만드는 방법에 대한 글을 작성했습니다: Building my first Kiro Power - Posthog Observability.

Customizable agents (커스텀 가능한 에이전트)

올해 초, Kiro는 customizable agents 또는 서브 에이전트 (Sub-agents)를 발표했습니다. 에이전트 (Agents)는 이미 Kiro 내부에 존재했습니다. IDE에서 스펙 기반 개발 (Spec-driven development)을 수행했거나 CLI에서 plan mode를 사용해 보았다면 이미 확인하셨을 것입니다. 두 방식 모두 특정 유형의 작업을 실행하기 위해 Kiro 내부에 이미 정의된 에이전트를 사용합니다.

에이전트는 지정된 방식으로 동작하도록 만드는 고유한 구조와 프롬프트 (Prompts)를 가지고 있습니다.

이들은 에이전트만이 나타나는 구조와 내부 프롬프트 (Internal Prompt)를 가지고 있습니다. 또한 활성화 또는 비활성화된 특정 도구 (Tools)들을 보유하며, 선택된 모델 (Model)을 가질 수 있습니다.

예를 들어, 플랜 에이전트 (Plan Agent)는 주어진 작업을 계획하기 위한 가이드처럼 동작합니다. 이 에이전트는 작업에 대해 질문을 던지고 상세한 계획을 만들어 줍니다. 이 에이전트는 파일 쓰기 (File-writing) 도구가 비활성화되어 있는데, 이는 여러분이 만들려는 것이 오직 계획일 뿐이며 실제 구현 (Implementation)을 수행하는 것이 아니기 때문입니다.

플랜 에이전트는 Kiro에 의해 이미 사전 정의된 에이전트입니다. 이제 여러분만의 에이전트를 만들 수 있으며, 이는 여러분의 작업을 다음 단계로, 혹은 네 단계 더 높게 끌어올릴 수 있음을 의미합니다. 왜 네 단계일까요? 서브 에이전트 (Sub-agents)를 사용하면 네 개의 에이전트를 병렬로 실행할 수 있기 때문입니다.

커스텀 에이전트 활용 방법

제가 항상 사용하는 에이전트들은 프로젝트 자체에서 수행하고 있는 작업과 관련된 에이전트들입니다.

예를 들어, 저는 TypeScript 프로젝트를 진행하고 있으므로 TypeScript 전문가 (TypeScript expert) 에이전트를 가지고 있습니다. 이 에이전트는 TypeScript 전문가로서 어떻게 작업해야 하는지에 대한 특정 프롬프트 (Prompt)를 가지고 있습니다. 그리고 저는 이 에이전트에 쓰기 (Write) 및 읽기 (Read) 도구를 활성화해 두었습니다.

계획 및 아키텍처를 위한 LLM 의회 (LLM Council) 조언

또 다른 예로는 계획, 아키텍처 (Architecture) 및 의사 결정 (Decision-making) 작업을 위한 사례가 있습니다.

보통 여러분이 가진 최고의 모델에게 질문하면 상당히 괜찮은 옵션을 줄 수 있지만, 이상적으로는 여러 가지 옵션을 확보해야 합니다. AI는 비결정론적 (Non-deterministic)이며 환각 (Hallucinate)을 일으킬 수 있기 때문입니다.

계획, 아키텍처, 의사 결정 작업을 수행할 때는 구현보다는 계획이나 설계를 만드는 것이 핵심입니다. 현실 세계에서는 팀원들과 모여 브레인스토밍을 하고 팀으로부터 다양한 의견을 듣는 것과 같습니다.

이것을 Kiro 내부에서 어떻게 구현할 수 있을까요? 여러분은 계획 수립(planning)과 같이 특정 프롬프트(prompt)를 가진 맞춤형 에이전트(customizable agents)를 보유하고 있습니다. 맞춤형 에이전트에서는 어떤 모델을 사용할지 지정할 수 있으므로, 동일한 유형의 에이전트라도 서로 다른 모델을 부여할 수 있습니다. 예를 들어 Opus, Sonnet, Haiku, Auto와 같은 네 가지 모델을 사용할 수 있습니다.

계획을 세울 때, 저는 Kiro에게 저의 _Agent Council_을 병렬로 사용하도록 요청합니다. Kiro는 이 네 가지 모델을 병렬로 실행하며, 각 모델은 저에게 독립적인 계획을 만들어 줍니다. 모델들이 작업을 마치면, 기본 에이전트(default agent)가 각 계획에서 가장 좋은 부분들을 취합하여 네 가지 계획을 저를 위해 컴파일(compile)합니다.

이는 계획을 세우는 모델을 완전히 바꾸는 방식입니다. 여러 모델과 함께 브레인스토밍을 하여 항상 최고 중의 최고를 확보할 수 있습니다. 하나의 모델은 환각(hallucinate)을 일으킬 수 있지만, 네 개가 동시에 환각을 일으키는 것은 더 어렵기 때문입니다.

명세 기반 개발 (Spec-driven development)

Kiro에서 제 관심을 가장 끌었던 부분은 IDE 내부에 이미 포함되어 있는 명세 기반 개발 (spec-driven development)입니다.

개발자들에게 이것은 완전히 새로운 개념은 아닙니다. 티켓(ticket)을 정의하고, 요구사항을 부여하고, 설계를 생성한 다음, 다양한 하위 작업(sub-tasks)을 기반으로 티켓을 구현하는 것과 유사합니다.

Kiro의 명세 모드(spec-mode)는 요구사항과 설계(design)를 생성하고 여러분을 위한 작업 목록(task list)을 만들어 줍니다. 이 모든 것은 Markdown 파일로 생성되며, 여러분은 이를 검토하고 여러분의 애플리케이션이나 리포지토리(repository)를 위한 컨텍스트(context)로 활용할 수 있습니다.

만약 제가 명세 기반 개발(Spec-Driven Development)에 더 집중한 기사를 쓰는 것에 관심이 있다면 댓글을 남겨주세요.

결론

이 기사에서 우리는 Steerings, Hooks, MCPs, Powers, 그리고 맞춤형 에이전트(customizable agents)가 무엇인지 살펴보았으며, 명세 기반 개발(spec-driven development)에 대해서도 살펴보았습니다.