AWS Builder Center

Builder Center

Kiro의 예전 모습과 지금 — 따로 만들던 세 엔진이 하나로 모이는 중

Kiro의 IDE, CLI, 웹은 각자 다른 에이전트 엔진을 써서 같은 .kiro/ 폴더도 다르게 읽었습니다. 지금은 ACP로 연결하는 엔진 하나로 합치는 중입니다. IDE와 웹은 옮겨 갔고, CLI는 10월 말 3.0에서 옮겨 갈 예정입니다.

Keehyun Jang

같은 .kiro/ 폴더인데 왜 다르게 읽었을까

Kiro는 AWS가 만든 AI 코딩 도구입니다. 데스크톱 IDE, 터미널에서 쓰는 CLI, 브라우저에서 쓰는 웹, 휴대폰 앱처럼 여러 화면(Kiro는 이것을 surface라고 부릅니다)으로 제공됩니다. 어느 화면에서든 프로젝트 루트의 .kiro/ 폴더에 에이전트 설정, hook(정해진 순간에 자동으로 실행되는 동작), steering(에이전트에게 주는 지침) 같은 파일을 둡니다.
저는 AI-DLC라는 오픈소스 개발 방법론(awslabs/aidlc-workflows )을 Kiro에서 쓰면서 그 설정 파일을 자주 들여다봤습니다. 그러면서 오래 이상하다고 느낀 것이 있습니다. 같은 Kiro인데 IDE용과 CLI용 설정 파일이 따로 있어야 했다는 점입니다. 공개 저장소의 AI-DLC v2.7.0 (2026년 9월)을 보면 IDE용 폴더에 이름이 같은 hook 파일이 두 가지 형식으로 나란히 들어 있습니다. 하나는 예전 IDE가 읽는 .kiro.hook 파일이고, 다른 하나는 새 IDE가 읽는 .kiro/hooks/*.json 파일입니다. CLI용 폴더에서는 hook이 아예 에이전트 설정 파일 안에 들어 있습니다.
처음에는 같은 프로그램의 설정 문법이 버전마다 조금씩 다른 것이라고 생각했습니다. 그런데 Kiro 팀이 2026년 8월에 공개한 글을 읽고 나서 이해가 바뀌었습니다. 그 차이는 문법 차이가 아니었습니다. 화면마다 에이전트 엔진이 아예 달랐던 것입니다.
이 글은 Kiro 팀의 공개 글과 문서, 그리고 Mac에서 직접 테스트한 결과를 바탕으로 썼습니다.

예전 모습: 화면마다 따로 만든 harness

Kiro 팀은 에이전트를 움직이는 이 층을 harness라고 부릅니다. 정의는 이렇습니다. 에이전트의 작업 반복(agent loop), 도구 실행, 하위 에이전트(sub-agent)에게 일 맡기기, 세션 관리, 설정 읽기, 모델과의 통신을 맡는 조율 계층입니다. 사용자가 보는 화면 뒤에서 실제로 "에이전트"로 일하는 부분입니다.
Kiro 팀의 글 "One agent, every surface" (2026년 8월 3일)에 따르면, 초기에는 빠르게 실험하려고 화면을 맡은 팀마다 harness를 직접 만들게 했습니다.
The IDE team built theirs in TypeScript to fit the Code OSS extension model, the CLI team built theirs in Rust for performance, and the web team built theirs in Python to stay close to the latest agent research.
IDE 팀은 TypeScript로, CLI 팀은 Rust로, 웹 팀은 Python으로 만들었습니다. 이름은 같은 Kiro지만 속은 서로 다른 언어로 쓰인 세 프로그램이었습니다. 덕분에 팀마다 빠르게 내놓을 수 있었지만, 팀마다 다른 선택을 했습니다. 아래 표에 나오는 spec 기반 개발은 요구사항을 정리하고, 기술 설계를 만들고, 작업 목록으로 나누는 과정을 에이전트와 함께 밟는 Kiro의 대표 기능입니다. Powers는 특정 기술의 도구와 작업 방법을 묶어 두었다가 필요할 때 에이전트에게 불러 주는 기능입니다. 같은 글이 짚은, 화면마다 달랐던 지점을 정리하면 다음과 같습니다.
갈라진 것IDE (0.x)CLI (예전 엔진, 1.x·2.x)
터미널 명령 권한trustedCommands 접두어(prefix) 일치 + 거부 목록은 부분 문자열 일치allowedCommands와 deniedCommands의 정규식 일치
세션 저장 방식따로따로
긴 대화 압축(compaction) 전략따로따로
하위 에이전트와 맥락 공유따로따로
쓸 수 있는 기능spec 기반 개발과 Powers는 IDE에만plan mode(계획 모드)와 code intelligence(코드 분석 기능)는 CLI에만
CLI 쪽은 계보도 알아 두면 좋습니다. Kiro CLI는 2025년 11월 17일, Kiro가 정식 출시(GA)된 날 함께 나왔습니다. 이때 버전이 1.20.0이었습니다. Kiro 문서는 이 CLI를 "the next update of the Q CLI"라고 소개합니다(Upgrading from Amazon Q Developer CLI ). 첫 버전 번호가 1.0이 아니라 1.20.0인 것도 이 계보와 함께 보면 이해하기 쉽습니다.
권한도 화면마다 따로였습니다. 예전 IDE에는 Autopilot과 Supervised 두 모드만 있었고, Kiro 문서는 이렇게 적습니다. "There was no way to allow some operations while blocking others — it was all-or-nothing."(IDE 0.x reference ) 두 화면 모두 권한을 도구 단위로 걸었다는 점도 문제였습니다. 예를 들어 ".env 파일은 읽지 마라"를 지키려면 파일을 읽을 수 있는 도구(read, glob, grep, code intelligence)마다 따로 막아야 했습니다. 하나라도 빠뜨리면 에이전트는 다른 도구로 그 파일을 읽을 수 있었습니다.
비용도 쌓였습니다. 같은 글은 이렇게 씁니다. "Every new capability had to be built and maintained three times … Bugs had to be fixed three times."
더 큰 문제는 이 구조로는 Kiro 팀이 처음부터 그리던 모습을 만들 수 없었다는 점입니다. 하루 일을 마치고 노트북을 닫아도 세션은 클라우드에서 계속 돌고, 커피를 사러 가는 길에 휴대폰으로 진행 상황을 보고, 다음 날 아침 IDE를 열어 이어서 일하는 모습입니다. 세션이 화면과 장비를 옮겨 다녀야 하는 그림입니다. 그런데 세 harness는 세션 형식도, 도구도, 설정 모델도 공유하지 않았습니다. 그래서 한 화면에서 시작한 세션을 다른 화면으로 옮기는 일은 "architecturally impossible", 즉 구조상 불가능했다고 적었습니다.

전환점: 웹판 공개 출시를 앞두고

Kiro 팀은 다른 방법도 검토했습니다. harness는 세 개로 두고, 에이전트가 어떻게 동작해야 하는지 계약만 맞추는 방법입니다. 하지만 이 방법을 택하지 않았습니다. 새 기능이 하나 생길 때마다 명세 하나, 구현 세 벌, 세 구현이 똑같이 동작하는지 계속 확인하는 일이 따라붙기 때문입니다.
결정의 계기는 웹판의 공개 출시 준비였습니다. 웹판을 그 전용 에이전트 그대로 내보내면 세 벌을 따로 고치는 비용이 계속 불어납니다. Kiro 팀은 그 대신 세 팀이 배운 것을 모아 harness 하나를 새로 만들기로 했습니다. 글에 따르면 이 harness도 Kiro로 만들었습니다.

하나로 모으는 방법: 라이브러리가 아니라 별도 프로세스

이 이야기에서 가장 흥미로운 결정은 harness를 라이브러리가 아니라 독립된 서버 프로세스로 만든 것입니다.
공통 코드를 라이브러리로 묶어 각 화면에 넣는 방법이 더 쉬워 보입니다. Kiro 팀은 이전 시도에서 그 방법이 경계를 지키지 못한다는 것을 봤다고 씁니다. 화면 코드가 공개하려던 적 없는 내부 함수를 부르거나, 라이브러리 위에 자기 에이전트 로직을 덧쌓기 시작합니다. 그러면 구현은 다시 갈라집니다. 프로세스를 따로 두면 화면과 에이전트 사이에 실제 벽이 생깁니다. 정해진 프로토콜로만 넘어갈 수 있고, 화면은 자기 언어와 런타임을 그대로 쓸 수 있습니다.
역할은 이렇게 나뉩니다.
  • harness: 도구, 맥락, 권한, 모델과의 통신처럼 에이전트 쪽의 모든 일
  • 화면(클라이언트): 사용자가 에이전트와 어떻게 주고받고, 에이전트가 한 일을 어떻게 보여 줄지
둘 사이의 프로토콜로는 ACP(Agent Client Protocol)를 골랐습니다. 편집기와 AI 코딩 에이전트가 주고받는 방식을 표준으로 정한 규격이고, 2026년 6월에 1.0이 됐습니다. Kiro 팀은 ACP를 "LSP(Language Server Protocol)의 AI 에이전트판"이라고 설명합니다(Kiro adopts ACP , 2026년 2월 5일). Kiro CLI는 통합 전부터 JetBrains IDE나 Zed 같은 편집기와 연결하려고 ACP를 지원하고 있었습니다. 통합 harness에서는 바깥 편집기뿐 아니라 Kiro 자신의 화면들도 이 프로토콜로 harness와 이야기합니다.
  • 로컬 화면(IDE, CLI)은 harness를 자식 프로세스로 띄우고 표준 입출력(stdio)으로 연결합니다.
  • 웹과 iOS 앱은 클라우드 sandbox에서 도는 harness에 WebSocket으로 연결합니다.
  • 실시간 방향 지시(live steering), spec 작업 흐름, 범위별 권한 같은 Kiro 고유 기능은 ACP의 확장 규칙에 따라 _kiro/ 이름공간에 추가했습니다. Kiro 팀이 밝힌 숫자를 더하면 메서드와 알림 종류가 쉰 개를 넘습니다.
이 구조가 실제로 따로 떠 있는 것은 Mac에서 테스트할 때도 볼 수 있었습니다. kiro-cli 2.30.0에서 자세한 기록(-v)을 켜고 --v3를 붙여 띄우면, 실행 기록에 KAS (Kiro Agent Server)가 시작된다는 줄이 먼저 찍힙니다. --v3를 붙이지 않으면 그런 줄이 없습니다. 지금 CLI 설치본에는 예전 엔진과 새 harness가 함께 들어 있고, 플래그로 둘 중 하나를 고르는 상태입니다.

하나가 되자 달라진 것

통합의 첫 효과는 한 화면에만 있던 기능이 다른 화면으로도 가기 시작한 것입니다. 설정 형식도 하나로 모였습니다.
대상통합 전통합 harness
spec 기반 개발IDE에만CLI(/spec new)와 웹에서도
사용자 정의 에이전트화면마다 다르게 동작.kiro/agents/의 Markdown 파일. 도구는 개별 이름 대신 read·write·shell 같은 태그로 고른다
hookIDE는 .kiro.hook, CLI는 에이전트 설정 안에공통 형식은 .kiro/hooks/*.json. CLI V3는 에이전트 설정 안에 같은 형식의 목록을 두는 것도 지원
긴 대화 압축harness마다 전략이 달라서, 대화가 길어지면 화면마다 다르게 동작구현 하나
권한화면마다 다른 문법, 도구 단위능력(capability) 단위 규칙 하나
가장 크게 바뀐 것은 권한입니다. 새 권한 모델은 형식 검증된 정책 언어 Cedar 를 바탕으로 합니다. 도구를 하는 일에 따라 fs_read, fs_write, shell, web_fetch, mcp, subagent 같은 능력으로 묶습니다. 그래서 앞에서 본 ".env는 읽지 마라"를 규칙 하나로 쓸 수 있습니다. 아래는 Kiro 권한 문서 의 문법으로 설명을 위해 만든 예시입니다.
1
2
3
4
5
6
rules:
- capability: fs_read
effect: deny
match:
- "**/.env"
- "**/.env.*"
fs_read를 막으면 파일을 읽는 도구 전부가 막힙니다. 도구를 하나하나 적을 필요가 없고, 나중에 새로 생기는 읽기 도구에도 같은 규칙이 적용됩니다. 규칙이 겹치면 범위(사용자 전역, 워크스페이스, 에이전트 등)와 상관없이 deny가 ask보다, ask가 allow보다 우선합니다. 에이전트가 자기 권한 파일을 고칠 수 없다는 것처럼, Kiro가 스스로 지키는 바꿀 수 없는 규칙도 있습니다.
두 번째 효과는 harness만 고쳐도 새 기능을 여러 화면에 함께 낼 수 있다는 것입니다. ACP 경계를 건드리지 않는 변경이면 화면 코드를 고치지 않아도 됩니다. Kiro 팀은 8월 글에서 예로 세 가지를 들었습니다. 세션 도중 .kiro/agents/의 파일을 고치면 바로 반영되는 기능, 모든 워크스페이스에서 실행되는 전역 hook(~/.kiro/hooks/), 자주 쓰는 규칙을 이름으로 묶은 policy preset입니다. 세 가지 모두 화면 코드를 고치지 않고 harness 업데이트만으로 내놓았다고 합니다.

