4개의 제품, 1개의 CEO 에이전트 — Lain을 활용한 멀티 프로젝트 오케스트레이션 (Multi-Project Orchestration)

화요일 오전 9시. Lain이 시간 단위의 정기 점검을 수행합니다. Lain은 네 개의 KittyClaw 보드 — Bloomii, Kalceo, VizMail, Ekioo — 를 열고, 담당자가 지정된 Todo 티켓들을 평가한 뒤 배정합니다. 콘텐츠 작가 (content-writer)가 Bloomii 기사 작성을 시작하는 동안, 프로그래머 (programmer)는 VizMail의 버그를 해결합니다. 동시에 Kalceo의 QA 테스터 (qa-tester)는 테스트 스위트 (test suite)를 실행합니다. 저는 수동으로 아무것도 실행하지 않았습니다. 그저 커피를 마시고 있을 뿐입니다.

이것이 현재 시스템의 상태입니다. 이 시스템이 어떻게 구축되었는지, 실제로 무엇을 변화시키는지, 그리고 여전히 무엇이 작동하지 않는지에 대해 설명하겠습니다.

세 개의 라이브 프로젝트가 이 시스템에 데이터를 공급합니다: 사회적 및 환경적 대안을 다루는 건설적 저널리즘 미디어 매체인 Bloomii, 프랑스 건설 계약업체를 위한 규제 관련 B2B SaaS인 Kalceo, 그리고 이 기사의 배경이 되는 에이전트 군단 (agent-fleet) R&D 프로젝트인 Ekioo입니다. 세 프로젝트 모두 AI 에이전트를 위한 칸반 오케스트레이터 (kanban orchestrator)인 KittyClaw 위에서 구동됩니다.

구조: 4개의 프로젝트, 1명의 CEO

각기 고유한 전문 에이전트 군단 (fleet)을 가진 4개의 활성 프로젝트:

• Bloomii — 그린 테크 (Green Tech) 콘텐츠 사이트. 에이전트 군단: 콘텐츠 작가 (content-writer), 팩트 체크 담당자 (fact-checker), 평가자 (evaluator), 커미터 (committer).
• Kalceo — 건설업체를 위한 BTP SaaS. 에이전트 군단: 프로그래머 (programmer), QA 테스터 (qa-tester), 커미터 (committer), 콘텐츠 작가 (content-writer).
• VizMail — 의미론적 분류 (semantic sorting) 기능이 있는 데스크톱 메일 클라이언트. 에이전트 군단: 프로그래머 (programmer), QA 테스터 (qa-tester), 커미터 (committer).
• KittyClaw — 칸반 (kanban) 그 자체. 에이전트 군단: 프로그래머 (programmer), QA 테스터 (qa-tester), 커미터 (committer), 평가자 (evaluator).

Lain은 이 프로젝트 군단 중 어느 곳에도 속해 있지 않습니다. Lain은 이들 위에 위치합니다. Lain의 역할은 시간 단위의 보드 검토, 에이전트 배정, 그리고 티켓이 너무 오래 차단 (blocked)되어 있을 경우 소유자에게 에스컬레이션 (escalation)하는 것입니다. 코드를 짜는 에이전트가 아니라, cron 위에서 실행되는 CEO입니다.

각 플릿(fleet)은 완전히 격리된 상태로 운영됩니다. 즉, 별도의 git 워크트리(worktrees)와 프로젝트별 에이전트별 영구 메모리(persistent memory)를 가집니다. Bloomii의 콘텐츠 작성자(content-writer)는 VizMail의 존재를 전혀 알지 못합니다.

무엇이 변하는가

수동적인 컨텍스트 스위칭(context-switching)이 사라집니다. 이것이 가장 구체적인 변화입니다. 이전에는 Bloomii에서 Kalceo로 전환하려면 컨텍스트를 다시 불러와야 했습니다. 우리가 어디까지 진행했는지, 우선순위는 무엇인지, 누가 무엇을 해야 하는지 등을 말이죠. 이제는 티켓 설명(ticket description)이 컨텍스트를 담고 있습니다. Lain이 이를 읽고 적절한 에이전트를 배정하면, 해당 에이전트가 차례로 내용을 읽습니다. 컨텍스트 스위칭은 여전히 존재하지만, 이제는 위임되었습니다.

프로젝트가 병렬로 진행됩니다. Bloomii 기사가 작성되는 동안, VizMail은 30개의 새로운 테스트를 병합(merge)할 수 있고, Kalceo는 3개의 결제 버그를 해결할 수 있으며, Ekioo는 X(구 트위터)에 포스팅을 할 수 있습니다. 이는 순차적인 것이 아니라 동시적인(concurrent) 작업입니다.

