개발을 하다 보면 저장소에는 다양한 업무가 빠르게 쌓입니다. 리뷰어를 기다리는 PR(Pull Request, 이하 PR), 원인 파악이 필요한 버그 이슈 같은 것들이죠. 중요한 일인 줄 알면서도 개발 흐름을 끊어야 해 자꾸 뒤로 미룹니다. 하루 이틀 지나면 어느새 아무도 손대지 않는 목록이 됩니다. 이런 일을 도맡아 줄 팀원이 하나 있다면 어떨까요?

이 글은 AI 에이전트를 단순한 도구가 아니라 우리 팀의 새 팀원으로 들이는 이야기입니다. 그 팀원의 이름은 Kiro Crew입니다. 우리 팀의 맥락을 기억하고, 정해진 시간에 스스로 일하며, 저장소를 늘 지켜보다 손댈 일이 생기면 알아서 움직이는 24시간 쉬지 않는 자율 에이전트죠.

이 글에서는 Kiro Crew의 개념과 동작 방식, 핵심 기능을 살펴봅니다. 그런 다음 이 새로운 팀원을 AWS에 배포해 실제 팀에 온보딩하고 팀 저장소의 이슈 분류와 사전 조사, PR 리뷰를 맡기는 과정을 따라가 봅니다. 글을 다 읽고 나면 저장소에 올라오는 이슈의 분류와 사전 조사, PR 리뷰를 믿고 맡길 수 있는 지치지 않는 팀원을 얻게 될 겁니다.

Kiro Crew 소개

그림1. Kiro Crew 기본 화면

Kiro Crew는 로컬이나 원격 머신에 늘 켜둔 채 쓰는 오픈소스 개인 AI 에이전트 워크스페이스입니다. Amazon 내부에서 MeshClaw라는 사이드 프로젝트로 시작해 6개월이 되지 않아 39,000명 이상의 개발자가 쓸 만큼 빠르게 퍼졌고, 지금은 Kiro Crew라는 이름의 공개 오픈소스 프로젝트(Apache 2.0)로 운영됩니다. 보통의 AI 어시스턴트가 말을 걸 때만 반응하는 일회성 도구라면, Kiro Crew는 계속 켜진 채 스스로 일하고 지난 맥락을 기억하는, “쓰는 도구”보다 “함께 일하는 팀원”에 가까운 존재입니다.

Kiro CLI 같은 터미널 기반 에이전트는 터미널을 열고 있는 동안만 일합니다. 반면 Kiro Crew는 에이전트를 끄지 않고 계속 돌려두는 것이 출발점입니다. 그러면 대시보드에서든 Slack에서든 같은 에이전트에게 말을 걸 수 있고, 대화가 끝나도 맥락은 메모리로 남아 다음 대화가 그걸 안고 시작하며, 정해진 시각이 되면 사람이 자리에 없어도 알아서 일을 시작합니다.

에이전트 백엔드로는 Kiro CLI를 사용합니다. Kiro Crew가 기존 .kiro 설정을 그대로 읽어들이기 때문에, 이미 만들어둔 steering과 Skill, 커스텀 Agent가 추가 설정 없이 그대로 동작합니다.

KiroCrew의 동작 방식

Kiro Crew의 구성 요소를 이해하려면 먼저 Kiro Crew와 Kiro CLI의 역할을 구분해야 합니다. Kiro Crew는 모델을 직접 호출하거나 파일을 고치는 에이전트 런타임이 아닙니다. 사용자 인터페이스와 실제 에이전트 런타임 사이에서 요청과 세션을 조율하는 게이트웨이입니다. 아래 그림은 Kiro Crew의 구조를 사용자 인터페이스, 게이트웨이, 에이전트 백엔드의 세 계층으로 나눠 보여줍니다.

그림2. Kiro Crew High-level 아키텍처

1. 사용자 인터페이스

사용자는 여러 창구로 Kiro Crew에 말을 겁니다. 웹 대시보드는 물론 CLI, 그리고 Slack·Telegram 같은 메시징 채널까지 모두 진입점이 되고, 데스크톱 앱은 이 웹 대시보드를 Electron으로 감싼 클라이언트입니다. 어느 창구로 들어오든 결국 같은 게이트웨이가 받으므로, 입구만 다를 뿐 같은 에이전트와 대화하는 셈입니다.