다만 "모든 화면이 완전히 같다"는 뜻은 아니다

통합 harness를 "어느 화면에서든 완전히 같은 프로그램"으로 읽으면 틀립니다. Kiro 팀도 "The harness is not one-size-fits-all"이라고 분명히 적었습니다. 화면은 자기 도구를 제공하고 harness의 기본 도구를 끌 수 있습니다. 예를 들어 IDE는 파일을 직접 읽고 쓰는 harness 도구 대신 Code OSS API를 쓰는 자기 도구를 씁니다. 화면마다 지원하는 기능에도 아직 차이가 있습니다. 예를 들어 웹에서는 에이전트가 격리된 클라우드 sandbox에서 돌기 때문에, permissions.yaml 규칙과 동작마다 묻는 승인이 적용되지 않습니다(Permissions ). hook도 Hooks 문서 의 지원표에는 IDE와 CLI만 표시돼 있고, 웹과 휴대폰 앱은 비어 있습니다. How Kiro works 문서는 어떤 기능이 아직 어느 화면에 오지 않았는지를 기능 페이지마다 표로 알려 준다고 씁니다.
그래서 저는 통합을 이렇게 이해합니다. 에이전트가 하는 일(설정을 읽는 방식, 권한 판정, 압축)은 하나로 모였고, 사람이 에이전트를 다루는 방식은 화면마다 남아 있다.

