Kiro Crew: 세션을 넘어 에이전트 작업을 이어 가는 오픈 소스 상주 작업 공간

Kiro Crew는 kirodotdev가 Apache 2.0 라이선스로 공개한 오픈 소스 개발 작업 공간입니다. 목표는 지속적이고, 스스로 학습하고, 스스로 발전하는 작업 공간입니다. 내 컴퓨터나 원격 호스트에서 실행되어, 한 번의 세션이 끝난 뒤에도 개발 작업이 이어지게 합니다. 대부분의 에이전트 세션은 채팅 창을 닫으면 끝납니다. Kiro Crew는 반대로 접근합니다. 상시 실행되는 Gateway 프로세스가 세션, 메모리, 일정, 작업 체크포인트를 보관하고, 대화와 대화 사이에도 작업을 이어 갑니다. 공개된 설명에서 네 개의 층을 읽을 수 있습니다. 첫째는 Gateway입니다. 상주 서비스이며 기본 포트는 5476입니다. 공식 Docker 예시는 127.0.0.1에 바인딩하므로, 기본 자세는 로컬 전용 접근임을 알 수 있습니다. 둘째는 진입점입니다. 데스크톱 앱, 웹 대시보드, CLI에 더해 Slack, Discord 같은 연결 도구가 있어, 같은 작업을 어느 쪽에서든 이어서 할 수 있습니다. 셋째는 에이전트 백엔드입니다. 기본 에이전트는 ACP 백엔드를 통해 kiro-cli 위에서 동작하며, 프로젝트는 검증된 다른 ACP 하니스도 있다고 밝힙니다. 넷째는 Kiro Crew Apps로, 특정 업무에 맞춘 인터페이스를 에이전트, 스킬, 일정, 연동, 백엔드 서비스와 함께 묶습니다.

설계를 떠받치는 장치는 세 가지입니다. 첫째는 영속성입니다. 세션, 메모리, 일정, 작업 체크포인트는 Gateway를 다시 시작해도 남습니다. 특히 체크포인트가 중요합니다. 여러 단계의 작업이 중단되어도 처음부터 다시 하지 않고 저장된 지점에서 재개할 수 있습니다. 둘째는 무인 실행입니다. 여러 단계의 작업이 터미널을 지켜보는 사람 없이 실행되고, 반복 작업은 정해진 일정에 시작되며, 하트비트가 시스템을 감시하다가 주의가 필요할 때만 알립니다. 셋째는 자기 학습입니다. 프로젝트는 수정 사항과 작업 실패가 오래 남는 교훈이 된다고 설명합니다. 다만 우리가 확인한 README 발췌본은 이 부분에서 잘려 있습니다. 교훈을 어떻게 저장하고 재사용하는지는 공식 문서로 확인해야 합니다.

설치와 배포 방식에는 공학적 우선순위가 드러납니다. curl -fsSL https://download.crew.kiro.dev/cli.sh | sh 한 줄이면 저장소를 복제하거나 프런트엔드를 빌드하지 않고도 서명된 Stable wheel을 설치합니다. --version으로 버전을 고정할 수 있지만 가장 낮은 버전은 0.1.2입니다. 0.1.0과 0.1.1은 매니페스트 서명 이전 버전이라 검증할 서명된 매니페스트가 없기 때문입니다. 공급망 무결성을 눈에 보이는 기능으로 다룬다는 뜻입니다. 릴리스 채널은 셋입니다. Stable이 기본이고, Insider는 릴리스 후보를, Nightly는 main 브랜치를 따릅니다. 컨테이너로는 Gateway가 GHCR에 다중 아키텍처 공개 이미지로 올라와 있어 상시 가동 서버에 맞습니다. 소스 빌드에는 Python 3.12 이상과 Node.js 22.12 이상이 필요하며, make build 다음에 kirocrew setup, kirocrew doctor, kirocrew gateway를 차례로 실행합니다. doctor는 시작 전에 환경을 점검하는 명령입니다.

성능에 대해서는 분명히 해 둘 점이 있습니다. 우리가 본 공개 자료에는 벤치마크 수치가 없습니다. 지연 시간, 처리량, 작업 성공률 비교가 없으므로 이 글도 숫자를 만들어 내지 않습니다. 비용 구조는 정성적으로 짚을 수 있습니다. Kiro Crew 자체는 일정과 영속성을 맡는 층입니다. 실제 추론 비용은 연결된 에이전트 백엔드, 기본적으로는 kiro-cli 뒤의 모델 호출에서 나옵니다. 상주 일정과 하트비트는 백그라운드 호출이 계속된다는 뜻이므로, 팀은 예산을 잡고 하트비트 간격을 적절히 정해야 합니다. 대가로 얻는 것은 사람의 시간입니다. 매번 같은 배경을 다시 설명하지 않아도 됩니다.

개발자와 기업에 미치는 영향은 세 가지입니다. 첫째, 일회성 대화에서 오래 함께하는 팀원으로 작업 방식이 바뀝니다. 메모리와 체크포인트 덕분에 맥락이 세션과 함께 사라지지 않습니다. 둘째, Apache 2.0 기반 자체 호스팅으로 코드와 데이터를 직접 관리하는 하드웨어에 둘 수 있어, 규정 준수 요건이 있는 팀에 중요합니다. 셋째, ACP 호환 다중 하니스 설계는 특정 에이전트에 대한 종속을 줄입니다. Slack과 Discord 연동으로 팀이 이미 쓰는 소통 흐름에도 들어갈 수 있습니다. 저장소의 Trendshift 배지는 개발자들이 이 프로젝트를 일찍부터 주목했음을 보여 줍니다. 한계도 분명합니다. 첫째, 기본 백엔드는 따로 설치하고 로그인해야 하는 kiro-cli가 필요합니다. 첫 실행 때 이를 확인하고, 없으면 공식 설치 안내로 연결합니다. 둘째, 무인 실행은 권한 위험을 키웁니다. 오래 스스로 움직이는 에이전트에는 샌드박스, 최소 권한, 감사 기록이 필요합니다. 프로젝트가 보안 정책과 샌드박스 설정 안내를 제공하므로 운영자는 꼼꼼히 읽어야 합니다. 셋째, 자기 학습은 양날의 검입니다. 잘못된 교훈이 굳어지면 이후 작업을 왜곡하므로, 학습된 내용을 검토하고 정리할 수 있어야 합니다. 넷째, 프로젝트가 아직 젊습니다. 문서가 고정 버전 예시로 0.6.0을 쓰므로 인터페이스와 동작이 바뀔 수 있습니다. 마지막으로 README에는 익명 사용 텔레메트리 항목이 있습니다. 기업은 도입 전에 범위와 끄는 방법을 확인해야 합니다.

정리하면 Kiro Crew의 관심 포인트는 단일 지표가 아닙니다. 오래 도는 에이전트를 설계의 중심 목표로 삼았다는 점입니다. 지속되는 상태, 재개 가능한 작업, 일정과 하트비트, 여러 진입점, 서명된 배포가 갖춰져 있습니다. 이 약속을 지킬 수 있는지는 자기 학습의 품질과 무인 작업을 둘러싼 안전 경계에 달려 있으며, 이후 릴리스에서 계속 지켜볼 만합니다.