2. 게이트웨이

서로 다른 인터페이스에서 들어온 요청은 모두 하나의 Kiro Crew 게이트웨이로 모입니다. 게이트웨이는 Python과 aiohttp로 구현된 단일 비동기(asyncio) 프로세스입니다. 요청을 알맞은 세션에 연결하고 메모리·컨텍스트를 실어 주며 안전장치를 적용하는 조율자 역할을 합니다. 게이트웨이는 개별 대화보다 오래 사는 상주 계층입니다. 사용자가 대시보드를 닫아도 실행 상태를 유지하며 메시지 수신과 스케줄 확인을 계속합니다. 그래서 대화가 끝난 뒤에도 기억이 남고 정해진 시각에 스스로 일을 시작할 수 있습니다.

게이트웨이는 실제 추론을 직접 하지 않고 ACP를 통해 에이전트 백엔드와 통신합니다. ACP는 JSON-RPC 2.0 메시지를 stdio로 주고받는 인터페이스로, 이 경계 덕분에 게이트웨이는 “여러 창구를 하나로 묶고 오래 기억하게 만드는” 자기 역할에만 집중할 수 있습니다.

3. 에이전트 백엔드

실제 일은 에이전트 백엔드의 Kiro CLI가 합니다. kiro-cli는 에이전트 런타임으로서 LLM Provider를 호출해 추론하고, MCP 서버의 도구를 실행하며, 모델 인증과 MCP 서버 관리까지 담당합니다. 게이트웨이는 요청을 조율하고, kiro-cli는 모델과 도구로 그 요청을 실행합니다. 이 역할 분리가 Kiro Crew 구조의 핵심입니다.

여기서 ‘에이전트’란 어떤 모델과 도구를 사용하고 어떤 지침을 따를지를 정의한 설정입니다. 게이트웨이는 세션을 열 때 그중 하나를 선택해 kiro-cli 런타임에 적용합니다. 코디네이터 역할을 하는 기본 에이전트는 하나의 일반적인 설정 파일을 기반으로 동작하는 것이기 때문에, 게이트웨이는 목적에 맞는 에이전트로 얼마든지 변경할 수 있도록 설계되어 있습니다.

Kiro Crew 주요 기능 소개

1. Sessions

Kiro Crew 대시보드에서는 대화 하나하나가 독립된 세션입니다. 여러 탭을 띄워 동시에 일할 수 있지만 한 탭의 에이전트는 다른 탭의 대화를 보지 못합니다. 선호·학습 내용·히스토리 같은 메모리는 세션 경계와 상관없이 공유되므로 새 세션도 늘 그 메모리를 안고 시작합니다. 게이트웨이가 재시작되면 세션은 알아서 다시 붙습니다. 기본 30분간 활동이 없어 닫혀도 메시지를 보내면 다시 이어지고 대화가 길어지면 오래된 맥락을 요약해 자리를 비웁니다.

세션에는 Autopilot 모드가 있습니다. 별도 앱이 아니라 세션의 실행 방식 중 하나입니다. 웰컴 화면의 “새 오토파일럿 채팅”이나 세션 메뉴에서 켤 수 있고, 설정에서 기본값으로 지정할 수도 있습니다. 흐름은 계획 → 승인 → 실행입니다. 에이전트가 작업을 여러 Stage로 쪼갠 계획을 내놓으면 사용자가 Go로 한 단계씩 승인하며 진행하고(Go All은 끝까지 자동, Cancel은 즉시 중단), 마지막 단계는 검증에 씁니다. 간단한 요청은 계획 없이 곧장 답하고 체크포인트가 필요한 작업만 이 흐름을 탑니다. 단계마다 시간 예산이 있고 반복 실패 시 사용자에게 판단을 되묻도록 설계돼, 자동 실행이 하염없이 겉돌지 않습니다.

그림3. Kiro Crew 세션 종류

