Kiro Crew로 만드는 무인 PR 브리핑 에이전트
들어가며
2026년 8월, AWS Kiro 팀이 오픈소스로 공개한 Kiro Crew는 “세션이 끝나도 지속되고, 스스로 학습하는 개발 워크스페이스”를 표방합니다. 개념 설명은 공식 블로그에 잘 정리되어 있으므로, 이 글에서는 간단한 AI Agent를 직접 하나 만들어보면서 핵심 기능을 검증해보겠습니다.
만들 것은 매일 아침 9시에 열린 PR을 요약해서 Slack으로 전달하는 무인 브리핑 에이전트입니다. 단순한 시나리오지만 MCP 연결, 스킬 정의, 서브에이전트 병렬 처리, 무인 스케줄 실행, 승인 게이트, 레슨 학습까지 Kiro Crew의 대표 기능을 한 바퀴 돌게 되는 구성입니다. (어떤 기능을 어디에 사용했는지는 글 마지막에 표로 정리해두었습니다.)
실습 환경
| 항목 | 내용 |
|---|---|
| 배포 대상 | AWS EC2 (Amazon Linux / Ubuntu) + Docker |
| 런타임 요건 | Python 3.10+, Node.js 18+ (소스 빌드 시) |
| 필요한 것 | Kiro 계정, GitHub PAT, Slack 워크스페이스 |
목표 아키텍처
Kiro Crew는 로컬에서도 실행할 수 있지만, 무인 실행이 전제인 에이전트이므로 이번 사례에서는 EC2 인스턴스에 Docker로 Gateway를 올리는 상시 구동 구성을 선택했습니다. 공식 문서의 remote host 배포 모델을 AWS에 적용한 형태입니다.
먼저 배포 모델을 이해하고 넘어가겠습니다. Kiro Crew는 별도의 클라우드 컨트롤 플레인 없이, Gateway, 에이전트 세션, ACP 프로세스(kiro-cli), 상태 데이터가 전부 하나의 호스트에 함께 위치하는 구조입니다. 즉, 이번 아키텍처에서 “에이전트가 실제로 실행되는 곳”은 EC2 인스턴스 하나이며, 웹 대시보드, Slack, 데스크톱 앱은 모두 그 EC2의 Gateway에 접속하는 창구 역할만 합니다. 개발자 PC에는 아무것도 설치할 필요 없이 SSH 터널로 대시보드에 접속하거나 Slack으로 대화하면 됩니다.
EC2를 선택한 이유는 매일 아침 무인 스케줄 실행이 전제라서 24시간 켜져 있는 호스트가 필요하기 때문입니다. 같은 이유가 충족된다면 로컬 맥, 홈서버, 다른 클라우드 VM 등 어떤 호스트든 무방합니다.

다이어그램의 구성 요소는 다음과 같습니다.
| 구성 요소 | 역할 | 비고 |
|---|---|---|
| EC2 인스턴스 | Kiro Crew Gateway 컨테이너 호스트 | ghcr.io/kirodotdev/kirocrew:stable |
| Gateway | 세션, 메모리, 스케줄, 승인을 관리하는 상주 프로세스 | 원격 접근은 토큰 인증 |
| EBS 볼륨 | ~/.kiro/crew 마운트 | 컨테이너 교체에도 세션, 메모리, 레슨 영속 |
| 에이전트 세션 | 스킬 실행 및 결과 취합 | ACP 런타임 위에서 kiro-cli 구동 |
| 서브에이전트 | 레포별 PR 조사를 병렬 수행 | 격리된 컨텍스트, 결과는 부모 세션으로 반환 |
| GitHub | PR, 리뷰, CI 데이터 소스 | MCP 서버 경유 |
| Slack | 브리핑 수신 + 인라인 승인 | 아웃바운드 연결 — 인바운드 포트 개방 불필요 |
표에서 보듯 EC2 인스턴스 바깥에 있는 것은 데이터 소스(GitHub)와 사용자 접점(Slack, 브라우저)뿐입니다. 특히 Slack, GitHub 연결이 전부 아웃바운드라는 점 덕분에, EC2 보안 그룹은 SSH(22)만 열어두는 최소 구성이 가능합니다.
매일 아침의 실행 시퀀스를 그려보면 다음과 같습니다.

