Kiro Powers와 Steering 간의 컨텍스트 라우팅 방법 (2026년 가이드)

우선 Powers가 해결하고자 했던 문제부터 살펴보겠습니다. Kiro 문서는 이를 두 문장으로 요약합니다. "프레임워크 컨텍스트가 없으면 에이전트는 추측을 합니다." 그리고 "컨텍스트가 너무 많으면 에이전트가 느려집니다." 여러 MCP 서버를 연결한다는 것은 작업을 시작하기 전에 모든 도구 정의를 미리 로드해야 함을 의미합니다.

Powers는 활성화(activation) 방식을 통해 이 문제를 해결합니다. "모든 MCP 도구를 한 번에 로드하는 대신, 대화 속 키워드를 기반으로 Powers가 동적으로 활성화됩니다." 작업이 시작되면 Kiro는 "작업 설명을 읽고", "설치된 Powers를 작업과 비교 평가한 후", "관련된 Powers만 컨텍스트에 로드"합니다. 그리고 작업이 끝나면 다시 비활성화됩니다. Kiro의 공식 예시에 따르면, 결제 작업에서 데이터베이스 작업으로 전환할 때 "Supabase Power가 활성화되고 Stripe는 비활성화"됩니다.

Power는 하나의 패키지입니다. 이는 Agent Plugins 사양을 따르며, 필수인 plugin.json 매니페스트와 선택 사항인 skills/, mcp.json 및 "Steering 파일과 같은 Kiro 전용 확장 기능"을 위한 dev.kiro/ 폴더로 구성됩니다. 매니페스트의 keywords 필드가 트리거 역할을 합니다. 이는 "활성화를 트리거하는 문자열 배열로, 개발자들이 해당 도구에 대해 이야기할 때 사용하는 용어와 일치해야 합니다."

Steering은 다르게 작동합니다. Kiro는 이를 "마크다운 파일을 통해 프로젝트에 대한 지속적인 지식을 에이전트에게 제공하는 것"으로 설명하며, 현재 4가지 포함 모드를 지원합니다. "Always included(항상 포함)"는 기본값으로, "모든 코드 생성에 영향을 미쳐야 하는 핵심 표준"에 사용됩니다. 조건부 포함(Conditional inclusion)은 "지정된 패턴과 일치하는 파일로 작업할 때만" 파일을 로드합니다. 수동 포함(Manual inclusion)은 채팅에서 해당 파일을 참조할 때 로드합니다. 그리고 자동 포함(Auto inclusion)은 "요청이 설명과 일치할 때" 로드하며, Kiro는 이것이 "Skills와 유사하게 작동한다"고 언급합니다.

따라서 두 방식 모두 관련이 있을 때만 로드하는 방법을 가지고 있습니다. Kiro 문서는 "How powers differ from skills and steering"이라는 섹션에서 의도된 구분을 명확히 설명합니다.

"Powers는 MCP 도구, 스킬, 지식을 하나의 설치 가능한 패키지로 묶은 플러그인입니다. 컨텍스트에 따라 동적으로 활성화됩니다. 도구와 가이드가 모두 필요한 연동 기능에 사용하세요."

"Steering은 에이전트의 행동을 형성하는 Kiro 전용 컨텍스트입니다. always, auto, fileMatch, manual 모드를 지원합니다. 프로젝트 표준 및 컨벤션에 사용하세요."

비교 분석에서 명시적으로 밝히지는 않았지만 설치 페이지를 보면 명확히 알 수 있는 차이점이 하나 더 있습니다. 바로 각 기능이 저장되는 위치입니다. Steering은 리포지토리에 저장됩니다. "에이전트는 리포지토리 루트의 .kiro/steering/ 폴더에서 Steering 파일을 자동으로 찾습니다." 반면 Powers는 Powers 패널을 통해 레지스트리, GitHub URL 또는 로컬 폴더에서 설치됩니다. 레거시 형식의 Power는 MCP 서버를 "사용자의 ~/.kiro/settings/mcp.json 설정 파일"에 등록하고, Agent Plugins 형식의 Power 서버는 "Kiro가 내부적으로 관리"합니다. 어느 쪽이든 Power는 리포지토리가 아닌 개별 사용자의 환경 설정의 일부입니다.

모든 것을 상시 활성화된 Steering에 넣기. 작동은 하지만, 모든 작업에서 비용을 지불해야 합니다. README의 오타를 수정하는 동안에도 결제 API에 대한 긴 노트 블록이 로드됩니다. 컨텍스트가 많은 자료에 대한 Kiro의 권장 사항은 더 좁은 범위의 모드를 사용하는 것입니다.