메모리는 세션을 넘어 Kiro Crew가 사용자를 ‘기억’하게 하는 핵심 요소로, 대화 속에서 자연스럽게 쌓입니다. 메모리는 다음 여섯 가지로 나뉩니다.

• 선호(Preferences)
• 진행 중인 작업의 맥락을 담은 프로젝트(Projects)
• 시간이 지나면서 요약되는 최근 히스토리
• 구조화된 사실을 담은 시맨틱 메모리
• 과거 사건의 조각을 기록한 에피소드 메모리
• 기본 동작을 덮어쓰는 교정 규칙인 교훈(Lessons)

30개의 메시지가 오갈 때마다 또는 일정 시간 동안 유휴 상태가 지속되면 자동으로 정리되며, “이거 기억해”라고 말하면 즉시 저장됩니다. 덕분에 새 세션에서도 지난 대화를 처음부터 다시 읽지 않고 사용자의 선호와 맥락을 이어받아 대화를 시작할 수 있습니다.

그림4. Kiro Crew 메모리

메모리는 저장 방식에 따라 두가지 방식으로 갈립니다. 파일 기반(~/.kiro/crew/workspace/memory/)에는 선호·프로젝트·최근 히스토리가 마크다운으로 담겨 세션 시작 시 통째로 프롬프트에 실리고, DB 기반(memory.db, SQLite + FAISS)에는 시맨틱·에피소딕·교훈이 임베딩으로 저장돼 유사도 검색으로 관련된 것만 골라 들어갑니다. 즉 파일 계층은 세션마다 통째로 넣는 안정적 맥락, DB 계층은 질문에 맞춰 선별하는 검색형 맥락입니다. 쌓인 내용은 Settings → Overview → Memory에서 열람·수정하고, 명령줄에서는 kirocrew learn add/list/remove로 교훈을 직접 다룹니다.

2. Schedule

스케줄은 에이전트 작업을 정해둔 시각에 자동으로 돌려주는 기능입니다. 잡 하나는 자연어 프롬프트와 일정을 묶은 것으로, 시간이 되면 자체 세션에서 실행돼 결과가 대시보드 알림 패널로 옵니다. 대시보드의 Schedule 패널에서 이름·프롬프트·주기를 채워 등록해도 되고, 채팅으로 “매주 평일 오전 9시에 열린 작업을 요약해줘”라고 말하면 에이전트가 알아서 잡을 만들어 줍니다. 등록한 잡은 같은 패널에서 상태와 다음 실행 시각을 보며 멈추거나 다시 돌리고, 지금 바로 실행하거나 수정·삭제할 수 있습니다. 일정은 표준 크론 표현식(예시, 0 9 * * 1-5, 매주 월요일부터 금요일까지 오전 9시 0분 실행)이나 N초 간격으로 지정하고, 잡마다 타임존이나 특정 날짜 제외(휴일 스킵)도 걸 수 있습니다. 여러 잡이 같은 순간에 몰리지 않도록 기본으로 약간의 지터(랜덤 지연)를 주는데, 필요하면 정시 실행으로 끕니다. 사람이 지켜보지 않는 실행이라 세션 단위 임시 신뢰(자동 승인)는 절대 붙지 않고, 훅 거부 목록과 민감 경로 차단, 거버넌스 정책은 변함없이 지켜집니다.

그림5. Kiro Crew 스케줄 메뉴

잡을 처음부터 직접 짜기 부담스럽다면 스케줄 템플릿이 있습니다. Schedule 화면에서 여는 템플릿 갤러리에 미리 만들어둔 프리셋이 카드로 정리돼 있고, 카드를 누르면 프롬프트와 일정이 채워진 생성 폼이 뜹니다. 사용자가 이를 확인하고 저장하는 구조라, 무엇이든 실행되기 전에 반드시 한 번 눈으로 짚고 넘어갑니다. 프리셋에는 코드 품질·저장소 정비·보안·운영·백로그 및 소통·지식 동기화 등 여섯 가지 설정 항목이 있습니다. Nightly Build Watch(매일 새벽 빌드 감시), Standup Brief(평일 아침 브리핑), Weekly Vuln Scan(주간 취약점 스캔), Session Summary(평일 퇴근 무렵 세션 요약) 등이 포함되어 있습니다.

