방에 엔지니어 셋을 모으지 않고 시스템을 이해한다, Candost가 서브모듈 66개로 만든 AI 하이브 마인드

TL;DR

• 매니저인 글쓴이는 시스템이 어떻게 연결되는지 알려고 엔지니어 서너 명을 한 방에 모으던 일을 없애려고 했다. 첫 시도인 Notion 범용 에이전트는 한 팀의 범위에서는 쓸 만했으나 도메인을 넘자 신뢰하기 어려워졌고, 두 번째로 저장소 약 66개를 서브모듈로 묶은 하이브 마인드를 만들었다.
• 핵심 설계는 제품과 팀 구조에 맞춘 폴더, 도메인마다 둔 AGENTS.md, 저장소 하나에만 범위를 둔 백그라운드 에이전트, 그들이 JSON 보고서로 넘기는 구조화된 핸드오버다. 저장소가 열 개쯤 넘자 모델이 임의로 움직이기 시작했다는 것이 이유다.
• 조직 지식은 주간 자동 루프로 갱신한다. 에이전트가 지난주 Notion과 Slack 변화를 보고서로 만들어 GitHub 이슈를 열면 Cursor 클라우드 에이전트가 문서를 고치는 PR을 올리고 사람이 검토해 병합한다.
• 글쓴이는 설정의 80%가 끝났다고 보며 자동 서브모듈 갱신과 Slack 멘션 연동은 아직 계획이다. 성능이나 시간 절감의 측정값은 글에 없다.

풀려던 문제

글쓴이는 SumUp에서 여러 도메인에 걸친 프로젝트를 맡는다. 각 도메인은 수십 개의 서비스와 애플리케이션으로 이뤄져 있고 시스템 전체를 아는 사람이 없어서 어떻게 동작하는지 알아내려면 매번 서너 명을 한 방에 모아야 했다고 한다. 그는 Mermaid 다이어그램과 Miro 보드, RFC, PRD로 버텼지만 변화 속도, 특히 AI 이후의 속도가 빨라져 같은 방식으로는 어려워졌다.

목표는 두 가지다. 주 목표는 그 ‘방에 모으는’ 단계를 없애는 것이다. 애플리케이션과 서비스, 도구, 인프라가 어떻게 연결되는지를 코드베이스와 팀 구조라는 결정적 지식과 합쳐서 알아내는 것이다. 부 목표는 문서에 적히지도 공유되지도 않은 암묵지를 끌어내는 메커니즘을 만드는 것이다.

첫 시도와 두 번째 시도

첫 시도는 Notion 커스텀 에이전트에 GitHub 등을 연결하고 지침 문서를 써 준 것이다. 한 팀의 도메인에 한정했을 때는 유용했지만 도메인 경계를 넘자 한계가 보였다. 연결하는 도메인과 저장소가 늘수록 올바른 정보를 못 찾았고 명시적으로 읽으라고 한 문서를 빠뜨리거나 도구 호출이 시간 초과로 실패하기도 했다. 신뢰도는 ‘쓸 만한’ 수준이었지만 자기 일을 맡길 정도는 아니었다고 평한다. 그래서 다음 AI SaaS를 찾는 대신 직접 만들기로 했다.

SumUp 전체는 저장소가 수천 개, Slack 채널이 수천 개라서 전부를 다루지 않고 SumUp의 핵심 세 영역, 곧 도메인 둘과 공용 모바일 앱 하나로 범위를 제한하고 자신이 맡은 도메인을 중심에 뒀다. 결과물은 단일 저장소에 다른 저장소(현재 약 66개)를 git 서브모듈로 붙이고 각자의 AGENTS.md를 두는 구조다. 구성 요소는 AI 도구 네 가지(OpenCode가 핵심이고 LLM 제공자에 연결되며, Notion과 Cursor가 주간 지식 갱신에 쓰인다), 사용자를 돕는 커스텀 에이전트 여섯 개, 다수의 AGENTS.md와 MEMORY.md, SOUL.md, 정보를 모아 보고서와 이슈를 만드는 에이전트, 지식 베이스를 갱신하는 PR 에이전트, 사람 한 명, 그리고 서브모듈 관리용 CLI다.