팀 컨벤션을 Power로 만들기. Power는 개인별로 설치됩니다. 팀의 에러 처리 규칙이 내가 설치한 Power에 들어 있다면, 이를 설치하지 않은 동료는 해당 규칙 없이 작업하게 되며, 리포지토리에는 누락된 사항이 전혀 표시되지 않습니다.

프로젝트 사실 관계를 키워드에 의존하기. 키워드는 연동 기능에 적합합니다. 개발자들이 작업할 때 자연스럽게 "Stripe"나 "데이터베이스" 같은 단어를 말하기 때문입니다. 하지만 프로젝트 컨벤션은 요청에 항상 신뢰성 있게 등장하는 특정 단어와 매칭하기 어렵습니다.

Auto Steering과 Powers를 동일하게 취급하기. 둘 다 관련성에 따라 활성화되지만, MCP 도구를 함께 가져오는 것은 하나뿐이며, 리포지토리와 함께 이동하는 것도 하나뿐입니다.

모든 인터페이스에서 포함 모드가 동일하게 작동한다고 가정하기. 현재 Kiro의 Steering 페이지에는 두 가지 상충되는 내용이 있습니다. 기능 표에는 "포함 모드(always, fileMatch, manual)"가 IDE, CLI, 웹, 모바일에서 지원된다고 표시되어 있습니다. 하지만 동일한 페이지에 다음과 같은 노트도 있습니다. "Kiro CLI에서는 현재 포함 모드가 지원되지 않습니다. .kiro/steering/ 디렉터리의 모든 Steering 파일이 자동으로 로드됩니다." 두 내용이 일치할 때까지는 어느 한쪽을 맹신하기보다 CLI에서 직접 동작을 검증해 보세요. IDE와 CLI를 위한 Kiro Steering 분리에 관한 이전 가이드는 두 번째 설명을 바탕으로 작성되었습니다.

라우팅은 결국 모든 컨텍스트 조각에 대해 두 가지 질문으로 귀결됩니다. 이 리포지토리에서 작업하는 모든 사람에게 필요한가? 그리고 무엇이 이를 트리거해야 하는가?

Step 1: 대상 및 트리거별로 각 컨텍스트 분류하기

현재 에이전트가 알고 있는 내용(Steering 파일 및 프롬프트에서 반복하는 모든 내용)을 나열해 보세요. 각 항목에 대해 다음 두 가지를 기록합니다.

대상(Audience): 이 리포지토리에서 작업하는 모든 사람에게 해당하는 사실인가요, 아니면 일부 사람들만 사용하는 도구에 관한 것인가요? 에러 처리 컨벤션, 디렉터리 구조, 테스트 명령어 등은 팀 공통의 사실(team facts)입니다. 특정 벤더의 API를 올바른 멱등성 패턴으로 호출하는 방법은 도구 전문 지식(tool expertise)입니다.

트리거(Trigger): 언제 로드되어야 하나요? 항상, 특정 파일이 열려 있을 때, 요청이 설명과 일치할 때, 아니면 누군가 명시적으로 요청할 때만인가요?

이를 통해 간단한 그리드가 만들어집니다. 어떤 트리거든 팀 공통의 사실은 Steering으로 갑니다. 도구와 함께 제공되는 도구 전문 지식은 Power로 갑니다. 도구가 없는 도구 전문 지식(예: 라이브러리 사용법 노트)은 둘 중 어디로든 갈 수 있으며, 대개 대상에 대한 질문을 통해 결정됩니다.

Step 2: 팀 컨벤션은 Steering에 유지하되, 작동하는 가장 좁은 범위의 모드 사용하기

각 팀 공통 사실에 대해 정확히 적용되는 시점에만 로드되도록 포함 모드를 선택합니다.

진정으로 보편적인 표준은 "always"로 유지합니다. Kiro가 제시하는 이 모드의 예시는 "기술 스택, 코딩 컨벤션, 핵심 아키텍처 원칙"입니다.

코드베이스의 특정 부분에 종속된 컨벤션은 파일 패턴을 사용하는 조건부 포함(conditional inclusion)을 적용하여, 컴포넌트 파일이 사용될 때만 컴포넌트 규칙이 로드되도록 합니다.

