10월 말 Kiro CLI V3 기본 적용 — 기존 V2 세션의 향방과 새로운 메모리 학습 방식 (2026)

V3는 완전히 새로운 것이 아닙니다. Kiro의 블로그 포스트에 따르면 "지난 6월에 V3를 선택 적용(opt-in) 환경으로 처음 소개"했으며, 현재는 "모든 사용자를 위해 V3를 기본값으로 설정할 준비를 하고 있다"고 합니다. 이 프롬프트는 "10월 말 CLI 3.0 릴리스를 앞두고" 10월 12일부터 표시되기 시작했습니다. 포스트는 또한 "이번 배포는 Kiro CLI에만 적용된다"고 덧붙였습니다.

프롬프트는 세 가지 선택지를 제공합니다:

• Switch to V3 and upgrade my configs (V3로 전환 및 설정 업그레이드): "V3를 기본 하네스(harness)로 저장하고, 자동 에이전트 업그레이드를 활성화하며, 워크스페이스 및 글로벌 커스텀 에이전트 설정 마이그레이션을 시작합니다."
• Remind me later (나중에 다시 알림): 문서에 따르면 이 옵션은 "현재 세션을 V2로 유지하고 약 7일 후에 제안을 다시 표시"합니다.
• Don't ask again (다시 묻지 않음): 블로그에서는 이 선택이 거부(opt-out)를 의미하지 않는다는 점을 명확히 하고 있습니다. 이 옵션은 "사용자를 V2에 계속 머물게 하지 않으며, 10월 말 CLI 3.0이 출시되면 설정이 여전히 V3로 업그레이드됩니다."

You can switch back for a single launch with the V2 flag, but "The flag applies to that launch only."

CLI 3.0에서는 일부 기능이 중단되기도 합니다. "CLI 3.0과 함께 인라인 셸 자동 완성(inline shell autocomplete) 및 CLI 데스크톱 앱 지원을 종료합니다. 또한 Classic 환경을 단종하고 터미널 UI의 새로운 기능에 집중할 예정입니다." 문서에는 알아두어야 할 또 다른 차이점이 나열되어 있습니다. "실험적인 /checkpoint 기능은 Classic 전용으로 남으며, V3는 대화 브랜치를 위해 /rewind 기능을 제공합니다."

Kiro CLI는 모든 세션을 자동으로 저장합니다. 세션 관련 문서에 따르면 "모든 대화 턴(turn)마다 모든 채팅 세션을 자동으로 저장"하며, 세션은 디렉터리별로 저장되므로 각 프로젝트는 고유한 히스토리를 가집니다.

V3는 세션을 다른 위치에 저장합니다. 마이그레이션 가이드에서는 다음과 같이 직접적으로 설명합니다. "V3는 V2와 다른 세션 저장소를 사용합니다. V3를 시도할 때 기존 V2 세션은 변환되거나 삭제되지 않습니다." 그리고 기존 세션으로 돌아가는 방법을 알려줍니다. "V2 세션으로 돌아가야 할 때" V2 플래그와 재개 선택기(resume picker)를 사용하여 chat 명령을 실행하면 됩니다.

반대 방향은 불가능합니다. V3 개요에 따르면 "저장된 세션 형식이 다르기 때문에 V2는 V3 세션을 열 수 없습니다. 이는 버전 간 마이그레이션 경계이며, V3의 재개 기능이 누락된 것이 아닙니다." 변경 사항 표에서도 세션 형식 변경을 영향도가 높은(high impact) 항목으로 분류하고 있습니다.

이 부분에서 Kiro의 소스 간에 설명이 다소 다릅니다. 출시 블로그 포스트에서는 "V3에서 V2 세션을 재개할 수 있지만, V3에서 생성된 세션을 V2에서 재개할 수는 없다"고 설명합니다. 반면 마이그레이션 가이드에서는 V2 세션이 변환되지 않는다고 설명하며, 해당 세션으로 돌아가려면 V2 플래그를 사용하라고 안내합니다. 두 소스 모두 V3 세션이 V2로 돌아갈 수 없다는 점에는 동의하지만, V2에서 V3로 가는 방향에 대해서는 다르게 설명하고 있습니다.

