멀티 에이전트라고 하면 자연스럽게 "에이전트를 몇 개 돌릴까?", "어떤 모델을 붙일까?" 같은 질문부터 떠올렸다.
하지만 발표에서는 시작부터 그런 접근이 본질이 아니라고 이야기했다.
멀티 에이전트의 핵심은 에이전트 수가 아니라 오케스트레이션(Orchestration) 에 있다.
즉, 몇 명의 에이전트가 참여하는지가 아니라 어떤 상태에서 누가 무엇을 책임지는지, 그리고 실패했을 때 어떻게 복구되는지를 설계하는 것이 더 중요하다는 것이다.
이 관점에서 보면 나쁜 멀티 에이전트 시스템은 생각보다 단순하다.
여러 에이전트에게 같은 질문을 던지고, 나온 결과를 적당히 합치는 수준에 머문다.
결과를 평가하는 기준도 없고, 실패했을 때 어디서 문제가 발생했는지도 알 수 없다.
반면 좋은 오케스트레이션은 다르다.
각 단계의 책임이 분리되어 있고, 결과를 검증할 수 있으며, 실패하면 특정 단계로 되돌아가는 루프가 설계되어 있다.
결국 중요한 것은 "에이전트를 많이 쓰는 것"이 아니라 상태(State)와 책임(Responsibility)을 설계하는 것 이었다.
이러한 철학을 가장 잘 보여주는 사례가 발표의 중심이었던 OmC(Oh My Claude Code)였다.
OmC는 단순히 Claude Code 위에 여러 에이전트를 얹어놓은 도구가 아니다.
구조를 보면 다음과 같이 구성된다.
User Input
→ Hooks
→ Skills
→ Agents
→ State
발표에서는 Harness 관점에서 중요한 것이 "한 번의 프롬프트"가 아니라 "지속되는 운영 상태"라고 설명했다.
즉, 사용자가 입력을 한 번 던지고 결과를 받는 것이 아니라, 시스템이 여러 번의 실행을 거치면서도 동일한 상태를 유지하고 활용할 수 있어야 한다는 것이다.
그래서 OmC는 프롬프트 자체보다 Lifecycle Event와 Cross-session State를 관리하는 방향으로 설계되어 있다고 한다.
이 철학은 OmC에서 제공하는 여러 워크플로우에서도 드러난다.
/autopilot은 반복 작업을 자동화하고, /ralph는 결과를 지속적으로 검증하고 수정하며, /ultrawork는 병렬적으로 리팩토링과 개선 작업을 수행한다.
/deep-interview는 구현에 들어가기 전에 요구사항 자체를 더 명확하게 만드는 역할을 담당한다. (가장 중요한 부분이다.)
흥미로운 점은 각각의 기능이 단순히 "무언가를 수행하는 명령어"가 아니라는 것이다.
모두 특정 책임과 상태 전이를 전제로 설계된 운영 루프에 가깝다.
이 지점에서 자연스럽게 Skills 이야기가 이어졌다.
Claude Code를 사용하는 사람이라면 누구나 "좋은 Skill을 많이 만들면 생산성이 올라가지 않을까?"라는 생각을 해봤을 것이다.
실제로 Skills는 강력하다.
반복적인 절차를 캡슐화할 수 있고, 특정 도메인 규칙을 강제할 수도 있으며, 작업 품질의 최소 수준을 보장하는 데도 도움이 된다.
하지만 스킬 수가 많아질수록 어떤 스킬을 선택해야 하는지 결정하는 비용이 커지고, 스킬끼리 상태를 공유하기 어려워진다.
또한 실패, 재시도, 승인 같은 운영 로직은 결국 스킬 바깥에서 관리해야 한다.
복잡한 Skill 숲을 만드는 것보다 단순한 Skill을 좋은 상태 머신으로 지탱하는 것이 더 강력할 수 있다.
결국 문제는 Skill의 개수가 아니라 운영 구조였다.
Custom Harness에서 소개된 "나쁜 질문"과 "좋은 질문"의 대비가 매우 인상 깊었다.
우리는 흔히
- 어떤 스킬을 추가할까?
- 에이전트를 몇 개 돌릴까?
- 어떤 모델이 가장 똑똑할까?
를 고민한다.
하지만 실제로 중요한 질문은
- 어떤 루프를 자동화할 것인가?
- 실패했을 때 어떻게 복구할 것인가?
- 사람의 승인이 필요한 시점은 어디인가?
였다.
좋은 Harness는 성공 경로만 정의하지 않는다.
실패, 재시도, 승인 대기, 보류 상태까지 모두 시스템 안에서 표현할 수 있어야 한다.
이를 위해 발표에서는 좋은 Harness가 가져야 할 7가지 설계 원칙도 소개했다.
작은 공개 표면, 명시적 상태 전이, 검증 가능한 완료 조건, 사람 승인 경계, 증거 중심 보고, 격리된 실행 환경, 운영 메모리와 정책의 분리.
개별 원칙도 중요했지만, 이들을 관통하는 메시지는 하나였다.
자동화를 신뢰하려면 자동화가 무엇을 했는지 볼 수 있어야 한다.
그리고 마지막에는 이러한 개념들을 실제 운영 체계로 확장한 것이 바로 Loop Engineering이라고 설명했다.
Harness가 "한 번의 작업을 잘 수행하게 만드는 구조"라면, Loop Engineering은 "그 작업이 계속해서 잘 수행되도록 만드는 운영 체계"에 가깝다.
한 번 잘 실행되는 데모를 만드는 것과 지속적으로 동작하는 시스템을 만드는 것은 전혀 다른 문제라는 이야기다.
그래서 OmC 생태계 역시 단순한 도구들의 집합이 아니라 역할별 계층으로 구성된다.
Claude Code가 단일 코딩 에이전트라면, OmC는 이를 오케스트레이션하는 계층이다.
OpenClaw는 세션과 메모리, 이벤트를 관리하는 런타임이며, Hermes는 에이전트와 런타임을 연결한다.
그 위에서 개발가재는 실제 운영 정책과 유지보수 루프를 담당한다.
AI Agent를 이야기할 때 여전히 모델의 지능이나 프롬프트 기법에 집중하는 경우가 많다.
하지만 실제 프로덕션 환경에서는 모델보다도 상태 관리, 책임 분리, 운영 루프 설계가 더 중요한 문제가 될 수 있다.
OmC의 핵심도 결국 명령어 모음이 아니라,
CLI, Skill, Hook, State File이 같은 상태를 바라보며 협력하는 구조
에 있었다.
AI Agent의 미래는 더 똑똑한 모델을 만드는 경쟁만이 아니라, 더 신뢰할 수 있는 운영 체계를 만드는 경쟁이 될 것이라는 생각이 들었던 세션이었다.