저는 지난 몇 달 동안 AI 어시스턴트(AI assistant) 대신 AI 팀을 사용하여 제 리포지토리(repos)를 운영해 왔습니다. 오늘 저는 그것을 가능하게 만든 결과물을 출시합니다. 바로 Claude Code를 위한 IRC 스타일의 에이전트 팀인 mARC입니다.

문제점부터 말씀드리겠습니다. 단일 AI 코딩 세션은 기억력도, 프로세스(process)도, 동료도 없는 천재적인 엔지니어와 같습니다. 코드는 빠르게 작성하지만, 그보다 더 빠르게 흐름을 놓칩니다. 채팅이 끝나면 결정 사항들은 증발해 버립니다. 어떤 보드(board)에도 기록되지 않는 작업들이 발생합니다. 그리고 코드를 작성한 바로 그 세션이 코드를 리뷰하게 되는데, 이는 결국 아무도 리뷰하지 않는다는 것을 의미합니다. 더 똑똑한 모델이 나온다고 해서 이 문제가 해결되지는 않습니다. 팀이 발명된 이유는 엔지니어들이 멍청해서가 아닙니다. 제품 출시(shipping)에는 구조(structure)가 필요하기 때문에 팀이 만들어진 것입니다.

그래서 mARC는 AI에게 더 큰 뇌를 주는 대신 팀 구조를 제공합니다. 채널을 열면 여러분은 코드 생성기(code generator)가 아닌 테크 리드(tech lead)처럼 행동하는 운영자(operator)인 @techlead와 대화하게 됩니다. 호출(ping)되기 전까지 채널에는 엔지니어, SRE, 디자이너, 보안 리뷰어(security reviewer), 그리고 연구원(researcher) 등 5명의 전문가가 대기하고 있습니다. 여러분이 "이슈를 저장할 때 사용자들에게 알림이 가고 있어요, 해결해 주세요"라고 말하면, 테크 리드는 사양(spec)을 작성하고, GitHub 이슈를 생성하며, 프로젝트 보드(Project board)에 등록합니다. 그리고 백그라운드에서 엔지니어에게 작업을 할당한 뒤, 작업이 진행되는 동안 여러분과 계속 대화를 나눕니다.

다음 네 가지 규칙이 이 시스템을 단순한 팬아웃 스크립트(fan-out script)가 아닌 하나의 팀으로 만듭니다.

할당 전 사양(Specs) 확정. 모호한 작업은 모호한 PR(Pull Request)을 만듭니다. 운영자는 목표, 수락 기준(acceptance criteria), 영향받는 파일, 그리고 제약 조건(constraints)이 결여된 작업은 무엇도 위임하지 않습니다. 만약 무언가 누락되었다면 운영자는 먼저 여러분에게 질문할 것입니다. 지금 질문 하나를 던지는 것이 나중에 PR을 되돌리는(reverted) 것보다 훨씬 저렴하기 때문입니다.

보드(board)는 신뢰할 수 있는 단일 정보원(source of truth)이며, 감사를 받습니다. 작업은 채팅 스크롤 기록이 아니라 GitHub 이슈와 프로젝트 보드에 존재합니다. 무언가를 할당하기 전에 운영자는 병합된 PR, 배포(deploys), CI를 대조하여 보드가 현실과 일치하는지 확인합니다. 보드는 거짓말을 할 수 있지만, 병합된 PR은 거짓말을 하지 않습니다. 여기서 상태(Status)는 실제로 의미를 갖습니다. '차단됨(Blocked)'은 여러분의 도움이 필요함을 의미하고, '완료됨(Done)'은 병합 및 검증되었음을 의미합니다.

작성자가 건너뛸 수 없는 리뷰 없이는 그 어떤 것도 병합되지 않습니다. 모든 PR (Pull Request)은 병합 전 diff (차이점)에 대해 보안 검사 (security pass)를 거칩니다. 리뷰어들은 계약상 읽기 전용 (read-only)입니다. 즉, 보안 에이전트 (security agent)와 연구원 (researcher)은 물리적으로 쓰기 도구 (write tools)를 가지고 있지 않습니다. 한때 우리는 그들에게 제한된 범위의 쓰기 폴더 (scoped write folder)를 제공하는 것을 고려했습니다. 하지만 연구원은 OWASP의 LLM 가이드라인과 GitHub의 토큰 강화 (token-hardening) 문서를 읽고 돌아와, 스스로의 쓰기 권한 부여에 반대하는 권고안을 제시했습니다. 그 아이디어는 마땅히 그래야 하듯 리뷰 과정에서 폐기되었습니다.