그림6. Kiro Crew 스케줄 템플릿

3. Artifacts

채팅에 바로 그려진 위젯이나 문서는 대화가 스크롤되면 사라지는 일회성 결과물입니다. 아티팩트는 여기에 고정된 식별자(slug)와 버전 히스토리, 그리고 열어볼 수 있는 URL(/artifacts/<slug>)을 붙여 오래 남기고 세션을 오가며 다시 꺼내 쓰게 만든 것입니다. 쓸모 있는 대시보드 UI(CR 큐, 파이프라인 상태 카드 등)든 제대로 된 문서(계획서, 설계, 분석 리포트)든, 두고두고 손보거나 동료와 나눌 만한 결과물을 한곳에 라이브러리로 모아둡니다. 만드는 법은 어렵지 않습니다. 세션에서 “이번 주 현황을 위젯으로 보여줘”, “설계 문서 작성해줘”처럼 요청해 에이전트가 결과물을 그려내면, 위젯의 북마크 아이콘을 누르거나 “저장해줘”라고 말해 아티팩트로 남깁니다(두고 쓸 만한 것은 에이전트가 알아서 저장하기도 합니다).

그림7. Kiro Crew 스케줄 아티팩트

4. Knowledge

지식 기능은 에이전트가 참고했으면 하는 외부 콘텐츠를 모아두는 큐레이션 저장소입니다. 대화에서 저절로 쌓이는 메모리와 달리, 지식에는 의도가 담깁니다. 무엇을 넣을지 사용자가 직접 고르니까요. 프로젝트 문서, API 레퍼런스와 스펙, 런북·SOP, 이해시키고 싶은 코드 저장소, 업무 관련 외부 아티클처럼 “에이전트가 이건 알고 있어야 한다” 싶은 자료를 담습니다.

검색은 에이전트가 알아서 합니다. 참고 자료가 필요하다고 판단하면 local_knowledge_search 도구가 자동으로 뜨는데, 벡터 유사도(쓸 수 있을 때, 아니면 키워드로 대체)로 가장 관련 있는 청크만 뽑아 오고 라이브러리 전체를 컨텍스트에 쏟아붓지는 않습니다. 임베딩은 메모리와 같은 인프로세스 런타임을 쓰며, 모델(약 610MB)이 첫 실행 때 자동으로 내려 받으므로 따로 설정할 일이 없습니다. 내려받기 전까지는 키워드 매칭으로 동작합니다.

그림8. Kiro Crew 지식 그래프

5. Apps

앱은 Kiro Crew를 하나의 플랫폼으로 넓혀주는 패키지입니다. 앱 하나가 에이전트·스킬·MCP 서버·크론 잡·대시보드 UI 페이지·백엔드 프로세스 가운데 필요한 것들을 골라 Crew에 얹어주며, 사용자는 대시보드의 App Store에서 클릭 한 번으로 설치하고 켭니다. 스킬 하나만 담은 파일 한 개짜리 앱부터 에이전트와 백엔드, 전용 UI 페이지까지 갖춘 완결형 앱까지 규모는 제각각입니다.

그림9. Kiro Crew Apps

(1) Issue Radar

Issue Radar는 지정한 GitHub/GitLab 저장소의 새 이슈와 PR을 지켜보다가, 처리할 거리가 생기면 알려주고 곧바로 조사·트리아지에 들어가게 해주는 앱입니다. 카드의 Investigate(이슈 원인 조사)나 Review(PR 리뷰 초안 작성) 버튼을 누르면 그 이슈나 PR을 맥락으로 삼는 세션이 열리고, 에이전트가 분석한 뒤 결론을 카드에 적어둡니다. 사람이 세션을 붙잡고 있지 않아도 짧은 주기로 도는 폴링 워처가 새 항목을 감지해 crew 세션을 깨우기 때문에, 저장소를 늘 지켜보는 용도로 알맞습니다. 다만 Issue Radar는 자체 토큰을 저장하지 않고 사용자의 CLI 세션에 맡기므로, 쓰려면 gh(GitLab이면 glab) 인증 세션이 있어야 합니다.