Step 1. 설치와 Gateway 기동
설치 경로는 4가지가 있으며, 어느 쪽이든 내부적으로 kiro-cli 위에서 동작합니다.
| 설치 경로 | 적합한 상황 |
|---|---|
| 데스크톱 앱 | 로컬에서 간단히 시작 |
| 원라인 인스톨 | 로컬, 원격 머신에 빠른 설치 |
| Docker | 상시 구동 서버 (이번 사례) |
| 소스 빌드 | 코드 수정, 기여 목적 |
이번 구성은 EC2 위에서 Docker로 구동합니다. ~/.kiro/crew에 해당하는 홈 디렉터리를 볼륨으로 마운트해 상태를 영속시키는 것이 핵심입니다.
docker run -d --name kirocrew \
-p 127.0.0.1:5476:5476 \
-v kirocrew-home:/home/kirocrew \
ghcr.io/kirodotdev/kirocrew:stable
대시보드는 loopback에만 바인딩되므로, 로컬 PC에서 SSH 터널로 접속합니다.
# 로컬 PC에서
ssh -N -L 5476:127.0.0.1:5476 ec2-user@<EC2_PUBLIC_IP>
# 이후 로컬 브라우저에서 <http://localhost:5476> 접속
첫 실행 시 kiro-cli가 없으면 자동으로 설치되고, 디바이스 코드 방식으로 Kiro 로그인을 안내합니다. 환경 점검은 명령 한 줄이면 충분합니다.
2. 조사 파이프라인 — Investigator → Triage → Graph → Reporter
kirocrew doctor
자주 만나는 초기 문제와 해법은 다음과 같습니다.
| 증상 | 원인 | 조치 |
|---|---|---|
| ACP 타임아웃 | kiro-cli 미설치/미로그인 | PATH 확인 후 로그인, 최초 MCP 기동은 시간 여유 |
| 메모리 검색이 키워드만 동작 | 임베딩 모델 다운로드 중 | ~/.kiro/crew/models 확인 — 완료되면 자동 전환 |
| MCP 설정 꼬임 | 구성 변경 누적 | kirocrew setup –agent-only (필요시 –clean) |
기존 Kiro 사용자라면 .kiro 설정(스티어링 파일, 스킬, 커스텀 에이전트)이 그대로 인식되므로 별도 마이그레이션은 필요 없습니다.
Step 2. GitHub MCP 서버 연결
에이전트가 PR 데이터를 읽으려면 GitHub 접근 수단이 필요합니다. Kiro Crew는 코어 런타임 수정 없이 MCP 서버를 추가하는 구조이므로, Kiro CLI의 MCP 설정에 GitHub MCP 서버를 등록하면 됩니다.
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
}
}
}
}
토큰은 설정 파일에 직접 넣지 말고 환경변수로 주입합니다. 이 지점에서 Kiro Crew의 크리덴셜 보호가 어떻게 겹겹이 동작하는지 정리하면 다음과 같습니다.

