Blog

AWS Kiro를 활용한 바이브코딩 협업 및 관리 환경 구축

Tags: , , ,


AI-RE DEVELOPMENT COLLABORATION MODEL
AWS Kiro와 Notion을 활용한
멀티에이전트 개발 협업 환경 구축
 
다수의 개발자와 다수의 AI Agent가 하나의 공통 지침과 프로젝트 정보를 기준으로 협업하는 AI-RE의 바이브코딩 개발체계

핵심 메시지
AI-RE 팀은 Kiro의 Spec 기반 개발과 Steering, Hooks를 기반으로 Git의 재현성, Notion의 실시간 협업성, 자체 도메인 Lock과 변경 감지 절차를 결합했습니다. 그 결과 여러 개발자와 Agent가 동시에 작업하더라도 동일한 기준과 승인된 기획 버전을 중심으로 개발할 수 있는 협업 방식을 실험하고 있습니다. 다만 Agent 권한, Snapshot 버전 관리, Lock 병렬성, 정량 성과 측정은 계속 고도화하고 있습니다.

Kiro
출처 — Kiro 공식 블로그 ‘Introducing Kiro’ (kiro.dev/blog/introducing-kiro)
01
AWS Kiro란
개발자의 편집 화면 안에서 AI Agent가 함께 일하는 개발 도구입니다.
AWS Kiro는 AI Agent에게 지시를 내리면 Agent가 저장소의 코드를 직접 수정하는 편집기(IDE)입니다. 지시는 편집 화면 옆 대화 패널에 입력하고, Agent는 저장소 전체를 읽은 뒤 관련 파일을 작성하고 수정합니다.
Agent가 작업에 쓰는 문서와 규칙은 저장소 안 .kiro 폴더에 파일로 쌓입니다. 크게 세 가지입니다.
📋
스펙 (spec)
.kiro/specs
기능 하나에 폴더 하나가 생기고, 그 안에 요구사항 · 설계 · 작업 목록 문서가 들어갑니다.
  
🧭
스티어링 (steering)
.kiro/steering
프로젝트 규칙을 적어 두면 모든 대화에 자동으로 붙습니다. 조건을 걸어 특정 파일을 만질 때만 붙일 수도 있습니다.
  
🔧
훅 (hook)
.kiro/hooks
파일 저장이나 작업 시작 같은 사건에 검사를 걸어 둡니다. 조건이 맞지 않으면 실행을 막을 수도 있습니다.
일반적인 코딩 보조 도구가 지금 이 파일을 어떻게 고칠지를 다룬다면, Kiro는 기능 하나를 어떤 순서로 만들 것인가를 다룹니다. 그래서 산출물이 코드 조각이 아니라 문서와 작업 목록의 형태로 먼저 나옵니다.
— 요구사항 → 설계 → 작업 목록 → 구현 순서로 진행하며, 각 단계는 사람이 승인해야 다음으로 넘어갑니다.
— 가벼운 수정은 대화 방식으로 바로 처리하고, 여러 파일에 걸친 기능 단위 작업에만 문서 방식을 씁니다.
— 변경마다 승인받는 방식과 맡겨 두고 결과를 검토하는 방식 중에서 작업 성격에 따라 고릅니다.

02
AI-RE(에어) 프로젝트 개요
솔루션팀에서 개발 중인 데이터분석플랫폼. 민감정보를 밖으로 내보내지 않고 분석하도록 만든 제품입니다.
🔒
격리된 분석환경
인터넷과 차단된 작업공간 안에서만 데이터가 열립니다.
  
🚪
반출입 통제
파일 이동은 검사와 결재를 거친 단일 경로로만 가능합니다.
  
🏢
기관 단위 분리
한 플랫폼을 여러 기관이 쓰되 데이터와 권한은 섞이지 않습니다.
권한·결재·감사기록·격리환경이 서로 물려 돌아가는 구조여서 개발 단위를 14개 도메인으로 쪼갭니다. 이 도메인이 뒤에 나오는 작업 점유(lock)와 진척 측정의 기준 단위입니다.
01 역할과 권한  ·  02 프로젝트  ·  03 결재  ·  04 데이터 카탈로그  ·  05 권한 모델  ·  06 반출입  ·  07 분석환경  ·  08 계정·인증·테넌트  ·  09 조직/팀  ·  10 요금  ·  11 감사 로그  ·  12 알림  ·  13 테넌트 정책  ·  14 다국어
— 백엔드·프론트엔드·인프라·테스트 각 영역에서 Agent가 투입됩니다.
— 한 사람이 여러 Agent를 동시에 운용하며, 기획 확인부터 문서화까지 맡깁니다.
— 사람은 판단과 검토, Agent는 지침에 따른 실행으로 역할을 구분합니다.

