이 기사는 Claude Code 6체로 구성된 멀티 에이전트(Multi-agent) 팀 「Lady's servants」(저택)를 5개월간 운용한 기록을 되돌아보는 연재의 제2회입니다. 제1회에서는 「집사와 메이드」라는 롤플레잉(Role-playing)이 에이전트 제어의 인터페이스 계층으로 기능한다는 이야기를 썼습니다.

이번에는 타임머신을 타고 2026년 2월로 돌아갑니다. 훅(Hook)도 모니터링 데몬(Monitoring Daemon)도 보고 프로토콜(Reporting Protocol)도 아직 아무것도 없었던, 탄생 직후의 저택이 실제로 어떻게 움직였는지를 보여드립니다. 수중에 남아있던 당시의 대시보드 로그를 시각과 함께 그대로 보여드리겠습니다.

탄생은 2월 3일 밤, 2시간 만에

리포지토리(Repository)의 초기 커밋(Commit)은 2026-02-03 20:22입니다. 내용은 README가 단 2줄뿐입니다. 그 2시간 후인 22:40에 본체의 커밋이 쌓입니다.

• CLAUDE.md (저택의 규칙) 217행
• 사용인 지시서 5인분 (알프레드, 클라이브, 에마, 릴리, 소피아) 약 1,200행
• tmux 세션을 6개가 아니라...
  5개 실행하는 startup.sh 269행

합계 약 2,050행. 저택은 하룻밤 사이에 세워진 셈입니다.

이때의 멤버는 5명이었습니다. 나중에 백엔드(Backend) 담당으로 합류하는 메이드 피오나는 아직 없습니다. 당시 대시보드의 사용인 목록에는 에마의 직함이 다음과 같이 적혀 있습니다.

| 에마 | 메이드 (기술) | 대기 중 | - |

「프론트엔드(Frontend)」가 아니라 「기술」. 즉, 구현은 전부 에마가 담당합니다. 이 직함이 나중에 결정적인 역할을 하게 됩니다.

통신도 아직 원시 시대입니다. 에이전트 간의 통지는 tmux send-keys를 이용한 수동 전송이었으며, 규칙에는 다음과 같은 주의사항이 있었습니다.

# 올바른 방법 (메시지와 Enter를 두 번에 나누어 전송)
tmux send-keys -t ladys-servants-emma "태스크가 도착했습니다. 확인하십시오."
tmux send-keys -t ladys-servants-emma Enter
...

이 「Enter는 나누어서 보내라」는 함정을 모든 에이전트가 밟지 않기를 기도하며 운영했습니다. 참 잘 돌아갔다는 생각이 듭니다.

2월 10일: 기록상 첫 번째 날

탄생 1주일 후인 2월 10일이 대시보드에 남은 첫 번째 풀 가동일입니다. 이날 저는 「LINE 예약 미니 앱의 MVP를 만들고 싶다」는 의뢰를 냈습니다. 활동 로그를 거의 그대로 인용하겠습니다 (시간은 모두 실제 기록입니다).

[10:00] 아가씨로부터 의뢰: Pencil.dev 조사
[11:00] 릴리: 조사 완료
[14:00] 아가씨로부터 의뢰: MVP 개발 계획 수립
...

아침의 조사 의뢰로 시작된 하루가 심야 0시 18분의 문서 작성으로 끝납니다. 계획 승인(15:30)부터 화면 구현 완료(23:10)까지 7시간 40분. 이 사이에 에마가 수행한 구현 태스크는 Firestore Rules부터 예약 API, LINE 인증, 미니 앱 화면, 관리 화면까지 17건입니다. 빌드는 main / web 모두 성공하며 마무리되었습니다.

이 로그를 통해 알 수 있는 것

지금 다시 읽어보니, 첫날의 로그에는 이후 5개월의 모습이 모두 예고되어 있습니다.

인간의 업무는 「승인」과 「외부 서비스의 절차」가 된다.

로그상에서 제가 등장하는 부분은 계획 승인, 패키지 설치 승인(의뢰 2분 후), 스텝 3의 GO 사인, 거의 그뿐입니다. 다만 로그에 남지 않는 업무가 하나 더 있었습니다. 이 MVP는 LINE 미니 앱이므로, LINE 측의 절차——프로바이더(Provider) 생성, 채널 및 Webhook 설정과 같은 관리 화면 조작——은 제가 수행합니다. 코드는 쓰지 않게 되더라도, 외부 서비스의 GUI와 계정 관련 업무는 인간에게 남습니다. 멀티 에이전트가 잘 돌아가고 있을 때, 인간은 감독석에 앉아 있을 수 있습니다. 반대로 말하면, 인간의 승인과 수작업이 병목(Bottleneck)이 됩니다. 승인 측은 나중에 화이트리스트 방식의 훅(Hook)을 통한 자동화로 진화하며(제4회), 외부 서비스 측이 마지막까지 인간에게 남게 되는 이야기는 제7회에서 자세히 다루겠습니다.

에마가 전부 하고 있다.

17개의 태스크 전부 에마가 했습니다. 「메이드 (기술)」라는 직함 그대로 프론트와 백엔드를 혼자 담당합니다. 이것이 약 1개월 후, 가동 분석 리포트에 기반하여 백엔드 전담 피오나를 「고용」하는 조직 개편으로 이어집니다. AI 팀도 인간의 팀과 마찬가지로, 부하의 편중은 분석하지 않으면 보이지 않습니다.

페이즈 게이트(Phase Gate)가 작동하고 있다.

