Mac mini에서 12개의 AI 에이전트로 Scrum, Jira, 그리고 Wiki를 대체하다

지난주 한 조사에 따르면 그 수치는 54%에 달했습니다. 오늘 배포되는 코드의 절반 이상이 AI에 의해 생성됩니다.

제 개인적인 업무에서는 그 수치가 아마 더 높을 것입니다. AI가 초안을 작성합니다. AI가 작업량을 추정합니다. AI가 테스트를 생성합니다. 저는 이전에 위험한 20% — 즉, 에지 케이스 (edge cases), 잘못된 상태 전이 (illegal state transitions), AI가 조용히 건너뛰는 판단 사항들에 대해 글을 쓴 적이 있습니다. 그 20% 때문에 저에게는 여전히 시니어 엔지니어 (senior engineers)가 필요합니다.

하지만 아무도 이야기하지 않는 두 번째 20%의 문제가 있습니다. 코드 내부의 문제가 아닙니다. 그 주변의 문제입니다.

스프린트 (Sprints). 스토리 포인트 (Story points). 스탠드업 (Standups). 아무도 업데이트하지 않는 Jira 보드. 작성된 당일에 이미 쓸모없어진 Confluence 페이지들. 이 모든 도구들은 한 사람이 작업을 수행하고, 또 다른 사람이 그 작업을 추적한다는 것을 전제로 합니다.

하지만 제 팀은 더 이상 그렇지 않습니다.

그래서 저는 15년 된 프로세스를 AI 네이티브 (AI-native) 팀에 맞추기 위해 억지로 끼워 맞추는 것을 그만두었습니다. 저는 저만의 작업 방식을 구축했고 이를 오픈 소스로 공개했습니다. 이것은 제 방 구석에 있는 Mac mini에서 실행됩니다. 그 내부 구성은 다음과 같습니다.

조직 전체를 하나의 숲으로 간주합니다. 각 리포지토리 (repo)는 나무이고, 각 기능 (feature)은 가지이며, 각 팀원은 세상에 존재하는 존재입니다. 이에 대한 자세한 내용은 아래에 설명되어 있지만, 네, 이것이 실제 대시보드 (dashboard)입니다.

저를 마침내 무너뜨린 것: 위키 (wiki)

깨달음을 얻은 순간은 바로 이때였습니다.

새로운 기능에 컨텍스트 (context)가 필요했습니다. 저는 우리의 위키를 열었습니다. 그 페이지는 6개월 전의 것이었습니다. 그 사이 우리는 아키텍처 (architecture)를 두 번이나 리팩토링 (refactored)했습니다. '신뢰할 수 있는 단일 원천 (source of truth)'은 자신만만하게, 그리고 완전히 틀려 있었으며, 그 주에 세 명의 엔지니어가 그것을 바탕으로 결정을 내렸습니다.

문서화 (Documentation)는 유지보수를 멈추는 순간 거짓말을 합니다. 그리고 아무도 그것을 유지보수하지 않습니다. 왜냐하면 유지보수하는 것은 우리 모두가 암묵적으로 건너뛰기로 합의한 잡무 (busywork)이기 때문입니다.

소스 코드 (Source code)는 거짓말을 하지 않습니다. 그럴 수 없습니다. 그것이 실제로 실행되는 것이기 때문입니다.

따라서 제가 구축한 시스템의 첫 번째 규칙은 다음과 같습니다: 코드가 곧 위키(wiki)입니다. 지식은 저장소(repository)로부터 추출됩니다. 즉, 콜 그래프(call graph), 모듈 경계(module boundaries), 패턴(patterns), 히스토리(history) 등을 추출하여 지속적으로 인덱싱(indexing)합니다. 에이전트나 사람이 "결제(settlement)가 어떻게 작동하나요?"라고 물으면, 답변은 누군가가 지난 분기에 작성하고 방치한 페이지가 아니라, 지금 당장 사실인 정보로부터 재구성됩니다.