버전 번호가 헷갈리는 이유

Kiro의 역사를 따라가다 보면 버전 번호에서 자주 막힙니다. kiro-cli --version은 2.30.0이라고 답하는데, 문서와 공지에는 "CLI 3.0", "V3"가 나옵니다. 번호가 두 가지를 가리키기 때문입니다.
  • 제품 버전: 설치한 앱의 번호입니다. 지금 CLI는 2.30.0, IDE는 1.2.x입니다.
  • 엔진 세대: 어떤 harness가 대화를 처리하는지입니다. CLI 2.x 안에는 예전 엔진(V2)과 통합 harness(V3)가 함께 들어 있습니다.
이 둘을 구분하면 번호가 헷갈리는 이유가 대부분 풀립니다.
  1. Kiro의 정식 출시는 1.0이 아니었습니다. 2025년 11월 17일 GA 때 IDE는 0.6이었습니다.
  2. Kiro CLI의 첫 버전은 1.0이 아니라 1.20.0이었습니다. Kiro 문서는 Kiro CLI를 Amazon Q Developer CLI의 다음 업데이트라고 소개합니다.
  3. CLI 2.0은 통합 harness를 들인 릴리스가 아니었습니다. 2026년 4월 13일의 2.0은 새 터미널 UI(TUI)를 기본으로 하고, headless 실행과 Windows를 지원했습니다. 새 harness(V3)는 그 뒤 6월의 2.8.0에서 기존 2.x 엔진과 나란히 처음 나왔습니다.
  4. CLI 3.0은 아직 나오지 않았습니다. 지금 "V3"는 2.x 설치본 안에서 --v3로 고르는 엔진입니다.
  5. IDE는 1.0에서 엔진을 바꿨습니다. CLI는 번호 하나(3.0)로 엔진 교체를 표시할 예정이지만, IDE는 0.x에서 1.0으로 넘어갈 때 통합 harness로 옮겨 갔습니다.