즉, 토큰이 프롬프트나 채팅 출력으로 새어 나가는 경로를 런타임에서 차단합니다. 설정 반영 후에는 채팅에서 “열린 PR 목록 보여줘”를 실행해 MCP 툴 호출이 정상 동작하는지 확인합니다.
Step 3. 브리핑 스킬 작성
Kiro Crew에서 스킬은 마크다운 파일입니다. 반복 실행할 워크플로우를 스킬로 정의해두면 관련 작업에서만 선택적으로 로드됩니다. PR 브리핑용 스킬을 다음과 같이 작성했습니다.
---
name: pr-briefing
description: 지정된 레포들의 열린 PR을 조사하고 리뷰 우선순위를 정리한 브리핑을 생성한다
---
# PR 브리핑 절차
1. 대상 레포: org/service-api, org/service-web, org/infra
2. 레포별 조사는 서브에이전트로 병렬 위임한다
3. 각 레포에서 수집할 항목:
- 열린 PR 목록과 마지막 업데이트 시각
- 리뷰 상태 (승인 대기 / 변경 요청 / 승인 완료)
- CI 체크 실패 여부, 실패 시 실패한 잡 이름
4. 취합 기준:
- 24시간 이상 리뷰 대기 중인 PR을 최상단에 배치
- CI 실패 PR은 실패 원인 한 줄 요약을 포함
5. 출력 형식: 레포별 섹션, PR당 한 줄, 링크 포함
6. 브리핑 생성 외의 쓰기 작업(코멘트, 재실행 등)은 반드시 승인을 요청한다
6번 항목이 설계의 핵심입니다. 기본 설정인 approval_mode: interactive와 스킬 내 규칙을 결합하면, 작업 유형별 권한이 다음처럼 나뉩니다.
| 작업 유형 | 예시 | 동작 방식 |
|---|---|---|
| 읽기 (조회) | PR 목록, 리뷰 상태, CI 체크 조회 | 에이전트 자율 수행 |
| 판단 (모델) | 우선순위 정렬, 요약 생성 | 에이전트 자율 수행 |
| 쓰기 (변경) | 코멘트 작성, 테스트 재실행, 머지 | 사용자 승인 필수 |
작성한 스킬은 채팅에서 “PR 브리핑 한번 만들어줘”로 수동 실행해 검증합니다. 이때 Activity 뷰에서 3개 레포 조사가 서브에이전트로 갈라져 병렬 실행되는 과정 및 각 에이전트의 추론, 툴 호출, 결과를 카드 단위로 실시간 확인할 수 있습니다.
Step 4. 스케줄 등록 — 무인 실행 전환
수동 실행이 검증되었으면 스케줄에 올립니다. Kiro Crew의 작업 시작 방식은 5가지 모드로 구분되는데, 이번 사례는 Scheduled 모드에 해당합니다.
| 모드 | 용도 | 진입점 | 이번 사례 |
|---|---|---|---|
| Scheduled | 브리핑, 정기 감사, 백업 | kirocrew cron / 자연어 요청 | ✅ 사용 |
| Proactive | 목표 재시도가 필요한 작업 | AutoNudge, goal-loop 스킬 | |
| Reactive | CI 알림, 외부 이벤트 대응 | 인증 웹훅, 메시징 이벤트 | 확장 후보 |
| Task runner | 체크포인트 기반 장기 프로젝트 | kirocrew run TASK.md | |
| Subagents | 병렬 독립 워크스트림 | kirocrew spawn run “task” | ✅ 스킬 내부에서 사용 |
등록은 자연어로 가능합니다. 대시보드 채팅에 다음과 같이 요청하면 타임존을 인식하는 recurring job으로 변환됩니다.
매주 평일 오전 9시에 pr-briefing 스킬로 브리핑을 생성해서 Slack DM으로 보내줘
CLI로 직접 관리할 수도 있습니다.
kirocrew cron # 등록된 recurring job 관리
kirocrew logs # 실행 로그 확인
비용 관점의 설계 포인트를 하나 짚자면, 판단이 필요 없는 데이터 수집은 모델 호출 없이 플레인 스크립트로 실행할 수 있습니다. 모델 호출을 요약, 우선순위 판단에만 사용하도록 분리하면 토큰 비용이 절감됩니다.
Step 5. Slack 연동 — 승인까지 폰에서
브리핑 수신 채널로 Slack을 연결합니다. 공식 Slack 설정 가이드를 따르면 되고, 크리덴셜은 JSON 설정이 아니라 ~/.kiro/crew/.env에 둡니다.
| 연동 후 가능해지는 것 | 설명 |
|---|---|
| 브리핑 수신 | 매일 09:00 브리핑이 Slack DM으로 도착 |
| 인라인 승인 | 쓰기 작업 승인 요청에 Slack 버튼으로 즉시 응답 |
| 컨텍스트 연속성 | 대시보드에서 시작한 대화를 Slack에서 그대로 이어받기 |
| 스트리밍 응답 | 에이전트 응답이 실시간 스트리밍으로 표시 |
Gateway 하나가 모든 상태를 보유하므로, 어느 서피스에서 접근하든 같은 워크스페이스, 같은 컨텍스트입니다. 연결이 아웃바운드 방식이라는 점도 다시 강조할 만합니다 — 대시보드 포트를 외부에 노출하지 않고도 모바일에서 에이전트를 다룰 수 있습니다.
Step 6. 교정을 레슨으로 — 에이전트 다듬기
며칠 운영해보면 고치고 싶은 부분이 나옵니다. 이때 스킬 파일을 수정하는 대신 채팅에서 지적하는 것으로 충분합니다.
드래프트 PR은 브리핑에서 제외해줘. 앞으로 계속.
이 교정이 어떻게 영구 규칙이 되는지가 Kiro Crew의 self-learning 사이클입니다.