「페이즈 완료 → 아가씨 승인 → 다음 페이즈」라는 구분이, 폭주하지 않고·되돌리는 범위도 작게 유지되는 단위를 만들고 있습니다.

2월 15일: 시스템이 스스로를 개선하기 시작했다

첫날로부터 5일 뒤의 로그에는 또 다른 종류의 업무가 나타납니다.

[14:00] 아가씨로부터 하명: 인사이트 리포트 분석·사용인 시스템 개선 제안
[14:30] 클라이브: 릴리에게 조사 위임, 개선 제안 리포트 작성 완료
[14:40] 알프레드: 아가씨에게 개선 제안 보고, Phase 1 승인
...

자신들의 운용 로그를 분석하게 하고, 개선안을 내게 한 뒤, 그 자리에서 구현하게 합니다. 지휘 계통 위반 방지책, 큐(Queue) 통신의 신뢰성 향상 등 12개 항목을 75분 만에 적용했습니다. 앱을 만드는 것과 동일한 지휘 계통으로, 저택 그 자체를 개수하는——이 자기 개수 루프가, 이후 5개월 동안 계속해서 돌아가게 됩니다.

마음에 드는 점은, Phase 3의 2개 항목을 "운용 실적을 쌓은 뒤 검토"하겠다며 보류한 것입니다. 당시의 대시보드에는 착수 판단 기준까지 적혀 있습니다 ("병렬 디스패치(Parallel Dispatch) 3회 이상 실시 후, 통합 시 문제가 발생했을 경우" 등).

만들 수 있는 것을 전부 만들지 않는다는 판단까지 포함된 자기 개수였습니다.

그리고 이날 16:35, 수수하지만 중요한 하명을 하나 내립니다.

[16:35] 아가씨로부터 하명: 대시보드 복제 저장 규칙 추가
[16:40] 클라이브: cmd_025 완료 (instructions/alfred.md 추가 + logs/ 생성)

"대시보드를 업데이트할 때, 전날 분량을 logs/에 복제 저장하라"는 규칙입니다. 이 기사에 인용하고 있는 시각이 포함된 로그가 지금까지 남아 있는 것은, 바로 이 cmd_025 덕분입니다. 회고 기사를 쓸 수 있을지 여부는, 5개월 전의 이 수수한 한 수에 달려 있었습니다. 로그는 남겨둡시다.

2월 18~19일: 새벽 1시 34분의 버그 수정 랠리

탄생한 지 아직 2주일 남짓 된 이 날, 개발의 "속도"가 다른 형태로 나타납니다. 캘린더 UI를 둘러싸고, 14:30부터 다음 날 1:34까지 약 11시간 동안 12건의 안건(cmd_027~038)이 흘러갔습니다. 일부를 발췌합니다.

[14:30] 아가씨로부터 하명: 캘린더 당일 표시 + 하단 디자인 → cmd_027
[15:12] 에마: 수정 완료
[15:20] 아가씨: 당일 날짜의 검은 배경 디자인 수정 지적 → cmd_028 (중지)
...

지시부터 수정 완료까지는 대략 7~17분입니다. "검은 배경으로 해줘" → "역시 아니야" → "점선으로 되돌려줘"라는 디자인의 3회 왕복도, 중지 커맨드(cmd_028)로서 솔직하게 기록되어 있습니다. 인간의 시행착오를 분 단위로 추종해주기 때문에, "일단 한번 봐보자"라는 시도의 비용이 비정상적으로 저렴해집니다. 이것이 멀티 에이전트(Multi-agent) 개발에서 가장 체감이 크게 변하는 부분이라고 생각합니다.

또 하나 주목해 주었으면 하는 것은 17:10의 흐름입니다. 버그를 잡으면서, 저는 "애초에 캘린더 날짜의 상태가 정리되어 있지 않은 것 아닌가"라는 생각이 들어, 디자인 담당인 소피아에게 상태 분석을 맡겼습니다. 소피아는 "5개 상태 + 1개 수식어의 2축 모델"로 정리하여, 그대로 디자인 규칙 문서로 승화시켰습니다. 이후 이 화면의 디자인 논의는 이 문서를 참조하여 이루어지게 되었습니다. 임기응변식 대응을 체계로 변환하는 담당이 팀 내에 있다는 것은, 역할 분담형 멀티 에이전트의 미덕입니다.

이 무렵에는 아직 몰랐던 것들

여기까지 읽으면 "최소 구성으로도 충분히 돌아가잖아"라고 생각하실지도 모릅니다. 실제로, 돌아가고 있었습니다. tmux 5 세션, YAML 파일 전달, 수동 통지. 그것만으로 MVP가 하루 만에 구축되었고, 심야의 버그 랠리도 처리할 수 있었습니다.

다만, 이때의 저택은 아직 알지 못했습니다.

• "보고드립니다"라고 화면에 표시하기만 하고 보고 YAML을 쓰는 것을 잊어버리면, 아무도 알아채지 못한다는 것 (보고 데드락 사건)
• status 필드 하나에 두 가지 의미를 담은 설계가, 통지의 누락이라는 칼날이 되어 돌아올 것이라는 점
• 그리고, 모두가 --dangerously-skip-permissions로 작동하고 있었다는 점

작은 저택이 실제 프로덕트 2개를 품고 확장됨에 따라, 이 "소박함"은 차례대로 사고로 변해갑니다. 다음 편은, 그 첫 번째 사고로부터 탄생한 통신 프로토콜의 진화사——"화면에 표시하는 것만으로는 보고가 되지 않는다"는 이야기입니다.

그럼, 다음 시간에 뵙겠습니다.

Discussion