연표로 보면 이렇습니다.
날짜무엇이 있었나
2025-07-14IDE 0.1 미리보기 공개
2025-11-17Kiro 정식 출시(IDE 0.6), Kiro CLI 1.20.0 출시
2026-02-05CLI가 ACP 지원 발표
2026-04-13CLI 2.0: 새 터미널 UI 기본, headless 실행, Windows 지원
2026-06ACP 1.0
2026-06-17CLI 2.8.0: V3를 미리 써 보는 --v3 추가. 같은 날 iOS 앱 공개(early access)
2026-06-25IDE 1.0.0: 능력 기반 권한, Markdown 에이전트, v1 hook 형식
2026-07-22CLI 2.14: V2 에이전트 설정을 V3에서도 쓸 수 있게 바꾸는 /upgrade-agent
2026-08-03Kiro 팀, 네 화면(IDE, CLI V3, 웹, iOS)이 통합 harness로 동작한다고 발표
2026-09-01Kiro 웹 정식 출시
2026-10-09"CLI V3를 기본으로 전환한다"는 공지
2026-10-12CLI 2.30: 시작할 때 V3 전환을 권하는 안내를 단계적으로 배포
2026년 10월 말(예정)CLI 3.0: V3가 기본
날짜는 Kiro 변경 기록 과 블로그 각 글의 게시일입니다.