이 두 설명이 반드시 모순되는 것은 아닙니다. V3 전용인 세션 대시보드는 이전 작업을 검색할 수 있습니다. "3글자 이상의 쿼리는 로컬 V2 및 V3 트랜스크립트의 인덱싱된 세션 콘텐츠도 검색합니다." V3에서 V2 세션을 찾아 V3에서 이어서 진행하는 것은 기술적으로 다를 수 있으며, 문서에서는 블로그가 정확히 어떤 의미였는지 명시하지 않고 있습니다. 가장 안전한 해석은 마이그레이션 가이드의 설명입니다. V2 세션은 그대로 유지되어 V2를 통해서만 읽을 수 있으므로, 중요한 세션의 경우 직접 테스트해 보기 전까지는 V3에서 이어서 작업할 수 있을 것이라 장담하지 않는 것이 좋습니다.

잃어버려서는 안 되는 중요한 대화의 경우, 마이그레이션 가이드에서 구체적인 조언을 제공합니다. "중요한 대화의 외부 기록이 필요한 경우, 해당 대화를 생성한 하네스로 열고 /chat save <path>를 실행하세요. 대상 하네스가 해당 파일을 로드할 수 있는지 확인하기 전까지는 내보낸 파일을 아카이브(보관용)로 취급하십시오."

여기서 주목해야 할 단어는 "아카이브"입니다. 내보낸 세션은 대화 내용을 보존할 뿐, 에이전트 앞에 해당 컨텍스트를 자동으로 다시 배치해 주지는 않습니다.

V3는 CLI에 메모리 기능을 추가합니다. Kiro의 메모리 페이지에서는 이를 명확하게 설명합니다. "메모리를 통해 Kiro는 한 채팅 세션에서 다음 세션으로 유용한 컨텍스트를 전달할 수 있습니다." 메모리는 "저장소 명령 및 컨벤션, 수정 사항, 디버깅 인사이트, 이미 제외된 접근 방식, 선호하는 작업 방식" 등을 기억할 수 있습니다.

메모리가 학습하는 대상은 두 가지 조건에 의해 결정됩니다.

V3가 필요합니다. "Kiro CLI의 메모리 기능은 V3를 요구합니다." 출시 포스트에서는 이를 "로컬 V3 세션에서의 작업"으로부터 학습한다고 설명합니다. 문서 어디에서도 V2 세션으로부터 학습한다는 설명은 없으므로, V2에서 Kiro에게 가르쳐 준 내용은 사용자가 직접 가져오지 않는 한 해당 세션에만 머물게 됩니다.

권한이 필요합니다. memories 명령을 사용하여 읽기 및 쓰기(read and write), 읽기 전용(read only), 또는 끄기(off) 중 액세스 수준을 선택할 수 있습니다. 읽기 및 쓰기 권한이 있어야만 Kiro가 정보를 변경할 수 있으며, "메모리 액세스 변경 사항은 새로운 Kiro CLI 세션을 시작할 때 적용됩니다." 또한 자동 업데이트 옵션도 제공되는데, 이 옵션의 도움말 텍스트는 "세션이 종료된 후를 포함하여 메모리를 자동으로 생성하고 다듬습니다"라고 설명합니다. 워크스페이스 신뢰(Workspace trust) 기능도 제한을 둡니다. "read & write 권한이 있더라도, 신뢰하지 않는 워크스페이스에서는 Kiro가 메모리를 추가, 변경 또는 삭제할 수 없습니다. 다만 읽기는 여전히 가능합니다."

저장된 내용을 검토할 수도 있습니다. memories 목록에는 각 메모리의 유형, 범위, 업데이트 시간이 표시되지만, "이 목록은 읽기 전용입니다. 메모리를 수정하거나 삭제하려면 채팅에서 Kiro에게 요청하세요."

메모리가 규칙(rules)을 대체하도록 설계된 것은 아닙니다. 문서에서는 "메모리는 학습된 컨텍스트를 추가할 뿐, 현재 대화, Steering(스티어링), 또는 참조 자료를 대체하지 않습니다"라고 명시하며, 다음과 같이 명확히 지시합니다. "규칙이 일관되게 적용되어야 하는 경우, Steering에 작성하십시오."

한 가지 경계가 더 있습니다. 메모리는 현재 CLI 및 웹 전용 기능입니다. IDE의 경우, Kiro의 메모리 페이지에 "IDE 메모리 지원 예정"이라고 표시되어 있습니다.