그림10. Kiro Crew 기본 앱 – Issue Radar

(2) Spec Builder

Spec Builder는 막연한 아이디어를 짜임새 있는 스펙으로 다듬어 주는 앱입니다. Kiro CLI v3의 스펙 워크플로(요구사항 → 설계 → 작업 → 실행)를 단계별 대화로 밟아 나가며, 단계마다 문서를 함께 손보고 승인한 뒤 다음으로 넘어갑니다. 곧장 코딩에 뛰어들기 전에 무엇을·왜·어떻게 만들지 먼저 맞추고, 그 결과를 실행 가능한 작업 목록까지 작성하고 싶을 때 사용해보세요.

그림11. Kiro Crew 기본 앱 – Spec Builder

(3) Build your own app

마땅한 앱이 없다면 App Kit으로 직접 만들면 됩니다. app.json 매니페스트에 어떤 에이전트·스킬·크론·MCP 서버·UI 페이지·백엔드를 얹을지 적어두면 Crew가 이를 읽어 알아서 연결해 주고(기본 resources: "gateway" 모드), 로컬에서 만든 앱은 앱 스토어를 거치지 않고 바로 설치해 씁니다. 앱은 저마다 별도의 git 저장소로 관리되며, 앱 레지스트리에 PR을 올려 등록하면 앱 스토어 목록에 떠서 다른 사용자도 원클릭으로 설치할 수 있습니다. 팀 자체 레지스트리를 연동하면 사내 전용 앱만 따로 배포하는 것도 가능합니다.

그림 12. 앱 스토어 목록에 노출되는 App Kit 기반으로 등록한 앱

6. Multi-instance Mode (Crew on Cloud)

KiroCrew는 여러 개의 원격 Crew를 하나의 대시보드에 탭으로 붙여 쓰는 멀티 인스턴스 기능을 지원합니다. 즉, 내 노트북에서 도는 Crew 게이트웨이, 다른 호스트(EC2 등 원격 서버)에서 도는 Crew 게이트웨이를 동시에 운영할 수 있습니다. 이를통해 아래와같은 장점을 얻게됩니다.

• 노트북은 화면만 띄우고, 실제 작업은 원격에서 처리합니다. 빌드, 테스트, 리포 스캔에 원격 박스의 CPU를 사용한다면 여러 세션을 동시에 돌려도 로컬 편집기는 느려지지 않습니다. 에이전트를 하나 더 붙일 때도 “지금 노트북이 버틸까”가 아니라 “어느 박스에 맡길까”만 정하면 됩니다.
• 작업이 내 노트북 상태와 묶이지 않습니다. 세션은 원격 게이트웨이 안에서 돕니다. 만약 EC2 셀프호스팅으로 배포한다면 systemd 서비스로 독립해 있으니 허브를 닫아도, 노트북이 슬립에 들어가도, 자리를 옮겨 네트워크가 바뀌어도 원격 쪽 작업은 그대로 진행됩니다. 돌아와서 허브를 켜면 붙어 있던 자리로 복귀하고, 그 사이 진행분을 이어서 봅니다. 30분짜리 마이그레이션을 걸어 두고 회의에 들어가는 게 가능해집니다.
• 환경을 목적별로 쪼갤 수 있습니다. 리포마다 요구하는 런타임 버전과 툴체인이 다릅니다. 한 대에 다 몰아넣으면 결국 서로의 환경을 침범할 수 있습니다. 원격을 하나씩 나눠 주면 각 박스가 자기 환경으로 독립할 수 있습니다. Linux 전용 빌드, arm64와 x86 양쪽 검증, 의존성 대규모 업그레이드처럼 되돌리기 번거로운 작업도 격리된 박스에서 돌리고 망가지면 그 박스만 버립니다.
• 데이터에 가까운 쪽에서 에이전트를 돌립니다. VPC 안에서만 접근할 수 있는 DB, 사내 전용 내부 서비스, 내려받기 부담스러운 데이터셋. 이런 경우에는 노트북으로 가져오는 대신 그 옆에 에이전트를 띄우는 편이 더 빠르고 안전합니다. 터널을 오가는 것은 대시보드 트래픽뿐이며, 작업 사본과 데이터는 원격에 그대로 남습니다.
• 스펙을 필요한 만큼만 빌립니다. 로컬은 구입 시점의 사양으로 고정되지만, 원격은 그렇지 않습니다. 큰 작업을 할 때는 원격 배포 인스턴스의 티어를 잠시 power 타입으로 올렸다가, 작업이 끝나면 kirocrew cloud stop 명령어로 중지해 EBS 비용만 지불할 수 있습니다. 메모리 16GB가 부족한 순간에 64GB를 30분만 사용할수도 있습니다.