지금 어디까지 왔나

화면별로 보면 이렇습니다.
  • IDE: 1.0부터 통합 harness를 씁니다. 지금은 1.2.x입니다.
  • 웹: 9월 1일 정식 출시됐습니다. 클라우드 sandbox에서 harness를 돌립니다.
  • 휴대폰(iOS): 아직 미리보기(early access)입니다. 사용 신청을 하고 차례가 오면 Apple TestFlight로 설치해서 씁니다. 휴대폰 앱은 harness를 직접 띄우지 않고 웹과 같은 클라우드 세션에 붙습니다. 웹, IDE, CLI에서 시작한 클라우드 세션을 휴대폰에서 이어서 지시하고, 작업을 새로 시작하거나 바뀐 코드를 검토하고 변경을 승인할 수 있다고 Kiro는 소개합니다(Mobile ). Pro 이상 유료 플랜과 iOS 26 이상이 필요하고, 모바일 전용 문서는 아직 "coming soon" 상태입니다. 안드로이드는 아직 지원하지 않습니다. Kiro 모바일 소개 페이지 는 "Is Android coming?"이라는 질문에 "We're starting with iOS for now, and we'll provide updates if Android is supported in the future."라고만 답합니다.
  • CLI: 아직 예전 엔진이 기본입니다. Mac에서 설정이 하나도 없는 빈 폴더에 kiro-cli 2.30.0을 플래그 없이 띄워 테스트했습니다. 실행 기록은 --v2를 붙였을 때와 같았고, 첫 화면에는 "An early release of Kiro CLI V3 is now available! Try it out: kiro-cli --v3"가 떴습니다. --v3를 붙였을 때만 "Welcome to Kiro CLI V3!"가 나왔습니다.