저장된 레슨, 메모리, 스킬은 전부 대시보드에서 조회, 수정, 삭제할 수 있습니다. 에이전트가 어떤 규칙을 학습했는지 블랙박스로 남지 않고, 원치 않는 학습은 직접 제거하면 됩니다.
운영 관점 체크포인트
실서비스 코드에 접근하는 에이전트를 상시 구동하는 만큼, 기본 탑재된 보안 레이어를 짚고 넘어가겠습니다. Kiro Crew의 특징은 이 통제가 프롬프트 지시가 아니라 런타임 경계에서 강제된다는 점입니다.
| 레이어 | 내용 | 확인 방법 |
|---|---|---|
| 네트워크 | 대시보드 loopback 바인딩, 원격은 토큰 인증 | docker port / 설정 확인 |
| OS 샌드박스 | Linux namespace / macOS Seatbelt 격리 (standard, strict, off) | 설정의 sandbox 값 |
| 명령 차단 | 137개 번들 deny 패턴 — 광범위 승인 상태에서도 파괴적 명령 차단 | kirocrew security events |
| 데이터 가드 | 민감 경로 차단, 환경변수 스트리핑, 크리덴셜 마스킹 | 출력 로그 검토 |
| 감사 | 모든 툴 활동의 서명된 감사 로그 | kirocrew security audit / verify |
| 거버넌스 | 정책 파일로 권한 상한 지정 (tightest-wins) | kirocrew policy show / explain |
텔레메트리는 하루 1회 익명 하트비트(인스턴스 ID, 버전, Python 버전, 설치 채널, 최초 실행 플래그, 5개 필드)가 전부이며, 프롬프트, 파일 내용, 경로, 호스트명, IP는 수집하지 않습니다.
kirocrew telemetry disable # 비활성화
kirocrew telemetry status # 전송 내용 확인
이번 사례에서 활용한 Kiro Crew 기능 정리
브리핑 에이전트 하나를 만들면서 실제로 사용한 기능을 단계별로 정리하면 다음과 같습니다.
| # | 기능 | 이번 사례에서의 활용 |
|---|---|---|
| 1 | Gateway (상주 프로세스) | EC2 + Docker로 상시 구동, 세션, 메모리, 스케줄 상태 보유 |
| 2 | 상태 영속 | EBS 마운트로 컨테이너 교체에도 워크스페이스 유지 |
| 3 | MCP 확장 | GitHub MCP 서버로 PR, 리뷰, CI 데이터 접근 |
| 4 | 마크다운 스킬 | 브리핑 절차를 pr-briefing 스킬로 정의, 관련 작업에서만 로드 |
| 5 | 서브에이전트 병렬 위임 | 레포 3개 조사를 격리된 서브에이전트로 동시 실행 후 취합 |
| 6 | Recurring Job (Scheduled 모드) | 자연어 요청을 평일 09:00 타임존 인식 반복 작업으로 등록 |
| 7 | Slack 연동 | 브리핑 수신, 스트리밍 응답, 대화 컨텍스트 연속성 |
| 8 | 승인 게이트 | 쓰기 작업(테스트 재실행 등)은 Slack 인라인 버튼으로 승인 후 실행 |
| 9 | Durable Lesson (self-learning) | “드래프트 PR 제외” 교정을 워크스페이스 레슨으로 영구 반영 |
| 10 | Activity 관측 | 서브에이전트별 추론, 툴 호출, 결과를 카드 단위로 실시간 확인 |
| 11 | 런타임 보안 레이어 | deny 패턴, 크리덴셜 마스킹, 감사 로그가 기본 적용된 상태로 운영 |
정리와 확장 아이디어
브리핑 에이전트 하나로 Kiro Crew의 핵심 사이클(MCP 연결 → 스킬 정의 → 병렬 위임 → 무인 스케줄 → 승인 게이트 → 레슨 학습)을 확인했습니다. 같은 패턴에서 확장할 수 있는 방향을 정리하면 다음과 같습니다.
| 확장 방향 | 사용 기능 | 시나리오 예시 |
|---|---|---|
| 상태 감시 | 하트비트 | 특정 PR, 배포 상태를 조건 충족 시까지 감시 후 알림 |
| 이벤트 대응 | 인증 웹훅 (Reactive) | CI 실패 이벤트 수신 시 원인 분석 태스크 자동 시작 |
| 장기 작업 | Task Runner | 마이그레이션 계획을 TASK.md로 정의, 체크포인트 기반 실행 |
| 전용 UI | Apps / App SDK | Issue Radar 설치 또는 팀 전용 트리아지 인터페이스 제작 |
에이전트 도구가 “채팅창 안의 조수”에서 “상주하는 워크스페이스”로 넘어가는 흐름에서, Kiro Crew는 39,000명 이상의 사내 사용자 검증을 거친 상태로 오픈소스화된 드문 사례입니다. 세션 하나를 넘어서는 반복 작업이 있다면, 이 글의 구성 그대로 시작해보시기 바랍니다.
- 다운로드: https://kiro.dev/crew
- GitHub: https://github.com/kirodotdev/kirocrew
- 문서: https://kiro.dev/docs/crew/
글 | 메가존클라우드 Commercial Managed Unit 최영훈 매니저