Confluence도 필요 없습니다. Notion의 무덤(graveyard)도 필요 없습니다. 권위를 가질 수 있는 유일한 문서는 컴파일(compile)되는 문서뿐입니다.

[

]

아무도 이 위키를 작성하지 않았습니다. 베이스라인 스캔(baseline scan)이 저장소들을 읽어 들여 이를 생성했습니다. 4개의 저장소에 걸친 19개의 라이브 기능(live features)이 있으며, 각각은 이를 뒷받침하는 코드로 추적 가능합니다.

또한 이를 읽기 위해 대시보드(dashboard)를 열 필요조차 없습니다. Slack에서 평이한 영어로 질문하십시오. "P3 백로그(backlog) 항목이 진행 중인가요? 출시(go-live) 날짜는 언제인가요?"라고 물으면, 봇이 라이브 BUD로부터 상태, 담당자, 목표 날짜, 소스(source)로 돌아가는 링크를 답변합니다. 지난 화요일에 누군가가 보드에 입력한 숫자가 아닙니다. 지금 당장 실제로 사실인 정보입니다.

[

]

여러분이 이미 사용 중인 것과 동일한 이모지 반응(emoji-react), 스레드 답장(thread-reply) 방식의 Slack입니다. 다만 답변이 기억이 아닌 신뢰할 수 있는 원천(source of truth)으로부터 나온다는 점이 다릅니다.

따라서 "코드가 곧 위키다"라는 말은 슬로건이 아니라 하나의 아키텍처(architecture)입니다. 지식은 스스로 동기화되는 네 가지 계층(layers)에 존재합니다:

저장소 자체 (The repos themselves) — 소스 코드와 각 저장소별 CLAUDE.md가 포함되며, 모든 PR(Pull Request)이 main 브랜치로 머지(merge)될 때마다 동기화됩니다.
에이전트 기술 (Agent skills) — 조직 표준(org standards), 설계 가이드라인(design guidelines), API 패턴 등이 포함되며, 변경 시 동기화됩니다.
중앙 저장소 (The central store) — BUDs, 기업 규칙(enterprise rules), 아키텍처 결정 사항 등이 포함되며, 실시간으로 관리됩니다.
벡터 검색 (Vector search) — 이 모든 것에 대한 의미론적 검색(semantic search)이 가능하며, 자동으로 인덱싱(indexed)됩니다.

이 방식이 단순한 고급 grep 이상의 가치를 갖는 데에는 두 가지 이유가 있습니다. 첫째, 이 시스템은 **코드 위치(code locations)**를 인덱싱합니다. 따라서 개발 과정에서 캡처된 모든 지식은 그것이 유래한 정확한 파일과 심볼(symbol)을 다시 가리킵니다. 둘째, 저장소 간(across repos) 연결을 지원합니다. 즉, 프론트엔드 호출이 서로 다른 두 개의 위키(wiki)에 분리된 사실로 남는 것이 아니라, 실제로 호출되는 백엔드 핸들러(backend handler)와 연결됩니다. 또한 정보가 결코 노후화되지 않습니다. 모든 PR 머지 이후, 영향을 받은 기능은 새로운 커밋 히스토리(commit history)와 새로운 코드 위치로 자동 업데이트되므로, 다음에 해당 기능을 다루는 에이전트는 지난달의 정보가 아닌 _현재_의 진실을 상속받게 됩니다.

이것이 Confluence에 대항하는 핵심 논리입니다. 수동으로 관리하는 대신 소스로부터 자동 동기화되고, 키워드 매칭 대신 의미론적 검색이 가능하며, 일일 노후화 탐지(staleness detection)를 통해 항상 최신 상태를 유지합니다. 또한 에이전트의 프롬프트(prompts)에 직접 연결되어 있어, 에이전트가 오래된 페이지를 바탕으로 추론하는 일이 발생하지 않습니다.

에이전트 주도 개발 (Agent-Driven Development), 한눈에 보기