프로세스 자체도 버전 관리됩니다. 무언가 잘못되었을 때, 그 교훈은 채팅창에서 사라지지 않습니다. PR을 통해 플레이북 (playbook)에 기록되며, 다른 코드와 마찬가지로 리뷰를 거칩니다. 실수를 저지른 팀이 그 실수를 방지하는 규칙을 배포합니다.

이것이 실제로 작동할까요? mARC는 자체 저장소 (repository)를 운영하며, 팀을 구축하는 팀의 모든 이슈 (issue), PR, 보안 리뷰, 그리고 결정 기록 (decision record)은 공개되어 있습니다. 당혹스러운 기록들까지 포함해서 말이죠.

제가 가장 좋아하는 사례는 이렇습니다. 팀의 자체 이슈 템플릿 (issue template)이 GitHub 이슈 본문에 @dev와 같은 핸들 (handles)을 작성하고 있었습니다. 그것들은 실제 낯선 사람들이 소유한 실제 GitHub 계정들이었으며, 우리가 제출한 모든 이슈에서 언급되었습니다. 심지어 한 릴리스(release)에서는 그들을 기여자 (contributors)로 나열하기도 했습니다. 팀은 템플릿을 수정하고, 14개의 과거 이슈를 정화 (sanitized)했으며, 다시는 이런 일이 발생하지 않도록 CI 게이트 (CI gate)를 추가했습니다. 그러자 그 수정 사항에 대한 보안 리뷰 과정에서 해당 게이트가 대소문자를 구분한다는 사실이 발견되었습니다. 즉, @Dev 같은 계정은 통과되었을 것이라는 뜻입니다. grep 플래그 하나면 해결될 문제였습니다. 이것이 바로 두 번째 눈 (second pair of eyes)이 필요한 이유입니다.

기록에는 더 많은 내용이 있습니다. 보안 리뷰어가 새로운 파서 (parser)를 적대적인 값 (hostile values)으로 조사하여, PR이 반영되기 전에 두 개의 강화 (hardenings) 사항이 병합된 설정 마이그레이션 (config migration) 사례가 있습니다. 또한, 제가 두 개의 쓰기 에이전트 (writing agents)를 작업 트리 (worktrees) 격리 없이 병렬로 투입했다가 하나가 다른 하나의 체크아웃 (checkout)을 덮어버렸던 날도 있었습니다. 그 복구 과정과 그로부터 도출된 배포 규칙은 모두 공개되어 있습니다.

이것이 무엇이 아닌지 명확히 하자면: 에이전트가 단 한 번에 TODO 앱을 작성해내는 그런 데모가 아닙니다. 의도적으로 그보다 더 느리고 소란스럽습니다. 배포 전의 사양 (Specs), 병합 (merge) 전의 검토 (review), 그리고 6개월 후에도 사람이 감사 (audit)할 수 있는 기록 (paper trail)이 존재합니다. 보드 (board)는 AI가 무엇을 했는지 보여주는 시각화 도구가 아닙니다. 그것은 실제 보드입니다. 나는 보드에 있는 어떤 항목이든 직접 집어 들어 직접 수행할 수 있습니다.

2분 만에 시도해 보세요. Claude Code와 GitHub 리포지토리 (repo)가 필요합니다:

/plugin marketplace add NexaDuo/mARC
/plugin install marc@nexaduo
/marc:tech-lead

설정 (config)도, 가입 (signup)도 필요 없습니다. 런타임 (runtime)에 조직 (org), 보드 (board), 경로 (paths) 등 당신의 리포지토리를 발견합니다. 세션 (session) 간에 바인딩 (binding)을 유지하고 싶다면, /marc:init이 team.toml을 스캐폴딩 (scaffolds)하며, 무언가를 쓰기 전에 모든 파일을 보여주고, 당신의 승인 없이는 아무것도 쓰지 않습니다.

리포지토리가 실제 랜딩 페이지입니다: github.com/NexaDuo/mARC. 스스로 작동하는 AI 팀의 모든 역사(창피한 순간들 포함)가 그곳에 담겨 있습니다.