폴더는 기술 스택(Kotlin이나 Go)이 아니라 제품과 팀의 구조로 나눴다. 예를 들어 domains/sales와 domains/payments 아래에 각각 repos/와 AGENTS.md를 둔다. 도메인 AGENTS.md에는 도메인 정의와 원칙, 구조, 폐기 예정 서비스, 진행 중인 중대형 프로젝트가 들어가고 저장소 개별 맥락은 넣지 않는다. 초기 내용은 Notion과 Slack에서 AI로 추출해 자신의 조직 지식과 무작위 점검으로 검증했으며 글쓴이는 이 작업이 시간을 가장 많이 썼고 교차 도메인 질문에 좋은 답이 나올 때까지 여러 번 고쳤다고 밝힌다. 한 번에 다 붙이지 않고 몇 개만 붙여 시험했다.

왜 커스텀 에이전트를 썼나

글쓴이의 관찰로는 Anthropic의 Opus가 힘들어하기 시작한 지점이 저장소 약 10개였다. 그 뒤로는 모델이 임의로 서브에이전트를 띄우기도 하고 스스로 일을 떠맡기도 해서, 서로 다른 도메인의 저장소를 같은 범위로 착각했다. ‘중요’나 ‘반드시’ 같은 단어로 강하게 지시해도 모델이 제멋대로 판단해서 길들일 필요가 있었다는 것이다. 이 관찰은 글쓴이의 경험이며 통제된 실험은 아니다.

그가 든 이유는 네 가지다. 저장소 하나로 범위를 좁힌 에이전트를 띄워 맥락을 작게 유지하려는 것, 저장소 하나 안에서는 Opus급이 필요 없고 Sonnet이나 GPT-Terra, 심지어 Haiku로도 충분하므로 비용을 아끼려는 것, 범용 서브에이전트의 핸드오버가 제각각이라 도메인 간 일관된 구조화 보고서가 필요한 것, 그리고 구조화된 핸드오버가 있는 시스템을 설계해 보며 배우려는 것이다. Fable의 높은 추론 설정이라면 아마 처리할 수 있겠지만 자기 예산으로는 너무 비싸고, 경험상 주 에이전트가 특정 백그라운드 에이전트를 특정 명령으로 띄울 때 결과가 훨씬 낫다고도 적었다.

구성은 주 에이전트 셋과 백그라운드 서브에이전트 둘이다. 주 에이전트는 General Companion, Primary Investigator, Primary Brainstormer이고 서브에이전트는 Domain Investigator와 Repository Inspector다. 사용자는 주 에이전트만 쓰고 백그라운드 에이전트를 직접 띄울 수 없다. 백그라운드 에이전트는 Zod 스키마로 정의한 JSON 보고서를 쓰고 이것이 에이전트 사이의 핸드오버 문서가 된다. 글쓴이는 사람 팀이 도메인마다 인수인계 문서를 두는 방식과 닮았다고 설명한다.

조사형 주 에이전트는 먼저 관련 도메인과 저장소를 추정하고 로드되지 않은 저장소는 내려받고 조사 계획을 세워 백그라운드 에이전트를 띄운 뒤 보고서를 합쳐 연결점을 찾아 최종 보고서를 만든다. 최종 보고서는 JSON 출력으로 만든 단일 HTML 파일이라 그대로 남에게 보낼 수 있다. 브레인스토밍 에이전트도 같은 방식이되 목적이 해결안 탐색이다. 도메인별로 장단점과 권고안을 만든 뒤 전체 생태계에 맞는 접근을 종합한다. 글쓴이는 도메인별로 따로 평가할 때 장단점 목록을 나열하는 것보다 더 풍부한 논의와 트레이드오프가 나온 경험을 근거로 든다.

세 번째 주 에이전트는 Mind of the Hive로, 기술만으로 풀리지 않는 문제를 위해 조직 맥락을 더한 것이다. 이 에이전트는 조직 구조와 가치, 엔지니어링 전략, DDD와 Conway의 법칙, Team Topologies 같은 리더의 사고 틀을 맥락으로 갖는다. 다른 주 에이전트를 필요하면 띄울 수 있지만 백그라운드 에이전트를 직접 띄우지는 못한다. 모든 주 에이전트는 복잡한 질의를 다뤄야 하므로 Opus 같은 좋은 최신 모델을 쓴다.