병목 현상(bottleneck)의 위치가 바뀝니다. 더 이상 개발 역량이 문제가 아니라 검증(validation)이 문제가 됩니다. 루프 내에 있는 유일한 인간은 저뿐입니다. 모든 PR(Pull Request)은 저를 거쳐야 합니다. 한꺼번에 5개의 티켓이 리뷰(Review) 단계로 들어오면 — 실제로 이런 일이 발생합니다 — 에이전트가 아니라 제가 병목 지점이 됩니다.

실제 수치 (2026-05-13 기준)

이 시스템은 몇 달 동안 운영되어 왔습니다. 프로젝트별 현재 상태는 다음과 같습니다:

프로젝트	지표
Bloomii	40개 이상의 발행된 기사, 5개의 균형 잡힌 편집 기둥 (editorial pillars)
...

이 수치들은 단기간에 몰아친 스프린트(sprint)의 결과가 아닙니다. 수개월 동안 꾸준한 리듬(cadence)을 유지하며 티켓 하나하나, 실행(run) 하나하나가 쌓여 만들어진 결과입니다.

여전히 발생하는 문제

솔직해져야겠습니다. 이 시스템은 완벽하지 않습니다.

무한 루프(Infinite loops). 일부 resume 자동화(automations)는 가드(guard) 없이 재실행됩니다. 만약 automations.json에 종료 조건(exit condition)이 제대로 연결되어 있지 않다면, '차단됨(Blocked)' 상태에 빠진 에이전트가 무한히 재시작될 수 있습니다. 이런 일이 여전히 발생합니다. 새로운 자동화가 추가될 때마다 종료 경로(exit path)에 대한 명시적인 검증이 필요합니다.

Lain에 남는 잔여 인지 부하 (Residual cognitive load). Lain은 매 라운드마다 프로젝트 간 컨텍스트 스위칭 (context-switches)을 수행합니다. 각 배정 (dispatch) 결정이 단순하더라도, 평가해야 할 프로젝트와 티켓이 쌓이면서 0이 아닌 부하가 발생합니다. 활성 프로젝트가 4개일 때는 관리 가능하지만, 8개가 되면 이는 아키텍처 (architectural) 문제로 변할 것입니다.

메모리 읽기 지연 시간 (Memory read latency). 모든 에이전트는 자신의 memory.md를 읽는 것으로 실행을 시작합니다. 밀도 높은 메모리를 가진 에이전트(콘텐츠 작성 에이전트는 약 100행 정도)의 경우, 이는 세션 시작 시 컨텍스트 (context)의 일부를 차지합니다. 메모리는 가치 있지만, 아직 우리가 제대로 측정하지 못하고 있는 읽기 비용 (read cost)이 존재합니다.

이것이 증명하는 것

이것이 가장 인상적인 기술은 아닙니다. 이것은 Claude 에이전트들이 티켓을 읽고 코드를 커밋 (commit)하는 과정입니다. KittyClaw를 오케스트레이터 (orchestrator)로, automations.json을 파이프라인 (pipeline)으로, memory.md를 지속적인 학습 (persistent learning) 도구로 사용하는 기반 아키텍처 (architecture)는 혁명적이지 않습니다. 다만 재현 가능할 뿐입니다.

구축하기 어려운 것은 운영상의 규율 (operational discipline)입니다: 잘 작성된 티켓, 명확한 컨텍스트 (context), 일관된 git 워크플로우 (workflow), 유지 관리되는 메모리 같은 것들 말입니다. 에이전트는 모호한 티켓을 보완해주지 않습니다. 오케스트레이션 (orchestration)의 품질은 백로그 (backlog)의 품질에 직접적으로 의존합니다.

만약 유사한 것을 구축하고 있다면, 하나의 프로젝트, 하나의 플릿 (fleet), 하나의 완전한 사이클(ticket → agent → PR → review)부터 시작하세요. 그 사이클이 당신 없이도 돌아갈 때, 두 번째 프로젝트를 추가하십시오.

Lain은 마법이 아닙니다. 잘 설계된 인프라스트럭처 (infrastructure) 위에서 잘 설정된 에이전트가 실행되는 것입니다. 시스템을 유지하느냐 탈선시키느냐의 차이는 모델의 정교함이 아니라, preamble.md에 정의된 규칙의 엄격함에 달려 있습니다.