저는 이 방법론을 에이전트 주도 개발 (Agent-Driven Development, ADD)이라고 부릅니다. 이를 설명하는 가장 간단한 방법은 이 방식이 대체하는 기존 요소와 나란히 비교하는 것입니다.

애자일 의식 (Agile ceremony)	기존의 가정	에이전트 주도 개발 (ADD)
스프린트 계획 (Sprint planning)	인간이 모든 작업을 수행하므로, 인간의 시간을 계획함	에이전트가 초안을 작성하고, 인간은 무엇을 만들 가치가 있는지 결정함
...

여섯 개 행 전체에 흐르는 패턴은 동일합니다: 기계가 노이즈를 처리하게 하여, 인간은 판단이 실제로 중요한 곳에 판단력을 집중할 수 있도록 하는 것입니다.

12개의 에이전트

상세히 설명하기에 앞서, 전체 사이클을 하나의 다이어그램으로 보여드리겠습니다. 루프를 따라 12개의 에이전트가 배치되어 있으며, 인간은 중심부와 모든 게이트(gate)에서 검토를 수행합니다.

채팅 접수 (Triage) → BUD → 설계 (Design) → 기술 아키텍처 (Tech Architecture) (기술 리드 검토; 스마트 할당(Smart Assignment)이 개발자 선정) → 개발 (Development) (AI + 인간) → 테스트 생성 (Test Generation) → 테스트 (Testing) (QA) → UAT 및 배포 (UAT & Deploy) (상태) → 기능 (Feature) → 학습 및 기술 (Learning & Skills). 외부 버그가 발생하면 기능이 다시 열립니다. 이 루프는 결코 직선인 척하지 않습니다.

ADD는 채팅 메시지로부터 프로덕션(production)에 이르기까지 전문화된 에이전트(agent) 체인을 통해 기능을 실행합니다. 각 에이전트는 하나의 단계를 담당합니다. 인간은 모든 게이트(gate)에서 검토하고 결정합니다. 이는 설계 단계부터 의도된 '인간 참여형(human-in-the-loop)' 방식이며, 완전 무인 자동화(lights-out automation)가 아닙니다.

시작은 Slack입니다. 요청을 남기면, **접수 에이전트 (Intake agent)**는 단순히 이를 기록하는 데 그치지 않습니다. 중복 구축을 방지하기 위해 기존 기능과 BUD를 확인한 다음, 유능한 PM(Product Manager)이 할 법한 질문들, 즉 '누구를 위한 것인가?', '왜 지금인가?', '일정은 어떻게 되는가?'를 묻습니다.

"알림 아이콘을 현대적인 디자인으로 바꿔줘"라고 하면, 에이전트는 중복 여부를 확인한 뒤 단 한 줄의 코드도 작성되기 전에 의도를 심문합니다.

그 이후부터 모든 기능은 동일한 7단계 라이프사이클(lifecycle)을 거치며, 각 단계는 해당 BUD의 탭(tab)이 됩니다:

Slack 아이디어 → 접수 (Intake) → 요구사항 (Requirements) → 설계 (Design) → 기술 명세 (Tech Spec)
   → 개발 (Development) → 코드 리뷰 (Code Review) → 테스트 (Testing) → 프로덕션 (Prod)
        ↑ 추정 (estimation), 상태 (status), 학습 및 기술 (learning and skills)이 병행 실행됨 ↑

모든 단계는 에이전트(Agent)에서 실행될 수 있습니다. 또는 에이전트를 끄고 MCP (Model Context Protocol)를 통해 로컬 AI로 직접 제어할 수도 있습니다. "단계별 에이전트가 꺼졌습니다. 당신이 이 BUD를 직접 운전하고 있습니다"라는 메시지는 단계별, 담당자별로 실제로 작동하는 토글(Toggle)입니다. 이것이 바로 인간 참여형 (Human-in-the-loop)의 실제 모습입니다.

그 중추를 중심으로 기존의 의식(Ceremonies)들을 대체하는 에이전트들이 배치됩니다:

추정 (Estimation) — 스토리 포인트 (Story points) 대신 AI-PERT + 몬테카를로 (Monte Carlo) 방식을 사용합니다 (아래 참조).
상태 (Status) — PR (Pull Request)을 읽어 분석하므로, 더 이상 스탠드업 미팅을 할 필요가 없습니다.
학습 (Learning) — BUD가 종료될 때 실제 차이점 (Diffs)과 인시던트 (Incidents)를 분석합니다.
기술 (Skills) — git 히스토리를 통해 누가 무엇에 강한지 프로파일링하고, 이를 추정 및 라우팅 (Routing)에 다시 반영합니다.

에이전트는 잡무를 처리합니다. 당신은 결정을 내립니다. 이 역할 분담이 전체 철학의 핵심입니다.

스탠드업은 사람이 아닌 업무를 읽습니다

저는 몇 달 동안 상태 보고를 위한 스탠드업 미팅을 진행하지 않았습니다. 스탠드업 에이전트 (Standup Agent)가 크론 (Cron) 작업에 따라 08:30에 이를 수행하지만, 흥미로운 점은 그것이 어디에서 정보를 읽어오느냐 하는 것입니다. 에이전트는 누구에게도 "어제 무엇을 했나요?"라고 묻지 않습니다. 실제로 어떤 일이 일어났는지를 읽습니다.

각 개발자의 로컬 설정에 있는 훅 (Hooks)과 MCP 서버가 프롬프트, 커밋 (Commits), 세션과 같은 실제 신호를 BUD로 다시 게시합니다. 작업이 시작되면 TODO 항목이 자동으로 할당되고, 에이전트가 코드를 완료하면 자동으로 완료 표시가 됩니다. 따라서 아무도 보드를 업데이트하지 않아도 보드는 현실을 반영합니다. 그런 다음 에이전트는 git, PR, 버그 및 채팅 활동을 집계하여 요약본을 만들고, 지연되는 항목에는 위험 플래그 (Risk flags)를 표시합니다.

파일 수준의 TODO 4개, 모두 작업 과정 자체에서 완료됨. PR #50 머지(merged), 4개의 커밋(commits), 2개의 파일, 5번의 세션, 0개의 에러 — 보드에 직접 입력한 것이 아니라 훅(hooks)으로부터 캡처됨. 상태(status)는 별도의 잡무가 아니라 빌드(building)의 부수적인 결과물임.

그리고 디자인 에이전트(Design Agent)는 코드에서 추출한 프로젝트의 디자인 시스템 (design system) — 추측이 아닌 실제 CSS 토큰(tokens) — 을 기반으로 와이어프레임(wireframes)을 생성하기 때문에, 생성된 결과물은 구조적으로 브랜드 가이드라인을 따르게 됩니다. 기술 사양서(tech spec)도 마찬가지입니다. 실제 아키텍처(architecture)와 토큰을 바탕으로 작성되므로, "브랜드 가이드라인을 준수할 것"이라는 말이 리뷰 코멘트가 아닌 기본값(default)이 됩니다.

스스로 재할당되는 품질 루프 (The quality loop that reassigns itself)

이 부분이 제가 가장 자랑스럽게 생각하는 지점입니다. 왜냐하면 대부분의 팀이 이 과정에서 조용히 부채(debt)를 쌓아가기 때문입니다.

테스트 플랜 에이전트(Test Plan Agent)는 BUD의 수락 기준(acceptance criteria)과 코드를 바탕으로 테스트 플랜을 자동 생성합니다 — Playwright e2e, 유닛(unit) 및 통합(integration) 테스트, 보안 테스트, 그리고 여전히 사람이 승인해야 하는 수동(manual) UAT 케이스까지 포함됩니다. MCP 토큰이 QA 자동화 리포지토리(repo)를 연결해 주므로, 테스트 커밋(commits)은 BUD로 곧장 흘러 들어갑니다.