Kiro Crew 우리팀 온보딩 시키기

1. 원격 Kiro Crew 설치하기

배포에 앞서 로컬에는 AWS CLI와 Session Manager 플러그인이 설치돼 있어야 합니다. OS별 설치 방법은 공식 문서 ‘AWS CLI 설치, 업데이트 및 제거‘와 ‘AWS CLI용 Session Manager 플러그인 설치‘를 참고하세요. 그다음 배포에 쓸 권한을 갖춘 프로필을 등록합니다.

(1) 새로운 Kiro Crew Cloud 자동 배포

왼쪽 메뉴에서 [설정] > [원격 Crew]로 이동한 후 [Set up a new one]을 선택합니다. AWS 관련 사전 설정을 완료하고 구성이 올바른지 검증합니다. 이어서 원하는 인스턴스 크기를 설정한 뒤 [Launch]를 클릭하여 배포합니다. 배포에는 약 10~15분이 소요됩니다. 배포가 완료되면, Kirocrew remote에 자동으로 등록되는 것을 확인할 수 있습니다. 이후 상단바의 왼쪽을 확인 및 선택하여, 원격으로 연결된 Kirocrew를 로컬 대시보드 환경에서 설정해볼수 있습니다.

그림13. Kiro Crew 원격 Crew 설정 화면 (Set up a new one)

(2) 기존 Kiro Crew 리모트 추가

이미 배포해 둔 원격 Crew가 있다면 새로 띄우지 않고 바로 연결할 수 있습니다. [Your crews] 설정 하단에서 기존 인스턴스를 추가하면 됩니다.

그림14. Kiro Crew 원격 Crew 설정 화면 (직접 설정)

(3) 예산 계산해보기

원격 Crew는 내 AWS 계정에서 돌아가므로, 인스턴스를 띄우기 전에 대략의 월 비용을 가늠해 두면 좋습니다. 아래는 이 글을 쓰는 시점 기준 서울 리전(ap-northeast-2)의 온디맨드 요금을 참고용으로 정리한 것입니다. 실제 청구액은 사용량과 요금 변동에 따라 달라지니, 정확한 금액은 AWS Pricing Calculator로 확인하시길 권합니다. 먼저 인스턴스 크기(compute)에 따른 요금입니다.

Kiro Crew가 기본으로 배포하는 스택은 EC2 인스턴스와 EBS 볼륨, 보안 그룹, IAM 역할만 만들고, 인터넷 게이트웨이를 통해 외부와 직접 통신할 수 있는 계정의 기본 VPC에 인스턴스를 올립니다.

기본 티어인 t4g.xlarge를 실제로 돌릴 때, 부대 비용(공인 IPv4 + EBS 40 GB)까지 합친 월 총액은 다음과 같습니다.

만약 –subnet으로 프라이빗(NAT 라우팅) 서브넷을 직접 지정하면 이야기가 달라집니다. 그 경우 NAT 게이트웨이(월 ~$43)와 Elastic IP 비용이 별도로 붙고, 인스턴스를 꺼도 NAT는 계속 과금됩니다. 사내에 이미 NAT가 있다면 상관없지만, 개인 계정이라면 기본 경로(기본 VPC)를 그대로 쓰는 편이 훨씬 저렴합니다.

2. Kiro Crew 업무 할당하기