특정 요청에만 중요한 긴 가이드는 Kiro가 매칭할 수 있는 name과 description을 포함하여 자동 포함(auto inclusion)을 적용합니다. Kiro가 권장하는 auto 모드의 용도는 "관련이 있을 때만 로드되어야 하는 컨텍스트가 많은 가이드"입니다.

가끔 실행하는 절차(마이그레이션 체크리스트, 트러블슈팅 가이드 등)는 수동 포함(manual inclusion)을 적용합니다. Kiro는 이를 "가끔씩만 필요한 전문 워크플로, 트러블슈팅 가이드, 마이그레이션 절차 또는 컨텍스트가 많은 문서"에 권장합니다.

모든 모드에서 중요한 구조적 규칙이 하나 있습니다. "포함 설정은 파일의 가장 첫 번째 콘텐츠여야 합니다. 그 앞에 빈 줄이나 다른 콘텐츠가 있어서는 안 됩니다." 빈 줄 뒤에 오는 프론트매터(front-matter) 블록은 프론트매터 블록으로 인식되지 않습니다.

커스텀 에이전트를 사용하는 경우 해당 설정도 확인하세요. Kiro는 "커스텀 에이전트를 사용할 때는 Steering 파일이 자동으로 포함되지 않습니다. Steering 컨텍스트를 로드하려면 에이전트의 resources 설정에 명시적으로 추가해야 합니다"라고 명시하고 있습니다.

Step 3: 도구 전문 지식을 Powers로 이동하고, 키워드를 확인한 후 각 인터페이스에서 검증하기

연동 기능의 경우, Steering에 가이드를 다시 작성하는 대신 Power를 설치하세요. 팀에서 사설 도구를 사용하는 경우, Kiro는 직접 빌드하는 것을 지원합니다. 명확한 description과 keywords가 포함된 plugin.json, 그리고 스킬 및 선택 사항인 MCP 설정을 구성하면 됩니다.

설치하는 모든 Power의 키워드를 읽어보세요. 이 키워드가 활성화 시점을 결정하며, 일반적으로 개발자들이 해당 도구에 대해 이야기하는 방식을 기준으로 작성되어 있어 여러분의 팀이 사용하는 용어와 일치하지 않을 수 있습니다.

그런 다음 검증합니다. Power를 트리거해야 하는 작업과 트리거하지 않아야 하는 작업을 시작하여 도구가 나타나고 사라지는지 확인합니다. 조건부 포함 영역을 터치하는 작업을 시작하고 Steering이 로드되는지 확인합니다. Steering 페이지의 상충되는 노트를 고려하여 IDE와 CLI(사용하는 경우) 모두에서 이를 수행하세요. 그리고 Powers가 팀 협업 방식의 일부라면 어떤 것들이 필요한지 기록해 두어, 새로 합류한 동료가 동일한 세트를 설치할 수 있도록 하세요.

1단계를 거치면 어떤 에이전트, 인터페이스, 플러그인이 로드되든 상관없이 유효한 팀 공통 사실 목록이 만들어집니다. MemoryLake는 특정 도구의 폴더 구조나 포함 모드에 의존하지 않고 이 목록을 보관할 수 있는 공간입니다.

사용자는 직접 자신의 언어로 항목을 작성합니다. .kiro/steering, 설치된 Powers 또는 다른 벤더의 저장소에서 데이터를 읽거나 쓰거나 삭제하지 않습니다.

Step 1: API 키 생성하기

로그인한 후 대시보드에서 키를 생성합니다. 이 키를 통해 에이전트는 Kiro나 팀 내 다른 도구에서 사용자가 작성한 항목을 읽을 수 있습니다.

Step 2: 첫 번째 메모리 업로드하기

1단계에서 정리한 팀 공통 사실을 항목당 하나씩 추가하고, 각 컨벤션이 존재하는 이유를 함께 적어줍니다. 이 이유는 나중에 누군가가 규칙을 이동할지, 변경할지, 아니면 그대로 유지할지 결정하는 기준이 됩니다.

Step 3: AI 및 에이전트 연결하기

에이전트가 워크스페이스를 가리키도록 설정합니다. 이렇게 하면 팀원이 어떤 인터페이스나 플러그인 세트를 사용하든 동일한 컨벤션을 사용할 수 있게 됩니다.