세션과 메모리는 눈에 띄는 변화입니다. 하지만 세션 시작 시 에이전트가 보게 되는 정보를 바꾸는 조용한 변화들도 존재합니다.

Steering 포함 모드가 이제 완전히 적용됩니다. Kiro의 Steering 페이지에 따르면 "Kiro CLI V3는 always, fileMatch, manual, auto 등 네 가지 포함 모드를 모두 지원합니다. V1/V2에서는 always로 표시된 파일만 자동으로 로드되었습니다. fileMatch 또는 manual로 표시된 파일은 자동 로드에서 제외되었습니다." 전환 후에는 특정 경로로 범위를 지정한 Steering 파일이 해당 경로에서 작업할 때 로드되기 시작하며, auto로 표시된 파일은 요청이 설명과 일치할 때 로드됩니다. 이 페이지의 이전 버전에서는 CLI 포함 모드를 다르게 설명했었으며, IDE와 CLI 간에 Steering 파일을 분리하는 방법에 대한 이전 가이드는 해당 버전을 기준으로 작성되었습니다. 현재 동작에 맞게 Steering 프런트 매터(front matter)를 확인해 보세요.

AGENTS.md가 더 깊은 곳까지 적용됩니다. 출시 포스트에서는 "저장소 루트뿐만 아니라 하위 디렉터리에도 AGENTS.md 파일을 배치할 수 있다"고 언급했으며, Steering 페이지에서는 이 파일들이 "워크스페이스 전반의 하위 디렉터리에서 감지된다"고 확인해 줍니다. AGENTS.md 파일은 포함 모드를 지원하지 않으며 항상 포함됩니다.

커스텀 에이전트는 컨텍스트 필드를 유지합니다. 업그레이드 문서에 따르면 "기타 모든 필드(name, description, model, prompt, resources, mcpServers, welcomeMessage)는 변경 없이 그대로 전달됩니다." Kiro의 Steering 문서에는 이와 관련된 내용이 추가되어 있습니다. "커스텀 에이전트를 사용할 때는 Steering 파일이 자동으로 포함되지 않습니다. Steering 컨텍스트를 로드하려면 에이전트의 resources 설정에 명시적으로 추가해야 합니다." 이 규칙은 업그레이드 후에도 여전히 적용됩니다.

일부 훅(hook)은 마이그레이션되지 않습니다. 블로그에서는 "변환할 수 없는 훅은 V3 설정에서 제외되고 경고로 보고된다"고 밝히고 있습니다. 훅 마이그레이션 페이지에 따르면 변환기는 "V3가 표현할 수 없는 훅을 삭제하고, 잘못된 프로필을 작성하는 대신 경고를 보고"합니다. 에이전트 시작 시 프로젝트 컨텍스트를 주입하기 위해 훅을 사용했다면, 해당 훅이 SessionStart 훅으로 제대로 변환되었는지 확인하세요. 누락된 컨텍스트 훅이 있다고 해서 Kiro가 작동을 멈추지는 않지만, 컨텍스트가 누락된 상태로 실행됩니다.

수동 편집 내용이 덮어써질 수 있습니다. 이 부분은 꼼꼼한 사용자들이 가장 놓치기 쉬운 부분입니다. "생성된 V3 필드를 수동으로 편집하면 Kiro는 이를 자동으로 새로 고치는 작업을 중단합니다." 그러면 에이전트가 동기화되지 않은 상태로 표시되며, "해당 그룹을 선택하면 V2 설정에서 V3를 다시 빌드하고 수동으로 편집한 V3 내용을 덮어씁니다." Kiro는 이 작업을 수행할 때 백업을 유지하지만, 튜닝을 시작하기 전에 미리 알아두는 것이 좋습니다.

Don't ask again을 선택하면 V2로 유지될 것이라는 가정. 이는 단지 프롬프트 표시를 중단할 뿐입니다. CLI 3.0은 어쨌든 설정을 업그레이드합니다.

V3가 V2가 중단된 지점부터 시작할 것이라는 가정. 새 세션은 Steering, AGENTS.md 파일, 그리고 V3가 학습한 메모리(V3 작업부터 시작됨)를 기반으로 시작됩니다.

내보낸 세션이 컨텍스트를 복원해 줄 것이라는 가정. Kiro는 대상 하네스가 로드할 수 있는지 확인하기 전까지는 이를 단순한 아카이브(보관용)로 취급하라고 권장합니다.