2.1 GitHub Issue 태그 자동 분류 맡기기

저장소에 이슈가 올라오면 가장 먼저 할 일은 분류입니다. 버그 리포트인지, 기능 요청인지, 단순 문서 수정인지 이슈를 읽고 라벨을 붙이는 일 자체는 어렵지 않지만, 수십 개가 밀리면 이내 아무도 손대지 않게 됩니다. Issue Radar 앱은 바로 이 분류 작업을 Kiro Crew에게 맡깁니다.

(1) 저장소 연결하기

그림15. Kiro Crew – Issue Radar 저장소 연결하기

Issue Radar를 설치하고 첫 번째로 할 일은 감시할 저장소를 연결하는 것입니다.

1. Issue Radar 페이지에서 [다른 저장소 연결] 클릭
2. GitHub(또는 GitLab) 저장소 URL 입력 (예: https://github.com/my-org/my-repo)
3. 로컬에 설정된 gh CLI 인증으로 접근 권한 자동 검증

연결이 끝나면 Issue Radar는 60초마다 저장소를 폴링하며 새 이슈와 PR을 추적합니다.

(2) 에이전트로 라벨 정리하기

그림16. Kiro Crew – Issue Radar 에서 이슈 태그 필터링

Issue Radar 열면 이슈가 목록으로 뜹니다. Kiro Crew의 에이전트가 각 이슈의 제목과 본문을 읽고, 저장소에 이미 정의된 태그 중에서 알맞은 것을 골라 라벨을 제안합니다. 다만 에이전트가 라벨을 직접 붙이지는 않습니다. 실제 적용은 사용자가 UI에서 확인한 뒤 라벨을 눌러야 이뤄집니다.

그림17. Kiro Crew – Issue Radar 에서 이슈 태그 자동화

(3) 더 나아가기: 이슈의 원인 사전 조사

그림18. Kiro Crew – Issue Radar 에서 이슈 조사하기

라벨 분류 외에 Issue Radar는 이슈 조사 기능도 제공합니다. 이슈 카드의 조사 버튼을 누르면 그 이슈를 맥락으로 삼는 에이전트 세션이 열리고, 에이전트가 코드를 훑으며 원인을 분석합니다. 분석 결과는 이슈 카드에 기록됩니다. 같은 이슈를 다시 열면 이전 세션이 이어지므로, 추가 질문을 던져 조사를 더 깊이 파고들 수 있습니다.

2.2 GitHub PR 리뷰 자동화하기

PR 리뷰는 팀에서 가장 병목이 되기 쉬운 일입니다. 리뷰어가 붙기까지 하루 넘게 걸리는 경우도 흔하고, 바쁜 와중에 보안 문제나 성능 이슈를 놓치기도 합니다. Code Review Sage 앱은 PR이 올라오면 에이전트가 코드를 읽고 구조화된 리뷰를 만들어 줍니다.

(1) 저장소 연결하기

Code Review Sage도 가장 먼저 리뷰할 저장소를 연결해야 합니다. 대시보드 사이드바에서 저장소를 추가하면 그 저장소의 open PR 목록이 바로 뜹니다. Issue Radar와 마찬가지로 gh CLI 인증이 필요합니다.

(2) 에이전트로 PR 리뷰하기

그림19. Kiro Crew – Code Review Sage 에서 PR 리뷰하기

Code Review Sage 대시보드에서 리뷰할 PR을 고르고 리뷰 버튼을 누르면, Kiro Crew의 에이전트가 변경 사항을 읽어 설계와 코드 품질을 검토합니다. PR 하나만 지정할 수도 있고, 저장소의 open PR 전체를 한 번에 배치로 돌릴 수도 있습니다. 같은 커밋으로 이미 리뷰한 PR은 자동으로 건너뛰므로 중복 리뷰가 생기지 않습니다. 에이전트는 변경된 코드의 정확성·보안·성능·에러 처리 등을 살펴보고, 발견한 문제마다 심각도를 매깁니다.

• 리뷰 필요: 배포를 막아야 할 수준의 문제
• 살펴볼 만함: 고칠 가치는 있지만 당장 위험하지는 않은 문제
• 문제 없음: 위험도가 낮고 변경 범위도 작아 더 지적할 것이 없는 경우

그리고 이 개별 판정을 종합해 PR 전체에 Red(차단)·Yellow(주의)·Green(통과) 등급을 매깁니다.

(3)GitHub PR에 리뷰 게시하기

그림20. Kiro Crew – Code Review Sage 에서 PR 코멘트 게시하기

리뷰가 끝나면 결과는 먼저 앱 대시보드에서 확인합니다. 각 발견 사항을 검토한 뒤 GitHub PR에 올릴 코멘트 초안을 작성하고, 댓글로 제출 버튼을 누르면 PR에 전체 판정 요약과 함께 문제가 있는 파일의 해당 라인마다 인라인 코멘트가 달립니다. 게시된 리뷰는 GitHub에서 미제출(Draft) 상태로 만들어지므로, 사람이 “Submit review”를 눌러야 비로소 공개됩니다.

Code Review Sage는 시간이 지날수록 우리 팀의 코드 컨벤션에 맞춰 리뷰 품질이 나아집니다. PR에서 지적한 문제가 실제 수정 커밋으로 이어지면, 에이전트가 자신이 어떤 패턴을 놓쳤는지 분석해 학습 후보로 기록합니다. 이렇게 쌓인 패턴은 이후 리뷰에 자동으로 반영됩니다. 예를 들어 “우리 팀은 DB 마이그레이션 PR에서 항상 rollback 스크립트를 확인한다”는 패턴이 쌓이면, 다음 마이그레이션 PR부터 에이전트가 이를 알아서 체크합니다.

마무리

지금까지 Kiro Crew의 구조와 핵심 기능을 살펴보고, AWS에 원격 Crew를 배포해 Issue Radar와 Code Review Sage로 이슈 분류와 사전 조사, PR 리뷰를 맡기는 과정까지 따라가 봤습니다. 이런 작업은 대시보드에서 직접 실행할 수도 있지만, 스케줄과 엮으면 팀의 아침을 바꿔 놓을 수 있습니다. 이를테면 매일 새벽 미분류 이슈에 라벨을 제안하거나 밤사이 열린 PR의 리뷰 초안을 미리 만들어 두도록 예약해 두는 식이죠. 그러면 사람은 빈 목록 앞에서 하루를 시작하는 대신, 이미 준비된 결과를 검토하는 데서 시작하게 됩니다.

잘 맡기는 요령은, 사람의 판단이 필요한 일과 에이전트에 넘겨도 되는 일을 처음부터 나눠 두는 것입니다. 조사와 정리, 리뷰 초안 작성처럼 결정을 위한 밑작업은 Kiro Crew에 맡기고, 라벨을 실제로 적용하거나 리뷰를 공개하는 최종 판단은 사람이 확인하고 누르는 자리에 남겨 두면 됩니다. 실제로 이 두 앱은 그렇게 설계돼 있어, 에이전트는 제안과 초안까지만 준비하고 마지막 한 번의 클릭은 사람 몫으로 둡니다. 여기에 민감 경로·자격 증명 접근은 실행 경계에서 차단되고 세션은 서로 격리되니, 넘길 일은 안심하고 넘기면서 지켜야 할 판단만 손에 쥘 수 있습니다.

처음부터 완벽한 자동화를 노릴 필요는 없습니다. 미분류 이슈 정리든 PR 리뷰 초안이든 하나만 골라 맡겨 보고, 결과가 믿을 만하면 스케줄과 앱을 하나씩 더해 나가면 됩니다. 그렇게 교훈이 쌓일수록 Kiro Crew는 우리 팀의 컨벤션과 저장소를 아는 팀원에 점점 가까워집니다. 지금 여러분의 저장소에서 가장 오래 밀려 있는 일 하나로 시작해 보시기 바랍니다.

끝으로, Kiro Crew는 지금도 활발히 개발되며 새로운 기능이 계속 더해지고 있습니다. 앞으로 이 팀원이 얼마나 더 유능해질지, 함께 기대하며 지켜봐 주시길 바랍니다.