03
일반적인 바이브코딩과 AI-RE 방식의 차이
같은 도구를 쓰지만 운영 방식이 다릅니다.
구분 일반적인 바이브코딩 AI-RE 협업형 바이브코딩
협업 구조 개발자 1명이 하나 이상의 AI Agent를 개인적으로 활용 다수의 개발자가 각자의 멀티에이전트를 사용하여 하나의 제품을 공동 개발
지침 관리 개발자 개인의 프롬프트와 로컬 문서에 의존 Notion에 공통 지침과 기획·명세를 통합하고 모든 Agent가 작업 전에 최신 내용을 확인
변경 전파 Git 커밋과 병합이 완료되어야 다른 개발자에게 반영 Notion의 공통 원본을 갱신하면 다른 개발자와 Agent가 즉시 최신 지침을 참조
작업 충돌 누가 어디를 고치는지 알 수 없어, 병합 시점에야 충돌을 발견 도메인 단위로 작업을 점유(lock)하여 한 영역에 활성 작업은 하나. 착수 전에 충돌을 차단
관리 관점 개별 작업과 코드 생성 중심 PM Agent가 코드, 일정, 품질, 리스크를 지속 분석하여 프로젝트 관리를 지원

04
Notion 기반 공통 지침 관리체계
Agent에게 들어가는 정보가 사람마다 다르면 구현 방향과 코드 구조가 달라질 수 있습니다. 분류 기준은 “얼마나 빨리 퍼져야 하는가” 하나입니다.
처음에는 모든 Agent 지침을 저장소에 두었습니다. 한 개발자가 지침을 수정했지만 커밋 전이었고, 그사이 다른 개발자의 Agent가 이전 규칙으로 API를 생성해 DTO와 오류 응답 형식을 다시 맞춰야 했습니다. 이후 변경이 잦은 기획을 Notion으로 옮겼더니, 이번에는 작업 재현성이 떨어졌습니다. 두 번을 겪고 나서 정한 기준이 아래와 같습니다.
보관 위치 판단
Agent가 참조하는
모든 정보
 →
자주 바뀌는가?
 아니오 ↗

예 ↘
🗃 Git — 코드와 불변 규칙
📓 Notion — 기획·명세·진행 상태
위치 대상 이유
Git 소스코드
협업 프로토콜 문서(CLAUDE.md)
영역별 Agent 지침(BE·FE·품질·인프라)		 소스코드는 형상관리가 기본입니다. 규칙과 지침도 자주 바뀌지 않는 데다 바뀔 때는 코드와 함께 리뷰를 거쳐야 하므로, 변경 이력이 코드와 같은 타임라인에 남는 편이 추적에 유리합니다.
Notion 기획 4개 페이지
feature별 Spec·Plan·Tasks
도메인 점유 현황판
도메인별 TODO 인덱스		 자주 바뀌고, 바뀐 내용이 즉시 공유돼야 합니다. 공유가 늦어지면 설계 불일치로 이어질 수 있습니다.
왜 Git만으로 관리하지 않는가
Git은 승인된 규칙과 코드의 변경 이력을 관리하는 데 적합하지만, 작성 중인 기획과 진행 상태를 즉시 공유하는 데는 별도의 커밋 · 푸시 과정이 필요합니다. AI-RE에서는 승인과 재현성이 중요한 규칙은 Git에 두고, 여러 참여자가 수시로 갱신하는 기획과 작업 상태는 Notion에서 관리했습니다.
  
Agent의 Notion 직접 접근
사람이 복사해 옮기지 않습니다. Agent가 API로 직접 읽고, 작업이 끝나면 상태와 변경 이력을 직접 기록합니다. 사람이 옮겨 적는 단계가 남으면 그 지점이 불일치의 발생원이 됩니다. 다만 Agent가 최신이 아닌 페이지를 참조해 옛 명세대로 구현한 적이 있어, 참조할 페이지를 지침에 명시하고 폐기한 페이지는 보관함으로 옮겼습니다.