메모리가 Steering을 대체할 것이라는 가정. Kiro는 일관되게 적용되어야 하는 규칙은 Steering에 속해야 한다고 명시합니다.

업그레이드가 모든 훅을 그대로 가져갈 것이라는 가정. 변환할 수 없는 훅은 경고와 함께 제외됩니다.

1단계: 여전히 의존하고 있는 V2 세션 정리하기

프로젝트별로 최근 V2 세션을 나열하고, 완료되지 않은 작업이나 다시 재구성하기 어려운 결정 사항이 포함된 세션을 선택하세요. 가능하면 V2에서 해당 작업을 마무리하십시오. 나머지는 마이그레이션 가이드의 제안대로 V2의 chat save 명령을 사용하여 외부 복사본을 저장하고, 전환하기 전에 Kiro 홈 디렉터리의 복사본을 보관해 두세요. Kiro의 권한 페이지에 따르면 기본 세션 저장소는 ~/.kiro/sessions/이며, 메모리 데이터베이스는 ~/.kiro/memories/입니다.

그런 다음 해당 세션에서 도출된 결론(결정 사항, 제외된 접근 방식, 합의된 컨벤션 등)을 추출하세요. 이 부분은 Kiro의 문서에서 V3 메모리가 V2로부터 자동으로 가져온다고 설명하지 않는 영역입니다.

2단계: 드라이 런(dry run)으로 에이전트를 업그레이드하고 모든 경고 읽기

팀에서 에이전트를 저장소에 보관하는 경우, 먼저 디렉터리 업그레이드를 미리 확인해 보세요. Kiro의 포스트에 따르면 dry-run 옵션으로 실행하라고 하며, 업그레이드 페이지에서는 드라이 런이 "변경될 내용을 보고하고 변환 경고를 포함한다"고 설명합니다. 그런 다음 각 파일을 백업하는 업그레이드를 실행하고 진단 결과를 확인하세요.

특히 누락된 훅과 Steering 또는 지식 파일을 가리키는 resources 항목이 있는지 확인하십시오. fileMatch 및 auto 파일이 V3에서 다르게 동작하기 시작하므로 Steering 파일의 포함 모드를 확인하세요. 동기화 해제 후 재빌드되는 동작을 이해하기 전까지는 생성된 필드를 수동으로 편집하지 않는 것이 좋습니다. 코딩 에이전트가 시작할 때 어떤 파일을 읽는지 더 자세히 알아보려면 코딩 에이전트가 실제로 읽는 파일에 대한 가이드를 참고하세요.

3단계: 메모리 기능을 의도적으로 활성화하고, 규칙은 Steering에 유지하기

기본 설정값을 그대로 수락하기보다는 메모리 액세스 수준을 직접 선택하세요. 읽기 및 쓰기는 Kiro가 학습할 수 있게 하며, 읽기 전용은 변경 없이 기존 내용을 사용할 수 있게 합니다. 메모리를 축적하고자 하는 워크스페이스를 신뢰(trust) 상태로 설정하세요.

그런 다음 항상 유지되어야 하는 모든 규칙을 Steering 또는 AGENTS.md로 이동시키세요. 메모리는 Kiro가 학습하는 내용을 위한 것이고, Steering은 사용자가 결정한 규칙을 위한 것입니다. 이전에 규칙이 무시된 적이 있다면, 에이전트가 지침 파일을 무시하는 이유에 대한 가이드에서 일반적인 원인을 확인해 보세요.

버전 변경은 프로젝트 컨텍스트가 특정 도구의 세션 저장소에 얼마나 많이 의존하고 있었는지 깨닫기에 좋은 기회입니다. MemoryLake는 작업 뒤에 숨겨진 결정 사항들을 사용자가 직접 관리하는 하나의 목록으로 유지하고, 이를 Kiro 및 다른 어시스턴트에서 사용할 수 있도록 지원하는 메모리 레이어입니다.

사용자는 자신의 언어로 직접 항목을 작성합니다. Kiro 세션, Kiro 메모리 데이터베이스, Steering 파일 또는 기타 벤더의 저장소에서 데이터를 읽거나 쓰거나 삭제하지 않습니다. 회사 코드로 작업하는 경우, 프로젝트 세부 정보를 다른 곳에 복사하기 전에 조직의 보안 정책을 확인하세요.