앞에서 본 그림도 아직 다 이뤄지지는 않았습니다. Kiro 팀은 8월 글에서 세션을 다른 환경으로 옮기기 위한 세션 묶음(session packaging), 어느 화면에서든 로컬 세션과 클라우드 세션을 함께 다루는 기능을 앞으로 만들 것으로 꼽았습니다. 통합 harness 덕분에 이런 기능도 한 번만 만들면 된다는 것이 Kiro 팀의 설명입니다.
흥미로운 점은 Kiro 문서는 이미 통합이 끝난 모습을 기준으로 쓰여 있다는 것입니다. How Kiro works  페이지는 "Every Kiro surface (the IDE, CLI, Web, and Mobile) is a front end to that same harness."라고 씁니다. CLI만 놓고 보면 이 문장은 아직 "V3를 고르면"이라는 조건이 붙은 상태입니다.
그 조건도 곧 사라질 예정입니다. 10월 9일 공지 "Kiro CLI V3 is rolling out as the default experience" 는 일정을 이렇게 밝혔습니다.
Starting October 12, we are gradually rolling out a startup prompt inviting you to switch ahead of the CLI 3.0 release by the end of October.
시작 안내에서 "Don't ask again"을 골라도 V2에 남지 않습니다. 공지는 이렇게 씁니다. "your setup will still be upgraded to V3 when CLI 3.0 is released at end of October." 3.0 이후에도 kiro-cli --v2로 예전 엔진을 쓸 수는 있지만 그 실행 한 번에만 적용됩니다. 이 공지에는 예전 엔진을 언제까지 쓸 수 있는지가 적혀 있지 않습니다.
CLI 3.0과 함께 정리되는 것도 있습니다. 예전 터미널 화면(Classic), 셸 명령 자동 완성, CLI 데스크톱 앱입니다. Classic 화면은 V3를 지원하지 않습니다. 그래서 9월 30일의 2.26부터 Classic으로 시작하면 지원 중단 안내가 나옵니다.
이 흐름은 CLI 밖에서도 보입니다. 내 컴퓨터나 원격 장비에서 계속 도는 개인 AI 에이전트 Kiro Crew에는 세션을 돌릴 harness를 고르는 기능이 미리보기로 들어왔습니다. 선택지 가운데 하나가 KAS이고, 문서는 이를 "Runs the Kiro agent harness through Kiro CLI's ACP relay"라고 설명합니다(Agent backends ). 다만 기본 선택지는 아직 "Kiro CLI"입니다.

V3로 옮겨 갈 때 확인할 것

