에이전트에게 저녁에 맡긴 작업이 다음 날에도 이어진다면, 채팅창보다 먼저 확인할 것은 “무엇이 남았나”입니다. Kiro Crew는 Gateway가 보관하는 세션·메모리·스케줄·작업 체크포인트의 지속성을 목표로 하지만, 재시작 뒤 모든 대화 문장이 똑같이 돌아온다는 뜻은 아닙니다. 재개 범위와 v0.7.1의 성능 수정 범위를 분리해 확인하는 편이 안전합니다.
노트북 덮개를 닫았다 다시 열면 메모는 남아도, 막 실행 중이던 도구 호출까지 같은 장면으로 돌아오리라 기대하기 쉽습니다. 이 글은 실제 실행 후기가 아니라 2026년 9월 27일 기준 공식 README·릴리스 노트·문서로 만든 하루 데모 절차입니다.
30초 요약
- Kiro Crew의 지속성 대상은 Gateway가 관리하는 세션, 메모리, 스케줄, 장기 작업 체크포인트입니다.
- v0.7.1은 지속성 기능을 새로 넣은 버전이 아니라, 채팅 시작·탭 전환을 느리게 하던 두 원인을 고친 안정화 핫픽스입니다.
- 재시작 직후에는 “세션 목록”, “작업 상태”, “재개 후 검증 결과”를 따로 확인해야 합니다.
- 다른 머신 이동이나 문제 복구는 일반 재시작과 구분하고 Snapshot & restore를 별도 경로로 봅니다.
Kiro Crew 0.7.1은 무엇을 고쳤나
공식 GitHub 릴리스 노트에 따르면 v0.7.1은 2026년 9월 25일 공개된 안정화 핫픽스입니다. 핵심은 새 지속성 기능을 추가한 일이 아니라, 사용 중인 세션이 없어진 뒤 에이전트별 view 파일을 회수해 새 채팅과 백그라운드 서브에이전트 시작이 느려지는 문제를 줄인 데 있습니다.
또 재연결한 채팅 창은 세션 전체 기록이 아니라 현재 표시할 행만 요청하도록 바뀌었습니다. 따라서 이 버전의 질문은 “재시작 뒤 무조건 복구되나?”보다 대시보드가 이전 상태를 다시 읽을 때 불필요하게 무거워지지 않는가에 가깝습니다.
재시작 뒤 남는 것과 다시 확인할 것을 나누기
Kiro Crew 공식 README는 세션, 메모리, 스케줄, 작업 체크포인트가 Gateway 재시작 뒤에도 유지된다고 설명합니다. 공식 제품 페이지도 활성 프로젝트와 작업 맥락, 장기 작업 체크포인트가 세션과 재시작을 넘어 지속·재개된다고 안내합니다.
다만 그 문장을 “실행 중이던 모든 외부 도구와 대화 원문이 같은 시점으로 되감긴다”로 읽으면 안 됩니다. 에이전트 작업은 앱을 옮겨주는 이삿짐센터보다, 메모·할 일·중간 저장본을 챙긴 작업 노트에 가깝습니다.
| 확인 대상 | 문서에서 확인한 범위 | 하루 데모에서 볼 장면 |
|---|---|---|
| 세션 | 독립 세션을 재시작 뒤 재개·검색 | 같은 세션이 목록에 보이고 다시 열리는지 |
| 메모리·프로젝트 맥락 | 선호·프로젝트 맥락이 새 작업으로 이어짐 | 다음 요청에서 저장한 작업 조건을 참조하는지 |
| 장기 작업 | 체크포인트·검증·재시도를 거쳐 재개 | 중단 지점과 다음 검증 단계가 구분되는지 |
| 스케줄 | Gateway가 계속 실행될 때 예약 작업 처리 | 다음 실행 시각과 마지막 실행 기록이 일치하는지 |
같은 세션이 열리는 일과 같은 외부 작업이 완료되는 일은 별도 검증 항목입니다. 네트워크, 인증, 연결한 MCP 도구, 대상 저장소 상태는 재시작 뒤에도 다시 실패할 수 있습니다.
하루 데모: 재시작 전후에 딱 네 번만 확인하기
하루 데모는 작고 되돌릴 수 있는 작업 하나부터 정하면 됩니다. 실제 환경에서는 운영 저장소 대신 샘플 저장소나 별도 브랜치를 고르고, 비밀값과 파괴적 명령은 작업에 넣지 않는 편이 좋습니다.
-
아침: 작업 경계 적기
세션에 “README의 제목 한 줄을 고치고 diff를 보여 준 뒤, 테스트 명령은 실행하지 말고 대기해 달라”처럼 종료 조건이 분명한 요청을 둡니다. 프로젝트 이름, 변경 파일, 다음 확인 행동을 짧게 기록합니다. -
점심: 중간 상태 보기
대시보드에서 세션 이름, 마지막 메시지, 작업 상태, 남은 승인 또는 검증 단계를 분리해 적습니다. ‘이미 끝난 결과’와 ‘재개할 작업’을 한 줄로 섞어 기록하지 않는 것이 핵심입니다. -
재시작: Gateway만 다시 시작한 뒤 열기
재시작 방법은 설치 형태와 운영 체계에 따라 다르므로 공식 설치·운영 문서를 따릅니다. 돌아온 뒤에는 먼저 세션 목록과 작업 상태를 보고, 그 다음에만 같은 세션으로 짧은 후속 요청을 보냅니다. -
저녁: 결과 대신 검증을 남기기
“세션이 보임”, “프로젝트 조건을 참조함”, “체크포인트 뒤 단계가 표시됨”, “도구 재인증이 필요함”처럼 관찰한 사실만 기록합니다. 성공·실패 한 줄보다 다음 날 재현 가능한 이 기록이 더 쓸모 있습니다.
문서 기반으로는 장기 작업이 체크포인트에서 검증·재시도를 거쳐 재개되는 구조를 기대할 수 있습니다. 하지만 실제 데모에서 도구 호출이 이어지는지는 연결한 백엔드와 권한 상태까지 확인해야 하므로, ‘세션 복구’라는 말만으로 도구 실행 복구를 판정하지 마세요.
최소 준비와 문서 기반 사용 예시
공식 README는 Kiro Crew가 Kiro CLI를 기본 에이전트 백엔드로 사용하며, 설치 뒤 사전 조건 확인과 Gateway 실행 경로를 제공한다고 안내합니다. 아래는 README에 나온 흐름을 줄인 문서 기반 예시이며, 이 글에서 실행한 명령은 아닙니다.
# 공식 README의 소스 빌드 흐름 예시
kirocrew setup
kirocrew doctor
kirocrew gateway
doctor에서 먼저 환경을 확인하는 이유는 재시작 복구 판단에서 “Crew가 상태를 잃었나”와 “백엔드·인증·도구가 준비되지 않았나”를 분리하기 위해서입니다. 데모는 변경 작업보다 상태 확인이 먼저여야 원인을 좁히기 쉽습니다.
바이브코딩으로 데모 기록을 넓히고 싶다면, 에이전트에게 결과를 만들어 달라고만 하지 말고 검증 표를 요구하는 편이 낫습니다. 다음 프롬프트는 실행 권한을 넓히지 않고, 관찰 가능한 상태를 정리하는 용도입니다.
이 세션에서 파일을 변경하거나 외부 명령을 실행하지 마세요.
현재 작업의 프로젝트 맥락, 마지막 완료 단계, 다음 검증 단계,
재시작 뒤 다시 확인할 의존성(인증·도구·네트워크)을 표로 정리해 주세요.
확인할 수 없는 항목은 추측하지 말고 ‘미확인’으로 표시해 주세요.
Snapshot은 재시작보다 큰 복구 시나리오다
공식 기능 문서는 Snapshot & restore를 Crew가 아는 내용을 휴대 가능한 tarball로 백업하고, 새 머신 이동이나 문제 복구에 쓰는 기능으로 소개합니다. 일반 재시작 확인과 환경 이동·문제 복구를 같은 테스트로 합치지 않는 것이 좋습니다.
하루 데모가 통과했다면 다음 주에는 Snapshot을 별도 시나리오로 다루세요. 백업 생성 시점, 보관 위치, 복원 뒤 확인할 세션·메모리·스케줄 항목을 정하고, 실제 복원은 비운영 환경에서 먼저 검증하는 순서가 안전합니다.
누구에게 맞고, 언제 굳이 쓰지 않아도 될까
여러 날에 걸친 조사, 반복 점검, 예약 작업처럼 “다음에 무엇을 다시 설명해야 하지?”가 자주 생기는 개발자에게 Kiro Crew의 지속성은 의미가 있습니다. 특히 세션과 대시보드를 여럿 열어 두는 환경에서는 v0.7.1의 view 파일 정리와 재연결 창 최적화가 체감 지연을 줄이는 방향의 수정입니다.
반대로 한 번의 짧은 코드 질의만 하고 종료하는 흐름이라면 지속형 작업공간을 따로 운영하는 비용이 더 클 수 있습니다. Kiro Web·IDE·CLI는 단일 세션에서 작업을 수행하고, Crew는 그 바깥의 메모리·일정·재개·조율을 확장한다는 공식 구분부터 자신의 작업 방식에 대입해 보세요.
작업 환경을 함께 정리한다면
대시보드·편집기·터미널을 나란히 두고 데모 기록을 남기는 경우에만 USB-C 도킹스테이션 카드가 맞습니다. 화면 하나만 쓰고 저장장치 연결도 드문 환경이라면 굳이 추가할 이유가 없습니다.
Snapshot을 실제로 별도 보관할 계획이 있을 때만 휴대용 SSD가 의미가 있습니다. 일반 재시작 확인만 하는 하루 데모라면 백업 장치를 구매하기보다 먼저 복구 범위를 기록하는 편이 우선입니다.
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
출처
핵심 정리: 다섯 가지 질문과 답
Q. Kiro Crew 0.7.1이 세션 복구를 새로 넣었나요?
아닙니다. 릴리스 노트상 v0.7.1은 새 채팅·서브에이전트 시작과 채팅 탭 전환을 느리게 하던 원인을 고친 안정화 핫픽스입니다.
Q. 재시작하면 무엇이 이어지나요?
공식 README 기준으로 Gateway가 관리하는 세션, 메모리, 스케줄, 작업 체크포인트의 지속성을 확인 대상에 둘 수 있습니다.
Q. 같은 세션이 열리면 외부 도구 작업도 끝난 건가요?
아닙니다. 인증, 네트워크, MCP 도구, 대상 저장소 상태는 별도로 다시 확인해야 합니다.
Q. 하루 데모에서 가장 먼저 남길 기록은 무엇인가요?
프로젝트 조건, 마지막 완료 단계, 다음 검증 단계, 재시작 뒤 필요한 의존성을 분리해 남기면 됩니다.
Q. 다른 컴퓨터로 옮기려면 재시작 데모만 하면 되나요?
아닙니다. 공식 기능 문서가 소개한 Snapshot & restore를 별도 백업·복원 시나리오로 검증해야 합니다.
글을 읽어 주셔서 감사합니다.
이 글이 도움이 되었고 새로운 정보를 계속 받아보고 싶으시다면 구독해 주세요.
'AI > 오픈 소스 소개' 카테고리의 다른 글
| ConnectOnion 함수 도구 연결, 에이전트가 무엇을 했는지 기록까지 남기는 법 (0) | 2026.09.26 |
|---|---|
| Orca Git worktree 데모, 에이전트 답이 섞일 때 비교부터 분리하는 법 (0) | 2026.09.25 |
| Smithers 0.35.0 복구 데모, 실패한 에이전트 작업을 처음부터 다시 돌리기 전에 (0) | 2026.09.22 |
| VeloxQuant-MLX로 긴 대화를 붙잡을 때, 압축률보다 먼저 볼 것 (0) | 2026.09.21 |
| SandBase Harness, 도구 실행이 멈췄을 때 승인 흐름을 확인하는 법 (0) | 2026.09.20 |
댓글