24시간 멈추지 않는 AI 개발팀 — MegaDB 멀티머신 하네스 회고
이 글은 이전 포스트에서 소개한 MegaDB 프로젝트의 후속편이다. MegaDB가 어떤 프로젝트인지는 해당 글을 참고하면 된다. 이번 글에서는 개발 과정에서 사용한 멀티머신 AI 에이전트 하네스의 구조와 운영 경험을 다룬다.
지난 한 달여간, 혼자서는 수년이 걸렸을 규모의 프로젝트를 38일 만에 마무리했다. 249,658줄의 Rust 코드, 14개 crate, 365개 소스 파일. 숫자만 보면 믿기 어렵지만, 이건 단순한 코드 생성의 이야기가 아니다. AI 에이전트들로 구성된 팀을 어떻게 조직하고, 어떤 구조로 일을 시켰고, 그 과정에서 무엇을 배웠는지에 대한 기록이다.
프로젝트의 세 시대
MegaDB는 Rust로 작성된 데이터베이스 엔진이다. OLTP와 OLAP를 모두 지원하고, SQL 파서, pgwire 프로토콜, gRPC, K8s 오퍼레이터, 벡터 검색, 그래프 쿼리까지 포함하는 꽤 큰 규모의 시스템이다.
개발은 세 단계를 거쳤다.
ERA 1: Solo Dev ERA 2: Agent Integration ERA 3: Multi-Machine Harness
(2/24-26) (2/27 - 3/20) (3/21 - 4/2)
◄───── 3일 ─────► ◄──────── 22일 ────────► ◄────── 12일 ──────►
┌───────────────────┬──────────────────────────────┬──────────────────────────┐
│ 프로젝트 부트스트랩 │ 단일 에이전트 가속 │ 3개 자율 에이전트 │
│ 타입, 스키마 │ Storage → SQL → Compute │ master-db + app-dev │
│ 16 PR │ → Network │ + reviewer │
│ 8 PR/day │ 328 PR, 14.9 PR/day │ 173 PR, 15.7 PR/day │
│ 28K LOC │ +168K LOC │ +54K LOC (전수 리뷰) │
└───────────────────┴──────────────────────────────┴──────────────────────────┘
Era 1 (2월 24일 ~ 26일): 3일간의 부트스트랩. 혼자서 9개 crate를 스캐폴딩하고 기본 타입과 설정을 잡았다. 하루 8 PR, 약 28K LOC. 일반적인 프로젝트 초기 단계다.
Era 2 (2월 27일 ~ 3월 20일): Claude Code를 단일 에이전트로 투입한 22일. 여기서 폭발적인 성장이 시작되었다. 하루 평균 14.9 PR, 총 328 PR이 머지되었고 168K LOC가 추가되었다. 스토리지 엔진, SQL 파서, 컴퓨트 레이어, 네트워크 서버까지 핵심 기능 대부분이 이 시기에 만들어졌다. 다만 코드 리뷰는 없었고, CI도 제대로 돌아가지 않았다. 속도는 빨랐지만 품질 게이트가 없는 상태였다.
Era 3 (3월 21일 ~ 4월 2일): 멀티머신 하네스를 도입한 12일. 3대의 AI 에이전트가 각자의 역할을 가지고 자율적으로 동작하기 시작했다. PR/day는 15.7로 Era 2와 비슷한 수준을 유지하면서도, 모든 PR이 리뷰를 거치고 CI가 통과된 상태로 머지되었다.
핵심은 이거다. 속도를 유지하면서 품질을 올렸다. 보통 둘 중 하나를 택해야 하는데, 에이전트 팀 구조가 이 트레이드오프를 깼다.
24시간 동작하는 AI 팀
하네스의 구조는 이렇다.
Machine 0 (Advisor): 사람이 담당하는 전략 레이어. 코드를 직접 쓰지 않는다. GitHub Issue를 통해 우선순위를 정하고, 전체 방향을 조율한다.
Machine 1 (master-db): 5개 코어 crate를 담당하는 에이전트. megadb-core, megadb-storage, megadb-compute, megadb-k8s, megadb-crypto. SIMD 최적화, 스토리지 엔진, K8s 오퍼레이터 같은 저수준 작업에 집중한다.
Machine 2 (app-dev): 9개 상위 crate를 담당하는 에이전트. SQL 파서, 네트워크 서버, CLI, 인증(OIDC/SAML/SCIM), 벡터/그래프 검색 등 애플리케이션 레벨 기능을 맡는다.
Machine 3 (reviewer): 읽기 전용 에이전트. 코드를 작성하지 않고, 모든 PR에 대해 기계적 검증과 6차원 아키텍처 리뷰를 수행한다. 품질 게이트 그 자체다.
┌─────────────────────────────────────────────────────────────┐
│ Machine 0: Advisor (Human) │
│ 전략 수립 · 하네스 모니터링 · 우선순위 결정 │
│ 코드 작성: 없음 │
└────────────────────────────┬────────────────────────────────┘
│ GitHub Issues로 작업 할당
▼
┌────────────────────────────┐ ┌────────────────────────────┐
│ Machine 1: master-db │ │ Machine 2: app-dev │
│ │ │ │
│ 5 Crates: │ │ 9 Crates: │
│ · megadb-core │ │ · megadb-sql │
│ · megadb-storage │ │ · megadb-network │
│ · megadb-compute │ │ · megadb-catalog │
│ · megadb-k8s │ │ · megadb-vector / graph │
│ · megadb-crypto │ │ · megadb-llm / fts / onnx │
│ │ │ · msql-cli │
│ Storage, SIMD, K8s │ │ SQL, API, CLI │
└─────────────┬──────────────┘ └──────────────┬─────────────┘
│ │
└──────────────┬──────────────────┘
▼
release-candidate 브랜치로 PR 오픈
▼
┌─────────────────────────────────────────────────────────────┐
│ Machine 3: Reviewer (Quality Gate) │
│ 기계적 검증 → 6차원 아키텍처 리뷰 → 승인/반려 │
│ 코드 작성: 없음 (읽기 전용) │
└─────────────────────────────────────────────────────────────┘
이 구조의 가장 큰 장점은 시간에 구애받지 않는다는 것이다. 내가 자는 동안에도 master-db는 스토리지 엔진의 cognitive complexity를 줄이고 있었고, app-dev는 SCIM 프로비저닝을 구현하고 있었으며, reviewer는 올라온 PR들을 하나하나 검토하고 있었다. 아침에 일어나면 밤새 처리된 PR 목록과 리뷰 코멘트가 쌓여 있다. 인간의 근무시간이라는 제약이 사라진 것이다.
데이터가 이를 뒷받침한다. 하네스 기간 동안 이슈의 중간값 사이클 타임이 3.4시간이었다. 이슈가 생성되고 해결되기까지 평균 반나절도 걸리지 않았다는 뜻이다. 피크 시에는 하루 39 PR이 머지되기도 했다.
.claude/ 디렉토리: 에이전트 시스템의 설계도
하네스의 마법은 GitHub의 자동화가 아니라, 프로젝트 루트의 .claude/ 디렉토리에 있다. 이곳은 에이전트들이 서로를 이해하고 조율하기 위한 인프라 코드다.
.claude/
├── workspace-claude.md ← Team constitution
├── agents/ ← 7 sub-agent prompts
│ ├── database-architect.md
│ ├── rust-systems-developer.md
│ ├── database-optimizer-architect.md
│ ├── data-engineering-specialist.md
│ ├── data-specialist.md
│ ├── database-architect-developer.md
│ └── system-performance-engineer.md
├── prompts/ ← 4 machine prompts
│ ├── machine-0-advisor.md
│ ├── machine-1-master-db.md
│ ├── machine-2-app-dev.md
│ └── machine-3-reviewer.md
├── scripts/ ← Launch & config
│ ├── launch.sh
│ └── check-deps.sh
└── templates/ ← PR/Issue templates
├── pull_request.md
└── issue.md
workspace-claude.md 는 마치 팀 헌법 같은 문서다. 여기에는:
- Crate 소유권 맵: 어떤 에이전트가 어떤 crate를 소유하는지 명시
- 의존성 그래프: 14개 crate 간의 정확한 의존 관계
- 통신 프로토콜: GitHub Issue/PR을 통한 작업 할당 방식
- 브랜치 전략: feat/master-db/xyz 같은 명시적 브랜칭
- 신호 파일 스키마: 에이전트 간 긴급 통신을 위한 JSON 포맷
4개 머신 프롬프트는 각각이 정확히 무엇을 해야 하는지 명시한다. master-db는 "megadb-storage의 WAL 복구 로직을 개선할 것"이라고 들으면, workspace-claude.md를 참조해서 "아, 내가 소유한 crate야"라고 판단하고 즉시 작업을 시작한다. 동시에 네 가지 안전장치가 작동한다:
- check-deps.sh: 빌드 시마다 의존성 방향을 검증. app-dev가 실수로 megadb-storage를 수정했다면 빌드 자체가 실패한다.
- crate 소유권 강제: CI에서 pull 후 파일 diff를 분석해서 "이 파일은 master-db 것인데 app-dev가 수정했네?"라고 걸어낸다.
- reviewer의 자동 거부: 리뷰어가 기계적으로 "Crate ownership violation" 라벨을 달고 revert한다.
- GitHub Branch Protection: release-candidate 브랜치는 reviewer의 approval 없이 머지 불가.
이 층이 겹쳐있기 때문에, 에이전트들이 서로의 코드를 밟을 수 없다. 이건 에이전트 팀 구조에서 매우 중요한데, 인간 개발자는 "아 미안해"라고 말하면서 해결할 수 있지만, AI는 그런 협상이 어렵기 때문이다.
Session 별 컴퓨터 할당의 위력
이 하네스 구조에서 가장 핵심적인 설계 결정은 각 에이전트에게 독립된 머신(세션)을 할당한 것이다.
왜 이게 중요한가? 일반적으로 AI 코딩 어시스턴트를 사용할 때는 하나의 세션에서 모든 작업을 처리한다. 하지만 이 방식은 몇 가지 근본적인 한계가 있다.
첫째, 컨텍스트 격리. master-db 에이전트가 storage 엔진의 WAL 구현을 고치고 있을 때, 같은 세션에서 app-dev가 SQL 파서를 수정하면 컨텍스트가 뒤섞인다. 각 에이전트가 자기 crate만 바라보는 독립된 환경을 가지면, 컨텍스트 윈도우를 해당 도메인의 코드로 최대한 활용할 수 있다. master-db는 항상 megadb-storage와 megadb-compute만 로드하므로, 불필요한 컨텍스트 경쟁이 없다.
둘째, 병렬성. 하나의 세션에서는 한 번에 하나의 작업만 가능하다. 하지만 머신을 분리하면 master-db가 SIMD 벡터라이제이션을 작업하는 동안 app-dev는 gRPC 서버를 구현할 수 있다. 실제로 워크로드 시프트 패턴을 보면, 초반에는 master-db가 기반을 닦고 후반으로 갈수록 app-dev가 그 위에서 통합 작업을 하는 자연스러운 의존성 흐름이 관찰된다.
100%┤ ▒▒▒ ▒▒▒ ░▒▒ ▒▒▒ ▒▒▒ ▒▒▒ ▒▒▒ ▒▒▒ ▒▒▒ ▒▒▒
│ ▒▒▒ ■■■ ■▒▒ ■■■ ■▒▒ ▒▒▒ ▒▒▒ ▒▒▒ ▒▒▒ ░░░ ░░░
│ ▒▒▒ ■■■ ■▒▒ ■■■ ■■▒ ■■▒ ■■▒ ░░▒ ░░▒ ░░░ ░░░
│ ■■■ ■■■ ■■■ ■■■ ■■■ ░░░ ░░░ ░░░ ░░░
│ ■■■ ■■■ ■■■ ■■■ ░░░ ░░░
│ ■■■ ■■■ ■■■ ■■■ ░░░ ░░░
0%┤───────────────────────────────────────────────────────────
Mar21 22 23 25 26 27 28 29 30 31 Apr1
■ master-db ░ app-dev ▒ reviewer
◄── master-db 주도 ──►◄── 전환 ──►◄── app-dev 주도 ──►
이 패턴은 자연발생적인 의존성 흐름을 보여준다. 낮은 수준의 crate(storage, compute)가 먼저 완성되어야 높은 수준의 crate(SQL, network, CLI)가 그 위에서 통합할 수 있기 때문이다. 어떤 에이전트도 이를 명시적으로 조율하지 않았는데, 각자의 crate에 집중한 결과 자연스럽게 이렇게 됐다.
셋째, Crate 소유권 강제. 각 에이전트가 자신에게 할당된 crate만 수정할 수 있도록 제한함으로써, 머지 컨플릭트를 원천적으로 차단했다. 이건 단순한 편의가 아니라, 자율 에이전트 시스템에서는 필수적인 설계다. 에이전트가 서로의 코드를 밟으면 복구가 어렵기 때문이다. 실제로 하네스 기간 중 merge conflict는 단 한 건도 없었다.
넷째, 장애 격리. 하나의 에이전트가 문제를 일으켜도 다른 에이전트의 작업에 영향을 주지 않는다. 실제로 하네스 운영 중 3-Machine 모드에서 2-Machine 모드로 떨어진 날도 있었지만, 나머지 에이전트들은 아무 문제 없이 작업을 계속했다.
결과적으로 하네스 기간의 에이전트별 기여를 보면 작업이 고르게 분산되었다.
| 에이전트 | PR 수 | 추가 LOC | 삭제 LOC | 주요 영역 |
|---|---|---|---|---|
| master-db | 57 (33%) | +18,028 | -5,838 | 스토리지, 컴퓨트, K8s, SIMD |
| app-dev | 58 (34%) | +13,277 | -4,765 | SQL, 네트워크, CLI, 인증, 테스트 |
| reviewer | 23 (13%) | +11,138 | -7,964 | 리뷰 중 발견한 기계적 수정 |
| 기타 | 35 (20%) | +17,961 | +640 | 크로스 에이전트 머지, 하네스 설정 |
reviewer가 코드를 작성하지 않음에도 11K LOC를 추가한 것은 리뷰 과정에서 발견한 기계적 수정(lint 위반, 포맷팅 등)을 직접 반영했기 때문이다.
개발-배포-테스트 사이클
하네스의 운영 방식은 일반적인 CI/CD와 다르다. 코드를 푸시하면 자동으로 테스트되는 게 아니라, 명시적인 배포-테스트 사이클이 돈다.
1. 에이전트가 feat 브랜치에서 작업 완료
2. release-candidate로 PR 오픈 → reviewer 자동 할당
3. reviewer의 승인 후 rebase & merge
4. release-candidate이 Kubernetes에 배포 (CircleCI job)
5. E2E 테스트 자동 실행
- 4개 스토리지 엔진 검증 (MEMORY, OLTP, OLAP, TIMESERIES)
- 100+ SQL 함수 테스트
- 분산 쿼리 테스트
- 스트레스 테스트
6. 테스트 통과 → 다음 에이전트가 최신 코드로 작업 시작
이 사이클이 빠르게 도는 이유는, 각 에이전트가 자기 영역만 수정하기 때문이다. master-db가 storage API를 바꾸면 app-dev는 그 변경 사항을 보고 자기 코드를 빠르게 조정할 수 있다. 의존성이 명확하고, crate 소유권이 정해져 있으니까.
실제로 메인 배포 브랜치는 release-candidate이다. main 브랜치는 검증된 안정화 포인트로만 사용되고, 모든 에이전트는 release-candidate을 타겟으로 작업한다. 이렇게 하면 개발과 안정화가 분리되고, "언제든 deploy 가능한 상태"를 유지할 수 있다.
테스트 체계: E2E부터 퍼지 테스트까지
MegaDB는 매우 포괄적인 테스트 체계를 갖추고 있다.
유닛 테스트: 1,876개의 유닛 테스트가 모두 통과한다. 이건 단순 라인 커버리지가 아니라, 각 crate의 핵심 로직을 검증한다.
통합 테스트: 13개의 integration test 파일이 있다:
- http_e2e.rs: HTTP API 엔드포인트 테스트
- money_e2e.rs: 금융 계산 정확성 검증
- cross_engine_integration.rs: 4개 스토리지 엔진 간 호환성
- wal_recovery.rs: WAL 복구 프로토콜
- columnar_integration.rs: 컬럼 저장소 쿼리 검증
- row_integration.rs: 로우 저장소 쿼리 검증
- builder_integration.rs: K8s operator 빌드 파이프라인
- encrypt_cache_integration.rs: 암호화 캐시 일관성
- 등등
퍼지 테스트: 4개의 fuzz target이 있다:
- fuzz_sql_parser: SQL 파서 fuzzing (임의 입력에 crash 안 하는지)
- fuzz_check_constraint_parser: 제약 조건 파서
- fuzz_optimizer_pipeline: 쿼리 최적화 파이프라인
- fuzz_pgwire_queries: PostgreSQL wire protocol
스모크 테스트: 60KB짜리 smoke_test_v070.sh 스크립트는 배포 후 K8s에서 한 번에 실행되는 종합 검증이다. 모든 4개 스토리지 엔진, 100+ SQL 함수, 그래프 쿼리, 벡터 검색 등을 한 번에 테스트한다.
스트레스 테스트: 장시간 고부하 상황을 시뮬레이션해서 메모리 누수나 deadlock이 없는지 검증한다.
카오스 테스트: K8s pod을 임의로 킬하거나, 네트워크를 끊거나, 디스크를 가득 채우는 상황을 시뮬레이션한다.
이 모든 테스트가 하네스 기간에 추가되거나 개선되었다. 왜 이렇게 충실한 테스트가 나올 수 있었을까? 답은 간단하다. reviewer 에이전트가 "각 PR이 테스트를 동반해야 한다"고 기계적으로 강제했기 때문이다. 코드만 있고 테스트가 없으면 자동으로 change requested를 달았다.
통신 구조와 병목의 해결
이 하네스의 통신 매체는 GitHub이다. Issue로 작업을 할당하고, PR로 결과물을 전달하고, 리뷰 코멘트로 피드백을 주고받는다. GitHub-only 통신은 모든 작업 흐름이 기록으로 남는다는 장점이 있다. 별도의 모니터링 대시보드나 슬랙 메시지 없이도 리포지토리의 Issue/PR 히스토리만으로 전체 프로젝트 상태를 파악할 수 있다.
오케스트레이션: machine-0-advisor의 120초 사이클
Machine 0 (advisor)은 단순히 Issue를 만드는 게 아니라, 120초마다 시스템 상태를 폴링한다. 현재 병목이 뭔지, 어떤 에이전트가 idle 상태인지, 어디를 급한 우선순위로 올려야 하는지를 판단하고 작업을 할당한다. 이 피드백 루프가 빠르기 때문에, 시스템이 스스로 최적화한다.
예를 들어, Mar 31에 39 PR이 한 날에 머지되려고 했을 때, reviewer가 병목이 되었다. 이를 감지한 advisor는:
- 낮은 우선순위 issue 몇 개를 닫거나 연기
- master-db와 app-dev의 작업 속도 조절
- reviewer를 도울 수 있는 자동화 스크립트 요청
이렇게 즉각적으로 대응할 수 있었다.
Reviewer 병목과 자동 검증
실제로 3월 31일에는 하루 39 PR이 머지되려고 했는데, reviewer가 단일 에이전트인 상태에서 이 물량을 처리하는 건 쉽지 않았다. 다만 여기서 중요한 건, reviewer의 부하가 높아진다고 해서 코드 품질을 떨어뜨리지 않았다는 것이다.
대신 자동화로 부하를 흡수했다:
- check-deps.sh: crate 의존성 검증을 CI에서 자동으로
- SonarQube: 85개의 정적 분석 규칙을 자동으로 적용
- Snyk: 의존성 취약점을 자동으로 스캔
- Clippy + fmt: 코드 스타일을 CI에서 강제
reviewer가 할 일은 이 자동 검증들을 모두 통과한 PR에 대해 아키텍처 리뷰만 하면 된다. 린트 위반이나 포맷팅은 이미 통과한 PR들이니까.
신호 파일 시스템 (폐지됨)
초기에는 .claude/agent-messages/ 디렉토리에 에이전트 간 신호를 전달하는 JSON 파일을 쓰려고 했다. 하지만 결과적으로 이건 쓸모없었다. GitHub Issue/PR만으로 충분했기 때문이다. 신호 파일은 "빠르게" 통신해야 하는 긴급 상황을 가정했는데, 실제로는 그런 상황이 거의 없었다. 대부분의 조율이 GitHub의 자동 워크플로우로 처리됐다.
여전히 개선이 필요한 점
Reviewer 병목: 3월 31일 같은 피크 상황에서는 reviewer가 병목이 된다. 이를 해결하는 몇 가지 방법이 있을 수 있다:
- Reviewer 다중화: 2-3대 reviewer를 두고, 라운드로빈이나 crate 기반으로 분배
- 계층형 리뷰: CI에서 자동화 검증을 끝내고, 아키텍처 리뷰만 에이전트가 담당
에이전트 간 실시간 통신 부재: master-db가 스토리지 API를 변경하면 app-dev는 다음 Issue가 할당될 때까지 이 변경 사항을 모른다. 이건 crate 소유권으로 머지 컨플릭트를 방지한 대가이기도 하다. 장기적으로는 이벤트 버스 같은 메커니즘이 필요할 수 있다.
컨텍스트 윈도우의 한계: 프로젝트가 커질수록 단일 에이전트가 자신의 crate 전체를 컨텍스트에 올리기 어려워진다. master-db의 5개 crate만 해도 상당한 코드량이다. 장기적으로는 RAG(Retrieval-Augmented Generation) 기반 컨텍스트 관리가 필요할 수 있다.
기능적 품질 검증: SonarQube와 Snyk는 형식적 품질을 본다. 하지만 코드가 실제로 올바른 쿼리 결과를 반환하는지, 동시성 환경에서 데이터 정합성을 유지하는지는 또 다른 차원이다. 퍼지 테스트와 프로퍼티 기반 테스트를 더 강화해야 한다.
숫자가 말해주는 것
┌──────────────────────────────────────────────────────────┐
│ MegaDB Repository Activity Summary │
│ 38 Days (2/24 - 4/2) │
├──────────────────────────────────────────────────────────┤
│ │
│ 590 PRs Merged 537 Issues Created │
│ ████████████████████████ ████████████████████ │
│ Avg 15.5 PR/day 520 Closed (97%) │
│ │
│ +384,175 Lines Added -48,684 Lines Deleted │
│ ████████████████████████ ██████ │
│ +335,491 Net Growth 38 Active Days │
│ │
│ Codebase: 1,799 → 249,658 Rust LOC (+13,778%) │
│ ████████████████████████████████████████████████████ │
│ 43 → 365 .rs Files 9 → 14 Crates │
│ │
└──────────────────────────────────────────────────────────┘
일주일별 PR 처리량
PRs
170 ┤ █
│ █
160 ┤ █ 161
│ █
│ █
100 ┤ █ █
│ █ █ 98
90 ┤ █ █
│ 81 █ █
80 ┤ █ █ █
│ █ █ 74 █
70 ┤ 59 █ █ █ █
│ █ 44 █ █ █ █
60 ┤ █ █ █ █ █ █
│ █ █ █ █ █ █
50 ┤ █ █ █ █ █ █
│ █ █ █ █ █ █
40 ┤ █ █ █ █ █ █
│ █ █ █ █ █ █
└────┴─────┴─────┴─────┴─────┴─────┴──
W08 W09 W10 W11 W12 W13
2/24 3/3 3/10 3/17 3/24 3/31
| 주차 | 기간 | PR 수 |
|---|---|---|
| W08 | 2/24~ | 59 |
| W09 | 3/3~ | 44 |
| W10 | 3/10~ | 81 |
| W11 | 3/17~ | 161 |
| W12 | 3/24~ | 74 |
| W13 | 3/31~ | 98 |
가장 높은 주는 W11 (3월 17-23일)로 161 PR을 처리했다. 이건 K8s/hardening 스프린트와 하네스 도입이 겹친 시점이다.
Era별 처리량 비교
| 지표 | Era 1 — 부트스트랩 (3일) | Era 2 — 단일 에이전트 (22일) | Era 3 — 멀티머신 (12일) |
|---|---|---|---|
| PR/day | 5.3 | 14.9 | 15.7 |
| LOC/day | 4,242 | 7,632 | 5,316 |
| 이슈/day | — | 19.9 | 8.3 |
핵심 통찰: Era 2에서 Era 3으로 전환할 때, PR/day는 거의 같은데 (14.9 → 15.7) LOC/day는 낮아졌다 (7,632 → 5,316). 왜일까? 하네스 기간은 하드닝에 집중했기 때문이다. 새로운 기능보다 SonarQube 위반 수정, cognitive complexity 감소, 테스트 커버리지 개선 같은 작업을 많이 했다. 이런 작업은 코드를 지우고 재구성하는 것이라서, 순증가 LOC는 낮지만 코드 품질은 크게 올라간다.
품질 vs 속도
| 항목 | Era 1 | Era 2 | Era 3 (하네스) |
|---|---|---|---|
| PR 코드 리뷰 | 없음 | 없음 | 100% |
| Crate 소유권 | 없음 | 없음 | 강제 적용 |
| CI 파이프라인 | 없음 | 깨짐 | 5/5 통과 |
| SonarQube | 없음 | 없음 | 85개 규칙 적용 |
| Snyk 스캔 | 없음 | 없음 | 활성화 |
| 의존성 검증 | 없음 | 없음 | check-deps.sh 강제 |
| Lint 정책 | 없음 | 없음 | unwrap/expect/panic 거부 |
| 이슈 추적 | 없음 | 약함 | 완전: 생성→클로즈 3.4시간 |
이 표가 말해주는 것은, 같은 속도를 유지하면서도 모든 품질 게이트를 추가했다는 것이다. 보통 품질 프로세스를 도입하면 속도가 30-50% 떨어지는데, AI 에이전트 팀은 reviewer를 별도 머신으로 분리하고 자동화를 극대화함으로써 이 오버헤드를 흡수했다.
코드베이스 성장
LOC
250K ┤ ●───● 249,658
│ ●──┘
240K ┤ ●──┘
│ ●──┘
230K ┤ ●──┘
│ ●──┘
220K ┤ ●──┘
│ ●──┘
200K ┤ ●──┘
│ ●──┘ ← 3/20: 195K
190K ┤ ●──┘
│ ●──┘
140K ┤ ●──┘
│ ●──┘ ← 3/15: 138K
120K ┤●──┘
│● ← 3/1: 80K
80K ┤│ ← 2/28: 57K
││
10K ┤● ← 2/26: 11K
2K ┤● ← 2/24: 1.8K
└─┴────┴────┴────┴────┴────┴────┴────┴────┴────┴────┴────┴──
2/24 2/28 3/1 3/7 3/12 3/15 3/20 3/22 3/25 3/28 3/30 4/2
▲
하네스 시작
이 곡선을 보면, 하네스 시작 이후 성장 속도가 약간 완화된다. 하지만 이건 "느려졌다"가 아니라 "더 지속 가능한 속도로 전환했다"는 뜻이다. 초반 폭발적 성장은 필요했지만, 장기 유지보수를 생각하면 현재 속도가 더 건강하다.
이슈 사이클 타임
| 지표 | 값 |
|---|---|
| 중간값 (Median) | 3.4시간 |
| 평균값 (Mean) | 11.6시간 |
| 최단 | 1분 미만 |
| 최장 | 69.5시간 |
| 클로저 레이트 | 97% (520/537) |
이게 의미하는 바는, 대부분의 이슈가 한 working session 안에 처리된다는 것이다. 어떤 기능이 요청되면, 담당 에이전트가 2-3시간 내에 작업을 완료하고, reviewer가 30분 내에 리뷰를 마친다. 이 빠른 피드백 루프 덕분에, 문제가 누적될 여지가 없다.
마치며
이 프로젝트를 통해 확인한 것은, AI 에이전트를 "더 빠른 코드 생성기"로 쓰는 것과 "팀으로 조직하는 것" 사이에 큰 차이가 있다는 것이다. 단일 에이전트도 인간 대비 압도적인 처리량을 보여주지만, 멀티 에이전트 하네스는 처리량을 유지하면서 품질, 추적성, 장애 격리를 동시에 달성한다.
더 흥미로운 건, 이 구조가 자동으로 self-healing 된다는 점이다. reviewer가 병목이 되면 advisor가 자동으로 작업을 조절한다. 한 에이전트가 느려지면 나머지가 작업을 나눠 가진다. 시스템이 스스로 최적화한다.
물론 아직 갈 길이 멀다. 에이전트 간 실시간 조율, E2E 테스트 자동화, 기능적 품질 검증, 컨텍스트 관리 등 개선할 점이 많다. 하지만 38일 만에 프로덕션 수준의 데이터베이스 엔진을 만들어낸 이 경험은, 앞으로 소프트웨어 개발이 어떤 방향으로 변해갈지를 꽤 명확하게 보여준다고 생각한다.
잠을 자도 코드가 나오고, 리뷰가 돌아가고, 이슈가 닫힌다. 이게 24시간 AI 팀이 있다는 것의 의미다.
이 글에서 언급된 모든 수치와 차트는 MegaDB 리포지토리의 실제 활동 데이터에서 추출한 것입니다. 프로젝트 전체 기간: 38일, 590 PRs, 537 이슈, 249,658 Rust LOC (14 crates) release-candidate 브랜치가 최신 개발 라인입니다.