05
기능 개발 절차
“만들어 달라”는 한 번의 지시로 끝내지 않고 5단계를 거칩니다. 아래는 감사 로그 조회 화면 추가 건의 실제 흐름입니다.
① Spec
② Plan
③ Tasks
④ 구현
⑤ PR
단계 산출물 이 건에서는 사람의 역할
① Spec 무엇을 만들 것인가 “누가 언제 무엇을 했는지”를 관리자가 조건으로 검색하고 결과를 파일로 내려받게 한다 범위 확정. 애매한 지점은 Agent가 되묻습니다
② Plan 구현 방식 + 영향 도메인 선언 11 감사 로그(주 도메인), 01 역할과 권한(read-only — 조회 권한만 참조) 설계 승인. 여기서 도메인 lock 확정
③ Tasks 의존 순서대로 정렬한 작업 목록 조회 API 추가 → 검색·필터 화면 → 파일 내려받기 → 권한 검사 테스트 누락 확인
④ 구현 코드와 테스트 Agent가 작성하고, 허용 범위 안에서 테스트가 통과할 때까지 반복 수정합니다 화면은 레이아웃 선승인 필수
⑤ PR 리뷰와 병합 main 기준 rebase → 검증 재실행 → 리뷰 → 병합 → lock 해제 코드 리뷰와 최종 승인
단계를 나누는 이유 — 바로 구현을 지시하면 코드는 빠르게 나오지만, 그 결과가 의도와 맞는지 확인할 지점이 없습니다. 단계를 나누면 방향 오류를 코드가 아니라 문서 단계에서 확인할 수 있습니다.

06
협업 규칙과 게이트
여럿이 동시에 작업할 때는 규칙을 지키자는 합의만으로 어긋남을 막기 어렵습니다. 그래서 자동으로 감지하고 중단하는 검증 게이트를 두고, 사람과 Agent에 동일한 절차를 예외 없이 적용합니다.
작업 개시 절차
두 번의 확인을 모두 통과해야 도메인을 점유하고 작업에 들어갑니다.
작업 범위 파악
↓
충돌 체크
점유 중인 도메인과 겹치는가
 예 →
STOP
owner 간 경계 조율
↓ 아니오
기획 변경 체크
snapshot 이후 변경이 있었는가
 예 →
STOP
방향 재확인 후 재개
↓ 아니오
Notion lock 획득
Status를 In Progress로 전이
↓
단계 실행
최초 1회가 아니라 단계 전환 때마다 반복합니다.
게이트 무엇을 검사하나 감지되면 검사 시점
🔒 모듈 owner제 내가 선언한 도메인이 다른 feature와 겹치는가 착수 불가. 경계 재조정 · 완료 대기 · 범위 재설정 중 택일 Plan 단계
🕔 기획 snapshot 대조 착수 때 기록한 기획 4개 페이지의 수정 시각이 그대로인가 즉시 중단. 변경 이력을 사람에게 제시하고 판단을 받아야 재개 단계 전환 · PR 직전
🔁 Status 전이 재검증 확인 시점과 lock 주장 시점 사이에 남이 먼저 들어오지 않았는가 전이 보류. 충돌 해소 후 다시 시도 전이 4회 전부
lock 입자
(주 도메인)·(BE only)·(FE only)·(read-only) 마커로 실제 수정 대상만 잠급니다. 		  왜 대조를 강제하나
Agent는 착수 이후 기획이 바뀌었는지를 스스로 확인하지 않습니다. 		  완료 문서 동결
병합된 feature 문서는 수정하지 않고, 보완이 필요하면 후속 feature로 분리합니다.

07
개발자와 AI의 역할 분담
위임 범위를 넓히더라도 되돌리기 어려운 결정은 개발자의 사전 승인을 거칩니다.
주체 역할
사람 개발자 목표 정의 · 기술 의사결정 · 작업 지시 · 산출물 검토 · 코드 리뷰 · 도메인 충돌 조정 · 최종 승인
개발 AI Agent 지침 확인 · 기존 코드 분석 · 설계 초안 · 코드 작성과 수정 · 테스트 · 정합성 검증 · 문서와 이력 기록
BE·FE·품질·인프라 영역별 지침을 각각 보유
PM Agent 진척 분석 · 일정 대비 비교 · 도메인별 구현 상태 측정 · 배포 준비도 점검 · 리스크 식별 · 대시보드 작성
🖥 화면 구현 직전
Agent가 ASCII 레이아웃과 인터랙션·권한 분기·에지 케이스를 먼저 제시합니다. 확정 전에는 코드를 쓰지 않고, 확정안은 Notion에 남깁니다.
  