첫 번째 차이점은 기본 컨텍스트 크기가 줄어든다는 것입니다. Power와 함께 로드되는 연동 가이드는 모든 작업에서 불필요한 비용을 발생시키지 않습니다. 더 넓은 관점에서, 컨텍스트 창이 커진다고 해서 들어갈 수 있는 내용이 달라지는 것이지 그곳에 있어야 마땅한 내용이 달라지는 것은 아니라는 점은 긴 컨텍스트가 메모리가 아닌 이유에서 다루는 핵심 내용입니다.

두 번째는 팀의 지식이 팀 내에 머문다는 점입니다. Steering에 있는 컨벤션은 리포지토리에 보관되어 검토되고 공유됩니다. 반면 Powers는 각 개인의 설정 영역으로 남게 되는데, 이는 도구에는 적합하지만 모두가 따라야 하는 규칙에는 적합하지 않습니다.

세 번째는 컨텍스트 비용이 명확해진다는 점입니다. 상시 활성화된 Steering에 보편적인 사실만 담겨 있을 때, 모든 요청의 고정된 부분은 작고 예측 가능해집니다. 메모리가 토큰 사용량을 줄이는 방법을 추적하는 팀들은 대개 매번 전송하던 데이터를 중단함으로써 비용을 절감하게 되며, 이는 토큰 비용 절감이 발생하는 곳에서도 언급된 바 있습니다.

네 번째는 긴 세션에 대한 회복 탄력성입니다. 필요에 따라 로드되는 컨텍스트는 세션이 압축(compacted)될 때 누락될 수도 있습니다. 어떤 사실이 반드시 살아남아야 하는지 파악하는 것은 Kiro 압축에서 살아남을 항목 결정하기에서 다루는 핵심 질문입니다.

대상(Audience)을 기준으로 먼저 라우팅하세요. 리포지토리의 모든 사람에게 필요하다면 Steering에 속합니다. 일부 사람들만 사용하는 도구와 함께 제공된다면 Power에 속합니다.

작동하는 가장 좁은 범위의 포함 모드를 사용하세요. 보편적인 표준에는 always, 특정 영역 규칙에는 파일 패턴(fileMatch), 무거운 가이드에는 auto, 가끔 사용하는 절차에는 manual을 사용합니다.

프론트매터(front-matter)를 가장 먼저 배치하세요. 포함 설정은 파일의 첫 번째 콘텐츠로 작성되어야만 작동합니다.

모든 Power의 키워드를 읽어보세요. 키워드가 활성화를 결정하며, 팀의 고유한 어휘가 아닌 일반적인 개발자 용어로 작성되어 있습니다.

팀이 의존하는 Powers 목록을 유지하세요. 한 컴퓨터에 설치된 Power는 리포지토리에 표시되지 않으며, 리포지토리를 새로 클론하는 다음 사람에게도 보이지 않습니다.

각 인터페이스에서 검증하세요. 현재 Kiro의 Steering 페이지는 CLI의 포함 모드에 대해 두 가지 상충되는 설명을 제공합니다. 가정하기보다 직접 테스트해 보고, MCP 서버도 동일한 관점에서 다루세요. 도구 이면의 사실 관계도 어딘가에 함께 보관될 때 비로소 MCP는 누락된 메모리 레이어가 됩니다. 나중에 도구를 이동하는 경우, Kiro에서 Codex로 마이그레이션하기를 통해 어떤 부분을 이전할 수 있는지 확인할 수 있습니다.

Kiro의 Powers와 Steering은 서로 관련된 문제를 서로 다른 위치에서 해결합니다. Powers는 연동 도구와 가이드를 하나로 묶어 대화 흐름에 따라 켜고 끕니다. Steering은 리포지토리 자체의 표준을 보관하며, 각 파일이 로드되는 시점을 제어하는 4가지 포함 모드를 제공합니다.

Kiro 문서는 이 구분을 명확히 밝히고 있습니다. Powers는 "도구와 가이드가 모두 필요한 연동 기능에", Steering은 "프로젝트 표준 및 컨벤션에" 사용됩니다. 여기에 설치 페이지의 내용을 덧붙이자면, Steering은 리포지토리와 함께 이동하고 Powers는 개인과 함께 이동한다는 점입니다.

모든 컨텍스트 조각을 대상과 트리거별로 분류하고, 팀 공통 사실은 작동하는 가장 좁은 범위의 모드로 Steering에 유지하며, 도구 전문 지식은 Powers가 담당하도록 하고, 사용하는 모든 인터페이스에서 이를 검증하세요. 그리고 이러한 메커니즘 중 어느 하나에 의존하지 않는 곳에 팀의 컨벤션을 기록해 두세요.