지식을 최신으로 유지하는 루프

글쓴이는 이 시스템이 결국 누군가 맥락을 갱신해 줘야 하는 개인에게 의존한다는 점을 문제로 삼는다. 그가 매일 조직을 따라가며 쌓는 맥락, 즉 조직 간 시스템 연결과 주고받는 데이터, 폐기하거나 시작할 흐름, 지금과 앞으로의 어려움은 그가 손을 놓는 순간 공유가 끊긴다. 처음에는 RAG를 검토했으나 과하다고 판단했다. 필요한 것은 초기 정보 집합과 지난주에 일어난 일의 주간 갱신이었기 때문이다.

그래서 만든 자동 루프는 다섯 단계다(주간 조사, 이슈 생성, Cursor 호출, PR 작성, 사람 검토). 커스텀 에이전트가 Notion과 Slack에서 지난주 업데이트를 조사해 주간 보고서를 쓰고 저장소에 GitHub 이슈로 올리며 Cursor 클라우드 에이전트를 띄워 보고서를 읽고 관련 컨텍스트 파일을 조사해 PR을 만들게 한다. 사람이 PR을 읽고 고친 뒤 병합하고 이슈를 닫는다. 주간 조사 에이전트는 1M 컨텍스트 모델을 쓰며 더 작은 컨텍스트의 모델은 실패했다고 한다. 그 뒤 서브모듈은 주 1회 수동으로 갱신하고 자동화는 곧 하겠다고 적었다.

부록의 세부와 글의 한계

OpenCode를 고른 이유는 모델을 바꿔 가며 맞는 것을 찾을 수 있다는 점이다. Claude Code는 좋은 하네스지만 장애가 나면 쓸 수 없고 특정 제공자에 묶이고 싶지 않다고 한다. OpenCode가 오픈 소스이고 플러그인 생태계가 활발하며 제품 매니저 같은 비개발자가 쓸 수 있는 데스크톱 앱이 있다는 점도 든다. 서브모듈이 열 개를 넘으면 관리가 어려워 만든 CLI는 모듈과 그룹의 로드와 언로드, 도메인 단위 처리, 상태 확인, 디스크 절약용 삭제를 지원하며 본인이 바이브 코딩으로 만들어 어떻게 동작하는지 모른다고 솔직히 적는다. 에이전트도 git 대신 이 CLI를 써서 토큰을 아낀다.

향후 과제는 에이전트 실행 전에 필요한 서브모듈만 갱신하는 단계, 깃허브 액션 기반의 크론 갱신, GitHub 없이 클라우드에서 조사하기, 모든 사용자의 실행에서 MEMORY.md를 갱신해 저장소에 밀어 넣기, 그리고 궁극 목표인 Slack 멘션으로 주 에이전트를 호출하기다.

읽을 때 유의할 점은 분명하다. 이 글은 한 사람이 자기 조직에서 만든 설정을 설명한 경험담이며 성능 평가가 없다. 교차 도메인 질문에 정확한 답이 나오는 비율, 서너 명을 모으던 시간이 얼마나 줄었는지, 비용이 얼마인지는 제시되지 않는다. 또 글에 나오는 모델 이름(Opus, Fable, GPT-Sol, GPT-Terra 등)은 글쓴이의 표기를 그대로 옮긴 것이고, 모델 사이의 능력 차이는 그의 인상이다. 전체 조직에 적용하지 않고 세 영역으로 범위를 좁혔다는 점, 암묵지의 품질을 사람이 검토해 병합한다는 점은 적용할 때 가장 참고할 만한 대목이다. 서브모듈이 커지면 관리 비용과 디스크, 갱신 지연이 문제가 된다는 것도 글이 스스로 인정한다.

참고 자료

Candost — Building an AI Hive Mind to Understand Systems as a Manager — 본문 전체와 부록, 향후 개선 항목을 읽고 정리했다. 게시일은 페이지에서 확인하지 못해 source_published를 비웠다.