🔀 PR 병합 직전
CI를 모두 통과해도 사람 리뷰를 거칩니다. 선언 범위 준수와 snapshot confirmed 여부가 체크 항목입니다.
  
💰 비용·아키텍처 판단
클라우드 자원, 구조 방향, 도구 선택은 Agent가 선택지와 권고까지, 결정은 사람이 합니다.

08
PM Agent를 활용한 진척·리스크 관리
작업 건수를 세지 않고 origin/main 코드를 직접 확인해 도메인별 진척을 판정합니다.
1
진척을 재는 방법
측정은 두 갈래로 나눕니다. 기능이 얼마나 구현됐는지와, 그 코드를 떠받치는 개발 기반이 건강한지입니다. 처음에는 작업 목록의 완료 개수로 셌는데, 문서상으로는 끝났지만 화면이 동작하지 않는 경우가 있어 집계가 체감과 어긋났습니다. 그래서 코드에서 직접 확인하는 방식으로 바꿨습니다.
기능 진척  — 기획한 것 중 얼마나 구현됐나 (도메인별 %로 산출)
BE 구조
controller · service · entity 존재
DB 마이그레이션
platform · tenant Flyway 목록
FE 화면
라우트 등록 + 페이지 구현
Spec 완료율
spec 상태 + tasks 체크박스
개발 트랙 건전성  — 기획에 안 잡히는 기반 (%가 아니라 상태와 신호로)
엔지니어링·아키텍처
구조 전환 잔여 작업, 모듈 경계 유지 여부
품질·테스트
E2E·프론트 유닛·백엔드 통합 테스트 증감
인프라·DevOps
CI, 배포 파이프라인, 관측성, 운영 문서
기술 부채
TODO 마커 추세, 코드와 문서의 알려진 모순
도메인별 판정값에 가중치를 곱해 전체 진척률을 냅니다. 기획서와 와이어프레임만 있는 것, 아직 병합되지 않은 로컬 작업은 진척으로 인정하지 않습니다.
2
관리 주기
상시 — 코드와 Spec 변화, 도메인별 진척, 테스트 현황과 병목을 점검
주간 — 기능 진척과 일정 경과를 비교하고 전주 대비 변화·신규 리스크를 리포트
리스크 — 알림 도메인, 결재 연계, CD 파이프라인, 관측성, 운영 Runbook을 우선순위로 관리
보고 — 대시보드를 자동 생성해 개발자와 관리자가 같은 근거로 판단

09
협업 환경의 기대효과
앞의 규칙과 게이트가 실제로 바꾸는 것들입니다.
항목 체계가 없을 때 현재
개발 방향 Agent마다 다른 규칙을 받아 구조와 스타일이 달라짐 전원이 같은 기획·아키텍처·코딩 규칙을 참조
변경 전파 커밋과 병합이 끝나야 다른 사람에게 도달 Notion 갱신 즉시 다음 작업부터 최신 기준 적용
병렬 작업 같은 곳을 동시에 고치고 병합 때 충돌 발견 도메인 점유가 공유되어 착수 전에 감지됨
재작업 기획 변경을 인지하지 못해 여러 Agent의 재작업이 누적될 수 있음 단계 전환 시점에 감지되어 재작업 범위가 한 단계로 제한
진척 파악 담당자 체감에 의존한 보고 PM Agent가 코드를 근거로 산출해 전원이 같은 수치를 확인
의사결정 통제 Agent 판단이 그대로 코드에 반영 주요 결정은 사람 승인, 근거는 feature 단위로 기록

 
AI-RE가 지향하는 개발 방식
AI가 사람을 대신하는 구조가 아닙니다. 사람이 기준과 판단을 쥐고, 여러 Agent가 그 기준 안에서 실행을 넓히는 구조입니다. Notion의 공통 지침, Git의 소스 형상관리, PM Agent의 진척·리스크 관리를 묶어 다수의 개발자와 AI가 한 팀처럼 움직이는 환경을 만들고 있습니다.

조회수 : 17