1단계: API 키 생성하기

로그인 후 대시보드에서 키를 생성합니다. 이 키는 MemoryLake 워크스페이스에 귀속되며, Kiro 또는 AWS 계정과 무관합니다.

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

1단계에서 V2 세션으로부터 추출한 결정 사항, 제외된 접근 방식, 컨벤션 등으로 시작하세요. 항목당 하나의 내용을 날짜 및 이유와 함께 기록합니다.

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

Kiro 및 사용하는 다른 어시스턴트를 연결합니다. 그러면 V3의 메모리가 이를 다시 학습할 때까지 기다릴 필요 없이, 첫 번째 세션부터 V3 및 다른 도구에서 동일한 결정 사항을 즉시 활용할 수 있습니다.

첫 번째 차이점은 버전 전환이 더 이상 도박이 되지 않는다는 것입니다. 어떤 세션으로 어떻게 돌아갈 수 있는지, 그리고 어떤 세션을 이미 요약해 두었는지 명확히 파악할 수 있습니다.

두 번째는 V3에서의 첫 주를 더 깔끔하게 보낼 수 있다는 점입니다. Steering, AGENTS.md, 그리고 직접 작성한 노트는 V3 세션의 메모리가 구축되는 동안 든든한 출발점을 제공합니다. 다른 도구들도 버전 업데이트 시 이와 유사하게 조용히 컨텍스트 변경을 겪은 바 있습니다. Cline의 조용한 컨텍스트 수정 사항에 대한 분석이 좋은 예시입니다.

세 번째는 업그레이드 자체로 인한 예기치 못한 문제를 줄일 수 있다는 점입니다. 누락된 훅이나 변경된 포함 모드를 실제 작업을 진행하는 도중이 아니라 드라이 런 과정에서 미리 발견할 수 있습니다.

네 번째는 이식성(portability)입니다. 나중에 Kiro에서 Claude Code로 마이그레이션하는 가이드에서 다루는 것처럼 작업을 다른 에이전트로 이동하더라도, 사용자의 결정 사항은 특정 도구의 세션 형식에 종속되지 않습니다.

Don't rely on Don't ask again (Don't ask again에 의존하지 마세요). CLI 3.0이 출시되면 어쨌든 업그레이드가 진행됩니다.

Kiro 홈 디렉터리를 먼저 백업하세요. 세션과 메모리가 그곳에 저장됩니다.

중요한 V2 세션은 V2에서 마무리하세요. 그런 다음 요약해 두십시오.

에이전트 업그레이드를 드라이 런으로 실행해 보세요. 적용하기 전에 모든 경고를 읽으십시오.

Steering 프런트 매터를 다시 확인하세요. V3에서는 포함 모드가 완전히 적용됩니다.

메모리 액세스 설정을 의도적으로 지정하세요. 그리고 신뢰할 수 있는 워크스페이스만 신뢰 상태로 설정하십시오.

규칙은 Steering에 유지하세요. Steering과 파워(powers)가 컨텍스트를 분할하는 방식에 대해서는 Kiro 파워와 Steering 간의 컨텍스트 라우팅 가이드를 참고하세요.

Kiro CLI V3는 2026년 10월 말 CLI 3.0 출시와 함께 기본값으로 적용되며, Don't ask again을 선택하더라도 V2에 머무를 수 없습니다. V3는 새로운 세션 저장소를 사용합니다. V3 세션은 V2에서 열 수 없습니다. Kiro 블로그에서는 V2 세션을 V3에서 재개할 수 있다고 설명하는 반면, 마이그레이션 가이드에서는 변환되지 않으므로 V2로 돌아가서 열어야 한다고 안내하고 있으니, 어느 한쪽을 맹신하기 전에 중요한 세션으로 직접 테스트해 보시기 바랍니다.

또한 V3는 CLI에 메모리 기능을 도입합니다. Kiro는 이를 사용자가 제어하는 액세스 권한 하에 로컬 V3 세션으로부터 학습하는 것으로 설명하며, 문서상으로는 V2로부터 학습한다는 언급이 없습니다.

일정이 도래하기 전에 의존하고 있는 V2 세션을 정리하고, 경고 사항을 확인하며 에이전트를 업그레이드하고, 보존하고자 하는 결정 사항들을 버전 변경으로 인해 유실되지 않을 안전한 곳에 기록해 두십시오.