새 엔진으로 옮겨도 대부분은 설정을 고칠 필요가 없다고 Kiro는 안내합니다. 하지만 사용자 정의 에이전트, 권한, hook을 직접 만들어 썼다면 변환 결과를 확인해야 합니다. 엔진이 다른 프로그램이었던 만큼, 설정을 읽는 방식 자체가 다르기 때문입니다.
권한은 규칙을 세우는 방식이 바뀌었습니다. V2는 신뢰하는 도구 목록과 도구별 설정을 쓰고, V3는 "어떤 동작을 어떤 대상에" 하는지에 대한 규칙을 씁니다. 도구별 설정과 능력별 규칙은 1:1로 대응하지 않습니다. 그래서 자동 변환은 지원하는 설정만 바꿉니다. 일부 패턴은 직접 확인하거나 다시 써야 합니다. Kiro는 변환 뒤 /upgrade-agent diagnostics로 경고를 확인하고 나서 새 규칙을 믿으라고 안내합니다.
Mac에서 예전 형식 에이전트 설정이 있는 상태로 --v3를 처음 띄우자 자동 변환이 실행됐고, 그 가운데 일부 설정에 변환 경고가 찍혔습니다. allowedTools에 web_* 같은 패턴을 쓴 설정은 새 규칙으로 대응되지 않았고, V3에 없는 use_aws 도구를 쓴 설정도 경고를 받았습니다. V3에서는 AWS CLI 명령을 shell 도구로 실행하고 shell 권한 규칙을 따릅니다. 2.30 변경 기록은 V3로 바꿀 때 V2에서 쓰던 접근을 더 많이 유지하도록 했다고 설명합니다("keeps more of your V2 agent access"). 경고만 보지 말고 백업 파일과 변환된 파일의 권한 규칙도 한 번 비교해 보길 권합니다.
hook은 형식과 두는 자리를 확인해야 합니다. 예전 CLI는 에이전트 설정 안에 hook을 객체로 넣었고, 트리거 이름도 agentSpawn 같은 camelCase였습니다. V3는 SessionStart 같은 PascalCase 트리거를 쓰는 목록 형식입니다. /upgrade-agent는 예전 hook을 그 에이전트 설정 안의 새 형식 목록으로 바꿔 줍니다. 특정 에이전트와 상관없이 늘 실행하거나 IDE와 함께 쓸 hook은 .kiro/hooks/*.json 파일로 옮기라고 Kiro 문서는 안내합니다. 변환할 수 없는 hook은 V3 설정에서 빠지고 경고로 알려 줍니다. IDE 1.0에서도 0.x의 예전 hook은 Agent Hooks 패널에서 마이그레이션할 수 있습니다. 직접 만든 hook이 실제로 실행되는지는 옮긴 뒤에 꼭 한 번 확인해 보세요.
변환 도구가 있습니다. 세션 안에서는 /upgrade-agent를 씁니다. 팀의 에이전트를 한 저장소에 모아 둔다면 2.29부터 kiro-cli agent upgrade <dir>로 폴더 전체를 바꿀 수 있습니다. 먼저 --dry-run으로 바뀔 내용과 경고를 보면 됩니다. 원본은 <name>.json.bak으로 백업됩니다.
세션은 한쪽으로만 이어집니다. V2 세션은 V3에서 이어 쓸 수 있지만, V3에서 만든 세션은 V2에서 열 수 없습니다.
지금 어느 엔진인지 확인하는 법도 알아 두면 좋습니다. 대화형으로 띄웠을 때 "Welcome to Kiro CLI V3!"가 보이면 V3입니다. 기본값을 미리 V3로 바꾸려면 공지에 나온 대로 kiro-cli settings chat.agentEngine v3를 씁니다. 프로젝트 하나에서만 V3를 쓰고 싶다면 프로젝트의 .kiro/settings/cli.json에 "chat.agentEngine": "v3"를 넣는 방법도 있습니다. Mac에서 2.30.0으로 테스트해 보니 그 설정을 둔 폴더 안에서는 플래그 없이 V3로 떴고, 설정이 없는 폴더에서는 V2로 떴습니다. CLI 설정 문서 는 kiro-cli settings --workspace로 프로젝트별 값을 저장하는 방법을 안내하지만, chat.agentEngine을 프로젝트별로 바꿀 수 있다고 명시하지는 않습니다.

이 글로 알 수 없는 것

구조와 결정 이유는 Kiro 팀의 공개 글을 따랐습니다. 세 harness가 각각 어떤 언어로 쓰였는지, 왜 라이브러리 대신 별도 프로세스를 골랐는지는 Kiro 팀이 블로그에 밝힌 내용입니다. 이 글은 공개된 글과 문서, 그리고 누구나 설치할 수 있는 Kiro CLI를 직접 실행해 본 결과만으로 썼습니다.
직접 확인한 것은 Mac에서 테스트한 결과입니다. kiro-cli 2.30.0에서 플래그 없이 띄웠을 때 V2로 시작한다는 것, --v3일 때 KAS가 뜬다는 것, 프로젝트 설정으로 엔진이 바뀐다는 것, 자동 변환이 남긴 경고가 여기에 해당합니다. 시작 안내는 단계적으로 배포되고 있으니 같은 버전이라도 다르게 보일 수 있습니다.
10월 말 일정은 예고입니다. CLI 3.0이 실제로 언제 나오는지, 예전 엔진을 언제까지 쓸 수 있는지는 이 글을 쓰는 시점에 확인할 수 없습니다.

정리

  1. 예전의 Kiro는 이름만 같은 세 프로그램이었습니다. IDE는 TypeScript, CLI는 Rust, 웹은 Python으로 harness를 따로 만들었습니다. 그래서 권한, hook, 세션 형식이 갈라졌고, 기능은 세 번 만들고 버그는 세 번 고쳐야 했습니다.
  2. Kiro는 harness를 별도 프로세스 하나로 합치고, ACP로 화면과 연결했습니다. 라이브러리가 아니라 프로세스로 나눈 덕분에 경계가 지켜지고, harness만 고쳐도 여러 화면에 함께 기능을 낼 수 있습니다. 권한은 Cedar 기반 능력 단위 규칙 하나로, 에이전트와 hook은 한 형식으로 모였습니다.
  3. 통합은 아직 진행 중입니다. IDE와 웹은 옮겨 갔고, CLI는 10월 말 3.0에서 V3가 기본이 될 예정입니다. 사용자 정의 에이전트, 권한, hook을 써 왔다면 지금 --v3로 한 번 띄워 변환 경고를 확인해 두는 것이 좋습니다.

참고 자료

# kiro# ai-ide# ai-dlc# ai# ai-agents
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article